we need help for rome
Locked
12
12
 
|
Stéphane Ducasse a écrit :
> Thanks john oops I learned something. > Now the problem is that I did not touch them. I just loaded code. So I wonder where they got lost or changed. > > Alain do you have the same in your image? > Hi all, Just back from a cool week-end, with a lot of sun... Yes, my RomePluginCanvas is the same as yours and it runs well on linux. But I've not removed any inst var myself. My version comes from the www.squeaksource.com/Rome. I've checked, and the RomePluginCanvas from squeaksource is still the same as mine: RomeCanvas subclass: #RomePluginCanvas instanceVariableNames: 'handle target flags strokeColor stack font fontSize fontMatrix' classVariableNames: 'FlagFill FlagStroke Registry' poolDictionaries: '' category: 'Rome-PluginCanvas' so, does it means that there are also two version of the plugin ? Cheers Alain > 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 >>> >> -- >> =========================================================================== >> John M. McIntosh <[hidden email]> Twitter: squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> =========================================================================== >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
probably :)
one coming from sophie and one coming from the repository. We will fix that as soon as we can make it run on mac (ok we just have to add the inst var) but would be nice to have a clean plugin but I imagine that john is stressed with the Scratch problem. Stef On Apr 19, 2010, at 8:44 AM, Alain Plantec wrote: > Stéphane Ducasse a écrit : >> Thanks john oops I learned something. >> Now the problem is that I did not touch them. I just loaded code. So I wonder where they got lost or changed. >> >> Alain do you have the same in your image? >> > Hi all, > Just back from a cool week-end, with a lot of sun... > Yes, my RomePluginCanvas is the same as yours and it runs well on linux. > But I've not removed any inst var myself. > My version comes from the www.squeaksource.com/Rome. > I've checked, and the RomePluginCanvas from squeaksource is still the same as mine: > > RomeCanvas subclass: #RomePluginCanvas > instanceVariableNames: 'handle target flags strokeColor stack font fontSize fontMatrix' > classVariableNames: 'FlagFill FlagStroke Registry' > poolDictionaries: '' > category: 'Rome-PluginCanvas' > > so, does it means that there are also two version of the plugin ? > > Cheers > Alain >> 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 >>>> >>> -- >>> =========================================================================== >>> John M. McIntosh <[hidden email]> Twitter: squeaker68882 >>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>> =========================================================================== >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Ok, it works when adding the instance variables:)
Thank you
2010/4/19 Stéphane Ducasse <[hidden email]> probably :) _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
good!
Stef On Apr 19, 2010, at 10:28 AM, Cyrille Delaunay wrote: > Ok, it works when adding the instance variables:) > Thank you > > 2010/4/19 Stéphane Ducasse <[hidden email]> > probably :) > one coming from sophie and one coming from the repository. > We will fix that as soon as we can make it run on mac (ok we just have to add the inst var) but would be nice to have a clean > plugin but I imagine that john is stressed with the Scratch problem. > > Stef > > On Apr 19, 2010, at 8:44 AM, Alain Plantec wrote: > > > Stéphane Ducasse a écrit : > >> Thanks john oops I learned something. > >> Now the problem is that I did not touch them. I just loaded code. So I wonder where they got lost or changed. > >> > >> Alain do you have the same in your image? > >> > > Hi all, > > Just back from a cool week-end, with a lot of sun... > > Yes, my RomePluginCanvas is the same as yours and it runs well on linux. > > But I've not removed any inst var myself. > > My version comes from the www.squeaksource.com/Rome. > > I've checked, and the RomePluginCanvas from squeaksource is still the same as mine: > > > > RomeCanvas subclass: #RomePluginCanvas > > instanceVariableNames: 'handle target flags strokeColor stack font fontSize fontMatrix' > > classVariableNames: 'FlagFill FlagStroke Registry' > > poolDictionaries: '' > > category: 'Rome-PluginCanvas' > > > > so, does it means that there are also two version of the plugin ? > > > > Cheers > > Alain > >> 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 > >>>> > >>> -- > >>> =========================================================================== > >>> John M. McIntosh <[hidden email]> Twitter: squeaker68882 > >>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > >>> =========================================================================== > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> [hidden email] > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> [hidden email] > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > > > > > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [Vm-dev] Re: we need help for rome
|
|
In reply to this post by Bert Freudenberg
On Apr 18, 2010, at 11:57 PM, Bert Freudenberg wrote: > 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/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. > > It's in the C code I linked above. I just reordered it for better readability. Yes I saw my question was more how do we identify code that is not used anymore? We just do the closure over the published primitives and the rest means that it is useful. My question was how did you identify that only 4 inst were used and not more. >>> 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. Ok I will browse the RomePlugin class with Cyrille and Jean-Baptiste >> 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. Yes. In fact my question was more is FormInstSize used (or are the functionality using FormInstSize used)? I have problems to see how we can clean the C code. All my questions should be interpreted with this slant. >> It doesn't need to be "in sync". But maybe I do not understand the question. Sorry was not clear. My question is how Cairo supports backwards compatibility? What happens if the plugin expect a different version of Cairo on the machine? May be they do not change their interface? Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
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/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 - >> > > -- > =========================================================================== > John M. McIntosh <[hidden email]> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Stéphane Ducasse a écrit :
> 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. > so two repositories. why ? does someone knows ? Cheers Alain > 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/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 - >>> >>> >> -- >> =========================================================================== >> John M. McIntosh <[hidden email]> Twitter: squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> =========================================================================== >> >> >> >> >> > > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
sophie used the impara ones.
So now this is good that we merged and check in the rome one. And probably repackage everything in Athens. Stef > > Stéphane Ducasse a écrit : >> 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. >> > I took it from squeaksource, not from source.impara.de. > so two repositories. > why ? > does someone knows ? > Cheers > Alain >> 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/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 - >>>> >>>> >>> -- >>> =========================================================================== >>> John M. McIntosh <[hidden email]> Twitter: squeaker68882 >>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>> =========================================================================== >>> >>> >>> >>> >>> >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [Vm-dev] Re: we need help for rome
|
|
In reply to this post by Stéphane Ducasse
On 19.04.2010, at 10:42, Stéphane Ducasse wrote:
> > > On Apr 18, 2010, at 11:57 PM, Bert Freudenberg wrote: > >> 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/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. >> >> It's in the C code I linked above. I just reordered it for better readability. > > Yes I saw my question was more how do we identify code that is not used anymore? > We just do the closure over the published primitives and the rest means that it is useful. > My question was how did you identify that only 4 inst were used and not more. If you look at the RomePlugin class you see that 8 class vars are defined. But in the generated C code, only the first four are declared. That is because the Slang translator only exports the used ones. That's how I know the others are unused - they were not exported :) >>>> 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. > > > Ok I will browse the RomePlugin class with Cyrille and Jean-Baptiste > > >>> 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. > > Yes. In fact my question was more is FormInstSize used (or are the functionality using FormInstSize used)? If you see it in the C code then yes, it is used. > I have problems to see how we can clean the C code. > All my questions should be interpreted with this slant. Well, no need to "clean the C code" because it is just generated. Clean the RomePlugin class instead :^) >>> It doesn't need to be "in sync". But maybe I do not understand the question. > > Sorry was not clear. > My question is how Cairo supports backwards compatibility? > What happens if the plugin expect a different version of Cairo on the machine? > May be they do not change their interface? Many projects are better about backwards compatibility than we are ;) Generally, once an API was added, it is *never* removed or changed in the same major version of a library. Only additions are allowed in point releases. This ensures code can dynamically link to older binaries and not break with newer releases. Also, the major version is part of the library name (executables actually link against bla.so.1 not bla.so) so multiple major versions of the same library can co-exist on a system. So major releases can remove or change existing API. In short, I wouldn't worry about it - I'm not sure in cairo's particular case but in general that's how it works. There is something to be said about published vs. public interfaces, and in Smalltalk we usually don't respect either ... - Bert - _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
On 2010-04-19, at 12:12 AM, Stéphane Ducasse wrote:
> probably :) > one coming from sophie and one coming from the repository. > We will fix that as soon as we can make it run on mac (ok we just have to add the inst var) but would be nice to have a clean > plugin but I imagine that john is stressed with the Scratch problem. > > Stef Well nothing a good night of sleep can't cure. I'm trying to build a new plugin based on the current squeaksource.com stuff. However MacPorts is busy grinding thru a build(s) for the thousand or so components to build freetype & pango & etc, since it's building a universal ppc, i386, x86_64 binary on an older G4 laptop running 10.5. Likely run for hours... -- =========================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
smime.p7s (3K) |
|
> probably :)
>> one coming from sophie and one coming from the repository. >> We will fix that as soon as we can make it run on mac (ok we just have to add the inst var) but would be nice to have a clean >> plugin but I imagine that john is stressed with the Scratch problem. >> >> Stef > > > Well nothing a good night of sleep can't cure. > I'm trying to build a new plugin based on the current squeaksource.com stuff. However MacPorts is busy grinding thru a build(s) for the thousand or so components to build freetype & pango & etc, since it's building a universal ppc, i386, x86_64 binary on an older G4 laptop running 10.5. Likely run for hours... oh yes I know the syndrome. Last time took me 5-6 hours for recompiling everything or what is just gtk :) What we will do is that I would like that this knowledge/burden is shared so we will give a try with jean-baptiste and cyrille to regenerate a plugin and compile it.... But we will see and learn a lot I imagine in the process. > > -- > =========================================================================== > John M. McIntosh <[hidden email]> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |