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.
Thank you, Andreas and Andrew!
I haven't kept in mind that in Smalltalk _all_ is an object! This is valid for classes, too.
But how is it with objects in the special objects array? Are object pointers stored in the special objects array constant - during one run of squeak - or not?
BTW:
I'm just storing the class pointer of classLargeNegativeInteger in a var in C. In 2.7 classLargeNegativeInteger also resists in the special objects array (according my updated image).
How is it in 2.6? Answer: It is not stored there!
So in either case: this way is no way.
Greetings,
Stephan
agree@carltonfields.com wrote:
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.
squeak-dev@lists.squeakfoundation.org
-
agreeļ¼ carltonfields.com -
Stephan Rudlof