On 2010-03-17, at 14:46 , Faré wrote:
On 17 March 2010 05:20, james anderson james.anderson@setf.de wrote:
On 2010-03-17, at 02:50 , Faré wrote:
ECL & LispWorks work for me,
that's nice. ecl has some sort of problem with the test mechanism[0],
what might the error in the cited transcript indicate as the cause for the problem with ecl? here is one entry:
Testing: asdf-pathname-test.script ;;; Loading "/ebs/test/asdf/test/asdf-pathname-test.script" ;;; Loading #P"/ebs/test/asdf/test/script-support.lisp" ;;; Loading #P"/development/lib/ecl-10.2.1/cmp.fas" ;;; Loading #P"/development/lib/ecl-10.2.1/sysfun.lsp" ;;; Loading "/ebs/test/asdf/tmp/asdf-ecl.fas" An error occurred during initialization: LOAD: Could not load file #P"/ebs/test/asdf/tmp/asdf-ecl.fas" (Error: "/ebs/test/asdf/tmp/asdf-ecl.fas: invalid ELF header"). Using ecl , asdf-pathname-test.script failed
abcl had a similar problem:
Testing: test-force.script Armed Bear Common Lisp 0.18.1 Java 1.6.0_0 Sun Microsystems Inc. OpenJDK Client VM Low-level initialization completed in 1.985 seconds. Startup completed in 3.591 seconds.
Caught ERROR while processing --eval option "(load "test- force.script")": Failed to find asdf-abcl.lisp in /ebs/test/asdf/tmp/asdf-abcl.abcl. Using abcl , test-force.script failed
which it does not have when i run the pathname tests as originally structured.
in order to run lispworks in batch mode i must trash the x library and feed the tests through stdin. that's a problem with their free version.
You should ask for a test license from LispWorks, then you can obtain the "lispworks" binary suitable for testing with, e.g. # echo '(hcl:save-image "lispworks" :environment nil)' > /tmp/ build.lisp ; # ./lispworks-6-0-0-x86-linux -siteinit - -init - -build /tmp/ build.lisp
i have asked.
i was hoping they would release something prebuilt in order that i can avoid having to install the entire java dev world just in order to build abcl.
their report must be missing some details: the leave-lisp operator is missing a clause for abcl, which prevents the tests from running. it needs something like
#+abcl (extensions:quit :status return)
before they get off the ground. in any case, the transcript[1] reads as if there is some problem with the test mechanics not with the test content. if you have any insight into that aspect of the problem, that would help.
You can either export ASDF_OUTPUT_TRANSLATIONS= something or after loading asdf you can asdf:initialize-output-translations with a proper SEXP.
what would a proper value be? one which still can claim to test asdf's "normal" configuration?
In run-tests.sh I currently use export ASDF_OUTPUT_TRANSLATIONS="${asdfdir}:${asdfdir}/tmp/fasls/$ (basename $command):"
the problem arises when running run-tests.sh from a web server.
would it controvert the purpose fo the tests to set it to a single directory which i know the web server process can use?
The whole point of that value is to short-circuit the "normal" configuration. But the last ":" in said variable is so you can still see said normal configuration when you print (asdf::output-translations).
I'd be most happy if it [ASDF tests] converted to using Stefil or 5AM or some such thing, with proper asdf::*variable* rebinding and package deletion. But I'm probably not going to do it myself.
[0] : http://ec2-174-129-63-37.compute-1.amazonaws.com/test/log/ 20100316T233422/ecl-output.txt [1] : http://ec2-174-129-63-37.compute-1.amazonaws.com/test/log/ 20100316T233422/abcl-output.txt
[ François-René ÐVB Rideau | Reflection&Cybernethics | http:// fare.tunes.org ] Mathematicians are like lovers. Grant a mathematician the least principle, and he will draw from it a consequence which you must also grant him, and from this consequence another. — Bernard Le Bouyer de Fontenelle