Re: Code formatter

[David Kastrup]

Graham Percival gra...@percival-music.ca writes:

 On Fri, Nov 13, 2009 at 11:23:55AM -0700, Carl Sorensen wrote:
 Jan believes that code formatting standards should be no more restrictive
 than the GNU standards.

 By the way, if somebody has a compelling argument why we should
 differ from the GNU standards, I'm willing to go up against Jan.
 But before I do that, I need to be *convinced* that the
 alternative is right.

 This same issue is relevant in the discussion about going to Lua.
 Lua is not GNU software.  It does use the MIT license, which is GPL
 compatible, according to the FSF.

 That's not an issue.  The issue is that rewriting lilypond would take
 thousands of hours of work, and nobody wants to do that work.

Yes.

 Besides, I really thought that the Lua-talk was a joke.

It was a quite serious hypothetical.  If xxx were to be started from
scratch is rarely an option.  If you want to, take it as if only
Lilypond had been written using Lua.  Because there are quite a number
of compelling advantages, not least of all performance.

 Some people at my university want to rewrite lilypond in Haskell --
 again, they weren't serious about it.  The notion was just a hey,
 wouldn't it be cool if...? thing.

This hypothetical was not wouldn't it be cool, but rather wouldn't it
be nice.  The Haskell rewrite sounds like potentially squeezing the
source code size by a factor of 2, squeezing the developer pond by a
factor of 20.  The Lua rewrite would likely squeeze the source code by a
similar size and double the developer pool.

Because one simple language that can be efficiently used for
_everything_ sure beats two complex languages that can only be used in
tandem for doing everything, in particular when we are talking about
efficiency.  And that's before we even take a look _which_ languages we
are talking about.

 The core developers have a better estimate of the enormous amount of
 work it would take to rewrite lilypond in lua, java, or whatever was
 being proposed.  Also possibly rewriting it to avoid using various
 libraries... so maybe re-implementing fontforge, pango, etc etc etc.

Reimplementation libraries is not an option, I think.  Lua is pretty
good for integrating libraries, and quite a number of external bindings
exist.

But the bottom line of course remains: any porting requires developers.
Another option would be to pull in Lua as an _additional_ extension
language, then move existing code in pieces to Lua.  That's the approach
that the Context/LuaTeX development team has taken.  The process has a
large evolutionary rather than planned taste to it.  But it shows
intermediate results that keep the motivation going.

Again: I am not proposing to actually do this.  It was just a wouldn't
it be nice.  Not cool, nice.  Because diving into the current system is
to a large degree fighting with the implementation rather than the
implemented system.

For anybody who thinks that I am fantasizing because of some arbitrary
language preferences, I recommend reading through the Programming in
Lua manual for which slightly older versions are completely online.

Very worthwhile, for programmers used to _any_ language.

 If anybody has a CONCRETE proposal on how to make things easier
 for non-Linux developers... along with the manpower required to
 IMPLEMENT those proposals... I'm more than willing to listen.  If
 their proposal includes a relatively minor amount of work from the
 core developers, I'm willing to do it.  If the proposal boils down
 to hey, how about you guys rewrite it in visual basic, while I
 continue to complain about bugs and the lack of a wiki... then
 they won't get anywhere.

Sure.

-- 
David Kastrup



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[demery]

 2) many programmers view code style in a highly personal,
 quasi-religious manner.
 ...
 ...Han-Wen and Jan have different views...

Foe me its a matter of blocking the whitespace to to present the code in a
way that makes it easier to understand.  This is not easy to do with any
automated tool.

A project done by a one-man team sees a limited set of tools and has a
limited amount of schizophrenia in esthetic decisions.

When the product is ported to as many platforms as ly is you see all the
toolsets and more.  Fonts make a difference.  Screen size and eyestrain
influence choice of font and font size.  Vendor coding style influences
things too.  Apple used to be rather cavalier about code namespace, they
would use short common words for class, structure, and field symbols. 
With cocoa things are somewhat improved, NS prefixes everything new, and
method names are verbose and attempt to be meaningful.  The verbosity has
a downside tho, many invocations are multi-line, especially when localized
text is involved.

 If the standard isn't even completely defined then how could the job of
 code janitor be given to an inexperienced Frog?

Actually, its a pretty good learning experience.

 until an official LilyPond coding standard is
 fully set in stone.

IMHO that would be a mistake, for example, switch statements have a number
of ways of being presented that are effective, no one way serves all code.

 Any automatic tool will

have faults, including being unavailable on some platform now in use.

I recall a movement sometime ago to mix code and prose commentary, making
real tab stops available for the code, and also allowing illustrations. 
Guess it died a hard death.

--
Dana Emery



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Jan Nieuwenhuizen]

Op vrijdag 13-11-2009 om 17:45 uur [tijdzone +], schreef Graham
Percival:
 On Fri, Nov 13, 2009 at 04:59:20PM -, Trevor Daniels wrote:
 
  Chris Snyder wrote Friday, November 13, 2009 4:35 PM
  Graham Percival wrote:

 interesting.  is that really the GNU style?  maybe I should check.
 Or wait, maybe this is something changed in fixcc.py.  I'll check
 there.

GNU codyng style is what you get when you edit code in Emacs or
run C-x h M-x indent-region in Emacs.  That's what fix-cc.py does.

Greetings,
Jan.

-- 
Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl| http://lilypond.org



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Chris Snyder]

Graham Percival wrote:

I'm afraid that you won't get many positive responses until you
look at the previous discussion about this issue.  Again, the main
developers have been bitten by people in the past asking many
questions, spending hours explaining things to them, but then
ultimately giving up and disappearing.


Before I started looking at formatters, I did search lilypond-devel and 
the issues tracker, but didn't come up with them (other than an issue 
for automatically formatting .ly files). It looks like I didn't do an 
extensive enough search or use the correct terms. The issue that Neil 
linked to brought me up to speed (I wasn't even aware that the frogs had 
their own mailing list).



I don't want to be discouraging, but most people won't take you
seriously unless you prove that you've done your research.  I'm
sorry, I know this *does* sound discouraging... but we have had
*years* of experience with people not following through.  You know
the expression once bitten, twice shy?  for us, it's ten times
bitten, twenty times shy.


Understood, and I realize that I haven't exactly proven myself in this 
community yet. I'm also comfortable enough here now that I'm not taking 
your response personally.



I'm sorry to be discouraging -- again, I think this would be a
*fantastic* project, especially if it handles scheme as well --
but it will be a *lot* more work than you're envisioning at the
moment.


There is one thing that bugs me about this discussion (and others) - it 
seems like sometimes improvements are rejected as being not good 
enough, even if they're still an incremental improvement. Wouldn't 
running all of the C++ code through astyle still be an improvement over 
the current situation? It wouldn't prevent future formatting mistakes 
and it wouldn't help with the Scheme and ly code, but it would still be 
a step in the right direction.


Thanks,
-Chris


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Chris Snyder]

Graham Percival wrote:

1) running astyle will change lines of code.  This makes the
history harder to look at... if we want to know who wrote a
particular line (say, there seems to be a bug here; hey Joe, why
did you write if (x = 3) ?), then it will appear that *you*
were the last person to change that line of code.  Even if all you
did was run astyle on it.


That seems to me to be unavoidable - or at least not worth the cost 
(investigating whitespace-aware diff tools, etc.) of avoiding it. Since 
the commit message would be Automated formatting cleanup we would just 
go to the previous commit in the tree (looking back on the Frogs list 
discussion, I see that you suggested exactly that).



2) many programmers view code style in a highly personal,
quasi-religious manner.

...

...Han-Wen and Jan have different views...


If the standard isn't even completely defined then how could the job of 
code janitor be given to an inexperienced Frog? It seems to me that no 
one can solve this problem until an official LilyPond coding standard is 
fully set in stone. In the meantime, newbies are left wondering what 
code style they should adhere to (perhaps having to predict which dev 
will be looking at a particular patch).



Any automatic tool will probably result in everybody having to
give up at least one closely-held belief (whether it's the
supremacy of tabs, or lining arguments up after an opening brace,
or how a switch/case command looks, or whatever).  So when you
propose a tool, we need to know what it will change.  And for all
those changes, we need to be convinced that it's an ok change.


I'm going to come out of the closet here, in a manner - I'm primarily 
a Java programmer. I don't think I can count on both hands the number of 
personal formatting preferences (not to mention an intense dislike of 
C++ - but I'm not about to touch *that* dead horse) I've suspended in 
order to contribute. I'm not complaining about this - as a newcomer, 
it's my duty to adhere to established standards - but I'd like to know 
what the standards are.



Sometimes, the automatic tool will just make existing
badly-formatted code meet our own standards.  In other cases, it
*will* change the standards.  Some of us won't care; others will
care deeply.


I know I'm not in a position to credibly admonish those that have put 
countless hours into what's essentially a labor of love, but it seems to 
me that these personal holy wars often get in the way of real 
productivity (the amount of time you've expended responding to me, for 
instance). It looks to me that 99% of the coding style is agreed upon - 
is the 1% really worth all of this frustration?


How about a compromise for tabs vs. spaces: even lines use spaces, odd 
lines use tabs. I'm sure we could create an emacs rule for that.


(since you don't know me very well, let me assure you that the former 
paragraph was written with tongue firmly implanted in cheek)


Thanks, and sorry for taking up everyone's time.

-Chris


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Bertalan Fodor (LilyPondTool)]

Yes, code formatting involves fascism.

- Someone, a lead architect should decide upon rules.
- Then a tool must be used to force these rules. It shouldn't be the 
tool's rules, but the tool should support the rules defined by the lead 
developer.

- You should NOT run it on all existing files.
- You should work the formatter on every file you commit, at least on 
the lines you changed. This is the only way to prevent merge conflicts 
caused by formatting.


Bert



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Graham Percival]

On Fri, Nov 13, 2009 at 10:44:54AM -0500, Chris Snyder wrote:
 Graham Percival wrote:
 1) running astyle will change lines of code.  This makes the
 history harder to look at... if we want to know who wrote a
 particular line (say, there seems to be a bug here; hey Joe, why
 did you write if (x = 3) ?), then it will appear that *you*
 were the last person to change that line of code.  Even if all you
 did was run astyle on it.

 That seems to me to be unavoidable - or at least not worth the cost  
 (investigating whitespace-aware diff tools, etc.) of avoiding it. Since  
 the commit message would be Automated formatting cleanup we would just  
 go to the previous commit in the tree (looking back on the Frogs list  
 discussion, I see that you suggested exactly that).

Yes... but it should only be done ONCE.  We should only run this
when we're certain that we have the right tool.

If somebody thinks that astyle is the right tool, then that person
can make an argument in favor of it.  Give us the info -- what
does astyle do differently?

 2) many programmers view code style in a highly personal,
 quasi-religious manner.
 ...
 ...Han-Wen and Jan have different views...

 If the standard isn't even completely defined then how could the job of  
 code janitor be given to an inexperienced Frog? It seems to me that no  
 one can solve this problem until an official LilyPond coding standard is  
 fully set in stone. In the meantime, newbies are left wondering what  
 code style they should adhere to (perhaps having to predict which dev  
 will be looking at a particular patch).

That's why I think this is the 3rd most important task to help new
developers.

I'm not saying that astyle *isn't* the best.  I'm saying that you
need to make an argument.  Don't just say hey, I found this tool
on teh internets, somebody run it on the source tree for me!.

- what does astyle do by default?
- what options does astyle have?
- which set of options in astyle produces the smallest possible
diff with our existing code?
(don't answer the questions on the list -- go investigate them)


I did this task with Marsyas (another open-source project, albeit
oriented on audio analysis+synthesis rather than music notation).
I know what I'm talking about.  There's both technical and
diplomatic portions to this task.

(as it happens, it was a partial victory.  I managed to convince
everybody else that astyle with a custom .astylerc file was the
best choice... but they refused to let me run it on all the source
files, for the history reasons.  The final verdict was use this
for anything new, otherwise keep your grubby paws off my source
code)

 I'm going to come out of the closet here, in a manner - I'm primarily  
 a Java programmer. I don't think I can count on both hands the number of  
 personal formatting preferences (not to mention an intense dislike of  
 C++ - but I'm not about to touch *that* dead horse) I've suspended in  
 order to contribute. I'm not complaining about this - as a newcomer,  
 it's my duty to adhere to established standards - but I'd like to know  
 what the standards are.

Unfortunately, it's not really set in stone.  Yes, that makes your
job harder.

*shrug*

if it was a 10-minute task, I would have done it already.

 Sometimes, the automatic tool will just make existing
 badly-formatted code meet our own standards.  In other cases, it
 *will* change the standards.  Some of us won't care; others will
 care deeply.

 I know I'm not in a position to credibly admonish those that have put  
 countless hours into what's essentially a labor of love, but it seems to  
 me that these personal holy wars often get in the way of real  
 productivity (the amount of time you've expended responding to me, for  
 instance). It looks to me that 99% of the coding style is agreed upon -  
 is the 1% really worth all of this frustration?

I'm not asking the impossible.  Do the steps I outline above.
Then pick one particular file... ideally a file that shows all the
types of changes that the astyle+astylerc will produce.

Send the diff here.  Or maybe to the Frog list first.  :)

Give a rationale for all the changes.  It could be as simple as
umm, astyle actually conforms to the GNU standard, whereas the
current source file doesn't.  Or it might be something like it
conforms to GNU with the extra modifications made by fixcc.py.
Or maybe even something like it doesn't match GNU *or* fixcc.py,
but in this email here, Jan said that we should do XYZ, and
Han-Wen said `whatever, I don't care any more'.

I don't think the latter case will apply.  But it might!


Again, it's not impossible.  But you need to do the homework
before we can start discussing it seriously.  I repeat my claim of
10-20 hours.  Probably 4 hours playing with astyle (and/or other
tools) and experimenting with different options, and 6 hours of
discussion + reading old emails + discussion.  And doubling it
just because I double all estimates.  Oh, those estimates 

Re: Code formatter

[Graham Percival]

(sorry if it's a duplicate; email problems)

On Fri, Nov 13, 2009 at 10:44:54AM -0500, Chris Snyder wrote:
 Graham Percival wrote:
 1) running astyle will change lines of code.  This makes the
 history harder to look at... if we want to know who wrote a
 particular line (say, there seems to be a bug here; hey Joe, why
 did you write if (x = 3) ?), then it will appear that *you*
 were the last person to change that line of code.  Even if all you
 did was run astyle on it.

 That seems to me to be unavoidable - or at least not worth the cost  
 (investigating whitespace-aware diff tools, etc.) of avoiding it. Since  
 the commit message would be Automated formatting cleanup we would just  
 go to the previous commit in the tree (looking back on the Frogs list  
 discussion, I see that you suggested exactly that).

Yes... but it should only be done ONCE.  We should only run this
when we're certain that we have the right tool.

If somebody thinks that astyle is the right tool, then that person
can make an argument in favor of it.  Give us the info -- what
does astyle do differently?

 2) many programmers view code style in a highly personal,
 quasi-religious manner.
 ...
 ...Han-Wen and Jan have different views...

 If the standard isn't even completely defined then how could the job of  
 code janitor be given to an inexperienced Frog? It seems to me that no  
 one can solve this problem until an official LilyPond coding standard is  
 fully set in stone. In the meantime, newbies are left wondering what  
 code style they should adhere to (perhaps having to predict which dev  
 will be looking at a particular patch).

That's why I think this is the 3rd most important task to help new
developers.

I'm not saying that astyle *isn't* the best.  I'm saying that you
need to make an argument.  Don't just say hey, I found this tool
on teh internets, somebody run it on the source tree for me!.

- what does astyle do by default?
- what options does astyle have?
- which set of options in astyle produces the smallest possible
diff with our existing code?
(don't answer the questions on the list -- go investigate them)


I did this task with Marsyas (another open-source project, albeit
oriented on audio analysis+synthesis rather than music notation).
I know what I'm talking about.  There's both technical and
diplomatic portions to this task.

(as it happens, it was a partial victory.  I managed to convince
everybody else that astyle with a custom .astylerc file was the
best choice... but they refused to let me run it on all the source
files, for the history reasons.  The final verdict was use this
for anything new, otherwise keep your grubby paws off my source
code)

 I'm going to come out of the closet here, in a manner - I'm primarily  
 a Java programmer. I don't think I can count on both hands the number of  
 personal formatting preferences (not to mention an intense dislike of  
 C++ - but I'm not about to touch *that* dead horse) I've suspended in  
 order to contribute. I'm not complaining about this - as a newcomer,  
 it's my duty to adhere to established standards - but I'd like to know  
 what the standards are.

Unfortunately, it's not really set in stone.  Yes, that makes your
job harder.

*shrug*

if it was a 10-minute task, I would have done it already.

 Sometimes, the automatic tool will just make existing
 badly-formatted code meet our own standards.  In other cases, it
 *will* change the standards.  Some of us won't care; others will
 care deeply.

 I know I'm not in a position to credibly admonish those that have put  
 countless hours into what's essentially a labor of love, but it seems to  
 me that these personal holy wars often get in the way of real  
 productivity (the amount of time you've expended responding to me, for  
 instance). It looks to me that 99% of the coding style is agreed upon -  
 is the 1% really worth all of this frustration?

I'm not asking the impossible.  Do the steps I outline above.
Then pick one particular file... ideally a file that shows all the
types of changes that the astyle+astylerc will produce.

Send the diff here.  Or maybe to the Frog list first.  :)

Give a rationale for all the changes.  It could be as simple as
umm, astyle actually conforms to the GNU standard, whereas the
current source file doesn't.  Or it might be something like it
conforms to GNU with the extra modifications made by fixcc.py.
Or maybe even something like it doesn't match GNU *or* fixcc.py,
but in this email here, Jan said that we should do XYZ, and
Han-Wen said `whatever, I don't care any more'.

I don't think the latter case will apply.  But it might!


Again, it's not impossible.  But you need to do the homework
before we can start discussing it seriously.  I repeat my claim of
10-20 hours.  Probably 4 hours playing with astyle (and/or other
tools) and experimenting with different options, and 6 hours of
discussion + reading old emails + discussion.  And doubling it
just because I 

Re: Code formatter

[Trevor Daniels]

Chris Snyder wrote Friday, November 13, 2009 4:35 PM





Graham Percival wrote:

I know that you're thinking this is ridiculous, but unless
somebody does it, newbies will continue to face this difficulty.
This job won't get done by itself.


Yes, I do think it's ridiculous. As I understand, you're saying, 
go find a tool that makes the code conform to a standard we 
haven't defined yet.


Chris is right: if progress is to be made the rules
must be defined first.  They can be defined
incrementally; in fact some already exist.  If we
can't agree on the rules there is little point in
searching for a tool.

Trevor



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Graham Percival]

On Fri, Nov 13, 2009 at 04:59:20PM -, Trevor Daniels wrote:

 Chris Snyder wrote Friday, November 13, 2009 4:35 PM
 Graham Percival wrote:
 I know that you're thinking this is ridiculous, but unless
 somebody does it, newbies will continue to face this difficulty.
 This job won't get done by itself.

 Yes, I do think it's ridiculous. As I understand, you're saying, go 
 find a tool that makes the code conform to a standard we haven't 
 defined yet.

 Chris is right: if progress is to be made the rules
 must be defined first.  They can be defined
 incrementally; in fact some already exist.  If we
 can't agree on the rules there is little point in
 searching for a tool.

FFS!ok, **I** will start doing this investigation.

1) git pull -r; cd lily
2) astyle *.cc
3) git diff  foo.patch
4) ls -lh foo.patch
-rw-r--r-- 1 gperciva gperciva 3.4M 2009-11-13 17:14 foo.patch

hmm, that's not too optimistic.  Let's see...
--- a/lily/accidental-engraver.cc 
+++ b/lily/accidental-engraver.cc 
@@ -29,61 +29,61 @@ 
 class Accidental_entry 
 { 
 public: 
-  bool done_; 
+bool done_;


hmm, indenting variables to be 4 spaces instead of 2 spaces.
Hmm... ick, a *ton* of things in the patch look like this.  Let's
try making it 2 spaces instead.

5) git checkout *.cc
6) astyle --style=gnu

I couldn't immediately see a use 2 spaces for indents, but let's
try this gnu option!
6) git diff  foo.patch
7) ls -lh foo.patch
-rw-r--r-- 1 gperciva gperciva 2.1M 2009-11-13 17:18 foo.patch

well, it's smaller, at least.

8)  looking at a diff...
--- a/lily/accidental-engraver.cc
+++ b/lily/accidental-engraver.cc
@@ -27,18 +27,18 @@
 #include translator.icc

 class Accidental_entry
-{
-public:
-  bool done_;
+  {
+  public:
+bool done_;

interesting.  is that really the GNU style?  maybe I should check.
Or wait, maybe this is something changed in fixcc.py.  I'll check
there.

hmm... ok, that file is difficult to read.  But gives me an
idea... what if I just run fixcc.py on the output of astyle
--style=gnu ?

... run the command... git-diff... look at the patch... ok, it's
bigger now.  that sucks.  What happens if we skip astyle and just
run fixcc.py ?

... ok, it *still* gives a 3-meg patch.  This is pretty good
evidence that, despite some people's claims to the contrary,
fixcc.py is broken.  Let's give up on that.


9)  ok, back to the original let's use 2 spaces instead of 4.
  astyle --indent=spaces=2 *.cc
gperc...@sapphire:~/src/lilypond/lily$ ls -lh foo.patch 
-rw-r--r-- 1 gperciva gperciva 2.2M 2009-11-13 17:30 foo.patch

well, this is looking better.  BTW, it's interesting that the
non-GNU style works better than the GNU style.

So, what's in the diff... hmm, stuff like this:
--- a/lily/accidental-engraver.cc
+++ b/lily/accidental-engraver.cc
@@ -109,8 +109,8 @@
Accidental_engraver::update_local_key_signature (SCM new_sig)
 {
   last_keysig_ = new_sig;
   set_context_property_on_children (context (),
-   ly_symbol2scm
(localKeySignature),
-   new_sig);
+ly_symbol2scm
(localKeySignature),
+new_sig);

   Context *trans = context ()-get_parent_context ();



that looks ok to me.  (although the email might break it up).
Basically, instead of lining up
  (context
  ly_symbol2cm
it lines up
  (contest
   ly_symbol2cm

I think the original was actually a typo.  Ok.  I am comfortable
proposing (and defending) this change.

what else is there?
@@ -121,10 +121,10 @@
Accidental_engraver::update_local_key_signature (SCM new_sig)

   SCM val;
   while (trans  trans-where_defined (ly_symbol2scm
(localKeySignature), val) == trans)
-{
-  trans-set_property (localKeySignature, ly_deep_copy
   (last_keysig_));
-  trans = trans-get_parent_context ();
-}
+  {
+trans-set_property (localKeySignature, ly_deep_copy
(last_keysig_));
+trans = trans-get_parent_context ();
+  }
 }

 struct Accidental_result


aha, the dreaded where should { brace go ?  well, astyle has a
whole bunch of options to change this.  For now, I'll just make a
note that we need to discuss this.  I'll keep on going, but once
I've finished my investigations, I'll make an email thread
specifically for this example, asking what we want, and telling
people that astyle can do whatever they decide they want.

Then I can sit back with popcorn and watch the debate.  HOWEVER,
I'm not going to start that discussion unless people have a reason
to trust that I'm going to follow through.


What's another thing... aha:
@@ -152,14 +152,14 @@ struct Accidental_result
   int score () const
   {
 return need_acc ? 1 : 0
-  + need_restore ? 1 : 0;
+   + need_restore ? 1 : 0;
   }
 };

this seems like a pretty fiddly change, but whatever.  I would be
happy to defend it.



let's skip on a bit.  Hmm, there's *huge* bunches of text that's
moved one space to the right because of 

Re: Code formatter

[Bertalan Fodor (LilyPondTool)]

Forget the tool. Astyle is very configurable, but we still could need 
our own formatter (though I wouldn't like that).
Developing C++ code on Windows is practically impossible, but can be 
well done with the VirtualBox pc for which I host the ISO (see the CG :))

So it doesn't matter whether the tool is supported on Windows or not.

But first:
- what are the rules?
- and then how we force that
You can even force that with manually, that is not approving code that 
doesn't adhere, but all that can be automatized could be. So there might 
be some static code analysis tools to be used as well.



Graham Percival wrote:

On Fri, Nov 13, 2009 at 04:59:20PM -, Trevor Daniels wrote:
  

Chris Snyder wrote Friday, November 13, 2009 4:35 PM


Graham Percival wrote:
  

I know that you're thinking this is ridiculous, but unless
somebody does it, newbies will continue to face this difficulty.
This job won't get done by itself.

Yes, I do think it's ridiculous. As I understand, you're saying, go 
find a tool that makes the code conform to a standard we haven't 
defined yet.
  

Chris is right: if progress is to be made the rules
must be defined first.  They can be defined
incrementally; in fact some already exist.  If we
can't agree on the rules there is little point in
searching for a tool.



FFS!ok, **I** will start doing this investigation.

1) git pull -r; cd lily
2) astyle *.cc
3) git diff  foo.patch
4) ls -lh foo.patch
-rw-r--r-- 1 gperciva gperciva 3.4M 2009-11-13 17:14 foo.patch

hmm, that's not too optimistic.  Let's see...
--- a/lily/accidental-engraver.cc 
+++ b/lily/accidental-engraver.cc 
@@ -29,61 +29,61 @@ 
 class Accidental_entry 
 { 
 public: 
-  bool done_; 
+bool done_;



hmm, indenting variables to be 4 spaces instead of 2 spaces.
Hmm... ick, a *ton* of things in the patch look like this.  Let's
try making it 2 spaces instead.

5) git checkout *.cc
6) astyle --style=gnu

I couldn't immediately see a use 2 spaces for indents, but let's
try this gnu option!
6) git diff  foo.patch
7) ls -lh foo.patch
-rw-r--r-- 1 gperciva gperciva 2.1M 2009-11-13 17:18 foo.patch

well, it's smaller, at least.

8)  looking at a diff...
--- a/lily/accidental-engraver.cc
+++ b/lily/accidental-engraver.cc
@@ -27,18 +27,18 @@
 #include translator.icc

 class Accidental_entry
-{
-public:
-  bool done_;
+  {
+  public:
+bool done_;

interesting.  is that really the GNU style?  maybe I should check.
Or wait, maybe this is something changed in fixcc.py.  I'll check
there.

hmm... ok, that file is difficult to read.  But gives me an
idea... what if I just run fixcc.py on the output of astyle
--style=gnu ?

... run the command... git-diff... look at the patch... ok, it's
bigger now.  that sucks.  What happens if we skip astyle and just
run fixcc.py ?

... ok, it *still* gives a 3-meg patch.  This is pretty good
evidence that, despite some people's claims to the contrary,
fixcc.py is broken.  Let's give up on that.


9)  ok, back to the original let's use 2 spaces instead of 4.
  astyle --indent=spaces=2 *.cc
gperc...@sapphire:~/src/lilypond/lily$ ls -lh foo.patch 
-rw-r--r-- 1 gperciva gperciva 2.2M 2009-11-13 17:30 foo.patch


well, this is looking better.  BTW, it's interesting that the
non-GNU style works better than the GNU style.

So, what's in the diff... hmm, stuff like this:
--- a/lily/accidental-engraver.cc
+++ b/lily/accidental-engraver.cc
@@ -109,8 +109,8 @@
Accidental_engraver::update_local_key_signature (SCM new_sig)
 {
   last_keysig_ = new_sig;
   set_context_property_on_children (context (),
-   ly_symbol2scm
(localKeySignature),
-   new_sig);
+ly_symbol2scm
(localKeySignature),
+new_sig);

   Context *trans = context ()-get_parent_context ();



that looks ok to me.  (although the email might break it up).
Basically, instead of lining up
  (context
  ly_symbol2cm
it lines up
  (contest
   ly_symbol2cm

I think the original was actually a typo.  Ok.  I am comfortable
proposing (and defending) this change.

what else is there?
@@ -121,10 +121,10 @@
Accidental_engraver::update_local_key_signature (SCM new_sig)

   SCM val;
   while (trans  trans-where_defined (ly_symbol2scm
(localKeySignature), val) == trans)
-{
-  trans-set_property (localKeySignature, ly_deep_copy
   (last_keysig_));
-  trans = trans-get_parent_context ();
-}
+  {
+trans-set_property (localKeySignature, ly_deep_copy
(last_keysig_));
+trans = trans-get_parent_context ();
+  }
 }

 struct Accidental_result


aha, the dreaded where should { brace go ?  well, astyle has a
whole bunch of options to change this.  For now, I'll just make a
note that we need to discuss this.  I'll keep on going, but once
I've finished my investigations, I'll make an email thread
specifically for this example, asking what we want, 

Re: Code formatter

[Chris Snyder]

Graham Percival wrote:

Whatever.  You're giving up.  All this time I've spent trying to
help you on this was wasted.  I'm sure that more experienced
developers list are either laughing at me, or shaking
their heads sadly... oh that Graham, he's trying to help the
beginners, but he still doesn't understand that it's just not
worth it


I'm not giving up. I would be happy to find and configure the proper 
tooling - automating it, even - if given a consistent, consensus-driven 
style standard - which doesn't currently exist.


I'd be happy to start posting messages to the mailing list with subjects 
like Allow tabs in source code? and Bracket alignment, but I don't 
think many people would appreciate the noise. Also, it seems to me that, 
on some issues at least, the discussion has already occurred and is 
deadlocked.


You're approaching this as if it's a technical issue. As of now, it's 
not. I don't have the standing in the community to resolve the social 
issues that must be dealt with first.


As an aside, there is a Windows binary available for download from the 
astyle website.


-Chris


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Carl Sorensen]

On 11/13/09 9:59 AM, Trevor Daniels t.dani...@treda.co.uk wrote:

 
 
 Chris Snyder wrote Friday, November 13, 2009 4:35 PM
 
 
 Graham Percival wrote:
 I know that you're thinking this is ridiculous, but unless
 somebody does it, newbies will continue to face this difficulty.
 This job won't get done by itself.
 
 Yes, I do think it's ridiculous. As I understand, you're saying,
 go find a tool that makes the code conform to a standard we
 haven't defined yet.
 
 Chris is right: if progress is to be made the rules
 must be defined first.  They can be defined
 incrementally; in fact some already exist.  If we
 can't agree on the rules there is little point in
 searching for a tool.

The rules are already defined (albeit unsatisfactorily in my opinion):

Do whatever emacs does.

Yes, this is unsatisfactory, because many of us don't use emacs.
Nevertheless, it is the defined standard.

Here is some background on the issue:

http://lists.gnu.org/archive/html/lilypond-devel/2009-04/msg00110.html

http://thread.gmane.org/gmane.comp.gnu.lilypond.devel/22855/

Jan believes that code formatting standards should be no more restrictive
than the GNU standards.  So if we want to make the standards more explicit,
we should handle that by proposing changes on emacs-devel, rather than by
creating LilyPond-specific standards.

As he points out, LilyPond *is* a GNU software package, so it makes sense
for GNU tools to be the standard tools.

Unfortunately, this does cause some grief with non-Linux developers.
However, it is quite easy to set up a Linux VM on Windows or on OSX.  So
those of us who use non GNU/Linux systems can get access if we are willing.

This same issue is relevant in the discussion about going to Lua.  Lua is
not GNU software.  It does use the MIT license, which is GPL compatible,
according to the FSF.

It seems to me that we don't have support from the core developers to move
to a more Windows-friendly development environment.  Of course, since
LilyPond is free software, anybody could develop a derivative work that was
developed in the tools of their choice on Windows.  But it would be a huge
undertaking, and it would split the development community.

So I think we are where we are, and are likely to stay there:  GNU/Linux
is the primary development platform, and the standards will remain as
GNU standards.

I'm not trying to dump on anybody.  I'm just trying to explain the world as
I see it.  We can expend a bunch of energy trying to change the world, or we
can expend energy figuring out how to work in the current world.  For me,
that means trying to work in the current world.  Hence, the importance of
the Contributors' Guide, and my efforts to improve it.

Thanks,

Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Werner LEMBERG]

 The rules are already defined (albeit unsatisfactorily in my opinion):
 
 Do whatever emacs does.

Then, for goodness' sake, why not write a small elisp program to use
Emacs in batch mode on the command line (yes, this is possible) to
format one or more files?  Emacs runs on Windows too, and nobody would
be forced to actually *use* it as an editor...


Werner


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Graham Percival]

On Fri, Nov 13, 2009 at 08:01:41PM +0100, Werner LEMBERG wrote:
 
  The rules are already defined (albeit unsatisfactorily in my opinion):
  
  Do whatever emacs does.
 
 Then, for goodness' sake, why not write a small elisp program to use
 Emacs in batch mode on the command line (yes, this is possible) to
 format one or more files?  Emacs runs on Windows too, and nobody would
 be forced to actually *use* it as an editor...

I asked for this sometime in Spring 2009, IIRC.  I think one
person replied saying yeah, that's easy, but didn't actually do
anything.

Cheers,
- Graham



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Nicolas Sceaux]

Le 13 nov. 2009 à 20:01, Werner LEMBERG a écrit :

 
 The rules are already defined (albeit unsatisfactorily in my opinion):
 
 Do whatever emacs does.
 
 Then, for goodness' sake, why not write a small elisp program to use
 Emacs in batch mode on the command line (yes, this is possible) to
 format one or more files?  Emacs runs on Windows too, and nobody would
 be forced to actually *use* it as an editor...

A quick google search gives:

emacs -batch sample.cc --eval '(indent-region (point-min) (point-max) nil)' -f 
save-buffer

But there are plenty of examples.

Nicolas



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Graham Percival]

On Fri, Nov 13, 2009 at 01:17:43PM -0500, Chris Snyder wrote:
 You're approaching this as if it's a technical issue. As of now, it's  
 not. I don't have the standing in the community to resolve the social  
 issues that must be dealt with first.

... you didn't learn anything from the long email I wrote?


As I said before, it's a mixture of technical and diplomatic.  But
before you can get diplomatic, you need to find a tool that
produces what you consider to be good code.  I want you to say I
believe that astyle 1.22 with these command-line options produces
good code.

Then I'll look at the output.  If I find something that I
question, then I'll ask if you really think that's good.  For
example, changing
   int foo
 = 3;
into
   int foo
   = 3;
is IMO questionable.

If you reply gee, I didn't notice that, then it's bad.  I lose
faith in your judgement.  If you say oh come on, who cares?  it's
close enough, right? then I lose even more faith.

However, if -- at the beginning -- you say I think that astyle
1.22 with these options produces good code, apart from this one
instance in the lilypond source code, which looks like this...
then I respect you.  You've looked into the matter.  You've warned
me of a potential downside to your tool.


Now, if you can say I looked at tools x, y, and z.  Y with
options a,b,c comes the closest to our existing code.
Unfortunately, Y has questionable output for these two bits of
source code.  On the other hand, if we rewrote one of those lines
of code, tool Y would produce good output.  In addition, tool Y is
eaiser to use than emacs, is only 500 kb instead of the 30 Mb that
emacs takes.  I therefore propose that we use tool Y to format the
C++ lilypond source code...

If you say the above, then I'm impressed.  You've investigated
other tools.  You're aware of the downsides of your chosen tool.
You've warned us ahead of time, so we're not unpleasantly
surprised.

We then spend a few days discussing it, and (probably) decide to
adopt it.  A few people disagree, but the argument in favor of it
is clear and honest.

- Graham


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Graham Percival]

On Fri, Nov 13, 2009 at 11:23:55AM -0700, Carl Sorensen wrote:
 Jan believes that code formatting standards should be no more restrictive
 than the GNU standards.

By the way, if somebody has a compelling argument why we should
differ from the GNU standards, I'm willing to go up against Jan.
But before I do that, I need to be *convinced* that the
alternative is right.

 This same issue is relevant in the discussion about going to Lua.  Lua is
 not GNU software.  It does use the MIT license, which is GPL compatible,
 according to the FSF.

That's not an issue.  The issue is that rewriting lilypond would
take thousands of hours of work, and nobody wants to do that work.
Besides, I really thought that the Lua-talk was a joke.

Some people at my university want to rewrite lilypond in Haskell
-- again, they weren't serious about it.  The notion was just a
hey, wouldn't it be cool if...? thing.

 It seems to me that we don't have support from the core developers to move
 to a more Windows-friendly development environment.

That's absolutely false.  (yes, I'm going to speak on behalf of
Han-Wen and Jan here, as well as from myself)

The core developers have a better estimate of the enormous amount
of work it would take to rewrite lilypond in lua, java, or
whatever was being proposed.  Also possibly rewriting it to avoid
using various libraries... so maybe re-implementing fontforge,
pango, etc etc etc.

One reason behind the switch to a new build system (waf) is
precisely to make things easier for windows developers.  Ok, we're
doing the doc stuff first -- but if that works well, then we'll do
the actual executable build system as well.

How many people are helping with that?  ... yeah, thought so.


If anybody has a CONCRETE proposal on how to make things easier
for non-Linux developers... along with the manpower required to
IMPLEMENT those proposals... I'm more than willing to listen.  If
their proposal includes a relatively minor amount of work from the
core developers, I'm willing to do it.  If the proposal boils down
to hey, how about you guys rewrite it in visual basic, while I
continue to complain about bugs and the lack of a wiki... then
they won't get anywhere.

Cheers,
- Graham


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Neil Puttock]

2009/11/13 Graham Percival gra...@percival-music.ca:

 If you could choose one such example, and add it somewhere to the
 CG similar to this:
 http://lilypond.org/doc/v2.13/Documentation/contributor/Sectioning-commands
 (bottom of the page)

 that would be awesome.

It's already there in section 8.5.5 (you added it in July).

Its only limitation is the way it indiscriminately reformats comments,
especially those including illustrations.

Regards,
Neil


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Carl Sorensen]

On 11/13/09 12:39 PM, Graham Percival gra...@percival-music.ca wrote:

 On Fri, Nov 13, 2009 at 08:18:04PM +0100, Nicolas Sceaux wrote:
 Le 13 nov. 2009 à 20:01, Werner LEMBERG a écrit :
 
 Then, for goodness' sake, why not write a small elisp program to use
 Emacs in batch mode on the command line (yes, this is possible) to
 format one or more files?  Emacs runs on Windows too, and nobody would
 be forced to actually *use* it as an editor...
 
 A quick google search gives:
 
 emacs -batch sample.cc --eval '(indent-region (point-min) (point-max) nil)'
 -f save-buffer
 
 But there are plenty of examples.
 
 If you could choose one such example, and add it somewhere to the
 CG similar to this:
 http://lilypond.org/doc/v2.13/Documentation/contributor/Sectioning-commands
 (bottom of the page)

That specific example is already in section 8.5 with a note that it needs to
be confirmed on -devel.

http://lilypond.org/doc/v2.13/Documentation/contributor/Code-style#Code-styl
e

I've moved it in the current git sources, but it's still in section 8.5,
specifically 8.5.5 Indenting files with emacs in script mode.

Thanks,


Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Ian Hulin]

Hi Carl and list,

Carl Sorensen wrote:



On 11/13/09 9:59 AM, Trevor Daniels t.dani...@treda.co.uk wrote:



Chris Snyder wrote Friday, November 13, 2009 4:35 PM

Graham Percival wrote:

I know that you're thinking this is ridiculous, but unless
somebody does it, newbies will continue to face this difficulty.
This job won't get done by itself.

Yes, I do think it's ridiculous. As I understand, you're saying,
go find a tool that makes the code conform to a standard we
haven't defined yet.

Chris is right: if progress is to be made the rules
must be defined first.  They can be defined
incrementally; in fact some already exist.  If we
can't agree on the rules there is little point in
searching for a tool.


The rules are already defined (albeit unsatisfactorily in my opinion):

Do whatever emacs does.

Yes, this is unsatisfactory, because many of us don't use emacs.
Nevertheless, it is the defined standard.


In which case we need to understand, note and detail whatever emacs
does in the CG, so users of other editors can set their environment up
not to get into trouble (this is the voice of bitter experience speaking
here).
Unfortunately emacs has language-sensitive information in its various
mode codes, so that it can be intelligent about indenting things to
the right level when you, as the programmer do something like hit the
enter key and then press TAB. This presumably is hidden in the lisp
code which defines the modes for C++ and Scheme.

There are lots of variables here as
Graham pointed out in his one-man role-play earlier in this thread.
Things like:
o Are tab characters used, or does the editor convert these to spaces?
o What is the maximum number of spaces per tab stop?
o What is the indentation size for the language in which the developer
 is currently programming?
 Note: We've got three main language environments when coding for
Lilypond:
C++, Scheme, Lilypond source, and in addition we've got to cope with
Scheme embedded in Lilypond source [e.g. init.ly].  This last one
confuses the hell out of emacs as it expects all Scheme language code to
be in a *.scm file.
This stuff is hidden in the emacs mode definitions and we need it in
black and white in the CG for users of other editors (e.g. JEdit,
Frescobaldi, vim) so they can configure their environments correctly.

Are these assumptions correct?
o C++ - Tabstops at every eighth character, indent size is four
characters
o Scheme - Tabstops at every eighth character, indent size is two characters
o Lilypond - Tabstops at every eighth character, indent size is four
characters.
o Overall club rules -
oo Whitespace should be zero or more tab characters followed by any
spaces necessary to indent to the correct level.
oo Thou shalt not have whitespace followed by a newline or the git
gremlins will come and drag out of your bed at 4 a.m. and eat you alive.
oo Whatever emacs does seems to imply we don't want the editor to
convert tab characters to spaces.

Bert and Wilbert (and the man or woman who can program vim, if (s)he's
out there),
is there any way we can get JEdit+LilyPondTool and Frescobaldi (and vim)
to do
whatever Emacs does for Lilypond, Scheme and C++?

Carl, I'm attempting to write a Chapter for CG to outline the bare bones 
of what new developers can get involved in (a sort of 'Intended 
Audience' Chapter), and I'd like to be able to include answers to the 
questions I've asked here.


Cheers,

Ian Hulin





___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Graham Percival]

On Fri, Nov 13, 2009 at 07:46:59PM +, Neil Puttock wrote:
 2009/11/13 Graham Percival gra...@percival-music.ca:
 
  If you could choose one such example, and add it somewhere to the
  CG similar to this:
  http://lilypond.org/doc/v2.13/Documentation/contributor/Sectioning-commands
  (bottom of the page)
 
 It's already there in section 8.5.5 (you added it in July).

Ok.  Carl mentioned that it had a note asking for confirmation.
Could somebody confirm that it works?

 Its only limitation is the way it indiscriminately reformats comments,
 especially those including illustrations.

Really?  I could understand indenting comments, but it actually
changes inside those?  That's icky.  :(

Would it be worth adapting _ as an alternative to spaces inside
illustrations inside comments, just to avoid this problem?
Stating that the code style is whatever emacs does, as long as
you manually revert its formatting in areas X Y and Z is getting
really iffy.

Cheers,
- Graham


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Neil Puttock]

2009/11/13 Graham Percival gra...@percival-music.ca:

 Would it be worth adapting _ as an alternative to spaces inside
 illustrations inside comments, just to avoid this problem?
 Stating that the code style is whatever emacs does, as long as
 you manually revert its formatting in areas X Y and Z is getting
 really iffy.

It appears to be OK so long as there's no space at the start of any
line inside the comment; for example, in lookup.cc, there's a fine
ascii art figure for round_filled_box (), which uses an asterisk on
each line to prevent the reformatting.

Regards,
Neil


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Carl Sorensen]

On 11/13/09 4:36 PM, Neil Puttock n.putt...@gmail.com wrote:

 2009/11/13 Graham Percival gra...@percival-music.ca:
 
 Would it be worth adapting _ as an alternative to spaces inside
 illustrations inside comments, just to avoid this problem?
 Stating that the code style is whatever emacs does, as long as
 you manually revert its formatting in areas X Y and Z is getting
 really iffy.
 
 It appears to be OK so long as there's no space at the start of any
 line inside the comment; for example, in lookup.cc, there's a fine
 ascii art figure for round_filled_box (), which uses an asterisk on
 each line to prevent the reformatting.

OK, so we could add this to the section on Comments in the CG.

Thanks,

Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Graham Percival]

On Fri, Nov 13, 2009 at 11:24:15PM +, Ian Hulin wrote:
 Hi Carl and list,

 Carl Sorensen wrote:

 Do whatever emacs does.

 In which case we need to understand, note and detail whatever emacs
 does in the CG, so users of other editors can set their environment up
 not to get into trouble (this is the voice of bitter experience speaking
 here).

No.  That road leads to nowhere.

The answer is to install emacs, then run the one-line command (I
recommend making it a shell script) to format your code before you
make a patch.

For your real work, use whatever editor you want, with whatever
indentation you like.  When you're ready to send a patch, run your
emacs-format command and *then* make a patch.

Anything else -- other than having a *real* code formatting
program, like astyle... again, it's a 10-20 hour job; not
impossible! -- is doomed to failure.

 Carl, I'm attempting to write a Chapter for CG to outline the bare bones  
 of what new developers can get involved in (a sort of 'Intended  
 Audience' Chapter), and I'd like to be able to include answers to the  
 questions I've asked here.

I'm not certain where you're intending to go with this.  As I keep
on saying, I haven't touched a line of lilypond code in about 4-5
years, but nobody would doubt that I've been enormously useful.
There are *tons* of jobs that involve no programming.

In all seriousness, I could split my jobs amongst 5 people doing
normal open-source work hours (i.e. not like me).  And I would
probably *still* be required to do various non-programming tasks.
But if I wasn't required for those jobs any more, then I could
finally do lilypond programming.  I'd love to do that stuff!
Please, please, start taking these crap jobs off my shoulders.

Especially anybody complaining about indentation or how hard it is
to figure out how to start or blah blah blah.

Cheers,
- Graham


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Graham Percival]

I'm amused that formatting everything in lily/*.cc with emacs
produces a 127 Kb diff.

Cheers,
- Graham


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Carl Sorensen]

On 11/13/09 4:24 PM, Ian Hulin i...@hulin.org.uk wrote:

 Hi Carl and list,
 
 Carl Sorensen wrote:
 
 
 On 11/13/09 9:59 AM, Trevor Daniels t.dani...@treda.co.uk wrote:
 
 
 Chris Snyder wrote Friday, November 13, 2009 4:35 PM
 Graham Percival wrote:
 I know that you're thinking this is ridiculous, but unless
 somebody does it, newbies will continue to face this difficulty.
 This job won't get done by itself.
 Yes, I do think it's ridiculous. As I understand, you're saying,
 go find a tool that makes the code conform to a standard we
 haven't defined yet.
 Chris is right: if progress is to be made the rules
 must be defined first.  They can be defined
 incrementally; in fact some already exist.  If we
 can't agree on the rules there is little point in
 searching for a tool.
 
 The rules are already defined (albeit unsatisfactorily in my opinion):
 
 Do whatever emacs does.
 
 Yes, this is unsatisfactory, because many of us don't use emacs.
 Nevertheless, it is the defined standard.
 
 In which case we need to understand, note and detail whatever emacs
 does in the CG, so users of other editors can set their environment up
 not to get into trouble (this is the voice of bitter experience speaking
 here).

This is probably OK, as long as we don't identify it as the standard.  That
is, we identify these rules as ways to achieve compatibility with the
standard, rather than as the standard itself.

Really, the correct way to do it is to run code through emacs (although
this doesn't apply to Scheme in .ly files, as emacs won't recognize them
as Scheme unless we put a Scheme header on the file (which might not be a
bad idea for (yet to be standardised) .ily files).

 Unfortunately emacs has language-sensitive information in its various
 mode codes, so that it can be intelligent about indenting things to
 the right level when you, as the programmer do something like hit the
 enter key and then press TAB. This presumably is hidden in the lisp
 code which defines the modes for C++ and Scheme.
 
 There are lots of variables here as
 Graham pointed out in his one-man role-play earlier in this thread.
 Things like:
 o Are tab characters used, or does the editor convert these to spaces?

emacs can behave either way.  IIUC, the standard is ambivalent concerning
tabs vs. spaces.  I proposed spaces only, Han-Wen agreed, and Jan said fine
as long as it's made part of the GNU standard.  So it's developer's choice.

When I edit code, I convert tabs to spaces in my changed lines, and nobody
has ever complained about that.


 o What is the maximum number of spaces per tab stop?

GNU standard is 8 spaces per tab.

 o What is the indentation size for the language in which the developer
   is currently programming?
   Note: We've got three main language environments when coding for
 Lilypond:
 C++, Scheme, Lilypond source, and in addition we've got to cope with
 Scheme embedded in Lilypond source [e.g. init.ly].  This last one
 confuses the hell out of emacs as it expects all Scheme language code to
 be in a *.scm file.
 This stuff is hidden in the emacs mode definitions and we need it in
 black and white in the CG for users of other editors (e.g. JEdit,
 Frescobaldi, vim) so they can configure their environments correctly.
 
 Are these assumptions correct?
 o C++ - Tabstops at every eighth character, indent size is four
 characters

Yes, as far as I can tell.

 o Scheme - Tabstops at every eighth character, indent size is two characters

Tabstops, yes.  Other rules, no.

There are specific indentations for let blocks.

In general, indentation for lists puts all list elements at the same level
(which is a one-space indent for an the second element of a list if it's on
a different line than the first element of the list).

Since we're talking about unofficial rules aimed at being compatible with
the standard whatever emacs does, I think we could refer to some
unofficial rules that teach proper scheme indenting (although we're on
shaky ground here, I admit).

Some references that have helped me:

http://community.schemewiki.org/?scheme-style  (my favorite)

http://www.cs.indiana.edu/proglang/scheme/indentation.html (some additional
explanations)

 o Lilypond - Tabstops at every eighth character, indent size is four
 characters.

No -- Lilypond indent is two characters.  LilyPond coding style is *not*
whatever emacs does.  It's already defined in the CG.

 o Overall club rules -
 oo Whitespace should be zero or more tab characters followed by any
 spaces necessary to indent to the correct level.
 oo Thou shalt not have whitespace followed by a newline or the git
 gremlins will come and drag out of your bed at 4 a.m. and eat you alive.

oo Thou shalt not have space followed by tab or the git gremlins will get
you as well.  I don't know if emacs fixes this kind of whitespace error
or not.

 oo Whatever emacs does seems to imply we don't want the editor to
 convert tab characters to spaces.

If you want to, you may.  emacs has 

Re: Code formatter

[Carl Sorensen]

On 11/13/09 4:42 PM, Graham Percival gra...@percival-music.ca wrote:

 I'm amused that formatting everything in lily/*.cc with emacs
 produces a 127 Kb diff.

Actually, that doesn't sound too bad to me, given the amount of code in
lily/*.cc and the lack of janitorial work we've had on the code.

Thanks,

Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Graham Percival]

On Fri, Nov 13, 2009 at 04:52:48PM -0700, Carl Sorensen wrote:
 On 11/13/09 4:42 PM, Graham Percival gra...@percival-music.ca wrote:
 
  I'm amused that formatting everything in lily/*.cc with emacs
  produces a 127 Kb diff.
 
 Actually, that doesn't sound too bad to me, given the amount of code in
 lily/*.cc and the lack of janitorial work we've had on the code.

I didn't say it was _bad_, just _amusing_.  Most of the patch is
comments...
-   */
+  */
 /*
-  all-font-metrics-scheme.cc -- implement bindings for
-  All_font_metrics.
+   all-font-metrics-scheme.cc -- implement bindings for
+   All_font_metrics.

stuff like that.  (WTF? it's trying to properly indent a /*
block?!?!)

Oh, and there's lots of
 MAKE_SCHEME_CALLBACK (Axis_group_interface, print, 1)
-SCM
+  SCM

bits.


Cheers,
- Graham


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Neil Puttock]

2009/11/13 Graham Percival gra...@percival-music.ca:

 Oh, and there's lots of
  MAKE_SCHEME_CALLBACK (Axis_group_interface, print, 1)
 -SCM
 +  SCM

My emacs doesn't do this. :)

IIRC, you mentioned this before; I think it's to do with (your) emacs
expecting a colon at the end of the macro (which isn't strictly
necessary).

Regards,
Neil


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Neil Puttock]

2009/11/14 Neil Puttock n.putt...@gmail.com:

 IIRC, you mentioned this before; I think it's to do with (your) emacs
 expecting a colon at the end of the macro (which isn't strictly
 necessary).

D'oh.  I mean semicolon of course. :)


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Graham Percival]

On Sat, Nov 14, 2009 at 12:03:52AM +, Neil Puttock wrote:
 2009/11/13 Graham Percival gra...@percival-music.ca:
 
  Oh, and there's lots of
   MAKE_SCHEME_CALLBACK (Axis_group_interface, print, 1)
  -SCM
  +  SCM
 
 My emacs doesn't do this. :)

Joy of joys...
gperc...@sapphire:~$ emacs --version
GNU Emacs 21.4.1

I'm guessing that you're on 22 ?  Well, only one of those can be
the definitive standard.  I guess we should declare emacs 22 to be
this?  :(


I want an independent code formatter more and more... :(
(but that doesn't mean that I'll relax my standards (no pun
intended) on this issue)

Cheers,
- Graham


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Trevor Daniels]

Graham Percival wrote Saturday, November 14, 2009 12:10 AM



On Sat, Nov 14, 2009 at 12:03:52AM +, Neil Puttock wrote:

2009/11/13 Graham Percival gra...@percival-music.ca:

 Oh, and there's lots of
 MAKE_SCHEME_CALLBACK (Axis_group_interface, print, 1)
 -SCM
 + SCM

My emacs doesn't do this. :)


Joy of joys...
gperc...@sapphire:~$ emacs --version
GNU Emacs 21.4.1

I'm guessing that you're on 22 ?  Well, only one of those can be
the definitive standard.  I guess we should declare emacs 22 to be
this?  :(


If the standard is whatever emacs does then it may
well change with emacs releases.  Seems a silly standard
to me, but then I'm not (yet) a developer.


I want an independent code formatter more and more... :(
(but that doesn't mean that I'll relax my standards (no pun
intended) on this issue)


No.  You need an independent standard.  A formatter can
come later.

Trevor



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Werner LEMBERG]

[using cc-mode for automatically formatting C++ code of lilypond]

 IIRC, you mentioned this before; I think it's to do with (your)
 emacs expecting a colon at the end of the macro (which isn't
 strictly necessary).

 D'oh.  I mean semicolon of course. :)

In case we are going to automatically check the formatting of the C++
stuff with a Makefile target, I suggest that the proper .el files
should be directly added to lilypond since (a) C mode is under
constant improvement and (b) to reduce the dependency on certain Emacs
or XEmacs versions.

BTW, its author Alan Mackenzie is very responsive, and is certainly
willing to assist in case of problems.

Unfortunately, on the home page of the cc-mode project

  http://cc-mode.sourceforge.net/

the CVS repository appears not to be up to date compared to the
various fixes he has applied to the Emacs CVS.

Alan, what do you suggest?


Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Graham Percival]

On Thu, Nov 12, 2009 at 05:52:30PM -0500, Chris Snyder wrote:
 After the on-going discussion that included talk about formatting, I did  
 a quick search for automatic code formatters, starting with one for the  
 C++ code (I think it's reasonable to expect to use a different formatter  
 for each programming language). I came across one - astyle  
 http://astyle.sourceforge.net - that has the GNU style built in and is  
 painless to use. I gave it a try, and it seems to work quite well.

 I'd be willing to run all of the C++ code through astyle and provide a  
 patch, but it seems like it would be easier if someone with push access  
 to git would do it. Any takers?

Woah there, cowboy.  Slow down!

It's not going to be that easy.  At a rough guess, I'd say that
the code formatter task will take 10-20 hours.  Seriously.

- do we really want separate tools?   (no, so is it impossible to
  have a single tool that does both comes to mind)
- what does astyle do differently than the current code?
- what *is* the current standard, by the way?
   (hint: the answer appears to be whatever emacs does, plus a
random python script that few people know about, and also a
special dance depending on the phase of the moon)

I'm afraid that you won't get many positive responses until you
look at the previous discussion about this issue.  Again, the main
developers have been bitten by people in the past asking many
questions, spending hours explaining things to them, but then
ultimately giving up and disappearing.


I don't want to be discouraging, but most people won't take you
seriously unless you prove that you've done your research.  I'm
sorry, I know this *does* sound discouraging... but we have had
*years* of experience with people not following through.  You know
the expression once bitten, twice shy?  for us, it's ten times
bitten, twenty times shy.

I'm sorry to be discouraging -- again, I think this would be a
*fantastic* project, especially if it handles scheme as well --
but it will be a *lot* more work than you're envisioning at the
moment.

Cheers,
- Graham


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Neil Puttock]

2009/11/12 Chris Snyder csny...@adoromusicpub.com:
 After the on-going discussion that included talk about formatting, I did a
 quick search for automatic code formatters, starting with one for the C++
 code (I think it's reasonable to expect to use a different formatter for
 each programming language). I came across one - astyle
 http://astyle.sourceforge.net - that has the GNU style built in and is
 painless to use. I gave it a try, and it seems to work quite well.

Graham's mentioned it in the other thread, but there's a bug tracker
issue for this here:

http://code.google.com/p/lilypond/issues/detail?id=746

There's a script for beautifying C++ code here:
scripts/auxiliar/fixcc.py, but it appears to be a bit out of date
(certainly when I tested it earlier this year, it didn't match the
average formatting we have currently).

Regards,
Neil


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Code formatter

[Bertalan Fodor]

I think that the question is not whether we want to use a code formatter but 
which one. Ideally applied automatically when pushing. 
Also, is there a tool for c++ like checkstyle and pmd in the java world? That 
could check for formatting issues and code smells and bad practices.

  Original message  
From: Graham Percival gra...@percival-music.ca
Sent: 12 Nov 2009 15:03 -08:00
To: Chris Snyder csny...@adoromusicpub.com
Cc: lilypond-devel lilypond-devel@gnu.org
Subject: Re: Code formatter

On Thu, Nov 12, 2009 at 05:52:30PM -0500, Chris Snyder wrote:
 After the on-going discussion that included talk about formatting, I did  
 a quick search for automatic code formatters, starting with one for the  
 C++ code (I think it's reasonable to expect to use a different formatter  
 for each programming language). I came across one - astyle  
 http://astyle.sourceforge.net - that has the GNU style built in and is  
 painless to use. I gave it a try, and it seems to work quite well.

 I'd be willing to run all of the C++ code through astyle and provide a  
 patch, but it seems like it would be easier if someone with push access  
 to git would do it. Any takers?

Woah there, cowboy.  Slow down!

It's not going to be that easy.  At a rough guess, I'd say that
the code formatter task will take 10-20 hours.  Seriously.

- do we really want separate tools?   (no, so is it impossible to
  have a single tool that does both comes to mind)
- what does astyle do differently than the current code?
- what *is* the current standard, by the way?
   (hint: the answer appears to be whatever emacs does, plus a
random python script that few people know about, and also a
special dance depending on the phase of the moon)

I'm afraid that you won't get many positive responses until you
look at the previous discussion about this issue.  Again, the main
developers have been bitten by people in the past asking many
questions, spending hours explaining things to them, but then
ultimately giving up and disappearing.


I don't want to be discouraging, but most people won't take you
seriously unless you prove that you've done your research.  I'm
sorry, I know this *does* sound discouraging... but we have had
*years* of experience with people not following through.  You know
the expression once bitten, twice shy?  for us, it's ten times
bitten, twenty times shy.

I'm sorry to be discouraging -- again, I think this would be a
*fantastic* project, especially if it handles scheme as well --
but it will be a *lot* more work than you're envisioning at the
moment.

Cheers,
- Graham


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel





___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel