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

[Pharo-project] cutting dependencies

by StÃ©phane Ducasse

Hi guys, Just to keep you informed. Tomorrow we will use Moose on Pharo1.1core to assess some dependencies between packages. We already did that in the past and cut some obvious dependencies. We will redo one step with Jannik and Marcus. We will probably redo a couple of sessions. The goal is to identify evil cyclic dependencies and fix them. The tool of jannik is good for that and we applied it on Morphic now we want to apply it on pharo. In the past we fixed some problems and identified missing infrastructural elements. For example the lack of a registration mechanism for the main menu. Now the fact that Setting is cool will also reduce some problems we saw before. This will raise the question of the usage of services too. Because Services are a registration mechanism. Some of you may have noticed that Andreas was successful to remove some packages from Squeak. It should be noted that a lot of these packages are already unloadable in Pharo :) The reorganization also in Test was already done in pharo. Lot of the changes happening in Squeak now (except some of the speed improvements) has already been done some time ago in Pharo. So this is nice to see that our vision was right. During a couple of years we pushed to get a smaller/cleaner system in Squeak and this is happening. So this is nice to see that we are right even if most people will not recognize or remember it :) Stef (going swimming in this cold winter).

Jan. 6, 2010

Re: [Pharo-project] Fwd: traits :)

by Alexandre Bergel

Very nice post! Alexandre On 5 Jan 2010, at 15:23, StÃ©phane Ducasse wrote: > > > > Some emails about traits from their father @ google :) > >> Hi Stef >> >> Sorry for the late reply. I'm just going through my email after the >> Christmas break... >> >> > Could someone please come up with ONE example where MI (traits in >> particular) solve an *actual* problem and not just some academic BS? >> >> I have encountered a bunch of cases in my every-day work at Google >> where single inheritance was not good enough to write the >> functionality that we needed without (a) code duplication and/or >> (b) boilerplate for object delegation (plus the associated >> complexity/slow-down/etc.). This was getting so annoying that I >> went through the hassle of implementing a template-based traits >> mechanism in C++ that we have been using quite regularly. >> >> For example, we have been designing and implementing a very complex >> framework for efficient handling of massive entity/relation graphs >> (billions of nodes). Since we needed this framework to be general >> across multiple aspects, we simply couldn't come up with a good way >> of doing this without some sort of MI, and traits proved to be >> extremely useful. So, based on my experience, I certainly have seen >> plenty of real-world applications where traits can make a >> tremendous difference!! >> >> That said, I can absolutely see that an overuse of traits can also >> add a lot of additional complexity. But in my opinion, this is not >> specific to traits and much more applies to almost any concept when >> it is overused. Consider for example single inheritance. If someone >> needs a class with 50 methods and decide to split this into a 10- >> level deep class hierarchy (just in case that somebody might want >> to reuse a part of it later), this will annoy a lot of other people >> and make things unnecessary complex. Similarly, if somebody splits >> a method with a 20 line algorithm into 10 helper methods with hard- >> to-understand names and consisting of only 2 lines each, this will >> probably make things much harder to understand (although having >> small methods is generally a good thing). >> So, despite the fact that the concepts of single inheritance and >> (helper-)methods can be overused, I'm sure that neither of us would >> argue that they are bad/useless in the first place. And this is the >> same for any of the other nice programming concepts that come to >> mind, like meta-programming and closures (as much as I love >> closures for parametrization, overuse of functional elements can >> make code really hard to understand as well...) >> >> From my point of view, the same applies to traits: If traits are >> used in cases where they actually bring a benefit, i.e., they >> factor together a set of methods that conceptually and logically >> belong together and actually facilitate code reuse, they have been >> very useful to me. >> >> >> Happy New Year and all the best, >> Nathanael >> > > > > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 6, 2010

Re: [Pharo-project] Beginner question :) search and replace in String

by Adrian Kuhn

Douglas Brebner <squeaklists@...> writes: > Please bear in mind that natural languages have much more redundancy and > less precision than programming languages. You are right! Personally I believe programming languages should strive to be as close to the the more stringent English of specification documents, and not to natural language with *all* its facets. The main line of argumentation in my previous mail was thus that the very argument of natural languages can be used in favor of my point as well :) > In addition, programming languages have handy tools like autocompletion > that natural languages don't, making abbreviations less useful :) That argument keeps popping up (eg from Ramon just in parallel to this answer, and also before) but I am not sure if auto completion is the whole story. For example in Object-C you have to write @"hello " stringByAppendingString: @"worlds!" to concatenate strings. Whereas in Smalltalk we just write 'hello ', 'worlds!' clearly both are as writable when you got auto completion, but isn't the second just more readable? In his "Elements of Style" William Strunk recommends to omit unnecessary word. With regard to source code, I'd say the lesson should be that more verbose is typically more readable but *not* always. So given this observation that sometimes operators (or single letters, which for that sake the same) are *sometimes* more readable than natural language, we can go an revisit the set of operators in Smalltalk and check if there might be more candidates. And I'd be more than surprised if are were not some more candidates for abbreviation. For example Pharo already got #<< for appending to a stream, so the same would make sense to append elements to a collecton, such that we can write list := List new << 'lorem' << 'ipsum' << 'dolor'. et cetera. --AA

Jan. 6, 2010

Re: [Pharo-project] What about killing PharoWeb images?

by StÃ©phane Ducasse

me too On Jan 6, 2010, at 11:26 AM, Marcus Denker wrote: > Hello, > > Yes... we need to control the amount of work invested. And we need to be > clear when we reach a point where we just can't provide something. > > So I vote for not having an official web image. > > Marcus > > On Jan 5, 2010, at 9:11 PM, Tudor Girba wrote: > >> I too believe that is the best choice at this moment. >> >> Cheers, >> Doru >> >> >> On 5 Jan 2010, at 20:15, StÃ©phane Ducasse wrote: >> >>> Let us be pragmatic and focused. >>> >>> I would say that I would prefer to have one single pharo-dev image >>> than a middle pharo-dev image and a pharo-web. >>> We can focus on pharo-dev >>> And let lukas ship a one-click seaside image. >>> >>> With the time the pharo-dev will support easy configuration to load >>> seaside >>> aida >>> and a lot more so we will just offer one good image and let people >>> decide. >>> so I would focus on our customers first :) >>> >>> Stef >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> www.tudorgirba.com >> >> "Reasonable is what we are accustomed with." >> >> >> _______________________________________________ >> 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

Jan. 6, 2010

Re: [Pharo-project] What about having a blog with news in pharo website?

by Marcus Denker

On Jan 5, 2010, at 3:29 PM, Mariano Martinez Peck wrote: > > > On Tue, Jan 5, 2010 at 3:15 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi Mariano, > > Our website, pharo-project.org, is Cmsbox, not Pier. > > Ups....sorry. You are right :) > > But anyway, we've > already set up a blog. The only problem is that nobody got round to > writing posts so far... > > > mmmmmm I didn't now about that. Was that announced ? No, not announced... I have an entry on my todo to start to use it, but I did not find the energy and time until now. So it would be nice to have a group of people take over filling this blog... Marcus

Jan. 6, 2010

Re: [Pharo-project] What about killing PharoWeb images?

by Marcus Denker

Hello, Yes... we need to control the amount of work invested. And we need to be clear when we reach a point where we just can't provide something. So I vote for not having an official web image. Marcus On Jan 5, 2010, at 9:11 PM, Tudor Girba wrote: > I too believe that is the best choice at this moment. > > Cheers, > Doru > > > On 5 Jan 2010, at 20:15, StÃ©phane Ducasse wrote: > >> Let us be pragmatic and focused. >> >> I would say that I would prefer to have one single pharo-dev image >> than a middle pharo-dev image and a pharo-web. >> We can focus on pharo-dev >> And let lukas ship a one-click seaside image. >> >> With the time the pharo-dev will support easy configuration to load >> seaside >> aida >> and a lot more so we will just offer one good image and let people >> decide. >> so I would focus on our customers first :) >> >> Stef >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Reasonable is what we are accustomed with." > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 6, 2010

Re: [Pharo-project] Interim build server

by StÃ©phane Ducasse

On Jan 6, 2010, at 9:29 AM, Michael Roberts wrote: > stef: great. > Yanni: I agree. I used to run the tests myself and publish them to > the google wiki for the end of 1.0 cycle. it did not scale ;-) > > I see the two efforts as complimentary. I am really working from the > inside out. Your approach is outside in. For example I have > refactored the image update code so that it is a bit more manageable. > Detecting the build failures is important, for example as I wrote my > post, an update stalled with EOCD error in MC code. this is cool! > hudson looks > good. all the dashboard and easy install stuff for free. do you > regularly use & maintain it? > > cheers, > Mike > > On Wed, Jan 6, 2010 at 7:08 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> mike >> >> I will ask in my team if our infrastructure can be used. >> Damien, marcus do you know the servers we have? >> >> Stef >> >> On Jan 5, 2010, at 10:27 PM, Michael Roberts wrote: >> >>> Hi, following on from the timely Hudson post ;-) I too have been >>> working on continuous integration. I am more interested in identifying >>> & integrating the various bits of plumbing first rather than the build >>> solution itself. I figured the infrastructure needed to be understood >>> first, and there could be value in such an interim solution >>> >>> To this end I have: >>> -written a simple image builder that updates the image in place. >>> -running remotely on a Linux host I have borrowed access >>> -building PharoCore 1.1 from #11110 onwards >>> -started to publish images at http://pharo.gforge.inria.fr/experimental/ >>> >>> remaining is to rename the core images to unstable and then look at >>> running some tests. This has exposed various issues, mainly image >>> timeout caused by the various dialogs that can popup when filing in >>> code. >>> >>> so >>> 1) if anyone would like to test the integrity of these experimental >>> auto-build images, please do >>> 2) discuss if something in this namespace >>> http://pharo.gforge.inria.fr/<> is suitable for automatic publishing >>> - i am not sure how you automatically create gforge "releases" but >>> for core images perhaps this is not needed >>> 3) find a real server we can run this on, (if this is considered >>> worthwhile). My requirements are Linux + daemontools + vnc server >>> - i can host my solution for a while, we need something strategic >>> >>> then once we have a server I'm happy to look at Hudson or whatever we >>> consider the right tool for doing this. I have also been playing with >>> Mason and sent some feedback to Colin. Like i say, for me the real >>> issues are running a Pharo image completely automated. >>> >>> Cheers, >>> Mike >>> >>> _______________________________________________ >>> 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

Jan. 6, 2010

Re: [Pharo-project] SplitJoinTest broken by new Regex version

by Lukas Renggli

Oscar fixed this in http://code.google.com/p/pharo/issues/detail?id=1415 Also this newly reported regex bug http://code.google.com/p/pharo/issues/detail?id=1727 seems to refer to a bug in the old version. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 6, 2010

[Pharo-project] SplitJoinTest broken by new Regex version

by Adrian Lienhard

After the update of VB-Regex (http://code.google.com/p/pharo/issues/detail?id=1639 ), the test SplitJoinTest>>testSplitStringOnRegex fails. Does somebody know what's wrong and how to fix it? Cheers, Adrian ___________________ http://www.adrian-lienhard.ch/

Jan. 6, 2010

Re: [Pharo-project] Interim build server

by Michael Roberts

stef: great. Yanni: I agree. I used to run the tests myself and publish them to the google wiki for the end of 1.0 cycle. it did not scale ;-) I see the two efforts as complimentary. I am really working from the inside out. Your approach is outside in. For example I have refactored the image update code so that it is a bit more manageable. Detecting the build failures is important, for example as I wrote my post, an update stalled with EOCD error in MC code. hudson looks good. all the dashboard and easy install stuff for free. do you regularly use & maintain it? cheers, Mike On Wed, Jan 6, 2010 at 7:08 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > mike > > I will ask in my team if our infrastructure can be used. > Damien, marcus do you know the servers we have? > > Stef > > On Jan 5, 2010, at 10:27 PM, Michael Roberts wrote: > >> Hi, following on from the timely Hudson post ;-) I too have been >> working on continuous integration. I am more interested in identifying >> & integrating the various bits of plumbing first rather than the build >> solution itself. Â I figured the infrastructure needed to be understood >> first, and there could be value in such an interim solution >> >> To this end I have: >> -written a simple image builder that updates the image in place. >> -running remotely on a Linux host I have borrowed access >> -building PharoCore 1.1 from #11110 onwards >> -started to publish images at http://pharo.gforge.inria.fr/experimental/ >> >> remaining is to rename the core images to unstable and then look at >> running some tests. Â This has exposed various issues, mainly image >> timeout caused by the various dialogs that can popup when filing in >> code. >> >> so >> 1) if anyone would like to test the integrity of these experimental >> auto-build images, please do >> 2) discuss if something in this namespace >> http://pharo.gforge.inria.fr/<> is suitable for automatic publishing >> Â - i am not sure how you automatically create gforge "releases" but >> for core images perhaps this is not needed >> 3) find a real server we can run this on, (if this is considered >> worthwhile). My requirements are Linux + daemontools + vnc server >> Â - i can host my solution for a while, we need something strategic >> >> then once we have a server I'm happy to look at Hudson or whatever we >> consider the right tool for doing this. Â I have also been playing with >> Mason and sent some feedback to Colin. Â Like i say, for me the real >> issues are running a Pharo image completely automated. >> >> Cheers, >> Mike >> >> _______________________________________________ >> 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 >

Jan. 6, 2010