Seems to me that it could be worth to have a look at this one.
Begin forwarded message:
From: "Klaus D. Witzel" <[EMAIL PROTECTED]>
Date: August 31, 2008 10:24:56 AM CEDT
To: [EMAIL PROTECTED]
Subject: [squeak-dev] Re: Bytecode not in sync with source?
Reply-To: The general-purpose Squeak developers list <[EMAIL PROTECTED]
>
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/PreRecompilationPatches.1.cs
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
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
