- Pharo-dev - lists.pharo.org

[Pharo-project] plugin in Nautilus

by Alexandre Bergel

Hi! Is there a documentation on how to create a plugin for Nautilus? I would like to create a command 'Hide all packages' in the Package column of Nautilus. Any hint on how to do this? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 19, 2013

Re: [Pharo-project] plugin in Nautilus

by Benjamin

Totally remove the list or just empty it ? For documentation http://rmod.lille.inria.fr/web/pier/software/Tools-Improvement/NautilusDocu… Section1.4 How to ... Ben On Apr 20, 2013, at 12:24 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > Is there a documentation on how to create a plugin for Nautilus? > > I would like to create a command 'Hide all packages' in the Package column of Nautilus. Any hint on how to do this? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

April 19, 2013

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

by phil＠highoctane.be

perfect. 2013/4/19 Marcus Denker <marcus.denker(a)inria.fr> > > 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] [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