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

[Mark Evenson]

On 5/21/10 1:26 PM, Alan Ruttenberg wrote:
> Hi Mark!
> Thanks a lot!

My pleasure

[…]

> 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
> effect

Both Load.loadSystemFile() and Load.loadFileFromStream() do indeed bind 
and reset the readtable, but as I understand our code, loading JSS 
should *always* (even in non-OSGi usage) thunk through 
loadFileFromStream(), so this shouldn't have different behavior.  I 
currently backporting your addition of jscheme.jar to the version that I 
can run under the Eclipse debugger to example loading from a 
PATHNAME-URL actually uses loadFileFromStream() in more detail under the 
debugger.

> 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.
>
> owlxmlparser/src/main/java/org/coode/owlapi/owlxmlparser/OWLXMLParserFactory.java
> "java.lang.NoClassDefFoundError:
> javax/xml/parsers/ParserConfigurationException
> at
> org.coode.owlapi.owlxmlparser.OWLXMLParserFactory.createParser(OWLXMLParserFactory.java:39)
> at
> uk.ac.manchester.cs.owl.owlapi.ParsableOWLOntologyFactory.getParsers(ParsableOWLOntologyFactory.java:82)
> at
> uk.ac.manchester.cs.owl.owlapi.ParsableOWLOntologyFactory.loadOWLOntology(ParsableOWLOntologyFactory.java:158)
> at
> uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:633)
> at
> uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntologyFromOntologyDocument(OWLOntologyManagerImpl.java:591)
> "
>
> 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'm failing to load your owl2 definition in a "normal" abcl/SLIME 
environment.

I do the following to setup LSW:

1.  Checkout [LSW from SVN][1] under "~/work/lsw/".

[1]: http://mumble.net:8080/svn/lsw/trunk

2.  Create symbolic links to all of your ASDF definitions

     unix$ cd ~/work/lsw && find . -name \*.asd -exec ln -s {} \;

3.  Add the following to my "~/.abclrc" to find your definitions and set 
the location of the Pellet library.

(defvar cl-user::*pellet-dir* "/Users/evenson/work/lsw/extlib/")
(require :asdf)
(pushnew '(merge-pathnames "work/lsw/" (user-homedir-pathname))
          asdf:*central-registry*)

4.  Build ABCL in "~/work/abcl/" with the following line in 
"abcl.properties" to include jscheme.jar and bsh-2.04b.jar in the 
default ABCL classpath:

     additional.jars=../lsw/lib/jscheme.jar:../lsw/lib/bsh-2.0b4.jar

5.  Startup ABCL with my own copy of SLIME in Emacs (more current than 
the SLIME you include with LSW, but I don't expect a difference).

6.  Load JSS via ASDF

     CL-USER> (require :jss)

7.  Load "owl2"

     CL-USER> (require :owl2)

This bombs with a

; Loading 
#P"/Users/evenson/.cache/common-lisp/armedbear-0.21.0-dev-fasl36-darwin-java-1.6/Users/evenson/work/lsw/owl/owl2/parse-mapping-spec.abcl" 
...
ASDF could not load OWL2 because #<END-OF-FILE {77662FDD}>.

for which the relevant part of the stack trace seems to be

[…]
  37: (SYSTEM::%READ-FROM-STRING "\"abc at langTag" T NIL 0 NIL ...)
  38: (READ-FROM-STRING "\"abc at langTag")
  39: (FLATTEN-TD (("td" . "http://www.w3.org/1999/xhtml") NIL 
"\"abc at langTag^^" (("i" . "http://www.w3.org/1999/xhtml") NIL 
"rdf:PlainLiteral")))
  40: (MAPPING-TABLE)
[…]

Any insight on how to get me loading owl2 sucessfully?


> 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.

Unfortunately, we're going to have to at least co-operate a little bit 
with OSGi.  And I still don't understand OSGi very well either, finding 
the openly available documentation very poor and not having enough time 
to go through the source code thoroughly.  The Eclipse OSGi 
implementation (Equinox) seems to have different meanings for parts of 
MANIFEST.MF.

So, anyone with a pointer to decent OSGi documentation, please chime in.

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