- Pharo-dev - lists.pharo.org

[Pharo-project] Installing MC1.5 into Pharo

by Damien Cassou

On Tue, Feb 17, 2009 at 9:02 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I do not understand how > > Issue 456: 7272: BlockContext equality test is missing > > is related to kernel extensions? As I understand it, KernelExtensions was a bunch of unrelated changes in the image. This package has been divided into multiple mantis issues. Also, the Null pattern is not necessary anymore to get MC15. Please Keith correct me. -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 17, 2009

Re: [Pharo-project] Loading Polymorph

by Damien Cassou

On Tue, Feb 17, 2009 at 10:52 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Should I patch MC before? Yes, I think so. Gary told me that when I tried to load Polymorph. -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 17, 2009

Re: [Pharo-project] Fonts in Pharo

by Marcus Denker

On 10.02.2009, at 10:48, Alexandre Bergel wrote: > Dear Gary and his team, > > I am truly delighted to see that a native font may be installed. This > is really cool! Very snappy as well. > > I have a suggestion. Probably you though about it, but let me try :-) > Each time I open an image, the cache is checked. I guess this is to > prevent a change in the host OS. > However, could the cache be checked only if the font saved in the > image does not exist at startup? > We relly need to check this... one thing is that the fonts it will be shipped with will be there anyway, so no need for checking. The code that does the check is FreeTypeFontProvider class>>startUp: > The cache could be explicitly checked when opening the font browser. > It has already an "update" button... could be called by default. -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Feb. 17, 2009

[Pharo-project] Some patches in inbox need review

by Damien Cassou

The following three issues have fixes in the Inbox. These fixes will help integration of MC1.5. Syntax Error dialogs raise more errors than does the calling Parser http://code.google.com/p/pharo/issues/detail?id=234 MC1.5 overrides methods in HTTPSocket http://code.google.com/p/pharo/issues/detail?id=580 ClassOrganizer categories breaks if given an empty array http://code.google.com/p/pharo/issues/detail?id=581 -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 17, 2009

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