asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

Oddities in ECL tests on Linux
by Robert Goldman 12 Sep '18

12 Sep '18

My Jenkins job is failing to test ECL successfully. What's interesting is that it looks like the tests are successful, but the checker is failing. Here's what I see in the transcript: These two expressions fail comparison with EQUAL: (UIOP/UTILITY:NEST (LISP-INVOCATION/LISP-INVOCATION:INVOKE-LISP :IMPLEMENTATION-TYPE (LISP-INVOCATION/ALLEGRO-VARIANTS:CURRENT-LISP-VARIANT) :CROSS-COMPILE NIL :IMAGE-PATH (UIOP/FILESYSTEM:NATIVE-NAMESTRING ASDF-TEST::IMG) :CONSOLE T :EVAL "(uiop:restore-image :entry-point 'hello:entry-point :lisp-interaction nil)" :RUN-PROGRAM-ARGS '(:OUTPUT :LINES :ERROR-OUTPUT T))) evaluates to ("No restarts available." "" "Top level in: #<process TOP-LEVEL>." "> ") '("hello, world") evaluates to ("hello, world") Oddly, when I try to run this at the command line, ECL throws to the interactive debugger on various signals and I have to restart it, before make test l=ecl will terminate successfully. I think I have seen this before, and it may be that ECL implicitly assumes that there will be some kind of C compilation tool chain present that I don't have, but I'm not sure about that. Suggestions for debugging would be welcom.

3 11

Re: Oddities in ECL tests on Linux
by Robert Goldman 02 Sep '18

02 Sep '18

On 31 Aug 2018, at 10:35, Marius Gerbershagen wrote: > This is most likely a bug in ECL. I recommend trying out a newer > version > of ecl (16.1.3 or the current develop branch from the git repository). I see your point, but have two comments: 1. If this really *is* an ECL bug, then shouldn't the Ubuntu package be updated and fixed? ASDF is supposed to work on the ECL that users will have, not only on the one that developers have. 2. I don't see a way to get a new ECL except by pulling from Gitlab and building. I do not have the time to run around building all available lisp implementations from source (and, again, ASDF should work on the versions of the implementations that users actually have, which means the ones provided by the packaging systems on the platforms). I build only SBCL, because that's an implementation I build anyway, for my work needs. Faré had the energy to play with all the different implementations in a substantial way, but I do not. So if the released version of an implementation is broken, I will simply regard that implementation as broken. If the *released version* of an implementation is broken for long enough (I'm looking at you, clisp), it will become unsupported by ASDF. Unsupported means "patches will be accepted, but I will no longer run the tests, and test failure on an unsupported implementation will not be a reason to hold up an ASDF release." Note that at the moment *all* implementations are essentially unsupported on Windows, since I have lost my Windows VM, and even if I got it back, I would have no way to develop on Windows. If you are a Windows user and this bothers you, I would be happy to support you in setting up a test environment, and even more happy to help you learn to patch ASDF. But even someone who doesn't want to patch ASDF, but who would be willing to run the test suite (or help figure out how it could be run through, e.g., Travis), would be a great help. > > Am 30.08.2018 um 21:51 schrieb Robert Goldman: >> I'm experimenting with your changes now but, for some reason that I >> don't understand, when I run the tests as |make l=ecl| interactively >> on >> Ubuntu (using the Ubuntu ECL package |16.1.2-3|), signals are >> throwing >> me into the interactive debugger, instead of being caught. I have no >> idea why this started happening, because I used to be able to run ECL >> successfully, and I don't believe I have changed the package >> (although >> Ubuntu might have upgraded it). >> >> Actually /usr/bin/ecl is crashing with SIGABRT when running programs, >> apparently, on my Ubuntu box. (|SIGABRT in si_run_program()|). I'll >> try >> uninstalling and reinstalling ECL in the hopes that fixes this, but >> unless I get some help, I will not be able to continue testing ASDF >> on >> ECL on Linux. >> >> On 30 Aug 2018, at 13:22, Marius Gerbershagen wrote: >> >> No, I don't think so. The sockets module has been part of ECL >> since >> version 0.9f from 2005. Please note, that this test can fail >> anyway if >> ECL is built without support for the respective module (be it :rt >> or >> :sockets). The change only prevents it from failing on a default >> build >> configuration. >> >> Am 30.08.2018 um 19:53 schrieb Robert Goldman: >> >> Thank you very much for these, Marius. I will look into >> fixing them >> directly. One question - do I need to check for ECL version >> number when >> requiring sockets in the test? I.e., to I need to test with >> |:rt| in >> older versions and |:sockets| in newer? Or will |:sockets| >> work >> in older >> versions of ECL, as well? >> >> Best, >> R >> >> On 30 Aug 2018, at 12:46, Marius Gerbershagen wrote: >> >> Harmless in the sense that ECL doesn't crash or throw me in >> the >> interactive debugger. Besides, the test failures seem to be >> easily >> fixed. The test-require.script test fails because it tries to >> require >> the :rt module which is deprecated on the develop branch and >> no >> longer >> build by default. A simple fix is to use the :sockets module >> instead: >> >> diff --git a/test/test-require.script >> b/test/test-require.script >> index e5f70857..1ef84e8c 100644 >> --- a/test/test-require.script >> +++ b/test/test-require.script >> @@ -178,7 +178,7 @@ >> #+allegro :sax >> #+clisp (first (remove "asdf" *dynmod-list* :test 'equal)) >> #+(or clozure cmucl) :defsystem >> - #+ecl :rt ;; loads faster than :ecl-quicklisp >> + #+ecl :sockets >> #+lispworks "comm" >> #+mkcl :walker >> #+sbcl :sb-md5 >> >> The test-program.script test seems to fail to include uiop >> because of an >> error in the linkable-system function. Tracing it shows that >> the >> function returns nil for the uiop system object, >> 1> (ASDF/BUNDLE::LINKABLE-SYSTEM #<system "uiop">) >> <1 (ASDF/BUNDLE::LINKABLE-SYSTEM NIL) >> which seems to be caused by a missing call to coerce-name: >> >> diff --git a/bundle.lisp b/bundle.lisp >> index 2ff56f93..42034c9f 100644 >> --- a/bundle.lisp >> +++ b/bundle.lisp >> @@ -529,7 +529,7 @@ which is probably not what you want; you >> probably >> need to tweak your output tran >> ;; If an ASDF upgrade is available from source, but not a >> UIOP >> upgrade to that, >> ;; then use the asdf/driver system instead of >> ;; the UIOP that was disabled by check-not-old-asdf-system. >> - (if-let (s (and (equal x "uiop") (output-files 'lib-op >> "asdf") >> (find-system "asdf/driver"))) >> + (if-let (s (and (equal (coerce-name x) "uiop") >> (output-files >> 'lib-op "asdf") (find-system "asdf/driver"))) >> (and (output-files 'lib-op s) s)) >> ;; If there was no source upgrade, look for modules provided >> by >> the implementation. >> (if-let (p (system-module-pathname (coerce-name x))) >> >> >> Am 29.08.2018 um 01:22 schrieb Faré: >> >> I can't reproduce this, for me the tests run fine without >> being thrown >> in the debugger. I only get two harmlessly looking test >> failures >> (test-program.script and test-require.script). >> >> No test failure is harmless. The test-program.script failure >> is what >> Robert saw, that I can reproduce. I didn't reproduce a >> failure with >> test-require. I had more problems with ECL from the develop >> branch, >> but maybe it was a bad idea to use the develop branch. >> >> —♯ƒ • François-René ÐVB Rideau >> •Reflection&Cybernethics• >> http://fare.tunes.org >> There are two kinds of people, those who do the work >> and those who take the credit. Try to be in the first group; >> there is less competition there >> — Indira Gandhi. >>

2 4

bootstrapping asdf
by Faré 06 Aug '18

06 Aug '18

In case anyone takes over maintenance of ASDF in the future, I wrote this mind dump on some of its more stuble "magic" behavior: https://fare.livejournal.com/190738.html Thanks to Eric Timmons for the prompting... PS: there are relatedly a few bug fixes in 3.3.2.5 — thanks and congratulations again to Robert Goldman for his careful reviewing and testing. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It is deplorable that many people think that the best way to improve the world is to forbid something. However, they're morally more advanced than the people who think the best way to improve the world is to kill somebody. — John McCarthy

2 2

Is anyone actually using the deferred warnings code?
by Robert Goldman 06 Aug '18

06 Aug '18

AFAICT, it is disabled by default, and it is not documented in the ASDF manual. So is this code even live, except for in the test scripts? It was pretty painful to get this to work because it relies on unexported (and hence unstable) SBCL internals. My *guess* is that this was originally done as a way to dispense with `WITH-COMPILATION-UNIT` and hence potentially parallelize the compilations. If no one is even using it, I am tempted to move it to be a contrib and drop it from the tests and maintenance as part of core ASDF. Maybe it would be better as a part of a POIU extension to ASDF, and relieve me of dealing with these SBCL compiler internals? Cheers, r

3 3

Another apology...
by Robert Goldman 31 Jul '18

31 Jul '18

I accidentally committed something with a stupid typo. I force-pushed the last push to keep the history clean. Thanks

1 0

More apologies needed
by Robert Goldman 29 Jul '18

29 Jul '18

Sorry *again*. My history fixing was done wrong initially. But 3.2.3.3 should be in place fine now. Best, r

1 0

A little history rewriting...
by Robert Goldman 29 Jul '18

29 Jul '18

Sorry -- I accidentally pushed tag 3.3.3.3 instead of 3.3.2.3. I have fixed that, but it involved deleting the tag from cl.net gitlab after having pushed it. Apologies and thanks to Fare for catching my mistake! R

1 0

Issues with Jenkins and clisp
by Robert Goldman 29 Jul '18

29 Jul '18

For some reason, the ASDF tests are failing on Jenkins on linux with clisp, but *only when run in Jenkins and only for clisp*. At the command line, all the tests pass for me. Under Jenkins, I get this failure on `test-program.script`: ``` ;; Loading file test-program.script ... FOO (UIOP/LISP-BUILD:CURRENT-LISP-FILE-PATHNAME) => #P"test-program.script" ; Registering system hello-world-example 0 errors, 0 warnings ;; Loading file /var/lib/jenkins/workspace/asdf/test/hello-world-example.asd ... ;; Loaded file /var/lib/jenkins/workspace/asdf/test/hello-world-example.asd 0 errors, 0 warnings 0 errors, 0 warnings ; Registering system lisp-invocation ;; Loading file /var/lib/jenkins/workspace/asdf/asdf.asd ... ;; Loaded file /var/lib/jenkins/workspace/asdf/asdf.asd 0 errors, 0 warnings ;; Loading file /var/lib/jenkins/workspace/asdf/build/fasls/clisp-2.49.60+-unix-x64/asdf/build/asdf.fas ... ;; Loaded file /var/lib/jenkins/workspace/asdf/build/fasls/clisp-2.49.60+-unix-x64/asdf/build/asdf.fas 0 errors, 326 warnings ;; Loading file /var/lib/jenkins/workspace/asdf/ext/lisp-invocation/lisp-invocation.asd ... ;; Loaded file /var/lib/jenkins/workspace/asdf/ext/lisp-invocation/lisp-invocation.asd 0 errors, 0 warnings 0 errors, 0 warnings 0 errors, 0 warnings ;; Loading file /var/lib/jenkins/workspace/asdf/ext/lisp-invocation/lisp-invocation.asd ... ;; Loaded file /var/lib/jenkins/workspace/asdf/ext/lisp-invocation/lisp-invocation.asd 0 errors, 0 warnings 0 errors, 0 warnings 0 errors, 0 warnings 0 errors, 0 warnings ;; Loading file /var/lib/jenkins/workspace/asdf/ext/fare-utils/fare-utils.asd ... ;; Loaded file /var/lib/jenkins/workspace/asdf/ext/fare-utils/fare-utils.asd 0 errors, 0 warnings *** - handle_fault error2 ! address = 0x55a16f64c670 not in [0x5575be29b000,0x5575be657030) ! SIGSEGV cannot be cured. Fault address = 0x55a16f64c670. GC count: 65 Space collected by GC: 74922832 Run time: 0 874720 Real time: 1 803489 GC time: 0 179953 Permanently allocated: 165368 bytes. Currently in use: 5850000 bytes. Free space: 1462440 bytes. Segmentation fault (core dumped) Using clisp, test-program.script failed ``` This is with the latest release (but ancient) clisp. It looks like it's not even making it through the preliminary loading process, since we don't see the "test image-op" debugging output. My guess is that this is not a real asdf failure, but instead is clisp being unable to find some piece of tool-age that it needs in order to build a program. But this happened only after (1) load-asdf changed and (2) `source-file-type` was deprecated. Neither of those seems obviously connected to this issue. Any hypotheses or suggestions for debugging?

3 3

POIU is bitrotten
by Faré 26 Jul '18

26 Jul '18

In case anyone cares (I suppose no one does), POIU, the parallel operator on independent units, that parallelizes compilation (but not loading) of ASDF component, with various options regarding determinism or non-determinism, is current bitrotten and not working on ASDF 3.3.2.2, and I disabled its functionality. I don't have the time or interest to fix it (I haven't been using CL at work for five years, and have stopped using it for new personal projects). The other option I know to parallelize a CL build is bazelisp (the Lisp support for bazel.build), which I would bet is also bitrotten, since I haven't touched it in years, either. [An earlier option I worked on, XCVB, has bitrotten long ago.] I am still available for advice in case someone wants to fix things — better ask before the information gets evicted to long-term storage. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Superstition brings bad luck. — Saul Gorn

2 4

A question about the warnings
by Nibby Nebbulous 18 Jul '18

18 Jul '18

I apologize for bringing up this subject, but, is there any chance a patch something like this would be accepted? This is in no way because I disagree with the warning, or have any desire to have multiple systems per "asd". I just want to enjoy the lovely peacefulness of no warnings, without living in my own forked world.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel