<div dir="ltr">Hi Bert,<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 4, 2017 at 5:01 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><div 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 Mon, Jul 3, 2017 at 11:43 PM, 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></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><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 Bert, Hi Tim,<div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="m_7128061771787360300gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Sep 15, 2016 at 2:55 PM, <span dir="ltr"><<a href="mailto:commits@source.squeak.org" target="_blank">commits@source.squeak.org</a>></span> wrote:</div><div class="gmail_quote">[snip]<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><a href="http://lists.squeakfoundation.org/pipermail/packages/2016-September/068930.html" rel="noreferrer" target="_blank">http://lists.squeakfoundation.<wbr>org/pipermail/packages/2016-Se<wbr>ptember/068930.html</a><br>
<br>
Name: System-bf.916<br>
Ancestors: System-bf.915<br>
<br>
Replace VM-level ImageSegment loading with a Smalltalk implementation for old (interpreter-era) projects.<br>
<br>
Also removes support for writing segments.<br>
<br>
This overrides the Spur support introduced in System-eem.758.</blockquote></div></div></div></div></blockquote></div></div></blockquote><div><br></div></span><div>I am currently putting back the ImageSegment support for saving projects and loading native segments produced in this way.</div></div></div></div></blockquote><div><br></div></span><div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Why? I thought we agreed that ImageSegments are not a great idea as a file format, for their lack of compatibility. Serialization speed isn't an issue anymore thanks to your fast jit.</div></div></div></div></div></blockquote><div><br></div><div>Quite, but there's legacy...</div><div><br></div><div>1. Tert is being ported to Squeak 6.x. Terf (nee Teleplace, nee Qwaq Forums, nee Croquet) makes heavy use of image segments; they're used to transfer room contents from server to entering client.</div><div><br></div><div>2. Max Leske is using segments for some application in Pharo and has been waiting patiently for a working version in Spur</div><div><br></div><div>3. I myself wanted to be able to transfer projects from working image to fresh VMMaker image build</div><div><br></div><div>4. the code is mature and works, so if it ain't broke why break it ? :-)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">What ImageSegments *are* good at is for splitting up an image into segments that do not have to be in memory at the same time - but in that case they would not be an independent entity but be considered part of one particular image. And for that we need only very few methods (that I removed too, see storeSegment).<br></div></div></div></div></div></blockquote><div><br></div><div>Well, we should indeed clean up, but I am for keeping the ability to save projects and for applications like Terf to continue.</div><div><br></div><div>I note that image segments can only be loaded into a VM using an identical heap representation, hence, even though 64 & 32 bit Spur have identical object header formats, loading a 32-bit segment into 64-bit Spur or vice verse needs to be done by parsing, adding to the suite of parsers written by Bert.</div><div><br></div><div>So while the store-side primitive may be useful, the load-time primitive is less useful. At some stage we could discard it in favor of a pure Smalltalk loader, provided performance is good enough, e.g. for Terf.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><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 class="gmail_extra"><div class="gmail_quote"><div> I''ve added subclasses of ImageSegment called NativeImageSegment and LegacyImageSegment. I have a few questions.</div><div><br></div><div>1. I'm curious about the ImageSegment>>scanFrom: method:</div><div><br></div><div><div>!ImageSegment methodsFor: 'fileIn/Out' stamp: 'RAA 6/22/2000 17:49'!</div><div>scanFrom: aStream</div><div> "Move source code from a fileIn to the changes file for classes in an ImageSegment. Do not compile the methods. They already came in via the image segment. After the ImageSegment in the file, !!ImageSegment new!! captures control, and scanFrom: is called."</div><div> | val chunk |</div><div><br></div><div> [aStream atEnd] whileFalse:</div><div> [aStream skipSeparators.</div><div> val := (aStream peekFor: $!!)</div><div> ifTrue: ["Move (aStream nextChunk), find the method or class</div><div> comment, and install the file location bytes"</div><div> (Compiler evaluate: aStream nextChunk logged: false)</div><div> scanFromNoCompile: aStream forSegment: self]</div><div> ifFalse: [chunk := aStream nextChunk.</div><div> aStream checkForPreamble: chunk.</div><div> Compiler evaluate: chunk logged: true].</div><div> aStream skipStyleChunk].</div><div> "regular fileIn will close the file"</div><div> ^ val! !</div></div><div><br></div><div>I don't see this in the new (legacy, System-bf.916) image segment loading code. Do Etoys projects not include source code and hence its irrelevant? </div></div></div></div></blockquote><div><br></div></span><div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">They do, but the code path to load them does not go through this method.</div></div></div></div></div></blockquote><div><br></div><div>What path does it go through?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><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 class="gmail_extra"><div class="gmail_quote"><div> The question boils down to whether this should be a method on ImageSegment, and hence inherited by both NativeImageSegment and LegacyImageSegment, or just NativeImageSegment. Also, I don't see how this method attaches sources to the methods brought in. Is it in fact useless and hence that's why you've left it out? If so, would it not be useful to add code that does update the source pointers in loaded methods correctly?</div></div></div></div></blockquote><div><br></div></span><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">The ImageSegment nowadays only stores uniclasses as objects. Other changes to the system are simply filed in, and not included in the segment. This method appears to be unused. I tried to trim everything not strictly needed for project loading</div></div></div></div></blockquote><div><br></div><div>OK, I'll nuke it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><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 class="gmail_extra"><div class="gmail_quote"><div></div><div>2. Should I pull in the Etoys extensions deleted in EToys-bf.234? (ImageSegment>>(classOrganize<wbr>rsBeRoots:,rehashDictionaries:<wbr>,rehashMethodDictionaries:)? I'm guessing they'll be needed for native loading.</div></div></div></div></blockquote><div><br></div></span><div>rehashDictionaries<div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0);display:inline">: is still there, not sure if we need the others.</div><br></div><span class=""><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 class="gmail_extra"><div class="gmail_quote"><div></div><div>3. Same for the SMBase extension ImageSegment>>writeForExportOn<wbr>:. I guess this should come back in too.</div></div></div></div></blockquote><div><br></div></span><div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">SqueakMap uses ImageSegments, yes. No idea if it's a good idea to write a new native segment.</div></div><span class=""><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 class="gmail_extra"><div class="gmail_quote"><div></div><div>4. Where should I look for tests that may have been removed?</div></div></div></div></blockquote><div><br></div></span><div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">There are no tests, unfortunately ...</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">The way I was testing is taking a project written by Etoys (from <a href="http://squeakland.org" target="_blank">squeakland.org</a>) and dropping it into a trunk image. Before your changes this did work, more or less: If you revert to System-pre.956 and make allocateMethodContext: and allocateBlockContext: simply return nil, you can load old projects again. These contexts aren't needed anyways for Etoys projects (if we needed them I'd recreate by recompiling). </div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I'm attaching a simple project that I just tested with this.</div></div></div></div></div></blockquote><div> </div><div>Thanks! </div></div><br><div class="gmail_signature" data-smartmail="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>