On Mar 24, 2013, at 13:45, Erik Huelsmann <ehuels@gmail.com> wrote:


On Sun, Mar 24, 2013 at 12:00 PM, Anton Vodonosov <avodonosov@yandex.ru> wrote:
24.03.2013, 14:44, "Erik Huelsmann" <ehuels@gmail.com>:
> But on the XPATH issue, I'm mostly very happy to know we've found and solved a compiler stability issue in light of compiling sources with shared structure.

Speaking of compiler stability issues, consider fixing the :CRASH results I've reported earlier:


Looking at the crash in cl-l10n, it looks like ALLOCATE-FUNCALLABLE-INSTANCE creates a StandardGenericFunction, not a funcallable instance. For some reason ALLOCATE-FUNCALLABLE-INSTANCE  seems to be called with a zero-length Layout, which means no slots are being allocated, while StandardGenericFunction expects to be a subclass of StandardGenericFunctionClass which does have slots...

Rudi, since this seems to match closely with your area of expertise, could you have a (quick) look at this and provide some pointers which could help us fix the array index out of bounds errors? The reproduction recipe is to simply quickload :cl-l10n.

One of my old kludges, coming back to bite me ...  Fixed in r14446, by checking whether the class passed to allocate-funcallable-instance is a subtype of standard-generic-function and creating either of two (java-side) types of funcallable objects.

Now cl-l10n is complaining about a missing #+abcl branch in the definition of GETENV, but we get past the previous bump in the compilation.

Rudi