asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

[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 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel