[squeak-dev] [Vm-dev] Re: [Pharo-dev] Nuking VM ImageSegment support (was Re: Daily Commit Log; System-bf.916)

Eliot Miranda eliot.miranda at gmail.com
Mon Jul 3 21:43:56 UTC 2017


Hi Bert, Hi Tim,


On Thu, Sep 15, 2016 at 2:55 PM, <commits at source.squeak.org> wrote:
> [snip]
>
>> http://lists.squeakfoundation.org/pipermail/packages/2016-Se
>> ptember/068930.html
>>
>> Name: System-bf.916
>> Ancestors: System-bf.915
>>
>> Replace VM-level ImageSegment loading with a Smalltalk implementation for
>> old (interpreter-era) projects.
>>
>> Also removes support for writing segments.
>>
>> This overrides the Spur support introduced in System-eem.758.
>
>
I am currently putting back the ImageSegment support for saving projects
and loading native segments produced in this way.  I''ve added subclasses
of ImageSegment called NativeImageSegment and LegacyImageSegment.   I have
a few questions.

1. I'm curious about the ImageSegment>>scanFrom: method:

!ImageSegment methodsFor: 'fileIn/Out' stamp: 'RAA 6/22/2000 17:49'!
scanFrom: aStream
    "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."
    | val chunk |

    [aStream atEnd] whileFalse:
        [aStream skipSeparators.
        val := (aStream peekFor: $!!)
            ifTrue: ["Move (aStream nextChunk), find the method or class
                        comment, and install the file location bytes"
                    (Compiler evaluate: aStream nextChunk logged: false)
                        scanFromNoCompile: aStream forSegment: self]
            ifFalse: [chunk := aStream nextChunk.
                    aStream checkForPreamble: chunk.
                    Compiler evaluate: chunk logged: true].
        aStream skipStyleChunk].
    "regular fileIn will close the file"
    ^ val! !

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?
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?

2. Should I pull in the Etoys extensions deleted in EToys-bf.234?
 (ImageSegment>>(classOrganizersBeRoots:,rehashDictionaries:,rehashMethodDictionaries:)?
I'm guessing they'll be needed for native loading.

3. Same for the SMBase extension ImageSegment>>writeForExportOn:.  I guess
this should come back in too.

4.  Where should I look for tests that may have been removed?

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


More information about the Squeak-dev mailing list