On Wed, 2010-03-10 at 22:19 +0100, Alessio Stalla wrote:

On Wed, Mar 10, 2010 at 9:14 PM, Alan Ruttenberg <alanruttenberg@gmail.com> 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?

Surely the function/class loading code has changed quite a lot since 0.18.1, so I'd advise you to try with abcl from trunk (or wait till 0.19 is released). Maybe the problem won't go away, but it's worth trying - at least we'll get a stack trace that's more meaningful wrt. the current state of affairs.

I included the error on trunk below. The url returned by the class loader has the wrong format. For some reason this url is being parsed in the Pathname class and it gets into trouble. I was thinking that it might be possible for me to make a minimal change to the code somehow to fix this but I have not yet figured out exactly how to make this change. -Timothy java.lang.Error at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1561) at org.armedbear.lisp.Primitive.execute(Primitive.java:108) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.Lisp.error(Lisp.java:357) at org.armedbear.lisp.Pathname.<init>(Pathname.java:184) at org.armedbear.lisp.Site.init(Site.java:59) at org.armedbear.lisp.Site.getLispHome(Site.java:72) at org.armedbear.lisp.Site.<clinit>(Site.java:82) at org.armedbear.lisp.Load.loadSystemFile(Load.java:255) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:158) at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:69) at org.sciencecommons.protege.lisp.LispContext.<init>(LispContext.java:14) at org.sciencecommons.protege.lisp.LispContext.getInstance(LispContext.java:20) at org.sciencecommons.protege.lisp.Activator.start(Activator.java:13) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java:1622) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:902) at org.protege.editor.core.BundleManager.startPlugins(BundleManager.java:110) at org.protege.editor.core.BundleManager.loadPlugins(BundleManager.java:41) at org.protege.editor.core.ProtegeApplication.loadPlugins(ProtegeApplication.java:277) at org.protege.editor.core.ProtegeApplication.initApplication(ProtegeApplication.java:171) at org.protege.editor.core.ProtegeApplication.start(ProtegeApplication.java:113) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java:1622) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077) at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) at java.lang.Thread.run(Thread.java:619) ERROR placeholder called with arguments: #<ERROR {1876E5D}> Unsupported URL: 'bundle://10.0:2/org/armedbear/lisp/boot.lisp'

Alessio

...

-Alan

---------- Forwarded message ---------- From: Timothy Redmond <tredmond@stanford.edu> Date: Wed, Mar 10, 2010 at 2:12 PM Subject: [POSSIBLE VIRUS:###] Re: further on common lisp integration To: Alan Ruttenberg <alanruttenberg@gmail.com>

There is something of a difficulty in using this library. It is doing some funky stuff with urls and class loaders and this doesn't work with Protege. Probably could be made to work by making some changes to the abcl sources. In particular it seems to detect that it is loading through the class loader if the prefix begins with jar which is not a correct assumption in general.

But here is a start if you want to debug a bit more.

-Timothy

java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:114) at java.util.zip.ZipFile.<init>(ZipFile.java:75) at org.armedbear.lisp.ZipCache.getZip(ZipCache.java:54) at org.armedbear.lisp.Lisp.readFunctionBytes(Lisp.java:1305) at org.armedbear.lisp.AutoloadedFunctionProxy$2.execute(AutoloadedFunctionProxy.java:307) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.processTagBody(Lisp.java:767) at org.armedbear.lisp.dotimes.execute(dotimes.java:105) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Load.faslLoadStream(Load.java:628) at org.armedbear.lisp.Load.access$100(Load.java:70) at org.armedbear.lisp.Load$1.execute(Load.java:485) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:501) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Load.loadStream(Load.java:593) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:556) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:499) at org.armedbear.lisp.Load.loadSystemFile(Load.java:415) at org.armedbear.lisp.Load$4.execute(Load.java:774) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Load.loadStream(Load.java:593) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:556) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:499) at org.armedbear.lisp.Load.loadSystemFile(Load.java:415) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:158) at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:69) at org.sciencecommons.protege.lisp.LispContext.<init>(LispContext.java:14) at org.sciencecommons.protege.lisp.LispContext.getInstance(LispContext.java:20) at org.sciencecommons.protege.lisp.Activator.start(Activator.java:13) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java:1622) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:902) at org.protege.editor.core.BundleManager.startPlugins(BundleManager.java:110) at org.protege.editor.core.BundleManager.loadPlugins(BundleManager.java:41) at org.protege.editor.core.ProtegeApplication.loadPlugins(ProtegeApplication.java:277) at org.protege.editor.core.ProtegeApplication.initApplication(ProtegeApplication.java:171) at org.protege.editor.core.ProtegeApplication.start(ProtegeApplication.java:113) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java:1622) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077) at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) at java.lang.Thread.run(Thread.java:619) java.lang.Error at org.armedbear.lisp.Primitives$70.execute(Primitives.java:1462) at org.armedbear.lisp.Primitive.execute(Primitive.java:108) at org.armedbear.lisp.Symbol.execute(Symbol.java:770) at org.armedbear.lisp.Lisp.error(Lisp.java:354) at org.armedbear.lisp.Lisp.readFunctionBytes(Lisp.java:1329) at org.armedbear.lisp.AutoloadedFunctionProxy$2.execute(AutoloadedFunctionProxy.java:307) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.processTagBody(Lisp.java:767) at org.armedbear.lisp.dotimes.execute(dotimes.java:105) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Load.faslLoadStream(Load.java:628) at org.armedbear.lisp.Load.access$100(Load.java:70) at org.armedbear.lisp.Load$1.execute(Load.java:485) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:501) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Load.loadStream(Load.java:593) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:556) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:499) at org.armedbear.lisp.Load.loadSystemFile(Load.java:415) at org.armedbear.lisp.Load$4.execute(Load.java:774) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Load.loadStream(Load.java:593) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:556) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:499) at org.armedbear.lisp.Load.loadSystemFile(Load.java:415) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:158) at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:69) at org.sciencecommons.protege.lisp.LispContext.<init>(LispContext.java:14) at org.sciencecommons.protege.lisp.LispContext.getInstance(LispContext.java:20) at org.sciencecommons.protege.lisp.Activator.start(Activator.java:13) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java:1622) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:902) at org.protege.editor.core.BundleManager.startPlugins(BundleManager.java:110) at org.protege.editor.core.BundleManager.loadPlugins(BundleManager.java:41) at org.protege.editor.core.ProtegeApplication.loadPlugins(ProtegeApplication.java:277) at org.protege.editor.core.ProtegeApplication.initApplication(ProtegeApplication.java:171) at org.protege.editor.core.ProtegeApplication.start(ProtegeApplication.java:113) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java:1622) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077) at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) at java.lang.Thread.run(Thread.java:619)

_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

On Wed, Mar 10, 2010 at 5:29 PM, Alessio Stalla <alessiostalla@gmail.com> wrote:

On Wed, Mar 10, 2010 at 11:06 PM, Timothy Redmond <tredmond@stanford.edu> wrote:

...

On Wed, 2010-03-10 at 22:19 +0100, Alessio Stalla wrote:

...

On Wed, Mar 10, 2010 at 9:14 PM, Alan Ruttenberg <alanruttenberg@gmail.com> 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?

Surely the function/class loading code has changed quite a lot since 0.18.1, so I'd advise you to try with abcl from trunk (or wait till 0.19 is released). Maybe the problem won't go away, but it's worth trying - at least we'll get a stack trace that's more meaningful wrt. the current state of affairs.

I included the error on trunk below.  The url returned by the class loader has the wrong format.  For some reason this url is being parsed in the Pathname class and it gets into trouble.  I was thinking that it might be possible for me to make a minimal change to the code somehow to fix this but I have not yet figured out exactly how to make this change.

Pathname represents a path to a file or, since recently, an entry in a Jar file, but it's not able to represent an arbitrary URL.

I know little about OSGi, but probably it requires some special handling if one wants to explicitly load resources like ABCL does.

As an attempt which I really doubt will work, you can try this: since what is failing is getLispHome() in class Site, and that can also use the "abcl.home" system property, you could try to set that property to "jar:file:/whatever/abcl.jar!/org/armedbear/lisp/" before loading ABCL and cross your fingers. You'll probably get past the current failing point but some other things will probably fail. Even if it works, it's not a good solution at all; still, it might serve as a temporary hack until we figure out how to behave in a OSGi context.

A bit better is to not hardcode the location: (defvar *abcl-jar* (make-pathname :device (pathname-device (java::jcall "toString" (java::jcall "getResource" (java::jclass "org.armedbear.lisp.Main") "/org/armedbear/lisp/Main.class"))))) Can we put that in system.lisp? -Alan

Alessio

...

-Timothy

java.lang.Error        at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1561)        at org.armedbear.lisp.Primitive.execute(Primitive.java:108)        at org.armedbear.lisp.Symbol.execute(Symbol.java:775)        at org.armedbear.lisp.Lisp.error(Lisp.java:357)        at org.armedbear.lisp.Pathname.<init>(Pathname.java:184)        at org.armedbear.lisp.Site.init(Site.java:59)        at org.armedbear.lisp.Site.getLispHome(Site.java:72)        at org.armedbear.lisp.Site.<clinit>(Site.java:82)        at org.armedbear.lisp.Load.loadSystemFile(Load.java:255)        at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:158)        at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:69)        at org.sciencecommons.protege.lisp.LispContext.<init>(LispContext.java:14)        at org.sciencecommons.protege.lisp.LispContext.getInstance(LispContext.java:20)        at org.sciencecommons.protege.lisp.Activator.start(Activator.java:13)        at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639)        at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700)        at org.apache.felix.framework.Felix.startBundle(Felix.java:1622)        at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915)        at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:902)        at org.protege.editor.core.BundleManager.startPlugins(BundleManager.java:110)        at org.protege.editor.core.BundleManager.loadPlugins(BundleManager.java:41)        at org.protege.editor.core.ProtegeApplication.loadPlugins(ProtegeApplication.java:277)        at org.protege.editor.core.ProtegeApplication.initApplication(ProtegeApplication.java:171)        at org.protege.editor.core.ProtegeApplication.start(ProtegeApplication.java:113)        at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639)        at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700)        at org.apache.felix.framework.Felix.startBundle(Felix.java:1622)        at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077)        at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)        at java.lang.Thread.run(Thread.java:619) ERROR placeholder called with arguments: #<ERROR {1876E5D}> Unsupported URL: 'bundle://10.0:2/org/armedbear/lisp/boot.lisp'

...

Alessio

...

-Alan

---------- Forwarded message ---------- From: Timothy Redmond <tredmond@stanford.edu> Date: Wed, Mar 10, 2010 at 2:12 PM Subject: [POSSIBLE VIRUS:###] Re: further on common lisp integration To: Alan Ruttenberg <alanruttenberg@gmail.com>

There is something of a difficulty in using this library.  It is doing some funky stuff with urls and class loaders and this doesn't work with Protege.  Probably could be made to work by making some changes to the abcl sources.  In particular it seems to detect that it is loading through the class loader if the prefix begins with jar which is not a correct assumption in general.

But here is a start if you want to debug a bit more.

-Timothy

java.util.zip.ZipException: error in opening zip file        at java.util.zip.ZipFile.open(Native Method)        at java.util.zip.ZipFile.<init>(ZipFile.java:114)        at java.util.zip.ZipFile.<init>(ZipFile.java:75)        at org.armedbear.lisp.ZipCache.getZip(ZipCache.java:54)        at org.armedbear.lisp.Lisp.readFunctionBytes(Lisp.java:1305)        at org.armedbear.lisp.AutoloadedFunctionProxy$2.execute(AutoloadedFunctionProxy.java:307)        at org.armedbear.lisp.LispThread.execute(LispThread.java:562)        at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494)        at org.armedbear.lisp.Lisp.eval(Lisp.java:459)        at org.armedbear.lisp.Lisp.processTagBody(Lisp.java:767)        at org.armedbear.lisp.dotimes.execute(dotimes.java:105)        at org.armedbear.lisp.Lisp.eval(Lisp.java:449)        at org.armedbear.lisp.Load.faslLoadStream(Load.java:628)        at org.armedbear.lisp.Load.access$100(Load.java:70)        at org.armedbear.lisp.Load$1.execute(Load.java:485)        at org.armedbear.lisp.LispThread.execute(LispThread.java:579)        at org.armedbear.lisp.Lisp.evalCall(Lisp.java:501)        at org.armedbear.lisp.Lisp.eval(Lisp.java:459)        at org.armedbear.lisp.Load.loadStream(Load.java:593)        at org.armedbear.lisp.Load.loadFileFromStream(Load.java:556)        at org.armedbear.lisp.Load.loadFileFromStream(Load.java:499)        at org.armedbear.lisp.Load.loadSystemFile(Load.java:415)        at org.armedbear.lisp.Load$4.execute(Load.java:774)        at org.armedbear.lisp.LispThread.execute(LispThread.java:562)        at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494)        at org.armedbear.lisp.Lisp.eval(Lisp.java:459)        at org.armedbear.lisp.Load.loadStream(Load.java:593)        at org.armedbear.lisp.Load.loadFileFromStream(Load.java:556)        at org.armedbear.lisp.Load.loadFileFromStream(Load.java:499)        at org.armedbear.lisp.Load.loadSystemFile(Load.java:415)        at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:158)        at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:69)        at org.sciencecommons.protege.lisp.LispContext.<init>(LispContext.java:14)        at org.sciencecommons.protege.lisp.LispContext.getInstance(LispContext.java:20)        at org.sciencecommons.protege.lisp.Activator.start(Activator.java:13)        at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639)        at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700)        at org.apache.felix.framework.Felix.startBundle(Felix.java:1622)        at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915)        at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:902)        at org.protege.editor.core.BundleManager.startPlugins(BundleManager.java:110)        at org.protege.editor.core.BundleManager.loadPlugins(BundleManager.java:41)        at org.protege.editor.core.ProtegeApplication.loadPlugins(ProtegeApplication.java:277)        at org.protege.editor.core.ProtegeApplication.initApplication(ProtegeApplication.java:171)        at org.protege.editor.core.ProtegeApplication.start(ProtegeApplication.java:113)        at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639)        at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700)        at org.apache.felix.framework.Felix.startBundle(Felix.java:1622)        at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077)        at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)        at java.lang.Thread.run(Thread.java:619) java.lang.Error        at org.armedbear.lisp.Primitives$70.execute(Primitives.java:1462)        at org.armedbear.lisp.Primitive.execute(Primitive.java:108)        at org.armedbear.lisp.Symbol.execute(Symbol.java:770)        at org.armedbear.lisp.Lisp.error(Lisp.java:354)        at org.armedbear.lisp.Lisp.readFunctionBytes(Lisp.java:1329)        at org.armedbear.lisp.AutoloadedFunctionProxy$2.execute(AutoloadedFunctionProxy.java:307)        at org.armedbear.lisp.LispThread.execute(LispThread.java:562)        at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494)        at org.armedbear.lisp.Lisp.eval(Lisp.java:459)        at org.armedbear.lisp.Lisp.processTagBody(Lisp.java:767)        at org.armedbear.lisp.dotimes.execute(dotimes.java:105)        at org.armedbear.lisp.Lisp.eval(Lisp.java:449)        at org.armedbear.lisp.Load.faslLoadStream(Load.java:628)        at org.armedbear.lisp.Load.access$100(Load.java:70)        at org.armedbear.lisp.Load$1.execute(Load.java:485)        at org.armedbear.lisp.LispThread.execute(LispThread.java:579)        at org.armedbear.lisp.Lisp.evalCall(Lisp.java:501)        at org.armedbear.lisp.Lisp.eval(Lisp.java:459)        at org.armedbear.lisp.Load.loadStream(Load.java:593)        at org.armedbear.lisp.Load.loadFileFromStream(Load.java:556)        at org.armedbear.lisp.Load.loadFileFromStream(Load.java:499)        at org.armedbear.lisp.Load.loadSystemFile(Load.java:415)        at org.armedbear.lisp.Load$4.execute(Load.java:774)        at org.armedbear.lisp.LispThread.execute(LispThread.java:562)        at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494)        at org.armedbear.lisp.Lisp.eval(Lisp.java:459)        at org.armedbear.lisp.Load.loadStream(Load.java:593)        at org.armedbear.lisp.Load.loadFileFromStream(Load.java:556)        at org.armedbear.lisp.Load.loadFileFromStream(Load.java:499)        at org.armedbear.lisp.Load.loadSystemFile(Load.java:415)        at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:158)        at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:69)        at org.sciencecommons.protege.lisp.LispContext.<init>(LispContext.java:14)        at org.sciencecommons.protege.lisp.LispContext.getInstance(LispContext.java:20)        at org.sciencecommons.protege.lisp.Activator.start(Activator.java:13)        at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639)        at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700)        at org.apache.felix.framework.Felix.startBundle(Felix.java:1622)        at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915)        at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:902)        at org.protege.editor.core.BundleManager.startPlugins(BundleManager.java:110)        at org.protege.editor.core.BundleManager.loadPlugins(BundleManager.java:41)        at org.protege.editor.core.ProtegeApplication.loadPlugins(ProtegeApplication.java:277)        at org.protege.editor.core.ProtegeApplication.initApplication(ProtegeApplication.java:171)        at org.protege.editor.core.ProtegeApplication.start(ProtegeApplication.java:113)        at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639)        at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700)        at org.apache.felix.framework.Felix.startBundle(Felix.java:1622)        at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077)        at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)        at java.lang.Thread.run(Thread.java:619)

_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

Actually, Pathnames of the form "jar:URL!/ENTRY" can now use an arbitrary URL as long as the java.net.URL constructor returns an instance we can use to get a URLConnection. There is a rather elaborate plugin mechanism to register additional protocols, which I'm guessing OSGi implements for bundle: but somehow returns something which behaves slightly different from the built-in file: and http: protocols that I tested with. Tersely written from my iPod On Mar 10, 2010, at 11:29 PM, Alessio Stalla <alessiostalla@gmail.com> wrote:

On Wed, Mar 10, 2010 at 11:06 PM, Timothy Redmond <tredmond@stanford.edu

...

wrote: On Wed, 2010-03-10 at 22:19 +0100, Alessio Stalla wrote:

...

On Wed, Mar 10, 2010 at 9:14 PM, Alan Ruttenberg <alanruttenberg@gmail.com> 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?

Surely the function/class loading code has changed quite a lot since 0.18.1, so I'd advise you to try with abcl from trunk (or wait till 0.19 is released). Maybe the problem won't go away, but it's worth trying - at least we'll get a stack trace that's more meaningful wrt. the current state of affairs.

I included the error on trunk below. The url returned by the class loader has the wrong format. For some reason this url is being parsed in the Pathname class and it gets into trouble. I was thinking that it might be possible for me to make a minimal change to the code somehow to fix this but I have not yet figured out exactly how to make this change.

Pathname represents a path to a file or, since recently, an entry in a Jar file, but it's not able to represent an arbitrary URL.

I know little about OSGi, but probably it requires some special handling if one wants to explicitly load resources like ABCL does.

As an attempt which I really doubt will work, you can try this: since what is failing is getLispHome() in class Site, and that can also use the "abcl.home" system property, you could try to set that property to "jar:file:/whatever/abcl.jar!/org/armedbear/lisp/" before loading ABCL and cross your fingers. You'll probably get past the current failing point but some other things will probably fail. Even if it works, it's not a good solution at all; still, it might serve as a temporary hack until we figure out how to behave in a OSGi context.

Alessio

...

-Timothy

java.lang.Error at org.armedbear.lisp.Primitives$pf_error.execute (Primitives.java:1561) at org.armedbear.lisp.Primitive.execute(Primitive.java:108) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.Lisp.error(Lisp.java:357) at org.armedbear.lisp.Pathname.<init>(Pathname.java:184) at org.armedbear.lisp.Site.init(Site.java:59) at org.armedbear.lisp.Site.getLispHome(Site.java:72) at org.armedbear.lisp.Site.<clinit>(Site.java:82) at org.armedbear.lisp.Load.loadSystemFile(Load.java:255) at org.armedbear.lisp.Interpreter.initializeLisp (Interpreter.java:158) at org.armedbear.lisp.Interpreter.createInstance (Interpreter.java:69) at org.sciencecommons.protege.lisp.LispContext.<init> (LispContext.java:14) at org.sciencecommons.protege.lisp.LispContext.getInstance (LispContext.java:20) at org.sciencecommons.protege.lisp.Activator.start (Activator.java:13) at org.apache.felix.framework.util.SecureAction.startActivator (SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle (Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java: 1622) at org.apache.felix.framework.BundleImpl.start (BundleImpl.java:915) at org.apache.felix.framework.BundleImpl.start (BundleImpl.java:902) at org.protege.editor.core.BundleManager.startPlugins (BundleManager.java:110) at org.protege.editor.core.BundleManager.loadPlugins (BundleManager.java:41) at org.protege.editor.core.ProtegeApplication.loadPlugins (ProtegeApplication.java:277) at org.protege.editor.core.ProtegeApplication.initApplication (ProtegeApplication.java:171) at org.protege.editor.core.ProtegeApplication.start (ProtegeApplication.java:113) at org.apache.felix.framework.util.SecureAction.startActivator (SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle (Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java: 1622) at org.apache.felix.framework.Felix.setActiveStartLevel (Felix.java:1077) at org.apache.felix.framework.StartLevelImpl.run (StartLevelImpl.java:264) at java.lang.Thread.run(Thread.java:619) ERROR placeholder called with arguments: #<ERROR {1876E5D}> Unsupported URL: 'bundle://10.0:2/org/armedbear/lisp/boot.lisp'

...

Alessio

...

-Alan

---------- Forwarded message ---------- From: Timothy Redmond <tredmond@stanford.edu> Date: Wed, Mar 10, 2010 at 2:12 PM Subject: [POSSIBLE VIRUS:###] Re: further on common lisp integration To: Alan Ruttenberg <alanruttenberg@gmail.com>

There is something of a difficulty in using this library. It is doing some funky stuff with urls and class loaders and this doesn't work with Protege. Probably could be made to work by making some changes to the abcl sources. In particular it seems to detect that it is loading through the class loader if the prefix begins with jar which is not a correct assumption in general.

But here is a start if you want to debug a bit more.

-Timothy

java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:114) at java.util.zip.ZipFile.<init>(ZipFile.java:75) at org.armedbear.lisp.ZipCache.getZip(ZipCache.java:54) at org.armedbear.lisp.Lisp.readFunctionBytes(Lisp.java:1305) at org.armedbear.lisp.AutoloadedFunctionProxy$2.execute (AutoloadedFunctionProxy.java:307) at org.armedbear.lisp.LispThread.execute(LispThread.java: 562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.processTagBody(Lisp.java:767) at org.armedbear.lisp.dotimes.execute(dotimes.java:105) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Load.faslLoadStream(Load.java:628) at org.armedbear.lisp.Load.access$100(Load.java:70) at org.armedbear.lisp.Load$1.execute(Load.java:485) at org.armedbear.lisp.LispThread.execute(LispThread.java: 579) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:501) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Load.loadStream(Load.java:593) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:556) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:499) at org.armedbear.lisp.Load.loadSystemFile(Load.java:415) at org.armedbear.lisp.Load$4.execute(Load.java:774) at org.armedbear.lisp.LispThread.execute(LispThread.java: 562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Load.loadStream(Load.java:593) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:556) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:499) at org.armedbear.lisp.Load.loadSystemFile(Load.java:415) at org.armedbear.lisp.Interpreter.initializeLisp (Interpreter.java:158) at org.armedbear.lisp.Interpreter.createInstance (Interpreter.java:69) at org.sciencecommons.protege.lisp.LispContext.<init> (LispContext.java:14) at org.sciencecommons.protege.lisp.LispContext.getInstance (LispContext.java:20) at org.sciencecommons.protege.lisp.Activator.start (Activator.java:13) at org.apache.felix.framework.util.SecureAction.startActivator (SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle (Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java: 1622) at org.apache.felix.framework.BundleImpl.start (BundleImpl.java:915) at org.apache.felix.framework.BundleImpl.start (BundleImpl.java:902) at org.protege.editor.core.BundleManager.startPlugins (BundleManager.java:110) at org.protege.editor.core.BundleManager.loadPlugins (BundleManager.java:41) at org.protege.editor.core.ProtegeApplication.loadPlugins (ProtegeApplication.java:277) at org.protege.editor.core.ProtegeApplication.initApplication (ProtegeApplication.java:171) at org.protege.editor.core.ProtegeApplication.start (ProtegeApplication.java:113) at org.apache.felix.framework.util.SecureAction.startActivator (SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle (Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java: 1622) at org.apache.felix.framework.Felix.setActiveStartLevel (Felix.java:1077) at org.apache.felix.framework.StartLevelImpl.run (StartLevelImpl.java:264) at java.lang.Thread.run(Thread.java:619) java.lang.Error at org.armedbear.lisp.Primitives$70.execute (Primitives.java:1462) at org.armedbear.lisp.Primitive.execute(Primitive.java:108) at org.armedbear.lisp.Symbol.execute(Symbol.java:770) at org.armedbear.lisp.Lisp.error(Lisp.java:354) at org.armedbear.lisp.Lisp.readFunctionBytes(Lisp.java:1329) at org.armedbear.lisp.AutoloadedFunctionProxy$2.execute (AutoloadedFunctionProxy.java:307) at org.armedbear.lisp.LispThread.execute(LispThread.java: 562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.processTagBody(Lisp.java:767) at org.armedbear.lisp.dotimes.execute(dotimes.java:105) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Load.faslLoadStream(Load.java:628) at org.armedbear.lisp.Load.access$100(Load.java:70) at org.armedbear.lisp.Load$1.execute(Load.java:485) at org.armedbear.lisp.LispThread.execute(LispThread.java: 579) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:501) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Load.loadStream(Load.java:593) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:556) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:499) at org.armedbear.lisp.Load.loadSystemFile(Load.java:415) at org.armedbear.lisp.Load$4.execute(Load.java:774) at org.armedbear.lisp.LispThread.execute(LispThread.java: 562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Load.loadStream(Load.java:593) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:556) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:499) at org.armedbear.lisp.Load.loadSystemFile(Load.java:415) at org.armedbear.lisp.Interpreter.initializeLisp (Interpreter.java:158) at org.armedbear.lisp.Interpreter.createInstance (Interpreter.java:69) at org.sciencecommons.protege.lisp.LispContext.<init> (LispContext.java:14) at org.sciencecommons.protege.lisp.LispContext.getInstance (LispContext.java:20) at org.sciencecommons.protege.lisp.Activator.start (Activator.java:13) at org.apache.felix.framework.util.SecureAction.startActivator (SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle (Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java: 1622) at org.apache.felix.framework.BundleImpl.start (BundleImpl.java:915) at org.apache.felix.framework.BundleImpl.start (BundleImpl.java:902) at org.protege.editor.core.BundleManager.startPlugins (BundleManager.java:110) at org.protege.editor.core.BundleManager.loadPlugins (BundleManager.java:41) at org.protege.editor.core.ProtegeApplication.loadPlugins (ProtegeApplication.java:277) at org.protege.editor.core.ProtegeApplication.initApplication (ProtegeApplication.java:171) at org.protege.editor.core.ProtegeApplication.start (ProtegeApplication.java:113) at org.apache.felix.framework.util.SecureAction.startActivator (SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle (Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java: 1622) at org.apache.felix.framework.Felix.setActiveStartLevel (Felix.java:1077) at org.apache.felix.framework.StartLevelImpl.run (StartLevelImpl.java:264) at java.lang.Thread.run(Thread.java:619)

_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

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

On Thu, Mar 11, 2010 at 2:13 PM, Mark Evenson <evenson@panix.com> wrote:

On Mar 11, 2010, at 12:08 PM, Alessio Stalla wrote:

[…]

...

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.

I'm definitely not wedded to cramming everything into Lisp pathname, so would welcome the exploration of  other implementation options here.  The jar Pathname work took a lot more effort than I originally thought, so I want to do as much exploring of reworking things without coding.

So, I take it you propose a Java-side abstraction here for Resource. How would this work for the Lisp user who wants to specify an option to LOAD?  Would we create CLOS abstractions for LOAD that specialize on the type?

Well LOAD is not a problem per se, as it basically only needs to obtain a stream from the resource, and that could be implemented in Java for the various Resource subclasses via a getStream method. What is more problematic, or at least requires some thought, is how to represent resources in Lisp, and if and how to allow the user to create and manipulate them from Lisp. You have surely more insight into the problem than I have; I proposed this abstraction because it seems useful and clean design to me, but I don't have very precise knowledge of the issue. Alessio

C:\development\abcl-trunk>ant Buildfile: build.xml abcl.clean.maybe: [echo] Cleaning all intermediate compilation artifacts. [echo] Setting 'abcl.build.incremental' enables incremental compilation. abcl.clean: [delete] Deleting directory C:\development\abcl-trunk\build abcl.copy.lisp: [copy] Copying 4 files to C:\development\abcl-trunk\build\classes abcl.init: [echo] java.version: 1.6.0_14 [echo] Implementation-Source: ${version.src} abcl.java.warning: abcl.jsr-223.notice: abcl.compile.java: [javac] Compiling 278 source files to C:\development\abcl-trunk\build\classes [javac] Note: C:\development\abcl-trunk\src\org\armedbear\lisp\AutoloadedFunctionProxy.java uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. abcl.fasls.uptodate: abcl.compile.lisp: [echo] [echo] Compiling Lisp system [echo] from C:\development\abcl-trunk\src\org\armedbear\lisp [echo] to C:/development/abcl-trunk/build/classes/org/armedbear/lisp [java] Armed Bear Common Lisp 0.20.0-dev (built Thu Mar 11 2010 14:27:39 PST) [java] Java 1.6.0_14 Sun Microsystems Inc. [java] Java HotSpot(TM) 64-Bit Server VM [java] Low-level initialization completed in 0.469 seconds. [java] java.lang.Error [java] at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1561) [java] at org.armedbear.lisp.Primitive.execute(Primitive.java:108) [java] at org.armedbear.lisp.Symbol.execute(Symbol.java:775) [java] at org.armedbear.lisp.Lisp.error(Lisp.java:357) [java] at org.armedbear.lisp.Load.loadSystemFile(Load.java:275) [java] at org.armedbear.lisp.Load$load_system_file.execute(Load.java:666) [java] at org.armedbear.lisp.LispThread.execute(LispThread.java:562) [java] at org.armedbear.lisp.Lisp.evalCall(Lisp.java:497) [java] at org.armedbear.lisp.Lisp.eval(Lisp.java:462) [java] at org.armedbear.lisp.Load.loadStream(Load.java:540) [java] at org.armedbear.lisp.Load.loadFileFromStream(Load.java:503) [java] at org.armedbear.lisp.Load.loadFileFromStream(Load.java:400) [java] at org.armedbear.lisp.Load.loadSystemFile(Load.java:325) [java] at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:158) [java] at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:93) [java] at org.armedbear.lisp.Main$1.run(Main.java:48) [java] at java.lang.Thread.run(Thread.java:619) [java] ERROR placeholder called with arguments: [java] #<ERROR {2C79A2E7}> [java] Failed to find loadable system file 'autoloads' in boot classpath. BUILD FAILED C:\development\abcl-trunk\build.xml:238: Java returned: 1 Total time: 10 seconds C:\development\abcl-trunk> On Thu, Mar 11, 2010 at 8:02 AM, Mark Evenson <evenson@panix.com> wrote:

On Mar 11, 2010, at 11:40 AM, Mark Evenson wrote:

[…]

...

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

Upon testing the patch turned out to be somewhere between "heh!" and "boo!", but ofter a bit of wrestling with Eclipse  I have [committed to ABCL trunk a patchset that allows ABCL to load in an OSGi context][r12524].  Unfortunately, the patch only works for Lisp that is loaded by LOAD-SYSTEM-FILE, so I fear that unless one can address loadable code via "jar:URL" type Pathnames this isn't going to be terribly useful as an extension mechanism.  But we're better than yesterday, huh?

[r12524]: http://code.google.com/p/abcl-dynamic-install/source/detail?r=a3cb85eb8ed09c...

--

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

_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel