Patchy email
04:35:09 (UTC) Begin LilyPond compile, previous commit at 1c980a9906a7ea01b9f99487e75580f7232f2491 04:35:11 Merged staging, now at:1c980a9906a7ea01b9f99487e75580f7232f2491 04:35:13Success:./autogen.sh --noconfigure 04:35:38Success:../configure --disable-optimising 04:35:58Success:nice make clean 04:42:46Success:nice make -j2 CPU_COUNT=2 "WEB_TARGETS=online offline" 05:02:14Success:nice make test -j2 CPU_COUNT=2 "WEB_TARGETS=online offline" 07:00:18 *** FAILED BUILD *** nice make doc -j2 CPU_COUNT=2 "WEB_TARGETS=online offline" Previous good commit: Current broken commit: 1c980a9906a7ea01b9f99487e75580f7232f2491 07:00:18 *** FAILED STEP *** merge from staging Failed runner: nice make doc -j2 CPU_COUNT=2 "WEB_TARGETS=online offline" See the log file log-staging-nice-make-doc--j2-CPU_COUNT=2-"WEB_TARGETS=online-offline".txt ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Set indent based on instrument name (issue 6457049)
On Mon, Jul 30, 2012 at 11:44:28PM +0100, Bernard Hurley wrote: > On Mon, Jul 30, 2012 at 10:14:37PM +0100, Phil Holmes wrote: > > - Original Message - From: > >> lily/output-def.cc:38: Real long_name_len = 0.0; > >> could these be class member variables instead of global variables? > > > > I don't believe so. I'd be happy to be corrected by someone who > > understands this better than I do, but my understanding of c++ (which I > > guess at based on c#) says that, in order to access a class member > > variable, you need to have an instantiation of the class. That is true. > In C++ variables can be declared static. If this is done all instances of > the class share the same instance of the variable and it can exist > even if the class has no instances see: Yes, that's also true. Let me rephrase my concern: in C++-land, having a global variable (including static variables) are viewed upon like picking one's nose. If there is absolutely no other way to achieve one's goal, it could be tolerated. But I would be very surprised if this could not be implemented without global variables, so I think another draft of the patch will be necessary. Hopefully somebody familiar with lilypond internals can skim the patch (it's quite small) and give a suggestion as to how to avoid the global variables. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Set indent based on instrument name (issue 6457049)
On Mon, Jul 30, 2012 at 10:14:37PM +0100, Phil Holmes wrote: > - Original Message - From: >> lily/output-def.cc:38: Real long_name_len = 0.0; >> could these be class member variables instead of global variables? > > I don't believe so. I'd be happy to be corrected by someone who > understands this better than I do, but my understanding of c++ (which I > guess at based on c#) says that, in order to access a class member > variable, you need to have an instantiation of the class. In C++ variables can be declared static. If this is done all instances of the class share the same instance of the variable and it can exist even if the class has no instances see: http://www.learncpp.com/cpp-tutorial/811-static-member-variables/ Bernard ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Patchy email
22:17:41 (UTC) Begin LilyPond compile, previous commit at 1c980a9906a7ea01b9f99487e75580f7232f2491 22:17:44 Merged staging, now at:1c980a9906a7ea01b9f99487e75580f7232f2491 22:17:46Success:./autogen.sh --noconfigure 22:18:21Success:../configure --disable-optimising 22:18:22 *** FAILED BUILD *** nice make clean -j2 CPU_COUNT=2 WEB_TARGETS="online offline" Previous good commit: Current broken commit: 1c980a9906a7ea01b9f99487e75580f7232f2491 22:18:22 *** FAILED STEP *** merge from staging Failed runner: nice make clean -j2 CPU_COUNT=2 WEB_TARGETS="online offline" See the log file log-staging-nice-make-clean--j2-CPU_COUNT=2-WEB_TARGETS="online-offline".txt 22:22:13 (UTC) Begin LilyPond compile, previous commit at 1c980a9906a7ea01b9f99487e75580f7232f2491 22:22:16 Merged staging, now at:1c980a9906a7ea01b9f99487e75580f7232f2491 22:22:18Success:./autogen.sh --noconfigure 22:22:43Success:../configure --disable-optimising 22:22:43 *** FAILED BUILD *** nice make clean -j2 CPU_COUNT=2 WEB_TARGETS=online\ offline Previous good commit: Current broken commit: 1c980a9906a7ea01b9f99487e75580f7232f2491 22:22:43 *** FAILED STEP *** merge from staging Failed runner: nice make clean -j2 CPU_COUNT=2 WEB_TARGETS=online\ offline See the log file log-staging-nice-make-clean--j2-CPU_COUNT=2-WEB_TARGETS=online\-offline.txt 22:32:48 (UTC) Begin LilyPond compile, previous commit at 1c980a9906a7ea01b9f99487e75580f7232f2491 22:32:50 Merged staging, now at:1c980a9906a7ea01b9f99487e75580f7232f2491 22:32:52Success:./autogen.sh --noconfigure 22:33:17Success:../configure --disable-optimising 22:33:37Success:nice make clean -j2 CPU_COUNT=2 "WEB_TARGETS=online offline" 22:35:09 (UTC) Begin LilyPond compile, previous commit at 1c980a9906a7ea01b9f99487e75580f7232f2491 22:35:10 *** FAILED STEP *** merge from staging Command 'git branch test-master-lock origin/master' returned non-zero exit status 128 fatal: A branch named 'test-master-lock' already exists. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Patchy email
22:17:41 (UTC) Begin LilyPond compile, previous commit at 1c980a9906a7ea01b9f99487e75580f7232f2491 22:17:44 Merged staging, now at:1c980a9906a7ea01b9f99487e75580f7232f2491 22:17:46Success:./autogen.sh --noconfigure 22:18:21Success:../configure --disable-optimising 22:18:22 *** FAILED BUILD *** nice make clean -j2 CPU_COUNT=2 WEB_TARGETS="online offline" Previous good commit: Current broken commit: 1c980a9906a7ea01b9f99487e75580f7232f2491 22:18:22 *** FAILED STEP *** merge from staging Failed runner: nice make clean -j2 CPU_COUNT=2 WEB_TARGETS="online offline" See the log file log-staging-nice-make-clean--j2-CPU_COUNT=2-WEB_TARGETS="online-offline".txt 22:22:13 (UTC) Begin LilyPond compile, previous commit at 1c980a9906a7ea01b9f99487e75580f7232f2491 22:22:16 Merged staging, now at:1c980a9906a7ea01b9f99487e75580f7232f2491 22:22:18Success:./autogen.sh --noconfigure 22:22:43Success:../configure --disable-optimising 22:22:43 *** FAILED BUILD *** nice make clean -j2 CPU_COUNT=2 WEB_TARGETS=online\ offline Previous good commit: Current broken commit: 1c980a9906a7ea01b9f99487e75580f7232f2491 22:22:43 *** FAILED STEP *** merge from staging Failed runner: nice make clean -j2 CPU_COUNT=2 WEB_TARGETS=online\ offline See the log file log-staging-nice-make-clean--j2-CPU_COUNT=2-WEB_TARGETS=online\-offline.txt 22:32:48 (UTC) Begin LilyPond compile, previous commit at 1c980a9906a7ea01b9f99487e75580f7232f2491 22:32:50 Merged staging, now at:1c980a9906a7ea01b9f99487e75580f7232f2491 22:32:52Success:./autogen.sh --noconfigure 22:33:17Success:../configure --disable-optimising 22:33:37Success:nice make clean -j2 CPU_COUNT=2 "WEB_TARGETS=online offline" 22:35:09 (UTC) Begin LilyPond compile, previous commit at 1c980a9906a7ea01b9f99487e75580f7232f2491 22:35:10 *** FAILED STEP *** merge from staging Command 'git branch test-master-lock origin/master' returned non-zero exit status 128 fatal: A branch named 'test-master-lock' already exists. 22:35:13 *** FAILED BUILD *** nice make -j2 CPU_COUNT=2 "WEB_TARGETS=online offline" Previous good commit: Current broken commit: 1c980a9906a7ea01b9f99487e75580f7232f2491 22:35:13 *** FAILED STEP *** merge from staging Failed runner: nice make -j2 CPU_COUNT=2 "WEB_TARGETS=online offline" See the log file log-staging-nice-make--j2-CPU_COUNT=2-"WEB_TARGETS=online-offline".txt ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Patchy email
22:17:41 (UTC) Begin LilyPond compile, previous commit at 1c980a9906a7ea01b9f99487e75580f7232f2491 22:17:44 Merged staging, now at:1c980a9906a7ea01b9f99487e75580f7232f2491 22:17:46Success:./autogen.sh --noconfigure 22:18:21Success:../configure --disable-optimising 22:18:22 *** FAILED BUILD *** nice make clean -j2 CPU_COUNT=2 WEB_TARGETS="online offline" Previous good commit: Current broken commit: 1c980a9906a7ea01b9f99487e75580f7232f2491 22:18:22 *** FAILED STEP *** merge from staging Failed runner: nice make clean -j2 CPU_COUNT=2 WEB_TARGETS="online offline" See the log file log-staging-nice-make-clean--j2-CPU_COUNT=2-WEB_TARGETS="online-offline".txt 22:22:13 (UTC) Begin LilyPond compile, previous commit at 1c980a9906a7ea01b9f99487e75580f7232f2491 22:22:16 Merged staging, now at:1c980a9906a7ea01b9f99487e75580f7232f2491 22:22:18Success:./autogen.sh --noconfigure 22:22:43Success:../configure --disable-optimising 22:22:43 *** FAILED BUILD *** nice make clean -j2 CPU_COUNT=2 WEB_TARGETS=online\ offline Previous good commit: Current broken commit: 1c980a9906a7ea01b9f99487e75580f7232f2491 22:22:43 *** FAILED STEP *** merge from staging Failed runner: nice make clean -j2 CPU_COUNT=2 WEB_TARGETS=online\ offline See the log file log-staging-nice-make-clean--j2-CPU_COUNT=2-WEB_TARGETS=online\-offline.txt ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Patchy email
22:17:41 (UTC) Begin LilyPond compile, previous commit at 1c980a9906a7ea01b9f99487e75580f7232f2491 22:17:44 Merged staging, now at:1c980a9906a7ea01b9f99487e75580f7232f2491 22:17:46Success:./autogen.sh --noconfigure 22:18:21Success:../configure --disable-optimising 22:18:22 *** FAILED BUILD *** nice make clean -j2 CPU_COUNT=2 WEB_TARGETS="online offline" Previous good commit: Current broken commit: 1c980a9906a7ea01b9f99487e75580f7232f2491 22:18:22 *** FAILED STEP *** merge from staging Failed runner: nice make clean -j2 CPU_COUNT=2 WEB_TARGETS="online offline" See the log file log-staging-nice-make-clean--j2-CPU_COUNT=2-WEB_TARGETS="online-offline".txt ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Set indent based on instrument name (issue 6457049)
- Original Message - From: To: ; ; Cc: ; Sent: Monday, July 30, 2012 6:54 PM Subject: Re: Set indent based on instrument name (issue 6457049) Little nitpicks based on my C++ experience in other projects, with no knowledge whatsoever of lilypond internals. http://codereview.appspot.com/6457049/diff/4001/lily/instrument-name-engraver.cc File lily/instrument-name-engraver.cc (right): http://codereview.appspot.com/6457049/diff/4001/lily/instrument-name-engraver.cc#newcode111 lily/instrument-name-engraver.cc:111: Instrument_name_engraver::Get_text_len_from_name (SCM scheme_text) convention is to use lower-case names for class functions (or methods if you prefer) http://codereview.appspot.com/6457049/diff/4001/lily/output-def.cc File lily/output-def.cc (right): http://codereview.appspot.com/6457049/diff/4001/lily/output-def.cc#newcode38 lily/output-def.cc:38: Real long_name_len = 0.0; could these be class member variables instead of global variables? I don't believe so. I'd be happy to be corrected by someone who understands this better than I do, but my understanding of c++ (which I guess at based on c#) says that, in order to access a class member variable, you need to have an instantiation of the class. The problem we have is that the knowledge of the instrument name strings is in a different class (Instrument_name_engraver). We need to persist the value of the longest instrument name, and pass it to output-def, where the indents are set. If we instantiated an output-def class in Instrument_name_engraver, we would lose the instantiation when Instrument_name_engraver dies, so the values would not be persisted. Hence why I ended up with global variables. The one thing I thought about on the way home tonight is that these need to be zeroed when we create a new Score, so I need to find out/be told how to do that. ... hmm, more generally, I'm not sold on the whole set_inst_name_len approach. Is there any way you could just pass an additional argument to line_dimenstions_int , and determine the data you need from that function? http://codereview.appspot.com/6457049/ Not AFAICS. It currently requires 2 arguments: Output_def *def, int n, and there's no way we can satisfy them from Instrument_name_engraver. I think adding an extra function to access the global variables is an effective encapsulation of the variable, and works for me. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: added missing #inlude for use with g++ 4.7 (issue 6434048)
LGTM - I'll push to staging if there are no objections in 24h. http://codereview.appspot.com/6434048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: clarify \header variables (2640) (issue 6456047)
On 2012/07/30 14:28:35, Graham Percival wrote: ... concerned that we discuss bookTitleMarkup and scoreTitleMarkup. These are discussed in Custom layout for title blocks a little further down. But I see they are not indexed, and a back reference there to this section is not well worded. I'll amend that and post a new patch. Trevor http://codereview.appspot.com/6456047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GOP2-3: GLISS (update 1)
There seems to be fairly broad support for _some_ form of standardization. Here's an update of the proposal along those lines, along with brief responses to common concerns, in order to let people just joining the discussion to skip the past 50 emails. Better formatting here: http://lilypond.org/~graham/gop/gop_4.html ** Summary Let’s start stabilizing portions of the LilyPond input syntax. We will guarantee that selected elements of the syntax will not change (even with convert-ly) during the 3.x releases. This will be a slow process, and the first phase (2012) will not even cover the entire “single staff notation” section in the tutorial. ** Motivation Some “computer languages” are fairly stable. A TeX or C++ program written 10 years ago will probably still compile with no modifications (notwithstanding the g++ 4.3 header and namespace changes). The same is not true of LilyPond; even after using convert-ly, there are still bits that require manual updating. Given that, LilyPond is not suitable as an archival format for music. It can produce a great pdf when you first write the file, but the .ly files require regular maintenance if you want them to compile in the latest stable version of lilypond. This is a problem for projects such as mutopia – a large fraction of their .ly files don’t compile with current lilypond. That means that they can’t benefit from recent bugfixes; users wanting the sheet music in a different size (say, printing a choral score as an A5 booklet) must delve into the ly code and make manual changes. A stable input syntax should also make it easier to write converters to/from lilypond, and should also make it easier to write GUIs for lilypond. Currently, any program which exports lilypond code needs to support multiple versions (e.g., 2.12 vs. 2.16). Hopefully making it easier to output lilypond code will lead to more/better programs which do this, either in terms of converting from alternate formats into lilypond, or in terms of GUIs calling lilypond as the backend. On a personal note, this is one of the biggest reasons I’ve given up on using lilypond personally. From 2001 to 2004 I got a minor in music composition. I carefully kept all my .ly files but foolishly did not preserve the pdfs. And now, 10 years later, I’m left with a bunch of music that I cannot generate sheet music for. It’s true that I could dig out old lilypond binaries to process the ly files (and I’ll probably tdo that at some point), but it would be much nicer if I could benefit from the past ten years of bugfixes in lilypond. Manually updating the .ly files would take hours or days; I’ve started this process a few times but always lost interest after a few files, since there’s no guarantee that I wouldn’t need to go through the same process in another few years. ** Why disallow convert-ly? - it forces us to take the process seriously by removing the "safety net". Any poor decisions from the process will be enthroned in the syntax for years to come[1]. Hopefully this will make us proceed cautiously, take a more serious look at the syntax proposals for potential problems, etc. - it signals to other projects that we’re serious about this. This makes tasks such as writing importers/exporters to/from lilypond much less undesirable. It also might help people doing musicology (or music theory) research with lilypond files. - it makes lilypond more suited to being an "archival" format (or at least less unsuited). convert-ly only converts files in a forward direction. Granted, there aren’t many instances where somebody might have a corpus of music they want to render in both lilypond 3.0 and 3.2, but it’s not impossible. For example, suppose there was a team of a dozen Russian musicologists archiving folk tunes, but lilypond 3.2 doesn’t work on OSX 11.4 because Apple broke their own API again. It would be nice if the team could share lilypond files between lilypond 3.0 and 3.2. (assuming that there were no special tweaks happening – i.e. the team was first getting the notes and rhythms written down, and are not planning to do a great deal of tweaking). ** Will this help the parser? Straightening out the parser is going to lead to some breakage in complicated and/or badly written scores. That may lead to some understandable frustration from some users, but if we’re running GLISS at the same time, that gives them some hope that things will settle down. Also, simply discussing the notation we wish to support will give rise to questions about precisly what the current system already supports, and can clarify our thoughts on it. ** Not necessarily any changes GLISS will not necessarily involve any change of notation; in fact, the first portion of “syntax stabilization” could just end up approving the existing syntax exactly as it stands. I think we should discuss each notation element separately without simply rubber-stamping the existing syntax. If there are any changes in the basic notation, then
Re: GOP2-3 - GLISS or not
Graham Percival writes: > In general, yes. But some aspects of our syntax haven't been > around for a long time -- footnotes, woodwind fingering, compound > meters, etc. Do we have the best syntax for those? I mean, > maybe David can figure out a way to allow us to write > \compoundMeter (3+2)/8 > or simply > \time (3+2)/8 > instead of > \compoundMeter #(3 2 8) I'd have done so already, but \time takes an optional beatstructure argument that is indistinguishable from a compound meter, being a number list. > Other than indirectly possibly motivating people to work on > converters and GUIs from lilypond code, I don't see GLISS as > adding new features to lilypond at all. Rather, I'm expecting > that new development continues as before; after some syntax has > been around for long enough that we're confident that it's good, > we declare it as "stable" so that users and programmers can rely > on it. Longevity is not a measure for quality. In particular when we are talking undocumented language quirks that are not likely to have been known or exercised. Documenting is a good litmus test: if writing documentation for some peculiarity makes your stomach turn, chances are that declaring it as part of a "stable" set is not doing anybody a favor. >> * dramatically simplify our parser/lexer code in a way that brings >> future rewards. > > David is working on this. Somewhat backwards: I am trying to bring future rewards, and when our current syntax throws a spanner in my works, I try arguing for change by figuring out the sneakiest way to streamline it. > Some of his changes will break user code, and some users will be upset > by this. I'm trying to make users feel better by phrasing it as a > "give and take" situation. Yes, some things will break, but other > things will have a guarantee of stability -- and the area of stability > will increase over time. LilyPond has quite a few areas where the underlying design is of "poke-with-a-stick-until-it-does-one-job" quality, drive-by coding. There is little won to "stabilize" on random stuff that is going to make life harder afterwards and that probably nobody understands or uses extensively. >> * dramatically expand our user-base > > Syntax stability can't hurt converts and GUIs. I hope that GLISS > can indirectly increase our user-base by making it easier for > people to convert music into lilypond. And have a good subset of LilyPond they can expect to convert back. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Set indent based on instrument name (issue 6457049)
Little nitpicks based on my C++ experience in other projects, with no knowledge whatsoever of lilypond internals. http://codereview.appspot.com/6457049/diff/4001/lily/instrument-name-engraver.cc File lily/instrument-name-engraver.cc (right): http://codereview.appspot.com/6457049/diff/4001/lily/instrument-name-engraver.cc#newcode111 lily/instrument-name-engraver.cc:111: Instrument_name_engraver::Get_text_len_from_name (SCM scheme_text) convention is to use lower-case names for class functions (or methods if you prefer) http://codereview.appspot.com/6457049/diff/4001/lily/output-def.cc File lily/output-def.cc (right): http://codereview.appspot.com/6457049/diff/4001/lily/output-def.cc#newcode38 lily/output-def.cc:38: Real long_name_len = 0.0; could these be class member variables instead of global variables? ... hmm, more generally, I'm not sold on the whole set_inst_name_len approach. Is there any way you could just pass an additional argument to line_dimenstions_int , and determine the data you need from that function? http://codereview.appspot.com/6457049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Set indent based on instrument name (issue 6457049)
Please review. http://codereview.appspot.com/6457049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
On Fri, Jul 27, 2012 at 12:56:12PM -0300, Han-Wen Nienhuys wrote: > On Tue, Jul 24, 2012 at 6:09 AM, Graham Percival > wrote: > > Let’s decide whether to try to stabilize the syntax or not. What > > type of project do we want LilyPond to be? What kinds of > > guarantees (or at least firm intentions) do we want to give to > > users with respect to lilypond 2 or 5 years from now being able to > > read their current ly files? > > I think Lily is way past the point for us to decide that the language > needs to be changed in any major way: syntax is not what stops people > from using lilypond, and changing it in notable ways will only drive > people away from Lily. If we're not going to change a piece of syntax, then why not inform users of that fact so that they can rely on it being the same? At the moment we have something like a "de facto" standard -- if somebody writes a GUI which exports lilypond 2.12 code, then it will probably work in lilypond 2.16. Unless it doesn't, in which case convert-ly will fix it. Unless it doesn't, in which case the GUI fails and the user needs to manually edit the exported .ly files and/or file a bug with the GUI project. Of course, then the GUI front-end needs to either support multiple .ly backends (i.e. "output to lilypond 2.12", "output to lilypond 2.16"). Or else it could drop support for lilypond 2.12 and only output for lilypond 2.16. Regardless of GLISS, we already *are* changing the format in non-convert-ly ways. Just last week, Keith found an example from mutopia that failed to compile after a proposed patch was applied. Now, I still support making that change, but I think we should give users (and programmers of projects which convert or export to lilypond) some hope that simple music won't be changed. I'm not saying that GLISS will necessarily involve any change of notation. I think we should discuss each notation element separately, and we should certainly consider whether any disadvantages of the current notation outweigh the pain of changing. Maybe we'll decide that it's not worth making any changes at all, so GLISS really will just be "input syntax *stabilization*". > We've had this problem for many years in the 1998-2003 period, when it > was a usable but limited program, and people had to re-tweak their .ly > files every few months because we had to get out of a corner we > painted ourselves into. Right. I was good friends with the guy who tried to maintain the rosegarden lilypond export when we were doing 1.6 to 1.8. I think that was when we changed from simultaneous music being <> to <<>> ? I can't remember the specifics, but he was pretty frustrated and in the end gave up. > Rather than "defining" some stable subset (and then getting into a lot > of discussion on what that subset should look like), I think we should > just take the overall decision on intent, that is: what are we trying > to do? My suggestion is: > > * big changes: not OK I agree with this. > * small changes, especially when they clean up things (I'm thinking of > the 4. vs 4.0 change David is working on): in principle OK, but the > upgrade path should either be automatic or cause failure on > compilation. I disagree; we're not going to be perfect with any new syntax. I think it's worthwhile to introduce new syntax for a year or two, find out what works and what doesn't, and fix it if necessary. Just look at all the iterations that footnotes have gone through! > * small changes that do not fall in the latter should be done over two > stable releases. First, you make the old syntax trigger compile > failure, and only the 2nd stable release you introduce a new > interpretation. That requires a fair amount of programmer effort to add the extra error checks and remove them later. > > ** Stability or not? > > > > Stabilizing a language is a tricky process. If you do it too > > early, then you’re stuck with whatever mistakes or poor design > > decisions. > > LilyPond has been around for 15 years, and its basic syntax for 9 > years. It would be weird to suggest that we'd be stabilizing to early. In general, yes. But some aspects of our syntax haven't been around for a long time -- footnotes, woodwind fingering, compound meters, etc. Do we have the best syntax for those? I mean, maybe David can figure out a way to allow us to write \compoundMeter (3+2)/8 or simply \time (3+2)/8 instead of \compoundMeter #(3 2 8) > > and then we guarantee that this file will compile, completely > > unmodified (no convert-ly allowed), for every lilypond 3.x > > version. This seem like a really small step, but I really don’t > > think that we can overestimate how much time, energy, and > > arguments this will require. > > I think this reasoning is red herring. Arguments take as much energy > as the participants want to invest in it. If you spend too much time > on it, stop writing replies to discussions. If people declared somebody as the ultimate dictator of input syntax, the
Re: Issue 1650: merge multiple header specifications. (issue 6445053)
On Mon, Jul 30, 2012 at 02:43:46PM +, d...@gnu.org wrote: > "Incorrect title (from book)" > "Correct title (from bookpart)" > and similar. That way, it is easier to see whether the results are as > expected. sure, that sounds good. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1650: merge multiple header specifications. (issue 6445053)
LGTM, seems to work correctly on all my (reg)tests. I actually like David's idea of changing the header field values to include correctness information. Still I like comments inside sample code to make the reasons for a particular block clearer. http://codereview.appspot.com/6445053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Using MSH Paris Nord server
John Mandereau writes: > 2012/7/30 Graham Percival : >> I'm not convinced that this is an advantage. I'd rather have one >> central place to look for patches and their status (currently >> google code, filtered by "has:Patch" and sorted based on patch >> status[1]). If "not bug fixes" patches aren't listed in the same >> place as "bug fix" patches, then we'll have two websites to check >> and keep up-to-date. > > I have never meant this. I meant that if we decide to adopt Gerrit, > then *all* pending patches will be on Gerrit, but patches that don't > come from bug reports on Google Code tracker needn't be added there. > > >> In short: we already have a global eye on submitted patches, >> provided that people use git-cl. > > Gerrit can provide this as well, and might offer a better global eye > than a generic issue tracker, be it an excellent one like Google Code. There is no point arguing this. We can't do a reasonable side-by-side comparison and/or transition if we don't work with the same frontend. The decision to change the frontend would be a rather invasive one, and one can't use more than one frontend in parallel since the point of the frontend is to provide a _complete_ overview over existing issues. > We certainly agree on this as long as we use Rietveld for patches > review, but if we find a better tool that provides a good frontend for > patches review that can also integrate with Google code, then there's > no reason to keep Google code as the frontend. Again: wrong time to argue this. One thing after the other. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Using MSH Paris Nord server
2012/7/30 Graham Percival : > I'm not convinced that this is an advantage. I'd rather have one > central place to look for patches and their status (currently > google code, filtered by "has:Patch" and sorted based on patch > status[1]). If "not bug fixes" patches aren't listed in the same > place as "bug fix" patches, then we'll have two websites to check > and keep up-to-date. I have never meant this. I meant that if we decide to adopt Gerrit, then *all* pending patches will be on Gerrit, but patches that don't come from bug reports on Google Code tracker needn't be added there. > In short: we already have a global eye on submitted patches, > provided that people use git-cl. Gerrit can provide this as well, and might offer a better global eye than a generic issue tracker, be it an excellent one like Google Code. > Don't get me wrong: I have nothing against switching the "backend" > from rietveld to gerrit. I just want to keep the google code > "frontend". We certainly agree on this as long as we use Rietveld for patches review, but if we find a better tool that provides a good frontend for patches review that can also integrate with Google code, then there's no reason to keep Google code as the frontend. > Ok. I just want to emphasize that you could easily spend 20 hours > setting this up, but then have the response be "no, we prefer the > old system". I've already evaluated this, so I don't mind :-) John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1650: merge multiple header specifications. (issue 6445053)
Reviewers: Graham Percival, Message: On 2012/07/30 14:35:05, Graham Percival wrote: LGTM, and I really like the comments in the regtests. Not me who can claim credit. In a few instances they were slightly unclear, though. I did not even bother looking at them. You'll probably tear your hairs out, but I lean towards scrapping the comments mostly, and instead augment the title texts to things like "Incorrect title (from book)" "Correct title (from bookpart)" and similar. That way, it is easier to see whether the results are as expected. Description: Issue 1650: merge multiple header specifications. Books get initialized from $defaultheader, this is what toplevel \header will set, and scores and bookparts are initialized empty so that they will end up combined with their respective (possibly implicit) books. Please review this at http://codereview.appspot.com/6445053/ Affected files: A input/regression/header-book-multiple.ly A input/regression/header-book-multiplescores.ly A input/regression/header-bookpart-multiple.ly A input/regression/header-score-multiple.ly A input/regression/header-toplevel-multiple.ly M lily/parser.yy ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Using MSH Paris Nord server
Reinhold Kainhofer writes: > On 30/07/2012 16:21, Graham Percival wrote: >> oh, logins just occurred to me. Can gerrit let people log in with >> their google accounts (IIRC there's an api for that), or would we >> all need to make new accounts on the gerrit server? > > > IIRC, gerrit works with any openID service... > A while ago I set up gerrit on my server to evaluate it (I even posted > it here), but I have meanwhile removed the installation again, as it > seemed no one was really interested. Without test-patchy understanding Gerrit URLs, there is really no way in which one can actually test this in connection with LilyPond development. In addition I would have needed a login IIRC. I agree with Graham that a transition is not feasible unless we can continue working with the Google Code frontend. A frontend move would be much more of a non-reversible change than supporting another backend. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 1650: merge multiple header specifications. (issue 6445053)
LGTM, and I really like the comments in the regtests. In a few
instances they were slightly unclear, though.
http://codereview.appspot.com/6445053/diff/2001/input/regression/header-book-multiple.ly
File input/regression/header-book-multiple.ly (right):
http://codereview.appspot.com/6445053/diff/2001/input/regression/header-book-multiple.ly#newcode14
input/regression/header-book-multiple.ly:14: % This should NOT replace,
but amend the header:
I spent 30 seconds trying to figure out why you wanted the title to be
printed as
"Title New Title"
before I realized I was misreading the comment.
Could the comment instead be:
% This should not replace the entire header, but only replace the
'title' field of the previous header. The subtitle should be unchanged.
similar change below. Alternately, you could change the field names:
\header{ title="don't print this title" subtitle="print subtitle" }
\header{ title="print this title"}
... etc. (with proper line-breaks because humans like using \n as a
separator even if lilypond doesn't distinguish between types of
whitespace)
http://codereview.appspot.com/6445053/diff/2001/input/regression/header-book-multiplescores.ly
File input/regression/header-book-multiplescores.ly (right):
http://codereview.appspot.com/6445053/diff/2001/input/regression/header-book-multiplescores.ly#newcode23
input/regression/header-book-multiplescores.ly:23: %% Do we have a
title, and is "New Subtitle" the subtitle?
please change to:
% this should print "new subtitle".
rather than having a question.
http://codereview.appspot.com/6445053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme spanner in input/regression/scheme-text-spanner.ly not quote-proof
Reinhold Kainhofer writes:
> On 28/07/2012 07:32, David Kastrup wrote:
>> Reinhold Kainhofer writes:
>>
>>> The text spanner implemented in scheme (which is also used as a basis
>>> for David's measure counter engraver) seems to work fine in the regtest,
>>> but apparently it is not quote-proof.
>>>
>>> In particular, if you try call \addQuote on some music that contains
>>> \schemeTextSpannerStart or \schemeTextSpannerEnd, then you get the
>>> following warnings and the text spanner is not quoted:
>> Well, scheme-text-spanner changes the \Global context, and quote
>> environments uses the layout definition partCombineListener in
>> ly/declarations-init.ly with an unchanged Global context.
>>
>> Change its Global context similarly, and you should be set.
>
> How can a user, who wants to use e.g. the measure counter engraver,
> change the partCombineListener' s Global context without messing with
> the original lilypond sources?
Uh, in the same manner as he changes the normal Global context?
> Am I missing something?
I don't understand the problem. You do something like
partCombineListener = \layout {
\partCombineListener
\context {
\Global
\grobdefinitions ...
EventClasses = ...
}
}
> The whole point of scheme engravers and scheme text spanners is that
> users can now also implement things in scheme without messing with the
> lilypond sources...
> If I understand you right, then the user cannot add new grobs in an
> include file without messing with the lilypond sources.
Make no mistake: scheme-text-spanner is a heap of junk messing with
LilyPond internals. Less so than previously, but still far too much.
So yes: for all practical purposes, the user cannot add new grobs. What
scheme-text-spanner does is not a user interface. It is code
duplication and hacking with internals. You can extend this hackery to
the partCombineListener if you want to. But scheme-text-spanner does
not in _any_ way constitute a user-accessible mechanism that is
guaranteed not to break either now or in future.
> Would a proper solution be to change the partCombineListener to a
> context mod and construct the real listener when we need it (i.e.
> replace the current (ly:parser-lookup parser 'partCombineListener) by
> the actual creation of the listener from the context in effect when
> add-quotable or recording-group-emulate is called?
I have no clue what you are talking about. partCombineListener is an
output definition, and I see no problem with it that would be any
different from that of the normal \layout output definition.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Using MSH Paris Nord server
On 30/07/2012 16:21, Graham Percival wrote: > oh, logins just occurred to me. Can gerrit let people log in with > their google accounts (IIRC there's an api for that), or would we > all need to make new accounts on the gerrit server? IIRC, gerrit works with any openID service... A while ago I set up gerrit on my server to evaluate it (I even posted it here), but I have meanwhile removed the installation again, as it seemed no one was really interested. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: Order of engravers within context matters (673) (issue 6448063)
LGTM, much easier to read now! http://codereview.appspot.com/6448063/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Midi: store dynamic information for note-on velocity; issue 1661 (issue 6428075)
LGTM http://codereview.appspot.com/6428075/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: clarify \header variables (2640) (issue 6456047)
http://codereview.appspot.com/6456047/diff/1/Documentation/notation/input.itely
File Documentation/notation/input.itely (left):
http://codereview.appspot.com/6456047/diff/1/Documentation/notation/input.itely#oldcode645
Documentation/notation/input.itely:645: @code{\header} title block and
@code{scoreTitleMarkup} for individual
I remember Mark Polesky being very concerned that we discuss
bookTitleMarkup and scoreTitleMarkup. IIRC it's good to know these
names in case you want to change the layout?
Anyway, I agree that these words aren't the most important parts of this
section (so I'm fine with your change to the top of this @node), but we
should probably mention them _somewhere_. Could you find some to copy
this paragraph to? or if it's already covered somewhere else in the
docs, then I'm happy to drop my concern.
http://codereview.appspot.com/6456047/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2702 in lilypond: Patch: Unify the lexer's idea of words and commands across all modes.
On Mon, Jul 30, 2012 at 02:57:06PM +0100, Graham Percival wrote:
>
> ok, but are we stepping in the right direction here? I mean, if
> \relative c' {
> \tempo "Allegro" 4. = 60
> }
> works but
> \midi {
> \tempo "Allegro" 4. = 60
> }
> fails, I wouldn't blame anybody for being surprised.
>
Not only that but software that generates ly files would not want to use
different formats for the temp in different places.
Bernard
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Using MSH Paris Nord server
On Mon, Jul 30, 2012 at 01:48:15PM +0200, John Mandereau wrote: > From: John Mandereau > 2012/7/30 David Kastrup : > > Here is what I see as the required steps: -snip steps- > > At this point of time, it becomes feasible to sensibly test one setup > > against the other for a typical developer. Yes. > However, a Gerrit setup for LilyPond alone will certainly help having > a global eye on submitted patches, and avoid creating Google Code > issues for patches that are not bug fixes. I'm not convinced that this is an advantage. I'd rather have one central place to look for patches and their status (currently google code, filtered by "has:Patch" and sorted based on patch status[1]). If "not bug fixes" patches aren't listed in the same place as "bug fix" patches, then we'll have two websites to check and keep up-to-date. In short: we already have a global eye on submitted patches, provided that people use git-cl. If they don't use git-cl, then it doesn't matter whether the "backend" is rietveld or gerrit; the patch will be lost in limbo on lilypond-devel until some kind developer steps in. Don't get me wrong: I have nothing against switching the "backend" from rietveld to gerrit. I just want to keep the google code "frontend". [1] sorry, icky url: http://code.google.com/p/lilypond/issues/list?can=2&q=has:Patch&sort=patch IMO all developers should have this bookmarked. > > Of course, if we later find that everybody finds Gerrit too cumbersome > > to use, or if we get serious protests against reviews being even placed > > there, the work invested up to that point may be wasted. > > Wasting time setting up Gerrit was my concern, but now it's no longer. > I'll chime in back when I have done steps a) and b). Ok. I just want to emphasize that you could easily spend 20 hours setting this up, but then have the response be "no, we prefer the old system". oh, logins just occurred to me. Can gerrit let people log in with their google accounts (IIRC there's an api for that), or would we all need to make new accounts on the gerrit server? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme spanner in input/regression/scheme-text-spanner.ly not quote-proof
On 28/07/2012 07:32, David Kastrup wrote: > Reinhold Kainhofer writes: > >> The text spanner implemented in scheme (which is also used as a basis >> for David's measure counter engraver) seems to work fine in the regtest, >> but apparently it is not quote-proof. >> >> In particular, if you try call \addQuote on some music that contains >> \schemeTextSpannerStart or \schemeTextSpannerEnd, then you get the >> following warnings and the text spanner is not quoted: > Well, scheme-text-spanner changes the \Global context, and quote > environments uses the layout definition partCombineListener in > ly/declarations-init.ly with an unchanged Global context. > > Change its Global context similarly, and you should be set. How can a user, who wants to use e.g. the measure counter engraver, change the partCombineListener' s Global context without messing with the original lilypond sources? Am I missing something? The whole point of scheme engravers and scheme text spanners is that users can now also implement things in scheme without messing with the lilypond sources... If I understand you right, then the user cannot add new grobs in an include file without messing with the lilypond sources. Would a proper solution be to change the partCombineListener to a context mod and construct the real listener when we need it (i.e. replace the current (ly:parser-lookup parser 'partCombineListener) by the actual creation of the listener from the context in effect when add-quotable or recording-group-emulate is called? However, I don't really have enough knowledge about how to create the actual listener in scheme and insert a given context mod in scheme... Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2702 in lilypond: Patch: Unify the lexer's idea of words and commands across all modes.
Graham Percival writes:
> On Mon, Jul 30, 2012 at 03:48:48PM +0200, David Kastrup wrote:
>> Graham Percival writes:
>>
>> > Does this affect
>> >
>> > {
>> > \tempo 4. = 120
>> > c2 d
>> > %\tempo "Adagio" 4. = 43.5
>> > \tempo "Adagio" 4. = 43
>> > e4. d8 c2
>> > }
>> >
>> > ?
>>
>> No.
>
> (aside: do we want to disallow all decimals in metronome markings?
> 43.5 doesn't work. I'm perfectly fine forbidding them, but some
> contemporary composers might want to give exact values)
#43.5 should work. I already stated that I would prefer having tokens
not mode dependent, and thus prohibit 4. from really meaning 4.0.
However, we already juggle between 4 (the duration) and 4 (the integer),
so that is basically just one more aggravation, and one could similarly
interpret 4. according to context.
In any way, I consider it a bit tasteless that we have to revert to
Scheme for disambiguating stuff that should be part of the regular
syntax.
>> \tempo syntax is insane. This is one thing that will eventually have to
>> go.
>
> ok, but are we stepping in the right direction here? I mean, if
> \relative c' {
> \tempo "Allegro" 4. = 60
> }
> works but
> \midi {
> \tempo "Allegro" 4. = 60
> }
> fails, I wouldn't blame anybody for being surprised.
We are not "stepping in the right direction". This is where we already
are.
>> Whitespace is whitespace in LilyPond without further significance,
>> and we are _not_ going to change this against my very firm
>> disapproval. It would be the death knell for having LilyPond
>> reasonably useful for computer-generated output, like exports from
>> other music software.
>
> I'm not seriously suggesting it, but I'd argue that significant
> whitespace should have an insignificant effect on
> computer-generated output. I mean, sure it might take an extra
> hour of debugging, but once you've got your exporter adding the
> right number of spaces, it should work, right?
Do you even have an idea what "adding the right number of spaces"
entails? You can no longer translate data to output in a linear
fashion, since you always have to track your current indentation level.
You can't, say, call a function for outputting an expression, because
you need to know whether you are at the start of line after or before
indentation, or somewhere else in line.
You _can't_ concatenate code and/or splice it in, because you need to
reformat it using the current indentation.
Have you ever written a program generating non-trivial Python? Or a
pretty-printer? Much more complex than writing just a printer, and with
an indentation-sensitive language, _everything_ needs to be
pretty-printed, in context.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: added missing #inlude for use with g++ 4.7 (issue 6434048)
On Mon, Jul 30, 2012 at 03:50:18PM +0200, David Kastrup wrote: > gra...@percival-music.ca writes: > > > LGTM, and I think it can be pushed to staging right now. > > Without even asking test-patchy? Sorry, of course we should ask test-patchy. I meant after that -- i.e. in this case I think we can skip the 96-hour countdown (since one countdown already started). However, if you have any concerns other than test-patchy, then of course we should wait and have the full countdown for reviews. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2702 in lilypond: Patch: Unify the lexer's idea of words and commands across all modes.
On Mon, Jul 30, 2012 at 03:48:48PM +0200, David Kastrup wrote:
> Graham Percival writes:
>
> > Does this affect
> >
> > {
> > \tempo 4. = 120
> > c2 d
> > %\tempo "Adagio" 4. = 43.5
> > \tempo "Adagio" 4. = 43
> > e4. d8 c2
> > }
> >
> > ?
>
> No.
(aside: do we want to disallow all decimals in metronome markings?
43.5 doesn't work. I'm perfectly fine forbidding them, but some
contemporary composers might want to give exact values)
> >> \midi { \tempo "Moderato"
> >> line-width = 100\mm }
> >>
> >> will not work any more, since
> >>
> >> \tempo "Moderato" 4. = 56
>
> Well, in the Midi block, \tempo "Moderato" is not exactly important.
> > hmm, I'm beginning to appreciated why C uses semicolons. ;)
>
> \tempo syntax is insane. This is one thing that will eventually have to
> go.
ok, but are we stepping in the right direction here? I mean, if
\relative c' {
\tempo "Allegro" 4. = 60
}
works but
\midi {
\tempo "Allegro" 4. = 60
}
fails, I wouldn't blame anybody for being surprised.
> Whitespace is whitespace in LilyPond without further significance, and
> we are _not_ going to change this against my very firm disapproval. It
> would be the death knell for having LilyPond reasonably useful for
> computer-generated output, like exports from other music software.
I'm not seriously suggesting it, but I'd argue that significant
whitespace should have an insignificant effect on
computer-generated output. I mean, sure it might take an extra
hour of debugging, but once you've got your exporter adding the
right number of spaces, it should work, right? I think the real
problem would be non-technical users trying to write files,
potentially without a fixed-width font, and getting confused about
7 spaces vs. 8 spaces.
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: added missing #inlude for use with g++ 4.7 (issue 6434048)
gra...@percival-music.ca writes: > LGTM, and I think it can be pushed to staging right now. Without even asking test-patchy? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: error while running make check (g++ 4.7.0): missing include of unistd.h
2012/7/30 Frédéric Bron : >> I wanted to run regression tests and compare before and after a change. >> However, I obtained the error given below after make -j8 CPU_COUNT=8 check >> >> I suspect this is because I am compiling with gcc/g++ 4.7.0 (coming >> with Fedora 17) and its release notes say: >> "Avoid polluting the global namespace and do not include ." >> we should then include >>#include >>#include >> before using getpid and getcwd. > > Who can review my patch? > http://codereview.appspot.com/6434048 To make our life easier with verifying that the build of sources with your patch passes, we currently use Google Code issues. As Graham pointed out, I created one manually, but please do so next time, which should be done if you enter login details in git-cl: Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2702 in lilypond: Patch: Unify the lexer's idea of words and commands across all modes.
Graham Percival writes:
> On Mon, Jul 30, 2012 at 01:12:44PM +0200, David Kastrup wrote:
>> Graham Percival writes:
>> > Could I have some examples? I just don't get this "word"
>> > business. Is there any syntax which was previously
>> > (theoretically) supported, which this patch breaks?
>>
>> Here is one thing that can be made to work: we can have music inside of
>> output definitions, but currently it is parsed in "initial" mode. That
>> means something like
>>
>> \layout { \tempo 4. = 120 }
>>
>> will not work and has to be written as
>>
>> \layout { \tempo 4 . = 120 }
>>
>> since 4. is a real number in "initial" mode. One way out would be to
>
> -snip explanation-
>
> Does this affect
>
> {
> \tempo 4. = 120
> c2 d
> %\tempo "Adagio" 4. = 43.5
> \tempo "Adagio" 4. = 43
> e4. d8 c2
> }
>
> ?
No.
> I thought that \tempo was something we put with notes, and the
> Notation manual agrees with me. Your example of \layout{} is
> confusing me.
Uh, right. This was supposed to be \midi { \tempo ... } for setting the
playback speed. Sorry for the confusion.
>> switch into "notes" mode temporarily for music. If we do that,
>> something like
>>
>> \layout { \tempo "Moderato"
>> line-width = 100\mm }
>>
>> will not work any more, since
>>
>> \tempo "Moderato" 4. = 56
Well, in the Midi block, \tempo "Moderato" is not exactly important.
> hmm, I'm beginning to appreciated why C uses semicolons. ;)
\tempo syntax is insane. This is one thing that will eventually have to
go.
> What about line-breaks? The combination of "functions" (in the
> generic sense, since I don't know if \tempo is an expression or
> macro or music function or whatever) having an optional number of
> arguments, with a lack of explicit "command is over" symbol,
> surely leads to a huge ton of pain in the parser/lexer.
>
> With my python background, I'd be perfectly happy to have
> significant-whitespace indents, i.e.
> \tempo "Allegro"
> 4. = 100
> line-width = 100\mm
>
> however, I acknowledge that it takes about two weeks for python
> beginners to get comfortable with this, so it may scare away
> musicians.
Whitespace is whitespace in LilyPond without further significance, and
we are _not_ going to change this against my very firm disapproval. It
would be the death knell for having LilyPond reasonably useful for
computer-generated output, like exports from other music software.
> I suppose that another option could be a "line continuation
> character", like \ in bash. But again, I could easily imagine this
> leading to more confusing syntax for beginners, not less.
No. And I don't want to throw ';' away by using it as a separator,
either.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
added missing #inlude for use with g++ 4.7 (issue 6434048)
LGTM, and I think it can be pushed to staging right now. http://codereview.appspot.com/6434048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: error while running make check (g++ 4.7.0): missing include of unistd.h
On Mon, Jul 30, 2012 at 08:50:01AM +0200, Frédéric Bron wrote: > Who can review my patch? > http://codereview.appspot.com/6434048 I see that John has just added it to the tracker: http://code.google.com/p/lilypond/issues/detail?id=2704 so it will now make its way onto our countdown. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2702 in lilypond: Patch: Unify the lexer's idea of words and commands across all modes.
On Mon, Jul 30, 2012 at 01:12:44PM +0200, David Kastrup wrote:
> Graham Percival writes:
> > Could I have some examples? I just don't get this "word"
> > business. Is there any syntax which was previously
> > (theoretically) supported, which this patch breaks?
>
> Here is one thing that can be made to work: we can have music inside of
> output definitions, but currently it is parsed in "initial" mode. That
> means something like
>
> \layout { \tempo 4. = 120 }
>
> will not work and has to be written as
>
> \layout { \tempo 4 . = 120 }
>
> since 4. is a real number in "initial" mode. One way out would be to
-snip explanation-
Does this affect
{
\tempo 4. = 120
c2 d
%\tempo "Adagio" 4. = 43.5
\tempo "Adagio" 4. = 43
e4. d8 c2
}
? I thought that \tempo was something we put with notes, and the
Notation manual agrees with me. Your example of \layout{} is
confusing me.
I think it would a real shame if we cannot let people specify a
metronome marking with the normal way of writing rhythms (i.e.
"4.").
> switch into "notes" mode temporarily for music. If we do that,
> something like
>
> \layout { \tempo "Moderato"
> line-width = 100\mm }
>
> will not work any more, since
>
> \tempo "Moderato" 4. = 56
hmm, I'm beginning to appreciated why C uses semicolons. ;)
What about line-breaks? The combination of "functions" (in the
generic sense, since I don't know if \tempo is an expression or
macro or music function or whatever) having an optional number of
arguments, with a lack of explicit "command is over" symbol,
surely leads to a huge ton of pain in the parser/lexer.
With my python background, I'd be perfectly happy to have
significant-whitespace indents, i.e.
\tempo "Allegro"
4. = 100
line-width = 100\mm
however, I acknowledge that it takes about two weeks for python
beginners to get comfortable with this, so it may scare away
musicians.
I suppose that another option could be a "line continuation
character", like \ in bash. But again, I could easily imagine
this leading to more confusing syntax for beginners, not less.
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fwd: Patchy's configure flags
Sorry for duplicating a message again David, I'm bugged by an email client I don't use often. -- Forwarded message -- From: John Mandereau Date: 2012/7/30 Subject: Re: Patchy's configure flags To: David Kastrup 2012/7/30 David Kastrup : > The problem is not actually the optimization setting, but the debug > code. So, I guess it's fine if I use CXXFLAGS="-O2 -finline-functions -march=pentium4 -mfpmath=sse" ./configure --disable-optimising ? Thanks, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy's configure flags
John Mandereau writes: > I wonder why Patchy has unconditionnally run configure with > --disable-optimising since last December or so. Because without that, compilations get run with -DNDEBUG and assertions are not tested. Also some other tests (like that for parsed objects that should be dead) are not being run. http://code.google.com/p/lilypond/issues/detail?id=1905> http://code.google.com/p/lilypond/issues/detail?id=1908#c3> > I guess there used to be issues with optimisation for some GCC > versions. Could optimisations be enabled again now? Or better, could > we allow developers who run Patchy tune configure flags? > > I'm asking this because I suspect the Pentium 4 at MSH Paris Nord > could build the docs significantly faster by building LilyPond with > appropriate GCC flags, instead of building a binary for a generic x86 > processor. The problem is not actually the optimization setting, but the debug code. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Patchy's configure flags
I wonder why Patchy has unconditionnally run configure with --disable-optimising since last December or so. I guess there used to be issues with optimisation for some GCC versions. Could optimisations be enabled again now? Or better, could we allow developers who run Patchy tune configure flags? I'm asking this because I suspect the Pentium 4 at MSH Paris Nord could build the docs significantly faster by building LilyPond with appropriate GCC flags, instead of building a binary for a generic x86 processor. John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fwd: Using MSH Paris Nord server
-- Forwarded message -- From: John Mandereau Date: 2012/7/30 Subject: Re: Using MSH Paris Nord server To: David Kastrup 2012/7/30 David Kastrup : > Here is what I see as the required steps: > > a) get a gerrit server set up > b) make test-patches.py deal with either Rietveld or Gerrit URLs for >testing > > At this point of time, it becomes feasible to manually create a Gerrit > review and have it go through our normal processes. > > c) make git-cl configurable so that it can optionally create Gerrit >reviews instead of Rietveld reviews. > > At this point of time, it becomes feasible to sensibly test one setup > against the other for a typical developer. > > d) document Gerrit operation of git-cl in the CG > > e) deprecate Rietveld use Right. I was about to submit patches the build system (cleaning traces of Stepmake as an installable, separate package, merging make and stepmake/stepmake, using git file list to roll source tarball, reduce make overhead by deleting useless makefiles in many subdirectories), but I think trying Gerrit has a higher priority, and it will be a good opportunity to test Gerrit on those patches (e.g. I'd be glad to see that Gerrit handles diffs with file renames, i.e. "git diff -M" on the command-line). > I don't see that feature comparisons from manuals will do much for > getting an actual hang of the respective advantages/disadvantages. At least it allows estimating them, I wanted to do this before diving into setting up Gerrit. Your message saves me the time and energy of writing a detailed review based on feature comparisons from manuals and previous discussions, which as you say would have far less value than an actual experiment with these tools/ > We know that the principal disadvantage of Rietveld is its inability to > deal with a patch sequence gracefully, and that one reviews tree changes > rather than commits (which would include commit messages, authors, > signoffs etc). Agreed. I experienced this too. > The base feature set other than that is comparable, but > figuring out how feasible the respective use cases will be can only be > done in practice. It seems from its manual that Gerrit doesn't provide as much email integration as Rietveld (e.g. replies by email get added to the review comments threads in the review server), but it might, and anyway this would not be terribly hard to add. However, a Gerrit setup for LilyPond alone will certainly help having a global eye on submitted patches, and avoid creating Google Code issues for patches that are not bug fixes. > I don't see that be can get by without at least > implementing b) in some manner, and we don't really need much of > "sufficient approval from core developers" for that. I was thinking of other tools, like ReviewBoard, but I find don't their issues system much useful; it has integration with Google Code, it seems to provide better Git integration than Rietveld, but less than Gerrit http://www.reviewboard.org/docs/manual/dev/faq/#does-review-board-support-git Well, we can integrate Gerrit with Google code through git-cl/test-patches, so ReviewBoard doesn't seem to win over Gerrit w.r.t. these two criteria. > Of course, if we later find that everybody finds Gerrit too cumbersome > to use, or if we get serious protests against reviews being even placed > there, the work invested up to that point may be wasted. Wasting time setting up Gerrit was my concern, but now it's no longer. I'll chime in back when I have done steps a) and b). John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2702 in lilypond: Patch: Unify the lexer's idea of words and commands across all modes.
Graham Percival writes:
> On Sun, Jul 29, 2012 at 10:15:10PM +0200, David Kastrup wrote:
>
>> It turns out that this definition works with
>> both "make test" as well as "make doc" without requiring any change in the
>> LilyPond code base.
>
> That's certainly promising.
>
>> Discuss. This is quite a consequential change regarding what word syntax
>> is valid and what not, but the previous state was rather arbitrary to the
>> degree of being wonky.
>
> Could I have some examples? I just don't get this "word"
> business. Is there any syntax which was previously
> (theoretically) supported, which this patch breaks?
Here is one thing that can be made to work: we can have music inside of
output definitions, but currently it is parsed in "initial" mode. That
means something like
\layout { \tempo 4. = 120 }
will not work and has to be written as
\layout { \tempo 4 . = 120 }
since 4. is a real number in "initial" mode. One way out would be to
switch into "notes" mode temporarily for music. If we do that,
something like
\layout { \tempo "Moderato"
line-width = 100\mm }
will not work any more, since
\tempo "Moderato" 4. = 56
is perfectly valid input, so the parser has to look ahead to see whether
anything that might be a duration will follow. It can't switch back to
"INITIAL" mode for that. But with our current setup, a "word" in
"notes" mode will not be allowed to contain hyphens, so the next token
is a STRING with the value "line". In "INITIAL" mode, it would be a
STRING with the value "line-width". Having just "line" be the string
means that the assignment goes haywire.
In contrast, if words have the same form in all modes, "line-width" will
get scanned correctly even while still being in "notes" mode, and the
following assignment will work properly after switching back to
"INITIAL" mode nominally one token late.
Having fewer different modes in the lexer also means that mostly
mode-unaware tools like highlighting editors and convert-ly are more
likely to get the basic units they are messing with identified
correctly.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Using MSH Paris Nord server
John Mandereau writes: > 2012/7/23 John Mandereau : >> Il giorno lun, 23/07/2012 alle 19.25 +0200, David Kastrup ha scritto: >>> Maybe running gerrit on it would be an option? >> >> This sounds an excellent idea. > > Wait, there has already been much discussion about patch review tools, > much of it happened when I was completely away. Before diving into > setting up Gerrit, I'd like to summarize the pros and cons of > Rietveld+Google Code Issues+Patchy (current system), Gerrit, > ReviewBoard, and others, judging on features that have been discussed > on this list. Be warned that I tend to prefer Gerrit, but I don't want > to spend time setting it before a contradictory assesment (summarizing > previous discussion and comparing the features of these tools > advertized by their manuals) and sufficient approval from core > developers. That implies having to make a choice before thinking about switching. I don't see that this makes much sense. Here is what I see as the required steps: a) get a gerrit server set up b) make test-patches.py deal with either Rietveld or Gerrit URLs for testing At this point of time, it becomes feasible to manually create a Gerrit review and have it go through our normal processes. c) make git-cl configurable so that it can optionally create Gerrit reviews instead of Rietveld reviews. At this point of time, it becomes feasible to sensibly test one setup against the other for a typical developer. d) document Gerrit operation of git-cl in the CG e) deprecate Rietveld use I don't see that feature comparisons from manuals will do much for getting an actual hang of the respective advantages/disadvantages. We know that the principal disadvantage of Rietveld is its inability to deal with a patch sequence gracefully, and that one reviews tree changes rather than commits (which would include commit messages, authors, signoffs etc). The base feature set other than that is comparable, but figuring out how feasible the respective use cases will be can only be done in practice. I don't see that be can get by without at least implementing b) in some manner, and we don't really need much of "sufficient approval from core developers" for that. Of course, if we later find that everybody finds Gerrit too cumbersome to use, or if we get serious protests against reviews being even placed there, the work invested up to that point may be wasted. But I don't see how we can even attempt to arrive at a decision before getting there. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Using MSH Paris Nord server
2012/7/23 John Mandereau : > Il giorno lun, 23/07/2012 alle 19.25 +0200, David Kastrup ha scritto: >> Maybe running gerrit on it would be an option? > > This sounds an excellent idea. Wait, there has already been much discussion about patch review tools, much of it happened when I was completely away. Before diving into setting up Gerrit, I'd like to summarize the pros and cons of Rietveld+Google Code Issues+Patchy (current system), Gerrit, ReviewBoard, and others, judging on features that have been discussed on this list. Be warned that I tend to prefer Gerrit, but I don't want to spend time setting it before a contradictory assesment (summarizing previous discussion and comparing the features of these tools advertized by their manuals) and sufficient approval from core developers. John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Using MSH Paris Nord server
2012/7/25 David Kastrup : > Lilyfan writes: >>> Message du 25/07/12 00:08 >>> De : "Trevor Daniels" >>> A : "Graham Percival" , "John Mandereau" >>> Copie à : "lilypond-devel" >>> Objet : Re: Using MSH Paris Nord server >>> Graham Percival wrote Tuesday, July 24, 2012 10:55 PM >>> >>> > grenouille.lilynet.net. >>> >>> I like it. Definitely better than crapaud which has an unfortunate >>> connotation to English-speakers. >>> >>> Trevor > > Well, the association for me was > http://en.wikipedia.org/wiki/Jean-Baptiste_Grenouille>, as the > not-quite sympathy-inspiring protagonist of a German novel. However, > the novel quite expands on the ethymology of the name, so the reader > will be aware of the association to frogs. > > Of course, it is almost inevitable for those versed in both the American > as well as the French language to think of John Longhorn's (aka Mark > Twain) famous frog story > http://www.angelfire.com/nb/classillus/images/jumping/jumping.html>, > an 18th century precursor of the famous "translate back and forth" game > that nowadays is popular with computer translation programs. Thanks for these references David. Jean-Charles, I'm sorry but there are more votes for "grenouille", so let's go for this. I'm asking Valentin. John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
