May 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] call for cleaning ideas around Spec

by Stephan Eggermont

On 04/05/16 16:10, Denis Kudriashov wrote: > 2016-05-04 15:34 GMT+02:00 Stephan Eggermont <stephan(a)stack.nl>: > >> There are too many Models. A clear distinction between DomainModel >> and ViewModel is needed. Please explain when a ViewController should >> be a Presenter. Where is the boundary between MVC and MVP? >> > > But there is good article about it > http://www.object-arts.com/downloads/papers/TwistingTheTriad.PDF > I know. But that is not what Spec does. Stephan

May 4, 2016

Re: [Pharo-dev] call for cleaning ideas around Spec

by Thierry Goubier

2016-05-04 13:43 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > by a factor of at least 2,5x compared to pure Morphic (I've seen a 5x). >> > > This doesn't mean anything. Can you please provide concrete numbers (what > you experience) and what is your expected target? Because I do not have > such problematic experience. > It depends a lot on the underlying platform you use. If you are on a Macbook Pro with a core i7 with turbo boost of 3GHz, no Pharo GUI, even very badly coded, will register. On a lower spec processor, it is significantly different. > Even if morphic took 40 ms and Spec 100 ms to open a window, then it's a > non-priority problem (~100ms to open a medium-sized window is a non-issue). > Unless you are opening such windows every minuteâ¦ > I'm talking about 250ms to open a very small window, 400/500ms for some tools, and a significant delay on many interactions because you have to wait for the rebuilding of a window components. It becomes problematic when you can type faster than the GUI reacts (scrolling with keypresses, for example). > Also I am a bit afraid that the slowness would come from the layout > processing / composing the objectsâ¦ which is a really complex piece, and > right now our priority is cleaning up the user-facing API. > When profiling, it doesn't seems to be the layout. But processing the object spec, yes. > But at least we can think about it, whether we would be able to do > something about it now or not. > Thanks, Thierry > > Peter >

May 4, 2016

Re: [Pharo-dev] call for cleaning ideas around Spec

by Denis Kudriashov

2016-05-04 15:34 GMT+02:00 Stephan Eggermont <stephan(a)stack.nl>: > There are too many Models. A clear distinction between DomainModel > and ViewModel is needed. Please explain when a ViewController should > be a Presenter. Where is the boundary between MVC and MVP? > But there is good article about it http://www.object-arts.com/downloads/papers/TwistingTheTriad.PDF

May 4, 2016

Re: [Pharo-dev] call for cleaning ideas around Spec

by Stephan Eggermont

On 04/05/16 08:19, stepharo wrote: > Hi guys > > > this afternoon we will have a meeting with Peter and others to talk > about cleaning Spec API. In AbstractWidgetModel we have dragEnabled dropEnabled dragTransformationBlock wantDropBlock acceptDropBlock transferBlock That needs to be one instance variable dealing with drag and drop. ComposableModel: aboutText seems to be in the wrong place. That is a WindowModel property, and we seem to need some kind of mechanism to propagate property access in the widget hierarchy. ComposableModel: keyStrokesForNextFocusHolder keyStrokesForPreviousFocusHolder I'm pretty sure I do not want focus switch to be an individual widget concern Stephan

May 4, 2016

Re: [Pharo-dev] call for cleaning ideas around Spec

by Stephan Eggermont

On 04/05/16 13:43, Peter UhnÃ¡k wrote: >> >> by a factor of at least 2,5x compared to pure Morphic (I've seen a 5x). >> > > This doesn't mean anything. Can you please provide concrete numbers (what > you experience) and what is your expected target? Because I do not have > such problematic experience. Thierry develops on a machine that is somewhat slower than those most Pharo users develop on: a Celeron 2955U machine. For Pharo I'd hope to be able to reasonably do development on a Raspberry Pi2. He is very aware of Morphic performance issues, so that factor 2.5 is not the layout processing, as that is the same for Morphic and Spec. We could add some Spec performance tests to jenkins/travis to see when we have regressions. Stephan

May 4, 2016

Re: [Pharo-dev] call for cleaning ideas around Spec

by Stephan Eggermont

On 04/05/16 15:24, stepharo wrote: > We are thinking that we would like to rename ComposableModel into Presenter > > to convey its role into the MVC triad. > > What do the spec users think? There are too many Models. A clear distinction between DomainModel and ViewModel is needed. Please explain when a ViewController should be a Presenter. Where is the boundary between MVC and MVP? Stephan

May 4, 2016

Re: [Pharo-dev] call for cleaning ideas around Spec

by stepharo

We are thinking that we would like to rename ComposableModel into Presenter to convey its role into the MVC triad. What do the spec users think? Stef Le 4/5/16 Ã 08:19, stepharo a Ã©crit : > Hi guys > > > this afternoon we will have a meeting with Peter and others to talk > about cleaning Spec API. > > If you want/can join let us know > > else we can organise another skype. > > if you have ideas let us know too. > > Stef >

May 4, 2016

Re: [Pharo-dev] [ANN] Pharo Astares Distribution

by Pierce Ng

On Tue, May 03, 2016 at 10:01:26PM +0200, Torsten Bergmann wrote: > into an own kind of Pharo distribution that I call AstaresDistribution. Nice! And that logo is awesome. Pierce

May 4, 2016

Re: [Pharo-dev] call for cleaning ideas around Spec

by Peter UhnÃ¡k

> > by a factor of at least 2,5x compared to pure Morphic (I've seen a 5x). > This doesn't mean anything. Can you please provide concrete numbers (what you experience) and what is your expected target? Because I do not have such problematic experience. Even if morphic took 40 ms and Spec 100 ms to open a window, then it's a non-priority problem (~100ms to open a medium-sized window is a non-issue). Unless you are opening such windows every minuteâ¦ Also I am a bit afraid that the slowness would come from the layout processing / composing the objectsâ¦ which is a really complex piece, and right now our priority is cleaning up the user-facing API. But at least we can think about it, whether we would be able to do something about it now or not. Peter

May 4, 2016

Re: [Pharo-dev] Keep print-it output on the same line in GTPlayground

by Peter UhnÃ¡k

Since I didn't want to wait, for now I've fixed it (for myself) by changing it to RubTextEditor>>atEndOfLineInsertAndSelect: aString | last lastChar | last := (self encompassParagraph: self selectionInterval) last. (self textArea text at: last) = Character cr ifFalse: [ last := last + 1 ]. self insertAndSelect: aString at: last On Tue, May 3, 2016 at 3:05 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > +1 > > 2016-05-03 14:41 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> >> >> On Tue, May 3, 2016 at 1:56 PM, Nicolai Hess <nicolaihess(a)gmail.com> >> wrote: >> >>> >>> >>> 2016-05-03 13:26 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: >>> >>>> >>>> >>>> On Tue, May 3, 2016 at 10:26 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>>> >>>>> the conclusion was to print the result on the next line. >>>>>> >>>>> >>>>> Well this isn't true for the last line. >>>>> >>>> >>>> Yes, right now it only inserts it on the new line if there is a line. >>>> >>>> >>>>> >>>>> The problem isn't just that it prints on the next line for the >>>>> intermediate results, but that it puts it before the next content. >>>>> Even if it was on a line of it's own it would be much better. >>>>> >>>> >>>> We could change it to always insert a new line and add the printed >>>> content to that line. >>>> But should it add an extra line if there already exists an empty line >>>> bellow? >>>> >>> >>> I would change it to "always print on the same line" >>> >> >> +1 >> > >

May 4, 2016