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

Re: [Pharo-dev] [HELP WANTED] Getting ready for Pharo 5.0 release (CentOS, oldLibC, Nix, ArchLinux, and others)

by Bernardo Ezequiel Contreras

Hi Esteban, I tried again and it doesn't work. :( But now i found another issue, if you take a look to pharo5.0/shared folder you will see the file PharoV40.sources (wrong version for this release) thanks On Sun, May 1, 2016 at 7:13 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 01 May 2016, at 10:59, Stephan Eggermont <stephan(a)stack.nl> wrote: > > > > On 30/04/16 23:13, Bernardo Ezequiel Contreras wrote: > >> Hi Esteban, > >> i found a problem with one of the packages, see below > >> > >> ** TODO This interpreter (vers. 6505) cannot read image file (vers. > 6521) > > > > So you have a non-spur vm there. You need a spur one > > yes, but Pharo5.0-linux-oldLibC.zip should download a spur vmâ¦ I need to > review that :) > > Esteban > > > > > Stephan > > > > > > > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

May 4, 2016

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

by Stephan Eggermont

On 05/05/16 00:23, Stephan Eggermont wrote: > On 05/05/16 00:15, Stephan Eggermont wrote: >> On 04/05/16 08:19, stepharo wrote: >>> if you have ideas let us know too. >> >> Why does every NewValueHolder have its own announcer? >> And is initializing all those unused valueHolders in initialize >> of Spec presentation classes not slow? > > Just a 50721 image I'm working in on SpecGenerator with 20 open windows: > > NewValueHolder allInstances size > 4872 > > (NewValueHolder allInstances select: [ :each | (each instVarNamed: > #announcer) numberOfSubscriptions = 0 ])size > 2566 Announcers are not designed to handle 0 or 1 subscriptions. If we want that, we need to fix them Stephan

May 4, 2016

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

by Stephan Eggermont

On 05/05/16 00:15, Stephan Eggermont wrote: > On 04/05/16 08:19, stepharo wrote: >> if you have ideas let us know too. > > Why does every NewValueHolder have its own announcer? > And is initializing all those unused valueHolders in initialize > of Spec presentation classes not slow? Just a 50721 image I'm working in on SpecGenerator with 20 open windows: NewValueHolder allInstances size 4872 (NewValueHolder allInstances select: [ :each | (each instVarNamed: #announcer) numberOfSubscriptions = 0 ])size 2566

May 4, 2016

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

by Stephan Eggermont

On 04/05/16 08:19, stepharo wrote: > if you have ideas let us know too. Why does every NewValueHolder have its own announcer? And is initializing all those unused valueHolders in initialize of Spec presentation classes not slow? Stephan

May 4, 2016

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

by Glenn CavarlÃ©

stepharo wrote > cleaning Spec API. +10 ! just general remarks i have about Spec: I think the role of Spec may be clarified. If Spec is just an UI builder we may remove the "overengineering" and we need another framework that provides someting like MVC, MVP, MVVM or ... If Spec intent to be an "app" framework, it is too confused now, and yes, it needs a clear separation between the presentation, the presentation logic, the domain logic, ... Maybe, extending the SpecLayout's responsibility should be one idea to handle the full "presentation" part, like the role played by markup languages. I'm not saying I want to transform Spec to XML :), but its role is basically the same. The existing separation between the widget declarations (instance side) and the widgets composition (class side) seem confusing to me. And we need also a clearest way to bind domain models to widgets. Using #whenSomethingChangedDo:aBlock everywhere make code a bit hard to read and to debug, if not completly ugly in complex UI... For me, the first goal of an UIBuilder (graphical or programmatic) is to ease the presentation and to ease the two-way data-binding with domain data/logic. If the ease-of-use of Spec is not more obvious compared to the underlying widget libraries (Morph / Bloc soon maybe...), it will be difficult to convince people to use it in future developments... But it is maybe a bit off topic -> "cleaning Spec API". Cheers, Glenn. ----- Glenn CavarlÃ© -- View this message in context: http://forum.world.st/call-for-cleaning-ideas-around-Spec-tp4893494p4893625… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 4, 2016

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

by Stephan Eggermont

On 04/05/16 18:18, stepharo wrote: > Can you open bug entries with such points? 18164 Put drag-and-drop behaviour in one object 18165 ComposableModel: aboutText seems to be in the wrong place 18166 Where should focus change keystrokes be handled? Stephan

May 4, 2016

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