April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Counting Messages as a Proxy for Average Execution Time in Pharo

by Michael Haupt

Alex, On 28 April 2011 15:37, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Counting messages is, in the average, closely link to the average execution time. I believe this is correct only as long as a purely interpreting VM is used, even though quick messages add a tiny bit of uncertainty. But add a JIT compiler and some inlining, and timeToRun and MessageTally are suddenly interesting again. Not having read your text, I surely cannot say anything remotely conclusive, but the assumption that execution time roughly equals the amount of messages sent seems rather naÃ¯ve once you leave the cosy well-predictable niche inhabited by pure interpreters. Best, Michael

April 28, 2011

Re: [Pharo-project] XML and DTD

by StÃ©phane Ducasse

On Apr 28, 2011, at 11:58 AM, Olivier Auverlot wrote: > Hi, > > 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 do not know. In VisualWorks there was a kind of validator now in XMLwriter....package I do not know. > > Thank for your help. > > Best regards > Olivier ;-) > > www.auverlot.fr >

April 28, 2011

[Pharo-project] Smalltalk position in Germany

by stephane ducasse

Hi guys HRWorks is looking for a good smalltalker (with potentially some german knowledge). If you are interested contact Thomas Holzer <thomas.holzer(a)hrworks.de> Stef

April 28, 2011

Re: [Pharo-project] Preallocation behavior

by jannik.laval

Hi all, thank you for the information. In fact, Alex you are right, I have a nextPutAll: that I should replace. Cheers, Jannik On Apr 28, 2011, at 15:02 , Alexandre Bergel wrote: > Hi Jannik, > >> === >> 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' ]]]. >> ==== > > In the first case you use nextPut:, in the second case you use nextPutAll:. > Replacing nextPutAll: by nextPut: gives me coherent result. > > 330 ms for the first, and 321 for the second (with the preallocation). > > Alexandre > > >> 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 > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

April 28, 2011

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