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

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

by Frank Shearar

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. 14, 2011

Re: [Pharo-project] anyone have a more up-to-date MethodWrappers for Squeak than MethodWrappers3.9-pmm.10?

by Eliot Miranda

Hi All, I'm getting on ok with updating the 3.9 code to 4.2 but there are a few uglies. This in particular is clear as mud: DF 4/19/2006 00:34 Â· MwMethodWrapper class methods for class initialization tweakClassFormat self setFormat: (self format bitOr: 16r200). Who is DF? What's the intent of this method? MwMethodWrapper is a subclass of CompiledMethod and so should have instSpec equal to CompiledMethod's instSpec (12/16rC). This sets it to 4 (WeakArray's). As far as I can see the above method is pointless. But how can I be sure. There's _no comment_ at all in this method. On Tue, Sep 13, 2011 at 2:42 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi All, > > the most up-to-date MethodWrappers I can find is for Squeak 3.9, > pre-closures. Anyone have anything compatible with Squeak 4.1/4.2/Pharo > 1.1/1.2/1.3? > > -- > best, > Eliot > > -- best, Eliot

Sept. 14, 2011

Re: [Pharo-project] What is an abstract method?

by Nicolas Cellier

2011/9/14 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Wed, Sep 14, 2011 at 11:13 AM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> 2011/9/14 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> > 2011/9/14 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >> >> >> >> >> On Wed, Sep 14, 2011 at 1:20 PM, Igor Stasenko <siguctua(a)gmail.com> >> >> wrote: >> >>> >> >>> On 13 September 2011 19:52, Alexandre Bergel <alexandre.bergel(a)me.com> >> >>> wrote: >> >>> > Hi! >> >>> > >> >>> > Apparently, the following method is abstract: >> >>> > >> >>> > ArrayedCollection>>add: newObject >> >>> > Â Â Â Â self shouldNotImplement >> >>> > >> >>> > If I evaluate: >> >>> > (ArrayedCollection>>#add:) isAbstract => true >> >>> > >> >>> > This is not quite right. A method that is cancelled is not abstract. >> >>> > >> >>> > I propose to change >> >>> > CompiledMethod>>abstractMarkers >> >>> > Â Â Â Â ^ #(subclassResponsibility shouldNotImplement) >> >>> > >> >>> > into >> >>> > CompiledMethod>>abstractMarker >> >>> > Â Â Â Â ^ #shouldNotImplement >> >>> > >> >>> > Does it make sense? >> >>> > >> >>> >> >>> yes >> >> >> >> >> >> Why? It doesn't for me. A method defined as ^ self >> >> subclassResponsibility >> >> is "abstract" from my point of view. >> >> >> > >> > See Eliot's mail, he already noticed the inversion. >> > It's just a copy/paste type, the inbox/SLICE seems correct >> >> s/type/typo/ > > :) :) :) Yep, me too... Note for next visit to the doctor: Remind to check some neural connections and probe for a left/right hand inversion. > >> >> > >> > Nicolas >> > >> >> >> >>> >> >>> > Cheers, >> >>> > Alexandre >> >>> > -- >> >>> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> >>> > Alexandre Bergel Â http://www.bergel.eu >> >>> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> >> >>> >> >>> >> >>> -- >> >>> Best regards, >> >>> Igor Stasenko. >> >>> >> >> >> >> >> >> >> >> -- >> >> Mariano >> >> http://marianopeck.wordpress.com >> >> >> >> >> > >> > > > > -- > best, > Eliot >

Sept. 14, 2011

Re: [Pharo-project] What is an abstract method?

by Eliot Miranda

On Wed, Sep 14, 2011 at 11:13 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2011/9/14 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > > 2011/9/14 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> > >> > >> On Wed, Sep 14, 2011 at 1:20 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >>> > >>> On 13 September 2011 19:52, Alexandre Bergel <alexandre.bergel(a)me.com> > >>> wrote: > >>> > Hi! > >>> > > >>> > Apparently, the following method is abstract: > >>> > > >>> > ArrayedCollection>>add: newObject > >>> > self shouldNotImplement > >>> > > >>> > If I evaluate: > >>> > (ArrayedCollection>>#add:) isAbstract => true > >>> > > >>> > This is not quite right. A method that is cancelled is not abstract. > >>> > > >>> > I propose to change > >>> > CompiledMethod>>abstractMarkers > >>> > ^ #(subclassResponsibility shouldNotImplement) > >>> > > >>> > into > >>> > CompiledMethod>>abstractMarker > >>> > ^ #shouldNotImplement > >>> > > >>> > Does it make sense? > >>> > > >>> > >>> yes > >> > >> > >> Why? It doesn't for me. A method defined as ^ self > subclassResponsibility > >> is "abstract" from my point of view. > >> > > > > See Eliot's mail, he already noticed the inversion. > > It's just a copy/paste type, the inbox/SLICE seems correct > > s/type/typo/ > :) :) :) > > > > > Nicolas > > > >> > >>> > >>> > Cheers, > >>> > Alexandre > >>> > -- > >>> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>> > Alexandre Bergel http://www.bergel.eu > >>> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > >>> > >>> > >>> -- > >>> Best regards, > >>> Igor Stasenko. > >>> > >> > >> > >> > >> -- > >> Mariano > >> http://marianopeck.wordpress.com > >> > >> > > > > -- best, Eliot

Sept. 14, 2011

Re: [Pharo-project] [COTDC] 84#2- MCMergeRecord

by laurent laffont

Today: MCMergeRecord Laurent On Sat, Sep 10, 2011 at 9:32 AM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Today: FreeTypeCacheLinkedList > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment > will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > Laurent >

Sept. 14, 2011

Re: [Pharo-project] What is an abstract method?

by Nicolas Cellier

2011/9/14 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2011/9/14 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >> >> On Wed, Sep 14, 2011 at 1:20 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> On 13 September 2011 19:52, Alexandre Bergel <alexandre.bergel(a)me.com> >>> wrote: >>> > Hi! >>> > >>> > Apparently, the following method is abstract: >>> > >>> > ArrayedCollection>>add: newObject >>> > Â Â Â Â self shouldNotImplement >>> > >>> > If I evaluate: >>> > (ArrayedCollection>>#add:) isAbstract => true >>> > >>> > This is not quite right. A method that is cancelled is not abstract. >>> > >>> > I propose to change >>> > CompiledMethod>>abstractMarkers >>> > Â Â Â Â ^ #(subclassResponsibility shouldNotImplement) >>> > >>> > into >>> > CompiledMethod>>abstractMarker >>> > Â Â Â Â ^ #shouldNotImplement >>> > >>> > Does it make sense? >>> > >>> >>> yes >> >> >> Why? It doesn't for me. A method defined as ^ self subclassResponsibility >> is "abstract" from my point of view. >> > > See Eliot's mail, he already noticed the inversion. > It's just a copy/paste type, the inbox/SLICE seems correct s/type/typo/ > > Nicolas > >> >>> >>> > Cheers, >>> > Alexandre >>> > -- >>> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> > Alexandre Bergel Â http://www.bergel.eu >>> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >

Sept. 14, 2011

Re: [Pharo-project] What is an abstract method?

by Nicolas Cellier

2011/9/14 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Wed, Sep 14, 2011 at 1:20 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 13 September 2011 19:52, Alexandre Bergel <alexandre.bergel(a)me.com> >> wrote: >> > Hi! >> > >> > Apparently, the following method is abstract: >> > >> > ArrayedCollection>>add: newObject >> > Â Â Â Â self shouldNotImplement >> > >> > If I evaluate: >> > (ArrayedCollection>>#add:) isAbstract => true >> > >> > This is not quite right. A method that is cancelled is not abstract. >> > >> > I propose to change >> > CompiledMethod>>abstractMarkers >> > Â Â Â Â ^ #(subclassResponsibility shouldNotImplement) >> > >> > into >> > CompiledMethod>>abstractMarker >> > Â Â Â Â ^ #shouldNotImplement >> > >> > Does it make sense? >> > >> >> yes > > > Why? It doesn't for me. A method defined as ^ self subclassResponsibility > is "abstract" from my point of view. > See Eliot's mail, he already noticed the inversion. It's just a copy/paste type, the inbox/SLICE seems correct Nicolas > >> >> > Cheers, >> > Alexandre >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel Â http://www.bergel.eu >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> > >> > >> > >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Mariano > http://marianopeck.wordpress.com > >

Sept. 14, 2011

Re: [Pharo-project] State of art for testing tools in Pharo?

by Denis Kudriashov

Hello 2011/9/14 Simon Denier <simon.denier(a)gmail.com> > > Especially, I am interested in the following topics: > > - any framework to perform BDD? > What's the status of SSpec? > I recomend you to try Mocketry http://www.squeaksource.com/Mocketry.html . It has nice "mocks" syntax and SSpec-like state specifications which are easilly extendable. See examples on squeaksource wiki part

Sept. 14, 2011

Re: [Pharo-project] What is an abstract method?

by Mariano Martinez Peck

On Wed, Sep 14, 2011 at 1:20 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 13 September 2011 19:52, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > > Hi! > > > > Apparently, the following method is abstract: > > > > ArrayedCollection>>add: newObject > > self shouldNotImplement > > > > If I evaluate: > > (ArrayedCollection>>#add:) isAbstract => true > > > > This is not quite right. A method that is cancelled is not abstract. > > > > I propose to change > > CompiledMethod>>abstractMarkers > > ^ #(subclassResponsibility shouldNotImplement) > > > > into > > CompiledMethod>>abstractMarker > > ^ #shouldNotImplement > > > > Does it make sense? > > > > yes > Why? It doesn't for me. A method defined as ^ self subclassResponsibility is "abstract" from my point of view. > > > Cheers, > > Alexandre > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > -- > Best regards, > Igor Stasenko. > > -- Mariano http://marianopeck.wordpress.com

Sept. 14, 2011

Re: [Pharo-project] State of art for testing tools in Pharo?

by Frank Shearar

On 14 September 2011 13:13, Simon Denier <simon.denier(a)gmail.com> wrote: > I would like to know what's the state of the art when it comes to tests in Pharo. What are the habits? The best practices? Is there any ongoing development? > > I stumble upon that this morning (through twitter) > http://www.lshift.net/blog/2011/09/13/checking-squeak-quickly I didn't try SqueakCheck out in Pharo, but it should Just Work. I'm more than happy to get bug reports. (One thing I forgot to do, and will do shortly, is kill the TheoryTestRunner. It was intended to be a console test runner, but when I found out how easy it was to integrate with/extend SUnit, I never bothered developing it further.) > Especially, I am interested in the following topics: > > - any framework to perform BDD? > What's the status of SSpec? I worked a bit on SSpec. I gave up: there were a number of references to classes that don't exist in SSpec, and once I'd cleared those away I boggled one too many times at some of the things it does (like raising an exception whose sole purpose is to set a flag, to show that you do actually have specs for some suite). I never did get a green bar. Niko Schwarz's PhExamples [1] stuff looks very interesting, and is on my todo list to check out. frank [1] http://www.squeaksource.com/phexample > I also saw that Sean was starting to play with Cucumber, I would be very interested to see that > > - developing a Seaside app in TDD/BDD mode? > Is there a tutorial out there about that? > I stumbled upon Seaside Testing, which looks like an interesting layer > http://www.shaffer-consulting.com/david/Seaside/TestingComponents/TestingCo… > > > -- > Simon Denier > > > > >

Sept. 14, 2011