3.9-7061 showstopper bug - Mantis #5231
stephane.ducasse at gmail.com
Sat Oct 14 15:03:25 UTC 2006
from the timestamp I think that this is the notification mechanism
We will see if we can introduce it in 3.9
On 14 oct. 06, at 14:33, Scott Wallace wrote:
> The bug was not only present in 3.8, it was already present in 3.7.
> It arrived in update "5706KCP170CompilerPrtclRefactor", in a method
> timestamped "NS 1/28/2004". So, amazingly, the community has been
> tolerating this showstopping bug in its "stable" releases for more
> than 2.5 years.
> I personally was unwilling to live with the bug for even a day,
> once I encountered it; so for me, as for Tim, this was a
> showstopper, no irony intended. Not only can the .changes file
> get quickly filled with arbitrarily large amounts of arbitrary
> text, but the unformatted logging of arbitrary text causes havoc
> with attempts of the ChangeList browser to parse chunks from
> the .changes file. So to me this was a completely intolerable bug.
> I quickly tracked down the cause to the "Kernel Cleaning Project,"
> in the change-set mentioned above. I couldn't immediately devise
> an obvious, elegant fix, but I did settle on a workaround that did
> the job, however unappetizingly. Since that time there have been
> two further advances on the method, one for TinLizzie (for Tweak
> compatibility) and the latest for OLPC.
> I attach the fileout that constitutes the latest OLPC incarnation
> of this method, which is more robust than the Squeakland version.
> I don't know how this would integrate with 3.9 -- Marcus must have
> had good reasons for not porting it 3.9 -- but I offer it FWIW.
> -- Scott
> On Oct 13, 2006, at 12:21 AM, Marcus Denker wrote:
>> On 13.10.2006, at 01:38, tim Rowledge wrote:
>>> I consider this to be a showstopper:-
>>> open a workspace
>>> type in some random stuff
>>> add a line
>>> and print it on the '3+4'
>>> Now use menu->changes->recent log file... to see what got put in
>>> the changes log.
>>> Whoops! Everything in the workspace up to the code printit'd is
>>> If you put some evaluable in the middle of the workspace and
>>> printit, again you get everything up to the printit.
>>> We can't let this go out for general use - it will fill the
>>> changes log much faster than anyone could ever expect and would
>>> completely break the logic of recovering your state by executing
>>> the recent changes file since many things would get repeated
>>> repeatedly. Not to mention, the entire text in the recovered file
>>> up to the chunk being evaluated would get logged *again*.
>> This does not seem to be 3.9 specific, as there was a fix for that
>> in squeakland...
>> I did not merge 3 of 150 changesets, and this is one of those:
>> Change Set: twoFixes-sw
>> Date: 12 November 2005
>> Author: Scott Wallace
>> Fixes the bug that logged the entire contents of a text pane up
>> through the end of the current selection, rather than only the
>> current selection, when logging a do-it to the changes.
>> If this is in 3.8, too, then by definition it is not a show
>> stopping bug. (As the show was not stopped with 3.8). So this
>> would need to be checked.
More information about the Squeak-dev