February 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Announcements for Pharo?

by StÃ©phane Ducasse

On Feb 26, 2009, at 4:45 PM, Michael Rueger wrote: > Keith Hodges wrote: > >>> We will include it. >>> >>> >>> Thanks, we will try with Pharo then. >>> Lautaro FernÃ¡ndez >> I am confused. Surely you would expect a loadable package to remain >> loadable and only be called up if needed? > > Although I'm normally the first to argue against including more stuff Yeap we know > > into the core image I think Announcements need to be part of core. > This will allow us to have *one* mechanism for signaling/subscribing > and > can over time replace the different variants that are now used and > provide a solid base for anyone needing such a mechanism. > In the experimental forks I have worked on having Announcements > available made all the difference. > > Michael > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 26, 2009

Re: [Pharo-project] Aaah, the pain or ParagraphEditor refactoring ; -)

by StÃ©phane Ducasse

On Feb 26, 2009, at 4:51 PM, Lukas Renggli wrote: >> Just for information, couldn't SafarÃ a be introduced here ? > > SafarÃ is not useable yet. It is too slow :-( So is it killed by over-engineering or over flexibility? Stef > > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 26, 2009

[Pharo-project] Fwd: Some ides for Refactoring and IDEs...

by StÃ©phane Ducasse

> > > Hi > > > I was in the PhD defense > PROGRAMMER FRIENDLY REFACTORING TOOLS of Emerson Murphy-Hill. > It is worth browsing because we can learn how to improve our IDE. > For example he shows support for selecting code to apply refacoring > - selecting expression automatically to perform extract and helping > you to avoid parentheses. > - he also shows the list of possible refactorings on the side for a > method. > > The stench blossom is cool is show on real time smells. > > http://multiview.cs.pdx.edu/refactoring/ > > > He mentioned > Dustin Cambell and Mark Miller. Designing refactoring tools for > develop- > ers. In Danny Dig and Michael Cebulla, editors, Proceedings of the > 2nd > Workshop on Refactoring Tools, 2008. > > but the result looks a bit clumsy. > > Stef > > > >

Feb. 26, 2009

Re: [Pharo-project] Announcements for Pharo?

by Norbert Hartl

On Thu, 2009-02-26 at 07:45 -0800, Michael Rueger wrote: > Keith Hodges wrote: > > >> We will include it. > >> > >> > >> Thanks, we will try with Pharo then. > >> Lautaro FernÃ¡ndez > > I am confused. Surely you would expect a loadable package to remain > > loadable and only be called up if needed? > > Although I'm normally the first to argue against including more stuff > into the core image I think Announcements need to be part of core. > This will allow us to have *one* mechanism for signaling/subscribing and > can over time replace the different variants that are now used and > provide a solid base for anyone needing such a mechanism. > In the experimental forks I have worked on having Announcements > available made all the difference. > Does that mean that the EventManager, package System-Object Events and the methods in Object will be replaced by that? If yes I'm all for it! Norbert

Feb. 26, 2009

Re: [Pharo-project] Announcements for Pharo?

by Janko MivÅ¡ek

Damien Cassou pravi: > Michael Rueger wrote: >> Although I'm normally the first to argue against including more stuff >> into the core image I think Announcements need to be part of core. > I have to disagree. The less we have the core, the easier it will be > to maintain it. However, Announcements may be included in the Pharo > distribution (currently named pharo-dev). I think we should discuss > that. I've added it to http://code.google.com/p/pharo/wiki/Packages Announcements will soon become as core as Morphic, actually even more, because they can replace the existing event mechanism in Morphic. VW guys actually did that in their GUI, so this is proven in practice. Therefore it is good for Announcements to become part of core, because it will enable so many things, which is the main goal of the core anyway: to contain a functionality useful as broadly as possible. So, make an exception, include Announcements in core, noone will regret that! Janko -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

Feb. 26, 2009

Re: [Pharo-project] Announcements for Pharo?

by Damien Cassou

On Thu, Feb 26, 2009 at 4:45 PM, Michael Rueger <m.rueger(a)acm.org> wrote: > Although I'm normally the first to argue against including more stuff > into the core image I think Announcements need to be part of core. I have to disagree. The less we have the core, the easier it will be to maintain it. However, Announcements may be included in the Pharo distribution (currently named pharo-dev). I think we should discuss that. I've added it to http://code.google.com/p/pharo/wiki/Packages -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 26, 2009

Re: [Pharo-project] Announcements for Pharo?

by Miguel Enrique CobÃ¡ MartÃnez

Michael Rueger wrote: > Keith Hodges wrote: > >>> We will include it. >>> >>> >>> Thanks, we will try with Pharo then. >>> Lautaro FernÃ¡ndez >> I am confused. Surely you would expect a loadable package to remain >> loadable and only be called up if needed? > > Although I'm normally the first to argue against including more stuff > into the core image I think Announcements need to be part of core. > This will allow us to have *one* mechanism for signaling/subscribing and > can over time replace the different variants that are now used and > provide a solid base for anyone needing such a mechanism. > In the experimental forks I have worked on having Announcements > available made all the difference. > +1 We need to standarize to only one implementation, if posible, adding the features needed from the others if neccesary. It could be that some features from other implementation could not be integrated because of architectural reason, but that will be discussed when the time arrives. Miguel CobÃ¡ > Michael > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 26, 2009

Re: [Pharo-project] Aaah, the pain or ParagraphEditor refactoring ; -)

by Lukas Renggli

> Just for information, couldn't SafarÃ a be introduced here ? SafarÃ is not useable yet. It is too slow :-( Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 26, 2009

Re: [Pharo-project] Announcements for Pharo?

by Michael Rueger

Keith Hodges wrote: >> We will include it. >> >> >> Thanks, we will try with Pharo then. >> Lautaro FernÃ¡ndez > I am confused. Surely you would expect a loadable package to remain > loadable and only be called up if needed? Although I'm normally the first to argue against including more stuff into the core image I think Announcements need to be part of core. This will allow us to have *one* mechanism for signaling/subscribing and can over time replace the different variants that are now used and provide a solid base for anyone needing such a mechanism. In the experimental forks I have worked on having Announcements available made all the difference. Michael

Feb. 26, 2009

Re: [Pharo-project] Aaah, the pain or ParagraphEditor refactoring ; -)

by CÃ©drick BÃ©ler

Just for information, couldn't SafarÃ a be introduced here ?

Feb. 26, 2009