- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Explaining Spec2 and why Bloc is on the roadmap

by Ben Coman

Thanks for the background info Steph. On Thu, 2 May 2019 at 17:28, ducasse <stepharo(a)netcourrier.com> wrote: > Spec 2.0 revisits fundamentally Spec. > - adds much better layouts (we will deprecate the interpreter design) A very long time ago that I was debugging a Spec app was that debugging INTO the framework from application code would take 30 odd steps before it got to evaluate the block passed by the application code. Sorry thats a bit vague, but I'm hoping deprecating the interpreter will improve such experience. As a general comment also, architectures using stored blocks for configuration rather than passing in an "object with defined methods" seems a lot "less live". Changing the code inside the block doesn't change the behaviour of existing elements. But maybe the "methods" way has its own issues. cheers -ben

May 3, 2019

Re: [Pharo-dev] [Pharo-users] Explaining Spec2 and why Bloc is on the roadmap

by Eric Gade

Stef, Exciting news all around. Is this s good opportunity to revisit theming? I made a good attempt to wrap my head around themes about a year ago or so, but it's quite complex. If now's not (understandably) the time, how will themes work with this new multiple-backend approach? On Thu, May 2, 2019 at 11:45 AM Alexandre Bergel via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Hi Stef, > > Thanks for this email. Spec 2 really looks great. > It is also great to foresee an integration of Bloc/Brick in Pharo. > > Cheers, > Alexandre > > > On May 2, 2019, at 5:27 AM, ducasse <stepharo(a)netcourrier.com> wrote: > > > > Dear Pharoers > > > > We would like to explain what is Spec 2.0 and how Bloc is on the Pharo > roadmap. > > > > Spec is a way to support a way to express and reuse application > interaction logic. > > Spec was first developed by Benjamin van Ryseghem and others while > supervised > > by StÃ©phane Ducasse. > > Over the years we cleaned Spec, but we never took the time to really > revisit it, and Spec > > was never stressed outside the scope of Pharo tools (even if there is > some people who > > used it in their projects, this was not the general case). There was a > need to deeply rethink > > the way we express and reuse interaction application logic. > > > > Spec 2.0 revisits fundamentally Spec. The consortium wants to > acknowledge the strong financial > > support of Schmidt in this new development. Here is a list of points we > are working on to support companies > > to build modern applications with Pharo. > > > > - adding support for many widgets and at the same time improving > existing widgets such as fasttable > > - adds much better layouts (we will deprecate the interpreter > design) > > - introducing a new way to architecture an application: > > Spec20 introduces the notion of application to better handle > resources and window flow > > - revisiting the internal logic of Spec (to remove useless parts > and enhance the ones that works) > > - adding many tests > > > > In addition we want that Spec 2.0 is not tight anymore with Morphic. > > Why? Because we want to make sure that: > > - companies can deploy desktop applications > > - we can reuse all the tools logic of Pharo with new widgets sets > such as Brick (widgets on top of Bloc) > > without having to rewrite everything. > > > > This is why Spec2.0 can optionally render using Gtk3.0. It also means > that in the future we can have native widgets. > > > > Now that Bloc/Brick is finally reaching a point where it can be tried > and eventually adopted, we want to > > make sure the transition to it will not force us to throw away the tools > we developed last ten years. > > We think that Bloc needs some effort to clean and structure it and > Spec2.0 gives the time to let Bloc and Brick > > mature. Also, we want to make sure that in the future we will be able to > adopt other backends in case we > > decide it (Remember new now is old tomorrow and while Bloc/Brick is new > and modern, it will not remain > > new and modern forever). > > > > Brick needs to be ready for Pharo consumption, and to make it possible > we need to move the image to converge. > > With Spec 2.0, in future versions we will just need to define a new > backend to get all our tools working. > > > > The Pharo Board > > > > > > > > > -- Eric

May 2, 2019

Re: [Pharo-dev] Explaining Spec2 and why Bloc is on the roadmap

by Alexandre Bergel

Hi Stef, Thanks for this email. Spec 2 really looks great. It is also great to foresee an integration of Bloc/Brick in Pharo. Cheers, Alexandre > On May 2, 2019, at 5:27 AM, ducasse <stepharo(a)netcourrier.com> wrote: > > Dear Pharoers > > We would like to explain what is Spec 2.0 and how Bloc is on the Pharo roadmap. > > Spec is a way to support a way to express and reuse application interaction logic. > Spec was first developed by Benjamin van Ryseghem and others while supervised > by StÃ©phane Ducasse. > Over the years we cleaned Spec, but we never took the time to really revisit it, and Spec > was never stressed outside the scope of Pharo tools (even if there is some people who > used it in their projects, this was not the general case). There was a need to deeply rethink > the way we express and reuse interaction application logic. > > Spec 2.0 revisits fundamentally Spec. The consortium wants to acknowledge the strong financial > support of Schmidt in this new development. Here is a list of points we are working on to support companies > to build modern applications with Pharo. > > - adding support for many widgets and at the same time improving existing widgets such as fasttable > - adds much better layouts (we will deprecate the interpreter design) > - introducing a new way to architecture an application: > Spec20 introduces the notion of application to better handle resources and window flow > - revisiting the internal logic of Spec (to remove useless parts and enhance the ones that works) > - adding many tests > > In addition we want that Spec 2.0 is not tight anymore with Morphic. > Why? Because we want to make sure that: > - companies can deploy desktop applications > - we can reuse all the tools logic of Pharo with new widgets sets such as Brick (widgets on top of Bloc) > without having to rewrite everything. > > This is why Spec2.0 can optionally render using Gtk3.0. It also means that in the future we can have native widgets. > > Now that Bloc/Brick is finally reaching a point where it can be tried and eventually adopted, we want to > make sure the transition to it will not force us to throw away the tools we developed last ten years. > We think that Bloc needs some effort to clean and structure it and Spec2.0 gives the time to let Bloc and Brick > mature. Also, we want to make sure that in the future we will be able to adopt other backends in case we > decide it (Remember new now is old tomorrow and while Bloc/Brick is new and modern, it will not remain > new and modern forever). > > Brick needs to be ready for Pharo consumption, and to make it possible we need to move the image to converge. > With Spec 2.0, in future versions we will just need to define a new backend to get all our tools working. > > The Pharo Board > > >

May 2, 2019

[ANN] Pharo Consortium New Academic Member: ISCLab

by Marcus Denker

The Pharo Consortium is very happy to announce that ISCLab has joined the Consortium as an Academic Member. About - ISCLab: Intelligent Software Construction Laboratory, Department of Computer Science, FCFM, University of Chile. The ISCLab develops methodologies to build software systems that are both resource efficient (CPU, memory, energy) and adequate with modern software development techniques. We push further the knowledge frontier of Software Engineering with innovative methodologies, rigorous empirical evaluations, and valuable software artifacts. https://isclab.dcc.uchile.cl - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org

May 2, 2019

Explaining Spec2 and why Bloc is on the roadmap

by ducasse

Dear Pharoers We would like to explain what is Spec 2.0 and how Bloc is on the Pharo roadmap. Spec is a way to support a way to express and reuse application interaction logic. Spec was first developed by Benjamin van Ryseghem and others while supervised by StÃ©phane Ducasse. Over the years we cleaned Spec, but we never took the time to really revisit it, and Spec was never stressed outside the scope of Pharo tools (even if there is some people who used it in their projects, this was not the general case). There was a need to deeply rethink the way we express and reuse interaction application logic. Spec 2.0 revisits fundamentally Spec. The consortium wants to acknowledge the strong financial support of Schmidt in this new development. Here is a list of points we are working on to support companies to build modern applications with Pharo. - adding support for many widgets and at the same time improving existing widgets such as fasttable - adds much better layouts (we will deprecate the interpreter design) - introducing a new way to architecture an application: Spec20 introduces the notion of application to better handle resources and window flow - revisiting the internal logic of Spec (to remove useless parts and enhance the ones that works) - adding many tests In addition we want that Spec 2.0 is not tight anymore with Morphic. Why? Because we want to make sure that: - companies can deploy desktop applications - we can reuse all the tools logic of Pharo with new widgets sets such as Brick (widgets on top of Bloc) without having to rewrite everything. This is why Spec2.0 can optionally render using Gtk3.0. It also means that in the future we can have native widgets. Now that Bloc/Brick is finally reaching a point where it can be tried and eventually adopted, we want to make sure the transition to it will not force us to throw away the tools we developed last ten years. We think that Bloc needs some effort to clean and structure it and Spec2.0 gives the time to let Bloc and Brick mature. Also, we want to make sure that in the future we will be able to adopt other backends in case we decide it (Remember new now is old tomorrow and while Bloc/Brick is new and modern, it will not remain new and modern forever). Brick needs to be ready for Pharo consumption, and to make it possible we need to move the image to converge. With Spec 2.0, in future versions we will just need to define a new backend to get all our tools working. The Pharo Board

May 2, 2019

[Pharo 8.0] Build #250: 2185-Color--storeOn-loses-precision

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #250 was: FAILURE. The Pull Request #3260 was integrated: "2185-Color--storeOn-loses-precision" Pull request url: https://github.com/pharo-project/pharo/pull/3260 Issue Url: https://github.com/pharo-project/pharo/issues/2185 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 1, 2019

[Pharo 8.0] Build #249: 3279-UndefinedClass-cleaning

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #249 was: FAILURE. The Pull Request #3280 was integrated: "3279-UndefinedClass-cleaning" Pull request url: https://github.com/pharo-project/pharo/pull/3280 Issue Url: https://github.com/pharo-project/pharo/issues/3279 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 1, 2019

[Pharo 8.0] Build #248: 3272-Slot-Demo-HistorySlot

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #248 was: SUCCESS. The Pull Request #3273 was integrated: "3272-Slot-Demo-HistorySlot" Pull request url: https://github.com/pharo-project/pharo/pull/3273 Issue Url: https://github.com/pharo-project/pharo/issues/3272 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 30, 2019

Re: [Pharo-dev] how implement isAbstract?

by Ben Coman

On Mon, 29 Apr 2019 at 22:38, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > A class is abstract by design and not necessarily because I can compute > something from its implementation that tells me that maybe it is abstract. > I somehow mark a class as abstract because it is abstract, not the other > way around. > Randon idea... ``#Frame abstract`` returning a hypothetical instance of AbstractClassSymbol which double-dispatches to set a property of the class when it is created per... Object subclass: #Frame abstract instanceVariableNames: 'frameNumber frameRolls nextFrame' classVariableNames: '' package: 'Exercism-Bowling' cheers -ben

April 30, 2019

Re: [Pharo-dev] color protocols and marking creation methods (msg 1 of Pharo-dev Digest, Vol 72, Issue 23)

by Jim Sawyer

> 1. Re: How to convey that a message create a new instance > (Esteban Maringolo) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 28 Apr 2019 13:11:06 -0300 > From: Esteban Maringolo <emaringolo(a)gmail.com> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] How to convey that a message create a new > instance > Message-ID: > <CAJMgPCK1YB98CFn3KxhcDxLmoY7mYoXDboT5ZC2o7ZbL6pTYjA(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Esteban A. Maringolo > > > On Sun, Apr 28, 2019 at 6:02 AM ducasse <stepharo(a)netcourrier.com> wrote: >>> On 28 Apr 2019, at 10:57, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> On 28 Apr 2019, at 01:05, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: >>>> >>>> I tend to use the following idioms: >>>> - 'beSomething' idiom for cases modifying the receiver. >>>> - 'newWithSomething' or 'copyWithXx' for cases when I want to make it clear that you would get a new instance As a class, I think of Color as a factory, answering an immutable (though not literal) propertyValue. I might tell an object with a color property to change to a different propertyValue. I would expect it to do so by changing the property (replacing the current value with anotherPropertyValue), and would not expect the propertyValue itself to mutate (thus affecting all references to said value). Red cannot be darker.Â Red is Red.Â This sortOfRed can be darker than thatSortOfRed, so if you have theColorRed you can ask it for something darker, but you cannot ask it to become darker. Therefore, Color should not have any 'be' methods or 'as' methods. It might well have some fancy 'instance side' modifiers for describing a desired result, but they should always be answering an immutable instance of the class Color. self setColor: (Color red " (#FF0000) " butDarker) self color: (self color butDarker) self lightBulbColor: (Color red opacity: 0.2) As for #be vs. #as vs #newSomething, I would agree. I've beenÂ using the following conventions... Â Â Â #beX Â Â Â #beNotX (iff mode X is binary) Â Â Â #be: X Â Â Â to mean change your own state to that of mode X Â Â Â #isX Â Â Â #is: X Â Â to answer whether state is currently mode X and Â Â Â #notXÂ Â Â (iff mode X is binary) Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â rather than #isNotX Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â so that the 'mode' category lists modes as Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â isX Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â isY Â Â Â Â Â Â Â Â Â Â Â Â Â Â isZ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â notX Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â notY Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â notZ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â which is easier to read when there are lots of modes. and Â Â Â #asClassX Â Â Â #as: ClassXÂ Â Â to mean answer yourself as an instance of ClassX Â Â Â #asNewClassX Â Â Â #asNew: ClassXÂ Â Â to mean answer yourself as a new instance of ClassX and Â Â Â #newSomething Â Â Â #newWith: intialValue to mean create and answer a new instance and Â Â Â #variableOrPropertyNameÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â public accessingÂ Â Â Â Â Â Â Â Â (possibly lazily initialed) Â Â Â #setVariableName: nilOrValue Â Â Â Â Â Â Â Â Â Â Â Â private mutating Â Â Â Â Â Â Â Â (can be reset to nil, but not otherwise changed) Â Â Â #releaseVariableOrPropertyNameÂ Â Â Â Â Â Â Â Â private initial/release Â Â Â (if a resource) and set to nil, answer nil. Â Â Â #resetVariableOrPropertyNameÂ Â Â Â Â Â Â Â Â Â Â Â private initial/release Â Â Â reset to nil, answer self variableOrProprtyName Â Â Â #resetVariableOrPropertyName: valueÂ Â Â private initial/releaseÂ Â Â Â release (if a resource) and set to value Â Â Â #somePropertyName: valueÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â public mutatingÂ Â Â Â Â Â Â Â Â Â Â (answer self -- private mutators answer parameter) but these are all conventions for mutable objects. -Jim Jim Sawyer: jas(a)cruzio.com === --- This email has been checked for viruses by AVG. https://www.avg.com

April 29, 2019