Re: hideNotes in tablature
Il 14/04/2012 21:09, James ha scritto: Hello, On 14 April 2012 15:47, Marc Hohlm...@hohlart.de 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. 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. If the change is accepted, the following snippet should be removed (I think): http://lsr.dsi.unimi.it/LSR/Snippet?id=633 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Correctly positions dots on rests that share a column with a beamed grob. (issue 5992073)
I got about halfway through, but then it got too complicated with the
various ways to compute the Dots' Y-offset under various conditions.
http://codereview.appspot.com/5992073/diff/5001/lily/dot-column.cc
File lily/dot-column.cc (right):
http://codereview.appspot.com/5992073/diff/5001/lily/dot-column.cc#newcode163
lily/dot-column.cc:163: are due to the fact that this callback is called
before line breaking
this callback *may be* called
There seems to be nothing enforcing that dot-positioning is done at any
particular time.
http://codereview.appspot.com/5992073/diff/5001/lily/dot-column.cc#newcode195
lily/dot-column.cc:195: int p = before_line_breaking
Dots::in_dot_column_with_beam_and_rest (dp.dot_)
This looks suspicious at first. But it seems that whenever this specific
condition is true, get_rounded_position() would return 0 anyway.
http://codereview.appspot.com/5992073/diff/5001/lily/dot-column.cc#newcode203
lily/dot-column.cc:203:
It seems we want to just skip the collision resolution for dots on
rests, and let them ride with the rest, one position higher than the
center of the rest.
if (Rest::has_interface (note))
{
cfg[p+1] = dp;
continue;
}
http://codereview.appspot.com/5992073/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: hideNotes in tablature
Hello, On 15 April 2012 07:13, Federico Bruni fedel...@gmail.com wrote: Il 14/04/2012 21:09, James ha scritto: Hello, On 14 April 2012 15:47, Marc Hohlm...@hohlart.de 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
Re: hideNotes in tablature
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: issues 2266 and 1721
- Original Message -
From: Jean-Charles Malahieude lily...@orange.fr
To: Phil Holmes m...@philholmes.net
Cc: Lily Bugs bug-lilyp...@gnu.org; lilypond-devel
lilypond-devel@gnu.org
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
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: hideNotes in tablature
- Original Message - From: Federico Bruni fedel...@gmail.com To: James pkx1...@gmail.com Cc: Devel lilypond-devel@gnu.org; lilypond-u...@gnu.org 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: Corrected comments and a function check_meshing_chords divided in two. (issue 5975054)
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: Corrected comments and a function check_meshing_chords divided in two. (issue 5975054)
On 14 April 2012 21:12, k-ohara5...@oco.net 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, d...@gnu.org 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/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: for_UP_and_DOWN
On 14 April 2012 18:06, David Kastrup d...@gnu.org 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 gra...@percival-music.ca wrote:
On Sat, Apr 14, 2012 at 06:06:41PM +0200, David Kastrup wrote:
Graham Percival gra...@percival-music.ca 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: for_UP_and_DOWN
Łukasz Czerwiński milimet...@gmail.com 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 Direction up_and_down { UP, DOWN };
for (vectorDirection::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
On 15 April 2012 16:49, David Kastrup d...@gnu.org wrote: Łukasz Czerwiński milimet...@gmail.com 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
On Sun, Apr 15, 2012 at 04:49:11PM +0200, David Kastrup wrote:
Łukasz Czerwiński milimet...@gmail.com 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 Direction up_and_down { UP, DOWN };
for (vectorDirection::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: Web: Add more 'Concerts' to introduction.itexi (issue 6007048)
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
Łukasz Czerwiński milimet...@gmail.com writes:
On 15 April 2012 16:49, David Kastrup d...@gnu.org wrote:
Łukasz Czerwiński milimet...@gmail.com 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
beam.cc:pure-rest-collision-callback Place on staff lines; issue 2468 (issue 6035053)
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
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
Re: beam.cc:pure-rest-collision-callback Place on staff lines; issue 2468 (issue 6035053)
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 gra...@percival-music.ca 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: for_UP_and_DOWN
On Sun, Apr 15, 2012 at 05:37:14PM +0200, David Kastrup wrote: Graham Percival gra...@percival-music.ca 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
Doc: CG - Update of Quick Start section (issue 6031053)
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: beam.cc:pure-rest-collision-callback Place on staff lines; issue 2468 (issue 6035053)
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
Re: beam.cc:pure-rest-collision-callback Place on staff lines; issue 2468 (issue 6035053)
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
Problem running makelsr.py
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 module 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: 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 module 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
Re: Problem running makelsr.py
Graham, On 15 April 2012 22:24, Graham Percival gra...@percival-music.ca 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 module 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
Read error from 'delta' in Git for staging
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
PATCH: Countdown to 20120417
For 20:00 MDT Tuesday April 17 Critical Issue 2468 http://code.google.com/p/lilypond/issues/detail?id=2468: augmentation dot of a moved rest is placed on a line - R6035053 http://codereview.appspot.com/6035053/ Documentation: Issue 2478 http://code.google.com/p/lilypond/issues/detail?id=2478: Patch: Web: Add more 'Concerts' to introduction.itexi - R6007048 http://codereview.appspot.com/6007048/ Issue 2481 http://code.google.com/p/lilypond/issues/detail?id=2481: Patch: Doc: CG - Update of Quick Start section - R6031053 http://codereview.appspot.com/6031053/ 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
