- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Delay startTimerInterruptWatcher in ScriptLoader >> cleanUpMethods -> DNU

by Mariano Martinez Peck

On Sun, Feb 28, 2010 at 1:17 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > I would remove cleanUpMethods and move what is worth and working to > cleanUpForRelease. > > Ok...I've created the issue: http://code.google.com/p/pharo/issues/detail?id=2100 > 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(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 1, 2010

Re: [Pharo-project] SqueakSave on Pharo

by Mariano Martinez Peck

On Sun, Feb 28, 2010 at 2:49 AM, Yanni Chiu <yanni(a)rogers.com> 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 > the dbx will work with Blob ONLY in the latests commits...as I have been playing with that few weeks ago. > 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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 1, 2010

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

by Schwab,Wilhelm K

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-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Sunday, February 28, 2010 4:17 PM To: Pharo-project(a)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-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of >> Adrian Lienhard >> Sent: Sunday, February 28, 2010 8:11 AM >> To: Pharo-project(a)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(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 28, 2010

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

by StÃ©phane Ducasse

lol I was really skeptical :) >> :ind | at the beginning of the line. > > Ahh, that was the mail program that broke it there.

Feb. 28, 2010

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

by Lukas Renggli

On 28 February 2010 22:38, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> 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(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 28, 2010

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

by StÃ©phane Ducasse

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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 28, 2010

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

by Nicolas Cellier

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

Feb. 28, 2010

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

by Lukas Renggli

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 <adi(a)netstyle.ch> 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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 28, 2010

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

by Adrian Lienhard

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

Feb. 28, 2010

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

by Lukas Renggli

>> 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

Feb. 28, 2010