- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Zinc feedback

by Sven Van Caekenberghe

On 20 May 2011, at 10:46, Sven Van Caekenberghe wrote: > 1. Zn manages its own list and registers its manager for that just once See http://code.google.com/p/pharo/issues/detail?id=4428

June 19, 2011

Re: [Pharo-project] MethodFinder should use pragmas

by Damien Cassou

On Sat, Jun 18, 2011 at 8:51 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I understand your fear > but we should try and see. Ok, I submitted a proposal, please have a look http://code.google.com/p/pharo/issues/detail?id=4426 -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 19, 2011

Re: [Pharo-project] why (UIManager default newPluggableDialogWindow: 'Pharo is cool') openInWorld

by StÃ©phane Ducasse

you are welcome :) I think that I will log all the things I learn slowly and we will try to fix the inconsistency. My first notes are in the basicWidgets chapter on pbe On Jun 19, 2011, at 12:36 PM, Benjamin wrote: > Can I participate ? > > > Ben > > On Jun 19, 2011, at 8:53 AM, StÃ©phane Ducasse wrote: > >> I'm starting to write one chapter on basic widgets >> and I would like to understand and record it. And also modify the system to be consistent. >> >> Stef >> >> >> >> On Jun 18, 2011, at 9:56 PM, Alexandre Bergel wrote: >> >>> Hi Stef, >>> >>> I have no idea about the answers to your question. But looking into this is important. >>> >>> Cheers, >>> Alexandre >>> >>> >>> On 18 Jun 2011, at 15:02, StÃ©phane Ducasse wrote: >>> >>>> >>>> On Jun 18, 2011, at 7:58 PM, stephane ducasse wrote: >>>> >>>>> why >>>>> >>>>> (UIManager default >>>>> newPluggableDialogWindow: 'Pharo is cool') openInWorld >>>>> >>>>> does not work? >>>>> Apparently MorphicUIManager is missing something? >>>>> Stef >>>>> >>>> >>>> >>>> (ExampleBuilderMorph new newPluggableDialogWindow: 'Pharo is cool') openInWorld >>>> >>>> is working because ExampleBuilderMorph inherits from Morph and not from Object >>>> >>>> (UITheme builder >>>> newPluggableDialogWindow: 'Pharo is cool'; >>>> minimumExtent: 200@300) openInWorld >>>> >>>> similarly. >>>> >>>> Now there is something that I do not understand. >>>> What is the use of the builder since I cannot pass it specific setting >>>> >>>> >>>> (UITheme builder >>>> newPluggableDialogWindow: 'Pharo is cool' >>>> for: (RectangleMorph new); >>>> beUnresizeable <<< does not work because the builder (a ComposableMorph does not pass such setting to the PluggableDialogWindow. >>>> ) openInWorld >>>> >>>> I would really like to have a nice kernel that support well such approach. >>>> In fact I imagine that we should not use UITheme builder that way. >>>> >>>> >>>> Stef >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >> >> > >

June 19, 2011

Re: [Pharo-project] why (UIManager default newPluggableDialogWindow: 'Pharo is cool') openInWorld

by Benjamin

Can I participate ? Ben On Jun 19, 2011, at 8:53 AM, StÃ©phane Ducasse wrote: > I'm starting to write one chapter on basic widgets > and I would like to understand and record it. And also modify the system to be consistent. > > Stef > > > > On Jun 18, 2011, at 9:56 PM, Alexandre Bergel wrote: > >> Hi Stef, >> >> I have no idea about the answers to your question. But looking into this is important. >> >> Cheers, >> Alexandre >> >> >> On 18 Jun 2011, at 15:02, StÃ©phane Ducasse wrote: >> >>> >>> On Jun 18, 2011, at 7:58 PM, stephane ducasse wrote: >>> >>>> why >>>> >>>> (UIManager default >>>> newPluggableDialogWindow: 'Pharo is cool') openInWorld >>>> >>>> does not work? >>>> Apparently MorphicUIManager is missing something? >>>> Stef >>>> >>> >>> >>> (ExampleBuilderMorph new newPluggableDialogWindow: 'Pharo is cool') openInWorld >>> >>> is working because ExampleBuilderMorph inherits from Morph and not from Object >>> >>> (UITheme builder >>> newPluggableDialogWindow: 'Pharo is cool'; >>> minimumExtent: 200@300) openInWorld >>> >>> similarly. >>> >>> Now there is something that I do not understand. >>> What is the use of the builder since I cannot pass it specific setting >>> >>> >>> (UITheme builder >>> newPluggableDialogWindow: 'Pharo is cool' >>> for: (RectangleMorph new); >>> beUnresizeable <<< does not work because the builder (a ComposableMorph does not pass such setting to the PluggableDialogWindow. >>> ) openInWorld >>> >>> I would really like to have a nice kernel that support well such approach. >>> In fact I imagine that we should not use UITheme builder that way. >>> >>> >>> Stef >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> > >

June 19, 2011

Re: [Pharo-project] roadmap for 1.4

by StÃ©phane Ducasse

On Jun 19, 2011, at 7:27 AM, Pavel Krivanek wrote: > Hi, > > I think that the best idea is to have one image for the system developers and end-users (for example, I almost never used full Pharo so it lost one tester). On the other hand we should continue with the modularization to allow to generate headless kernel image, gopher image, basic morphic image etc. on the request with bootstrapping. To have smallest possible image is not the main goal of the effort around PharoKernel. The main goal is to have beauty modular system where all dependencies all described well and packages can be easily loaded and unloaded. The buildserver can generate all the set of images for special purposes so it will be more natural then now when we have two main images. Yes yes yes but :) we should have a set of tools that are working together and we should not be responsible of making sure that all the possible combination work. I would like to get a process (as I mentioned in the other mail) seed + MetacelloSpec + modification => seed' + MetacelloSpec' and that we are able to build hudson that takes aSeed + a spec => run all the tests + run all the quality check Right now we have seed + list of package + modification => seed' + list of package' and we get in trouble when we modify seed parts that influence external package so what we want is to have seed + metacello = the minimal tools that we need to be efficient modifying seed for me OB Engine Shout O/Ecompletion Stef > > -- Pavel > > > > 18.6.2011 v 22:29, Guillermo Polito <guillermopolito(a)gmail.com>: > >> Hi Stef! >> >> do you mean integrating all them in the Core? Or maybe follow Markus' idea of having just one image? Maybe that's an important discussion to have too :). >> I can give a hand for the repository stuff. Should we replicate repositories + metacello configs in order to be able to freeze them, isn't it? >> >> Guille >> >> On Sat, Jun 18, 2011 at 9:59 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Hi guys >> >> here is a kind of dump of roadmap for 1.4 first level is to make sure that we have only one single image. >> >> - load FileSystem >> -> so that we can start to integrate and improve the fileSystem API >> >> - Load shout, Ocompletion, RBEngine (not OB) so that we can change what should be changed for RPackage to work >> >> - Ring >> -> so that we can start to integrate it >> >> - Fuel >> -> so that we can deprecate SmartRefStream (there may be a problem with mcz (not sure)). >> >> - I want Opal in 1.4 too. >> >> - continue to remove StringHolder hierarchy >> >> - Morphic improvements >> >> Comments are welcomed. >> >> Stef >> >> >>

June 19, 2011

Re: [Pharo-project] roadmap for 1.4

by Mariano Martinez Peck

On Sun, Jun 19, 2011 at 7:27 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > Hi, > > I think that the best idea is to have one image for the system developers > and end-users (for example, I almost never used full Pharo so it lost one > tester). On the other hand we should continue with the modularization to > allow to generate headless kernel image, gopher image, basic morphic image > etc. on the request with bootstrapping. To have smallest possible image is > not the main goal of the effort around PharoKernel. The main goal is to have > beauty modular system where all dependencies all described well and packages > can be easily loaded and unloaded. The buildserver can generate all the set > of images for special purposes so it will be more natural then now when we > have two main images. > > +1 > -- Pavel > > > > 18.6.2011 v 22:29, Guillermo Polito <guillermopolito(a)gmail.com>: > > Hi Stef! > > do you mean integrating all them in the Core? Or maybe follow Markus' idea > of having just one image? Maybe that's an important discussion to have too > :). > I can give a hand for the repository stuff. Should we replicate > repositories + metacello configs in order to be able to freeze them, isn't > it? > > Guille > > On Sat, Jun 18, 2011 at 9:59 AM, StÃ©phane Ducasse <<stephane.ducasse(a)inria.fr> > stephane.ducasse(a)inria.fr> wrote: > >> Hi guys >> >> here is a kind of dump of roadmap for 1.4 first level is to make sure that >> we have only one single image. >> >> - load FileSystem >> -> so that we can start to integrate and improve the fileSystem API >> >> - Load shout, Ocompletion, RBEngine (not OB) so that we can change what >> should be changed for RPackage to work >> >> - Ring >> -> so that we can start to integrate it >> >> - Fuel >> -> so that we can deprecate SmartRefStream (there may be a problem >> with mcz (not sure)). >> >> - I want Opal in 1.4 too. >> >> - continue to remove StringHolder hierarchy >> >> - Morphic improvements >> >> Comments are welcomed. >> >> Stef >> >> >> > -- Mariano http://marianopeck.wordpress.com

June 19, 2011

Re: [Pharo-project] roadmap for 1.4

by StÃ©phane Ducasse

this is why I want to have a distribution repository and one click load of what we want. Now in addition we need to have the powerful tools inside the system (core) because we should be able to use the best tools to manage the changes. Stef >> Hi, >> >> I think that the best idea is to have one image for the system >> developers and end-users (for example, I almost never used full Pharo so >> it lost one tester). On the other hand we should continue with the >> modularization to allow to generate headless kernel image, gopher image, >> basic morphic image etc. on the request with bootstrapping. To have >> smallest possible image is not the main goal of the effort around >> PharoKernel. The main goal is to have beauty modular system where all >> dependencies all described well and packages can be easily loaded and >> unloaded. The buildserver can generate all the set of images for special >> purposes so it will be more natural then now when we have two main images. > > +1 > > Me too - I never use full Pharo. I build the image I want from Core. If there were a suitable special purpose image built as outlined above, then that image would be my new starting point. If not, then I guess I would have to start from whatever Core+Dev image results from the process, and then unload stuff (or, if it isn't too big, use it as is). > >

June 19, 2011

Re: [Pharo-project] roadmap for 1.4

by StÃ©phane Ducasse

On Jun 18, 2011, at 10:29 PM, Guillermo Polito wrote: > Hi Stef! > > do you mean integrating all them in the Core? Or maybe follow Markus' idea of having just one image? yes > Maybe that's an important discussion to have too :). > I can give a hand for the repository stuff. Should we replicate repositories + metacello configs in order to be able to freeze them, isn't it? What we want is to avoid to have two images to maintain. Now what I would love to have is the following one configuration for the image that the build system always load and we get something smaller that the current dev. The idea is that core should not be used but there and just as a seed to build the system So I would love to see how we could manage update with Metacello because we would have bootstrap the process seed1 + MT1 => Pharo1 Pharo1 + modifications => MT2 + seed2 (optionally) seed1 or seed2 + MT2 => Pharo2 + modifications Stef > > Guille > > On Sat, Jun 18, 2011 at 9:59 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > here is a kind of dump of roadmap for 1.4 first level is to make sure that we have only one single image. > > - load FileSystem > -> so that we can start to integrate and improve the fileSystem API > > - Load shout, Ocompletion, RBEngine (not OB) so that we can change what should be changed for RPackage to work > > - Ring > -> so that we can start to integrate it > > - Fuel > -> so that we can deprecate SmartRefStream (there may be a problem with mcz (not sure)). > > - I want Opal in 1.4 too. > > - continue to remove StringHolder hierarchy > > - Morphic improvements > > Comments are welcomed. > > Stef > > >

June 19, 2011

Re: [Pharo-project] why (UIManager default newPluggableDialogWindow: 'Pharo is cool') openInWorld

by StÃ©phane Ducasse

I'm starting to write one chapter on basic widgets and I would like to understand and record it. And also modify the system to be consistent. Stef On Jun 18, 2011, at 9:56 PM, Alexandre Bergel wrote: > Hi Stef, > > I have no idea about the answers to your question. But looking into this is important. > > Cheers, > Alexandre > > > On 18 Jun 2011, at 15:02, StÃ©phane Ducasse wrote: > >> >> On Jun 18, 2011, at 7:58 PM, stephane ducasse wrote: >> >>> why >>> >>> (UIManager default >>> newPluggableDialogWindow: 'Pharo is cool') openInWorld >>> >>> does not work? >>> Apparently MorphicUIManager is missing something? >>> Stef >>> >> >> >> (ExampleBuilderMorph new newPluggableDialogWindow: 'Pharo is cool') openInWorld >> >> is working because ExampleBuilderMorph inherits from Morph and not from Object >> >> (UITheme builder >> newPluggableDialogWindow: 'Pharo is cool'; >> minimumExtent: 200@300) openInWorld >> >> similarly. >> >> Now there is something that I do not understand. >> What is the use of the builder since I cannot pass it specific setting >> >> >> (UITheme builder >> newPluggableDialogWindow: 'Pharo is cool' >> for: (RectangleMorph new); >> beUnresizeable <<< does not work because the builder (a ComposableMorph does not pass such setting to the PluggableDialogWindow. >> ) openInWorld >> >> I would really like to have a nice kernel that support well such approach. >> In fact I imagine that we should not use UITheme builder that way. >> >> >> Stef > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

June 19, 2011

Re: [Pharo-project] roadmap for 1.4

by Yanni Chiu

On 19/06/11 1:27 AM, Pavel Krivanek wrote: > Hi, > > I think that the best idea is to have one image for the system > developers and end-users (for example, I almost never used full Pharo so > it lost one tester). On the other hand we should continue with the > modularization to allow to generate headless kernel image, gopher image, > basic morphic image etc. on the request with bootstrapping. To have > smallest possible image is not the main goal of the effort around > PharoKernel. The main goal is to have beauty modular system where all > dependencies all described well and packages can be easily loaded and > unloaded. The buildserver can generate all the set of images for special > purposes so it will be more natural then now when we have two main images. +1 Me too - I never use full Pharo. I build the image I want from Core. If there were a suitable special purpose image built as outlined above, then that image would be my new starting point. If not, then I guess I would have to start from whatever Core+Dev image results from the process, and then unload stuff (or, if it isn't too big, use it as is).

June 19, 2011