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

Re: [Pharo-project] Error at startup with the NonInteractiveUIManager

by Camillo Bruni

to clarify: you didn't get anything in the PharoDebug.log? if not, maybe we should add a --verbose switch do dump the extensive stack-trace? On 2012-04-25, at 23:34, Francois Stephany wrote: > I've identified the source of my problem =) > > I starts my image with a script like: > > exec "$VM" $VM_PARAMS "$IMAGE" $STARTUP_SCRIPT > where $STARTUP_SCRIPT is the path to a .st file. That file was named "startup.st". Which is automatically loaded with Pharo 1.4. So it was loaded twice and my image was fucked. > > I tried to modify my script to: > exec "$VM" $VM_PARAMS "$IMAGE" > and put "startup.st" next to the image. But that still gives me the error. > > > In the end I just kept > exec "$VM" $VM_PARAMS "$IMAGE" $STARTUP_SCRIPT > > but rename the file lying in $STARTUP_SCRIPT in "start.st". > > Everything seems to work fine now. > > > On 25/04/12 00:48, Mariano Martinez Peck wrote: >> >> >> On Wed, Apr 25, 2012 at 7:12 AM, Francois Stephany >> <tulipe.moutarde(a)gmail.com <mailto:tulipe.moutarde@gmail.com>> wrote: >> >> Hi there, >> >> I have a problem when trying to start an application on a linux >> server with the latest cogvm (2550) and Pharo 1.4-14438. >> >> >> ==== Startup Error: PrimitiveFailed: primitive #primGetPosition: >> in MultiByteFileStream failed >> MultiByteFileStream(Object)>>__primitiveFailed: >> MultiByteFileStream(Object)>>__primitiveFailed >> MultiByteFileStream(__StandardFileStream)>>__primGetPosition: >> MultiByteFileStream(__StandardFileStream)>>position >> MultiByteFileStream(__PositionableStream)>>__skipStyleChunk >> MultiByteFileStream(__PositionableStream)>>__fileInAnnouncing: >> in Block: [:bar | ... >> NonInteractiveUIManager(__CommandLineUIManager)>>__progressInitiationExceptionDef__aultAction: >> ProgressInitiationException>>__defaultAction >> UndefinedObject>>handleSignal: >> MethodContext(ContextPart)>>__handleSignal: >> Got startup errors: >> PrimitiveFailed: primitive #primGetPosition: in >> MultiByteFileStream failed >> >> >> >> >> >> Francois, I think that stacktrace is a problem trying to write into >> PharoDebug.log ANOTHER problem. So you shuld try to somehow see which is >> the original error. >> >> Cheers >> >> I haven't identified the cause yet but if anybody had that problem >> before, i'm all ears ;) >> >> >> Cheers, >> Francois >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > -- > http://tulipemoutarde.be > CA: +1 778 558 3225 > BE: +32 65 709 131 >

April 25, 2012

Re: [Pharo-project] flyover help

by Francisco Garau

The following code demonstrates the problem: EllipseMorph new setBalloonText: 'hello world'; openInWorld It's always the same behaviour regardless the text (even adding an extra space at the end computes a box which is too big...) It happens in 1.4 and 2.0. I would like to try in previous Pharos, but can't get hold of 1.3 or 1.2. Are those images available somewhere? I am looking in BaloonMorph >> popUpForHand: - Francisco PS: sorry for the previous message on the wrong thread On 25 April 2012 23:10, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: > More like word wrapping got broken sometime on CharacterScanner cleanups... > > Regards, Gary > > Sent from my iPad > > On 25 Apr 2012, at 23:02, Francisco Garau <francisco.garau(a)gmail.com> > wrote: > > > Hi - the bounding rectangle of the flyover help is not big enough and > always causing the last letter to show on a second line. > > > > If nobody has reported it, I'll try to fix it. > > > > Any pointers are appreciated. > > > > - Francisco > > <Screen shot 2012-04-25 at 22.58.07.png> > >

April 25, 2012

Re: [Pharo-project] Concrete Type Inference

by Francisco Garau

The following code demonstrates the problem: EllipseMorph new setBalloonText: 'hello world'; openInWorld It's always the same behaviour regardless the text (even adding an extra space at the end computes a box which is too big...) It happens in 1.4 and 2.0. I would like to try in previous Pharos, but can't get hold of 1.3 or 1.2. Are those images available somewhere? I am looking in BaloonMorph >> popUpForHand: - Francisco On 21 March 2012 14:44, Santiago Bragagnolo <santiagobragagnolo(a)gmail.com>wrote: > Thanks too, i spend two hours searching for it last night :P when i > couldn't make work the image of Concrete Type in the latest vm. (i had to > prove :P). > > > 2012/3/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> >> On Mar 21, 2012, at 10:34 AM, Francisco Garau wrote: >> >> > Hi - we are trying to port to Pharo some work I've done on Concrete >> Type Inference back in 2001. >> >> Excellent! >> We want that ;) >> >> > >> > I've got a Squeak 2.8 image which is working, but having some minor >> problems with the pluggins. >> > >> > Is there a public repository where old Squeak distributions are stored? >> >> normally on http://www.squeak.org/ >> there is an ftp >> http://ftp.squeak.org >> >> stef >> >> > >> > Thanks, >> > Francisco >> >> >> >

April 25, 2012

Re: [Pharo-project] flyover help

by Gary Chambers

More like word wrapping got broken sometime on CharacterScanner cleanups... Regards, Gary Sent from my iPad On 25 Apr 2012, at 23:02, Francisco Garau <francisco.garau(a)gmail.com> wrote: > Hi - the bounding rectangle of the flyover help is not big enough and always causing the last letter to show on a second line. > > If nobody has reported it, I'll try to fix it. > > Any pointers are appreciated. > > - Francisco > <Screen shot 2012-04-25 at 22.58.07.png>

April 25, 2012

[Pharo-project] flyover help

by Francisco Garau

Hi - the bounding rectangle of the flyover help is not big enough and always causing the last letter to show on a second line. If nobody has reported it, I'll try to fix it. Any pointers are appreciated. - Francisco

April 25, 2012

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

by Levente Uzonyi

On Wed, 25 Apr 2012, Frank Shearar wrote: > On 25 April 2012 21:11, 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. > > Indeed: you might recall I've mentioned some incompatibilities between > Pharo and Squeak where PetitParser is concerned: Symbol >> isBinary > doesn't exist, you MUST have Scanner prefAllowUnderscoreSelectors: > true and Scanner allowUnderscoreAsAssignment: false, you need to > fiddle with RB so you can load AST-Core and AST-Compiler, and so on. > It's _possible_ (I wrote/am writing the number grammar in a Squeak > image), and once I've addressed _this_ incompatibility, I'll address > the others! > >>> 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. > > I foolishly forgot to add the message tally. You'll notice the absence > of the weak finalization process: that might have been because the > image predated the recent weak finalization thrashing fix. I'm using Eliot's VMs and those don't include Igor's patch. Levente > > frank > >>> 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] PetitSmalltalk: now with a self-contained grammar for number literals

by Levente Uzonyi

On Wed, 25 Apr 2012, Eliot Miranda wrote: > > > 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 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... Of course, but the incremental GC is intended to be fast enough to be unnoticable even during audio playback, so it shouldn't take more than 1-2ms on a slower system. Levente > Â > > > > 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 > > > > > > > > > > > > > > > -- > best,Eliot > > >

April 25, 2012

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

by Frank Shearar

On 25 April 2012 21:11, 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. Indeed: you might recall I've mentioned some incompatibilities between Pharo and Squeak where PetitParser is concerned: Symbol >> isBinary doesn't exist, you MUST have Scanner prefAllowUnderscoreSelectors: true and Scanner allowUnderscoreAsAssignment: false, you need to fiddle with RB so you can load AST-Core and AST-Compiler, and so on. It's _possible_ (I wrote/am writing the number grammar in a Squeak image), and once I've addressed _this_ incompatibility, I'll address the others! >> 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. I foolishly forgot to add the message tally. You'll notice the absence of the weak finalization process: that might have been because the image predated the recent weak finalization thrashing fix. frank >> 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] PetitSmalltalk: now with a self-contained grammar for number literals

by Levente Uzonyi

On Wed, 25 Apr 2012, Frank Shearar wrote: > On 20 April 2012 15:15, Frank Shearar <frank.shearar(a)gmail.com> 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 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. Creating a new parser (PPSmalltalkNumberParser) takes quite a while, if you extract the parser creation, then you'll get closer to the performance limit of PetitParser: | p | p := PPSmalltalkNumberParser new. [ Time millisecondsToRun: [100000 timesRepeat: [p parse: '1234567890']] ] timeProfile. "==> 2594" There are still places where you create parsers on the fly, like PPSmalltalkNumberGrammar #>> number. These should be avoided. Levente > > 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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>> >

April 25, 2012

Re: [Pharo-project] Error at startup with the NonInteractiveUIManager

by Francois Stephany

I've identified the source of my problem =) I starts my image with a script like: exec "$VM" $VM_PARAMS "$IMAGE" $STARTUP_SCRIPT where $STARTUP_SCRIPT is the path to a .st file. That file was named "startup.st". Which is automatically loaded with Pharo 1.4. So it was loaded twice and my image was fucked. I tried to modify my script to: exec "$VM" $VM_PARAMS "$IMAGE" and put "startup.st" next to the image. But that still gives me the error. In the end I just kept exec "$VM" $VM_PARAMS "$IMAGE" $STARTUP_SCRIPT but rename the file lying in $STARTUP_SCRIPT in "start.st". Everything seems to work fine now. On 25/04/12 00:48, Mariano Martinez Peck wrote: > > > On Wed, Apr 25, 2012 at 7:12 AM, Francois Stephany > <tulipe.moutarde(a)gmail.com <mailto:tulipe.moutarde@gmail.com>> wrote: > > Hi there, > > I have a problem when trying to start an application on a linux > server with the latest cogvm (2550) and Pharo 1.4-14438. > > > ==== Startup Error: PrimitiveFailed: primitive #primGetPosition: > in MultiByteFileStream failed > MultiByteFileStream(Object)>>__primitiveFailed: > MultiByteFileStream(Object)>>__primitiveFailed > MultiByteFileStream(__StandardFileStream)>>__primGetPosition: > MultiByteFileStream(__StandardFileStream)>>position > MultiByteFileStream(__PositionableStream)>>__skipStyleChunk > MultiByteFileStream(__PositionableStream)>>__fileInAnnouncing: > in Block: [:bar | ... > NonInteractiveUIManager(__CommandLineUIManager)>>__progressInitiationExceptionDef__aultAction: > ProgressInitiationException>>__defaultAction > UndefinedObject>>handleSignal: > MethodContext(ContextPart)>>__handleSignal: > Got startup errors: > PrimitiveFailed: primitive #primGetPosition: in > MultiByteFileStream failed > > > > > > Francois, I think that stacktrace is a problem trying to write into > PharoDebug.log ANOTHER problem. So you shuld try to somehow see which is > the original error. > > Cheers > > I haven't identified the cause yet but if anybody had that problem > before, i'm all ears ;) > > > Cheers, > Francois > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- http://tulipemoutarde.be CA: +1 778 558 3225 BE: +32 65 709 131

April 25, 2012