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)

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)

On 09.12.2014, at 15:02, Craig Latta craig@netjam.org 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

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)

On Tue, Dec 9, 2014 at 12:36 PM, Chris Muller asqueaker@gmail.com wrote:

On Tue, Dec 9, 2014 at 8:02 AM, Craig Latta craig@netjam.org 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.