June 2008 - Pharo-dev - lists.pharo.org

[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

Re: [Pharo-project] Need code review

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 16, 2008

Re: [Pharo-project] Need code review

by Alain Plantec

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 >

June 16, 2008

RE: [Pharo-project] Reintegration of StringSocket

by Gary Chambers

I notice that StringSocket inherits from ObjectSocket and then Stream... so StringSocketStream might have been a better name for it.... Gary. > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr]On Behalf Of Michael > Rueger > Sent: 14 June 2008 3:52 AM > To: An open mailing list to discuss any topics related to an > open-sourceSmalltalk > Subject: Re: [Pharo-project] Reintegration of StringSocket > > > StÃ©phane Ducasse wrote: > > sure > > can you publish it somewhere? > > > > Stef > > > > On Jun 13, 2008, at 3:39 PM, Damien Cassou wrote: > > > >> Hi, > >> > >> StringSocket is a class part of Nebraska. You removed that class. > >> However, Universe uses this class to publish packages. Is it possible > >> to reintegrate this class, at least partially to support Universe? > > I would rather vote for rewrite Universes to not use. > Special subclasses of Socket are plain evil ;-) > > Michael > > _______________________________________________ > 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