[Ecls-list] cl-launch and ecl, again
fahree at gmail.com
Sat Nov 1 15:57:24 UTC 2008
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.
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
> 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
> LAUNCH_FORM="(handler-bind ((error #'invoke-debugger)) (progn (setf
> 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
> 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.
> Backtrace: CL-LAUNCH::BUILD-AND-DUMP > cl-launch::run > si:bytecodes >
> si:bytecodes > si:bytecodes > si:bytecodes > si:bytecodes >
> 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")
>> (probe-file "cl-launch-14000-load.lisp")
> 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.
More information about the ecl-devel