Massive detabbing of the source

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

Massive detabbing of the source

Jan Stolarek
I thought I could clean up the source code from all the tabs and then remove {-#
OPTIONS -fno-warn-tabs #-} pragmas + comment below it. This is a massive change though (140 files
would be affected) and I suspect it could potentially be a problem to others working on the
source (could cause some merge problems). So, can I just proceed with cleaning up all those 140
files and then send a single patch or should I devide this task into smaller ones (e.g. a single
patch for every directory in the $(TOP)/compiler/) or should I just give up on this idea?

Janek


Reply | Threaded
Open this post in threaded view
|

Massive detabbing of the source

Simon Peyton Jones
Hmm. Precisely because it causes un-forced conflicts, our policy has been:
        de-tab when you are modifying a file anyway

But if you find files that are stable -- have not been modified for some months -- then yes you could detab them. Perhaps one directory at a time?  

I'm unsure it's worth the bother, but would not want to obstruct.  Others may have views

Simon

| -----Original Message-----
| From: ghc-devs-bounces at haskell.org [mailto:ghc-devs-bounces at haskell.org]
| On Behalf Of Jan Stolarek
| Sent: 17 January 2013 13:32
| To: ghc-devs at haskell.org
| Subject: Massive detabbing of the source
|
| I thought I could clean up the source code from all the tabs and then
| remove {-# OPTIONS -fno-warn-tabs #-} pragmas + comment below it. This
| is a massive change though (140 files would be affected) and I suspect
| it could potentially be a problem to others working on the source (could
| cause some merge problems). So, can I just proceed with cleaning up all
| those 140 files and then send a single patch or should I devide this
| task into smaller ones (e.g. a single patch for every directory in the
| $(TOP)/compiler/) or should I just give up on this idea?
|
| Janek
|
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs


Reply | Threaded
Open this post in threaded view
|

Massive detabbing of the source

Simon Marlow-7
On 17/01/13 14:06, Simon Peyton-Jones wrote:
> Hmm. Precisely because it causes un-forced conflicts, our policy has been:
> de-tab when you are modifying a file anyway
>
> But if you find files that are stable -- have not been modified for some months -- then yes you could detab them. Perhaps one directory at a time?
>
> I'm unsure it's worth the bother, but would not want to obstruct.  Others may have views

I don't think it's worth the bother either: conflicts are a pain and
slow down development, whereas tabs don't.  I don't have any large
branches right now so I wouldn't be affected, but there certainly are a
few active branches with large-scale changes.

Cheers,
        Simon



Reply | Threaded
Open this post in threaded view
|

Massive detabbing of the source

Jan Stolarek
In reply to this post by Simon Peyton Jones
Dnia czwartek, 17 stycznia 2013, Simon Peyton-Jones napisa?:
> But if you find files that are stable -- have not been modified for some
> months -- then yes you could detab them.
This seems to be a good heuristic.

> I'm unsure it's worth the bother
Cleaner code is worth the bother :) Especially that is really not that much effort.

Janek


Reply | Threaded
Open this post in threaded view
|

Massive detabbing of the source

Richard Eisenberg-2
In reply to this post by Jan Stolarek
I don't know whether the files have been "stable" or not, but I'm working on some pretty massive changes to a handful of files in order to support promotion of GADTs, among other fun things. So, if I may ask, please stay away from detabbing the following:

TypeRep
Type
Coercion
OptCoercion
Unify
CoreLint
Kind

After the code has stabilized and I've merged, I'm happy to detab these files myself later on...

Thanks for asking!
Richard

On Jan 17, 2013, at 8:31 AM, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:

> I thought I could clean up the source code from all the tabs and then remove {-#
> OPTIONS -fno-warn-tabs #-} pragmas + comment below it. This is a massive change though (140 files
> would be affected) and I suspect it could potentially be a problem to others working on the
> source (could cause some merge problems). So, can I just proceed with cleaning up all those 140
> files and then send a single patch or should I devide this task into smaller ones (e.g. a single
> patch for every directory in the $(TOP)/compiler/) or should I just give up on this idea?
>
> Janek
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs



Reply | Threaded
Open this post in threaded view
|

Massive detabbing of the source

Jan Stolarek
In reply to this post by Jan Stolarek
> I don't think it's worth the bother either: conflicts are a pain and
> slow down development, whereas tabs don't. (...) there certainly are a
> few active branches with large-scale changes.
That's another good point.

I looked through the git history and it seems there are actually few tabbed files that weren't
touched for the last 6 months. It follows that tabbed files that people work on are not being
actually detabbed by them, unless the policy is to detab only the parts that are modified, not
the whole file.

I won't do this massive detabbing of the whole source since it indeed could cause more problems
than profits, but my opinion is that at some point detabbing should be just done or otherwise
those -fno-warn pragmas and tabs will stay in the source code forever. Perhaps it would be a good
idea to detab a bunch of files every month?

Janek


Reply | Threaded
Open this post in threaded view
|

Massive detabbing of the source

Alexander Kjeldaas
 On Jan 18, 2013 10:17 AM, "Jan Stolarek" <jan.stolarek at p.lodz.pl> wrote:

> > I don't think it's worth the bother either: conflicts are a pain and
> > slow down development, whereas tabs don't. (...) there certainly are a
> > few active branches with large-scale changes.
> That's another good point.
>
> I looked through the git history and it seems there are actually few
> tabbed files that weren't
> touched for the last 6 months. It follows that tabbed files that people
> work on are not being
> actually detabbed by them, unless the policy is to detab only the parts
> that are modified, not
> the whole file.
>
> I won't do this massive detabbing of the whole source since it indeed
> could cause more problems
> than profits, but my opinion is that at some point detabbing should be
> just done or otherwise
> those -fno-warn pragmas and tabs will stay in the source code forever.
> Perhaps it would be a good
> idea to detab a bunch of files every month?
>
>
Well if this is true, then I think you could solve this simply by looking
for this in a git commit hook or some other hook.
http://stackoverflow.com/questions/3985463/prevent-pushes-to-git-containing-tabs-in-certain-files-e-g-cpp-h-cmakeli
https://github.com/mrc/git-hook-library

Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130118/81865c20/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

Massive detabbing of the source

Jan Stolarek
Dnia pi?tek, 18 stycznia 2013, Alexander Kjeldaas napisa?:
> Well if this is true, then I think you could solve this simply by looking
> for this in a git commit hook or some other hook.
> http://stackoverflow.com/questions/3985463/prevent-pushes-to-git-containing
>-tabs-in-certain-files-e-g-cpp-h-cmakeli
> https://github.com/mrc/git-hook-library
There is already such a hook:

"We'd like to move away from tabs in the long term, and so a git hook on darcs.haskell.org will
reject series of commits that add tabs to a file that is currently tab-free. (Note that there are
no restrictions on adding tabs to a file already containing them.)"

From: http://hackage.haskell.org/trac/ghc/wiki/Commentary/CodingStyle#TabsvsSpaces

Janek


Reply | Threaded
Open this post in threaded view
|

Massive detabbing of the source

Alexander Kjeldaas
Then it's even easier.  Update the hook to reject all tabs in source code
files, wait 6 months, and start detabbing the remaining files.  Then the
probability of conflict should be pretty low.

Alexander


On Fri, Jan 18, 2013 at 1:46 PM, Jan Stolarek <jan.stolarek at p.lodz.pl>wrote:

> Dnia pi?tek, 18 stycznia 2013, Alexander Kjeldaas napisa?:
> > Well if this is true, then I think you could solve this simply by looking
> > for this in a git commit hook or some other hook.
> >
> http://stackoverflow.com/questions/3985463/prevent-pushes-to-git-containing
> >-tabs-in-certain-files-e-g-cpp-h-cmakeli
> > https://github.com/mrc/git-hook-library
> There is already such a hook:
>
> "We'd like to move away from tabs in the long term, and so a git hook on
> darcs.haskell.org will
> reject series of commits that add tabs to a file that is currently
> tab-free. (Note that there are
> no restrictions on adding tabs to a file already containing them.)"
>
> From:
> http://hackage.haskell.org/trac/ghc/wiki/Commentary/CodingStyle#TabsvsSpaces
>
> Janek
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130118/75d7c7cc/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

Massive detabbing of the source

Richard Eisenberg-2
I like Alexander's idea, but there's a subtle problem with it: Any sizeable change to one file requires (at least) small changes in several other files. Say X.hs has tabs. If I make a one-line change to X.hs, and you're in the middle of massive changes to X.hs, and I detab X.hs in the course of committing my one-line change, you have a bad merge in your future.

So, my suggestion would be to do what Alexander suggests, but essentially to make the error into a warning. When committing a file with tabs, the hook can report a list of all files containing tabs in them, encouraging the committer to detab any files they have made significant changes to. The commit would still go through, though. Then, after 6 months of that, we can change the warning into a proper error and/or do a massive full-sweep detabbing.

Richard

On Jan 18, 2013, at 8:03 AM, Alexander Kjeldaas wrote:

> Then it's even easier.  Update the hook to reject all tabs in source code files, wait 6 months, and start detabbing the remaining files.  Then the probability of conflict should be pretty low.
>
> Alexander
>
>
> On Fri, Jan 18, 2013 at 1:46 PM, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:
> Dnia pi?tek, 18 stycznia 2013, Alexander Kjeldaas napisa?:
> > Well if this is true, then I think you could solve this simply by looking
> > for this in a git commit hook or some other hook.
> > http://stackoverflow.com/questions/3985463/prevent-pushes-to-git-containing
> >-tabs-in-certain-files-e-g-cpp-h-cmakeli
> > https://github.com/mrc/git-hook-library
> There is already such a hook:
>
> "We'd like to move away from tabs in the long term, and so a git hook on darcs.haskell.org will
> reject series of commits that add tabs to a file that is currently tab-free. (Note that there are
> no restrictions on adding tabs to a file already containing them.)"
>
> From: http://hackage.haskell.org/trac/ghc/wiki/Commentary/CodingStyle#TabsvsSpaces
>
> Janek
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130118/8497acc6/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

Massive detabbing of the source

David Terei
I don't mind too much either way what happens here as I have no
outstanding changes.

However, I generally agree with the Simons. We've been slowly removing
tabs over time and a little ugliness doesn't hurt for now. I also like
that de-tabbing for me has been a big motivation to not simply de-tab,
but to clean up those files in a larger sense.

My 2 cents :).

On 18 January 2013 09:08, Richard Eisenberg <eir at cis.upenn.edu> wrote:

> I like Alexander's idea, but there's a subtle problem with it: Any sizeable
> change to one file requires (at least) small changes in several other files.
> Say X.hs has tabs. If I make a one-line change to X.hs, and you're in the
> middle of massive changes to X.hs, and I detab X.hs in the course of
> committing my one-line change, you have a bad merge in your future.
>
> So, my suggestion would be to do what Alexander suggests, but essentially to
> make the error into a warning. When committing a file with tabs, the hook
> can report a list of all files containing tabs in them, encouraging the
> committer to detab any files they have made significant changes to. The
> commit would still go through, though. Then, after 6 months of that, we can
> change the warning into a proper error and/or do a massive full-sweep
> detabbing.
>
> Richard
>
> On Jan 18, 2013, at 8:03 AM, Alexander Kjeldaas wrote:
>
> Then it's even easier.  Update the hook to reject all tabs in source code
> files, wait 6 months, and start detabbing the remaining files.  Then the
> probability of conflict should be pretty low.
>
> Alexander
>
>
> On Fri, Jan 18, 2013 at 1:46 PM, Jan Stolarek <jan.stolarek at p.lodz.pl>
> wrote:
>>
>> Dnia pi?tek, 18 stycznia 2013, Alexander Kjeldaas napisa?:
>> > Well if this is true, then I think you could solve this simply by
>> > looking
>> > for this in a git commit hook or some other hook.
>> >
>> > http://stackoverflow.com/questions/3985463/prevent-pushes-to-git-containing
>> >-tabs-in-certain-files-e-g-cpp-h-cmakeli
>> > https://github.com/mrc/git-hook-library
>> There is already such a hook:
>>
>> "We'd like to move away from tabs in the long term, and so a git hook on
>> darcs.haskell.org will
>> reject series of commits that add tabs to a file that is currently
>> tab-free. (Note that there are
>> no restrictions on adding tabs to a file already containing them.)"
>>
>> From:
>> http://hackage.haskell.org/trac/ghc/wiki/Commentary/CodingStyle#TabsvsSpaces
>>
>> Janek
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>