On 2/24/13 Feb 24 -7:05 PM, Faré wrote:
On Sun, Feb 24, 2013 at 7:14 PM, Robert Goldman rpgoldman@sift.info wrote:
TEST ABORTED: Subprocess run with command "/bin/ln -sf /Users/rpg/lisp/asdf/test/test-multiple.asd /Users/rpg/lisp/asdf/build/test-multiple-too.asd 2>&1" exited with error code 1
No backtrace for this.
I believe the problem is that EXT:SYSTEM on ECL runs whatever shell is the value of SHELL, but your test code is all written for bash, without checking for it.
I use the T shell.
Probably a good thing that I am testing with this unusual configuration!
I suppose the test code should force SHELL to be bash. I don't know if there's a portable way to do this. ASDF used to invoke /bin/sh, in RUN-SHELL-COMMAND, IIRC.
It is possible that there is a bug in asdf/driver:run-program, or maybe one in ECL itself. Can you run again while tracing as follows? (trace asdf/driver:run-program ext:run-program ext:shell)
I think the test-multiple might pass if you the /bin/ in /bin/ln.
Is the "T shell" the same thing as tcsh? Let me try it... Indeed, I can reproduce the failure with SHELL=tcsh make t l=ecl t='test-run-program.script even though this works: SHELL=tcsh make t l=ccl t='test-run-program.script That's because somehow ECL, to get the exit value of a process, reverts to a more primitive call to system, and then relies on "exec > tmpfile ; command" for redirection, independently from the content of command. It looks like this is not portable to tcsh; and probably not to Windows, either. I don't know how to solve this problem portably or to automatically detect a workaround.
Maybe the test script runner should just export SHELL=/bin/sh ?
That sounds right for the short term.
I don't claim to have fully grokked ASDF:RUN-PROGRAM yet. Would it be reasonable to modify it so that when :force-shell is T (a) it prefers /bin/sh to alternatives, or CMD.EXE on windows? and (b) it allows the user to override and request her shell to be used?
The reason I suggest this is that it would provide a consistent way to encapsulate the behavior we see from ECL. We default to a standard shell for the maximum in portability, but we allow the programmer to demand his shell under some circumstances?
I have given this exactly 2.4 seconds of thought, so this might be A Very Stupid Idea.
I was just looking for a portable way to keep ecl's behavior and other systems behaviors consistent when viewed through ASDF:RUN-PROGRAM.
- ABCL 1.1.0.2 failed test-encodings: [...]
Weird. Looks like the UTF-8-encoded characters were read as MacRoman. Within which sub-test does that occur? A bit more context above would help.
This is the one that failed:
(with-encoding-test (explicit-u8 :utf-8) (def-test-system :test-encoding-explicit-u8 :components ((:file "lambda" :encoding :utf-8))))
Note that to make this work, I added a dynamic variable that bound asdf-test::*test-name* and made the assert-compare-helper incorporate that name in its output.
The dynamic variable was a little yucky, but otherwise I would have had to push the name (as an optional) through the arglist of all of the comparison macros....
This might be useful for debugging, but the implementation is super nasty.
I'm not sure what you changed to "make it work". If explicit request for utf-8 encoding doesn't work, something is probably broken in either asdf and/or abcl.
Sorry -- "make it work" just meant "make it so that I could determine which test failed," not "make the encoding behave correctly."
best, r