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

[asdf-devel] Towards ASDF 2.33
by Faré 27 Mar '13

27 Mar '13

Dear all, as things are settling down, I am resuming a monthly schedule for releasing ASDF. I intend to release ASDF 2.33 some time next week. Since previous release 2.32, it includes the following changes: * deferred-warning receives yet more improvements for CCL. * upgrade is made more robust in many cases, notably for ECL, SBCL, or when using UIOP with an old ASDF<=2.26. * Packages have been tweaked to pass more tests, notably wrt what symbols are exported. * Image lifecycle support is improved, thanks to deploying ASDF3 for QRes. More options for dump-image on CCL; handle reentrance in restore-image. * delete-directory-tree, delete-empty-directory, copy-file, directory-exists-p, file-exists-p were added to UIOP, also better strcat, with reduce/strcat, base-string-p, etc. * Portability tweaks for Allegro, Clozure, CLISP, ECL, LispWorks, SBCL. * Recompilation avoided for things already done by defsystem-depends-on. * monolithic-fasl-op was fixed in cases when the main system has components. * *uninteresting-conditions* was added as a common list of conditions shared between the compile-time and load-time muffled conditions. Please test as appropriate. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Society was guilty. It was thus arrested, tried, convicted, executed. Only remained individuals, free and responsible: You. No more excuse.

1 0

[asdf-devel] GCL support
by Faré 27 Mar '13

27 Mar '13

I'm told GCL can be compiled with cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/gcl co gcl ; cd gcl ./configure --disable-dynsysgmp --enable-static --prefix=$HOME/local make But it requires some symbols that are missing from the libnss or some such in Ubuntu 12.04LTS (which is a known bug in Ubuntu, fixed in the latest). I'm not going to bother making ASDF work with it, but in case some masochistic person wants to learn about portability across Common Lisp implementations the hard way, that's the dubious exercise proposal of the day. Maybe someone will even make a debian package out of it. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Skill without imagination is craftsmanship. Imagination without skill is contemporary art. — Tom Stoppard

1 0

[asdf-devel] ABCL and UIOP
by Mark Evenson 27 Mar '13

27 Mar '13

abcl-1.2.0-dev currently uses asdf-2.32 which includes a perfectly fine (as far as we know) UIOP. But one can't load UIOP 2.32.5 from Quicklisp 2013-03-12 in abcl-1.2.0-dev, getting the following error: The symbol UIOP/UTILITY::LOAD-ASDF-DEBUG-UTILITY is not accessible in package UIOP/DRIVER which is triggered by the following UNEXPORT: (UNEXPORT UIOP/UTILITY::LOAD-ASDF-DEBUG-UTILITY #<PACKAGE UIOP/DRIVER>) Is it to be expected that ASDF cannot, in general, "host" later versions of UIOP without first upgrading ASDF? It might be nice to consider some sort of warning in this situation, as until ASDF3 gets more widespread, people may be tempted to get Quicklisp to locate and load UIOP for them. Or maybe I have misunderstood the packaging of ASDF with ABCL? I have been simply using the results of "make build/asdf.lisp" in the path of our CL:REQUIRE implementation. I am supposed to somehow make the asdf.asd and uiop.asd files accessible as well?

2 7

[asdf-devel] test results for 1.2.0-dev
by Anton Vodonosov 22 Mar '13

22 Mar '13

Hello. Got the test results from Erik's machine few days ago, but only now have time to report them to the mailing list. Comparison of 1.1.1 and 1.2.0-dev on quicklisp 2013-03-12: http://common-lisp.net/project/cl-test-grid/abcl/abcl-diff3.html It doesn't present big difference as I hoped, because closer-mop now compiles on any version of ABCL, including 1.1.1. Maybe runtime behavior will be different, but we have no test suites which highlight this difference. Note some regressions: uiop, metacopy-with-contextl, xcvb-bridge. I haven't analyzed what is the cause. Probably something ASDF-related. To give you sense of ABCL progress, here is the report comparing ABCL 1.1.1 on two quicklisps: 2013-02-17 and 2013-03-12: http://common-lisp.net/project/cl-test-grid/abcl/abcl-diff4.html As you see, much more libraries compile OK in new quicklisp. Note, these two quicklisps were tested on different machines, and the later quicklisp was tested with absence of gcc. This explains failure of cl-gss for example, which can be ignored. Pay attention to some CRASH results in new quicklisp. These crashes reproduce in 1.2.0-dev too and are caused by various errors in ABCL (like index out of bounds, assertion failed). Command line to reproduce it at the cl-test-grid.cloud.efficito.com machine, as user testgrid: rm -r .cache/common-lisp/ java -XX:MaxPermSize=1024m -jar /home/testgrid/lisps/abcl/dist/abcl.jar --noinit --nosystem --batch --eval '(require :abcl-contrib)' --load /home/testgrid/quicklisp/setup.lisp --eval '(ql:quickload :cl-l10n)' > log 2>&1 Finally, here is the load failures report for 1.2.0-dev: http://common-lisp.net/project/cl-test-grid/abcl/abcl-1-2-0-load-failures.h… Recall, that the default sorting in this report tries to present on top the libraries fixing which will give bigger "outcome". More detailed explanation of the report columns is here: https://github.com/cl-test-grid/cl-test-grid/tree/master/reporting#combinin… As you see, there are several directions to dig further, depending on what you are more interested to start with. Let me know what other reports you want to see, or what configurations to test, or how to reproduce certain errors. Best regards, - Anton

1 1

[asdf-devel] Remaining issue with monofasl output - systems with no :components fail
by Dave Cooper 21 Mar '13

21 Mar '13

Oops, it looks like I didn't re-test the "workaround" case. That is, a system with some :depends-on but no :components. Such systems now fail to build either 'asdf:fasl-op or 'asdf:monolithic-fasl-op. The 'asdf:fasl-op gives the "WTF -- no input files?" Of course there are no input files -- there are no :components. So maybe the WTF error is correct behavior in the case of 'asdf:fasl-op. But in case of 'asdf:monolithic-fasl-op, I think the correct behavior should simply be to omit the "empty" fasl, which is apparently what it had been doing previously. This can be replicated with for example the current master of gendl. It's allowed for a defsystem to have only :depends-on and no :components, isn't it? -- 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

1 1

[asdf-devel] Workaround (was: adsf/bundle:monolithic-fasl sometimes puts dependent system first in list)
by Dave Cooper 20 Mar '13

20 Mar '13

As you probably are aware, an apparent workaround for this apparent bug is to make a toplevel "container" system, whose only contents is a :depends-on which contains the actual desired system (or list of systems). It seems that if the toplevel system has no actual file components, then it will not appear in the (asdf:component-depends-on 'asdf/bundle:monllithic-fasl-op ...) at all, and subsequently the systems appear in the correct order --- so the generated monofasl will be usable. In fact that's why I didn't see the bug initially, because gendl.asd normally is just such a container system and has no source components (last night I purposely "broke" it for testing by inclusion of a "source/try.lisp" at the toplevel -- if you clone the repository now, that source directory will not be there, and the monofasl for :gendl will work). I hope this is useful information. On Fri, Mar 15, 2013 at 7:06 PM, Dave Cooper <david.cooper(a)genworks.com>wrote: > > Try this: > > 1. git clone git://github.com/genworks/gendl.git > > 2. put it in your quicklisp/local-projects/ > > 3. (ql:register-local-projects) > > 4. (ql:quickload :gendl) > > 5. (ql:operate 'asdf/bundle:monolithic-fasl-op :gendl) > > 6. (first (asdf:output-files 'asdf/bundle:monolithic-fasl-op :gendl)) > > 7. Copy the yielded pathname string to use in next step. > > 8. [in a fresh Lisp] (load <the --all-systems fasl from step 7>) > > 9. [back in first Lisp]: > > (asdf:component-depends-on 'asdf/bundle:monolithic-fasl-op :gendl) > > 10. Read it and weep. system :gendl comes _first_ in the list. I feel it > should come _last_. > > > I tried to look into the asdf code behind this operation but am afraid it > is currently far over my head. > > > > -- > 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 > -- 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

2 5

Re: [asdf-devel] Workaround (was: Canonical function to list ordered components for asdf/bundle:monolithic-fasl-op (was: adsf/bundle:monolithic-fasl sometimes puts dependent system first in list))
by Dave Cooper 18 Mar '13

18 Mar '13

> What is the canonical function to see the list which will be > > written out by asdf/bundle:monolithic-fasl-op? I remember you said it's > not > > really component-depends-on -- so what is it again? > > > -- 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

2 1

[asdf-devel] adsf/bundle:monolithic-fasl sometimes puts dependent system first in list
by Dave Cooper 16 Mar '13

16 Mar '13

Try this: 1. git clone git://github.com/genworks/gendl.git 2. put it in your quicklisp/local-projects/ 3. (ql:register-local-projects) 4. (ql:quickload :gendl) 5. (ql:operate 'asdf/bundle:monolithic-fasl-op :gendl) 6. (first (asdf:output-files 'asdf/bundle:monolithic-fasl-op :gendl)) 7. Copy the yielded pathname string to use in next step. 8. [in a fresh Lisp] (load <the --all-systems fasl from step 7>) 9. [back in first Lisp]: (asdf:component-depends-on 'asdf/bundle:monolithic-fasl-op :gendl) 10. Read it and weep. system :gendl comes _first_ in the list. I feel it should come _last_. I tried to look into the asdf code behind this operation but am afraid it is currently far over my head. -- 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 2

[asdf-devel] New tests with upgrade
by Robert Goldman 15 Mar '13

15 Mar '13

Works better, thanks! Still running into an error when trying to upgrade allegromodern from 1.85, though. What's odd is that this fails when running inside 'make test-all': Above backtrace due to this condition: #P"/Users/rpg/lisp/asdf/build/fasls/acl-8.2m-macosx-x64/asdf/build/asdf.fasl" does not exist, cannot load Script failed upgrade FAILED for allegromodern from 1.85 using method 'load-asdf-lisp'load-asdf-system But when I run mlisp -q and follow the directions given: mlisp -q then copy/paste: (load"test/script-support.lisp") (asdf-test::da) (test-upgrade 'load-asdf-lisp'load-asdf-system "1.85") everything is fine: ; Upgraded ASDF from version 1.85 to version 2.32.8 ; Registering #<system "asdf"> ;; ASDF, version 2.32.8 Testing it ;;; Installing streamc patch, version 3. ;;; Compiling file /Users/rpg/lisp/asdf/build/asdf.lisp ;;; Writing fasl file ;;; /Users/rpg/.cache/common-lisp/acl-8.2m-macosx-x64/Users/rpg/lisp/asdf/build/asdf-ASDF-TMP.fasl ;;; Fasl write complete Warning: first-feature is defined more than once as `operator' in file /Users/rpg/lisp/asdf/build/asdf.lisp. Warning: implementation-type is defined more than once as `operator' in file /Users/rpg/lisp/asdf/build/asdf.lisp. Warning: *implementation-type* is defined more than once as `variable' in file /Users/rpg/lisp/asdf/build/asdf.lisp. Warning: operating-system is defined more than once as `operator' in file /Users/rpg/lisp/asdf/build/asdf.lisp. Warning: architecture is defined more than once as `operator' in file /Users/rpg/lisp/asdf/build/asdf.lisp. ;;; Compiling file /Users/rpg/lisp/asdf/test/file1.lisp ;;; Writing fasl file ;;; /Users/rpg/.cache/common-lisp/acl-8.2m-macosx-x64/Users/rpg/lisp/asdf/test/file1-ASDF-TMP.fasl ;;; Fasl write complete ;;; Compiling file /Users/rpg/lisp/asdf/test/file2.lisp ;;; Writing fasl file ;;; /Users/rpg/.cache/common-lisp/acl-8.2m-macosx-x64/Users/rpg/lisp/asdf/test/file2-ASDF-TMP.fasl ;;; Fasl write complete ;;; Compiling file /Users/rpg/lisp/asdf/test/file3.lisp ;;; Writing fasl file ;;; /Users/rpg/.cache/common-lisp/acl-8.2m-macosx-x64/Users/rpg/lisp/asdf/test/file3-ASDF-TMP.fasl ;;; Fasl write complete ;;; Compiling file /Users/rpg/lisp/asdf/test/file4.lisp ;;; Writing fasl file ;;; /Users/rpg/.cache/common-lisp/acl-8.2m-macosx-x64/Users/rpg/lisp/asdf/test/file4-ASDF-TMP.fasl ;;; Fasl write complete Script succeeded nil This suggests the problem may be in the testing infrastructure. best, r

2 1

[asdf-devel] Still having errors on ECL upgrade tests
by Robert Goldman 15 Mar '13

15 Mar '13

This time on 2.32: Testing ASDF upgrade from 2.32 using method 'load-asdf-lisp'load-asdf-lisp-clean make[2]: *** No rule to make target `uiop/package.lisp', needed by `build/asdf.lisp'. Stop. ./test/run-tests.sh -c ecl Cheers, r

2 1