April 2015 - asdf-devel - mailman3.common-lisp.net

[asdf-devel] Retest
by Robert P. Goldman 08 Apr '15

08 Apr '15

Now all tests pass on Linux for me (but I'm not testing ABCL there). ABCL on the Mac fails test-stamp-propagation: TEST ABORTED: These two expressions fail comparison with EQUAL: (SANITIZE-LOG (RELOAD ASDF/DEFSYSTEM:DEFSYSTEM)) evaluates to ((:COMPILING :SYSTEM)) (QUOTE ((:COMPILING :SYSTEM) (:COMPILE-TOPLEVEL :FILE1) (:LOAD-TOPLEVEL :FILE1) (:COMPILE-TOPLEVEL :FILE2) (:LOAD-TOPLEVEL :FILE2))) evaluates to ((:COMPILING :SYSTEM) (:COMPILE-TOPLEVEL :FILE1) (:LOAD-TOPLEVEL :FILE1) (:COMPILE-TOPLEVEL :FILE2) (:LOAD-TOPLEVEL :FILE2)) Above backtrace due to this condition: These two expressions fail comparison with EQUAL: (ASDF-TEST::SANITIZE-LOG (ASDF-TEST::RELOAD ASDF/DEFSYSTEM:DEFSYSTEM)) evaluates to ((:COMPILING :SYSTEM)) (QUOTE ((:COMPILING :SYSTEM) (:COMPILE-TOPLEVEL :FILE1) (:LOAD-TOPLEVEL :FILE1) (:COMPILE-TOPLEVEL :FILE2) (:LOAD-TOPLEVEL :FILE2))) evaluates to ((:COMPILING :SYSTEM) (:COMPILE-TOPLEVEL :FILE1) (:LOAD-TOPLEVEL :FILE1) (:COMPILE-TOPLEVEL :FILE2) (:LOAD-TOPLEVEL :FILE2)) Script failed Using abcl, test-stamp-propagation.script failed Does this work on Linux? cheers, r

2 3

[asdf-devel] Trying to get ASDF tests (especially uiop:run-program) on Windows (Allegro CL, CCL) cleaned up before 3.0.3 release
by Dave Cooper 08 Apr '15

08 Apr '15

Starting a new thread, but in due course we should keep Fare's most recent words from previous thread in mind for expanding the test suite for uiop:run-program: Fare wrote: Ideally there would a test that includes all printable ASCII > characters and ensures that quoting works alright, with either a list > or string argument (beware quoting when generating the string). Anyway, here is what I'm seeing currently (with an unpatched 3.0.2.7): Allegro 9.0: ========= Running the test script from cygwin brings up an Allegro CL Console which immediately displays the following error: ==== An unhandled error occurred during initialization: An error occurred (Attempt to take the value of the unbound variable `|"TEST/SCRIPT-SUPPORT.LISP"|'.) during the reading or evaluation of -e "(or #.(load \\\"test/script-support.lisp\\\") #.(asdf-test::compile-asdf-script))" <The Lisp process exited with status -1 (0xffffffff)> ==== So the -e argument is not making it properly into the Allegro, and it looks like something has to be updated in the test script just to get Allegro/Windows to start running the tests. Would anyone from Franz Support care to have a look at this? I did confirm that normal programs can be run with Allegro's excl:run-shell-command without the need for "cmd /c" prepended. CCL 1.9 ======= asdf test results for (unpatched) 3.0.2.7 are here: https://www.dropbox.com/sh/jc2cqwpkp06dupm/tx0U1Fun65/cl/tests/asdf/output/… Note that the first failure, for the bundle-test, is a known bug in ccl:fasl-concatenate in CCL 1.9 for Windows, and has been fixed in the trunk for CCL 1.10. The second failure just looks like the extra space after the "ok 1" as we were seeing before. Perhaps this is also a CCL issue? Can anyone from Clozure comment on this? Also, I think I confirmed that CCL's ccl:run-program on Windows really does need the "cmd /c " prepended to be able to run a normal program. Currently the uiop:run-program is doing (cons "cmd" (strcat "/c " command)) for commands given as a single string, but it does not prepend anything for commands given as a list. There was previous opinion that the list form of the command should not automatically get the ("cmd" "c/") prepended. But from what I can tell, the user will always have to do (uiop:run-program (append '("cmd" "/c") command) if user wants to give command as a list. If that's the case, then for consistent interface of uiop:run-program across different Lisps, shouldn't uiop:run-program go ahead and do that appending by default? SBCL ===== Sorry, I'm not running SBCL on Windows at the moment. Anyone? Get with me if you can use some guidance getting the ASDF test scripts running. LispWorks ======== I don't have LWW at this juncture. Anyone? ABCL, ECL, CLISP, GCL (who am I forgetting?) ====================================== Anyone running these on Windows and willing to run some ASDF testing scripts (probably through cygwin)? Get with me if you want some guidance and/or moral support. Regards, Dave

2 3

[asdf-devel] Pushed manual cleanups
by Robert P. Goldman 08 Apr '15

08 Apr '15

I have pushed what I hope are substantial improvements to the ASDF manual, at least to the early parts of it. Faré: is it easily possible to push this to the web page using your makefile? Cheers, r

2 5

[asdf-devel] deferred warnings doesn't tell which file
by Attila Lendvai 08 Apr '15

08 Apr '15

hi! so, i'm using deferred warnings, because warnings are useful! the only problem is that, in this specific case, i get the following after compilation has finished: ; compilation finished in 0:00:00.033 ; in: LAMBDA (SB-PCL::.METHOD-ARGS. SB-PCL::.NEXT-METHODS.) ; (SB-MOP:SLOT-VALUE-USING-CLASS # HU.DWIM.PEREC::INSTANCE ...) ; ; caught WARNING: ; undefined variable: HU.DWIM.PEREC::INSTANCE ; ; compilation unit finished ; Undefined variable: ; HU.DWIM.PEREC::INSTANCE ; caught 1 WARNING condition ; ; compilation unit aborted ; caught 4 fatal ERROR conditions and it doesn't even tell which file it happened with. (this error comes from the depths of sbcl internals around generic methods). how was it meant to work originally? is it assumed that the warning will always contain a name or something that helps identifying where it comes from? if so, then it's not always the case, and when warnings are not deferred at least the current toplevel form is visible in the output. note: this is not a showstopper just an inconvenience. i can identify the file by checking the *.sbcl-warnings files manually. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Here is the world. Beautiful and terrible things will happen. Don't be afraid.” — Frederick Buechner

2 2

Test failure: CCL 1.9 on Mac OSX
by Robert Goldman 08 Apr '15

08 Apr '15

Just pulled and ran all the tests, and CCL 1.9 fails test-utilities on Mac OSX: TEST ABORTED: These two expressions fail comparison with EQUAL: NIL evaluates to NIL (FISHY-ASDF-EXPORTED-SYMBOLS) evaluates to (ASDF/OPERATION:ORIGINAL-INITARGS) cheers, r

2 2

[asdf-devel] ASDF
by Faré 08 Apr '15

08 Apr '15

I suppose it would be better to release 3.0.3 without merging my branches, and merge my branches afterwards. On the other hand, there are a few bugs I fixed in my run-program branch, independently from the new functionality, that I'd like to commit in the master branch before the release, with your permission: * the external-format bug in with-temporary-file is shameful. Sorry. * the stdin / stdout / stderr initialization is better, and allows run-program to work at all on ECL when in SLIME (or in many other cases). * the slight changes in external-format defaults (from :default to utf-8) should be done earlier rather than later (for increased consistency) * the new docstrings are also merge-worthy. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Few people are capable of expressing with equanimity opinions which differ from the prejudices of their social environment. Most people are even incapable of forming such opinions. — Albert Einstein

2 2

[asdf-devel] 3.1.0.75 pushed: more checking of system names
by Robert P. Goldman 08 Apr '15

08 Apr '15

This is a repair of last night's commit. I added a test for the new system name checks, which had some fan-out -- I needed to fix DEF-TEST-SYSTEM to permit systems named with strings instead of symbols. Also, I check to make sure that all the system names, when being registered, are case-flattened down, and issue a continuable error if not. cheers, r

2 3

[asdf-devel] Another grammar question
by Robert Goldman 08 Apr '15

08 Apr '15

The :REQUIRE directive seems undocumented. Under what circumstances is it acceptable? thanks, r -- Robert P. Goldman Staff Scientist Smart Information Flow Technologies (d/b/a SIFT, LLC) 211 N. First St., Suite 300 Minneapolis, MN 55401 Voice: (612) 326-3934 Email: rpgoldman(a)SIFT.net

2 5

[asdf-devel] Will you please test the latest ASDF with CMUCL
by Robert Goldman 08 Apr '15

08 Apr '15

On Mac OS X for me, it fails upgrade from 2.32 to the latest (3.0.2.2) using method require. Faré's testing instructions are: /usr/local/bin/cmucl -noinit then copy/paste: (load"test/script-support.lisp") (asdf-test::da) (test-upgrade 'load-asdf-lisp'load-asdf-lisp-clean "REQUIRE") I get an error as follows: Error in function KERNEL:CLASS-TYPEP: Class is currently invalid: #<KERNEL::STANDARD-CLASS ASDF/SYSTEM:SYSTEM {48589A35}> Please let me know any findings. I'd like to get this fixed (or disconfirmed) before we release 3.0.3. Best, r

2 2

[asdf-devel] cmucl upgrade of asdf works (somewhat)
by Faré 08 Apr '15

08 Apr '15

An innocuous-looking change suggested by rpgoldman, of not providing a default initform for the selfward-operation slot, led after testing to fixing a few innocuous bugs in asdf, but also to a better understanding of the issues with CMUCL and upgrade. After the innocuous change, tests failed on CMUCL that didn't; some of it was bugs in ASDF that had been papered over by that initform: things that shouldn't have been selfward-operation were, and now had no initform — that was easily fixed. Then, there was a CMUCL bug, whereby sometimes, for reasons not understood yet deterministic and easy but not simple to trigger, some operations would be created without an initialized selfward-operation slot. This was worked around by noticing that selfward-operation was meant to be an :allocation :class slot, but that option wasn't inherited by slot specializations, and needed to be explicitly specified every time the slot was specialized (no doubt because trying to inherit the option would require a non-trivial decision procedure in case of conflict between multiple super-slots); fixing ASDF to do the right thing papered over that CMUCL bug. (to reproduce, checkout 3.1.0.37 and make t l=cmucl t=test-encodings.script) While we were experimenting with CLOS and CMUCL, we tried to remove the #+cmu declaim optimize (not sure why it was ever there), and/or add a #+cmu (setf c::top-level-lambda-max 0). That didn't help (yet I removed the declaim at rtoy's suggestion), but along the way, we noticed that upgrade works from 3.0.1, 3.0.2, 3.0.3, and fails from 2.32 and earlier. The issue is that defclass component has a renamed a slot, and its subclass system is invalidated, but CMUCL somehow fails to finalize it again before it's next used. The good news is that not only have we identified two CMUCL bugs, we have established to upgrade works from 3.0.1 to 3.0.3, which is all that matters, really, since CMUCL updates its ASDF frequently. And we know what to do to avoid more upgrade woes on CMUCL: avoid incompatible slot definitions in classes and/or superclasses. I changed our tests to upgrade versions in reverse chronological order, which is more relevant, and disabled older versions when using CMUCL. I also bumped *oldest-forward-compatible-asdf-version* to 2.33, since we don't have a method on update-instance-for-redefined-class to account for the renamed slot. That leaves the upgrade issue found by cl-grid-test on CCL with cl-l10n and some other systems. wow. such procrastination. much bugfix. very robustified. wow. All because rpgoldman read the source and wanted a tiny cleanup. In other news, still no date set for the walkthrough of ASDF sources on Google hangout; since rpgoldman is the primary audience, we're waiting for his schedule to open up. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "I believe that sex is one of the most beautiful, natural, wholesome things that money can buy." — Steve Martin

3 6