- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Move to package from sender and implementors list

by David RÃ¶thlisberger

> I added an issue on this. > Probably what I did with the 'move package' in OB can be adapted. I will > work on this. It's actually already there in the senders and implementors browser of OB. The command you wrote is available for method and message nodes. David > On 25 Sep 2008, at 13:29, StÃ©phane Ducasse wrote: > >> Hi guys >> >> it would be great to have the senders and implementors tools >> offering move to package in their menus. >> >> Stef

Sept. 25, 2008

Re: [Pharo-project] On Icons

by Igor Stasenko

2008/9/25 David RÃ¶thlisberger <squeak(a)webcitas.ch>: > Hi Igor, > >> I know, determining all senders could be a slow operation (especially >> when you need to scan a list of them), but maybe there can be used >> some kind of optimizations like lazy/background evaluation? > > I like this idea, but indeed, performance is a big issue here. I haven't > found a solution yet to make this efficient enough. > Lazy/background evaluation would require us to store this information > directly in the compiled method object, something that I would rather not > like to do. In particular updating the information when suddendly a method > gets or loses its sender(s) might get difficult. Not necessary in methods. OB can hold a set of selectors which have no senders and update it periodically (when system changed). > > > David > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 25, 2008

[Pharo-project] Just for fun...

by StÃ©phane Ducasse

Hi guys guess what... The old preferencePanelWindow is defined and created within the class Preferences of course preferencesControlPanel I will kill it. Stef

Sept. 25, 2008

Re: [Pharo-project] Move to package from sender and implementors list

by Alexandre Bergel

I added an issue on this. Probably what I did with the 'move package' in OB can be adapted. I will work on this. Alexandre On 25 Sep 2008, at 13:29, StÃ©phane Ducasse wrote: > Hi guys > > it would be great to have the senders and implementors tools > offering move to package in their menus. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 25, 2008

[Pharo-project] Move to package from sender and implementors list

by StÃ©phane Ducasse

Hi guys it would be great to have the senders and implementors tools offering move to package in their menus. Stef

Sept. 25, 2008

Re: [Pharo-project] about preparing the first release

by Bill Schwab

Stability takes at least two forms: the system works AND is not going to experience violent change. Given that more of the latter is possible/expected, it might be better to start at 0.1. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> adi(a)netstyle.ch 09/25/08 5:21 AM >>> On Sep 25, 2008, at 11:12 , Damien Cassou wrote: > On Wed, Sep 24, 2008 at 10:49 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: >> I'd suggest the common major.minor[.maintenance] scheme starting >> with "1.0". > > I would not start with "1.0" because it means this is already stable > enough for anyone to rely upon. isn't this exactly the goal of the release?! Only if the shipped version is reasonably stable the people will use it... Adrian _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 25, 2008

Re: [Pharo-project] On Icons

by David RÃ¶thlisberger

Hi Igor, > I know, determining all senders could be a slow operation (especially > when you need to scan a list of them), but maybe there can be used > some kind of optimizations like lazy/background evaluation? I like this idea, but indeed, performance is a big issue here. I haven't found a solution yet to make this efficient enough. Lazy/background evaluation would require us to store this information directly in the compiled method object, something that I would rather not like to do. In particular updating the information when suddendly a method gets or loses its sender(s) might get difficult. David

Sept. 25, 2008

Re: [Pharo-project] About traits support in OB

by David RÃ¶thlisberger

>> What do you think, should I change it like this or not? > > Give a try. I think that this is worth. ok, good, I will. David

Sept. 25, 2008

Re: [Pharo-project] On Icons

by StÃ©phane Ducasse

Thanks.! Stef > >>> something I would love to have..... >>> is a means to know whether a method is defined in multiple class >>> or only >>> the one I'm browsing. >> There is the annotation panel (to enable in the preferences) that >> shows this and other similar information. It slows everything down >> though. > > The main reason for the annotation panel to be so slow is that it > accesses all change sets to find out from where the current methods > origins... Actually, we could disable this access to the change sets > in the Preferences: #defaultAnnotationRequests. > > If we just show whether there is one or more implementor of a > method, then this will be much faster. We could introduce yet > another icon for this. ;) > > David > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 25, 2008

Re: [Pharo-project] about preparing the first release

by Adrian Lienhard

On Sep 25, 2008, at 11:12 , Damien Cassou wrote: > On Wed, Sep 24, 2008 at 10:49 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: >> I'd suggest the common major.minor[.maintenance] scheme starting >> with "1.0". > > I would not start with "1.0" because it means this is already stable > enough for anyone to rely upon. isn't this exactly the goal of the release?! Only if the shipped version is reasonably stable the people will use it... Adrian

Sept. 25, 2008