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

[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 04 Jul '14

04 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

[Asdf-devel] Should MKCL wait for ASDF 3.1.3? [Was: Moving MKCL's bundled version to ASDF 3.1.2]
by Jean-Claude Beaudoin 21 Jun '14

21 Jun '14

On Fri, Jun 20, 2014 at 11:05 PM, Jean-Claude Beaudoin < jean.claude.beaudoin(a)gmail.com> wrote: > > On Fri, Jun 20, 2014 at 7:53 PM, Faré <fahree(a)gmail.com> wrote: > >> >> Robert, I took the liberty of committing this fix as 3.1.2.5. >> You might want a different fix, or to scratch this feature, etc. >> >> >> > I can confirm that, as of now, ASDF git master head is completing > a "live upgrade" like ASDF 3.0.3.0.X did. > > > In the light of this recent bug fix (mentioned here above) is there any significant advantage for MKCL to move to ASDF 3.1.2 (or should it be 3.1.2.6 or later) over, for example, waiting for ASDF 3.1.3? Robert, I am under the impression that this is mostly your call, is it not?

3 2

[Asdf-devel] Moving MKCL's bundled version to ASDF 3.1.2
by Jean-Claude Beaudoin 21 Jun '14

21 Jun '14

On Wed, Jun 18, 2014 at 1:55 AM, Faré <fahree(a)gmail.com> wrote: > Can you upgrade your ASDF from 3.0.3.0.2 to 3.1.2? > Does 3.1.2 require a patch? If it does, then let's get it pushed > upstream into e.g. 3.1.2.5. > > I dropped in ASDF 3.1.2 from the release tarball in the MKCL 1.1.9 source tree as a direct replacement of the currently bundled ASDF. It compiled fine. The whole MKCL build completes and installs as usual. The thus resulting ASDF 3.1.2 reports all tests are good when 'make test l=mkcl" is run, as well as with 'make test-upgrade l=mkcl'. But when I come to try an upgrade from 3.1.2 to 3.1.2.4 syntax-control branch I then get a crash. Here is attached the transcript of what is produced at the repl. The error message basically says that 'build/asdf.lisp' cannot be found. And in fact it is missing (it used to be produced properly by 3.0.3.0.X). If I drop to a shell prompt and do make build/asdf.lisp and try the same upgrade again then it completes properly. So is there something broken now with the ASDF bundle 'concatenate' ops? > NB: please send a diff; I can review it, but Robert should commit and > push it — I'm out of this business (except for the branches I wrote > and would like to see merged — Robert, any news about them?) > > Would do but I don't quite understand how to fix what I just reported here above. > PS: minor issue, but when I (quit), I get this annoying message: > > (quit) > > ;; MKCL shutdown: Thread refused to be interrupted: Sleeping thread: > #<thread "Imported thread pool filler daemon" active detached (27380) > 0x7f1aa19d0700 0000000003286000>, in file threads.d at line 1076. > ;; MKCL shutdown: Killing thread #<thread "Imported thread pool filler > daemon" active detached (27380) 0x7f1aa19d0700 0000000003286000>. > > Thanks for the report. I bet you get this only once in a blue moon. It is just a harmless annoyance. It also just reminds me that there is still some practical reality of thread programming I have come to terms with. It is the very low frequency combined with clear randomness that bothers me. I just have get back to it and silence this nagger for good... Thanks again.

3 6

[Asdf-devel] dragonfly BSD support
by Christophe Rhodes 20 Jun '14

20 Jun '14

Hi, I'm probably going to add DragonFly BSD support to SBCL. The patch I'm merging contains something a bit like the attached patch to asdf, which although is probably not necessary (we'll still have the :BSD feature in) might want to be added in for completion. Cheers, Christophe

2 2

Re: [Asdf-devel] mkcl and asdf upgrade. It works now.
by Jean-Claude Beaudoin 18 Jun '14

18 Jun '14

On Mon, Jun 16, 2014 at 9:20 PM, Faré <fahree(a)gmail.com> wrote: > Interestingly, uiop/common-lisp.lisp sets > clos::*redefine-class-in-place* in uiop/common-lisp — is the problem > due to your compiling asdf/defsystem separately, and bind r-c-i-p in > LOAD, so that this setting doesn't apply to asdf/defsystem? > I thought this was one possible problem but obviously this is not the one you hit upon. (And I believe it still is a loophole worth closing). > > At first, your solution looked like it wasn't working. Then, I tried > to reproduce, and then it worked against ASDF 3.1.2. But still not > against the syntax-control branch. I'm confused. > > It turns out that I have never taken time to do a complete and detailed inspection of each and every location in the MKCL's code where object up-to-date-ness is required, until now that is. And what you hit upon, trying to do your ASDF upgrade, revealed a good number of gaping holes inside MKCL in that area. So now I hope I have plugged all of them properly without missing one. The whole fix is in MKCL's git repo master head. I tried it on my copy of ASDF syntax-control branch head and it worked OK. Could you please confirm that it also works for you? This will be part of MKCL 1.1.9 that I will push out the door as a released version in a few days from now. Thank you for your help solving this MKCL's issue.

3 2

[Asdf-devel] Need to do uiop:setup-temporary-directory in image built with uiop
by Dave Cooper 18 Jun '14

18 Jun '14

Dear ASDF maintainer(s), I just noticed that it is necessary to do (uiop:setup-temporary-directory) in an image which has UIOP built into it, when that image is run on a different machine or under a different user account (at least on Windows). Otherwise, the function (uiop:temporary-directory) returns whatever was the temporary directory as computed in the build environment (in my case it's in the "dcooper8" home directory. So am I correct that it's pretty much a requirement to call (uiop:setup-temporary-directory) upon startup of an image which contains uiop built into it? Are there any other functions which should be called to initialize uiop? Is there a way to achieve this at image dump time instead of startup time (e.g. clearing the temporary directory entirely so it will be forced to reset when next demanded in the built image)? If I'm missing something from the documentation on this please feel free to slap me in that direction. Regards Dave Cooper

3 8