<div dir="ltr">Hi Bert,<div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 23, 2017 at 5:58 AM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">On Wed, Mar 22, 2017 at 11:08 PM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-m_6532931549143463089gmail-"><span class="gmail-">On Wed, Mar 22, 2017 at 02:39:41PM -0700, Eliot Miranda wrote:<br>
> On Wed, Mar 22, 2017 at 2:17 PM, David T. Lewis <<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>> wrote:<br>
><br></span><span class="gmail-">> > One temporary glitch is that the update to Kernel-eem.1067 is generating a<br>
> > merge<br>
> > request dialog. I'm not certain, but I think that this would go away with<br>
> > an<br>
> > additional update map to force update from Kernel-eem.1065 to<br>
> > Kernel-eem.1067.<br>
> ><br>
><br>
> Damn, and I thought I'd figured out a way to get away with one update map<br>
> :-).  So how to I generate the intermediate map and what version number<br>
> should it receive?<br>
><br>
<br>
</span></span><span class="gmail-">I'm not sure I have this right, so hopefully someone else can confirm or<br>
correct me. But I think this is what is happening:<br>
<br>
- The update-eem.400 update map loads Kernel-eem.1065, which is the version<br>
immediately before the class hierarchy changes.<br>
<br>
- Kernel-eem.1066 (and any later package) has the package prefix that changes<br>
the class hierarchy. As of 1066, the changes have been made in the preamble<br>
but not yet committed, so the package is dirty after loading 1066.<br>
<br>
- Kernel-eem.1077 commits the actual changes. The package is dirty at this<br>
point, hence the merge dialog.<br>
<br>
Kernel-eem-1077 contains the prefix that makes the changes, and also the<br>
actual changes. So I am guessing that if we add update-xxx.401 and have it<br>
point directly to Kernel-eem.1077, then this would probably avoid the<br>
merge dialog. But I have not tried it so I am not sure.<br>
<br>
Dave<br></span></blockquote><div><br></div><div>I did not get a merge dialog, so maybe all is fine?</div><div><br></div><div>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:</div></div></div></div></blockquote><div><br></div><div>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</div><div>- check if the transformation has been applied and if so exit.</div><div>- apply the transformation</div><div>- check that the transformation succeeded</div><div>allows for the preamble script to invoke the method as many times as the package is loaded until the preamble script is modified</div><div><br></div><div>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</div><div>- if a particular version of a package script was actually applied to an image</div><div>- when a particular version of a package script was actually applied to an image</div><div>The same criticism can be levelled at class initialisers, but their being more accessible to the standard tools makes exploring the questions easier IMO.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div><div>---------- package preamble ----------</div><div>"CompiledMethod is too dangerous to change, Monticello won't do it for us"</div><div>(Smalltalk classNamed: 'CompiledCode') ifNil: [</div><div><span class="gmail-m_6532931549143463089gmail-Apple-tab-span" style="white-space:pre-wrap">    (</span>ByteArray variableByteSubclass: #CompiledCode</div><div><span class="gmail-m_6532931549143463089gmail-Apple-tab-span" style="white-space:pre-wrap">         </span>instanceVariableNames: ''</div><div><span class="gmail-m_6532931549143463089gmail-Apple-tab-span" style="white-space:pre-wrap">              </span>classVariableNames: ''</div><div><span class="gmail-m_6532931549143463089gmail-Apple-tab-span" style="white-space:pre-wrap">         </span>poolDictionaries: ''</div><div><span class="gmail-m_6532931549143463089gmail-Apple-tab-span" style="white-space:pre-wrap">           </span>category: 'Kernel-Methods') setFormat: CompiledMethod format.</div><div><span class="gmail-m_6532931549143463089gmail-Apple-tab-span" style="white-space:pre-wrap">  </span>CompiledMethod superclass: (Smalltalk at: #CompiledCode).</div><div><span class="gmail-m_6532931549143463089gmail-Apple-tab-span" style="white-space:pre-wrap">      </span>CompiledMethod class superclass: (Smalltalk at: #CompiledCode) class.</div><div><span class="gmail-m_6532931549143463089gmail-Apple-tab-span" style="white-space:pre-wrap">  </span>(Smalltalk at: #CompiledCode) classPool: CompiledMethod classPool.</div><div><span class="gmail-m_6532931549143463089gmail-Apple-tab-span" style="white-space:pre-wrap">     </span>CompiledMethod classPool: Dictionary new].</div></div><div><br></div><div>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.</div><div><br></div><div>(just mentioning this for future migrations, what Eliot committed works fine)</div></div></div></div></blockquote><div><br></div><div>You could have saved me some work ;-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-HOEnZb"><font color="#888888"><div><br></div><div>- Bert -</div><div><br></div></font></span></div></div></div>
<br><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>