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

[Pharo 8.0] Build #114: 2736-Update-Epicea-to-Spec-changes

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

There is a new Pharo build available! The status of the build #114 was: SUCCESS. The Pull Request #2747 was integrated: "2736-Update-Epicea-to-Spec-changes" Pull request url: https://github.com/pharo-project/pharo/pull/2747 Issue Url: https://pharo.fogbugz.com/f/cases/2736 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 5, 2019

[Pharo 7.0] Build #152: 2699 - backport pharo-vcs/tonel bug fix

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

There is a new Pharo build available! The status of the build #152 was: SUCCESS. The Pull Request #2700 was integrated: "2699 - backport pharo-vcs/tonel bug fix" Pull request url: https://github.com/pharo-project/pharo/pull/2700 Issue Url: https://pharo.fogbugz.com/f/cases/Pharo7.0 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 5, 2019

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

by Ben Coman

On Tue, 5 Mar 2019 at 22:08, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Now, your solution, the pragma, is just as complex, because it would still > require people to (1) understand the issue and (2) remember to add the > pragma correctly. > I agree those points apply in relation to creating code, but for an existing method with such a pragma I believe it would be reasonably easy for newcomers to read and understand the impact of modifying the data, but I've really nothing to back up that belief. cheers -ben

March 5, 2019

[Pharo 7.0] Build #151: 2699 - backport pharo-vcs/tonel bug fix

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

There is a new Pharo build available! The status of the build #151 was: SUCCESS. The Pull Request #2700 was integrated: "2699 - backport pharo-vcs/tonel bug fix" Pull request url: https://github.com/pharo-project/pharo/pull/2700 Issue Url: https://pharo.fogbugz.com/f/cases/Pharo7.0 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 5, 2019

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

by Sven Van Caekenberghe

Tim, Your example is exactly the most common 'gotcha' case where something unexpected happens. In that case, when one of the underlying #massTable constants/specs changes, I would add a comment timestamp in the class #initialize method, something along the lines "last change: 20190305". You are right that this is a complex and not so obvious issue, both for newcomers as for others. The key cause of this is that we have a live image that lives longer that a classic program, people are not used to this. Class variables hold state, sometimes even complex databases. The decision to not always rerun all class #initialize methods is because sometimes these might hold expensive calculations, another reason might be that not all class #initialize methods can run in all circumstances (they might want to load external data, etc, ...). Now, your solution, the pragma, is just as complex, because it would still require people to (1) understand the issue and (2) remember to add the pragma correctly. If the dependency goes over different classes, with potentially unknown users, it might even be impossible to solve. Sven > On 5 Mar 2019, at 01:50, Tim Mackinnon <tim(a)testit.works> wrote: > > If we go back to where this comes from - I donât think its so obvious what the behaviour is. Newcomers to Smalltalk donât get it, and I suspect even seasoned Smalltalkers have to think twice or more about this. > > If we roll back to where I think this question came from: > > If I have a simple constant like #maxLimit - I can stick it as an instance method as: > > maxLimit > ^42 > > > But if my constant is more complicated like: > > massTable > | multiplier | > multipier := 4.25678. > > ^{ âaâ -> 27 * multiplier. > âbâ -> 42 * multiplier. > â¦ > âzâ -> 106 * multiplier } asDictionary > > It's not ideal to have this as an instance method - so you are advised to move it up to the class level, and try to emulate a âconstâ. > > But this still isnât good enough as its evaluated every time - so you add a class variable MassTable and initialize it once, in class>>initialize > > Initialise > > MassTable := self massTable. > > > Ok - so far so good - except you made a mistake and want to correct the value for âzâ, which you change from 106 to 110 and press save. > > But surprise, surprise, it doesnât change - because when is class #initialise actually called? Trick question it turns out - as if I make the change in GitHub, commit the code and then reload the package with iceberg - it still wonât change as reloading code doesnât cause class initialise (which is surprising to most). > > I think that this this quite common occurrence shouldnât be so mysterious - why canât I just change the code, save it and have the value change in some obvious manor without some voodoo. This is one of those strange cases of smalltalk where it doesnât obviously do what I expect and I need to know too much of the system to do the right thing. > > I think we could come up with a way to make this easier - but It would be good to get the wisdom of the crowd in on this. > > This is one of the early exercise in Exercism, and weâd like to know the best, element, in keeping with the philosophy solution. > > At the moment, a class variable with a lazy getter is the suggested solution e.g. > > massTable > âMyClass MassTable := nil. self massTable >>>â > > ^MassTable ifNil: [ MassTable := self createMassTable ] > > Where you have to remember to click on the example icon, or evaluate a doIt is the best solution. > > To me - this is WTF? Surely we can do better in an environment where we control the compiler, ide and interaction model? > > Tim > > > >> On 4 Mar 2019, at 16:26, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> (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 5, 2019

[Pharo 7.0] Build #150: 2699 - backport pharo-vcs/tonel bug fix

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

There is a new Pharo build available! The status of the build #150 was: FAILURE. The Pull Request #2700 was integrated: "2699 - backport pharo-vcs/tonel bug fix" Pull request url: https://github.com/pharo-project/pharo/pull/2700 Issue Url: https://pharo.fogbugz.com/f/cases/Pharo7.0 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 5, 2019

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

by Tim Mackinnon

If we go back to where this comes from - I donât think its so obvious what the behaviour is. Newcomers to Smalltalk donât get it, and I suspect even seasoned Smalltalkers have to think twice or more about this. If we roll back to where I think this question came from: If I have a simple constant like #maxLimit - I can stick it as an instance method as: maxLimit ^42 But if my constant is more complicated like: massTable | multiplier | multipier := 4.25678. ^{ âaâ -> 27 * multiplier. âbâ -> 42 * multiplier. â¦ âzâ -> 106 * multiplier } asDictionary It's not ideal to have this as an instance method - so you are advised to move it up to the class level, and try to emulate a âconstâ. But this still isnât good enough as its evaluated every time - so you add a class variable MassTable and initialize it once, in class>>initialize Initialise MassTable := self massTable. Ok - so far so good - except you made a mistake and want to correct the value for âzâ, which you change from 106 to 110 and press save. But surprise, surprise, it doesnât change - because when is class #initialise actually called? Trick question it turns out - as if I make the change in GitHub, commit the code and then reload the package with iceberg - it still wonât change as reloading code doesnât cause class initialise (which is surprising to most). I think that this this quite common occurrence shouldnât be so mysterious - why canât I just change the code, save it and have the value change in some obvious manor without some voodoo. This is one of those strange cases of smalltalk where it doesnât obviously do what I expect and I need to know too much of the system to do the right thing. I think we could come up with a way to make this easier - but It would be good to get the wisdom of the crowd in on this. This is one of the early exercise in Exercism, and weâd like to know the best, element, in keeping with the philosophy solution. At the moment, a class variable with a lazy getter is the suggested solution e.g. massTable âMyClass MassTable := nil. self massTable >>>â ^MassTable ifNil: [ MassTable := self createMassTable ] Where you have to remember to click on the example icon, or evaluate a doIt is the best solution. To me - this is WTF? Surely we can do better in an environment where we control the compiler, ide and interaction model? Tim > On 4 Mar 2019, at 16:26, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > (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 5, 2019

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

by Nicolas Cellier

Le lun. 4 mars 2019 Ã 21:35, Eliot Miranda <eliot.miranda(a)gmail.com> a Ã©crit : > > > On Mon, Mar 4, 2019 at 8:26 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> (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 >> > > +1000. KISS. > Except that things are not simple if you have nested dependencies: You have no way to control initialization order! If (A initialize) will instantiate a B new that require (B initialize) then you are screwed. You then have to create several packages and load them in the right order to work around the initialization. This is one reason for resorting to lazy initalization: disantangle such initialization dependencies. But hardcoding every lazy initialization does not sound right. A class>>accessMyClassVar ^MyClassVar ifNil: [self initializeMyClassVar] Having a way to link the method #initializeMyClassVar to MyClassVar with a declarative form by way of #<initialize> annotation is more universal/nice. A class>>initializeMyClassVars #<initialize> MyClassVar := 1. MyOtherClassVar := B new: 10. Having an UnitializedStatic instance automatically becomeForward: whatever initialized object is simple and legitimate magic. I agree that maintaining the registry that links initializer to this variable is the complex part The easy part is when adding a new initializer method (this is the case of installing a package in image). The harder part is when changing or removing a previous initializer (exactly like what happened to you recently with FFI). > >> >> > 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 >> >> >> > > -- > _,,,^..^,,,_ > best, Eliot >

March 4, 2019

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

by Eliot Miranda

On Mon, Mar 4, 2019 at 8:26 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > (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 > +1000. KISS. > > > 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 > > > -- _,,,^..^,,,_ best, Eliot

March 4, 2019

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

by Eliot Miranda

Hi Esteban, On Mon, Mar 4, 2019 at 9:09 AM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > 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> > 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). > That seems right to me. Only methods containing FFI calls should be in the register. If one redefines such na method to remove its FFI call then it should be removed from the registry. The alternative would be for the reset code to check that it is resetting a method containing an FFI call, and if there is none, not resetting. This might be simpler in the end. > > Esteban > > > >> >> 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 > > > -- _,,,^..^,,,_ best, Eliot

March 4, 2019