Re: [Pharo-project] [squeak-dev] Re: #recreateSpecialObjectsArray woes
On 12 April 2010 19:32, Andreas Raab <andreas.raab@gmx.de> wrote:
On 4/12/2010 7:17 AM, Igor Stasenko wrote:
what you think?
I think "no, no, no". Two reasons: 1) the extension of the splObjs implies a hardcoded contract with the VM; having it externally settable makes it look as if one could just stick in stuff for fun.
By 'For fun', you mean writing a plugin, which needs own a special objects to work? I wanted to add a special objects couple of times in plugins, but then i had to step back , knowing that it will require overriding the #recreateSpecialObjects method, which is tedious and error prone, because you never know if people who may use your plugin could also use FFI, Alien or something else. By keeping things intact, we're having a bottleneck which doesn't allows developers to use a special objects array in their plugins for own purposes (i guess you're not assuming that FFI and Alien are the only exceptional plugins which having an ultimate right to touch a special objects array).
2) The recreation of the splObjs implies specific knowledge about which values should be added and which values should be removed.
Sure, each part of a system knows wery well which objects should be there and at what place. But there is no need to recreate an array (unless it needs to grow) , and it could be done automatically, by copying old objects into a new, bigger array, while revoking the #recreateSpecialObjects from system completely. For replacing an object(s) in array there is a simple as #at:put: Ensuring an array size doesn't means automatically that it should be rebuilt from scratch, in same way as OrderedCollection doesn't forcing you to add all items from scratch into it, once it needs to grow.
In any case, there are only two packages that have ever made mods to the splObjs array (FFI and Alien) for *very* specialized reasons. We should just add these definitions manually and remove the patch from the Alien package.
I think you are mixing the cause and consequence here. As to me, the reason, why there's only two plugins who extending a special objects array is because its very tedious and error prone. Mostly because of conflicting overrides by different packages! Anyways, if you don't like playing with special objects array. Please, can we think of a scheme which at least allows us to avoid overrides of a very same method by different packages?
Cheers, Â - Andreas
-- Best regards, Igor Stasenko AKA sig.
On 4/12/2010 10:43 AM, Igor Stasenko wrote:
On 12 April 2010 19:32, Andreas Raab<andreas.raab@gmx.de> wrote:
On 4/12/2010 7:17 AM, Igor Stasenko wrote:
what you think?
I think "no, no, no". Two reasons: 1) the extension of the splObjs implies a hardcoded contract with the VM; having it externally settable makes it look as if one could just stick in stuff for fun.
By 'For fun', you mean writing a plugin, which needs own a special objects to work?
You don't need special objects. Their use in FFI and Alien is a historical accident. What you'd do today is register the classes directly with your plugin instead of sticking them into splObjs.
I wanted to add a special objects couple of times in plugins, but then i had to step back , knowing that it will require overriding the #recreateSpecialObjects method, which is tedious and error prone, because you never know if people who may use your plugin could also use FFI, Alien or something else.
Precisely. All of these are good reasons why you shouldn't modify splObjs to begin with. What you do instead is to provide a primitive in your plugin that accepts the classes / objects you intend to use. This wouldn't work in the past because you had no way of handling GC correctly. Today, you can give your plugin an array of your own special objects that is used by your plugin, registered with the VM as a GC root and there's no need to modify splObjs. Cheers, - Andreas
By keeping things intact, we're having a bottleneck which doesn't allows developers to use a special objects array in their plugins for own purposes (i guess you're not assuming that FFI and Alien are the only exceptional plugins which having an ultimate right to touch a special objects array).
2) The recreation of the splObjs implies specific knowledge about which values should be added and which values should be removed.
Sure, each part of a system knows wery well which objects should be there and at what place. But there is no need to recreate an array (unless it needs to grow) , and it could be done automatically, by copying old objects into a new, bigger array, while revoking the #recreateSpecialObjects from system completely. For replacing an object(s) in array there is a simple as #at:put: Ensuring an array size doesn't means automatically that it should be rebuilt from scratch, in same way as OrderedCollection doesn't forcing you to add all items from scratch into it, once it needs to grow.
In any case, there are only two packages that have ever made mods to the splObjs array (FFI and Alien) for *very* specialized reasons. We should just add these definitions manually and remove the patch from the Alien package.
I think you are mixing the cause and consequence here. As to me, the reason, why there's only two plugins who extending a special objects array is because its very tedious and error prone. Mostly because of conflicting overrides by different packages!
Anyways, if you don't like playing with special objects array. Please, can we think of a scheme which at least allows us to avoid overrides of a very same method by different packages?
Cheers, - Andreas
On 12 April 2010 20:49, Andreas Raab <andreas.raab@gmx.de> wrote:
On 4/12/2010 10:43 AM, Igor Stasenko wrote:
On 12 April 2010 19:32, Andreas Raab<andreas.raab@gmx.de> Â wrote:
On 4/12/2010 7:17 AM, Igor Stasenko wrote:
what you think?
I think "no, no, no". Two reasons: 1) the extension of the splObjs implies a hardcoded contract with the VM; having it externally settable makes it look as if one could just stick in stuff for fun.
By 'For fun', you mean writing a plugin, which needs own a special objects to work?
You don't need special objects. Their use in FFI and Alien is a historical accident. What you'd do today is register the classes directly with your plugin instead of sticking them into splObjs.
I wanted to add a special objects couple of times in plugins, but then i had to step back , knowing that it will require overriding the #recreateSpecialObjects method, which is tedious and error prone, because you never know if people who may use your plugin could also use FFI, Alien or something else.
Precisely. All of these are good reasons why you shouldn't modify splObjs to begin with. What you do instead is to provide a primitive in your plugin that accepts the classes / objects you intend to use. This wouldn't work in the past because you had no way of handling GC correctly.
Today, you can give your plugin an array of your own special objects that is used by your plugin, registered with the VM as a GC root and there's no need to modify splObjs.
Looks like i missed something. HOW? Suppose a primitive needs to answer an instance of a special class, known by it. How it can instantiate it, if it having no any clues, where its invoked from, and it can't rely on a receiver, nor any of method's arguments?
Cheers, Â - Andreas
-- Best regards, Igor Stasenko AKA sig.
On 4/12/2010 10:57 AM, Igor Stasenko wrote:
On 12 April 2010 20:49, Andreas Raab<andreas.raab@gmx.de> wrote:
Today, you can give your plugin an array of your own special objects that is used by your plugin, registered with the VM as a GC root and there's no need to modify splObjs.
Looks like i missed something. HOW? Suppose a primitive needs to answer an instance of a special class, known by it. How it can instantiate it, if it having no any clues, where its invoked from, and it can't rely on a receiver, nor any of method's arguments?
You make it work just like splObjs, i.e., FooPlugin>>primitiveSetSplObjs "Sets the special objects for my plugin" splObjs := interpreterProxy stackObjectValue: 0. "... should have sanity checks ..." interpreterProxy addGCRoot: (self cCode: '&splObjs'). FooPlugin>>instantiateNewBar "Instantiates a new Bar (at index 2 in the splObjs)" "... should have sanity checks ..." foo := interpreterProxy instantiateClass: (interpreterProxy fetchPointer: 2 ofObject: splObjs) indexableSize: 0. interpreterProxy pop: 1 thenPush: foo. then you use it like here: Foo class>>startUp: resuming "Install my special objects on system startup" resuming ifTrue:[ self primitiveSetSplObjs: {Foo. Bar. DukeNukem. 42}. ]. Foo class>>newBar ^self primitiveNewBar The "trick" is that your plugin can register whatever it wants for GC tracing (in fact you should probably set the variable to nilObj and call addGCRoot from initialiseModule exactly once and release it via shutdownModule). This removes the need for abusing splObjs to stick in stuff that you'd like to preserve between prim calls. Cheers, - Andreas
On 12 April 2010 21:08, Andreas Raab <andreas.raab@gmx.de> wrote:
On 4/12/2010 10:57 AM, Igor Stasenko wrote:
On 12 April 2010 20:49, Andreas Raab<andreas.raab@gmx.de> Â wrote:
Today, you can give your plugin an array of your own special objects that is used by your plugin, registered with the VM as a GC root and there's no need to modify splObjs.
Looks like i missed something. HOW? Suppose a primitive needs to answer an instance of a special class, known by it. How it can instantiate it, if it having no any clues, where its invoked from, and it can't rely on a receiver, nor any of method's arguments?
You make it work just like splObjs, i.e.,
FooPlugin>>primitiveSetSplObjs     "Sets the special objects for my plugin"     splObjs := interpreterProxy stackObjectValue: 0.     "... should have sanity checks ..."     interpreterProxy addGCRoot: (self cCode: '&splObjs').
FooPlugin>>instantiateNewBar     "Instantiates a new Bar (at index 2 in the splObjs)"
    "... should have sanity checks ..."     foo := interpreterProxy instantiateClass: (interpreterProxy fetchPointer: 2 ofObject: splObjs) indexableSize: 0.     interpreterProxy pop: 1 thenPush: foo.
then you use it like here:
Foo class>>startUp: resuming     "Install my special objects on system startup"     resuming ifTrue:[         self primitiveSetSplObjs: {Foo. Bar. DukeNukem. 42}.     ].
Foo class>>newBar     ^self primitiveNewBar
The "trick" is that your plugin can register whatever it wants for GC tracing (in fact you should probably set the variable to nilObj and call addGCRoot from initialiseModule exactly once and release it via shutdownModule). This removes the need for abusing splObjs to stick in stuff that you'd like to preserve between prim calls.
Ah, that's cool.. Except that most recent SVN repository sqVirtualMachine.h (revision 1955) having no addGCroot: defined in InterpreterProxy struct. I am using wrong SVN repository? http://squeakvm.org/svn/squeak/trunk/ After some research i found another file in plugins/IA32ABI/, which includes new proxy functions, but its not used by builder.
Cheers, Â - Andreas
-- Best regards, Igor Stasenko AKA sig.
On 4/12/2010 11:46 AM, Igor Stasenko wrote:
Ah, that's cool.. Except that most recent SVN repository sqVirtualMachine.h (revision 1955) having no addGCroot: defined in InterpreterProxy struct. I am using wrong SVN repository? http://squeakvm.org/svn/squeak/trunk/
Err, weird. The code is in VMMaker but it seems as if SVN hasn't been updated. It should include this: #if VM_PROXY_MINOR > 7 /* New methods for proxy version 1.8 */ /* callbackEnter: Re-enter the interpreter loop for a callback. Arguments: callbackID: Pointer to a location receiving the callback ID used in callbackLeave Returns: True if successful, false otherwise */ sqInt (*callbackEnter)(sqInt *callbackID); /* callbackLeave: Leave the interpreter from a previous callback Arguments: callbackID: The ID of the callback received from callbackEnter() Returns: True if succcessful, false otherwise. */ sqInt (*callbackLeave)(sqInt callbackID); /* addGCRoot: Add a variable location to the garbage collector. The contents of the variable location will be updated accordingly. Arguments: varLoc: Pointer to the variable location Returns: True if successful, false otherwise. */ sqInt (*addGCRoot)(sqInt *varLoc); /* removeGCRoot: Remove a variable location from the garbage collector. Arguments: varLoc: Pointer to the variable location Returns: True if successful, false otherwise. */ sqInt (*removeGCRoot)(sqInt *varLoc); #endif Cheers, - Andreas
On 12 April 2010 21:52, Andreas Raab <andreas.raab@gmx.de> wrote:
On 4/12/2010 11:46 AM, Igor Stasenko wrote:
Ah, that's cool.. Except that most recent SVN repository sqVirtualMachine.h (revision 1955) having no addGCroot: defined in InterpreterProxy struct. I am using wrong SVN repository? http://squeakvm.org/svn/squeak/trunk/
Err, weird. The code is in VMMaker but it seems as if SVN hasn't been updated. It should include this:
Yes. I remember seeing that code before. This is twice strange that its not in SVN repo. [snip]
Cheers, Â - Andreas
-- Best regards, Igor Stasenko AKA sig.
It's in the Alien directory. somehow it never got promoted to the cross platform directory. So check the sqVirtualMachine.h You may need to adjust it. On 2010-04-12, at 12:01 PM, Igor Stasenko wrote:
On 12 April 2010 21:52, Andreas Raab <andreas.raab@gmx.de> wrote:
On 4/12/2010 11:46 AM, Igor Stasenko wrote:
Ah, that's cool.. Except that most recent SVN repository sqVirtualMachine.h (revision 1955) having no addGCroot: defined in InterpreterProxy struct. I am using wrong SVN repository? http://squeakvm.org/svn/squeak/trunk/
Err, weird. The code is in VMMaker but it seems as if SVN hasn't been updated. It should include this:
Yes. I remember seeing that code before. This is twice strange that its not in SVN repo.
[snip]
Cheers, - Andreas
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Okay, then i propose to: 1. fix the interpreterProxy spec, so all VMs will include addRoot() & friends 2. create a single and _final_ version of #recreateSpecialObjectsArray 3. remove overrides of this method from both FFI and Alien packages. 4. Optionally, rewrite plugins to use own special objects at initialization, so they no longer need extending specialObjectsArray, and hence use of #recreateSpecialObjectsArray -- Best regards, Igor Stasenko AKA sig.
On 4/12/2010 12:49 PM, Igor Stasenko wrote:
Okay, then i propose to:
1. fix the interpreterProxy spec, so all VMs will include addRoot()& friends 2. create a single and _final_ version of #recreateSpecialObjectsArray 3. remove overrides of this method from both FFI and Alien packages. 4. Optionally, rewrite plugins to use own special objects at initialization, so they no longer need extending specialObjectsArray, and hence use of #recreateSpecialObjectsArray
+1. Cheers, - Andreas
On Apr 12, 2010, at 9:49 PM, Igor Stasenko wrote:
Okay, then i propose to:
1. fix the interpreterProxy spec, so all VMs will include addRoot() & friends 2. create a single and _final_ version of #recreateSpecialObjectsArray 3. remove overrides of this method from both FFI and Alien packages. 4. Optionally, rewrite plugins to use own special objects at initialization, so they no longer need extending specialObjectsArray, and hence use of #recreateSpecialObjectsArray
5. Add a **large comment** stating how it should be done. For example using the example andreas used. Stef
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Andreas Raab -
Igor Stasenko -
John M McIntosh -
Stéphane Ducasse