March 2019 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Esteban's ChangeLog week of 25 February 2019

by ducasse

This is super cool and with native back-ends it will be super sexy :) Iâm eager to see the presentation of Spec2 at PharoDays. Which reminds me that we should create a new branch in the book. Stef > On 4 Mar 2019, at 08:00, estebanlm(a)gmail.com wrote: > > Hello! > > This is my weekly ChangeLog, from 25 February 2019 to 3 March 2019. > You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=25/2/2019&to=3/3/2019 > > ChangeLog > ========= > > 1 March 2019: > ------------- > > * I have been working on introducing the concept of +Application+ to Spec2. > An application is the entry point of... well, any application you will do with Spec2. It will contain > information needed to make the application works in different contexts: > 1) a theme > 2) shared resources > 3) the backend to use (Morphic) > 4) access to standard dialogs, etc. (what now is found in UIManager). > > It is hard because it implies a lot of other refactors: > > * open/close of windows needs to pass through an application (to keep navigation working) > * An application needs to be present on each window opened. > * Windows needs to be the root of a presenter (and not just a holded variable in a ComposablePresenter) > * Initialization of windows now is made by calling a method: #initializeWindow:, this was already added, but now we need to generalise it. > * ... > > Anyway, this is a lot of work and is taking more than desirable :( > > > 26 February 2019: > ----------------- > > * Spec 2 day: > > 1) fix a bug in GridLayout: calculous of column width when columns is not homogeneous was bad because > some morphs (labels, strings) needs to fit to contents (and it was not doing it). > > 2) Starting to introduce the concept of "Application": A window is not a good enough abstraction, we need > to use also the concept of application (several windows interacting, sharing resources, theme, etc.). > > > 25 February 2019: > ----------------- > > * Today I made some advances in Spec2: > > 1) I worked on the transmissions mini-framework. The ability to make easy transmissions > between components in Glamour was always something I liked it. So I did not want to lose > it in the transition from Glamour to Spec2. > > I implemented a small layer on Spec presenters to be able to define input ports and output > ports. That way you can define transmissions "glamour style", with full power of Spec behind. > > Someting like this is now possible: > > ---- > packages := self newList displayBlock: #name. > classes := self newList displayBlock: #name. > self transmit from: packages; to: classes; transform: #definedClasses. > ---- > > 2) Also, I added some functionality to allow to add arbitrary presenters to the new layouts. > > This is useful when doing forms, for example: you do not want to instantiate all the time a > LabelPresenter to add a label. That way, you can now define things like this: > > ---- > SpecGridLayout new > columnHomogeneous: false; > add: 'Name' at: 1@1; > add: #nameTextInput at: 2@1; > add: 'Host' at: 1@2; > add: #hostTextInput at: 2@2; > add: 'Port' at: 1@3; > add: #portNumberInput at: 2@3; > yourself > ---- > > This will probably deserve a re-work later, but is already a lot better :) > > 3) I implementer a new type of presenter: +ActionBarPresenter+. This is similar to a toolbar, > but its purpose is to add some actions (something like the small button pad you see in macOS and > others). Since they do not serve same purpose, usability is not always the same and then they need > to be separated. > > > cheers! > Esteban >

March 4, 2019

Esteban's ChangeLog week of 25 February 2019

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 25 February 2019 to 3 March 2019. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=25/2/2019&to=3/3/2019 ChangeLog ========= 1 March 2019: ------------- * I have been working on introducing the concept of +Application+ to Spec2. An application is the entry point of... well, any application you will do with Spec2. It will contain information needed to make the application works in different contexts: 1) a theme 2) shared resources 3) the backend to use (Morphic) 4) access to standard dialogs, etc. (what now is found in UIManager). It is hard because it implies a lot of other refactors: * open/close of windows needs to pass through an application (to keep navigation working) * An application needs to be present on each window opened. * Windows needs to be the root of a presenter (and not just a holded variable in a ComposablePresenter) * Initialization of windows now is made by calling a method: #initializeWindow:, this was already added, but now we need to generalise it. * ... Anyway, this is a lot of work and is taking more than desirable :( 26 February 2019: ----------------- * Spec 2 day: 1) fix a bug in GridLayout: calculous of column width when columns is not homogeneous was bad because some morphs (labels, strings) needs to fit to contents (and it was not doing it). 2) Starting to introduce the concept of "Application": A window is not a good enough abstraction, we need to use also the concept of application (several windows interacting, sharing resources, theme, etc.). 25 February 2019: ----------------- * Today I made some advances in Spec2: 1) I worked on the transmissions mini-framework. The ability to make easy transmissions between components in Glamour was always something I liked it. So I did not want to lose it in the transition from Glamour to Spec2. I implemented a small layer on Spec presenters to be able to define input ports and output ports. That way you can define transmissions "glamour style", with full power of Spec behind. Someting like this is now possible: ---- packages := self newList displayBlock: #name. classes := self newList displayBlock: #name. self transmit from: packages; to: classes; transform: #definedClasses. ---- 2) Also, I added some functionality to allow to add arbitrary presenters to the new layouts. This is useful when doing forms, for example: you do not want to instantiate all the time a LabelPresenter to add a label. That way, you can now define things like this: ---- SpecGridLayout new columnHomogeneous: false; add: 'Name' at: 1@1; add: #nameTextInput at: 2@1; add: 'Host' at: 1@2; add: #hostTextInput at: 2@2; add: 'Port' at: 1@3; add: #portNumberInput at: 2@3; yourself ---- This will probably deserve a re-work later, but is already a lot better :) 3) I implementer a new type of presenter: +ActionBarPresenter+. This is similar to a toolbar, but its purpose is to add some actions (something like the small button pad you see in macOS and others). Since they do not serve same purpose, usability is not always the same and then they need to be separated. cheers! Esteban

March 4, 2019

Re: [Pharo-dev] managing modification of class initialization methods

by Nicolas Cellier

Hi Ben, It's probably time to revisit http://smallissimo.blogspot.com/2011/08/lazy-initialization-of-shared-varia… Le lun. 4 mars 2019 Ã 03:47, Ben Coman <btc(a)openinworld.com> a Ã©crit : > In relation to developing sample solutions for an Exercism exercise, the > following observation was made about class initialization... > > > class is initialized on load - and not when you modify it - so this can > be very confusing for users > > My first thought was to wonder if Quality Assistant could track whether a > class initialize method had been run after it was modified, > and display alerts. > > Alternatively, I wonder if a reasonable pattern would be to > couple class-side lazy initialization > with a pragma to reset a variable when the method is saved... > > MyClass class >> referenceData > <onSaveResetVariable: ReferenceData> > ^ ReferenceData := ReferenceData ifNil: [ 'reference data' ] > > cheers -ben >

March 4, 2019

managing modification of class initialization methods

by Ben Coman

In relation to developing sample solutions for an Exercism exercise, the following observation was made about class initialization... > class is initialized on load - and not when you modify it - so this can be very confusing for users My first thought was to wonder if Quality Assistant could track whether a class initialize method had been run after it was modified, and display alerts. Alternatively, I wonder if a reasonable pattern would be to couple class-side lazy initialization with a pragma to reset a variable when the method is saved... MyClass class >> referenceData <onSaveResetVariable: ReferenceData> ^ ReferenceData := ReferenceData ifNil: [ 'reference data' ] cheers -ben

March 4, 2019

Weird FFI method redefinition in Pharo 6

by Eliot Miranda

Hi All, I'm trying to debug remaining limitations in Image Segment support in Spur using a case provided by Max Leske. This is a pair of Pharo 6 images, one of which saves an image segment the other which loads it. Both use OSEnvironment>>getEnv: to access environment variables. The base definition of OSEnvironment>>getEnv: is !OSEnvironment methodsFor: 'accessing' stamp: 'auto 5/3/2016 10:31'! getEnv: arg1 "This method calls the Standard C Library getenv() function. The name of the argument (arg1) should fit decompiled version." ^ self ffiCall: #( String getenv (String arg1) ) module: LibC! ! but as I'm using the VM Simulator to debug the image segment issues I need to avoid the FFI, which isn't yet simulateable. So I redefine OSEnvironment>>getEnv: as follows, and then save and exit. !OSEnvironment methodsFor: 'accessing' stamp: 'EliotMiranda 02/27/2019 17:09'! getEnv: aByteStringOrByteArray "This method calls the Standard C Library getenv() function. The name of the argument (arg1) should fit decompiled version." <primitive: 'primitiveGetenv' module: '' error: ec> ec == #'bad argument' ifTrue: [aByteStringOrByteArray isString ifFalse: [^self getEnv: aByteStringOrByteArray asString]]. self primitiveFail! ! But, and here's the weird bit, when I start up the image, the new definition has been discarded and replaced by the original. WTF?!?! Why is this happening? How can I disable this? The only way that I've found I am able to save with a new version is by doing a Save As... to a new name. This is fine, but I find the current behavior extremely unhelpful. Is it a bug? If it is intended, whats the rationale? _,,,^..^,,,_ best, Eliot

March 3, 2019

Re: [Pharo-dev] GT FileReference inspector menu items

by Tudor Girba

Hi, > On Mar 3, 2019, at 3:45 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Doru, > > I've been adding menu items to the AbstractFileReference Items tab by modifying > > AbstractFileReference>>gtInspectorItemsIn: > > This obviously isn't a good way to add menu items as different > packages will over-write each other and was wondering if an extensible > framework had been included in the new GT toolkit (e.g. using pragmas > to define the menu items)? (or am I missing something in Pharo 8)? You did not miss it. There is no option for this. > If not - consider this a feature request :-) We played with this in multiple ways and came to the conclusion that it is too complicated and requires too much magic for the gain. There are two alternatives: 1. extract specific views in a separate class and make that one be extensible 2. offer a generic mechanism to disable unwanted views. This allows one to provide an alternative view and disable the default one. > P.S. The new String inspector as demoed in > > https://twitter.com/feenkcom/status/1102159122571710465 > > looks great! Being able to see the character easily is something I've > wanted many times. I am happy you like it :) Cheers, Doru > > Thanks! > Alistair > -- www.feenk.com "There are no old things, there are only old ways of looking at them."

March 3, 2019

Call for Mentors: Google Summer of Code 2019 with Pharo Consortium

by Jigyasa Grover

Hello Pharo-ers ! On behalf of the community, I would like to thank each one of you for their significant contribution which has led to our organisation being selected in Google Summer of Code (GSoC) yet again: https://summerofcode.withgoogle.com/organizations/6741777344626688/ Before the students start proposing projects and submitting proposals, I would like to invite all the experienced members to be a part of this amazing experience and mentor students to work on Pharo projects over the summer. Here is a GSoC mentor guide which one should definitely read to know more about roles and responsibilities: https://google.github.io/gsocguides/mentor/ Please volunteer to mentor any of the existing projects (Listed here: http://gsoc.pharo.org/) as soon as possible or propose fresh ideas for projects which shall help improve Pharo ! To add your own project idea to the list, visit http://gsoc.pharo.org/#adding-a-proposal. Looking forward to an appreciable representation from the Pharo community. Best regards Jigyasa Grover Pharo Consortium Org Admin, Google Summer of Code 2019 -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 3, 2019

[Pharo 8.0] Build #113: 2728-Rescue-RubCleaning-to-remove-PluggableTextMorph-and-friends

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

There is a new Pharo build available! The status of the build #113 was: FAILURE. The Pull Request #2730 was integrated: "2728-Rescue-RubCleaning-to-remove-PluggableTextMorph-and-friends" Pull request url: https://github.com/pharo-project/pharo/pull/2730 Issue Url: https://pharo.fogbugz.com/f/cases/2728 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 3, 2019

[Pharo 8.0] Build #112: 2734-Integrate-spec-200

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

There is a new Pharo build available! The status of the build #112 was: SUCCESS. The Pull Request #2735 was integrated: "2734-Integrate-spec-200" Pull request url: https://github.com/pharo-project/pharo/pull/2735 Issue Url: https://pharo.fogbugz.com/f/cases/2734 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 3, 2019

GT FileReference inspector menu items

by Alistair Grant

Hi Doru, I've been adding menu items to the AbstractFileReference Items tab by modifying AbstractFileReference>>gtInspectorItemsIn: This obviously isn't a good way to add menu items as different packages will over-write each other and was wondering if an extensible framework had been included in the new GT toolkit (e.g. using pragmas to define the menu items)? (or am I missing something in Pharo 8)? If not - consider this a feature request :-) P.S. The new String inspector as demoed in https://twitter.com/feenkcom/status/1102159122571710465 looks great! Being able to see the character easily is something I've wanted many times. Thanks! Alistair

March 3, 2019