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

Re: [Pharo-project] TORCH: supporting source-code change integration

by StÃ©phane Ducasse

henrik did you try on 1.1? Stef On May 18, 2010, at 1:00 PM, Henrik Johansen wrote: > > > Den 18.05.2010 12:12, skrev Mariano Martinez Peck: >> Hola VerÃ³nica! >> >> I love it!!! nice, very nice :) >> >> I will give you more feedback as far as I start to use it. >> The only thing I would add is a button in the MC. Look the attached >> screenshot. It would be cool not only to have it in the context menu, >> but in the MC broser...for example, next to "changes" button a "torch" >> button or something like that. >> >> I really like it. Moose and all it tools seems to be working in Pharo >> 1.1 so....maybe if people agree we can include this cool tool together >> with Mondrian and Glamour ? They have 460 green tests :) > Strange, for me it lead to errors in 1.1 because: > - It depends on Momo10 (MorphTreeMorph) > - This has been integrated into Morphic in 1.1 > - Loading Torch overrode the code in Morphic with code from Momo rep. > - The "old" tree was missing methods (rowInset:) used by the settings > browser, so that broke. > > Soooo, Metacello tags with version info as well coming soon? > I really haven't followed that discussion :) > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 18, 2010

Re: [Pharo-project] TORCH: supporting source-code change integration

by Henrik Johansen

Den 18.05.2010 12:12, skrev Mariano Martinez Peck: > Hola VerÃ³nica! > > I love it!!! nice, very nice :) > > I will give you more feedback as far as I start to use it. > The only thing I would add is a button in the MC. Look the attached > screenshot. It would be cool not only to have it in the context menu, > but in the MC broser...for example, next to "changes" button a "torch" > button or something like that. > > I really like it. Moose and all it tools seems to be working in Pharo > 1.1 so....maybe if people agree we can include this cool tool together > with Mondrian and Glamour ? They have 460 green tests :) Strange, for me it lead to errors in 1.1 because: - It depends on Momo10 (MorphTreeMorph) - This has been integrated into Morphic in 1.1 - Loading Torch overrode the code in Morphic with code from Momo rep. - The "old" tree was missing methods (rowInset:) used by the settings browser, so that broke. Soooo, Metacello tags with version info as well coming soon? I really haven't followed that discussion :) Cheers, Henry

May 18, 2010

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

by StÃ©phane Ducasse

+1 archives are like that. On May 18, 2010, at 12:39 PM, Tudor Girba wrote: > Hi, > > Well, the whole point of the "publish" idea would be to ensure a safe and guarded place from which everything can be loaded. > > If you depend on other repositories, these can disappear in time and you are back to the same problem as now. > > So, I think the only way around this problem is to produce configurations that can load only from a controlled repository. > > Cheers, > Doru > > > > On 18 May 2010, at 12:03, Mariano Martinez Peck wrote: > >> >> >> On Tue, May 18, 2010 at 10:59 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: >> Hi, >> >> I like this approach: >> 1. Projects can continue to be built independently. For example, in Moose, we have already a process with multiple configurations (one for each repository) depending on each other. >> 2. When ready, the Configurations and all related packages are "published" in the PharoXXMetacelloRepository. Having a package per Configuration makes it easy to copy it. >> >> The only problem is that the code of Configuration mentions explicitly the repository (especially in the case of having nested Configurations, I point to a configuration by specifying the repository, package, and class). So, I guess the simplest thing here would be to provide the default "load" method to already override dynamically all repositories with the PharoXXMetacelloRepository. >> >> >> Thanks Doru for pointing this. Actually, this was the only "problem" I found with the solution. My though about this where: >> >> - I really don't care where they are the confs you depends on. I only care that YOU loads and runs perfectly. >> - Maybe that other confs that you depend on are also in the same repo...but I don't think something bad to getting the conf from, for example, MetacelloRepository. >> >> You can update the conf once you publish it and to use the PharoXXXMetacelloRepositopry instead of MetacelloRepository or whatever, but I don't think it is strictly needed. What it is needed is that it loads and works ok. If other person, or even you, want to ALSO publish your dependences, great... >> >> What do you think? >> >> Cheers >> >> Mariano >> >> >> Cheers, >> Doru >> >> >> >> On 18 May 2010, at 09:32, StÃ©phane Ducasse wrote: >> >> I understand nicolas. Now my agenda is more than full. >> and the proposal is here. Simple >> >> ========================================================== >> One repo per version Pharo1.0, Pharo11 ... MetacelloRepository >> containing **published** configurationOfXXX >> -> all the dependent packages are copied locally + configuration ready to load using load. >> >> A project >> contain its single/or several configurationOfMyProject with the complete history >> people commit the config to their repository and if they want they **publish** from their repository to the version repository >> a version. This version is frozen -> all the dependent packages are copied locally + configuration ready to load using load. >> >> For Pharo core or pharo packages that we maintain we want to maintain it as a project. >> with its own repository and packages. >> >> We can use automatic build server to validate the status or migration between different repositories >> ========================================================== >> >> >> Stef >> >> On May 17, 2010, at 11:00 PM, Nicolas Cellier wrote: >> >> The meaning of my message was don't do it for squeak, but do it for yourself. >> I don't doubt the mailing list is a mine of information, but even in >> the best mine you need to dig a lot before extracting the gold >> nuggets. >> Of course, I've got no right to control your agenda, who am I ? >> You can consider the subject close, and I won't find your attitude >> shocking at all. >> But next time, consider writing a rationale for your own, it will >> increase quality of Pharo decision process. >> >> Best regards >> >> Nicolas >> >> 2010/5/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> nicolas >> >> all the information is in the metacello mailing-list and we already posted many mails on that topics in this mailing list. >> I'm sorry but I do not have the time to repeat again what we said. Now since I'm in a really good mood >> in a nutshell >> >> one repo per version Pharo1.0, Pharo11 ... MetacelloRepository >> containing configurationOfXXX frozen = all the dependent packages are copied locally + configuration ready to load using load. >> >> a project >> contain its single/or whatever configurationOfMyProject >> people publish the config to their repository and if they want they push from their repository to the version repository >> a version that they freeze (may be using tags) >> >> For Pharo core or pharo packages that we maintain we want to maintain it as a project. >> with its own repository and packages. >> >> Then we have a server that load configuration and barks if something wrong happen. And may be we kick out >> the configurationofXXX from MetacelloRepositories >> >> Steph, >> I understand how boring it may seem: >> - you already discussed the subject over and over >> - you already took decisions >> and now we come later with new proposals, and ask you to reconsider >> the work again... >> >> more than that. :) >> It looks like if we did not talk or think about what we are doing. >> >> >> As for the Preferences/Settings, Pharo choices are probably very weel thought. >> >> However, every solution will come with trade offs, and it would be >> good to have a rationale justifying the choices you made, and perhaps >> more importantly justifying why you did abandon some solutions, >> because some questions might be repeated in Pharo 1.2, 1.3, 2.0 ... >> and find different answers in different context. Note that Squeak >> evolutions might have influence on Pharo too, and it's part of the >> context... >> >> I strongly encourage you to establish your rationale on Pharo grounds >> - independently of Andreas proposals, put it on the Pharo wiki and let >> us know the URL. >> >> You also know that Squeak goals are not exactly those of Pharo w.r.t. >> backward compatibility, so Squeak can't just blindly replicate Pharo >> solutions without a rationale. >> >> The merit of Andreas proposal is to try and establish such a >> rationale. Without it, we're bound to repeat discussions again and >> again, >> >> So to fix the problem consider that as our proposal. >> >> Stef >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow." >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 18, 2010

Re: [Pharo-project] TORCH: supporting source-code change integration

by StÃ©phane Ducasse

veronica I would love to have the two clouds on the same page :) Doru we are looking for a nice way to represent the left top corner (which summarize the changes) if you have any idea. Stef On May 18, 2010, at 11:00 AM, Veronica Isabel Uquillas Gomez wrote: > Dear all, > > I would like to announce Torch, a tool for supporting source-code change integration. For now, it offers visualizations of the changes and enhanced change lists. > Torch can be accessed through Monticello (in the main MC browser, in the repository browser or in the history browser). Selecting a version or slice, you can view the changes with Torch using the contextual menu. > Once you open the Torch dashboard, you can access the enhanced change list or a detailed visualization via the contextual menu as well. > > Torch is available on SqueakSource, the repository is named Torch, and you need to load the ConfigurationOfTorch package. > It runs in a dev or core image. > > For a dev image. > - ConfigurationOfTorch loadVersion10 > > For a core image. > 1) Set fonts - described in the attached file. > 2) ConfigurationOfTorch loadDefault > > I would appreciate comments and feedback! > > Best Regards, > VerÃ³nica Uquillas GÃ³mez > Vrije University Brussel - SOFT Lab > University of Lille - RMOD Team > > <torchFontsScript.st> > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 18, 2010

Re: [Pharo-project] Collection arithmethic method category

by StÃ©phane Ducasse

Thanks fernando this is cool to see that we are building a mindshare here. > > I understand, the Collections in Smalltalk are heterogeneous, and putting arithmetic behavior conceptually breaks that design. ( Same as Object gets a ton of awful behavior now! ) > > I like this new viewpoint, and will adopt it! > > Fernando > > > On May 18, 2010, at 11:23 AM, StÃ©phane Ducasse wrote: > >> I do not like this protocol and the way it is done because what if I want one that is not in the list. >> >> >> Stef >> >> On May 18, 2010, at 11:17 AM, Mariano Martinez Peck wrote: >> >>> >>> >>> On Tue, May 18, 2010 at 11:17 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>> >>> >>> On Tue, May 18, 2010 at 11:04 AM, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: >>> I see now that they were moved to an external package in Squeaksource. >>> >>> And it is not loaded by default in PharoCore1.1. >>> >>> >>> Do you think this should be included in PharoDev? >>> >>> >>> it is working in Pharo 1.1 ? does it have tests? >>> >>> >>> >>> Thanks! >>> >>> Fernando >>> >>> >>> >>> On May 18, 2010, at 10:51 AM, Henrik Johansen wrote: >>> >>>> http://code.google.com/p/pharo/issues/detail?id=332 >>>> >>>> PS. How about the Collection -> Math functions protocol? >>>> >>>> Cheers, >>>> Henry >>>> >>>> On May 18, 2010, at 10:41 53AM, Fernando olivero wrote: >>>> >>>>> Sorry, i meant >>>>> >>>>>> In PharoCore 1.1 >>>>>> Collection organization listAtCategoryNamed: 'arithmethic' #() >>>>> >>>>>> In Pharo1.0 >>>>>> Collection organization listAtCategoryNamed: 'arithmetic' #(#* #+ #- #/ #'//' #'\\' #raisedTo:) >>>>> >>>>> >>>>> >>>>> >>>>> On May 18, 2010, at 10:32 AM, Fernando olivero wrote: >>>>> >>>>>> In Pharo1.0 >>>>>> Collection organization listAtCategoryNamed: 'arithmethic' #() >>>>>> >>>>>> In PharoCore1.1 >>>>>> Collection organization listAtCategoryNamed: 'arithmetic' #(#* #+ #- #/ #'//' #'\\' #raisedTo:) >>>>>> >>>>>> And the arithmethic is not an extension of any Package. >>>>>> >>>>>> Why are all the methods in that category no present in PharoCore? >>>>>> How and when are they added into Pharo ? >>>>>> >>>>>> Fernando >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 18, 2010

Re: [Pharo-project] So...we freeze 1.1 ? (next steps?)

by StÃ©phane Ducasse

Yes lukas prepared the package when we were eating black chocolate like mad :) On May 18, 2010, at 11:39 AM, Adrian Lienhard wrote: > > On May 18, 2010, at 11:24 , StÃ©phane Ducasse wrote: > >> >> On May 18, 2010, at 9:53 AM, Adrian Lienhard wrote: >> >>> Yes, we should probably do that. It requires some work because of changes in 1.1. >> >> The network rollback package is ready to be loaded. We were just waiting to know > > Oh, you already did the work! > > Then I suggest to load it. The "new" IPv6 code basically is a hack on top of the old implementation. Its prone to fail. > > Adrian > >> >>> >>> Adrian >>> >>> >>> On May 18, 2010, at 09:24 , Michael Roberts wrote: >>> >>>> I am surprised too. would it not be safer to just apply the same >>>> reversion of the code so that 1.1 is the same as 1.0? Then when >>>> someone has the time to do a full review, a "new" network can be >>>> applied to the start of a dev cycle, with some form of integration >>>> tests. >>>> >>>> cheers, >>>> Mike >>>> >>>> On Tue, May 18, 2010 at 6:31 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>>>> Hi Alex, >>>>> >>>>> One thing that bothers me is the network code. Although nobody reported problems I cannot believe that it suddenly works without that we fixed it. The new implementation that is in 1.1 has been reverted in 1.0 and since then we haven't had any complaints. Now in 1.1 I guess that there are not that many people using it yet. >>>>> >>>>> If there are people at the sprint with different OS and configurations (Linux vs Mac; IPv4 vs. IPv6), you could try to reproduce the problems that were reported earlier (check the issue tracker). >>>>> >>>>> Another valuable help would be to (manually) test the tools, especially the ones loaded into Pharo to make sure we don't have any obvious problems there. >>>>> >>>>> Hope you have a productive weekend! >>>>> >>>>> Cheers, >>>>> Adrian >>>>> >>>>> On May 18, 2010, at 02:49 , Alexandre Bergel wrote: >>>>> >>>>>> Mariano, Stef, Adrian, >>>>>> >>>>>> I would like to focus the Pharo sprint this week end on helping Pharo 1.1. >>>>>> In addition to reviewing and fixing the issues tagged as 1.1, are there some particular actions you want to see realized this Saturday? >>>>>> >>>>>> Cheers, >>>>>> Alexandre >>>>>> >>>>>> >>>>>> On 16 May 2010, at 18:26, Alexandre Bergel wrote: >>>>>> >>>>>>>> - Integegrate the remaining fixes and crates a PharoCore-11XXX-alpha1.zip and put it in gforge >>>>>>> >>>>>>> >>>>>>> I will go over some this week. >>>>>>> >>>>>>> Alexandre >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 18, 2010

Re: [Pharo-project] Community Supported Packages

by StÃ©phane Ducasse

Hi andreas >> Absolutely. One thing that took me by surprise is the response in the Pharo world. I did not see it so can you indicate me where you see a response? >> Given that this is a proposal for Squeak I thought that the response would at most be "see, we told you so". who are we to give lesson to squeakers? People can bash metacello in the past and change their mind. This is since we managed Squeak3.9 with packages (and in fact even before - our ENVY experience back in 99) that we know that package without a map are not working well. >> Instead it appears to be ... well, I'm actually not exactly sure. Seems like a mixture of feeling threatened and NIH. >From my point of view I do not really care. If squeak use metacello good for you. We know what we want to try and we will try it. We worked and discussed with dale since ESUG last year about that and now that 1.1 is getting out this is the right time to pass in production mode. > If you look at it objectively, my proposal is extremely similar to what Pharo uses, and I've explicitly mentioned that it was inspired by Pharo's use of MetacelloRepository. Outside of the community packages aspect, pretty much the only differences are: > 1) Whether to use one configuration per package or not. > 2) Whether configurations are preloaded in the image. > That's about it. I really fail to see what the big hiatus is about.

May 18, 2010

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

by Tudor Girba

Hi, Well, the whole point of the "publish" idea would be to ensure a safe and guarded place from which everything can be loaded. If you depend on other repositories, these can disappear in time and you are back to the same problem as now. So, I think the only way around this problem is to produce configurations that can load only from a controlled repository. Cheers, Doru On 18 May 2010, at 12:03, Mariano Martinez Peck wrote: > > > On Tue, May 18, 2010 at 10:59 AM, Tudor Girba > <tudor.girba(a)gmail.com> wrote: > Hi, > > I like this approach: > 1. Projects can continue to be built independently. For example, in > Moose, we have already a process with multiple configurations (one > for each repository) depending on each other. > 2. When ready, the Configurations and all related packages are > "published" in the PharoXXMetacelloRepository. Having a package per > Configuration makes it easy to copy it. > > The only problem is that the code of Configuration mentions > explicitly the repository (especially in the case of having nested > Configurations, I point to a configuration by specifying the > repository, package, and class). So, I guess the simplest thing here > would be to provide the default "load" method to already override > dynamically all repositories with the PharoXXMetacelloRepository. > > > Thanks Doru for pointing this. Actually, this was the only "problem" > I found with the solution. My though about this where: > > - I really don't care where they are the confs you depends on. I > only care that YOU loads and runs perfectly. > - Maybe that other confs that you depend on are also in the same > repo...but I don't think something bad to getting the conf from, for > example, MetacelloRepository. > > You can update the conf once you publish it and to use the > PharoXXXMetacelloRepositopry instead of MetacelloRepository or > whatever, but I don't think it is strictly needed. What it is needed > is that it loads and works ok. If other person, or even you, want > to ALSO publish your dependences, great... > > What do you think? > > Cheers > > Mariano > > > Cheers, > Doru > > > > On 18 May 2010, at 09:32, StÃ©phane Ducasse wrote: > > I understand nicolas. Now my agenda is more than full. > and the proposal is here. Simple > > ========================================================== > One repo per version Pharo1.0, Pharo11 ... MetacelloRepository > containing **published** configurationOfXXX > -> all the dependent packages are copied locally + > configuration ready to load using load. > > A project > contain its single/or several configurationOfMyProject with the > complete history > people commit the config to their repository and if they want > they **publish** from their repository to the version repository > a version. This version is frozen -> all the dependent packages > are copied locally + configuration ready to load using load. > > For Pharo core or pharo packages that we maintain we want to > maintain it as a project. > with its own repository and packages. > > We can use automatic build server to validate the status or > migration between different repositories > ========================================================== > > > Stef > > On May 17, 2010, at 11:00 PM, Nicolas Cellier wrote: > > The meaning of my message was don't do it for squeak, but do it for > yourself. > I don't doubt the mailing list is a mine of information, but even in > the best mine you need to dig a lot before extracting the gold > nuggets. > Of course, I've got no right to control your agenda, who am I ? > You can consider the subject close, and I won't find your attitude > shocking at all. > But next time, consider writing a rationale for your own, it will > increase quality of Pharo decision process. > > Best regards > > Nicolas > > 2010/5/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > nicolas > > all the information is in the metacello mailing-list and we already > posted many mails on that topics in this mailing list. > I'm sorry but I do not have the time to repeat again what we said. > Now since I'm in a really good mood > in a nutshell > > one repo per version Pharo1.0, Pharo11 ... MetacelloRepository > containing configurationOfXXX frozen = all the dependent > packages are copied locally + configuration ready to load using load. > > a project > contain its single/or whatever configurationOfMyProject > people publish the config to their repository and if they want > they push from their repository to the version repository > a version that they freeze (may be using tags) > > For Pharo core or pharo packages that we maintain we want to > maintain it as a project. > with its own repository and packages. > > Then we have a server that load configuration and barks if something > wrong happen. And may be we kick out > the configurationofXXX from MetacelloRepositories > > Steph, > I understand how boring it may seem: > - you already discussed the subject over and over > - you already took decisions > and now we come later with new proposals, and ask you to reconsider > the work again... > > more than that. :) > It looks like if we did not talk or think about what we are doing. > > > As for the Preferences/Settings, Pharo choices are probably very > weel thought. > > However, every solution will come with trade offs, and it would be > good to have a rationale justifying the choices you made, and perhaps > more importantly justifying why you did abandon some solutions, > because some questions might be repeated in Pharo 1.2, 1.3, 2.0 ... > and find different answers in different context. Note that Squeak > evolutions might have influence on Pharo too, and it's part of the > context... > > I strongly encourage you to establish your rationale on Pharo grounds > - independently of Andreas proposals, put it on the Pharo wiki and let > us know the URL. > > You also know that Squeak goals are not exactly those of Pharo w.r.t. > backward compatibility, so Squeak can't just blindly replicate Pharo > solutions without a rationale. > > The merit of Andreas proposal is to try and establish such a > rationale. Without it, we're bound to repeat discussions again and > again, > > So to fix the problem consider that as our proposal. > > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Every thing has its own flow." > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Be rather willing to give than demanding to get."

May 18, 2010

Re: [Pharo-project] TORCH: supporting source-code change integration

by Mariano Martinez Peck

Hola VerÃ³nica! I love it!!! nice, very nice :) I will give you more feedback as far as I start to use it. The only thing I would add is a button in the MC. Look the attached screenshot. It would be cool not only to have it in the context menu, but in the MC broser...for example, next to "changes" button a "torch" button or something like that. I really like it. Moose and all it tools seems to be working in Pharo 1.1 so....maybe if people agree we can include this cool tool together with Mondrian and Glamour ? They have 460 green tests :) DEV!!!!!!!! :) On Tue, May 18, 2010 at 11:39 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi Veronica, > > It is pretty impressive :). > > Would it be Ok if I added this on the Moose page? > > Cheers, > Doru > > > > On 18 May 2010, at 11:21, StÃ©phane Ducasse wrote: > > Thanks veronica. >> lukas said that he was impressed this is a complement :) >> >> On May 18, 2010, at 11:00 AM, Veronica Isabel Uquillas Gomez wrote: >> >> Dear all, >>> >>> I would like to announce Torch, a tool for supporting source-code change >>> integration. For now, it offers visualizations of the changes and enhanced >>> change lists. >>> Torch can be accessed through Monticello (in the main MC browser, in the >>> repository browser or in the history browser). Selecting a version or slice, >>> you can view the changes with Torch using the contextual menu. >>> Once you open the Torch dashboard, you can access the enhanced change >>> list or a detailed visualization via the contextual menu as well. >>> >>> Torch is available on SqueakSource, the repository is named Torch, and >>> you need to load the ConfigurationOfTorch package. >>> It runs in a dev or core image. >>> >>> For a dev image. >>> - ConfigurationOfTorch loadVersion10 >>> >>> For a core image. >>> 1) Set fonts - described in the attached file. >>> 2) ConfigurationOfTorch loadDefault >>> >>> I would appreciate comments and feedback! >>> >>> Best Regards, >>> VerÃ³nica Uquillas GÃ³mez >>> Vrije University Brussel - SOFT Lab >>> University of Lille - RMOD Team >>> >>> <torchFontsScript.st> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of problem > understanding." > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 18, 2010

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

by Mariano Martinez Peck

On Tue, May 18, 2010 at 10:59 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi, > > I like this approach: > 1. Projects can continue to be built independently. For example, in Moose, > we have already a process with multiple configurations (one for each > repository) depending on each other. > 2. When ready, the Configurations and all related packages are "published" > in the PharoXXMetacelloRepository. Having a package per Configuration makes > it easy to copy it. > > The only problem is that the code of Configuration mentions explicitly the > repository (especially in the case of having nested Configurations, I point > to a configuration by specifying the repository, package, and class). So, I > guess the simplest thing here would be to provide the default "load" method > to already override dynamically all repositories with the > PharoXXMetacelloRepository. > > Thanks Doru for pointing this. Actually, this was the only "problem" I found with the solution. My though about this where: - I really don't care where they are the confs you depends on. I only care that YOU loads and runs perfectly. - Maybe that other confs that you depend on are also in the same repo...but I don't think something bad to getting the conf from, for example, MetacelloRepository. You can update the conf once you publish it and to use the PharoXXXMetacelloRepositopry instead of MetacelloRepository or whatever, but I don't think it is strictly needed. What it is needed is that it loads and works ok. If other person, or even you, want to ALSO publish your dependences, great... What do you think? Cheers Mariano > Cheers, > Doru > > > > On 18 May 2010, at 09:32, StÃ©phane Ducasse wrote: > > I understand nicolas. Now my agenda is more than full. >> and the proposal is here. Simple >> >> ========================================================== >> One repo per version Pharo1.0, Pharo11 ... MetacelloRepository >> containing **published** configurationOfXXX >> -> all the dependent packages are copied locally + configuration >> ready to load using load. >> >> A project >> contain its single/or several configurationOfMyProject with the >> complete history >> people commit the config to their repository and if they want they >> **publish** from their repository to the version repository >> a version. This version is frozen -> all the dependent packages are >> copied locally + configuration ready to load using load. >> >> For Pharo core or pharo packages that we maintain we want to maintain it >> as a project. >> with its own repository and packages. >> >> We can use automatic build server to validate the status or migration >> between different repositories >> ========================================================== >> >> >> Stef >> >> On May 17, 2010, at 11:00 PM, Nicolas Cellier wrote: >> >> The meaning of my message was don't do it for squeak, but do it for >>> yourself. >>> I don't doubt the mailing list is a mine of information, but even in >>> the best mine you need to dig a lot before extracting the gold >>> nuggets. >>> Of course, I've got no right to control your agenda, who am I ? >>> You can consider the subject close, and I won't find your attitude >>> shocking at all. >>> But next time, consider writing a rationale for your own, it will >>> increase quality of Pharo decision process. >>> >>> Best regards >>> >>> Nicolas >>> >>> 2010/5/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>>> nicolas >>>> >>>> all the information is in the metacello mailing-list and we already >>>> posted many mails on that topics in this mailing list. >>>> I'm sorry but I do not have the time to repeat again what we said. Now >>>> since I'm in a really good mood >>>> in a nutshell >>>> >>>> one repo per version Pharo1.0, Pharo11 ... MetacelloRepository >>>> containing configurationOfXXX frozen = all the dependent packages >>>> are copied locally + configuration ready to load using load. >>>> >>>> a project >>>> contain its single/or whatever configurationOfMyProject >>>> people publish the config to their repository and if they want they >>>> push from their repository to the version repository >>>> a version that they freeze (may be using tags) >>>> >>>> For Pharo core or pharo packages that we maintain we want to maintain it >>>> as a project. >>>> with its own repository and packages. >>>> >>>> Then we have a server that load configuration and barks if something >>>> wrong happen. And may be we kick out >>>> the configurationofXXX from MetacelloRepositories >>>> >>>> Steph, >>>>> I understand how boring it may seem: >>>>> - you already discussed the subject over and over >>>>> - you already took decisions >>>>> and now we come later with new proposals, and ask you to reconsider >>>>> the work again... >>>>> >>>> >>>> more than that. :) >>>> It looks like if we did not talk or think about what we are doing. >>>> >>>> >>>> As for the Preferences/Settings, Pharo choices are probably very weel >>>>> thought. >>>>> >>>>> However, every solution will come with trade offs, and it would be >>>>> good to have a rationale justifying the choices you made, and perhaps >>>>> more importantly justifying why you did abandon some solutions, >>>>> because some questions might be repeated in Pharo 1.2, 1.3, 2.0 ... >>>>> and find different answers in different context. Note that Squeak >>>>> evolutions might have influence on Pharo too, and it's part of the >>>>> context... >>>>> >>>>> I strongly encourage you to establish your rationale on Pharo grounds >>>>> - independently of Andreas proposals, put it on the Pharo wiki and let >>>>> us know the URL. >>>>> >>>>> You also know that Squeak goals are not exactly those of Pharo w.r.t. >>>>> backward compatibility, so Squeak can't just blindly replicate Pharo >>>>> solutions without a rationale. >>>>> >>>>> The merit of Andreas proposal is to try and establish such a >>>>> rationale. Without it, we're bound to repeat discussions again and >>>>> again, >>>>> >>>> >>>> So to fix the problem consider that as our proposal. >>>> >>>> Stef >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > www.tudorgirba.com > > "Every thing has its own flow." > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 18, 2010