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

Re: [Pharo-project] [squeak-dev] Re: HTTP client library in Pharo?

by Andrey Larionov

Hi, Andreas. Could you also look in cross-domain cookie handling. When domain specified with leading period. For example: .squeak.org It mean, what cookie will be available for squeak.org domain and for all subdomains of squeak.org. On Wed, Aug 4, 2010 at 21:15, Andreas Raab <andreas.raab(a)gmx.de> wrote: > ah, that's a silly bug. Thanks for reporting.

Aug. 4, 2010

Re: [Pharo-project] HTTP client library in Pharo?

by Andreas Raab

On 8/4/2010 9:57 AM, Mariano Martinez Peck wrote: > Hi Adrei, excellent :) > > BTW, for HTTP Client you should cc Andreas Raab or squeak mailing list.... Squeak-dev please (http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-dev) > On Wed, Aug 4, 2010 at 6:08 PM, Andrei Stebakov <lispercat(a)gmail.com > <mailto:lispercat@gmail.com>> wrote: > > I also found that cookies were not correctly sent. > Every cookie was sent with its own "Cookie: " header which is not > correct. I'm curious, why do you think that's incorrect? My understanding is that RFC 2616 explicitly allows that: "Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one 'field-name: field-value' pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma." And the condition appears to be satisfied in RFC 2109 regarding the Cookie header: "The syntax for the header is: cookie = "Cookie:" cookie-version 1*((";" | ",") cookie-value) ... " > Also cookie collection is too restrictive to the domain. Let's say > your request goes to www.domain.com <http://www.domain.com> and in > the cookies it'll have > domain.com <http://domain.com>. > Those cookies won't be collected since the current algorithm requires > it to match from the start of the string (probably should only match > the end of the string). Yeah, that's a silly bug. Thanks for reporting. Cheers, - Andreas

Aug. 4, 2010

Re: [Pharo-project] [Seaside] bad performance Pharo Windows 7 64bit

by George Herolyants

BTW. This may sound strange, but I experience great requests execution time using Firefox on Windows Vista (which is quite similar to Win7). When I access seaside through "localhost" at the address bar, every request takes about one second! But when I write ip-address (127.0.0.1), requests execution time decreases to about 10ms! Though I don't know the reasons of such strange behaviour. Maybe it's DNS versus Netbios names resolving issue. Sadly but IE doesn't have such an issue :). 2010/8/4 Mariano Martinez Peck <marianopeck(a)gmail.com>: > BTW....you should say also which VM versionÂ you are using. > > Cheers > > Mariano > > On Wed, Aug 4, 2010 at 4:45 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: >> >> >> On Wed, Aug 4, 2010 at 4:44 PM, Mariano Martinez Peck >> <marianopeck(a)gmail.com> wrote: >>> >>> The only BIG problem I found using Pharo in Windows is when there are >>> some antivirus running like Nod32 or friends. Mostly when using Monticello >>> as .changes are changing all the time, the antivirus runs the scan every >>> time.... The way to solve is to exclude the Pharo folder from the antivirus >>> analysis. >>> >>> Sorry, maybe this has nothing to do with your case. >>> >>> Cheers >>> >>> Mariano >>> >>> On Wed, Aug 4, 2010 at 4:34 PM, Bart Veenstra <bart.veenstra(a)gmail.com> >>> wrote: >>>> >>>> Hi, >>>> I am among the few people still using windows for my development and I >>>> won't make the switch to OS-X because I simply love my keyboard layout >>>> and shortcuts. And...Windows 7 is not that bad after all.. >>>> When I use seaside-3.0rc on a Windows XP 32bit system at work, i get >>>> the performance I expect. >>>> >>>> Opening the JQuery UI example on WXP takes 766ms in total : >>>> >>>> >>>> GET jquery-ui http://localhost:8080/javascript/jquery-ui Â 200 OK >>>> localhost:8080 7.6 KB Â 63ms >>>> GET jQuery.js http://localhost:8080/files/JQDeploymentLibrary/jQuery.js >>>> 200 OK localhost:8080 70.5 KB 47ms >>>> GET jQueryUi.js >>>> http://localhost:8080/files/JQUiDeploymentLibrary/jQueryUi.js 200 OK >>>> localhost:8080 187.8 KB 282ms >>>> GET development.css >>>> http://localhost:8080/files/WADevelopmentFiles/development.css 200 OK >>>> localhost:8080 2.9 KB 32ms >>>> and so on... >>>> >>>> On my W7 64bit, each request takes over a second: >>>> >>>> GET jquery-ui http://localhost:8080/javascript/jquery-ui 200 OK >>>> localhost:8080 7.6 KB 1.05s >>>> GET jQuery.js http://localhost:8080/files/JQDeploymentLibrary/jQuery.js >>>> 200 OK localhost:8080 70.5 KB 1.01s >>>> GET jQueryUi.js >>>> http://localhost:8080/files/JQUiDeploymentLibrary/jQueryUi.js 200 OK >>>> localhost:8080 187.8 KB 1.08s >>>> GET development.css >>>> http://localhost:8080/files/WADevelopmentFiles/development.css 200 OK >>>> localhost:8080 2.9 KB 1.01s >>>> >>>> As you can see, each request takes over a second on W7 64bit. >>>> >>>> Does anyone else noticed this behaviour? I have no performance issues >>>> in seaside for Vast80 and VW77. >>>> >>>> Regards, >>>> >>>> Bart >>>> _______________________________________________ >>>> seaside mailing list >>>> seaside(a)lists.squeakfoundation.org >>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 4, 2010

Re: [Pharo-project] [Metacello] Re: Trait missing method isMetacelloConfig in Pharo 1.1

by Dale Henrichs

Jochen, Trait isn't present in all of the smalltalks that metacello runs on, so I'm looking for a simple way to resolve the problem without doing something trait-specific ... I think I'll go with an Error handler instead ... only the classes that actually implement the method are interesting .... hmmm maybe a pragma would be even better ... Dale Jochen Riekhof wrote: > Hi Dale... > > being really new to all this, I might state the obvious, but my impression currently is that > > The purpose of isMetacelloConfig was to produce a class-side default method returning false if ob-metacello package is installed and override it when necessary in subclasses (class side) > The (false in Pharo) assumption was that Class is the proper base to cover all cases. Pharo has Traits which are not Classes, and on encountering these the assumption failed. > Putting isMetacelloConfig default method also to Trait sounds to me better than putting it to Object, as the intention was to have it just on the class/trait side of things. > > I do not know if it actually works, but maybe isMetacelloConfig default method should be defined in a Trait itself and used by Class and Trait? > > Ciao > > ...Jochen > > Am 03.08.2010 um 21:34 schrieb Dale Henrichs: > >> Mariano, >> >> My actual fix was to add the method to Object ... does that fix not work? >> >> Dale >> >> Mariano Martinez Peck wrote: >>> On Tue, Aug 3, 2010 at 7:29 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: >>> we could add that to trait is this helps. >>> Not necessary. It will just have the *ob-metacello category so that with Monticello it is packaged inside the Mteacello packages. >>> just the same as Class >> isMetacelloConfig >>> (I guess) >>> On Aug 3, 2010, at 7:25 PM, Mariano Martinez Peck wrote: >>> > You spotted a Metacallo bug. Thanks for the report. >>> > >>> > The problem is (I think) that in >>> > >>> > OBCmdMetacello >> isActive >>> > ^ ((target isKindOf: OBClassNode) >>> > and: [ requestor isSelected: target ]) >>> > and: [ self selectedClass isMetacelloConfig ] >>> > >>> > >>> > selectClass can be a Trait, not necessary Behavior. >>> > >>> > If you see, Metacello implemented >>> > >>> > Class >>isMetacelloConfig >>> > >>> > ^false >>> > >>> > But nothing in Trait. So...you can just add it also in Traits or... >>> > >>> > Maybe moving that method to Behavior helps? I am not sure how >>> Traits is implemented. Can you check? >>> > >>> > The problem is that Gemstone doesn't have Traits...thus problably >>> why the bug exists :) >>> > >>> > Cheers >>> > >>> > Mariano >>> > >>> > >>> > >>> > On Tue, Aug 3, 2010 at 6:16 PM, Jochen Riekhof <lists(a)riekhof.de >>> <mailto:lists@riekhof.de>> wrote: >>> > Hi... >>> > >>> > just noticed that I get a walkback after creating a Trait and >>> then opening the Context-Menu on the browser's classes list pane. >>> It complains >>> > MessageNotUnderstood: Trait>>isMetacelloConfig >>> > >>> > Adding the missing method to Trait solves the issue. Probably it >>> is just missing from {ob-metacello} package? >>> > >>> > Ciao >>> > >>> > ...Jochen >>> > >>> > >>> > _______________________________________________ >>> > Pharo-project mailing list >>> > Pharo-project(a)lists.gforge.inria.fr >>> <mailto:Pharo-project@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 >>> <mailto:Pharo-project@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 >>> <mailto:Pharo-project@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

Aug. 4, 2010

Re: [Pharo-project] HTTP client library in Pharo?

by Mariano Martinez Peck

Hi Adrei, excellent :) BTW, for HTTP Client you should cc Andreas Raab or squeak mailing list.... On Wed, Aug 4, 2010 at 6:08 PM, Andrei Stebakov <lispercat(a)gmail.com> wrote: > I also found that cookies were not correctly sent. > Every cookie was sent with its own "Cookie: " header which is not correct. > It should be in a format of "Cookies: name1=value1; name2=value2 " > I temporarily fixed it in my current image, I'll try to send out the > patch if it's not already fixed by someone else. > Also cookie collection is too restrictive to the domain. Let's say > your request goes to www.domain.com and in the cookies it'll have > domain.com. > Those cookies won't be collected since the current algorithm requires > it to match from the start of the string (probably should only match > the end of the string). > > Andrei > > On Sat, Jul 31, 2010 at 9:03 PM, Andrey Larionov <anlarionov(a)gmail.com> > wrote: > > I found WebClient resonably helpful. And in Pharo1.1 WebClient loaded > > with Metacello passes all tests green on Linux. In more recent version > > some test related to WebSockets are failed. > > I found WebClient lack of multi-domain cookie support and response > > encoding problems, but working on it right now. > > > > On Thu, Jul 29, 2010 at 20:06, Andrei Stebakov <lispercat(a)gmail.com> > wrote: > >> I've been trying to find a library for Pharo/Squeak which would handle > >> GET/POST requests with the ability to manage cookies and deal with > >> https servers. > >> The HTTPSocket that's included in Pharo doesn't have cookies support. > >> I tried to find any library that handles cookies and there came up > >> CurlPlugin and SWHTTPClient. > >> SWHTTPClient page has a broken link to the source code > >> (http://map.squeak.org/package/15f42ec1-e93e-4bcf-ab2b-6746ae9d413f) > >> CurlPlugin package for Win32 that I found on the main project page > >> fails most of the tests and can't retrieve any http data. > >> I also found WebClient/WebServer library at > >> http://www.squeaksource.com/@QY3MLGU4hU3c8qcE/2xQek_iM which also > >> fails most tests after installation. > >> > >> I wonder what people in smalltalk community are using when they need > >> to do some web scraping when they need to keep some session in > >> cookies? > >> What would be the best library to invest time into (I am very new to > Smalltalk)? > >> > >> Thank you, > >> Andrei > >> > >> _______________________________________________ > >> 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 >

Aug. 4, 2010

Re: [Pharo-project] update to OCompletion

by Mariano Martinez Peck

On Wed, Aug 4, 2010 at 2:09 AM, Tim Mackinnon <tamackinnon(a)gmail.com> wrote: > Am I missing something here - in a fresh 1.1 one click image if I do: > ConfigurationOfOCompletion project latestVersion load > > The problem is the following: latestVersion answer the latest version BUT not the ones that are blassed as #development, #broken, etc. See the method #excludeFromLatestVersion The latest (and working) version of Ocompletion is in version 1.1.2, which is blassed as #development. Thus, you are probably loading 1.1.1 (last one released). I like to let versions in development for a while, to detect bugs. And then, blasse those versions as release. So...if you want to load 1.1.2 explicitly, you can just do: (ConfigurationOfOCompletion project version: '1.1.1') load Or ConfigurationOfOCompletion project lastVersion load lastVersion doesn't exclude the cases I told you. Finally, you can always load a baseline. As baselines only have structural inormation, and you are not telling Metacello wich version to load for each package, it will load all the latests version. Thus, if you want to load the very latest versions of all packages, load a baseline. For example: (ConfigurationOfOCompletion project version: '1.1-baseline') load Cheers Mariano > I get an endless stream of errors: > > The method Boolean and:and: has been deprecated. > use and: > > Select Proceed to continue, or close this window to cancel the > operation.??????? > > > > On 3 Aug 2010, at 16:31, StÃ©phane Ducasse wrote: > > I have no problem. I ***love*** metacello and the garanty it offers to >> load packages coherently >> >> Stef >> >> On Aug 3, 2010, at 5:29 PM, Mariano Martinez Peck wrote: >> >> >>> >>> On Tue, Aug 3, 2010 at 5:20 PM, Romain Robbes <romain.robbes(a)gmail.com> >>> wrote: >>> >>>> Message: 7 >>>> Date: Tue, 3 Aug 2010 11:20:03 +0200 >>>> From: St?phane Ducasse <stephane.ducasse(a)inria.fr> >>>> Subject: Re: [Pharo-project] update to OCompletion >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Message-ID: <94557FA5-8F73-42B7-8537-3882867A80B5(a)inria.fr> >>>> Content-Type: text/plain; charset=us-ascii >>>> >>>> thanks romain (and sorry for my stupid suggestion - good that you >>>> corrected it) >>>> Your tools are really important. >>>> Is there a ConfigurationOfOCompletion or just loading OCompletion works? >>>> >>> >>> >>> Yes, Mariano made a ConfigurationOfOCompletion. Otherwise, just loading >>> the latest OCompletion package on top of the old one should work too. >>> >>> >>> My conf says you also need Shout and RoelTyper ;) but maybe they are >>> optional >>> >>> >>> Romain >>> >>> -- >>> Romain Robbes >>> http://romain.robb.es >>> rrobbes(a)dcc.uchile.cl >>> >>> >>> _______________________________________________ >>> 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 >

Aug. 4, 2010

Re: [Pharo-project] [Metacello] Re: Trait missing method isMetacelloConfig in Pharo 1.1

by Jochen Riekhof

Hi Dale... being really new to all this, I might state the obvious, but my impression currently is that The purpose of isMetacelloConfig was to produce a class-side default method returning false if ob-metacello package is installed and override it when necessary in subclasses (class side) The (false in Pharo) assumption was that Class is the proper base to cover all cases. Pharo has Traits which are not Classes, and on encountering these the assumption failed. Putting isMetacelloConfig default method also to Trait sounds to me better than putting it to Object, as the intention was to have it just on the class/trait side of things. I do not know if it actually works, but maybe isMetacelloConfig default method should be defined in a Trait itself and used by Class and Trait? Ciao ...Jochen Am 03.08.2010 um 21:34 schrieb Dale Henrichs: > Mariano, > > My actual fix was to add the method to Object ... does that fix not work? > > Dale > > Mariano Martinez Peck wrote: >> On Tue, Aug 3, 2010 at 7:29 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: >> we could add that to trait is this helps. >> Not necessary. It will just have the *ob-metacello category so that with Monticello it is packaged inside the Mteacello packages. >> just the same as Class >> isMetacelloConfig >> (I guess) >> On Aug 3, 2010, at 7:25 PM, Mariano Martinez Peck wrote: >> > You spotted a Metacallo bug. Thanks for the report. >> > >> > The problem is (I think) that in >> > >> > OBCmdMetacello >> isActive >> > ^ ((target isKindOf: OBClassNode) >> > and: [ requestor isSelected: target ]) >> > and: [ self selectedClass isMetacelloConfig ] >> > >> > >> > selectClass can be a Trait, not necessary Behavior. >> > >> > If you see, Metacello implemented >> > >> > Class >>isMetacelloConfig >> > >> > ^false >> > >> > But nothing in Trait. So...you can just add it also in Traits or... >> > >> > Maybe moving that method to Behavior helps? I am not sure how >> Traits is implemented. Can you check? >> > >> > The problem is that Gemstone doesn't have Traits...thus problably >> why the bug exists :) >> > >> > Cheers >> > >> > Mariano >> > >> > >> > >> > On Tue, Aug 3, 2010 at 6:16 PM, Jochen Riekhof <lists(a)riekhof.de >> <mailto:lists@riekhof.de>> wrote: >> > Hi... >> > >> > just noticed that I get a walkback after creating a Trait and >> then opening the Context-Menu on the browser's classes list pane. >> It complains >> > MessageNotUnderstood: Trait>>isMetacelloConfig >> > >> > Adding the missing method to Trait solves the issue. Probably it >> is just missing from {ob-metacello} package? >> > >> > Ciao >> > >> > ...Jochen >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> <mailto:Pharo-project@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 >> <mailto:Pharo-project@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 >> <mailto:Pharo-project@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

Aug. 4, 2010

Re: [Pharo-project] [ANN] PharoConfigurationBrowser

by Miguel Enrique CobÃ¡ MartÃnez

El miÃ©, 04-08-2010 a las 10:52 -0500, Miguel Enrique CobÃ¡ MartÃnez escribiÃ³: > El miÃ©, 04-08-2010 a las 15:16 +0200, StÃ©phane Ducasse escribiÃ³: > > Thanks! > > As soon as miguel changes the name (universes to metacelloRepositories) I will integrate it. > > > > Stef > > Then we settle on > > www.squeaksource.com/MetacelloRepositoryForPharo10 > www.squeaksource.com/MetacelloRepositoryForPharo11 > www.squeaksource.com/MetacelloRepositoryForPharo12 > > ? > > Cheers > > I tried to create those repositories but squeaksource has a limit on package names of 20 chars. Other options are: - MetaRepoPharoXX - RepositoryForPharoXX - RepositoryPharoXX - RepoPharoXX - RepoForPharoXX - MetacelloForPharoXX - MetacelloPharoXX - PackagesForPharoXX - MetaPoolForPharoXX I really want to use prefixes because that way they appear listed together in squeaksource. And is easier for users to identify all the repositories for all the Pharo releases. You are free to propose other naming conventions. Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Aug. 4, 2010

Re: [Pharo-project] Trait missing method isMetacelloConfig in Pharo 1.1

by Dale Henrichs

I plan to handle the issue by having a MNU handler for isMetacelloConfig use ... until then patching Trait will work... Dale StÃ©phane Ducasse wrote: > sounds good compromise indeed. > > Stef > > On Aug 3, 2010, at 7:31 PM, Mariano Martinez Peck wrote: > >> >> On Tue, Aug 3, 2010 at 7:29 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> we could add that to trait is this helps. >> >> >> Not necessary. It will just have the *ob-metacello category so that with Monticello it is packaged inside the Mteacello packages. >> just the same as Class >> isMetacelloConfig >> >> (I guess) >> >> >> On Aug 3, 2010, at 7:25 PM, Mariano Martinez Peck wrote: >> >>> You spotted a Metacallo bug. Thanks for the report. >>> >>> The problem is (I think) that in >>> >>> OBCmdMetacello >> isActive >>> ^ ((target isKindOf: OBClassNode) >>> and: [ requestor isSelected: target ]) >>> and: [ self selectedClass isMetacelloConfig ] >>> >>> >>> selectClass can be a Trait, not necessary Behavior. >>> >>> If you see, Metacello implemented >>> >>> Class >>isMetacelloConfig >>> >>> ^false >>> >>> But nothing in Trait. So...you can just add it also in Traits or... >>> >>> Maybe moving that method to Behavior helps? I am not sure how Traits is implemented. Can you check? >>> >>> The problem is that Gemstone doesn't have Traits...thus problably why the bug exists :) >>> >>> Cheers >>> >>> Mariano >>> >>> >>> >>> On Tue, Aug 3, 2010 at 6:16 PM, Jochen Riekhof <lists(a)riekhof.de> wrote: >>> Hi... >>> >>> just noticed that I get a walkback after creating a Trait and then opening the Context-Menu on the browser's classes list pane. It complains >>> MessageNotUnderstood: Trait>>isMetacelloConfig >>> >>> Adding the missing method to Trait solves the issue. Probably it is just missing from {ob-metacello} package? >>> >>> Ciao >>> >>> ...Jochen >>> >>> >>> _______________________________________________ >>> 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

Aug. 4, 2010

Re: [Pharo-project] [ANN] Pharo Metacello Universes

by Miguel Enrique CobÃ¡ MartÃnez

El miÃ©, 04-08-2010 a las 19:52 +0400, Andrey Larionov escribiÃ³: > Why there should be repository per release? As i know > MetacelloConfiguration already contains information about compatible > Pharo versions. Because is cleaner and as the releases of Pharo diverge a lot more, the code to install package becomes full of conditionals to handle the distinct issues with each pharo release. For example, Magma. Magma 1.1r1 worked good in any pharo 1.0, 1.1 and 1.2. But Magma 1.1r2 doesn't work anymore on Pharo1.0 because Pharo 1.0 doesn't have the classes DirectoryEntryDirectory and DirectoryEntryFile that are used by the new magma version. So I had to modify the configuration with conditionals an several variations of preDoits and postDoits and test what version image is ConfigurationOfMagma is being ran. After a couple of hours I gave up. The correct solution is to have a specific ConfigurationOfMagma for each released pharo version. This have benefits also: - It permits the unstable repository to heavily update the ConfigurationOfXXX without disturbing or broke the stable ones. - It permits the ConfigurationOfXXX code to remain clean, without a conditionals for every posible combination of release image version and package to be installed version - It permits the maintainer of a ConfigurationOfXXX to decide when to stop supporting old version of a certain package by deleting the old versionXX: methods of the ConfigurationOfXXX in the newer pharo releases. Not always is good to be able to install each and every version of a package in the newest release of pharo (maybe even old versions won't work in the new releases, like the menu registration issue or classes that doesn't belong to the core image) - It permits to issue maintenance ConfigurationOfXXX releases for a stable or "old-stable" image releases, without altering the configurationOfXXX in other repositories Cheers > > 2010/8/4 Miguel Enrique CobÃ¡ MartÃnez <miguel.coba(a)gmail.com>: > > El miÃ©, 04-08-2010 a las 11:46 +0200, Torsten Bergmann escribiÃ³: > >> Hi Miguel, > >> > >> hey, nice! If we follow this convention then it is easy to implement > >> a universe browser that selects the correct universe repo and > >> displays all loadable versions. Loading stuff should just be > >> a few clicks away - I personally hate all this MC/Gofer typing ... > >> > >> Attached is a quick/simple implementation of such a browser: > >> > > > > Mann, Sie sind Ã¼ber schnell! > > > > I tested it in PharoCore 1.0 and worked after a few changes, but the > > interface is cool. +1 to aim it be the default universe browser in 1.2. > > Simple, to the point. > > In Pharo 1.0 I had: > > > > - Open it with Universe open (doesn't register on menu because of the > > lacking pragmas) > > - UniverseBrowser pharoUniverse returns PharoCore1.0 instead of Pharo10 > > to build the universe name. This could be changed in two ways: > > - Add a system property that states the image repository: > > SystemVersion current universeName "Returns Pharo10 for image > > releases 1.0, 1.0.1, 1.0.5, etc) > > - Use the equivalent method in the gofer package I uploaded to > > PharoInbox (if it is approved, so there is only a unique source for > > converting image version string to universe names) > > > > Other than that, I like the browser. > > > > > > > >> - file in the attached changeset (I tried in Pharo 1.2) > >> - open via World menu -> "Universe Browser" > >> - select the configuration you want and from the context menu choose > >> -- "Load configuration" -> only the config is loaded > >> -- "Load configuration and latest version" -> the config and lates version is loaded > >> > >> Have fun! I used Pharo 1.2 - should work in Pharo 1.0 and 1.1 too > >> (havent tested). > >> > >> Bye > >> T. > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > Cheers > > > > -- > > Miguel CobÃ¡ > > http://miguel.leugim.com.mx > > > > > > _______________________________________________ > > 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 -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Aug. 4, 2010