May 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] Community Supported Packages

by StÃ©phane Ducasse

You may be right. Now I suggest that we do and learn. Stef On May 17, 2010, at 3:12 PM, Torsten Bergmann wrote: > Mariano Martinez Peck wrote on [1]: >> I don't agree here. You DON'T necessary need to have the packages inside the >> image to have a UI. > > Please read what I wrote. I did not say that it is impossible > to build the UI when you have an external config - but "it would > be easy to build a UI" when it is already in the image. I'm sure > you will agree here. > > However - even when SqueakMap is not well maintained - it's UI > was easy to use and was easy accessible and one could use it > with a few clicks. > > Using Monticello tools, loading and evaluating by hand is > currently possible - but this is a step backward in usability > compared to what Squeak has/had. But this is a convenience/tool > issue that has to be solved. > > Bye > T. > > [1] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-May/026829.html > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 17, 2010

[Pharo-project] TextEditor and NewTextMorph merges and fixes

by Fernando olivero

Issue: 2375 Name: System-Text-FernandoOlivero.8 Author: FernandoOlivero Time: 17 May 2010, 3:22:14 pm ###################################### Issue: -- Name: Morphic-FernandoOlivero.588 Author: FernandoOlivero Time: 17 May 2010, 1:42:04 pm

May 17, 2010

Re: [Pharo-project] Managing Pharo external packages with Metacello, please read!

by Geert Claes

Mariano Martinez Peck wrote: > > 1) We create a squeaksource repository called Pharo10MetacelloRepository > Just a wee idea here, since there are all these ConfigurationOfXXX packages, why not have a MetacelloRepositoryForXXX (rather than XXXMetacelloRepository). Maybe ConfigurationRepositoryForXXX is a better name? -- View this message in context: http://forum.world.st/Managing-Pharo-external-packages-with-Metacello-pleas… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 17, 2010

[Pharo-project] [squeak-dev] Community Supported Packages

by Torsten Bergmann

Mariano Martinez Peck wrote on [1]: >I don't agree here. You DON'T necessary need to have the packages inside the >image to have a UI. Please read what I wrote. I did not say that it is impossible to build the UI when you have an external config - but "it would be easy to build a UI" when it is already in the image. I'm sure you will agree here. However - even when SqueakMap is not well maintained - it's UI was easy to use and was easy accessible and one could use it with a few clicks. Using Monticello tools, loading and evaluating by hand is currently possible - but this is a step backward in usability compared to what Squeak has/had. But this is a convenience/tool issue that has to be solved. Bye T. [1] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-May/026829.html -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

May 17, 2010

Re: [Pharo-project] [squeak-dev] Community Supported Packages

by Mariano Martinez Peck

On Mon, May 17, 2010 at 2:14 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > I tried to follow the discussion on both lists regarding supported packages > and how/where to manage them by using Metacello. I can not give complete > feedback > since I go with GÃ¶ran here who said "I need to read your thoughts once more > before giving proper feedback." and I think we all should take the time to > think about all the implications the different approaches have. > > With this discussion we set up the base for the future of package > maintenance > but also for collaboration amongst the communities, how images are built, > ...! > > I'm sure we all want to blur the line between in and out of the (whatever) > image > and share/reuse as many code/packages as possible within the broader > community > (Squeak, Pharo, Cuis, Gemstone, ...). So: > > Goal Nr. 1 is: if it is not in my environment then just load it. > Goal Nr. 2 is: if it is loaded it should work in my environment since it > brings > in anything it needs to work > > Currently the discussion and actions seem to focus on where to put the > configurations (into the image vs. in repositories per version). I'm in > favour > of the latter since that is easier to handle and share between platforms > while having them in the image would limit people who work on various > platforms, it would not scale and eat more resources for maintenance. > > My fear is also that if you have the configurations within the image then > we all will end up with something similar to the unmaintained SqueakMap > registrations. With external repos we can also feed CI-Tools (Hudson build > server, ...) > > I agree with all this. > The only benefit from the "maintining configs in-image" would be that > it would be easy to build a UI similar to SqueakMap/Universe Browser. > This is something that has to be solved - especially for Pharo since > loading/browsing > it is not very "user friendly" today, but AFAIK work already started with > the > "Loader" project. Agree with Andreas that Metacello needs more work and > a good browser of available configs would be a plus. > I don't agree here. You DON'T necessary need to have the packages inside the image to have a UI. If you are using this tool, is because you have internet connection, otherwise you won't be able to install anything. So, if you have internet connection, no need to have configurations in the image. They will be difficult to update and to manage. Even more, having an external repo pero version, give us a "UI" as you want but reusing the tools we already have. Ok, it is not perfect, but it works: As I say, when you distribute Pharo1.0 you include the Pharo10MetacelloRepository already added. Then, you open Monticello Browser, browse the repo Pharo10MetacelloRepository, choose the one you want, you load it with Monticello, and then just evaluate: ConfigurationOfXXX load. You can even put a class side initialize for that if you want. Cheers Mariano > > But thats not the main question. Even if Squeak decides to have the > configurations > "in-image" and Pharo decides for external configs one can mix them: > An in-image ConfigurationOfMyApp just loads the > ConfigurationOfMyAppExternal > where the last one is maintained in an external repo and the internal > config is for convenience to just load it. > > However - I have to reread all the arguments and think about all this. > > <warning> > But with a better acceptance of Metacello there will be more to come and > to discuss! > </warning> > > Lets think about the implications for anything above the virtual machine: > > Squeak is currently maintained as a "full image" using the trunk process > while Pharo already switched to a "small core + external packages" model. > > The "pharo core" image (which is not Pharo!) is getting stable and > hopefully > smaller and one can already create a Pharo image right from the > "ConfigurationOfPharo". That is there and working. > > I'm not saying that Squeak is not getting stable (I'm still a Squeak AND > Pharo guy) > but it is a different approach to build the end result that we later > announce on > our websites. > > If Squeak jumps on the Metacello config bandwagon it may also have to think > about > jumping onto the "small core + external packages" model. At least to me > this would be the next logical step. > > This leads to several questions: > > - could this small core could be the same for all of us - especially since > we currently fix stuff in Cuis, Squeak and Pharo mostly the same way > > - could this small core be reduced to a minimum set of objects and a > loader > that is able just suck in the things defined in package configurations > of packages that work together > > - would any specific assembled/deployed image not just be a special distro > of the "small kernel" + selected packages (similar to the linux world) > > So "Squeak" may later be the distro with media/fun/experimental packages > or etoys and "Pharo" may later be the distro with packages oriented > towards commercial development. > > However then the lines are blurred then and if you have the common core on > your disk you can even create your own distro with Seaside and Etoys ... > > Pharo will follow the path "kernel" + selected packages" and external > config path anyway since this is already discusssed and prepared. > > >From what I understand so far a repo for Pharo 1.1. will appear soon > with freezed/working configs and a build structure will be set up. > So lets see how this works out and if successfull if Squeak will > adapt it too. > > Just my 2 cents. Expect additionally cents after getting more time to > think about all this ... > > Bye > T. > > > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > >

May 17, 2010

Re: [Pharo-project] Metacello and SourceTalk ...

by Geert Claes

What would be the biggest challenges moving to MC2 and a MC2 Repository like SourceTalk? Mariano Martinez Peck wrote: > > Hi Geert. I agree it would awesome to have Monticello 2 and SourcTalk for > Pharo 1.2. I have not idea the status. I tested once (you can see > squeakdbx there) but I have a lot of problems. And the project seems > "dead". I mean, I don't think someone is working on it. That said, it > would be great someone to work on it and maybe start to using it by Pharo > 1.2 > -- View this message in context: http://forum.world.st/Metacello-and-SourceTalk-tp2219294p2219517.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 17, 2010

Re: [Pharo-project] Metacello and SourceTalk ...

by Mariano Martinez Peck

Hi Geert. I agree it would awesome to have Monticello 2 and SourcTalk for Pharo 1.2. I have not idea the status. I tested once (you can see squeakdbx there) but I have a lot of problems. And the project seems "dead". I mean, I don't think someone is working on it. That said, it would be great someone to work on it and maybe start to using it by Pharo 1.2 Cheers Mariano On Mon, May 17, 2010 at 11:06 AM, Geert Claes <geert.wl.claes(a)gmail.com>wrote: > > SourceTalk/Monticello 2 hasn't been top priority because there have been > plenty of other more urgent matters that required attention. > > Maybe with all the discussion around Metacello, Repositories, Pharo > Release, > Code Freeze, Continuous Integration etc ... it may be a good idea to use > this momentum to look at SourceTalk/Monticello 2 again? The name > SourceTalk > probably makes more sense with the idea of the Repository serving the > Squeak > and Pharo communities. SourceTalk should probably also remove the need for > projects to use Google Code simply for its Wiki and Issue Tracker. > > A number of other "Ideas To Implement" > (http://code.google.com/p/pharo/wiki/IdeasToImplement) have already made > it > to the next stage. > -- > View this message in context: > http://forum.world.st/Metacello-and-SourceTalk-tp2219294p2219294.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 17, 2010

[Pharo-project] Community Supported Packages

by Torsten Bergmann

Hi, I tried to follow the discussion on both lists regarding supported packages and how/where to manage them by using Metacello. I can not give complete feedback since I go with GÃ¶ran here who said "I need to read your thoughts once more before giving proper feedback." and I think we all should take the time to think about all the implications the different approaches have. With this discussion we set up the base for the future of package maintenance but also for collaboration amongst the communities, how images are built, ...! I'm sure we all want to blur the line between in and out of the (whatever) image and share/reuse as many code/packages as possible within the broader community (Squeak, Pharo, Cuis, Gemstone, ...). So: Goal Nr. 1 is: if it is not in my environment then just load it. Goal Nr. 2 is: if it is loaded it should work in my environment since it brings in anything it needs to work Currently the discussion and actions seem to focus on where to put the configurations (into the image vs. in repositories per version). I'm in favour of the latter since that is easier to handle and share between platforms while having them in the image would limit people who work on various platforms, it would not scale and eat more resources for maintenance. My fear is also that if you have the configurations within the image then we all will end up with something similar to the unmaintained SqueakMap registrations. With external repos we can also feed CI-Tools (Hudson build server, ...) The only benefit from the "maintining configs in-image" would be that it would be easy to build a UI similar to SqueakMap/Universe Browser. This is something that has to be solved - especially for Pharo since loading/browsing it is not very "user friendly" today, but AFAIK work already started with the "Loader" project. Agree with Andreas that Metacello needs more work and a good browser of available configs would be a plus. But thats not the main question. Even if Squeak decides to have the configurations "in-image" and Pharo decides for external configs one can mix them: An in-image ConfigurationOfMyApp just loads the ConfigurationOfMyAppExternal where the last one is maintained in an external repo and the internal config is for convenience to just load it. However - I have to reread all the arguments and think about all this. <warning> But with a better acceptance of Metacello there will be more to come and to discuss! </warning> Lets think about the implications for anything above the virtual machine: Squeak is currently maintained as a "full image" using the trunk process while Pharo already switched to a "small core + external packages" model. The "pharo core" image (which is not Pharo!) is getting stable and hopefully smaller and one can already create a Pharo image right from the "ConfigurationOfPharo". That is there and working. I'm not saying that Squeak is not getting stable (I'm still a Squeak AND Pharo guy) but it is a different approach to build the end result that we later announce on our websites. If Squeak jumps on the Metacello config bandwagon it may also have to think about jumping onto the "small core + external packages" model. At least to me this would be the next logical step. This leads to several questions: - could this small core could be the same for all of us - especially since we currently fix stuff in Cuis, Squeak and Pharo mostly the same way - could this small core be reduced to a minimum set of objects and a loader that is able just suck in the things defined in package configurations of packages that work together - would any specific assembled/deployed image not just be a special distro of the "small kernel" + selected packages (similar to the linux world) So "Squeak" may later be the distro with media/fun/experimental packages or etoys and "Pharo" may later be the distro with packages oriented towards commercial development. However then the lines are blurred then and if you have the common core on your disk you can even create your own distro with Seaside and Etoys ... Pharo will follow the path "kernel" + selected packages" and external config path anyway since this is already discusssed and prepared. >From what I understand so far a repo for Pharo 1.1. will appear soon with freezed/working configs and a build structure will be set up. So lets see how this works out and if successfull if Squeak will adapt it too. Just my 2 cents. Expect additionally cents after getting more time to think about all this ... Bye T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

May 17, 2010

Re: [Pharo-project] Class>>rename:

by Igor Stasenko

Is #rename: still untracked by changes log? 2010/5/17 Fernando olivero <oliverof(a)lu.unisi.ch>: > Issue 2437. > Fix in Pharo Inbox: > > Name: Kernel-FernandoOlivero.662 > Author: FernandoOlivero > > > > > _______________________________________________ > 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.

May 17, 2010

[Pharo-project] Class>>rename:

by Fernando olivero

Issue 2437. Fix in Pharo Inbox: Name: Kernel-FernandoOlivero.662 Author: FernandoOlivero

May 17, 2010