Smalltalk › Squeak › Squeak - Dev

Changing the update map name

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Eliot Miranda-2

Changing the update map name

Hi David, Hi All,

I see a couple of issues with the update map name I can't solve. First, the change made in May to use a default McMcmUpdater instance means that the update map name is cached in the instance and I don't see how changing it in the Preferences browser would either flush the default instance or update the default instance's updateMapName. Second, changing the update map name in the Preferences browser has no effect. This seems to be because there's a conflict between the instance creation message for an McMcmUpdater:

McMcmUpdater class>>updateMapName: baseName

"Answer a new instance with a base update name baseName such as

'update' or 'update.oscog' "

^ self new updateMapName: baseName

and that this is used as the default setter for the preference:

McMcmUpdater class>>updateMapName

"Name for update map, without version info"

<preference: 'Update map name'

category: 'updates'

description: 'Base name for the update maps'

type: #String>

^UpdateMapName ifNil: ['update']

So I guess that we could rename the instance creation message to be forUpdateMapName: or simply nuke it. i.e. this

McMcmUpdater class>>default

"The default instance for system updates. Uses a default update map

name that may be set as a preference to enable a specific update stream

for a repository."

^ self updaters

at: self defaultUpdateURL

ifAbsentPut: [self updateMapName: self updateMapName]

would become

McMcmUpdater class>>default

"The default instance for system updates. Uses a default update map

name that may be set as a preference to enable a specific update stream

for a repository."

^ self updaters

at: self defaultUpdateURL

ifAbsentPut: [self forUpdateMapName: self updateMapName]

McMcmUpdater class>>default

"The default instance for system updates. Uses a default update map

name that may be set as a preference to enable a specific update stream

for a repository."

^ self updaters

at: self defaultUpdateURL

ifAbsentPut: [self new updateMapName: self updateMapName]

and updateMapName: would become

McMcmUpdater class>> updateMapName: aString

UpdateMapName := aString

_,,,^..^,,,_

best, Eliot

David T. Lewis

Re: Changing the update map name

Eliot,

You're right, there is a bug in the update map name preference handling.
I'll see if I can fix it (but maybe not tonight).

Background:

The default updater is not a singleton, it is one of possibly many
updaters. So changing the 'Update URL' or 'Update map name' preference
does not modify a single updater, instead it should answer the appropriate
updater for the given URL and update map name.

In an up to date 5.0 trunk image, if I open a PreferenceBrowser and
change the 'Update URL' preference, then MCMcmUpdater default answers
the corresponding updater. However, the 'Update map name' in the preferences
browser is not letting me enter a new name and that is a bug. As you note,
there is a conflict between the methods for instance creation and the
accidentally duplicate method names for preferences.

Dave

On Thu, Aug 27, 2015 at 03:41:53PM -0700, Eliot Miranda wrote:

> Hi David, Hi All,
>
> I see a couple of issues with the update map name I can't solve. First,
> the change made in May to use a default McMcmUpdater instance means that
> the update map name is cached in the instance and I don't see how changing
> it in the Preferences browser would either flush the default instance or
> update the default instance's updateMapName. Second, changing the update
> map name in the Preferences browser has no effect. This seems to be
> because there's a conflict between the instance creation message for an
> McMcmUpdater:
>
> McMcmUpdater class>>updateMapName: baseName
> "Answer a new instance with a base update name baseName such as
> 'update' or 'update.oscog' "
>
> ^ self new updateMapName: baseName
>
> and that this is used as the default setter for the preference:
>
> McMcmUpdater class>>updateMapName
> "Name for update map, without version info"
>
> <preference: 'Update map name'
> category: 'updates'
> description: 'Base name for the update maps'
> type: #String>
>
> ^UpdateMapName ifNil: ['update']
>
> So I guess that we could rename the instance creation message to be
> forUpdateMapName: or simply nuke it. i.e. this
>
> McMcmUpdater class>>default
> "The default instance for system updates. Uses a default update map
> name that may be set as a preference to enable a specific update stream
> for a repository."
>
> ^ self updaters
> at: self defaultUpdateURL
> ifAbsentPut: [self updateMapName: self updateMapName]
>
> would become
>
> McMcmUpdater class>>default
> "The default instance for system updates. Uses a default update map
> name that may be set as a preference to enable a specific update stream
> for a repository."
>
> ^ self updaters
> at: self defaultUpdateURL
> ifAbsentPut: [self forUpdateMapName: self updateMapName]
>
> or
>
> McMcmUpdater class>>default
> "The default instance for system updates. Uses a default update map
> name that may be set as a preference to enable a specific update stream
> for a repository."
>
> ^ self updaters
> at: self defaultUpdateURL
> ifAbsentPut: [self new updateMapName: self updateMapName]
>
> and updateMapName: would become
>
> McMcmUpdater class>> updateMapName: aString
>
> UpdateMapName := aString
>
>
> _,,,^..^,,,_
> best, Eliot

David T. Lewis

Re: Changing the update map name

In reply to this post by Eliot Miranda-2

Hi Eliot,

This should be resolved in MonticelloConfigurations-dtl.137 in the inbox.

I put it in the inbox because it affects the update stream. I think I have
a reasonable implementation now, but if you can check it before I move it
to trunk I'd appreciate it.

A limitation as currently implemented is that changing the update map name
requires a new default updater, so the user would be stuck updating the
(hopefully new) stream from its beginning. That is fine as long as we really
want to switch update streams, but not so good if someone is just fiddling
around with the preference settings to see what they do.

This can be fixed, but I think this is a relatively infrequent use case
so the current approach may be good enough. I did add a confirm dialog to
prevent the user from reinitializing the update stream without warning.

Dave

On Thu, Aug 27, 2015 at 03:41:53PM -0700, Eliot Miranda wrote: