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

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

by StÃ©phane Ducasse

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. I do not know what is the configuration option. Stef On Sep 29, 2008, at 9:00 PM, Simon Kirk wrote: > Hi all. > > Not sure where I should report this. If I use the middle/right > (depending on one's preferences) click World menu (the one with > Project and Configuration sub-menus down towards the bottom third of > the menu), when my mouse goes over the "Configuration" menu section, > the entire image freezes irrevocably, at least on OSX (my VM). > > A few fast-hit alt-. efforts can bring up a debugger on the current > process, but it too is frozen. > > Don't know if this was already something knew about. Sorry for the > duplication if so. > > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 29, 2008

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

by StÃ©phane Ducasse

On Sep 29, 2008, at 9:00 PM, Simon Kirk wrote: > Hi all. > > Not sure where I should report this. If I use the middle/right > (depending on one's preferences) click World menu (the one with > Project and Configuration sub-menus down towards the bottom third of > the menu), when my mouse goes over the "Configuration" menu section, > the entire image freezes irrevocably, at least on OSX (my VM). Did you check if you have the preference to warn deprecated method on? Because when I do the same as you I get a currentProjectRefactoring.... > A few fast-hit alt-. efforts can bring up a debugger on the current > process, but it too is frozen. > > Don't know if this was already something knew about. Sorry for the > duplication if so. No report It also shows that we have to clean this menu.

Sept. 29, 2008

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

by StÃ©phane Ducasse

this is not clear yet, but SqueakMap will not be kept as a way to load code. So this is normal that your code does not load with squeakmap. stef On Sep 29, 2008, at 9:16 PM, 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. > > Best regards, > Dan Corneanu. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 29, 2008

[Pharo-project] SqueakMap Packae Loader - nil object

by Dan Corneanu

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. Best regards, Dan Corneanu.

Sept. 29, 2008

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

by StÃ©phane Ducasse

> We will see at the end what was the better Idea ;-) Good challenge :) I will integrate a bit more etoys now. Stef

Sept. 29, 2008

Re: [Pharo-project] How do we manage todos?

by StÃ©phane Ducasse

ok but there are todos :) Stef On Sep 29, 2008, at 8:16 PM, Norbert Hartl wrote: > On Mon, 2008-09-29 at 10:51 +0200, Marcus Denker wrote: >> On 28.09.2008, at 21:40, StÃ©phane Ducasse wrote: >> >>> I would prefer a bugtraker with a tag todo that are not bug fixes. >> >> Ok. Then we can split up the one entry that has all the TODOs. >> > Ok, there are things that are more _to do_ than others? :)) > > Norbert > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 29, 2008

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

by Simon Kirk

Hi all. Not sure where I should report this. If I use the middle/right (depending on one's preferences) click World menu (the one with Project and Configuration sub-menus down towards the bottom third of the menu), when my mouse goes over the "Configuration" menu section, the entire image freezes irrevocably, at least on OSX (my VM). A few fast-hit alt-. efforts can bring up a debugger on the current process, but it too is frozen. Don't know if this was already something knew about. Sorry for the duplication if so. 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: [Pharo-project] How do we manage todos?

by Norbert Hartl

On Mon, 2008-09-29 at 10:51 +0200, Marcus Denker wrote: > On 28.09.2008, at 21:40, StÃ©phane Ducasse wrote: > > > I would prefer a bugtraker with a tag todo that are not bug fixes. > > Ok. Then we can split up the one entry that has all the TODOs. > Ok, there are things that are more _to do_ than others? :)) Norbert

Sept. 29, 2008

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

by Marcus Denker

>> >> So fixes are not integrated into the image anymore and the report >> then >> closed? > When a release image is released the fixes are integrated into the > image > as normal, and can be closed or marked "fixed". > 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? > 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. Especially as 3.7 is very different to 3.9 (just the I18N stuff will kill you). 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, 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. You can not do anything even remotely complex if any changeset that fixes something in 3.11 needs to work on 3.7, too. > >> What I don't understand with the use of Installer with mantis >> entries: >> From my >> experience from 3.6 to 3.9, there is quite some dependency between >> fixes. > Nothing is automatic, if you or some script loads the wrong fix in the > wrong order then that is a problem. And of course this means that nobody can load any other order, so it makes no sense to have all the fixes as entities on their own at all. >> >> to build "your own release". This just can't work with all the >> dependencies between >> fixes. > However, the old way, fixes are applied to a moving target, since the > alpha image is continuously being updated. Yes, this is very important. As loading a fix for 3.10 into the developement version of 3.11 will almost never work, as other fixes already changed the sytem. This is true even with the installer. So you will end up in using the "moving target" of 3.10+ Intaller as your "HEAD" system that people use when doing changes. Else you will end up in many changesets that have conflicts, and, very annoyting, hundreds of douple-reports of bugs. > With this approach fixes > applied to 3.10 (a fixed target) are used to create a 3.11 unstable > until the combination of fixes is deemed "stable" 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. You can never manage the amount of changes submitted if you can just say: "rejected. reason: conflicts with current version. Please resubmit". Another very important principle is to close reports on the bugtracker as soon as possible to keep it managable. 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). Overall, I am 100% sure that your idea how to manage 3.11 is fundamentally wrong (sorry). 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. We will see at the end what was the better Idea ;-) Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 29, 2008

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

by StÃ©phane Ducasse

another point 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). Stef

Sept. 29, 2008