- Pharo-dev - lists.pharo.org

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

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

by laurent laffont

On Sun, May 30, 2010 at 1:51 PM, Alain Plantec <alain.plantec(a)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 ? 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>> wrote: >>> >>> On Thu, May 27, 2010 at 4:45 PM, David T. Lewis >>> <lewis(a)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> >>> >>> 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 Igor Stasenko

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.

May 30, 2010

Re: [Pharo-project] Rome/Athens notes

by Igor Stasenko

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.

May 30, 2010

Re: [Pharo-project] SUnit Time out

by Chris Muller

(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.. 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.. 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.. 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 >

May 30, 2010

Re: [Pharo-project] Trip to Pharo land

by Adrian Lienhard

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

May 30, 2010

[Pharo-project] List of pending items for 1.1

by StÃ©phane Ducasse

Hi all I did a fast list of items it would make sense to close for 1.1: Can you help us? I'm going over the issues and sort them - FFI/Alien? - http://code.google.com/p/pharo/issues/detail?id=2481 Issue 2481: Fix code gen infinite recursion - Issue 2446: Method lookup bug when evaluating code in a ParagraphEditor. http://code.google.com/p/pharo/issues/detail?id=2446 - Issue 2436: Compiler outofScopeNotification - Issue 2470: runSimulated behaviour http://code.google.com/p/pharo/issues/detail?id=2470 - Issue 1450: Displaying block content in inspector, debugger Stef

May 30, 2010

[Pharo-project] [update 1.1] #11379

by StÃ©phane Ducasse

11379 ----- - Issue 1832: remove unnecessary halt or convert them into error Now as part of the integration process I will do a little Compiler recompileAll to see if we catch some problems with source. Stef

May 30, 2010