[armedbear-devel] progress with abcl in protege

[Alessio Stalla]

On Tue, May 18, 2010 at 8:09 PM, Mark Evenson <evenson at panix.com> wrote:
>[snip]

Hello Mark,

very nice work! The more environments ABCL can run in, the better.

> Some problems:
>
> 1.  The REPL thread is being started in the GUI constructor at the moment.
>  The general OSGi contract is that a bundle must only start threads with the
> Activator.start() method, and all threads must be stopped when
> Activator.stop() returns.
>
> 2.  I'd actually like to have the abcl container start()/stop() relevant
> OSGi threads so that the bundling is useful for other containers.  To this
> end, I am imagining a simple message server for ABCL that takes messages as
> they come in, and ships them off to REPL threads as necessary, returning the
> results.  There would be an optional argument to such messages that would
> specify a thread to execute on.  Under this proposal, other OSGi bundles
> would only be able to "communicate" with EVAL.  Is this too restrictive?  It
> probably is if only Strings are going back and forth, but maybe if we
> allowed LispObjects that were somehow "deep copied" back and forth,
> providing access to the useful routines.
>
> 3.  There are parts of ABCL that call System.exit() (at least one is present
> in Autoload.load()), which is not going to work well.  I plan to replace
> this somehow, perhaps by waiting for all tasks to finish, then signaling
> that the singleton Interpreter is no longer valid by disposing of the
> reference?

I'm afraid that disposing the Interpreter and starting a new one is
not the same as rebooting ABCL. Most of the state is reachable from
static fields; the list of packages is static, for example.
That said, System.exit() should really be removed in favor of an
Interpreter.quit() or something like that, which will call
System.exit() in the default case, but may be overridden in order to
do other things in certain environments.
If you want to have multiple instances of ABCL running in parallel, or
even simply to restart it without restarting the JVM, you have to run
each instance in a dedicated classloader. If, as I have understood,
you intend to use ABCL as a service provider accessed through some
kind of "remoting" layer (even when on the same machine as the other
modules), then it's perfectly fine to have ABCL locked in its own
private world, since all communication with it will be through message
passing - *if* the type of those messages is a class which is shared
among all the ABCL instances, i.e. loaded by a shared parent
classloader, i.e. not LispObject. I'm talking of the actual Class of
the message here - a byte[] containing a serialized LispObject would
be fine.

> 4.  I think it would be useful to move the JPanel code into base ABCL for a
> basic interactive REPL.  This would facilitate embedding ABCL in many tools
> where the core functionality is maintained in central location.  This would
> allow Netbeans, for example, to easily include a GUI to the ABCL REPL.  I
> would not favor this being a full IDE effort at all, but would provide the
> base GUI element that others could customize.  At the same time, maybe we
> should consider removing unused parts of the
> org.armedbear.lisp.java.{awt,swing}.* classes?  Is this something used by J
> that could profitably moved over?

What is the JPanel code? As part of my "Snow" GUI library, I have a
basic REPL, debugger and inspector available. The REPL is pure Java
and does not depend on anything but Swing/AWT, so it could be included
in ABCL as-is. There's room for improvement, but it's already usable
as it is if you don't expect fancy things from it. The Lisp interface
to the REPL, the debugger and the inspector instead are written in
Lisp and depend on the Snow DSL. I know Alan successfully ran the Snow
REPL with Protege (after some bugfixing).

> 5.  'build.xml' needs to be OSGi build-aware in a better manner.  The
> current patchset assumes that the user will always be doing an OSGi build
> when it is invoked.
>
> Comments, feedback, et. al. solicited,
> Mark

Cheers,
Alessio