Hi All,
these two slots are the unused MethodContext and BlockContext prototypes. They're either side of class BlockClosure. I'd like to use one of them for threaded callbacks (the foreign callback process slot, upon which a callback from a foreign thread can be run) and keep another in reserve. In Smalltalk these are indices 36 & 38 in SmalltalkImage>>recreateSpecialObjectsArray. Objections, encouragements, alternatives?
best Eliot
Sure no problems here
On 2010-08-26, at 1:31 PM, Eliot Miranda wrote:
Hi All,
these two slots are the unused MethodContext and BlockContext prototypes. They're either side of class BlockClosure. I'd like to use one of them for threaded callbacks (the foreign callback process slot, upon which a callback from a foreign thread can be run) and keep another in reserve. In Smalltalk these are indices 36 & 38 in SmalltalkImage>>recreateSpecialObjectsArray. Objections, encouragements, alternatives?best Eliot
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Do we really need to recycle these slots? Why not just appending these to the end?
Cheers, - Andreas
On 8/26/2010 1:31 PM, Eliot Miranda wrote:
Hi All,
these two slots are the unused MethodContext and BlockContextprototypes. They're either side of class BlockClosure. I'd like to use one of them for threaded callbacks (the foreign callback process slot, upon which a callback from a foreign thread can be run) and keep another in reserve. In Smalltalk these are indices 36 & 38 in SmalltalkImage>>recreateSpecialObjectsArray. Objections, encouragements, alternatives?
best Eliot
No objections from my point of view, although I do slightly prefer Andreas' approach.
These two slots were present in Squeak 3.6 but were apparently unused. I presume that they were intended for the (now dormant) NewCompiler work. In the interest of general tidiness it would be best to recycle the slots, but for the sake of courtesy to anyone who still has an interest in NewCompiler it may be better to retain them a while longer (I think that there may be some interest it in for research purposes, even if it does not provide practical benefits otherwise).
I note also that the size of the special objects array can serve as a de facto version identifier, so it does not really hurt to have the array grow a little bit when some significant new feature is added.
Dave
On Thu, Aug 26, 2010 at 01:51:16PM -0700, Andreas Raab wrote:
Do we really need to recycle these slots? Why not just appending these to the end?
Cheers,
- Andreas
On 8/26/2010 1:31 PM, Eliot Miranda wrote:
Hi All,
these two slots are the unused MethodContext and BlockContextprototypes. They're either side of class BlockClosure. I'd like to use one of them for threaded callbacks (the foreign callback process slot, upon which a callback from a foreign thread can be run) and keep another in reserve. In Smalltalk these are indices 36 & 38 in SmalltalkImage>>recreateSpecialObjectsArray. Objections, encouragements, alternatives?
best Eliot
On Aug 26, 2010, at 11:58 PM, David T. Lewis wrote:
No objections from my point of view, although I do slightly prefer Andreas' approach.
These two slots were present in Squeak 3.6 but were apparently unused. I presume that they were intended for the (now dormant) NewCompiler work.
Thanks david for the cautious words. The new compiler is far from dormant in fact. Jorge worked a year on it. Since last week new compiler is called Opal (because this is the see around here where we can see england). Marcus, jb, jorge are working a lot on it. Marcus should send some announces about they progress. There is also a mailing-list and the result is quite pleasant. The goal is to use it in Pharo1.3. So far large clean up to IR, decompiler working for fullclosures.....
In the interest of general tidiness it would be best to recycle the slots, but for the sake of courtesy to anyone who still has an interest in NewCompiler it may be better to retain them a while longer (I think that there may be some interest it in for research purposes, even if it does not provide practical benefits otherwise).
I note also that the size of the special objects array can serve as a de facto version identifier, so it does not really hurt to have the array grow a little bit when some significant new feature is added.
Dave
On Thu, Aug 26, 2010 at 01:51:16PM -0700, Andreas Raab wrote:
Do we really need to recycle these slots? Why not just appending these to the end?
Cheers,
- Andreas
On 8/26/2010 1:31 PM, Eliot Miranda wrote:
Hi All,
these two slots are the unused MethodContext and BlockContext prototypes. They're either side of class BlockClosure. I'd like to use one of them for threaded callbacks (the foreign callback process slot, upon which a callback from a foreign thread can be run) and keep another in reserve. In Smalltalk these are indices 36 & 38 in SmalltalkImage>>recreateSpecialObjectsArray. Objections, encouragements, alternatives?
best Eliot
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
David T. Lewis -
Eliot Miranda -
John M McIntosh -
stephane ducasse