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:
>
>>
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.
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 unde
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
--- 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
n 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
>
> Da
s 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 singl
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 obj
--- 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 a
--- 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
--- 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 th
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-user
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 m
--- 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 uniqueIns
14 matches
Mail list logo
