BaselineOf atomic load type

Hi,

I want to use atomic loadtype in a BaselineOf

I used to set `prject loadType: #atomic` in the #project method of my ConfigurationOf, but it seems this does not work with BaselineOf.
The reason we changed to atomic loading was that when loading in GemStone, this prevents broken classhistories when moving classes between packages.

Is there a way to achieve atomic loading?

cheers
Johan

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

That should work, but I assume the devil is in the details.... which
side (class/instance) are you setting loadType: ... if you can share the
class maybe I can take a look ...

Dale


On 11/5/17 11:34 AM, Johan Brichau wrote:
--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Hi Dale,

Thanks for the swift reply. 

When debugging the load, I notice the atomic load policy is indeed used.

The issue I encounter is that a class initialize method of a class in one package fails because of an undeclared dependency on another package.

This did not fail when using the ConfigurationOf and I am wondering if class initialization is done on a per-package basis or should it also be postponed to after all packages have loaded when using atomic loadpolicy?

I actually don't remember this level of detail ... I would have imagined that the initialization is held of until the end, because the classes aren't even defined until all of the definitions have been defined ... presumably the problem is occurring because you expect the initializations to take place in a certain order and that order is not respected in atomic load ... package order is lost in this process ... controlling initialization order is on e of the reasons to use #linear load ... I suppose that there might be a way preserve package order for initializations ---

I don't have a lot of cycles right now, to take on this project, but I would be willing to work with someone from your team to help with adding this feature to Metacello ... from 10,000 feet it looks like the atomic load directives build a package order postLoad list so I would think that package load order would be maintained for initialization ... but I know that problem with Seaside (#linear was created for Seaside, mainly) that the initialization need to be performed _without_ other classes being present --- do you happen to be trying to do this with Seaside? If so that is completely different kettle of fish ---

Dale

thanks

Johan

On Sunday, November 5, 2017 at 10:20:26 PM UTC+1, Dale wrote:

That should work, but I assume the devil is in the details.... which
side (class/instance) are you setting loadType: ... if you can share the
class maybe I can take a look ...

Dale


On 11/5/17 11:34 AM, Johan Brichau wrote:
> Hi,
>
> I want to use atomic loadtype in a BaselineOf
>
> I used to set `prject loadType: #atomic` in the #project method of my ConfigurationOf, but it seems this does not work with BaselineOf.
> The reason we changed to atomic loading was that when loading in GemStone, this prevents broken classhistories when moving classes between packages.
>
> Is there a way to achieve atomic loading?
>
> cheers
> Johan
>

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Hey Dale,

> On 10 Nov 2017, at 14:29, Dale Henrichs <[hidden email]> wrote:
>>
>> The issue I encounter is that a class initialize method of a class in one package fails because of an undeclared dependency on another package.
>> This did not fail when using the ConfigurationOf and I am wondering if class initialization is done on a per-package basis or should it also be postponed to after all packages have loaded when using atomic loadpolicy?
> I actually don't remember this level of detail ... I would have imagined that the initialization is held of until the end, because the classes aren't even defined until all of the definitions have been defined ... presumably the problem is occurring because you expect the initializations to take place in a certain order and that order is not respected in atomic load ... package order is lost in this process ... controlling initialization order is on e of the reasons to use #linear load ... I suppose that there might be a way preserve package order for initializations ---

The class initialization fails because a method defined in another package was not loaded yet.
The initialization order does not matter in my case, I was just expecting the class initialization to occur after the loading of all packages.

I fixed it by moving the method because we had a circular package dependency anyway, so I’m not blocked by the issue right now.
Just strange this one did not pop up until I tried our loading spec in a BaselineOf.

If the atomic loading still preserves classhistories in Gemstone when classes are moved between packages, I’m fine with it.

> I don't have a lot of cycles right now, to take on this project, but I would be willing to work with someone from your team to help with adding this feature to Metacello ... from 10,000 feet it looks like the atomic load directives build a package order postLoad list so I would think that package load order would be maintained for initialization ... but I know that problem with Seaside (#linear was created for Seaside, mainly) that the initialization need to be performed _without_ other classes being present --- do you happen to be trying to do this with Seaside? If so that is completely different kettle of fish ---

No, it’s the Yesplan source I’m trying to move to git completely.

Thanks for the proposal and sending a response on your travel (you are traveling to Smalltalks?)
We’ll see what I can find and I will report back here.

cheers
Johan

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

On 11/10/17 5:41 AM, Johan Brichau wrote:
> Hey Dale,
>
>> On 10 Nov 2017, at 14:29, Dale Henrichs <[hidden email]> wrote:
>>> The issue I encounter is that a class initialize method of a class in one package fails because of an undeclared dependency on another package.
>>> This did not fail when using the ConfigurationOf and I am wondering if class initialization is done on a per-package basis or should it also be postponed to after all packages have loaded when using atomic loadpolicy?
>> I actually don't remember this level of detail ... I would have imagined that the initialization is held of until the end, because the classes aren't even defined until all of the definitions have been defined ... presumably the problem is occurring because you expect the initializations to take place in a certain order and that order is not respected in atomic load ... package order is lost in this process ... controlling initialization order is on e of the reasons to use #linear load ... I suppose that there might be a way preserve package order for initializations ---
> The class initialization fails because a method defined in another package was not loaded yet.
> The initialization order does not matter in my case, I was just expecting the class initialization to occur after the loading of all packages.
This seems to be more of a bug .... it seems to me that with atomic
loads the initialization should be deferred until all definitions are
loaded (a stack from the failure should provide the necessary information).

The other possibility is there is still a project with a #linear
loadType present ... Metacello will honor mixed #linear and #atomic load
types, but when a #linear project is encountered I think the
initializations up to that point get fired ... perhaps this is what is
happening to you? I'm actually not going to Smalltalks this year ... I am working on an
internal project that has a deadline of today (for my part:)

Dale

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

> The other possibility is there is still a project with a #linear loadType present ... Metacello will honor mixed #linear and #atomic load types, but when a #linear project is encountered I think the initializations up to that point get fired ... perhaps this is what is happening to you?

There’s even a very good chance that is happening.
I’ll check and report back.

> I'm actually not going to Smalltalks this year ... I am working on an internal project that has a deadline of today (for my part:)

oh, I understood you’re on a plane and was assuming ;)
Good luck with that deadline.

Johan

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.