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

[Faré]

Dear JJ,

once again, thanks a lot for your support.

I've uploaded an updated version of cl-launch without the bugs you
reported, but the basic failure of ECL is the same. Whatever the
faults of cl-launch are, the error message is much too low-level to be
of practical help debugging them.

http://fare.tunes.org/files/cl-launch/cl-launch_2.10.sh

Note that if you copy-paste the ecl command for debugging, you need to have
* the clt-asd.asd file and its accompanying the clt-sys.lisp as
created by running the cl-launch test, as well as any other cl-launch
test file. Substitute any asd file, really.
* proper environment:
  export CL_LAUNCH_PID=12345 CL_LAUNCH_HEADER=/home/fare/bin/cl-launch
CL_LAUNCH_DEBUG=t

> Ok, seems like HANDLER-BIND is a better option because you break
> directly where the error happens. In the case of cl-launch, the
> appropriate option to get into the debugger with errors would be to
> use
>  LAUNCH_FORM="(handler-bind ((error #'invoke-debugger)) (progn (setf
> si::*break-enable*
> t)${MAYBE_PACKAGE_FORM}${HASH_BANG_FORM}${LAUNCH_FORMS}))"
> which both enables the debugger and binds it to error conditions.
>
The newly added CL_LAUNCH_DEBUG flag (not a command-line option yet)
inserts the handler-bind debugging statement you suggested for ECL.

> When I apply this change to the test 86, the result is
>
I'm baffled that you can go beyond test 76. If you could, maybe the
problem is that I didn't compile my ECL properly? For reference, I'm
using a git checkout from a few days ago with

./configure --prefix=/usr/local/stow/ecl --enable-gengc
--enable-smallcons --enable-unicode --enable-threads=auto
--enable-shared --enable-boehm=system --enable-slow-config
--with-system-gmp --enable-opcode8 --enable-long-double --with-x

I'll try updating to today's git and trying again (nah, today it
complains it can't find GC_malloc in -lgc then dies saying "configure:
error: System Boehm GC library requested but not found." yet I can
find GC_malloc in /usr/lib/libgc.so).

> ;;; Warning: COMPILE-FILE warned while performing #<ASDF:COMPILE-OP
> NIL 16823760> on
> #<ASDF:CL-SOURCE-FILE "header" "cl-launch-14000-prefix" 7659520>.
> Filesystem error with pathname
> #P"/Users/jjgarcia/src/cl-launch/cl-launch-14000-load.lisp".
> Either
>  1) the file does not exist, or
>  2) we are not allow to access the file, or
>  3) the pathname points to a broken symbolic link.
> Broken at SI:TOP-LEVEL.Available restarts:
> 1. (TRY-RECOMPILING) Try recompiling load
> 2. (RETRY) Retry performing #<ASDF:COMPILE-OP NIL 16823760> on
> #<ASDF:CL-SOURCE-FILE "load" "cl-launch-14000-prefix" 7684056>.
> 3. (ACCEPT) Continue, treating #<ASDF:COMPILE-OP NIL 16823760> on
> #<ASDF:CL-SOURCE-FILE "load" "cl-launch-14000-prefix" 7684056> as
> having been successful.
> Top level.
>> :b
> Backtrace: CL-LAUNCH::BUILD-AND-DUMP > cl-launch::run > si:bytecodes >
> si:bytecodes > si:bytecodes > si:bytecodes > si:bytecodes >
> si:bytecodes
>> :v
> Local variables:
>  CL-LAUNCH::DUMP: "/Users/jjgarcia/src/cl-launch/clt.image"
>  LOAD: "/Users/jjgarcia/src/cl-launch/clt-out-sh"
>  CL-LAUNCH::SYSTEM: NIL
>  RESTART: "tt"
>  CL-LAUNCH::INIT: NIL
>  CL-LAUNCH:QUIT: 0
>  CL-LAUNCH::HEADER: "./cl-launch_2.09.sh"
>  CL-LAUNCH::HEADER-FILE: "cl-launch-14000-header.lisp"
>  CL-LAUNCH::LOAD-FILE: "cl-launch-14000-load"
>> (probe-file "cl-launch-14000-load")
> #P"/Users/jjgarcia/src/cl-launch/cl-launch-14000-load"
>> (probe-file "cl-launch-14000-load.lisp")
> NIL
>
> The compiler fails to find the file without the appropriate extension.
>
There was a bug in cl-launch that I fixed in 2.10, but the basic
low-level failure remains for me after I fix it. Actually, with bug
fixed, the low-level failure now occurs for me with both
build-and-dump strategies (switch from xxx- to yyy- in the appropriate
source code location).

Thanks again for your support!

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Luck occurs when preparedness meets opportunity.