* bug#42533: 28.0.50; srecode-utest-project test failing on macOS @ 2020-07-25 18:32 Philipp 2020-08-04 15:14 ` Lars Ingebrigtsen 0 siblings, 1 reply; 9+ messages in thread From: Philipp @ 2020-07-25 18:32 UTC (permalink / raw) To: 42533 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)) ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#42533: 28.0.50; srecode-utest-project test failing on macOS 2020-07-25 18:32 bug#42533: 28.0.50; srecode-utest-project test failing on macOS Philipp @ 2020-08-04 15:14 ` Lars Ingebrigtsen 2020-08-10 14:40 ` Lars Ingebrigtsen 0 siblings, 1 reply; 9+ messages in thread From: Lars Ingebrigtsen @ 2020-08-04 15:14 UTC (permalink / raw) To: Philipp; +Cc: Eric Ludlam, 42533 Philipp <p.stephani2@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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#42533: 28.0.50; srecode-utest-project test failing on macOS 2020-08-04 15:14 ` Lars Ingebrigtsen @ 2020-08-10 14:40 ` Lars Ingebrigtsen 2020-08-15 20:18 ` Eric Ludlam 0 siblings, 1 reply; 9+ messages in thread From: Lars Ingebrigtsen @ 2020-08-10 14:40 UTC (permalink / raw) To: Philipp; +Cc: Eric Ludlam, 42533 Lars Ingebrigtsen <larsi@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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#42533: 28.0.50; srecode-utest-project test failing on macOS 2020-08-10 14:40 ` Lars Ingebrigtsen @ 2020-08-15 20:18 ` Eric Ludlam 2020-08-16 11:41 ` Lars Ingebrigtsen 0 siblings, 1 reply; 9+ messages in thread From: Eric Ludlam @ 2020-08-15 20:18 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Philipp, Eric Ludlam, 42533 [-- Attachment #1: Type: text/plain, Size: 2290 bytes --] 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@gnus.org> wrote: > Lars Ingebrigtsen <larsi@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 > [-- Attachment #2: Type: text/html, Size: 3096 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#42533: 28.0.50; srecode-utest-project test failing on macOS 2020-08-15 20:18 ` Eric Ludlam @ 2020-08-16 11:41 ` Lars Ingebrigtsen 2020-08-16 14:41 ` Eric Ludlam 0 siblings, 1 reply; 9+ messages in thread From: Lars Ingebrigtsen @ 2020-08-16 11:41 UTC (permalink / raw) To: Eric Ludlam; +Cc: Philipp, Eric Ludlam, 42533 Eric Ludlam <ericludlam@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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#42533: 28.0.50; srecode-utest-project test failing on macOS 2020-08-16 11:41 ` Lars Ingebrigtsen @ 2020-08-16 14:41 ` Eric Ludlam 2020-08-18 16:59 ` Lars Ingebrigtsen 0 siblings, 1 reply; 9+ messages in thread From: Eric Ludlam @ 2020-08-16 14:41 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Philipp, Eric Ludlam, 42533 [-- Attachment #1: Type: text/plain, Size: 6634 bytes --] On Sun, Aug 16, 2020 at 7:41 AM Lars Ingebrigtsen <larsi@gnus.org> wrote: > 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 > > 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 [-- Attachment #2: Type: text/html, Size: 8443 bytes --] ^ permalink raw reply related [flat|nested] 9+ messages in thread
* bug#42533: 28.0.50; srecode-utest-project test failing on macOS 2020-08-16 14:41 ` Eric Ludlam @ 2020-08-18 16:59 ` Lars Ingebrigtsen 2020-08-18 17:57 ` Lars Ingebrigtsen 0 siblings, 1 reply; 9+ messages in thread From: Lars Ingebrigtsen @ 2020-08-18 16:59 UTC (permalink / raw) To: Eric Ludlam; +Cc: Philipp, Eric Ludlam, 42533 Eric Ludlam <ericludlam@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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#42533: 28.0.50; srecode-utest-project test failing on macOS 2020-08-18 16:59 ` Lars Ingebrigtsen @ 2020-08-18 17:57 ` Lars Ingebrigtsen 2020-08-30 19:35 ` Eric Ludlam 0 siblings, 1 reply; 9+ messages in thread From: Lars Ingebrigtsen @ 2020-08-18 17:57 UTC (permalink / raw) To: Eric Ludlam; +Cc: Philipp, Eric Ludlam, 42533 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#42533: 28.0.50; srecode-utest-project test failing on macOS 2020-08-18 17:57 ` Lars Ingebrigtsen @ 2020-08-30 19:35 ` Eric Ludlam 0 siblings, 0 replies; 9+ messages in thread From: Eric Ludlam @ 2020-08-30 19:35 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Philipp, Eric Ludlam, 42533 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-08-30 19:35 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-07-25 18:32 bug#42533: 28.0.50; srecode-utest-project test failing on macOS Philipp 2020-08-04 15:14 ` Lars Ingebrigtsen 2020-08-10 14:40 ` Lars Ingebrigtsen 2020-08-15 20:18 ` Eric Ludlam 2020-08-16 11:41 ` Lars Ingebrigtsen 2020-08-16 14:41 ` Eric Ludlam 2020-08-18 16:59 ` Lars Ingebrigtsen 2020-08-18 17:57 ` Lars Ingebrigtsen 2020-08-30 19:35 ` Eric Ludlam
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.