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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1025evalFix-sw.cs.gz
Type: application/x-gzip
Size: 1180 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20061014/5b5c3895/1025evalFix-sw.cs.bin
-------------- next part --------------


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
>