April 2010 - Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

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/… >>> #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

April 19, 2010

Re: [Pharo-project] we need help for rome

by StÃ©phane Ducasse

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 <stephane.ducasse(a)inria.fr> > 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 > >>>> Pharo-project(a)lists.gforge.inria.fr > >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>>> > >>> -- > >>> =========================================================================== > >>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > >>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > >>> =========================================================================== > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 19, 2010

Re: [Pharo-project] we need help for rome

by Cyrille Delaunay

Ok, it works when adding the instance variables:) Thank you 2010/4/19 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > 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 > >>>> Pharo-project(a)lists.gforge.inria.fr > >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>>> > >>> -- > >>> > =========================================================================== > >>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > >>> Corporate Smalltalk Consulting Ltd. > http://www.smalltalkconsulting.com > >>> > =========================================================================== > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 19, 2010

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

by StÃ©phane Ducasse

yes sounds good Stef >>>> > Anyway, couldn't we just link the first occurrence of "Smalltalk" to en.wikipedia.org/wiki/Smalltalk?

April 19, 2010

Re: [Pharo-project] Issue tracking system

by StÃ©phane Ducasse

On Apr 19, 2010, at 9:32 AM, GÃ¶ran Krampe wrote: > Hi! > > laurent laffont wrote: >> OK Thanks. >> Laurent Laffont >> On Fri, Apr 16, 2010 at 9:37 PM, Torsten Bergmann <astares(a)gmx.de <mailto:astares@gmx.de>> wrote: >> Sorry ... have to correct myself: Gjallar is based on Seaside. > > Indeed it is and AFAIK it should probably work fine in Pharo too. Gjallar has been "semi sleeping" for a while but I intend to try to move it forward and we have a customer pushing me also :) This is a great news. > > Please send any questions to the Gjallar mailinglist or to me privately and I will answer. > > regards, GÃ¶ran > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 19, 2010

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

by Adrian Lienhard

On Apr 19, 2010, at 09:10 , StÃ©phane Ducasse wrote: > On Apr 19, 2010, at 1:56 AM, Stephen Taylor wrote: > >> Henrik Johansen wrote: >> >>> Gotta love reddit... >> [...] >>> - "I don't know what Smalltalk is, and the site doesn't tell me, not even the about page!" >> >> That one I think is legitimate - and not just for Pharo but for almost every Open Source project out there. I think every project's home page should keep first time in visitors in mind. (My very least favourite thing for the first page of a site is to see the project commit log - talk about unwelcoming!). > > Good remark. > Thanks. > Does anybody have some text we could reuse? I think that anybody that is enough interested will be able to type "Smalltalk" into Google. Next, people are going to ask what a programming language is, and we have to explain that too ;) Anyway, couldn't we just link the first occurrence of "Smalltalk" to en.wikipedia.org/wiki/Smalltalk? >> And to say something positive - Pharo 1.0 looks great - solid and serious and workable. A couple of my co-workers have called my bluff and asked for a Smalltalk tutorial, and I'll be happy to show them Pharo. Thanks :) Cheers, Adrian

April 19, 2010

Re: [Pharo-project] Issue tracking system

by laurent laffont

2010/4/19 GÃ¶ran Krampe <goran(a)krampe.se> > Hi! > > laurent laffont wrote: > >> OK Thanks. >> >> Laurent Laffont >> >> >> >> On Fri, Apr 16, 2010 at 9:37 PM, Torsten Bergmann <astares(a)gmx.de<mailto: >> astares(a)gmx.de>> wrote: >> >> Sorry ... have to correct myself: Gjallar is based on Seaside. >> > > Indeed it is and AFAIK it should probably work fine in Pharo too. Gjallar > has been "semi sleeping" for a while but I intend to try to move it forward > and we have a customer pushing me also :) > > Please send any questions to the Gjallar mailinglist or to me privately and > I will answer. > > regards, GÃ¶ran Hi, I've just spent half an hour on it, unable to test the image provided on the website, magma errors :( . I'll put this on Gjallar mailing list as soon as I can. Load it into Pharo, I want it ! ConfigurationOfGjallar would be cool. Some questions, I haven't found answers on Gjallar website. One feature I would like is to split and merge issues, and keep trac of this split / merge. For example, two customers can report the same bug. But they don't know each other. I would like to create a merge of these two issues for me. When I mark it as resolved, both customers can see automatically their issues as resolved. Sometimes a reported issue involves several tasks. I want to create these tasks or split the issue in several sub-issues. When all sub-issues resolved, the original one is marked as resolved. Is it possible ? Cheers, Laurent Laffont > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 19, 2010

Re: [Pharo-project] Iliad 0.8 released!

by Julian Fitzell

2010/4/18 Nicolas Petton <petton.nicolas(a)gmail.com> > Le dimanche 18 avril 2010 Ã 19:25 +0100, Julian Fitzell a Ã©crit : > > 2010/4/18 Nicolas Petton <petton.nicolas(a)gmail.com> > > Now I'm not really happy with the codec stuff, as from a GNU > > Smalltalker > > point of view it seems too Squeak/Pharo oriented, but I can > > leave with > > that for now. > > > > To be honest, I'm not totally happy with that part either. :) It's > > good enough for now but reworking the encoding stuff is on my > > (personal, anyway) list for Seaside 3.1. > > Why do you keep Grease into Seaside's repository? Couldn't it have its > own repository and roadmap? > I suppose it might have it's own repository sometime. It probably will have its own "roadmap". It will *definitely* have its own version numbering (though releases will probably coincide fairly closely with Seaside's releases, at least for a while - I'm imagining a 1.0 release to coincide with Seaside's 3.0 final). For now it's more convenient for us to have it all in one repository. Also, we're not ready to cut the tie to Seaside... Grease is still, fundamentally, Seaside's compatibility layer. For now we're doing what we can to keep it general and inviting others to use it if it fits their needs (we certainly hope it does), but we need to ensure it's fitting our needs. Over time, as it becomes more general, if people are adopting it and we're more confident in its evolution, maybe we'll cut it loose. Julian

April 19, 2010

Re: [Pharo-project] Canvas transform bug when rendering text?

by Adrian Lienhard

Yes, please tag important fixes with milestone 1.0.1. I added this milestone as a predefined label (so it will show up in the autocompleter). Adrian On Apr 18, 2010, at 13:12 , StÃ©phane Ducasse wrote: > > On Apr 18, 2010, at 10:32 AM, Michael Roberts wrote: > >> On Sun, Apr 18, 2010 at 8:21 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> we should release 1.1 much faster :) >>> like that people will be able to get all the fixes.... >> >> yes ;) >> >> for tagging fixes for 1.0 maintenance, should we use a milestone 1.0.1 >> in the tracker? - is this code candidate for 1.0.1? > > 1.0.1 would be better because we really want to not spend too much time on this one > since far too many fixes were made in 1.1 > > Stef > >> >> cheers, >> Mike >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 19, 2010

Re: [Pharo-project] Issue tracking system

by GÃ¶ran Krampe

Hi! laurent laffont wrote: > OK Thanks. > > Laurent Laffont > > > On Fri, Apr 16, 2010 at 9:37 PM, Torsten Bergmann <astares(a)gmx.de > <mailto:astares@gmx.de>> wrote: > > Sorry ... have to correct myself: Gjallar is based on Seaside. Indeed it is and AFAIK it should probably work fine in Pharo too. Gjallar has been "semi sleeping" for a while but I intend to try to move it forward and we have a customer pushing me also :) Please send any questions to the Gjallar mailinglist or to me privately and I will answer. regards, GÃ¶ran

April 19, 2010