Of course if you have different concerns split them accordingly.

Stef

On Aug 31, 2008, at 8:25 AM, stephane ducasse wrote:

> create a new entry and funnel all the other ones to the new one.
> Nicolas what would be great is to have one change that group  
> everything else this is really difficult to find the right files
> to file in together.
>
> Stef
>
> On Aug 31, 2008, at 4:46 AM, nicolas cellier wrote:
>
>> SqNumberParser speed up has been introduced a little prematurely in  
>> 3.10.1 image. I uploaded correction for a detail at http://bugs.squeak.org/view.php?id=6976
>>
>> Now all the tests parsing gradual underflow Float should pass again
>> (round to the nearest Float as was the case before the speed up).
>>
>> That's quite some time i spent correcting my own bugs with this  
>> SqNumberParser!
>> - http://bugs.squeak.org/view.php?id=6976 speed up (harvested in  
>> 3.10.1)
>> introduced the bug described above
>> - http://bugs.squeak.org/view.php?id=6982 (not harvested)
>> had a typo
>> - http://bugs.squeak.org/view.php?id=3512 (harvested in 3.9)
>> introduced a bug in ScaledDecimal parsing
>> (see http://bugs.squeak.org/view.php?id=7169)
>> - http://bugs.squeak.org/view.php?id=6779 (in minor fix unstable  
>> 3.10)
>> duplicated this bug in another method
>> so did http://bugs.squeak.org/view.php?id=6982
>>
>> Sorry for inconvenience (don't think any user but me bumped into  
>> these problems however, given that Number readFrom: is far worse  
>> w.r.t. nearest Float, and is still the official Number reader in  
>> the image).
>> Sorry for flooding maintainers too (I think the impact is bigger).
>>
>> Looking at my own code i saw code duplications, not enough comment,  
>> typos in comments.
>> Some will find that using inst var to save some of the parser state  
>> is tricky, but that's another subject (Scanner and parser do the  
>> same). This is the cost of efficiency. And that's why comments are  
>> necessary.
>>
>> Anyway, i refactored a bit, cleaned duplications, added comments,  
>> and added more speed again for LargeInteger using same kind of  
>> divide and conquer trick as http://bugs.squeak.org/view.php?id=6887  
>> (more in another post)
>>
>> All my tests are green. Now, i have a problem for publishing in  
>> mantis. Since the refactoring does interfere with a lot of already  
>> published patches some harvested, some not, some on the way to be  
>> harvested, It might create some problems for harvesters (load order  
>> of Installer mantis ensureFix:).
>>
>> I like the small change sets for they can be adopted independantly  
>> in several distributions, but there Monticello might be more  
>> appropriated.
>>
>> What do you suggest?
>>
>>
>>
>
>
>