[Ecls-list] cl-launch and ecl, again

[Juan Jose Garcia-Ripoll]

On Fri, Oct 31, 2008 at 7:16 PM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> wrote:
> On Thu, Oct 30, 2008 at 6:43 PM, Faré <fahree at gmail.com> wrote:
>> If you're interested, you can try for yourself.
>>
>>  mkdir /tmp/foo
>>  cd /tmp/foo
>>  wget http://fare.tunes.org/files/cl-launch/cl-launch_2.09.sh
>>  apt-get install clisp gcl gclcvs cmucl sbcl
>>  ./cl-launch_2.09.sh -l 'ecl' -B tests
>
> Did this on my Mac OS X, using ECL sources from GIT or CVS
> repositories (master and stable branches respectively, so nothing
> fancy) and the first test that fails is #86. It fails because the
> value of the variable HEADER in BUILD-AND-DUMP is NIL and you are
> applying ENSURE-LISP-FILE on it. I cannot try on linux because my big
> quadcore box died this morning out of a hard disk failure.

I should add that I tried both from the command line and from a
running ECl, using the same commands that your log file shows. The
reason for running them from the toplevel instead of using -eval and
-load command line arguments is that the latter will _never_ enter the
debugger. This is designed so on purpose, since entering the debugger
in a script that is being executed god knows where and how is
unreasonable.

If you really need to enter the debugger, a workaround is to enclose
the command in a HANDLER-CASE statment as in
ecl -norc -eval '(setf si::*break-enable* t)' -eval '(handler-case
(cos #\a) (error (c) (invoke-debugger c)))'

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28009 (Spain)
http://juanjose.garciaripoll.googlepages.com