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

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

17 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

[Asdf-devel] :AROUND methods
by Robert P. Goldman 08 Jun '14

08 Jun '14

Trying to identify what's breaking my system in the syntax-case branch, I found a bunch of around methods in ASDF. IIRC once upon a time we had removed all the :AROUND methods on exported generic functions, on the grounds that they could unpredictably interact with programmers' extensions. I think we experimented with using a bespoke method combination method to allow ourselves to have our own around methods and "arounder" methods for programmers. Even more vaguely, I think I remember that the method-combination extension didn't work reliably on all implementations, so it was stripped out. But I thought when that happened, we tried to excise the use of method combination in ASDF. Am I hallucinating this? I'd be grateful to anyone whose memory of this stuff is better. thanks, r

2 5

[Asdf-devel] New draft of design document pushed
by Robert P. Goldman 03 Jun '14

03 Jun '14

It's still at an interim state, but I think it's getting to the point where it will be generally useful. I did a bunch of minor reformatting, and took a several of your responses and translated them into the main thread, removing the back-and-forth: I don't think the discussion is as valuable as a clear statement of the design. I have a big, sloppy mess of a system involving at least one additional readtable, that breaks under the syntax-control branch. That's going to be my test case for forcing myself to understand this. Best, r

2 2

[Asdf-devel] Merged master into syntax-control
by Robert P. Goldman 01 Jun '14

01 Jun '14

To ease understanding of changes, I've merged master into syntax-control, and pushed the result. Please LMK if there are any issues with this. The resulting branch passes all the regression tests (haven't tested updates). cheers, r

1 0

Re: [Asdf-devel] Wanted: Debian packager
by Faré 25 May '14

25 May '14

Here's the patch I've committed on my local release branch, but haven't pushed to common-lisp.net yet, pending maintainer approval. Note that 1- the email listed at the end of the top entry of the changelog has to be the same as the person who's going to sign the package with his PGP key as registered on mentors.debian.net, before the package is uploaded. So if someone else is going to upload this or future packages, the address should be amended (and also added in the debian/control file). 2- lintian ../cl-asdf*.changes is your friend. 3- To create the package I'm using the version of the release script that's in master, 4- A good exercise in further bootstrapping ASDF would be convert bin/asdf-builder to a trivial cl-launch script + a system asdf-build (or meta-asdf? whatever), and the Makefile to a trivial wrapper that invokes it (except for the initial bootstrap of the concatenated build/asdf.lisp), and the Makefile targets into as many secondary systems of asdf-build. I'm refraining from doing more of it, since I'm moving to new projects. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A single flaw in someone else's beliefs, they are discredited. Repeated obvious flaws in your own, you keep the blind faith. Government saves! On Fri, May 16, 2014 at 8:57 AM, Kambiz Darabi <darabi(a)m-creations.com> wrote: > Hello, > > On 2014-05-16 07:12 CEST, Faré <fahree(a)gmail.com> wrote: > >> That said, I can do the asdf debian package one last time for 3.1.2. >> I've experimented a bit and come up with a better recipe. Apparently >> the trick to avoid dealing with complications is to work in a branch >> where the only changes since the upstream release tag are in the >> debian/ directory. If you let me do it, I'll do it in the release >> branch. I updated the bin/asdf-builder script to do the release >> (moving code from the Makefile and making it better — scripting is SO >> much better in Lisp). Of course, the script as exists in the release >> branch is insufficient, and since it does a git clean -xfd we need to >> extract it from master under another name everytime. >> So: I committed some debian-only changes in my release branch (not >> pushed — but I can do it if you approve, and even upload), and ran: >> git show master:bin/asdf-builder > bin/x && chmod a+x bin/x && >> ./bin/x debian-package >> and it looks like it worked. I can push all that if you want, or show >> you how to do it. It's a matter of >> git checkout release ; git show master:debian/changelog > >> debian/changelog ; edit debian/changelog > > I have never packaged for Debian, but I use it since rex (1996). With a > bit of hand-holding, I might be able to do the packaging work. > > Where can I fetch your changes? > > > Kambiz Darabi

4 7

Re: [Asdf-devel] Wanted: Debian packager
by Kambiz Darabi 16 May '14

16 May '14

Cross-posted to asdf-devel before subscribing: -------------------- Start of forwarded message -------------------- From: Kambiz Darabi <darabi(a)m-creations.com> To: Faré <fahree(a)gmail.com> Cc: Robert Goldman <rpgoldman(a)sift.info>, Debian Common Lisp Team <pkg-common-lisp-devel(a)lists.alioth.debian.org>, ASDF-devel <asdf-devel(a)common-lisp.net> Subject: Re: [Asdf-devel] Wanted: Debian packager Date: Fri, 16 May 2014 08:57:10 +0200 Hello, On 2014-05-16 07:12 CEST, Faré <fahree(a)gmail.com> wrote: > That said, I can do the asdf debian package one last time for 3.1.2. > I've experimented a bit and come up with a better recipe. Apparently > the trick to avoid dealing with complications is to work in a branch > where the only changes since the upstream release tag are in the > debian/ directory. If you let me do it, I'll do it in the release > branch. I updated the bin/asdf-builder script to do the release > (moving code from the Makefile and making it better — scripting is SO > much better in Lisp). Of course, the script as exists in the release > branch is insufficient, and since it does a git clean -xfd we need to > extract it from master under another name everytime. > So: I committed some debian-only changes in my release branch (not > pushed — but I can do it if you approve, and even upload), and ran: > git show master:bin/asdf-builder > bin/x && chmod a+x bin/x && > ./bin/x debian-package > and it looks like it worked. I can push all that if you want, or show > you how to do it. It's a matter of > git checkout release ; git show master:debian/changelog > > debian/changelog ; edit debian/changelog I have never packaged for Debian, but I use it since rex (1996). With a bit of hand-holding, I might be able to do the packaging work. Where can I fetch your changes? Kambiz Darabi -------------------- End of forwarded message --------------------

1 0

[Asdf-devel] Wanted: Debian packager
by Robert P. Goldman 16 May '14

16 May '14

For previous versions of ASDF, Faré has been providing a debian package, cl-asdf. I'd like a volunteer to take over the packaging process. The more I mess with this, the less I feel like I know what I'm doing. I haven't *maintained* (as opposed to used) a Linux box for about 5 years, and when I did, I used an RPM-based distro, instead of a .deb-based one. For that matter, this is not dogfood that I plan on consuming. So..... 1. Is anyone else willing to take over the packaging? This should be relatively minimal amount of work, really just running the build scripts, uploading the packages, and yelling at me when the Changelog is badly formatted, etc. 2. If the answer to #1 is "no," how bad is that, anyway? Does anyone actually use ASDF from cl-asdf instead of getting it bundled from their implementation or installing from source? Maybe this package could simply go away? Cheers, r

2 3