- Pharo-dev - lists.pharo.org

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

by Chris Muller

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 >

March 3, 2010

Re: [Pharo-project] Fwd: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk

by Henrik Johansen

I'd vote for b) too, should make it easier than a) in the future to move towards a separation of concerns like what was discussed. Personally, I think some of the voters might be a bit mislead by the points "compatible with Cuis" for a), and "different from Cuis" for b, listed in the initial post. Option b) is still _compatible_ with Cuis, only the _implementation_ is different. (ie code like Smalltalk vmParameterAt: xyz will work with both proposed solutions). Unless, of course, I'm the one misunderstanding :) Cheers, Henry Den 03.03.2010 15:02, skrev Nicolas Cellier: > Sorry to open a new thread, but here is my own position. > > Cheers > > Nicolas > > ---------- Forwarded message ---------- > From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Date: 2010/3/3 > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > To: The general-purpose Squeak developers list > <squeak-dev(a)lists.squeakfoundation.org> > > > 2010/3/3 Andreas Raab <andreas.raab(a)gmx.de>: > >> On 3/2/2010 10:14 PM, Michael Haupt wrote: >> >>> Hi, >>> >>> Am 03.03.2010 um 03:41 schrieb Andreas Raab <andreas.raab(a)gmx.de>: >>> >>>> Consequently I'm going to completely ignore any forward-looking >>>> proposals and simply state that the current count is 3 votes for the >>>> first variant (Phil, David, Bert) and 1 vote for the second variant >>>> (Igor). >>>> >>> here's another for "Smalltalk", then. >>> >> That choice doesn't exist :-) You can vote for: >> >> a) Smalltalk class == SystemDictionary, or >> >> b) Smalltalk class == SmalltalkImage >> >> Cheers, >> - Andreas >> >> >> > I vote for b). > > After discussing this with Stephane Ducasse, I quite agree on this scheme: > > SmalltalkImage should better be renamed System. > System soleInstance = Smalltalk. > Of course an optional bakward compatibility module would define > SmalltalkImage current > > Smalltalk globals or Smalltalk namespace class = SystemDictionary > Maybe SystemDictionary shouldbetter be renamed Namespace to separate > the notion of System. > > Then, if we are in need of separating methods, create new classes > SmalltalkVM etc... > But don't impose that in Kernel code, use methods indirections > (Smalltalk vm blah...) > > This is a bit harder path than a), but lot cleaner IMO > > Nicolas > > _______________________________________________ > 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] [squeak-dev] #ensure: issues (was: Re: Pharo by Example vol 2: new chapter available)

by Alexandre Bergel

Thanks Levente! Cheers, Alexandre On 3 Mar 2010, at 11:33, Levente Uzonyi wrote: > On Wed, 3 Mar 2010, StÃ©phane Ducasse wrote: > >> >> On Mar 2, 2010, at 10:33 PM, Levente Uzonyi wrote: >> >>> On Tue, 2 Mar 2010, Henrik Sperre Johansen wrote: >>> >>>> >>>>>> PS. For the not-so-faint-of-heart, open a Transcript and try >>>>>> evaluating: >>>>>> |proc| >>>>>> proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show: >>>>>> 'Finish!' Processor yield.]] newProcess. >>>>>> proc resume. >>>>>> Processor yield. >>>>>> proc suspend. >>>>>> proc terminate. >>>>> Why don't we get it printing? >>>> Forgot a . there, supposed to be >>>> >>>> |proc| >>>> proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show: >>>> 'Finish!'. Processor yield.]] newProcess. >>>> proc resume. >>>> Processor yield. >>>> proc suspend. >>>> proc terminate. >>>> >>>> on my machine it prints: >>>> *Start!Start!Finish! >>> >>> The problem occurs because Transcript >> #endEntry (sent from >>> #show:) >>> takes a while to execute, so the process (proc) prints 'Start!', but >>> it gets terminated before execution reaches #resetContents (#reset >>> in >>> Squeak). So 'Start!' is still in the stream. Then our process >>> executes the >>> #ensure: block and it prints 'Start!' and 'Finish!' too. >> >> >> Thanks for the explanation levente! >> But I'm still dizzy :) why Transcript show: 'Finish' would also >> print 'start' ? > > 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. > > > Levente > >> >>> >>> There's worse problem with #ensure: and #terminate is that, a >>> process executing an #ensure: block can be terminated. If you >>> evaluate this code: >>> >>> | process stage1 stage2 stage3 counter | >>> stage1 := stage2 := stage3 := false. >>> counter := 0. >>> process := [ >>> [ stage1 := true ] ensure: [ >>> stage2 := true. >>> 1000000 timesRepeat: [ counter := counter + 1 ]. >>> stage3 := true ] ] newProcess. >>> process resume. >>> Processor yield. >>> process suspend. >>> process terminate. >>> 1000 milliSeconds asDelay wait. >>> { stage1. stage2. stage3. counter } explore >>> >>> you will find that stage1 and stage2 is reached as expected, but >>> stage3 is not and counter is less than 1000000. That's because the >>> forked process started evaluating the #ensure: block, but it was >>> terminated by our process. >>> >>> Is this the expected behavior when sending #terminate to a process >>> which is evaluating an #ensure: block? >>> >>> >>> Cheers, >>> BalÃ¡zs & Levente >>> >>> >>>> >>>> *yay >>>> Henry* >>>> * >>> >> >> >> _______________________________________________ >> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 3, 2010

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

by Levente Uzonyi

On Wed, 3 Mar 2010, StÃ©phane Ducasse wrote: > > On Mar 2, 2010, at 10:33 PM, Levente Uzonyi wrote: > >> On Tue, 2 Mar 2010, Henrik Sperre Johansen wrote: >> >>> >>>>> PS. For the not-so-faint-of-heart, open a Transcript and try evaluating: >>>>> |proc| >>>>> proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show: >>>>> 'Finish!' Processor yield.]] newProcess. >>>>> proc resume. >>>>> Processor yield. >>>>> proc suspend. >>>>> proc terminate. >>>> Why don't we get it printing? >>> Forgot a . there, supposed to be >>> >>> |proc| >>> proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show: >>> 'Finish!'. Processor yield.]] newProcess. >>> proc resume. >>> Processor yield. >>> proc suspend. >>> proc terminate. >>> >>> on my machine it prints: >>> *Start!Start!Finish! >> >> The problem occurs because Transcript >> #endEntry (sent from #show:) >> takes a while to execute, so the process (proc) prints 'Start!', but >> it gets terminated before execution reaches #resetContents (#reset in >> Squeak). So 'Start!' is still in the stream. Then our process executes the >> #ensure: block and it prints 'Start!' and 'Finish!' too. > > > Thanks for the explanation levente! > But I'm still dizzy :) why Transcript show: 'Finish' would also print 'start' ? 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. Levente > >> >> There's worse problem with #ensure: and #terminate is that, a process executing an #ensure: block can be terminated. If you evaluate this code: >> >> | process stage1 stage2 stage3 counter | >> stage1 := stage2 := stage3 := false. >> counter := 0. >> process := [ >> [ stage1 := true ] ensure: [ >> stage2 := true. >> 1000000 timesRepeat: [ counter := counter + 1 ]. >> stage3 := true ] ] newProcess. >> process resume. >> Processor yield. >> process suspend. >> process terminate. >> 1000 milliSeconds asDelay wait. >> { stage1. stage2. stage3. counter } explore >> >> you will find that stage1 and stage2 is reached as expected, but stage3 is not and counter is less than 1000000. That's because the forked process started evaluating the #ensure: block, but it was terminated by our process. >> >> Is this the expected behavior when sending #terminate to a process which is evaluating an #ensure: block? >> >> >> Cheers, >> BalÃ¡zs & Levente >> >> >>> >>> *yay >>> Henry* >>> * >> > > > _______________________________________________ > 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 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2010/3/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> On Mar 3, 2010, at 1:28 PM, Henrik Johansen wrote: >> >>> >>> >>> Den 03.03.2010 10:36, skrev StÃ©phane Ducasse: >>>> Browser vs SystemNavigation and much more such as abstraction (traits kind of mistakes) for the sake of it. >>>> >>>> I was thinking that I would love to have a message-oriented solution. >>>> One of these days 1.2 we will have to clean Smalltalk, SmalltalkImage current. >>>> The mail is long but worth to get some ideas that you may like or not. >>>> >>>> Stef >>>> >>> I have to say I support what to me seemed like the general consensus on >>> this, that the separation just didn't go far enough to make it worth it :) >>> I especially like the >>> Smalltalk vm parameterAt: >>> Smalltalk query allCallsOn: >>> etc. >>> protocol, sure you add a globals category to SystemDictionary, but to me >>> the resulting code looks much better than both the current state of >>> SmalltalkImage vmParameterAt: and SystemNavigation current allCallsOn: >>> (or were those class methods?), and the old where SystemDictionary was a >>> complete mess. >> >> I agree with part of it (see my next/previous mail :) >> >> even if for SystemNavigation I do not really like Smalltalk query ccalll.... >> > > My own position is this one: > > 1) Rename Browser -> SystemBrowser > 2) Rename SystemNavigation -> Browser > 3) move SystemNavigation methods -> class side > > 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 > Of course, unless SystemNavigation become a statefull object remembering navigation paths, caching frequent requests etc... In which case, it wouldcease to be a factory. >>> 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 >> >

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>: > > On Mar 3, 2010, at 1:28 PM, Henrik Johansen wrote: > >> >> >> Den 03.03.2010 10:36, skrev StÃ©phane Ducasse: >>> Browser vs SystemNavigation and much more such as abstraction (traits kind of mistakes) for the sake of it. >>> >>> I was thinking that I would love to have a message-oriented solution. >>> One of these days 1.2 we will have to clean Smalltalk, SmalltalkImage current. >>> The mail is long but worth to get some ideas that you may like or not. >>> >>> Stef >>> >> I have to say I support what to me seemed like the general consensus on >> this, that the separation just didn't go far enough to make it worth it :) >> I especially like the >> Smalltalk vm parameterAt: >> Smalltalk query allCallsOn: >> etc. >> protocol, sure you add a globals category to SystemDictionary, but to me >> the resulting code looks much better than both the current state of >> SmalltalkImage vmParameterAt: and SystemNavigation current allCallsOn: >> (or were those class methods?), and the old where SystemDictionary was a >> complete mess. > > I agree with part of it (see my next/previous mail :) > > even if for SystemNavigation I do not really like Smalltalk query ccalll.... > My own position is this one: 1) Rename Browser -> SystemBrowser 2) Rename SystemNavigation -> Browser 3) move SystemNavigation methods -> class side 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 >

March 3, 2010

[Pharo-project] Status of Loader?

by Schwab,Wilhelm K

Hello all, What is the current status of Loader? Bill

March 3, 2010

[Pharo-project] Fwd: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk

by Nicolas Cellier

Sorry to open a new thread, but here is my own position. Cheers Nicolas ---------- Forwarded message ---------- From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> Date: 2010/3/3 Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> 2010/3/3 Andreas Raab <andreas.raab(a)gmx.de>: > On 3/2/2010 10:14 PM, Michael Haupt wrote: >> >> Hi, >> >> Am 03.03.2010 um 03:41 schrieb Andreas Raab <andreas.raab(a)gmx.de>: >>> >>> Consequently I'm going to completely ignore any forward-looking >>> proposals and simply state that the current count is 3 votes for the >>> first variant (Phil, David, Bert) and 1 vote for the second variant >>> (Igor). >> >> here's another for "Smalltalk", then. > > That choice doesn't exist :-) You can vote for: > > a) Smalltalk class == SystemDictionary, or > > b) Smalltalk class == SmalltalkImage > > Cheers, > Â - Andreas > > I vote for b). After discussing this with Stephane Ducasse, I quite agree on this scheme: SmalltalkImage should better be renamed System. System soleInstance = Smalltalk. Of course an optional bakward compatibility module would define SmalltalkImage current Smalltalk globals or Smalltalk namespace class = SystemDictionary Maybe SystemDictionary shouldbetter be renamed Namespace to separate the notion of System. Then, if we are in need of separating methods, create new classes SmalltalkVM etc... But don't impose that in Kernel code, use methods indirections (Smalltalk vm blah...) This is a bit harder path than a), but lot cleaner IMO Nicolas

March 3, 2010

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

by Adrian Lienhard

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

March 3, 2010

Re: [Pharo-project] Polymorph fixes

by Richard Durr

Cool. I dislike the Watery2 look a little bit, because it seems to me so close but not really matching the MacÂ OSÂ X Aqua design. On Tue, Mar 2, 2010 at 2:15 AM, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: > Yes, Hilaire is doing a theme to match the XO UI specs... some good will > come from this for Polymorph generally, in terms of extending the > "Widget set"... date pickers etc... > > On Mon, 2010-03-01 at 23:20 +0100, Richard Durr wrote: >> What's the Sugar theme? For the XO-Laptop? >> >> On Mon, Mar 1, 2010 at 8:34 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >> > Thanks. >> > I will give a try but may be we have a bug in scriptLoader :) >> > >> > Stef >> > On Mar 1, 2010, at 6:52 PM, Gary Chambers wrote: >> > >> >> A few fixes on SqueakSource. >> >> >> >> Polymorph-Widgets-gvc.24 >> >> Polymorph-Tools-Diff-gvc.24 >> >> >> >> Notably: >> >> >> >> Table layout of submorphs with #shrinkWrap attributes. >> >> Themeing of menu item text colours to help Hilaire in his Sugar theme efforts. ThemeSettings integration left for another time... >> >> Wrong "sides" for "compare to current" when using diff tools in change sets (versions browser etc.). >> >> Prevention of window dragging from submorphs promoted from StandardWindow to SystemWindow (deals with oddities when click-dragging from submorphs... offset would be wrong and window "jumps"). >> >> Wrong colours for faded background windows in Watery themes. >> >> Fix colours in W2K theme (requires class-side reinitialisation of defaultSettings. Do "UIThemeW2K defaultSettings: nil" before changing theme). >> >> Toolbars now Panel-based to adapt to pane colour. >> >> DockingBar based menus now deal with mouseFocus correctly. >> >> >> >> >> >> Regards, Gary >> >> _______________________________________________ >> >> 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