Does Monticello try to install shared pools before methods using them?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Does Monticello try to install shared pools before methods using them?

ccrraaiigg

Hoi--

     I'm attempting to create a Monticello package which provides a
shared pool (as a subclass of SharedPool) and methods which use its
variables. On installation, does Monticello try to ensure that a pool is
installed before methods which use it? When I install the package in a
fresh system, I get messages on the Transcript complaining that shared
variables are undefined.

     Is there some way one fiddles with the writing process, or with the
package after it is written, to avoid ordering problems?


     thanks!

-C

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)


Reply | Threaded
Open this post in threaded view
|

Re: Does Monticello try to install shared pools before methods using them?

Chris Muller-3
I'm pretty sure the responsibility falls to the loader.  I'm not too
familiar with it but if I wanted to be I would probably start tracing
from McVersionLoader.

Do your pool references end up being valid?  That is the most
important but I agree it would be an annoyance to see those messages
in the Transcript.

On Mon, Dec 8, 2014 at 7:24 AM, Craig Latta <[hidden email]> wrote:

>
> Hoi--
>
>      I'm attempting to create a Monticello package which provides a
> shared pool (as a subclass of SharedPool) and methods which use its
> variables. On installation, does Monticello try to ensure that a pool is
> installed before methods which use it? When I install the package in a
> fresh system, I get messages on the Transcript complaining that shared
> variables are undefined.
>
>      Is there some way one fiddles with the writing process, or with the
> package after it is written, to avoid ordering problems?
>
>
>      thanks!
>
> -C
>
> --
> Craig Latta
> netjam.org
> +31 6 2757 7177 (SMS ok)
> + 1 415 287 3547 (no SMS)
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Does Monticello try to install shared pools before methods using them?

Eliot Miranda-2
Hi All, Hi Bert,

On Mon, Dec 8, 2014 at 12:02 PM, Chris Muller <[hidden email]> wrote:
I'm pretty sure the responsibility falls to the loader.  I'm not too
familiar with it but if I wanted to be I would probably start tracing
from McVersionLoader.

+1.  Craig, I thought that Monticello had been modified to load additions first, then changes, then removals.  But when I read the code I can't see this sorting in trunk.  Bert, what's your recollection?  And if you agree that Monticello does this, where's the code?  I see that MCPatch>>applyTo: doesn't do anything special and when it appears to collect its definitions in MCPatch>>initializeWithBase:target: there is no sorting going on.  What am I missing?

Do your pool references end up being valid?  That is the most
important but I agree it would be an annoyance to see those messages
in the Transcript.

Hi Craig,
 

On Mon, Dec 8, 2014 at 7:24 AM, Craig Latta <[hidden email]> wrote:
>
> Hoi--
>
>      I'm attempting to create a Monticello package which provides a
> shared pool (as a subclass of SharedPool) and methods which use its
> variables. On installation, does Monticello try to ensure that a pool is
> installed before methods which use it? When I install the package in a
> fresh system, I get messages on the Transcript complaining that shared
> variables are undefined.

As I said above I thought Monticello implemented that sensible load order of add, change, remove, in which case poll definitions should be included in additions, and before any methods.  But I can't see where in current trunk this is happening.  AFAIC, not loading in this order is a bug.  We need as predictable aand useful a general load order as possible, and it should be straight-forward to arrange that pools are added early.

>
>      Is there some way one fiddles with the writing process, or with the
> package after it is written, to avoid ordering problems?
>
>
>      thanks!
>
> -C
>
> --
> Craig Latta
> netjam.org
> <a href="tel:%2B31%206%202757%207177" value="+31627577177">+31 6 2757 7177 (SMS ok)
> <a href="tel:%2B%201%20415%20287%203547" value="+14152873547">+ 1 415 287 3547 (no SMS)
>
>




--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Does Monticello try to install shared pools before methods using them?

Bert Freudenberg
On 08.12.2014, at 23:58, Eliot Miranda <[hidden email]> wrote:

Hi All, Hi Bert,

On Mon, Dec 8, 2014 at 12:02 PM, Chris Muller <[hidden email]> wrote:
I'm pretty sure the responsibility falls to the loader.  I'm not too
familiar with it but if I wanted to be I would probably start tracing
from McVersionLoader.

+1.  Craig, I thought that Monticello had been modified to load additions first, then changes, then removals. 

Yep. See MCPackageLoader>>basicLoad.

- Bert -






smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

re: Does Monticello try to install shared pools before methods using them?

ccrraaiigg
In reply to this post by Chris Muller-3

Hi Chris--

> Do your pool references end up being valid?

     I don't know yet; the entire system hangs. :)  I figured I'd see
what was going on with the undeclared stuff first.


     thanks,

-C

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)


Reply | Threaded
Open this post in threaded view
|

re: Does Monticello try to install shared pools before methods using them?

ccrraaiigg

> Do your pool references end up being valid?

     Aha, the answer is no. So, I had to put some things in a separate
package which must be loaded first. Among those things is a change
required by a remote-object-aware version of
IdentityDictionary>>scanFor:; the system was crashing when they were
loaded in the wrong order.


     thanks again,

-C

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)


Reply | Threaded
Open this post in threaded view
|

re: Does Monticello try to install shared pools before methods using them?

Tobias Pape

On 09.12.2014, at 15:02, Craig Latta <[hidden email]> wrote:

>> Do your pool references end up being valid?
>
>     Aha, the answer is no. So, I had to put some things in a separate
> package which must be loaded first. Among those things is a change
> required by a remote-object-aware version of
> IdentityDictionary>>scanFor:; the system was crashing when they were
> loaded in the wrong order.
>

I recall the pool-before-something pattern from
FFI, where we first have to load a pool package
and then the actual classes.

Best
        -Tobias

Reply | Threaded
Open this post in threaded view
|

re: Does Monticello try to install shared pools before methods using them?

Eliot Miranda-2
In reply to this post by ccrraaiigg
Hi Craig,

    but if you changed the code in MCPackageLoader>>basicLoad to load pool classes first what happens?  If we keep working around limitations, everyone has to work-around the limitations every time  Instead we can make it better.

On Tue, Dec 9, 2014 at 6:02 AM, Craig Latta <[hidden email]> wrote:

> Do your pool references end up being valid?

     Aha, the answer is no. So, I had to put some things in a separate
package which must be loaded first. Among those things is a change
required by a remote-object-aware version of
IdentityDictionary>>scanFor:; the system was crashing when they were
loaded in the wrong order.


     thanks again,

-C

--
Craig Latta
netjam.org
<a href="tel:%2B31%20%20%206%202757%207177" value="+31627577177">+31 6 2757 7177 (SMS ok)
<a href="tel:%2B%201%20415%20%20287%203547" value="+14152873547">+ 1 415 287 3547 (no SMS)





--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

re: Does Monticello try to install shared pools before methods using them?

Chris Muller-3
In reply to this post by ccrraaiigg
On Tue, Dec 9, 2014 at 8:02 AM, Craig Latta <[hidden email]> wrote:
>
>> Do your pool references end up being valid?
>
>      Aha, the answer is no. So, I had to put some things in a separate
> package which must be loaded first. Among those things is a change
> required by a remote-object-aware version of
> IdentityDictionary>>scanFor:; the system was crashing when they were
> loaded in the wrong order.

Interesting.  What did you have to do to #scanFor:, some kind of proxy
detection or something?

PS -- I agree with Eliot that MC _should_ handle compiling subclasses
of SharedPool first.  I thought it did..

Reply | Threaded
Open this post in threaded view
|

re: Does Monticello try to install shared pools before methods using them?

Eliot Miranda-2


On Tue, Dec 9, 2014 at 12:36 PM, Chris Muller <[hidden email]> wrote:
On Tue, Dec 9, 2014 at 8:02 AM, Craig Latta <[hidden email]> wrote:
>
>> Do your pool references end up being valid?
>
>      Aha, the answer is no. So, I had to put some things in a separate
> package which must be loaded first. Among those things is a change
> required by a remote-object-aware version of
> IdentityDictionary>>scanFor:; the system was crashing when they were
> loaded in the wrong order.

Interesting.  What did you have to do to #scanFor:, some kind of proxy
detection or something?

PS -- I agree with Eliot that MC _should_ handle compiling subclasses
of SharedPool first.  I thought it did..

No, right now only methodAdditions are handled first.  Look at MCPackageLoader>>basicLoad which is aching to be refactored to pull the exception handlers out.  It should look like

basicLoad
"Load the contents of some package. This is the core loading method
in Monticello. Be wary about modifying it unless you understand the details
and dependencies of the various entities being modified."
RecentMessages default suspendWhile:
[[CurrentReadOnlySourceFiles cacheDuring:
[[self innerBasicLoad]
on: InMidstOfFileinNotification
do: [:n | n resume: true]]]
ensure: [self flushChangesFile]]

innerBasicLoad
"Load the contents of some package. This is the core loading method
in Monticello. Be wary about modifying it unless you understand the details
and dependencies of the various entities being modified."
| pkgName |
errorDefinitions := OrderedCollection new.
"Obviously this isn't the package name but we don't have anything else
to use here. ChangeSet current name will generally work since a CS is 
usually installed prior to installation."
pkgName := ChangeSet current name.
preamble ifNotNil:
[ChangeSet current preambleString: (self preambleAsCommentNamed: pkgName)].

"Pass 1: Load everything but the methods,  which are collected in methodAdditions."
additions
do: [:ea | 
ea isMethodDefinition 
ifTrue: [methodAdditions add: ea asMethodAddition]
ifFalse:
[[ea load]
on: Error
do: [errorDefinitions add: ea]]]
displayingProgress: 'Reshaping ', pkgName.

"Try again any delayed definitions"
self shouldWarnAboutErrors ifTrue:
[self warnAboutErrors].
errorDefinitions do: [:ea | ea load] 
displayingProgress: 'Reloading ', pkgName.

"Pass 2: We compile new / changed methods"
methodAdditions
do: [:ea| ea createCompiledMethod] 
displayingProgress: 'Compiling ', pkgName.

'Installing ', pkgName
displayProgressFrom: 0
to: 2
during:
[:bar|
"There is no progress *during* installation since a progress bar update
will redraw the world and potentially call methods that we're just trying to install."
bar value: 1.

"Pass 3: Install the new / changed methods
(this is a separate pass to allow compiler changes to be loaded)"
methodAdditions do:
[:ea| ea installMethod].

"Pass 4: Remove the obsolete methods"
removals do:
[:ea| ea unload]].

"Finally, notify observers for the method additions"
methodAdditions
do: [:each | each notifyObservers] 
"the message is fake but actually telling people how much time we spend
in the notifications is embarrassing so lie instead"
displayingProgress: 'Installing ', pkgName.

additions
do: [:ea | ea postloadOver: (self obsoletionFor: ea)] 
displayingProgress: 'Initializing ', pkgName

But I have to say that I don't understand how basicLoad/innerBasicLoad sorts things.  Confusing.  Anyway, looks like the "Pass 1: Load everything but the methods,  which are collected in methodAdditions." pass needs to be split into something that loads things that inherit from SharedPool first.

--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

re: Does Monticello try to install shared pools before methods using them?

ccrraaiigg
In reply to this post by Eliot Miranda-2

Hoi Eliot--

> ...but if you changed the code in MCPackageLoader>>basicLoad to load
> pool classes first what happens?  If we keep working around
> limitations...

     Cool, I'll give it a go. :)


-C

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)


Reply | Threaded
Open this post in threaded view
|

re: Does Monticello try to install shared pools before methods using them?

ccrraaiigg
In reply to this post by Chris Muller-3

> What did you have to do to #scanFor:, some kind of proxy detection or
> something?

     Yup, a different hashing scheme for proxies.


-C

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)