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

[Mariano Martinez Peck]

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