- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Collection arithmethic method category

by Fernando olivero

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

May 18, 2010

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

by Adrian Lienhard

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

May 18, 2010

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

by Tudor Girba

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."

May 18, 2010

Re: [Pharo-project] HTTP Proxy server ...

by Geert Claes

Mariano Martinez Peck wrote: > >> I can't seem to connect using a proxy server with network authentication. >> I >> have now successfully saved the HTTP proxy server and port number as well >> as >> the user name and password. I am using 1.1 using the new Settings >> browser >> and successfully updated the settings in "MyOwn" settings style. >> > I didn't understand. Is it working or not ? For me it was working when > setting all the fields. > No, when I do a "System > Software update" I get a message saying "All code update servers seem to be unavailable" and when I try to Open a Monticello repository I get: "Error: Could not access http ...". How do I find out if the settings I have saved are actually being used? Mariano Martinez Peck wrote: > >> Also, how can I set the "use automatic configuration script"? Is there >> maybe a way for the VM to detect the proxy settings somehow just like a >> web >> browser detects the network/proxy settings from the host OS? >> > I don't know. In my experience (in mac) it automatically detects the proxy > and port, but not the username and password. > So...if there is proxy without authentication, I don't need to do > anything. > But if it is required, then I need to define it in the settings browser. > On my mac at home all works fine (no proxy server there) but on windows it doesn't detect anything. I had to manually add the proxy server, port, user name and password. -- View this message in context: http://forum.world.st/HTTP-Proxy-server-tp2220967p2220992.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 18, 2010

Re: [Pharo-project] Decoding bug with XMLParser ?

by Alexandre Bergel

To give a bit of context, the problem is: -=-=-=-=-=-=-=-=-=-=-=-= exampleEncodedXML ^'<?xml version="1.0" encoding="UTF-8"?> <test-data>…</test-data> ' testDecodingCharacters | xmlDocument element | "XMLTokenizer testDecodingCharacters" xmlDocument := XMLDOMParser parseDocumentFrom: self exampleEncodedXML readStream. element := xmlDocument firstTagNamed: #'test-data'. self assert: element contentString first codePoint = 8230 -=-=-=-=-=-=-=-=-=-=-=-= #testDecodingCharacters goes yellow > Thinking of it, it's not really an encoding problem, rather a bug in > the entity->character conversion. I guess there should be a similar > test where there is an actual ellipsis character in the xml, instead > of the entity. Any idea how your test can goes green? > And now I realize our server will not be able to connect outside its > DMZ, so I won't be able to use the fix :D DMZ ? Cheers, Alexandre > > > > >> On 16 May 2010, at 13:35, Damien Pollet wrote: >> >>> Hi, >>> >>> I have a failing test to show the problem, but I can't commit to the >>> XMLSupport squeaksource, so I attach the MCZ here. >>> Basically, if I parse an UTF-8 document with an entity like … >>> (ellipsis), I don't get a Character with the correct #codePoint. >>> >>> Cheers, >>> >>> -- >>> Damien Pollet >>> type less, do more [ | ] http://people.untyped.org/damien.pollet >>> <XML-Parser-DamienPollet.75.mcz> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet

May 18, 2010

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

by StÃ©phane Ducasse

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 > > 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

May 18, 2010

Re: [Pharo-project] Collection arithmethic method category

by StÃ©phane Ducasse

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

May 18, 2010