<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><span style="font-family:arial,sans-serif;color:rgb(34,34,34)">On Wed, Jun 28, 2017 at 12:19 AM, Eliot Miranda </span><span dir="ltr" style="font-family:arial,sans-serif;color:rgb(34,34,34)"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span><span style="font-family:arial,sans-serif;color:rgb(34,34,34)"> wrote:</span><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi All, Hi Bert, Hi Colin,<div><br></div><div>    today I was working with Ron Teitelbaum on porting the Terf client to Squeak 6.x.  The bootstrap builder creates some base MCConfigurations and then updates them from the various repositories, hence downloading the latest versions of certain packages into the package cache.</div><div><br></div><div>Some of the downloaded packages are for Tweak, and Tweak classes include field definitions which require special Monticello support to manage.  The special handling is provided by the TweakMC package.  Here are some of the relevant definitions:</div><div><br></div><div>MCStWriter>><wbr>visitTweakFieldDefinition: definition<div><span class="gmail-m_5472800488947415325gmail-Apple-tab-span" style="white-space:pre-wrap">        </span>self writeTweakFieldDefinition: definition</div><div><br></div><div><br></div><div>MCStWriter>><wbr>writeTweakFieldDefinition: definition</div><div><span class="gmail-m_5472800488947415325gmail-Apple-tab-span" style="white-space:pre-wrap">  </span>self chunkContents: [:s | definition printDefinitionOn: stream]</div><div><br></div><div>which produces output like the following in the <a href="http://snapshot.st" target="_blank">snapshot.st</a> file:</div><div><br></div><div><div>CCostumeGrid defineFields: '<?xml  version="1.0" ?></div><div><fields></div><div>        <field toGet="origin" toSet="origin:" changeEvent="originChanged"><wbr>origin</field></div><div>        <field toGet="extent" toSet="extent:" changeEvent="extentChanged"><wbr>extent</field></div><div>        <field toGet="enabled" toSet="enabled:" changeEvent="enabledChanged"><wbr>enabled</field></div><div>        <field toGet="visible" toSet="visible:" changeEvent="visibleChanged"><wbr>visible</field></div><div>        <field toGet="color" toSet="color:" changeEvent="colorChanged"><wbr>color</field></div><div></fields>'!</div></div><div><br></div><div>Note that no special support is needed for producing the snapshot.bin because that can save arbitrary objects.</div><div><br></div><div>So, (I think) because we were loading packages saved by Squeak V3 into a Squeak Spur image the binary isn't loaded and instead the source is compiled. (Am I right?)</div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">​It's not an ImageSegmen​t, so that should not be a problem. Missing class definitions, however, would be a problem. This might be the case with MCFieldDefs (or whatever they are called, don't</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">​remember).</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>  If the update happens *before* TweakMC has been loaded then the packages that get installed into package-cache are missing all the field definitions because the support to produce them is missing.</div><div><br></div><div>This was exactly our situation; we're freshly bootstrapping a Terf image, which includes adding support for Tweak, and TweakMC is loaded by the bootstrap /after/ the configurations have been updated, and hence the Tweak packages in the package-cache are corrupted.</div><div><br></div><div>We fixed our issue by modifying the bootstrap to load TweakMC up front.  But IMO *this shouldn't be necessary*.</div><div><br></div><div>Why, when Monticello downloads a package from a repository, does it rewrite that package to install it in the package-cache directory?  </div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">​Because MC has no concept of "files". Each repository can have a different representation for how it stores a version (e.g. MCDictionaryRepository is literally just a dictionary of MCVersions). That's why an MCVersion is created by an MCReader when loading from a repo, and writing to a repo invokes that repo's MCWriter.</div></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Surely it has *no business* rewriting the contents of the package and could simply copy the file itself.  If it does the rewrite, as it is doing now, it opens up the transcription to all sorts of errors, the above being one.  Not only is the approach slow, and error prone, it is unnecessary.  The file could be copied quite simply.</div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">​Only if both repos are MCFileBasedRepositories. ​</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Is this easy to fix?  I think it's a really bad design flaw.</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">​I don't think it's simple to fix. A version is not a file conceptually, so anything we hack to make it look like it is would be just that, a hack. The Right Way is to load the extension for MC itself first, and then use the mechanics that are there.</div></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">That hack could be added to MCVersion>>addToCache along the lines of</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><div class="gmail_default"><br></div><div class="gmail_default">addToCache</div><div class="gmail_default"><span style="white-space:pre"> </span>(thisContext findContextSuchThat: [:c | c receiver isKindOf: MCReader]) ifNotNil:</div><div class="gmail_default"><span style="white-space:pre">             </span>[:ctxt | | contents |</div><div class="gmail_default"><span style="white-space:pre">         </span>contents := (ctxt receiver instVarNamed: 'stream') contentsOfEntireFile.</div><div class="gmail_default"><span style="white-space:pre">              </span>self halt].</div><div class="gmail_default"><span style="white-space:pre">   </span>MCCacheRepository default storeVersion: self</div><div class="gmail_default"><br></div><div class="gmail_default">... and then store 'contents' in the cache directly. The hack could be cleaned up by using a notification to get at the stream by more official means. However, I don't think that's a good idea, as it goes against the design as explained above. Other opinions/ideas very welcome :)</div><div class="gmail_default"><br></div></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">- Bert -</div></div></div></div>