July 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN][Dev-Images] July 2009 versions

by StÃ©phane Ducasse

probably now I was talking about pharo. what do we want in pharo (old pharo-dev) Stef On Jul 6, 2009, at 7:49 PM, Adrian Lienhard wrote: > just a thought: instead of a Pharo-full image, wouldn't it be more > useful if we had a package manager (Metacello?) that lets the user > install what he likes (and not more)? > > Cheers, > Adrian > > On Jul 6, 2009, at 18:27 , StÃ©phane Ducasse wrote: > >> Damien >> >> may be we will have to think about what should be available in pharo >> (old pharo-dev) >> vs pharo-full >> >> >> my first cut at pharo is >> >>> eCompletion version 0.102 >>> eCompletion-Traits version 0.1 >>> eCompletionOmniBrowser version 0.5 >> >>> OB-Enhancements version 0.328 >>> OmniBrowser version 0.447 >>> OmniBrowser-Algernon version 0.5 >>> OmniBrowser-Full version 0.27 >>> OmniBrowser-Morphic version 0.88 >>> OmniBrowser-Refactory version 145 >>> OmniBrowser-Regex version 0.18 >>> OmniBrowser-Standard version 0.406 >> >>> Polymorph EventEnhancements version 1.1 >>> Polymorph Geometry version 1.1 >>> Polymorph TaskbarIcons version 1.0 >>> Polymorph ToolBuilder version 1.3 >>> Polymorph Tools Diff version 1.3 >>> Polymorph Widgets version 1.4 >>> Refactoring Core version 48 >>> Refactoring Spelling version 5 >>> RoelTyper version 0.60 >> >>> Universes version 52 >>> Universes OmniBrowser version 0.38 >>> YAXO version 14 >>> Shout version 3.15-tween.72 >>> ShoutWorkspace version 1-tween.4 >> >> >> >> >>> VBRegex version 1.9 >> is already in Pharo >> >> >> all the rest may go in pharo -full >> >>> Aida version 5.6 >>> Algernon version 1.2 >>> AST version 164 >>> AutomaticMethodCategorizer version 0.25 >>> AutomaticMethodCategorizerOB version 0.2 >>> DynamicBindings version 2.7 >>> Installer version 4.3 >>> Installer-Core version 4.3.313 >>> Installer-Formats version 4.3.3 >>> Installer-Scripts version 4.3.8 >>> KomHttpServer version 7.0.45 >>> KomServices version 1.19 >>> Magritte-Model version 1.1.1.349 >>> Magritte-Seaside version 1.1.1.302 >>> Magritte-Tests version 1.1.1.153 >>> >>> Pier version current >>> Pier-Blog version 1.1.1.117 >>> Pier-Documents version 1.1.1.15 >>> Pier-EditorEnh version 1.1.1.48 >>> Pier-Model version 1.1.1.328 >>> Pier-Seaside version 1.1.1.419 >>> Pier-Security version 1.1.1.141 >>> Pier-Tests version 1.1.1.137 >>> >>> RSRSS2 version 2.8.4.12 >>> Scriptaculous version 2.8.4.250 >>> ScriptManager version 0.6 >>> Seaside version 2.8.4.591 >>> Seaside-Adapters-Core version pmm.2.mcz >>> Seaside-Adapters-Swazoo version 9 >>> Seaside-Squeak-Adapters version pmm.3.mcz >>> SeasideAdaptersCompatibility version pmm.1.mcz >>> >>> SmaCC runtime version 13 >>> Sport version 2.31 >>> Squeak dev packages version 0.28 >>> Squeak web packages version 0.2 >> >> >>> SUnit-improved version 4.0.118 >>> SUnitGUI-improved version 4.0.50 >> what is this? >> >> >> >>> Swazoo version 2.1 >>> >>> >>> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> "Lambdas are relegated to relative obscurity until Java makes them >>> popular by not having them." James Iry >>> >>> _______________________________________________ >>> 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

July 6, 2009

Re: [Pharo-project] Tests

by StÃ©phane Ducasse

Yes mike so if you can check that it would just great. On Jul 6, 2009, at 7:44 PM, Michael Roberts wrote: > Sure it's a good thing. We should make sure our test output is telling > the truth.,... > Mike > On Monday, July 6, 2009, Damien Cassou <damien.cassou(a)gmail.com> > wrote: >> On Sun, Jul 5, 2009 at 12:36 PM, Adrian Lienhard<adi(a)netstyle.ch> >> wrote: >>> Running the tests in the latest core (10371), I get the following >>> results: >>> 5154 run, 5133 passes, 2 expected failures, 17 failures, 2 errors >>> >>> Comparing to the last result in 10292cl [1]: >>> 3029 run, 2956 passes, 2 expected failures, 24 failures, 47 errors >>> >>> >>> I wonder how it is possible to get from 3029 to 5154 tests? >> >> More tests, less problems, why do you care? :-)

July 6, 2009

Re: [Pharo-project] Squeak Forks Popularity & Trends Estimate

by Hernan Wilkinson

Hi Stef, have you thought about have not only first class instance variables but first class variables? (no matter the scope). I think that would be interesting... observers on variables would be pretty easy to implement, type inference (or type recollection)... not sure about the trade-off cost/convenience, but looks interesting... accessing local variables could be made sending messages to thisContext... anyway, just an idea. On Mon, Jul 6, 2009 at 6:31 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Hi nevin > > our goal is not predominancy :) It was never. I would be happy that > squeak offers a really good multimedia > platform. Our goal is to deliver good open source smalltalk. > Our goal is to get agile, rethink the system, use good software > engineering practices (systematic smallLnt rules), > tests.... > We want to propose/accept/evaluate new solutions: > first class package, > first class instance variables, better refactoring support, > may be modules, security, new compiler.... > > Smalltalk deserves a clean and powerful implementation and > we will work on that hard. > > Stef > > PS: you can forward this answer to squeak-dev if you feel the need. > > On Jul 6, 2009, at 3:17 AM, Nevin Pratt wrote: > > > There's no right or wrong answer to the following three questions. > > And, > > every response is meaningful, because it helps reveal the general > > sense > > of direction that the community is feeling. > > > > *********************** > > Question #1: Of the various Squeak forks (such as Croquet, Pharo, > > etc.), > > what is your feeling of their relative popularities at this point in > > time, and how does that compare with the current popularity of the > > base > > Squeak distribution? > > > > Question #2: This is related to the above-- what is your feeling of > > the > > relative popularity *trend* of each of the forks, and how does that > > compare with your feeling of the *trend* of the future popularity of > > the > > base Squeak distribution? > > > > Question #3: What is your justification for your answers to the above > > two questions? > > ************************ > > > > I'll begin with my own answers... > > > > ...I'm beginning to feel like the Pharo fork currently now has maybe > > 50% > > or more of the popularity of the base Squeak distro, and I'm beginning > > to feel like Pharo is headed to become the dominant distribution in > > the > > future, surpassing the original Squeak distro. And I base that > > feeling > > on several observations: > > > > 1. The email traffic comparison on the "Pharo-project" email list > > compared to the email traffic on "The general-purpose Squeak > > developers > > list", and the observed trend in such traffic. > > > > 2. The number of developers posting on the Pharo-project email list. > > > > 3. The specific developers posting on the Pharo-project email list > > (known Squeakers who have contributed heavily to Squeak in the past). > > > > 4. The fact that Seaside development has moved to Pharo. > > > > At one time I wondered if Croquet would become the dominant Squeak > > fork, > > for the simple reason that it had a business organization "officially" > > supporting it, similar to what Squeak had in the Disney days. But > > now I > > think I would bet my money on Pharo. > > > > What do you think? And why? > > > > Also, remember, there's certainly nothing wrong with several > > "dominant" > > forks existing. But of those, one of them will still be the most > > popular overall. And I'm curious about thoughts of which one that is, > > and which one that will become, and why you think so. > > > > Nevin > > > > > > > > > > > > > > _______________________________________________ > > 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 >

July 6, 2009

Re: [Pharo-project] Squeak Forks Popularity & Trends Estimate

by Schwab,Wilhelm K

Nevin, If one wants to dominate the Smalltalk market, then write a Smalltalk, and a good one. Croquet, IMHO, is missing the mark by being a 3D system first, second, and maybe third, and further into MHO, missing the opportunity to provide a retained mode 3D graphic engine. Note that I am not saying there is anything wrong with the product as delivered, but it could be a great deal more useful to a wide range of users if a few layers were identified and exposed/marketed as useful systems. I also think Tweak is a bad design idea; never do to the language what you can do with/in the language. I see it as a logical extension of inheritance vs. composition; the former is easily over-used when the latter applies, and I see Tweak as a similar trap. To date, I think Pharo is the most likely Squeak fork to result in a good Smalltalk. That is because the process is open, includes just enough iron fist control to make decisions as needed, and because making a good Smalltalk _that people can use as they see fit_ is the stated objective. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Monday, July 06, 2009 4:32 AM To: nevin(a)smalltalkpro.com Cc: Pharo Development Subject: Re: [Pharo-project] Squeak Forks Popularity & Trends Estimate Hi nevin our goal is not predominancy :) It was never. I would be happy that squeak offers a really good multimedia platform. Our goal is to deliver good open source smalltalk. Our goal is to get agile, rethink the system, use good software engineering practices (systematic smallLnt rules), tests.... We want to propose/accept/evaluate new solutions: first class package, first class instance variables, better refactoring support, may be modules, security, new compiler.... Smalltalk deserves a clean and powerful implementation and we will work on that hard. Stef PS: you can forward this answer to squeak-dev if you feel the need. On Jul 6, 2009, at 3:17 AM, Nevin Pratt wrote: > There's no right or wrong answer to the following three questions. > And, > every response is meaningful, because it helps reveal the general > sense of direction that the community is feeling. > > *********************** > Question #1: Of the various Squeak forks (such as Croquet, Pharo, > etc.), what is your feeling of their relative popularities at this > point in time, and how does that compare with the current popularity > of the base Squeak distribution? > > Question #2: This is related to the above-- what is your feeling of > the relative popularity *trend* of each of the forks, and how does > that compare with your feeling of the *trend* of the future popularity > of the base Squeak distribution? > > Question #3: What is your justification for your answers to the above > two questions? > ************************ > > I'll begin with my own answers... > > ...I'm beginning to feel like the Pharo fork currently now has maybe > 50% or more of the popularity of the base Squeak distro, and I'm > beginning to feel like Pharo is headed to become the dominant > distribution in the future, surpassing the original Squeak distro. > And I base that feeling on several observations: > > 1. The email traffic comparison on the "Pharo-project" email list > compared to the email traffic on "The general-purpose Squeak > developers list", and the observed trend in such traffic. > > 2. The number of developers posting on the Pharo-project email list. > > 3. The specific developers posting on the Pharo-project email list > (known Squeakers who have contributed heavily to Squeak in the past). > > 4. The fact that Seaside development has moved to Pharo. > > At one time I wondered if Croquet would become the dominant Squeak > fork, for the simple reason that it had a business organization > "officially" > supporting it, similar to what Squeak had in the Disney days. But now > I think I would bet my money on Pharo. > > What do you think? And why? > > Also, remember, there's certainly nothing wrong with several > "dominant" > forks existing. But of those, one of them will still be the most > popular overall. And I'm curious about thoughts of which one that is, > and which one that will become, and why you think so. > > Nevin > > > > > > > _______________________________________________ > 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

July 6, 2009

Re: [Pharo-project] [ANN][Dev-Images] July 2009 versions

by Mariano Martinez Peck

On Mon, Jul 6, 2009 at 4:49 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > just a thought: instead of a Pharo-full image, wouldn't it be more > useful if we had a package manager (Metacello?) that lets the user > install what he likes (and not more)? > Yes! something like Seaside builder? > > Cheers, > Adrian > > On Jul 6, 2009, at 18:27 , StÃ©phane Ducasse wrote: > > > Damien > > > > may be we will have to think about what should be available in pharo > > (old pharo-dev) > > vs pharo-full > > > > > > my first cut at pharo is > > > >> eCompletion version 0.102 > >> eCompletion-Traits version 0.1 > >> eCompletionOmniBrowser version 0.5 > > > >> OB-Enhancements version 0.328 > >> OmniBrowser version 0.447 > >> OmniBrowser-Algernon version 0.5 > >> OmniBrowser-Full version 0.27 > >> OmniBrowser-Morphic version 0.88 > >> OmniBrowser-Refactory version 145 > >> OmniBrowser-Regex version 0.18 > >> OmniBrowser-Standard version 0.406 > > > >> Polymorph EventEnhancements version 1.1 > >> Polymorph Geometry version 1.1 > >> Polymorph TaskbarIcons version 1.0 > >> Polymorph ToolBuilder version 1.3 > >> Polymorph Tools Diff version 1.3 > >> Polymorph Widgets version 1.4 > >> Refactoring Core version 48 > >> Refactoring Spelling version 5 > >> RoelTyper version 0.60 > > > >> Universes version 52 > >> Universes OmniBrowser version 0.38 > >> YAXO version 14 > >> Shout version 3.15-tween.72 > >> ShoutWorkspace version 1-tween.4 > > > > > > > > > >> VBRegex version 1.9 > > is already in Pharo > > > > > > all the rest may go in pharo -full > > > >> Aida version 5.6 > >> Algernon version 1.2 > >> AST version 164 > >> AutomaticMethodCategorizer version 0.25 > >> AutomaticMethodCategorizerOB version 0.2 > >> DynamicBindings version 2.7 > >> Installer version 4.3 > >> Installer-Core version 4.3.313 > >> Installer-Formats version 4.3.3 > >> Installer-Scripts version 4.3.8 > >> KomHttpServer version 7.0.45 > >> KomServices version 1.19 > >> Magritte-Model version 1.1.1.349 > >> Magritte-Seaside version 1.1.1.302 > >> Magritte-Tests version 1.1.1.153 > >> > >> Pier version current > >> Pier-Blog version 1.1.1.117 > >> Pier-Documents version 1.1.1.15 > >> Pier-EditorEnh version 1.1.1.48 > >> Pier-Model version 1.1.1.328 > >> Pier-Seaside version 1.1.1.419 > >> Pier-Security version 1.1.1.141 > >> Pier-Tests version 1.1.1.137 > >> > >> RSRSS2 version 2.8.4.12 > >> Scriptaculous version 2.8.4.250 > >> ScriptManager version 0.6 > >> Seaside version 2.8.4.591 > >> Seaside-Adapters-Core version pmm.2.mcz > >> Seaside-Adapters-Swazoo version 9 > >> Seaside-Squeak-Adapters version pmm.3.mcz > >> SeasideAdaptersCompatibility version pmm.1.mcz > >> > >> SmaCC runtime version 13 > >> Sport version 2.31 > >> Squeak dev packages version 0.28 > >> Squeak web packages version 0.2 > > > > > >> SUnit-improved version 4.0.118 > >> SUnitGUI-improved version 4.0.50 > > what is this? > > > > > > > >> Swazoo version 2.1 > >> > >> > >> > >> -- > >> Damien Cassou > >> http://damiencassou.seasidehosting.st > >> > >> "Lambdas are relegated to relative obscurity until Java makes them > >> popular by not having them." James Iry > >> > >> _______________________________________________ > >> 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 >

July 6, 2009

Re: [Pharo-project] [ANN][Dev-Images] July 2009 versions

by Adrian Lienhard

just a thought: instead of a Pharo-full image, wouldn't it be more useful if we had a package manager (Metacello?) that lets the user install what he likes (and not more)? Cheers, Adrian On Jul 6, 2009, at 18:27 , StÃ©phane Ducasse wrote: > Damien > > may be we will have to think about what should be available in pharo > (old pharo-dev) > vs pharo-full > > > my first cut at pharo is > >> eCompletion version 0.102 >> eCompletion-Traits version 0.1 >> eCompletionOmniBrowser version 0.5 > >> OB-Enhancements version 0.328 >> OmniBrowser version 0.447 >> OmniBrowser-Algernon version 0.5 >> OmniBrowser-Full version 0.27 >> OmniBrowser-Morphic version 0.88 >> OmniBrowser-Refactory version 145 >> OmniBrowser-Regex version 0.18 >> OmniBrowser-Standard version 0.406 > >> Polymorph EventEnhancements version 1.1 >> Polymorph Geometry version 1.1 >> Polymorph TaskbarIcons version 1.0 >> Polymorph ToolBuilder version 1.3 >> Polymorph Tools Diff version 1.3 >> Polymorph Widgets version 1.4 >> Refactoring Core version 48 >> Refactoring Spelling version 5 >> RoelTyper version 0.60 > >> Universes version 52 >> Universes OmniBrowser version 0.38 >> YAXO version 14 >> Shout version 3.15-tween.72 >> ShoutWorkspace version 1-tween.4 > > > > >> VBRegex version 1.9 > is already in Pharo > > > all the rest may go in pharo -full > >> Aida version 5.6 >> Algernon version 1.2 >> AST version 164 >> AutomaticMethodCategorizer version 0.25 >> AutomaticMethodCategorizerOB version 0.2 >> DynamicBindings version 2.7 >> Installer version 4.3 >> Installer-Core version 4.3.313 >> Installer-Formats version 4.3.3 >> Installer-Scripts version 4.3.8 >> KomHttpServer version 7.0.45 >> KomServices version 1.19 >> Magritte-Model version 1.1.1.349 >> Magritte-Seaside version 1.1.1.302 >> Magritte-Tests version 1.1.1.153 >> >> Pier version current >> Pier-Blog version 1.1.1.117 >> Pier-Documents version 1.1.1.15 >> Pier-EditorEnh version 1.1.1.48 >> Pier-Model version 1.1.1.328 >> Pier-Seaside version 1.1.1.419 >> Pier-Security version 1.1.1.141 >> Pier-Tests version 1.1.1.137 >> >> RSRSS2 version 2.8.4.12 >> Scriptaculous version 2.8.4.250 >> ScriptManager version 0.6 >> Seaside version 2.8.4.591 >> Seaside-Adapters-Core version pmm.2.mcz >> Seaside-Adapters-Swazoo version 9 >> Seaside-Squeak-Adapters version pmm.3.mcz >> SeasideAdaptersCompatibility version pmm.1.mcz >> >> SmaCC runtime version 13 >> Sport version 2.31 >> Squeak dev packages version 0.28 >> Squeak web packages version 0.2 > > >> SUnit-improved version 4.0.118 >> SUnitGUI-improved version 4.0.50 > what is this? > > > >> Swazoo version 2.1 >> >> >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Lambdas are relegated to relative obscurity until Java makes them >> popular by not having them." James Iry >> >> _______________________________________________ >> 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

July 6, 2009

Re: [Pharo-project] Tests

by Michael Roberts

Sure it's a good thing. We should make sure our test output is telling the truth.,... Mike On Monday, July 6, 2009, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Sun, Jul 5, 2009 at 12:36 PM, Adrian Lienhard<adi(a)netstyle.ch> wrote: >> Running the tests in the latest core (10371), I get the following >> results: >> 5154 run, 5133 passes, 2 expected failures, 17 failures, 2 errors >> >> Comparing to the last result in 10292cl [1]: >> 3029 run, 2956 passes, 2 expected failures, 24 failures, 47 errors >> >> >> I wonder how it is possible to get from 3029 to 5154 tests? > > More tests, less problems, why do you care? :-) > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 6, 2009

Re: [Pharo-project] Download URL changed??

by Adrian Lienhard

I changed that because the path /download conflicted with the standard download path of files in the CMS. I checked who is pointing to that URL and found only two rather old pages in the Google index. Since the sitemap opens if you access the old path, you will easily find the download site in there. Hence I think its not a big issue. Adrian On Jul 6, 2009, at 17:20 , Damien Cassou wrote: > Hi, > > I've just noticed that > > http://pharo-project.org/download > > has been changed to: > > http://pharo-project.org/pharo-download > > Is there a good reason? I used the first url in many emails and > announcements. I think this will confuse people. Moreover, Google > search also provides a link to the first url. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 6, 2009

Re: [Pharo-project] Problem with fork

by Mariano Martinez Peck

Reinout: I forgot to thank you for the explanation and the time to do it :) I was very useful for me. I even change my code to your proposal. Thanks!!! Mariano On Fri, Jul 3, 2009 at 10:35 AM, Reinout Heeck <reinz(a)desk.org> wrote: > Hi all, > this is my first post here, just joined this group so let me do a > quick introduction. > I have 10+ years of experience doing full-time development with > VisualWorks (creating trading platforms for the European energy > exchanges). > Also I have near-zero experience with using Squeak or how its > development process works. I'll slowly cut my teeth, starting by > interacting on this mailing list. > > > Multi threading is something I have spent a lot of quality time with, > so I want to share some thoughts on the following: > > |semaphores tr| > semaphores := Array new: 10. > tr := ThreadSafeTranscript new. > tr open. > 1 to: 10 do: [ :index | semaphores at: index put: Semaphore new ]. > > 1 to: 10 do: [:i | > [ > tr nextPutAll: i printString, ' fork '; cr. > (semaphores at: i) signal. > ] fork > ]. > > semaphores do: [:each | each wait ]. > tr show: 'all forks proccesed'; cr. > > > I have seen this pattern often (allocating a semaphore for every > forked process), I usually interpret this as a signal that such code > is still in its first 'make it work/make it right' stages. > What a lot of people don't realize is that at its heart a semapore is > a thread-safe counter/register (and if you look at the hierarchy it is > implemented on you wouldn't guess that either, since the hierarchy > stresses the implementation part that manages waiting processes rather > than the counter aspect). > > So trying to take the code snippet toward 'make it abstract' territory > this could be refactored to lean more on the counter aspect of > semaphores and use only a single semaphore: > > > |count sem tr| > tr := ThreadSafeTranscript new. > tr open. > count := 10. > sem := Semaphore new. > > 1 to: count do: [:i | > [ tr nextPutAll: (i printString, ' fork\') withCRs. > sem signal. > ] fork]. > > count timesRepeat: [sem wait]. > tr show: 'all forks proccesed'; cr. > > > > Now the above is about as far as you can go with the current Squeak > and VisualWorks implementations so you can take it as a simple > refactoring advise. > > > > > However I want to press on a bit more (and go a bit off-topic for this > list ;-) because I feel it still has a big problem: we need to > maintain a 'count' and pass that between the two loops in the above > example. > In the current example this is not much of a problem but in more > complex applications where the forking is done by yet other forked > processes we will need to make 'count' thread-safe as well -- I find > this very ugly, because you will need an extra semaphore just to make > the original semaphore work as required. > Furthermore you cannot add new forked processes once the second loop > has started running. > > So here is an experiment I did a couple of years ago with VisualWorks: > I altered the VM (just one line of its source ;-) so it would react > properly to semaphores that have negative values in the > 'excessSignals' instance variable, and I added a method #unsignal to > Semaphore that would decrease the value of that ivar. > > In my experiments that yielded many opportunities to simplify > multiprocessing code (not only for thread synchronization but also for > passing around counts in a thread-safe register!). > > In the above code that would allow us to 'pre-load' the semaphore at > the place where the threads are created with as result that the > 'count' variable can be removed and the bottom loop can be removed too: > > > |count sem tr| > tr := ThreadSafeTranscript new. > tr open. > sem := Semaphore forMutualExclusion. "We need one excessSignal to > balance the #wait below" > > 1 to: 10 do: [:i | > sem unsignal. "outside the forked code" > [ tr nextPutAll: (i printString, ' fork\') withCRs. > sem signal. "balance the unsignal" > ] fork]. > > sem wait. "no loop, no need to know the count!" > tr show: 'all forks proccesed'; cr. > > > > > > Above was just a simple refactoring, but look at how I needed it: > > |sem tr| > tr := ThreadSafeTranscript new. > tr open. > sem := Semaphore new. "no excessSignal this time" > > "set up a monitoring system first(!)" > [ sem wait. > tr show: 'all forks proccesed'; cr > ] fork. > > "then create jobs (in my case I had only a single first job that would > recursively create more jobs, not shown here)" > > 1 to: 10 do: [:i | > sem unsignal. > [ tr nextPutAll: (i printString, ' fork\') withCRs. > sem signal. > ] fork]. > "Now that we are sure at least one job is entered balance the #wait we > started out with" > sem signal. > > > Since we elided 'count' I can move the code that relied on it up in > front of the thread creation code, I very much like this flavor of > decoupling. > > > I guess this illustrates that Semaphore is stuck in the 'make it work/ > make it right' phase for thirty years now, and that moving it into > 'make it abstract' territory will make lots of hairy multi-threading > code much simpler to express... > > (And for those thinking this through: yes I did implement a thread- > safe #add: and #valueWithReset on semaphore too ;-) > > > I hope I didn't bore y'all and stray to far off-topic, but I did want > to share this bit of insight I gained by tinkering with the semaphore > implementation: semaphores are thread-safe counters at their heart. > > > > Cheers, > > Reinout > ------- > > PS: big congrats with the license cleaning milestone, this is what > finally pulled me into this project :-) > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 6, 2009

Re: [Pharo-project] Loads of Pharo development process questions

by Reinout Heeck

>> >> I think we should consider cribbing from the model that Linux distros >> use: >> >> Load (more precisely: use -- we might not be able to load it) a / >> specific/ version of the Squeak tool, and then apply a separate >> (Pharo- >> maintained) set of patches to make it Pharo compliant. > > but only the developer of the tool can do that. No, quite the opposite: The Pharo maintainers maintain the Pharo compliance patches for every tool we import, the tool developer should not be bothered with these -- should not even see them. Only a subset of these patches -- the bugfixes created in the Pharo community -- should be pushed up to the tool developer. This way both worlds could get the best of both worlds: The tool developers still get bugfixes posted despite their original implementation possibly being/becoming incompatible with Pharo. The Pharo community gets the freedom to become incompatible with Squeak without loosing the benefits of ongoing tool development on Squeak. I am not saying this is the only solution, just describing what is a 'field proven' model in the Linux community which seems to perfectly implement the stated goals of Pharo. > >> [...for version management] >>> The vision is bytecode loader >> >> Pleas don't go there. Byte-code loading is a very nice-to-have in >> deployment scenarios (lazy plugin loading, live update delivery to >> deployed apps etc) but if there is one thing that using VW's Store >> has >> taught me it is that it definitely should not be part of a code >> repository that is used for development code version management. > > This is in VW store is bad. I do not see why a package MCZ could not > ship with > a byte-code synchronized version of the source. Then we could have a > stripper > or a synchronizer that recompile the source code and produce new > bytecode. In my experience it 'poisons' the repository with packages that load fine as bytecode but fail to load as source. Mostly in 'auto brain surgery' scenarios where the /source/ should contain more load ordering hints (but never attains that level because the binary version hides these bugs). I reiterate that VW shows that source loading is fast enough -- even for rather large updates. So in my opinion 'fast enough' source loading should be attained first, and bin-loading should be added later as an option (and probably not in the code repository but perhaps in a cache in front of such a repository, or maybe sideways as part of a build process). > > we will start by fixing packageInfo :-) right! R -

July 6, 2009