Re: [Pharo-project] about code formatting in pharo
Stef, I have never liked forced formatting; good scanners and parsers have allowed us to move beyond that. Again, I have no real concern over how you chose to format the code in the base system; I would care greatly about any attempt to build that into the language (since you bring it up) or the tools as a mandatory feature. Bill -Original Message- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Sunday, February 28, 2010 4:17 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo you know go (the language) includes in the language the formatting so there is no discussion. Now I really like to see smalltalk code and not C code because. It slows me down a lot when I read and I read a lot of code. :) Stef On Feb 28, 2010, at 8:51 PM, Adrian Lienhard wrote: > Hi Bill, > > Don't worry. Nobody wants to force you to use his conventions :) > > The question really only concerns the code of PharoCore. I think a consistent > way of code formatting really is a good idea, even if not everybody agrees > with each rule. > > Cheers, > Adrian > > On Feb 28, 2010, at 18:43 , Schwab,Wilhelm K wrote: > >> Adrian, >> >> Horrible is an understatement :) Your version is a big improvement. I >> frequently put ending brackets on their own line with indentation to aid in >> matching, but not always. >> >> I do not (much) care what conventions the benevolent dictators select for >> Pharo, but I **do** care that it not be forced on my code that I retain for >> my own use. There should be ways to compile, export and load code and >> packagets w/o encountering automatic formatting. As long as that is the >> case, enjoy!! >> >> Bill >> >> >> >> -Original Message- >> From: pharo-project-boun...@lists.gforge.inria.fr >> [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of >> Adrian Lienhard >> Sent: Sunday, February 28, 2010 8:11 AM >> To: Pharo-project@lists.gforge.inria.fr >> Subject: Re: [Pharo-project] about code formatting in pharo >> >> I've attached the coding conventions that we use at Cmsbox and netstyle.ch. >> They closely follow the suggestions of Kent Beck's "Smalltalk Best Practice >> Patterns". >> >> According to these rules I would format the following example: >> >> --- >> 1 to: (mine size min: his size) do: >> [ :ind | >> (mine at: ind) = (his at: ind) >> ifTrue: [ self instVarAt: ind put: >> (anotherObject instVarAt: ind) ] ]. >> --- >> >> as: >> >> --- >> 1 >> to: (mine size min: his size) >> do: [ :index | >> (mine at: index) = (his at: index) ifTrue: [ >> self >> instVarAt: index >> put: (anotherObject instVarAt: index) ] ]. >> --- >> >> Putting "[ :ind |" on a new line and using multiple tab indentation looks >> horrible to me. >> >> Cheers, >> Adrian >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
lol I was really skeptical :) >> :ind | at the beginning of the line. > > Ahh, that was the mail program that broke it there. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
On 28 February 2010 22:38, Stéphane Ducasse wrote: > > On Feb 28, 2010, at 10:28 PM, Lukas Renggli wrote: > I've commented >>> >>> commited :) I guess I saw in on the rss feed :) >> >> Yeah. >> >>> can we get rid of the >>> >>> :ind | >> >> Select 'ind', in the context menu select 'refactor source', 'rename >> temporary'. Then give the new name 'index', press 'ok'. Done. > > no i meant > > 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) ] ] > > or > > self class isVariable & anotherObject class isVariable > ifTrue: [ 1 to: (self basicSize min: anotherObject basicSize) > do: [:ind | > self basicAt: ind put: > (anotherObject basicAt: ind) ] ] > > but not starting > > :ind | at the beginning of the line. Ahh, that was the mail program that broke it there. Lukas > > >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
On Feb 28, 2010, at 10:28 PM, Lukas Renggli wrote: >>> I've commented >> >> commited :) I guess I saw in on the rss feed :) > > Yeah. > >> can we get rid of the >> >> :ind | > > Select 'ind', in the context menu select 'refactor source', 'rename > temporary'. Then give the new name 'index', press 'ok'. Done. no i meant 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) ] ] or self class isVariable & anotherObject class isVariable ifTrue: [ 1 to: (self basicSize min: anotherObject basicSize) do: [:ind | self basicAt: ind put: (anotherObject basicAt: ind) ] ] but not starting :ind | at the beginning of the line. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
The configurable formatter can be told from how many keyword messages on it should put them on multiple lines. Also you can give exceptions of messages that you always/never want to put on multiple lines. Lukas On 28 February 2010 22:29, Adrian Lienhard wrote: > > On Feb 28, 2010, at 22:12 , Stéphane Ducasse wrote: >>> --- >>> 1 >>> to: (mine size min: his size) >>> do: [ :index | >>> (mine at: index) = (his at: index) ifTrue: [ >>> self >>> instVarAt: index >>> put: (anotherObject instVarAt: index) ] ]. >>> --- >>> >>> Putting "[ :ind |" on a new line and using multiple tab indentation looks >>> horrible to me. >> >> :) >> >> why not like that? >>> 1 >>> to: (mine size min: his size) >>> do: [ :index | >>> (mine at: index) = (his at: index) >>> ifTrue: [ self >>> instVarAt: index >>> put: (anotherObject instVarAt: index) >>> ] ]. > > The difference is not big, but I prefer the first version because you get one > indentation less (and you don't break the rule that an indentation always has > only one tab, which is not the case above). > > Also it makes formatting of conditionals consistent with the formatting of > other messages, e.g., > > receiver foo: x > > instead of > > receiver > foo: x > > > The rule for ifTrue:ifFalse: follows the same rule, i.e., that keyword > messages with more than one argument are put on separate lines: > > receiver > foo: x > bar: y > > > Adrian > ___ > Pharo-project mailing list > Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Streams. Status and where to go?
2010/2/28 Igor Stasenko :
> On 28 February 2010 12:00, Nicolas Cellier
> wrote:
>> 2010/2/28 Igor Stasenko :
>>> 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.
>
It deserves being buffered !
Here are the results with later version:
| str |
str := (String new: 1000 withAll: $a) asByteArray.
{
[ (XtreamUTF8Converter on: str readXtream binary) buffered upToEnd ] bench.
[ (UTF8Decoder new source: str readXtream binary) buffered upToEnd ] bench.
[ str readXtream binary upToEnd ] bench.
}
#('3441.711657668466 per second.' '44901.4197160568 per second.'
'168149.7700459908 per second.')
Nicolas
>> Nicolas
>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@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@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
On Feb 28, 2010, at 22:12 , Stéphane Ducasse wrote: >> --- >> 1 >> to: (mine size min: his size) >> do: [ :index | >> (mine at: index) = (his at: index) ifTrue: [ >> self >> instVarAt: index >> put: (anotherObject instVarAt: index) ] ]. >> --- >> >> Putting "[ :ind |" on a new line and using multiple tab indentation looks >> horrible to me. > > :) > > why not like that? >> 1 >> to: (mine size min: his size) >> do: [ :index | >> (mine at: index) = (his at: index) >> ifTrue: [ self >> instVarAt: index >> put: (anotherObject instVarAt: index) ] >> ]. The difference is not big, but I prefer the first version because you get one indentation less (and you don't break the rule that an indentation always has only one tab, which is not the case above). Also it makes formatting of conditionals consistent with the formatting of other messages, e.g., receiver foo: x instead of receiver foo: x The rule for ifTrue:ifFalse: follows the same rule, i.e., that keyword messages with more than one argument are put on separate lines: receiver foo: x bar: y Adrian ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
>> I've commented > > commited :) I guess I saw in on the rss feed :) Yeah. > can we get rid of the > > :ind | Select 'ind', in the context menu select 'refactor source', 'rename temporary'. Then give the new name 'index', press 'ok'. Done. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
Thanks lukas > I've commented commited :) I guess I saw in on the rss feed :) > a version of RBConfigurableFormatter that can format > #copyFrom: to the following code. This comes pretty close to the > document of Adrian: > > 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. " > > > | 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) ] ] > can we get rid of the :ind | ;) > -- > Lukas Renggli > http://www.lukas-renggli.ch > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
I've commented a version of RBConfigurableFormatter that can format #copyFrom: to the following code. This comes pretty close to the document of Adrian: 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. " | 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) ] ] -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
Hi James > Lukas do you have some code samples. >> Something that I particularly hate is the following >> >> self bla ifTrue: [ >> ... >> >> ] ifFalse: [ >> ... >> ] > > I'd like to understand what it is about the above you hate. See levente In addition I have to apy extreme attention to see that the two branches are sent to the same conditional > >> That is see in the code. >> >> I want >> self bla >> ifTrue: [ ... >> ] >> ifFalse: [ >> ... ] > > Does the code in the ifTrue: block begin on the same line? How about the > ifFalse: block? If it begins on the same line, then how many indents for the > second line? > > James > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
you know go (the language) includes in the language the formatting so there is no discussion. Now I really like to see smalltalk code and not C code because. It slows me down a lot when I read and I read a lot of code. :) Stef On Feb 28, 2010, at 8:51 PM, Adrian Lienhard wrote: > Hi Bill, > > Don't worry. Nobody wants to force you to use his conventions :) > > The question really only concerns the code of PharoCore. I think a consistent > way of code formatting really is a good idea, even if not everybody agrees > with each rule. > > Cheers, > Adrian > > On Feb 28, 2010, at 18:43 , Schwab,Wilhelm K wrote: > >> Adrian, >> >> Horrible is an understatement :) Your version is a big improvement. I >> frequently put ending brackets on their own line with indentation to aid in >> matching, but not always. >> >> I do not (much) care what conventions the benevolent dictators select for >> Pharo, but I **do** care that it not be forced on my code that I retain for >> my own use. There should be ways to compile, export and load code and >> packagets w/o encountering automatic formatting. As long as that is the >> case, enjoy!! >> >> Bill >> >> >> >> -Original Message- >> From: pharo-project-boun...@lists.gforge.inria.fr >> [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Adrian >> Lienhard >> Sent: Sunday, February 28, 2010 8:11 AM >> To: Pharo-project@lists.gforge.inria.fr >> Subject: Re: [Pharo-project] about code formatting in pharo >> >> I've attached the coding conventions that we use at Cmsbox and netstyle.ch. >> They closely follow the suggestions of Kent Beck's "Smalltalk Best Practice >> Patterns". >> >> According to these rules I would format the following example: >> >> --- >> 1 to: (mine size min: his size) do: >> [ :ind | >> (mine at: ind) = (his at: ind) >> ifTrue: [ self instVarAt: ind put: >> (anotherObject instVarAt: ind) ] ]. >> --- >> >> as: >> >> --- >> 1 >> to: (mine size min: his size) >> do: [ :index | >> (mine at: index) = (his at: index) ifTrue: [ >> self >> instVarAt: index >> put: (anotherObject instVarAt: index) ] ]. >> --- >> >> Putting "[ :ind |" on a new line and using multiple tab indentation looks >> horrible to me. >> >> Cheers, >> Adrian >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
+ 10 >> I'd like to understand what it is about the above you hate. > > It's like C code, not like a message send. Do you write code like this? > > aCollection do: [ :each | > ... > ] separatedBy: [ > ... > ] > >> >>> That is see in the code. >>> >>> I want >>> self bla >>> ifTrue: [ ... >>> ] >>> ifFalse: [ >>> ... ] >> >> Does the code in the ifTrue: block begin on the same line? How about the >> ifFalse: block? If it begins on the same line, then how many indents for the >> second line? >> > > IMHO, if the code in the first block is short enought, then it's only a > single line, otherwise not, for example: > > self bla > ifTrue: [ self bar ] > ifFalse: [ > ... ] > > self bla > ifTrue: [ > ... ] > ifFalse: [ > ... ] > > This book has great guidelines: > http://stephane.ducasse.free.fr/FreeBooks/WithStyle/SmalltalkWithStyle.pdf > > > Levente > > > >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
thanks adrian On Feb 28, 2010, at 2:11 PM, Adrian Lienhard wrote: > I've attached the coding conventions that we use at Cmsbox and netstyle.ch. > They closely follow the suggestions of Kent Beck's "Smalltalk Best Practice > Patterns". > > According to these rules I would format the following example: > > --- > 1 to: (mine size min: his size) do: > [ :ind | > (mine at: ind) = (his at: ind) > ifTrue: [ self instVarAt: ind put: > (anotherObject instVarAt: ind) ] ]. > --- > > as: > > --- > 1 > to: (mine size min: his size) > do: [ :index | > (mine at: index) = (his at: index) ifTrue: [ > self > instVarAt: index > put: (anotherObject instVarAt: index) ] ]. > --- > > Putting "[ :ind |" on a new line and using multiple tab indentation looks > horrible to me. :) why not like that? > 1 > to: (mine size min: his size) > do: [ :index | > (mine at: index) = (his at: index) > ifTrue: [ self > instVarAt: index > put: (anotherObject instVarAt: index) ] > ]. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
> > 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 Not for me :) May be I read too much Smalltalk code I prefer the rectangle approach of the first one ;) ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [ANN 1.1] pre-built 1.1#11239
http://gforge.inria.fr/frs/download.php/26559/PharoCore-1.1-11239-UNSTABLE.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Scamper revival
There is the further concern about the browser. It wastes screen space (which is at a premium) and adds weight and distracting functionality. There is something to be said for the a fat client app that does what it needs to do and nothing else. -Original Message- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Eagle Offshore Sent: Sunday, February 28, 2010 2:23 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Scamper revival I wouldn't be so sure. http://html5demos.com/ http://jqtouch.com/ On Feb 27, 2010, at 4:41 PM, Schwab,Wilhelm K wrote: > there is no way in hell that HTML+CSS+JavaScript is going to keep up ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
Adrian, I appreciate the reassurance, and agree that conventions are a good idea. I further agree with Lukas that a formatter is a good way to get there, but want to make the case for doing that in a way that does not force the hands of end-user (which I appear to have done). Bill -Original Message- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Sunday, February 28, 2010 2:52 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo Hi Bill, Don't worry. Nobody wants to force you to use his conventions :) The question really only concerns the code of PharoCore. I think a consistent way of code formatting really is a good idea, even if not everybody agrees with each rule. Cheers, Adrian On Feb 28, 2010, at 18:43 , Schwab,Wilhelm K wrote: > Adrian, > > Horrible is an understatement :) Your version is a big improvement. I > frequently put ending brackets on their own line with indentation to aid in > matching, but not always. > > I do not (much) care what conventions the benevolent dictators select for > Pharo, but I **do** care that it not be forced on my code that I retain for > my own use. There should be ways to compile, export and load code and > packagets w/o encountering automatic formatting. As long as that is the > case, enjoy!! > > Bill > > > > -Original Message- > From: pharo-project-boun...@lists.gforge.inria.fr > [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of > Adrian Lienhard > Sent: Sunday, February 28, 2010 8:11 AM > To: Pharo-project@lists.gforge.inria.fr > Subject: Re: [Pharo-project] about code formatting in pharo > > I've attached the coding conventions that we use at Cmsbox and netstyle.ch. > They closely follow the suggestions of Kent Beck's "Smalltalk Best Practice > Patterns". > > According to these rules I would format the following example: > > --- > 1 to: (mine size min: his size) do: > [ :ind | > (mine at: ind) = (his at: ind) > ifTrue: [ self instVarAt: ind put: > (anotherObject instVarAt: ind) ] ]. > --- > > as: > > --- > 1 > to: (mine size min: his size) > do: [ :index | > (mine at: index) = (his at: index) ifTrue: [ > self > instVarAt: index > put: (anotherObject instVarAt: index) ] ]. > --- > > Putting "[ :ind |" on a new line and using multiple tab indentation looks > horrible to me. > > Cheers, > Adrian > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Introducing Myself / FFI comments
I would like to add to this discussion. The issue on "breaking code compatibility" /per se/ it is not the central issue, the real trouble is to have to expend too much time to learn how to "re-compatibilize" the cote, or use [the] new construct that is not deprecated. I'm not an active Python developer, but I used to work in a place where it was used extensively and the 'elbow' feedback I got from colleagues was that that Python did a good job on this aspect. my 0.01999 -- Cesar Rabak Em 28/02/2010 05:24, Hilaire Fernandes < hila...@ofset.org > escreveu: Andreas Raab a écrit : > The *one* tradeoff I wasn't willing to make for the sake of my users was > to break their code; was to make their code non-loadable for absolutely > no benefit for these users. Cleaning up two methods and fifty lines of > code isn't worth breaking six years of work from lots of people. It > wasn't then, it isn't today. However, breaking code compatibility is very common in opensource world, probably to ease evolution. I remember to read somewhere it happens several time in Python, an alive and kicking community... ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
Hi Bill, Don't worry. Nobody wants to force you to use his conventions :) The question really only concerns the code of PharoCore. I think a consistent way of code formatting really is a good idea, even if not everybody agrees with each rule. Cheers, Adrian On Feb 28, 2010, at 18:43 , Schwab,Wilhelm K wrote: > Adrian, > > Horrible is an understatement :) Your version is a big improvement. I > frequently put ending brackets on their own line with indentation to aid in > matching, but not always. > > I do not (much) care what conventions the benevolent dictators select for > Pharo, but I **do** care that it not be forced on my code that I retain for > my own use. There should be ways to compile, export and load code and > packagets w/o encountering automatic formatting. As long as that is the > case, enjoy!! > > Bill > > > > -Original Message- > From: pharo-project-boun...@lists.gforge.inria.fr > [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Adrian > Lienhard > Sent: Sunday, February 28, 2010 8:11 AM > To: Pharo-project@lists.gforge.inria.fr > Subject: Re: [Pharo-project] about code formatting in pharo > > I've attached the coding conventions that we use at Cmsbox and netstyle.ch. > They closely follow the suggestions of Kent Beck's "Smalltalk Best Practice > Patterns". > > According to these rules I would format the following example: > > --- > 1 to: (mine size min: his size) do: > [ :ind | > (mine at: ind) = (his at: ind) > ifTrue: [ self instVarAt: ind put: > (anotherObject instVarAt: ind) ] ]. > --- > > as: > > --- > 1 > to: (mine size min: his size) > do: [ :index | > (mine at: index) = (his at: index) ifTrue: [ > self > instVarAt: index > put: (anotherObject instVarAt: index) ] ]. > --- > > Putting "[ :ind |" on a new line and using multiple tab indentation looks > horrible to me. > > Cheers, > Adrian > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Scamper revival
I wouldn't be so sure. http://html5demos.com/ http://jqtouch.com/ On Feb 27, 2010, at 4:41 PM, Schwab,Wilhelm K wrote: > there is no way in hell that HTML+CSS+JavaScript is going to keep up ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Infinite Loop and Ctrl+.
we should open a ticket On Sun, Feb 28, 2010 at 2:15 PM, Adrian Lienhard wrote: > Sure, no worries. In any case it would be nice if it always worked... > > Adrian > > On Feb 28, 2010, at 13:52 , Lukas Renggli wrote: > > > I wasn't implying that this was the fault of Pharo. I just noticed it > > suddenly and I somehow thought that this worked at some point in the > > past, but I might be wrong. > > > > Lukas > > > > On 28 February 2010 13:29, Adrian Lienhard wrote: > >> It worked for me the first time I tried, but not the second time (the VM > eventually crashed). > >> > >> Already in Squeak 3.9 it was sometimes impossible to break endless > recursions. So I'm not sure if this related to changes in Pharo 1.0. > >> > >> Adrian > >> > >> On Feb 26, 2010, at 16:50 , Lukas Renggli wrote: > >> > > Is this just me that suddenly cannot break out of an infinite loop > > with Ctrl+. in Pharo 1.0 anymore? > > Works here. [true] whileTrue: [] > >>> > >>> Yes, that works for me too, but try: > >>> > >>> UndefinedObject compile: 'foo self foo'. > >>> nil foo > >>> > Which vm are you using? Squeak 4.2.2beta1U here right now... > >>> > >>> Yes, I am using this one too. > >>> > >>> Lukas > >>> > >>> -- > >>> Lukas Renggli > >>> http://www.lukas-renggli.ch > >>> > >>> ___ > >>> Pharo-project mailing list > >>> Pharo-project@lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> ___ > >> Pharo-project mailing list > >> Pharo-project@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@lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
Adrian, Horrible is an understatement :) Your version is a big improvement. I frequently put ending brackets on their own line with indentation to aid in matching, but not always. I do not (much) care what conventions the benevolent dictators select for Pharo, but I **do** care that it not be forced on my code that I retain for my own use. There should be ways to compile, export and load code and packagets w/o encountering automatic formatting. As long as that is the case, enjoy!! Bill -Original Message- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Sunday, February 28, 2010 8:11 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo I've attached the coding conventions that we use at Cmsbox and netstyle.ch. They closely follow the suggestions of Kent Beck's "Smalltalk Best Practice Patterns". According to these rules I would format the following example: --- 1 to: (mine size min: his size) do: [ :ind | (mine at: ind) = (his at: ind) ifTrue: [ self instVarAt: ind put: (anotherObject instVarAt: ind) ] ]. --- as: --- 1 to: (mine size min: his size) do: [ :index | (mine at: index) = (his at: index) ifTrue: [ self instVarAt: index put: (anotherObject instVarAt: index) ] ]. --- Putting "[ :ind |" on a new line and using multiple tab indentation looks horrible to me. Cheers, Adrian ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] SqueakSave on Pharo
I sent an email last week, and saw no answer, so far. So I've put up what I have. Stéphane Ducasse wrote: > Yanni excellent to have it on squeaksource. > Now did you contact the maintainer (if any) or the people that developed it > (I like it a lot) to mention that? > Because at least they should know if some changes get introduced that they > can cherrypick it. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
On Sun, 28 Feb 2010, James Foster wrote: On Feb 28, 2010, at 1:58 AM, Stéphane Ducasse wrote: Lukas do you have some code samples. Something that I particularly hate is the following self bla ifTrue: [ ... ] ifFalse: [ ... ] I'd like to understand what it is about the above you hate. It's like C code, not like a message send. Do you write code like this? aCollection do: [ :each | ... ] separatedBy: [ ... ] That is see in the code. I want self bla ifTrue: [ ... ] ifFalse: [ ... ] Does the code in the ifTrue: block begin on the same line? How about the ifFalse: block? If it begins on the same line, then how many indents for the second line? IMHO, if the code in the first block is short enought, then it's only a single line, otherwise not, for example: self bla ifTrue: [ self bar ] ifFalse: [ ... ] self bla ifTrue: [ ... ] ifFalse: [ ... ] This book has great guidelines: http://stephane.ducasse.free.fr/FreeBooks/WithStyle/SmalltalkWithStyle.pdf Levente ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
On Feb 28, 2010, at 1:58 AM, Stéphane Ducasse wrote: > Lukas do you have some code samples. > Something that I particularly hate is the following > > self bla ifTrue: [ > ... > > ] ifFalse: [ > ... > ] I'd like to understand what it is about the above you hate. > That is see in the code. > > I want > self bla > ifTrue: [ ... > ] > ifFalse: [ > ... ] Does the code in the ifTrue: block begin on the same line? How about the ifFalse: block? If it begins on the same line, then how many indents for the second line? James ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Smalltalk and Bioinformatics
Hi all, I'm preparing a presentation and just wondering if anyone out there is doing bioinformatics with Smalltalk? Cheers, Hernán ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
Stef, It pains me to have to be a pain about this. I never use a space after a colon; what other people do is their business, but I much prefer having the space gone. Other formatting concerns are far less trivial to me than a personal preference. Lukas is correct about using a formatter, but it has to be a separate or optional step because the current state of formatting is hostile to comments. If moving code to Pharo has taught me anything, it is that I have been correct to embed dated (month-year) comments in my code. The RB scatters them to the four corners, which is why I don't use the thing. I also format code in ways that are analogous to phrasing in music. I tried to capture it in a custom formatter, and quickly realized that I see design, workflow, organizational politics, etc., and the machine sees syntax. It will never "understand" what belongs together and what does not. Anything that forces formatting on me is defective. If there is a way for me to optionally format my code with a Pharo formatter, I'm happy to do so as I turn it over. Anything that I am actively using will be littered with comments (until I tire of them[*]) and formatted in a way that helps me see the big picture long after the machine smashes it down to a mere sequence of byte codes. Bill [*] every so often, I clean out truly obsolete information, but that is more a question of the amount of change that has occurred, not chronological age. In moving to Pharo, I ran across couple of related defects from 2003, and fixed them within an hour thanks to comments in the code. This is one of many such stories that have formed my (somewhat stubborn) thoughts on code formatting. -Original Message- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Sunday, February 28, 2010 4:52 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo 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). Lukas On 28 February 2010 10:36, stephane ducasse 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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Streams. Status and where to go?
On 28 February 2010 15:44, Nicolas Cellier
wrote:
> 2010/2/28 Igor Stasenko :
>> On 28 February 2010 14:33, Nicolas Cellier
>> wrote:
>>> 2010/2/28 Igor Stasenko :
On 28 February 2010 12:45, Nicolas Cellier
>> ..
>>>
>>> Anyway, main contributor of UTF8Decoder inefficiency is
>>> Unicode>>value: and leadingChar handling:
>>>
>>
>> btw, why its using #value: , not more efficient charFromUnicode: ?
>>
>> value: code
>>
>> | l |
>> code < 256 ifTrue: [^ Character value: code].
>> l := Locale currentPlatform languageEnvironment leadingChar.
>> l = 0 ifTrue: [l := 255].
>> ^ Character leadingChar: l code: code.
>>
>> for unicode leadingChar is always 255 (see Unicode>>leadingChar)
>>
>> So, i'm not sure what this code with Locale doing here?
>>
>> Btw, converter could use a 'leadingChar' ivar, which can be initialized to
>> Locale currentPlatform languageEnvironment leadingChar. (if this correct),
>> or Unicode>>leadingChar , which i feel more correct.
>>
>> And then just build chars by own, without using Unicode global:
>> Character leadingChar: leadingChar code: uniCode
>>
>>
>
> Yes, and as already suggested a few month ago by Andreas and former by
> me and some others, the Unicode leadingChar should better be = 0
>
big +1
by default , a most straightforward things should be those, which is
universal in our world.
And unicode is hardly can be depicted as a marginal one :)
> Nicolas
>
>>
>>> | str |
>>> str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream
>>> binary.
>>> MessageTally spyOn:
>>> [ (UTF8Decoder new source: str readXtream buffered)
>>> buffered upToEnd ]
>>>
>>>
>>> - 133 tallies, 133 msec.
>>>
>>> **Tree**
>>>
>>> Process: (40) 37486: nil
>>>
>>> 99.2% {132ms} BufferedReadXtream>>checkAvailableDataInBuffer
>>> 99.2% {132ms} BufferedReadXtream>>readNextBuffer
>>> 99.2% {132ms} UTF8Decoder(CharacterDecoder)>>readInto:startingAt:count:
>>> 50.4% {67ms} UTF8Decoder>>next
>>> |45.1% {60ms} Unicode class>>value:
>>> | |30.1% {40ms} Locale>>languageEnvironment
>>> | | |29.3% {39ms} LanguageEnvironment class>>localeID:
>>> | | | 29.3% {39ms} Dictionary>>at:ifAbsent:
>>> | | | 27.1% {36ms} Dictionary>>scanFor:
>>> | | | |15.0% {20ms} LocaleID>>=
>>> | | | | |6.0% {8ms} UndefinedObject(Object)>>=
>>> | | | | |6.0% {8ms} primitives
>>> | | | | |3.0% {4ms} ByteString(String)>>=
>>> | | | | | 2.3% {3ms} primitives
>>> | | | |9.8% {13ms} LocaleID>>hash
>>> | | | | |6.8% {9ms} ByteString(String)>>hash
>>> | | | | |2.3% {3ms} UndefinedObject(Object)>>hash
>>> | | | | | 1.5% {2ms} primitives
>>> | | | |2.3% {3ms} primitives
>>> | | | 2.3% {3ms} primitives
>>> | |9.8% {13ms} Character class>>leadingChar:code:
>>> | | |5.3% {7ms} Character class>>value:
>>> | | | |3.0% {4ms} primitives
>>> | | | |2.3% {3ms} Character>>setValue:
>>> | | |4.5% {6ms} primitives
>>> | |2.3% {3ms} primitives
>>> | |1.5% {2ms} Latin1Environment(LanguageEnvironment)>>leadingChar
>>> | |1.5% {2ms} Locale class>>currentPlatform
>>> |3.0% {4ms} CollectionReadXtream>>next
>>> |2.3% {3ms} primitives
>>> 18.8% {25ms} UTF8Decoder(CharacterDecoder)>>readInto:startingAt:count:
>>> |9.8% {13ms} UTF8Decoder>>next
>>> | |9.0% {12ms} Unicode class>>value:
>>> | | 6.0% {8ms} Locale>>languageEnvironment
>>> | | |5.3% {7ms} LanguageEnvironment class>>localeID:
>>> | | | 5.3% {7ms} Dictionary>>at:ifAbsent:
>>> | | | 5.3% {7ms} Dictionary>>scanFor:
>>> | | | 3.0% {4ms} LocaleID>>=
>>> | | | |1.5% {2ms} UndefinedObject(Object)>>=
>>> | | | |1.5% {2ms} ByteString(String)>>=
>>> | | | | 1.5% {2ms}
>>> ByteString(String)>>compare:with:collated:
>>> | | | 2.3% {3ms} LocaleID>>hash
>>> | | | 1.5% {2ms} UndefinedObject(Object)>>hash
>>> | | 2.3% {3ms} Latin1Environment(LanguageEnvironment)>>leadingChar
>>> |5.3% {7ms} UTF8Decoder(CharacterDecoder)>>readInto:startingAt:count:
>>> | |3.0% {4ms} UTF8Decoder>>next
>>> | | |3.0% {4ms} Unicode class>>value:
>>> | | | 2.3% {3ms} Locale>>languageEnvironment
>>> | | | 2.3% {3ms} LanguageEnvironment class>>localeID:
>>> | | | 2.3% {3ms} Dictionary>>at:ifAbsent:
>>> | | | 2.3% {3ms} Dictionary>>scanFor:
>>> | |1.5% {2ms}
>>> UTF8Decoder(CharacterDecoder)>>readInto:startingAt:count:
>>> |2.3% {3ms} ByteArray(SequenceableCollection)>>readXtreamFrom:to:
>>> | 1.5% {2ms} CollectionReadXtream class>>read:from:to:
>>> |
Re: [Pharo-project] Streams. Status and where to go?
2010/2/28 Igor Stasenko :
> On 28 February 2010 14:33, Nicolas Cellier
> wrote:
>> 2010/2/28 Igor Stasenko :
>>> On 28 February 2010 12:45, Nicolas Cellier
> ..
>>
>> Anyway, main contributor of UTF8Decoder inefficiency is
>> Unicode>>value: and leadingChar handling:
>>
>
> btw, why its using #value: , not more efficient charFromUnicode: ?
>
> value: code
>
> | l |
> code < 256 ifTrue: [^ Character value: code].
> l := Locale currentPlatform languageEnvironment leadingChar.
> l = 0 ifTrue: [l := 255].
> ^ Character leadingChar: l code: code.
>
> for unicode leadingChar is always 255 (see Unicode>>leadingChar)
>
> So, i'm not sure what this code with Locale doing here?
>
> Btw, converter could use a 'leadingChar' ivar, which can be initialized to
> Locale currentPlatform languageEnvironment leadingChar. (if this correct),
> or Unicode>>leadingChar , which i feel more correct.
>
> And then just build chars by own, without using Unicode global:
> Character leadingChar: leadingChar code: uniCode
>
>
Yes, and as already suggested a few month ago by Andreas and former by
me and some others, the Unicode leadingChar should better be = 0
Nicolas
>
>> | str |
>> str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream
>> binary.
>> MessageTally spyOn:
>> [ (UTF8Decoder new source: str readXtream buffered)
>> buffered upToEnd ]
>>
>>
>> - 133 tallies, 133 msec.
>>
>> **Tree**
>>
>> Process: (40) 37486: nil
>>
>> 99.2% {132ms} BufferedReadXtream>>checkAvailableDataInBuffer
>> 99.2% {132ms} BufferedReadXtream>>readNextBuffer
>> 99.2% {132ms} UTF8Decoder(CharacterDecoder)>>readInto:startingAt:count:
>> 50.4% {67ms} UTF8Decoder>>next
>> |45.1% {60ms} Unicode class>>value:
>> | |30.1% {40ms} Locale>>languageEnvironment
>> | | |29.3% {39ms} LanguageEnvironment class>>localeID:
>> | | | 29.3% {39ms} Dictionary>>at:ifAbsent:
>> | | | 27.1% {36ms} Dictionary>>scanFor:
>> | | | |15.0% {20ms} LocaleID>>=
>> | | | | |6.0% {8ms} UndefinedObject(Object)>>=
>> | | | | |6.0% {8ms} primitives
>> | | | | |3.0% {4ms} ByteString(String)>>=
>> | | | | | 2.3% {3ms} primitives
>> | | | |9.8% {13ms} LocaleID>>hash
>> | | | | |6.8% {9ms} ByteString(String)>>hash
>> | | | | |2.3% {3ms} UndefinedObject(Object)>>hash
>> | | | | | 1.5% {2ms} primitives
>> | | | |2.3% {3ms} primitives
>> | | | 2.3% {3ms} primitives
>> | |9.8% {13ms} Character class>>leadingChar:code:
>> | | |5.3% {7ms} Character class>>value:
>> | | | |3.0% {4ms} primitives
>> | | | |2.3% {3ms} Character>>setValue:
>> | | |4.5% {6ms} primitives
>> | |2.3% {3ms} primitives
>> | |1.5% {2ms} Latin1Environment(LanguageEnvironment)>>leadingChar
>> | |1.5% {2ms} Locale class>>currentPlatform
>> |3.0% {4ms} CollectionReadXtream>>next
>> |2.3% {3ms} primitives
>> 18.8% {25ms} UTF8Decoder(CharacterDecoder)>>readInto:startingAt:count:
>> |9.8% {13ms} UTF8Decoder>>next
>> | |9.0% {12ms} Unicode class>>value:
>> | | 6.0% {8ms} Locale>>languageEnvironment
>> | | |5.3% {7ms} LanguageEnvironment class>>localeID:
>> | | | 5.3% {7ms} Dictionary>>at:ifAbsent:
>> | | | 5.3% {7ms} Dictionary>>scanFor:
>> | | | 3.0% {4ms} LocaleID>>=
>> | | | |1.5% {2ms} UndefinedObject(Object)>>=
>> | | | |1.5% {2ms} ByteString(String)>>=
>> | | | | 1.5% {2ms}
>> ByteString(String)>>compare:with:collated:
>> | | | 2.3% {3ms} LocaleID>>hash
>> | | | 1.5% {2ms} UndefinedObject(Object)>>hash
>> | | 2.3% {3ms} Latin1Environment(LanguageEnvironment)>>leadingChar
>> |5.3% {7ms} UTF8Decoder(CharacterDecoder)>>readInto:startingAt:count:
>> | |3.0% {4ms} UTF8Decoder>>next
>> | | |3.0% {4ms} Unicode class>>value:
>> | | | 2.3% {3ms} Locale>>languageEnvironment
>> | | | 2.3% {3ms} LanguageEnvironment class>>localeID:
>> | | | 2.3% {3ms} Dictionary>>at:ifAbsent:
>> | | | 2.3% {3ms} Dictionary>>scanFor:
>> | |1.5% {2ms}
>> UTF8Decoder(CharacterDecoder)>>readInto:startingAt:count:
>> |2.3% {3ms} ByteArray(SequenceableCollection)>>readXtreamFrom:to:
>> | 1.5% {2ms} CollectionReadXtream class>>read:from:to:
>> | 1.5% {2ms} CollectionReadXtream>>read:from:to:
>> 13.5% {18ms} ByteArray(SequenceableCollection)>>readXtreamFrom:to:
>> |10.5% {14ms} CollectionReadXtream class>>read:from:to:
>> | |6.8% {9ms} CollectionReadXtream>>read:from:to:
>> | | |3.0% {4ms} primitives
>> | | |2.3% {3ms} SmallI
Re: [Pharo-project] Streams. Status and where to go?
On 28 February 2010 14:33, Nicolas Cellier
wrote:
> 2010/2/28 Igor Stasenko :
>> On 28 February 2010 12:45, Nicolas Cellier
..
>
> Anyway, main contributor of UTF8Decoder inefficiency is
> Unicode>>value: and leadingChar handling:
>
btw, why its using #value: , not more efficient charFromUnicode: ?
value: code
| l |
code < 256 ifTrue: [^ Character value: code].
l := Locale currentPlatform languageEnvironment leadingChar.
l = 0 ifTrue: [l := 255].
^ Character leadingChar: l code: code.
for unicode leadingChar is always 255 (see Unicode>>leadingChar)
So, i'm not sure what this code with Locale doing here?
Btw, converter could use a 'leadingChar' ivar, which can be initialized to
Locale currentPlatform languageEnvironment leadingChar. (if this correct),
or Unicode>>leadingChar , which i feel more correct.
And then just build chars by own, without using Unicode global:
Character leadingChar: leadingChar code: uniCode
> | str |
> str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream
> binary.
> MessageTally spyOn:
> [ (UTF8Decoder new source: str readXtream buffered)
> buffered upToEnd ]
>
>
> - 133 tallies, 133 msec.
>
> **Tree**
>
> Process: (40) 37486: nil
>
> 99.2% {132ms} BufferedReadXtream>>checkAvailableDataInBuffer
> 99.2% {132ms} BufferedReadXtream>>readNextBuffer
> 99.2% {132ms} UTF8Decoder(CharacterDecoder)>>readInto:startingAt:count:
> 50.4% {67ms} UTF8Decoder>>next
> |45.1% {60ms} Unicode class>>value:
> | |30.1% {40ms} Locale>>languageEnvironment
> | | |29.3% {39ms} LanguageEnvironment class>>localeID:
> | | | 29.3% {39ms} Dictionary>>at:ifAbsent:
> | | | 27.1% {36ms} Dictionary>>scanFor:
> | | | |15.0% {20ms} LocaleID>>=
> | | | | |6.0% {8ms} UndefinedObject(Object)>>=
> | | | | |6.0% {8ms} primitives
> | | | | |3.0% {4ms} ByteString(String)>>=
> | | | | | 2.3% {3ms} primitives
> | | | |9.8% {13ms} LocaleID>>hash
> | | | | |6.8% {9ms} ByteString(String)>>hash
> | | | | |2.3% {3ms} UndefinedObject(Object)>>hash
> | | | | | 1.5% {2ms} primitives
> | | | |2.3% {3ms} primitives
> | | | 2.3% {3ms} primitives
> | |9.8% {13ms} Character class>>leadingChar:code:
> | | |5.3% {7ms} Character class>>value:
> | | | |3.0% {4ms} primitives
> | | | |2.3% {3ms} Character>>setValue:
> | | |4.5% {6ms} primitives
> | |2.3% {3ms} primitives
> | |1.5% {2ms} Latin1Environment(LanguageEnvironment)>>leadingChar
> | |1.5% {2ms} Locale class>>currentPlatform
> |3.0% {4ms} CollectionReadXtream>>next
> |2.3% {3ms} primitives
> 18.8% {25ms} UTF8Decoder(CharacterDecoder)>>readInto:startingAt:count:
> |9.8% {13ms} UTF8Decoder>>next
> | |9.0% {12ms} Unicode class>>value:
> | | 6.0% {8ms} Locale>>languageEnvironment
> | | |5.3% {7ms} LanguageEnvironment class>>localeID:
> | | | 5.3% {7ms} Dictionary>>at:ifAbsent:
> | | | 5.3% {7ms} Dictionary>>scanFor:
> | | | 3.0% {4ms} LocaleID>>=
> | | | |1.5% {2ms} UndefinedObject(Object)>>=
> | | | |1.5% {2ms} ByteString(String)>>=
> | | | | 1.5% {2ms}
> ByteString(String)>>compare:with:collated:
> | | | 2.3% {3ms} LocaleID>>hash
> | | | 1.5% {2ms} UndefinedObject(Object)>>hash
> | | 2.3% {3ms} Latin1Environment(LanguageEnvironment)>>leadingChar
> |5.3% {7ms} UTF8Decoder(CharacterDecoder)>>readInto:startingAt:count:
> | |3.0% {4ms} UTF8Decoder>>next
> | | |3.0% {4ms} Unicode class>>value:
> | | | 2.3% {3ms} Locale>>languageEnvironment
> | | | 2.3% {3ms} LanguageEnvironment class>>localeID:
> | | | 2.3% {3ms} Dictionary>>at:ifAbsent:
> | | | 2.3% {3ms} Dictionary>>scanFor:
> | |1.5% {2ms}
> UTF8Decoder(CharacterDecoder)>>readInto:startingAt:count:
> |2.3% {3ms} ByteArray(SequenceableCollection)>>readXtreamFrom:to:
> | 1.5% {2ms} CollectionReadXtream class>>read:from:to:
> | 1.5% {2ms} CollectionReadXtream>>read:from:to:
> 13.5% {18ms} ByteArray(SequenceableCollection)>>readXtreamFrom:to:
> |10.5% {14ms} CollectionReadXtream class>>read:from:to:
> | |6.8% {9ms} CollectionReadXtream>>read:from:to:
> | | |3.0% {4ms} primitives
> | | |2.3% {3ms} SmallInteger(Magnitude)>>max:
> | | |1.5% {2ms} SmallInteger(Magnitude)>>min:
> | |2.3% {3ms} CollectionReadXtream class(Behavior)>>new
> | |1.5% {2ms} primitives
> |3.0% {4ms} primitives
> 3.8% {5ms} Unicode class>>value:
> |3.0% {4ms} primitives
>
Re: [Pharo-project] Infinite Loop and Ctrl+.
Sure, no worries. In any case it would be nice if it always worked... Adrian On Feb 28, 2010, at 13:52 , Lukas Renggli wrote: > I wasn't implying that this was the fault of Pharo. I just noticed it > suddenly and I somehow thought that this worked at some point in the > past, but I might be wrong. > > Lukas > > On 28 February 2010 13:29, Adrian Lienhard wrote: >> It worked for me the first time I tried, but not the second time (the VM >> eventually crashed). >> >> Already in Squeak 3.9 it was sometimes impossible to break endless >> recursions. So I'm not sure if this related to changes in Pharo 1.0. >> >> Adrian >> >> On Feb 26, 2010, at 16:50 , Lukas Renggli wrote: >> > Is this just me that suddenly cannot break out of an infinite loop > with Ctrl+. in Pharo 1.0 anymore? Works here. [true] whileTrue: [] >>> >>> Yes, that works for me too, but try: >>> >>> UndefinedObject compile: 'foo self foo'. >>> nil foo >>> Which vm are you using? Squeak 4.2.2beta1U here right now... >>> >>> Yes, I am using this one too. >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@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@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Infinite Loop and Ctrl+.
I wasn't implying that this was the fault of Pharo. I just noticed it suddenly and I somehow thought that this worked at some point in the past, but I might be wrong. Lukas On 28 February 2010 13:29, Adrian Lienhard wrote: > It worked for me the first time I tried, but not the second time (the VM > eventually crashed). > > Already in Squeak 3.9 it was sometimes impossible to break endless > recursions. So I'm not sure if this related to changes in Pharo 1.0. > > Adrian > > On Feb 26, 2010, at 16:50 , Lukas Renggli wrote: > Is this just me that suddenly cannot break out of an infinite loop with Ctrl+. in Pharo 1.0 anymore? >>> >>> Works here. [true] whileTrue: [] >> >> Yes, that works for me too, but try: >> >> UndefinedObject compile: 'foo self foo'. >> nil foo >> >>> Which vm are you using? Squeak 4.2.2beta1U here right now... >> >> Yes, I am using this one too. >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Simple (but effective) Optimization of PackageOrganizer
Good to now that you are going fine ;-) I'm currently in Paris. I'm leaving to Ha Noi this afternoon but there is a big tempest in Europe right now, a lot of flights have been canceled ... On Sun, Feb 28, 2010 at 12:56 PM, Alexandre Bergel wrote: > Johan and Romain are fine too. This morning a new shake woke me up... > It should be like this for the next weeks. > > Alexandre > > > On 28 Feb 2010, at 06:44, Stéphane Ducasse wrote: > >> Let us know. Seems to be a really big earthquake. >> Probably at santiago some old houses suffered but not the new ones. >> >> Stef >> >> On Feb 28, 2010, at 1:39 AM, Alexandre Bergel wrote: >> >>> Fortunately yes. I am currently on the seaside, these has been some >>> tsunami alert, but I haven't more than a very strong tide. >>> Wondering how I will find my flat in Santiago. >>> >>> Thanks for asking, >>> Alexandre >>> >>> >>> On 27 Feb 2010, at 08:17, Serge Stinckwich wrote: >>> I see that a big earthquake hit Chile : http://www.alertnet.org/thenews/newsdesk/LDE61Q02O.htm I hope everything is ok with you. On Fri, Feb 26, 2010 at 6:58 PM, Alexandre Bergel wrote: > issue #2085 > > Replace the method PackageOrganizer>>packageOfClass: aClass ifNone: > errorBlock by > -=-=-=-=-= > packageOfClass: aClass ifNone: errorBlock > | classCategory | > classCategory := aClass category. > packages at: classCategory ifPresent: [:v | ^ v]. > > (classCategory includes: $-) > ifTrue: [ packages at: (classCategory copyUpTo: $-) > ifPresent: [:v | > ^ v] ]. > > ^ self packages detect: [:ea | ea includesClass: aClass] > ifNone: > errorBlock > -=-=-=-=-= > > Before this enhancement: > [100 timesRepeat: [Object package]] timeToRun > => 141 > > After the fix: > => 2 > > Easy thing to do. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/ ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/ ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Streams. Status and where to go?
2010/2/28 Igor Stasenko :
> On 28 February 2010 12:45, Nicolas Cellier
> wrote:
>> 2010/2/28 Igor Stasenko :
>>> On 28 February 2010 12:00, Nicolas Cellier
>>> wrote:
2010/2/28 Igor Stasenko :
> 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 p
Re: [Pharo-project] Infinite Loop and Ctrl+.
It worked for me the first time I tried, but not the second time (the VM eventually crashed). Already in Squeak 3.9 it was sometimes impossible to break endless recursions. So I'm not sure if this related to changes in Pharo 1.0. Adrian On Feb 26, 2010, at 16:50 , Lukas Renggli wrote: >>> Is this just me that suddenly cannot break out of an infinite loop >>> with Ctrl+. in Pharo 1.0 anymore? >> >> Works here. [true] whileTrue: [] > > Yes, that works for me too, but try: > > UndefinedObject compile: 'foo self foo'. > nil foo > >> Which vm are you using? Squeak 4.2.2beta1U here right now... > > Yes, I am using this one too. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Delay startTimerInterruptWatcher in ScriptLoader >> cleanUpMethods -> DNU
I would remove cleanUpMethods and move what is worth and working to cleanUpForRelease. Cheers, Adrian On Feb 25, 2010, at 13:49 , Mariano Martinez Peck wrote: > Try to evaluate ScriptLoader new cleanUpMethods > > and you will see that in ScriptLoader >> cleanUpMethods > > you do: > > Delay startTimerInterruptWatcher. > > and there is the DNU as startTimerInterruptWatcher is never implemented. > > Solutions ? > > 1) Remove Delay startTimerInterruptWatcher. from cleanUpMethods > > 2) Maybe the message should be stopTimerEventLoop ?? I have no idea > > > The only thing I found in the issues was this: > > http://code.google.com/p/pharo/issues/detail?id=1424 > > > In squeak 3.9 the method is implemented, and like this: > > startTimerInterruptWatcher >"Reset the class variables that keep track of active Delays and re-start > the timer interrupt watcher process. Any currently scheduled delays are > forgotten." >"Delay startTimerInterruptWatcher" > >| p | >self primSignal: nil atMilliseconds: 0. >TimingSemaphore == nil >ifFalse: [TimingSemaphore terminateProcess]. >TimingSemaphore _ Semaphore new. >AccessProtect _ Semaphore forMutualExclusion. >SuspendedDelays _ >SortedCollection sortBlock: >[:d1 :d2 | d1 resumptionTime <= d2 resumptionTime]. >ActiveDelay _ nil. >p _ [self timerInterruptWatcher] newProcess. >p priority: Processor timingPriority. >p resume. > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] CeBIT anyone?
So will anybody be at the CeBIT? RD ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Simple (but effective) Optimization of PackageOrganizer
Johan and Romain are fine too. This morning a new shake woke me up... It should be like this for the next weeks. Alexandre On 28 Feb 2010, at 06:44, Stéphane Ducasse wrote: > Let us know. Seems to be a really big earthquake. > Probably at santiago some old houses suffered but not the new ones. > > Stef > > On Feb 28, 2010, at 1:39 AM, Alexandre Bergel wrote: > >> Fortunately yes. I am currently on the seaside, these has been some >> tsunami alert, but I haven't more than a very strong tide. >> Wondering how I will find my flat in Santiago. >> >> Thanks for asking, >> Alexandre >> >> >> On 27 Feb 2010, at 08:17, Serge Stinckwich wrote: >> >>> I see that a big earthquake hit Chile : >>> http://www.alertnet.org/thenews/newsdesk/LDE61Q02O.htm >>> I hope everything is ok with you. >>> >>> On Fri, Feb 26, 2010 at 6:58 PM, Alexandre Bergel >>> wrote: issue #2085 Replace the method PackageOrganizer>>packageOfClass: aClass ifNone: errorBlock by -=-=-=-=-= packageOfClass: aClass ifNone: errorBlock | classCategory | classCategory := aClass category. packages at: classCategory ifPresent: [:v | ^ v]. (classCategory includes: $-) ifTrue: [ packages at: (classCategory copyUpTo: $-) ifPresent: [:v | ^ v] ]. ^ self packages detect: [:ea | ea includesClass: aClass] ifNone: errorBlock -=-=-=-=-= Before this enhancement: [100 timesRepeat: [Object package]] timeToRun => 141 After the fix: => 2 Easy thing to do. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> >>> -- >>> Serge Stinckwich >>> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >>> Smalltalkers do: [:it | All with: Class, (And love: it)] >>> http://doesnotunderstand.org/ >>> >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
On 28 February 2010 12:44, Stéphane Ducasse 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 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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >>
Re: [Pharo-project] Streams. Status and where to go?
On 28 February 2010 12:45, Nicolas Cellier
wrote:
> 2010/2/28 Igor Stasenko :
>> On 28 February 2010 12:00, Nicolas Cellier
>> wrote:
>>> 2010/2/28 Igor Stasenko :
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-proje
[Pharo-project] [update 1.1] #11239
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). ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Streams. Status and where to go?
2010/2/28 Igor Stasenko :
> On 28 February 2010 12:00, Nicolas Cellier
> wrote:
>> 2010/2/28 Igor Stasenko :
>>> 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@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@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@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
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 >>> 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@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@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@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@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
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 ] ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] How to manage oos dev
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
On 28 February 2010 11:58, Stéphane Ducasse 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 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@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@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
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. " | 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 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 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 >>> =
[Pharo-project] [update 1.1] #11238
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 Yea So I will not integrate more today ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Streams. Status and where to go?
On 28 February 2010 12:00, Nicolas Cellier
wrote:
> 2010/2/28 Igor Stasenko :
>> 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.
> Nicolas
>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> ___
> Pharo-project mailing list
> Pharo-project@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@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Streams. Status and where to go?
2010/2/28 Igor Stasenko :
> 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 :)
Nicolas
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
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 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@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@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
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). Lukas On 28 February 2010 10:36, stephane ducasse 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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Streams. Status and where to go?
If you feel that this is important we can take some time and port the code from VW. Let us know I can ask cyrille to give a try. Stef On Feb 27, 2010, at 10:56 PM, Nicolas Cellier wrote: > 2010/2/27 Levente Uzonyi : >> On Sat, 27 Feb 2010, Richard Durr wrote: >> >>> So what speaks against using VisualWorks' Xtreams? >>> >>> http://www.cincomsmalltalk.com/blog/blogView?entry=3444278480&printTitle=Smalltalk_Daily_02/22/10:_Introducing_Xtreams&showComments=true >> >> 1. Someone has to port it. >> 2. It's optimized for VW, so the ported code's performance will probably be >> bad. >> >> >> Levente >> > > Licensing was not clear when I begun, so I just picked a few ideas and > re-implement from scratch. > Now it would be interesting to try porting VW Xtream (I should say the > original XTream, I just hijacked the name...). > Concerning performance, VW XTream use exeptions extensively, which I > tried to avoid. > > Nicolas > >>> >>> On Fri, Feb 26, 2010 at 11:01 PM, Igor Stasenko >>> wrote: On 26 February 2010 21:30, Nicolas Cellier wrote: > > 2010/2/26 Igor Stasenko : >> >> On 26 February 2010 18:59, Nicolas Cellier >> wrote: >>> >>> 2010/2/26 Igor Stasenko : Hello, Nicolas. >>> >>> Hi igor. >>> You should load it in trunk. >>> >> Ah, i think my image is a bit outdated then. >> I want to try it out. I tried to load it (XTream-Core) into my image, and it bug me about unresolved dependencies: This package depends on the following classes: ByteTextConverter You must resolve these dependencies before you will be able to load these definitions: ByteTextConverter>>nextFromXtream: ByteTextConverter>>nextPut:toXtream: ByteTextConverter>>readInto:startingAt:count:fromXtream: I ignored these warnings, pressing continue, and here what it warns about in my trunk image: TextConverter>>next:putAll:startingAt:toXtream: (latin1Map is Undeclared) TextConverter>>next:putAll:startingAt:toXtream: (latin1Encodings is Undeclared) TextConverter>>readInto:startingAt:count:fromXtream: (latin1Map is Undeclared) Is ByteTextConverter a Pharo-specific class? >>> >>> This is a refactoring of TextConverter I made in trunk. >>> Pharo did the same before me (it comes from Sophie), but I missed it >>> unfortunately... >>> If you seen my previous message, i think you noticed that XXXTextConverter is abdominations (IMO), and should be reimplemented as a wrapping-streams instead. Would you be willing to change that in XStreams? I mean implementing a conversion streams model, which can wrap around any other stream, like: myStream := UTFReaderStream on: otherStream. myString := myStream contents. or using other way: myString := (someBaseStream wrapWith: UTFReaderStream) contents. or.. myDecodedString := (someBaseStream wrapWith: (DecodingStreams decoderFor: myEncoding) contents. That's would be much nicer than using converters. >>> >>> Currently, I have a ConverterReadXtream and a ConverterWriteXtream >>> which are stream wrappers. >>> They use old TextConverter to do the real job, but I agree, a full >>> rewrite of this one is needed. >>> However, I would like to keep these two layers for Stream composition: >>> - the generic converter stream >>> - the conversion algorithm >>> >> >> Why? >> In your implementation you already added the >> readInto: aCollection startingAt: startIndex count: anInteger >> and >> next: count into: aString startingAt: startIndex >> into converters, which makes them even more like streams. >> > > Yes, you may be right. > Maybe my ratio innovating/reusing was a bit low :) > >> So, what stopping you from making an abstract, generic XtreamWrapper >> class, >> and then a number of subclasses (LatinConversionStream , >> UnicodeConversionStream etc), > > Yes, that's possible. But it's already what ConverterReadXtream and > ConverterWriteXtream are. > I suggesting to use a following hierarchy Xtream -> XtreamWrapper -> ConverterXtream -> (bunch of subclasses) or just Xtream -> XtreamWrapper -> (bunch of subclasses) since i don't think there a lot of specific behavior in ConverterXtream worth creating a separate class. But maybe i'm wrong. >> as well as BufferedWrapper? >> > > BufferedReadXtream and BufferedWriteXtream already are generic. It's > just that I have separated read
Re: [Pharo-project] SqueakSave on Pharo
Yanni excellent to have it on squeaksource. Now did you contact the maintainer (if any) or the people that developed it (I like it a lot) to mention that? Because at least they should know if some changes get introduced that they can cherrypick it. Stef On Feb 28, 2010, at 2:49 AM, Yanni Chiu wrote: > laurent laffont wrote: >> On Fri, Feb 19, 2010 at 9:24 PM, Yanni Chiu >>> >>> Can you put it on squeaksource ? >> >>I'll clean up the package I have, and then ping the author for how >>contributions are to be handled (before forking it on squeaksource). >>BTW, the HPI repository is now back online. > > Okay, it's at: > > http://www.squeaksource.com/SqueakSave > > SqSave-tkow.127.mcz - This version was created from the HPI version by > unzip'ing the .mcz, fixing the issues that prevented it from loading > into Pharo, by editing the source.st file, then re-zip'ing into a .mcz > package. > > SqSave-YanniChiu.135.mcz - This version was developed for my needs at > the time, then clean up somewhat for public release. Using the native > postgres driver (and probably dbx one too), the following 3 tests are > still failing: > SqsCTISearchQueryTest.testQueryBlob SqsCTISearchQueryTest.testReferenceToSubclassElementWithinCollection SqsSTISearchQueryTest.testQueryBlob > > > Some class category names were changed, and some example code left out. > The original .127.mcz should be loadable, so you can see what was > changed. The repository is set for global read/write. > > -- > Yanni > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Simple (but effective) Optimization of PackageOrganizer
Let us know. Seems to be a really big earthquake. Probably at santiago some old houses suffered but not the new ones. Stef On Feb 28, 2010, at 1:39 AM, Alexandre Bergel wrote: > Fortunately yes. I am currently on the seaside, these has been some > tsunami alert, but I haven't more than a very strong tide. > Wondering how I will find my flat in Santiago. > > Thanks for asking, > Alexandre > > > On 27 Feb 2010, at 08:17, Serge Stinckwich wrote: > >> I see that a big earthquake hit Chile : >> http://www.alertnet.org/thenews/newsdesk/LDE61Q02O.htm >> I hope everything is ok with you. >> >> On Fri, Feb 26, 2010 at 6:58 PM, Alexandre Bergel >> wrote: >>> issue #2085 >>> >>> Replace the method PackageOrganizer>>packageOfClass: aClass ifNone: >>> errorBlock by >>> -=-=-=-=-= >>> packageOfClass: aClass ifNone: errorBlock >>> | classCategory | >>> classCategory := aClass category. >>> packages at: classCategory ifPresent: [:v | ^ v]. >>> >>> (classCategory includes: $-) >>> ifTrue: [ packages at: (classCategory copyUpTo: $-) >>> ifPresent: [:v | >>> ^ v] ]. >>> >>> ^ self packages detect: [:ea | ea includesClass: aClass] >>> ifNone: >>> errorBlock >>> -=-=-=-=-= >>> >>> Before this enhancement: >>> [100 timesRepeat: [Object package]] timeToRun >>> => 141 >>> >>> After the fix: >>> => 2 >>> >>> Easy thing to do. >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >> Smalltalkers do: [:it | All with: Class, (And love: it)] >> http://doesnotunderstand.org/ >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] about code formatting in pharo
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Introducing Myself / FFI comments
Andreas Raab a écrit : > The *one* tradeoff I wasn't willing to make for the sake of my users was > to break their code; was to make their code non-loadable for absolutely > no benefit for these users. Cleaning up two methods and fifty lines of > code isn't worth breaking six years of work from lots of people. It > wasn't then, it isn't today. However, breaking code compatibility is very common in opensource world, probably to ease evolution. I remember to read somewhere it happens several time in Python, an alive and kicking community... ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
