On Thu, Mar 11, 2010 at 11:40 AM, Mark Evenson evenson@panix.com wrote:
On Mar 10, 2010, at 9:14 PM, Alan Ruttenberg wrote:
Protege is an ontology development tool. I'm interested in using abcl to develop plugins and TIm Redmond was kind enough to have a stab at doing a first pass integration, but ran into trouble. I wonder if his report makes rings a bell?
Attached is an untested patch that takes a stab at fixing the problem of loading ABCL from an OSGi loader like that present in Protege. It's going to take me a bit of time to get to a place where I can test this, so maybe someone else with a working Protege development environment could at least tell me if it either works (yay!), looks promising (heh!), or just fails (boo!).
The patch is very hackish and preliminary, as by loading from OSGi bundles we will no longer have the property that all arguments to LOAD-SYSTEM-FILE are expressible as a Pathname. I expect that this means that *LOAD-TRUENAME* isn't going to work very well, but I don't think this is going to prevent the system from at least initializing.
I think the right approach to minimize the abstraction perturbation in the system load routines is to figure out a manner to express an arbitrary URL that Java groks via java.net.URL as a Lisp Pathname (not just a "jar:" or "file:" URLs as is the current behavior). I think I once read (maybe in the SBCL source?) a proposal where Pathname HOST was to be potentially treated as a URL. Does anyone know of a Lisp that fits URLs into Pathname that we could study as a proposal? If we want URLs to be fairly opaque to the rest of Pathname (i.e. no MERGE-PATHNAME semantics etc.), it would probably be pretty easy to push this into the HOST part of Pathname, which is currently only used for logical pathnames and UNC path support under Windows. This probably means that logical pathnames couldn't be used to refer to arbitrary URLs, but I would have to think about it a bit.
I don't know how hard it is, but at this point what do you think about having an abstract base class/interface (say, Resource) which only has a name property and from which you can extract an input stream, and have this class be extended by Pathname, JarURLResource, GenericURLResource, whatever? Some operations on pathnames really do only make sense for file pathnames, not arbitrary URLs.
Supporting OSGi (and Eclipse in general) is an important goal for ABCL, so we (I?) will try to diligently to get quickly get support for loading the ABCL base system from an OSGi loader.
I agree on the importance of the goal, and I'm willing to help.
Bye, Alessio