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

Re: [Pharo-project] Quickly getting the method call stack depth

by Alexandre Bergel

Indeed. Thanks! > This is more than twice as fast, though it may be still too slow for > your > needs: > > | depth running | > running := thisContext. > depth := 1. > [ (running := running instVarAt: 1) == nil ] > whileFalse: [ depth := depth + 1 ]. > depth [ 100000 timesRepeat: [ | depth running | running := thisContext. depth := 1. [ (running := running instVarAt: 1) == nil ] whileFalse: [ depth := depth + 1 ]. depth ] ] timeToRun => 321 [ 100000 timesRepeat: [| depth running | depth := 0. running := thisContext. [ running sender notNil ] whileTrue: [ running := running sender. depth := depth + 1]. depth] ] timeToRun => 942 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 3, 2010

Re: [Pharo-project] [squeak-dev] #ensure: issues (was: Re: Pharo by Example vol 2: new chapter available)

by StÃ©phane Ducasse

> Transcript is just a stream. #show: is just a combination of #nextPutAll: and #endEntry. #endEntry displays the contents of the stream and when that's done it removes everything from the stream with #resetContents. #resetContents is never executed, because the process is terminated before that. So the contents of the stream are kept and displayed again later. I should have looked in the code. Now what is fun is that I did not not get at least an intuition. Anyway I learned something valuable. *Thanks* levente Now what is strange is that we always get this behavior because it relies on the fact that resetContents is not executed so if the process would be suspended a bit later it would be ok. Am'I correct? I will start to write a couple of chapter on concurrent programming because this is the best way to exorcize your doubts. I imagine that I will probably write for newbies and will need some concurrent minded people to catch up what I will write. Stef

March 3, 2010

[Pharo-project] [update 1.1] #11243

by StÃ©phane Ducasse

11243 ----- - Issue 2102: Fix the fact that local temp can shadow silently instance var --- fixed Problem fixed: We cannot have twice the same block arg in a method [:each | each ...] [:each | each ...] THANKS jorge :) Do you like good bio beer? Stef

March 3, 2010

Re: [Pharo-project] Undo compiler temporary variable handling

by StÃ©phane Ducasse

youpi! I integrate it now then. Stef On Mar 3, 2010, at 8:00 PM, Jorge Ressia wrote: > Fixed in Compiler-JorgeRessia.142 > > The behavior should be the same as before removing the interactive validation. > > I recompiled the image and it worked fine. > > Lukas tried it out with some monticello test packages and worked too. > > Cheers, > > Jorge > > On Wed, Mar 3, 2010 at 6:34 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Yanni >> >> I imagine that you are right. >> Jorge I got problem with >> >> colorPaletteForDepth: depth extent: chartExtent >> >> I think that we should recompile the image. I should have thought about that. >> I could remove the last change for the moment. >> >> Stef >> >> On Mar 3, 2010, at 4:58 PM, Yanni Chiu wrote: >> >>> Jorge Ressia wrote: >>>> We tested it with Lukas and is working fine. However, we should see >>>> that there are no further side effects. >>> >>> I can't check right now, but I suspect it is the cause of this >>> side-effect - you cannot use the same block variable name in the same >>> method. E.g. >>> >>> foobar >>> collectionA do: [:each | each foo]. >>> collectionB do: [:each | each bar]. >>> >>> I get a syntax error on the second "each". Is this considered shadowing? >>> >>> -- >>> Yanni >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >>

March 3, 2010

[Pharo-project] SketchMorph removal

by StÃ©phane Ducasse

Hi I removed SketchMorph and adapted ImageMorph to be invoked instead. Now sketchMorph has ColorPickerMorph as a subclass so since I did not get the time to understand how we can substitute ColorChooserMorph here is what I did: I fileout sketchmoroh from another image, renamed it with emacs with a funky name and fileout ColorPickerMorph and made sure to use this new superclass. In the process I added some example in comment to ColorChooserMorph. Now it would be good if one of you could have a look at the slice I published in the inbox. alain yes we got rid of it :) http://code.google.com/p/pharo/issues/detail?id=2109 Stef

March 3, 2010

Re: [Pharo-project] Undo compiler temporary variable handling

by Jorge Ressia

Fixed in Compiler-JorgeRessia.142 The behavior should be the same as before removing the interactive validation. I recompiled the image and it worked fine. Lukas tried it out with some monticello test packages and worked too. Cheers, Jorge On Wed, Mar 3, 2010 at 6:34 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Yanni > > I imagine that you are right. > Jorge I got problem with > > Â Â Â Â colorPaletteForDepth: depth extent: chartExtent > > I think that we should recompile the image. I should have thought about that. > I could remove the last change for the moment. > > Stef > > On Mar 3, 2010, at 4:58 PM, Yanni Chiu wrote: > >> Jorge Ressia wrote: >>> We tested it with Lukas and is working fine. However, we should see >>> that there are no further side effects. >> >> I can't check right now, but I suspect it is the cause of this >> side-effect - you cannot use the same block variable name in the same >> method. E.g. >> >> foobar >> Â Â Â collectionA do: [:each | each foo]. >> Â Â Â collectionB do: [:each | each bar]. >> >> I get a syntax error on the second "each". Is this considered shadowing? >> >> -- >> Yanni >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

March 3, 2010

Re: [Pharo-project] Worth reading discussion on Smalltalk vs SmalltalkImage

by Nicolas Cellier

2010/3/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> 1) Rename Browser -> SystemBrowser >> 2) Rename SystemNavigation -> Browser >> 3) move SystemNavigation methods -> class side > > Why not > Â Â Â Â Navigator > Â Â Â Â Finder and we do not change all the existing books that always called Browser the tool > > Â Â Â Â Finder allCallOn: #new > Stef Yes, that works too. I don't fear the confusion of Browser the finder and SystemBrowser the tool : - because with all browse messages implemented in the finder, it can be viewed as the mean to access the tool - because advanced users wishing to program will just discover the subtle implementation difference by browsing But then, I don't care that much Nicolas >> >> Rationale: >> 1) that's what is written in window title, isn't it ? >> 2) Browser allCallsOn: and Browser browseAllCallsOn: are so neat ! >> 3) Is there any value in instance side, or is SystemNavigation just a factory ? >> >> Browser would not designate the tool, but the friendly compagnon used >> to browse and query. >> You can easily create a few compatibility hooks to SystemBrowser if required. >> >> Nicolas >> >>>> The important thing if this becomes the solution, is deciding what goes >>>> where, (in a consistent fashion across forks), >>> >>> I'm sure that we will be able to have something that is cross fork. I do not have the energy >>> to argue. >>> >>>> as well as the level of >>>> backwards-compatibility packages should be offered/deprecation methods >>>> kept in the image. >>> >>> _______________________________________________ >>> 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 >

March 3, 2010

[Pharo-project] [update 1.1] #11242

by StÃ©phane Ducasse

11242 ----- - Issue 2102: Fix the fact that local temp can shadow silently instance var --- reverted for now jorge I would appreciate a bit of your knowledge on this one :) Stef

March 3, 2010

Re: [Pharo-project] [update 1.1] #11241

by StÃ©phane Ducasse

I reverted the changes because you could get like me an error loading code :) Stef On Mar 3, 2010, at 6:48 PM, Adrian Lienhard wrote: > ok, I'll wait. > > Adrian > > On Mar 3, 2010, at 18:39 , StÃ©phane Ducasse wrote: > >> there is a problem do not integrate it. >> >> We cannot have twice the same block arg in a method >> >> [:each | each ...] >> [:each | each ...] >> >> I will revert the change in 11242 >> >> Stef >> >> On Mar 3, 2010, at 3:01 PM, Adrian Lienhard wrote: >> >>> Yes, I agree. I'll do it this evening. >>> >>> Adrian >>> >>> On Mar 3, 2010, at 14:32 , Lukas Renggli wrote: >>> >>>> Great! >>>> >>>> Adrian, is it possible to merge Issue 2102 into Pharo 1.0 too? I think >>>> it is important to have that fixed there too. >>>> >>>> Lukas >>>> >>>> >>>> On 3 March 2010 14:20, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>> 11241 >>>>> ----- >>>>> >>>>> - Issue 2102: Fix the fact that local temp can shadow silently instance var >>>>> - cleaning findChgSet >>>>> - fixing packageInfo typos overriden -> overridden >>>>> - Fix file = and added one test >>>>> >>>>> Stef >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> >>>> -- >>>> Lukas Renggli >>>> http://www.lukas-renggli.ch >>>> >>>> _______________________________________________ >>>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 3, 2010

Re: [Pharo-project] about code formatting in pharo

by StÃ©phane Ducasse

+ 1 And I know that you read kent patterns. We got all brainwashed with them.... I;m still hoping that his book will be out of print :) For now rebuying one for the team here since some guys messed up my nice and clean version. Stef > > On Mar 3, 2010, at 16:53 , Yanni Chiu wrote: > >> Isn't readability a matter of taste, or were experiments done? > > Indeed. As long as we don't carry out usability studies, we don't know what is better and we have to resort to personal taste. When I said "I don't like x" I also meant "I find it is less readable". Yanni gives a good argument below. > > In any case, I don't want to start an endless discussion about formatting, but I think it is interesting to get the different opinions to be able to come up with a formatter that works for as many people as possible. > > What we probably all agree on is that a common convention (or automatic formatter) for code in PharoCore would improve readability in comparison to the current situation in which we have all sorts of formatting. > > Cheers, > Adrian > >> >> IIRC, the arguments for productivity had to do with everyone just >> accepting one standard - not that one standard was "better" than >> another, just that there be *one* team standard (in the interest of >> productivity). >> >> I prefer the "hanging left bracket" because it allows the subsequent >> lines to have the same tabbing. That makes me faster, without requiring >> an automatic formatter. >> >> -- >> Yanni >> >> >> Chris Muller wrote: >>> Well, Kent makes a well-reasoned argument for Rectangular Block, >>> readability and productivity. "I don't like it" is just a statement >>> of someone's personal taste, a non-starter in terms of a useful >>> discussion about formatting. >>> >>> My goal is to make the system more productive and, by my experience, >>> that's what these formatting patterns accomplish. >>> >>> - Chris >>> >>> >>> On Wed, Mar 3, 2010 at 3:51 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >>>>> what do you mean by now used? >>>>> Did they change that recently? >>>> According to http://planetmisc.squeak.org/ >>>> a new package Compiler-cmm.131.mcz is now in Squeak inbox >>>> and may find its way into trunk ... >>>> >>>> >>>>> I don't like Beck's rule "3. Rectangular Block" >>>> vs. >>>>> So for me personally, Beck's rule 3 is the one that looks better. >>>> And there we have them: discussions on what looks better :) >>>> >>>> Bye >>>> T. >>>> -- >>>> Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - >>>> jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser >>>> >>>> _______________________________________________ >>>> 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

March 3, 2010