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

Re: [Pharo-project] Trip to Pharo land

by StÃ©phane Ducasse

> Hi! > > So much discussion about that little post... :) > > On 05/30/2010 10:10 PM, StÃ©phane Ducasse wrote: >> Yes but in that case >> try 1.0 >> try 1.1 alpha > > Hmmm, Stephane still likes to top post I notice :) I do not know what you are implying. But I think that we are trying to building a process for pharo so this discussion is only about that: what are the expectations of people and what can we deliver and if all these stuff make sense. Conclusion - we can only retrofit showstoppers fixes - even good documentation of changes may not make people not failed but we can try something simple. - short release cycles is a must and we are doing it now. > Anyway, Igor nailed it pretty good with his post actually - I was merely documenting "what I was trying to do and ended up doing". > > And one thing to note is that I should have tried 1.1. But... why didn't I? > > I am not sure the website can/should be different - but fact remains that I got "fooled" by the fact that 1.0 was just released and I really (stupid I know, but hey...) didn't think it was to be considered "outdated" already :) Yes it really is. Get the feel with 1.1. It is ***really*** better. Stef

May 30, 2010

[Pharo-project] [update 1.1] #11380

by StÃ©phane Ducasse

11380 ----- - Issue 2484: Verify Number of FFI argument. Squeak trunk - Issue 2486: Pixel values for depth 32 is off for some colors. Thanks Henrik. - Issue 2337: Fix decompilation not to truncate very long decompiled methods. - Issue 2449: Help Browser should provide task bar icon - Issue 2470: runSimulated behaviour fixed. Tx eliot I recompile the complete image and got no problem so far. STef

May 30, 2010

Re: [Pharo-project] Rome/Athens notes

by Igor Stasenko

On 30 May 2010 23:08, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > cool post > Yeah, these things are quite interesting. Except that not much people actually interested in it :) Here's another thing, which can be done right (if we want). Rome/OpenVG Paths is actually nothing else than a special kind of more general thing - shape. So, at very basis, we should have only two components for painting: shape and paint. And in fact we need to support only a single operation: fill the shape with given paint. (The path stroke could be seen as a special kind of fill) So the question is: Really. Why we should constrain ourselves with specific things from a very starting, by cutting out a most basic (and abstact ideas) behind? There are infinite number of ways, how one could define a shape. While paths is only a small, yet effective representation of shapes. In same way there are infinite number of ways how one could define a paint. Then this looks like a strong basis for building-up a powerful & flexible graphics engine :) > Stef > > On May 30, 2010, at 8:53 PM, Igor Stasenko wrote: > >> On 30 May 2010 17:26, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> Hi, >>>> >>>> i found rome API very close to OpenVG. >>>> Still OpenVG is a bit superior :) >>>> So, i'm using it as a guide to model/implement Rome interfaces. >>> >>> Excellent! >>> >>>> So, here is my thoughts (i also having a draft class skeleton for them): >>> >>> frankly consider that we are working on Rome because we need something >>> to get access to Cairo/ whatever but we are newbie at the level. >>> Now the good point for us is that we are smart newbies :) >>> and ready to learn fast. >>> >>> So our first idea is >>> Â Â Â Â - make it work (romePluginCanvas) >>> Â Â Â Â - make all romeReferenceCanvas >>> >>> Get feedback, improve it improve it improve it >>> as well as make all the code use it make all the code use it . >>> >>> So thanks for your brainstorming/ideas/wishes >>> >>> >>>> Because, we could simply do: >>>> >>>> canvas fill: myPath with: myPaint >>>> >>>> instead of: >>>> >>>> canvas selectFill: myPaint. >>>> canvas fill: myPath. >>>> >>>> Because you anyways can't draw a paths without paints, i don't see why >>>> canvas should have a notion of 'current fill' or 'current paint'. >>>> I think that with paint's encapsulation, its not necessary. >>>> >>>> >>>> I'd like to hear your thoughts about it. >>> >>> No idea. Now at the back end level or "reference level" >>> is there a value to separate? >>> because like that you can do >>> >>>> canvas selectFill: myPaint. >>>> canvas fill: myPath. >>>> canvas fill: myPath.canvas fill: myPath.canvas fill: myPath.canvas fill: myPath.canvas fill: myPath.canvas fill: myPath.canvas fill: myPath. >>> >> >> Right. I considered that too, before proposing ;) >> Selecting a paint and then drawing multiple paths using it may look >> like having some value. >> >> But the point is, that in practice you barely will use such feature. >> >> For instance, lets take a morph: >> >> Morph>>romeDrawOn: aCanvas >> Â Â Â aCanvas >> Â Â Â Â Â Â Â selectFill: self fillStyle; >> Â Â Â Â Â Â Â selectPen: self borderStyle; >> Â Â Â Â Â Â Â drawRectangle: self bounds >> >> Do you seen how you can reuse a previously selected paints here? I don't. >> You can't reuse, because you don't know what was selected previously >> (and querying it will cost you more cycles >> than just selecting a right one). >> >> So, that's how you will use it in 99% of cases: >> >> select >> fill >> select >> fill.. >> >> But not >> >> select >> fill fill fill .. >> >> One more example. A Tiger demo, which i did in OpenVG binding. >> A Tiger takes it roots from an SVG file, so it is right to say, that >> it covers the use of SVG for drawings. >> In SVG, each particular path it having own stroke/fill parameters. >> There is no way how you can reuse a previously selected paints, >> because each unique fragment having own settings, >> and even if a whole scene (as big as Tiger) using similar paints >> multiple times, you still can't reuse them because you need to follow >> the order of drawing (iterating over a collection of paths, but not a >> collection of paints), otherwise you won't get what you expecting to >> see. >> >> You can reuse paints by creating them, and then caching , so it won't >> cost you a conversion, each time you using it. >> (For instance you can convert a GradientFillStyle to appropriate paint >> object, and cache it somewhere). >> But selecting the paint costs nothing, and buys nothing in terms of >> speed (at least in my implementation, and i suspect in every other ;) >> ). >> >> I think that 'selection' and 'binding' mechanism in those APIs serve >> only one purpose: to minimize the number of arguments >> for function calls and as a workaround of having no OO. >> But in smalltalk world, we having objects, which can represent any >> kind of our domain objects (paths, paints etc), >> and so, from OO perspective binding/selecting looks like a useless thing. >> >> A big downside of such selection mechanism can be illustrated by taking OpenGL. >> It is cool, when you having one window, one context, one texture and >> one pencil to rule them all. >> But in practice, you often need more than one canvas, window, texture etc. >> And this is where such 'selection' mechanism starts standing in your way. >> For instance, if you working with multiple GL contexts in squeak, the >> only way how to ensure that you _always_ >> working with right context is to prepend each api call with: >> Â makeCurrent(myContextHandle). >> by literally turning every gl function like: Â func(a, b, c) into >> func(context, a, b, c) >> otherwise, you can't ensure a correct behavior, when you working with >> multiple contexts in multiple processes, >> having high chances being interrupted by each other. >> >> This is where passing an extra argument(s) is preferable, because it >> tells directly, with what object you wanna work with and so it >> minimizes the chances to make a mess. :) >> >>> >>> Stef >>> >>> >>>> Paints: >>>> >>>> Paint is an object, which when applied to path, renders(draws) the >>>> path using paint's unique properties. >>>> >>>> I defined two methods in paint's base class: >>>> >>>> fillPath: aPath on: aCanvas >>>> >>>> Â Â Â self subclassResponsibility >>>> >>>> strokePath: aPath on: aCanvas >>>> >>>> Â Â Â self subclassResponsibility >>>> >>>> So, to draw a path, one should use a concrete paint to either fill it >>>> or stroke it (or both, if you want, but its handled by canvas and >>>> still will end up with separate fill & stroke requests to paint). >>>> >>>> I started from a quite basic things: >>>> >>>> NullPaint >>>> Â Paint which does not performs any drawing. >>>> Â Applying this paint to any path won't lead to any >>>> changes/processing. Â A simple OO approach to define 'nothing' :) >>>> >>>> SolidColorPaint >>>> Â Â Â instanceVariableNames: 'color' >>>> >>>> Â Paint with solid color. Most trivial thing which can be done :) >>>> >>>> RomePen >>>> Â Â Â instanceVariableNames: 'paint capStyle joinStyle width dash' >>>> >>>> A 'pen' paint is just encapsulating a set of properties, which is used >>>> for stroke. >>>> It is using another paint, which should handle the fills (in 'paint' >>>> ivar), while various stroke properties should be handled by itself. >>>> Filling with pen, will be the same as filling with its paint. While >>>> doing a stoke is different (includes path processing, given the values >>>> of pen's properties etc etc). >>>> I'm not sure with this part. Maybe stroke properties would be better >>>> to leave in canvas? Both OpenVG and Rome seems like following this >>>> road, >>>> but i don't quite like that stroke properties is global for canvas and >>>> lacking a proper encapsulation. >>>> >>>> CompositePaint >>>> Â Quite dumb thing. Holds a list of paints. When asked to fill or >>>> stroke the path, applies paints from own list. >>>> >>>> GradientPaint (abstract) >>>> Â LinearGradient >>>> Â RadialGradient >>>> etc.. >>>> paints which will use gradients for fills. Nothing fancy :) >>>> >>>> >>>> Canvas protocol: >>>> >>>> selectFill: anObject >>>> >>>> Â Â Â fill := anObject asRomePaintOn: self >>>> >>>> - selects a paint which will be used for fills. >>>> >>>> selectPen: anObject >>>> >>>> Â Â Â pen := anObject asRomePaintOn: self >>>> >>>> - selects a paint which will be used for stokes. >>>> >>>> >>>> stroke: anObject >>>> Â Â Â | path | >>>> Â Â Â path := anObject asRomePathOn: self. >>>> >>>> Â Â Â fill strokePath: path on: self. >>>> >>>> - stroke a path using currently selected 'pen' paint >>>> >>>> fill: anObject >>>> Â Â Â | path | >>>> Â Â Â path := anObject asRomePathOn: self. >>>> >>>> Â Â Â fill fillPath: path on: self. >>>> >>>> - fill path using paint for fills >>>> >>>> >>>> fillAndStroke: anObject >>>> Â Â Â | path | >>>> Â Â Â path := anObject asRomePathOn: self. >>>> >>>> Â Â Â fill fillPath: path on: self. >>>> Â Â Â pen strokePath: path on: self >>>> >>>> - fill and stroke path. >>>> >>>> And from that point, i wonder, do we need to have a paint's selection >>>> mechanisms at all? >>>> >>>> Because, we could simply do: >>>> >>>> canvas fill: myPath with: myPaint >>>> >>>> instead of: >>>> >>>> canvas selectFill: myPaint. >>>> canvas fill: myPath. >>>> >>>> Because you anyways can't draw a paths without paints, i don't see why >>>> canvas should have a notion of 'current fill' or 'current paint'. >>>> I think that with paint's encapsulation, its not necessary. >>>> >>>> >>>> I'd like to hear your thoughts about it. >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

May 30, 2010

Re: [Pharo-project] Trip to Pharo land

by GÃ¶ran Krampe

Hi! So much discussion about that little post... :) On 05/30/2010 10:10 PM, StÃ©phane Ducasse wrote: > Yes but in that case > try 1.0 > try 1.1 alpha Hmmm, Stephane still likes to top post I notice :) Anyway, Igor nailed it pretty good with his post actually - I was merely documenting "what I was trying to do and ended up doing". And one thing to note is that I should have tried 1.1. But... why didn't I? I am not sure the website can/should be different - but fact remains that I got "fooled" by the fact that 1.0 was just released and I really (stupid I know, but hey...) didn't think it was to be considered "outdated" already :) I will see if I can do an update trial on 1.1 and see how that goes. regards, GÃ¶ran

May 30, 2010

Re: [Pharo-project] Issue 670: Should clean Morph menu

by StÃ©phane Ducasse

I would start removing some of the them: the obvious one :) or the ones I marked > I take this thread back to life. Is everyone happy with this menu? Is It useful? :P > > On Wed, May 26, 2010 at 6:59 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > magic of morphic :) > > Stef > > On May 26, 2010, at 11:29 AM, Gary Chambers wrote: > > > Well, even if a morph does not, at any one time, use a table layout the settings are preserved and use if switched to a table layout... > > > > Curiously these options are pretty much the only ones I use from the menu ;-) > > > > > > Regards, Gary > > ----- Original Message ----- > > From: Carla F. Griggio > > To: Pharo-project(a)lists.gforge.inria.fr > > Sent: Tuesday, May 25, 2010 10:25 PM > > Subject: Re: [Pharo-project] Issue 670: Should clean Morph menu > > > > Well, I haven't tried all those actions, but if it helps in any way, the ones I usually use are: > > > > grab > > delete > > copy text > > submorphs > > inspect > > show actions > > debug-> > > inspect morph > > inspect model > > browse morph class > > browse model class > > > > > > > > I don't see what the layout options do. I don't know much about layouts, so maybe this doesn't make sense, but... shouldn't the options for table layout be available only if the morph I'm dealing with has a table layout? > > > > > > > > On Tue, May 25, 2010 at 5:58 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > **EXCELLENT** > > truly excellent > > Yes we try to sort that and get some cleaning. > > > > > grab > > > copy to paste buffer > > > collapse > > > delete > > > copy text > > > go behind > > > add halo > > > duplicate > > > embed into-> > > > PasteUpMorph > > > SystemWindow > > > resize > > > change color... > > > drop shadow-> > > > show shadow > > > shadow color... > > > shadow offset... > > > layout-> > > > no layout > > > proportional layout > > > table layout > > > change layout inset... > > > child layout-> > > > disable layout in tables > > > horizontal resizing-> > > > rigid > > > shrink wrap > > > space fill > > > vertical resizing-> > > > rigid > > > shrink wrap > > > space fill > > > table layout-> > > > reverse table cells > > > clip to cell size > > > rubber band cells > > > change cell inset... > > > change min cell size... > > > change max cell size... > > > list direction-> > > > ... > > > wrap direction-> > > > ... > > > cell positioning-> > > > ... > > > list centering-> > > > ... > > > wrap centering-> > > > ... > > > list spacing-> > > > ... > > > cell spacing-> > > > ... > > > provide clipping > > > submorphs > > ?? > > > > > inspect > > > explore > > > > > browse hierarchy > > ?? > > > > > save morph in file > > > attach to resource > > ?? > > > > > show actions > > > debug-> > > > inspect morph > > > inspect owner chain > > > inspect model > > > explore morph > > > browse morph class > > > browse model class > > > explore view hierarchy > > > call #tempCommand > > ?? > > > define #tempCommand > > ?? > > > > > open editing > > > edit label... > > > > > > Cheers, > > > Guille > > > _______________________________________________ > > > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 30, 2010

Re: [Pharo-project] Trip to Pharo land

by StÃ©phane Ducasse

Yes but in that case try 1.0 try 1.1 alpha like that you simply know if you software is running. Even in VW or Java you have to do that. because would you really spend time reading 20 pages of bug fixes? Stef On May 30, 2010, at 9:30 PM, Igor Stasenko wrote: > I think that Goran's case was an indication how sometimes hard to cope > up with latest & finest things. > So, Goran had issues with trunk, as well as with Pharo.. > And wasted a time by using old/obsolete, wrong things, because of lack > of information. > > Take into account that all of it happen to not someone just starting, > but with one, who being around for a while! > This gives you idea how hard it might be for newcomers. Scarce > resources, no docs, explanations, > installation instructions, roadmaps etc etc.. > > So, this is what we should to take care of. Including of bug fixes, of > course. :) > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 30, 2010

Re: [Pharo-project] Trip to Pharo land

by StÃ©phane Ducasse

so far none. :) Now it would be good to use the bug tracker to create a list of issues we closed. Lukas told me that this is easy. Stef > If there is a need for backporting important fixes to 1.0 I can do that during the sprint next Saturday. But I would need to know *which* fixes are the critical ones. > > Adrian > > On May 30, 2010, at 18:10 , StÃ©phane Ducasse wrote: > >>> I'd guess the important thing is to explain on the Pharo web site >>> that bug fixes are in the 1.1 and are not (always) retrofitted to 1.0 >> >> only showstoppers = severe bugs = that can put the system on his knees. >> But probably we should stay that: >> >> "In the current set of ressources only showstoppers or extremely severe bugs are retrofitted in >> old versions" >> >> Stef >> >>> >>> Stephan >> >> >> _______________________________________________ >> 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

May 30, 2010

Re: [Pharo-project] Rome/Athens notes

by StÃ©phane Ducasse

cool post Stef On May 30, 2010, at 8:53 PM, Igor Stasenko wrote: > On 30 May 2010 17:26, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Hi, >>> >>> i found rome API very close to OpenVG. >>> Still OpenVG is a bit superior :) >>> So, i'm using it as a guide to model/implement Rome interfaces. >> >> Excellent! >> >>> So, here is my thoughts (i also having a draft class skeleton for them): >> >> frankly consider that we are working on Rome because we need something >> to get access to Cairo/ whatever but we are newbie at the level. >> Now the good point for us is that we are smart newbies :) >> and ready to learn fast. >> >> So our first idea is >> - make it work (romePluginCanvas) >> - make all romeReferenceCanvas >> >> Get feedback, improve it improve it improve it >> as well as make all the code use it make all the code use it . >> >> So thanks for your brainstorming/ideas/wishes >> >> >>> Because, we could simply do: >>> >>> canvas fill: myPath with: myPaint >>> >>> instead of: >>> >>> canvas selectFill: myPaint. >>> canvas fill: myPath. >>> >>> Because you anyways can't draw a paths without paints, i don't see why >>> canvas should have a notion of 'current fill' or 'current paint'. >>> I think that with paint's encapsulation, its not necessary. >>> >>> >>> I'd like to hear your thoughts about it. >> >> No idea. Now at the back end level or "reference level" >> is there a value to separate? >> because like that you can do >> >>> canvas selectFill: myPaint. >>> canvas fill: myPath. >>> canvas fill: myPath.canvas fill: myPath.canvas fill: myPath.canvas fill: myPath.canvas fill: myPath.canvas fill: myPath.canvas fill: myPath. >> > > Right. I considered that too, before proposing ;) > Selecting a paint and then drawing multiple paths using it may look > like having some value. > > But the point is, that in practice you barely will use such feature. > > For instance, lets take a morph: > > Morph>>romeDrawOn: aCanvas > aCanvas > selectFill: self fillStyle; > selectPen: self borderStyle; > drawRectangle: self bounds > > Do you seen how you can reuse a previously selected paints here? I don't. > You can't reuse, because you don't know what was selected previously > (and querying it will cost you more cycles > than just selecting a right one). > > So, that's how you will use it in 99% of cases: > > select > fill > select > fill.. > > But not > > select > fill fill fill .. > > One more example. A Tiger demo, which i did in OpenVG binding. > A Tiger takes it roots from an SVG file, so it is right to say, that > it covers the use of SVG for drawings. > In SVG, each particular path it having own stroke/fill parameters. > There is no way how you can reuse a previously selected paints, > because each unique fragment having own settings, > and even if a whole scene (as big as Tiger) using similar paints > multiple times, you still can't reuse them because you need to follow > the order of drawing (iterating over a collection of paths, but not a > collection of paints), otherwise you won't get what you expecting to > see. > > You can reuse paints by creating them, and then caching , so it won't > cost you a conversion, each time you using it. > (For instance you can convert a GradientFillStyle to appropriate paint > object, and cache it somewhere). > But selecting the paint costs nothing, and buys nothing in terms of > speed (at least in my implementation, and i suspect in every other ;) > ). > > I think that 'selection' and 'binding' mechanism in those APIs serve > only one purpose: to minimize the number of arguments > for function calls and as a workaround of having no OO. > But in smalltalk world, we having objects, which can represent any > kind of our domain objects (paths, paints etc), > and so, from OO perspective binding/selecting looks like a useless thing. > > A big downside of such selection mechanism can be illustrated by taking OpenGL. > It is cool, when you having one window, one context, one texture and > one pencil to rule them all. > But in practice, you often need more than one canvas, window, texture etc. > And this is where such 'selection' mechanism starts standing in your way. > For instance, if you working with multiple GL contexts in squeak, the > only way how to ensure that you _always_ > working with right context is to prepend each api call with: > makeCurrent(myContextHandle). > by literally turning every gl function like: func(a, b, c) into > func(context, a, b, c) > otherwise, you can't ensure a correct behavior, when you working with > multiple contexts in multiple processes, > having high chances being interrupted by each other. > > This is where passing an extra argument(s) is preferable, because it > tells directly, with what object you wanna work with and so it > minimizes the chances to make a mess. :) > >> >> Stef >> >> >>> Paints: >>> >>> Paint is an object, which when applied to path, renders(draws) the >>> path using paint's unique properties. >>> >>> I defined two methods in paint's base class: >>> >>> fillPath: aPath on: aCanvas >>> >>> self subclassResponsibility >>> >>> strokePath: aPath on: aCanvas >>> >>> self subclassResponsibility >>> >>> So, to draw a path, one should use a concrete paint to either fill it >>> or stroke it (or both, if you want, but its handled by canvas and >>> still will end up with separate fill & stroke requests to paint). >>> >>> I started from a quite basic things: >>> >>> NullPaint >>> Paint which does not performs any drawing. >>> Applying this paint to any path won't lead to any >>> changes/processing. A simple OO approach to define 'nothing' :) >>> >>> SolidColorPaint >>> instanceVariableNames: 'color' >>> >>> Paint with solid color. Most trivial thing which can be done :) >>> >>> RomePen >>> instanceVariableNames: 'paint capStyle joinStyle width dash' >>> >>> A 'pen' paint is just encapsulating a set of properties, which is used >>> for stroke. >>> It is using another paint, which should handle the fills (in 'paint' >>> ivar), while various stroke properties should be handled by itself. >>> Filling with pen, will be the same as filling with its paint. While >>> doing a stoke is different (includes path processing, given the values >>> of pen's properties etc etc). >>> I'm not sure with this part. Maybe stroke properties would be better >>> to leave in canvas? Both OpenVG and Rome seems like following this >>> road, >>> but i don't quite like that stroke properties is global for canvas and >>> lacking a proper encapsulation. >>> >>> CompositePaint >>> Quite dumb thing. Holds a list of paints. When asked to fill or >>> stroke the path, applies paints from own list. >>> >>> GradientPaint (abstract) >>> LinearGradient >>> RadialGradient >>> etc.. >>> paints which will use gradients for fills. Nothing fancy :) >>> >>> >>> Canvas protocol: >>> >>> selectFill: anObject >>> >>> fill := anObject asRomePaintOn: self >>> >>> - selects a paint which will be used for fills. >>> >>> selectPen: anObject >>> >>> pen := anObject asRomePaintOn: self >>> >>> - selects a paint which will be used for stokes. >>> >>> >>> stroke: anObject >>> | path | >>> path := anObject asRomePathOn: self. >>> >>> fill strokePath: path on: self. >>> >>> - stroke a path using currently selected 'pen' paint >>> >>> fill: anObject >>> | path | >>> path := anObject asRomePathOn: self. >>> >>> fill fillPath: path on: self. >>> >>> - fill path using paint for fills >>> >>> >>> fillAndStroke: anObject >>> | path | >>> path := anObject asRomePathOn: self. >>> >>> fill fillPath: path on: self. >>> pen strokePath: path on: self >>> >>> - fill and stroke path. >>> >>> And from that point, i wonder, do we need to have a paint's selection >>> mechanisms at all? >>> >>> Because, we could simply do: >>> >>> canvas fill: myPath with: myPaint >>> >>> instead of: >>> >>> canvas selectFill: myPaint. >>> canvas fill: myPath. >>> >>> Because you anyways can't draw a paths without paints, i don't see why >>> canvas should have a notion of 'current fill' or 'current paint'. >>> I think that with paint's encapsulation, its not necessary. >>> >>> >>> I'd like to hear your thoughts about it. >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 30, 2010

Re: [Pharo-project] SUnit Time out

by StÃ©phane Ducasse

On May 30, 2010, at 8:52 PM, Chris Muller wrote: > (Copying squeak-dev too). > > I'm not sold on the whole test timeout thing. When I run tests, I > want to know the answer to the question, "is the software working?" > > Putting a timeout on tests trades a slower, but definitive, "yes" or > "no" for a supposedly-faster "maybe". But is getting a "maybe" back > really faster? I've just incurred the cost of running a test suite, > but left without my answer. I get a "maybe", what am I supposed to do > next? Find a faster machine? Hack into the code to fiddle with a > timeout pragma? That's not faster.. Thanks this is a really good point. > But, the reason given for the change was not for running tests > interactively (the 99% case), rather, all tests form the beginning of > time are now saddled with a timeout for the 1% case: > > "The purpose of the timeout is to catch issues like infinite loops, > unexpected user input etc. in automated test environments." > > If tests are supposed to be quick (and deterministic) anyway, wouldn't > an infinite loop or user-input be caught the first time the test was > run (interactively)? Seriously, when you make software changes, we > run the tests interactively first, and then the purpose of night-time > automated test environment is to catch regressions on the merged > code.. Yes this is what I was also implying in my previous mail. If we have a test server this does not really help to have a time out and I wonder the case of infinite loop because this may be really rare. > In that case, the high-level test-controller which spits out the > results could and should be responsible for handling "unexpected user > input" and/or putting in a timeout, not each and every last test > method.. > > IMO, we want short tests, so let's just write them to be short. If > they're too long, then the encouragement to shorten them comes from > our own impatience of running them interactively. Running them in > batch at night requires no patience, because we're sleeping, and > besides, the batch processor should take responsibility for handling > those rare scenarios at a higher-level.. I agree. Thanks for sharing your thoughts. So the issue is done. :) > > Regards, > Chris > > > On Sat, May 29, 2010 at 2:53 AM, stephane ducasse > <stephane.ducasse(a)free.fr> wrote: >> Hi guys >> >> in Squeak andreas introduced the idea of test time out >> Do you think that this is interesting? >> >> Stef >> >> SUnit >> ----- >> All test cases now have an associated timeout after which the test is considered failed. The purpose of the timeout is to catch issues like infinite loops, unexpected user input etc. in automated test environments. Timeouts can be set on an individual test basis using the <timeout: seconds> tag or for an entire test case by implementing the #defaultTimeout method. >> _______________________________________________ >> 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

May 30, 2010

Re: [Pharo-project] how to add an entry in World Menu (was: CommandShell)

by Alain Plantec

Le 30/05/2010 21:30, laurent laffont a Ã©crit : > On Sun, May 30, 2010 at 1:51 PM, Alain Plantec <alain.plantec(a)free.fr > <mailto:alain.plantec@free.fr>> wrote: > > > http://book.pharo-project.org/book/TipsAndTricks/DeclaringSetting > Alain > > Thanks Alain. Do you know how I can browse all methods defining > systemsettings pragma ? browse all senders to #systemsettings. alternatively, open the settingBrowser and just double click on an item to browse it or the nearest parent with <systemsettings> (or popup the context menu on an item and choose "browse"). Feel free to ask for more informations, It will be the occasion to enrich this doc. Cheers Alain > > Cheers. > > Laurent Laffont > > http://pharocasts.blogspot.com/ > http://magaloma.blogspot.com/ > > Le 28/05/2010 07:33, Alain Plantec a Ã©crit : > > Le 27/05/2010 23:02, laurent laffont a Ã©crit : > > See > http://book.pharo-project.org/book/TipsAndTricks/WorldMenuRegistration > > yep! > > > Can someone write a little example on how to add Settings > ? I need this :) > > ok, I will. > Cheers > Alain > > > Cheers, > > Laurent > > On Thu, May 27, 2010 at 9:56 PM, laurent laffont > <laurent.laffont(a)gmail.com > <mailto:laurent.laffont@gmail.com> > <mailto:laurent.laffont@gmail.com > <mailto:laurent.laffont@gmail.com>>> wrote: > > On Thu, May 27, 2010 at 4:45 PM, David T. Lewis > <lewis(a)mail.msen.com <mailto:lewis@mail.msen.com> > <mailto:lewis@mail.msen.com <mailto:lewis@mail.msen.com>>> > wrote: > > On Thu, May 27, 2010 at 09:04:37AM +0200, laurent > laffont wrote: > > Hi Dave, > > > > I've managed to make it running in Pharo (remove all > isMorphic ifFalse ... > > stuff, change menu registration, a little work is needed to > adapt to Pharo > > new settings system). It works (I can publish a package when > back at home). > > > > Now I suppose you want to keep it running on Squeak, I don't > know how to > > handle differences on world menu and preferences. > > > > For the MVC part, is there some value in keeping it ? > > Hi Laurent, > > Thanks, I would be very interested in seeing your > changes, > especially the > menu registration fixes. > > > For menu registration, add > > CommandShell class>>#menuCommandOn: aBuilder > <worldMenu> > (aBuilder item: #'Command Shell') > parent: #Tools; > action:[self open]; > help: 'Smalltalk simulation of a Unix command shell '. > > and comment / remove Preferences in CommandShell > class>>#initialize. > > > Laurent > > > I do want to keep this working on MVC and on other > Squeak > images. What > I really need to do is repackage CommandShell and > OSProcess so > that > everything is not all in two giant packages. I > originally > "packaged" > these many years ago before Squeak had real > packages and > Monticello, > so I basically separated things into two completely > separate > SAR packages > that could be independently maintained (even though > CommandShell and > OSProcess were intended to work together). That was > quite a > project > at the time, but it is badly out of date now, so I > need to go back > and make this stuff work properly with Metacello > configurations. > > Dave > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@lists.gforge.inria.fr> > <mailto:Pharo-project@lists.gforge.inria.fr > <mailto:Pharo-project@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 > <mailto:Pharo-project@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 > <mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

May 30, 2010