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

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alpha universe

by Lukas Renggli

> but this is not what we want when we do not use a universe. To be able to properly load Seaside a system that can handle dependencies is a requirement. To our knowledge, Universe is the only system in Squeak/Pharo that can handle this task. If you do not like Universes you can always load the Monticello packages manually following this graph: <http://www.lukas-renggli.ch/dropbox/seaside-2.9/seaside.png>. Good luck ;-) Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 25, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alpha universe

by Norbert Hartl

On Thu, 2008-09-25 at 15:51 +0200, Lukas Renggli wrote: > On 9/25/08, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > why can we have an installer script or mcm ? > > We should be able to have one click install too. > > It will eventually become simpler. > > An installer script or an mcm is not an option because that would > always load one fixed configuration. Only with Universe we have the > possibility to load the set of packages the developer needs, and pull > in a minimal set of required dependencies automatically. > What will you do with current channels (beta,...) with seaside. Are you preparing an universe for each. The most important thing that is lacking in Universe is to assign a package version to a certain channel. This leads to something I've seen some times: A package the is called Seaside-beta-anything which is broken as soon as this beta becomes stable. For me universes capture the basic idea of an package distribution tree but it lacks essential stuff. Without that I don't know if it is worth it. Having a maintained universe only for seaside is a good thing. But you have to include KomHttpServer as well which will also be in the "official" universe. And AFAIK you can't merge universes, right? We could convert your universe into a Monticello configuration. It may sound stupid as first but I don't think it is hard to do and we wouldn't need to have universes and XML parser in the image. my 2 cents, Norbert

Sept. 25, 2008

Re: [Pharo-project] Removing class category

by StÃ©phane Ducasse

But the problem that we face is that we have dependency that could be already factored out. I will start to remove etoy and we will see Stef On Sep 25, 2008, at 4:08 PM, Marcus Denker wrote: > > On 25.09.2008, at 15:40, Alexandre Bergel wrote: > >> Hi! >> >> I just created a package MorphicBalloon that contains the 3 classes >> defined in Morphic-Balloon. >> Here is the comment: >> -=-=-=-=-=-=-=-=-=-=-=-= >> This package contains the 3 classes that define Balloon >> (BalloonCanvas, BalloonRectangleMorph, MatrixTranformMorph). >> These three classes, are only referenced by classes defined in the >> class category Morphic-Support. >> I am not sure whether this is a good change, but it is a first step >> to remove class category >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> This is an example that should raise the question about where we >> want to go. >> I feel that having class category as sub-monticellopackage is a >> bad thing. >> We should get rid of class category. >> > > I don't know if that is a good idea... Morphic is such a blob of > unmaintainability, we should not add more confusion by > packaging it into many tiny packages. > > I would first clean up. > > Marcus > > -- > 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 >

Sept. 25, 2008

Re: [Pharo-project] Removing class category

by Marcus Denker

On 25.09.2008, at 15:40, Alexandre Bergel wrote: > Hi! > > I just created a package MorphicBalloon that contains the 3 classes > defined in Morphic-Balloon. > Here is the comment: > -=-=-=-=-=-=-=-=-=-=-=-= > This package contains the 3 classes that define Balloon > (BalloonCanvas, BalloonRectangleMorph, MatrixTranformMorph). > These three classes, are only referenced by classes defined in the > class category Morphic-Support. > I am not sure whether this is a good change, but it is a first step > to remove class category > -=-=-=-=-=-=-=-=-=-=-=-= > > This is an example that should raise the question about where we > want to go. > I feel that having class category as sub-monticellopackage is a bad > thing. > We should get rid of class category. > I don't know if that is a good idea... Morphic is such a blob of unmaintainability, we should not add more confusion by packaging it into many tiny packages. I would first clean up. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 25, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alpha universe

by StÃ©phane Ducasse

On Sep 25, 2008, at 3:51 PM, Lukas Renggli wrote: > On 9/25/08, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> why can we have an installer script or mcm ? >> We should be able to have one click install too. > > It will eventually become simpler. > > An installer script or an mcm is not an option because that would > always load one fixed configuration. but this is not what we want when we do not use a universe. > Only with Universe we have the > possibility to load the set of packages the developer needs, and pull > in a minimal set of required dependencies automatically. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > 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] Fwd: [Seaside-dev] preliminary Seaside 2.9 alpha universe

by Lukas Renggli

On 9/25/08, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > why can we have an installer script or mcm ? > We should be able to have one click install too. It will eventually become simpler. An installer script or an mcm is not an option because that would always load one fixed configuration. Only with Universe we have the possibility to load the set of packages the developer needs, and pull in a minimal set of required dependencies automatically. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 25, 2008

[Pharo-project] Removing class category

by Alexandre Bergel

Hi! I just created a package MorphicBalloon that contains the 3 classes defined in Morphic-Balloon. Here is the comment: -=-=-=-=-=-=-=-=-=-=-=-= This package contains the 3 classes that define Balloon (BalloonCanvas, BalloonRectangleMorph, MatrixTranformMorph). These three classes, are only referenced by classes defined in the class category Morphic-Support. I am not sure whether this is a good change, but it is a first step to remove class category -=-=-=-=-=-=-=-=-=-=-=-= This is an example that should raise the question about where we want to go. I feel that having class category as sub-monticellopackage is a bad thing. We should get rid of class category. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 25, 2008

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