> > 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.