GNU bug report logs - #42533
28.0.50; srecode-utest-project test failing on macOS

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 42533 in the body.
You can then email your comments to 42533 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Philipp <p.stephani2 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; srecode-utest-project test failing on macOS
Date: Sat, 25 Jul 2020 20:32:58 +0200

This is a follow-up to Bug#30700, reporting individual test failures on
macOS as separate bugs.

Under macOS, 'make check' fails in the test srecode-utest-project:

Running 2 tests (2020-07-25 20:22:08+0200, selector `(not (or (tag :expensive-test) (tag :unstable)))')
Test srecode-utest-project backtrace:
  signal(ert-test-failed (((should-not "Failed to load app specific te
  ert-fail(((should-not "Failed to load app specific template when ava
  #f(compiled-function () #<bytecode 0x179a6521f8940163>)()
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name srecode-utest-project :documentation 
  ert-run-or-rerun-test(#s(ert--stats :selector (not (or (tag :expensi
  ert-run-tests((not (or (tag :expensive-test) (tag :unstable))) #f(co
  ert-run-tests-batch((not (or (tag :expensive-test) (tag :unstable)))
  ert-run-tests-batch-and-exit((not (or (tag :expensive-test) (tag :un
  eval((ert-run-tests-batch-and-exit '(not (or (tag :expensive-test) (
  command-line-1(("-L" ":." "-l" "ert" "-l" "lisp/cedet/srecode-utest-
  command-line()
  normal-top-level()
Test srecode-utest-project condition:
    (ert-test-failed
     ((should-not "Failed to load app specific template when available.")
      :form "Failed to load app specific template when available." :value "Failed to load app specific template when available."))
   FAILED  1/2  srecode-utest-project (2.174053 sec)



In GNU Emacs 28.0.50 (build 67, x86_64-apple-darwin19.5.0, NS appkit-1894.50 Version 10.15.5 (Build 19F101))
 of 2020-07-25
Repository revision: 3b44829823f43d3736b8ec9db2258eeff7f6c16a
Repository branch: master
Windowing system distributor 'Apple', version 10.3.1894
System Description:  Mac OS X 10.15.5

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --with-modules --without-xml2 --without-pop --with-mailutils
 --enable-gcc-warnings=warn-only --enable-checking=all
 --enable-check-lisp-object-type 'CFLAGS=-ggdb3 -O0''

Configured features:
JPEG TIFF GIF PNG NOTIFY KQUEUE ACL GNUTLS ZLIB TOOLKIT_SCROLL_BARS NS
MODULES THREADS JSON PDUMPER LCMS2

Important settings:
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc dired dired-loaddefs rfc822
mml easymenu mml-sec epa epg epg-config gnus-util rmail rmail-loaddefs
text-property-search time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils phst skeleton derived edmacro
kmacro pcase ffap thingatpt url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json map url-vars mailcap subr-x rx gnutls puny seq
byte-opt gv bytecomp byte-compile cconv dbus xml compile comint
ansi-color ring cl-loaddefs cl-lib tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/ns-win ns-win
ucs-normalize mule-util term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads kqueue cocoa ns
lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 69711 5100)
 (symbols 48 8650 1)
 (strings 32 23543 1970)
 (string-bytes 1 768529)
 (vectors 16 14147)
 (vector-slots 8 172535 4996)
 (floats 8 26 29)
 (intervals 56 206 0)
 (buffers 992 10))

Message #8 received at 42533 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Philipp <p.stephani2 <at> gmail.com>
Cc: Eric Ludlam <zappo <at> gnu.org>, 42533 <at> debbugs.gnu.org
Subject: Re: bug#42533: 28.0.50; srecode-utest-project test failing on macOS
Date: Tue, 04 Aug 2020 17:14:08 +0200

Philipp <p.stephani2 <at> gmail.com> writes:

> This is a follow-up to Bug#30700, reporting individual test failures on
> macOS as separate bugs.
>
> Under macOS, 'make check' fails in the test srecode-utest-project:

This also has:

  :expected-result (if (getenv "EMACS_HYDRA_CI") :failed :passed) ; fixme

    * test/lisp/cedet/srecode-utest-template.el (srecode-utest-project):
    Test fails on hydra.nixos.org, for some reason.

So it's not just failing on Macos.

I've tried to follow the logic of the test, but I'm failing to see how
the code diverges under Linux and Macos...  Perhaps Eric has some input
here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #13 received at 42533 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Philipp <p.stephani2 <at> gmail.com>
Cc: Eric Ludlam <zappo <at> gnu.org>, 42533 <at> debbugs.gnu.org
Subject: Re: bug#42533: 28.0.50; srecode-utest-project test failing on macOS
Date: Mon, 10 Aug 2020 16:40:32 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> I've tried to follow the logic of the test, but I'm failing to see how
> the code diverges under Linux and Macos...  Perhaps Eric has some input
> here?

I spent about an hour on this last night, comparing what happens on
Macos and Debian (where this test doesn't fail), and I wasn't
successful.  This test is more of an integration test than a unit test
in that it doesn't tell you much about where deep in the srecode
machinery things go wrong, unfortunately...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #16 received at 42533 <at> debbugs.gnu.org (full text, mbox):

From: Eric Ludlam <ericludlam <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Philipp <p.stephani2 <at> gmail.com>, Eric Ludlam <zappo <at> gnu.org>,
 42533 <at> debbugs.gnu.org
Subject: Re: bug#42533: 28.0.50; srecode-utest-project test failing on macOS
Date: Sat, 15 Aug 2020 16:18:03 -0400

[Message part 1 (text/plain, inline)]

Srecode loads in templates for various modes and applications into a map.
That particular test is verifying that the template associated with
srecode's template mode for the application 'tests' was found.

There are 2 templates for the 'test' application in:
 etc/srecode/proj-test.srt.
 etc/srecode/test.srt

Plus the template template:
 etc/srecode/template.srt

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.

The first part of the list are the mode specific template files.  After are
the application templates, and tests app should be in there.  (It was first
for me when I just tried it.)

What *might* be going on is ~/.emacs.d/srecode-map.el could be out of date
for whatever user/machine is running the test.  Discovering all the
templates is a bit slow, and srecode will rescan files that change but
doesn't know what files to scan based on file name, so the map and the
cache was meant to speed things up.  You can force a reload by passing
non-nil into srecode-get-maps.   The earlier test srecode-utest-map-reset
should do that, but as I look at the code, I don't see that it is.  In the
old cedet test suite, all the tests were run in a forced order w/out ert
(it wasn't around, or I didn't know about it when I was writing tests the
first time.)  Thus, there may be some order dependency I don't know about.

Hopefully this is helpful.  I don't usually have this much time to poke
around in emacs anymore.  You caught me on a good day. :)
Eric

On Mon, Aug 10, 2020 at 10:40 AM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:

> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
> > I've tried to follow the logic of the test, but I'm failing to see how
> > the code diverges under Linux and Macos...  Perhaps Eric has some input
> > here?
>
> I spent about an hour on this last night, comparing what happens on
> Macos and Debian (where this test doesn't fail), and I wasn't
> successful.  This test is more of an integration test than a unit test
> in that it doesn't tell you much about where deep in the srecode
> machinery things go wrong, unfortunately...
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>

[Message part 2 (text/html, inline)]

Message #19 received at 42533 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eric Ludlam <ericludlam <at> gmail.com>
Cc: Philipp <p.stephani2 <at> gmail.com>, Eric Ludlam <zappo <at> gnu.org>,
 42533 <at> debbugs.gnu.org
Subject: Re: bug#42533: 28.0.50; srecode-utest-project test failing on macOS
Date: Sun, 16 Aug 2020 13:41:24 +0200

Eric Ludlam <ericludlam <at> gmail.com> writes:

> Plus the template template:
>  etc/srecode/template.srt
>
> 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?

> You can force a reload by
> passing non-nil into srecode-get-maps.  The earlier test
> srecode-utest-map-reset should do that, but as I look at the code, I
> don't see that it is.

I put some (srecode-get-maps t) calls in there, but it didn't seem to
have any effect...

> Hopefully this is helpful.  I don't usually have this much time to
> poke around in emacs anymore.  You caught me on a good day. :)

:-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #22 received at 42533 <at> debbugs.gnu.org (full text, mbox):

From: Eric Ludlam <ericludlam <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Philipp <p.stephani2 <at> gmail.com>, Eric Ludlam <zappo <at> gnu.org>,
 42533 <at> debbugs.gnu.org
Subject: Re: bug#42533: 28.0.50; srecode-utest-project test failing on macOS
Date: Sun, 16 Aug 2020 10:41:28 -0400

[Message part 1 (text/plain, inline)]

On Sun, Aug 16, 2020 at 7:41 AM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:

> Eric Ludlam <ericludlam <at> gmail.com> 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:

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

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:

?#<srecode-mode-table srecode-mode-table-158f6cf8352c>
   ] Name: "srecode-mode-table-158f6cf8352c"
   ] Class: #'srecode-mode-table
   ] :major-mode #'srecode-template-mode
   ] :modetables #<list o' stuff: 3 entries>
   ] :tables #<list o' stuff: 3 entries>

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

[Message part 2 (text/html, inline)]

Message #25 received at 42533 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eric Ludlam <ericludlam <at> gmail.com>
Cc: Philipp <p.stephani2 <at> gmail.com>, Eric Ludlam <zappo <at> gnu.org>,
 42533 <at> debbugs.gnu.org
Subject: Re: bug#42533: 28.0.50; srecode-utest-project test failing on macOS
Date: Tue, 18 Aug 2020 18:59:11 +0200

Eric Ludlam <ericludlam <at> gmail.com> writes:

(Thank you for the explanation and debugging instructions.)

> 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.

If think indeed something is going wrong in that function.  On the Macos
system (where things fail), the files variable is:

(("/Users/larsi/src/emacs/trunk/etc/srecode/proj-test.srt" . srecode-template-m\
ode)
 ("/Users/larsi/src/emacs/trunk/etc/srecode/test.srt" . srecode-template-mode))

On Debian, there things work, it's:

(("/home/larsi/src/emacs/trunk/etc/srecode/test.srt" . srecode-template-mode)
 ("/home/larsi/src/emacs/trunk/etc/srecode/proj-test.srt" . srecode-template-mode))

So is this sorting sensitive?

Hm...  no, I tried reversing the sorting, and it still fails.  Well, I'll
keep on poking at this...  Thanks for the help.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #28 received at 42533 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eric Ludlam <ericludlam <at> gmail.com>
Cc: Philipp <p.stephani2 <at> gmail.com>, Eric Ludlam <zappo <at> gnu.org>,
 42533 <at> debbugs.gnu.org
Subject: Re: bug#42533: 28.0.50; srecode-utest-project test failing on macOS
Date: Tue, 18 Aug 2020 19:57:00 +0200

Found it!

For test-project, proj is "/tmp/", and on Debian default-directory is
/tmp/.  That is not the case on Macos -- proj is
/var/folders/xv/8kvz838x15533stz7gy96zd40000gn/T/ there:

(cl-defmethod srecode-template-table-in-project-p ((tab srecode-template-table))
  "Return non-nil if the table TAB can be used in the current project.
If TAB has a :project set, check that the directories match.
If TAB is nil, then always return t."
  (let ((proj (oref tab project)))
    ;; Return t if the project wasn't set.
    (if (not proj) t
      ;; If the project directory was set, let's check it.
      (let ((dd (expand-file-name default-directory))
	    (projexp (regexp-quote (directory-file-name proj))))
	(if (string-match (concat "^" projexp) dd)
	    t nil)))))

*phew*

OK, now to fix that...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #35 received at 42533 <at> debbugs.gnu.org (full text, mbox):

From: Eric Ludlam <ericludlam <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Philipp <p.stephani2 <at> gmail.com>, Eric Ludlam <zappo <at> gnu.org>,
 42533 <at> debbugs.gnu.org
Subject: Re: bug#42533: 28.0.50; srecode-utest-project test failing on macOS
Date: Sun, 30 Aug 2020 15:35:46 -0400

On 8/18/20 1:57 PM, Lars Ingebrigtsen wrote:
> Found it!
>
> For test-project, proj is "/tmp/", and on Debian default-directory is
> /tmp/.  That is not the case on Macos -- proj is
> /var/folders/xv/8kvz838x15533stz7gy96zd40000gn/T/ there:
>
Huzzah!  Glad you were able to find the difference.

Eric

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.