- Pharo-dev - lists.pharo.org

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

by Ben Coman

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' ] > > On Mon, 4 Mar 2019 at 14:52, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Hi Ben, > It's probably time to revisit > > http://smallissimo.blogspot.com/2011/08/lazy-initialization-of-shared-varia… > Interesting stuff, but after ten minutes studying it I didn't fully grok it. So my first impression is its too much magic and I couldn't isolate what is required of a simple user. For comparison, could you show what a user would need to do to duplicate my example using that system, assuming the background magic was in place. cheers -ben

March 4, 2019

[ANN] Pharo Consortium New Academic Member: USTH University of Science and Technology of Hanoi

by Marcus Denker

The Pharo Consortium is very happy to announce that the USTH University of Science and Technology of Hanoi has joined the Consortium as an Academic Member. About - USTH University of Science and Technology of Hanoi: https://usth.edu.vn - 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

March 4, 2019

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

by Tim Mackinnon

He he Ben - I was just coming over here to ask something similar â¦ It also struck me that a method that initialises a class variable should rerun when saved, as the mystery of class side #initialize and when its actually sent can be a bit overwhelming. These days, we have all of the hooks to do this well donât we? I guess the issue comes down to how far you have to go if there are method dependencies etc. So yeah - maybe a pragma to make the intent clear might be a nice way to go. As it stands (and where Iâm sure this thread comes from) - I think the clarity of: MyVar ifNil: [MyVar := self bigInitialisation] makes it a bit more obvious that its a lazy initialisation and you have to re-run it (and I cheat with an example like: âMyClassVar := nil. MyClass myClassVarAccessor >>>â) But I wonder if the lazy initialisation approach is the favoured one anyway - and am curious what others think (but still agree with Ben that class initialised vars should work better in this day and age). Tim > On 4 Mar 2019, at 02:46, Ben Coman <btc(a)openinworld.com> wrote: > > 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

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