[Vm-dev] failing/errors Pharo Tests with CogVM
Mariano Martinez Peck
marianopeck at gmail.com
Thu Sep 23 07:32:14 UTC 2010
Hi. Today I run the tests with the new build 2312 and it is better, at least
the Float tests are passing:
9715 run, 9708 passes, 0 expected failures, 5 failures, 2 errors, 0
unexpected passes
Failures:
FileStreamTest>>#testPositionPastEndIsAtEnd
PCCByLiteralsTest>>#testSwitchPrimCallOffOn
AllocationTest>>#testOneGigAllocation
MethodContextTest>>#testClosureRestart
ReleaseTest>>#testUndeclared
Errors:
MessageTallyTest>>#testSampling1
WeakSetInspectorTest>>#testSymbolTableM6812
Thanks
Mariano
On Mon, Sep 20, 2010 at 4:18 PM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:
> 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/20100923/5f7fadea/attachment.htm
More information about the Vm-dev
mailing list