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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

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

Stéphane Ducasse


Begin forwarded message:

Date: April 18, 2010 8:15:05 PM GMT+02:00
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
[hidden email].


From: stephane ducasse <[hidden email]>
Date: April 18, 2010 8:14:58 PM GMT+02:00
To: Squeak Virtual Machine Development Discussion <[hidden email]>
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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project