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