[squeak-dev] SqNumberParser refactoring

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

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

>
>
> El 8/31/08 3:25 AM, "stephane ducasse" <[hidden email]> escribió:
>
>> 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
>
>
> That's why in past we have only one person in charge , only a source of
> loading updates (the updates folder in ftp) and only a process for submit,
> review, discuss and at some point put in the stream.
>

> Dear Nicolas,
>> You are right on one point, it's too easy to introduce a typo in
>> mantis Installer hooks or PBWiki unstable branch scripts, making the
>> overall construction fragile (I made several myself). But that's only
>> the first stage of harvesting chain.
> Indeed it is only the first step.
>> It seems to me that PBwiki does have some filter at next level, though
>> I did not understand exactly the process for moving changes from
>> Unstable to Stable branch.
>>
>> And PBWiki relaxes a bit the hard job of reviewing/harvesting patches
>> from mantis, using a more collaborative way.
>> Installer and PBWiki are just tools for harvesters, like mantis is.
>> They help working around some of the mantis problems.
> The purpose of putting scripts on installer.pbwiki.com is so that those
> scripts can be loaded into 'any' image with the minimum of Installer or
> at best LPF loaded. This scenario is intended to enable the user to see
> and select what to apply to their own images. Its a place to easily try
> out and publish sets of fixes, temporarily, in lieu of a more formal
> process which will need more than just Installer/LPF.
>
> This is not the same as the more controlled formal process of building
> the next (3.11) release. For details of this more formal process...
>
> If you load into a 3.10 image...
>
> Installer install: 'Tasks'.
>
> You will find classes ReleaseAfterSqueak310 and
> ReleaseAfterSqueak310Unstable, the method #taskBugFixes has your bug
> fixes, as migrated from the original harvested
> installer.pbwiki.com/MinorFixesUnstable-Squeak3:10 page. You can now
> contribute your fixes to this package in repository:
> http://www.squeaksource.com/Tasks package: Tasks-Squeak3.10"
>
> To build a 3.11u (unstable test candidate) for yourself run the
> following command line...
>
> .../vm/squeak /Squeak/pr_next/Squeak3dot10.7159.image
> http://installer.pbwiki.com/f/LPF.st Installer
> do="NextUnstableCandidate" SmalltalkImage save=Squeak3.11u2
>
> This will soon be included in our automated build and testing tool
> "Bob", but for now you can give it a go. It's not quite there yet since
> the script doesnt run to completion as yet but you should get the
> general idea. As the script runs, the mantis reports for every fix
> loaded are collated and added to the instance side of
> ReleaseAfterSqueak310Unstable as documentation.
>
> best regards
>
> Keith
>
>
>
>

> Hi,
>
>> The purpose of putting scripts on installer.pbwiki.com is so that those
>> scripts can be loaded into 'any' image with the minimum of Installer or
>> at best LPF loaded.
>
> The scripting idea is valuable when you want to "run" scripts (to
> produce output data) on a solid+fat+stable defined
> core of functions+components exposed by the scripting
> engine/compiler...
> It is not the case for smalltalk systems, where any change can
> be done on the system, during an installation the intent is to
> produce change in the system, and the most valuable attribute
> of the system itself is it´s stability.
> (a very diferent scenario to where use of scripting has
> proven to be good)
>
>> This scenario is intended to enable the user to see
>> and select what to apply to their own images.
>
> The real problem here is that "the user" (the owner of the
> system under my pov) must ask/respond without
> seen/understanding what will be injected and also without
> understanding some areas of the system that will be affected
> by the "script" (a script that is written by a person that do not
> know about the system it is been installed).

>
> I consider that it is not enough to "see"/read the package
> intention, if the injection(ingestion?) of changes to the system
> is fast, "the user" will receive also more uncertaninty about
> the stability of the system .
> Incremental (and fine grained) incorporation of pieces in a
> guided tour can be more effective; e.g. it is better to make
> incorporations of features as much slow as possible, to let
> the person learn about what is been incorporated and
> act/ask/reflect while understanding what is included.
>