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

Re: [Pharo-project] Regarding SimpleMorphic

by Fernando Olivero

A nice paper on this topic, On the Notion of Inheritance (1996) by Antero Taivalsaari http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.110.7221 Fernando On Mon, Apr 4, 2011 at 2:01 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 31 March 2011 22:03, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> >>> >>> Stef, >>> >>> I'm sure you really miss last year, but we're entering the second quarter of 2011 ;-) >>> >>> []s >>> >>> Getting back to the technical part of your post, I also always tried to understand why in some cases we end up with this strange hierarchy >> >> people long time ago thought that inheritance = reuse. >> > > It is strange, because i learned that inheritance is _specialization_. > > And i actually haven't took much care about subtleties of this, before > i met smalltalk and start coding in it. It is in smalltalk, where it > become apparent to me: > - subclassing is not a way to "extend" a superclass, it is a way to > specialize a superclass. > > >>> (which you mock saying Car inherits from Wheel), specially if we take in account Smalltalk is a single inheritance language, so you have only a shot to specialize a given class. >>> >>> Maybe the folks that did it in the past were less used to composing than inheriting and the second way saves writing some new methods to avoid breaking the Demeter principle? >> >> I'm quite sure that LOD was not their concern. >>> >>> Perhaps understanding the "crucial incident" could lead us to better roadmap. . . >> >> No. We know design. We should just implement it. >> >> Stef >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

April 4, 2011

Re: [Pharo-project] [ANN] For testing: 1.2.1 One-Click

by Hannes Hirzel

On 4/3/11, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Out of the box, system browsers are opening with a scroll bar between the > lists and code pane. Click on it, and the bar disappears. > > Curious which vm was in use, I tried: > > SmalltalkImage current vmVersion 'Squeak3.10.2 of ''5 June 2008'' > [latest update: #7179]' > > Looks weird?? Ask the vm itself. In a terminal (I think in the correct > place): > > ./squeakvm -version > 4.0.3-2202 #1 XShm Tue Apr 13 11:56:47 PDT 2010 gcc 4.3.2 > Linux vps2.piumarta.com 2.6.18-028stab053.10-ent #1 SMP Thu Feb 28 20:34:08 > MSK 2008 i686 GNU/Linux > plugin path: /somewhere/Contents/Linux/ [default: > /somewhere/Pharo-1.2.1/Contents/Linux/] > > Ubuntu Lucid. > > oCompletion is not going away easily. No denigration of the hard work that > went into it, I want to simply turn it off, read what it otherwise can't > help covering, and type myself. > > Bill > Ubuntu 10.04.1 LTS (Lucid) Some time after starting the tests the screen goes blank and remains blank..... --Hannes

April 4, 2011

Re: [Pharo-project] [ANN 1.2] 1.2.1 Full Release Image

by Hannes Hirzel

On 4/3/11, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Apr 3, 2011, at 10:22 AM, Lukas Renggli wrote: > >> A pity that broken OB code is used, nevertheless it is quite usable. >> > > Yes, and I added a bug report on March 22: > > http://code.google.com/p/pharo/issues/detail?id=3842 > > But nobody cared to react. So how important can it be? > > There are two possibilities: > > -> Postponing the release because it's not perfect. > (We are doing this for *3 Months* already) > > -> Not release and wait another 3 Months. > > > Marcus There are _three_ possibilities: -> Postponing the release because it's not perfect. (We are doing this for *3 Months* already) -> Not release and wait another 3 Months. -> Mark the issues which are not resolved as 'Known bug', post this list some time before the release and ask people if they do not have objections. Take silence for agreement and then include the 'Known bug list' in the release announcement. --Hannes

April 4, 2011

Re: [Pharo-project] Regarding SimpleMorphic

by Igor Stasenko

On 31 March 2011 22:03, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >> >> Stef, >> >> I'm sure you really miss last year, but we're entering the second quarter of 2011 ;-) >> >> []s >> >> Getting back to the technical part of your post, I also always tried to understand why in some cases we end up with this strange hierarchy > > people long time ago thought that inheritance = reuse. > It is strange, because i learned that inheritance is _specialization_. And i actually haven't took much care about subtleties of this, before i met smalltalk and start coding in it. It is in smalltalk, where it become apparent to me: - subclassing is not a way to "extend" a superclass, it is a way to specialize a superclass. >> (which you mock saying Car inherits from Wheel), specially if we take in account Smalltalk is a single inheritance language, so you have only a shot to specialize a given class. >> >> Maybe the folks that did it in the past were less used to composing than inheriting and the second way saves writing some new methods to avoid breaking the Demeter principle? > > I'm quite sure that LOD was not their concern. >> >> Perhaps understanding the "crucial incident" could lead us to better roadmap. . . > > No. We know design. We should just implement it. > > Stef > -- Best regards, Igor Stasenko AKA sig.

April 4, 2011

Re: [Pharo-project] Pharo 1.3 process

by Esteban Lorenzano

btw... how's the repository policy we are going to use? to keep MetacelloRepository? or better to use MetacelloRepositoryForPharo12, etc.? if we are going for the 2nd option, we need to start switching :P cheers, Esteban El 03/04/2011, a las 4:17p.m., StÃ©phane Ducasse escribiÃ³: >> >> - Get rid of the Core/Full image destinction. This does not work. And I will not do a release with having two images again... it never worked, and it will never work. > > Yes but for that we need a good browser that we can maintain. > >> Yes, 2 images seems hard to maintain and hard to understand for newcomers. >> >> May be we can have: >> - Metacello configurations tested separately in Pharo-Clients in Hudson (like PetitParser, Seaside, ...) - drop the ones that don't have tests >> - drop actual Pharo, rename PharoCore => Pharo. >> - GUI tool in Pharo to easy load Metacello configurations (some stuff must be easy to load for newbies, especially help > > This is the idea. This is why I asked people (mariano in particular) to focus on helping metacello taking off the ground > and to focus on metacello distributions. Once this is up and running. we can have Pharo and hudson loads and certifies the distributions. > > Stef

April 4, 2011

Re: [Pharo-project] Issue 3950 in pharo: SequenceableCollection>>#findBinary and friends (wrong exceptionBlock, delegation)

by pharo＠googlecode.com

Comment #2 on issue 3950 by sven.van...(a)gmail.com: SequenceableCollection>>#findBinary and friends (wrong exceptionBlock, delegation) http://code.google.com/p/pharo/issues/detail?id=3950 You're right, that issue deals with the same subject, and from a first look, modulo some units tests, should solve the issue that I raised. I did not know that a multi argument #cull:[cull:[cull:]] silently skipped arguments until the block's argument count matches. I should have searched the issue list first, thanks for the pointer. Sven

April 4, 2011

Re: [Pharo-project] Regarding SimpleMorphic

by Benjamin

On Apr 1, 2011, at 8:29 PM, csrabak(a)bol.com.br wrote: > Em 31/03/2011 18:10, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> escreveu: > >> On Mar 31, 2011, at 8:08 PM, csrabak(a)bol.com.br wrote: >> >>> Benjamin, >>> Testing the understanding of the diagram of yours: >>> Model, Pluggable TextMorph, Pluggable CodeMorph, Browser, Browser >>> Model, Debugger and Debugger Model all inherit from Object? >>> the representation of "based on" means that it changes states in >>> the model counterpart, and "use" means that has some similarity >>> but not enough to inherit from the other classes? >> >> based on means, that the view (on right) is based on the model (on >> left) > > This still tautological: does "based on" means the structure is one-to-one correspondent? > > Or are we re-introducing the MVC paradigm and the "based on" means that the View has to know the inners of the Model in order to be built? Yes it's MVC, the problem is there is no proper controllers ... Ben > >> use means that the View use/is composed with the other view. >> By example, Browser is based on BrowserModel, and Browser (as a >> Morph by example) contains a PluggableCodeMorph > > This one explains well your thought, or at least I've the belief I understood. > >> >> >> Is it better like that ? > > The second part, much better, for the first one I'm still lost :-( > >> (I'm sorry, but I'm not sure to be able to do a good UML ^^) > > OK. > > Let's see if after fully understanding your idea we can come by something. > >

April 4, 2011

Re: [Pharo-project] Announcement real problems - please read and comment.

by Igor Stasenko

On 4 April 2011 12:55, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >>>>> Henrik what is your answer to problem 1 >>>>> >>>>> Problem 1 >>>>> Â Â - the second announcement was never sent, because the first one broke the second was blocked. >>>>> Â Â >> Â we should make sure that if an announcement leads to an error, other annoucements on the same emit should pass >>>>> >>>>> Because we can get the system down just because one guy can register a bug. >>>> http://forum.world.st/Another-finalization-concern-error-handling-td2989615… >>>> >>>> It's basically the same. >>> ?? >> Same basic problem, same solutions apply. >> I'd rather not repeat the exact same discussion. >> Just exchange "finalization" with "announcement delivery" when reading the thread > > Igor what was exactly the summary? > Summary, in short, is following: we want to iterate over some arbitrary collection and perform an action per each element, like: collection do: [:each | each doSomeAction ] but the problem here is that if one action triggers an error, then your loop are interrupted and no other actions performed for the remaining elements of collection. So, we need such behavior , that guarantees that: a) all elements , except errorneous get processed b) if an error is unhandled by action , then show a debugger window in terms of implementation this means that we should run each action in separate forked process (and Eliot described a clever scheme how to avoid most overhead of forking). So then, even if some action will trigger an error, it won't interrupt the loop and error could be handled in debugger > Stef > -- Best regards, Igor Stasenko AKA sig.

April 4, 2011

Re: [Pharo-project] Announcement real problems - please read and comment.

by StÃ©phane Ducasse

>>>> Henrik what is your answer to problem 1 >>>> >>>> Problem 1 >>>> - the second announcement was never sent, because the first one broke the second was blocked. >>>> >> we should make sure that if an announcement leads to an error, other annoucements on the same emit should pass >>>> >>>> Because we can get the system down just because one guy can register a bug. >>> http://forum.world.st/Another-finalization-concern-error-handling-td2989615… >>> >>> It's basically the same. >> ?? > Same basic problem, same solutions apply. > I'd rather not repeat the exact same discussion. > Just exchange "finalization" with "announcement delivery" when reading the thread Igor what was exactly the summary? Stef

April 4, 2011

Re: [Pharo-project] Issue 3950 in pharo: SequenceableCollection>>#findBinary and friends (wrong exceptionBlock, delegation)

by pharo＠googlecode.com

Comment #1 on issue 3950 by ryd...(a)gmail.com: SequenceableCollection>>#findBinary and friends (wrong exceptionBlock, delegation) http://code.google.com/p/pharo/issues/detail?id=3950 See Issue 3345 Something went wrong when the same was attempted in Pharo... (Not using cull, not rewriting the methods which were part of old api, etc.) Personally, I'm not sure what the actual benefits of a do: parameter, and hi/lo error parameters are. Juan and Levente are usually pretty smart guys though :)

April 4, 2011