[Ecls-list] Examples of successful integration in applications.

[Andrew Topp]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Lehr wrote:
| Juan, et. al.,
|
| Is anybody actually using ECL?  What applications are being written
with it?
| Besides unicorp (http://unicorp.sourceforge.net/).  Even on that
project, ECL
| integration seems to be in a holding-pattern.
|
| Does anybody have any examples that they can share?  Since the
documentation is
| so sparse, they would be more useful if some examples of successful
integration
| of ECL into pre-existing or new applications were available.
|
| The actual ECL code does not actually use much of the documented API.
  The CLX
| and pvm code that is included is outdated.  Some of the more commonly used
| functions are not documented.  I have in mind, some functions
discussed on the
| mailing list, like cl_def_c_function_va(), e.g.,
|
|
http://sourceforge.net/mailarchive/forum.php?thread_id=2546679&forum_id=1307
|
| and others used in ECL and unicorp code.
|
| I would contribute some myself.  But I am having too much trouble
conjuring a
| reliable framework that I can my other team members can use.
|
| I have a big problem with trapping errors.  After studying the code
and using
| the various functions and CPP macroes from stacks.h, my program still
pops into
| the top-level when an error occurs.  Such errors as non-existent
packages or
| failing to load a file.  Having a critical daemon invisibly enter the
repl is
| not a good thing.  So I need to solve that, too.
|
| Has anybody solved that?  The unicorp developers have similar problems.
|

I have some ideas for error handling in UC that I'd like to try, but
Crystal Space has moved too far since I last updated UC, so that code is
completely diked out of the build for now. I have started updating it
against CS CVS, but this is incomplete.

First option, I'd try to get ECL completely in its own thread, with the
virtual terminal-io stream doing IO, ECL running as itself, and all
C++<->Lisp interaction going through abstractions and a global
interpreter mutex lock (a little like Python's multithreaded app
support). It would simplify the black box issues - ECL is very
determined in a fair number of instances to jump into an interactive
debugger, no matter what, if it can't get one, it bugs out or is left in
an inconsistent state. Most of that is because I had to force an unwind
of the ECL stacks in the middle of a debug-handling call and continue
execution of the CS app loop to display the debugging info in the next
screen update. With threads, that's not a problem (or as much of one).

Second option is to examine these black box issues (black box meaning, I
have to treat ECL as a closed system, which can't be messed with) and
try to make them happen, and fix the problems within ECL itself. Give it
a go with valgrind and friends. This is a larger job, but would mean I'd
not need to use threads (I would prefer not requiring the use of
threads). I'm not sure they're all solvable.

I don't know the current state of ECL's code, well, I'm not too sure of
the current state of UC's code :). 'Work' work, dabbling in Crystal
Space development, and another project have absorbed nearly all my time.
Many of the old issues have more than likely been addressed. I will be
giving it a go whenever I have the time and inclination, but it'll be a
few months before anything substantial comes out of it. I do have to get
the UC internals up to date against CS, fully functional, before I
rewrite spl_lisp from the ground up.

Btw, it's nice having my favourite project mentioned by other people :).
- --
|> DeSigna (Andrew Topp)

GPG Public Key:
http://search.keyserver.net:11371/pks/lookup?op=get&search=0x76E841F6

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/p4I0p7NYgnboQfYRAh78AJ4hLon+Ak18+t89aYMg77GbJMtIFgCgvHPn
5fQjrawENNUotN9TpjZS/BI=
=TfKh
-----END PGP SIGNATURE-----