[Vm-dev] Re: [Pharo-project] we need help for rome

Bert Freudenberg bert at freudenbergs.de
Sun Apr 18 17:45:48 UTC 2010


I think only the first 4 inst vars are actually used by the plugin:

http://squeakvm.org/svn/squeak/trunk/platforms/unix/src/plugins/RomePlugin/RomePlugin.c
#define CanvasHandleIndex 0
#define CanvasTargetIndex 1
#define CanvasFlagsIndex 2
#define CanvasStrokeColorIndex 3
#define CanvasInstSize 8

So on Linux, Rome does use the "right" size. John appears to have used a Sophie image to generate his Plugin, which makes this fail (though I could not find his Rome plugin in the Mac OS platform code so can't verify that theory).

The proper fix would be to modify RomePlugin class>>initializeInstVarIndices to not generate the indices, but simply hard-code only the used ones (setting CanvasInstSize to 4), and change the comparison John mentioned below to <=. Also remove the unused *Index class vars. Now that there are plugins in the wild, hard-coding the indices is a good idea anyway. During development, the flexible generator version was useful, but not anymore.

- Bert -

On 18.04.2010, at 18:45, Stéphane Ducasse wrote:
> 
> John
> 
> how can I know the order and the iv that are used by the plugin?
> 
> Stef
> 
> On Apr 17, 2010, at 4:09 AM, John M McIntosh wrote:
> 
>> (a) In Sophie   
>> RomeCanvas subclass: #RomePluginCanvas
>> 	instanceVariableNames: 'handle target flags strokeColor stack font fontSize fontMatrix currentFillColor currentBackColor glyphAccuracy cachedGlyphBlt cachedClearBlt drawRunPositions drawRunGlyph drawRunPointY'
>> 	classVariableNames: 'CachedTarget FlagFill FlagStro
>> 
>> (b) In Pharo 
>> 
>> RomeCanvas subclass: #RomePluginCanvas
>> 	instanceVariableNames: 'handle target flags strokeColor stack font fontSize fontMatrix'
>> 	classVariableNames: 'FlagFill FlagStroke Registry'
>> 	poolDictionaries: ''
>> 	category: 'Rome-PluginCanvas'
>> 
>> Comment warning: 
>> 
>> INST VAR ORDER IS KNOWN TO PLUGIN! DO NOT REARRANGE!
>> 
>> 
>> So in the plugin we have... 
>> 
>> if (interpreterProxy->slotSizeOf(canvasOop)) < CanvasInstSize)
>> 	fail().
>> 
>> 
>> where CanvasInstSize is 13
>> 
>> but as you see in (b) the number of instance slots for the canvas Oops is  8. 
>> 
>> 8 < 13, oops you fail. 
>> 
>> So where did the instance vars   currentFillColor currentBackColor glyphAccuracy cachedGlyphBlt cachedClearBlt
>> go? On purpose gone, refactored, old code. etc.... 
>> 
>> 
>> On 2010-04-16, at 1:37 PM, Stéphane Ducasse wrote:
>> 
>>> 
>>> On Apr 16, 2010, at 10:30 PM, John McIntosh wrote:
>>> 
>>>> Well I'm just as puzzled as you since the primitive gets executed and you are using the same binary that was shipped with Sophie years back. 
>>> 
>>> I like to hear that because I feel less idiot. :)



More information about the Vm-dev mailing list