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

Re: [Pharo-project] [Moose-dev] Roassal new algorithms

by Frank Shearar

On 19 April 2013 20:45, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 19 April 2013 20:39, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 19 April 2013 21:33, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>> Oh absolutely! >>> >>> My comment comes from trying to analyse the dependencies between >>> classes in my SIP stack [1]. What I found was that simply mapping >>> dependencies in a flat namespace (as Delphi has) resulted in a tangled >>> mess. >>> >> Oh.. SIP. RTP/RTCP been there , did that :) >> implementing it in C++ years ago. > > Good times! I just wish I could find the data I used: I took the d3 > sample and mucked around with it... and probably deleted it :/ Found it! So I hacked a Ruby script to crawl over the Delphi source files and find inter-unit dependencies. Then I (manually) grouped units into RTP, Transport, Location, Transaction, Platform, and so on. Finally I manually grouped those groups into even higher level groups: SIP, Media, and so on. You can see the drastic effect on bundling that this grouping via hierarchical naming has. frank > frank > >>> Then I added the unit name to the classes, so I had, say, >>> IdSipTransport.TIdSipTransport. That resulted in a slightly less >>> tangled mess: the strands started to bundle together. >>> >>> Once I added a third layer - I grouped things into high level concepts >>> like Transport, Transaction, Dialog, and so on - the strands bundled >>> sufficiently tightly to actually be useful. >>> >>> I suspect the same will hold true for Pharo (and Squeak). So if you >>> turn names like "Debugger class in the Tools-Debugger package" into >>> Tools.Debugger.Debugger you'd be well on your way. >>> >>> frank >>> >>> [1] https://github.com/frankshearar/SipStack >>> >>> On 19 April 2013 19:57, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>>> This is a very cool visualization. There is no reason why we cannot do it in Pharo >>>> >>>> Alexandre >>>> >>>> >>>> On Apr 19, 2013, at 10:49 AM, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>>> >>>>> I've played with these before [1]. They work best with hierarchical names. In other words, in a flat namespace (say, showing class dependencies with just the class name) you end up with a very messy diagram. >>>>> >>>>> Let's assume you use "." as the name token separator. If you prefixed the names with their packages, say Tools-Debugger.Debugger, you'd get a better graph, where the bundles would be tighter. If you made things more hierarchical still, say with names like Tools.Debugger.Debugger, things would look even better. >>>>> >>>>> The deeper the naming hierarchy the fewer fat bundles you get in the image. >>>>> >>>>> frank >>>>> >>>>> [1] http://mbostock.github.io/d3/talk/20111116/bundle.html >>>>> >>>>> On 19 April 2013 16:37, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>>>> Let's have this discussion in the Pharo list. >>>>> >>>>> Alexandre >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: Alexandre Bergel <alexandre.bergel(a)me.com> >>>>>> Subject: [Moose-dev] Re: Roassal new algorithms >>>>>> Date: April 19, 2013 11:25:31 AM GMT-04:00 >>>>>> To: Moose-related development <moose-dev(a)iam.unibe.ch> >>>>>> Reply-To: Moose-related development <moose-dev(a)iam.unibe.ch> >>>>>> >>>>>>> There are more than simply linear, quadratic and cubic Bezier curves. In fact, as you can have as many control points as you wish, you can have a Bezier curve of any order. >>>>>> >>>>>> Ok >>>>>> >>>>>>> But what I was calling RadialBezierCurve was a kind of strategy, I mean I have an abstract class which knows how to compute a curve, but I still have to choose my control points so I was thinking to create different subclasses whose role is to know what are their control points : >>>>>>> >>>>>>> - The radial one choose its control points within the same radius as its source and its target. >>>>>> >>>>>> Ah ok >>>>>> >>>>>>> I wanted to create an ortoVertical and an ortoHorizontal whose control points would have been computed differently, so that we could use Bezier curve for regular tree too. >>>>>> >>>>>> It would be cool to have hierarchical bundles edges in Roassal. >>>>>> A screenshot of what it looks like: >>>>>> <Screen Shot 2013-04-19 at 11.24.59 AM.png> >>>>>> >>>>>> The technical description: http://www.win.tue.nl/~dholten/papers/bundles_infovis.pdf >>>>>> >>>>>> Alexandre >>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev(a)iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >>

April 19, 2013

Re: [Pharo-project] How to get the AST Node for a Context

by Marcus Denker

On Apr 17, 2013, at 5:51 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > We implemented this today: > > #sourceNode for MethodContext. It returns the AST node of context, as part of the whole AST of the method. > today we added: [ 1 + 2 ] sourceNode. ==> RBBlockNode([ 1 + 2 ]) (Object>>#halt) sourceNodeForPC: 22. ==> RBMessageNode(Halt now) And (of course): |block blockNodeViaContext blockNodeViaClosure | block := [blockNodeViaContext := thisContext sourceNode]. block value. blockNodeViaClosure := block sourceNode. blockNodeViaContext == blockNodeViaClosure ==> true Marcus

April 19, 2013

Re: [Pharo-project] files.pharo.org: Moving to new server

by Marcus Denker

On Apr 19, 2013, at 10:04 PM, phil(a)highoctane.be wrote: > While you guys are at it, why not create: > > http://get.pharo.org This already exists? Marcus

April 19, 2013

Re: [Pharo-project] files.pharo.org: Moving to new server

by phil＠highoctane.be

While you guys are at it, why not create: http://get.pharo.org It's like for vlc for example 2013/4/19 Marcus Denker <marcus.denker(a)inria.fr> > > On Apr 19, 2013, at 5:54 PM, Ben Coman <btc(a)openInWorld.com> wrote: > > > Marcus Denker wrote: > >> 3) enable CDN for the static files. (NEXT WEEK) > >> > >> > >> Marcus and Camillo > >> > > > > I have seen mentioned that SmalltalkHub is faster than previous > repositories, but I also wonder... is there any consideration (or value) to > hooking SmalltalkHub up with a CDN ? All uploaded mcz files are effectively > static content. > > > we where thinking about that, too. > > We should try... > > Marcus > > >

April 19, 2013

Re: [Pharo-project] [Moose-dev] Roassal new algorithms

by Frank Shearar

On 19 April 2013 20:39, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 19 April 2013 21:33, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> Oh absolutely! >> >> My comment comes from trying to analyse the dependencies between >> classes in my SIP stack [1]. What I found was that simply mapping >> dependencies in a flat namespace (as Delphi has) resulted in a tangled >> mess. >> > Oh.. SIP. RTP/RTCP been there , did that :) > implementing it in C++ years ago. Good times! I just wish I could find the data I used: I took the d3 sample and mucked around with it... and probably deleted it :/ frank >> Then I added the unit name to the classes, so I had, say, >> IdSipTransport.TIdSipTransport. That resulted in a slightly less >> tangled mess: the strands started to bundle together. >> >> Once I added a third layer - I grouped things into high level concepts >> like Transport, Transaction, Dialog, and so on - the strands bundled >> sufficiently tightly to actually be useful. >> >> I suspect the same will hold true for Pharo (and Squeak). So if you >> turn names like "Debugger class in the Tools-Debugger package" into >> Tools.Debugger.Debugger you'd be well on your way. >> >> frank >> >> [1] https://github.com/frankshearar/SipStack >> >> On 19 April 2013 19:57, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> This is a very cool visualization. There is no reason why we cannot do it in Pharo >>> >>> Alexandre >>> >>> >>> On Apr 19, 2013, at 10:49 AM, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>> >>>> I've played with these before [1]. They work best with hierarchical names. In other words, in a flat namespace (say, showing class dependencies with just the class name) you end up with a very messy diagram. >>>> >>>> Let's assume you use "." as the name token separator. If you prefixed the names with their packages, say Tools-Debugger.Debugger, you'd get a better graph, where the bundles would be tighter. If you made things more hierarchical still, say with names like Tools.Debugger.Debugger, things would look even better. >>>> >>>> The deeper the naming hierarchy the fewer fat bundles you get in the image. >>>> >>>> frank >>>> >>>> [1] http://mbostock.github.io/d3/talk/20111116/bundle.html >>>> >>>> On 19 April 2013 16:37, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>>> Let's have this discussion in the Pharo list. >>>> >>>> Alexandre >>>> >>>> Begin forwarded message: >>>> >>>>> From: Alexandre Bergel <alexandre.bergel(a)me.com> >>>>> Subject: [Moose-dev] Re: Roassal new algorithms >>>>> Date: April 19, 2013 11:25:31 AM GMT-04:00 >>>>> To: Moose-related development <moose-dev(a)iam.unibe.ch> >>>>> Reply-To: Moose-related development <moose-dev(a)iam.unibe.ch> >>>>> >>>>>> There are more than simply linear, quadratic and cubic Bezier curves. In fact, as you can have as many control points as you wish, you can have a Bezier curve of any order. >>>>> >>>>> Ok >>>>> >>>>>> But what I was calling RadialBezierCurve was a kind of strategy, I mean I have an abstract class which knows how to compute a curve, but I still have to choose my control points so I was thinking to create different subclasses whose role is to know what are their control points : >>>>>> >>>>>> - The radial one choose its control points within the same radius as its source and its target. >>>>> >>>>> Ah ok >>>>> >>>>>> I wanted to create an ortoVertical and an ortoHorizontal whose control points would have been computed differently, so that we could use Bezier curve for regular tree too. >>>>> >>>>> It would be cool to have hierarchical bundles edges in Roassal. >>>>> A screenshot of what it looks like: >>>>> <Screen Shot 2013-04-19 at 11.24.59 AM.png> >>>>> >>>>> The technical description: http://www.win.tue.nl/~dholten/papers/bundles_infovis.pdf >>>>> >>>>> Alexandre >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev(a)iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >> > > > > -- > Best regards, > Igor Stasenko. >

April 19, 2013

Re: [Pharo-project] files.pharo.org: Moving to new server

by Marcus Denker

On Apr 19, 2013, at 11:21 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > Next: DNS Server (after Lunch). > > This might impact the URL forwards > ci.pharo.org > pharo.org > > as forwarding is done differently on the new setup. > We decided to do that next weekâ¦ mostly because URL forwarding like is was done at namecheap is more complicated with the new DNS provider (read: they don't do that, as it is not DNS but needs a server). Instead we managed to the whole update cycle to work again for 3.0 using the new server (which was more complex than imaginableâ¦). TODO for CND -> setup server for forwarding DNS entries to URLs -> Switch DNS Provider -> enable caching CDN for updating -> fix 2.0 like we did 3.0 today -> fine-tune changed update process Marcus

April 19, 2013

Re: [Pharo-project] [Moose-dev] Roassal new algorithms

by Igor Stasenko

On 19 April 2013 21:33, Frank Shearar <frank.shearar(a)gmail.com> wrote: > Oh absolutely! > > My comment comes from trying to analyse the dependencies between > classes in my SIP stack [1]. What I found was that simply mapping > dependencies in a flat namespace (as Delphi has) resulted in a tangled > mess. > Oh.. SIP. RTP/RTCP been there , did that :) implementing it in C++ years ago. > Then I added the unit name to the classes, so I had, say, > IdSipTransport.TIdSipTransport. That resulted in a slightly less > tangled mess: the strands started to bundle together. > > Once I added a third layer - I grouped things into high level concepts > like Transport, Transaction, Dialog, and so on - the strands bundled > sufficiently tightly to actually be useful. > > I suspect the same will hold true for Pharo (and Squeak). So if you > turn names like "Debugger class in the Tools-Debugger package" into > Tools.Debugger.Debugger you'd be well on your way. > > frank > > [1] https://github.com/frankshearar/SipStack > > On 19 April 2013 19:57, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> This is a very cool visualization. There is no reason why we cannot do it in Pharo >> >> Alexandre >> >> >> On Apr 19, 2013, at 10:49 AM, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> >>> I've played with these before [1]. They work best with hierarchical names. In other words, in a flat namespace (say, showing class dependencies with just the class name) you end up with a very messy diagram. >>> >>> Let's assume you use "." as the name token separator. If you prefixed the names with their packages, say Tools-Debugger.Debugger, you'd get a better graph, where the bundles would be tighter. If you made things more hierarchical still, say with names like Tools.Debugger.Debugger, things would look even better. >>> >>> The deeper the naming hierarchy the fewer fat bundles you get in the image. >>> >>> frank >>> >>> [1] http://mbostock.github.io/d3/talk/20111116/bundle.html >>> >>> On 19 April 2013 16:37, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> Let's have this discussion in the Pharo list. >>> >>> Alexandre >>> >>> Begin forwarded message: >>> >>>> From: Alexandre Bergel <alexandre.bergel(a)me.com> >>>> Subject: [Moose-dev] Re: Roassal new algorithms >>>> Date: April 19, 2013 11:25:31 AM GMT-04:00 >>>> To: Moose-related development <moose-dev(a)iam.unibe.ch> >>>> Reply-To: Moose-related development <moose-dev(a)iam.unibe.ch> >>>> >>>>> There are more than simply linear, quadratic and cubic Bezier curves. In fact, as you can have as many control points as you wish, you can have a Bezier curve of any order. >>>> >>>> Ok >>>> >>>>> But what I was calling RadialBezierCurve was a kind of strategy, I mean I have an abstract class which knows how to compute a curve, but I still have to choose my control points so I was thinking to create different subclasses whose role is to know what are their control points : >>>>> >>>>> - The radial one choose its control points within the same radius as its source and its target. >>>> >>>> Ah ok >>>> >>>>> I wanted to create an ortoVertical and an ortoHorizontal whose control points would have been computed differently, so that we could use Bezier curve for regular tree too. >>>> >>>> It would be cool to have hierarchical bundles edges in Roassal. >>>> A screenshot of what it looks like: >>>> <Screen Shot 2013-04-19 at 11.24.59 AM.png> >>>> >>>> The technical description: http://www.win.tue.nl/~dholten/papers/bundles_infovis.pdf >>>> >>>> Alexandre >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > -- Best regards, Igor Stasenko.

April 19, 2013

Re: [Pharo-project] [Moose-dev] Roassal new algorithms

by Frank Shearar

Oh absolutely! My comment comes from trying to analyse the dependencies between classes in my SIP stack [1]. What I found was that simply mapping dependencies in a flat namespace (as Delphi has) resulted in a tangled mess. Then I added the unit name to the classes, so I had, say, IdSipTransport.TIdSipTransport. That resulted in a slightly less tangled mess: the strands started to bundle together. Once I added a third layer - I grouped things into high level concepts like Transport, Transaction, Dialog, and so on - the strands bundled sufficiently tightly to actually be useful. I suspect the same will hold true for Pharo (and Squeak). So if you turn names like "Debugger class in the Tools-Debugger package" into Tools.Debugger.Debugger you'd be well on your way. frank [1] https://github.com/frankshearar/SipStack On 19 April 2013 19:57, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > This is a very cool visualization. There is no reason why we cannot do it in Pharo > > Alexandre > > > On Apr 19, 2013, at 10:49 AM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> I've played with these before [1]. They work best with hierarchical names. In other words, in a flat namespace (say, showing class dependencies with just the class name) you end up with a very messy diagram. >> >> Let's assume you use "." as the name token separator. If you prefixed the names with their packages, say Tools-Debugger.Debugger, you'd get a better graph, where the bundles would be tighter. If you made things more hierarchical still, say with names like Tools.Debugger.Debugger, things would look even better. >> >> The deeper the naming hierarchy the fewer fat bundles you get in the image. >> >> frank >> >> [1] http://mbostock.github.io/d3/talk/20111116/bundle.html >> >> On 19 April 2013 16:37, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Let's have this discussion in the Pharo list. >> >> Alexandre >> >> Begin forwarded message: >> >>> From: Alexandre Bergel <alexandre.bergel(a)me.com> >>> Subject: [Moose-dev] Re: Roassal new algorithms >>> Date: April 19, 2013 11:25:31 AM GMT-04:00 >>> To: Moose-related development <moose-dev(a)iam.unibe.ch> >>> Reply-To: Moose-related development <moose-dev(a)iam.unibe.ch> >>> >>>> There are more than simply linear, quadratic and cubic Bezier curves. In fact, as you can have as many control points as you wish, you can have a Bezier curve of any order. >>> >>> Ok >>> >>>> But what I was calling RadialBezierCurve was a kind of strategy, I mean I have an abstract class which knows how to compute a curve, but I still have to choose my control points so I was thinking to create different subclasses whose role is to know what are their control points : >>>> >>>> - The radial one choose its control points within the same radius as its source and its target. >>> >>> Ah ok >>> >>>> I wanted to create an ortoVertical and an ortoHorizontal whose control points would have been computed differently, so that we could use Bezier curve for regular tree too. >>> >>> It would be cool to have hierarchical bundles edges in Roassal. >>> A screenshot of what it looks like: >>> <Screen Shot 2013-04-19 at 11.24.59 AM.png> >>> >>> The technical description: http://www.win.tue.nl/~dholten/papers/bundles_infovis.pdf >>> >>> Alexandre >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

April 19, 2013

[Pharo-project] Any wishes for Roassal?

by Alexandre Bergel

Hi! Roassal 2.0 is on the way. We would like to make sure everybody find this release attractive. We are wondering whether you have some particular requirements you would like us to address or some bugs you would like to see fixed. Feel free to speak up! Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 19, 2013

Re: [Pharo-project] [Moose-dev] Roassal new algorithms

by Alexandre Bergel

This is a very cool visualization. There is no reason why we cannot do it in Pharo Alexandre On Apr 19, 2013, at 10:49 AM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > I've played with these before [1]. They work best with hierarchical names. In other words, in a flat namespace (say, showing class dependencies with just the class name) you end up with a very messy diagram. > > Let's assume you use "." as the name token separator. If you prefixed the names with their packages, say Tools-Debugger.Debugger, you'd get a better graph, where the bundles would be tighter. If you made things more hierarchical still, say with names like Tools.Debugger.Debugger, things would look even better. > > The deeper the naming hierarchy the fewer fat bundles you get in the image. > > frank > > [1] http://mbostock.github.io/d3/talk/20111116/bundle.html > > On 19 April 2013 16:37, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Let's have this discussion in the Pharo list. > > Alexandre > > Begin forwarded message: > >> From: Alexandre Bergel <alexandre.bergel(a)me.com> >> Subject: [Moose-dev] Re: Roassal new algorithms >> Date: April 19, 2013 11:25:31 AM GMT-04:00 >> To: Moose-related development <moose-dev(a)iam.unibe.ch> >> Reply-To: Moose-related development <moose-dev(a)iam.unibe.ch> >> >>> There are more than simply linear, quadratic and cubic Bezier curves. In fact, as you can have as many control points as you wish, you can have a Bezier curve of any order. >> >> Ok >> >>> But what I was calling RadialBezierCurve was a kind of strategy, I mean I have an abstract class which knows how to compute a curve, but I still have to choose my control points so I was thinking to create different subclasses whose role is to know what are their control points : >>> >>> - The radial one choose its control points within the same radius as its source and its target. >> >> Ah ok >> >>> I wanted to create an ortoVertical and an ortoHorizontal whose control points would have been computed differently, so that we could use Bezier curve for regular tree too. >> >> It would be cool to have hierarchical bundles edges in Roassal. >> A screenshot of what it looks like: >> <Screen Shot 2013-04-19 at 11.24.59 AM.png> >> >> The technical description: http://www.win.tue.nl/~dholten/papers/bundles_infovis.pdf >> >> Alexandre >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 19, 2013