[Ecls-list] Embedding ECL inside a containing C++ program.

[Andrew Topp]

No prob, gave me some time to play.

My current badly hacked-together solution involves a
bunch of function pointers hooked directly from file.d
into the lisp plugin, customized lsp/top.lsp and
clos/conditions.lsp to allow the top-level to drop
through on an EOF and error handling that doesn't
cause UC to segfault or exit(). Its ugly and
inefficient, I think I'll try a whack at your
solution:).

I'm inexperienced with Lisp (you may have guessed),
beyond the basics.. I learnt most of my current skills
from hacking on the PD Abuse lisp interpreter. CLOS is
above my head, though I'm learning.

I've so far encountered a few minor problems:
 1 - liblsp.a sometimes seems to override things I've
redefined. *tpl-commands* is the one that had me
confused for ages.. I had redefined the :EOF handler
to call a new defun tpl-dropout which broke to UC via
a throw caught above the tpl loop. FEerrors calling
universal-error-handler (clos/condition.lsp)
eventually ended up calling tpl again, but
*tpl-commands* had managed to reset the :EOF handler
to quit again. Removing top.lsp from the library build
fixed it.

An eof condition is generated by my modified
readc_stream when nothing's left in the input buffer
to signal the toplevel to drop through.

 2 - FEerror() can't return :). Its not a bug, but its
something that escaped me for a long time, because
whenever I fixed the above prob ECL would chuck a
wobbly and spit out a stream of errors. Fixed it with
a change to conditions, calling break-to-system
(UC-defined cl_objectfn) which uses setjmp() to break
back into the UC glue code.

So far, my code works unsteadily, I've gotten rid of
most of the bugs and crashers. Most of the problems
are more than likely in my glue code than any problems
with the UC backend or plugin subsystems or ECL
themselves.

Just 3 other things I'd like to ask:
 - How does the GC like having objects outside its
territory? CS & UC both use the standard C mallocators
as well as C++ new/delete. cl_object references are
held only in local variables, but I don't like the
idea of the GC deciding to do a collection in the
middle of one of my functions and not realizing I've
got several objects referenced.
 - Its setjmp() safe? I don't like using it, but so
far its the only way I can break out of a FEerror and
handle a quit properly (shutting down the CS
application loop politely instead of just calling
exit()).
 - Is it possible to emulate a complete filesystem
interface like this? CS has a system called VFS which
allows a virtual file system to be composed of far
flung real directories and ZIP file archives all
mounted in a common directory tree. Being able to
access .lsp sources and data files from inside ECL
using CS's VFS is something I need to do once I
actually get ECL integrated.

Anyway, the CLOS stuff is a _lot_ cleaner than my
cobbled together trash. Going to try it out asap:).
Changing it in Lisp is better than modifying the ECL
sources themselves.

Thanks,

>> Andrew (talmakion at yahoo.com.au)

 --- Juan Jose Garcia-Ripoll <jlr at mpq.mpg.de> wrote: >
Hi Andrew,
> 
> I am sorry for the delay on the answer.
> 
> On Saturday 17 August 2002 18:21, Andrew Topp wrote:
> > The project I'm working on is Universal
> Corporation
> > (http://sourceforge.net/projects/unicorp).
> >
> > I'm attempting to embed the ECL Lisp interpreter
> > within UniCorp as its scripting engine, console
> > command interpreter and UI manager, among other
> things [...]
> 
> Great to hear it.
> 
> > I'd like the input from the graphical console to
> be
> > fed into the Lisp top-level. I'd like the output
> to be
> > displayed on the graphical console. Looking over
> the
> > guts of print.d and file.d doesn't seem to offer
> much
> > help.
> 
> What I am going to suggest is untested, but it has
> been implemented in ECL 
> since the very first versions (It belongs to Beppe).
> In ECL you can write to 
> any object which supports the methods
> 
> {&clSstream_write_char, "STREAM-WRITE-CHAR",
> CL_ORDINARY},
> {&clSstream_write_string, "STREAM-WRITE-STRING",
> CL_ORDINARY},
> {&clSstream_fresh_line, "STREAM-FRESH-LINE",
> CL_ORDINARY},
> {&clSstream_clear_output, "STREAM-CLEAR-OUTPUT",
> CL_ORDINARY},
> {&clSstream_force_output, "STREAM-FORCE-OUTPUT",
> CL_ORDINARY},
> 
> and you can read to from any object which supports
> the methods
> 
> {&clSstream_read_line, "STREAM-READ-LINE",
> CL_ORDINARY},
> {&clSstream_read_char, "STREAM-READ-CHAR",
> CL_ORDINARY},
> {&clSstream_unread_char, "STREAM-UNREAD-CHAR",
> CL_ORDINARY},
> {&clSstream_peek_char, "STREAM-PEEK-CHAR",
> CL_ORDINARY},
> {&clSstream_listen, "STREAM-LISTEN", CL_ORDINARY},
> {&clSstream_clear_input, "STREAM-CLEAR-INPUT",
> CL_ORDINARY},
> 
> See the code in print.d and read.d to find out how
> it works. It is pretty easy 
> and the important points are enclosed within pairs
> of #ifdef CLOS...#endif
> 
> As far as I recall, these objects need not be
> descendent of the class STREAM. 
> Only the methods should be there. Perhaps you can
> define these methods to 
> call your console reading/writing routines.
> 
> The other possibility which comes to my mind is that
> you define two STRING 
> streams. One for input, one for output. Then you
> should have an entry point 
> to the Lisp code, that you call whenever an event
> happens. This routine would 
> perform output by writing to the STRING stream, and
> on exit your graphical 
> toplevel could collect the output and actually
> present it.
> 
> > I've hacked up my CVS version slightly and
> > incorporated it into the UC tree (mainly
> > Makefile/configure modifications to work with the
> > Makefile-only UC build system. Still working on
> Mingw
> > combatability (sic)).
> 
> I would like to learn about these changes. Mingw was
> always on my mind as a 
> possible target, but I would not now how to go from
> the unix scripts to 
> Makefiles.
> 
> Juanjo
> 
> -- 
> Max-Planck-Institut fuer Quantenoptik
> +49/089/32905-127
> Hans-Kopfermann-Str. 1, D-85748	
> www.arrakis.es/~worm
> Garching b. Muenchen, Germany		worm at arrakis.es
> 
> 
> 
> 
>
-------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of
> that same old
> cell phone?  Get a new here for FREE!
>
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Ecls-list mailing list
> Ecls-list at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ecls-list

http://digital.yahoo.com.au - Yahoo! Digital How To
- Get the best out of your PC!