[Pharo-project] Fix the other dependencies of asContextWithSender:
Eliot should this fix be applied to pharo? http://code.google.com/p/pharo/issues/detail?id=2655 Is there a dependency? Stef
On Tue, Jul 6, 2010 at 12:51 PM, stephane ducasse <stephane.ducasse@free.fr>wrote:
Eliot
should this fix be applied to pharo? http://code.google.com/p/pharo/issues/detail?id=2655
Yes please. Almost everything I'm likely to put in Compiler, Kernel or System on Squeak 4.1 belongs in all dialects using the closure compiler.
Is there a dependency?
What's happing here is that very old primitive failure code that allowed the closure system to run on old VMs without closure support depended on BlockClosure>>asContext, which had a bug in it. So the changes reflect the bug fix but are enclosed in false ifTrue: [] because they really are obsolete, but the code is retained because its useful documentation of how the closure primitives should work. I hope this makes sense! best Eliot
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Eliot, There are several other changes in that package that could generate different behavior. Are they correct? They are: BlockClosure >> value used to call primitive 201, now calls 205 used to check for zero args, now checks for one (!?) BlockClosure >> value: used to call primitive 202, now calls 205 BlockClosure >> value:value: used to call primitive 203, now calls 205 BlockClosure >> value:value:value: used to call primitive 204, now calls 205 Primitive 205 was previously only used for #value:value:value:value:, so I wonder if this might be a mistake. Thanks, Juan Vuletich Eliot Miranda wrote:
On Tue, Jul 6, 2010 at 12:51 PM, stephane ducasse <stephane.ducasse@free.fr <mailto:stephane.ducasse@free.fr>> wrote:
Eliot
should this fix be applied to pharo? http://code.google.com/p/pharo/issues/detail?id=2655
Yes please. Almost everything I'm likely to put in Compiler, Kernel or System on Squeak 4.1 belongs in all dialects using the closure compiler.
Is there a dependency?
What's happing here is that very old primitive failure code that allowed the closure system to run on old VMs without closure support depended on BlockClosure>>asContext, which had a bug in it. So the changes reflect the bug fix but are enclosed in false ifTrue: [] because they really are obsolete, but the code is retained because its useful documentation of how the closure primitives should work. I hope this makes sense!
best Eliot
Stef
Hi Juan, On Wed, Jul 7, 2010 at 5:24 AM, Juan Vuletich <juan@jvuletich.org> wrote:
Hi Eliot,
There are several other changes in that package that could generate different behavior. Are they correct? They are:
BlockClosure >> value used to call primitive 201, now calls 205 used to check for zero args, now checks for one (!?)
BlockClosure >> value: used to call primitive 202, now calls 205
BlockClosure >> value:value: used to call primitive 203, now calls 205
BlockClosure >> value:value:value: used to call primitive 204, now calls 205
Primitive 205 was previously only used for #value:value:value:value:, so I wonder if this might be a mistake.
Quite right, this is a mistake. I was careless copy-pasting the fix between them. I've committed fixes to trunk. In the VM these primitive numbers all bind to the same primitive so there was no visible effect. Thanks for checking! best Eliot
Thanks, Juan Vuletich
Eliot Miranda wrote:
On Tue, Jul 6, 2010 at 12:51 PM, stephane ducasse < stephane.ducasse@free.fr <mailto:stephane.ducasse@free.fr>> wrote:
Eliot
should this fix be applied to pharo? http://code.google.com/p/pharo/issues/detail?id=2655
Yes please. Almost everything I'm likely to put in Compiler, Kernel or System on Squeak 4.1 belongs in all dialects using the closure compiler.
Is there a dependency?
What's happing here is that very old primitive failure code that allowed the closure system to run on old VMs without closure support depended on BlockClosure>>asContext, which had a bug in it. So the changes reflect the bug fix but are enclosed in false ifTrue: [] because they really are obsolete, but the code is retained because its useful documentation of how the closure primitives should work. I hope this makes sense!
best Eliot
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Eliot, Eliot Miranda wrote:
Hi Juan,
On Wed, Jul 7, 2010 at 5:24 AM, Juan Vuletich <juan@jvuletich.org <mailto:juan@jvuletich.org>> wrote:
Hi Eliot,
There are several other changes in that package that could generate different behavior. Are they correct? They are:
BlockClosure >> value used to call primitive 201, now calls 205 used to check for zero args, now checks for one (!?)
BlockClosure >> value: used to call primitive 202, now calls 205
BlockClosure >> value:value: used to call primitive 203, now calls 205
BlockClosure >> value:value:value: used to call primitive 204, now calls 205
Primitive 205 was previously only used for #value:value:value:value:, so I wonder if this might be a mistake.
Quite right, this is a mistake. I was careless copy-pasting the fix between them. I've committed fixes to trunk. In the VM these primitive numbers all bind to the same primitive so there was no visible effect. Thanks for checking!
best Eliot
When I integrate stuff in Cuis, I always do my best effort to understand it! Anyway, I see your new version, but in BlockClosure >> value it still does numArgs ~= 1 ifTrue: [self numArgsError: 1]. even if the older version (9/3/2008) it checked for zero arguments. Is this right? If so, what's the rationale? Thanks! Juan Vuletich
On Wed, Jul 7, 2010 at 11:46 AM, Juan Vuletich <juan@jvuletich.org> wrote:
Hi Eliot,
Eliot Miranda wrote:
Hi Juan,
On Wed, Jul 7, 2010 at 5:24 AM, Juan Vuletich <juan@jvuletich.org<mailto: juan@jvuletich.org>> wrote:
Hi Eliot,
There are several other changes in that package that could generate different behavior. Are they correct? They are:
BlockClosure >> value used to call primitive 201, now calls 205 used to check for zero args, now checks for one (!?)
BlockClosure >> value: used to call primitive 202, now calls 205
BlockClosure >> value:value: used to call primitive 203, now calls 205
BlockClosure >> value:value:value: used to call primitive 204, now calls 205
Primitive 205 was previously only used for #value:value:value:value:, so I wonder if this might be a mistake.
Quite right, this is a mistake. I was careless copy-pasting the fix between them. I've committed fixes to trunk. In the VM these primitive numbers all bind to the same primitive so there was no visible effect. Thanks for checking!
best Eliot
When I integrate stuff in Cuis, I always do my best effort to understand it!
Anyway, I see your new version, but in BlockClosure >> value it still does numArgs ~= 1 ifTrue: [self numArgsError: 1]. even if the older version (9/3/2008) it checked for zero arguments. Is this right? If so, what's the rationale?
No rationale there at all. Another mistake. I'm having a bad day /:
Thanks! Juan Vuletich
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Eliot Miranda wrote:
On Wed, Jul 7, 2010 at 11:46 AM, Juan Vuletich <juan@jvuletich.org <mailto:juan@jvuletich.org>> wrote:
When I integrate stuff in Cuis, I always do my best effort to understand it!
Anyway, I see your new version, but in BlockClosure >> value it still does numArgs ~= 1 ifTrue: [self numArgsError: 1]. even if the older version (9/3/2008) it checked for zero arguments. Is this right? If so, what's the rationale?
No rationale there at all. Another mistake. I'm having a bad day /:
Then I hope it gets better! Thanks, Juan Vuletich
participants (3)
-
Eliot Miranda -
Juan Vuletich -
stephane ducasse