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