[armedbear-devel] Changes committed to org.sciencecommons.lisp.protege

Alan Ruttenberg alanruttenberg at gmail.com
Fri May 21 11:26:21 UTC 2010

Hi Mark!
Thanks a lot!

I've been playing and notice a couple of things.

1) Added jscheme.jar as my jss code uses that

2) Fixed a couple of jss bootstrappy things to make it happy

3) Does load bind the readtable? I can't seem to side-effect it when loading
jss and so have to type
 (set-dispatch-macro-character #\# #\" 'read-invoke) to get it to take

4) Having some kind of classpath issues still. When I try (show-classtree "
http://purl.obolibrary.org/obo/iao.owl") (after loading my ow2 package
sucessfully), which should exercise a bunch of stuff, I get a class not
found error in the OWLAPI code.


This is code that uses jss for the jar management and I have no idea how
this interacts with the classpath management of OSGI. I guess OSGI is doing
various kinds of isolation and I want to blow all the isolation away :)

I guess I'm bound to lose somehow - I'm dynamically loading the OWLAPI jar,
for instance, but protege has it loaded? I guess I can skip loading them
with jss if I can figure out how to use the ones that protege has loaded.
They are in various plugins.

Right now the jss code looks at the classpath to figure out what jars it
should parse to get class names. I suppose by analogy I would look through
the bundles for classnames. Is there a way to programmatically determine
which bundles are available? To add them programmatically? Or do I need to
recompile the plugin to get access to a new plugin?

e.g. I see that I can get a protege editor class:
(jclass "org.protege.editor.core.FileUtils")
-> #<java class org.protege.editor.core.FileUtils {39C7}>

But jss doesn't know about it:

(find-java-class 'core.fileutils)
-> NIL
#<ERROR {5D08B1}>

If you have a pointer to your favorite doc about how the OSGI classloading
works, please let me know.


On Thu, May 20, 2010 at 3:01 PM, Mark Evenson <evenson at panix.com> wrote:

> Alan granted me commit rights, so I have updated the
> org.sciencecommons.lisp.protege plugin to a (hopefully) fully working
> version.  Instead of breaking ABCL out in a separate OSGi bundle, I included
> it in the org.sciecommons.lisp.protege bundle directly as a) I'd like to get
> ABCL out to the Protege community for use who probably couldn't care less as
> long as they have a Common Lisp plugin, and b) working through the
> threading/isolation issues doesn't look like a quick task.
> Attached to this mail is a tentative README cobbled together from Alan's
> initial emails.
> --
> "A screaming comes across the sky.  It has happened before, but there
> is nothing to compare to it now."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20100521/51e56468/attachment.html>

More information about the armedbear-devel mailing list