- Pharo-dev - lists.pharo.org

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

by Toon Verwaest

What is the problem exactly? Do you somewhere rely on exact position in the complete string? What you could do is just keep line + column number since that stays fixed. Just increment newline on the systems newline sequence, and set column back to 0. On Apr 28, 2011 10:48 AM, "Tudor Girba" <tudor.girba(a)gmail.com> wrote: > 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

[Pharo-project] [update 1.3] #13174

by Marcus Denker

13174 ----- Issue 4099: Find and replace doesnt accept with Enter key Issue 4102: Show commit message only after successfully commiting a new version Issue 4108: remove authoringPrototype methods Issue 4105: Failing test: Tests.SystemChangeNotification.ChangeHooksTest.testMethodRemovedEvent2 Issue 4082: nil@nil Issue 4069: Object>>withArgs:executeMethod: should be removed we deprecate the specialized version (Prim 189), but keep #withArgs:executeMethod: for now until there is a primitive for CompiledMethod... (this is used for executing DoIts). For the next step, we will add another Issue later. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 28, 2011

Re: [Pharo-project] Preallocation behavior

by StÃ©phane Ducasse

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

April 28, 2011

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

by Tudor Girba

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

:). It can be improved in a number of ways. Instead of atAllPut:, it should be from:to:put: (so atAllPut: x should be self from: 1 to: self size put: x), it should do 8 or so at:put:s by hand before starting the loop, and it should keep a block of 2048 or so for the iteration (less memory traffic on the CPU that way, read *the same* 8kb or so all the time, write *different* 8kb each time). All of this is thoroughly explained and measured in the book. I forget the minute details right now, but tinkering with those details does make a difference. On 4/28/11 1:00 , Henrik Sperre Johansen wrote: > On 28.04.2011 09:30, Andres Valloud wrote: >> As a side comment, I do not know if an atAllPut: method I wrote back >> in about 2000 or so is still in the image... but if it is not, keep in >> mind that you can use something like replaceFrom:to:with:startingAt: >> using the receiver as the source of data, duplicating the amount of >> data copied each time. Back then, if you had to write the same object >> more than 26 or so times, it was faster to use the duplicating "block >> copy" method. The key is to avoid multiple primitive calls (which >> have expensive overhead compared to what is actually done), and >> replace them with a single primitive call that does a bunch of >> writes. With the duplication method, you could get away with doing >> 9000 writes in no more than 15 primitive calls. I wrote about this in >> much more detail in the Fundamentals volume 2 book. > It is. It's still beautiful :D > >> >> On 4/27/11 23:35 , jannik.laval wrote: >>> Hi all, >>> >>> I am playing with MessageTally, and I have a strange result with >>> prealocation. >>> Here is my example. I am working on a PharoCore1.3, with a VM4.2.5 >>> >>> 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. > > 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. > > ie. you are not measuring equivalent operations. > > That it only takes twice as long is due to Andres' excellent nextPutAll: > implementation :) > > Cheers, > Henry > . >

April 28, 2011

Re: [Pharo-project] Preallocation behavior

by Henrik Sperre Johansen

On 28.04.2011 09:30, Andres Valloud wrote: > As a side comment, I do not know if an atAllPut: method I wrote back > in about 2000 or so is still in the image... but if it is not, keep in > mind that you can use something like replaceFrom:to:with:startingAt: > using the receiver as the source of data, duplicating the amount of > data copied each time. Back then, if you had to write the same object > more than 26 or so times, it was faster to use the duplicating "block > copy" method. The key is to avoid multiple primitive calls (which > have expensive overhead compared to what is actually done), and > replace them with a single primitive call that does a bunch of > writes. With the duplication method, you could get away with doing > 9000 writes in no more than 15 primitive calls. I wrote about this in > much more detail in the Fundamentals volume 2 book. It is. It's still beautiful :D > > On 4/27/11 23:35 , jannik.laval wrote: >> Hi all, >> >> I am playing with MessageTally, and I have a strange result with >> prealocation. >> Here is my example. I am working on a PharoCore1.3, with a VM4.2.5 >> >> 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. 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. ie. you are not measuring equivalent operations. That it only takes twice as long is due to Andres' excellent nextPutAll: implementation :) Cheers, Henry

April 28, 2011

Re: [Pharo-project] Bug while updating PharoCore

by Marcus Denker

fixed. (by uploading the missing versions to squeaksource) On Apr 27, 2011, at 8:46 PM, Marcus Denker wrote: > > I added a tracker entry: > > http://code.google.com/p/pharo/issues/detail?id=4104 > > I will see how to fix that. > > On Apr 27, 2011, at 5:59 PM, Casimiro de Almeida Barreto wrote: > >> While loading 13171-Pha-CleanupsFinderSearch debugger is raised with >> Message not understood: Receiver of "load" is nil >> >> and: >> >> DoIt >> | t1 | >> t1 := MCHttpRepository >> location: 'http://www.squeaksource.com/Pharo/' >> user: '' >> password: ''. >> (t1 loadVersionFromFileNamed: 'ScriptLoader13-MarcusDenker.191.mcz') >> load. >> ^ ScriptLoader new update13171 >> >> Meaning ScriptLoader13-MarcusKender.191.mcz is not there or squeaksource >> is down... >> > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 28, 2011

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

by Mariano Martinez Peck

On Thu, Apr 28, 2011 at 5:56 AM, Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > On Wed, Apr 27, 2011 at 3:21 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > > Hi. IMPORTANT: This is not the final 1.3 release, it just one simple > > snapshot and one point. We all want a rock-solid Pharo 1.3 release, but > that > > doesn't happens automagically. We all need to start using and testing the > > image before they are release. It is for the better of all of us. The > more > > we test the more stable will be the release. So...we need your help. What > > you can do? > > > > 1) test test test test test. Use it. Take this image and use it for your > > regular work. > > 2) report bugs: http://www.pharo-project.org/community/issue-tracking > > 3) propose fixes: http://code.google.com/p/pharo/wiki/HowToContribute > > 4) Fix errors/failures tests > > 5) Load your OWN packages and projects now. Don't wait until Pharo1.3 is > > released and then ask "uuhh what happened to XXX? you removed? ohhh but I > > use it". > > 6) Do you maintain Metacello configurations? ok, if you test your > project > > and works correctly in Pharo 1.3, please update (or create if you don't > yet > > have it) the #stable, > > 7) Do you maintain packages included in Pharo? please check we are using > > the correct versions > > 8) I would like to see people testing AidaWeb, Magma, Fuel, Moose, > DBXTalk, > > Seaside and all its friends, Zinc, FileSystem, etc, etc, etc. > > > > Pharo-1.3-13173 should work with Interpreter VM and with Cog. For Cog I > > recommend to download the last one from Eliot's page: > > http://www.mirandabanda.org/files/Cog/VM/ > > I try with VM Squeak 4.2.5beta1U on mac os x 10.6.7 but the image is > not launch at all. > No problem to launch the image with last cog VM. > > grrrr sorry my bad. I opeed the image (with cog) to re-save it with another name. If you take the one from hudson (same image) it should work: https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.3/111/ > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > -- Mariano http://marianopeck.wordpress.com

April 28, 2011

Re: [Pharo-project] Preallocation behavior

by Andres Valloud

As a side comment, I do not know if an atAllPut: method I wrote back in about 2000 or so is still in the image... but if it is not, keep in mind that you can use something like replaceFrom:to:with:startingAt: using the receiver as the source of data, duplicating the amount of data copied each time. Back then, if you had to write the same object more than 26 or so times, it was faster to use the duplicating "block copy" method. The key is to avoid multiple primitive calls (which have expensive overhead compared to what is actually done), and replace them with a single primitive call that does a bunch of writes. With the duplication method, you could get away with doing 9000 writes in no more than 15 primitive calls. I wrote about this in much more detail in the Fundamentals volume 2 book. On 4/27/11 23:35 , jannik.laval wrote: > Hi all, > > I am playing with MessageTally, and I have a strange result with > prealocation. > Here is my example. I am working on a PharoCore1.3, with a VM4.2.5 > > First of all, I spy this source code: > ==== > MessageTally spyOn: > [ 500 timesRepeat: [ > | str | > *str := ''*. > 9000 timesRepeat: [ str := str, 'A' ]]]. > ==== > > 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] Preallocation behavior

by Andres Valloud

Maybe in the last case you also need to send nextPut: instead of nextPutAll:... On 4/27/11 23:35 , jannik.laval wrote: > Hi all, > > I am playing with MessageTally, and I have a strange result with > prealocation. > Here is my example. I am working on a PharoCore1.3, with a VM4.2.5 > > First of all, I spy this source code: > ==== > MessageTally spyOn: > [ 500 timesRepeat: [ > | str | > *str := ''*. > 9000 timesRepeat: [ str := str, 'A' ]]]. > ==== > > 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