New 3.9alpha image is ready! (sort of)
bert at impara.de
Thu Jul 7 10:16:02 UTC 2005
Am 07.07.2005 um 08:35 schrieb Andreas Raab:
> Hi Doug -
>>> In Tweak we have basically a fixed load order (==configuration)
>>> which originates from the configuration used in the original
>>> build. But the main reason for wanting to have a well-defined
>>> load order is that typically, if there are sets of cross-package
>>> changes, they follow already established dependencies.
>> Yes, makes sense. That should reduce the need for special update
>> changesets to load packages in a special order.
> Yes. That's another implicit advantage - most of the time stuff
> just "works" by loading the latest package versions.
Indeed - given that you have a "managed" repository, which has a
linear numbering scheme and everyone agrees to merge in the latest
version (so that when you upload v.n+1 it has v.n as ancestor). Maybe
one could use squeaksource's blessing feature to enforce that.
So if you have cross-package changes, you just post all of them, and
the load order is defined by the stored configuration (see below).
>> Any suggestions on how I should implement this? I guess we could
>> have a method defined somewhere (in the load-updates code) which
>> has a
>> hardcoded, ordered list of the 35 package names. I guess this list
>> won't change very often. (The 3.9a-6676 image doesn't seem to be
>> hanging onto the MCConfiguration instance that was loaded in update
>> #6676, otherwise I might try to use that.)
That "hardcoded, ordered list of the 35 package names" would just be
like the literal configuration that you issue as changeset (without
the #upgrade call), but put into a method. It is precisely that
literal representation why the configuration is as simple as it is
now (compared to a full-blown MCVersion). It just defines a load
order for a few packages, that's all :)
> What we've done so far is to have a global which stores the latest
> version of a configuration and then just works issuing a
> "updateFromRepositories". It's very simple stuff - if you are
> curious check out CProjectBuilder>>loadUpdates and
Yep, this works nicely in Tweak. Pasting the methods below for easier
reference. I stripped out the progress display and logging.
TweakUpdateStreamManager loadUpdates. "from update stream"
| map |
map := self defaultConfiguration.
DefaultConfiguration == nil] whileTrue. "repeat if we have a new
^DefaultConfiguration ifNil: [
DefaultConfiguration := MCConfiguration fromArray: #(
There is a hook to set DefaultConfiguration to nil whenever the
#defaultConfiguration method is recompiled (but this relies on Tweak
semantics). Alternatively, you might have a class-side #initialize
method that contains the new configuration, so it would automatically
get overwritten after an update, and you test for map identity in
#updateFromRepositories rather than testing for nil.
The call to #updateFromRepositories in #loadUpdates might possibly be
guarded by a "bleeding edge" preference. That way, normal users only
would get the "stable" configuratons explicitly posted to the stream,
while the system developers would get all the latest packages from
- Bert -
More information about the Packages