On Tue, May 18, 2010 at 8:09 PM, Mark Evenson evenson@panix.com wrote:
[snip]
Hello Mark,
very nice work! The more environments ABCL can run in, the better.
Some problems:
- 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.
- 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.
- 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.
- 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).
- '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