- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Trip to Pharo land

by Henrik Sperre Johansen

On 30.05.2010 23:17, StÃ©phane Ducasse wrote: >> 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. Sort of like 4.0 and 4.1, although the gap is a bit smaller :) Cheers, Henry

May 30, 2010

Re: [Pharo-project] Rome/Athens notes

by Igor Stasenko

On 31 May 2010 00:20, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On May 30, 2010, at 10:57 PM, Igor Stasenko wrote: > >> 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 :) > > I do not think so. > Good posts are read more that you believe. Now in mailing-list the numbers of mails > cut the knowledge after a point. > But i posted here mainly to discuss these ideas. If we don't have a discussion, then we won't have a resolution, and its not matters how good post is or not, because a true value of any idea can be determined by considering all alternatives and discussing them. But maybe i'm a bit too hurry , because you mentioned that first things which needs to be done is to make current stuff working. The other thing is, that i am writing GL stuff from scratch (mostly), so i tend to pay more attention on design first, and then on implementation. >> 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 :) > > I do not know. Do the other frameworks outside smalltalk use something else > than paths? Yes. In 3D you have meshes, NURB surfaces , constructive-solid geometry and tons of other stuff. > I think that we should start > Â Â Â Â - making rome working. We are nearly there > Â Â Â Â - test it > Â Â Â Â - refactor it. > Â Â Â Â - I would like to see the canvas for morphic30 too. > Â Â Â Â - refactor the system to use that. > stef > Yes. Yes. Yes :) > > _______________________________________________ > 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] Rome/Athens notes

by StÃ©phane Ducasse

On May 30, 2010, at 10:57 PM, Igor Stasenko wrote: > 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 :) I do not think so. Good posts are read more that you believe. Now in mailing-list the numbers of mails cut the knowledge after a point. > 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 :) I do not know. Do the other frameworks outside smalltalk use something else than paths? I think that we should start - making rome working. We are nearly there - test it - refactor it. - I would like to see the canvas for morphic30 too. - refactor the system to use that. stef

May 30, 2010

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