Thanks Scott.
from the timestamp I think that this is the notification mechanism  
from nathanael.
We will see if we can introduce it in 3.9

Stef

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