asdf-devel

asdf-devel@common-lisp.net

2 participants
1378 discussions

[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 20 Mar '13

20 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 14 Mar '13

14 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

[asdf-devel] ECL upgrade failed
by Robert Goldman 12 Mar '13

12 Mar '13

Ran the tests again today, and got this new error: Configuring ASDF Being a bit verbose Frob packages TEST ABORTED: Cannot use #<"UIOP/DRIVER" package> from #<"ASDF-TEST" package>, because UIOP/PATHNAME:PATHNAME-DIRECTORY-PATHNAME and PATHNAME-DIRECTORY-PATHNAME will cause a name conflict. Script failed upgrade FAILED for ecl from 2.21 using method 'load-asdf-lisp-and-test-uiop'load-asdf-fasl This is ECL 12.12.1, Mac OS X Lion. Best, R

2 1

Re: [asdf-devel] testing ASDF with cl-test-grid
by Anton Vodonosov 12 Mar '13

12 Mar '13

Performed tests with ABCL and ACL (express edition, and on Windows, as my linux system turns out to be too old to run ACL 9.0 and the ACL 8.0 Express license has expired). http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-20.html ACL shows new problem with portableaserve and via it with all genworks-gdl systems. The error: No defined method for ASDF/ACTION:PERFORM oncompiling #<ORIGINAL-ASERVE "aserve" "dummy"> Aside from that all the failures are (upstream) library errors we saw already on other lisps. All the CRASH results are to be ignored. They are caused by heap size limitation of the ACL Express edition. ABCL shows no new problems. All the failures are upstream library errors we saw already on other lisps and com.informatimago.common-lisp TIMEOUT due to http://trac.common-lisp.net/armedbear/ticket/274. Best regards, - Anton

6 23

[asdf-devel] uiop 2.32.4's uiop.asd has nonexistent (:static-file "contrib/debug.lisp")
by Dave Cooper 09 Mar '13

09 Mar '13

As mentioned in subject: uiop 2.32.4's uiop.asd has nonexistent (:static-file "contrib/debug.lisp") This is causing (ql:quickload :uiop) to warn and consequently force a rebuild of it and all dependent systems. I see there is asdf/contrib/debug.lisp but no such file in uiop/ - is something supposed to be moved around? -- 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

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