[armedbear-devel] expecting to find integer on stack

[Alan Ruttenberg]

On Sun, May 9, 2010 at 1:32 PM, Alessio Stalla <alessiostalla at gmail.com> wrote:
> On Sun, May 9, 2010 at 6:58 PM, Alan Ruttenberg
> <alanruttenberg at gmail.com> wrote:
>> On Sun, May 9, 2010 at 11:45 AM, Alessio Stalla <alessiostalla at gmail.com> wrote:
>>> On Tue, Apr 27, 2010 at 8:54 AM, Alan Ruttenberg
>>> <alanruttenberg at gmail.com> wrote:
>>>> On Tue, Apr 27, 2010 at 2:48 AM, Alessio Stalla <alessiostalla at 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?

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.

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

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

Agree on this.

-Alan