- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN] PharoConfigurationBrowser

by Miguel Enrique CobÃ¡ MartÃnez

El miÃ©, 04-08-2010 a las 19:34 +0200, StÃ©phane Ducasse escribiÃ³: > > > I like this one > > - MetacelloForPharoXX This one appears like a fork of Metacello that works on PharoXX release. This is a little misleading name. > > then > - MetaRepoForPharoXX I like this too. I'll create the repositories with this name format: http://www.squeaksource.com/MetaRepoForPharo10 http://www.squeaksource.com/MetaRepoForPharo11 http://www.squeaksource.com/MetaRepoForPharo12 Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Aug. 4, 2010

Re: [Pharo-project] update to OCompletion

by Mariano Martinez Peck

2010/8/4 Tim Mackinnon <tamackinnon(a)gmail.com> > That's a great explanation - that clears up a number of things for me - I > appreciate that. > I am glad I helped. You can also take a look to the Metacello draft we wrote for Pharo By Example 2. I attach it. Cheers Mariano > > Tim > > On 4 Aug 2010, at 17:53, Mariano Martinez Peck wrote: > > > > 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 >> > > _______________________________________________ > 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] PharoConfigurationBrowser

by StÃ©phane Ducasse

On Aug 4, 2010, at 6:26 PM, Miguel Enrique CobÃ¡ MartÃnez wrote: > > - RepositoryForPharoXX > - RepositoryPharoXX > - RepoPharoXX > - RepoForPharoXX > I like this one > - MetacelloForPharoXX then - MetaRepoForPharoXX then > - MetaRepoPharoXX > - MetacelloPharoXX > - PackagesForPharoXX > - MetaPoolForPharoXX

Aug. 4, 2010

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

by StÃ©phane Ducasse

thanks for the explanation :) this is great! On Aug 4, 2010, at 6:09 PM, Miguel Enrique CobÃ¡ MartÃnez wrote: > 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 > > > _______________________________________________ > 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 StÃ©phane Ducasse

>> > > I have read the discussions and yes that would be good but some things > concern me: > - Repository size (maybe this is not a problem but the squeak source > downtime come to mind) memory disc is cheap > - Load in the squeak source when sync is being done. yes > - Who syncs the packages, Metacello when uploadingÂ¡ Some webmaster? A > cron? the commiter press a button: "archive" and as a side effect all the packages are recursively pulled up and save :) > - What about conflicting names in packages. I would not bother right now. > - Maybe RFB-MiguelCoba.25 in ConfigurationOfRFB ask it from lukas repo > and ConfigurationOfOtherPackage requires RFB-MiguelCoba.25 from > squeaksource RFB repository and for any reason the packages are distinct > (maybe a bug was found and republished in lukas repo with the same > version number, but squeaksource version was copied before the fix was > done) the one loaded by the config should be the one saved. > Maybe those problems never show. Anyway, the idea of having all > available is good, but maybe not a task of Metacello, but as an > independent effort. Metacello will just use the redundant repositories > when installing a package. > > > Cheers > >> >> Else this is great. >> >> Stef >> >> >> On Aug 4, 2010, at 11:41 AM, Adrian Lienhard wrote: >> >>> Hi Miguel, >>> >>> Thanks! It's great to see progress on this front! >>> >>> Cheers, >>> Adrian >>> >>> On Aug 4, 2010, at 10:21 , Miguel Enrique CobÃ¡ MartÃnez wrote: >>> >>>> Hi all, >>>> >>>> I have created three new repositories on squeaksource: >>>> >>>> http://www.squeaksource.com/UniverseForPharo10 >>>> http://www.squeaksource.com/UniverseForPharo11 >>>> http://www.squeaksource.com/UniverseForPharo12 >>>> >>>> They are the repositories for the current versions of Pharo. The idea is >>>> that each new release add a new UniverseForXXX repository and populates >>>> it with the current UniverseForXXX packages of the stable release. >>>> >>>> Right now they are mostly empty, but should be populated by the >>>> community and the ConfigurationOfXXX maintainers. >>>> >>>> Most ConfigurationOfXXX packages in >>>> >>>> http://www.squeaksource.com/MetacelloRepository >>>> >>>> should be copied to UniverseForPharo10. Which versions? The last known >>>> version that is working correctly on Pharo 1.0. This will be the >>>> official universe for Pharo1.0. No ConfigurationOfXXX should be stored >>>> on UniverseForPharo10 if it is not working correctly on Pharo10. >>>> >>>> Then two things can follow: >>>> >>>> - If the package already has ConfigurationOfXXX package versions that >>>> work in Pharo 1.1, those versions should be copied to >>>> UniverseForPharo11. >>>> >>>> - If the ConfigurationOfXXX only works for Pharo1.0 and the maintainer >>>> want to create the configuration for Pharo 1.1, he/she must copy the >>>> last working configuration for the package from UniverseForPharo10 to >>>> UniverseForPharo11. There he/she can start modifying the package until >>>> it works correctly in Pharo1.1 (use the blessing: tags wisely to avoid >>>> marking a broken configuration as released) >>>> >>>> This will permit to populate the UniverseForPharo11 based on the last >>>> working package versions from UniverseForPharo10. From that point they >>>> will likely diverge because of maintenance releases to the packages in >>>> any UniverseForXXX repository. >>>> >>>> The same will must be done to migrate from UniverseForPharo11 to >>>> UniverseForPharo12. You get the idea. >>>> >>>> With time, MetacelloRepository should be deprecated in favor of this >>>> UniverseForXXX repositories. >>>> >>>> Anyone is free to copy a working version from a previous Universe to a >>>> new Universe. They have read/write permissions to all. >>>> >>>> This setup will avoid the problems we are having right now with the >>>> in-image changes that are rendering the ConfigurationOfXXX unusable in >>>> distinct releases of Pharo. >>>> >>>> What this means to the end user: >>>> >>>> - For released version of Pharo >>>> >>>> They will have to use gofer this way: >>>> >>>> Gofer new >>>> squeaksource: 'UniverseForPharo10'; "Or UniverseForPharo11" >>>> project: 'ConfigurationOfMagma'; >>>> load. >>>> ConfigurationOfMagma project latestVersion load. >>>> >>>> - For next releases of Pharo >>>> >>>> Gofer loadFromUniverse: 'Magma'. "Or with GoferProjectLoader" >>>> ConfigurationOfMagma project latestVersion load. >>>> >>>> All this depends on conventions to find the appropriate universe for >>>> each pharo release, and also in the support from tools (like gofer in >>>> this example or the GoferProjectLoader if it is part of the core image). >>>> The universe functionality of the tools right now rely on the >>>> SystemVersion current majorMinorVersion string for deciding which >>>> repository to connect to. This could be improved surely but for now it >>>> works. >>>> >>>> I'm loading a new version of Gofer to PharoInbox with this functionality >>>> added so if you want to load directly from the universes with gofer do: >>>> >>>> Gofer upgrade. >>>> Gofer loadFromUniverse: 'YourPackageAlreadyInAUniverse'. >>>> >>>> But wait to this change to be treated by Stephane or Lukas before >>>> attempt it. >>>> >>>> Right now there is only Magma in the three repositories, but it >>>> shouldn't be hard for the maintainers of the other Configurations to >>>> help populate the universes from Pharo1.0, Pharo1.1 and Pharo1.2. >>>> >>>> This will benefit us as a community because the universes for the >>>> released pharo versions will be mostly untouched (only maintenance >>>> releases) and people will have the freedom to modify the configuration >>>> in the unstable (currently UniverseForPharo12) universe without >>>> affecting the users of the stable versions. >>>> >>>> Also, this will avoid to have a lot of conditionals inside the >>>> ConfigurationOfXXX classes, because a given class will target a specific >>>> Pharo release (the version on the newest universes could even delete the >>>> methods for the old universe, because will likely won't work in the new >>>> universe, deleting unnecessary and legacy code from the configuration) >>>> >>>> Comments and improvements welcome >>>> >>>> -- >>>> 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 >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 Tim Mackinnon

That's a great explanation - that clears up a number of things for me - I appreciate that. Tim On 4 Aug 2010, at 17:53, Mariano Martinez Peck wrote: > > > 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 > > _______________________________________________ > 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] [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