- Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

>> > > 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. I agree but it means that other pharoers should stand up and sign for that because I'm full and will probably continue to be. > 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. Ok so this is a good news. > 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). yes this is also an alternative. >> we will start by fixing packageInfo > > :-) right! > > > > R > - > > > _______________________________________________ > 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 StÃ©phane Ducasse

On Jul 6, 2009, at 9:33 PM, Hernan Wilkinson wrote: > Hi Stef, > have you thought about have not only first class instance variables > but first class variables? (no matter the scope). yes this was included. Now we want to really experiment and provide a real and working solution. I just mentioned that because Smalltalk deserves a better instantiation. :) > 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, We did a simple implementation with marcus and the implementation we came up with did not have **any** runtime penalties. Now the classBuilder is so brittle that to make sure that we would have a robust implementation we would have to rewrite it and this is a real nightmare... look at the comment. for now we just created an extra instance variable that serves to allocate our instances :) > but looks interesting... accessing local variables could be made > sending messages to thisContext... anyway, just an idea. so far having plain well working first class instance/class variable would be a really good achiemenet with a good mop. Would be great. Imagine people could implement tweak like field without requiring copying the compiler and adding XML syntax :) > > 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 > > _______________________________________________ > 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 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