Begin forwarded message:
From: nicolas cellier <[EMAIL PROTECTED]>
Date: August 31, 2008 4:46:31 AM CEDT
To: [EMAIL PROTECTED]
Subject: [squeak-dev] SqNumberParser refactoring
Reply-To: The general-purpose Squeak developers list <[EMAIL PROTECTED]
>
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?
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
