This was a recent addition to the interpreterProxy, and your VM may not support it. Andreas mistakenly called the additional function a "minor" revision, so a plugin depending upon its existence > may try to run the code, even if it doesn't exist. It won't. The interpreter proxy exports a major number and a > minor number,
but the plugin will only accept proxies that have the same > major and *at least* the minor version the plugin was compiled with. > Therefore, unless you've hacked setInterpreter() a plugin will never run with > incompatible proxies.
This appears to be correct (I had misread the code of setInterpeter earlier), so the error was mine, not Andreas's. So, help me out -- does the V2.6 VM interpeterProxy support classLargeNegativeInteger() or not? I had a few problems with code that exploded when I made the call, but disappeared after using various hacks to get a handle to the oop more directly. If so, I'm confused why that code crashed earlier, but worked when I passed the class as a parameter. (Maybe I just ran that unit test wrong -- I'll get back to you). If not, I'm confused why the plugins ran at all.
Now I've taken another way: I'm initializing a variable 'myClassLargeNegativeInteger' (to avoid name clashes with 'classLargeNegativeInteger' in 2.7) while starting up the > system by a startup class method and use this variable then. This works fine and avoids unnecessary parameters in ST primitive (your approach) or C function calls (my first approach). And also the changes to use the features of 2.7 are minimal. This is dangerous. If you cache any Oop on the C side it will not be
remapped during GC and the next call to your primitive after > GC will almost always break the system.
Right, and in practice, I didn't actually go that route, but instead passed the class on each call using references to the parameter stack instead which survived GC's.