[asdf-devel] Test results on Mac OSX

[Robert Goldman]

On 2/24/13 Feb 24 -7:05 PM, Faré wrote:
> On Sun, Feb 24, 2013 at 7:14 PM, Robert Goldman <rpgoldman at 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