Begin forwarded message:

> From: [email protected]
> Date: April 18, 2010 8:15:05 PM GMT+02:00
> To: [email protected]
> Subject: Re: [Vm-dev] Re: [Pharo-project] we need help for rome
> 
> You are not allowed to post to this mailing list, and your message has
> been automatically rejected.  If you think that your messages are
> being rejected in error, contact the mailing list owner at
> [email protected].
> 
> 
> From: stephane ducasse <[email protected]>
> Date: April 18, 2010 8:14:58 PM GMT+02:00
> To: Squeak Virtual Machine Development Discussion 
> <[email protected]>
> Cc: [email protected]
> Subject: Re: [Vm-dev] Re: [Pharo-project] we need help for rome
> 
> 
> 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. :)
>> 
> 
> 
> 
> 

_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to