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

Re: [Pharo-project] Faster Sets and Pharo 1.1?

by Chris Muller

Hmm, well, that only moves the goal posts to ~320K. I just ran a bigger test in 3.9. Not only are the numbers comparable at the beginning of the test with a small IdentitySet, they only degrade to 10X slower at 1M elements. The trunk IdentitySet seems to have much more rapid degradation... On Wed, Mar 17, 2010 at 9:40 PM, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > Â On 18.03.2010 02:08, Chris Muller wrote: >> >> Thank you very much for the links. Â Ok, so if you take Lukas' test >> code from the first link, and try it in trunk. Â Here it is, but >> tweaked for an IdentitySet and increased to simulate a modestly-sized >> real-world use-case, 250K elements: >> >> | test ord | >> test := IdentitySet new. >> [ test size>= 250000 ] whileFalse: [ >> Â Â ord := OrderedCollection new: 100. >> Â Â 1000 timesRepeat: [ >> Â Â Â Â test add: ( ord add: Object new ) ]. >> Â Â Transcript >> Â Â Â Â show: test size asString; >> Â Â Â Â tab. >> Â Â Transcript show: >> Â Â Â Â [ >> Â Â Â Â Â Â 10 timesRepeat: [ >> Â Â Â Â Â Â Â Â ord do: [ :each | test includes: each ] ] >> Â Â Â Â ] timeToRun asString. >> Â Â Transcript cr ] >> >> 3.9 can run this entire thing and be done with it in under one minute. >> Â In trunk, all looks pretty fine until 136K elements, at which point >> it completely seizes up; worse by a factor of> Â 120X. >> >> Â - Chris > > Simplistic fix: > - remove 282311 from HashedCollection class>>goodPrimes. > > The table should probably be remade for squeak, keeping in mind the > scaledIdentityHash implementation. > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 18, 2010

Re: [Pharo-project] Faster Sets and Pharo 1.1?

by Henrik Sperre Johansen

On 18.03.2010 02:08, Chris Muller wrote: > Thank you very much for the links. Ok, so if you take Lukas' test > code from the first link, and try it in trunk. Here it is, but > tweaked for an IdentitySet and increased to simulate a modestly-sized > real-world use-case, 250K elements: > > | test ord | > test := IdentitySet new. > [ test size>= 250000 ] whileFalse: [ > ord := OrderedCollection new: 100. > 1000 timesRepeat: [ > test add: ( ord add: Object new ) ]. > Transcript > show: test size asString; > tab. > Transcript show: > [ > 10 timesRepeat: [ > ord do: [ :each | test includes: each ] ] > ] timeToRun asString. > Transcript cr ] > > 3.9 can run this entire thing and be done with it in under one minute. > In trunk, all looks pretty fine until 136K elements, at which point > it completely seizes up; worse by a factor of> 120X. > > - Chris Simplistic fix: - remove 282311 from HashedCollection class>>goodPrimes. The table should probably be remade for squeak, keeping in mind the scaledIdentityHash implementation. Cheers, Henry

March 18, 2010

Re: [Pharo-project] A challenge for us

by Henrik Sperre Johansen

On 18.03.2010 01:09, GermÃ¡n Arduino wrote: > I would like to help also, even when I'm with very little free time. > > To start I would like to understand how is the Pharo development > process, being that (until now) I've mostly used RC2/3. > > The main doubts I've are: > > 1. The UNSTABLE version (the 1.1 right?) comes with no dev tools > installed (OB, Shout, etc). Exist some metacello configuration to > install all these tools? (I thinked that could be > ConfigurationOfPharo, but seems that fail to install). Not all dev tools can be expected to be updated and work on a work-in-progress core image, thus we (well, at least I) make due with the good ol' system browser. Important packages will be updated and configurations working in 1.1 made available after API changes have been prohibited. That said, the O2Browser was updated a short time ago to work in 1.1 IIRC, your best bet for a more advanced browser would probably be to try and load a configuration of that. > 2. On the gforge page (http://gforge.inria.fr/frs/?group_id=1299) > what is Pharo (pharo-dev) ? Is 1.0 RC2 with some tools? Pharo-dev is older versions of the core image, with tools equivalent to what is found in the RC-releases preloaded. (In fact, the latest release in that category is Pharo1.0-10508-rc2dev10.01.2.zip ) > 3. On the gforge page (http://gforge.inria.fr/frs/?group_id=1299) > what is Pharo1.1-64bit-Core? I mean, with which vm is supposed to be > used? It's an image that has been run through the SystemTracer which converts it to 64bit format. You will be able to run it on the 64-64 version of the 5.0 Mac OSX VM's, not sure about the other platforms. Please note many of the vm-plugins are not 64bit clean, thus are likely to fail or crash your VM if used. > 4. Some days ago I asked (with no response) about the Package Browser > on RC2. I've found several mails talking about some problems between > OB and O2, but I've not clear how to install it (I would like to have > on 1.1 also). AFAIK, Alexandre and David spent some time a while ago to completely separate the model of O2 from that used by OB, thus resolving clashes caused by O2 overrides, now both should be able to be loaded at the same time in 1.0. (load with ConfigurationOfO2 in MetacelloRepository) > Well, this is all for now, I will try also to read on the web page > about repos and other things related with the Pharo development > process. > > Thanks. > GermÃ¡n. There's only two repo's you really need: MetacelloRepository, for loading the tools you find useful (Really nice for checking issues with different tools in 1.1 as well) Inbox - Where you commit slices for inclusion in the next version. Cheers, Henry PS. The latest 1.0 release is PharoCore-1.0-10515rc3 (available from the gforge page), to get the equivalent of a Pharo (pharo-dev) rc image, load the ConfigurationOfPharo into that, and evaluate (ConfigurationOfPharo version: '1.0-rc.3-baseline') load. PPS. There will be an error when doing the load, since the AST-Tests package in squeaksource/rb has been renamed AST-Tests-Core, and the same for Refactoring-Tests, and the old packages removed... Lukas, would you mind uploading them again? For now, you can debug, and in the method that breaks, change the packageSpec's file to 'AST-Tests-Core-lr.8' and Refactoring-Tests-Core-lr.34 respectively. This will happen twice, since the spec first loads ConfigurationOfRefactoringBrowser once as part of the defined packages, then again as a prereq when loading ConfigurationOfOmniBrowser. <file:///C:/Pharo/Pharo1.0-10508-rc2dev10.01.2/Pharo1.0-10508-rc2dev10.01.2/Fonts/>

March 18, 2010

Re: [Pharo-project] Faster Sets and Pharo 1.1?

by Chris Muller

Thank you very much for the links. Ok, so if you take Lukas' test code from the first link, and try it in trunk. Here it is, but tweaked for an IdentitySet and increased to simulate a modestly-sized real-world use-case, 250K elements: | test ord | test := IdentitySet new. [ test size >= 250000 ] whileFalse: [ ord := OrderedCollection new: 100. 1000 timesRepeat: [ test add: ( ord add: Object new ) ]. Transcript show: test size asString; tab. Transcript show: [ 10 timesRepeat: [ ord do: [ :each | test includes: each ] ] ] timeToRun asString. Transcript cr ] 3.9 can run this entire thing and be done with it in under one minute. In trunk, all looks pretty fine until 136K elements, at which point it completely seizes up; worse by a factor of > 120X. - Chris On Wed, Mar 17, 2010 at 5:02 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2010/3/17 Chris Muller <asqueaker(a)gmail.com>: >> Wow, I'm really glad this topic has just come up right when I'm >> researching the list, trying to figure out why a large IdentitySet >> seems to have gotten incredibly slow in the trunk image, relative to >> 3.9. >> >> I haven't had a chance to do any measurements yet, but I have an >> IdentitySet with just a quarter-million objects, it *seems* to be much >> slower to add than in 3.9. >> > > Huh? That's interesting, it should be the opposite. > I presume you IdentitySet has enough room allocated (beware, some > basicSize can be slow, better be a prime). > Since there were 4096 different identityHash only and all contiguous, > adding time did turn in O(n) in 3.9, so O(n^2)/2 to addAll:. > Now, there are still 4096 different hash, but scaled to be non > contiguous. Your score should be around O((n/4096)^2). > Unless you messed with #identityHash or used basicNew: ? > > Nicolas > > http://bugs.squeak.org/view.php?id=1876 > http://code.google.com/p/pharo/issues/detail?id=213 > http://code.google.com/p/pharo/issues/detail?id=1868 > Browse pharo list in 2009. > Message from Andres Valloud and Martin McClure > Also search scaledIdentityHash identityHash IdentitySet in squeak-dev > in 2009 messages from Levente. > >> Did Faster Sets get integrated into the trunk image? Â I can't seem to >> find discussion or benchmark results on the list. Â Any info is greatly >> appreciated. >> >> Â - Chris >> >> On Wed, Mar 17, 2010 at 12:58 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> Thanks Ralph >>> >>> Levente, nicolas, henrik can you help us to take a good decision. >>> I'm not precise enough on that topic and its implications. >>> What I would love it to have Faster Set >>> Levente is it dependent on hash changes that martin is working on? >>> >>> Stef >>> >>> On Mar 17, 2010, at 6:39 PM, Ralph Boland wrote: >>> >>>> When I released my FasterSets package it was too late >>>> for consideration for Pharo 1.0 so it was stated that it would be reconsidered >>>> for Â Pharo Â 1.1. >>>> >>>> Of course, since my release, Levente has rewritten my version of FasterSets >>>> from scratch and also made many other changes to Sets. >>>> >>>> So I am wondering what the status of FasterSets is with respect to Pharo 1.1: >>>> >>>> Â a) FasterSets is not wanted in Pharo. >>>> Â b) Â You will use my version of FasterSets in Pharo 1.1. >>>> Â c) Â You will use Levente's version of FasterSets and perhaps his many other >>>> Â Â Â Â changes to Sets/Dictionaries in Pharo Â 1.1. >>>> >>>> Regards, >>>> >>>> Ralph Boland >>>> >>>> _______________________________________________ >>>> 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 >

March 18, 2010

Re: [Pharo-project] A challenge for us

by GermÃ¡n Arduino

I would like to help also, even when I'm with very little free time. To start I would like to understand how is the Pharo development process, being that (until now) I've mostly used RC2/3. The main doubts I've are: 1. The UNSTABLE version (the 1.1 right?) comes with no dev tools installed (OB, Shout, etc). Exist some metacello configuration to install all these tools? (I thinked that could be ConfigurationOfPharo, but seems that fail to install). 2. On the gforge page (http://gforge.inria.fr/frs/?group_id=1299) what is Pharo (pharo-dev) ? Is 1.0 RC2 with some tools? 3. On the gforge page (http://gforge.inria.fr/frs/?group_id=1299) what is Pharo1.1-64bit-Core? I mean, with which vm is supposed to be used? 4. Some days ago I asked (with no response) about the Package Browser on RC2. I've found several mails talking about some problems between OB and O2, but I've not clear how to install it (I would like to have on 1.1 also). Well, this is all for now, I will try also to read on the web page about repos and other things related with the Pharo development process. Thanks. GermÃ¡n. 2010/3/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > It would be good to start checking for example the date and time tests. > For example the readFrom: methods are ugly and it would be nice to access the tests and complement > it if necessary. Adding nice categories and not as yet unclassified or Testing would be good. > > Stef > > On Mar 17, 2010, at 2:23 AM, Carla F. Griggio wrote: > >> Same here. >> Sounds nice to start cooperating. How can I help? >> >> On Tue, Mar 16, 2010 at 10:28 PM, <csrabak(a)bol.com.br> wrote: >> If I understand correctly, i.e., committing to one task per month I'm more than willing to help. >> >> What would be the protocol to cooperate on this? >> >> -- >> Cesar Rabak >> >> >> Em 16/03/2010 04:21, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: >> Hi >> >> I would like to initiative a task (monthly) for us. I would like to get really good tests coverage >> for some of the core classes. For example Date, Time, Duration, DateAndTime. >> This is really important in the long term to get sure that we identify bugs as soon as they appear. >> >> It would be really good if we could get team up and fix that together. Does anybody want to help? >> >> I started to fix some bugs there and write more tests in the process of fixing tests. >> >> Stef >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 18, 2010

Re: [Pharo-project] Smalltalk isMacOS ifTrue: [ Smalltalk osVersion asNumber >= 1000

by David T. Lewis

On Wed, Mar 17, 2010 at 03:02:10PM -0700, John M McIntosh wrote: > Ah memories. > > That is "Oh is this running on a macintosh, if so then is it running on OSX versus OS 9?" In OSProcess, I'm using OSProcess class>>isUnixMac "True if the platform is Mac OS on OSX" | osVersion numericOsVersion | osVersion := self osVersion. ^ ('darwin*' match: osVersion "Ian's VM") or: [numericOsVersion := osVersion asInteger ifNil: [0]. (self platformName = 'Mac OS') and: [numericOsVersion >= 1000] "John's VM"] > but the > (SmalltalkImage current osVersion asNumber >= 1000 and: [SmalltalkImage current osVersion asNumber < 1030]) > still is valid. What is the significance of version 1030? Dave

March 18, 2010

Re: [Pharo-project] [ANN] Gofer Project Loader 1.0 (BETA)

by Alexandre Bergel

> load involves loading a project into an image in which the project > does not exist. > upgrade involves loading a project into an image in which the > project already is loaded. > > Loading is straightforward ... it is what we do all of the time. Add > a bunch of classes and methods, then run the #initialize methods for > the new classes. > > Upgrading is interesting because besides adding/removing classes and > methods, you have to worry about completely unloading packages that > are no longer part of the project. You also have to worry about the > fact that new classes will get there #initialize methods, but > preexisitng classes will not ... which can lead to interesting > results. This may lead to pre/post upgrade doits... I easily understand the difference. I was just wondering whether load: cannot do an update: if the package is present already. Maybe as I user I should not take care whether a package is already present before loading it. Just a thought. > Remove is interesting because you have to also consider removing any > projects that are dependent upon the project being removed. > > Once Metacello 1.0 is released I start working on adding upgrade > and remove to Metacello. Sounds like a good plan! Thanks for your explanation. Alexandre > Dale > ----- "Alexandre Bergel" <alexandre(a)bergel.eu> wrote: > > | Hi Esteban, > | > | It looks cool. I tried and I was seen apparent problems. > | I think it would be useful to add > | loadLastVersionOf: > | loadLastStableVersionOf: > | > | I am not aware of Metacello details, but where is there a > distinction > | > | between loading and upgrading? > | You do not have removeProject: or something? > | > | Cheers, > | Alexandre > | > | > | On 17 Mar 2010, at 09:23, Esteban Lorenzano wrote: > | > | > Hi, > | > I want to announce the immediate release of GoferProjectLoader, a > | > Gofer extension to manage Metacello configurations. > | > For all who want to know quickly what is this, here is a small > | > synopsis: > | > > | > GoferProjectLoader is a loader for Metacello configurations (A > | > metacello configuration is a full project load tool, including > | > package/project dependencies with it corresponding versions). > | > GoferProjectLoader automatically scan projects stored on > | > MetacelloRepository, but you can add your private repositories as > | > well. GoferProjectLoader responsibilities include: > | > > | > 1) Install project versions and keep track of them. > | > 2) Update configurations and upgrade projects (if desired). > | > > | > GoferProjectLoader relies on Metacello and Gofer to perform this > | > tasks (In fact, It can be thought as a Gofer extension to > understand > | > | > Metacello packages). > | > > | > To load GoferProjectLoader, you need to do: > | > > | > Gofer it > | > squeaksource: 'MetacelloRepository'; > | > package: 'ConfigurationOfGoferProjectLoader'; > | > load. > | > > | > ConfigurationOfGoferProjectLoader project lastVersion load. > | > > | > With this... you'll never need again to perform once and again > this > | > | > repetitive configuration... instead, you can do things like: > | > > | > Gofer project > | > load: 'Seaside30'; > | > load: 'Pier2'. > | > > | > You can see the full documentation here: > | > http://www.smallworks.com.ar/en/community/GoferProjectLoader > | > > | > Now I'm working on the promised page for configurations (Adrian: I > | > | > really sorry for the delay... I know I promised this a lot of time > | > | > ago... but time is the tyrant :( ) > | > > | > Cheers, > | > Esteban > | > > | > > | > > | > _______________________________________________ > | > Pharo-project mailing list > | > Pharo-project(a)lists.gforge.inria.fr > | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- > project > | > | -- > | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > | Alexandre Bergel http://www.bergel.eu > | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > | > | > | > | > | > | > | _______________________________________________ > | 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 17, 2010

Re: [Pharo-project] Removal of requires calculation code

by Lukas Renggli

It's always great to hear when code is made optionally loadable. Lukas On Wednesday, March 17, 2010, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > EXCELLENT! > I will integrate that soon. > >> I finally managed to finish this task, which I started at last week's sprint. >> >> This change removes the required/provided selectors computation code that was in the Traits package for historical reasons. This removes 17 classes with about 240 methods from PharoCore. I re-packaged the removed code and put it on SqueakSource: >> >> http://www.squeaksource.com/Requires.html >> >> >> Info for integrators: >> >> Preamble: >> ------------ >> SystemChangeNotifier uniqueInstance noMoreNotificationsFor: RequiredSelectors current. >> SystemChangeNotifier uniqueInstance noMoreNotificationsFor: ProvidedSelectors current >> SystemChangeNotifier uniqueInstance noMoreNotificationsFor: LocalSends current. >> >> >> Changes (in inbox): >> ------------ >> Name: Kernel-AdrianLienhard.622 >> Author: AdrianLienhard >> Time: 17 March 2010, 8:57:59 pm >> UUID: b3776db1-b0c0-4e01-808b-0090fc7a42dc >> Ancestors: Kernel-StephaneDucasse.621, Kernel-AdrianLienhard.615 >> >> Name: Traits-AdrianLienhard.363 >> Author: AdrianLienhard >> Time: 17 March 2010, 9:06:32 pm >> UUID: 6d4af177-0e6f-4db1-bf30-1fd62c10c298 >> Ancestors: Traits-StephaneDucasse.362, Traits-AdrianLienhard.359 >> >> Name: ScriptLoader11-AdrianLienhard.305 >> Author: AdrianLienhard >> Time: 17 March 2010, 9:00:43 pm >> UUID: 0eae5794-e74e-4d4d-a6e0-8e3a8b641af0 >> Ancestors: ScriptLoader11-StephaneDucasse.304, ScriptLoader11-AdrianLienhard.290 >> >> Name: Tests-AdrianLienhard.136 >> Author: AdrianLienhard >> Time: 17 March 2010, 9:05:49 pm >> UUID: 7dd01882-2b6e-4dce-8139-caf9cc96caf4 >> Ancestors: Tests-StephaneDucasse.135, Tests-AdrianLienhard.125 >> >> >> To track this change: http://code.google.com/p/pharo/issues/detail?id=2160 >> >> Cheers, >> Adrian >> >> ___________________ >> http://www.adrian-lienhard.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 > -- Lukas Renggli http://www.lukas-renggli.ch

March 17, 2010

Re: [Pharo-project] [ANN] Gofer Project Loader 1.0 (BETA)

by Miguel Enrique CobÃ¡ Martinez

El miÃ©, 17-03-2010 a las 15:20 -0700, Dale Henrichs escribiÃ³: > ----- "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: > > | > - any idea about how we go to differentiate "stable" and "unstable" > | > | > universes for each Pharo version? How does the user know which version > | > is the one he needs for his version of Pharo? Sorry, this is not > | > directly related to the Gofer Project Loader but I think it is the next > | > important step towards a working package management system! > | > | No clue... maybe we need to add to Metacello a new "dependence > | dimension", like "minimum version of distribution"... but Dale can be > | much more helpful than me in this area. > > I imagine that code targetted for specific Pharo versions will be treated like we treat code targeted for different Smalltalk dialects. So you would write specs like the following: > > spec for: #common do: [...]. > spec for: #squeakCommon do: [...]. > spec for: #pharo do: [...]. > spec for: #'pharo1.0' do: [...]. > spec for: #'pharo1.1' do: [...]. > > or possibly like the following, if a finer version granularity is needed: > > spec for: #common do: [...]. > spec for: #squeakCommon do: [...]. > spec for: #pharo do: [...]. > spec for: #'pharo1.0' do: [...]. > spec for: #'pharo1.0-10508' do: [...]. > spec for: #'pharo1.0-10515' do: [...]. > spec for: #'pharo1.1' do: [...]. > spec for: #'pharo1.1-11508' do: [...]. > spec for: #'pharo1.1-11515' do: [...]. > > Dale > umm, no please! There would be a lot of combinations after a while. Why about having a new spec universes message that accept a list of symbols, each symbol representing a given "universe" of tested packages. This list will be the only thing to modify when grouping different versions of the same package in different repositories. For example, I start with ConfigurationOfMagma version 1.0r43. Two weeks later I release ConfigurationOfMagma with support for loading 1.0r44. Both this versions have been tested on Pharo 1.0. So the both are marked spec universes: #(#pharo10). A week later Pharo 1.1 is released, and I test the configuration on this new version of pharo. Both work ok. So I modify the line to: spec universes: #(#pharo10 #pharo11) and commit. The tools (GoferProjectLoader) then add functionality to scan this list and presents the users only the appropriated ones based on the image the users is querying the repository. Of course this is very simplistic because as the debian model shows, requires a maintainer of each configuration and the user to report if a given #pharo11 marked version actually doesn't work. If something don't work, or a new version is given that works, or the tag #pharo11 is removed from that version effectively removing it from that given universe until bugs are fixed or worked around. What do you think? Cheers > _______________________________________________ > 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

March 17, 2010

Re: [Pharo-project] [ANN] Gofer Project Loader 1.0 (BETA)

by Dale Henrichs

----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: | esteban | | excellent!!! | Now how can we load code for Pharo1.0 which is different for Pharo1.1 | and soon Pharo1.2.... | you see what I mean. | | Ideally I would like to have the MetacelloRepository structured in a | tree with versions | 1.0/1.2.... so that in three years from now I can still load a version | of something. | The idea that we discuss with Dale is to be able to to a freeze of a | configuration so that it copies | all the dependent packages in a metacelloRepository. Metacello 1.0-beta.25 will have a couple of new features that support the creation and use of historical/secondary repositories. I have added #fetch/#fetch: that downloads all of the packages/configurations into a target repository ... the using #repositoryOverrides: you can arrange that all of the package loads will done from the target repository (regardless of what the config specifies)... Dale

March 17, 2010