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

[stephane ducasse]

Thanks Bert

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

how did you get that information? from the image side or C code?
Because I tried to see but unsure.

> 
> 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).

Now I understand why alain could remove the instance variable when cleaning the image side. 


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


I browsed a bit the C code and I'm learning so may be my questions are not clever, but 

	- do we need the pango primitives for ROME?
	Apparently Pango may use Cairo for fonts rendering but do Rome needs that?
	So is it simpler to use fonts via pango than cairo.

	- then what about FormInstSize?

	(interpreterProxy->slotSizeOf(formOop)) < FormInstSize
	does it mean
	
	- the primitives we have access to are listed by 
		void* RomePlugin_exports[][3] = {
	
	- how do we know that the plugin is somehow in sync with Cairo "latest" version?

Stef

> 
> - 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. :)
>