[Pharo-project] Mike we need some fixes for mime.... :)
From: stephane ducasse <stephane.ducasse@free.fr> Date: February 15, 2009 3:49:58 PM CEST To: Pharo Development <Pharo-project@lists.gforge.inria.fr> Subject: Mike we need some fixes for mime....
Issue 527: MIMEDocument changes break Kom http://code.google.com/p/pharo/issues/detail?id=527
Issue 520: MIMEDocument class(Object)>>doesNotUnderstand: #resetMIMEdatabase http://code.google.com/p/pharo/issues/detail?id=520
Tx Stef
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
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
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
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
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
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 <stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
participants (5)
-
Lukas Renggli -
Marcus Denker -
Michael Roberts -
Michael Rueger -
Stéphane Ducasse