[squeak-dev] SqNumberParser refactoring
stephane.ducasse at free.fr
Sun Aug 31 06:26:32 UTC 2008
Of course if you have different concerns split them accordingly.
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.
> 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
>> - http://bugs.squeak.org/view.php?id=6976 speed up (harvested in
>> 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
>> 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
>> 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
>> What do you suggest?
More information about the Squeak-dev