On Mon, Apr 26, 2010 at 5:58 PM, Erik Huelsmann <ehuels@gmail.com> wrote:

Hi Alan,

On Mon, Apr 26, 2010 at 7:59 AM, Alan Ruttenberg <alanruttenberg@gmail.com> wrote:

...

Fresh svn update. Compiled with Java 1.5 on OSX File attached.

Thanks for the attachment and stack trace! Alessio did some research tonight, after which I was able to fix the issue.

Could you test that the current trunk is working as it should?

It is, thanks. Now I'm getting used to the new pathname code and other changes. 1) I used to use probe-file to test whether a thing was a file. Now, however, probe-file on an http URI will return true. Is there a recommended way to see whether a pathname is a file pathname? 2) I use a different classloader (from bsh) so as to be able to add jars to my classpath dynamically. However, if I wanted to specialize a method on a java class so obtained, I need to coerce it to one that clos knows about. I was using an internal call to do so: (#"findJavaClass" 'org.armedbear.lisp.JavaClass class) However this is gone in the new version. Could you suggest how I can register a java class that I've obtained from the alternative class manager so that clos knows about it? Thanks, Alan

Bye,

Erik.

On Tue, Apr 27, 2010 at 8:24 AM, Mark Evenson <evenson@panix.com> wrote:

On 4/27/10 4:05 AM, Alan Ruttenberg wrote:

[…]

...

Now I'm getting used to the new pathname code and other changes.

1) I used to use probe-file to test whether a thing was a file. Now, however, probe-file on an http URI will return true. Is there a recommended way to see whether a pathname is a file pathname?

URL-PATHNAME and JAR-PATHNAME are now subtypes of PATHNAME, so the usual CL type machinery should be at your disposal.  For convenience, we have defined predicate functions EXT:PATHNAME-URL-P and EXT:PATHNAME-JAR-P which is what I would expect one for common usage.

...

2) I use a different classloader (from bsh) so as to be able to add jars to my classpath dynamically. However, if I wanted to specialize a method on a java class so obtained, I need to coerce it to one that clos knows about. I was using an internal call to do so:

(#"findJavaClass" 'org.armedbear.lisp.JavaClass class)

However this is gone in the new version. Could you suggest how I can register a java class that I've obtained from the alternative class manager so that clos knows about it?

Hmmm, this should be unrelated to the URL pathname implementation.

JavaObject.java seems to still have a findJavaClass() method, and even provides a Lisp interface JAVA::%FIND-JAVA-CLASS.  Maybe JSS is failing to properly invoke the method?

In any case, we should figure out what functionality you need here, and polish this up as a semi-supported interface Lisp-side for usage.  The first step is figuring out where (and then why) we changed this.

IIRC, I should have a local patch to make JCLASS use another classloader if you pass it to it, including in CLOS method specializers, as in (defmethod foo ((x (jclass "foo" *my-classloader*))) ...) If that sounds sensible to you, I can adapt it to the current version of abcl and commit it, so it can be tested. Ciao, Alessio

On Tue, Apr 27, 2010 at 8:54 AM, Alan Ruttenberg <alanruttenberg@gmail.com> wrote:

On Tue, Apr 27, 2010 at 2:48 AM, Alessio Stalla <alessiostalla@gmail.com> wrote:

...

IIRC, I should have a local patch to make JCLASS use another classloader if you pass it to it, including in CLOS method specializers, as in (defmethod foo ((x (jclass "foo" *my-classloader*))) ...)

 If that sounds sensible to you, I can adapt it to the current version of abcl and commit it, so it can be tested.

Let's give it a shot.

I finally committed the patch on trunk. Alessio

On Sun, May 9, 2010 at 6:58 PM, Alan Ruttenberg <alanruttenberg@gmail.com> wrote:

On Sun, May 9, 2010 at 11:45 AM, Alessio Stalla <alessiostalla@gmail.com> wrote:

...

On Tue, Apr 27, 2010 at 8:54 AM, Alan Ruttenberg <alanruttenberg@gmail.com> wrote:

...

On Tue, Apr 27, 2010 at 2:48 AM, Alessio Stalla <alessiostalla@gmail.com> wrote:

...

IIRC, I should have a local patch to make JCLASS use another classloader if you pass it to it, including in CLOS method specializers, as in (defmethod foo ((x (jclass "foo" *my-classloader*))) ...)

 If that sounds sensible to you, I can adapt it to the current version of abcl and commit it, so it can be tested.

Let's give it a shot.

I finally committed the patch on trunk.

Tested, works. Thanks.

So what do you think about actually integrating the bean shell class loader into ABCL. Source is at

http://ikayzo.org/svn/beanshell (root) http://ikayzo.org/svn/beanshell/BeanShell/src/bsh/classpath (classloader) http://ikayzo.org/svn/beanshell/BeanShell/src/bsh/BshClassManager.java (classmanager)

I've been using it for about 5 years and it's pretty useful, allowing dynamic modifications to the classpath, including jars as part of asdf systems, etc.

The addUrl method to dynamically add new resources to the classpath is very nice and easy to add. I'm less convinced by the other stuff, which subverts the normal classloading semantics: the bsh classloader reloads all classes from the classpath, except the core BeanShell classes, instead of delegating to the parent classloader first. I fear this may cause bugs and/or inefficiencies in the context of ABCL, and even without those concerns I see little value in adding it. Do you actually use this feature? And if yes, what for? Also, if we expose the classloader to the user and allow him to modify the classpath, we must make sure that said classloader is used in all the relevant places. I'd prefer to postpone that to after version 0.20 is released, to avoid the risk of inadvertently introducing subtle bugs in 0.20. Just my .02, Alessio

On Mon, May 10, 2010 at 2:05 AM, Alan Ruttenberg <alanruttenberg@gmail.com> wrote:

I've used the ability to add resources to the classpath explicitly. Via use of ClassManager I may have used the other inadvertently. I've never looked deeply at what happens behind the scenes. What I can say is that I've rarely had any issue with jss over the years I've used it within ABCL.

From a quick read of ClassManager, it seems to me it's mostly a thin layer over a classloader, which can optionally swap another classloader in to "reload" classes at will (as well as doing other stuff to support BeanShell itself). I think it can be a useful addition, but I'd keep the two things conceptually separate if possible: have a generic classloader with dynamic classpath and another, "greedy" classloader that will always load resources from its own jars first, which can be used to "reload" (or better, load different versions of) classes in a jar or set of jars. The two might actually be a single class with a boolean switch: my point is that they should be clearly distinguishable so the user can ultimately decide what to do.

If you think you can preserve the desired add-to-classpath behavior with less mechanism, then I'm game to give it a try.

It's possible, with the caveat that adding a new jar which contains a class that has already been loaded from somewhere else (in the same classloader chain) won't make the classloader use the new class. In other words, the classpath is only partially dynamic (a given class will see a static snapshot the time it is loaded). That's true for the bsh classloader as well, as far as I understand, except the bsh one will always ignore classes in the system classpath (the one specified at startup) and always load them from the jars it knows. Using "greedy" classloaders and layering them will enable to load multiple versions of a class. But as I said, I'd keep the two things separate. It would also be nice to have the "greedy" classloader optionally use a Lisp function predicate to decide whether to be greedy or not on a per-class basis. Hope this makes sense, Alessio