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/R... #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. :)
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/R... #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. :)
On 18.04.2010, at 20:14, stephane ducasse wrote:
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/R... #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.
It's in the C code I linked above. I just reordered it for better readability.
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.
Pango provides word/paragraph layout. Many non-latin scripts (e.g. Devanagari) require "glyph shaping", there is no one-to-one mapping between Unicode characters and glyphs rendered in context. Pango can do that. I'm not aware of any other renderer in Squeak that would support this (Yoshiki added it for OLPC). Well, maybe the Unicode plugin from Scratch could do it too, not sure.
- then what about FormInstSize?
(interpreterProxy->slotSizeOf(formOop)) < FormInstSize does it mean
Same thing. The instance variables actually used by the plugin should be hard coded. Otherwise the same would happen as in Sophie - some inst vars were added to the Canvas, so the inst size compiled into the plugin became larger than necessary.
Btw, by now you probably have guessed that a workaround for the Mac issue would be to add 5 dummy inst vars to RomePluginCanvas just to make the plugin happy.
- the primitives we have access to are listed by void* RomePlugin_exports[][3] = {
Right.
- how do we know that the plugin is somehow in sync with Cairo "latest" version?
It doesn't need to be "in sync". But maybe I do not understand the question.
- Bert -
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. :)
Well hey I'm just the guy tapping the compile button, er no support agreement here...
Likely the original plugin code came via
MCHttpRepository location: 'http://source.impara.de/Rome' user: '' password: ''
If someone wants to make the required fixes to the plugin code, and the smalltalk code I *think* I can build a new plugin.. Likely this won't affect Sophie users (if any) because that's a one click app. However this means an update to the mac vm's and other platforms in order to ensure the smalltalk class in a Pharo image matches expectations.
On 2010-04-18, at 10:45 AM, Bert Freudenberg wrote:
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/R... #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 -
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Well, the Linux one is fine, as I wrote. It is built from
http://www.squeaksource.com/Rome.html
You could simply use that to build the plugin, which should work fine.
Or someone could merge the Sophie stuff from the impara repo, adding the fix I suggested.
The impara repos are read-only and not used anymore AFAIK, so I'd suggest committing to the squeaksource repo.
- Bert -
On 18.04.2010, at 23:23, John M McIntosh wrote:
Well hey I'm just the guy tapping the compile button, er no support agreement here...
Likely the original plugin code came via
MCHttpRepository location: 'http://source.impara.de/Rome' user: '' password: ''
If someone wants to make the required fixes to the plugin code, and the smalltalk code I *think* I can build a new plugin.. Likely this won't affect Sophie users (if any) because that's a one click app. However this means an update to the mac vm's and other platforms in order to ensure the smalltalk class in a Pharo image matches expectations.
On 2010-04-18, at 10:45 AM, Bert Freudenberg wrote:
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/R... #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 -
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Ok I will ask cyrille if he can have a look at the c :)
Stef
On Apr 18, 2010, at 11:23 PM, John M McIntosh wrote:
Well hey I'm just the guy tapping the compile button, er no support agreement here...
Likely the original plugin code came via
MCHttpRepository location: 'http://source.impara.de/Rome' user: '' password: ''
This is strange because I think that alain took it from there too. May be not.
Stef
If someone wants to make the required fixes to the plugin code, and the smalltalk code I *think* I can build a new plugin.. Likely this won't affect Sophie users (if any) because that's a one click app. However this means an update to the mac vm's and other platforms in order to ensure the smalltalk class in a Pharo image matches expectations.
On 2010-04-18, at 10:45 AM, Bert Freudenberg wrote:
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/R... #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 -
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
vm-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
John M McIntosh -
stephane ducasse