July 2014 - asdf-devel - mailman3.common-lisp.net

[Asdf-devel] (asdf:output-file 'asdf:monolithic-fasl-op ...) no longer working
by Dave Cooper 30 Jul '14

30 Jul '14

I'm not sure how much this matters because it's mostly a backward compatibility issue with something which is a relatively new feature anyway, but (asdf:output-file[s] 'asdf:monolithic-fasl-op ...) no longer works in 3.1.3 (at least on CCL/Linux). The new nomenclature is apparently: (asdf:output-file[s] 'asdf:monolithic-compile-bundle-op ...) is 'asdf:monolithic-compile-bundle-op indeed the exact replacement for 'asdf:monolithic-fasl-op? FWIW, (asdf:operate 'asdf:monolithic-fasl-op ...) still appears to work. I apologize for not running tests on my own stuff before the release of 3.1.3; I'll try to make a point of doing that for future releases. -- My Best, Dave Cooper, Genworks Support david.cooper(a)genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699

3 5

[Asdf-devel] minimakefile branch
by Faré 29 Jul '14

29 Jul '14

I hadn't tested the minimakefile branch with quicklisp, so of course it wasn't working. Fixed. All you need to bootstrap the asdf-tools is a recent quicklisp (and possibly removing antique cl-ppcre packages from debian that might take precedence). I just realized that with quicklisp, asdf:load-system seems to load already-installed quicklisp packages, but not install new ones, for which you need ql:quickload. Xach, is that on purpose? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I'll start exercising as soon as I'm into shape.

3 3

[Asdf-devel] ASDF version 3.1.3 released: Important bug-fix release
by Robert P. Goldman 24 Jul '14

24 Jul '14

Today I have released (with much help from Fare) ASDF 3.1.3. We urge implementations that are currently shipping with 3.1.2 to move forward to 3.1.3. 3.1.3 has no API incompatibilities that we know of, and contains significant bug fixes. Most significantly, 3.1.3 fixes bugs that impede hot-upgrade from 3.1.2 to a later version of ASDF, which is critical to ASDF development. In addition, we have fixed multiple bugs in ASDF system search caching, that impeded correct use of restarts involving adding new systems to a running CL. Regards, Robert Goldman

1 0

[Asdf-devel] ASDF 3.1.2.9 now available
by Robert P. Goldman 18 Jul '14

18 Jul '14

We have merged the bug fixes for 1335323, and pushed as 3.1.2.9. This is a release candidate for 3.1.3, which we hope to release this coming week. Please test it! thanks! r

3 3

[Asdf-devel] converting asdf build & test to Lisp
by Faré 10 Jul '14

10 Jul '14

My latest procrastination was to convert the ASDF Makefile and supporting build and test scripts to CL. On the one hand, the Makefile didn't translate into asdf secondary targets, like I expected: it's all regular CL functions, modulo some slightly elaborate calling conventions so that the appropriate functions can be called from the Makefile like before, as in: make t l=clisp t="test-utilities.script test-program.script" make bump-version v=4.0 etc. It's all in the minimakefile branch. Dave, can you test that branch on Windows? I'm particularly curious about LispWorks on Windows, since it's the implementation that has always given us the most trouble with argument passing on Windows; but other Windows implementations make me curious too: there is this elaborate compose-eval-string in tools/invoke-lisp.lisp that produces a string without space, single or double quote or backslash, that is hopefully suitable for passing to the worst implementations of Windows command-line parsers. The infrastructure now in asdf/tools/ could serve as the basic for a cross-implementation testing framework. I'm not interested in developing one, but those of you who deliver code on a lot of platforms might be. Death to shell scripts, long live Lisp scripts! —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The rule is perfect: in all matters of opinion our adversaries are insane. — Mark Twain

5 15

[Asdf-devel] Partial fix for bug1335323
by Robert P. Goldman 09 Jul '14

09 Jul '14

I have just pushed to the topic branch a partial fix for this bug, and for the cache incorrectness I posted about yesterday. The cache incorrectness fix unpleasantly caused me to have to multiply the restarts, which makes the code ugly, and slops across cache.lisp and find-system.lisp, but I couldn't come up with a better solution. The test for refinding needs some refining: as soon as I get that done (it's more a matter of getting the test systems set up properly than actually fixing any more ASDF code. cheers, r

1 0

[Asdf-devel] asdf and dependencies
by Faré 09 Jul '14

09 Jul '14

Dear Kambiz, are you still interested in making a git repository with asdf + dependencies as modules? It would help development and make Robert more comfortable with the minimakefile branch. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Do not handicap your children by making their lives easy. — Robert Heinlein, "Time Enough For Love"

2 1

[Asdf-devel] bug1335323 reveals another bug....
by Robert P. Goldman 09 Jul '14

09 Jul '14

It turns out that caching negative results from FIND-SYSTEM search overrides the ERROR-P option to FIND-SYSTEM. If ERROR-P is T, but a NIL result is found in the cache, FIND-SYSTEM will return the NIL instead of raising a MISSING-COMPONENT error. I have just pushed a new test-cache.script that fails because of this bug. I will try to fix this tomorrow -- it's a little tricky, the logic is baked into WITH-ASDF-CACHE, I believe. FIND-SYSTEM will have to get refactored to move the error-handling outside WITH-ASDF-CACHE.

1 0

[Asdf-devel] Questions about LOAD-SYSTEM & OPERATE
by Robert P. Goldman 05 Jul '14

05 Jul '14

In the process of making a test for bug1335323, I discovered that the top-level call to look up the system in LOAD-SYSTEM/OPERATE, is FIND-COMPONENT, not FIND-SYSTEM, so that the REINITIALIZE-SOURCE-REGISTRY-AND-RETRY restart is not available. Also, for some reason, I am unable to find the "force1" subsystem of "test-asdf", although "test-asdf" is found correctly: 1: (OPERATE LOAD-OP "test-asdf/force1") 2: (FIND-COMPONENT NIL "test-asdf/force1") 3: (FIND-COMPONENT "test-asdf/force1" NIL) 4: (FIND-SYSTEM "test-asdf/force1" NIL) 5: (FIND-SYSTEM "test-asdf" NIL) 5: FIND-SYSTEM returned #<PACKAGE-INFERRED-SYSTEM "test-asdf"> 5: (FIND-SYSTEM "test-asdf" NIL) 5: FIND-SYSTEM returned #<PACKAGE-INFERRED-SYSTEM "test-asdf"> 4: FIND-SYSTEM returned NIL 3: FIND-COMPONENT returned NIL 2: FIND-COMPONENT returned NIL Any idea why this is happening? It's after an attempt to clear the ASDF cache, and I wonder if that's implicated -- maybe just smashing the *asdf-cache* isn't correct. When I first call FIND-SYSTEM, I do find the system: ; Loading system definition for test-asdf from /Users/rpg/lisp/asdf/test/test-asdf.asd ;; loading #P"/Users/rpg/lisp/asdf/test/test-asdf.asd" ; Registering #<SYSTEM "test-asdf"> ; Registering #<SYSTEM "test-asdf/all"> ; Registering #<SYSTEM "test-asdf/1"> ; Registering #<SYSTEM "test-asdf/2"> ; Registering #<SYSTEM "test-asdf/4"> ; Registering #<SYSTEM "test-asdf/test9-1"> ; Registering #<SYSTEM "test-asdf/test-module-depend"> ; Registering #<SYSTEM "test-asdf/test9-2"> ; Registering #<SYSTEM "test-asdf/test9-3"> ; Registering #<SYSTEM "test-asdf/test-source-directory-1"> ; Registering #<SYSTEM "test-asdf/test-source-directory-2"> ; Registering #<SYSTEM "test-asdf/bundle-1"> ; Registering #<SYSTEM "test-asdf/bundle-2"> ; Registering #<SYSTEM "test-asdf/force"> ; Registering #<SYSTEM "test-asdf/force1"> Clearing the caches and finding..... I have pushed my bug1335323 topic branch to cl.net, since I could use some help with it, in case anyone has the time to examine it. (whoops. I can see now that I should be keeping the cache entries for ASDF, POIU, and their components; that's probably a bug, since if you are changing ASDF you're probably better off unwinding completely and starting over, instead of trying to handle an error) Cheers, r

2 1

[Asdf-devel] Why does asdf use ``operate''?
by Mirko Vukovic 05 Jul '14

05 Jul '14

Why does ASDF use the (operate operation-name arguments ...) convention instead of the more usual function call (function-name arguments ...) Even with `operate', eventually a function will be called. Also that one can define top level functions that call operate (defun foo (...) (operate 'foo-operation ...)) What does the extra layer of operate allow that generic functions and methods do not? Thank you, Mirko

2 1

[Asdf-devel] Documentation questions about FIND-SYSTEM and LOCATE-SYSTEM
by Robert P. Goldman 02 Jul '14

02 Jul '14

When following up discussion about bug 1335323, I stumbled across the following paragraph in the manual: When system definitions are loaded from @file{.asd} files, a new scratch package is created for them to load into, so that different systems do not overwrite each others operations. The user may also wish to (and is recommended to) include @code{defpackage} and @code{in-package} forms in his system definition files, however, so that they can be loaded manually if need be. I believe that this is no longer accurate. Fare, you changed to loading everything into ASDF-USER, didn't you? Also, LOCATE-SYSTEM isn't documented at all. I see that it's exposed by interface.lisp, but I'm not sure why it is. If exposed, I'd like to document it, but it looks like an outsider should always use FIND-SYSTEM.

2 6