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) |
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) > > |
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 +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?
Hi Craig,
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.
best,
Eliot |
On 08.12.2014, at 23:58, Eliot Miranda <[hidden email]> wrote:
Yep. See MCPackageLoader>>basicLoad. - Bert - smime.p7s (5K) Download Attachment |
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) |
> 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) |
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 |
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:
best,
Eliot |
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.. |
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: 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 |
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) |
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) |
Free forum by Nabble | Edit this page |