Mike we need some fixes for mime.... :)
Locked
Mike we need some fixes for mime.... :)
 
|
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Mike we need some fixes for mime.... :)
|
|
Stéphane Ducasse wrote:
>> Issue 520: MIMEDocument class(Object)>>doesNotUnderstand: >> #resetMIMEdatabase >> http://code.google.com/p/pharo/issues/detail?id=520 Hmm, there isn't a MIMEDocument>>initialize anymore, so the bug is introduced by someone reintroducing/overriding the class initialize method. Michael _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Mike we need some fixes for mime.... :)
|
|
On Feb 16, 2009, at 5:15 PM, Michael Rueger wrote: > Stéphane Ducasse wrote: > >>> Issue 520: MIMEDocument class(Object)>>doesNotUnderstand: >>> #resetMIMEdatabase >>> http://code.google.com/p/pharo/issues/detail?id=520 > > > Hmm, there isn't a MIMEDocument>>initialize anymore, so the bug is > introduced by someone reintroducing/overriding the class initialize > method. you wrote: Comment 1 by mike.rueger, Feb 14 (2 days ago) My guess is that MIMEDocument>>initialize is changed/overriden by Pier? Now I checked and in previous version this method was define in MIMEDocument MIMEdatabase _ self extendedMIMEdatabase so did you remove it on purpose during the refactoring? Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Mike we need some fixes for mime.... :)
|
|
> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Mike we need some fixes for mime.... :)
|
|
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Mike we need some fixes for mime.... :)
|
|
> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Mike we need some fixes for mime.... :)
|
|
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Marcus Denker -- [hidden email] http://www.iam.unibe.ch/~denker _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Mike we need some fixes for mime.... :)
|
|
In reply to this post by Lukas Renggli
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Mike we need some fixes for mime.... :)
|
|
In reply to this post by Marcus Denker
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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Marcus Denker -- [hidden email] > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Mike we need some fixes for mime.... :)
|
|
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Mike we need some fixes for mime.... :)
|
|
In reply to this post by Marcus Denker
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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Marcus Denker -- [hidden email] > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Mike we need some fixes for mime.... :)
|
|
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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> Marcus Denker -- [hidden email] >> http://www.iam.unibe.ch/~denker >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Marcus Denker -- [hidden email] http://www.iam.unibe.ch/~denker _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Mike we need some fixes for mime.... :)
|
|
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Mike we need some fixes for mime.... :)
|
|
I just wanted to add that I agree the change is currently at the wrong
level. Whilst the change was done with the best intentions, and in the best spirit of what Pharo is trying to be, the impact on the user was not obvious until it was live. I wanted to load the cryptography package so that I could play with the Amazon cloud stuff. I get exactly the same warning and it is a disruption. I agree with the thread that said this should be a code critic rule, and / or there is some control over when the warnings are raised. I also saw that Doru was having issues with it as well in another thread. I'm all for change, but in this case we need to be more sophisticated about it. thanks, Mike On Tue, Feb 17, 2009 at 9:48 AM, Stéphane Ducasse <[hidden email]> wrote: > 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 > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |