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

Re: [Pharo-project] recategorizing all the categories...

by Lukas Renggli

There are lint rules that detect - uncategorized methods - methods that are in a different protocol in their superclass We also have some scripts in Seaside that fix common problems, e.g. make them all lowercase and use #initialize instead of #'class initialize' or #'initialize-release'. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 18, 2010

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

by StÃ©phane Ducasse

On Mar 18, 2010, at 8:30 AM, Adrian Lienhard wrote: > Here is yet another way how we could model universes. We just have multiple Metacello repositories: > > - MetacelloRepository is the one that everybody can commit to (testing universe) > - MetacelloRepositoryPharo1.0 is the stable universe for Pharo 1.0 > - MetacelloRepositoryPharo1.1 is the stable universe for Pharo 1.1 > - etc. Yes this is what I was thinking. In general the policy for a metacello config is to be in the project where it belongsto and **copied** to the MetacelloRepository. > A package always first gets into the testing universe and when it is known to work in a particular version it is copied into the appropriate repository. The Gofer Project Loader would just need to know the repository for the current Pharo version. Like in Debian, one can add the testing universe to get unstable versions if needed. > > This setup would not need any code changes in Metacello and it allows us to use access rights to assign people to manage the process and assert a certain level of quality. Yes! > > Cheers, > Adrian > > > On Mar 17, 2010, at 23:41 , Miguel Enrique CobÃ¡ Martinez wrote: > >> 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 >> >> >> _______________________________________________ >> 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] recategorizing all the categories...

by StÃ©phane Ducasse

because there is a difference between my desk and the desk of marcus. My desk is full of paper and I'm the only one that can find sometimes on it (which is ok this is my desk) but now if marcus needs to use my desk it will take him more time to find something. While with a nicely labelled desk then this is easier to find something. Stef On Mar 18, 2010, at 5:22 AM, HernÃ¡n Morales Durand wrote: > Hi Stef, > I don't see why unclassified should correlate to dirt. > Cheers, > > HernÃ¡n > > 2010/3/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > hi guys > > I wanted to know if one you try tried to automatically recategorized all the methods of the system. > Because I'm tired to get this as yet unclassified in my face. I looks to my like dirt in the street. > Wanna get clean... > > 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

March 18, 2010

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

by StÃ©phane Ducasse

Thanks. I will publish what I did and we can iterate from here. I have isUnix isRiscOS isMacOS isWin32 isWin32CE And I imagine that I will need isMacOS9 isMacOSX On Mar 18, 2010, at 1:03 AM, David T. Lewis wrote: > 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? Yes this was my question? > > Dave > > > _______________________________________________ > 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] [ANN] Gofer Project Loader 1.0 (BETA)

by StÃ©phane Ducasse

Dale I was thinking to something more orthogonal. Because at the time I publish something for pharo1.0 I do not know that it will not work in pharo1.1. So I was thinking that the repository could be the same to differentiate. If I publish in repository1.0 then it is for 1.0 same for 1.1. Like we can also build distributions. We could ship Pharo1.1 with the publicly available 1.1 complaint project. Then we do not have to change the tags for 1.2 at the configuration level. Now people may also want to have one for multiple pharo versions and in that case use 'pharo1.0' and so on. Stef On Mar 17, 2010, at 11:20 PM, Dale Henrichs wrote: > > ----- "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 > > _______________________________________________ > 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] [ANN] Gofer Project Loader 1.0 (BETA)

by Adrian Lienhard

Here is yet another way how we could model universes. We just have multiple Metacello repositories: - MetacelloRepository is the one that everybody can commit to (testing universe) - MetacelloRepositoryPharo1.0 is the stable universe for Pharo 1.0 - MetacelloRepositoryPharo1.1 is the stable universe for Pharo 1.1 - etc. A package always first gets into the testing universe and when it is known to work in a particular version it is copied into the appropriate repository. The Gofer Project Loader would just need to know the repository for the current Pharo version. Like in Debian, one can add the testing universe to get unstable versions if needed. This setup would not need any code changes in Metacello and it allows us to use access rights to assign people to manage the process and assert a certain level of quality. Cheers, Adrian On Mar 17, 2010, at 23:41 , Miguel Enrique CobÃ¡ Martinez wrote: > 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 > > > _______________________________________________ > 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 Levente Uzonyi

On Wed, 17 Mar 2010, Chris Muller wrote: > 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... Since there are only 4096 different keys, you're practically growing 4096 lists in an array. The cause of the problem is that the gap between the slots which are the head of the lists are less than the length of the list, so clustering will occur. Most primes above 100000 are affected by this issue in the #goodPrimes array. We can solve this issue by using: (1) different primes in general (2) different primes for identity hash based collections (3) a different method for #scaledIdentityHash calculation (4) a combination of the above I found 5918 primes between 5 and 1000000 which are expected to behave optimally (and 59115 which are close to optimal) with #scaledIdentityHash, so probably (1) or (2) is the ideal solution. Levente 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 > _______________________________________________ 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 HernÃ¡n Morales Durand

2010/3/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > 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. > Is there a consensus about what are called the "core" classes of Pharo? In the "Advanced Smalltalk" book, page 22, there is a useful distinction between "System classes" and "Base classes". Pletzke says basically: -System classes are those necessary to run the system -Base classes form the basis for an application but may not be required to run the system unless they are also System classes Could anybody identify both sets? They are the same in Squeak? It would be cool to discuss this with people in Squeak lists, maybe a good point to start avoiding duplication of efforts. Cheers, HernÃ¡n

March 18, 2010

Re: [Pharo-project] recategorizing all the categories...

by HernÃ¡n Morales Durand

Hi Stef, I don't see why unclassified should correlate to dirt. Cheers, HernÃ¡n 2010/3/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > hi guys > > I wanted to know if one you try tried to automatically recategorized all > the methods of the system. > Because I'm tired to get this as yet unclassified in my face. I looks to my > like dirt in the street. > Wanna get clean... > > Stef > _______________________________________________ > 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] recategorizing all the categories...

by Igor Stasenko

On 17 March 2010 21:59, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > hi guys > > I wanted to know if one you try tried to automatically recategorized all the methods of the system. > Because I'm tired to get this as yet unclassified in my face. I looks to my like dirt in the street. > Wanna get clean... > But not all methods can be categorized automatically. I think tools can easily detect a category only for accessors and overrides, when you overriding a method which assigned to some category in superclass. How you suppose to auto-cat rest? > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

March 18, 2010