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

Re: [Pharo-project] package renaming

by Mariano Martinez Peck

On Mon, Sep 26, 2011 at 9:39 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > Hi, > > do we have some experiences with renaming some of basic system > packages in the update stream? Because we will need to rename Morphic > package to something like Morphic-Core or so to enable the next > Morphic package splitting. > Be aware of method extensions. They are not taken into account at all. > > Cheers, > -- Pavel > > -- Mariano http://marianopeck.wordpress.com

Sept. 26, 2011

[Pharo-project] package renaming

by Pavel Krivanek

Hi, do we have some experiences with renaming some of basic system packages in the update stream? Because we will need to rename Morphic package to something like Morphic-Core or so to enable the next Morphic package splitting. Cheers, -- Pavel

Sept. 26, 2011

[Pharo-project] [update 1.4] #14164

by Marcus Denker

14164 ----- Issue 4770: Change the way changes are displayed into the changes browser of Monticello http://code.google.com/p/pharo/issues/detail?id=4770 Issue 4493: remove BDFFontReader and friends http://code.google.com/p/pharo/issues/detail?id=4493 Issue 4624: Shout Setting does not show up in the Setting Browser. http://code.google.com/p/pharo/issues/detail?id=4624 Issue 4854: must enforce class name checking and check class name when renaming of copying a class http://code.google.com/p/pharo/issues/detail?id=4854 -- Marcus Denker -- http://marcusdenker.de

Sept. 26, 2011

[Pharo-project] [ANN] Pharo Glorp port release

by Guillermo Polito

Hi! We are reaaaaally happy to announce (at last) a very very stable release of the new Glorp port :D. We've done a lot to achieve the following results with Glorp: OpenDBX Oracle: - 7 errors related to Blobs, which are not supported by opendbx. - 1 failure related to timestamp cast (and I don't understand the test intention yet :P) OpenDBX MySql: - 100% green tests :D OpenDBX PostgreSQL: - 7 errors and 1 failure related to Blobs, which are not supported by opendbx (again). OpenDBX SQLite: - 6 failures related to large objects, which are not supported by opendbx (again again).. 2 (expected) failures related to times & dates. Native PostgresV2 Driver: - 2 failures with blobs So far, some FAQs: *Â¿What is the difference between this port and the old one?* Almost 4 years of work of the VW team with tons of bugfixing (see the last 4 years release notes from Glorp for more detail :P) *Â¿How can I load it?* If you want to load Glorp + OpenDBX, you can try the following: *Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfGlorpDBX'; load. (((Smalltalk at: #ConfigurationOfGlorpDBX) perform: #project) perform: #version: with: #stable) load* Also, you can try loading only Glorp (maybe because you want to integrate it with your own database driver): Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfGlorp'; load. (((Smalltalk at: #ConfigurationOfGlorp) perform: #project) perform: #version: with: #stable) load *Â¿How did we test it?* We've tested it in Pharo 1.2 and Pharo 1.3 + Jenkins CogVms. *Â¿What's coming next?* *We are working for your happiness (?).* Hehe, our next step is to release the DBXMagritte project, which aims to allow people working in the Software business to create easy CRUD -the same scaffolding idea from RoR for example- including some of the following features: - (create a class model + magritte descriptions) from a database schema - [if you already have a descripted class model] use magritte descriptions to create a database schema - use magritte descriptions to create glorp mappings And then, you can use the same descriptions for your Seaside app, or in every magritte-friend framework you like ;) So, thanks again to ESUG for sponsoring the project :). Guillermo, Santiago, Gisela, Mariano, Esteban and Diogenes

Sept. 26, 2011

Re: [Pharo-project] PetitSmalltalk: now with a self-contained grammar for number literals

by StÃ©phane Ducasse

thanks for the analysis I ejoyed reading it. Stef On Sep 25, 2011, at 4:21 PM, Nicolas Cellier wrote: > 2011/9/25 Frank Shearar <frank.shearar(a)gmail.com>: >> Nicolas, you'd mentioned a log_2 n implementation for number parsing. >> I think by that you mean the division of digits into two "packets" >> that are processed and then added? >> >> I tried a straight-forward fold (using the * 10 that you said you didn't like!) >> >> Time millisecondsToRun: [10000 timesRepeat: >> ['123456789012345678901234567890' inject: 0 into: [:acc :each | 10 * >> acc + each digitValue]]] => 818 >> >> and what I think you meant: >> >> | f | >> f := 1. "Just to shut the compiler up about the self-reference." >> f := [:someDigits | | len | >> len := someDigits size. >> (len = 1) >> ifTrue: [someDigits first digitValue] >> ifFalse: [ | leftHalf rightHalf | >> leftHalf := someDigits first: len // 2. >> rightHalf := someDigits allButFirst: len // 2. >> ((f value: (leftHalf)) * (10 raisedTo: rightHalf size)) + (f value: >> rightHalf)]]. >> Time millisecondsToRun: [10000 timesRepeat: [f value: >> '123456789012345678901234567890']] => 1508 >> >> I went with the straight-forward fold because it was simpler and my >> (quite possibly wrong/inefficient) attempt at a log_2 n version was a >> lot less readable. >> >> I'd greatly appreciate being gently corrected! >> >> frank >> > > Hmm, let's see. > > Suppose that SmallIntegers are on 3 digits, and Large begins at 4. > And let's compose a 32 digits number 12345678901234567890123456789012 > > If I do the naive loop the first 3 loops (6 ops) give small ints. > Then the next 29 loops (58 ops) are performed with large ints. > > Now, if I perform these ops: > > ((1234 * (10**4) + 5678) * (10**8) + (9012 * (10**4) + 3456)) * > (10**16) + ((7890 * (10**16) + 1234) * (10**8) + (5678 * (10**4) + > 9012)) > > This time, I have 24 loops with small int (48 ops) and 8 loops (16 > ops) with large ints for evaluating the 4 digits ints. > Plus 14 operations to assemble these large ints into the final result. > Plus a number of operations required to evaluate the powers of 10: > without cache, this is > > 10**4 = 10 squared squared (1 small op + 1 large) * 4 times. > 10**8 = 10 squared squared squared (1 small op + 2 large) * 2 times. > 10**16 = 10 squared squared squared (1 small op + 3 large) * 1 time. > > The total is 55 ops on small ints + 41 ops on large ints. > So the second algorithm costs more operations on total, but cheaper ones. > Suppose every operation on SmallInteger costs 1 and LargeInteger costs 10, > we have a cost of 586 for the first, 465 for the second. > > Also, the cost of Large int operations is not constant. > It is proportional to max(length1,length2) for + and to length1*length2 for *. > So, we'll consider length(10**n)=n. > In first case, length2=1 and length1 is varying linearly between 4 and > 32, thus a mean of 18*2 digit ops per loop * 29 loops. > > In the second case, the cost in digit ops is: > 1) (3*1+4) per loop * 8 loops for forming the 4 digits elementary large ints > 2) (4*4+8) per loop * 4 loops for forming the 8 digits large ints > 3) (8*8+16) per loop * 2 loops for forming the 16 digits large ints > 4) (16*16+32) for the last iteration > > Plus the costs of evaluating powers of 10: > 1) (100 squared) is evaluated 7 times * (2*2) digit ops > 2) (10000 squared) is evaluated 3 times * (4*4) digit ops > 3) (100000000 squared) is evaluated 1 times * (8*8) digit ops > > grand total is 18*2*29 = 1044 digit ops for the naive algorithm > For the divide and conquer form, that is ((3*1+4)*8) + ((4*4+8)*4) + > ((8*8+16)*2) + (16*16+32) + (2*2*7) + (4*4*3) + (8*8) = 740 > > In your 30 decimal digits example, large integers are formed of 10 > decimal digits (SmallInteger maxVal + 1) printString size, so we would > have to translate above count... > But it's boring, we can lazily bench it: > > | stream | > stream := '123456789012345678901234567890' readStream. > { > [stream reset; nextFloat] bench. > [stream reset. Number readFrom: stream] bench. > } > #('15,600 per second.' '23,500 per second.') "Old 4.2 VM" > #('56,100 per second.' '97,700 per second.') "recent COG VM" > > Stream>>nextFloat is a naive loop with almost every operation inlined. > Number>>readFrom: traverses a bunch of sends before the real > operations take place. > > The overhead equlibrates around 12 decimal digits in non COG VM ! > That's why it was already faster for scanning a 15 digits Float (non > counting the fact that nextFloat fails to answer the nearest Float). > Now, in COG, it equilibrates around 20 digits. > > If we want to draw the cost versus log of number of digits: > > | gen counts serie cost1 cost2 | > gen := Generator on: [:g | [g yield: '1234567890' atRandom] repeat]. > counts := (2 to: 13) collect: [:e | 2 raisedTo: e]. > serie := counts collect: [:count | > String withAll: (gen next: count)]. > cost1 := serie collect: [:e | > [1000 timesRepeat: [e readStream nextFloat]] timeToRun]. > cost2 := serie collect: [:e | > [1000 timesRepeat: [(Number readFrom: e readStream) asFloat]] timeToRun]. > {counts. cost1. cost2.} > #("NON COG VM" > #(4 8 16 32 64 128 256 512 1024 2048 4096 8192) > #(2 2 25 65 146 304 647 1412 3288 8393 24021 77189) > #(6 6 21 51 94 177 361 742 1550 3872 8471 22647)) > > #("COG VM" > #(4 8 16 32 64 128 256 512 1024 2048 4096 8192) > #(0 2 3 20 56 139 334 838 2323 7010 23614 85925) > #(2 0 4 13 24 53 116 264 626 1646 4552 14191)) > > It's not a log_2 cost at the end, but it's already some gain. > It's possible that above costs are dominated by garbage collection, > but I don't know how to measure that accurately... > > Nicolas > >> On 14 September 2011 20:26, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>> On 3 September 2011 19:35, Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> 2011/9/3 Frank Shearar <frank.shearar(a)gmail.com>: >>>>> On 3 September 2011 18:50, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>>> I think it is a good idea to have the number parser separate, after >>>>>> all it might also make sense to use it separately. >>>>>> >>>>>> It seems that the new Smalltalk grammar is significantly slower. The >>>>>> benchmark PPSmalltalkClassesTests class>>#benchmark: that uses the >>>>>> source code of the collection hierarchy and does not especially target >>>>>> number literals runs 30% slower. >>>>>> >>>>>> Also I see that "Number readFrom: ..." is still used within the >>>>>> grammar. This seems to be a bit strange, no? >>>>> >>>>> Yes: it's a double-parse, which is a bit lame. First, we parse the >>>>> literal with PPSmalltalkNumberParser, which ensures that the thing >>>>> given to Number class >> #readFrom: is a well-formed token (so, in >>>>> particular, Squeak's Number doesn't get to see anything other than a >>>>> well-formed token). >>>>> >>>>> It sounds like you're happy with the basic concept, so maybe I should >>>>> remove the Number class >> #readFrom: stuff, see if I can't remove the >>>>> performance issues, and resubmit the patch. >>>>> >>>>> frank >>>>> >>>> >>>> Yes, a NumberParser is essentially parsing, and this duplication sounds useless. >>>> The main feature of interest in NumberParser that I consider a >>>> requirement and should find its equivalence in a PetitNumberParser is: >>>> - round a decimal representation to nearest Float >>>> It's simple, just convert a Fraction asFloat in a single final step to >>>> avoid cumulating round off errors - see >>>> #makeFloatFromMantissa:exponent:base: >>>> >>>> The second feature of interest in NumberParser is the ability to >>>> parser LargeInteger efficiently by avoiding (10 * largeValue + >>>> digitValue) loops, and replacing them with a log(n) cost. >>>> This would be a simple thing to implement in a functional language. >>> >>> Hopefully this won't offend your sensibilities too much :). It does, >>> in fact, use 10* loops - I wrote an experimental "front half * rear >>> half" recursion, which was slower in my benchmarks. >>> >>> This version has the grammar and parser doing no string->number >>> conversion at all. PPSmalltalkNumberMaker supplies a number of utility >>> methods designed to stop one from making malformed numbers. It also >>> supplies a builder interface that the parser uses to construct >>> numbers. >>> >>> frank >>> >>>> Nicolas >>>> >>>>>> Lukas >>>>>> >>>>>> >>>>>> On 3 September 2011 17:18, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>>>>>> On 3 September 2011 15:56, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>>>>> On 3 September 2011 16:51, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>>>>>>>> Hi Lukas, >>>>>>>>> >>>>>>>>> I haven't :) mainly because I'm unsure where to put it - is there >>>>>>>>> perhaps a PP Inbox, or shall I just post the merged version, or what's >>>>>>>>> your preference? (How about an mcd between my merge and PP's head?) >>>>>>>> >>>>>>>> Just put the .mcz at some public URL (dropbox, squeak source, ...) or >>>>>>>> attach it to a mail. >>>>>>> >>>>>>> Ah, great - here it is. You'll see I've written the grammar as a >>>>>>> separate class. That was really more to make what I'd done more >>>>>>> obvious and to minimise the change to PPSmalltalkGrammar, but perhaps >>>>>>> it's not a bad idea anyway: it's easy to see the number literal >>>>>>> subgrammar. >>>>>>> >>>>>>> frank >>>>>>> >>>>>>>> Lukas >>>>>>>> >>>>>>>> -- >>>>>>>> Lukas Renggli >>>>>>>> www.lukas-renggli.ch >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Lukas Renggli >>>>>> www.lukas-renggli.ch >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> >

Sept. 25, 2011

Re: [Pharo-project] Class creation notification

by StÃ©phane Ducasse

indeed. >> > Yes, it will be totally unsafe, if tools hold caches relying on the > notifications for invalidation (which is entirely appropriate). > A better solution would be to provide bulk notifications, so instead of > sending a notification to subscribers once for each class added, you update > them only once, after all classes are created. > Same holds true for other kind of system changes. > > Cheers, > Henry > > -- > View this message in context: http://forum.world.st/Class-creation-notification-tp3837570p3841078.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Sept. 25, 2011

Re: [Pharo-project] PetitSmalltalk: now with a self-contained grammar for number literals

by Nicolas Cellier

2011/9/25 Frank Shearar <frank.shearar(a)gmail.com>: > Nicolas, you'd mentioned a log_2 n implementation for number parsing. > I think by that you mean the division of digits into two "packets" > that are processed and then added? > > I tried a straight-forward fold (using the * 10 that you said you didn't like!) > > Time millisecondsToRun: [10000 timesRepeat: > ['123456789012345678901234567890' inject: 0 into: [:acc :each | 10 * > acc + each digitValue]]] => 818 > > and what I think you meant: > > | f | > f := 1. "Just to shut the compiler up about the self-reference." > f := [:someDigits | | len | > Â Â Â Â len := someDigits size. > Â Â Â Â (len = 1) > Â Â Â Â Â Â Â Â ifTrue: [someDigits first digitValue] > Â Â Â Â Â Â Â Â ifFalse: [ | leftHalf rightHalf | > Â Â Â Â Â Â Â Â Â Â Â Â leftHalf := someDigits first: len // 2. > Â Â Â Â Â Â Â Â Â Â Â Â rightHalf := someDigits allButFirst: len // 2. > Â Â Â Â Â Â Â Â Â Â Â Â ((f value: (leftHalf)) * (10 raisedTo: rightHalf size)) + (f value: > rightHalf)]]. > Time millisecondsToRun: [10000 timesRepeat: [f value: > '123456789012345678901234567890']] => 1508 > > I went with the straight-forward fold because it was simpler and my > (quite possibly wrong/inefficient) attempt at a log_2 n version was a > lot less readable. > > I'd greatly appreciate being gently corrected! > > frank > Hmm, let's see. Suppose that SmallIntegers are on 3 digits, and Large begins at 4. And let's compose a 32 digits number 12345678901234567890123456789012 If I do the naive loop the first 3 loops (6 ops) give small ints. Then the next 29 loops (58 ops) are performed with large ints. Now, if I perform these ops: ((1234 * (10**4) + 5678) * (10**8) + (9012 * (10**4) + 3456)) * (10**16) + ((7890 * (10**16) + 1234) * (10**8) + (5678 * (10**4) + 9012)) This time, I have 24 loops with small int (48 ops) and 8 loops (16 ops) with large ints for evaluating the 4 digits ints. Plus 14 operations to assemble these large ints into the final result. Plus a number of operations required to evaluate the powers of 10: without cache, this is 10**4 = 10 squared squared (1 small op + 1 large) * 4 times. 10**8 = 10 squared squared squared (1 small op + 2 large) * 2 times. 10**16 = 10 squared squared squared (1 small op + 3 large) * 1 time. The total is 55 ops on small ints + 41 ops on large ints. So the second algorithm costs more operations on total, but cheaper ones. Suppose every operation on SmallInteger costs 1 and LargeInteger costs 10, we have a cost of 586 for the first, 465 for the second. Also, the cost of Large int operations is not constant. It is proportional to max(length1,length2) for + and to length1*length2 for *. So, we'll consider length(10**n)=n. In first case, length2=1 and length1 is varying linearly between 4 and 32, thus a mean of 18*2 digit ops per loop * 29 loops. In the second case, the cost in digit ops is: 1) (3*1+4) per loop * 8 loops for forming the 4 digits elementary large ints 2) (4*4+8) per loop * 4 loops for forming the 8 digits large ints 3) (8*8+16) per loop * 2 loops for forming the 16 digits large ints 4) (16*16+32) for the last iteration Plus the costs of evaluating powers of 10: 1) (100 squared) is evaluated 7 times * (2*2) digit ops 2) (10000 squared) is evaluated 3 times * (4*4) digit ops 3) (100000000 squared) is evaluated 1 times * (8*8) digit ops grand total is 18*2*29 = 1044 digit ops for the naive algorithm For the divide and conquer form, that is ((3*1+4)*8) + ((4*4+8)*4) + ((8*8+16)*2) + (16*16+32) + (2*2*7) + (4*4*3) + (8*8) = 740 In your 30 decimal digits example, large integers are formed of 10 decimal digits (SmallInteger maxVal + 1) printString size, so we would have to translate above count... But it's boring, we can lazily bench it: | stream | stream := '123456789012345678901234567890' readStream. { [stream reset; nextFloat] bench. [stream reset. Number readFrom: stream] bench. } #('15,600 per second.' '23,500 per second.') "Old 4.2 VM" #('56,100 per second.' '97,700 per second.') "recent COG VM" Stream>>nextFloat is a naive loop with almost every operation inlined. Number>>readFrom: traverses a bunch of sends before the real operations take place. The overhead equlibrates around 12 decimal digits in non COG VM ! That's why it was already faster for scanning a 15 digits Float (non counting the fact that nextFloat fails to answer the nearest Float). Now, in COG, it equilibrates around 20 digits. If we want to draw the cost versus log of number of digits: | gen counts serie cost1 cost2 | gen := Generator on: [:g | [g yield: '1234567890' atRandom] repeat]. counts := (2 to: 13) collect: [:e | 2 raisedTo: e]. serie := counts collect: [:count | String withAll: (gen next: count)]. cost1 := serie collect: [:e | [1000 timesRepeat: [e readStream nextFloat]] timeToRun]. cost2 := serie collect: [:e | [1000 timesRepeat: [(Number readFrom: e readStream) asFloat]] timeToRun]. {counts. cost1. cost2.} #("NON COG VM" #(4 8 16 32 64 128 256 512 1024 2048 4096 8192) #(2 2 25 65 146 304 647 1412 3288 8393 24021 77189) #(6 6 21 51 94 177 361 742 1550 3872 8471 22647)) #("COG VM" #(4 8 16 32 64 128 256 512 1024 2048 4096 8192) #(0 2 3 20 56 139 334 838 2323 7010 23614 85925) #(2 0 4 13 24 53 116 264 626 1646 4552 14191)) It's not a log_2 cost at the end, but it's already some gain. It's possible that above costs are dominated by garbage collection, but I don't know how to measure that accurately... Nicolas > On 14 September 2011 20:26, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> On 3 September 2011 19:35, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> 2011/9/3 Frank Shearar <frank.shearar(a)gmail.com>: >>>> On 3 September 2011 18:50, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>> I think it is a good idea to have the number parser separate, after >>>>> all it might also make sense to use it separately. >>>>> >>>>> It seems that the new Smalltalk grammar is significantly slower. The >>>>> benchmark PPSmalltalkClassesTests class>>#benchmark: that uses the >>>>> source code of the collection hierarchy and does not especially target >>>>> number literals runs 30% slower. >>>>> >>>>> Also I see that "Number readFrom: ..." is still used within the >>>>> grammar. This seems to be a bit strange, no? >>>> >>>> Yes: it's a double-parse, which is a bit lame. First, we parse the >>>> literal with PPSmalltalkNumberParser, which ensures that the thing >>>> given to Number class >> #readFrom: is a well-formed token (so, in >>>> particular, Squeak's Number doesn't get to see anything other than a >>>> well-formed token). >>>> >>>> It sounds like you're happy with the basic concept, so maybe I should >>>> remove the Number class >> #readFrom: stuff, see if I can't remove the >>>> performance issues, and resubmit the patch. >>>> >>>> frank >>>> >>> >>> Yes, a NumberParser is essentially parsing, and this duplication sounds useless. >>> The main feature of interest in NumberParser that I consider a >>> requirement and should find its equivalence in a PetitNumberParser is: >>> - round a decimal representation to nearest Float >>> It's simple, just convert a Fraction asFloat in a single final step to >>> avoid cumulating round off errors - see >>> #makeFloatFromMantissa:exponent:base: >>> >>> The second feature of interest in NumberParser is the ability to >>> parser LargeInteger efficiently by avoiding (10 * largeValue + >>> digitValue) loops, and replacing them with a log(n) cost. >>> This would be a simple thing to implement in a functional language. >> >> Hopefully this won't offend your sensibilities too much :). It does, >> in fact, use 10* loops - I wrote an experimental "front half * rear >> half" recursion, which was slower in my benchmarks. >> >> This version has the grammar and parser doing no string->number >> conversion at all. PPSmalltalkNumberMaker supplies a number of utility >> methods designed to stop one from making malformed numbers. It also >> supplies a builder interface that the parser uses to construct >> numbers. >> >> frank >> >>> Nicolas >>> >>>>> Lukas >>>>> >>>>> >>>>> On 3 September 2011 17:18, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>>>>> On 3 September 2011 15:56, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>>>> On 3 September 2011 16:51, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>>>>>>> Hi Lukas, >>>>>>>> >>>>>>>> I haven't :) mainly because I'm unsure where to put it - is there >>>>>>>> perhaps a PP Inbox, or shall I just post the merged version, or what's >>>>>>>> your preference? (How about an mcd between my merge and PP's head?) >>>>>>> >>>>>>> Just put the .mcz at some public URL (dropbox, squeak source, ...) or >>>>>>> attach it to a mail. >>>>>> >>>>>> Ah, great - here it is. You'll see I've written the grammar as a >>>>>> separate class. That was really more to make what I'd done more >>>>>> obvious and to minimise the change to PPSmalltalkGrammar, but perhaps >>>>>> it's not a bad idea anyway: it's easy to see the number literal >>>>>> subgrammar. >>>>>> >>>>>> frank >>>>>> >>>>>>> Lukas >>>>>>> >>>>>>> -- >>>>>>> Lukas Renggli >>>>>>> www.lukas-renggli.ch >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Lukas Renggli >>>>> www.lukas-renggli.ch >>>>> >>>>> >>>> >>>> >>> >>> >> > >

Sept. 25, 2011

Re: [Pharo-project] PetitSmalltalk: now with a self-contained grammar for number literals

by Frank Shearar

Nicolas, you'd mentioned a log_2 n implementation for number parsing. I think by that you mean the division of digits into two "packets" that are processed and then added? I tried a straight-forward fold (using the * 10 that you said you didn't like!) Time millisecondsToRun: [10000 timesRepeat: ['123456789012345678901234567890' inject: 0 into: [:acc :each | 10 * acc + each digitValue]]] => 818 and what I think you meant: | f | f := 1. "Just to shut the compiler up about the self-reference." f := [:someDigits | | len | len := someDigits size. (len = 1) ifTrue: [someDigits first digitValue] ifFalse: [ | leftHalf rightHalf | leftHalf := someDigits first: len // 2. rightHalf := someDigits allButFirst: len // 2. ((f value: (leftHalf)) * (10 raisedTo: rightHalf size)) + (f value: rightHalf)]]. Time millisecondsToRun: [10000 timesRepeat: [f value: '123456789012345678901234567890']] => 1508 I went with the straight-forward fold because it was simpler and my (quite possibly wrong/inefficient) attempt at a log_2 n version was a lot less readable. I'd greatly appreciate being gently corrected! frank On 14 September 2011 20:26, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 3 September 2011 19:35, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> 2011/9/3 Frank Shearar <frank.shearar(a)gmail.com>: >>> On 3 September 2011 18:50, Lukas Renggli <renggli(a)gmail.com> wrote: >>>> I think it is a good idea to have the number parser separate, after >>>> all it might also make sense to use it separately. >>>> >>>> It seems that the new Smalltalk grammar is significantly slower. The >>>> benchmark PPSmalltalkClassesTests class>>#benchmark: that uses the >>>> source code of the collection hierarchy and does not especially target >>>> number literals runs 30% slower. >>>> >>>> Also I see that "Number readFrom: ..." is still used within the >>>> grammar. This seems to be a bit strange, no? >>> >>> Yes: it's a double-parse, which is a bit lame. First, we parse the >>> literal with PPSmalltalkNumberParser, which ensures that the thing >>> given to Number class >> #readFrom: is a well-formed token (so, in >>> particular, Squeak's Number doesn't get to see anything other than a >>> well-formed token). >>> >>> It sounds like you're happy with the basic concept, so maybe I should >>> remove the Number class >> #readFrom: stuff, see if I can't remove the >>> performance issues, and resubmit the patch. >>> >>> frank >>> >> >> Yes, a NumberParser is essentially parsing, and this duplication sounds useless. >> The main feature of interest in NumberParser that I consider a >> requirement and should find its equivalence in a PetitNumberParser is: >> - round a decimal representation to nearest Float >> It's simple, just convert a Fraction asFloat in a single final step to >> avoid cumulating round off errors - see >> #makeFloatFromMantissa:exponent:base: >> >> The second feature of interest in NumberParser is the ability to >> parser LargeInteger efficiently by avoiding (10 * largeValue + >> digitValue) loops, and replacing them with a log(n) cost. >> This would be a simple thing to implement in a functional language. > > Hopefully this won't offend your sensibilities too much :). It does, > in fact, use 10* loops - I wrote an experimental "front half * rear > half" recursion, which was slower in my benchmarks. > > This version has the grammar and parser doing no string->number > conversion at all. PPSmalltalkNumberMaker supplies a number of utility > methods designed to stop one from making malformed numbers. It also > supplies a builder interface that the parser uses to construct > numbers. > > frank > >> Nicolas >> >>>> Lukas >>>> >>>> >>>> On 3 September 2011 17:18, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>>>> On 3 September 2011 15:56, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>>> On 3 September 2011 16:51, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>>>>>> Hi Lukas, >>>>>>> >>>>>>> I haven't :) mainly because I'm unsure where to put it - is there >>>>>>> perhaps a PP Inbox, or shall I just post the merged version, or what's >>>>>>> your preference? (How about an mcd between my merge and PP's head?) >>>>>> >>>>>> Just put the .mcz at some public URL (dropbox, squeak source, ...) or >>>>>> attach it to a mail. >>>>> >>>>> Ah, great - here it is. You'll see I've written the grammar as a >>>>> separate class. That was really more to make what I'd done more >>>>> obvious and to minimise the change to PPSmalltalkGrammar, but perhaps >>>>> it's not a bad idea anyway: it's easy to see the number literal >>>>> subgrammar. >>>>> >>>>> frank >>>>> >>>>>> Lukas >>>>>> >>>>>> -- >>>>>> Lukas Renggli >>>>>> www.lukas-renggli.ch >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Lukas Renggli >>>> www.lukas-renggli.ch >>>> >>>> >>> >>> >> >> >

Sept. 25, 2011

Re: [Pharo-project] [Vm-dev] jenkins cog - slow monticello on osx

by Tudor Girba

Hi, I have: ZipPlugin VMMaker-oscog-IgorStasenko.123 (i) Cheers, Doru On 25 Sep 2011, at 13:04, Mariano Martinez Peck wrote: > > > ---------- Forwarded message ---------- > From: Mariano Martinez Peck <marianopeck(a)gmail.com> > Date: Sun, Sep 25, 2011 at 1:04 PM > Subject: Re: [Vm-dev] [Pharo-project] jenkins cog - slow monticello on osx > To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > > > > > On Thu, Sep 22, 2011 at 9:57 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > > Check to see if your VM has ZipPlugin (Smalltalk listBuiltinModules). > > Good point. I see it. > Doru, do you ? > > This has a big effect on Monticello performance. > > Dave > > On Thu, Sep 22, 2011 at 07:32:17PM +0200, Tudor Girba wrote: > > > > Hi, > > > > I looked a bit into the slowness of the OS X Jenkins Cog VM with Monticello. The problem exists and it is reproducible. > > > > I performed the following experiments using the following script: > > > > Time millisecondsToRun: > > [ 1 to: 100 do: [:x | > > | window | > > window := MCWorkingCopyBrowser new show. > > window delete ] ] > > > > I ran it on the same image using the following vms (on Mac OS X Lion): > > - Jenkins VM from 31.08.2011 > > - Cog VM r2489 > > > > I ran the scenario twice with two different setups: > > > > 1. I placed the image in an empty folder: > > > > Cog VM 2389: 4808 ms > > Jenkins VM: 7345 ms > > > > 2. I places the image in a folder that already had a large package-cache with 7400 mcz files: > > Cog VM: 4867 ms > > Jenkins VM: 50754 ms > > > > > > So: > > - even if there is no package cache, the Jenkins VM seems to perform 1.5 times slower > > - when there is a package-cache, it becomes hardly unusable. > > > > Cheers, > > Doru > > > > > > On 8 Sep 2011, at 12:10, Tudor Girba wrote: > > > > > Hi, > > > > > > I did not forget about this, but I did not have enough time yet. > > > > > > Cheers, > > > Doru > > > > > > > > > On 26 Aug 2011, at 14:40, Igor Stasenko wrote: > > > > > >> > > >> On 26 August 2011 13:30, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > >>> Hi, > > >>> > > >>> Since a couple of weeks I am working with the Cog VM built on Jenkins: > > >>> https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-Mac-Cocoa/ > > >>> > > >>> Here is a little feedback. It worked quite well, the only problem is that Monticello is really slow in the Moose image. This means that even opening the Monticello Browser takes several seconds. > > >>> > > >>> I thought that this might be induced by something in the Moose image, but if I try with the Elliot's VM (2489), it works blazingly fast. > > >>> > > >> > > >> Thanks for the information, Tudor. > > >> Apparently the difference between Eliot's VM and Cog-Mac-Cocoa that > > >> they are using different frameworks > > >> (Carbon vs Cocoa) > > >> and i don't know too much details about the difference there. > > >> John or Esteban may have better insights how to fix that. > > >> > > >>> Cheers, > > >>> Doru > > >>> > > >>> > > >>> -- > > >>> www.tudorgirba.com > > >>> > > >>> "The coherence of a trip is given by the clearness of the goal." > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >> > > >> > > >> > > >> -- > > >> Best regards, > > >> Igor Stasenko AKA sig. > > > > > > -- > > > www.tudorgirba.com > > > > > > "Yesterday is a fact. > > > Tomorrow is a possibility. > > > Today is a challenge." > > > > > > > > > > > > > -- > > www.tudorgirba.com > > > > "Sometimes the best solution is not the best solution." > > > > -- > Mariano > http://marianopeck.wordpress.com > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- www.tudorgirba.com "Presenting is storytelling."

Sept. 25, 2011

[Pharo-project] Fwd: [Vm-dev] jenkins cog - slow monticello on osx

by Mariano Martinez Peck

---------- Forwarded message ---------- From: Mariano Martinez Peck <marianopeck(a)gmail.com> Date: Sun, Sep 25, 2011 at 1:04 PM Subject: Re: [Vm-dev] [Pharo-project] jenkins cog - slow monticello on osx To: Squeak Virtual Machine Development Discussion < vm-dev(a)lists.squeakfoundation.org> On Thu, Sep 22, 2011 at 9:57 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > > Check to see if your VM has ZipPlugin (Smalltalk listBuiltinModules). > Good point. I see it. Doru, do you ? > This has a big effect on Monticello performance. > > Dave > > On Thu, Sep 22, 2011 at 07:32:17PM +0200, Tudor Girba wrote: > > > > Hi, > > > > I looked a bit into the slowness of the OS X Jenkins Cog VM with > Monticello. The problem exists and it is reproducible. > > > > I performed the following experiments using the following script: > > > > Time millisecondsToRun: > > [ 1 to: 100 do: [:x | > > | window | > > window := MCWorkingCopyBrowser new show. > > window delete ] ] > > > > I ran it on the same image using the following vms (on Mac OS X Lion): > > - Jenkins VM from 31.08.2011 > > - Cog VM r2489 > > > > I ran the scenario twice with two different setups: > > > > 1. I placed the image in an empty folder: > > > > Cog VM 2389: 4808 ms > > Jenkins VM: 7345 ms > > > > 2. I places the image in a folder that already had a large package-cache > with 7400 mcz files: > > Cog VM: 4867 ms > > Jenkins VM: 50754 ms > > > > > > So: > > - even if there is no package cache, the Jenkins VM seems to perform 1.5 > times slower > > - when there is a package-cache, it becomes hardly unusable. > > > > Cheers, > > Doru > > > > > > On 8 Sep 2011, at 12:10, Tudor Girba wrote: > > > > > Hi, > > > > > > I did not forget about this, but I did not have enough time yet. > > > > > > Cheers, > > > Doru > > > > > > > > > On 26 Aug 2011, at 14:40, Igor Stasenko wrote: > > > > > >> > > >> On 26 August 2011 13:30, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > >>> Hi, > > >>> > > >>> Since a couple of weeks I am working with the Cog VM built on > Jenkins: > > >>> https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-Mac-Cocoa/ > > >>> > > >>> Here is a little feedback. It worked quite well, the only problem is > that Monticello is really slow in the Moose image. This means that even > opening the Monticello Browser takes several seconds. > > >>> > > >>> I thought that this might be induced by something in the Moose image, > but if I try with the Elliot's VM (2489), it works blazingly fast. > > >>> > > >> > > >> Thanks for the information, Tudor. > > >> Apparently the difference between Eliot's VM and Cog-Mac-Cocoa that > > >> they are using different frameworks > > >> (Carbon vs Cocoa) > > >> and i don't know too much details about the difference there. > > >> John or Esteban may have better insights how to fix that. > > >> > > >>> Cheers, > > >>> Doru > > >>> > > >>> > > >>> -- > > >>> www.tudorgirba.com > > >>> > > >>> "The coherence of a trip is given by the clearness of the goal." > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >> > > >> > > >> > > >> -- > > >> Best regards, > > >> Igor Stasenko AKA sig. > > > > > > -- > > > www.tudorgirba.com > > > > > > "Yesterday is a fact. > > > Tomorrow is a possibility. > > > Today is a challenge." > > > > > > > > > > > > > -- > > www.tudorgirba.com > > > > "Sometimes the best solution is not the best solution." > -- Mariano http://marianopeck.wordpress.com -- Mariano http://marianopeck.wordpress.com

Sept. 25, 2011