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

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

by Marcus Denker

On Sep 15, 2011, at 8:53 AM, Martin Dias wrote: > Hi Dimitri, > > I think image segments are supported in same way in Pharo but I'm not sure. > ImageSegments are in 1.3, but we removed them in 1.4. But Projects are not working in Pharo since 1.0. > About Fuel, it is in active development. It currently works and has several release versions but it doesn't replace completely ImageSegment. Hopefully we might be capable of doing that in some months... at the moment you can find some limitations, especially if you were using DiskProxy (do you?). > > There is more info, including how to install and try it, here: http://rmod.lille.inria.fr/web/pier/software/Fuel > > Cheers, > MartÃn > > > On Wed, Sep 14, 2011 at 6:59 PM, Dimitry Golubovsky <golubovsky(a)gmail.com> wrote: > 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 > > -- Marcus Denker -- http://marcusdenker.de

Sept. 15, 2011

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

by Martin Dias

Hi Dimitri, I think image segments are supported in same way in Pharo but I'm not sure. About Fuel, it is in active development. It currently works and has several release versions but it doesn't replace completely ImageSegment. Hopefully we might be capable of doing that in some months... at the moment you can find some limitations, especially if you were using DiskProxy (do you?). There is more info, including how to install and try it, here: http://rmod.lille.inria.fr/web/pier/software/Fuel Cheers, MartÃn On Wed, Sep 14, 2011 at 6:59 PM, Dimitry Golubovsky <golubovsky(a)gmail.com>wrote: > 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. 15, 2011

[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