Re: lilymidi: Add --pretty switch to lilymidi.py to display midi in human-readable form (with --dump) (issue4628078)
On Sun, Jul 03, 2011 at 03:45:09PM -0600, Colin Campbell wrote: Given the above, perhaps it would be wise to defer any formal Patch Meister role until we have decided how (and if) patches are to be recorded. I can carry on with keeping an eye on the tracker, but anything else would require either manually logging postings on -devel or periodic manual scans of each (known) developer's patches on Reitveld. What about discussing this sooner rather than later? Next wednesday is already marked for Phil's build system output: http://lilypond.org/~graham/gop/gop_5.html but we could begin the patch handling discussion on 13 July. That's only 2 days after I return to Canada, so I'm not likely to have a good proposal ready. Could you write one? Phil wrote his build system proposal; it would be great if you could write a similar one for patch handling. Remarks from the CG: Patch review tool: Reitveld is inconvenient in some respects: it requires a google account, and there’s no way to see all patches relating to lilypond. Should we switch to something like gerritt? http://code.google.com/p/lilypond/issues/detail?id=1184 (prep: 5 hours. discuss: 15 hours) More elabortation: - what are the patch review frameworks out there? - how well do they support git? automatically tracking patches? ease of making reviews? etc. - what kind of manual administration is required for each tool? - what policies should we have? what should/must developers do? what should/must reviewers do? what else is there left to do? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)
k-ohara5...@oco.net wrote Monday, July 04, 2011 4:33 AM I really, really, wish Astyle had a fully gnu-compliant mode out of the box. I went through the regexp's again and think this is good to go. I agree. This is a big improvement, and would give us control over the layout style ourselves (rather than what emacs does). The odd niggle is not important; consistency is. Thanks for pursuing this to a satisfactory conclusion, Keith! Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fixes multiple line glissandos the right way. (issue4631086)
Reviewers: , Message: Passes regtests - should be good to go! Thanks to Neil Han-Wen for the help. Cheers, MS Description: Fixes multiple line glissandos the right way. Please review this at http://codereview.appspot.com/4631086/ Affected files: M lily/line-spanner.cc M scm/define-grobs.scm M scm/output-lib.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)
Trevor Daniels writes: I agree. This is a big improvement, and would give us control over the layout style ourselves (rather than what emacs does). While the work being done here is possibly a good thing, let me remind you once more that we are a GNU project and thus use the GNU standards and thus we need no control over, we need not decide about, we need not discuss layout style. That's a feature. The GNU standards are implemented by Emacs, and if it makes an error, then that's a serious bug that should be reported (to emacs). It seems to me that someone is spending a lot of effort `just' to accomodate people who haven't found how awesome Emacs is to edit code and thus introduce layout problems. This makes it now easier to use another editor than Emacs, which may or may not be an improvement. While choice is good, in this case it decreases the need for non-Emacs users to try Emacs, and I'm not at all sure if that's a feature. Greetings, Jan. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)
On Mon, Jul 04, 2011 at 11:28:19AM +0200, Jan Nieuwenhuizen wrote: While the work being done here is possibly a good thing, let me remind you once more that we are a GNU project and thus use the GNU standards and thus we need no control over, we need not decide about, we need not discuss layout style. That's a feature. then WTF is fixcc.py ?! (the original one, pre-astyle) LilyPond has a *huge* history of deviating from GNU standards. This makes it now easier to use another editor than Emacs, which may or may not be an improvement. While choice is good, in this case it decreases the need for non-Emacs users to try Emacs, and I'm not at all sure if that's a feature. I'm sorry, I thought this was a project to create aesthetically beautiful notation. Not an emacs is awesome and let's force everybody to use my favorite text editor project. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilymidi: Add --pretty switch to lilymidi.py to display midi in human-readable form (with --dump) (issue4628078)
On Mon, Jul 04, 2011 at 08:14:45AM +0100, Graham Percival wrote: Remarks from the CG: Patch review tool: Reitveld is inconvenient in some respects: it requires a google account, and there’s no way to see all patches relating to lilypond. Should we switch to something like gerritt? http://code.google.com/p/lilypond/issues/detail?id=1184 Further to that: I just merged some changes by Dmytro to the lilypond-extra repository on github, and I was blown away by the interface. Github has *really* done a good job on the UI / user experience. It might be worth investigating this as a potential review tool. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: compiling documentation
Hello, )-Original Message- )From: lilypond-devel-bounces+james.lowe=datacore@gnu.org )[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On )Behalf Of Jonathan Kulp )Sent: 03 July 2011 16:35 )To: Graham Percival )Cc: lilypond-devel@gnu.org )Subject: Re: compiling documentation ) )On Sun, Jul 3, 2011 at 10:26 AM, Graham Percival graham@percival- )music.ca wrote: ) On Sun, Jul 03, 2011 at 10:18:56AM -0500, Jonathan Kulp wrote: ) On Sun, Jul 3, 2011 at 8:22 AM, Graham Percival ) gra...@percival-music.ca wrote: ) ) My goodness. I assume this is with lilydev? Can you reproduce it ) on the command-line? ... ) )I'm running Linux Mint Debian Edition, which is based on Debian Testing )branch. Not sure what consequences that might have for this situation. I )just run apt-get build-dep lilypond when setting up build env. I also )install gnome-common for autoconf package and dblatex. [James' reply:] I use LilyDev exclusively but have experimented with Debian dists (such as a straight *buntu) about 6 mon ths back and then following the CG and could get things to work back then (IIRC I only had to do the build-dep thing and then get autoconf as there was no issue at that time with dblatex), but if it isn't too much effort to install Virtual Box and install Lilydev just to see if you get the same problems (with a speedyish internet connection you can be up, compiling in about 30 minutes) it would certainly help to see what the issue is - at least fundamentally prove that it works (as it does for me). We may then need to update the CG for non-lilydev users. However ./autogen.sh and/or ./configure should report any missing/old/wrong dependencies. So do you get anything back from them (you will probably get something about a 'recommended' Fontforge version as I do - the lilydev version is fine if one or two revs back) James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)
Am Montag 04 Juli 2011, 11:28:19 schrieb Jan Nieuwenhuizen: The GNU standards are implemented by Emacs, and if it makes an error, then that's a serious bug that should be reported (to emacs). It seems to me that someone is spending a lot of effort `just' to accomodate people who haven't found how awesome Emacs is to edit code and thus introduce layout problems. This makes it now easier to use another editor than Emacs, which may or may not be an improvement. While choice is good, in this case it decreases the need for non-Emacs users to try Emacs, and I'm not at all sure if that's a feature. Oh that irony! Isn't one of the main ideas of FOSS to give you the freedom to choose which software you want to use rather than locking you down to one particular choice? It's really ironic that the argument now is that everyone is supposed to use emacs and those who don't should be slightly forced to use it. And no, I don't use emacs, and I won't use it in the future either (I'm using kate). If that means that my code is not formatted according to the GNU standard, okay so be it. What doesn't really help is that the GNU coding standard is not very clearly spelled out. Several things are defined as teh output of Emacs (compare the OOXML specification, in part defined as behave as Wort 97 does). Cheers, REInhold -- -- Reinhold Kainhofer, Vienna University of Technology, Austria email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * Edition Kainhofer Music Publishing, http://www.edition-kainhofer.com/ * LilyPond music typesetting software, http://www.lilypond.org/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix issue 75: Allow multiple concurrent slurs (issue4643067)
Reviewers: J_lowe, Message: On 2011/07/04 00:18:07, J_lowe wrote: Hello, I get an error when I try to make: That's fixed now. Cheers, Reinhold Description: Fix issue 75: Allow multiple concurrent slurs Rewrite the Slur_engraver and the Phrasing_slur_engraver to support multiple concurrent slurs. The default lilypond syntax using parentheses still supports only one slur at a time, but by adding a slur-id property to the (Phrasing)SlurEvent music expression, one can create multiple concurrent slurs, each with a different slur-id. This finally allows appoggiaturas and acciaccaturas (which both create a slur from the grace note the the next note) to be placed inside a slur. Please review this at http://codereview.appspot.com/4643067/ Affected files: A input/regression/phrasing-slur-multiple.ly A input/regression/slur-grace.ly A input/regression/slur-multiple.ly M lily/phrasing-slur-engraver.cc M lily/slur-engraver.cc M lily/slur.cc M ly/grace-init.ly M scm/define-grob-properties.scm M scm/define-grobs.scm M scm/define-music-properties.scm M scm/define-music-types.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Adds a warning for non-list fingeringOrientations settings. (issue4650070)
Reviewers: ,
Message:
Fixes issue 1734.
Description:
Adds a warning for non-list fingeringOrientations settings.
Please review this at http://codereview.appspot.com/4650070/
Affected files:
M lily/new-fingering-engraver.cc
Index: lily/new-fingering-engraver.cc
diff --git a/lily/new-fingering-engraver.cc b/lily/new-fingering-engraver.cc
index
db99dede95b2979324c3d7858911928bb67ac069..9909790b1d72e0c368f91837c078c4e6af4029bf
100644
--- a/lily/new-fingering-engraver.cc
+++ b/lily/new-fingering-engraver.cc
@@ -178,6 +178,11 @@ void
New_fingering_engraver::position_scripts (SCM orientations,
vectorFinger_tuple *scripts)
{
+ if (scm_list_p (orientations) != SCM_BOOL_T)
+{
+ warning (fingeringOrientations must be a list. Setting to '(up
down).);
+ orientations = scm_list_2 (ly_symbol2scm (up), ly_symbol2scm
(down));
+}
for (vsize i = 0; i scripts-size (); i++)
if (stem_ to_boolean (scripts-at (i).script_-get_property
(add-stem-support)))
Side_position_interface::add_support (scripts-at (i).script_,
stem_);
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix issue 75: Allow multiple concurrent slurs (issue4643067)
reinhold.kainho...@gmail.com writes: Description: Fix issue 75: Allow multiple concurrent slurs Rewrite the Slur_engraver and the Phrasing_slur_engraver to support multiple concurrent slurs. The default lilypond syntax using parentheses still supports only one slur at a time, but by adding a slur-id property to the (Phrasing)SlurEvent music expression, one can create multiple concurrent slurs, each with a different slur-id. This finally allows appoggiaturas and acciaccaturas (which both create a slur from the grace note the the next note) to be placed inside a slur. Here is my principal beef: slurs are just one of a bunch of spanners that can be instantiated only once per voice (text spanners are particularly bad I think). So I would consider it nice if this sort of functionality was implemented as a general extension on spanners. In case that a general extension is infeasible at this point of time, similar extensions remain thinkable for other spanners, and at least the user experience should be somewhat compatible. So as a minimal change request, I would suggest using spanner-id instead of slur-id, in the hope that a later implementation might be able to generalize this without a change in syntax. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compiling documentation
On Mon, Jul 4, 2011 at 4:58 AM, James Lowe james.l...@datacore.com wrote: )I'm running Linux Mint Debian Edition, which is based on Debian Testing )branch. Not sure what consequences that might have for this situation. I )just run apt-get build-dep lilypond when setting up build env. I also )install gnome-common for autoconf package and dblatex. [James' reply:] I use LilyDev exclusively but have experimented with Debian dists (such as a straight *buntu) about 6 mon ths back and then following the CG and could get things to work back then (IIRC I only had to do the build-dep thing and then get autoconf as there was no issue at that time with dblatex), but if it isn't too much effort to install Virtual Box and install Lilydev just to see if you get the same problems (with a speedyish internet connection you can be up, compiling in about 30 minutes) it would certainly help to see what the issue is - at least fundamentally prove that it works (as it does for me). We may then need to update the CG for non-lilydev users. However ./autogen.sh and/or ./configure should report any missing/old/wrong dependencies. So do you get anything back from them (you will probably get something about a 'recommended' Fontforge version as I do - the lilydev version is fine if one or two revs back) My build env is fine, or at least it has been for more than a year. The doc-compile problem only started a couple of weeks ago. I have lilydev installed on another hard drive. Maybe I'll pop it in and try it out. I'd rather not bother with VMs at the moment. Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilymidi: Add --pretty switch to lilymidi.py to display midi in human-readable form (with --dump) (issue4628078)
On 11-07-04 03:54 AM, Graham Percival wrote: On Mon, Jul 04, 2011 at 08:14:45AM +0100, Graham Percival wrote: Remarks from the CG: Patch review tool: Reitveld is inconvenient in some respects: it requires a google account, and there’s no way to see all patches relating to lilypond. Should we switch to something like gerritt? http://code.google.com/p/lilypond/issues/detail?id=1184 Further to that: I just merged some changes by Dmytro to the lilypond-extra repository on github, and I was blown away by the interface. Github has *really* done a good job on the UI / user experience. It might be worth investigating this as a potential review tool. Cheers, - Graham I'll see what I can put together, Graham. I'm looking toward something like trac, which would combine issue tracking with patch management. Colin -- The human race has one really effective weapon, and that is laughter. -- Mark Twain ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds a warning for non-list fingeringOrientations settings. (issue4650070)
On 2011/07/04 12:38:06, MikeSol wrote: Fixes issue 1734. On 2011/07/04 12:38:06, MikeSol wrote: Fixes issue 1734. I think this covers up the real problem: context settings in a \layout block have no type check. Your addition simply duplicates Guile's error message for fingeringOrientations set in music (and doesn't cover stringNumberOrientations or strokeFingerOrientations). http://codereview.appspot.com/4650070/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds a warning for non-list fingeringOrientations settings. (issue4650070)
On Jul 4, 2011, at 2:47 PM, n.putt...@gmail.com wrote: On 2011/07/04 12:38:06, MikeSol wrote: Fixes issue 1734. On 2011/07/04 12:38:06, MikeSol wrote: Fixes issue 1734. I think this covers up the real problem: context settings in a \layout block have no type check. I didn't realize this was the real issue :) Any tips as to how one would go about fixing this? Anything that happens before engravers kick in (dispatchers, parsers, etc.) remains a mystery to me... Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds a warning for non-list fingeringOrientations settings. (issue4650070)
On 4 July 2011 13:53, m...@apollinemike.com m...@apollinemike.com wrote: I didn't realize this was the real issue :) Any tips as to how one would go about fixing this? Anything that happens before engravers kick in (dispatchers, parsers, etc.) remains a mystery to me... Context_def::add_context_mod () is where the assignment takes place (and you can see from set_property () how the type-checking is done). I suppose though this is deliberate, otherwise every compilation would redundantly type-check settings from default context definitions, which we assume are correct (i.e., from engraver-init.ly/performer-init.ly). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds a warning for non-list fingeringOrientations settings. (issue4650070)
On 7/4/11 7:14 AM, Neil Puttock n.putt...@gmail.com wrote: On 4 July 2011 13:53, m...@apollinemike.com m...@apollinemike.com wrote: I didn't realize this was the real issue :) Any tips as to how one would go about fixing this? Anything that happens before engravers kick in (dispatchers, parsers, etc.) remains a mystery to me... Context_def::add_context_mod () is where the assignment takes place (and you can see from set_property () how the type-checking is done). I suppose though this is deliberate, otherwise every compilation would redundantly type-check settings from default context definitions, which we assume are correct (i.e., from engraver-init.ly/performer-init.ly). Would a redundant check of settings from default context definitions be a problem? I can't imagine that such a check would take 1% of the processing time. Plus, I don't think it's really a redundant check; I think it's a real check. Absent such a check, we're trusting on the *-init.ly files being correct, which admits a potential programming error. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds a warning for non-list fingeringOrientations settings. (issue4650070)
On 4 July 2011 15:31, Carl Sorensen c_soren...@byu.edu wrote: Would a redundant check of settings from default context definitions be a problem? I can't imagine that such a check would take 1% of the processing time. I don't know, though I agree is unlikely to be a significant overhead. Plus, I don't think it's really a redundant check; I think it's a real check. Absent such a check, we're trusting on the *-init.ly files being correct, which admits a potential programming error. The *-init.ly files are covered by regression testing since -dcheck-internal-types triggers an assertion error for incorrect context property settings. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds a warning for non-list fingeringOrientations settings. (issue4650070)
Am Montag, 4. Juli 2011, 16:39:08 schrieb Neil Puttock: On 4 July 2011 15:31, Carl Sorensen c_soren...@byu.edu wrote: Plus, I don't think it's really a redundant check; I think it's a real check. Absent such a check, we're trusting on the *-init.ly files being correct, which admits a potential programming error. The *-init.ly files are covered by regression testing since -dcheck-internal-types triggers an assertion error for incorrect context property settings. Is there any possibility to install those checks only after all internal init files have been processed? 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 https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds a warning for non-list fingeringOrientations settings. (issue4650070)
On Jul 4, 2011, at 5:04 PM, Reinhold Kainhofer wrote: Am Montag, 4. Juli 2011, 16:39:08 schrieb Neil Puttock: On 4 July 2011 15:31, Carl Sorensen c_soren...@byu.edu wrote: Plus, I don't think it's really a redundant check; I think it's a real check. Absent such a check, we're trusting on the *-init.ly files being correct, which admits a potential programming error. The *-init.ly files are covered by regression testing since -dcheck-internal-types triggers an assertion error for incorrect context property settings. Is there any possibility to install those checks only after all internal init files have been processed? Alternatively, there could be a lazy_internal_set_property method in context.cc that has a scheme binding accessed in the init files. To make sure regtests work, we could make it so that this is still responsive to the assert error for type checking. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds redirect-lilypond-output option to lilypond-book (issue4664060)
- Original Message - From: percival.music...@gmail.com To: philehol...@googlemail.com; em...@philholmes.net Cc: lilypond-devel@gnu.org; re...@codereview.appspotmail.com Sent: Sunday, July 03, 2011 7:25 PM Subject: Re: Adds redirect-lilypond-output option to lilypond-book (issue4664060) LGTM, and fantastic website with testing info. I have three requests for future work, but this patch should get pushed first. - the final Child returned 1 doesn't tell me (as a user/doc-writer, rather than phd student) anything. How hard would it be to put the Look in logfile... line after that one? (a very quick skim suggests that this would be icky, so maybe forget about it) Or maybe just make the child returned into Error: could not complete command, or maybe Error: child returned __insert_error_code_interpretation__ ? AFAICS this is a doddle to change. I'll do this as a follow up piece of work unless you want it earlier. - it's a bit weird to see tons of output even when using the --redirect-lilypond-output. Would it be possible to make a --use-logfiles option which automatically turns on --redirect-lilypond-output, but also captures stderr+stdlog and writes *those* to a file? (and maybe in addition to writing the log file, it would display the Error: child returned __blah_blah__ line) Don't think so, at present. From my reading of the Python, progress and error messages mostly go to stderr, as does the error message. To make it so that we don't see progress but do see the error message would be something of a rewrite of how progress and errors are handled in lilylib and lilypond-book. So, we need the GOP debate on stderr versus stdout. - it would be great to automatically show the last X lines of the logfile. (but that's definitely something to do later on) It needs to be a bit cleverer than that. The last 5 lines are: Converting to `/home/phil/TestFolder/BookTest/c4/lily-4139797f-2.pdf'... Writing /home/phil/TestFolder/BookTest/c4/lily-4139797f-systems.texi... Writing /home/phil/TestFolder/BookTest/c4/lily-4139797f-systems.tex... Writing /home/phil/TestFolder/BookTest/c4/lily-4139797f-systems.count... error: failed files: c4/lily-4139797f.ly In this case, it needs line 32 out of 52 (which says): rest-note-collision.ly:9:0: error: unknown escaped string: `\PhilWasHere' I'll have a think. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)
Jan Nieuwenhuizen wrote Monday, July 04, 2011 10:28 AM Trevor Daniels writes: I agree. This is a big improvement, and would give us control over the layout style ourselves (rather than what emacs does). While the work being done here is possibly a good thing, let me remind you once more that we are a GNU project and thus use the GNU standards and thus we need no control over, we need not decide about, we need not discuss layout style. That's a feature. I looked at the GNU coding standards for C: http://www.gnu.org/prep/standards/standards.html#Formatting They are defined very loosely, and are recommendations rather than hard requiements. To quote: We don’t think of these recommendations as requirements, because it causes no problems for users if two different programs have different formatting styles. But whatever style you use, please use it consistently, since a mixture of styles within one program tends to look ugly. If you are contributing changes to an existing program, please follow the style of that program. So what we are doing seems to me to be quite compatible with GNU standards. The GNU standards are implemented by Emacs, and if it makes an error, then that's a serious bug that should be reported (to emacs). It seems to me that someone is spending a lot of effort `just' to accomodate people who haven't found how awesome Emacs is to edit code and thus introduce layout problems. This makes it now easier to use another editor than Emacs, which may or may not be an improvement. While choice is good, in this case it decreases the need for non-Emacs users to try Emacs, and I'm not at all sure if that's a feature. Surely you're not serious! Are you?? Decreasing the need for Emacs is the whole point of this discussion. Greetings, Jan. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)
On 7/4/11 3:28 AM, Jan Nieuwenhuizen jann...@gnu.org wrote: Trevor Daniels writes: I agree. This is a big improvement, and would give us control over the layout style ourselves (rather than what emacs does). While the work being done here is possibly a good thing, let me remind you once more that we are a GNU project and thus use the GNU standards and thus we need no control over, we need not decide about, we need not discuss layout style. That's a feature. The GNU standards are implemented by Emacs, and if it makes an error, then that's a serious bug that should be reported (to emacs). It seems to me that someone is spending a lot of effort `just' to accomodate people who haven't found how awesome Emacs is to edit code and thus introduce layout problems. This makes it now easier to use another editor than Emacs, which may or may not be an improvement. While choice is good, in this case it decreases the need for non-Emacs users to try Emacs, and I'm not at all sure if that's a feature. I've tried Emacs, and I can't see the benefits justifying fighting through the learning curve. It's not comfortable for me; I have 30+ years of experience with vi(m), so it's hardwired in my bones. We need more, not fewer, developers on LilyPond. Why would we want to force people to try Emacs as a condition of helping out with LilyPond? Do we want to try to prohibit people from using Jedit, or Frescobaldi, since they're not Emacs? And I refuse, on principle, to accept a standard that says do it the way software package XYZ does it. This is not a standard, it's an excuse for not having a standard. That's behavior I'd expect from a proprietary software house, not from an organization that advocates software freedom. It's a peculiar type of freedom that says you're free to do anything you want with the software, except make changes in an editor other than our approved editor. Now I realize that nobody is forced to follow the GNU coding standards; they can modify the code to their heart's content and keep a separate distro from the official distro. But there's something philosophically wrong about this, and it seems to me that it's largely laziness on the part of the FSF.They are unwilling to define a standard that is other than machine-readable (a set of elisp macros and settings is only machine-readable, even if it's human understandable). So although this is a GNU project, I feel perfectly comfortable with advocating a style that is enforced by a project-specific tool that can be used by contributors working in any editor, rather than tying it to Emacs. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compiling documentation
On Mon, Jul 4, 2011 at 7:55 AM, Jonathan Kulp jonlancek...@gmail.com wrote: However ./autogen.sh and/or ./configure should report any missing/old/wrong dependencies. So do you get anything back from them (you will probably get something about a 'recommended' Fontforge version as I do - the lilydev version is fine if one or two revs back) My build env is fine, or at least it has been for more than a year. The doc-compile problem only started a couple of weeks ago. I have lilydev installed on another hard drive. Maybe I'll pop it in and try it out. I'd rather not bother with VMs at the moment. Well everything built fine on my lilydev system. Must be something wrong on Mint Debian. I get segfaults running 2.15.4 on my regular lilypond files too. No build errors compiling LP, but the compiled LP doesn't work right. :shrug: Not going to try to track this down ATM. Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)
On Mon, 04 Jul 2011 09:32:21 -0700, Trevor Daniels t.dani...@treda.co.uk wrote: Jan Nieuwenhuizen wrote Monday, July 04, 2011 10:28 AM It seems to me that someone is spending a lot of effort `just' to accommodate people who haven't found how awesome Emacs is to edit code and thus introduce layout problems. Surely you're not serious! Are you?? The emacs versus vi religious war is an old running joke. You'll notice that some of the gnu coding standards you linked to, like braces on do-while, are specifically designed to defend against emacs's awesome ability to introduce layout problems. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
modifying default behaviour of tremolo slashes (issue4636081)
Reviewers: xratamacue_hotmail.com, reinhold_kainhofer.com,
Message:
Passes regtests.
Description:
modifying default behaviour of tremolo slashes
It turned out that tremolo slashes should have
quite constant slope (definately not depending
on beam slope), so i change that. I also changed
slash style so that it isn't rectangle in any
cases by dafault.
Please review this at http://codereview.appspot.com/4636081/
Affected files:
M lily/stem-tremolo.cc
Index: lily/stem-tremolo.cc
diff --git a/lily/stem-tremolo.cc b/lily/stem-tremolo.cc
index
4d1678889a63ee382a4a207bf5d31fd2424194f2..2163f08bca4737b1cd1fbdb631471d0b823e84e5
100644
--- a/lily/stem-tremolo.cc
+++ b/lily/stem-tremolo.cc
@@ -37,6 +37,10 @@ Stem_tremolo::calc_slope (SCM smob)
Grob *stem = unsmob_grob (me-get_object (stem));
Spanner *beam = Stem::get_beam (stem);
+ /* We used to have tremolo slashes angled exactly like beams
+ (if the note had a beam), but it turned out
+ that it's not proper notation.
+
if (beam)
{
Real dy = 0;
@@ -54,11 +58,13 @@ Stem_tremolo::calc_slope (SCM smob)
return scm_from_double (dx ? dy / dx : 0);
}
else
-/* down stems with flags should have more sloped trems (helps avoid
- flag/stem collisions without making the stem very long) */
-return scm_from_double (
-(Stem::duration_log (stem) = 3 get_grob_direction (stem) ==
DOWN) ?
- 0.40 : 0.25);
+ */
+
+ /* down stems with flags should have more sloped trems (helps avoid
+ flag/stem collisions without making the stem very long) */
+ return scm_from_double (
+ (Stem::duration_log (stem) = 3 get_grob_direction (stem) ==
DOWN) ?
+0.40 : 0.25);
}
MAKE_SCHEME_CALLBACK (Stem_tremolo, calc_width, 1)
@@ -79,6 +85,10 @@ MAKE_SCHEME_CALLBACK (Stem_tremolo, calc_style, 1)
SCM
Stem_tremolo::calc_style (SCM smob)
{
+ /* We used to use rectangle tremolo style for beamed notes
+ and flagged upstem notes, but it looks like it shouldn't
+ be done that way.
+
Grob *me = unsmob_grob (smob);
Grob *stem = unsmob_grob (me-get_object (stem));
Direction stemdir = get_grob_direction (stem);
@@ -86,6 +96,9 @@ Stem_tremolo::calc_style (SCM smob)
bool flag = Stem::duration_log (stem) = 3 !beam;
return ly_symbol2scm (((stemdir == UP flag) ||
beam) ? rectangle : default);
+ */
+
+ return ly_symbol2scm (default);
}
Real
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: modifying default behaviour of tremolo slashes (issue4636081)
Looks mostly good to me. Thanks, Carl http://codereview.appspot.com/4636081/diff/1/lily/stem-tremolo.cc File lily/stem-tremolo.cc (right): http://codereview.appspot.com/4636081/diff/1/lily/stem-tremolo.cc#newcode42 lily/stem-tremolo.cc:42: that it's not proper notation. We shouldn't keep the code in and commented out; let's just get rid of it. No old cruft kept around. http://codereview.appspot.com/4636081/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
an example of minimal example (issue4636082)
Reviewers: Graham Percival, james.lowe_datacore.com,
Message:
In response to
http://lists.gnu.org/archive/html/lilypond-user/2011-07/msg00060.html
Description:
an example of minimal example
for some people it's not clear enough how tiny
a tiny example should be. So i used a recently
discussed example to illustrate it.
Please review this at http://codereview.appspot.com/4636082/
Affected files:
M Documentation/web/community.itexi
Index: Documentation/web/community.itexi
diff --git a/Documentation/web/community.itexi
b/Documentation/web/community.itexi
index
d6918d1fbc0504526444c58c5edac755016938ac..7f9551a5a8d1521c084904625025910cf1334d19
100644
--- a/Documentation/web/community.itexi
+++ b/Documentation/web/community.itexi
@@ -270,7 +270,37 @@ guidelines for @ref{Bug reports}.}
@divClass{column-center-top}
@subheading What are @qq{Tiny examples}?
-A tiny example is an example from which nothing can be removed.
+A tiny example is an example from which @strong{nothing} can be removed.
+
+Is the code below a minimal example?
+
+@lilypond
+\version 2.14.1
+\include english.ly
+
+\score {
+ \new Staff {
+ \key d \major
+ \numericTimeSignature
+ \time 2/4
+ cs' d'' b''16 cs' d'' b''8.
+ %% Here: the tie on the D's looks funny
+ %% Too tall? Left-hand endpoint is not aligned with the B tie?
+ ~
+ cs' d'' b''8 [ b d'' a'' ]
+ }
+}
+@end lilypond
+
+Well, it is not very big, but a truly minimal example is here:
+
+@lilypond
+\version 2.14.1
+{
+ % middle tie looks funny here:
+ c' d'' b''8. ~ c' d'' b''8
+}
+@end lilypond
@divEnd
@divClass{column-left-bottom}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Release candidate for 2.14.2
As far as I can see, all bugfixes from the 2.15 branch are now backported to stable/2.14 I plan to ask Graham to release a new version on Saturday, July 9. There have been only minor documentation changes since 2.14.1, IIUC, but I would invite the translators to check to see if there is any work needed to be done before 2.14.2 comes out. I know there is one pending patch that I expect to see in a few hours. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: an example of minimal example (issue4636082)
I like this, but I think it should have a little bit more information. I don't think that the changes in the comments affect whether it is minimal or not -- perhaps the comments should be the same in both cases. What we wanted to get rid of is any unnecessary LilyPond input. In this case that means \score, \newStaff, \key d \major, \numericTimeSignature, and \time 2/4. We also got rid of unnecessary notes. Since we were focusing on the ties, we only needed the tied notes. HTH, Carl http://codereview.appspot.com/4636082/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: modifying default behaviour of tremolo slashes (issue4636081)
Hi Janek, I'm afraid I don't like this at all. While the authorities may be in agreement that the slashes should be sloped, all the scores I've looked at follow the same style as LilyPond (which I think reflects a more traditional hand-engraved style). It would be preferable to allow users to choose whether to keep the current default or switch to the more modern behaviour. This could be as simple as adding a calc-slope callback which ignores beams and setting style to 'default. Cheers, Neil http://codereview.appspot.com/4636081/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Separate flags into their own sub-font. (issue4654084)
LGTM! Thank you, Carl! http://codereview.appspot.com/4654084/diff/42/mf/feta-flags-generic.mf File mf/feta-flags-generic.mf (right): http://codereview.appspot.com/4654084/diff/42/mf/feta-flags-generic.mf#newcode4 mf/feta-flags-generic.mf:4: % Copyright (C) 1997--2011 Han-Wen Nienhuys han...@xs4all.nl Shouldn't your name be here, Carl? http://codereview.appspot.com/4654084/diff/42/mf/feta-scripts.mf File mf/feta-scripts.mf (right): http://codereview.appspot.com/4654084/diff/42/mf/feta-scripts.mf#newcode1450 mf/feta-scripts.mf:1450: begingroup; You added this because every glyph should be in some group now? http://codereview.appspot.com/4654084/diff/42/mf/feta-scripts.mf#newcode1452 mf/feta-scripts.mf:1452: height# := staff_space#; are the colons only a matter of style? http://codereview.appspot.com/4654084/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: an example of minimal example (issue4636082)
We need to be careful about adding stuff to the webpage; perfection is
when there's nothing left to remove, not when there's nothing left to
add.
I'm glad that you're working on it! I'm just warning you that there
will be many nitpicks.
http://codereview.appspot.com/4636082/diff/3/Documentation/web/community.itexi
File Documentation/web/community.itexi (right):
http://codereview.appspot.com/4636082/diff/3/Documentation/web/community.itexi#newcode273
Documentation/web/community.itexi:273: A tiny example is an example from
which @strong{nothing} can be removed.
I'm happy with this change.
http://codereview.appspot.com/4636082/diff/3/Documentation/web/community.itexi#newcode275
Documentation/web/community.itexi:275: Is the code below a minimal
example?
This is way too long. I spent a lot of time and effort making the
website as minimal as possible to increase readability
Hmm... I'd be ok with it if you put it in a box at the bottom of the
page. I actually can't believe that we don't have any examples on the
Tiny examples page -- the only place to find something is on the Bug
reports page!
http://codereview.appspot.com/4636082/diff/3/Documentation/web/community.itexi#newcode277
Documentation/web/community.itexi:277: @lilypond
this won't compile; it would have to be @example instead, and that will
require @{ @} escapes.
http://codereview.appspot.com/4636082/diff/3/Documentation/web/community.itexi#newcode346
Documentation/web/community.itexi:346: using less than a single measure.
I prefer only. If somebody gets it down to 1 measure, we're not going
to quibble about 2 beats vs. 4 beats.
http://codereview.appspot.com/4636082/diff/3/Documentation/web/community.itexi#newcode353
Documentation/web/community.itexi:353: 2 lines of code, and few exceed
10 lines.
Hmm. I'm worried that this (combined with the next item) would make the
page too wordy. Leave it in there for the next draft, but I may
complain about it later.
http://codereview.appspot.com/4636082/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)
On 2011/07/04 01:54:40, Carl wrote: Instead of filtering out bad events, I chose to filter in only events with ligature interfaces. That's a lot of internal_has_interface () calls. :) You might as well create a new interface just for NoteHead (e.g., ligature-head-interface). Cheers, Neil http://codereview.appspot.com/4667055/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Release candidate for 2.14.2
On Mon, Jul 04, 2011 at 01:57:54PM -0600, Carl Sorensen wrote: I plan to ask Graham to release a new version on Saturday, July 9. May or may not happen. That's the last day of the conference; I'll probably be in the Venice airport for 2-3 hours, and then London Heathrow terminal 5 for 14 hours. Some airports give free wifi, so I might be able to ssh to my desktop and make the release, but other airports don't. I'm back in Vancouver on the afternoon of the 10th, but I'll probably sleep for 12 hours straight, so don't expect a release until the 11th. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds a warning for non-list fingeringOrientations settings. (issue4650070)
On 2011/07/04 13:14:55, Neil Puttock wrote: Context_def::add_context_mod () is where the assignment takes place (and you can see from set_property () how the type-checking is done). Where is set_property defined? cheers, Janek http://codereview.appspot.com/4650070/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: an example of minimal example (issue4636082)
On 2011/07/04 20:02:59, Carl wrote: I like this, but I think it should have a little bit more information. I don't think that the changes in the comments affect whether it is minimal or not -- perhaps the comments should be the same in both cases. Imo it's more readable when the comment is briefer. Also the way in wchich it divides the music is distracting for me. thanks, Janek http://codereview.appspot.com/4636082/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds a warning for non-list fingeringOrientations settings. (issue4650070)
On 4 July 2011 21:33, lemniskata.bernoull...@gmail.com wrote: Where is set_property defined? lily/include/lily-guile-macros.hh The actual type-checking occurs in Context::internal_set_property (). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)
On 2011/07/04 09:28:26, janneke_gnu.org wrote:
The GNU standards are implemented by Emacs,
Well, it looks like the problems with fixcc.py were caused by regexps,
not emacs.
Also, I tried to make the output of the modified fixcc+asytle pass
unchanged through emacs, but the very many cases of line-broken
asssignments will be different.
long_variable_name = first_term
+ second_term; // emacs
long_variable_name = first_term
+ second_term; // astyle
Emacs users will forget to run fixcc (because they are lazy heathens, as
all vi users know :-) causing distracting whitespace changes in the
diffs.
So *if* we can add back regexps to fixcc.py that do what neither emacs
nor programmers do automatically:
pad parentheses me-origin ();
unpad parenthesis-groups if ((a mask) == (d mask))
pad operators array[i + 1]
without breaking other things, then we could go back to call emacs for
the indenting.
Then hopefully the script would commute with emacs
fixcc.py (code) == emacs ( fixcc.py (code))
Patches welcome.
But until that is done, my proposal remains this shorter
prefilter+astyle.
http://codereview.appspot.com/4662074/diff/4031/scripts/auxiliar/fixcc.py
File scripts/auxiliar/fixcc.py (left):
http://codereview.appspot.com/4662074/diff/4031/scripts/auxiliar/fixcc.py#oldcode148
scripts/auxiliar/fixcc.py:148:
('((if|while)\s+\(([^\)]|\([^\)]*\))*\))\s*;', '\\1\n;'),
This is what was line-breaking the semicolon on an unbraced do-while!
do
something;
while (relevant)
;
So I was wrong to blame emacs for this one when I said
You'll notice that some of the gnu coding standards
you linked to, like braces on do-while, are
specifically designed to defend against emacs's
http://codereview.appspot.com/4662074/diff/4031/scripts/auxiliar/fixcc.py
File scripts/auxiliar/fixcc.py (right):
http://codereview.appspot.com/4662074/diff/4031/scripts/auxiliar/fixcc.py#newcode64
scripts/auxiliar/fixcc.py:64: # trailing operator, but don't un-trail
assignment operators or close angle-braces
Looking through the existing code, line-broken assignments /do/ get the
'=' on the second line
long_name
= long_initializer;
so I could restore that.
http://codereview.appspot.com/4662074/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)
On Mon, Jul 04, 2011 at 09:58:14PM +0200, Jan Nieuwenhuizen wrote: Carl Sorensen writes: I've tried Emacs, and I can't see the benefits justifying fighting through the learning curve. It's not comfortable for me; I have 30+ years of experience with vi(m), so it's hardwired in my bones. Something went wrong here; it's awesome if we can manage not to depend on Emacs anymore. Ok, so you do not object us adopting fixcc-with-astyle as the official formatter for C++ code? I'll modify the actual GOP-PROP and move it to the (probable decision) 7-day countdown. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Release candidate for 2.14.2
On 7/4/11 2:30 PM, Graham Percival gra...@percival-music.ca wrote: On Mon, Jul 04, 2011 at 01:57:54PM -0600, Carl Sorensen wrote: I plan to ask Graham to release a new version on Saturday, July 9. May or may not happen. That's the last day of the conference; I'll probably be in the Venice airport for 2-3 hours, and then London Heathrow terminal 5 for 14 hours. Some airports give free wifi, so I might be able to ssh to my desktop and make the release, but other airports don't. I'm back in Vancouver on the afternoon of the 10th, but I'll probably sleep for 12 hours straight, so don't expect a release until the 11th. Venice -- that's a nice place. Heathrow, not so much Whenever you can get to it is fine. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)
On 2011/07/04 20:30:10, Neil Puttock wrote: On 2011/07/04 01:54:40, Carl wrote: Instead of filtering out bad events, I chose to filter in only events with ligature interfaces. That's a lot of internal_has_interface () calls. :) I wondered about that. But I think the first one that is true will stop the evaluation, so at the present only one would be called. The original way you suggested was to have two internal_has_interface () calls; this one only adds one. You might as well create a new interface just for NoteHead (e.g., ligature-head-interface). We already have the unused ligature-interface. What if I just added ligature-interface to NoteHead? Thanks, Carl http://codereview.appspot.com/4667055/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Separate flags into their own sub-font. (issue4654084)
I've almost forgotten: i checked that Carl's patch set passes regtests. http://codereview.appspot.com/4654084/diff/42/mf/feta-scripts.mf File mf/feta-scripts.mf (right): http://codereview.appspot.com/4654084/diff/42/mf/feta-scripts.mf#newcode1450 mf/feta-scripts.mf:1450: begingroup; On 2011/07/04 20:48:45, Carl wrote: On 2011/07/04 20:19:31, Janek Warchol wrote: You added this because every glyph should be in some group now? No, the begingroup and endgroup define the scope over which the save functions. and the height, overshoot, and width that are used in this glyph should be limited to this glyph. Ah, ok. http://codereview.appspot.com/4654084/diff/42/mf/feta-scripts.mf#newcode1452 mf/feta-scripts.mf:1452: height# := staff_space#; On 2011/07/04 20:48:45, Carl wrote: On 2011/07/04 20:19:31, Janek Warchol wrote: are the colons only a matter of style? No. The colon makes it an assignment. Without the colon, it's an equation that becomes a constraint; eventually the equation is solved. The intention here, AFAICS, is to have it be an assignment, so I made it explicit. Yes, i'd say that too. http://codereview.appspot.com/4654084/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: an example of minimal example (issue4636082)
New patch set uploaded.
2011/7/4 percival.music...@gmail.com:
I'm glad that you're working on it! I'm just warning you that there
will be many nitpicks.
No problem. If they aren't about code style, i can handle them :)
http://codereview.appspot.com/4636082/diff/3/Documentation/web/community.itexi
File Documentation/web/community.itexi (right):
http://codereview.appspot.com/4636082/diff/3/Documentation/web/community.itexi#newcode275
Documentation/web/community.itexi:275: Is the code below a minimal
example?
On 2011/07/04 20:24:56, Graham Percival wrote:
This is way too long. I spent a lot of time and effort making the
website as
minimal as possible to increase readability
I had this feeling too.
Hmm... I'd be ok with it if you put it in a box at the bottom of the
page. I
actually can't believe that we don't have any examples on the Tiny
examples page
-- the only place to find something is on the Bug reports page!
Done (at least i hope that it's written correctly).
http://codereview.appspot.com/4636082/diff/3/Documentation/web/community.itexi#newcode277
Documentation/web/community.itexi:277: @lilypond
On 2011/07/04 20:24:56, Graham Percival wrote:
this won't compile; it would have to be @example instead, and that
will require
@{ @} escapes.
Umm.. is it right now?
http://codereview.appspot.com/4636082/diff/3/Documentation/web/community.itexi#newcode346
Documentation/web/community.itexi:346: using less than a single measure.
On 2011/07/04 20:24:56, Graham Percival wrote:
I prefer only. If somebody gets it down to 1 measure, we're not
going to
quibble about 2 beats vs. 4 beats.
Umm, James' original example was exactly one measure, and we condemned
it as being too long.
2011/7/4 James Harkins jamshar...@gmail.com wrote:
To me, one bar is tiny.
And after all, this wording doesn't force people to make examples less
then one measure at all costs. It only suggests things.
http://codereview.appspot.com/4636082/diff/3/Documentation/web/community.itexi#newcode353
Documentation/web/community.itexi:353: 2 lines of code, and few exceed
10 lines.
On 2011/07/04 20:24:56, Graham Percival wrote:
Hmm. I'm worried that this (combined with the next item) would make
the page
too wordy. Leave it in there for the next draft, but I may complain
about it
later.
I moved it to the bottom box, how do you like it?
http://codereview.appspot.com/4636082/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
tuplet number on cross-staff kneed-beam
Hello, all --
First of all, I hope that I'm asking this question on the appropriate list!
I'm trying to simplify the workaround relating to tuplet-number
position on kneed beams
http://lsr.dsi.unimi.it/LSR/Snippet?id=646
and I'm running into an unexpected problem.
My reasoning is that, since the tuplet number is positioned according
to the bracket, a logical first (certainly hacky!) step is to move the
(invisible) bracket to the beam by setting the 'positions property of
the bracket to that of the beam. Then, the position of the number
could be refined according to its height, the thickness of the beam,
etc.
This works as planned, except that in 2.14.1, the staves are pushed
apart dramatically. \override Beam #'collision-voice-only has no
effect on the problem. Manually setting Beam #'positions can be used
to fix the problem, but that is obviously inconvenient.
I've attached an .ly file with the function (stripped down to fit just
this case), and several images of the output (one is produced with
2.12.3, the other two with 2.14.1 -- one with an override of the Beam
#'positions). There doesn't appear to be any problem in 2.12.3.
Is there anything I can do to fix this problem with the function? Any
help would be greatly appreciated!
Thanks,
David
attachment: function-current-stable.pngattachment: function-current-stable-positions-override.pngattachment: function-previous-stable.png\version 2.14.1
#(define (tuplet-number-to-beam tuplet-number)
(let* ((tuplet-bracket (ly:grob-object tuplet-number 'bracket))
(note-column (ly:grob-parent tuplet-number X))
(stem (ly:grob-object note-column 'stem))
(beam (ly:grob-object stem 'beam)))
;; Move (invisible) TupletBracket to beam, taking number with it
(ly:grob-set-property! tuplet-bracket 'positions (ly:grob-property beam 'positions))
;; Number is now centered on beam. Offset it based on width of beam and height
;; of tuplet number.
(ly:grob-set-property! tuplet-number 'Y-offset
(-
(+
(ly:grob-property beam 'beam-thickness)
(/ (interval-length (ly:grob::stencil-height tuplet-number)) 2))
\new PianoStaff
\new Staff = 1 {
s4
}
\new Staff = 2 {
\relative c {
\clef bass
%% following line has no effect
\override Beam #'collision-voice-only = ##t
%% following line improves situation
%\override Beam #'positions = #'(5 . 5)
\override TupletNumber #'after-line-breaking = #tuplet-number-to-beam
\times 2/3 {
c8
\change Staff = 1
c''
\change Staff = 2
c,,
}
}
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)
On 4 July 2011 21:57, carl.d.soren...@gmail.com wrote: The original way you suggested was to have two internal_has_interface () calls; this one only adds one. But for the invalid heads, all three calls would be made (and of course, for a NoteHead itself only the first interface check will ever happen, so the other calls are redundant). We already have the unused ligature-interface. What if I just added ligature-interface to NoteHead? Sounds fine to me. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: an example of minimal example (issue4636082)
On 2011/07/04 21:01:44, Janek Warchol wrote:
2011/7/4 percival.music...@gmail.com:
this won't compile; it would have to be @example instead, and that
will
require
@{ @} escapes.
Umm.. is it right now?
why the mao are you asking me? Cutpaste this and tell me yourself:
cd build/
make website
It either compiles, or it doesn't.
Umm, James' original example was exactly one measure, and we condemned
it as
being too long.
It was too long in terms of lines of text, not in terms of duration. Or
to put it another way: it was too complicated. It had scary stuff like
\useNumericTimeSignature.
Cheers,
- Graham
http://codereview.appspot.com/4636082/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
GOP-PROP 3 - C++ formatting (probable decision)
http://lilypond.org/~graham/gop/gop_3.html ** Proposal summary Speaking academically, C++ code style is a solved problem. Let’s pick one of the existing solutions, and let a computer deal with this. Humans should not waste their time, energy, and creativity manually adding tabs or spaces to source code. I propose that we use a modified fixcc.py using astyle internally. * the final script will be run blindly on the lilypond source code. We will accept whatever formatting the final version of this script produces, with no manual tweaking. * patches which have been run through this tool will not be rejected for style reasons. Any code formatting “desires” which are not enforced by fixcc.py will not be considered grounds for rejecting a patch. * after the proposal is accepted, we will leave over two weeks for existing patches to be accepted. The script will be run on the source code on 2011 August 01. We will take the fixcc+astyle from here: http://codereview.appspot.com/4662074/ (just the fixcc.py and maybe some test files; we will not make any changes to .cc or .hh files until 2011 August 01) ** Rationale New contributors sometimes struggle to follow our indentation and code style – this is especially difficult when parts of our existing source code doesn’t have a consistent style. This is problematic... we want new contributors to be struggling with the lilypond architecture, not playing games in their text editors! we’ve lost time, energy, and contributors because of this. Two bad examples: (the second one hopefully hasn’t lost us a contributor – but her patch was delayed by three weeks because of indentation issues, and that can’t be very encouraging) http://codereview.appspot.com/1724041/ http://codereview.appspot.com/4490045/ This is also the worst “administrative” time-wasters in recent LilyPond history; we’ve had numerous discussions without actually resolving anything. Previous discussions on tabs v. spaces include the following: http://thread.gmane.org/gmane.comp.gnu.lilypond.devel/22691 http://lists.gnu.org/archive/html/lilypond-devel/2009-04/msg00076.html ** Eliminate tabs I’m going to make the bold step of assuming that we will eliminate tabs in all C++ files. I personally like the idea of tabs, but from an examination of source code styles (both official and unofficial) in various projects, I must admit that this ship has sailed. Too many programs/editors don’t support tabs. Too many people find them confusing. Too many cutpaste jobs from html results in spaces instead of tabs. http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Spaces_vs._Tabs http://www.rosegardenmusic.com/wiki/dev:coding_style http://techbase.kde.org/Policies/Kdelibs_Coding_Style ** Implementation notes Some amount of mess is unavoidable, but I believe it can be mitigated. lilydev needs to have whatever tool we end up choosing. Patches will break, unless somebody applies the patch to the un-indented source code, then run the indentation tool, then make a new patch, etc. Massive confusion. Hopefully we can get most of the existing patches merged before 2011 Aug 01. It’s not the end of the world if we need to give manual attention to a few patches right after the change-over, though. Future: we may want to consider adding a git hook to call whatever indentation script before any commit. This will not be implented as part of this proposal, though. We can avoid some of this pollution in git history by ignoring whitespaces changes: git diff -w Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes multiple line glissandos the right way. (issue4631086)
LGTM apart from some indentation infelicities (space before tab in indent). http://codereview.appspot.com/4631086/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: an example of minimal example (issue4636082)
2011/7/4 percival.music...@gmail.com: On 2011/07/04 21:01:44, Janek Warchol wrote: Umm.. is it right now? why the mao are you asking me? Cutpaste this and tell me yourself: cd build/ make website It either compiles, or it doesn't. Ooops, sorry... I didn't know that it's possible to compile website separately from all other documentation (which takes a lot of time, according to CG, and i've never done it). I did this, and it compiled. However, when i opened build/out-website/index.html, a black-and white text only page apperared. Does it mean i should do things described in CG 6.3? Umm, James' original example was exactly one measure, and we condemned it as being too long. It was too long in terms of lines of text, not in terms of duration. Or to put it another way: it was too complicated. It had scary stuff like \useNumericTimeSignature. ok, i admit this was more non-tinish than the additional notes alone. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix issue 75: Allow multiple concurrent slurs (issue4643067)
On 2011/07/04 12:17:46, Reinhold wrote: On 2011/07/04 00:18:07, J_lowe wrote: Hello, I get an error when I try to make: That's fixed now. Make succeeds, and reg tests look ok, but there is one note in one of the .ly files that the reg test threw up that may or may not be significant. --snip-- 2.449490 mozart-hrn-3.log @@ -1,6 +1,10 @@ Parsing... Renaming input to: `mozart-hrn-3.ly' -Interpreting music... [8][16][24][32][40][48][56][64][72][80][88][96][104][112][120] +Interpreting music... [8][16][24][32][40][48][56][64][72][80][88] +../../input/regression/mozart-hrn3-allegro.ily:129:17: warning: Already have slur + \longgrace d16 + ( \endlonggrace +[96][104][112][120] Preprocessing graphical objects... Interpreting music... Interpreting music... --snip-- James http://codereview.appspot.com/4643067/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)
On 2011/07/04 21:22:58, Neil Puttock wrote: On 4 July 2011 21:57, mailto:carl.d.soren...@gmail.com wrote: We already have the unused ligature-interface. nbsp;What if I just added ligature-interface to NoteHead? Sounds fine to me. OK, so I've added ligature-interface to NoteHead, and everything seems to work now. Thanks, Carl http://codereview.appspot.com/4667055/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix issue 75: Allow multiple concurrent slurs (issue4643067)
On Di., 5. Jul. 2011 00:30:52 CEST, pkx1...@gmail.com wrote:
On 2011/07/04 12:17:46, Reinhold wrote:
On 2011/07/04 00:18:07, J_lowe wrote:
Hello, I get an error when I try to make:
That's fixed now.
Make succeeds, and reg tests look ok, but there is one note in one of
the .ly files that the reg test threw up that may or may not be
significant.
+../../input/regression/mozart-hrn3-allegro.ily:129:17: warning: Already
have slur
+ \longgrace d16
+ ( \endlonggrace
That warning is okay (it was a bug that the warning wasn't shown so far), it
really uses two nested slurs (one normal and another one for the grace)
However, that whole code is really strange:
d2( ~ d8[ e16 d] \grace {
\override Stem #'stroke-style = #grace
\longgrace d16( \endlonggrace
\revert Stem #'stroke-style }
%% todo: should insert grace slur here.
c8[ b16 c)]
where
longgrace = \override Stem #'stroke-style = #'()
endlonggrace = \revert Stem #'stroke-style
So, the first override and revert dosn't have any effect... I suppose those
grace notes should really use appoggiatura / acciaccatura. AFAICS, that file is
from mutopia an almost 10 years old, so it was never properly updated to new
syntax.
Cheers,
Reinhold
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Release candidate for 2.14.2
2011/7/4 Carl Sorensen c_soren...@byu.edu: As far as I can see, all bugfixes from the 2.15 branch are now backported to stable/2.14 I plan to ask Graham to release a new version on Saturday, July 9. There have been only minor documentation changes since 2.14.1, IIUC, but I would invite the translators to check to see if there is any work needed to be done before 2.14.2 comes out. I know there is one pending patch that I expect to see in a few hours. Here is mine. I have pushed it in lilypond/translation branch. Please backport. commit 993a1318a345e27f5a299e738b4163d6bcc3 Author: Francisco Vila francisco.v...@hispalinux.es Date: Tue Jul 5 03:00:11 2011 +0200 Doc-es: update Input -- Stable. Unfortunately I can not currently build the docs because make fails at the configure stage. It happens that now I need /usr/bin/fontforge = 20100501 (installed: 20090923). Several dependencies prevent en easy update of that package in my Ubuntu system. In addition, I see Dénes has pushed two Doc-hu commits in lilypond/translation branch minutes ago. I can not say whether they are intended to be backported to stable. These are commit 9780d79af0855706354029509cbb11464a63d901 Author: Dénes Harmath harmathde...@gmail.com Date: Tue Jul 5 02:50:33 2011 +0200 Doc-hu: Fixed typo commit 71cea6af77bf3d639dcfd8ad09fd235aab22c5f7 Author: Dénes Harmath harmathde...@gmail.com Date: Tue Jul 5 02:49:08 2011 +0200 Doc-hu: trying to build PDF A bunch of other minor, trivial edits are needed in Doc-es for the statistics to be wholly right; I will not do them. I think I'm going to forget Stable for now and concentrate on updating Master. Thanks! -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Release candidate for 2.14.2
9780d79af0855706354029509cbb11464a63d901 is intended to be backported to stable, 71cea6af77bf3d639dcfd8ad09fd235aab22c5f7 is not. On 2011.07.05., at 3:23, Francisco Vila wrote: 2011/7/4 Carl Sorensen c_soren...@byu.edu: As far as I can see, all bugfixes from the 2.15 branch are now backported to stable/2.14 I plan to ask Graham to release a new version on Saturday, July 9. There have been only minor documentation changes since 2.14.1, IIUC, but I would invite the translators to check to see if there is any work needed to be done before 2.14.2 comes out. I know there is one pending patch that I expect to see in a few hours. Here is mine. I have pushed it in lilypond/translation branch. Please backport. commit 993a1318a345e27f5a299e738b4163d6bcc3 Author: Francisco Vila francisco.v...@hispalinux.es Date: Tue Jul 5 03:00:11 2011 +0200 Doc-es: update Input -- Stable. Unfortunately I can not currently build the docs because make fails at the configure stage. It happens that now I need /usr/bin/fontforge = 20100501 (installed: 20090923). Several dependencies prevent en easy update of that package in my Ubuntu system. In addition, I see Dénes has pushed two Doc-hu commits in lilypond/translation branch minutes ago. I can not say whether they are intended to be backported to stable. These are commit 9780d79af0855706354029509cbb11464a63d901 Author: Dénes Harmath harmathde...@gmail.com Date: Tue Jul 5 02:50:33 2011 +0200 Doc-hu: Fixed typo commit 71cea6af77bf3d639dcfd8ad09fd235aab22c5f7 Author: Dénes Harmath harmathde...@gmail.com Date: Tue Jul 5 02:49:08 2011 +0200 Doc-hu: trying to build PDF A bunch of other minor, trivial edits are needed in Doc-es for the statistics to be wholly right; I will not do them. I think I'm going to forget Stable for now and concentrate on updating Master. Thanks! -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Release candidate for 2.14.2
On 7/4/11 7:23 PM, Francisco Vila paconet@gmail.com wrote: 2011/7/4 Carl Sorensen c_soren...@byu.edu: As far as I can see, all bugfixes from the 2.15 branch are now backported to stable/2.14 I plan to ask Graham to release a new version on Saturday, July 9. There have been only minor documentation changes since 2.14.1, IIUC, but I would invite the translators to check to see if there is any work needed to be done before 2.14.2 comes out. I know there is one pending patch that I expect to see in a few hours. Here is mine. I have pushed it in lilypond/translation branch. Please backport. commit 993a1318a345e27f5a299e738b4163d6bcc3 Author: Francisco Vila francisco.v...@hispalinux.es Date: Tue Jul 5 03:00:11 2011 +0200 Backported. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Release candidate for 2.14.2
On 7/4/11 7:26 PM, Harmath Dénes harmathde...@gmail.com wrote: 9780d79af0855706354029509cbb11464a63d901 is intended to be backported to stable, 71cea6af77bf3d639dcfd8ad09fd235aab22c5f7 is not. backported Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add display method for \tweak (fixes issue 1733) (issue4645077)
LGTM Carl http://codereview.appspot.com/4645077/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes multiple line glissandos the right way. (issue4631086)
LGTM Carl http://codereview.appspot.com/4631086/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds glissando stems to Lilypond. (issue4661061)
Looking at the details of the code, it seems fine. But I tend to agree with Han-Wen's concerns. I'm wondering if it's possible to avoid code dup by making a base_stem_engraver of which glissando_stem_engraver and stem_engraver would be children. I probably don't have the right terminology for this (in fact I'm sure I don't), but I'm thinking of what happens with ligature_engraver and mensural_ligature_engraver. Feel free to ignore this message if it's not helpful. I haven't tried it and don't have a concrete suggestion. Thanks, Carl http://codereview.appspot.com/4661061/diff/12004/lily/stem.cc File lily/stem.cc (right): http://codereview.appspot.com/4661061/diff/12004/lily/stem.cc#newcode1093 lily/stem.cc:1093: programming_error (Glissandi stem must have two and only two noteheads.); I'd probably prefer to have this stated Glissando stem does not have exactly two noteheads, because then it's a description of the error, instead of a description of the desired behavior. http://codereview.appspot.com/4661061/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New breve rest with ledger lines (issue4650052)
LGTM Carl http://codereview.appspot.com/4650052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Flag functions instead of defining glyphs directly (issue4625067)
lgtm I can see how this will work well for defining a whole set. Carl http://codereview.appspot.com/4625067/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Small pitch bends correct and tested. (issue4654063)
LGTM, with Neil's comments taken Carl http://codereview.appspot.com/4654063/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)
Also, I tried to make the output of the modified fixcc+asytle pass unchanged through emacs, but the very many cases of line-broken asssignments will be different. That's a problem. long_variable_name = first_term + second_term; // emacs This is correct. Emacs users will forget to run fixcc That won't do, sorry. Let's make it as easy as possible for non-Emacs users; but choosing a coding style that Emacs does not support is a no-go. We can still opt for using the current astyle solution, just as long as we see that this approach is a huge step forward and recognise that astyle still needs some fixes (and request these on the astyle development list). Greetings, Jan. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix issues 1259 and 1433 (\breakDynamicSpan and a spanner's style=#'none over a line break) (issue4630070)
LGTM, but I haven't explored the strange behavior you've identified. Carl http://codereview.appspot.com/4630070/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)
Graham Percival writes: Ok, so you do not object us adopting fixcc-with-astyle as the official formatter for C++ code? It seems that this is a huge step forward; just don't change the definition to `whatever astyle can currently handle'; rather than: fixcc is okay and we're working with the astyle developers on some fixes. Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix issue 75: Allow multiple concurrent slurs (issue4643067)
LGTM, with one comment. I do wonder if David is right, and we should be using spanner_id instead of slur_id. Carl http://codereview.appspot.com/4643067/diff/3001/lily/slur-engraver.cc File lily/slur-engraver.cc (right): http://codereview.appspot.com/4643067/diff/3001/lily/slur-engraver.cc#newcode201 lily/slur-engraver.cc:201: ev-origin ()-warning(_ (Already have slur)); Should this be already have slur? http://codereview.appspot.com/4643067/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
