Exupery and the Closure Compiler

[bryce at kampjes.demon.co.uk]

Should Exupery 0.12 be made compatible with the closure compiler? Both
Exupery and the closure compiler use the "unused" slot in
MethodContext. Exupery uses the slot to indicate that the
MethodContext uses native code. The closure compiler uses it to hold a
pointer to the environment which contains shared variables.

Exupery uses it because until recently Exupery used to use normal
MethodContexts when executing compiled code. The native program
counter was stored in the "unused" slot. If the slot was a
SmallInteger it was the address to jump to to resume native code, if
it was a nil then the context should be interpreted.

When I added block support I moved the native program counter into the
same slot as the interpreted program counter. Later
ExuperyMethodContext was created to allow the debugger to work with
compiled method contexts again. Originally they were the same to the
debugger, but the "unused" slot should have been nilled out if the
context was single stepped. With the native PC in the PC slot having a
dedicated context object makes it easier to work with
tools. Polymorphism can deal with converting the native program
counter into a bytecode program counter and decompiling a context
if it's changed through reflection.

It's probably worthwhile me having a proper look at the logic to
switch between native code and interpreted code. There was a bug
that's been fixed in the Slang support (going from interpreted to
compiled) and I'm not sure that the native code check has the same bug
(going from compiled to interpreted). The bug was that interpreted
blocks with a SmallInteger receiver were being treated as native code.

I guess I should investigate before 0.12 even if I then decide not
to change it.

Are people interested in running Exupery and the closure compiler
at the same time?

Bryce