September 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] OB's icon support improved

by David RÃ¶thlisberger

> why the down cyan arrow is not a down cyan arrow with a down orange > arrow? (may be this is ugly but it would be > more consistent). well, we have a cyan square for an abstract method without sub-implementation, so for those with sub-impl., we could have a small cyan square with an orange down arrow. But I think the current cyan down arrow looks much better. David

Sept. 30, 2008

Re: [Pharo-project] OB's icon support improved

by David RÃ¶thlisberger

> So I miss the pane showing the comment under the class def. yes, true. I need to how to to that. What we have in the multiple selection browser is the mechanism to automatically get the class comment on the right of the class def panel in a second panel. > May be a good way also would be to have the question mark with a > different color when there is a comment. Or in red when there's no comment. > David we are starting to use manifesto for package so it would be > also great to show them. Ok. Do you have an example of a package using it? Moose? David

Sept. 30, 2008

Re: Installer was: Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Igor Stasenko

I like the Installer. Its a simple tool to break your work onto multiple stages/packages. It is very useful for making automatic builds. No manual image hacking - instead you have to fix the scripts or packages. This will guarantee that every time you will load the same code as before, w/o losing or forgetting something. -- Best regards, Igor Stasenko AKA sig.

Sept. 30, 2008

[Pharo-project] Integrate early and release often and tests was: Installer was: Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Simon Kirk

Hi all. Apropos of the conversation this subject line evolved from, I was thinking about this from Marcus: "Pharo will do it completely differently: release often, integrate as soon as possible, keep the bugtracker down to managable levels and do not be religiously backwards-compatible." This lead me to think various comments recently from Stef (I think - I apologise if I'm miss-paraphrasing, but I can't find the exact messages) about how to tell which tests have failed/passed etc as the versions go by. I submit that in order for early integration and regular release to work, it needs to be an "all tests green or nothing" situation. Of course, it's very difficult to make sure all the tests are passing, but I just ran *all* the tests in the system, and there's only one error and one failure. This is fantastic work! Not only that but the error is down to BookMorph (due for removal iirc?) and a #printString problem with Array, the latter of which *has* to be simple to fix. If this level of passing tests (or even better, all of them; not necessarily possible as various things like EToys are stripped out I imagine) is maintained, there's no need to tell what tests have changed state from version to version; moreover Pharo will be far the better for it, imho. Just my â¬0.02 :) Cheers, Simon ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Sept. 29, 2008

Re: Installer was: Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Simon Kirk

FWIW I am 100% behind "release often, integrate as soon as possible". Not only this but you only have to do a small amount of googling to begin to realise that *finally* the computing world is getting the sea change required to make this approach the main stream, rather than the BUF* (release planning in this case). I'm not trying to invalidate people taking other approaches: I simply don't think they're the best way to do things. If those people working hard on Pharo can stick to the guns of this approach (and it's not an easy approach), I think it will be the right one. I'm sorry I don't have more time to give myself, but I try to keep myself useful from time to time. Cheers, Simon On 29 Sep 2008, at 20:55, Keith Hodges wrote: > >> Release image? that means, you will not close *any* bug-report until >> you release >> 3.11? Wow. But you sure close at least duplicated bug-reports? > Wow what? The release will know which bug fixes are included and > provide > a list of fixes which can be closed, when the release is actually > ready > and available. >>> Everything that I have been developing loads into "all" existing >>> images, >>> so for example, LPF may want to load fixes into 3.7 if it needs >>> something. >> >> So does this make sense? I think there is not enough manpower to >> even get >> *one* stable and *one* development branch going. Beeing backtward >> compatible to >> such old releases makes no sense. > So why does Seaside, Magma etc run in older images? > > Please think sensibly, we are not trying to make "everything" work in > all images. Just to enable the things that we want to work when > necessary. > > Last year I found myself working in 3.8, 3.9 and 3.10, maintaining > different packages in different images. For example I would have to > have > an image especially configured just for developing contributions to > Seaside. I ended up running about 12 different images. Simply > because MC > would not handle method extensions and overrides correctly. > > So essential step... "make MC run identically in all images, and make > overrides and extensions work"... in the process benefit the whole > community. >> Especially as 3.7 is very different to 3.9 >> (just the I18N stuff will kill you). > It wont kill me since I am not using it. > > The point is that there are people actually using 3.7 and 3.8 for > things. Up until recently Gjallar was using 3.8. The transition to > 3.10 > was achieved by building the image in 3.8 using an installer script, > then migrating that script and the packages involved to work with both > 3.8 and 3.10. Finally the script was run to generate a 3.10 image. >> In the end, what you are doing will result in kind of re-doing 3.8 >> for >> 3.7, >> 3.9 for 3.8... and so on, > Not really. > > To get Monticello 1.5 working in 3.7 requires something like 5-6 > methods > to be added to the base image. Necessary changes to Kernel are usually > very minimal. >> in addition to actually doing 3.11. >> Is that realistic? >>> Previously fixes are ONLY available by waiting for the >>> release team to harvest, or by manually loading a changeset in >>> yourself. >>> Now the harvesters can make a fix readily available for everyone >>> through >>> Installer. >>> >>> This attitude of supporting all users of squeak, while moving things >>> forward for everyone, is a core-value of the 3.11 team. >> >> This is *the* recipe for failure. > There is no need to be so dramatic. > > We have been doing this for a while now and have seen nothing but > success. LPF is useful it works and has worked for lots of people, > whereas before the Croquet community and the XO community were > destined > to be out on their own. I now know that I can load my website up on my > XO, and I fully expect to be able to try Rio out in Croquet. >> You can not do anything even remotely >> complex if any changeset that fixes something in 3.11 needs to work >> on >> 3.7, too. > I never said that it would "have to", but it can if necessary. >> However, the old way, fixes are applied to a moving target, since the >> >> But this can not work: fixes depend on each other. It is *one of >> the most >> important principles* to let the submitter of fixes do the work of >> merging >> his fix with the latest fix applied to the image. Else you will die. > That's a bit dramatic, I am not planning on dying any time soon. >> You can never manage the amount of changes submitted if you can >> just say: >> "rejected. reason: conflicts with current version. Please resubmit". > We dont need to say that at all. We can say, here is an image, (or > here > is a script which builds the image) in which your fix is loaded and > needs further work. >> Another very important principle is to close reports on the >> bugtracker as >> soon as possible to keep it managable. > I don't see that, but then I am not looking at the BugTracker to read > bug reports. I periodically export reports into squeak, so I am look > at > them in my class browser where each report is a method that I can > categorize. >> This even means that once a changeset >> is harvested, the report is closed *and not re-opend* if there is a >> new bug >> after applying. That is a *new* report, for a *new* bug (the report >> then will >> of course refrence the faulty closed report). > Sounds fair enough. But I dont think you are understanding the > "release" > is an atomic event. Fixes can get tweaked improved up until the > release. >> Overall, I am 100% sure that your idea how to manage 3.11 is >> fundamentally wrong >> (sorry). > Your approach is based around small incremental changes to an image, > performed by a single person. In particular it is easier to add things > than to remove things. Overall it results in an adhoc process that > lacks > planning. It lacks control over the big picture. Everyone ends up > following the one person doing the release. The release team do what > they want in whatever order they want to do it. No one knows what the > plan is in advance and there is no mechanism provided for people to > contribute into the work. > > We have 3.11 fully planned, the script to generate the test-candidate > runs, from end to end. Contributors can add their fix-tasks to that > script. >> And Pharo will do it completely differently: release often, integrate >> as soon >> as possible, keep the bugtracker down to managable levels and do not >> be religiously >> backwards-compatible. > This is a cop out, it is taking a process that could be a slope and > making it a step, but you are pretending that it will be a slope by > saying nice things like "release often" and "integrate asap". Squeak > has > never been release often or integrate as soon as possible. The reason > for this is nothing to do with squeak, it is to do with PROCESS. The > Squeak 3.7 3.8 3.9 PROCESS did not support these ideals. So unless the > Pharo process has changed, the pharo process will not be any > different. > > However, the 3.11 development has been entirely about creating a > process > that will support "release often" and that we could do monthly time > boxed releases with. >> We will see at the end what was the better Idea ;-) > I have always maintained that Pharo's goals and 3.11's goals are > essentially the same. > > Keith > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Sept. 29, 2008

Re: [Pharo-project] Total image lockup when using middle/right click menu on world

by Simon Kirk

Thanks Marcus (and Stef) - glad there's a fix, and now I know in future where to look for bugs that I may find, and to report them. On 29 Sep 2008, at 20:34, Marcus Denker wrote: > > On 29.09.2008, at 21:29, StÃ©phane Ducasse wrote: > >> Good catch, if I press proceed then my image gets blocked >> can you enter a bug entry? >> And really another menu with lot of things to clean or we should >> simply get rid of it. >> > > Fix: http://code.google.com/p/pharo/issues/detail?id=191 > > > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Sept. 29, 2008

Re: Installer was: Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Keith Hodges

StÃ©phane Ducasse wrote: > > >> We will see at the end what was the better Idea ;-) > > Good challenge :) > I will integrate a bit more etoys now. > > Stef Not a challenge I am taking up, I have a ball joint to replace on my car, and no time to input into this at the moment. Keith

Sept. 29, 2008

Re: Installer was: Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Keith Hodges

> Release image? that means, you will not close *any* bug-report until > you release > 3.11? Wow. But you sure close at least duplicated bug-reports? Wow what? The release will know which bug fixes are included and provide a list of fixes which can be closed, when the release is actually ready and available. >> Everything that I have been developing loads into "all" existing images, >> so for example, LPF may want to load fixes into 3.7 if it needs >> something. > > So does this make sense? I think there is not enough manpower to even get > *one* stable and *one* development branch going. Beeing backtward > compatible to > such old releases makes no sense. So why does Seaside, Magma etc run in older images? Please think sensibly, we are not trying to make "everything" work in all images. Just to enable the things that we want to work when necessary. Last year I found myself working in 3.8, 3.9 and 3.10, maintaining different packages in different images. For example I would have to have an image especially configured just for developing contributions to Seaside. I ended up running about 12 different images. Simply because MC would not handle method extensions and overrides correctly. So essential step... "make MC run identically in all images, and make overrides and extensions work"... in the process benefit the whole community. > Especially as 3.7 is very different to 3.9 > (just the I18N stuff will kill you). It wont kill me since I am not using it. The point is that there are people actually using 3.7 and 3.8 for things. Up until recently Gjallar was using 3.8. The transition to 3.10 was achieved by building the image in 3.8 using an installer script, then migrating that script and the packages involved to work with both 3.8 and 3.10. Finally the script was run to generate a 3.10 image. > In the end, what you are doing will result in kind of re-doing 3.8 for > 3.7, > 3.9 for 3.8... and so on, Not really. To get Monticello 1.5 working in 3.7 requires something like 5-6 methods to be added to the base image. Necessary changes to Kernel are usually very minimal. > in addition to actually doing 3.11. > Is that realistic? >> Previously fixes are ONLY available by waiting for the >> release team to harvest, or by manually loading a changeset in yourself. >> Now the harvesters can make a fix readily available for everyone through >> Installer. >> >> This attitude of supporting all users of squeak, while moving things >> forward for everyone, is a core-value of the 3.11 team. > > This is *the* recipe for failure. There is no need to be so dramatic. We have been doing this for a while now and have seen nothing but success. LPF is useful it works and has worked for lots of people, whereas before the Croquet community and the XO community were destined to be out on their own. I now know that I can load my website up on my XO, and I fully expect to be able to try Rio out in Croquet. > You can not do anything even remotely > complex if any changeset that fixes something in 3.11 needs to work on > 3.7, too. I never said that it would "have to", but it can if necessary. > However, the old way, fixes are applied to a moving target, since the > > But this can not work: fixes depend on each other. It is *one of the most > important principles* to let the submitter of fixes do the work of > merging > his fix with the latest fix applied to the image. Else you will die. That's a bit dramatic, I am not planning on dying any time soon. > You can never manage the amount of changes submitted if you can just say: > "rejected. reason: conflicts with current version. Please resubmit". We dont need to say that at all. We can say, here is an image, (or here is a script which builds the image) in which your fix is loaded and needs further work. > Another very important principle is to close reports on the bugtracker as > soon as possible to keep it managable. I don't see that, but then I am not looking at the BugTracker to read bug reports. I periodically export reports into squeak, so I am look at them in my class browser where each report is a method that I can categorize. > This even means that once a changeset > is harvested, the report is closed *and not re-opend* if there is a > new bug > after applying. That is a *new* report, for a *new* bug (the report > then will > of course refrence the faulty closed report). Sounds fair enough. But I dont think you are understanding the "release" is an atomic event. Fixes can get tweaked improved up until the release. > Overall, I am 100% sure that your idea how to manage 3.11 is > fundamentally wrong > (sorry). Your approach is based around small incremental changes to an image, performed by a single person. In particular it is easier to add things than to remove things. Overall it results in an adhoc process that lacks planning. It lacks control over the big picture. Everyone ends up following the one person doing the release. The release team do what they want in whatever order they want to do it. No one knows what the plan is in advance and there is no mechanism provided for people to contribute into the work. We have 3.11 fully planned, the script to generate the test-candidate runs, from end to end. Contributors can add their fix-tasks to that script. > And Pharo will do it completely differently: release often, integrate > as soon > as possible, keep the bugtracker down to managable levels and do not > be religiously > backwards-compatible. This is a cop out, it is taking a process that could be a slope and making it a step, but you are pretending that it will be a slope by saying nice things like "release often" and "integrate asap". Squeak has never been release often or integrate as soon as possible. The reason for this is nothing to do with squeak, it is to do with PROCESS. The Squeak 3.7 3.8 3.9 PROCESS did not support these ideals. So unless the Pharo process has changed, the pharo process will not be any different. However, the 3.11 development has been entirely about creating a process that will support "release often" and that we could do monthly time boxed releases with. > We will see at the end what was the better Idea ;-) I have always maintained that Pharo's goals and 3.11's goals are essentially the same. Keith

Sept. 29, 2008

Re: [Pharo-project] SqueakMap Packae Loader - nil object

by Marcus Denker

On 29.09.2008, at 21:16, Dan Corneanu wrote: > Hi, > there is an exception when trying to open SqueakMap Package Loader in > the latest pharo/pharo-dev images with the latests updates. > The object instance variable of SMSqueakMap is nil. > I'm not sure if I should have put an issue on the tracker or not. http://code.google.com/p/pharo/issues/detail?id=193 (even though it will be removed... but even if the world endet tomorrow, one should plant a tree or so someone famous once said) Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 29, 2008

Re: [Pharo-project] Total image lockup when using middle/right click menu on world

by Marcus Denker

On 29.09.2008, at 21:29, StÃ©phane Ducasse wrote: > Good catch, if I press proceed then my image gets blocked > can you enter a bug entry? > And really another menu with lot of things to clean or we should > simply get rid of it. > Fix: http://code.google.com/p/pharo/issues/detail?id=191 -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 29, 2008