[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