- Pharo-dev - lists.pharo.org

[Pharo-project] Glorp question

by Friedrich Dominicus

Well this may be an ambigous question, but can Glorp generate a description from an existent relationatl Database model? e.g assume i wouuld have Customer id integer field1 string field2 integer address_id foreign key into address address id integer zip .... And Glorp generates a Model from it? Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

Sept. 15, 2011

Re: [Pharo-project] Explicit return in []

by StÃ©phane Ducasse

On Sep 15, 2011, at 8:13 AM, Lukas Renggli wrote: > > Q1 When are they absolutely required? > > Not needed, but convenient. JavaScript for example does't have them. Things are done differently (exceptions, return values, ...). do you have some examples how they do that? > > > Q2 What replacing mechanisms would be needed? > > Exceptions are typically used to simulate non-local returns if really needed. > > Lukas > > > Q3 What would we gain from an implementation stand point? > > It seems that in resilience lars removed them and more. > > > > Stef > > > > for Q1 I see > > > > foo > > x isZero ifTrue: [^ 33]. > > self continue > > > > -- > Lukas Renggli > www.lukas-renggli.ch

Sept. 15, 2011

Re: [Pharo-project] Explicit return in []

by Lukas Renggli

> Q1 When are they absolutely required? Not needed, but convenient. JavaScript for example does't have them. Things are done differently (exceptions, return values, ...). > Q2 What replacing mechanisms would be needed? Exceptions are typically used to simulate non-local returns if really needed. Lukas > Q3 What would we gain from an implementation stand point? > It seems that in resilience lars removed them and more. > > Stef > > for Q1 I see > > foo > x isZero ifTrue: [^ 33]. > self continue > -- Lukas Renggli www.lukas-renggli.ch

Sept. 15, 2011

Re: [Pharo-project] Explicit return in []

by Lukas Renggli

> Q1 When are they absolutely required? Not needed, but convenient. JavaScript for example does't have them. Things are done differently (exceptions, return values, ...). > Q2 What replacing mechanisms would be needed? Exceptions are typically used to simulate non-local returns if really needed. Lukas > Q3 What would we gain from an implementation stand point? > It seems that in resilience lars removed them and more. > > Stef > > for Q1 I see > > foo > x isZero ifTrue: [^ 33]. > self continue > -- Lukas Renggli www.lukas-renggli.ch

Sept. 15, 2011

[Pharo-project] Explicit return in []

by StÃ©phane Ducasse

Hi this is early (at least to me) and I was asking myself a probably stupid question. But I would like to get your smart answers :) does a smalltalk like language really need explicit return in []? Q1 When are they absolutely required? Q2 What replacing mechanisms would be needed? Q3 What would we gain from an implementation stand point? It seems that in resilience lars removed them and more. Stef for Q1 I see foo x isZero ifTrue: [^ 33]. self continue

Sept. 15, 2011

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

by Dennis Schetinin

+1 though Mocks are for TDD mostly, not just for testing. 2011/9/14 Denis Kudriashov <dionisiydk(a)gmail.com> > 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 > -- Dennis Schetinin

Sept. 15, 2011

[Pharo-project] Fuel or image segments (project files)

by Dimitry Golubovsky

Hi, The application I am working on (which currently runs under Squeak VM on Android) will be migrated to Pharo. The current version heavily relies upon use of image segments (projects) which provides a simple (though slow) way to save/restore the application data not touching the image (the Squeak port is unable to save images anyway, Cog can do this, but I'd rater not touch the image) with versioning. Are image segments supported in Pharo Core same way? I saw a message about stopping the support of image segments in future versions of Pharo in favor of Fuel. What is current status of Fuel development? Is it usable? Thanks. -- Dimitry Golubovsky Anywhere on the Web

Sept. 14, 2011

Re: [Pharo-project] Debugger bug fix 1

by Michael Roberts

sorry guys, i have not had time to be online much. Eliot, guys, thanks for the code (Phillipe, Hi!). I think i saw marcus comment on the tracker that something sensible had been done? i just wanted to offer a thought that we do not change the original Pharo debugger too much from Squeak. i saw a recent issue # that was a 'debugger refactoring'. tracking merges & bugs between Squeak and Pharo is hard, it would be nice to concentrate on pure fixes where possible.... (if you itch to refactor...help Doru with the new debugger model etc). cheers Mike On Thu, Sep 8, 2011 at 9:37 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I'm a bit busy (too much to follow carefully). > Just tell me what I should integrate and I will do it fast. > > Stef > > On Sep 8, 2011, at 2:37 PM, Michael Roberts wrote: > >> So I found the bug with the first assignment. It is caused by a difference between squeak and Pharo in SortedCollection. (on my phone so will be brief) >> >> In Pharo the debugger map collection gets sorted and asked for an index for a given pc. It is supposed to answer 1 because there is no match and it is expected to be the first index for insertion. However when the asSortedCollection gets done the internal start index of the collection is 2. This manifests the bug. 2 is answered as the insertion position but this is a value internal to the collection. >> >> Squeak does not have this bug because it forces a reset of the start index to 1. Hope that makes sense. I don't know what the correct fix is. We copy the reset:1 type code to force the collection to have start from 1 property. We check semantics of index for insertion. Is it the position of the element of index relative to pointers? Or we change the debugger to calculate the offset (but this feels wrong) >> >> So this is an opportunity for some test cases and fixes around sorted collection if we know what the correct semantics are. This leak of '2' out of the collection is only wrong if 2 is a valid state. If that makes sense... >> >> Cheers >> Mike > > >

Sept. 14, 2011

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