The Inbox: System-fbs.586.mcz

A new version of System was added to project The Inbox:
http://source.squeak.org/inbox/System-fbs.586.mcz

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

Name: System-fbs.586
Author: fbs
Time: 12 August 2013, 3:54:00.949 pm
UUID: 3061bc7e-52e4-da48-a797-71ebdbd89b42
Ancestors: System-fbs.585

Move check-for-updates into MonticelloConfigurations, thanks to pragma preferences and Smalltalk's startup/shutdown registration.

=============== Diff against System-fbs.585 ===============

Item was changed:
  ----- Method: AutoStart class>>checkForUpdates (in category 'updating') -----
  checkForUpdates
  | availableUpdate updateServer |
  World
  ifNotNil: [
  World install.
  ActiveHand position: 100@100].
- HTTPClient isRunningInBrowser
- ifFalse: [^self processUpdates].
  availableUpdate := (AbstractLauncher extractParameters
  at: 'UPDATE'
  ifAbsent: [''] ) asInteger.
  availableUpdate
  ifNil: [^false].
  updateServer := AbstractLauncher extractParameters
  at: 'UPDATESERVER'
  ifAbsent: [AbstractLauncher extractParameters
  at: 'UPDATE_SERVER'
  ifAbsent: ['Squeakland']].
  Utilities setUpdateServer: updateServer.
  ^SystemVersion checkAndApplyUpdates: availableUpdate!

Item was removed:
- ----- Method: AutoStart class>>processUpdates (in category 'updating') -----
- processUpdates
- "Process update files from a well-known update server.  This method is called at system startup time,   Only if the preference #updateFromServerAtStartup is true is the actual update processing undertaken automatically"
- | choice |
- (Preferences valueOfFlag: #updateFromServerAtStartup) ifTrue:
- [choice := UIManager default chooseFrom: #('Yes, Update' 'No, Not now' 'Don''t ask again')
- title: 'Shall I look for new code\updates on the server?' withCRs.
- choice = 1 ifTrue: [
- Utilities updateFromServer].
- choice = 3 ifTrue: [
- Preferences setPreference: #updateFromServerAtStartup toValue: false.
- self inform: 'Remember to save you image to make this setting permant.']].
- ^false!

Item was changed:
  ----- Method: Preferences class>>personalizeUserMenu: (in category 'personalization') -----
  personalizeUserMenu: aMenu
  "The user has clicked on the morphic desktop with the yellow mouse button (option+click on the Mac); a menu is being constructed to present to the user in response; its default target is the current world.  In this method, you are invited to add items to the menu as per personal preferences.
+ The default implementation, for illustrative purposes, sets the menu title to 'personal', and adds items for go-to-previous-project and show/hide flaps."
- The default implementation, for illustrative purposes, sets the menu title to 'personal', and adds items for go-to-previous-project, show/hide flaps, and load code updates"
 
  aMenu addTitle: 'personal' translated.  "Remove or modify this as per personal choice"
 
  aMenu addStayUpItem.
  aMenu add: 'previous project' translated action: #goBack.
- aMenu add: 'load latest code updates' translated target: Utilities action: #updateFromServer.
  aMenu add: 'about this system...' translated target: Smalltalk action: #aboutThisSystem.
 
  aMenu addLine.
 
  aMenu addUpdating: #suppressFlapsString target: Project current action: #toggleFlapsSuppressed.
  aMenu balloonTextForLastItem: 'Whether prevailing flaps should be shown in the project right now or not.' translated!

Item was removed:
- ----- Method: Utilities class>>openUpdateButton (in category 'user interface') -----
- openUpdateButton
- PluggableButtonMorph new
- label: 'Load Code Updates';
- model: Utilities;
- action: #updateFromServer;
- openInHand!

Item was removed:
- ----- Method: Utilities class>>setSystemVersionFromConfig: (in category 'fetching updates') -----
- setSystemVersionFromConfig: anMCConfiguration
- "Set the current system version date to the latest date found in anMCConfiguration (or the associated working copy). Also set the highest update number to the sum of version numbers in the config."
-
- | versionNumbers versionDates |
- versionNumbers := anMCConfiguration dependencies collect: [:d |
- (d versionInfo name copyAfterLast: $.) asInteger].
- versionDates := anMCConfiguration dependencies collect: [:d |
- d versionInfo date
- ifNil: [d package workingCopy ancestors first date]].
- SystemVersion current
- date: versionDates max;
- highestUpdate: versionNumbers sum.
- !

Item was changed:
  ----- Method: Utilities class>>updateFromServer (in category 'fetching updates') -----
  updateFromServer
+ self deprecated: 'Use MCMcmUpdater updateFromServer'.
+ ^ MCMcmUpdater updateFromServer.!
- "Update the image by loading all pending updates from the server."
- | config |
- "Flush all caches. If a previous download failed this is often helpful"
- MCFileBasedRepository flushAllCaches.
- config := MCMcmUpdater updateFromDefaultRepository.
- config ifNil: [^self inform: 'Unable to retrieve updates from remote repository.' translated].
- self setSystemVersionFromConfig: config.
- self inform: ('Update completed.
- Current update number: ' translated, SystemVersion current highestUpdate).!

Item was changed:
+ (PackageInfo named: 'System') postscript: '"Make #updateFromServerAtStartup a pragma preference as part of moving image updating out of Utilities."
+ MCMcmUpdater updateFromServerAtStartup: (Preferences valueOfFlag: #updateFromServerAtStartup).
+ Preferences removePreference: #updateFromServerAtStartup.'!
- (PackageInfo named: 'System') postscript: '"Migrate #Curvier to the new pragma preference."
- CurvierMorph drawCurvier: Preferences Curvier.
- Preferences removePreference: #Curvier.'!

On 2013-08-12, at 14:53, [hidden email] wrote:


This change would always execute the case meant for the web-browser plugin. (this whole mechanism is unused anyway, even in Etoys, but still)

Also, what's wrong with "Utilities updateFromServer"? Seems to me much nicer and easier to remember than "MCMcmUpdater updateFromServer". Call it a Facade, if you need to appease the gods of agile ;)

- Bert -

On 12 August 2013 16:42, Bert Freudenberg <[hidden email]> wrote:
Right. I was expecting to hear that this particular change was bad. My
preference would be to rip it out completely. Or, at most, preserve it
in 45Deprecated, or elsewhere. AncientUpdateStream or something.

> Also, what's wrong with "Utilities updateFromServer"? Seems to me much nicer and easier to remember than "MCMcmUpdater updateFromServer". Call it a Facade, if you need to appease the gods of agile ;)

* I want Utilities to die. It's a mess of mixed responsibilities. Even
were that all cleaned up, it'd be a mess of mixed responsibilities
delegated to better suited places. It's Bad(tm) for modularity:
Utilities >> #updateFromServer makes System depend on
MonticelloConfiguration, which is already dependent on System.
Breaking that cycle is the whole point of this commit.

* With MCMcmUpdater >> #updateFromServer we concentrate updating in one place.

frank

> - Bert -
>
>
>

On 2013-08-12, at 20:09, Frank Shearar <[hidden email]> wrote:

Safe to delete IMHO. Nothing else depends on it so no need to deprecate.


Maybe we need some high-level package then that can easily depend on all the stuff. MCMcmUpdater is just the mechanism, but the intent is something like "Squeak updateFromServer" (or even just "Squeak update"). Utilities used to be that place. I'm fine with something different, but having a gazillion single-purpose classes for such high-level operations seems to make things harder on users, not simpler.

Discussion welcome, of course :)

- Bert -

On Mon, Aug 12, 2013 at 08:25:33PM +0200, Bert Freudenberg wrote:
It walks like a utility and it quacks like a utility, so I think it's a Utility.

Dave

+1.  For both actually -- We want the system packages to be more
modularized, but not have to remember two things instead of just one,
every time we want to make use of a "system" service.

The facade would reside in some pretty high-level package, but which
one?  A reason to be interested in starting to think about our package
hierarchy..

As for the facades name, hm.  We do already have "Smalltalk"...?

On 12 August 2013 20:10, David T. Lewis <[hidden email]> wrote:
Well, that's a fair point. Another solution to the problem I'm trying
to address would be to move Utilities out of System.

>> Utilities used to be that place. I'm fine with something different, but having a gazillion single-purpose classes for such high-level operations seems to make things harder on users, not simpler.
>>
>> Discussion welcome, of course :)

There might be some bits lets over, but I'd like to see at least the
following things moved out of Utilities:
* finding pointers: Utilities >> #pointersTo:except: already lives in
PointerFinder
* the identification protocol in its entirety belongs in a class
called something like SystemAuthor
* the old update stream stuff really ought to go
* move the selector hacking stuff to Symbol
(#inherentSelectorForGetter:, I'm looking at you!)
* any other methods that take a single parameter and construct
something based on that parameter really belongs with the (expected)
parameter's class. (The general case of the
#inherentSelectorForGetter: example.)

>> - Bert -
>>
>
> It walks like a utility and it quacks like a utility, so I think it's a Utility.

Well, there are Utilities, and there are dumping grounds for things
you can't immediately find the proper place for, and just dump it any
old place.

frank

> Dave
>
>

On 12 August 2013 20:39, Chris Muller <[hidden email]> wrote:
Despite my monomania, I agree. In this particular case there is only
one thing to remember - update - but for sure, higher level packages
stitch together smaller, specific, goals into some overarching
concern.

> The facade would reside in some pretty high-level package, but which
> one?  A reason to be interested in starting to think about our package
> hierarchy..
>
> As for the facades name, hm.  We do already have "Smalltalk"...?

Certainly `Smalltalk updateFromTrunk` has a nice ring to it.

frank

On 2013-08-12, at 21:45, Frank Shearar <[hidden email]> wrote:
>
> Certainly `Smalltalk updateFromTrunk` has a nice ring to it.
>
> frank

... unless you set a different default updateURL, as is the case in a fresh release image (or like we did for the Frank system at Viewpoints). So I wouldn't put "trunk" into the name for the general utility.

- Bert -

On 12 August 2013 21:25, Bert Freudenberg <[hidden email]> wrote:
> On 2013-08-12, at 21:45, Frank Shearar <[hidden email]> wrote:
>>
>> Certainly `Smalltalk updateFromTrunk` has a nice ring to it.
>>
>> frank
>
> ... unless you set a different default updateURL, as is the case in a fresh release image (or like we did for the Frank system at Viewpoints). So I wouldn't put "trunk" into the name for the general utility.

updateFromTrunk
    ^ self updateFromURL: 'http://source.squeak.org/trunk'

frank

> - Bert -
>
>
>

On 2013-08-12, at 21:40, Frank Shearar <[hidden email]> wrote:

Apropos:

http://geek-and-poke.com/geekandpoke/2013/8/20/naming-is-key

- Bert -