- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] PhD Thesis offer

by stepharo

looks like a job for mOose :) Le 4/5/16 Ã 12:37, jannik laval a Ã©crit : > Dear friends, > > I am looking for a french student (or someone speaking french) who > wants to engage in a CIFRE PhD thesis (it is a thesis with a french > company). > > The subject is attached to the mail. > > Best regards, > -- > ~~Jannik Laval~~ > Enseignant-chercheur > Responsable PÃ©dagogique Licence Coordonnateur de Projet en SystÃ¨me > d'Information > IUT LumiÃ¨re, UniversitÃ© Lyon LumiÃ¨re > laboratoire DISP > http://www.jannik-laval.eu > http://www.phratch.com > http://www.approchealpes.info

May 4, 2016

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

by stepharo

***Thanks*** Stephan this is the kind of things we should start fixing!!! I want more :). Can you open bug entries with such points? Stef Le 4/5/16 Ã 16:03, Stephan Eggermont a Ã©crit : > > > 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 stepharo

I would rename composableModel into Presenters. Stef Le 4/5/16 Ã 16:58, Stephan Eggermont a Ã©crit : > 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 stepharo

First we should clean it, then we speed it up. Stef Le 4/5/16 Ã 15:45, Stephan Eggermont a Ã©crit : > 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 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