[armedbear-devel] Does ABCL reload abcl.jar after it starts up?
I have a quick (I hope) question. Does ABCL reload abcl.jar after it starts up? Or do something else unusual with the jar once it's running? Context: I'm exploring using ABCL as an add-on to NetLogo, an agent-based modeling environment. (It might be more correct to say that I'm using NetLogo as an add-on to ABCL, since the primary code is in Lisp.) With the add-on method, NetLogo "extensions", one usually doesn't have to tell NetLogo where additional jars such as abcl.jar can be found. As long as they're in the extension's own directory, NetLogo will find the extra jars. This is apparently due to a little bit of voodoo that NetLogo engages in. However, in the case of my ABCL extension, NetLogo will load the extension, but then generate an error when I invoke ABCL via Interpreter.evaluate(). The problem is avoided if specify abcl.jar in the classpath explicitly, either on the command line (undesirable for NetLogo), or by adding abcl.jar to the classpath in Java (which works fine--so that's what I'm doing). Just curious about what ABCL is doing--thanks. (The ABCL NetLogo extension is very simple, now that I've figured out the details, and seems to be working beautifully, by the way. I'm surprised that there haven't been some glitches. It just works.) Marshall Abrams mabrams@uab.edu
On Jun 19, 2012, at 23:00 , Marshall wrote:
I have a quick (I hope) question. Does ABCL reload abcl.jar after it starts up? Or do something else unusual with the jar once it's running?
By default, ABCL does not need to reload the JAR, but it is continually accessed from startup as each PATHNAME to each artifact addressed by CL:LOAD is lazily accessed by the computations run through the local ABCL node. When you run CL:REQUIRE on :ABCL-CONTRIB, the current classpath is interpolated to figure out a plausible path for "abcl-contrib.jar". When you CL:REQUIRE on :JSS, the entire classpath is dynamically introspected to enumerate the set of all currently invocable Java classes hashed by their fully dot-qualified JVM name.
Context: I'm exploring using ABCL as an add-on to NetLogo, an agent-based modeling environment. (It might be more correct to say that I'm using NetLogo as an add-on to ABCL, since the primary code is in Lisp.) With the add-on method, NetLogo "extensions", one usually doesn't have to tell NetLogo where additional jars such as abcl.jar can be found. As long as they're in the extension's own directory, NetLogo will find the extra jars. This is apparently due to a little bit of voodoo that NetLogo engages in. However, in the case of my ABCL extension, NetLogo will load the extension, but then generate an error when I invoke ABCL via Interpreter.evaluate(). The problem is avoided if specify abcl.jar in the classpath explicitly, either on the command line (undesirable for NetLogo), or by adding abcl.jar to the classpath in Java (which works fine--so that's what I'm doing). Just curious about what ABCL is doing--thanks.
You're gonna need the class org.armedbear.Interpreter to resolvable by the JVM to invoke evaluate. If you aren't entering ABCL via org.armedbear.lisp.Main, then, yes, you will need to have "abcl.jar" be present in the current JVM's classpath. Both of your methods of adding "abcl.jar" are valid, just choose the way that allows you to maintain your linkages in a sane manner.
(The ABCL NetLogo extension is very simple, now that I've figured out the details, and seems to be working beautifully, by the way. I'm surprised that there haven't been some glitches. It just works.)
The kind of feedback we like to hear!
participants (2)
-
Mark Evenson -
Marshall