While debugging FloatTest>>#testNaNCompare (From http://bugs.squeak.org/view.php?id=6719 FloatNaNCompare-M6719-Test.2.cs),
I had a very strange behavior: Executing in Debugger:
theNaN := Float nan. anotherNaN := Float infinity - Float infinity. comparand := {1. 2.3. Float infinity. 2/3. 1.25s2. 2 raisedTo: 50}. comparand := comparand , (comparand collect: [:e | e negated]). comparand := comparand , {theNaN. anotherNaN}.
I ended up with a comparand filled with some nils. The problem vanished when I did recompile.
Unfortunately I saved the image before I had the idea to inspect the Bytecode and then could not reproduce the problem.
I suspect it is related to http://bugs.squeak.org/view.php?id=6720 . Does anyone experiment this kind of problem?
Nicolas
Good Morning Nicolas,
on Sun, 31 Aug 2008 02:22:23 +0200, you wrote:
While debugging FloatTest>>#testNaNCompare (From http://bugs.squeak.org/view.php?id=6719 FloatNaNCompare-M6719-Test.2.cs),
I had a very strange behavior: Executing in Debugger:
theNaN := Float nan. anotherNaN := Float infinity - Float infinity. comparand := {1. 2.3. Float infinity. 2/3. 1.25s2. 2 raisedTo: 50}. comparand := comparand , (comparand collect: [:e | e negated]). comparand := comparand , {theNaN. anotherNaN}.
I ended up with a comparand filled with some nils. The problem vanished when I did recompile.
Unfortunately I saved the image before I had the idea to inspect the Bytecode and then could not reproduce the problem.
I suspect it is related to http://bugs.squeak.org/view.php?id=6720 . Does anyone experiment this kind of problem?
Yes, sometimes annoying things happen with temp names declared interactively :( for an example, cut all temp names in a source method then ask for pretty print ...
Have you seen Eliot's #parse:class:category:noPattern:context:notifying:ifFail:
- http://www.mirandabanda.org/files/Cog/Closures0808/Bootstrap/changesets/PreR...
in which, while repeatNeeded, a fresh instance of Encoder is assigned. This is not so in stock .images, but perhaps the cure for sorts of problems experienced with declarations made interactively.
HTH.
/Klaus
Nicolas
Klaus D. Witzel a écrit :
Good Morning Nicolas,
Yes, sometimes annoying things happen with temp names declared interactively :( for an example, cut all temp names in a source method then ask for pretty print ...
Have you seen Eliot's #parse:class:category:noPattern:context:notifying:ifFail:
http://www.mirandabanda.org/files/Cog/Closures0808/Bootstrap/changesets/PreR...
in which, while repeatNeeded, a fresh instance of Encoder is assigned. This is not so in stock .images, but perhaps the cure for sorts of problems experienced with declarations made interactively.
HTH.
/Klaus
Thanks, i had an early look, when Eliot published in his blog, but no time to test. I think I will try newer versions in a virgin image because I have some conflicting changes (like http://bugs.squeak.org/view.php?id=2918).
squeak-dev@lists.squeakfoundation.org