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