[Ecls-list] Embedding ECL inside a containing C++ program.
Andrew Topp
talmakion at yahoo.com.au
Fri Aug 23 10:06:03 UTC 2002
Juanjo:
I've rewritten the Lisp plugin to use frs_push() and
the CLOS classes instead of setjmp() and direct
fn-pointer hooks to modified sources. UC now compiles
against vanilla ECL, and kind of runs.
I have a problem with IO, however. The setjmp() stuff
works fine.
uc-stdio-stream is a class defined in stdio.lsp,
loaded from ucl-init.lsp, UC's Lisp initialization
file. It just contains a bunch of methods which call
make_si_function()'d cfuns to do their dirty work.
I use this code to create the instance:
(defvar *unicorp-io* nil)
(defun unicorp-setup-io ()
(if (not (eq (type-of *unicorp-io*)
'UC-STDIO-STREAM))
(setq *unicorp-io* (make-instance (find-class
'uc-stdio-stream))))
(setf *standard-input* *unicorp-io*
*standard-output* *unicorp-io*
*error-output* *unicorp-io*
*query-io* *unicorp-io*
*debug-io* *unicorp-io*
*terminal-io* *unicorp-io*
*trace-output* *unicorp-io*))
(The if statement is some grunge I added while trying
to debug).
Output works fine, everything goes to the console
perfectly. The top-level runs from ucl-init, prints
its banner, calls read-char which uses cl_throw() to
break back to UC.
The first command I enter to the console evaluates
correctly. I rewrote the console code the same day I
redid the lisp plugin, so there's some rendering
problems with newlines still. But it does work.
Typing _anything_ after the first command, will
generate the error:
No applicable method for STREAM-READ-CHAR
Continually. Nothing else will be parsed. It seems to
happen before the evaluation even begins; evaluation
is done via a top-level wrapper which catches errors
and allows tpl to eat the form through
uc-stdio-stream. INVOKE-TOP-LEVEL isn't even called;
RunText evaluates forms by
eval(c_string_to_object("(invoke-top-level)"), NULL,
Cnil);.
Error handling and the debugger are things which I'm
working on, syntax errors in files usually end up in
freezes with ECL spamming stderr with
bind-stack-overflow errors, runtime errors are handled
ok. Any syntax error in ucl-init load results in a
segfault. Some runtime errors during init are handled
ok.
The problem with the stdio-stream is probably in my
Lisp. If you have any ideas or suggestions I should
try or test I'd be grateful.
Any pointers on how to gracefully handle errors and
even invoke the debugger safely from within the
embedded environment (throw/catch with a FEerror in
between seems to result in bind stack overflows) would
be nice too:). I don't know enough about ECL to write
a cfun universal-error-handler, which could handle
initialization errors at least.
Apologies if I'm being annoying or taking up to much
time, I usually like to work through these things
myself, I learn far more. I don't really know enough
about ECL's guts to get started. The CLOS solution
would never have occured to me.
The ecldev doc is useful, but not extensive enough.
Once I get through all this, I may be able to
contribute to it, if you like.
View complete sources in CVS:
stdio.lsp:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/unicorp/unicorp/data/lisp/stdio.lsp
ucl-init.lsp:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/unicorp/unicorp/data/lisp/ucl-init.lsp
lisp.cpp:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/unicorp/unicorp/plugins/lisp/lisp.cpp
Thanks,
>> Andrew (talmakion at yahoo.com.au).
http://digital.yahoo.com.au - Yahoo! Digital How To
- Get the best out of your PC!
More information about the ecl-devel
mailing list