Hi All, Hi Bert, On Mon, Dec 8, 2014 at 12:02 PM, Chris Muller <asqueaker@gmail.com> 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 <craig@netjam.org> 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 +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

-- best, Eliot