[Vm-dev] failing/errors Pharo Tests with CogVM

[Mariano Martinez Peck]

Ok....that's to all the responses. The thread is now far away my knoweldege,
so I will naively ask:  is it worth creating a Pharo 1.1.1 one click with
CogVM?

Marcus released a PharoCore 1.1.1 with changes for CogVM and some important
fixes. I took that core image and I created a new dev. But before releasing,
I run the tests and I found them.

Seems you all discussed about the Float problems...but what about the
others? I remember them and I thing they were fixed in newest versions of
VMMaker.

So...the question is now....are the failure/error of those tests means that
Pharo is "unreleasable" with CogVM? Should we wait for the fix or we should
release anyway?

Thanks in advance,

Mariano

On Fri, Sep 17, 2010 at 8:20 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

>
>
>
> On Thu, Sep 16, 2010 at 10:54 PM, Andreas Raab <andreas.raab at gmx.de>wrote:
>
>>
>> On 9/16/2010 2:44 PM, Eliot Miranda wrote:
>>
>>>     I realise we need to be more precise.  Are you talking about NaNs
>>> specifically or NaN and Inf?
>>>
>>
>> NaN only. +-Inf are fine as they have a well-defined mathematical
>> relationship over the set of numbers. NaN does not.
>>
>>
>>  The Squeak VM happily answers Inf from its
>>> float primitives.  In fact the only guard against a NaN or Inf result
>>> being produced by the floating-point primitives is the guard against
>>> dividing by zero.  But e.g. in the interpreter (1.0e300 / 1.0e-300)
>>> isInfinite and there is no failure.  So specifically failing for aFloat
>>> / 0.0 seems a bit of a fig leaf to me.
>>>
>>> So what would your ideal semantics be?
>>> a) - fail whenever the result is Inf or NaN?
>>> b) - fail whenever the result is NaN and allow aFloat / 0.0 to answer Inf
>>> c) - fail whenever the result is NaN but fail aFloat / 0.0
>>> d) - the Interpreter status quo, fail only for aFloat / 0.0
>>> e) - never fail and answer Nan and Inf as specified in IEEE 754
>>>
>>> The situation with VW before IEEE was that it did a) and we changed it
>>> so that the mode switch selected either a) or e), with, IIRC, the
>>> current default being e).
>>>
>>
>> f) Fail whenever the result is NaN or when dividing by zero.
>>
>
> OK, to be pedantic that's c) above.  But fine. This is a reasonable choice.
>
>
>> My preference for f) is that division by zero should be consistent between
>> floating point numbers and integers. It would be strange if "1 / 0" => boom
>> but "1.0 / 0" => Inf or "1 / 0.0" => Inf. *However* underflow isn't division
>> by zero and may silently result in Inf. In other words:
>>
>>        self should:[1.0 / 0.0] raise: ZeroDivide.
>>
>> but (#successor produces the smallest float larger than the receiver)
>>
>>        self shouldnt:[1.0 / 0.0 successor] raise: Error.
>>        self assert: (1.0 / 0.0 successor) = Float infinity.
>>
>> Cheers,
>>  - Andreas
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100920/87811bd0/attachment.htm