- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Weird FFI method redefinition in Pharo 6

by Esteban Lorenzano

Hi, Mmmâ¦ FFIMethodRegistry is reseting the method value to its old value because you modified the method but you did not executed it (you simulated it, I guess), and FFICalloutAPI updates the registry on method execution. Then on image shutdown the methods are reseted to their original value. This is usually not an issue, but running with the simulator can cause that problem. Esteban > On 3 Mar 2019, at 23:03, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > 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 4, 2019

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

by Norbert Hartl

> Am 04.03.2019 um 03:46 schrieb Ben Coman <btc(a)openinworld.com>: > > 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' ] > Isnât the usual way to do that to register the class in the shutdown list and implement #shutdown: ? Norbert

March 4, 2019

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