Running fixcc.py

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

Running fixcc.py

David Kastrup

Hi,

it got a bit lost in other things, but I think I would want to run
fixcc.py right now, reformatting the C++ stuff (it doesn't help with the
conventions for template arguments but there are comparatively few of
those).

It's been run on stable already; so running on master makes future
cherry-picking less painful.

Ok?

People having patches in the C++ area will need to rebase.  I could
imagine doing that with git rebase -i, halting at every step, running
fixscm, committing, reverting that commit (except for the last) and
continuing.

Afterwards you have a sequence of

Revert _my_ fixscm commit
commit
fixscm
revert fixscm
commit
fixscm
revert fixscm
commit
fixscm

and you do another git rebase -i and squash each sequence of "revert
fixscm, commit, fixscm" into a single commit.

That should be a conflict-free way of doing this.  But only as long as
my fixscm commit actually reverts usefully on master.

But maybe not that many patches are in the queue right now.

Ok for me to go ahead, say tomorrow?

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Running fixcc.py

Torsten Hämmerle
Hi David,

No objections!
Probably this is, directly after introduction of new stable, the best
opportunity for tidying up and general re-formatting we'll have in years.

I'm a bit confused though:  starting off with fixcc, you are suddenly
talking about fixscm.  Is it about cc files, or scm files, or both?

Thanks,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html

Reply | Threaded
Open this post in threaded view
|

Re: Running fixcc.py

David Kastrup
Torsten Hämmerle <[hidden email]> writes:

> Hi David,
>
> No objections!
> Probably this is, directly after introduction of new stable, the best
> opportunity for tidying up and general re-formatting we'll have in years.
>
> I'm a bit confused though:  starting off with fixcc, you are suddenly
> talking about fixscm.  Is it about cc files, or scm files, or both?

This is about cc files, but scm files are due as well.  They will take a
bit more preparation and a separate issue/patch.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Running fixcc.py

Dan Eble
In reply to this post by David Kastrup
On Mar 21, 2020, at 11:26, David Kastrup <[hidden email]> wrote:
> it got a bit lost in other things, but I think I would want to run
> fixcc.py right now, reformatting the C++ stuff (it doesn't help with the
> conventions for template arguments but there are comparatively few of
> those).

OK here.  Also, thanks for suggesting an approach to rebasing.

Dan


Reply | Threaded
Open this post in threaded view
|

Re: Running fixcc.py

Dan Eble
In reply to this post by David Kastrup
On Mar 21, 2020, at 11:26, David Kastrup <[hidden email]> wrote:
> it got a bit lost in other things, but I think I would want to run
> fixcc.py right now, reformatting the C++ stuff (it doesn't help with the
> conventions for template arguments but there are comparatively few of
> those).

Did you use astyle 2.04 or another version?  I built 2.04 from source and ran it on master and I see a handful of differences in 3 files.

Dan


Reply | Threaded
Open this post in threaded view
|

Re: Running fixcc.py

David Kastrup
Dan Eble <[hidden email]> writes:

> On Mar 21, 2020, at 11:26, David Kastrup <[hidden email]> wrote:
>> it got a bit lost in other things, but I think I would want to run
>> fixcc.py right now, reformatting the C++ stuff (it doesn't help with the
>> conventions for template arguments but there are comparatively few of
>> those).
>
> Did you use astyle 2.04 or another version?  I built 2.04 from source

Uhm, I did not actually go to that effort and just used --sloppy.

> and ran it on master and I see a handful of differences in 3 files.

3.1.  I am afraid that I may have updated my system since the review,
and that looks like more of a version update than what I did the review
with.  Yes, this is more along the line of --extra-sloppy .  This is
sort of embarrassing, but I haven't even considered the implications of
just using what is there when a particular version has been declared
"standard" and people may actually use it in order _not_ to cause
spurious reformatting.

So where should we go from here?

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Running fixcc.py

Dan Eble
On Mar 22, 2020, at 17:04, David Kastrup <[hidden email]> wrote:
>
> Dan Eble <[hidden email]> writes:
>
>> Did you use astyle 2.04 or another version?  I built 2.04 from source
...
> 3.1.  I am afraid that I may have updated my system since the review,
...
> So where should we go from here?

As far as I'm concerned, we could just declare 3.1 to be the new preferred version.  I'm not sure whether that would inconvenience anyone else, though.

Dan


Reply | Threaded
Open this post in threaded view
|

Re: Running fixcc.py

David Kastrup
Dan Eble <[hidden email]> writes:

> On Mar 22, 2020, at 17:04, David Kastrup <[hidden email]> wrote:
>>
>> Dan Eble <[hidden email]> writes:
>>
>>> Did you use astyle 2.04 or another version?  I built 2.04 from source
> ...
>> 3.1.  I am afraid that I may have updated my system since the review,
> ...
>> So where should we go from here?
>
> As far as I'm concerned, we could just declare 3.1 to be the new
> preferred version.  I'm not sure whether that would inconvenience
> anyone else, though.

It's the current version, so eventually it might have become a candidate
anyway.  If we do that, fixcc should probably be changed such that 3.1
is the version accepted without --sloppy .

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Running fixcc.py

Dan Eble
On Mar 23, 2020, at 17:10, David Kastrup <[hidden email]> wrote:
>
> Dan Eble <[hidden email]> writes:

>> As far as I'm concerned, we could just declare 3.1 to be the new
>> preferred version.  I'm not sure whether that would inconvenience
>> anyone else, though.
>
> It's the current version, so eventually it might have become a candidate
> anyway.  If we do that, fixcc should probably be changed such that 3.1
> is the version accepted without --sloppy .

I'll submit that for review along with some tweaks to the clang-format configuration.  I still have some testing to do.

Dan


Reply | Threaded
Open this post in threaded view
|

Re: Running fixcc.py

David Kastrup
Dan Eble <[hidden email]> writes:

> On Mar 23, 2020, at 17:10, David Kastrup <[hidden email]> wrote:
>>
>> Dan Eble <[hidden email]> writes:
>
>>> As far as I'm concerned, we could just declare 3.1 to be the new
>>> preferred version.  I'm not sure whether that would inconvenience
>>> anyone else, though.
>>
>> It's the current version, so eventually it might have become a candidate
>> anyway.  If we do that, fixcc should probably be changed such that 3.1
>> is the version accepted without --sloppy .
>
> I'll submit that for review along with some tweaks to the clang-format
> configuration.  I still have some testing to do.

Thanks, and sorry for causing that workload out of not really thinking
through things.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Running fixcc.py

Dan Eble
On Mar 23, 2020, at 18:41, David Kastrup <[hidden email]> wrote:
>
> Dan Eble <[hidden email]> writes:
>
>> I'll submit that for review along with some tweaks to the clang-format
>> configuration.  I still have some testing to do.
>
> Thanks, and sorry for causing that workload out of not really thinking
> through things.

Think nothing of it.  I prefer Ubuntu's latest package over a 7-year-old source tarball from SourceForge.

https://codereview.appspot.com/551640043/

Dan