asdf-devel

asdf-devel@common-lisp.net

2 participants
1378 discussions

[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 20 Jun '14

20 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 17 Jun '14

17 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

Re: [Asdf-devel] mkcl and asdf upgrade
by Jean-Claude Beaudoin 16 Jun '14

16 Jun '14

On Sat, Jun 14, 2014 at 1:26 PM, Faré <fahree(a)gmail.com> wrote: > > Could you please do > > > > rm /home/tunes/src/common-lisp/mkcl/src/gc/include/private/config.h > > > > and then do again the sequence: > > > > make distclean; configure <your options>; make > > > > I'll try to make a better fix in the next hours... > > > > > That worked, as far as building mkcl goes. Of course, mkcl still has > the same class redefinition bug. > > I think the full fix is now in git repo master head. Could you please do a "make distclean" then pull from git repo master head, configure again, and finally do a "make install" or whatever you need to re-attempt the ASDF upgrade that broke. Please tell me the result.

3 4

Re: [Asdf-devel] mkcl and asdf upgrade, partial fix
by Jean-Claude Beaudoin 14 Jun '14

14 Jun '14

On Sat, Jun 14, 2014 at 3:47 AM, Faré <fahree(a)gmail.com> wrote: > I tried to run cl-launch with mkcl, and mkcl crashed during the > upgrade of asdf from 3.0.3.0.1 to 3.1.2: > echo '(in-package :fare-quasiquote) (format t "~A~%" *package*)' | cl > -l mkcl -s fare-quasiquote-extras -f - > Error during command line arguments processing: > The index 35 (max: 31) is not a valid slot > index in the object #<ASDF/SYSTEM:SYSTEM "asdf">.. > > I suppose it's the new slots added in the syntax-control branch that > are confusing mkcl when it fails to correctly use the magic that calls > update-instance-for-redefined-class. > Still investigating this one. > > I tried to compile a newer mkcl with asdf 3.1.2, but got this error: > > make[2]: Leaving directory `/home/tunes/src/common-lisp/mkcl/src/c' > gcc -o mkcl_min c/cinit.o c/all_symbols.o mkclmin.a mkclgc.a -lgmp > -pthread -lrt -ldl -lm > mkclmin.a(alloc_2.o): In function `mkcl_init_alloc': > /home/tunes/src/common-lisp/mkcl/src/c/alloc_2.d:1007: undefined > reference to `MK_GC_set_thr_restart_signal' > mkclmin.a(unixint.o): In function `mkcl_init_late_unixint': > /home/tunes/src/common-lisp/mkcl/src/c/unixint.d:1918: undefined > reference to `MK_GC_get_thr_restart_signal' > collect2: ld returned 1 exit status > > This should now be fixed in git repo master head. Thanks for the report.

1 0

[Asdf-devel] mkcl and asdf upgrade
by Faré 14 Jun '14

14 Jun '14

I tried to run cl-launch with mkcl, and mkcl crashed during the upgrade of asdf from 3.0.3.0.1 to 3.1.2: echo '(in-package :fare-quasiquote) (format t "~A~%" *package*)' | cl -l mkcl -s fare-quasiquote-extras -f - Error during command line arguments processing: The index 35 (max: 31) is not a valid slot index in the object #<ASDF/SYSTEM:SYSTEM "asdf">.. I suppose it's the new slots added in the syntax-control branch that are confusing mkcl when it fails to correctly use the magic that calls update-instance-for-redefined-class. I tried to compile a newer mkcl with asdf 3.1.2, but got this error: make[2]: Leaving directory `/home/tunes/src/common-lisp/mkcl/src/c' gcc -o mkcl_min c/cinit.o c/all_symbols.o mkclmin.a mkclgc.a -lgmp -pthread -lrt -ldl -lm mkclmin.a(alloc_2.o): In function `mkcl_init_alloc': /home/tunes/src/common-lisp/mkcl/src/c/alloc_2.d:1007: undefined reference to `MK_GC_set_thr_restart_signal' mkclmin.a(unixint.o): In function `mkcl_init_late_unixint': /home/tunes/src/common-lisp/mkcl/src/c/unixint.d:1918: undefined reference to `MK_GC_get_thr_restart_signal' collect2: ld returned 1 exit status —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Economics is not about goods and services; it is about human choice and action. — Ludwig von Mises

1 0

[Asdf-devel] syntax-control branch
by Robert P. Goldman 08 Jun '14

08 Jun '14

I haven't fully grokked the code changes in the syntax-control branch yet. However, I have read over the design notes in TODO, and pulled them out into a separate file, which I am attaching here. I have annotated with a number of open questions, and added a bullet point to document rationale, which is currently mostly a place-holder for a statement. WRT my concerns about the syntax-control modifications: I have done some rooting around and have found a few libraries that are intended to set up a system for interactive use with a special readtable. These are things like expert system shells, etc. So at some point near the end of their system load, they will set *READTABLE* prior to finishing the load and dropping out for the user to deal with them. I can see that someone might not like this -- indeed, I'd rather there was a (START-FOO-SHELL) command instead. On the other hand, note that these are not really LIBRARIES; these are SYSTEMS. These are not intended to be slurped into something else: the programmer expects that his/her system will load, set up things for an interactive user, and then hand back control to the user through the REPL. Isn't the syntax control approach fundamentally incompatible with this? I don't think this is an especially tasty thing to do, but I'm also not convinced that it's ASDF's job to break arbitrary CL anti-patterns. Changing this behavior is likely to give very confusing bugs that won't be obvious to the poor user. On the other hand, I see files where there's something that sets the READTABLE obviously where what's intended is to simply set the readtable for the compiling and loading of this one file, and leaking that change is wrong. Note that a programmer who wants to be clean about this, in the current world, can set the readtable at the top of a file, and restore it at the bottom. If we take away the current behavior, the programmer who wants to set things up for the user is just completely out of luck. Or, maybe not: the very sophisticated ASDF user could add a PERFORM method on LOAD-OP on the interactive system. I think. I haven't grokked what's going on in syntax-control well enough. I am in a quandary about this. IMO the problem is a hole in the CL spec, which doesn't provide a good way to distinguish between two different intended uses for readtables. Before merging the syntax-control mods, I need to be convinced that it's appropriate for the ASDF community to force a solution to this problem on the CL community, instead of leaving the CL community to pick its way through the issue as it has to date.

2 8

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel