[armedbear-devel] progress with abcl in protege

[Mark Evenson]

For Alan's goal to create an ABCL plugin for Protege–which is an Eclipse 
RCP application so this work contributes to running ABCL on Eclipse 
Equinox and OSGi in general–I've gotten to a fairly stable state for 
which I've creating the attached patches from my local snapshots.

That's "patches" because I ended up creating an Eclipse OSGi project for 
ABCL itself separate from the org.sciencecommons.protege.lisp so I could 
run Protege under Eclipse to interactively debug things.

With [r12696][1], the ABCL trunk contains the necessary support in 
Pathnames to run as an Eclipse OSGi bundle.  I have backported these 
changes to the abcl-0.20 branch, so as long as nothing else crops up, 
this release should be a good starting point.

[1]: http://trac.common-lisp.net/armedbear/changeset/12696

Since I needed to debug ABCL's load procedure in Eclipse, instead of 
using Alan's procedure I [followed the instructions for building Protege 
from Eclipse][2], and then added the abcl and 
org.sciencecommons.protege.lisp plugins.  Therefore, the patches in this 
email "convert" abcl and org.sciencecommons.protege.lisp to Eclipse OSGi 
projects.  It should be possible to build purely from Ant as Alan 
described with the additional step of invoking Ant on the 
'abcl/protege-build.xml' with the PROTEGE_HOME set to the proper value.

[2]: http://protegewiki.stanford.edu/wiki/CompileProtege4InEclipseFromSvn

To build and run Protege with the Lisp plugin from Eclipse:

1.  Follow the instructions to [building Protege from Eclipe][2]

2.  Checkout the abcl SVN trunk (later than r12696) into the workspace.

3.  Apply 'abcl-osgi.patch' to the abcl directory

4.  Apply 'org.sciencecommons.protege.lisp.patch' to the corresponding 
directory.

5.  Create the external tool builder configurations to build abcl and 
org.sciencecommons.protege.lisp by following the instructions [to "add 
your own plugin"][3].  For abcl, you will be adding "protege-build.xml".

6.  Build abcl and then org.sciencecommons.protege.lisp form the 
external tool build configuration created in step 5

7.  Run Protege by using the "Protege.From.Build" run configuration.

[3]: 
http://protegewiki.stanford.edu/wiki/CompileProtege4InEclipseFromSvn#Add_your_own_plugin

Some improvements over the previous state:

1.  ABCL loads fully, including SWANK via ASDF

2.  The J editor no longer appears.

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?

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?

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


-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: abcl-osgi.patch
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20100518/c69a25dd/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: org.sciencecommons.protege.lisp.patch
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20100518/c69a25dd/attachment-0001.ksh>