Re: [Pharo-users] Updating singletons
Hi Steffen, > However, there is another fun possibility to figure out that a change > happened that does not involve configuration - though, a bit hacky. ;-) > You could write the accessor method such that it recompiles itself with > the first access after loading new code. For example: > >> Singleton>>uniqueInstance >> instance := self class new. >> self class compile: 'uniqueInstance ^instance'. >> ^instance If I understand this correctly, it replaces the uniqueInstance method by another one that returns the singleton instance. And when the code is reloaded, it's the above method that is reinstated, to be used just once. Neat! Thanks, Konrad.
Re: [Pharo-users] Updating singletons
Dale, > Did you try what I suggested and did it solve your problem? I tried, but I see no difference. The postload method is still not executed. Konrad.
Re: [Pharo-users] Updating singletons
Konrad, Did you try what I suggested and did it solve your problem? Dale On 1/5/19 2:45 AM, Konrad Hinsen wrote: Dale, This looks like a case where you are using a metadata-less repository ... if so you, should add the following method to your baseline class: Sorry, that's way above my understanding of baselines and repository handling in general. I started from https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/Baselines.md and adapted the examples there to my own situation, my project being hosted on GitHub: https://github.com/khinsen/leibniz-pharo/ This mod will cause packages to be unconditionally loaded ... Monticello does a definition comparison on package load so only changed definitions are loaded into the image ... I'd say that a new dependency should be treated like a changed one, but again I am still very much lost in the jungle of Monticello, Metacello, Gofer, Iceberg, etc. It's the most opaque aspect of Pharo I have encountered so far. Cheers, Konrad.
Re: [Pharo-users] Updating singletons
Hi Konrad, sorry, I might have misread your question such that it was about updating references to an obsolete object. However, there is another fun possibility to figure out that a change happened that does not involve configuration - though, a bit hacky. ;-) You could write the accessor method such that it recompiles itself with the first access after loading new code. For example: Singleton>>uniqueInstance instance := self class new. self class compile: 'uniqueInstance ^instance'. ^instance Best, Steffen Am .01.2019, 18:04 Uhr, schrieb Konrad Hinsen : Hi Steffen, Have you considered to yield (an) proxy object(s) instead of the actual > Singleton in uniqueInstance? This way it suffices to update the proxy > with each update of the code. I am not sure I understand what you are proposing. My problem is figuring out how to change in-memory objects when they become obsolete after a code change. So I'd say it doesn't matter much if the object I need to change is the singleton or a proxy to it, but maybe I am missing something! Cheers, Konrad.
Re: [Pharo-users] Updating singletons
--- Begin Message --- Dale, > This looks like a case where you are using a metadata-less repository > ... if so you, should add the following method to your baseline class: Sorry, that's way above my understanding of baselines and repository handling in general. I started from https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/Baselines.md and adapted the examples there to my own situation, my project being hosted on GitHub: https://github.com/khinsen/leibniz-pharo/ > This mod will cause packages to be unconditionally loaded ... Monticello > does a definition comparison on package load so only changed definitions > are loaded into the image ... I'd say that a new dependency should be treated like a changed one, but again I am still very much lost in the jungle of Monticello, Metacello, Gofer, Iceberg, etc. It's the most opaque aspect of Pharo I have encountered so far. Cheers, Konrad. --- End Message ---
Re: [Pharo-users] Updating singletons
--- Begin Message --- Talking about metadataless, I just bumped into: https://pharo.manuscript.com/f/cases/22865/ using *MetacelloCypressBaselineProjec*t. I'm pushing a PR as an attempt to fix it but for sure if Dale can give it a review it will be great! https://github.com/pharo-project/pharo/pull/2173 Then we need to fix it upstream in Metacello. Regards, Gabriel On Fri, Jan 4, 2019 at 3:04 PM Dale Henrichs < dale.henri...@gemtalksystems.com> wrote: > Konrad, > This looks like a case where you are using a metadata-less repository ... > if so you, should add the following method to your baseline class: > > projectClass > Smalltalk at: #'MetacelloCypressBaselineProject' ifPresent: [ :cl | ^ cl ]. > ^ super projectClass > > This mod will cause packages to be unconditionally loaded ... Monticello > does a definition comparison on package load so only changed definitions > are loaded into the image ... > > Hope this helps, > > Dale > > On 1/4/19 5:12 AM, Konrad Hinsen via Pharo-users wrote: > > Subject: > Re: [Pharo-users] Updating singletons > > From: > Konrad Hinsen > > Date: > 1/4/19, 5:12 AM > > To: > pharo-users@lists.pharo.org > > H Cyril, > > > Fetching, loading and post loads should leave a trace during the > execution in the Transcript. > > Thanks, that helps to confirm that my postload is never executed when I > update a package + baseline in an image that already had an earlier > version loaded. Nothing at all is shown in the Transcript. Reloading the > package and/or the baseline package doesn't leave any trace either. And > if I add a dependency, then update the package again, the new dependency > is not loaded either. > > Hypothesis: baseline changes have no effect for already installed packages. > > When I load my modified package + baseline into a fresh image, lots of > actions are shown in the Transcript, including the execution of my > postload action. But in that situation, I don't actually need it. > > Cheers, > Konrad. > > > --- End Message ---
Re: [Pharo-users] Updating singletons
Konrad, This looks like a case where you are using a metadata-less repository ... if so you, should add the following method to your baseline class: projectClass Smalltalk at: #'MetacelloCypressBaselineProject' ifPresent: [ :cl | ^ cl ]. ^ super projectClass This mod will cause packages to be unconditionally loaded ... Monticello does a definition comparison on package load so only changed definitions are loaded into the image ... Hope this helps, Dale On 1/4/19 5:12 AM, Konrad Hinsen via Pharo-users wrote: Subject: Re: [Pharo-users] Updating singletons From: Konrad Hinsen Date: 1/4/19, 5:12 AM To: pharo-users@lists.pharo.org H Cyril, Fetching, loading and post loads should leave a trace during the execution in the Transcript. Thanks, that helps to confirm that my postload is never executed when I update a package + baseline in an image that already had an earlier version loaded. Nothing at all is shown in the Transcript. Reloading the package and/or the baseline package doesn't leave any trace either. And if I add a dependency, then update the package again, the new dependency is not loaded either. Hypothesis: baseline changes have no effect for already installed packages. When I load my modified package + baseline into a fresh image, lots of actions are shown in the Transcript, including the execution of my postload action. But in that situation, I don't actually need it. Cheers, Konrad.
Re: [Pharo-users] Updating singletons
Hi Steffen, Have you considered to yield (an) proxy object(s) instead of the actual > Singleton in uniqueInstance? This way it suffices to update the proxy > with each update of the code. I am not sure I understand what you are proposing. My problem is figuring out how to change in-memory objects when they become obsolete after a code change. So I'd say it doesn't matter much if the object I need to change is the singleton or a proxy to it, but maybe I am missing something! Cheers, Konrad.
Re: [Pharo-users] Updating singletons
--- Begin Message --- H Cyril, > Fetching, loading and post loads should leave a trace during the > execution in the Transcript. Thanks, that helps to confirm that my postload is never executed when I update a package + baseline in an image that already had an earlier version loaded. Nothing at all is shown in the Transcript. Reloading the package and/or the baseline package doesn't leave any trace either. And if I add a dependency, then update the package again, the new dependency is not loaded either. Hypothesis: baseline changes have no effect for already installed packages. When I load my modified package + baseline into a fresh image, lots of actions are shown in the Transcript, including the execution of my postload action. But in that situation, I don't actually need it. Cheers, Konrad. --- End Message ---
Re: [Pharo-users] Updating singletons
--- Begin Message --- Hello, Fetching, loading and post loads should leave a trace during the execution in the Transcript. For pre/post load it should have something like: Evaluated -> baseline [BaselineOfMyProject] >> selector This is the primary source of informations I use to debug baselines. -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature --- End Message ---
Re: [Pharo-users] Updating singletons
--- Begin Message --- Ben, > You might use a Baseline #postLoadDoIt: > https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/Baselines.md Thanks, that looks like exactly what I need... except that it doesn't seem to work. My postload method is not run when a new version of the code is loaded into an image. Nor when I load my project into a fresh image. Which makes me wonder more generally how one can debug baselines. The mechanism that uses them is very opaque: you write some code as a kind of plugin to some framework, but it is not clear at all how this code is used. > Consider that a person pulling your changes cannot know if you have > upgraded the library versions of any dependencies, > so always updating via a Baseline might be a reasonable expectation. Indeed, baselines make a lot of sense in principle. Cheers, Konrad --- End Message ---
Re: [Pharo-users] Updating singletons
Have you considered to yield (an) proxy object(s) instead of the actual Singleton in uniqueInstance? This way it suffices to update the proxy with each update of the code. Am 3. Januar 2019 15:36:27 MEZ schrieb Ben Coman : >On Thu, 3 Jan 2019 at 20:01, Konrad Hinsen via Pharo-users < >pharo-users@lists.pharo.org> wrote: > >> Dear Pharo experts, >> >> I am wondering if there is a good way to deal with singleton objects >> whose value needs to be updated following changes in the code that >> initializes it. >> >> Following the model of many examples in Pharo itself, I have defined >a >> singleton class with a uniqueInstance method for accessing (and >creating >> if necessary) the single instance, and a method "reset" marked as a >> script to set the uniqueInstance back to nil when required, i.e. >after >> source code changes make the prior value inappropriate. >> >> This works very well, as long as I don't forget to do the reset, >which >> has already caused me a few hours of debugging time. Worse, suppose >> someone else is using my project in progress, pulling changes from my >> GitHub repo once per week. That person cannot know if the latest >changes >> require a singleton reset. More importantly, users shouldn't have to >> know about such internal details at all. >> >> So is there a way to do the reset automatically whenever a new >version >> of my package is loaded into an image? >> >> Thanks in advance, >> Konrad. >> > >You might use a Baseline #postLoadDoIt: >https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/Baselines.md > > >Consider that a person pulling your changes cannot know if you have >upgraded the library versions of any dependencies, >so always updating via a Baseline might be a reasonable expectation. > >But that doesn't help you while developing within the one image. > >cheers -ben
Re: [Pharo-users] Updating singletons
On Thu, 3 Jan 2019 at 20:01, Konrad Hinsen via Pharo-users < pharo-users@lists.pharo.org> wrote: > Dear Pharo experts, > > I am wondering if there is a good way to deal with singleton objects > whose value needs to be updated following changes in the code that > initializes it. > > Following the model of many examples in Pharo itself, I have defined a > singleton class with a uniqueInstance method for accessing (and creating > if necessary) the single instance, and a method "reset" marked as a > script to set the uniqueInstance back to nil when required, i.e. after > source code changes make the prior value inappropriate. > > This works very well, as long as I don't forget to do the reset, which > has already caused me a few hours of debugging time. Worse, suppose > someone else is using my project in progress, pulling changes from my > GitHub repo once per week. That person cannot know if the latest changes > require a singleton reset. More importantly, users shouldn't have to > know about such internal details at all. > > So is there a way to do the reset automatically whenever a new version > of my package is loaded into an image? > > Thanks in advance, > Konrad. > You might use a Baseline #postLoadDoIt: https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/Baselines.md Consider that a person pulling your changes cannot know if you have upgraded the library versions of any dependencies, so always updating via a Baseline might be a reasonable expectation. But that doesn't help you while developing within the one image. cheers -ben
[Pharo-users] Updating singletons
--- Begin Message --- Dear Pharo experts, I am wondering if there is a good way to deal with singleton objects whose value needs to be updated following changes in the code that initializes it. Following the model of many examples in Pharo itself, I have defined a singleton class with a uniqueInstance method for accessing (and creating if necessary) the single instance, and a method "reset" marked as a script to set the uniqueInstance back to nil when required, i.e. after source code changes make the prior value inappropriate. This works very well, as long as I don't forget to do the reset, which has already caused me a few hours of debugging time. Worse, suppose someone else is using my project in progress, pulling changes from my GitHub repo once per week. That person cannot know if the latest changes require a singleton reset. More importantly, users shouldn't have to know about such internal details at all. So is there a way to do the reset automatically whenever a new version of my package is loaded into an image? Thanks in advance, Konrad. --- End Message ---
