3.9-7061 showstopper bug - Mantis #5231

> I consider this to be a showstopper:-
>
> open a workspace
> type in some random stuff
> add a line
>     '3+4'
> 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 logged.
> If you put some evaluable in the middle of the workspace and printit,
> again you get everything up to the printit.

>
> On 12-Oct-06, at 4:57 PM, Brad Fuller wrote:
>
>> tim Rowledge wrote:
>>> I consider this to be a showstopper:-
> [snip]
>> interesting.... I just tried it and the changes were normal. This is in
>> the 34-dev image which is #7061
>> does the amount of random stuff typed make a difference?
>> (I tried '3+4' and 3+4)
>
> Very curious. Starting a new 7061 image on my OSX G5 Mac
>
> open a workspace
> type 3+4 and print it
>
> open the recent log  -
>  ----SNAPSHOT----an Array(12 October 2006 4:47:43 pm)
> NewSourceReferences-7061.image priorSource: 27317!
>
> 3+4!
>
> now type in the workspace 4+2, printit and open the recent log again -
> ----SNAPSHOT----an Array(12 October 2006 4:47:43 pm)
> NewSourceReferences-7061.image priorSource: 27317!
>
> 3+4!
>
> 3+4 7
>
> 4+2!
>
> As you can see, the previous contents of the workspace are logged
> instead of just the code that was evaluated.

> I consider this to be a showstopper:-
>
> open a workspace
> type in some random stuff
> add a line
> '3+4'
> 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  
> logged.
> 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*.
>

>
> 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
>> '3+4'
>> 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  
>> logged.
>> 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:
>
> http://bugs.impara.de/view.php?id=3331
>
> 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.
>
>      Marcus
>

> 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.
>
> Cheers,
>
>  -- Scott
>
>
>
> <1025evalFix-sw.cs.gz>
>
>
> 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
>>> '3+4'
>>> 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  
>>> logged.
>>> 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:
>>
>> http://bugs.impara.de/view.php?id=3331
>>
>> 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.
>>
>>      Marcus
>>
>
>

> 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.

> I consider this to be a showstopper:-
>
> open a workspace
> type in some random stuff
> add a line
> '3+4'
> 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  
> logged.
> 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*.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> "Bother" said Pooh, as his trigger finger tired.
>
>
>

>
> On 14.10.2006, 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.
>
> No, there was no good reason... just a lack of energy.
>
>     Marcus