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

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

by Dale Henrichs

----- "Alexandre Bergel" <alexandre(a)bergel.eu> wrote: | > 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. That is probably a good idea ... the less someone has to think before running a script the better, as long as the 'right thing is done'.

March 17, 2010

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

by Dale Henrichs

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

March 17, 2010

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

by Nicolas Cellier

http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg15177.ht… http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-November/141493… etc... 2010/3/17 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 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 >

March 17, 2010

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

by Dale Henrichs

Alexandre, 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... 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. 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

March 17, 2010

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

by Nicolas Cellier

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

March 17, 2010

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

by John M McIntosh

Ah memories. That is "Oh is this running on a macintosh, if so then is it running on OSX versus OS 9?" However I will point out that there is no way to run a pharo image on OS 9 because I've never built a Closure VM for that version of the operating system. So looking at FreeTypeFontProvider>>platformAbsoluteDirectories you can dispose of the check for os-x since it will always be os-x if the platform is macintosh HostSystemMenuMacOSX>>isActiveHostMenuProxyClass is still required since it's a subclass of the OS-9 behaviour. HostSystemMenusTest I note it won't trigger the OS-9 code, so you *could* remove those like in testCommandIDMacOnly " (SmalltalkImage current osVersion asNumber < 1000) ifTrue: [^self]. " but the (SmalltalkImage current osVersion asNumber >= 1000 and: [SmalltalkImage current osVersion asNumber < 1030]) still is valid. testCountsMacOnly has (SmalltalkImage current osVersion asNumber >= 1000) The JapaneseEnvironment & KoreanEnvironment seem to be deciding if os-x thenUTF8 fonts Ffenestri of course was written for os-9 and os-x, so there is os-9 and os-x flavors/subclasses to decide on. MacOSXPlatform>>isActivePlatform confirms that it's osx, mind there is no os-9 flavour, so checking for os-x is kinda pointless. On 2010-03-17, at 1:43 PM, StÃ©phane Ducasse wrote: > John > > Do you know the meaning of that > Smalltalk isMacOS ifTrue: [ Smalltalk osVersion asNumber >= 1000] > that I turn it into a nice message? > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

March 17, 2010

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

by Dale Henrichs

Excellent work ... very good idea to hook it into Gofer! Dale ----- "Esteban Lorenzano" <estebanlm(a)gmail.com> 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

March 17, 2010

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

by Chris Muller

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

March 17, 2010

Re: [Pharo-project] May be there is a problem with ChangeSet

by StÃ©phane Ducasse

It seems that my changes are superimposed with partial changes of font rendering made by nicolas. Some of the methods are part of others... Strange. Stef On Mar 17, 2010, at 10:11 PM, StÃ©phane Ducasse wrote: > Apparently I have methods that are cut.... > and I cannot load the file back.... > > I cannot save with MC either. :( > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 17, 2010

[Pharo-project] May be there is a problem with ChangeSet

by StÃ©phane Ducasse

Apparently I have methods that are cut.... and I cannot load the file back.... I cannot save with MC either. :( Stef

March 17, 2010