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

Re: [Pharo-project] Return values of methods

by csrabak＠bol.com.br

Aug. 19, 2009

Re: [Pharo-project] Return values of methods

by Lukas Renggli

> I read somewhere that having a method that may return different type > of values is not of a good style. I first through it was in Kent's > book, but I cannot find it. > Is there a book that talk about this coding style? There is a SmallLint rules that checks for this, see the class RBReturnsBooleanAndOtherRule. As a rational it states: "Checks for methods that return a boolean value (true or false) and return some other value such as (nil or self). If the method is suppose to return a boolean, then this signifies that there is one path through the method that might return a non-boolean. If the method doesn't need to return a boolean, you should probably rewrite it to return some non-boolean value since other programmers reading your method might assume that it returns a boolean." Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Aug. 19, 2009

Re: [Pharo-project] Call for synchronization with OB tools

by Damien Cassou

Hi Stef, On Mon, Aug 17, 2009 at 11:06 AM, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> wrote: > I'm totally confused about the state of the OB tools and this is not a > good point. > So which version are loaded in pharo? Download Pharo and open a Monticello browser. You can also have a look at the script which generates the image and which is included in all Pharo archives: instClass lukas project: 'omnibrowser'; install: 'OmniBrowser'; install: 'OB-Standard'; install: 'OB-Morphic'; install: 'OB-SUnitIntegration'. > What is the status of these versions? Works quite fine at least for Lukas and me :-). > For the pharo book we are stuck because the chapters were using the > package browser > but now we cannot load it. You can load it, but not in a Pharo image, you have to use a Core. I hope David and Colin will do something about this. At some point, you will have to decide what to include in Pharo. You decided to include the package browser, then you changed your mind and decided to include the classical category browser. This is exactly what I did. > Who controls what is loaded as OB tools? I ask people and I change the script depending on people wishes. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Aug. 19, 2009

Re: [Pharo-project] Return values of methods

by Mariano Martinez Peck

On Wed, Aug 19, 2009 at 5:29 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > Dear List, > > Consider the following method: > -=-=-=-=-=-=-=-=-=-=-=-= > AClass>>aMethod > ^ self compute > ifTrue: [ #aSelector ] > ifFalse: [ false ] > -=-=-=-=-=-=-=-=-=-=-=-= > I read somewhere that having a method that may return different type > of values is not of a good style. It would be worst if they are not only different type but also not polymorphic > I first through it was in Kent's > book, but I cannot find it. > Is there a book that talk about this coding style? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 19, 2009

Re: [Pharo-project] Fwd: OverlyComplex

by Miguel CobÃ¡

On Wed, Aug 19, 2009 at 9:55 AM, <csrabak(a)bol.com.br> wrote: >> El miÃ©, 19-08-2009 a las 00:04 -0300, csrabak(a)bol.com.br escribiÃ³: > Miguel, > >> > Em 18/08/2009 22:25, Igor Stasenko < siguctua(a)gmail.com > escreveu: >> > >> > >> Em 18/08/2009 20:23, Ken.Dickey < Ken.Dickey(a)whidbey.com > >> > escreveu: >> > >> > [snipped] > [snipped] >> >> Maybe you can tell us how much time would you estimate for a java (or >> better yet, c++) version of Seaside or maybe of GLORP, that were made >> for a significant part of their initial life for a single person. >> > > This kind of repts have been used for year to attempt to prove a > lot of non provable things: a similar argument was used to > attempt to "demonstrate" that Linus Torvalds could have written > the kernel for Linux [which applies for the requirement of > yours "...significant part of their initial life for a single > person."] > > Other languages/technologies all have histories, but see: this in > logic is considered the fallacy of cherry picking, where an > interesting and sufficiently high profile case can be shown > off (a famous one is the developmet of the Viaweb site > [http://en.wikipedia.org/wiki/Viaweb] Well maybe you are right, maybe not. More examples that were never *managed* in an enterprise way: Non-commercial: Ruby On Rails Tomcat Apache web server FreeBSD/NetBSD/OpenBSD Squeak Pharo Commercial: Amazon Facebook Google 37signals.com Failed ones, well a lot more than can be described, although they are almost never publicly mentioned. Lots of project from Consulting houses using *enterprise* products as ERP and processes like RUP (and others even more "proved"), with ISO certifications on processes have failed espectacularly. Here in my work, at least 3 projects done by external consulting firms have failed and took a lot more time and resources than the initially estimated. Also the poor souls that they bring to work in the project keep changing every 2 or 3 month (burned by the pressure and the impossible deadlines), and we have had 3 managers for one of these projects. So, yes, I have a very bad impression. Maybe it is just bad luck. Who knows? My friends on other places tell similar stories. So, as you say, nothing can be take for granted on a project both *managed* and *unmanaged* projects can fail, but the fact that a lot of unmanaged projects succeed, makes me wonder of the usefulness of the enterprise *ways* of work. But, lets no start a flame here. I respect your opinion about *managed* projects and have my opinion about *unmanaged* projects. The enterprise world will never change. > > The issue about productivity and discussions about differences > thereof due languages is the _average_ productivity for the mass > of active users. > >> I *am* times more productive in Smalltalk than in Java or PHP or C, even >> if I can not show an *enterprise* benchmark the kind of ones that Garner >> and friends so happily like to show in magazines and flyers. >> > > I don't deny you can be, as I am. Â I can tell why it is in my case. > > If you and we cannot show hard data on an *enterprise* > benchmark (I represent in this country one of the friends and > used to work to the mentioned) you'll a *lot* of difficulty on > convincing companies to embrace this technology. > I am 100% agree with you, sadly that it what the "pointed haired bosses" want to save its asses in the case a project fails. That way they at least can say that it was not because of a bad technology election. How the say goes? Nobody has been fired for choosing IBM? Now you have ISO900*, RUSP, SAP, oracle, etc. :) >> So, a lot of people here can attest that indeed it is more productive to >> work in Smalltalk taht in other languages, and that is the reason why >> this *myth* persist. Maybe subjective, maybe not. We know that when we >> work in Smalltalk and think how much more time/work/effort/boredom will >> take to do the same on other languages. >> > > My contribution to this debate is that if we don't bring > demonstrable data to become facts, we will continue to be heard > as some kind of hacker of a wacky or semi-defunct > language (depending upon the thoughts of the listener). But hey, that is not a goal of the smalltalk community, to appeal and to be the first option for a new project as the java guys, for example, want. We know that there are right tools for each problem in hand. The Pharo project has a goal of be a platform for enterprise apps, but that is different to want to be *the* platform for enterprise apps. Take the case of ruby on rails (and dynamic languages too), 5 years ago it was crazy to even propose them on a meeting for a new project. Now even SUN is sponsoring them on their vm. Times changes, and with time (and even more with the apropriate marketing) the technologies will reach the key people on enterprises and will be an option, even if no metric can be shown for them. > >> >> > Today, due the minute participation of Smalltalk in world production >> > of new funcionality, you cannot find in any commercial or publicly >> > available database on productivity (like ISBSG http://www.isbsg.org/) >> > it mentioned by itself, but only lumped as OTHER 4GL). >> > >> > For a more or less uptodate and public reference, give a look at >> > http://www.qsm.com/?q=resources/function-point-languages-table/index.html >> > >> > >> >> WTF. From the page: >> >> What is a gearing factor? The gearing factor is simply the average >> number of Source Lines of Code (SLOC) per function point in the >> completed project. It is calculated by dividing the final code count >> for a completed project by the final function point count. SLOC counts >> are logical, not physical line counts. >> >> Nuts, is this how the *enterprise* projects are evaluated? >> That is absolute non-sense. What is the difference between logical and >> physical line counts? > > The main point of the text you read is that the evaluations > should be done asap in IFPUG Funtion Points or similar > metric. The proviso thy put there is to allow different coding > practices to be accomodated without inflating the outcomes. A lot > of languages allow more than a logical statement to put in a > single line, or for aesthetical reasons break a single statement > in more than a single line. > Yes, I know that, but my point is: What that does show about a project? A closure in Smalltalk it is more powerfull and usefull that 100 lines of java code or 1000 lines of java code. But a the very same code could be produced in java by using the apropriate library and reduce the line count from 100 to 1. What does that demonstrate? That java is on par with smalltalk? That java it is not just 10 times more productive than c++ but but 1000 times better. I am exaggerating, I know that the numbers are not used that way, but you get my point: although the metrics are promoted as more enterprisey, they aren't. In a certain leve, they are arbitrary. > >> >> > >Or maybe there is something which >> > >increasing their productivity? >> > >> > As you make the rept "are they all genious", I counter with: would you >> > accept/believe that all managers who're responsible for development >> > worldwide are "pointed haired bosses" which cannot discover if such a >> > thing as 'silver bullet' existed? >> > >> > Most productivity is obtained due discipline, processes, trained and >> > motivated people, and one of the last factors is programming language >> > syntax. Programming language technology obviously has a role, >> > otherwise it would be indifferent programming in (say) Smalltalk, >> > versus (say) assembly. >> >> More non-sense, the process isn't a factor. The very same person can do >> sometimes the same work in a week or in a night with coffee. > > A single *task* yes! > A complete project like the Pharo revamp of a renewed Squeak *not*! > > That's where processes come into play and modify the outcomes. > >> WE ARE NOT machines producing nails in a predictable, constant over >> time, unaffected by personal affairs. This factory model doesn't work >> and has never worked. And the ever increasing complexity and irreal >> methods created to try to measure people are a sad result of this way of >> thinking. > > Agreed. It is not for this that development processes are for. It > would become out topic here so I refrain of further discussion. > >> I believe that the work we do is more akin to the artistic disciplines. > > This kind of thinking is an attempt to evade the necessary > debate. Â Most of software development is not of pure conception > but turning into some usable artifact the conception. I would > quote T.A.Edison on his saying about "1% inspiration and 99% > transpiration.", processes is to make us more productive in 99% > part of the job! > > >> Will you try to measure the work done by a musician? or a painter? > > When [s]he is composing, probably not (but: get a look at the > Movie and Advertising industries), when they're playing or the > painter is applying the picture in church's roof, *yes*. > >> That is why the pointed haired bosses depiction and Dilbert cartoons are >> so popular. > > I agree they are popular, but remember that geeks and nerd > depictions are also popular! > > Regards, > > -- > Cesar Rabak > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 19, 2009

[Pharo-project] Return values of methods

by Alexandre Bergel

Dear List, Consider the following method: -=-=-=-=-=-=-=-=-=-=-=-= AClass>>aMethod ^ self compute ifTrue: [ #aSelector ] ifFalse: [ false ] -=-=-=-=-=-=-=-=-=-=-=-= I read somewhere that having a method that may return different type of values is not of a good style. I first through it was in Kent's book, but I cannot find it. Is there a book that talk about this coding style? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 19, 2009

[Pharo-project] Pretty print doesn't work on Traits with OB Package Browser

by Mariano Martinez Peck

Hi! I opened this ticket: http://code.google.com/p/pharo/issues/detail?id=1076 This happens when using the OB Package Browser. I am using 10414. To reproduce: 1) Browse any Trait, for example TBehaviorCategorization 2) Select a method, right button, pretty print 3) You will get a Trait DNU #formatterClass The fix is easy: Crate in Trait a instance side method: formatterClass ^self class formatterClass The thing is that I don't know in which package should this be commited. AST? Best, Mariano ps: the bug report and fix is thanks to Marcelo Cortez

Aug. 19, 2009

Re: [Pharo-project] Class>>isSystemDefined ?

by Alexandre Bergel

officialClass and isSystemDefined are two unnecessary methods. The .cs attached to this issue remove these methods and take care of the callers. I added an entry to the google code website and I provide a change set file to clean. #1075 http://code.google.com/p/pharo/issues/detail?id=1075 The following demonstrates that no impact is expected from loading the clean. In a fresh 10401, the method #isSystemDefined always return true. To be convinced: (Smalltalk allClasses select: [:cls | cls isSystemDefined not]) isEmpty => true (Smalltalk allClasses select: [:cls | cls class isSystemDefined not]) isEmpty => true This is normal, since isSystemDefined is defined as follows: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Class>>isSystemDefined "Answer true if the receiver is a system-defined class, and not a UniClass (an instance- specific lightweight class)" ^ self == self officialClass MetaClass>>isSystemDefined "Answer false if I am a UniClass (an instance-specific lightweight class)" ^ true Class>>officialClass "I am not a UniClass. (See Player officialClass). Return the class you use to make new subclasses." ^ self MetaClass>>officialClass "We want to make a new instance of the receiver, which is a subclass of MorphicModel. Answer who to make a new subclass of. Also used to tell if a given class is a UniClass, existing only for its single instance." ^ self name last isDigit ifTrue: [MorphicModel] ifFalse: [self] "MorphicModel7 can not have subclasses, but Slider and SystemWindow may" -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= When #officialClass is sent to a class, the receiver is always returned. (MorphicModel allSubclasses select: [:cls | cls name last isDigit]) isEmpty => true Before loading the clean, in a fresh 10410 you had: 7124 run, 7102 passes, 4 expected failures, 16 failures, 2 errors, 0 unexpected passes These figures do not change after having loaded the clean. Cheers, Alexandre On 18 Aug 2009, at 16:52, StÃ©phane Ducasse wrote: > did you got a cs for fixing that? > Else could you just log that as a bug entry for 1.1 > Stef > > On Aug 11, 2009, at 4:04 PM, Alexandre Bergel wrote: > >> Dear List members, >> >> The following method is defined in Class: >> -=-=-=-=-=-=-=-=-= >> Class>>isSystemDefined >> "Answer true if the receiver is a system-defined class, and not a >> UniClass (an instance-specific lightweight class)" >> >> ^ self == self officialClass >> -=-=-=-=-=-=-=-=-= >> >> isSystemDefined is sent a number of times. Especially by streams. I >> guess that this determines what should be serialized what should not. >> >> However, #officialClass has only two implementers: >> >> -=-=-=-=-=-=-=-=-= >> Class>>officialClass >> "I am not a UniClass. (See Player officialClass). Return the class >> you use to make new subclasses." >> >> ^ self >> -=-=-=-=-=-=-=-=-= >> >> And slightly more surprising: >> >> -=-=-=-=-=-=-=-=-= >> MorphicModel>>officialClass >> "We want to make a new instance of the receiver, which is a subclass >> of MorphicModel. Answer who to make a new subclass of. Also used to >> tell if a given class is a UniClass, existing only for its single >> instance." >> >> ^ self name last isDigit ifTrue: [MorphicModel] ifFalse: [self] >> "MorphicModel7 can not have subclasses, but Slider and SystemWindow >> may" >> -=-=-=-=-=-=-=-=-= >> >> There is a very strong smell for cleaning here. Apparently, most of >> usage of #isSystemDefined could be replaced by #isBehavior >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 19, 2009

Re: [Pharo-project] Getting Javascript in Moose and/or Pharo

by Alexandre Bergel

Looks good. I am more in a reverse engineering perspective actually. Keep us informed. Cheers, Alexandre On 17 Aug 2009, at 17:48, Eagle Offshore wrote: > I will go you one better. > > I want to do a port of webkit basing it on the GTK one because that > one has a C api and can run more or less identically on OSX, Windows, > and linux. I want web content in Pharo and I don't want to maintain > it - I'd rather we adopt it. > > Then, I want to explore bridging the DOM to smalltalk objects. I've > been downloading and building this stuff all weekend. > > This is very preliminary - its taken all weekend to download all of > the required libraries to build gtkwebkit on the mac. > > I also had the idea some time ago about building an entire UI on top > of webkit using bridged smalltalk DOM. This would let you specify > your widget layout as HTML/CSS but code in Smalltalk and provide a > more or less portable but native UI. Apparently, I'm not the only one > with this idea. > > http://www.advogato.org/article/981.html > > -Todd Blanchard > > On Aug 17, 2009, at 2:24 PM, Alexandre Bergel wrote: > >> Dear List >> >> Making Pharo interacting with Javascript has been the cup of tea of >> the Seaside community. >> I am wondering whether there has been an attempt to produce a parser >> for Javascript within Pharo. >> >> We are interested in getting Javascript models within Moose. >> >> For now, it is likely what we will use the parser of Mozilla to >> produce MSE files. >> >> Cheers, >> Alexandre >> >> NB: Sorry for the cross-posting >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 19, 2009

Re: [Pharo-project] WeakSet growth (issue 1047)

by Henrik Johansen

Ah yes, I have a bad habit of just replying to an old post, and erasing the subject, I'll try and improve my behaviour from now on. I posted a short update to the issue, as I borked up the test results (as usual...) the my first one. : However, the main improvement I expected (constant instead of growing runtime per iteration) still occurs when I run the test properly. Cheers, Henry On Aug 19, 2009, at 4:46 50PM, StÃ©phane Ducasse wrote: > henrik > please create new threads else people may miss your posts > > On Aug 19, 2009, at 4:41 PM, Henrik Johansen wrote: > >> I updated this issue with a solution which is simpler and less >> intrusive than the one in Mantis, >> and don't suffer from any Concurrency-issues not present already. >> (You could argue they solve different problems, but the impact of not >> recycling nilSlots is much less important with this patch, since >> WeakSets won't tend to grow as large) >> >> I'd be grateful if someone would read my reasoning/test the patch, >> and >> give feedback whether there are scenarios where it's not a valid >> solution. >> >> Cheers,

Aug. 19, 2009