- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Preallocation behavior

by Henrik Sperre Johansen

On 28.04.2011 12:35, Toon Verwaest wrote: > On 04/28/2011 12:34 PM, Henrik Sperre Johansen wrote: >> On 28.04.2011 11:27, StÃ©phane Ducasse wrote: >>> may be you could add a bug entry on the cog tracker >>> >>> stef >> It's not a bug, it's a feature. >> >> Cheers, >> Henry >> > That it only works on non-readwrite streams? > No, that it's not implemented at all in Cog. (which is what I assume Steph was talking about since he mentioned the cog tracker) The "only works on non-readwrite streams"-bug in "standard" vm's was fixed in VMMaker-dtl.153 as mentioned in the thread I linked, so the definition of "newish" would be any VM built with sources newer than that. Cheers, Henry

April 28, 2011

Re: [Pharo-project] [ANN] PharoDev-1.3-13173

by Philippe Marschall

On 04/27/2011 06:37 PM, Marcus Denker wrote: > > On Apr 27, 2011, at 6:27 PM, Philippe Marschall wrote: >> >> - OBDefinition >> #doItReceiver references FakeClassPool >> > > This can not be. I added FakeClassPool back to the Deprecated13 package some > updates ago. Although I downloaded the latest Core it still had several updates not applied because of some SqueakSource troubles. So it can be that I simply miss those updates. Cheers Philippe

April 28, 2011

Re: [Pharo-project] how to deal with string position in relation to cr/crlf

by Alexandre Bergel

I experienced a similar problem when I worked on CAnalyzer. What I did is simply to remove all lf characters before doing anything. Alexandre Le 28 avr. 2011 Ã 04:47, Tudor Girba <tudor.girba(a)gmail.com> a Ã©crit : > Hi, > > I have a small problem related to file line endings and storing the token information of PetitParser. > > Sometimes, we parse the sources on Windows and then manipulate the model on Linux or Mac. In this context, if I store the token positions in a string, I encounter problems because CR and LF are considered characters, but the line endings can vary. > > ('abc', Character cr asString , 'd') findString: 'd'. > ==> 5 > > ('abc', Character cr asString , Character lf asString, 'd') findString: 'd'. > ==> 6 > > > How would you approach this problem? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Every thing has its own flow." > > > > >

April 28, 2011

Re: [Pharo-project] Preallocation behavior

by Nicolas Cellier

IMHO, you would need a stream equivalent of atAll:put: maybe something like stream next: 900 put: $A. It would write directly to destination and save a copy versus say stream nextPutAll: (String new: 900 withAll: $A) 2011/4/28 Toon Verwaest <toon.verwaest(a)gmail.com>: > On 04/28/2011 08:35 AM, jannik.laval wrote: > > First of all, I spy this source code: > ==== > MessageTally spyOn: > Â Â Â [ 500 timesRepeat: [ > Â Â Â Â Â Â Â Â Â Â Â | str | > Â Â Â Â Â Â Â Â Â Â Â str := ''. > Â Â Â Â Â Â Â Â Â Â Â 9000 timesRepeat: [ str := str, 'A' ]]]. > ==== > > This is what Joel Spolsky called a "Shlemiel the Painter's algorithm" > http://www.joelonsoftware.com/articles/fog0000000319.html > > It's obviously very slow and it's very different from the code below for > obvious reasons. > > Other /languages that won't be named/ just do hacks to allow you to think in > terms of string concatenation while it's optimized internally using buffers. > This works well to make programs by dummies faster, but it also dumbs down > programmers since you forget that stuff actually needs to be done. > > The result appears after 24 961 ms. > An optimization is to use a Stream. Here is my source code: > === > MessageTally spyOn: > Â Â Â [ 500 timesRepeat: [ > Â Â Â Â Â Â Â Â Â Â Â | str | > Â Â Â Â Â Â Â Â Â Â Â str := WriteStream on: (String new). > Â Â Â Â Â Â Â Â Â Â Â 9000 timesRepeat: [ str nextPut: $A ]]]. > === > The result appears after 812 ms, which is a large improvement. > Now, we could optimize again using the preallocation. Here is my source > code: > ==== > MessageTally spyOn: > Â Â Â [ 500 timesRepeat: [ > Â Â Â Â Â Â Â Â Â Â Â | str | > Â Â Â Â Â Â Â Â Â Â Â str := WriteStream on: (String new: 10000). > Â Â Â Â Â Â Â Â Â Â Â 9000 timesRepeat: [ str nextPutAll: 'A' ]]]. > ==== > And the result is strange: it makes 2 times slower to display the result. > The result appears after 1656 ms. > Here is the spy result: > === > Â - 1656 tallies, 1656 msec. > **Tree** > -------------------------------- > Process: (40s) Â 464519168: nil > -------------------------------- > **Leaves** > 22.9% {380ms} UndefinedObject>>DoIt > 22.5% {373ms} SmallInteger(Integer)>>timesRepeat: > 22.2% {368ms} WriteStream>>nextPutAll: > === > There is the call of UndefinedObject>>DoIt which is added and takes time. > Does anyone know what is done during the preallocation ? > Why is it slower than non-preallocation ? > Thanks for your answers. > Jannik >

April 28, 2011

Re: [Pharo-project] GitFs / MCGit

by Mariano Martinez Peck

On Wed, Apr 27, 2011 at 10:09 PM, Camillo Bruni <camillo.bruni(a)inria.fr>wrote: > Lukas once implemented a small MC Repository type that simple stores the > source.st in a git repository. And what it does with the rest of the files of the .mcz ? like the snapshot binary ? > Due to changes in the recent pharo versions some of the git code didn't > work anymore. So that's fixed now and you can use git for storing monticello > versions. > > The following uses a local git repos as a monticello repository: > > MCGitRepository directory: 'test_git' > > Of course it is not fully useful since it uses a single file to store > everything, rendering normal git tools unusable. Hence I will experiment > tomorrow a bit on how to split up methods and classes into something more > representable. I guess the trickiest part will be to tell git how methods > and classes changed when they are renamed, but even that should not be such > a problem.. > > In short, I will use github and share my code with the rest of the world > ;). > > camillo > > > On 2011-04-27, at 21:50, Tudor Girba wrote: > > > Hi, > > > > I am not sure I understand the implication. Could you explain, please? :) > > > > Cheers, > > Doru > > > > > > On 27 Apr 2011, at 21:37, Camillo Bruni wrote: > > > >> Thanks for your help :) > >> > >> So Lukas Git Repository for Monticello works again. ByeBye sqeaksource > for me... ;) > >> > >> On 2011-04-27, at 19:14, Max Leske wrote: > >> > >>> Concerning 2: > >>> No, it doesn't make sense at all to return nil. The reason that no > exception is signalled is simply that that case should never be possible > (not really an argument, I know :D). The method #packedObjectWithSignature > is only sent if no loose object could be found. Then the packs are scanned > and if the object isn't found in the packs the method returns nil. > >>> > >>> I think an exception would make a lot of sense but I didn't implement > an exception handling mechanism for FSGit so a user will get slapped in the > face with a debugger. Better though than having to track down that nil > bug... > >>> > >>> > >>> On 27.04.2011, at 16:21, Camillo Bruni wrote: > >>> > >>>> Hi Max, > >>>> > >>>> I took another effort to work on the git bindings of MC. > >>>> However I ran into troubles with FSGitFilesystem on commiting. > >>>> > >>>> 1. I fail when saving the repos in GitCommit >> parents when it starts > to lazily load the object which does not exist yet... > >>>> > >>>> 2. GitRespository >> packedObjectWithSignature: aGitObjectSignature > >>>> does not throw an exception but simply returns nil? does this make > sense? > >>>> > >>>> > >>>> maybe you have a clue how to solve this faster than I do :-) > >>>> > >>>> camillo > >>> > >>> > >> > >> > > > > -- > > www.tudorgirba.com > > > > "There are no old things, there are only old ways of looking at them." > > > > > > > > > > > -- Mariano http://marianopeck.wordpress.com

April 28, 2011

Re: [Pharo-project] XML and DTD

by Damien Cassou

On Thu, Apr 28, 2011 at 11:58 AM, Olivier Auverlot <olivier.auverlot(a)gmail.com> wrote: > Now, I'm playing with XML-Parser. It's a funny game but I have a little > question. How to validate a XML file with a DTD ? I don't know about your question. However, you may also want to try this parser: http://source.lukas-renggli.ch/petit -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

April 28, 2011

Re: [Pharo-project] Preallocation behavior

by Toon Verwaest

On 04/28/2011 12:34 PM, Henrik Sperre Johansen wrote: > On 28.04.2011 11:27, StÃ©phane Ducasse wrote: >> may be you could add a bug entry on the cog tracker >> >> stef > It's not a bug, it's a feature. > > Cheers, > Henry > That it only works on non-readwrite streams?

April 28, 2011

Re: [Pharo-project] Preallocation behavior

by Henrik Sperre Johansen

On 28.04.2011 11:27, StÃ©phane Ducasse wrote: > may be you could add a bug entry on the cog tracker > > stef It's not a bug, it's a feature. Cheers, Henry

April 28, 2011

Re: [Pharo-project] Preallocation behavior

by Henrik Sperre Johansen

On 28.04.2011 12:12, Toon Verwaest wrote: > nextPut: anObject > "Primitive. Insert the argument at the next position in the Stream > represented by the receiver. Fail if the collection of this stream > is not an > Array or a String. Fail if the stream is positioned at its end, or > if the > position is out of bounds in the collection. Fail if the argument > is not > of the right type for the collection. Optional. See Object > documentation > whatIsAPrimitive." > > <primitive: 66> > position >= writeLimit > ifTrue: [^ self pastEndPut: anObject] > ifFalse: > [position := position + 1. > ^collection at: position put: anObject] > > The primitive will only fail if you are trying to write past the end. > This check is very fast since it's primitive... and we'll only go in > Smalltalk code when it fails. The first version on the other hand is > always first some smalltalk code (quite a lot for your basic example) > before it goes into a slightly more heavy primitive > (replaceFrom:to:with:startingAt:). To be exact, the primitive always fails on Cog (not implemented, jitted version is just as fast), and only works for non-ReadWriteable streams on newish (last year or so) VM's :) http://forum.world.st/Bug-in-Interpreter-gt-gt-primitiveNextPut-td788236.ht… The constant overhead is still lower than nextPutAll: of course. Cheers, Henry

April 28, 2011

Re: [Pharo-project] Preallocation behavior

by Henrik Sperre Johansen

On 28.04.2011 10:49, StÃ©phane Ducasse wrote: > Henrik > > you lost me > >> In the first example, you are making a single string with all A's of size 9000 repeated 500 times. >> In the second example, you are making 9000 strings with all A's of size 10000 repeated 500 times. > Why? My bad, I misread and thought the code was using atAllPut: , like it should :) (that is, if its intent is to initialize a presized collection with default values) MessageTally spyOn: [ 500 timesRepeat: [ | str | str :=String new: 9000. str atAllPut: $A ]]. only takes a couple of milliseconds. As for nextPut: vs nextPutAll:, that is to be expected. nextPutAll: is optimized for sizes> 1, on my machine it "catches up" when you surpass 4 characters added in each loop. Cheers, Henry

April 28, 2011