February 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] Flattening traits

by Andy Kellens

Hello, I am trying to load Ring into GemStone. As Ring uses traits, the first thing I did was flatten the traits. Based on a thread on this mailing list from June 2011 (Elliot flattening the traits in Fuel) I used Behavior>flattenDownAllTraits. One thing I noticed is that, while this method successfully flattens the instance methods of the trait, the class methods appear to be just removed. I was able to fix this by changing method Behavior>>flattenDown. Before this method was implemented as: flattenDown: aTrait | selectors | [self hasTraitComposition and: [self traitComposition allTraits includes: aTrait]] assert. selectors := (self traitComposition transformationOfTrait: aTrait) selectors. self basicLocalSelectors: self basicLocalSelectors , selectors. self removeFromComposition: aTrait. My guess is that the culprit for this is the method Behavior>>removeFromComposition:, which removes the trait both from the instance and the class side. While the trait selectors were added to the instance side, they are not to the class side and therefore they are gone after the flattening. I was able to fix this by changing the method to: flattenDown: aTrait | selectors classSelectors transformation classTransformation | [self hasTraitComposition and: [self traitComposition allTraits includes: aTrait]] assert. transformation := self traitComposition transformationOfTrait: aTrait. selectors := transformation selectors. classSelectors := classTransformation selectors. self basicLocalSelectors: (self basicLocalSelectors ifNil:[selectors] ifNotNil:[:bs | bs, selectors]). self class basicLocalSelectors: (self class basicLocalSelectors ifNil:[classSelectors] ifNotNil:[:bs | bs, classSelectors]). self removeFromComposition: aTrait. My fix feels more like a workaround than a real solution to the problem, so before that I submit a patch to the inbox I was wondering if someone with more knowledge regarding the traits implementation has any input on this ... Cheers, Andy

Feb. 2, 2012

Re: [Pharo-project] How to disable development tools on Pharo 1.3

by Esteban Lorenzano

Hi Noury, I packaged what I have. And even create a settings configuration for it (under "Deployment" category). Notice that is very hacky and ugly and needs a lot (and I mean A LOT) of polish... but is a start :) see WSSettings class>>#setDeployment: for a start. best, Esteban El 02/02/2012, a las 6:40a.m., Noury Bouraqadi escribiÃ³: > Hi Esteban, > > On 31 janv. 2012, at 14:23, Esteban Lorenzano wrote: > >> Hi, >> >> in fact, what Mariano posted is just a part... disable everything is complicated, because code is everywhere... I'm collection all of this changes in a package, to see in advance if it is possible to abstract that. > > Thanks Esteban! > Do you have a version of this package already? > Otherwise, I'll start packaging what Mariano sent. > > >> Ideally, we should have a preference "Disable Development Mode", or something like that to allow desktop developers to easily switch... >> > Yes. We should have a menu for this. It's part of dev tools. > It's a shame that this critical feature isn't available yet. > > Noury > >> best, >> Esteban >> >> El 31/01/2012, a las 10:16a.m., Ben Coman escribiÃ³: >> >>> Noury Bouraqadi wrote: >>>> I remember having seen some time in the past a menu that allows to shrink the image and disable the world menu. >>>> But, I can't retrieve any thing related. I don't care about the menu per se. I'd be happy with a message to send to some object that does the job. >>>> >>>> >>>> Noury >>>> -- >>>> http://twitter.com/#!/NouryBouraqadi >>>> http://www.kroobe.com/profile/noury >>>> >>>> >>> Squeak 3.9 based, but perhaps something useful... >>> "Prepare For Application Deployment" http://squeak.preeminent.org/tut2007/html/205.html >>> >>> >> >> > > Noury > -- > http://twitter.com/#!/NouryBouraqadi > http://www.kroobe.com/profile/noury > > > Afin de contribuer au respect de l'environnement, > merci de n'imprimer ce courriel qu'en cas de necessite > > Please consider the environment before you print > > > >

Feb. 2, 2012

Re: [Pharo-project] Building a developer community

by Ben Coman

laurent laffont wrote: > http://www.slideshare.net/kohsuke/building-developer-community > > Slide 9 looks interesting (Thank you for downloading page). How can I do > that with cmsbox / pharo website ? > > Laurent Laffont > > Slide 20 is an interesting premise. "Division of Labor > Collaboration." Under the assumption that is true, then perhaps a Smalltalk with a lot in its image is more dependent on collaboration and why the drive of Pharo towards modularization is important to better enable division of labor. regards, Ben

Feb. 2, 2012

Re: [Pharo-project] Question regarding LinkedList collect:

by Ben Coman

Henrik Johansen wrote: > On Feb 2, 2012, at 10:34 AM, Andreas Haufler (scireum GmbH) wrote: > > >> Hi everyone, >> >> I'm a Pharo newbie with some knowledge about Smalltalk. Surfing through the code base I stumbled over the implementation of LinkedList collect: - Your're right, there is none, it's inherited by SequenceableCollection. Looking through this code, I discovered that it builds a LinkedList of the same size and then uses the at: and at:put: selector to copy the transformed values form the first list to the second. >> >> Knowing that at: and at:put: have O(n) complexity for linked lists, this makes collect: an O(n^2) operation. On the other hand, this could easily changed into O(n) by implementing collect: for LinkedList: >> >> collect: aBlock >> "Evaluate aBlock with each of the receiver's elements as the argument. >> Collect the resulting values into a collection like the receiver. Answer >> the new collection." >> >> | newCollection | >> newCollection := self species new. >> self do: >> [:val | >> newCollection add: (aBlock value: val)]. >> ^ newCollection >> >> I profiled this using: >> x := LinkedList new. >> 1 to: 10000 do: [:n |x add: n]. >> TimeProfileBrowser onBlock: [ x collect: [:i | i] ] >> >> and saw a improvement of: 795msec (old) vs. 6msec (new). >> >> I wonder therefore, if LinkedList is just seldomly used (in Java i.e. nearly all lists use ArrayList nowadays)? Or would the system benefit from this improvement? I could then look through the other methods (collect:from:to: et. al.) and provide a patch. >> >> >> best regards + thank's for creating such a beautiful system >> Andreas Haufler >> > > It does suffer from being a subclass of SequenceableCollection where default implementations assume O(1) at: and at:put: implementationsâ¦ > You're right it's not often used (at least not polymorphical to normal collections), and as such it's a tradeoff between keeping the implementation small (by using slow, but working super implementations), and reimplementing methods efficiently. > > In this case though, it seems Alain already noticed, and collect: has already been reimplemented efficiently in 1.4 > > Cheers, > Henry > > Henrik, Please note that I've only picked this as an example since it occurred coincidently with my having just read the insightful slides of the "[Pharo-project] Building a developer community" thread - but in light of that... While your answer was good technically, it was not as good as it could be for "building Pharo's developer community". Here a "visitor" with reasonable Smalltalk ability extended a helping hand. The response returned was a polite "we are doing good on our own thanks" - which is fine except except it does not draw them in. An alternative might have included "its already been done but come and have a look at it. It would be great if you could help out with (other stuff)" Now some disclaimers... * I did stretch the example since Alain is a third party whom you can't just throw Andreas at unannounced. * There has been little time for anyone else to answer * I don't mean to posts should be constrained by kid gloves. Hopefully though this is a useful perspective to mix in with everything else important. warm regards, Ben

Feb. 2, 2012

Re: [Pharo-project] Building a developer community

by Janko MivÅ¡ek

Very nice presentation indeed. Some for me more interesting thoughts: Every developer starts as a visitor! (my addon: first impression counts!) Visitor -> User -> Developer * Visitor to user - Download, install, initial configuration,â¦ * User to developerâ - Obtain source code, build, run, contribute,â¦ * Obstacles,however little, add up quickly * You donât see the lost opportunities * DOWNLOAD link? How hard is that ... * Make them read code - online browsing! Best regards Janko S, laurent laffont piÅ¡e: > http://www.slideshare.net/kohsuke/building-developer-community > > Slide 9 looks interesting (Thank you for downloading page). How can I do > that with cmsbox / pharo website ? > > Laurent Laffont -- Janko MivÅ¡ek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565

Feb. 2, 2012

[Pharo-project] Fwd: [vwnc] Smalltalk for small projects only?

by Janko MivÅ¡ek

-------- Prvotno sporoÄilo -------- Datum: Tue, 31 Jan 2012 07:54:58 -0600 Od: Peter Hunsberger <peter.hunsberger(a)gmail.com> With all due respect to the experience of everyone here, people really need to give up on this naive belief that Smalltalk development is any more efficient than development in any other language. The simple fact is that within the Smalltalk community a large portion of the developers have been using the tools for a long time and are very good at using them. Throw them at another environment and they are not as efficient. However, if you take new developers and throw them at a Smalltalk project it takes longer to get them up to speed than throwing them at a Java project simply because of the fact that Smalltalk is not as ubiquitous. I switched to Java back when IBM dropped Smalltalk, so I've seen both sides of this issue for a long time, so let me related some anecdotal experience: I'm currently working on a Smalltalk project that has about about 50 man years of effort in it over 10 years. Prior to this I worked on a Java and XSLt project that had about the same effort over the same period. Both have web based GUI's with a fair amount of JavaScript and the usual HTML crud and use a relational DB back end (SQL server and Oracle respectively). The Smalltalk project has had a mix of very experienced Smalltalk developers and inexperienced ones. The Java project was mainly junior and intermediate experience devs. I'd say the overall architecture and design was about equivalent; very different, but equally well done and comprehensive. The projects are very similar in concept and execution. The Java project had about twice as many function points (some pretty major) implemented and four times as many use cases supported at the point I switched to the Smalltalk project. For the most part this has little to do with the language itself. Rather, it is mainly, the supporting infrastructure that one is able to draw on in Java projects and this includes Eclipse, Git, etc. Open Source projects also played a big part of this, in the Java world one can pull in large chunks of functionality at very low cost (eg. XSLt 2.0 processors and pipelines, Spring, Hadoop, you name it) that are just not quite matched in the Smalltalk world. You can often get close, but it seems that there is always something missing, if only because the teams supporting the Smalltalk projects are often much smaller and just can't quite keep up with the every changing specs and requirements. Bottom line, don't kid yourself that there is any inherent advantage in using Smalltalk development over any other language. It is faster for experienced devs in small projects, but if you've got to pull a team together from scratch for some medium to large complexity enterprise scale project it is probably not going to fair as well. Now onto the main question posed here.... I have also worked on a successful 200 man year project (C and C++ in this case), which broke down to a little less than 100 people over a little more than 2 years. This was in the telecom world and involved many main frame billing interfaces and switching equipment interfaces, all very mission critical. In this case about 60% of the team was heads down developers. The rest of it was dedicated testers, tech writers, business analysts, project managers and managers. Here again the supporting infrastructure played an important role. Business analysts could write up use cases that got stored in a repository (a proprietary system) that could be used to generate test case stubs and documentation stubs. The development team tracked progress and bug reports in the same repository and source code version control was tied to the repository. End user documentation was stored in the repository and version controlled. It was simple to know what was going on anywhere in the project and to know where the problems were and what code did what and to see the entire life cycle of any portion of the code base from customer requirement to final deliverable. I know of no support infrastructure that even comes close in the Smalltalk world and would consider it madness to even consider taking on such a project using Smalltalk. Peter Hunsberger On Sun, Jan 29, 2012 at 2:37 AM, laurent laffont <laurent.laffont(a)gmail.com <mailto:laurent.laffont@gmail.com>> wrote: 200 developers on a project ? Scaring ..... They should use another technology than Java to go under 50 developers. They will save a lot of money :) Laurent 2012/1/28 Janko MivÅ¡ek <janko.mivsek(a)eranova.si <mailto:janko.mivsek@eranova.si>> Hi guys, Ralph Johnson in his InfoQ interview made an interesting observation: 2:55 minute: "Smalltalk made an fundamental error ... image ... you can build something with 4-5 people what 50 people can build in Java, but if you take 200 people in Java ... it is really designed for small systems ... " Are we because of the image really destined for relatively small projects and small systems (of Java 50 people project size)? Are we really not able to scale to bigger projects/systems because of that? Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but still... [1] http://www.infoq.com/interviews/johnson-armstrong-oop Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

Feb. 2, 2012

[Pharo-project] Fwd: [vwnc] Smalltalk for small projects only?

by Janko MivÅ¡ek

-------- Prvotno sporoÄilo -------- Datum: Wed, 1 Feb 2012 11:54:22 -0500 Od: Paul Baumann <paul.baumann(a)theice.com> Peter's point that "that there is [not] any inherent advantage in using Smalltalk development over any other language" is true by the criteria that he defined to judged it. It is funny to see "Smalltalk efficiency" is being framed by a standard of high resource requirements, and that Java having twice as many function points and four times as many cases for equivalent architecture and design was somehow a less relevant measure. One might observe that having such a wide variety of similar tools for a language like Java can indicate a limitation of reuse and extension. Smalltalk syntax is less restrictive in how a framework can be reused and extended; that is a better criteria to judge efficiency of the language. "Smalltalk" is syntax and a basic class library; it is not defined by the availability of a vendor features. IBM failures are more relevant than a Smalltalk failure. Large IBM projects of that era failed from Analysis Paralysis. A common goal was compliance with the latest buzz that IBM sold. There were a multitude of management styles in vogue at that time and all could be characterized as top-down management. The "60% heads down developers" were given static designs that had a high and continuous cycle of costs as theory met reality. Large amounts of dumb and redundant code would be generated early. Code inertia and resistance to change would preclude opportunity that is discovered later (like the ability to eliminate thousands of classes with a single reusable type). The result is as predictable as any top-down management style. All design problems were prevented from being fixed until they caused serious and recognizable problems. The management styles of the time promised theoretical efficiencies of scale that had been determined from earlier failures with less malleable languages than Smalltalk. Effectiveness of these feudalistic management styles had yet to be recognized as Dark Ages in the context of software development. Smalltalk does well when individual developers are given opportunity and responsibility, and to the extent that implementation is not restricted. Success with Smalltalk is about rewarding independent action that furthers an objective goal. Management of a Smalltalk project is about providing healthy incentives while minimizing barriers to change. Top-down management (sold by IBM) was more to blame than "Smalltalk". Smalltalk is successfully used for large mission-critical projects that affect global markets. It doesn't take even a dozen Smalltalk developers to do that. Smalltalk can be more efficient than other languages when a compatible management style is used. Smalltalk struggled through the Dark Ages of project management while more popular languages were developed outside of those conditions. Smalltalk is a victim of timing, management, and vision. The more popular languages provide opportunity of market more so than opportunity of syntax. Languages have evolved to be increasingly more malleable like Smalltalk; that is recognition of an advantage that Smalltalk has always had rather than proof that Smalltalk never was more efficient. Some people value opportunity of syntax that Smalltalk offers and have the vision to leverage that to a competitive advantage. Other people recognize that the availability of resources and frameworks can also be leveraged as an advantage over Smalltalk. It is possible to find success or failure either way. Paul Baumann *From:*vwnc-bounces@cs.uiuc.edu [mailto:vwnc-bounces@cs.uiuc.edu] *On Behalf Of *James Robertson *Sent:* Tuesday, January 31, 2012 14:10 *To:* VWNC NC *Subject:* Re: [vwnc] [Pharo-project] Smalltalk for small projects only? Ironically, I worked on a telecom project <in that domain> over a decade ago, with more people involved. Still in production, too. On Jan 31, 2012, at 8:54 AM, Peter Hunsberger wrote: With all due respect to the experience of everyone here, people really need to give up on this naive belief that Smalltalk development is any more efficient than development in any other language. The simple fact is that within the Smalltalk community a large portion of the developers have been using the tools for a long time and are very good at using them. Throw them at another environment and they are not as efficient. However, if you take new developers and throw them at a Smalltalk project it takes longer to get them up to speed than throwing them at a Java project simply because of the fact that Smalltalk is not as ubiquitous. I switched to Java back when IBM dropped Smalltalk, so I've seen both sides of this issue for a long time, so let me related some anecdotal experience: I'm currently working on a Smalltalk project that has about about 50 man years of effort in it over 10 years. Prior to this I worked on a Java and XSLt project that had about the same effort over the same period. Both have web based GUI's with a fair amount of JavaScript and the usual HTML crud and use a relational DB back end (SQL server and Oracle respectively). The Smalltalk project has had a mix of very experienced Smalltalk developers and inexperienced ones. The Java project was mainly junior and intermediate experience devs. I'd say the overall architecture and design was about equivalent; very different, but equally well done and comprehensive. The projects are very similar in concept and execution. The Java project had about twice as many function points (some pretty major) implemented and four times as many use cases supported at the point I switched to the Smalltalk project. For the most part this has little to do with the language itself. Rather, it is mainly, the supporting infrastructure that one is able to draw on in Java projects and this includes Eclipse, Git, etc. Open Source projects also played a big part of this, in the Java world one can pull in large chunks of functionality at very low cost (eg. XSLt 2.0 processors and pipelines, Spring, Hadoop, you name it) that are just not quite matched in the Smalltalk world. You can often get close, but it seems that there is always something missing, if only because the teams supporting the Smalltalk projects are often much smaller and just can't quite keep up with the every changing specs and requirements. Bottom line, don't kid yourself that there is any inherent advantage in using Smalltalk development over any other language. It is faster for experienced devs in small projects, but if you've got to pull a team together from scratch for some medium to large complexity enterprise scale project it is probably not going to fair as well. Now onto the main question posed here.... I have also worked on a successful 200 man year project (C and C++ in this case), which broke down to a little less than 100 people over a little more than 2 years. This was in the telecom world and involved many main frame billing interfaces and switching equipment interfaces, all very mission critical. In this case about 60% of the team was heads down developers. The rest of it was dedicated testers, tech writers, business analysts, project managers and managers. Here again the supporting infrastructure played an important role. Business analysts could write up use cases that got stored in a repository (a proprietary system) that could be used to generate test case stubs and documentation stubs. The development team tracked progress and bug reports in the same repository and source code version control was tied to the repository. End user documentation was stored in the repository and version controlled. It was simple to know what was going on anywhere in the project and to know where the problems were and what code did what and to see the entire life cycle of any portion of the code base from customer requirement to final deliverable. I know of no support infrastructure that even comes close in the Smalltalk world and would consider it madness to even consider taking on such a project using Smalltalk. Peter Hunsberger On Sun, Jan 29, 2012 at 2:37 AM, laurent laffont <laurent.laffont(a)gmail.com <mailto:laurent.laffont@gmail.com>> wrote: 200 developers on a project ? Scaring ..... They should use another technology than Java to go under 50 developers. They will save a lot of money :) Laurent 2012/1/28 Janko MivÅ¡ek <janko.mivsek(a)eranova.si <mailto:janko.mivsek@eranova.si>> Hi guys, Ralph Johnson in his InfoQ interview made an interesting observation: 2:55 minute: "Smalltalk made an fundamental error ... image ... you can build something with 4-5 people what 50 people can build in Java, but if you take 200 people in Java ... it is really designed for small systems ... " Are we because of the image really destined for relatively small projects and small systems (of Java 50 people project size)? Are we really not able to scale to bigger projects/systems because of that? Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but still... [1] http://www.infoq.com/interviews/johnson-armstrong-oop Best regards Janko

Feb. 2, 2012

Re: [Pharo-project] Question regarding LinkedList collect:

by Henrik Johansen

On Feb 2, 2012, at 10:34 AM, Andreas Haufler (scireum GmbH) wrote: > Hi everyone, > > I'm a Pharo newbie with some knowledge about Smalltalk. Surfing through the code base I stumbled over the implementation of LinkedList collect: - Your're right, there is none, it's inherited by SequenceableCollection. Looking through this code, I discovered that it builds a LinkedList of the same size and then uses the at: and at:put: selector to copy the transformed values form the first list to the second. > > Knowing that at: and at:put: have O(n) complexity for linked lists, this makes collect: an O(n^2) operation. On the other hand, this could easily changed into O(n) by implementing collect: for LinkedList: > > collect: aBlock > "Evaluate aBlock with each of the receiver's elements as the argument. > Collect the resulting values into a collection like the receiver. Answer > the new collection." > > | newCollection | > newCollection := self species new. > self do: > [:val | > newCollection add: (aBlock value: val)]. > ^ newCollection > > I profiled this using: > x := LinkedList new. > 1 to: 10000 do: [:n |x add: n]. > TimeProfileBrowser onBlock: [ x collect: [:i | i] ] > > and saw a improvement of: 795msec (old) vs. 6msec (new). > > I wonder therefore, if LinkedList is just seldomly used (in Java i.e. nearly all lists use ArrayList nowadays)? Or would the system benefit from this improvement? I could then look through the other methods (collect:from:to: et. al.) and provide a patch. > > > best regards + thank's for creating such a beautiful system > Andreas Haufler It does suffer from being a subclass of SequenceableCollection where default implementations assume O(1) at: and at:put: implementationsâ¦ You're right it's not often used (at least not polymorphical to normal collections), and as such it's a tradeoff between keeping the implementation small (by using slow, but working super implementations), and reimplementing methods efficiently. In this case though, it seems Alain already noticed, and collect: has already been reimplemented efficiently in 1.4 Cheers, Henry

Feb. 2, 2012

Re: [Pharo-project] How to disable development tools on Pharo 1.3

by Noury Bouraqadi

Hi Esteban, On 31 janv. 2012, at 14:23, Esteban Lorenzano wrote: > Hi, > > in fact, what Mariano posted is just a part... disable everything is complicated, because code is everywhere... I'm collection all of this changes in a package, to see in advance if it is possible to abstract that. Thanks Esteban! Do you have a version of this package already? Otherwise, I'll start packaging what Mariano sent. > Ideally, we should have a preference "Disable Development Mode", or something like that to allow desktop developers to easily switch... > Yes. We should have a menu for this. It's part of dev tools. It's a shame that this critical feature isn't available yet. Noury > best, > Esteban > > El 31/01/2012, a las 10:16a.m., Ben Coman escribiÃ³: > >> Noury Bouraqadi wrote: >>> I remember having seen some time in the past a menu that allows to shrink the image and disable the world menu. >>> But, I can't retrieve any thing related. I don't care about the menu per se. I'd be happy with a message to send to some object that does the job. >>> >>> >>> Noury >>> -- >>> http://twitter.com/#!/NouryBouraqadi >>> http://www.kroobe.com/profile/noury >>> >>> >> Squeak 3.9 based, but perhaps something useful... >> "Prepare For Application Deployment" http://squeak.preeminent.org/tut2007/html/205.html >> >> > > Noury -- http://twitter.com/#!/NouryBouraqadi http://www.kroobe.com/profile/noury Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite Please consider the environment before you print

Feb. 2, 2012

Re: [Pharo-project] How to disable development tools on Pharo 1.3

by Noury Bouraqadi

Thanx Ben. I was aware of the old squeak stuff. I actually have the code on my disk. But, I was wondering if there is something for Pharo. On 31 janv. 2012, at 14:16, Ben Coman wrote: > Noury Bouraqadi wrote: >> I remember having seen some time in the past a menu that allows to shrink the image and disable the world menu. >> But, I can't retrieve any thing related. I don't care about the menu per se. I'd be happy with a message to send to some object that does the job. >> >> >> Noury >> -- >> http://twitter.com/#!/NouryBouraqadi >> http://www.kroobe.com/profile/noury >> >> > Squeak 3.9 based, but perhaps something useful... > "Prepare For Application Deployment" http://squeak.preeminent.org/tut2007/html/205.html > > Noury -- http://twitter.com/#!/NouryBouraqadi http://www.kroobe.com/profile/noury Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite Please consider the environment before you print

Feb. 2, 2012