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

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

by Eliot Miranda

On Wed, Apr 25, 2012 at 1:11 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Fri, 20 Apr 2012, Frank Shearar wrote: > > On 20 April 2012 03:51, Levente Uzonyi <leves(a)elte.hu> wrote: >> >>> On Thu, 19 Apr 2012, Frank Shearar wrote: >>> >>> I found a serious bug in parsing numbers with negative exponents. It >>>> was completey broken, in fact, parsing 1e-1 as 10, not 1 / 10. Anyway. >>>> This version fixes that, and adds a bunch of tests demonstrating that >>>> number parsing will return rationals if it can. >>>> >>>> It's significantly slower than Squeak's SqNumberParser: >>>> >>>> Time millisecondsToRun: [100000 timesRepeat: [SqNumberParser parse: >>>> '1234567890']] => 466 >>>> >>>> >>>> Time millisecondsToRun: [100000 timesRepeat: [PPSmalltalkNumberParser >>>> parse: '1234567890']] => 32082 >>>> >>>> I've attached a MessageTally spying on the latter: I've not much skill >>>> in reading these, but nothing leaps out at me as being obviously >>>> awful. >>>> >>> >>> >>> Didn't check the code, just the tally, and I think that >>> PPSmalltalkNumberParser(**PPSmalltalkNumberGrammar)>>**digitsBase: is >>> begging >>> for optimization. It's probably also the cause of the high amount of >>> garbage >>> which causes significant amount of time spent with garbage collection. >>> It's also interesting is that the finalization process does so much work, >>> there may be something wrong with your image. >>> >> >> Thanks for taking a look, Levente. >> >> I'd expect digitsBase: to dominate the running costs, given that we're >> parsing numbers. >> > > I finally checked the code and there's plenty of space for optimization. > Note that the code can't be loaded into Squeak, because there's an invalid > symbol #__gen__binding, and some methods with nil category. > > > >> I do make a large number of throwaway "immutable" values with a >> Builder-like pattern... in PPSmalltalkNumberParser >> >> #makeNumberFrom:base:. That, I would imagine, could explain the >> garbage? >> > > The current garbage collector is not optimal for large images and large > amount of garbage, so you should try avoid creating it in performance > critial parts of your code. > > > >> If I may, what do you look for when reading the MessageTally? How do >> you tell, for instance, that there's excessive garbage production? >> > > In your tally GC time was 20% of total time and another 20% for the > finalization process. These numbers should be much lower, usually less than > 1%. > > > That the incremental GCs take 7ms? (I'm reading Andreas' comments on >> http://wiki.squeak.org/squeak/**4210 <http://wiki.squeak.org/squeak/4210>again.) >> > > 7ms for an incremental GC is also a bit high, it should be around 1-2ms. Careful. Absolute GC times (as any run-time) depend on the machine. On a slow machine GC runs slow... > > > > Levente > > > >> frank >> >> Levente >>> >>> >>> >>>> 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<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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>> >> >> > -- best, Eliot

April 25, 2012

Re: [Pharo-project] Who is maintaining the Grease configuration

by Dale Henrichs

... let me finish my thought ... I can share that algorithm with you, if you want:) Dale ----- Original Message ----- | From: "Dale Henrichs" <dhenrich(a)vmware.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Wednesday, April 25, 2012 2:01:05 PM | Subject: Re: [Pharo-project] Who is maintaining the Grease configuration | | For Gemstone, I generate (and cache) the attributes based on | programmatic access to the image version number... | | Dale | | ----- Original Message ----- | | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | | To: Pharo-project(a)lists.gforge.inria.fr | | Sent: Wednesday, April 25, 2012 12:58:25 PM | | Subject: Re: [Pharo-project] Who is maintaining the Grease | | configuration | | | | Ok I will do it. | | We should add this to our process. | | | | Stef | | | | | | > The first thing that I ran into is that the attributes for | | > Pharo2.0 | | > need to be updated ... right now: | | > | | > ConfigurationOfGrease project attributes | | > | | > returns: | | > | | > an OrderedCollection(#common #squeakCommon #pharo #'pharo1.x' | | > #'pharo1.4.x') | | > | | > Looks like SmalltalkImage>>metacelloPlatformAttributes needs to | | > be | | > updated to return: | | > | | > #(#squeakCommon #pharo #'pharo2.x' #'pharo2.0.x') | | > | | > Dale | | > | | > ----- Original Message ----- | | > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | | > | To: Pharo-project(a)lists.gforge.inria.fr | | > | Sent: Wednesday, April 25, 2012 10:26:18 AM | | > | Subject: Re: [Pharo-project] Who is maintaining the Grease | | > | configuration | | > | | | > | Thanks | | > | I will start to add the pharo2.0.x to some configurations too. | | > | | | > | Stef | | > | | | > | > I'm the editor for the Grease configuration, so I'll take | | > | > this | | > | > on | | > | > ... | | > | > | | > | > Dale | | > | > | | > | > ----- Original Message ----- | | > | > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | | > | > | To: "Pharo-project(a)lists.gforge.inria.fr Development" | | > | > | <Pharo-project(a)lists.gforge.inria.fr> | | > | > | Sent: Wednesday, April 25, 2012 7:37:14 AM | | > | > | Subject: [Pharo-project] Who is maintaining the Grease | | > | > | configuration | | > | > | | | > | > | Because we should create a symbolic version for 20 | | > | > | | | > | > | This package depends on the following classes: | | > | > | BlockContext | | > | > | You must resolve these dependencies before you will be able | | > | > | to | | > | > | load | | > | > | these definitions: | | > | > | fixCallbackTemps | | > | > | tempVarRefs | | > | > | valueWithPossibleArguments: | | > | > | | | > | > | | | > | > | | | > | > | | > | | | > | | | > | | | > | | | | | | |

April 25, 2012

Re: [Pharo-project] Who is maintaining the Grease configuration

by Dale Henrichs

For Gemstone, I generate (and cache) the attributes based on programmatic access to the image version number... Dale ----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Wednesday, April 25, 2012 12:58:25 PM | Subject: Re: [Pharo-project] Who is maintaining the Grease configuration | | Ok I will do it. | We should add this to our process. | | Stef | | | > The first thing that I ran into is that the attributes for Pharo2.0 | > need to be updated ... right now: | > | > ConfigurationOfGrease project attributes | > | > returns: | > | > an OrderedCollection(#common #squeakCommon #pharo #'pharo1.x' | > #'pharo1.4.x') | > | > Looks like SmalltalkImage>>metacelloPlatformAttributes needs to be | > updated to return: | > | > #(#squeakCommon #pharo #'pharo2.x' #'pharo2.0.x') | > | > Dale | > | > ----- Original Message ----- | > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | > | To: Pharo-project(a)lists.gforge.inria.fr | > | Sent: Wednesday, April 25, 2012 10:26:18 AM | > | Subject: Re: [Pharo-project] Who is maintaining the Grease | > | configuration | > | | > | Thanks | > | I will start to add the pharo2.0.x to some configurations too. | > | | > | Stef | > | | > | > I'm the editor for the Grease configuration, so I'll take this | > | > on | > | > ... | > | > | > | > Dale | > | > | > | > ----- Original Message ----- | > | > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | > | > | To: "Pharo-project(a)lists.gforge.inria.fr Development" | > | > | <Pharo-project(a)lists.gforge.inria.fr> | > | > | Sent: Wednesday, April 25, 2012 7:37:14 AM | > | > | Subject: [Pharo-project] Who is maintaining the Grease | > | > | configuration | > | > | | > | > | Because we should create a symbolic version for 20 | > | > | | > | > | This package depends on the following classes: | > | > | BlockContext | > | > | You must resolve these dependencies before you will be able | > | > | to | > | > | load | > | > | these definitions: | > | > | fixCallbackTemps | > | > | tempVarRefs | > | > | valueWithPossibleArguments: | > | > | | > | > | | > | > | | > | > | > | | > | | > | | > | | |

April 25, 2012

Re: [Pharo-project] Nautilus for Pharo 2.0?

by Gary Chambers

As, I'll start using Nautilus... Regards, Gary Sent from my iPad On 25 Apr 2012, at 20:43, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Gary > > let us shake a bit 2.0 before jumping. :) > > Stef > > > On Apr 25, 2012, at 7:41 PM, Gary Chambers wrote: > >> Ar, will switch once migrated our stuff from (early) 1.4... >> >> Regards, Gary >> >> ----- Original Message ----- From: "Dale Henrichs" <dhenrich(a)vmware.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Wednesday, April 25, 2012 6:24 PM >> Subject: Re: [Pharo-project] Nautilus for Pharo 2.0? >> >> >>> And Nautilus looks and drives nicely (after a few minutes in Pharo2.0 myself:) >>> >>> Dale >>> >>> ----- Original Message ----- >>> | From: "Mariano Martinez Peck" <marianopeck(a)gmail.com> >>> | To: Pharo-project(a)lists.gforge.inria.fr >>> | Sent: Wednesday, April 25, 2012 10:14:03 AM >>> | Subject: Re: [Pharo-project] Nautilus for Pharo 2.0? >>> | >>> | >>> | >>> | >>> | >>> | On Wed, Apr 25, 2012 at 6:20 PM, Benjamin < >>> | benjamin.vanryseghem.pharo(a)gmail.com > wrote: >>> | >>> | >>> | Since a couple of minutes, Nautilus is part of Nautilus 2.0 >>> | >>> | >>> | >>> | s/Nautilus 2.0/Pharo 2.0 >>> | >>> | ;) >>> | >>> | >>> | >>> | Ben >>> | >>> | >>> | >>> | On Apr 25, 2012, at 6:17 PM, Noury Bouraqadi wrote: >>> | >>> | > Any plans to have an auto-build on Jenkins? >>> | > >>> | > Noury >>> | > -- >>> | > http://twitter.com/#!/NouryBouraqadi >>> | > http://www.kroobe.com/profile/noury >>> | > >>> | > >>> | > Afin de contribuer au respect de l'environnement, >>> | > merci de n'imprimer ce courriel qu'en cas de necessite >>> | > >>> | > Please consider the environment before you print >>> | > >>> | > >>> | > >>> | > >>> | >>> | >>> | >>> | >>> | >>> | -- >>> | Mariano >>> | http://marianopeck.wordpress.com >>> | >>> | >> >> > >

April 25, 2012

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

by Levente Uzonyi

On Fri, 20 Apr 2012, Frank Shearar wrote: > On 20 April 2012 03:51, Levente Uzonyi <leves(a)elte.hu> wrote: >> On Thu, 19 Apr 2012, Frank Shearar wrote: >> >>> I found a serious bug in parsing numbers with negative exponents. It >>> was completey broken, in fact, parsing 1e-1 as 10, not 1 / 10. Anyway. >>> This version fixes that, and adds a bunch of tests demonstrating that >>> number parsing will return rationals if it can. >>> >>> It's significantly slower than Squeak's SqNumberParser: >>> >>> Time millisecondsToRun: [100000 timesRepeat: [SqNumberParser parse: >>> '1234567890']] => 466 >>> >>> Time millisecondsToRun: [100000 timesRepeat: [PPSmalltalkNumberParser >>> parse: '1234567890']] => 32082 >>> >>> I've attached a MessageTally spying on the latter: I've not much skill >>> in reading these, but nothing leaps out at me as being obviously >>> awful. >> >> >> Didn't check the code, just the tally, and I think that >> PPSmalltalkNumberParser(PPSmalltalkNumberGrammar)>>digitsBase: is begging >> for optimization. It's probably also the cause of the high amount of garbage >> which causes significant amount of time spent with garbage collection. >> It's also interesting is that the finalization process does so much work, >> there may be something wrong with your image. > > Thanks for taking a look, Levente. > > I'd expect digitsBase: to dominate the running costs, given that we're > parsing numbers. I finally checked the code and there's plenty of space for optimization. Note that the code can't be loaded into Squeak, because there's an invalid symbol #__gen__binding, and some methods with nil category. > > I do make a large number of throwaway "immutable" values with a > Builder-like pattern... in PPSmalltalkNumberParser >> > #makeNumberFrom:base:. That, I would imagine, could explain the > garbage? The current garbage collector is not optimal for large images and large amount of garbage, so you should try avoid creating it in performance critial parts of your code. > > If I may, what do you look for when reading the MessageTally? How do > you tell, for instance, that there's excessive garbage production? In your tally GC time was 20% of total time and another 20% for the finalization process. These numbers should be much lower, usually less than 1%. > That the incremental GCs take 7ms? (I'm reading Andreas' comments on > http://wiki.squeak.org/squeak/4210 again.) 7ms for an incremental GC is also a bit high, it should be around 1-2ms. Levente > > frank > >> Levente >> >> >>> >>> 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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>> >> > >

April 25, 2012

Re: [Pharo-project] Downloading a file

by Sven Van Caekenberghe

On 25 Apr 2012, at 21:35, Sven Van Caekenberghe wrote: > I'll test some more... Sean, Sorry, there was indeed something wrong, with my examples, but I couldn't figure it out at first. Things is, you can't say #beOneShot because then the connection is closed after the first succesfull request/response cycle, and with a streaming entity that means that the underlying stream is gone (well closed). It would have been nice if socket stream threw an exception instead of returning zeros ;-) These examples should work: ZnClient new systemPolicy; accept: ZnMimeType imageJpeg; url: 'http://caretaker.wolf359.be/sun-fire-x2100.jpg'; downloadToFileNamed: '/tmp/sun-fire-x2100.jpg'. ZnClient new systemPolicy; accept: ZnMimeType text; url: 'http://zn.stfx.eu/zn/numbers.txt'; downloadToFileNamed: '/tmp/numbers.txt'. Optionally a #close should be sent to the client as well (although garbage collection will close the socket eventually). By using #systemPolicy, success is enforced anyway. And when the pharo website is up again: ZnClient new systemPolicy; accept: ZnMimeType imagePng; url: 'http://www.pharo-project.org/images/pharo.png'; downloadToFileNamed: '/tmp/pharo.png'. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

April 25, 2012

Re: [Pharo-project] Who is maintaining the Grease configuration

by StÃ©phane Ducasse

Ok I will do it. We should add this to our process. Stef > The first thing that I ran into is that the attributes for Pharo2.0 need to be updated ... right now: > > ConfigurationOfGrease project attributes > > returns: > > an OrderedCollection(#common #squeakCommon #pharo #'pharo1.x' #'pharo1.4.x') > > Looks like SmalltalkImage>>metacelloPlatformAttributes needs to be updated to return: > > #(#squeakCommon #pharo #'pharo2.x' #'pharo2.0.x') > > Dale > > ----- Original Message ----- > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Wednesday, April 25, 2012 10:26:18 AM > | Subject: Re: [Pharo-project] Who is maintaining the Grease configuration > | > | Thanks > | I will start to add the pharo2.0.x to some configurations too. > | > | Stef > | > | > I'm the editor for the Grease configuration, so I'll take this on > | > ... > | > > | > Dale > | > > | > ----- Original Message ----- > | > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > | > | To: "Pharo-project(a)lists.gforge.inria.fr Development" > | > | <Pharo-project(a)lists.gforge.inria.fr> > | > | Sent: Wednesday, April 25, 2012 7:37:14 AM > | > | Subject: [Pharo-project] Who is maintaining the Grease > | > | configuration > | > | > | > | Because we should create a symbolic version for 20 > | > | > | > | This package depends on the following classes: > | > | BlockContext > | > | You must resolve these dependencies before you will be able to > | > | load > | > | these definitions: > | > | fixCallbackTemps > | > | tempVarRefs > | > | valueWithPossibleArguments: > | > | > | > | > | > | > | > > | > | > | >

April 25, 2012

Re: [Pharo-project] [update 2.0] #20011

by StÃ©phane Ducasse

> Hi, > > I am a bit puzzled by the current trend of 2.0. > > Are these additions part of the image, or will they be loaded continuously on top of a seed image? > > If it's the former, I thought that we discussed a while ago to keep the image to a minimum, and, in particular, to not load RB in it. Or did anything change in the meantime? > > Cheers, > Doru Doru I guess that esteban is putting pressure on himself like that. :) You know that I want a small image and loading code. So I would have been a bit less wild for a while but may be this is the right decision. Now let us see. I think that it will stress a bit the system, so do not move moose to 2.0 for now. Stef

April 25, 2012

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

by Frank Shearar

I haven't published it there, no: that's up to Lukas, once he's convinced of its utility :). However, I've just published it and its ancestors to my scratchpad repository at http://ss3.gemstone.com/ss/Scratchpad-fbs so there's a public backup. frank On 25 April 2012 18:28, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > frank > > did you publish in the petitparser repo? > because we should not lose that. > > Stef > >>>>> >>>> Didn't check the code, just the tally, and I think that >>>> PPSmalltalkNumberParser(PPSmalltalkNumberGrammar)>>digitsBase: is begging >>>> for optimization. It's probably also the cause of the high amount of garbage >>>> which causes significant amount of time spent with garbage collection. >>>> It's also interesting is that the finalization process does so much work, >>>> there may be something wrong with your image. >>> >>> Thanks for taking a look, Levente. >>> >>> I'd expect digitsBase: to dominate the running costs, given that we're >>> parsing numbers. >>> >>> I do make a large number of throwaway "immutable" values with a >>> Builder-like pattern... in PPSmalltalkNumberParser >> >>> #makeNumberFrom:base:. That, I would imagine, could explain the >>> garbage? >>> >>> If I may, what do you look for when reading the MessageTally? How do >>> you tell, for instance, that there's excessive garbage production? >>> That the incremental GCs take 7ms? (I'm reading Andreas' comments on >>> http://wiki.squeak.org/squeak/4210 again.) >> >> Levente, you're quite right: #digitsBase: has now been optimised even >> more, reducing the time taken to run my benchmark >> >> MessageTally spyOn: [Time millisecondsToRun: [100000 timesRepeat: >> [PPSmalltalkNumberParser parse: '1234567890']]] >> >> from ~32 seconds to ~16 seconds. (Memoising was the answer: >> #digitsBase: is effectively a higher-order production and, like OMeta, >> PPCompositeParser doesn't memoise those. A simple class var dictionary >> solves that problem. >> >> frank >> >>> frank >>> >>>> Levente >>>> >>>> >>>>> >>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >> <PetitSmalltalk-fbs.63.mcz> > >

April 25, 2012

Re: [Pharo-project] pharo site is down

by StÃ©phane Ducasse

tx. this is strange may be there is power outage at bern Stef On Apr 25, 2012, at 9:24 PM, Francisco Garau wrote: > Apologies if somebody has already reported, but the Pharo site seems to be down > > http://www.pharo-project.org/

April 25, 2012