Smalltalk › Pharo › Pharo Smalltalk Users

Updating singletons

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

14 messages Options

Pharo Smalltalk Users mailing list

Updating singletons

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.

Ben Coman

Re: Updating singletons

On Thu, 3 Jan 2019 at 20:01, Konrad Hinsen via Pharo-users <[hidden email]> 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

Steffen Märcker

Re: 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 <[hidden email]>:

On Thu, 3 Jan 2019 at 20:01, Konrad Hinsen via Pharo-users <[hidden email]> 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 Smalltalk Users mailing list

Re: Updating singletons

In reply to this post by Ben Coman

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

Pharo Smalltalk Users mailing list

Re: Updating singletons

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 (836 bytes) Download Attachment

Pharo Smalltalk Users mailing list

Re: Updating singletons

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.

khinsen

Re: Updating singletons

In reply to this post by Steffen Märcker

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.

Dale Henrichs-3

Re: Updating singletons

In reply to this post by Pharo Smalltalk Users mailing list

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 [hidden email]

Date:

1/4/19, 5:12 AM

To:

[hidden email]

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.

Pharo Smalltalk Users mailing list

Re: Updating singletons

Talking about metadataless, I just bumped into: https://pharo.manuscript.com/f/cases/22865/ using

MetacelloCypressBaselineProject.

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 <[hidden email]> 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 [hidden email]

Date:
1/4/19, 5:12 AM

To:
[hidden email]
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.

Pharo Smalltalk Users mailing list

Re: Updating singletons

In reply to this post by Dale Henrichs-3

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.

Steffen Märcker

Re: Updating singletons

In reply to this post by khinsen

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 <[hidden email]>:

> 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.

Dale Henrichs-3

Re: Updating singletons

In reply to this post by Dale Henrichs-3

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.

khinsen

Re: 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.

khinsen

Re: Updating singletons

In reply to this post by Steffen Märcker

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.