Re: Part_combine_iterator::derived_mark: don't abort marking prematurely. (issue 6057044)

On 2012/04/18 05:49:01, dak wrote: On 2012/04/18 04:39:20, dak wrote: > One could instead use a static array with pointers-to-member (basically > offsets), and then dereference them. In that case, a 0 entry would indeed work > as an ending mark. > > But for 4 entries? To illustrate:

Re: Part_combine_iterator::derived_mark: don't abort marking prematurely. (issue 6057044)

On 2012/04/18 04:39:20, dak wrote: One could instead use a static array with pointers-to-member (basically offsets), and then dereference them. In that case, a 0 entry would indeed work as an ending mark. But for 4 entries? To illustrate: static Stream_event * Part_combine_iterator::*

Re: Part_combine_iterator::derived_mark: don't abort marking prematurely. (issue 6057044)

Reviewers: Graham Percival, Message: On 2012/04/17 20:21:14, Graham Percival wrote: LGTM and can be pushed right now. But for my general ignorance: why not just hard-code 4? I suppose that using the sizeof() trick makes it a bit safer in case somebody adds something to ptrs, but is there

Re: Regarding LSR translation work

2012/4/17 Federico Bruni : > Another solution could be keeping the current structure and changing only > check-translation.py so that, when looking at the files in > Documentation/snippets, it should check only the changes inside texidoc = "" > and doctitle = "" strings. Yes, I intially thougth th

Re: for_UP_and_DOWN

Ok, Could we sum up the discussion? As I understand: for (UP_and_DOWN(d)) { } is ok, right? I will wait for two OKs and then make changes and produce and upload a patch. Łukasz ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.

Part_combine_iterator::derived_mark: don't abort marking prematurely. (issue 6057044)

LGTM and can be pushed right now. But for my general ignorance: why not just hard-code 4? I suppose that using the sizeof() trick makes it a bit safer in case somebody adds something to ptrs, but is there any other reason? http://codereview.appspot.com/6057044/

Re: Regarding LSR translation work

Hi Francisco, thanks for bringing this to the attention of developers! Il 17/04/2012 11:46, Francisco Vila ha scritto: Hello all, As you know, we translators are constantly aware of how much pendant work we have, thanks to 'make check-translation'. For example, right now cd Documentation

Re: issues 2266 and 1721

Le 15/04/2012 14:56, Phil Holmes disait : - 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 s

Re: Regarding LSR translation work

Le 17/04/2012 11:46, Francisco Vila disait : Hello all, As you know, we translators are constantly aware of how much pendant work we have, thanks to 'make check-translation'. For example, right now cd Documentation make ISOLANG=es check-translation | wc -l gives ten thousand lines as resu

Let pitched trills in articulations be transposed as well (issue 6062043)

LGTM, and I think we can skip the countdown for this one. http://codereview.appspot.com/6062043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Regarding LSR translation work

Hello all, As you know, we translators are constantly aware of how much pendant work we have, thanks to 'make check-translation'. For example, right now cd Documentation make ISOLANG=es check-translation | wc -l gives ten thousand lines as result, most of them from Documentation/snippets/. T