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

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

by Igor Stasenko

On 28 February 2010 12:44, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > But, if there is only single block, i usually typing: > > self bla ifTrue: [ > Â code. > Â code. > Â ] > > Yes I see > I would prefer > > self bla ifTrue: [ > Â code. > Â code. ] > > > for me I try > >> self bla ifTrue: [ code ]. > yes, one-liner is ok, but only if its short. The most disguising thing in formatting an exception handling code: runTest: aSelector | actualResult expectedResult | [ self logTest: aSelector; clearLog; perform: aSelector ] on: MyTestError do: [ :ex | self log: 'Unhandled Exception'. ex return: nil ]. as you can see, its a bit hard to quickly determine, where ends one block and starts another one. That's why i'm always putting ' ] ' at the next line, and align its indentation to be the same as in opening brace: [ self logTest: aSelector; clearLog; perform: aSelector ] on: MyTestError do: [ :ex | self log: 'Unhandled Exception'. ex return: nil ]. do you agree that this one is much more readable? > > or > self bla > Â Â Â Â ifTrue: [ code. > Â Â Â Â Â Â Â Â Â code.] > > but I'm not happy because tabbing does not work to align the last line. > So any ideas. I have to reread the kent book. > > Stef > >> also i'm usually putting closing ' ] ' at new line, but indented >> relatively to receiver, not like: >> >> >> self bla ifTrue: [ >> Â Â code. >> Â Â code. ] >> >> >> Also, if statement ends with ']' , i adding a blank like at the end: >> >> >> self bla ifTrue: [ >> Â Â code. >> Â ]. >> >> self bla ifTrue: [ >> Â Â code. >> Â ]. >> >> >>> >>>> I would use a formatter, like this you can make it really consistent. >>>> The RBConfigurableFormatter is pretty good in that, the only thing I >>>> don't like is the placing of the square brackets. I should look into >>>> fixing that, otherwise it formats exactly the way I would format >>>> myself (and in the way you propose). >>> >>> I would really like to play with the idea of automatic formatting >>> to see how it goes. >>> >>> Stef >>> >>>> >>>> Lukas >>>> >>>> On 28 February 2010 10:36, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >>>>> Hi guys >>>>> >>>>> I would like to build a set of canonical code formatting convention for Pharo. >>>>> I need your help. Now take time before replying :) >>>>> I would like to structure the discussion and proceed step by step. So at max I would like to discuss one or two formatting approach per mail. >>>>> Once we agree I would like to define a wiki page. >>>>> >>>>> >>>>> **Space after : rule >>>>> ============= >>>>> for example I would like to always have a space after a : >>>>> >>>>> classes := Smalltalk allClasses select:[:aClass| >>>>> Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) >>>>> Â Â Â Â Â Â Â Â Â Â Â or:[aClass class includesSelector: #cleanUp:] >>>>> Â Â Â ]. >>>>> >>>>> -> >>>>> >>>>> >>>>> classes := Smalltalk allClasses select: [:aClass| >>>>> Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) >>>>> Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:] >>>>> Â Â Â ]. >>>>> >>>>> >>>>> **Block arg rule >>>>> ============= >>>>> Do we want a space before and after block arg >>>>> >>>>> Smalltalk allClasses select: [:aClass :method| >>>>> >>>>> -> Smalltalk allClasses select: [ :aClass :method | >>>>> >>>>> >>>>> ** selector or block indented compared to receiver >>>>> ======================================= >>>>> >>>>> Finally do we follow kent block ideas? >>>>> >>>>> classes := Smalltalk allClasses select: [:aClass| >>>>> Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) >>>>> Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:] >>>>> Â Â Â ]. >>>>> >>>>> -> >>>>> classes := Smalltalk allClasses >>>>> Â Â Â Â Â Â Â Â Â Â Â Â select: [:aClass| (aClass class includesSelector: #cleanUp) >>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:]]. >>>>> >>>>> 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 >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Feb. 28, 2010

Re: [Pharo-project] Streams. Status and where to go?

by Igor Stasenko

On 28 February 2010 12:45, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2010/2/28 Igor Stasenko <siguctua(a)gmail.com>: >> On 28 February 2010 12:00, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> 2010/2/28 Igor Stasenko <siguctua(a)gmail.com>: >>>> Hi, i'm also did some hacking. I uploaded XTream-Wrappers-sig.1 into SqS/XTream. >>>> >>>> There is a basic XtreamWrapper class, which should work transparently >>>> for any stream (hopefully ;). >>>> Next, in subclass i created converter. Sure thing i could also add a >>>> buffered wrapper, but maybe later :) >>>> >>>> Here some benchmarks. The file i used to test is utf-8 russian doc >>>> text - in attachment.. >>>> >>>> | str | >>>> str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream. >>>> { >>>> [ str reset. (XtreamUTF8Converter on: str readXtream) upToEnd ] bench. >>>> [ str reset. (UTF8Decoder new source: str readXtream) upToEnd ] bench. >>>> } >>>> #('21.71314741035857 per second.' '14.0371688414393 per second.') >>>> Â #('22.16896345116836 per second.' '14.5186953062848 per second.') >>>> >>>> Next, buffered >>>> >>>> | str | >>>> str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream. >>>> { >>>> [ str reset. (XtreamUTF8Converter on: str readXtream buffered) upToEnd ] bench. >>>> [ str reset. (UTF8Decoder new source: str readXtream buffered) upToEnd ] bench. >>>> } >>>> #('58.52976428286057 per second.' '25.44225800039754 per second.') >>>> #('58.90575079872205 per second.' '25.87064676616916 per second.') >>>> >>>> >>>> I'm also tried double-buffering, but neither my class nor yours >>>> currently works with it: >>>> >>>> | str | >>>> str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream. >>>> { >>>> [ str reset. (XtreamUTF8Converter on: str readXtream buffered) >>>> buffered upToEnd ] bench. >>>> [ str reset. (UTF8Decoder new source: str readXtream buffered) >>>> buffered upToEnd ] bench. >>>> } >>>> >>>> Please , take a look. There are some quirks which not because i >>>> cleaned up decoding/encoding code. >>>> See XtreamWrapper>>upToEnd implementation. >>>> >>>> >>> >>> Yes I published a bit soon and messed up because one temp from text >>> converter method (source) had same name as CharacterDecoder inst var >>> :( >>> Find a second attempt: >>> >>> | str | >>> str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream binary. >>> { >>> [ str reset. (XtreamUTF8Converter on: str readXtream buffered) >>> buffered upToEnd ] bench. >>> [ str reset. (UTF8Decoder new source: str readXtream buffered) >>> buffered upToEnd ] bench. >>> } >>> #('118.0347513481126 per second.' '31.38117129722167 per second.') >>> >>> >>> As you can see, the optimistic ASCII version is pessimistic in case of >>> non ASCII... >>> It creates a composite stream and perform a lot of copys... >>> This is known and waiting better algorithm :) >>> >> >> whoops.. you got more than 3x speedup, while mine was around 2x. >> But please, try on ascii files. >> >> Â | str | >> Â str := (String new: 1000 withAll: $a) asByteArray. >> Â { >> Â [ (XtreamUTF8Converter on: str readXtream binary) Â upToEnd ] bench. >> Â [ (UTF8Decoder new source: str readXtream binary) Â upToEnd ] bench. >> Â [ str readXtream binary upToEnd ] bench. >> Â } >> Â #('2039.392121575685 per second.' '1158.568286342731 per second.' >> '92143.1713657269 per second.') >> >> so, conversion is 90..45 times slower than just copying data :) >> We need to tighten up this gap. >> One would be to optimize #readInto:startingAt:count: using batch-mode >> conversion. >> > > Igor, you also got a problem: > > | str | > str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream binary. > (XtreamUTF8Converter on: str readXtream) upToEnd = (StandardFileStream > readOnlyFileNamed: 'unitext.txt') contents utf8ToSqueak > -> false > > unless it's utf8ToSqueak and leadingChar stuff... > yes, this is because of wrong quirk in XtreamWrapper>>upToEnd i also tried to replace #next: by #nextAvailable: but it still not working right - returns 8192 characters (4 fully read buffers), but missing the tail, when buffer is underflow due to meeting end of file. By reverting this method back to same as in ReadXtream it works correctly, but apparently will be slower: (XtreamUTF8Converter on: (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream binary) contents size 10153 (StandardFileStream readOnlyFileNamed: 'unitext.txt') contents utf8ToSqueak size 10153 Please see what can be done in this regard. P.S. tried to bench it without my quirk.. heh, not so slower.... | str | str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream binary. { [ str reset. (XtreamUTF8Converter on: str readXtream buffered) upToEnd ] bench. [ str reset. (UTF8Decoder new source: str readXtream buffered) upToEnd ] bench. } #('66.653362602275 per second.' '27.16197323746755 per second.') >>> Nicolas >>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Feb. 28, 2010

[Pharo-project] [update 1.1] #11239

by stephane ducasse

11239 ----- - Issue 2026: RecentMessageSet fixes. Tx Pavel :) - Issue 2066: Conversions from/to hex representations in ByteArray (from squeak). Now we can read and print ByteArray in hex with upper and lower case. Stef well a final one (yes noury we arrive now).

Feb. 28, 2010

Re: [Pharo-project] Streams. Status and where to go?

by Nicolas Cellier

2010/2/28 Igor Stasenko <siguctua(a)gmail.com>: > On 28 February 2010 12:00, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> 2010/2/28 Igor Stasenko <siguctua(a)gmail.com>: >>> Hi, i'm also did some hacking. I uploaded XTream-Wrappers-sig.1 into SqS/XTream. >>> >>> There is a basic XtreamWrapper class, which should work transparently >>> for any stream (hopefully ;). >>> Next, in subclass i created converter. Sure thing i could also add a >>> buffered wrapper, but maybe later :) >>> >>> Here some benchmarks. The file i used to test is utf-8 russian doc >>> text - in attachment.. >>> >>> | str | >>> str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream. >>> { >>> [ str reset. (XtreamUTF8Converter on: str readXtream) upToEnd ] bench. >>> [ str reset. (UTF8Decoder new source: str readXtream) upToEnd ] bench. >>> } >>> #('21.71314741035857 per second.' '14.0371688414393 per second.') >>> Â #('22.16896345116836 per second.' '14.5186953062848 per second.') >>> >>> Next, buffered >>> >>> | str | >>> str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream. >>> { >>> [ str reset. (XtreamUTF8Converter on: str readXtream buffered) upToEnd ] bench. >>> [ str reset. (UTF8Decoder new source: str readXtream buffered) upToEnd ] bench. >>> } >>> #('58.52976428286057 per second.' '25.44225800039754 per second.') >>> #('58.90575079872205 per second.' '25.87064676616916 per second.') >>> >>> >>> I'm also tried double-buffering, but neither my class nor yours >>> currently works with it: >>> >>> | str | >>> str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream. >>> { >>> [ str reset. (XtreamUTF8Converter on: str readXtream buffered) >>> buffered upToEnd ] bench. >>> [ str reset. (UTF8Decoder new source: str readXtream buffered) >>> buffered upToEnd ] bench. >>> } >>> >>> Please , take a look. There are some quirks which not because i >>> cleaned up decoding/encoding code. >>> See XtreamWrapper>>upToEnd implementation. >>> >>> >> >> Yes I published a bit soon and messed up because one temp from text >> converter method (source) had same name as CharacterDecoder inst var >> :( >> Find a second attempt: >> >> | str | >> str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream binary. >> { >> [ str reset. (XtreamUTF8Converter on: str readXtream buffered) >> buffered upToEnd ] bench. >> [ str reset. (UTF8Decoder new source: str readXtream buffered) >> buffered upToEnd ] bench. >> } >> #('118.0347513481126 per second.' '31.38117129722167 per second.') >> >> >> As you can see, the optimistic ASCII version is pessimistic in case of >> non ASCII... >> It creates a composite stream and perform a lot of copys... >> This is known and waiting better algorithm :) >> > > whoops.. you got more than 3x speedup, while mine was around 2x. > But please, try on ascii files. > > Â | str | > Â str := (String new: 1000 withAll: $a) asByteArray. > Â { > Â [ (XtreamUTF8Converter on: str readXtream binary) Â upToEnd ] bench. > Â [ (UTF8Decoder new source: str readXtream binary) Â upToEnd ] bench. > Â [ str readXtream binary upToEnd ] bench. > Â } > Â #('2039.392121575685 per second.' '1158.568286342731 per second.' > '92143.1713657269 per second.') > > so, conversion is 90..45 times slower than just copying data :) > We need to tighten up this gap. > One would be to optimize #readInto:startingAt:count: using batch-mode > conversion. > Igor, you also got a problem: | str | str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream binary. (XtreamUTF8Converter on: str readXtream) upToEnd = (StandardFileStream readOnlyFileNamed: 'unitext.txt') contents utf8ToSqueak -> false unless it's utf8ToSqueak and leadingChar stuff... >> Nicolas >> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 28, 2010

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

by StÃ©phane Ducasse

But, if there is only single block, i usually typing: self bla ifTrue: [ code. code. ] Yes I see I would prefer self bla ifTrue: [ code. code. ] for me I try > self bla ifTrue: [ code ]. or self bla ifTrue: [ code. code.] but I'm not happy because tabbing does not work to align the last line. So any ideas. I have to reread the kent book. Stef > also i'm usually putting closing ' ] ' at new line, but indented > relatively to receiver, not like: > > > self bla ifTrue: [ > code. > code. ] > > > Also, if statement ends with ']' , i adding a blank like at the end: > > > self bla ifTrue: [ > code. > ]. > > self bla ifTrue: [ > code. > ]. > > >> >>> I would use a formatter, like this you can make it really consistent. >>> The RBConfigurableFormatter is pretty good in that, the only thing I >>> don't like is the placing of the square brackets. I should look into >>> fixing that, otherwise it formats exactly the way I would format >>> myself (and in the way you propose). >> >> I would really like to play with the idea of automatic formatting >> to see how it goes. >> >> Stef >> >>> >>> Lukas >>> >>> On 28 February 2010 10:36, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >>>> Hi guys >>>> >>>> I would like to build a set of canonical code formatting convention for Pharo. >>>> I need your help. Now take time before replying :) >>>> I would like to structure the discussion and proceed step by step. So at max I would like to discuss one or two formatting approach per mail. >>>> Once we agree I would like to define a wiki page. >>>> >>>> >>>> **Space after : rule >>>> ============= >>>> for example I would like to always have a space after a : >>>> >>>> classes := Smalltalk allClasses select:[:aClass| >>>> (aClass class includesSelector: #cleanUp) >>>> or:[aClass class includesSelector: #cleanUp:] >>>> ]. >>>> >>>> -> >>>> >>>> >>>> classes := Smalltalk allClasses select: [:aClass| >>>> (aClass class includesSelector: #cleanUp) >>>> or: [aClass class includesSelector: #cleanUp:] >>>> ]. >>>> >>>> >>>> **Block arg rule >>>> ============= >>>> Do we want a space before and after block arg >>>> >>>> Smalltalk allClasses select: [:aClass :method| >>>> >>>> -> Smalltalk allClasses select: [ :aClass :method | >>>> >>>> >>>> ** selector or block indented compared to receiver >>>> ======================================= >>>> >>>> Finally do we follow kent block ideas? >>>> >>>> classes := Smalltalk allClasses select: [:aClass| >>>> (aClass class includesSelector: #cleanUp) >>>> or: [aClass class includesSelector: #cleanUp:] >>>> ]. >>>> >>>> -> >>>> classes := Smalltalk allClasses >>>> select: [:aClass| (aClass class includesSelector: #cleanUp) >>>> or: [aClass class includesSelector: #cleanUp:]]. >>>> >>>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 28, 2010

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

by StÃ©phane Ducasse

Looks good to me If one day we get a cooler one we could get > > self class isVariable & anotherObject class isVariable > ifTrue: > [ 1 to: (self basicSize min: anotherObject basicSize) do: [ :ind | > self basicAt: ind put: (anotherObject basicAt: ind) ] ] > self class isVariable & anotherObject class isVariable ifTrue: [ 1 to: (self basicSize min: anotherObject basicSize) do: [ :ind | self basicAt: ind put: (anotherObject basicAt: ind) ] ] self class isVariable & anotherObject class isVariable ifTrue: [ 1 to: (self basicSize min: anotherObject basicSize) do: [ :ind | self basicAt: ind put: (anotherObject basicAt: ind) ] ] > Object>>longPrintStringLimitedTo: aLimitValue > "Answer a String whose characters are a description of the receiver." > > | str | > str := String > streamContents: > [ :aStream | > self > longPrintOn: aStream > limitedTo: aLimitValue > indent: 0 ]. "Objects without inst vars should return something" > ^ str isEmpty > ifTrue: [ self printString , String cr ] > ifFalse: [ str ] > > I would love to have it like that ;-D Object>>longPrintStringLimitedTo: aLimitValue "Answer a String whose characters are a description of the receiver." | str | str := String streamContents: [ :aStream | self longPrintOn: aStream limitedTo: aLimitValue indent: 0 ]. "Objects without inst vars should return something" ^ str isEmpty ifTrue: [ self printString , String cr ] ifFalse: [ str ]

Feb. 28, 2010

[Pharo-project] How to manage oos dev

by StÃ©phane Ducasse

http://video.google.com/videoplay?docid=-4216011961522818645# The subtitle is misleading How Open Source Projects Survive Poisonous People (And You Can Too) I think that we can learn from them :) The video is much more that about Poisonous people. A lot of interested advices - having vision making sure that people understand it - what are the values of the project - communications (use mails to communicate often) - commit often little code instead of a large chunk - bus factors (encourage people to share they knowledge so cool) - people marking their packages and not letting other sharing. - I like the consensus they promote. - a good one for me :) don't let the emotion drain you :) I can tell you that I'm learning :))))) Stef

Feb. 28, 2010

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

by Igor Stasenko

On 28 February 2010 11:58, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Lukas do you have some code samples. > Something that I particularly hate is the following > > Â Â Â Â self bla ifTrue: [ > Â Â Â Â Â Â Â Â ... > > Â Â Â Â ] ifFalse: [ > Â Â Â Â Â Â Â Â ... > Â Â Â Â ] > > That is see in the code. > > I want > Â Â Â Â self bla > Â Â Â Â Â Â Â Â ifTrue: [ ... > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ] > Â Â Â Â Â Â Â Â ifFalse: [ > Â Â Â Â Â Â Â Â Â Â Â Â ... Â Â Â Â Â Â ] > > +1 But, if there is only single block, i usually typing: self bla ifTrue: [ code. code. ] also i'm usually putting closing ' ] ' at new line, but indented relatively to receiver, not like: self bla ifTrue: [ code. code. ] Also, if statement ends with ']' , i adding a blank like at the end: self bla ifTrue: [ code. ]. self bla ifTrue: [ code. ]. > >> I would use a formatter, like this you can make it really consistent. >> The RBConfigurableFormatter is pretty good in that, the only thing I >> don't like is the placing of the square brackets. I should look into >> fixing that, otherwise it formats exactly the way I would format >> myself (and in the way you propose). > > I would really like to play with the idea of automatic formatting > to see how it goes. > > Stef > >> >> Lukas >> >> On 28 February 2010 10:36, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >>> Hi guys >>> >>> I would like to build a set of canonical code formatting convention for Pharo. >>> I need your help. Now take time before replying :) >>> I would like to structure the discussion and proceed step by step. So at max I would like to discuss one or two formatting approach per mail. >>> Once we agree I would like to define a wiki page. >>> >>> >>> **Space after : rule >>> ============= >>> for example I would like to always have a space after a : >>> >>> classes := Smalltalk allClasses select:[:aClass| >>> Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) >>> Â Â Â Â Â Â Â Â Â Â Â or:[aClass class includesSelector: #cleanUp:] >>> Â Â Â ]. >>> >>> -> >>> >>> >>> classes := Smalltalk allClasses select: [:aClass| >>> Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) >>> Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:] >>> Â Â Â ]. >>> >>> >>> **Block arg rule >>> ============= >>> Do we want a space before and after block arg >>> >>> Smalltalk allClasses select: [:aClass :method| >>> >>> -> Smalltalk allClasses select: [ :aClass :method | >>> >>> >>> ** selector or block indented compared to receiver >>> ======================================= >>> >>> Finally do we follow kent block ideas? >>> >>> classes := Smalltalk allClasses select: [:aClass| >>> Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) >>> Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:] >>> Â Â Â ]. >>> >>> -> >>> classes := Smalltalk allClasses >>> Â Â Â Â Â Â Â Â Â Â Â Â select: [:aClass| (aClass class includesSelector: #cleanUp) >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:]]. >>> >>> 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 > -- Best regards, Igor Stasenko AKA sig.

Feb. 28, 2010

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

by Lukas Renggli

A few examples: Object>>perform: selector orSendTo: otherTarget "If I wish to intercept and handle selector myself, do it; else send it to otherTarget" ^ (self respondsTo: selector) ifTrue: [ self perform: selector ] ifFalse: [ otherTarget perform: selector ] Object>>doesNotUnderstand: aMessage "Handle the fact that there was an attempt to send the given message to the receiver but the receiver does not understand this message (typically sent from the machine when a message is sent to the receiver and no method is defined for that selector)." "Testing: (3 activeProcess)" "fixed suggested by Eliot miranda to make sure [Object new blah + 1] Â on: MessageNotUnderstood Â do: [:e | e resume: 1] does not loop indefinitively" | exception resumeValue | (exception := MessageNotUnderstood new) message: aMessage; receiver: self. resumeValue := exception signal. ^ exception reachedDefaultHandler ifTrue: [ aMessage sentTo: self ] ifFalse: [ resumeValue ] Below is an example that shows the placement of block brackets with multiline blocks. I would like to change that so that the brackets are placed on the line above (that's in my opinion the only major flaw in the automatic formatting), unfortunately I haven't found the time to do this: Object>>copyFrom: anotherObject "Copy to myself all instance variables I have in common with anotherObject. This is dangerous because it ignores an object's control over its own inst vars. " <primitive: 168> | mine his | mine := self class allInstVarNames. his := anotherObject class allInstVarNames. 1 to: (mine size min: his size) do: [ :ind | (mine at: ind) = (his at: ind) ifTrue: [ self instVarAt: ind put: (anotherObject instVarAt: ind) ] ]. self class isVariable & anotherObject class isVariable ifTrue: [ 1 to: (self basicSize min: anotherObject basicSize) do: [ :ind | self basicAt: ind put: (anotherObject basicAt: ind) ] ] Object>>longPrintStringLimitedTo: aLimitValue "Answer a String whose characters are a description of the receiver." | str | str := String streamContents: [ :aStream | self longPrintOn: aStream limitedTo: aLimitValue indent: 0 ]. "Objects without inst vars should return something" ^ str isEmpty ifTrue: [ self printString , String cr ] ifFalse: [ str ] On 28 February 2010 10:58, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Lukas do you have some code samples. > Something that I particularly hate is the following > > Â Â Â Â self bla ifTrue: [ > Â Â Â Â Â Â Â Â ... > > Â Â Â Â ] ifFalse: [ > Â Â Â Â Â Â Â Â ... > Â Â Â Â ] > > That is see in the code. > > I want > Â Â Â Â self bla > Â Â Â Â Â Â Â Â ifTrue: [ ... > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ] > Â Â Â Â Â Â Â Â ifFalse: [ > Â Â Â Â Â Â Â Â Â Â Â Â ... Â Â Â Â Â Â ] > > > >> I would use a formatter, like this you can make it really consistent. >> The RBConfigurableFormatter is pretty good in that, the only thing I >> don't like is the placing of the square brackets. I should look into >> fixing that, otherwise it formats exactly the way I would format >> myself (and in the way you propose). > > I would really like to play with the idea of automatic formatting > to see how it goes. > > Stef > >> >> Lukas >> >> On 28 February 2010 10:36, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >>> Hi guys >>> >>> I would like to build a set of canonical code formatting convention for Pharo. >>> I need your help. Now take time before replying :) >>> I would like to structure the discussion and proceed step by step. So at max I would like to discuss one or two formatting approach per mail. >>> Once we agree I would like to define a wiki page. >>> >>> >>> **Space after : rule >>> ============= >>> for example I would like to always have a space after a : >>> >>> classes := Smalltalk allClasses select:[:aClass| >>> Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) >>> Â Â Â Â Â Â Â Â Â Â Â or:[aClass class includesSelector: #cleanUp:] >>> Â Â Â ]. >>> >>> -> >>> >>> >>> classes := Smalltalk allClasses select: [:aClass| >>> Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) >>> Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:] >>> Â Â Â ]. >>> >>> >>> **Block arg rule >>> ============= >>> Do we want a space before and after block arg >>> >>> Smalltalk allClasses select: [:aClass :method| >>> >>> -> Smalltalk allClasses select: [ :aClass :method | >>> >>> >>> ** selector or block indented compared to receiver >>> ======================================= >>> >>> Finally do we follow kent block ideas? >>> >>> classes := Smalltalk allClasses select: [:aClass| >>> Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) >>> Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:] >>> Â Â Â ]. >>> >>> -> >>> classes := Smalltalk allClasses >>> Â Â Â Â Â Â Â Â Â Â Â Â select: [:aClass| (aClass class includesSelector: #cleanUp) >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:]]. >>> >>> 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 > -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 28, 2010

[Pharo-project] [update 1.1] #11238

by StÃ©phane Ducasse

11238 ----- - Issue 2089: Case insensitive search for MethodFinder/MessageNames tx marcus - Issue 2097: SecureHashAlgorithm raising an error upon empty input (from squeak) - Issue 2087: Compacting all methodDictionaries (from squeak) - Cycles cutting tx Jannik Stef (I will be off playing games with kids and noury and luc today....) I will show them magic the gathering Yeahhhh So I will not integrate more today

Feb. 28, 2010