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?

Edgar J. De Cleene a écrit :

El 8/31/08 3:25 AM, "stephane ducasse" stephane.ducasse@free.fr 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.

You are right, some form of inertia is needed to filter proposed/incoming changes and harvesters have to sharpen and exercize their criticism hard. This is a difficult job, because some problems are detected lately only when patches are in use. That's why some kind of quarantine provided by an Unstable branch is a good idea. It is complementary to SUnitTests which should be the major tool, but I would not engage the life of my son on the sole guarantee of SUnitTests completeness, would you?.

Installer opens the Pandora Box, I was guilty on adopt it at the beginning of 3dot10 release.

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.

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.

And I think the policy of having scripts external and in sites which is not in control of Squeakers is , well, a disaster waiting to happen.

It is still possible to warn then blacklist any undesired person not adhering the rules, isn't it, so things are (should be) under control.

Or maybe Squeak is only for Masters now.

I don't understand this. Concerning harvesting team, age and wisdom are required qualities for at least one member, and having a master in such team would not hurt, would it?

Edgar

2008/8/31 Edgar J. De Cleene edgardec2001@yahoo.com.ar:

El 8/31/08 11:06 AM, "nicolas cellier" ncellier@ifrance.com escribió:

...

I don't understand this. Concerning harvesting team, age and wisdom are required qualities for at least one member, and having a master in such team would not hurt, would it?

I meaning in the past , many who begins with Squeak only need hit the updates button.

Now , seems people need more.

You and lots of people do a terrific work in Mantis. Mantis is a tool still all need learn how to use , until some better tool arise.

Concerning Mantis. Take a look at Seaside people, who using a code.google to track issues. Choosing and migrating to new issue tracker could help , but only if we will be sure that we will not end up with a tons of reported bugs which no-one cares to fix and review.

One of idea to make use of Mantis more convenient is to create a bug fixes hubs and collect all fixes in them, so instead of doing search/filtering on issues by category, you simply open a report named 'fixes included into Squak X.Y.unstable', where everyone could see a progress and ask to test/include own fix.

...

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.

It's not bad do all kinds of experiments, I doing all the time. When at some point we discover our mistakes, we should recognize and go back to the right way.

But Squeak is about objects, I believe. For scripting , many others languages like Perl exist.

Ralph teach me to avoid Doits and all should go to Classes and Methods.

I made tons of mistakes in 3dot10 ! Take two releases all know Monticello could't manage a complete release. I very confident in Monticello 2 and maybe some of DeltaStreams could do the trick.

Sure Test is not a silver bullet, but is some useful.

And we are people , not computers , so at some point we should made hand work.

Edgar

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.

If we let "smalltalk users" continue incorporating and using instant features, the effect is similar to copy&paste ("problems" appears when peolpe do not have time to think about it).

best, Ale.

----- Original Message ----- From: "Keith Hodges" keith_hodges@yahoo.co.uk To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Sunday, August 31, 2008 4:24 PM Subject: Re: [squeak-dev] Re: SqNumberParser refactoring

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

2008/9/1 Alejandro F. Reimondo aleReimondo@smalltalking.net:

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.

If we let "smalltalk users" continue incorporating and using instant features, the effect is similar to copy&paste ("problems" appears when peolpe do not have time to think about it).

Sure, a mistake made by "smalltalk user" can lead to problems, which: a) easy to reproduce , since scripts is provided b) easy to fix , because of a) c) easy to distribute fix, by fixing a script

and compare this to a mistake, done by a "master" who did something which only he can understand, and which only he could fix, and as its often happens, have no time/will/money to spend fixing the problem he once introduced.

best, Ale.