Den 24.08.2010 13:36, skrev Guillermo Polito:
> Hi!
>
> taking a look at issue 2579
>
http://code.google.com/p/pharo/issues/detail?id=2579 I saw it's all
> done but:
>
> "The float access methods are an alternative to what is described in
> 2580 / 2581 , didn't see this when I posted.
> They are slightly slower in a CogVM when primitive fails, since you
> will have 2 primitive failures before handling, but do not need the
> Parser change which allows primitive pragmas with non-literal error
> parameter.
>
> Either way, if this approach is chosen, we might as well write: (same
> for basicAt:put:)
> Float >> basicAt: index
> <primitive: 38>
> ^super basicAt: index
> as ec is always nil in this case."
>
> That should replace
>
> Float >> basicAt: index
> "...."
> <primitive: 38>
> | ec |
> ec == nil ifTrue: "primitive not implemented; floats are in
> big-endian/PowerPC order."
> [^super basicAt: index].
> index isInteger ifTrue: [self errorSubscriptBounds: index].
> index isNumber
> ifTrue: [^self basicAt: index asInteger]
> ifFalse: [self errorNonIntegerIndex]
>
> --------------------------------------------------------------------------
>
> I ran all the FloatTests and I got:
>
> -Cog VM: all green before and after the change.
> -non-Cog VM: 1 failure (on testNaNCompare) before and after the change
>
I don't get any failures on a Windows-nonCog 4.0.2 vm... On what
platform, and which parts of NaNCompare is failing exactly?
> I can't see tests for the primitive failure, maybe we should have...
>
? If primitive 38 fails, you're either not on a Cog vm, or the error
conditions are exactly the same as for Object basicAt:.
> Anyway, I wonder if this change is ok for the non-cog vm also. Does
> anyone know?
>
Yes, of course, otherwise it wouldn't be an alternative ;)
Cheers,
Henry
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Locked
