Re: Problem running makelsr.py

[Phil Holmes]

- Original Message - 
From: "Graham Percival" 

To: "James" ; "Phil Holmes" 
Cc: "Devel" 
Sent: Sunday, April 15, 2012 10:24 PM
Subject: Re: Problem running makelsr.py



On Sun, Apr 15, 2012 at 10:18:41PM +0100, James wrote:

james@jameslilydev2:~/lilypond-git$ ./scripts/auxiliar/makelsr.py
Traceback (most recent call last):
  File "./scripts/auxiliar/makelsr.py", line 56, in 
TAGS = os.listdir (in_dir)
OSError: [Errno 2] No such file or directory: ''



I cannot see any change to this script recently,


Phil made a recent change to avoid explicitly giving the tags, but
that change isn't happy with a local makelsr.py update.  He may be
able to extend this to local files, but I suspect that the easiest
fix will be to revert his change and just manually alter the TAGS
definition.

- Graham



I'll fix this later.

--
Phil Holmes



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

PATCH: Countdown to 20120417

[Colin Campbell]

For 20:00 MDT Tuesday April 17

Critical
Issue 2468 
: augmentation 
dot of a moved rest is placed on a line - R6035053 



Documentation:
Issue 2478 
: Patch: Web: 
Add more 'Concerts' to introduction.itexi - R6007048 

Issue 2481 
: Patch: Doc: 
CG - Update of Quick Start section - R6031053 



Cheers,

Colin

--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )

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

Read error from 'delta' in Git for staging

[James]

Hello,

I've noticed an problem on my git when I tried to checkout staging and
then git pull -r.

--snip--
james@jameslilydev2:~/lilypond-git$ git status
# On branch master
nothing to commit (working directory clean)
james@jameslilydev2:~/lilypond-git$ git checkout staging
error: failed to read object d3eee73c6d278425bcf694c7bf221dc334bd2a5f
at offset 434935 from
.git/objects/pack/pack-0b0c25e2ea4c8652fd7fea0ea862c9d733110161.pack
Switched to branch 'staging'
Your branch is behind 'origin/staging' by 9 commits, and can be fast-forwarded.
james@jameslilydev2:~/lilypond-git$ git pull -r
First, rewinding head to replay your work on top of it...
error: failed to read delta base object
d3eee73c6d278425bcf694c7bf221dc334bd2a5f at offset 434935 from
.git/objects/pack/pack-0b0c25e2ea4c8652fd7fea0ea862c9d733110161.pack
Fast-forwarded staging to f1defa51a982cf769172cfcdd6b2612608ba2746.
james@jameslilydev2:~/lilypond-git$ gitk
james@jameslilydev2:~/lilypond-git$ lily-git.tcl
james@jameslilydev2:~/lilypond-git$ git branch
  master
* staging
  test-staging
james@jameslilydev2:~/lilypond-git$ git pull -r
Current branch staging is up to date.
--snip--

As you can see if I keep doing a git pull -r the error 'goes away'.

This is my patchy VM but I get no physical device (disk read errors)
either on the VM or the underlying host.

As Master and Staging are both on the same commit and because read
errors are always worrying (especially to someone who works in the
Storage Industry),

Perhaps this is overkill, but there isn't anything urgent on, and I
have backups of this VM - if anyone wants me to do 'stuff' on this
install - I'm going to blow my complete VM away, reinstall LilyDev and
download $LILYPOND_GIT from scratch.

This will take an hour or so on my connection, so Patchy merge won't
run until I get up tomorrow morning.

James

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

Re: Problem running makelsr.py

[James]

Graham,

On 15 April 2012 22:24, Graham Percival  wrote:
> On Sun, Apr 15, 2012 at 10:18:41PM +0100, James wrote:
>> james@jameslilydev2:~/lilypond-git$ ./scripts/auxiliar/makelsr.py
>> Traceback (most recent call last):
>>   File "./scripts/auxiliar/makelsr.py", line 56, in 
>>     TAGS = os.listdir (in_dir)
>> OSError: [Errno 2] No such file or directory: ''
>
>> I cannot see any change to this script recently,
>
> Phil made a recent change to avoid explicitly giving the tags, but
> that change isn't happy with a local makelsr.py update.  He may be
> able to extend this to local files, but I suspect that the easiest
> fix will be to revert his change and just manually alter the TAGS
> definition.

Thanks, I thought I was going mad. I haven't done a snippet/new for a
while and couldn't recall anything changing.

This will hold up Pavel's checkin but there is nothing riding on it,
so it can wait.

james

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

Re: Problem running makelsr.py

[Graham Percival]

On Sun, Apr 15, 2012 at 10:18:41PM +0100, James wrote:
> james@jameslilydev2:~/lilypond-git$ ./scripts/auxiliar/makelsr.py
> Traceback (most recent call last):
>   File "./scripts/auxiliar/makelsr.py", line 56, in 
> TAGS = os.listdir (in_dir)
> OSError: [Errno 2] No such file or directory: ''

> I cannot see any change to this script recently,

Phil made a recent change to avoid explicitly giving the tags, but
that change isn't happy with a local makelsr.py update.  He may be
able to extend this to local files, but I suspect that the easiest
fix will be to revert his change and just manually alter the TAGS
definition.

- Graham

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

Problem running makelsr.py

[James]

Hello,

While trying to run makelsr.py at the top level of the tree I get this error.

--snip--

james@jameslilydev2:~/lilypond-git$ ./scripts/auxiliar/makelsr.py
Traceback (most recent call last):
  File "./scripts/auxiliar/makelsr.py", line 56, in 
TAGS = os.listdir (in_dir)
OSError: [Errno 2] No such file or directory: ''

--snip--

Am I missing something here?

I cannot see any change to this script recently,

I have attached a formatted patch (which I don't think is the cause -
I get the same issue when I run this on a 'clean' tree) on Issue 2247
just in case, but I don't know what the problem is.

Any help would be appreciated.

James

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

Re: beam.cc:pure-rest-collision-callback Place on staff lines; issue 2468 (issue 6035053)

[k-ohara5a5a]

On 2012/04/15 16:45:54, Keith wrote:


An improvement would be to round-to-larger


Done, along with other cleanup following the similar function
rest_collision_callback()

http://codereview.appspot.com/6035053/

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

Re: beam.cc:pure-rest-collision-callback Place on staff lines; issue 2468 (issue 6035053)

[k-ohara5a5a]

Reviewers: Graham Percival, dak,

Message:
On 2012/04/15 15:32:10, dak wrote:


if max/min trigger, rint is applied to some rest_max_pos.  It would >

appear that it should rather apply only to the calculated mean.

I want the final output to be an integral number of staff spaces, and
rest_max_pos might not be.  (Despite its name, rest_max_pos is in units
of staff-spaces, usually 2.5)


every second staff line will get avoided for values in between.


Yes, the tentative placement for beamed rests favors the middle,
uppermost, and lowermost lines, in the usual five-line staff.

An improvement would be to round-to-larger, as in
rest_collision_callback() when it sets the final position of the rest.
That function is also more careful to make the shift relative to
'prev_offset' an integral number of staff spaces, rather than the
position relative to staff-center.

Description:
beam.cc:pure-rest-collision-callback Place on staff lines; issue 2468

Please review this at http://codereview.appspot.com/6035053/

Affected files:
  M lily/beam.cc


Index: lily/beam.cc
diff --git a/lily/beam.cc b/lily/beam.cc
index  
0cfc3e193cba6b3feea911abb09a6f9e5118d6c2..0cb9946eec038e9fca0960072a0fa5d49e712a7c  
100644

--- a/lily/beam.cc
+++ b/lily/beam.cc
@@ -1372,7 +1372,7 @@ Beam::pure_rest_collision_callback (SCM smob,
 then bound it by the minimum and maximum positions outside the staff.
 4.0 = 2.0 to get out of staff space * 2.0 for the average
   */
-  amount = min (max ((Stem::head_positions (left)[beamdir] +  
Stem::head_positions (right)[beamdir]) / 4.0, rest_max_pos[DOWN]),  
rest_max_pos[UP]);
+  amount = rint( min (max ((Stem::head_positions (left)[beamdir] +  
Stem::head_positions (right)[beamdir]) / 4.0, rest_max_pos[DOWN]),  
rest_max_pos[UP]));


   return scm_from_double (amount);
 }



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

Doc: CG - Update of Quick Start section (issue 6031053)

[graham]

LGTM; a few minor nitpicks.


http://codereview.appspot.com/6031053/diff/1/Documentation/contributor/quick-start.itexi
File Documentation/contributor/quick-start.itexi (left):

http://codereview.appspot.com/6031053/diff/1/Documentation/contributor/quick-start.itexi#oldcode17
Documentation/contributor/quick-start.itexi:17: @advanced{experienced
developers may prefer to use their own
I'd rather keep this paragraph, and possibly even the one above it.
Some people won't notice it, I think it's worth keeping it in case they
do.

http://codereview.appspot.com/6031053/diff/1/Documentation/contributor/quick-start.itexi
File Documentation/contributor/quick-start.itexi (right):

http://codereview.appspot.com/6031053/diff/1/Documentation/contributor/quick-start.itexi#newcode254
Documentation/contributor/quick-start.itexi:254: @node Lily-git
Isn't the name of the program "lily-git", with no capitals?

http://codereview.appspot.com/6031053/diff/1/Documentation/contributor/quick-start.itexi#newcode258
Documentation/contributor/quick-start.itexi:258: @q{Lily-git}) is a
simple-to-use, GUI to help you download and update
I'd rather stick with @command{lily-git.tcl} here.  Also, no comma after
"simple-to-use".

http://codereview.appspot.com/6031053/

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

Re: for_UP_and_DOWN

[Graham Percival]

On Sun, Apr 15, 2012 at 05:37:14PM +0200, David Kastrup wrote:
> Graham Percival  writes:
> > I like that solution, but I'm iffy about relying on compiler
> > support for elements of languages that are less than 10 years old.
> 
> I was not suggesting we use it.  I just pointed out that in future for
> _some_ things "the C++ way" could become less incompatible with
> "readable".

:)

point to you.

- Graham

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

Re: for_UP_and_DOWN

[David Kastrup]

Graham Percival  writes:

> On Sun, Apr 15, 2012 at 05:16:07PM +0200, David Kastrup wrote:
>> Actually, with option -std=c++0x GCC would accept
>> 
>> for (Direction d : { UP, DOWN })
>> {
>>...
>> }
>> 
>> and that would be readable enough without having to revert to macros.
>
> I like that solution, but I'm iffy about relying on compiler
> support for elements of languages that are less than 10 years old.

I was not suggesting we use it.  I just pointed out that in future for
_some_ things "the C++ way" could become less incompatible with
"readable".

-- 
David Kastrup

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

Re: beam.cc:pure-rest-collision-callback Place on staff lines; issue 2468 (issue 6035053)

[dak]

On 2012/04/15 15:20:13, Graham Percival wrote:

wow, looks very nice and simple.  I vote for pushing immediately, but

please

wait for at least one other such vote (or a countdown).


if max/min trigger, rint is applied to some rest_max_pos.  It would
appear that it should rather apply only to the calculated mean.

The calculated mean uses the current rounding mode.  If it is IEEE
rounding, this means round to even: (1+2)/2.0 will be rounded to 2.0,
and (2+3)/2.0 will be rounded to 2.0 as well.  That looks suspicious to
me, like every second staff line will get avoided for values right in
between.

http://codereview.appspot.com/6035053/

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

Re: for_UP_and_DOWN

[Graham Percival]

On Sun, Apr 15, 2012 at 05:16:07PM +0200, David Kastrup wrote:
> Actually, with option -std=c++0x GCC would accept
> 
> for (Direction d : { UP, DOWN })
> {
>...
> }
> 
> and that would be readable enough without having to revert to macros.

I like that solution, but I'm iffy about relying on compiler
support for elements of languages that are less than 10 years old.
For examples, does clang++ support that?  gcc 4.1.2 (which is what
GUB has)?  gcc 3.4 or whatever openbsd still uses?  etc.

If we use a macro, then at least we could change the definition in
one place in order to work around old/broken compilers.

- Graham

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

beam.cc:pure-rest-collision-callback Place on staff lines; issue 2468 (issue 6035053)

[graham]

wow, looks very nice and simple.  I vote for pushing immediately, but
please wait for at least one other such vote (or a countdown).

http://codereview.appspot.com/6035053/

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

Re: for_UP_and_DOWN

[David Kastrup]

Łukasz Czerwiński  writes:

> On 15 April 2012 16:49, David Kastrup  wrote:
>
> Łukasz Czerwiński  writes:
> > I'd like to write code, that will make Lilypond better or easier
> to be
> > used
> 
> 
> Not necessarily the same as "the C++ way".
> 
>
> Right :) No iterators needed here :)

Actually, with option -std=c++0x GCC would accept

for (Direction d : { UP, DOWN })
{
   ...
}

and that would be readable enough without having to revert to macros.

-- 
David Kastrup


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

Re: Web: Add more 'Concerts' to introduction.itexi (issue 6007048)

[janek . lilypond]

one typo


http://codereview.appspot.com/6007048/diff/1/Documentation/web/introduction.itexi
File Documentation/web/introduction.itexi (right):

http://codereview.appspot.com/6007048/diff/1/Documentation/web/introduction.itexi#newcode509
Documentation/web/introduction.itexi:509: musical director.  His many,
recent works include; @emph{Go Thy Way},
Without a comma i think?
"His many recent works include"

http://codereview.appspot.com/6007048/

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

Re: for_UP_and_DOWN

[Graham Percival]

On Sun, Apr 15, 2012 at 04:49:11PM +0200, David Kastrup wrote:
> Łukasz Czerwiński  writes:
> 
> > The final suggestion depends on suggestions from all of you. If you
> > find a better idea for (UP_and_DOWN(d)), I'll do so. If you find
> > easier: for_UP_and_DOWN, it could be this.
> 
> I find for_UP_and_DOWN somewhat more consistent, but syntax-aware
> editors (and indenters) don't share my sentinent.  So using that will be
> rather boorish.

That's precisely why I liked the suggestion of
  for (UP_and_DOWN(d))
{
}
since editors will have no problem with that.

> The C++ way would be to use iterators here.  Something like
> 
> use std;
> 
> const vector  up_and_down { UP, DOWN };
> 
> for (vector::iterator d = up_and_down.cbegin ();
>  d != up_and_down.cend(); ++d) {
> [Do something with *d]
> }

...
is that really the kind of un-abstraction you like to see?
I mean, sure, go ahead and use an iterator for the macro
definition.  But my eyes glaze over when I see a for loop spanning
multiple lines.  All we want to do is execute some code for UP and
DOWN.


> > I'd like to write code, that will make Lilypond better or easier to be
> > used
> 
> Not necessarily the same as "the C++ way".

inb4 "those goals are mutually incompatible".  ;)

- Graham

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

Re: for_UP_and_DOWN

[Łukasz Czerwiński]

On 15 April 2012 16:49, David Kastrup  wrote:

> Łukasz Czerwiński  writes:
> > I'd like to write code, that will make Lilypond better or easier to be
> > used
>
> Not necessarily the same as "the C++ way".
>

Right :) No iterators needed here :)



> > and it's not my goal to fulfill my ambitions to force unwanted
> > changes, so:
> >
> > 1) As Graham and Keith wanted for(UP_and_DOWN), the macro and example
> > is:
> >
> > #define UP_and_DOWN(d) \
> > Direction d = UP; d != CENTER; flip(&d), d == UP ? d = CENTER : d
>
> That looks rather nonsensical.  Why use flip at all here, and what with
> the obscure : d as a nop?  You could write
>
> ; d = d == UP ? DOWN : CENTER ;


Yeah, you're absolutely right, that way is simpler, thanks :)

Łukasz
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: for_UP_and_DOWN

[David Kastrup]

Łukasz Czerwiński  writes:

> The final suggestion depends on suggestions from all of you. If you
> find a better idea for (UP_and_DOWN(d)), I'll do so. If you find
> easier: for_UP_and_DOWN, it could be this.

I find for_UP_and_DOWN somewhat more consistent, but syntax-aware
editors (and indenters) don't share my sentinent.  So using that will be
rather boorish.

The C++ way would be to use iterators here.  Something like

use std;

const vector  up_and_down { UP, DOWN };

for (vector::iterator d = up_and_down.cbegin ();
 d != up_and_down.cend(); ++d) {
[Do something with *d]
}

> I'd like to write code, that will make Lilypond better or easier to be
> used

Not necessarily the same as "the C++ way".

> and it's not my goal to fulfill my ambitions to force unwanted
> changes, so:
>
> 1) As Graham and Keith wanted for(UP_and_DOWN), the macro and example
> is:
>
> #define UP_and_DOWN(d) \
> Direction d = UP; d != CENTER; flip(&d), d == UP ? d = CENTER : d

That looks rather nonsensical.  Why use flip at all here, and what with
the obscure : d as a nop?  You could write

; d = d == UP ? DOWN : CENTER ;

-- 
David Kastrup

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

Re: for_UP_and_DOWN

[Łukasz Czerwiński]

On 14 April 2012 18:06, David Kastrup  wrote:

>
> Is this supposed to declare d itself or not?


Yes, it will declare d as a variable visible only in for loop (I'm using a
new way of handling variables declared in for() clause - those variables
will no longer be visible outside the for() loop).

On 14 April 2012 18:32, Graham Percival  wrote:

> On Sat, Apr 14, 2012 at 06:06:41PM +0200, David Kastrup wrote:
> > Graham Percival  writes:
> >
> > >> > for (UP_and_DOWN(d))
> > >> >   { ... }
> > >> > for (LEFT_and_RIGHT(d))
> > >> >   { ... }
> > >>
> > > Not yet.  I just wanted to clarify what you were talking about,
> > > since most people don't have the time to go trawling through
> > > rietveld discussions.  If something is difficult to understand,
> > > the first instinct is just to ignore the discussion.
> >
> > Is this supposed to declare d itself or not?
>
> ... probably?
>
>
> Lukasz, could we have a nice concise example of exactly what the
> final suggestion is?  What's the macro?
>
> - Graham


The final suggestion depends on suggestions from all of you. If you find a
better idea for (UP_and_DOWN(d)), I'll do so. If you find easier:
for_UP_and_DOWN, it could be this.

I'd like to write code, that will make Lilypond better or easier to be used
and it's not my goal to fulfill my ambitions to force unwanted changes, so:

1) As Graham and Keith wanted for(UP_and_DOWN), the macro and example is:

#define UP_and_DOWN(d) \
Direction d = UP; d != CENTER; flip(&d), d == UP ? d = CENTER : d

int main() {
for(UP_and_DOWN(d)) {
 printf("%d\n", (int)d);
}
}

The example will print the integer value for UP and then the integer value
for DOWN:
1
-1


2) If the macro would be for_UP_and_DOWN, those would be:


#define for_UP_and_DOWN(d) \
 for(Direction d = UP; d != CENTER; flip(&d), d == UP ? d = CENTER : d)

int main() {
for_UP_and_DOWN(d) {
 printf("%d\n", (int)d);
}
}

The output is of course the same - the integer value for UP and then the
integer value for DOWN:
1
-1

Which option should I include in the Lilypond's code? As I wrote earlier,
there were 2 votes for 1)

Łukasz
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Corrected comments and a function check_meshing_chords divided in two. (issue 5975054)

[Łukasz Czerwiński]

On 14 April 2012 21:12,  wrote:

> Splitting the function in two doesn't make it any easier for me to
> understand, but I had figured it out before.
>
> On 2012/03/21 18:56:08, Milimetr88 wrote:
>
>> What I was taught at the university is to write short
>> and simple functions that do only one thing.
>>
>
> Maybe this was intended as advice for when you initially write code; it
> would encourage the writer to find the smallest independent tasks and
> cleanest interfaces between those tasks.  Splitting up an existing
> function, that has grown into its assigned task and assigned interface,
> is different.




On 14 April 2012 22:37,  wrote:

>
> Splitting the function into two parts does not make sense since the
> first part has no well-defined output that can be considered reasonably
> independent from the requirements and workings of the algorithms in the
> second part.  When you are redesigning the second part, you'll need to
> redefine the "interface" between the two parts and the first part as
> well.  Whether or not you put an artificial function call boundary in
> the middle of the function, it is not composed of modular parts that
> could be reused in different contexts.
>
> Modularity is not a self-serving goal.
> http://codereview.appspot.com/**5975054/
>

Ok, I'll merge it back.

Łukasz
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Corrected comments and a function check_meshing_chords divided in two. (issue 5975054)

[milimetr88]

http://codereview.appspot.com/5975054/diff/1/lily/staff-symbol-referencer.cc
File lily/staff-symbol-referencer.cc (right):

http://codereview.appspot.com/5975054/diff/1/lily/staff-symbol-referencer.cc#newcode126
lily/staff-symbol-referencer.cc:126: * Returns vertical position of a
symbol relatively to the staff.
On 2012/04/14 19:12:01, Keith wrote:

On 2012/04/14 13:56:18, Milimetr88 wrote:
> Relative to which element?
"relative to the staff"
Most English speakers think of this construction as an adjective,

describing

'position', so we use the adjective form 'relative'.
We see 'relatively' a lot from people who think in other languages,

but that

makes English speakers search for the adjective being modified by

'relatively'.

Ah, ok. I thought that Han-Wen wants me to replace THE WHOLE comment
with a one word: "relative" :D Now it's clear for me - I'll change that
one word.

http://codereview.appspot.com/5975054/diff/1/lily/staff-symbol-referencer.cc#newcode137
lily/staff-symbol-referencer.cc:137: * The unit is halves of staff
space.
On 2012/04/14 19:12:01, Keith wrote:

On 2012/04/14 13:56:18, Milimetr88 wrote:
>
> Is there any official coding style for comments? I couldn't find any

in CG.


With very few exceptions, block comments in LilyPond C code use no *.

That is

enough to recognize the convention.  You should take out the *s here.



> And as it was stated here:
>


http://codereview.appspot.com/5651069/diff/5002/lily/note-collision.cc#newcode191

> leading *'s prevent comments misalignment.



Those are the exceptions.  Emacs' indenter will left-align block

comments. Years

ago someone auto-indented the code with emacs and destroyed all the

ASCII-art

comments that draw note-configurations.



If we write an explicit rule, then it is harder to adapt the next time

we meet

an exceptional case.


Ok, so there should be leading *, if and only if there is an ASCII-art
in the comment, right?

http://codereview.appspot.com/5975054/

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

Re: hideNotes in tablature

[Phil Holmes]

- Original Message - 
From: "Federico Bruni" 

To: "James" 
Cc: "Devel" ; 
Sent: Sunday, April 15, 2012 2:13 PM
Subject: Re: hideNotes in tablature



Il 15/04/2012 12:06, Federico Bruni ha scritto:

Yes, issue 1459 is fixed.
How can I change the label to fixed in the tracker?


I guess I can't:

"Only project owners and committers can edit issue metadata. These users 
see additional fields when entering a new issue or adding a comment. The 
drop-down auto-complete menu for each field will help you enter commonly 
used values. However, for the labels, you are free to enter new or 
uncommon labels simply by typing them."


http://code.google.com/p/support/wiki/IssueTrackerFAQ#Edit_issue_labels_&_metadata

Can you add me to the members?



Done.

--
Phil Holmes



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

Re: hideNotes in tablature

[Federico Bruni]

Il 15/04/2012 12:06, Federico Bruni ha scritto:

Yes, issue 1459 is fixed.
How can I change the label to fixed in the tracker?


I guess I can't:

"Only project owners and committers can edit issue metadata. These users 
see additional fields when entering a new issue or adding a comment. The 
drop-down auto-complete menu for each field will help you enter commonly 
used values. However, for the labels, you are free to enter new or 
uncommon labels simply by typing them."


http://code.google.com/p/support/wiki/IssueTrackerFAQ#Edit_issue_labels_&_metadata

Can you add me to the members?

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

Re: issues 2266 and 1721

[Phil Holmes]

- Original Message - 
From: "Jean-Charles Malahieude" 

To: "Phil Holmes" 
Cc: "Lily Bugs" ; "lilypond-devel" 


Sent: Saturday, April 14, 2012 5:46 PM
Subject: Re: issues 2266 and 1721


It might have something to do with the way both glossary and snippet are 
built: I just noticed, on fresh make doc on staging (as of

312f7ebc83ec9fb8cbbddfcf78b65a8502c16ab2 ), that
music-glossary.splittexi.log weight is 0 byte, but
snippets.splittexi.log is 190.9 Kio (1618 lines).

Cheers,
Jean-Charles



I reckon I now know why this is happening.  We get the same error if the 
text of pitches.itely is cut down to:


@node Hauteurs
@section Hauteurs
@translationof Pitches

Morceaux choisis :
@rlsrnamed{Pitches,Hauteurs}.

The error goes away if @translationof Pitches is changed to @translationof 
Pitcher.  So I think @rlsrnamed{Pitches,Hauteurs} is translated 
automatically to @rlsrnamed{Hauteurs,Hauteurs} and the system can't then 
find the node Hauteurs.


What do you think?

--
Phil Holmes



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

Re: hideNotes in tablature

[Federico Bruni]

Il 15/04/2012 11:00, James ha scritto:

Federico, it seems you have the ability (and knowledge) to create a
tracker yourself so I suggest that if issue 1459 is fixed you change
the label to fixed - someone else will verify -  and then create a new
tracker for the enhancement - whatever it is. Else whoever comes back
to the old tracker has to puzzle their way through and often this puts
people off (unless you yourself are going to work and create the
patch).



Yes, issue 1459 is fixed.
How can I change the label to fixed in the tracker?

The patch itself is very easy and I could create it, but I think that 
I'd better just create the issue in the tracker.

Here it is:
http://code.google.com/p/lilypond/issues/detail?id=2480

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

Re: hideNotes in tablature

[James]

Hello,

On 15 April 2012 07:13, Federico Bruni  wrote:
> Il 14/04/2012 21:09, James ha scritto:
>
>> Hello,
>>
>> On 14 April 2012 15:47, Marc Hohl  wrote:
>>>
>>> Am 14.04.2012 11:57, schrieb Federico Bruni:


 Hi,

 I started using version 2.13.56 and I realized that this bug seems
 fixed:
 http://code.google.com/p/lilypond/issues/detail?id=1459
>>
>>
>> I'll verify that if no one else has. I am building a latest version at
>> the moment of 2.15.x
>>
>
> I've tested it now on latest version of lilypond/translation branch.
> It works fine.

Right so Issue 1459 is fixed?

>
>
>> However reading the tracker again just now, are the comments from this
>> morning a 'new' issue or an 'enhancement' if so, we need a new
>> tracker.
>>
>> Could Federico or Marc clarify please?
>>
>
> It's an enhancement, which has already been discussed before (see links I
> pasted in the tracker) but never recorded in the tracker.

You don't really make it easy for the bug squad - who are generally
non-technical people who have enough to do without having to pick
apart/read through long threads, threads I might add that have never
been reported to the bug list (or dev list - that was me).

Federico, it seems you have the ability (and knowledge) to create a
tracker yourself so I suggest that if issue 1459 is fixed you change
the label to fixed - someone else will verify -  and then create a new
tracker for the enhancement - whatever it is. Else whoever comes back
to the old tracker has to puzzle their way through and often this puts
people off (unless you yourself are going to work and create the
patch).

>
> If the change is accepted, the following snippet should be removed (I
> think):
> http://lsr.dsi.unimi.it/LSR/Snippet?id=633

Add this to the same (new?) Tracker as well.

We're desperately trying to make it as easy as possible for the bug
squad (and developers) to workout what a tracker is for and if/when it
is fixed and more importantly how to know what they are looking at.

I hope you understand.

james

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