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

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

by Esteban Lorenzano

> On 4 Mar 2019, at 16:02, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Esteban, > > On Mon, Mar 4, 2019 at 4:31 AM Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > 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. > > It happens with or without the simulator. If I redefine the method and save, expecting that on startup the new version will be executed, and startup with the normal VM, the method is reset. Surely this is a bug and the method should be removed from the FFI registry when it is redefined with no FFI usage in it. Right? Then indeed, that may be a bugâ¦ still, I need to check the best way to fix it (we need to introduce a check when compiling to reset the ffi methodâ¦ I guess with a compiler plugin). Esteban > > > Esteban > >> On 3 Mar 2019, at 23:03, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@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 >> > > > > -- > _,,,^..^,,,_ > best, Eliot

March 4, 2019

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

by Sven Van Caekenberghe

(1) the basic concepts are clear (and have been for a long time): - when a class initialize method is loaded, it is executed afterwards, if and only if the source code changed - there are startUp[:] and shutDown[:] and SessionManager to handle images coming up, saving and going down With these tools you can build any behaviour you want. I am not sure we need something else, except maybe more education (2) the problem is much larger than just the class initialize method, since that can call other methods (like #initializeConstants, etc, ..) - even if the class initialize method did not change, a method further down might have and could require re-initialization. For this reason I sometimes put a timestamp in a comment of the class initialize method to force re-initialization since I known that I added a new constant somewhere (much) further down. Complex new features might do more harm than good > On 4 Mar 2019, at 17:13, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Mon, 4 Mar 2019 at 20:08, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > 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: ? > > To me a good minute to work out why I didn't understand you. > Sorry, I meant <onMethodSaveResetVariable: ReferenceData> > > So when 'reference data' is updated and the modified method is saved, > the variable gets lazy initialized *again* with the new definition. > > hope that is more clear, > cheers -ben

March 4, 2019

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

by Alistair Grant

Hi Doru, Thanks for your reply. On Sun, 3 Mar 2019 at 21:27, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > 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. OK. I'll (eventually) have a play with these ideas. Thanks again, Alistair > > 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 4, 2019

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

by Ben Coman

On Mon, 4 Mar 2019 at 20:08, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > 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: ? > To me a good minute to work out why I didn't understand you. Sorry, I meant <onMethodSaveResetVariable: ReferenceData> So when 'reference data' is updated and the modified method is saved, the variable gets lazy initialized *again* with the new definition. hope that is more clear, cheers -ben

March 4, 2019

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

by Eliot Miranda

Hi Esteban, On Mon, Mar 4, 2019 at 4:31 AM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > 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. > It happens with or without the simulator. If I redefine the method and save, expecting that on startup the new version will be executed, and startup with the normal VM, the method is reset. Surely this is a bug and the method should be removed from the FFI registry when it is redefined with no FFI usage in it. Right? > > 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 > > > -- _,,,^..^,,,_ best, Eliot

March 4, 2019

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