Mike we need some fixes for mime.... :)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Mike we need some fixes for mime.... :)

Stéphane Ducasse



From: stephane ducasse <[hidden email]>
Date: February 15, 2009 3:49:58 PM CEST
To: Pharo Development <[hidden email]>
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





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Mike we need some fixes for mime.... :)

Michael Rueger-6
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
Reply | Threaded
Open this post in threaded view
|

Re: Mike we need some fixes for mime.... :)

Stéphane Ducasse

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
Reply | Threaded
Open this post in threaded view
|

Re: Mike we need some fixes for mime.... :)

Lukas Renggli
>        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
Reply | Threaded
Open this post in threaded view
|

Re: Mike we need some fixes for mime.... :)

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
> [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
Reply | Threaded
Open this post in threaded view
|

Re: Mike we need some fixes for mime.... :)

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Mike we need some fixes for mime.... :)

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
> [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
Reply | Threaded
Open this post in threaded view
|

Re: Mike we need some fixes for mime.... :)

Stéphane Ducasse
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
Reply | Threaded
Open this post in threaded view
|

Re: Mike we need some fixes for mime.... :)

Stéphane Ducasse
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
Reply | Threaded
Open this post in threaded view
|

Re: Mike we need some fixes for mime.... :)

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Mike we need some fixes for mime.... :)

Stéphane Ducasse
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
Reply | Threaded
Open this post in threaded view
|

Re: Mike we need some fixes for mime.... :)

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
>>> [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
Reply | Threaded
Open this post in threaded view
|

Re: Mike we need some fixes for mime.... :)

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Mike we need some fixes for mime.... :)

Michael Roberts-2
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