Re: [Patch] Add support for tempo ranges (issue3248042)
On 2010/11/27 00:43:23, Neil Puttock wrote:
it's been
reviewed thoroughly (I hope :), so go ahead and push.
Hi Neil, greetings everybody,
I've pushed this patch, so hopefully nothing will get broken. It is
undocumented as of yet, but I'll wait for Neil to complete his own work
so that I can possibly take this into account when writing the relevant
documentation.
One caveat though: the display-lily regtest now outputs an
unequal-thingy because of the \tempo blah command that I added, upon
Neil's suggestion:
Test 90 unequal: .
in = \tempo Andante
out = { \unset Score . tempoUnitDuration
\unset Score . tempoUnitCount
\set Score . tempoText = #Andante
}
Then again, I'm pretty sure Neil's future patch will address this, so
I'm not too restless about it :-)
Cheers,
Valentin.
http://codereview.appspot.com/3248042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gettext status?
On Sun, Nov 28, 2010 at 4:33 PM, Jean-Charles Malahieude lily...@orange.fr wrote: If you have a look at http://translationproject.org/domain/lilypond.html you'll see that the template file is as of 2.13.7, which means that anything that has disappeared form the sources will remain in the record and what has been amended or added since then is absent. Indeed. That's unconvenient. As a matter of fact, any major version should be preceded by an upload of a new template (assignees get automatically acknowledged by the FTP) in order to have an up to date set of translated messages. Okay. What do you suggest? Are you able (and willing!) to update the template? Is there anything I can do in this regard? Otherwise, I'll just send you my .po file when I'm done and leave you to do... well, whatever it is you wanna do with it :-) Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14 release, or GOP now (part 2)
On Mon, Nov 29, 2010 at 06:37:08AM -0700, Carl Sorensen wrote: What about option 0 -- try to coordinate the resources we currently have available on the critical issues? I would like that. I'm a bit surprised to see so many people talking about branching a stable/2.14 -- I don't think that would solve anything. I'm willing to try it as an experiment, but I really doubt that having a separate branch would encourage more people to spend more time on critical issues. I'm not sure if this is feasible or not, but I regularly check the critical issues to see if I can help resolve them. Here's a rundown of my typical check. -snip- To summarize it: you expect Joe to fix 2 issues, Neil to fix 3, and John to fix 1. However, according to the issue tracker, John and Neil have both started 1 issue. Given his expertise and the number of other open issues, I agree that working on the spacing issues would not be very efficient. But I disagree with ignore critical issues entirely. Right now, for this specific set of critical issues, it appears to me that those who have the knowledge and skills to solve the issues is working on them. Anybody else would need to climb a big hill to get ready to solve them. I do not disagree with this. However, my conclusion is not let's frolic and party in the valley; my conclusion is let's start climbing -- in particular, let's start climbing *together*. To use a sports analogy, our current teamwork is like playing doubles tennis. Person A works on stuff x. Person B works on stuff y. The project as a whole benefits from this specialization. However, at the moment we have an overabundance of stuff x. Should Mr. B, C, D, E, and F just sit around waiting for Mr. A to deal with all the stuff x ? I don't think so. Instead of doubles tennis, let's play volleyball. Let's all (or at least, everybody other than Joe+Neil+John) works together on an issue. Instead of one person hitting the ball back, let's have multiple people stop the ball, set it up, and then send it back. Will it take us longer than if Neil did it himself? maybe. But is Neil such a genius that he can solve all the critical issues before we can solve one? With absolutely no disrespect to him, I don't think so. I think that if you, me, Patrick, Valentin, Keith, Mark, Marc, Trevor, etc., all work together on just ONE critical issue, we can get it fixed before Neil finishes all the other issues. Let's examine 1336 in detail, since I happen to be more familiar with it. - Valentin created a good Tiny example. - Patrick created a backtrace. That's useful for me, since I don't know how to create them. - I started to investigate it in my stupid manner. I think that I've isolated the part of code that's segfaulting. It has something to do with X-offset. I've now posted patch so that anybody can reproduce and check my results. - Neil suggested -- again, no disrespect to him, but it was a *suggestion*, not *knowledge* -- that the cause was something about cloning a MultiMeasureRest. What's the next step in this story? Well, I'd like some evidence that MultiMeasureRest is actually the problem. - a brief look at the source suggests that MultiMeasureRest isn't in one of the lily/*.cc files; it's actually in scm/. I have no clue which scheme file handles cloning -- or even what that word means in the context of lilypond internals -- but that's no reason for me to give up. There will be some .cc file that I can add a printf() to, or some scheme file that I can add a (display...) to, which will print out a suspicious piece of text when I compile bad.ly, but which will print out no suspcious text when I compile good.ly. - Somebody who knows about scheme -- Mark, Valentin, Trevor? -- could help a lot in this investigation. Or some combination thereof. - Maybe Trevor only has enough knowledge+time this morning such that he could identify that the cloning happens on line 123 of scm/define-grob-properties.scm. That's not a failure, that's not useless -- that piece of knowledge is vital for the next step! - Then maybe in the afternoon, Valentin can afford to spend 30 minutes inserting (display...) into random places near line 123, and discovers that add (display (my (bounds)) to line 138 displays the suspicious/non-suspicious text. Great! - Then at midnight Europe time but mid-afternoon Canadian-time, Mark the scheme guru looks at the output, and realizes that the whole thing could be fixed by adding (if (!= (my (bounds) 0) to line 872 of scm/cloning-a-grob.scm. Or maybe there's still more steps required in this story. Maybe he spends two hours poking around, and doesn't see any obvious next step. Sometimes that's what happens. But he writes about what he tried, so mid-morning European time I read about his attemps, and think of other things to try. Look, I am not scared of lilypond. I know almost nothing about our internals. I
volleyball issue 1336
This is an attempt to collaboratively solve issue 1336. (that said, if anybody can jump in and solve it instantly with a patch, go right ahead! if this issue is solved, we'll just pick another one) http://code.google.com/p/lilypond/issues/detail?id=1336 There is a theory about why this happens, from Neil: It looks to me like the MultiMeasureRest has invalid bounds when cloned, so the cloned object is NULL when the MultiMeasureRestNumber is aligned (the parent object no longer exists) Can anybody think of a way to test this theory? i.e. I'm not asking how to stop this from happening. I'm not even asking for solid evidence that this is, in fact, happening. I'm just asking how we could *begin* the *attempt* to gather such evidence. The answer might be something like: - cloning is done by lily/grob-clone.cc - hey, I've found a method in lily/multi-measure-engraver.cc called 'clone()', we should probably look there - did you try looking at scm/define-grobs.scm, which is where MultiMeasureRest is defined? - 'clone' is a basic term of scheme programming, you idiot, why on earth are you trying to do any lilypond programming if you don't know even know that? Any of those answers would be an improvement on my current knowledge of this bug, and would be appreciated. If nobody has any ideas I'll try grepping for MultiMeasureRest and clone, and start poking around blindly. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git history, Savannah
2010/12/1 Valentin Villenave valen...@villenave.net: On Wed, Dec 1, 2010 at 10:34 AM, Trevor Daniels t.dani...@treda.co.uk wrote: Looks like Valentin is best placed to do this. I've now pushed my master branch (with one additional commit wrt the tempo-range feature that Neil will now dismember in order to rebase his own patch :-) Please let me know if I should also push my translations branch or something; I think yes. Latest in http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=shortlog;h=refs/heads/lilypond/translation is 92190ad98 Docs-de: update syntax with convert-ly to fix doc build from John, but there are at least 25 more commits newer than this. The newest I can see by either way in this branch is the one Trevor mentioned, fff96cc1a9 'Doc: @file entries clean-up, take3' Thanks! -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB target_cpu error
On Wed, Dec 1, 2010 at 9:26 AM, Graham Percival gra...@percival-music.ca wrote: On Mon, Nov 29, 2010 at 11:23 AM, Valentin Villenave v.villen...@gmail.com wrote: Actually, this was a totally unnecessary precaution. I've never heard of any *nix system where uname -m would return X86_64 or I686 instead of their lower-case counterparts. ... Bottom line: let's get rid of it already. Could we get a patch for this soon? I wanted to make an unstable release last Sat. oh, wait a moment. I can't make a release anyway due to savannah being down. So no rush. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Md5sums and lilypond repository - First contribution
On Mon, Nov 29, 2010 at 08:41:28AM +, Philippe Neyrat wrote: I'd like to know if you can use it on the repositories, in order to have files with md5sum hashes of the different versions of Lilypond. Sorry, this would require a patch to GUB. If you are not already familiar with the system, it would take 10-20 hours to learn enough about how it works to create such a patch. At the moment, there seems to be a strong desire to get 2.14 out, so I will not offer to create the patch myself (I estimate it would be a 30-minute task for me); I will spend that time on release-oriented tasks instead. If this is still an open request after 2.14 is released, I might look at it then, but I make no guarantees. Don't forget to change the owner of the script as root, and enable execution only for root... I cannot think of any reason why such a script should require root permission. Sorry for the bad news, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
cross-staff beams
Hi,
Please try the following example, which is rendered less than optimal
using 2.13.40. Do you agree Lilypond should be able to
do better than this ? Is it worth a bug report ?
%-8-
\version 2.13.40
upper = \relative c' {
\clef treble
\time 2/4
\set Staff.beatStructure = #'(2)
e4 e | e e |
}
lower = \relative c {
\clef bass
\time 2/4
R2 |
\change Staff = up e'8
\change Staff = down a,,
\change Staff = up e''
\change Staff = down a,, |
}
\score {
\new PianoStaff
\new Staff=up \upper
\new Staff=down \lower
\layout {}
}
%--8--
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git history, Savannah
2010/11/30 Francisco Vila paconet@gmail.com:
Hello. As you probably know, Savannah has been down for days; now it
is almost restored but latest backups are not newer than those of
November 24th. We should look at our local repos, try to restore the
history and find out whether are there any missing commits. I have a
recent history of the headlines only with their comments, from the RSS
feed via Google reader. My last commit on master is
commit 05acc0d1a25051a35083aeb2acf0955678e882cf
Author: Reinhold Kainhofer reinh...@kainhofer.com
Date: Wed Nov 24 16:50:23 2010 +0100
FiguredBass: Extenders for figs of different width should stop at same
posit
but RSS does recall the following:
- 1a7951329 Ties: Print out a warning for unterminated ties
- f0f0f0648b PartCombine: part-combine texts on first real note
rather than rests
- 8e43cb8e5 PartCombine: Shuffle functions around so
unisono/solo1/solo2/chords_together/apart are together in the code; No
code changes
- 9189a4acb Doc-fr: new language option for musixml2ly
- 54913d988 Doc-fr: conflicting node name
- 67e7cb936 Doc-es: translate some new snippets, fix repeated typo.
- 0960af56b76 Doc-es: markers for newly translated snippets.
- 7ba0a2264 Doc: cleanup @file{}, take 2: remove all @/ escaping sequences.
- 95a4237d0a Merge branch 'master' into lilypond/translation
The latter is from Valentin. I think you are a good candidate to push
the most recent history once passwords and all that jazz is working
again.
Here is a patch that includes a few more commits, starting from the
last in git.savannah.gnu.org/gitweb/?p=lilypond.git;a=summary , now 7
days old:
http://paconet.org/lilypond/0917fa124d1b4.zip (101 Kb)
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git history, Savannah
Francisco Vila wrote Tuesday, November 30, 2010 2:31 PM
Hello. As you probably know, Savannah has been down for days; now
it
is almost restored but latest backups are not newer than those of
November 24th. We should look at our local repos, try to restore
the
history and find out whether are there any missing commits.
- 1a7951329 Ties: Print out a warning for unterminated ties
- f0f0f0648b PartCombine: part-combine texts on first real note
rather than rests
- 8e43cb8e5 PartCombine: Shuffle functions around so
unisono/solo1/solo2/chords_together/apart are together in the
code; No
code changes
- 9189a4acb Doc-fr: new language option for musixml2ly
- 54913d988 Doc-fr: conflicting node name
- 67e7cb936 Doc-es: translate some new snippets, fix repeated
typo.
- 0960af56b76 Doc-es: markers for newly translated snippets.
- 7ba0a2264 Doc: cleanup @file{}, take 2: remove all @/ escaping
sequences.
- 95a4237d0a Merge branch 'master' into lilypond/translation
The latter is from Valentin.
I have these, plus
- fff96cc1a9 Doc: @file entries clean-up, take3 (add line-breaks)
on the translation branch, also from Valentin.
I think you are a good candidate to push
the most recent history once passwords and all that jazz is
working
again.
Looks like Valentin is best placed to do this.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git history, Savannah
On Wed, Dec 1, 2010 at 10:34 AM, Trevor Daniels t.dani...@treda.co.uk wrote: Looks like Valentin is best placed to do this. I've now pushed my master branch (with one additional commit wrt the tempo-range feature that Neil will now dismember in order to rebase his own patch :-) Please let me know if I should also push my translations branch or something; Cheers! Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git history, Savannah
Hello, On 01/12/2010 09:34, Trevor Daniels wrote: Francisco Vila wrote Tuesday, November 30, 2010 2:31 PM Hello. As you probably know, Savannah has been down for days; now it is almost restored but latest backups are not newer than those of November 24th. We should look at our local repos, try to restore the history and find out whether are there any missing commits. .. Being someone who doesn't really understand much of this but who does patches for Doc. I've pulled this morning and make ; make doc seems to work ok and I did a make doc-clean yesterday, so as of 11:00 GMT everything for me compiled doc wise, but if someone 'announce' when everything is ok I'd appreciate it :) Thank you for your consideration. James ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14 release, or GOP now (part 2)
On Wed, Dec 1, 2010 at 9:46 AM, Trevor Daniels t.dani...@treda.co.uk wrote: Graham Percival wrote Tuesday, November 30, 2010 8:04 AM I'm willing to try it as an experiment, but I really doubt that having a separate branch would encourage more people to spend more time on critical issues. It wouldn't, but that wasn't the point of the suggestion. There's a history of new code not working quite right due to bugs, oversights, etc that only come to light a few weeks later. That's why the release plan calls for having a release candidate for two weeks, with no critical issues reported against it, before making a stable release. That release candidate would of course be made from a separate branch, with only translation patches being applied to that branch. I'll wait another day for comments in case anybody missed it due to the savannah list downtime, but I despite my objection, I'll branch stable/2.14 in the next few days unless anybody speaks heavily against it. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: volleyball issue 1336
On 11/30/10 4:24 AM, Graham Percival gra...@percival-music.ca wrote:
This is an attempt to collaboratively solve issue 1336. (that said,
if anybody can jump in and solve it instantly with a patch, go right
ahead! if this issue is solved, we'll just pick another one)
http://code.google.com/p/lilypond/issues/detail?id=1336
There is a theory about why this happens, from Neil:
It looks to me like the MultiMeasureRest has invalid bounds when cloned, so
the cloned object is NULL when the MultiMeasureRestNumber is aligned (the
parent object no longer exists)
Can anybody think of a way to test this theory? i.e. I'm not asking
how to stop this from happening. I'm not even asking for solid
evidence that this is, in fact, happening. I'm just asking how we
could *begin* the *attempt* to gather such evidence.
I've identified that it is in fact the MultiMeasureRestNumber that is
causing the problem. My version of your patch that sets the offset to zero
rather than exiting results in the MMRNumber showing up at the far left of
the page.
The invalid bounds part of it is demonstrated in the error message when
bad.ly is run:
bad.ly:8:2: programming error: Spanner `MultiMeasureRest' is not fully
contained in parent spanner. Ignoring orphaned part
This error message comes from lily/spanner.cc. There is a method in
lily/spanner.cc called clone:
29 Grob *
30 Spanner::clone () const
31 {
32 return new Spanner (*this);
33 }
The clone method is called from Spanner::do_break_processing
60 else if (bound-get_system ())
61 {
62 Spanner *span = dynamic_castSpanner * (clone ());
63 span-set_bound (LEFT, bound);
64 span-set_bound (RIGHT, bound);
65
66 assert (span-get_system ());
67 span-get_system ()-typeset_grob (span);
68 broken_intos_.push_back (span);
69 }
Also, the clone method would be called if the error message weren't issued:
113 bool ok = parent_rank_slice.contains (bounds[LEFT]-get_column
()-get_rank ());
114 ok = ok parent_rank_slice.contains
(bounds[RIGHT]-get_column ()-get_rank ());
115
116 if (!ok)
117 {
118 programming_error (to_string (Spanner `%s' is not fully
contained in parent spanner. Ignoring orphaned part,
119 name ().c_str ()));
120 continue;
121 }
122
123
124 Spanner *span = dynamic_castSpanner * (clone ());
125 span-set_bound (LEFT, bounds[LEFT]);
126 span-set_bound (RIGHT, bounds[RIGHT]);
I actually think this may be a profitable place to investigate.
My attempts have taken a slightly different tack. I'm looking up the
backtrace, trying to see if I can do something with understanding the
delayed evaluation chain (frames 4-6). Going above the delayed evaluation,
I get to get_offset and relative_coordinate, both in lily/grob.cc.
Looking in relative_coordinate, I see
300 Real
301 Grob::relative_coordinate (Grob const *refp, Axis a) const
302 {
303 /* eaa - hmmm, should we do a programming_error() here? */
304 if ((this == NULL) || (refp == this))
305 return 0.0;
306
307 /* We catch PARENT_L_ == nil case with this, but we crash if we did
308 not ask for the absolute coordinate (ie. REFP == nil.) */
309 Real off = get_offset (a);
310 if (refp == dim_cache_[a].parent_)
311 return off;
312
313 off += dim_cache_[a].parent_-relative_coordinate (refp, a);
314
315 return off;
316 }
This looks like a promising place to investigate some more, because I don't
really see that we catch PARENT_L_ == nil case. But I haven't yet had the
time to investigate this.
HTH,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git history, Savannah
Francisco Vila paconet@gmail.com writes: 2010/12/1 Valentin Villenave valen...@villenave.net: On Wed, Dec 1, 2010 at 10:34 AM, Trevor Daniels t.dani...@treda.co.uk wrote: Looks like Valentin is best placed to do this. I've now pushed my master branch (with one additional commit wrt the tempo-range feature that Neil will now dismember in order to rebase his own patch :-) Please let me know if I should also push my translations branch or something This sounds like the git repository is online again, and _some_ people are able to access it. Personally, I still get git pull Permission denied (publickey). fatal: The remote end hung up unexpectedly So _if_ others are able to access git, it would seem that the account data backup is quite older than the git repository itself. How should I proceed? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git history, Savannah
On Wed, Dec 1, 2010 at 11:18 AM, Francisco Vila paconet@gmail.com wrote: I think yes. Done :-) Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git history, Savannah
Am Mittwoch, 1. Dezember 2010, um 06:31:13 schrieb Patrick McCarty:
On 2010-11-30, Francisco Vila wrote:
commit 05acc0d1a25051a35083aeb2acf0955678e882cf
Author: Reinhold Kainhofer reinh...@kainhofer.com
Date: Wed Nov 24 16:50:23 2010 +0100
FiguredBass: Extenders for figs of different width should stop at
same posit
This is the latest commit on my local master branch, too.
but RSS does recall the following:
- 1a7951329 Ties: Print out a warning for unterminated ties
- f0f0f0648b PartCombine: part-combine texts on first real note
rather than rests
- 8e43cb8e5 PartCombine: Shuffle functions around so
unisono/solo1/solo2/chords_together/apart are together in the code; No
code changes
- 9189a4acb Doc-fr: new language option for musixml2ly
- 54913d988 Doc-fr: conflicting node name
- 67e7cb936 Doc-es: translate some new snippets, fix repeated typo.
- 0960af56b76 Doc-es: markers for newly translated snippets.
- 7ba0a2264 Doc: cleanup @file{}, take 2: remove all @/ escaping
sequences. - 95a4237d0a Merge branch 'master' into
lilypond/translation
The latter is from Valentin. I think you are a good candidate to push
the most recent history once passwords and all that jazz is working
again.
I don't subscribe to Savannah git commits, but I think I remember
seeing (at least) some of these commits at git.sv.gnu.org before it
went offline.
They are restoring from an older backup (since all commits since the
compromise might also be compromised...).
I can push my latest version as soon as I can push again. That's:
8e43cb8e56e3caf52d62f7f4d73b2db9cdf45c3b
(PartCombine: Shuffle functions around so [...], on 26.11.10 16:37)
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git history, Savannah
Oh, I've just been able to pull again, so my access seems to have been sorted out. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git history, Savannah
I have these, plus - fff96cc1a9 Doc: @file entries clean-up, take3 (add line-breaks) on the translation branch, also from Valentin. I think you are a good candidate to push the most recent history once passwords and all that jazz is working again. [git is working again!] It really doesn't matter who is pushing. To be sure, all people who have done `git push' in the last few days should push again. Provided there aren't unpushed commits in the private repositories, nothing can happen. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: volleyball issue 1336
On 30 November 2010 11:24, Graham Percival gra...@percival-music.ca wrote: There is a theory about why this happens, from Neil: It looks to me like the MultiMeasureRest has invalid bounds when cloned, so the cloned object is NULL when the MultiMeasureRestNumber is aligned (the parent object no longer exists) Can anybody think of a way to test this theory? i.e. I'm not asking how to stop this from happening. I'm not even asking for solid evidence that this is, in fact, happening. I'm just asking how we could *begin* the *attempt* to gather such evidence. See spanner.cc, lines 113-121. If this code doesn't exit the loop early, the crash goes away (since it allows the cloned spanner to exist outside its parent's bounds). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14 release, or GOP now (part 2)
On Wed, Dec 1, 2010 at 11:16 AM, Graham Percival gra...@percival-music.ca wrote: I'll wait another day for comments in case anybody missed it due to the savannah list downtime, but I despite my objection, I'll branch stable/2.14 in the next few days unless anybody speaks heavily against it. It might be better to wait just a bit more, Neil (possibly Reinhold) and I still have outstanding patches (by which I mean that these patches are awesome, of course :) I'm not sure your usual I'll do thisthat in 48 hours unless someone objects before then is the right approach here: you might want to consider announcing I'm planning to do thisthat, do I have your green light? and then wait for all major contributors (i.e. not me) to catch up. (Just a thought.) Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git history, Savannah
This sounds like the git repository is online again, and _some_ people are able to access it. Personally, I still get git pull Permission denied (publickey). fatal: The remote end hung up unexpectedly So _if_ others are able to access git, it would seem that the account data backup is quite older than the git repository itself. Hmm. According to http://savannah.gnu.org/, they are using a backup from Nov. 22nd, and write access has been restored today at 11:00 GMT. How should I proceed? Retry? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14 release, or GOP now (part 2)
On 11/30/10 1:04 AM, Graham Percival gra...@percival-music.ca wrote: On Mon, Nov 29, 2010 at 06:37:08AM -0700, Carl Sorensen wrote: What about option 0 -- try to coordinate the resources we currently have available on the critical issues? I would like that. I'm a bit surprised to see so many people talking about branching a stable/2.14 -- I don't think that would solve anything. I'm willing to try it as an experiment, but I really doubt that having a separate branch would encourage more people to spend more time on critical issues. Instead of doubles tennis, let's play volleyball. Let's all (or at least, everybody other than Joe+Neil+John) works together on an issue. Instead of one person hitting the ball back, let's have multiple people stop the ball, set it up, and then send it back. OK, I'm up for a volleyball game. However, I'm not sufficiently motivated to do it all by myself if lots of other people are only working on new features or discussing policy changes. If they're having fun, then I want to have fun too. But if there's a solid core of people doing the hard work of trying to fix critical issues, then I will absolutely be part of that group. Me too. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: server down?
On 28/11/2010 10:10, Werner LEMBERG wrote: Savannah is still down, see http://identi.ca/group/fsfstatus The message has been updated on http://identi.ca/group/fsfstatus they seem to have had some Storage Failure and are restoring the data. codewiz: lists.gnu.org down for a double drive failure on one RAID array. Data recovery in progress, will take some time. !fsfstatus about 5 hours ago from xmpp Then fsfstatus Full name (Monitor FSF and GNU Server Status) Location Boston, MA, US URL http://identi.ca/group/fsfsys Note FSF and GNU system status (machines / networks down / up) Sys Admins are cure, bernie, and peabo. See also fsfsys group. Aliases fsfsys gnustatus gnusys However I still cannot open http://git.savannah.gnu.org/gitweb/?p=lilypond.git as of 12:12 GMT. James ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git history, Savannah
Werner LEMBERG w...@gnu.org writes: This sounds like the git repository is online again, and _some_ people are able to access it. Personally, I still get git pull Permission denied (publickey). fatal: The remote end hung up unexpectedly So _if_ others are able to access git, it would seem that the account data backup is quite older than the git repository itself. Hmm. According to http://savannah.gnu.org/, they are using a backup from Nov. 22nd, and write access has been restored today at 11:00 GMT. How should I proceed? Retry? As mentioned elsewhere, your advice worked perfectly. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
`#(define page-breaking foo)' vs. `page-breaking = #foo'
Any reason why the 'page-breaking \paper variable tends to be declared with a scheme definition? I typically see it like this in the docs: #(define page-breaking ly:minimal-breaking) I prefer to use this form though: page-breaking = #ly:minimal-breaking In my commit b0a027f, I changed the standard setting for this in paper-defaults-init.ly, and nothing broke as far as I can tell. Any opposition to changing the other scheme-style declarations in the docs? Thanks - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `#(define page-breaking foo)' vs. `page-breaking = #foo'
On Tue, Nov 30, 2010 at 5:49 AM, Mark Polesky markpole...@yahoo.com wrote: In my commit b0a027f, I changed the standard setting for this in paper-defaults-init.ly, and nothing broke as far as I can tell. Any opposition to changing the other scheme-style declarations in the docs? Seems a lot nicer to me :) Please do! (btw: we should really have a native-looking syntax for such things as set-global-staff-size etc. as well. Is there a particular reason that makes it unachievable?) Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git history, Savannah
Valentin's merge which is currently the head^ on savannah is the same commit I have as master. I think it is likely to be the most current commit. As far as I can tell, all the commits you have identified are currently on savannah, and are in my local repository as well. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB target_cpu error
On Mon, Nov 29, 2010 at 11:23 AM, Valentin Villenave v.villen...@gmail.com wrote: Actually, this was a totally unnecessary precaution. I've never heard of any *nix system where uname -m would return X86_64 or I686 instead of their lower-case counterparts. ... Bottom line: let's get rid of it already. Could we get a patch for this soon? I wanted to make an unstable release last Sat. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Position of cue clefs?
On Mon, Nov 29, 2010 at 7:07 AM, Werner LEMBERG w...@gnu.org wrote: And it should be transposed to the instrument's transposition. I've seen untransposed cues too, especially in, say, Piano or Celesta parts with a mark `Klar. in A' , but this is probably just lazyness (or uncertainty or ignorance) of the engraver. I understand your point, but we might also have users (esp. in music schools) who would be happy to have the ability to use untransposed cue notes. Perhaps we could have a switchable property for that? like \set Score.transposableCueClef = ##t (disabled by default) BTW: I agree with everything else you said. Cue Clefs should avoid looking like proper Clefs at all costs! Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git history, Savannah
On 1 December 2010 10:00, Valentin Villenave valen...@villenave.net wrote: I've now pushed my master branch (with one additional commit wrt the tempo-range feature that Neil will now dismember in order to rebase his own patch :-) Please let me know if I should also push my translations branch or something; I think this is premature until we're sure Savannah won't do another restore from backup (the site suggests this might happen). BTW, you should rebase before pushing (git pull -r); current master has duplicate commits. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: removal of all 'fragment' instances in the @Lilypond examples
hello, This is (I hope) a relatively trivial patch for the Learning Manual http://codereview.appspot.com/3369041 Just a removal of all 'fragment' instances in the @Lilypond examples. James ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `#(define page-breaking foo)' vs. `page-breaking = #foo'
Mark Polesky markpole...@yahoo.com writes: Any reason why the 'page-breaking \paper variable tends to be declared with a scheme definition? I typically see it like this in the docs: #(define page-breaking ly:minimal-breaking) I prefer to use this form though: page-breaking = #ly:minimal-breaking In my commit b0a027f, I changed the standard setting for this in paper-defaults-init.ly, and nothing broke as far as I can tell. Any opposition to changing the other scheme-style declarations in the docs? There is a difference between the two forms. The former sneaks by Lilypond's parser completely (executing it at scanning time), the latter executes the assignment itself in sync with the Lilypond parser. In borderline cases, the second might lead to more sane results. However, if you write something like page-breaking = #ly:minimal-breaking #(define xxx page-breaking) it is conceivable that xxx is defined as the _old_ value of page-breaking. I don't particularly like this asynchronicity. I think that your proposed change feels saner, all in all. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gettext status?
Le 30/11/2010 21:46, Valentin Villenave disait : On Sun, Nov 28, 2010 at 4:33 PM, Jean-Charles Malahieude lily...@orange.fr wrote: If you have a look at http://translationproject.org/domain/lilypond.html you'll see that the template file is as of 2.13.7, which means that anything that has disappeared form the sources will remain in the record and what has been amended or added since then is absent. Indeed. That's inconvenient. As a matter of fact, any major version should be preceded by an upload of a new template (assignees get automatically acknowledged by the FTP) in order to have an up to date set of translated messages. Okay. What do you suggest? Are you able (and willing!) to update the template? Is there anything I can do in this regard? Otherwise, I'll just send you my .po file when I'm done and leave you to do... well, whatever it is you wanna do with it :-) As a matter of fact, I first of all would like to /get rid of/ spacing.itely before 2.13.999 comes out. Before doing anything, I will try to generate a template, and ask John if there is a specific procedure to upload it on the FTP. By the way, I might do it as well for the docs, which are not under the control of the FTP. These separate po files deal with comments and variable names from the snippets. Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
paper-defaults-init.ly questions
I found these in paper-defaults-init.ly: #(define make-header (...)) #(define make-footer (...)) #(define font-defaults '((...))) #(define text-font-defaults `((...))) 1) Do we need the quasiquote ` for text-font-defaults? Wouldn't a regular quote ' be fine? 2) Are these \paper variables like the others or is that a misconception? Is there value in declaring them like the rest of the \paper variables? Like so: make-header = #(...) make-footer = #(...) font-defaults = #'((...)) text-font-defaults = #'((...)) Should they be listed alongside the other \paper variables in NR 4.1? 3) I'd like to change this... mm = 1.0 in = 25.4 pt = #(/ in 72.27) cm = #(* 10 mm) ...to this... mm = #1.0 cm = #(* 10 mm) in = #(* 25.4 mm) pt = #(/ in 72.27) Would that be better? 4) These numbers should have a # in front of them, right? blank-after-score-page-force = 2 blank-last-page-force = 0 blank-page-force = 5 Thanks. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: server down?
On Tue, 2010-11-30 at 12:12 +, James wrote: On 28/11/2010 10:10, Werner LEMBERG wrote: Savannah is still down, see http://identi.ca/group/fsfstatus However I still cannot open http://git.savannah.gnu.org/gitweb/?p=lilypond.git as of 12:12 GMT. James One wonders whether the -devel community has looked into gittorrent: http://advogato.org/article/994.html Given the effect of putting all the eggs in one basket, distributed git seems quite interesting. Colin -- --- Since we are destined to live out our lives in the prison of our minds, our one duty is to furnish it well. - Sir Peter Ustinov, actor, writer and director (1921-2004) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: NR 4: Minor edits. (issue3406041)
Reviewers: , Message: Here's a patch to clean up the NR spacing chapter a little more. Does everything look okay? Thanks. - Mark Description: Doc: NR 4: Minor edits. Please review this at http://codereview.appspot.com/3406041/ Affected files: M Documentation/notation/spacing.itely ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
