Hi. Today I run the tests with the new build 2312 and it is better, at least the Float tests are passing:<br><br><br>9715 run, 9708 passes, 0 expected failures, 5 failures, 2 errors, 0 unexpected passes<br>Failures:<br>FileStreamTest>>#testPositionPastEndIsAtEnd<br>
PCCByLiteralsTest>>#testSwitchPrimCallOffOn<br>AllocationTest>>#testOneGigAllocation<br>MethodContextTest>>#testClosureRestart<br>ReleaseTest>>#testUndeclared<br><br>Errors:<br>MessageTallyTest>>#testSampling1<br>
WeakSetInspectorTest>>#testSymbolTableM6812<br><br><br>Thanks<br><br>Mariano<br><br><div class="gmail_quote">On Mon, Sep 20, 2010 at 4:18 PM, Mariano Martinez Peck <span dir="ltr"><<a href="mailto:marianopeck@gmail.com">marianopeck@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">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?<br>
<br>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. <br>
<br>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.<br><br>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?<br>
<br>Thanks in advance,<br><br>Mariano<br><br><div class="gmail_quote">On Fri, Sep 17, 2010 at 8:20 PM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <br><br><br><div class="gmail_quote"><div class="im">On Thu, Sep 16, 2010 at 10:54 PM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de" target="_blank">andreas.raab@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><br>
On 9/16/2010 2:44 PM, Eliot Miranda wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I realise we need to be more precise. Are you talking about NaNs<br>
specifically or NaN and Inf?<br>
</blockquote>
<br></div>
NaN only. +-Inf are fine as they have a well-defined mathematical relationship over the set of numbers. NaN does not.<div><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
The Squeak VM happily answers Inf from its<br>
float primitives. In fact the only guard against a NaN or Inf result<br>
being produced by the floating-point primitives is the guard against<br>
dividing by zero. But e.g. in the interpreter (1.0e300 / 1.0e-300)<br>
isInfinite and there is no failure. So specifically failing for aFloat<br>
/ 0.0 seems a bit of a fig leaf to me.<br>
<br>
So what would your ideal semantics be?<br>
a) - fail whenever the result is Inf or NaN?<br>
b) - fail whenever the result is NaN and allow aFloat / 0.0 to answer Inf<br>
c) - fail whenever the result is NaN but fail aFloat / 0.0<br>
d) - the Interpreter status quo, fail only for aFloat / 0.0<br>
e) - never fail and answer Nan and Inf as specified in IEEE 754<br>
<br>
The situation with VW before IEEE was that it did a) and we changed it<br>
so that the mode switch selected either a) or e), with, IIRC, the<br>
current default being e).<br>
</blockquote>
<br></div>
f) Fail whenever the result is NaN or when dividing by zero.<br></blockquote><div><br></div></div><div>OK, to be pedantic that's c) above. But fine. This is a reasonable choice.</div><div class="im"><div><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
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:<br>
<br>
self should:[1.0 / 0.0] raise: ZeroDivide.<br>
<br>
but (#successor produces the smallest float larger than the receiver)<br>
<br>
self shouldnt:[1.0 / 0.0 successor] raise: Error.<br>
self assert: (1.0 / 0.0 successor) = Float infinity.<br>
<br>
Cheers,<br><font color="#888888">
- Andreas<br>
</font></blockquote></div></div><br>
<br></blockquote></div><br>
</blockquote></div><br>