Hi Bert,

On Thu, Mar 23, 2017 at 5:58 AM, Bert Freudenberg <bert at freudenbergs.de>
wrote:

> On Wed, Mar 22, 2017 at 11:08 PM, David T. Lewis <lewis at mail.msen.com>
> wrote:
>
>> On Wed, Mar 22, 2017 at 02:39:41PM -0700, Eliot Miranda wrote:
>> > On Wed, Mar 22, 2017 at 2:17 PM, David T. Lewis <lewis at mail.msen.com>
>> wrote:
>> >
>> > > One temporary glitch is that the update to Kernel-eem.1067 is
>> generating a
>> > > merge
>> > > request dialog. I'm not certain, but I think that this would go away
>> with
>> > > an
>> > > additional update map to force update from Kernel-eem.1065 to
>> > > Kernel-eem.1067.
>> > >
>> >
>> > Damn, and I thought I'd figured out a way to get away with one update
>> map
>> > :-).  So how to I generate the intermediate map and what version number
>> > should it receive?
>> >
>>
>> I'm not sure I have this right, so hopefully someone else can confirm or
>> correct me. But I think this is what is happening:
>>
>> - The update-eem.400 update map loads Kernel-eem.1065, which is the
>> version
>> immediately before the class hierarchy changes.
>>
>> - Kernel-eem.1066 (and any later package) has the package prefix that
>> changes
>> the class hierarchy. As of 1066, the changes have been made in the
>> preamble
>> but not yet committed, so the package is dirty after loading 1066.
>>
>> - Kernel-eem.1077 commits the actual changes. The package is dirty at this
>> point, hence the merge dialog.
>>
>> Kernel-eem-1077 contains the prefix that makes the changes, and also the
>> actual changes. So I am guessing that if we add update-xxx.401 and have it
>> point directly to Kernel-eem.1077, then this would probably avoid the
>> merge dialog. But I have not tried it so I am not sure.
>>
>> Dave
>>
>
> I did not get a merge dialog, so maybe all is fine?
>
> Note that if Eliot had not put the migration code in a method, we wouldn't
> even have needed an update map. With Tim Felgentreff I did this before (but
> forgot to put in the inbox, sorry) and we only had a preamble like this in
> the Kernel package:
>

I don't like having complex package scripts, at least not unless senders
works with them.  So I consciously chose to use the method.  One of the
things that's a little weak with package scripts is knowing how long they
should stay there.  The style that I used in my method
- check if the transformation has been applied and if so exit.
- apply the transformation
- check that the transformation succeeded
allows for the preamble script to invoke the method as many times as the
package is loaded until the preamble script is modified

It would be nice to have some ability to look at versions of package
scripts and match the changes against package versions.  I'm not sure I see
a way of determining easily
- if a particular version of a package script was actually applied to an
image
- when a particular version of a package script was actually applied to an
image
The same criticism can be levelled at class initialisers, but their being
more accessible to the standard tools makes exploring the questions easier
IMO.


> ---------- package preamble ----------
> "CompiledMethod is too dangerous to change, Monticello won't do it for us"
> (Smalltalk classNamed: 'CompiledCode') ifNil: [
> (ByteArray variableByteSubclass: #CompiledCode
> instanceVariableNames: ''
> classVariableNames: ''
> poolDictionaries: ''
> category: 'Kernel-Methods') setFormat: CompiledMethod format.
> CompiledMethod superclass: (Smalltalk at: #CompiledCode).
> CompiledMethod class superclass: (Smalltalk at: #CompiledCode) class.
> (Smalltalk at: #CompiledCode) classPool: CompiledMethod classPool.
> CompiledMethod classPool: Dictionary new].
>
> This way there's no need to have separate package versions adding the
> script, introducing the preamble, loading the actual code, and removing the
> script; it's just a single version.
>
> (just mentioning this for future migrations, what Eliot committed works
> fine)
>

You could have saved me some work ;-)


>
> - Bert -
>
>
>
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170324/e2aacabe/attachment.html>