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

Re: [Pharo-project] Loading Polymorph

by StÃ©phane Ducasse

When I merge simply the latest version it blocks the system with read banners everywhere. Should I patch MC before? Stef On Feb 16, 2009, at 8:24 PM, StÃ©phane Ducasse wrote: > ok do you imply that I should be able to push in the release the > latest version without problem? > Excellent! > > Stef > > On Feb 16, 2009, at 1:22 PM, Gary Chambers wrote: > >> Loads from 42 upwards should be ok as normal. Polymorph-Widgets- >> gvc-45 now >> on SqueakSource >> with some lint related changes and a few other goodies ;-) >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Sunday, February 15, 2009 2:53 PM >> Subject: Re: [Pharo-project] Loading Polymorph >> >> >>> I will try to see what I can do to load it. >>> >>> Stef >>> >>> >>>> Latest Polymorph-Widgets versions (from 41 to 42) require the MC >>>> workaround to load/merge, unfortunately. >>>> Anything down to drawing... in this case the change to dropShadows. >>>> >>>> Regards, Gary >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 17, 2009

Re: [Pharo-project] Mike we need some fixes for mime.... :)

by StÃ©phane Ducasse

Ok >> > Lets discuss this monday. :) > I am not against change, but this chagne is *at the wrong level*. > > I don't want RB Lint to do the check in the browser (maybe later), > it can be done just the same it is now done in the classbuilder, just > in the browser. That's where we want it, as it talks to the user. Why not then. My gut feeling is that we should have LARGE warning when also saving or loading code. Consistency can be a good thing

Feb. 17, 2009

Re: [Pharo-project] Mike we need some fixes for mime.... :)

by Marcus Denker

On 17.02.2009, at 10:35, StÃ©phane Ducasse wrote: > another point > > Pharo looks to me a bit dead then. if the goal is just to clean Squeak > then it is already a failure. > There are design decisions that were taken more than 30 years ago. > There are so much things that are not optimal in the current system > that if just because one single > class in an external package uses an uppercase we stop to consider > that having some enforced coding > convention, then I imagine that we will have to fork again to do > something that really open-space. > > Of course we can discuss to fix it using RB, but RB is not integrated > into OB because OB should stay platform > independent blablbalblbababl... I think that there are far too much > constraints in play. > > I imagine that pharo will have success but it will just be a clean > smalltalk....wonderful, really exciting > an old stuff rejuvenated. > Lets discuss this monday. I am not against change, but this chagne is *at the wrong level*. I don't want RB Lint to do the check in the browser (maybe later), it can be done just the same it is now done in the classbuilder, just in the browser. That's where we want it, as it talks to the user. Marcus > stef > > On Feb 17, 2009, at 10:20 AM, Marcus Denker wrote: > >> Hi, >> >> I think we should revert the change. >> >> The idea was to enforce good coding practices, for that, a better >> place >> is the browser itself: it should have a "checking" phase where it >> does >> checks >> and tells the user if there are strange things (Lukas mentioned that >> Lint applied >> to just one method is *very* fast). >> >> Marcus >> >> >> On 17.02.2009, at 09:59, Lukas Renggli wrote: >> >>>> propose a preference to turnout the warning >>>> Who implemented this Uppercase class instance variable. >>> >>> That was recently added to the classbuilder. As I wrote in the other >>> thread the class builder should not bother about such things, a >>> preference does not help here because newbies won't know what >>> settings >>> they have to choose for a particular package to load without >>> debuggers >>> popping up. I created lint rules that check for consistent >>> capitalization of variable names (instance-, temp-, argument- >>> variables >>> lowercase; class-, pool-, global-variables uppercase). >>> >>>> I do not understand why if you turn an uppercase class instance >>>> variable >>>> into a lower case class instance variable this would fucked up the >>>> other pier installations? >>>> The migration of instances is broken? >>> >>> The class builder is not the problem. It is Monticello that treats a >>> variable renaming as a removal of the old and addition of the new >>> variable. >>> >>> 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 >> >> -- >> Marcus Denker -- denker(a)iam.unibe.ch >> http://www.iam.unibe.ch/~denker >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Feb. 17, 2009

Re: [Pharo-project] Mike we need some fixes for mime.... :)

by StÃ©phane Ducasse

another point Pharo looks to me a bit dead then. if the goal is just to clean Squeak then it is already a failure. There are design decisions that were taken more than 30 years ago. There are so much things that are not optimal in the current system that if just because one single class in an external package uses an uppercase we stop to consider that having some enforced coding convention, then I imagine that we will have to fork again to do something that really open-space. Of course we can discuss to fix it using RB, but RB is not integrated into OB because OB should stay platform independent blablbalblbababl... I think that there are far too much constraints in play. I imagine that pharo will have success but it will just be a clean smalltalk....wonderful, really exciting an old stuff rejuvenated. stef On Feb 17, 2009, at 10:20 AM, Marcus Denker wrote: > Hi, > > I think we should revert the change. > > The idea was to enforce good coding practices, for that, a better > place > is the browser itself: it should have a "checking" phase where it does > checks > and tells the user if there are strange things (Lukas mentioned that > Lint applied > to just one method is *very* fast). > > Marcus > > > On 17.02.2009, at 09:59, Lukas Renggli wrote: > >>> propose a preference to turnout the warning >>> Who implemented this Uppercase class instance variable. >> >> That was recently added to the classbuilder. As I wrote in the other >> thread the class builder should not bother about such things, a >> preference does not help here because newbies won't know what >> settings >> they have to choose for a particular package to load without >> debuggers >> popping up. I created lint rules that check for consistent >> capitalization of variable names (instance-, temp-, argument- >> variables >> lowercase; class-, pool-, global-variables uppercase). >> >>> I do not understand why if you turn an uppercase class instance >>> variable >>> into a lower case class instance variable this would fucked up the >>> other pier installations? >>> The migration of instances is broken? >> >> The class builder is not the problem. It is Monticello that treats a >> variable renaming as a removal of the old and addition of the new >> variable. >> >> 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 > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 17, 2009

Re: [Pharo-project] Mike we need some fixes for mime.... :)

by Marcus Denker

On 17.02.2009, at 10:29, StÃ©phane Ducasse wrote: > I'm quite skeptical because when did you run smallLint on your own > code? > I mean: load the right version of RB, understand the UI of > SmallLint.... > run the rules, and fix that should be fixed, annotate what should not > be fixed. > > So if you want to revert the changes do it, but I'm really sad because > the problem > is not in the check but in the fact that MC is not good enough. > > Then this means that everybody will be able to write code that will > always take time > to read. For me when I read Singleton vs singleton it makes a scoping > difference: > one shared for all the subclasses and one per class. > > So if smalltalkers are not able to deal with that.... > The question is if these checks should be done deep in the object model or at the border. What would be the problem of moving the check into the browser, instead of doing it in classbuilder? Marcus

Feb. 17, 2009

Re: [Pharo-project] Mike we need some fixes for mime.... :)

by StÃ©phane Ducasse

I'm quite skeptical because when did you run smallLint on your own code? I mean: load the right version of RB, understand the UI of SmallLint.... run the rules, and fix that should be fixed, annotate what should not be fixed. So if you want to revert the changes do it, but I'm really sad because the problem is not in the check but in the fact that MC is not good enough. Then this means that everybody will be able to write code that will always take time to read. For me when I read Singleton vs singleton it makes a scoping difference: one shared for all the subclasses and one per class. So if smalltalkers are not able to deal with that.... Stef > Hi, > > I think we should revert the change. > > The idea was to enforce good coding practices, for that, a better > place > is the browser itself: it should have a "checking" phase where it does > checks > and tells the user if there are strange things (Lukas mentioned that > Lint applied > to just one method is *very* fast). > > Marcus > > > On 17.02.2009, at 09:59, Lukas Renggli wrote: > >>> propose a preference to turnout the warning >>> Who implemented this Uppercase class instance variable. >> >> That was recently added to the classbuilder. As I wrote in the other >> thread the class builder should not bother about such things, a >> preference does not help here because newbies won't know what >> settings >> they have to choose for a particular package to load without >> debuggers >> popping up. I created lint rules that check for consistent >> capitalization of variable names (instance-, temp-, argument- >> variables >> lowercase; class-, pool-, global-variables uppercase). >> >>> I do not understand why if you turn an uppercase class instance >>> variable >>> into a lower case class instance variable this would fucked up the >>> other pier installations? >>> The migration of instances is broken? >> >> The class builder is not the problem. It is Monticello that treats a >> variable renaming as a removal of the old and addition of the new >> variable. >> >> 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 > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 17, 2009

Re: [Pharo-project] Mike we need some fixes for mime.... :)

by StÃ©phane Ducasse

Ok I see > That was recently added to the classbuilder. As I wrote in the other > thread the class builder should not bother about such things, a > preference does not help here because newbies won't know what settings > they have to choose for a particular package to load without debuggers > popping up. I know that we already disagree on that one so I will reread the thread if needed. Now having a bit of rules should help. Uppercase are for globals. Then the preference has nothing todo with newbies. I thought more as a way to help you to migrate. Newbies should not write code were classinstancevar are in uppercase. > I created lint rules that check for consistent > capitalization of variable names (instance-, temp-, argument-variables > lowercase; class-, pool-, global-variables uppercase). > >> I do not understand why if you turn an uppercase class instance >> variable >> into a lower case class instance variable this would fucked up the >> other pier installations? >> The migration of instances is broken? > > The class builder is not the problem. It is Monticello that treats a > variable renaming as a removal of the old and addition of the new > variable. Indeed this is not good and break the smooth migration of smalltalk. Sorry about that. This really shows that we can improve. For example the fact that the changeset does not treat class definitino as doit and that instance varaible are not first class entities does not help either. stef

Feb. 17, 2009

Re: [Pharo-project] Mike we need some fixes for mime.... :)

by Marcus Denker

Hi, I think we should revert the change. The idea was to enforce good coding practices, for that, a better place is the browser itself: it should have a "checking" phase where it does checks and tells the user if there are strange things (Lukas mentioned that Lint applied to just one method is *very* fast). Marcus On 17.02.2009, at 09:59, Lukas Renggli wrote: >> propose a preference to turnout the warning >> Who implemented this Uppercase class instance variable. > > That was recently added to the classbuilder. As I wrote in the other > thread the class builder should not bother about such things, a > preference does not help here because newbies won't know what settings > they have to choose for a particular package to load without debuggers > popping up. I created lint rules that check for consistent > capitalization of variable names (instance-, temp-, argument-variables > lowercase; class-, pool-, global-variables uppercase). > >> I do not understand why if you turn an uppercase class instance >> variable >> into a lower case class instance variable this would fucked up the >> other pier installations? >> The migration of instances is broken? > > The class builder is not the problem. It is Monticello that treats a > variable renaming as a removal of the old and addition of the new > variable. > > 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 -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Feb. 17, 2009

Re: [Pharo-project] Mike we need some fixes for mime.... :)

by Lukas Renggli

> propose a preference to turnout the warning > Who implemented this Uppercase class instance variable. That was recently added to the classbuilder. As I wrote in the other thread the class builder should not bother about such things, a preference does not help here because newbies won't know what settings they have to choose for a particular package to load without debuggers popping up. I created lint rules that check for consistent capitalization of variable names (instance-, temp-, argument-variables lowercase; class-, pool-, global-variables uppercase). > I do not understand why if you turn an uppercase class instance variable > into a lower case class instance variable this would fucked up the > other pier installations? > The migration of instances is broken? The class builder is not the problem. It is Monticello that treats a variable renaming as a removal of the old and addition of the new variable. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 17, 2009

Re: [Pharo-project] Mike we need some fixes for mime.... :)

by StÃ©phane Ducasse

propose a preference to turnout the warning Who implemented this Uppercase class instance variable. I do not understand why if you turn an uppercase class instance variable into a lower case class instance variable this would fucked up the other pier installations? The migration of instances is broken? Stef On Feb 17, 2009, at 9:34 AM, Lukas Renggli wrote: >> Comment 1 by mike.rueger, Feb 14 (2 days ago) My guess is that >> MIMEDocument>>initialize is changed/overriden by Pier? > > No. Magritte and Pier do not touch MimeDocument. Seaside adds two > extension methods, but they do not conflict. It is KomHttpServer that > adds #initialize as a class extension method. > > Pier does not load into newer Pharo versions for another reason: It > has an uppercase class instance variable that I cannot rename without > f***ing up all existing Pier installations (see related discussion). > > 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. 17, 2009