- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Vm-dev] Re: we need help for rome
by Bert Freudenberg April 19, 2010

April 19, 2010

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/… >> #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. :) >> >

2 2

Re: [Pharo-project] we need help for rome
by StÃ©phane Ducasse April 19, 2010

April 19, 2010

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/… >> #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(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > >

2 2

[Pharo-project] Help on collaborator Active book
by laurent laffont April 19, 2010

April 19, 2010

Hi, how to: - upload / display pictures ? - correctly highlight linux commands ? I use == but here http://book.pharo-project.org/book/Virtual-Machine/Building/BuildVMOnLinux it seems that / is a special character so the lines are red. Cheers, Laurent Laffont

7 19

[Pharo-project] Iliad 0.8 released!
by Nicolas Petton April 19, 2010

April 19, 2010

We are happy to announce the release of Iliad version 0.8 for GNU Smalltalk et Pharo. New features include: - Iliad is now using Grease and non portable code has been partially replaced; - The "mark dirty" mechanism has been rewritten to improve support for tabs/windows sharing the same session; - The new Formula package makes it easy to build validated forms; - Control flow has been improved with new widgets (like confirmations, sequences, etc) and widgets can append or prepend other widgets; - In addition to static files served with ILDiskDirectory, they can also be served from the image with ILMemoryDirectory; - Smalltalk code can be evaluated on DOM events with #on<event>Do: ; - Rewrite rules can be applied to the url builder; Last but not least, the release also includes an experimental implementation of Comet using XmlHttpRequest long polling. GNU Smalltalkers can download Iliad with gst-package (using GST 3.2): gst-package -t ~/.st --download iliad Or clone it from github: git clone git://github.com/NicolasPetton/iliad.git Pharo users can download a preconfigured image: http://www.iliadproject.org/resources/lYk5F_GiApFb/ggAMT_HRzRph9Yxp/Iliad-0… Or download Iliad packages from the SqueakSource repository: http://www.squeaksource.com/Iliad.html We would like to thank Steven Costiou for his work on the Pharo version of Iliad. Nicolas Petton & SÃ©bastien Audier

5 10

[Pharo-project] Canvas transform bug when rendering text?
by David Harvey April 19, 2010

April 19, 2010

Hi list, I'm writing a little charting morph, and while playing with rotating text for axis labels came across something which I've noted in Morphs text handling a couple of times. If I apply a transform in a drawing operation, rotated text _appears_ to be drawn twice, slightly offset, giving a scrappy bold look. It seems only to do this when drawing on a form canvas that's backed onto the display: if you pick and drag the morph, the text is rendered beautifully. The test morph attached isolates the problem. The transcript logging is an attempt to see what might be happening: looking at the output it appears that there are circumstances in which the during: block is invoked twice. Any thoughts? David ------------------ David Harvey www.teamsandtechnology.com www.cateams.com @david_harvey

10 28

[Pharo-project] Fwd: [Vm-dev] Re: we need help for rome
by StÃ©phane Ducasse April 18, 2010

April 18, 2010

Begin forwarded message: > From: pharo-project-owner(a)lists.gforge.inria.fr > Date: April 18, 2010 8:15:05 PM GMT+02:00 > To: stephane.ducasse(a)gmail.com > 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 > pharo-project-owner(a)lists.gforge.inria.fr. > > > From: stephane ducasse <stephane.ducasse(a)gmail.com> > Date: April 18, 2010 8:14:58 PM GMT+02:00 > To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > Cc: Pharo-project(a)lists.gforge.inria.fr > 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/… >> #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. :) >> > > > >

1 0

[Pharo-project] About the collaborative pier
by stephane ducasse April 18, 2010

April 18, 2010

Hi doru Can you change the setup of the pier to have a clear distinction between chapter and section? > because it is really counter intuitive > we never know if we are editing a new table of contents, chapter or section. > Just now I edited again an entry in the table of contents and added a subsection when I wanted a section. Thanks. I would like to avoid losing time all the time. Stef

5 7

[Pharo-project] Fix 1938 - various changes
by Sean P. DeNigris April 18, 2010

April 18, 2010

In inbox. http://code.google.com/p/pharo/issues/detail?id=1938 Sean DeNigris p.s. following the screencast (http://pharocasts.blogspot.com/2010/03/how-to-contribute-to-pharo.html) made it much easier to submit the code. -- View this message in context: http://n4.nabble.com/Fix-1938-various-changes-tp2014441p2014441.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

4 4

April 18, 2010

thanks sean. I may have some time today but this is really sunny :) If people want to have a look.... http://code.google.com/p/pharo/issues/detail?id=1938 Stef Begin forwarded message: > From: pharo(a)googlecode.com > Date: April 17, 2010 11:43:52 PM GMT+02:00 > To: stephane.ducasse(a)gmail.com > Subject: Re: Issue 1938 in pharo: related to 1910 Readonly.... > > > Comment #1 on issue 1938 by sean.p.denigris: related to 1910 Readonly.... > http://code.google.com/p/pharo/issues/detail?id=1938 > > Fix is PharoInbox. Slice-Fix1938. > > All suggestions implemented. And, for DigitalSignatureAlgorithm class, it looked like maybe > writeExamplesToDisk, testKeySet, and/or example should be moved also. > > > -- > You received this message because you are listed in the owner > or CC fields of this issue, or because you starred this issue. > You may adjust your issue notification preferences at: > http://code.google.com/hosting/settings

1 0

April 18, 2010

Hi guys Let me reiterate it: - We need you! - 75 % of the issues on the bug tracker are simple. - BTW how did we learn stuff, by reading code and learning. I'm not smart I'm just a tedious learner I can any opportunity to learn something new. - if you spend 30 min a week, YOU CAN get an IMPACT! - if pharo is important for you then 30 min in a good investment - every single LITTLE bugs fixed and improvement is IMPORTANT - we do not want the final latest coolest superhyper cool and hyper clever fixes! - we accept little improvement - in UNSTABLE we have the right to push not 100% finish code Now think what YOU can do for pharo. Because Yes YOU can - screencast - checking tests (yesterday I moved CompiledMethodAsStringTest>>testPrint to CompiledMethodTest>>testPrint) Yeah hyper difficult - Class comments: look at the URI class comment - blogging - tweeting We should slowly change our process so that Pharo continue to evolve even if we disappear on the moon. Now I asked marcus to focus on the newcompiler and stop fixing little bugs because we want to make progress on other fronts. We want newcompiler - we want the newcompiler - we want the newcompiler and fixing it and fixing its interface. We want Helvetia hooks -We want Helvetia hooks. We want a new package object (but I do not find time to code argh). Stef

11 21