From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eric Ludlam Newsgroups: gmane.emacs.bugs Subject: bug#42533: 28.0.50; srecode-utest-project test failing on macOS Date: Sun, 16 Aug 2020 10:41:28 -0400 Message-ID: References: <87mu3amojj.fsf@gnus.org> <87ft8u1s4f.fsf@gnus.org> <87zh6uvmvv.fsf@gnus.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000e4a52f05acffa6ca" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25992"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Philipp , Eric Ludlam , 42533@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Aug 16 16:42:18 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k7JrV-0006em-N9 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 16 Aug 2020 16:42:17 +0200 Original-Received: from localhost ([::1]:55372 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k7JrU-0004Hf-Nu for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 16 Aug 2020 10:42:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49178) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k7JrG-0004G2-ID for bug-gnu-emacs@gnu.org; Sun, 16 Aug 2020 10:42:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46580) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1k7JrG-0005DQ-90 for bug-gnu-emacs@gnu.org; Sun, 16 Aug 2020 10:42:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1k7JrG-0000Cb-7G for bug-gnu-emacs@gnu.org; Sun, 16 Aug 2020 10:42:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eric Ludlam Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 16 Aug 2020 14:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42533 X-GNU-PR-Package: emacs Original-Received: via spool by 42533-submit@debbugs.gnu.org id=B42533.1597588909757 (code B ref 42533); Sun, 16 Aug 2020 14:42:02 +0000 Original-Received: (at 42533) by debbugs.gnu.org; 16 Aug 2020 14:41:49 +0000 Original-Received: from localhost ([127.0.0.1]:58126 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k7Jr3-0000C4-0Y for submit@debbugs.gnu.org; Sun, 16 Aug 2020 10:41:49 -0400 Original-Received: from mail-vs1-f44.google.com ([209.85.217.44]:38691) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k7Jqz-0000Bq-VD for 42533@debbugs.gnu.org; Sun, 16 Aug 2020 10:41:47 -0400 Original-Received: by mail-vs1-f44.google.com with SMTP id r7so7008379vsq.5 for <42533@debbugs.gnu.org>; Sun, 16 Aug 2020 07:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4x4CVtX2mUzf73CboJ4GyM/PaoH16RXHs7RKHT1JwIw=; b=cyDqDsXVaXAV0LKBh5VK6s8XgekMYaZhFy3RrNsohgL1stzbW/N15fYW1b+b50nqTW uohipq1Zsgvmw52sh8ZBocLQc79+qOQ6GxiBBMpNTLk6POeuK/sbVrYhabvsiCzKR2rQ BlGBdlZxqYOfqHlaAxVmNDaDAZka8YjI5ZgdGfdoXFeGkXrXjBCIn50IE+bWJNEDRiQp jBR441RpBy0RZbwcrvHlTeK3h3U7HbFSOUg1YnyYja5dXjFe8j9LjhmAipKj+IgrjFiq 7Rp02zwfI638JkM59eFv0ltisSd4Pbmz9mFMWGiyrjszE8dfEPmeu6nImrfP6fqZtWi/ tD/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4x4CVtX2mUzf73CboJ4GyM/PaoH16RXHs7RKHT1JwIw=; b=ZKhmcDF8ZkVzP65qecTCSf9bjHjK8T2aWB4+Sp36aaHtNLkRhlaBu6wlBtPXUhZbi8 Fwcf9Gv4b5htvBa4eGCs2sRZNNU3N3SkkLutdIO5/IFPqIgjwlHf66Ow+6psqQzfX86J oQwxy44oC4jOKuG+nQF+OLLglcRgz3ksWjpY9LZ/eEIt4Skj78UUMiQfZZBdTMrIlJs0 ag6AoToGbC6zcCsmRmOxlC/frfPp8tMemRQsLGzWunDGIzC5LW45pwajN3Ii7J0S/vkA qymAoFPBGV107unyQhCLg1QulDaCC3Yvzn3G5TSQ3+v+FTlm1AIbtxQoGpvUP+hHyDkH pZiw== X-Gm-Message-State: AOAM531kMHYSzqSRLesixhjv63MiBEoycoE2mjlF1EeF3Ywnc/v3ZYg/ HrY4tc5uz/VGLLpK5PWL9eDKpJv6AryyiqGnv8s= X-Google-Smtp-Source: ABdhPJzNmHzHSFrrWiH5Z9nd8gPDhL46bLtqK+wxgi/O3ByPTnm3pUVkYSQrVmFdpr4jOK8tsOyzPHfATLH5mZ+aFYk= X-Received: by 2002:a05:6102:c2:: with SMTP id u2mr6319141vsp.141.1597588900192; Sun, 16 Aug 2020 07:41:40 -0700 (PDT) In-Reply-To: <87zh6uvmvv.fsf@gnus.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:185289 Archived-At: --000000000000e4a52f05acffa6ca Content-Type: text/plain; charset="UTF-8" On Sun, Aug 16, 2020 at 7:41 AM Lars Ingebrigtsen wrote: > Eric Ludlam writes: > > > You can use: > > M-x srecode-get-maps RET > > > > to list all the templates discovered during srecode initialization on > > the different platforms to see what is different. > > Thanks. Unfortunately, the number of maps on the Debian machine (where > this works) and the Macos machine (where it doesn't) is identical, and > they both list the test srt files: > > -- Application Maps -- > tests : > Mode Filename > ------ ------------------ > srecode-template-mode /Users/larsi/src/emacs/trunk/etc/srecode/test.srt > srecode-template-mode > /Users/larsi/src/emacs/trunk/etc/srecode/proj-test.srt > > Hm... are those really supposed to have the same mode name? Isn't the > mode name used as an accessor in a hash table somewhere? Could that > explain the differences? > > Yes, there will be multiple template files for the same mode. This is one of the cool things about srecode, which was designed for code generation. Each template file has its own priority, and lots of templates for the same mode can be loaded in. For any given context, only templates prioritized for that given file are used. For example, default.srt has a 'copyright' template for inserting a copyright, and a 'filecomment' template that uses it. Any given mode file might choose to override 'filecomment' but keep using the default 'copyright' template. A particular application that generates code might have a default app template that embed filecomment in itself. Thus, an app FOO might have a FOO_init_file (generic) that uses filecomment (mode specific), that uses copyright (generic). A user might not like how copyright is represented for C++. They could then create their own c++ template in a project specific location (via ede) or in their home directory. In c++, when using the FOO srecode app, that app will now generate a preferred copyright statement which would match the generic `filecomment' insert. As you can imagine, you can have any number of templates specialized for a mode or app. This lets us provide ways to generate basic code in core templates, and apps can then generate code specific to what they need re-using the base templates, while also allowing users to customize the core templates as needed. Hopefully that all makes sense. It's sort of like css for code generation. I just never got around to building that ultimate code gen tool I was dreaming about. When I was building srecode & semantic, I had to develop my own debugging tools to inspect the complex data structures. I pulled the latest emacs from master to see if they still work. Here are some steps for the extra debugging tools I use: ;; In your .emacs (require 'data-debug) (require 'eieio-datadebug) (load-file "~/cedet/cedet-git/lisp/cedet/semantic/adebug.el") ;; Need to port this to Emacs from CEDET on sourceforge ;; For srecode debugging, you don't need that last line. (global-set-key "\M-:" 'data-debug-eval-expression) ;; Replace typical eval expression for extra debug tooling I then noticed that the latest version of EIEIO bypassed a key part of data-debug-eval-expression. Here's a patch: diff --git a/lisp/cedet/data-debug.el b/lisp/cedet/data-debug.el index 604fc40926..11749c5da0 100644 --- a/lisp/cedet/data-debug.el +++ b/lisp/cedet/data-debug.el @@ -1063,7 +1063,7 @@ data-debug-eval-expression (unless (eq old-value new-value) (setq debug-on-error new-value)))) - (if (or (consp (car values)) (vectorp (car values))) + (if (or (consp (car values)) (vectorp (car values)) (object-p (car values))) (let ((v (car values))) (data-debug-show-stuff v "Expression")) ;; Old style I then created /tmp/foo.srt (a template file in /tmp). It looks like this: ;;; My template file for testing. ;; 1 (setq srecode-mode-table-list nil) ;; 2 (call-interactively 'srecode-get-maps) ;; 3 (srecode-load-tables-for-mode major-mode) ;; 4 (srecode-table major-mode) ;; 5 (setq temp (srecode-template-get-table (srecode-table) "test-project" "test" 'tests )) ;; 6 (srecode-load-tables-for-mode major-mode 'tests) Each line is just a snippet from srecode-test-template.el. C-x-C-e on line labled 1 to completely flush all data loaded into SRECODE. M-: (srecode-table) RET should show nil. The second line should show the map list of all the various templates which you used before. The third line will load in tables for srecode-template-mode. M-: (srecode-table) RET should now show an expression debug of the data structure with that looks like this: ?# ] Name: "srecode-mode-table-158f6d5cd470" ] Class: #'srecode-mode-table ] :major-mode #'srecode-template-mode ] :modetables # ] :tables # The last 2 lines should have 1 entry in them. You can skip line 4 which verifies the above. LIne 5 should show nil (ie - no app templates loaded.) Line 6 will load in application specific templates. This is testing a feature of srecode loading. You can have lots of app specific templates and not slow down basic template loading until they are needed. (ie - the app will load it's own templates) M-: (srecode-table) RET should now show: ?# ] Name: "srecode-mode-table-158f6cf8352c" ] Class: #'srecode-mode-table ] :major-mode #'srecode-template-mode ] :modetables # ] :tables # with 3 tables loaded. In the debug expression buffer you can also press SPC to open up a given line that is itself a list or object. My assumption is you won't get 3 items in the output above on MAC and will need to edebug `srecode-load-tables-for-mode'. There is also a command `data-debug-edebug-expr' you can bind to some key in edebug. I used to have it on E, but that seems to be something else these days. The important bit is what files are listed (start of srecode-load-tables-for-mode) which should include the 2 app files, and later in the same function if any of those files fail to load. As you may have guessed, the sequence is working for me on my Ubuntu box. I also hope you like the data-debug feature. Normally the basics in Emacs are fine, but for complex data structures, being able to walk through an instance of a variable is critical for understanding how some of the code might be misbehaving if you're not sure which part of the data structure to look at. Hope this helps Eric --000000000000e4a52f05acffa6ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Aug 16, 2020 at 7:41 AM Lars Ingebrigtsen <= ;larsi@gnus.org> wrote:
<= div class=3D"gmail_quote">
Eric Ludlam <= ericludlam@gmail.com> writes:

> You can use:
> M-x srecode-get-maps RET
>
> to list all the templates discovered during srecode initialization on<= br> > the different platforms to see what is different.

Thanks.=C2=A0 Unfortunately, the number of maps on the Debian machine (wher= e
this works) and the Macos machine (where it doesn't) is identical, and<= br> they both list the test srt files:

-- Application Maps --
tests :
Mode=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 F= ilename
------=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ------= ------------
srecode-template-mode=C2=A0 =C2=A0/Users/larsi/src/emacs/trunk/etc/srecode/= test.srt
srecode-template-mode=C2=A0 =C2=A0/Users/larsi/src/emacs/trunk/etc/srecode/= proj-test.srt

Hm...=C2=A0 are those really supposed to have the same mode name?=C2=A0 Isn= 't the
mode name used as an accessor in a hash table somewhere?=C2=A0 Could that explain the differences?


Yes, there will be multiple template f= iles for the same mode.=C2=A0 This is one of the cool things about srecode,= which was designed for code generation.=C2=A0 Each template file has its o= wn priority, and lots of templates for the same mode can be loaded in.=C2= =A0 For any given context, only templates prioritized for that given file a= re used.

For example, default.srt has a 'copyr= ight' template for inserting a copyright, and a 'filecomment' t= emplate that uses it.=C2=A0 Any given mode file might choose to override &#= 39;filecomment' but keep using the default 'copyright' template= .=C2=A0 A particular application that generates code might have a default a= pp template that embed filecomment in itself.=C2=A0 =C2=A0Thus, an app FOO = might have a FOO_init_file (generic) that uses filecomment (mode specific),= that uses copyright (generic).

A user might not l= ike how copyright is represented for C++.=C2=A0 They could then create thei= r own c++ template in a project specific location (via ede) or in their hom= e directory.=C2=A0 In c++, when using the FOO srecode app, that app will no= w generate a preferred copyright statement which would match the generic `f= ilecomment' insert.
As you can imagine, you can have any numb= er of templates specialized for a mode or app.=C2=A0 This lets us provide w= ays to generate basic code in core templates, and apps can then generate co= de specific to what they need re-using the base templates, while also allow= ing users to customize the core templates as needed.

Hopefully=C2=A0that all makes sense.=C2=A0 It's sort of like css for= code generation.=C2=A0 I just never got around to building that ultimate c= ode gen tool I was dreaming about.

When I was buil= ding srecode & semantic, I had to develop my own debugging tools to ins= pect the complex data structures.=C2=A0 I pulled the latest emacs from mast= er to see if they still work.=C2=A0 Here are some steps for the extra debug= ging tools I use:

;; In your .emacs
(req= uire 'data-debug)
(require 'eieio-datadebug)
(load-file "= ;~/cedet/cedet-git/lisp/cedet/semantic/adebug.el") ;; Need to port thi= s to Emacs from CEDET on sourceforge
;; For srecode debugging= , you don't need that last line.

(global-s= et-key "\M-:" 'data-debug-eval-expression) ;; Replace typical= eval expression for extra debug tooling

I the= n noticed that the latest version of EIEIO bypassed a key part of data-debu= g-eval-expression.=C2=A0 Here's a patch:

diff = --git a/lisp/cedet/data-debug.el b/lisp/cedet/data-debug.el
index 604fc4= 0926..11749c5da0 100644
--- a/lisp/cedet/data-debug.el
+++ b/lisp/ced= et/data-debug.el
@@ -1063,7 +1063,7 @@ data-debug-eval-expression
=C2= =A0 =C2=A0 =C2=A0 =C2=A0(unless (eq old-value new-value)
=C2=A0 (setq de= bug-on-error new-value))))
=C2=A0
- =C2=A0(if (or (consp (car values)= ) (vectorp (car values)))
+ =C2=A0(if (or (consp (car values)) (vectorp = (car values)) (object-p (car values)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0(let (= (v (car values)))
=C2=A0 (data-debug-show-stuff v "Expression"= ))
=C2=A0 =C2=A0 =C2=A0;; Old style

I then = created /tmp/foo.srt=C2=A0 (a template file in /tmp).=C2=A0 =C2=A0It looks = like this:

;;; My template file for testing.;; 1 = (setq srecode-mode-table-list nil)
;; 2 (call-interactively 'srecode= -get-maps)
;; 3 (srecode-load-tables-for-mode major-mode)
;; 4 (sreco= de-table major-mode)
;; 5 (setq temp (srecode-template-get-table (srecod= e-table) "test-project" "test" 'tests ))
;; 6 (s= recode-load-tables-for-mode major-mode 'tests)

Each line is just a snippet from srecode-test-template.el.

C-x-C-e=C2=A0 on line labled 1 to completely fl= ush all data loaded into SRECODE.

M-: (srecode-tab= le) RET

should show nil.

= The second line should show the map list of all the various templates which= you used before.

The third line will load in tabl= es for srecode-template-mode.

M-: (srecode-ta= ble) RET

should now show an expre= ssion debug of the data structure with that looks like this:

=
?#<srecode-mode-table srecode-mode-table-158f6d5cd470>
= =C2=A0 =C2=A0] Name: "srecode-mode-table-158f6d5cd470"
=C2=A0 = =C2=A0] Class: #'srecode-mode-table
=C2=A0 =C2=A0] :major-mode #'= ;srecode-template-mode
=C2=A0 =C2=A0] :modetables #<list o' stuff= : 1 entries>
=C2=A0 =C2=A0] :tables #<list o' stuff: 1 entries= >

The last 2 lines should have 1 entry in t= hem.

You can skip line 4 which verifies the above.=

LIne 5 should show nil (ie - no app templates loa= ded.)


Line 6 will load in applicati= on specific templates.=C2=A0

This is testing a fea= ture of srecode loading.=C2=A0 You can have lots of app specific templates = and not slow down basic template loading until they are needed.=C2=A0 (ie -= the app will load it's own templates)

M-: (srecode-table) RET

=
should now show:

?#<srecode-mode-tab= le srecode-mode-table-158f6cf8352c>
=C2=A0 =C2=A0] Name: "srecod= e-mode-table-158f6cf8352c"
=C2=A0 =C2=A0] Class: #'srecode-mode= -table
=C2=A0 =C2=A0] :major-mode #'srecode-template-mode
=C2=A0 = =C2=A0] :modetables #<list o' stuff: 3 entries>
=C2=A0 =C2=A0]= :tables #<list o' stuff: 3 entries>

with 3 tables loaded.=C2=A0 =C2=A0In the debug expression buffer you can a= lso press SPC to open up a given line that is itself a list or object.

My assumption is you won't get 3 items in the outp= ut above on MAC and will need to edebug `srecode-load-tables-for-mode'.=

There is also a command `data-debug-edebug-expr&#= 39; you can bind to some key in edebug.=C2=A0 I used to have it on E, but t= hat seems to be something else these days.

The= important bit is what files are listed (start of srecode-load-tables-for-m= ode) which should include the 2 app files, and later in the same function i= f any of those files fail to load.

As you may have= guessed, the sequence is working for me on my Ubuntu box.=C2=A0 I also hop= e you like the data-debug feature.=C2=A0 Normally the basics in Emacs are f= ine, but for complex data structures, being able to walk through an instanc= e of a variable is critical for understanding how some of the code might be= misbehaving if you're not sure which part of the data structure to loo= k at.

Hope this helps
Eric
--000000000000e4a52f05acffa6ca--