December 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.4] #14267

by stephane ducasse

14267 ----- - Issue 5113: Use ZnClient instead of HttpClient. Let us try to see if the update stream is ok after that one. Stef

Dec. 25, 2011

[Pharo-project] [update 1.4] #14268

by StÃ©phane Ducasse

14268 ----- - Issue 5126: french Date format. Thanks Olivier Overlot. http://code.google.com/p/pharo/issues/detail?id=5126

Dec. 25, 2011

Re: [Pharo-project] Good practicces! Looking for examples

by Franz Josef Konrad

Stef, you should also refere to Kent Beck's book "SmallTalk Best Practice Patterns" in your chapter. IMHO it's one of the best Smalltalk books written in this area. Franz Josef Am 24.12.2011 14:53, schrieb StÃ©phane Ducasse: > Hi guys > > talking with sven during the last sprint we realized that it would be good to collect and document some good practices. > So I started a chapter for PBE2 on coding practices. > > I will take the some of the optimization that sven did in time/date printOn: as a start > > If you have some suggestions with examples I could integrate to the chapter. > > > Stef > > >

Dec. 25, 2011

[Pharo-project] [update 1.4] #14266

by StÃ©phane Ducasse

14266 ----- - Issue 5117: MNU: Transcripter class>>open. Thanks vpnbecmann. http://code.google.com/p/pharo/issues/detail?id=5117 - Issue 5122: ZnUpdate-Dec-20. Thanks sven van caekenberghe. http://code.google.com/p/pharo/issues/detail?id=5120 Stef

Dec. 25, 2011

Re: [Pharo-project] IdentitySet but using #hash rather than #identityHash ?

by Andres Valloud

I betcha the performance problem is because the collision "trains" end up hitting each other. In this case you likely won't be able to avoid collisions. So, instead of the regular hashed collections that use open addressing linear probing, use a hashed collection that stores objects in hash buckets. It would be great if hashed collections did not inline a specific storage strategy, but alas... :(. On 12/12/11 0:58 , Mariano Martinez Peck wrote: > Hi guys. I hope this is not a very stupid question. Background: in Fuel > we have a IdentityDictionary where we put each of the objects we find > while traversing the graph. We need to use IdentitySet because we cannot > have repetitions (and to avoid loops) so we NEED to use #==. In such > dictionary we put ALL objects of the graph, so it can be very big. Since > IdentitySet uses #identityHash, it means it will be using those ONLY 12 > bits in the object header. It means that we have 2^12 = 4096 different > values. > > Question: having explained the previous, I wanted to be able to use > #hash rather than #identityHash since several classes implement #hash > and hence I thought that using #hash I could have less colisions and > hence a better performance. I tried to make a subclass of IdentitySet > that uses #hash rather than #identityHash but my image freezes. I also > tried something like: > > set := PluggableSet new. > set hashBlock: [ :elem | elem hash ]. > set equalBlock: [ :a :b | a == b ]. > > But it doesn't work either. I works with simple tests in a workspace but > when I run the full tests of Fuel, it enters in a loop in the method > #hash of Collection.. > > Anyway, my question is, should that work? if not, what is the exact reason? > > Thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 25, 2011

Re: [Pharo-project] Good practicces! Looking for examples

by StÃ©phane Ducasse

indeed the presentation is quite good and I like the tips section. Right now I started to collect coding examples (i.e. do not use , but nextPutAll:â¦.). Stef On Dec 25, 2011, at 3:26 AM, Damien Pollet wrote: > On 24 December 2011 14:53, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> If you have some suggestions with examples I could integrate to the chapter. > > HernÃ¡n had a good list in his talk on the design of patagonia: > http://www.slideshare.net/esug/design-principlesbehindpatagonia > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

Dec. 25, 2011

Re: [Pharo-project] Good practicces! Looking for examples

by Damien Pollet

On 24 December 2011 14:53, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > If you have some suggestions with examples I could integrate to the chapter. HernÃ¡n had a good list in his talk on the design of patagonia: http://www.slideshare.net/esug/design-principlesbehindpatagonia -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Dec. 25, 2011

Re: [Pharo-project] Good practicces! Looking for examples

by Schwab,Wilhelm K

Stef, My current working theory is that the command pattern is indeed good practice; it also has a way of exacting a price for the flexibility. Objects as functions are useful. I do a fair amount of that in gathering data from/about various algorithms. The objects can (by inheritance) share details of what to record (with overrides where needed) and then do their own thing on what/how to compute. Add a #subclassResponsibility method for the algorithm's name/label, and the result is fairly nice. FWIW, I sometimes ask myself why I "bothered" to use command (as I said, it is powerful and trouble all at the same time), but I don't recall regret over objects as functions. Find bug, write failing test, fix bug with help of new test, in that order; +10. Short methods - not always!! :) I am reminded of the first time I *enrolled* in a numerical analysis class. Details below for those who have nothing better to do. During that one lecture I attended, he said many things of interest. He talked about generic programming, using equations of lines (Ax+By=C always works, slope-intercept can become indeterminate). He didn't care what language we chose to use for exercises, because (without a hint of arrogance about it) "I will be able to READ (his emphasis) anything in common use." There was more (not bad for a first day of an undergraduate class). The relevant point was his description of structured programming as an alternative to goto instructions. But he said something that was a new thought to me at the time: the problem was not the goto, it was the label, which invites jumps from anywhere. My point? Short methods come at the cost of many little methods. Each of those "helper" methods is what Dr. X would see as a label. Think about it. Please do not suggest that we enforce private methods in Smalltalk, because the code still reads the same way, and all it really does is force people to copy methods or create forwarding methods to be able to call what they want, making more entry points - IMHO at least. I am *not* saying that we should have a minimum line length for methods, but there are indeed times when it helps to put an entire thought in one place. If it helps any, I usually encounter this in methods that fork processes. By the time the process gets a loop started, has an #ensure: block to clean up after itself, has a critical section or two, etc., it's not what one would call short, but IMHO, it is one "phrase" that is best seen as a whole. Bill So what's all this about enrolling for a class I didn't take? My undergraduate advisor was an interesting guy. One of the more colorful instructions he gave me was to try to get ahead of things by taking numerical analysis as taught by the computer science department; scheduling details meant that I would get the course almost a year earlier than would have otherwise been possible. One caveat: I had clear instructions that if (let's call him Dr. X) was assigned to teach it, leave immediately, drop the course and add (I forget what) in its place. You already know what happened: Dr. X walked in the room. Not wanting to walk out in the middle of his lecture, I stuck around. After about 20 minutes, I really wanted to take the class, which is why I tried to talk my advisor into letting me do so, but he was emphatic that Dr. X was a first class nut job (some US slang) and that I would end up being just one more bright student who would come back screaming - he had tried several times earlier, always with the same results. With that, I followed his instructions and took numerical analysis in turn. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Saturday, December 24, 2011 9:51 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Good practicces! Looking for examples On Dec 24, 2011, at 3:07 PM, Alexandre Bergel wrote: > Not sure what you mean with good coding practice, but here my contrib: > > - the command pattern (e.g., OB, Mondrian Easel, MonticelloBrowser) > - symbol polymorphic to block and other object-as-function Not sure that this is a good practices. I think that you like them because you use Smalltalk as a DSL. > - writing test before fixing code > - having short methods indeed Here is what I started to write.

Dec. 24, 2011

Re: [Pharo-project] Wrong number with message tally?

by Alexandre Bergel

Good point! It actually makes sense. But how comes that 36% is spent in the eventLoop method? In some situation, the InputEventPollingFetcher>>eventLoop can take up to 90% of the execution time. I guess this is essentially to answer to Cmd-. right? Cheers, Alexandre On 24 Dec 2011, at 13:18, Nicolas Cellier wrote: > I did not check code, but to me, the symptoms look like the other > processes are not reported but their are still counted in the > percentage. > You can compare the results of these two invocations: > > MessageTally spyOn: [1 to: 10000 do: [:i | Float pi storeString]]. > > - 386 tallies, 389 msec. > > **Tree** > -------------------------------- > Process: (40s) 328990720: nil > -------------------------------- > 61.4% {239ms} Float>>storeOn: > 61.4% {239ms} Float>>storeOn:base: > 61.4% {239ms} Float>>absPrintExactlyOn:base: > snip... > > MessageTally spyAllOn: [1 to: 10000 do: [:i | Float pi storeString]]. > > - 386 tallies, 388 msec. > > **Tree** > -------------------------------- > Process: other processes > -------------------------------- > -------------------------------- > Process: (40s) 328990720: nil > -------------------------------- > 58.5% {227ms} Float>>storeOn: > 58.5% {227ms} Float>>storeOn:base: > 57.5% {223ms} Float>>absPrintExactlyOn:base: > snip... > -------------------------------- > Process: (50) 240123904: WeakArray class>>finalizationProcess > -------------------------------- > 2.6% {10ms} WeakArray class>>finalizationProcess > -------------------------------- > Process: (60) Input events fetching process: [delaySemaphore wait] in > Delay>>wait > -------------------------------- > 36.3% {141ms} InputEventPollingFetcher(InputEventFetcher)>>eventLoop > 36.3% {141ms} InputEventPollingFetcher>>waitForInput > 36.3% {141ms} Delay>>wait > > > Strangely in Squeak, spyOn: often reports about the finalizationProcess > > - 381 tallies, 381 msec. > > **Tree** > -------------------------------- > Process: other processes > -------------------------------- > 7.6% {29ms} WeakArray class>>finalizationProcess > -------------------------------- > Process: (40s) 93165: nil > -------------------------------- > 86.4% {329ms} Float>>storeOn: > |86.4% {329ms} Float>>storeOn:base: > | 85.8% {327ms} Float>>absPrintExactlyOn:base: > | 41.5% {158ms} False>>| > snip... > > Nicolas > > 2011/12/24 Alexandre Bergel <alexandre.bergel(a)me.com>: >> I am not familiar with CUIS. But MessageTally is implemented in just one class. I commented it and some added tests a few months ago. >> >> In Visualworks, the root of the callgraph is always reported at 100%. >> >> I will continue to work on the Pharo version. >> >> Alexandre >> >> >> On 24 Dec 2011, at 11:52, StÃ©phane Ducasse wrote: >> >>> Alex >>> >>> normally I integrated the fixes of juan long time ago. Now could you have a look at CUIS to see if you get the same effect. >>> >>> Stef >>> >>> On Dec 24, 2011, at 3:29 PM, Alexandre Bergel wrote: >>> >>>>> This means that some other process (probably the finalization process, since #factorial creates a lot of garbage) was running and/or gc happened during the "missing" 34.2%. The gc times are listed below. >>>> >>>> I also thought about that. But I doubt this is the only reason. I tried: >>>> >>>> MessageTally spyOn: [ 100 timesRepeat: [XMLDOMParser parse: (FileStream fileNamed: 'path to an xml file') contents ]]. >>>> >>>> and I obtain >>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>> - 168 tallies, 168 msec. >>>> >>>> **Tree** >>>> -------------------------------- >>>> Process: (40s) 754188288: nil >>>> -------------------------------- >>>> 18.5% {31ms} XMLDOMParser>>parseDocument >>>> 18.5% {31ms} XMLDOMParser(SAXHandler)>>parseDocument >>>> 18.5% {31ms} XMLParser>>parseDocument >>>> 18.5% {31ms} XMLParser>>parseToken >>>> 18.5% {31ms} XMLTokenizer>>nextToken >>>> 16.1% {27ms} XMLTokenizer>>nextMarkupToken >>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>> >>>> The memory stat are >>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>> >>>> **Memory** >>>> old +120,524 bytes >>>> young -442,960 bytes >>>> used -322,436 bytes >>>> free +322,436 bytes >>>> >>>> **GCs** >>>> full 0 totalling 0ms (0.0% uptime) >>>> incr 12 totalling 5ms (3.0% uptime), avg 0.0ms >>>> tenures 2 (avg 6 GCs/tenure) >>>> root table 0 overflows >>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>> >>>> >>>> The factorial example consumes more memory, and it is reported to consume 72% >>>> >>>> Something is weird. I will look into it. >>>> >>>> Cheers, >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 24, 2011

Re: [Pharo-project] Good practicces! Looking for examples

by StÃ©phane Ducasse

On Dec 24, 2011, at 4:28 PM, Nicolas Cellier wrote: > Oh, but I didn't understand it was about optimization... > Good practice is to not optimize prematurely ;) Not only but I started to collect what I have > For example, inlining some message send, replacing explicit iteration > message by more obscure to:do: or whileTrue: loops etc... are not good > practices, just compromisesâ¦ Indeed :) I would like something more in the vein of Smalltalk by Example Stef > > Nicolas > > 2011/12/24 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> Bad practices and anti-pattern might be very instructive too... >> >> Nicolas >> >> 2011/12/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>> On Dec 24, 2011, at 3:07 PM, Alexandre Bergel wrote: >>> >>>> Not sure what you mean with good coding practice, but here my contrib: >>>> >>>> - the command pattern (e.g., OB, Mondrian Easel, MonticelloBrowser) >>>> - symbol polymorphic to block and other object-as-function >>> >>> Not sure that this is a good practices. I think that you like them because you use Smalltalk as a DSL. >>> >>>> - writing test before fixing code >>>> - having short methods >>> indeed >>> >>> Here is what I started to write. >>> >

Dec. 24, 2011