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

Re: [Pharo-project] Glamour configuration doesn't load in Pharo 1.3

by Tudor Girba

Hi, Strange indeed. The thing is that in my image, these methods are not extensions. So, I cannot see why they would not load. In any case, Glamour was always loaded in the Dev image. Cheers, Doru On 4 Sep 2011, at 10:58, StÃ©phane Ducasse wrote: > Hi lukas > > Does not look good to me. Looks like strnage dependencies. > Thanks for reporting. > > Stef > >> *** Warning: Warning: This package depends on the following classes: >> LessonView >> ScriptManager >> You must resolve these dependencies before you will be able to load >> these definitions: >> LessonView>>shoutAboutToStyle: >> ScriptManager>>shoutAboutToStyle: >> >> Not sure if this is intentional, because now that I load Glamour >> manually it works nicely in Pharo 1.3 (as well as the build is 4 times >> faster, 2 instead of 8 min). >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > -- www.tudorgirba.com "Every successful trip needs a suitable vehicle."

Sept. 4, 2011

Re: [Pharo-project] about Shout default to shout any text?

by StÃ©phane Ducasse

On Sep 4, 2011, at 10:48 AM, Lukas Renggli wrote: > All editors should be shout-able, but they should only be shouted if > their model implements #shoutAboutToStyle: or whatever specific > callback the system configured shouter is using. Yes I saw that. I'm still waiting for alain description to fully understand. > If CodeEditor has support for shouting only, This is not what I implied. More that some places like inspector may be hold a reference to text while they should to codeeditor and that in text shout default should be off. > then OB is screwed again > because there the extra behavior of CodeEditor (or SmalltalkEditor it > is called, I think) is not wanted. OK Now may be the default should be inverted. Not styled by default else we should really have a look at all the places where we should not shout and fix them. Because it looks strange to have a red text in inspector left pane especially when shout tries to parse anOrderedCollection (........) Do you do that in OB? Stef > > Lukas > > On 4 September 2011 10:40, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Alain >> >> either we should change some textEditor into CodeEditor (and the inverse) or we should make sure that by default texts are not shouted. >> Because we have a lot of place (like workspace, some inspector panes >> So what do you think? >> >> Stef >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch >

Sept. 4, 2011

Re: [Pharo-project] Glamour configuration doesn't load in Pharo 1.3

by StÃ©phane Ducasse

Hi lukas Does not look good to me. Looks like strnage dependencies. Thanks for reporting. Stef > *** Warning: Warning: This package depends on the following classes: > LessonView > ScriptManager > You must resolve these dependencies before you will be able to load > these definitions: > LessonView>>shoutAboutToStyle: > ScriptManager>>shoutAboutToStyle: > > Not sure if this is intentional, because now that I load Glamour > manually it works nicely in Pharo 1.3 (as well as the build is 4 times > faster, 2 instead of 8 min). > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Sept. 4, 2011

[Pharo-project] Glamour configuration doesn't load in Pharo 1.3

by Lukas Renggli

*** Warning: Warning: This package depends on the following classes: LessonView ScriptManager You must resolve these dependencies before you will be able to load these definitions: LessonView>>shoutAboutToStyle: ScriptManager>>shoutAboutToStyle: Not sure if this is intentional, because now that I load Glamour manually it works nicely in Pharo 1.3 (as well as the build is 4 times faster, 2 instead of 8 min). Lukas -- Lukas Renggli www.lukas-renggli.ch

Sept. 4, 2011

Re: [Pharo-project] about Shout default to shout any text?

by Lukas Renggli

All editors should be shout-able, but they should only be shouted if their model implements #shoutAboutToStyle: or whatever specific callback the system configured shouter is using. If CodeEditor has support for shouting only, then OB is screwed again because there the extra behavior of CodeEditor (or SmalltalkEditor it is called, I think) is not wanted. Lukas On 4 September 2011 10:40, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Alain > > either we should change some textEditor into CodeEditor (and the inverse) or we should make sure that by default texts are not shouted. > Because we have a lot of place (like workspace, some inspector panes > So what do you think? > > Stef > -- Lukas Renggli www.lukas-renggli.ch

Sept. 4, 2011

[Pharo-project] about Shout default to shout any text?

by StÃ©phane Ducasse

Alain either we should change some textEditor into CodeEditor (and the inverse) or we should make sure that by default texts are not shouted. Because we have a lot of place (like workspace, some inspector panes So what do you think? Stef

Sept. 4, 2011

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

by StÃ©phane Ducasse

> I think it is a good idea to have the number parser separate, after > all it might also make sense to use it separately. +1. Modularity and composibility is a strong apsect of PP so we should use them. Especially since in the future we want to use petitSmalltalk for pharo (to be checked speedwise). > > 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? > > 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. 4, 2011

Re: [Pharo-project] opening a text in a window

by StÃ©phane Ducasse

Ok for me where are the files for 1.3: the first slices? (not tagged for-14)? On Sep 3, 2011, at 10:28 AM, Alain Plantec wrote: > :)) > I'm documenting shout using (an help for the help browser + adding Shout-Examples with several examples). > Now, maybe 1.3 should be fixed without this help and keep it for 1.4. > Alain > On 31/08/2011 22:48, StÃ©phane Ducasse wrote: >> So what I learned waiting for the full explanation alain will nicely give us (thanks thanks thanks) >> >> The model of the widgets (yes the funky StringHolder is asked whether it should be styled or not) by invoking the method >> shoutAboutToStyle: >> >> shoutAboutToStyle: aPluggableShoutMorphOrView >> ^ self stylingActive >> >> Now I do not know more but soon will :) >> > >

Sept. 4, 2011

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

by Frank Shearar

On 3 September 2011 20:43, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2011/9/3 Frank Shearar <frank.shearar(a)gmail.com>: >> 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. >> >> It's bad for performance but it's definitely not useless: it removes >> the platform-dependent issues around Number class >> #readFrom:. In >> Squeak we use the ExtendedNumberParser which will quite happily accept >> '1.' as a valid number. This way, #readFrom: definitely gets a valid >> Smalltalk number literal. >> >> frank >> > > My question was why using NumberParser at all? > I indicated one essential feature of interest that should be ported to > a PetitNumberParser (round to nearest Float), and another optional one > for optimization. I'm not arguing at all. The first instance - turning the radix digits into a number - is trivial to remove. The second use of NumberParser's next on the hit list. If you have any further suggestions on efficient conversions from collection-of-digit-characters to numbers that aren't already in NumberParser, I'm all ears. My use of Number class >> #readFrom: was entirely a pragmatic first step - it let me write the grammar while keeping the test suite green. Now I need just address your and Lukas' suggestions, before I resubmit. Most importantly, I know that the basic idea/structure's not crazy. frank > Nicolas > >>> 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. >>> >>> 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. 3, 2011

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

by Nicolas Cellier

2011/9/3 Frank Shearar <frank.shearar(a)gmail.com>: > 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. > > It's bad for performance but it's definitely not useless: it removes > the platform-dependent issues around Number class >> #readFrom:. In > Squeak we use the ExtendedNumberParser which will quite happily accept > '1.' as a valid number. This way, #readFrom: definitely gets a valid > Smalltalk number literal. > > frank > My question was why using NumberParser at all? I indicated one essential feature of interest that should be ported to a PetitNumberParser (round to nearest Float), and another optional one for optimization. Nicolas >> 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. >> >> 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. 3, 2011