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

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

by Sean Allen

This is a known issue on windows w/ at least firefox. You can fix it by turning off ipv6: Turn off using ipv6 in firefox to solve... http://kb.mozillazine.org/Network.dns.disableIPv6 you could also look into this ( but i dont think it works for localhost )... http://kb.mozillazine.org/Network.dns.ipv4OnlyDomains On Wed, Aug 4, 2010 at 1:04 PM, George Herolyants <george.herolyants(a)gmail.com> wrote: > 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 >> > > _______________________________________________ > 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

[Pharo-project] Pharo 1.1. impressions and suggestions

by Janko MivÅ¡ek

Dear Pharoers, I just finished syncing new Aida from VW on new Pharo 1.1 and during that I collect few impressions and also suggestions, how to proceed. Please find them as a kind of "concrete congratulation" to your work :) Impressions: =========== - design is nice and polished, default font looks professional - responsiveness and speed of browsing seems now fast enough - very nice and simple Word menu - nicely enhanced Inspector - nice Google-like search in browser - Aida is among few projects on DEVImageWorkspace, thanks guys! - Settings browser is a real progress forward, nicely organized, but with still too much choices. I suppose many settings are never or really rarely used, those should be put outside this Settings browser. - Help system also looks very promising! With an introduction of context help also (like ? icons elsewhere) we can come close to ideal help. Of course we need also good docs writers to write a really good help, nicely balanced between a newcomer than expert viewpoint. Suggestions: =========== - some Start button? Maybe named World? Not just ProfStef's 'go evaluation' (which is much better than nothing of course). At least a right click to come to a Word menu must be explained somewhere at the start, otherwise one is lost how to proceed. - window buttons on Linux and Windows are on the wrong side. This is very dangerous thing, user can quickly make en error and accidentialy close a window. In any case it is very very annoying! A real showstopper for me! - System browser has no package view, just categories. This is confusing to newcomers, what are packages, what categories? Having packages also in a category view will be more understandable. - back button in browser, like on web browsers! - why hierarchy button opens a new browser, why rather not toggle hierarchy/category view in the same window? - in general: avoid opening new windows, rather "reuse" the same one. This is the current usability trend elsewhere. - What about introducing tabs in browser? This is very very useful and handy, mostly because we are used of tabs from web browsers. - Browser opens just too small size. It should open in a size recomendable for further development (like for encouraging the 10 lines per method rule) - What if we introduce "add class", "add method" etc. dialogs in menu too? Yes yes I know, but look from a newcomer perspective.. - Search line on the top of browser should have a 'Search:' at the start, to find it easily with an eye. What if it ignore the upper/lowercase by default. Users are used of ignore-case search from elsewhere, like Google. - Inspector and explorer still two different but very similar things. Inspector is now much better than before, having tree view of inspected object do we still need to add confusion with additional explorer? - Help needs a search field. API docs hierarchy is quite deep and without a search near to unusable. Also, in a System browser there need to be a link to the corresponding help text. And vice versa, link to the class in browser from help. - Still no breakpoints! Please introduce them, Squeak/Pharo seems nowadays the only Smalltalk without breakpoints! - why isn't a class comment visible below the class definition in the same pane, as was once? - Undocumented classes should have a special mark to encourage commenting them. Maybe that question mark button (?) in red color? - Popup menu in method pane is too large, some choices not really so important to be there (like paste..., explore it, do again(redo?) ) - Popup menu: choices find, find again, extended search should be joined in one find... - Popup menu: set breakpoint, clear breakpoint Best regards Janko -- Janko MivÅ¡ek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565

Aug. 4, 2010

Re: [Pharo-project] about ToolBuilder

by Carla F. Griggio

Hmmm but if Mars is using it, there will be another UI framework using ToolBuilder, so it would have sense to keep it, maybe? 2010/8/4 Richard Durr <richard.durr(a)googlemail.com> > Ups, it was not written by Gilad but by Vassili: > > http://blog.3plus4.org/2008/11/13/how-to-design-a-smalltalk-ui-framework/ > > > On Tue, Aug 3, 2010 at 12:15 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > >> Oh, I'm using it for Mars... but I can remove it anyway, just let me know. >> >> Cheers, >> Esteban >> >> >> On 2010-08-02 17:05:58 -0300, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> said: >> >> I agree that it should be removed, but this means that many tools need >>>> to be rewritten in plain morphic. >>>> >>> >>> do you know which ones? >>> Because a lot of buildwith: methods are not used in fact. >>> >>> Lukas >>>> >>>> 2010/8/2 Richard Durr <richard.durr(a)googlemail.com>: >>>> >>>>> +1. >>>>> See Gilad's text about least common denominator in UI-widgetery >>>>> >>>>> On Fri, Jul 30, 2010 at 12:20 PM, stephane ducasse >>>>> <stephane.ducasse(a)free.fr> wrote: >>>>> >>>>>> >>>>>> Hi guys >>>>>> >>>>>> during the sprint I discussed with Gary about ToolBuilder and we think >>>>>> that it would be better to remove it >>>>>> since a lot of new widgets are not covered so this means that we will >>>>>> be >>>>>> constantly limiting ourselves. >>>>>> Of course ToolBuilder is a nice idea (if we would have several UI >>>>>> framework). So far we got only one >>>>>> and we would have several we would have to take the smallest common >>>>>> denominator. >>>>>> Another idea would be to extend toolBuilder to support new widgets. >>>>>> So what do you think? >>>>>> >>>>>> 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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> Lukas Renggli >>>> www.lukas-renggli.ch >>>> >>>> _______________________________________________ >>>> 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 Dale Henrichs

Miguel, I think that this kind of approach makes lots of sense ... I've toyed with the idea of a "white list" of configuration versions, but someone would have to be responsible for maintaining the "white list" and the users would have to responsible for using the "white list" ... A repository per version is very simple and gives the maintainer flexibility in managing releases. Dale 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 >

Aug. 4, 2010

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