The Trunk: MonticelloConfigurations-fbs.118.mcz

Frank Shearar uploaded a new version of MonticelloConfigurations to project The Trunk:
http://source.squeak.org/trunk/MonticelloConfigurations-fbs.118.mcz

==================== Summary ====================

Name: MonticelloConfigurations-fbs.118
Author: fbs
Time: 21 November 2013, 9:20:19.085 pm
UUID: aaba44a1-8cfd-4147-8d94-69d5fc5ac571
Ancestors: MonticelloConfigurations-cmm.117

Move the #upgradeIsMerge preference to MCConfiguration.

=============== Diff against MonticelloConfigurations-cmm.117 ===============

Item was changed:
  Object subclass: #MCConfiguration
  instanceVariableNames: 'name dependencies repositories log'
+ classVariableNames: 'DefaultLog ExtraProgressInfo LogToFile UpgradeIsMerge'
- classVariableNames: 'DefaultLog ExtraProgressInfo LogToFile'
  poolDictionaries: ''
  category: 'MonticelloConfigurations'!
 
  !MCConfiguration commentStamp: 'dtl 5/10/2010 23:03' prior: 0!
  An MCConfiguration specifies the configuration of a set of related Monticello packages. It maintains an ordered list of package versions and a list of repositories in which the packages may be found.
 
  An MCConfiguration may be filed out for storage as an array specification, and new instances can be created from a stored array specification.
  !

Item was removed:
- ----- Method: MCConfiguration class>>initialize (in category 'class initialization') -----
- initialize
- "MCConfiguration initialize"
-
- Preferences addPreference: #upgradeIsMerge
- categories: #('updates') default: false
- balloonHelp: 'When upgrading packages, use merge instead of load'.!

Item was added:
+ ----- Method: MCConfiguration class>>upgradeIsMerge (in category 'preferences') -----
+ upgradeIsMerge
+ "Answer true if you wish to merge upstream changes whenever you upgrade."
+ <preference: 'Upgrade is merge'
+ category: 'Monticello'
+ description: 'When upgrading packages, use merge instead of load'
+ type: #Boolean>
+ ^UpgradeIsMerge ifNil: [true]!

Item was added:
+ ----- Method: MCConfiguration class>>upgradeIsMerge: (in category 'preferences') -----
+ upgradeIsMerge: aBoolean
+ UpgradeIsMerge := aBoolean.!

Item was changed:
  ----- Method: MCConfiguration>>upgrade (in category 'actions') -----
  upgrade
  ^self depsSatisfying: [:dep | dep isFulfilledByAncestors not]
  versionDo: [:ver |
+ (self class upgradeIsMerge and: [ver shouldMerge])
- (Preferences upgradeIsMerge and: [ver shouldMerge])
  ifFalse: [ver load]
  ifTrue: [[ver merge]
  on: MCMergeResolutionRequest do: [:request |
  request merger conflicts isEmpty
  ifTrue: [request resume: true]
  ifFalse: [request pass]]]]
  displayingProgress: 'upgrading packages'
  !

Item was changed:
  ----- Method: MCMcmUpdater class>>updateFromRepositories: (in category 'updating') -----
  updateFromRepositories: repositoryUrls
  "MCMcmUpdater updateFromRepositories: #(
  'http://squeaksource.com/MCUpdateTest'
  )"
 
  | repos config |
+ MCConfiguration upgradeIsMerge: true.
- Preferences enable: #upgradeIsMerge.
  LastUpdateMap ifNil:[LastUpdateMap := Dictionary new].
  "The list of repositories to consult in order"
  repos := repositoryUrls collect:[:url|
  MCRepositoryGroup default repositories
  detect:[:r| r description = url]
  ifNone:[ | r |
  r := MCHttpRepository location: url user: '' password: ''.
  MCRepositoryGroup default addRepository: r.
  r]].
 
  "The list of updates-author.version.mcm sorted by version"
  repos do:[:r| r cacheAllFileNamesDuring:[
  | updateList |
  updateList := self updateListFor: r.
  "Proceed only if there are updates available at all."
  updateList ifNotEmpty: [
  (LastUpdateMap at: r description ifAbsent: [0]) = 0 ifTrue: [
  "No update has ever been loaded from this repo. If no package is
  present in the image either, we can skip right to the latest config"
  config := r versionNamed: updateList last value.
  (config dependencies anySatisfy: [:dep| dep package hasWorkingCopy])
  ifFalse: [ (self useLatestPackagesFrom: r)
  ifTrue: [LastUpdateMap at: r description put: updateList last key.
  updateList := #()]
  ifFalse: [updateList := updateList last: 1]]].
  "Now process each update file. Check if we have all dependencies and if not,
  load the entire configuration (this is mostly to skip older updates quickly)"
  updateList do:[:assoc|
  ProgressNotification signal: '' extra: 'Processing ', assoc value.
  config := r versionNamed: assoc value.
  "Skip packages that were specifically unloaded"
  config dependencies: (config dependencies
  reject: [:dep| self skipPackages includes: dep package name]).
  self updateMissingPackages ifFalse:[
  "Skip packages that are not in the image"
  config dependencies: (config dependencies
  select: [:dep| dep package hasWorkingCopy])].
  (config dependencies allSatisfy:[:dep| dep isFulfilled])
  ifFalse:[config upgrade].
  LastUpdateMap at: r description put: assoc key.
  ] displayingProgress: 'Processing configurations'.
  "We've loaded all the provided update configurations.
  Use the latest configuration to update all the remaining packages."
  (self useLatestPackagesFrom: r) ifTrue: [
  config updateFromRepositories.
  config upgrade].
  ]].
  ].
  ^config!

Item was added:
+ (PackageInfo named: 'MonticelloConfigurations') postscript: '"below, add code to be run after the loading of this package"
+ MonticelloConfigurations updateIsMerge: Preferences updateIsMerge.'!

On 21 November 2013 21:20,  <[hidden email]> wrote:
Just by the way, MonticelloConfigurations depends on System for one
thing only now: Utilities' author stuff. I'm knocking up a completely
lame minimal mimic-existing-stuff SystemAuthor that I will hopefully
finish tomorrow. I plan to sever this dependency, and then remove all
the references to Utilities authorName/Initials with SystemAuthor
current, and then we can think about any other stuff we might do with
this.

frank

What's wrong with a dependency on System?

Is your overall goal to completely remove System from the system?


On Thu, Nov 21, 2013 at 4:33 PM, Frank Shearar <[hidden email]> wrote:

Back when Levente approached this, we had a detailed discussion about
it.  I think we should all go back and read that before introducing a
SystemAuthor class.

Personally, I wouldn't mind just having

   Smalltalk authorInitials  "answers a String"

until we decide we need to support multiple concurrent Author objects
with more than just name and initials..

And this makes sense anyway -- Smalltalk's current #author.

I struggle with having a whole class (SystemAuthor) when we cannot
take proper advantage of it and only really need one String field at
this time, not a heavy-weight, value-holder singleton.

On Thu, Nov 21, 2013 at 4:33 PM, Frank Shearar <[hidden email]> wrote:

Here's the opening of that discussion:

  http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-September/165845.html

On Thu, Nov 21, 2013 at 5:05 PM, Chris Muller <[hidden email]> wrote:

On 21 Nov 2013, at 22:58, Chris Muller <[hidden email]> wrote:

> What's wrong with a dependency on System?

Because a dependency on system is a dependency on everything that system depends on... which is most of the image.

> Is your overall goal to completely remove System from the system?

Not really. I want to give it a serious hair trim and break it up into pieces that make sense. Right now it's a bucket of things, without a coherent story. When you reply to this saying "it's the smalltalk environment" my reply is "no, the image is". System is the God Class antipattern applied to packages.

frank

It's been over a year, and several rounds of discussion. The last round fizzled out with 'yeah ok we should do it but don't call it Author'. Really, I don't particularly care _what_ we do as long as we remove another part of Utilities. So I'm going to write a minimal thing that pulls the state out of Utilities, where it never belonged. Once the real problem - that state - has been addressed, finessing the API will be much easier.

frank

On 21 Nov 2013, at 23:05, Chris Muller <[hidden email]> wrote:

On 22 November 2013 08:29, Frank Shearar <[hidden email]> wrote:
> It's been over a year, and several rounds of discussion. The last round fizzled out with 'yeah ok we should do it but don't call it Author'. Really, I don't particularly care _what_ we do as long as we remove another part of Utilities. So I'm going to write a minimal thing that pulls the state out of Utilities, where it never belonged. Once the real problem - that state - has been addressed, finessing the API will be much easier.

I sound like a rude, grumpy old man. I don't mean to sound _rude_ :)
So I'll go re-re-read the last round of discussion, and make sure I'm
not deliberately snubbing anyone's ideas, and deliver some code.
Hopefully it won't be a complete disaster, but in order to fix this
problem, _someone_ has to write something. So I'll take the hit, and
put my code up for tomato-throwing.

frank

On Fri, 22 Nov 2013, Frank Shearar wrote:

> It's been over a year, and several rounds of discussion. The last round fizzled out with 'yeah ok we should do it but don't call it Author'. Really, I don't particularly care _what_ we do as long as we remove another part of Utilities. So I'm going to write a minimal thing that pulls the state out of Utilities, where it never belonged. Once the real problem - that state - has been addressed, finessing the API will be much easier.

Will your implementation be any different than what mine was?


Levente

On Thu, 21 Nov 2013, Chris Muller wrote:

So more than a year has passed, but it seems to me that there's no demand
for anything more than extracting the functionality from Utilities.
Also, there are two fields: initials and name. And if those are held in a
single object, then swapping them is simpler, which would be useful while
running the tests.


Levente

On 22 November 2013 10:44, Levente Uzonyi <[hidden email]> wrote:
Seeing as I didn't finish anything on the train this morning, I'd far
rather just use your implementation. Did you adjust the API to fit
Colin's comments about #username?

It looks like you've already done the work. I'm happy to be the one to
ram it through trunk.

frank

On 21 November 2013 23:05, Chris Muller <[hidden email]> wrote:
We cannot take proper advantage of it because it doesn't exist yet :)

I'd rather waste an entire class and kill Utilities, than have
Utilities continually stick a spanner in the more important objective
of modularity.

First Utilities, then the world!

frank

On 22 November 2013 10:53, Frank Shearar <[hidden email]> wrote:
The only thing I don't like is the class-side replication of the
instance-side protocol. I'd rather just have a #current (which is
there already).

frank

Hi Frank,

On 11/22/2013 11:09 AM, Frank Shearar wrote:
> I'd rather waste an entire class and kill Utilities, than have
> Utilities continually stick a spanner in the more important objective
> of modularity.
>
> First Utilities, then the world!
>
> frank

I think overrides (a la VW, but they could be done even better) could solve these entanglement problems much easier
(after the initial investment), directly attacking modularity and helping address other issues in this area:
loading/unloading, minimal image, versioning.

Florin

On 22 November 2013 16:37, Chris Muller <[hidden email]> wrote:
I would not cry if we removed authorName, or made it simply an alias
for authorInitials. I do want it a separate class though, because it's
a separate entity. It's not just a string, after all: it's a string
with setup logic, and asking the user for stuff. I've made classes for
less than that, many times.

frank

On 22 November 2013 16:10, Frank Shearar <[hidden email]> wrote:
The thing is, this singleton-ness makes the tests really messy, in
that they monkey around with global state. Why can't we allow the #new
and work with test instances, throw away the setters, and have a
functional style SystemAuthor that we entirely replace when we need
to?

frank

Hi Florin,

On Fri, Nov 22, 2013 at 8:35 AM, Florin Mateoc <[hidden email]> wrote:

I think overrides (a la VW, but they could be done even better)

+1.  I was the guilty party that f**ed up the implementation of the VW ones (but then it was my idea also).  See http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-January/142760.html for a better approach to implementation.  Does it make sense to you?

 

could solve these entanglement problems much easier
(after the initial investment), directly attacking modularity and helping address other issues in this area:
loading/unloading, minimal image, versioning.

Florin

--
best,

Eliot

I actually liked overrides a lot - I should have emphasized that (especially that there are seemingly so many things that I don't like :) - must be the age).
It was, from my point of view, the one saving grace for Store (as compared to Envy, which was otherwise fantastic (and it had atomic loading).

I am sorry, I did not really understand your alternative approach from that message. What I had in mind was, on one hand, to remove any restrictions for what an override can do (I don't remember exactly, but I think there were some unnecessary restrictions), on the other hand, specify in the override itself what it expects the overidee to be. These override expectations should be in the form of source code (method formatted source, class structure...), not versions or some such.
The fact that the override specifies its expectations not only makes it likely that it will work when they are met, but also implies that they were tested in that configuration by their developer. The expectations for each override should be a collection, not a single source, since this would allow to load multiple packages that override the same things. One of the expectations would be the base variation, another would be after a known other package overrode it...

Cheers,
Florin