- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN] MVC removal step two harvested

by Norbert Hartl

On Tue, 2008-06-17 at 13:35 +0200, StÃ©phane Ducasse wrote: > Hi all > > I harvested the changes proposed by alain for the removal of MVC. > Please test pharo since it was a large change. > tests run as expected. There is one obsolete class left which is referenced by MvcTextEditor. That sounds like it is to be removed anyway ;) Otherwise a AppRegistry removeObsolete will do. Norbert

June 17, 2008

[Pharo-project] [ANN] MVC removal step two harvested

by StÃ©phane Ducasse

Hi all I harvested the changes proposed by alain for the removal of MVC. Please test pharo since it was a large change. stef

June 17, 2008

[Pharo-project] Fwd: [Seaside] Timespan bug

by StÃ©phane Ducasse

Begin forwarded message: > From: "David T. Lewis" <lewis(a)mail.msen.com> > Date: June 17, 2008 2:50:58 AM CEDT > To: Seaside - general discussion <seaside(a)lists.squeakfoundation.org> > Subject: Re: [Seaside] Timespan bug > Reply-To: Seaside - general discussion <seaside(a)lists.squeakfoundation.org > > > > On Mon, Jun 16, 2008 at 01:50:43PM +1000, Steve Aldred wrote: >> Sorry for posting this here but I don't use Squeak itself and hence >> aren't on the main squeak list. >> >> As a VW Seaside user I do use Squeak extensions. There is a bug in >> Timespan as shown below: >> >> (Year starting: (DateAndTime year: 2008 month: 1 day:1)) previous >> >> The result should be 2007 but it returns 2006. >> >> Year should implement previous the same as Month does. > > Steve, > > Thanks for reporting this issue. I was going to enter a report on your > behalf in the Squeak bug tracking system, but it looks like Brent is > already on top of it :) > > http://bugs.squeak.org/view.php?id=7097 > > The bug report includes a proposed fix, which is straightforward if > you > want to include it in your image: > > http://bugs.squeak.org/file_download.php?file_id=3386&type=bug > > Brent's fix is as follows: > > Year>>previous > "This implementation handles leap years correctly" > ^ self class year: (self year - 1) > > Dave > > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >

June 17, 2008

[Pharo-project] Fwd: getting class variable access

by StÃ©phane Ducasse

Begin forwarded message: > From: Colin Putney <cputney(a)wiresong.ca> > Date: June 16, 2008 12:08:33 AM CEDT > To: OmniBrowser developers <ob-dev(a)wiresong.ca> > Subject: Re: getting class variable access > Reply-To: OmniBrowser developers <ob-dev(a)wiresong.ca> > > > On 15-Jun-08, at 11:57 AM, stephane ducasse wrote: > >> still having good name in the registration would help because OB >> adaptor sucks > > Agreed. Unfortunately, the registration mechanism doesn't let you > choose the name displayed in the menu. It just uses the name of the > class being registered. Also, the protocol expected by the > registration mechanism is particularly twisted, which is why I had to > create a separate class for it, instead of using OBSystemBrowser > directly. > > Colin > _______________________________________________ > ob-dev mailing list > ob-dev(a)wiresong.ca > http://mail.wiresong.ca/mailman/listinfo/ob-dev >

June 17, 2008

Re: [Pharo-project] Namespaces?

by StÃ©phane Ducasse

alex I reread what we did and I do not like it I can tell you tomorrow why. Stef On Jun 16, 2008, at 8:53 PM, Alexandre Bergel wrote: > Few years ago Stef and I worked on an implementation. It is working > fairly well. Unfortunately, we did not push it for an inclusion. > http://www.squeaksource.com/Namespace > > I just tried it. 'Namespace install' to install it. > Test are green in my seaside image. > > Cheers, > Alexandre > > On 16 Jun 2008, at 19:14, Michael Rueger wrote: > >> Hi all, >> >> asking the unmentionable ;-) >> >> Are there any plans for (simple) name spaces in Pharo? >> Reason I'm asking is that it would make moving code between e.g. VW >> and Pharo easier IMHO. >> >> Michael >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 16, 2008

Re: [Pharo-project] Namespaces?

by StÃ©phane Ducasse

On Jun 16, 2008, at 7:14 PM, Michael Rueger wrote: > Hi all, > > asking the unmentionable ;-) :) > Are there any plans for (simple) name spaces in Pharo? This is not that I would not like but really I'm thorn apart because really having something simple would be nice but after we have the tools and I'm not sure that having that orthogonal to packages would be good. I reread recently the proposal of goran but I do not like the idea that we would have Goo::Point in the code everywhere instead of Point or GooPoint. Now I would like to know whether we can factor that at the "border" of package but this have the prices of import statements. Now I have the impression that for pharo first having some nice clean packages is the first step. > > Reason I'm asking is that it would make moving code between e.g. VW > and Pharo easier IMHO. I would only do it in one way :) Stef

June 16, 2008

Re: [Pharo-project] Namespaces?

by StÃ©phane Ducasse

But I would change it. Stef On Jun 16, 2008, at 8:53 PM, Alexandre Bergel wrote: > Few years ago Stef and I worked on an implementation. It is working > fairly well. Unfortunately, we did not push it for an inclusion. > http://www.squeaksource.com/Namespace > > I just tried it. 'Namespace install' to install it. > Test are green in my seaside image. > > Cheers, > Alexandre > > On 16 Jun 2008, at 19:14, Michael Rueger wrote: > >> Hi all, >> >> asking the unmentionable ;-) >> >> Are there any plans for (simple) name spaces in Pharo? >> Reason I'm asking is that it would make moving code between e.g. VW >> and Pharo easier IMHO. >> >> Michael >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 16, 2008

Re: [Pharo-project] Namespaces?

by Alexandre Bergel

Few years ago Stef and I worked on an implementation. It is working fairly well. Unfortunately, we did not push it for an inclusion. http://www.squeaksource.com/Namespace I just tried it. 'Namespace install' to install it. Test are green in my seaside image. Cheers, Alexandre On 16 Jun 2008, at 19:14, Michael Rueger wrote: > Hi all, > > asking the unmentionable ;-) > > Are there any plans for (simple) name spaces in Pharo? > Reason I'm asking is that it would make moving code between e.g. VW > and Pharo easier IMHO. > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 16, 2008

[Pharo-project] Namespaces?

by Michael Rueger

Hi all, asking the unmentionable ;-) Are there any plans for (simple) name spaces in Pharo? Reason I'm asking is that it would make moving code between e.g. VW and Pharo easier IMHO. Michael

June 16, 2008

Re: [Pharo-project] Need code review

by StÃ©phane Ducasse

Ok I will try to harvest it today. Stef On Jun 16, 2008, at 2:23 PM, Alexandre Bergel wrote: > Ah ok.. > I see now... > > As I said, your removal makes fully sense to me... > > Alexandre > > > On 16 Jun 2008, at 14:13, Alain Plantec wrote: > >> Hi Alexandre, >> thanks for this review. >> >> On Monday 16 June 2008 09:34:26 Alexandre Bergel wrote: >>>> http://lists.gforge.inria.fr/pipermail/pharo-project/2008-June/000323.html >>>>>> [Pharo-project] MVC removal step2 investigations >> ... >>> Few questions: >>> - Inspector>>openOn: anObject withEvalPane: withEval withLabel: >>> label >>> valueViewClass: valueViewClass seems to be called by FormInspectView >>> class>>openOn: aFormDictionary withLabel: aLabel >>> Don't you think that removing this method might be a problem? >> FormInspectView class is removed >>> - Why have you removed PasteUpMorph>>open ? >> Here is it's code: >> PasteUpMorph>>open >> "Open a view on this WorldMorph." >> MorphWorldView openOn: self. >> MorphWorldView is a subclass of View (MVC) which is removed. >> So PasteUpMorph>>open makes sense only in MVC context. >>> >>> Je n'ai vu aucun problÃ¨me aprÃ¨s avoir chargÃ© le removal. >>> I favour an inclusion. >> I would only insist on the following point: >> One big change concerns the Controller hierarchy which was >> Controller #('model' 'view' 'sensor' 'lastActivityTime') >> MouseMenuController #('redButtonMenu' 'redButtonMessages') >> ScrollController #('scrollBar' 'marker' 'savedArea' 'menuBar' >> 'savedMenuBarArea') >> ParagraphEditor #('paragraph' 'startBlock' 'stopBlock' >> 'beginTypeInBlock' ' >> and which becomes: >> Controller #('model' 'sensor' 'lastActivityTime') >> ParagraphEditor #('paragraph' 'startBlock' 'stopBlock' >> 'beginTypeInBlock' 'emphasisHere' 'initialText' 'selectionShowing' >> 'otherInterval' 'lastParentLocation') >> >> as you can see, MouseMenuController and ScrollController are >> removed and ParagraphEditor is now a direct subclass of Controller. >> Controller is now more simple because of 'view' instance variable >> removeal. >> I think that 'lastActivityTime' can be removed too and I've also >> noticed more cleaning possibilities implied by this changeset. >> Especially in class ScreenController which holds a lot of menu >> methods which are not used anymore >> (world menu equivalent methods but in the context of MVC). >> I will provide a changeset or a slice later. >> >> alain >>> >>> Cheers, >>> Alexandre >>> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 16, 2008