Re: Ugliness in the Learning Manual
I've now reported the cartouche problem to bug-texinfo. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GOP-PROP 7: Developers as resources (accepted)
No comments last time, but this is just a confirmation of status quo proposal so I'm not concerned that I've missed any dissent. Officially accepted now. http://lilypond.org/~graham/gop/gop_7.html ** Proposal summary We shall treat developers (and contributors) as Independent volunteers: each person does whatever they want, whenever they want. We have busy careers and lives; we make no expectations of action from anybody (with the exception of the 6 people in “Meister” positions). Two people expressed interest in having some sort of “team” approach, where they would work collaboratively (possibly under the direction of somebody) on a problem, but that is not sufficient interest to make it worth organizing. ** Rationale I have historically been very vocal about treating developers at “independent volunteers”, but some recent discussions are making me wonder if that’s the best way to go. Our policy on this topic will influence many upcoming discussions. ** Implementation notes None yet. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB can't build fonts
I see a ton of errors like this: Compilation failed in require at /main/src/gub/target/darwin-ppc/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/out/mf2pt1 line 30. BEGIN failed--compilation aborted at /main/src/gub/target/darwin-ppc/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/out/mf2pt1 line 30. I see this recently in git: 86e8e6fb33dec1974104fe042c2a4a52d8ccda50 --- scripts/build/mf2pt1.pl --- index 62463d3..2119e7b 100644 @@ -1,4 +1,4 @@ -#!@PERL@ +#! /usr/bin/perl Could we not do this? At least until the end of this month? I mean, I doubt that we *actually* want to force the use of the system perl instead of the ./configure perl, but even if you do, please make that change later. (insert complaint about my desktop being 7000km away, hidden behind 2 separate ssh servers, and altogether a real pain to do anything GUB-ish with it. Don't worry; my social life and limited computing power will come to an end in 2 weeks) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB can't build fonts
I see this recently in git: 86e8e6fb33dec1974104fe042c2a4a52d8ccda50 --- scripts/build/mf2pt1.pl --- index 62463d3..2119e7b 100644 @@ -1,4 +1,4 @@ -#!@PERL@ +#! /usr/bin/perl Aah, this escaped my attention. I normally double-check all the patches I apply, sorry. Fixed in git. Could we not do this? At least until the end of this month? I mean, I doubt that we *actually* want to force the use of the system perl instead of the ./configure perl, but even if you do, please make that change later. BTW, it is normally a good idea if external source files like mf2pt1.pl are tagged as modified if they are changed. However, is the conversion from the original `/usr/bin/perl' to the necessary @PERL@ such a change? I tend to say `no', but... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 7: Developers as resources (accepted)
Hi Graham, I checked the html and typo alert... On 12/08/11 08:04, Graham Percival wrote: No comments last time, but this is just a confirmation of status quo proposal so I'm not concerned that I've missed any dissent. Officially accepted now. http://lilypond.org/~graham/gop/gop_7.html ** Proposal summary We shall treat developers (and contributors) as Independent volunteers: each person does whatever they want, whenever they want. We have busy careers and lives; we make no expectations of action from anybody (with the exception of the 6 people in “Meister” positions). Two people expressed interest in having some sort of “team” approach, where they would work collaboratively (possibly under the direction of somebody) on a problem, but that is not sufficient interest to make it worth organizing. ** Rationale I have historically been very vocal about treating developers at I have historically been very vocal about treating developers as (Stylistic note, you've changed from the we to I in the Proposal - it reads better to use one or the other - then you change back to Our policy below). Strangely the royal we sounds more collegiate and friendly. “independent volunteers”, but some recent discussions are making me wonder if that’s the best way to go. Our policy on this topic will influence many upcoming discussions. See above. ** Implementation notes None yet. Cheers, - Graham Cheers, Ian ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: script for auto-indenting .scm files.
Am Freitag, 12. August 2011, 02:44:11 schrieb Carl Sorensen: On 8/11/11 6:32 PM, Graham Percival gra...@percival-music.ca wrote: On Thu, Aug 11, 2011 at 06:28:09PM -0600, Carl Sorensen wrote: On 8/11/11 6:17 PM, Carl Sorensen c_soren...@byu.edu wrote: BTW, usage is ./scmindent.scm input-file output-file Could we get that in a comment at the top of the file ? Yep. Here it is, along with the change to /usr/bin/env guile. And I ran the file through itself to clean up some sloppy indenting I had left behind when modifying things from Racket to Guile. I think I'm really going to like having this, if we can get all the bugs worked out.. Do you know anything about the license? Apparently, the homepage of the original script is: http://evalwhen.com/scmindent/ But there is no mention of the license... Maybe we can ask Dorai to clarify this. All his other software at evalwhen.com is under a very permissive license: === cat COPYING Copyright © 2009 Dorai Sitaram. All rights reserved. Permission to distribute and use this work for any purpose is hereby granted provided this copyright notice is included in the copy. This work is provided as is, with no warranty of any kind. === And http://evalwhen.com/neuindex.html says: Here are some Scheme- and Common-Lisp-related items. Everything presented here is freely distributable and freely usable, and comes with no warranty of any kind. FS (as in GPL, LGPL) bundlers who require a standard license may use the LGPL to bundle any of these items. Others should find my CCOPYING file adequate. Unfortunately, the scmindent is not listed there, so we cannot be 1000% sure that this licensing should apply to it, too. 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
Fixes figuredBassCenterContinuations. (issue4868046)
Reviewers: ,
Message:
figuredBassCenterContinuations fails to merge continuation lines on if a
figure is composed of three or more figures.
This tiny patch fixes that.
Bertrand
Description:
Fixes figuredBassCenterContinuations.
Please review this at http://codereview.appspot.com/4868046/
Affected files:
M lily/figured-bass-engraver.cc
Index: lily/figured-bass-engraver.cc
diff --git a/lily/figured-bass-engraver.cc b/lily/figured-bass-engraver.cc
index
18b895660fa079c07523a31a1d4ea45802f3f0b3..24bf68db363eb88ae7ccd37a430f7759ddfbe5cf
100644
--- a/lily/figured-bass-engraver.cc
+++ b/lily/figured-bass-engraver.cc
@@ -217,19 +217,16 @@ Figured_bass_engraver::listen_bass_figure
(Stream_event *ev)
void
Figured_bass_engraver::center_continuations (vectorSpanner * const
consecutive_lines)
{
- if (consecutive_lines.size () == 2)
-{
- vectorGrob * left_figs;
- for (vsize j = consecutive_lines.size (); j--;)
-left_figs.push_back (consecutive_lines[j]-get_bound (LEFT));
+ vectorGrob * left_figs;
+ for (vsize j = consecutive_lines.size (); j--;)
+left_figs.push_back (consecutive_lines[j]-get_bound (LEFT));
- SCM ga = Grob_array::make_array ();
- unsmob_grob_array (ga)-set_array (left_figs);
+ SCM ga = Grob_array::make_array ();
+ unsmob_grob_array (ga)-set_array (left_figs);
- for (vsize j = consecutive_lines.size (); j--;)
-consecutive_lines[j]-set_object (figures,
- unsmob_grob_array
(ga)-smobbed_copy ());
-}
+ for (vsize j = consecutive_lines.size (); j--;)
+consecutive_lines[j]-set_object (figures,
+ unsmob_grob_array (ga)-smobbed_copy
());
}
void
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes figuredBassCenterContinuations. (issue4868046)
LGTM. That check has been there since time immemorial. I have sometimes wondered, too, but never bothered to change anything (since I don't use continuation combining). http://codereview.appspot.com/4868046/diff/4/lily/figured-bass-engraver.cc File lily/figured-bass-engraver.cc (left): http://codereview.appspot.com/4868046/diff/4/lily/figured-bass-engraver.cc#oldcode220 lily/figured-bass-engraver.cc:220: if (consecutive_lines.size () == 2) I always thought this was on purpose, so I didn't bother to change it. http://codereview.appspot.com/4868046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Moving away from make
I understand it's been discussed before, but I am wondering whether it's worth thinking the unthinkable and considering moving away from make. I know it's been used in loads of projects and is much loved, but actually, from a design perspective, it's appalling. If I was writing a make system from scratch, I would describe dependencies in data structures that are viewable and editable, and have a separate program that uses those structures to determine which files need making. Instead we have a fairly impenetrable system of makefiles that are created by (to me) a completely impenetrable autoconf system, and the only way of checking dependencies is to open all the makefiles (sourcefiles in effect) and read and understand each. It's rather as if one had to read the LilyPond .cpp files to understand how to change a piece of music. I've done 5 minutes research and have found SCons. I've not gone into any more depth with that yet. Does it seem worth looking into this, or something else, in more detail? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes figuredBassCenterContinuations. (issue4868046)
This was introduced in one of Han-Wen's commits : 7d7d33f3f1c6c45aaf3fd1e5c68b0b75a1be248d At that time there was no property to center figures, that's probably why Han-Wen added this condition (I know, this doesn't explain well its presence). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Moving away from make
Am Freitag, 12. August 2011, 15:53:56 schrieb Phil Holmes: I understand it's been discussed before, but I am wondering whether it's worth thinking the unthinkable and considering moving away from make. I suppose that everyone here would be glad if we could get away from make. It's just that our build system is really, really complicated and very complex, including dozens of different functionalities, different handling of the same file type depending on the directory, etc. I've done 5 minutes research and have found SCons. I've not gone into any more depth with that yet. Does it seem worth looking into this, or something else, in more detail? Jan did some work ok building lilypond with scons from 2004-2007. All traces of that have been removed 2009 by John in commit 24cd9ffc8b5a4ea03a29414eb7ae038a2d568d45. Another candidate would be cmake, which is used by the KDE project, so it is also able to handle large projects. I don't know, however, whether any of those is really able to provide the functionality that we really want/need (bin/doc/web/check/test-baseline builds, cross-compiling for GUB, etc.) Cheers, Reinhold PS: There was also some discussion on -devel to use waf, but IIRC that's lacking some vital features. PS2: When KDE switched to cmake, they initially favored SCons, but that was not up to the task of building KDE, so they finally ended up with cmake. See http://lwn.net/Articles/188693/ -- -- 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: Moving away from make
I understand it's been discussed before, but I am wondering whether it's worth thinking the unthinkable and considering moving away from make. Any simplification is welcomed, I think. I've done 5 minutes research and have found SCons. I've not gone into any more depth with that yet. Does it seem worth looking into this, or something else, in more detail? LilyPond had support for SCons some time ago, IIRC, but this has been dropped meanwhile. Other thinkable make alternatives are cmake and makepp. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fixing website translations
2011/7/30 Graham Percival gra...@percival-music.ca: I've been seeing these warnings for months: Processing web site: [cs] WARNING: Unable to find node 'Řešení potíží' in book usage. WARNING: Unable to find node 'Proč se mění skladba?' in book usage. Processing web site: [de] Processing web site: [es] Processing web site: [fr] Processing web site: [hu] Processing web site: [it] WARNING: Unable to find node 'Text editor support' in book usage. WARNING: Unable to find node 'Troubleshooting' in book usage. WARNING: Unable to find node 'Why does the syntax change?' in book usage. could somebody fix them? This message seems to have been largely ignored. I often see similar warnings on make doc, but not that few, rather hundredths of them. As the excerpt you post refers to [cs] and [it], I forward to Pavel and Federico. 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: fixing website translations
Il giorno ven, 12/08/2011 alle 16.49 +0200, Francisco Vila ha scritto: Processing web site: [it] WARNING: Unable to find node 'Text editor support' in book usage. WARNING: Unable to find node 'Troubleshooting' in book usage. WARNING: Unable to find node 'Why does the syntax change?' in book usage. could somebody fix them? This message seems to have been largely ignored. I often see similar warnings on make doc, but not that few, rather hundredths of them. As the excerpt you post refers to [cs] and [it], I forward to Pavel and Federico. I gave a quick look at 2.14.2 doc and couldn't find any broken link (from Usage or from Learning Manual). Except for a broken link in the appendix A of LM; but it is not related to the warning above. Well, I'm not good at finding the source of problems. I'm going in holidays, I won't be able to check it before the end of August. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fixing website translations
2011/8/12 Federico Bruni fedel...@gmail.com: Il giorno ven, 12/08/2011 alle 16.49 +0200, Francisco Vila ha scritto: Processing web site: [it] WARNING: Unable to find node 'Text editor support' in book usage. WARNING: Unable to find node 'Troubleshooting' in book usage. WARNING: Unable to find node 'Why does the syntax change?' in book usage. could somebody fix them? This message seems to have been largely ignored. I often see similar warnings on make doc, but not that few, rather hundredths of them. As the excerpt you post refers to [cs] and [it], I forward to Pavel and Federico. I gave a quick look at 2.14.2 doc and couldn't find any broken link (from Usage or from Learning Manual). Except for a broken link in the appendix A of LM; but it is not related to the warning above. Apparently, the 'Warning: unable to find x in book y' messages do not lead necessarily to broken links. IMO they are a side effect of old, unused code. Well, I'm not good at finding the source of problems. I'm going in holidays, I won't be able to check it before the end of August. Same for me. I still have 2/3 days available. -- 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: Moving away from make
On Fri, Aug 12, 2011 at 02:53:56PM +0100, Phil Holmes wrote: I understand it's been discussed before, but I am wondering whether it's worth thinking the unthinkable and considering moving away from make. Budget 2000 hours. That's not a typo. I don't think it provides a good cost/benefit ratio. Another problem is that every build system sucks. I've tried scons, waf, and cmake. Out of all of those, cmake is the least icky, but I hate that they invented Yet Another Scripting Language and don't let me do stuff with the simplicity and elegance of python. waf looks the nicest at first glance, but they don't support having files with the same name in the source tree and build tree, and I was appalled at their attitude (you shouldn't want to do that). The job of the build system is to do whatever we need; being told that we shouldn't want to view html documents, or that we should change our directory structure, does not impress me. Look for previous discussion about this in the archives, and if you're interested, you could try to talk some sense into the waf people. I know it's been used in loads of projects and is much loved, but actually, from a design perspective, it's appalling. Oh, make is a disaster. But the sad thing is that it's less of a disaster than those other major contenders. I've heard rumors of a google build system; if that's open-source, it might be a possible contender. But failing that, I think we're stuck. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Moving away from make
On 8/12/11 9:32 AM, Graham Percival gra...@percival-music.ca wrote: On Fri, Aug 12, 2011 at 02:53:56PM +0100, Phil Holmes wrote: I understand it's been discussed before, but I am wondering whether it's worth thinking the unthinkable and considering moving away from make. Budget 2000 hours. That's not a typo. I don't think it provides a good cost/benefit ratio. Another problem is that every build system sucks. I've tried scons, waf, and cmake. Out of all of those, cmake is the least icky, but I hate that they invented Yet Another Scripting Language and don't let me do stuff with the simplicity and elegance of python. waf looks the nicest at first glance, but they don't support having files with the same name in the source tree and build tree, and I was appalled at their attitude (you shouldn't want to do that). The job of the build system is to do whatever we need; being told that we shouldn't want to view html documents, or that we should change our directory structure, does not impress me. Look for previous discussion about this in the archives, and if you're interested, you could try to talk some sense into the waf people. I've been loosely following waf, and I think the restriction about the same name was in waf 1.5 but has been eliminated in 1.6, which is now out. I think it would be worth taking another look. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Moving away from make
On Fri, Aug 12, 2011 at 09:51:46AM -0600, Carl Sorensen wrote: On 8/12/11 9:32 AM, Graham Percival gra...@percival-music.ca wrote: waf looks the nicest at first glance, but they don't support having files with the same name in the source tree and build tree, I've been loosely following waf, and I think the restriction about the same name was in waf 1.5 but has been eliminated in 1.6, which is now out. I think it would be worth taking another look. Ok. Here you go: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=shortlog;h=refs/heads/dev/waf If you, or Phil, or anybody, can get some basic html documents happening in dev/waf, we can discuss it further. If it's actually possible, then ETA: 2 hours (not counting time learning how to switch branches, and not counting time spent reading the previous serious discussion in fall 2009) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Moving away from make
On Fri, Aug 12, 2011 at 10:53 AM, Phil Holmes em...@philholmes.net wrote: I understand it's been discussed before, but I am wondering whether it's worth thinking the unthinkable and considering moving away from make. I know it's been used in loads of projects and is much loved, but actually, from a design perspective, it's appalling. If I was writing a make system from scratch, Careful: many people have tried writing something better, and most attempts failed. It is not a trivial problem. I would describe dependencies in data structures that are viewable and editable, and have a separate program that uses those structures to determine which files need making. Instead we have a fairly impenetrable system of makefiles that are created by (to me) a completely impenetrable autoconf system, and the only way of checking dependencies is to open all the makefiles (sourcefiles in effect) and read and understand each. It's rather as if one had to read the LilyPond .cpp files to understand how to change a piece of music. We tried scons for a while, but it is extremely slow for incremental builds. Given that Cmake has a large following (examples include KDE and LLVM), I'd be comfortable with switching to that. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB cannot run tests
Is this a python 2.5+ism? GUB only uses python 2.4.
Please revert or rewrite in a python 2.4 manner.
-release-unstable/scripts/build/output-distance.py, line 317
return float(s) if 'nan' not in s else float(s.split('.')[0])
^
SyntaxError: invalid syntax
Traceback (most recent call last):
File test-lily/rsync-test.py, line 204, in ?
main ()
File test-lily/rsync-test.py, line 198, in main
compare_test_info (options)
File test-lily/rsync-test.py, line 169, in compare_test_info
compare_test_tarballs (options, versions_found[-3:])
File test-lily/rsync-test.py, line 119, in
compare_test_tarballs
system (cmd)
File test-lily/rsync-test.py, line 77, in system
raise Exception ('fail')
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fixing website translations
On Fri, Aug 12, 2011 at 05:27:53PM +0200, Francisco Vila wrote: 2011/8/12 Federico Bruni fedel...@gmail.com: Il giorno ven, 12/08/2011 alle 16.49 +0200, Francisco Vila ha scritto: Processing web site: [it] WARNING: Unable to find node 'Text editor support' in book usage. WARNING: Unable to find node 'Troubleshooting' in book usage. WARNING: Unable to find node 'Why does the syntax change?' in book usage. I gave a quick look at 2.14.2 doc and couldn't find any broken link (from Usage or from Learning Manual). Except for a broken link in the appendix A of LM; but it is not related to the warning above. Given that the documentation is different from the web site, I'm not convinced. Apparently, the 'Warning: unable to find x in book y' messages do not lead necessarily to broken links. IMO they are a side effect of old, unused code. FFS...! other languages have managed to fix these. For that matter, you don't even need to read the language to fix these problems! - we no longer have text editor support in Usage. What has that node been renamed to? Go update the name. - ditto for the other two. If you can't remember anything like this, then go look in the archives for the other 4 or 5 times I've complained about similar problems. Translators fixed those ones fairly quickly; either ask them how they did it, or look at the git history to find out how. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Commas in section headings
On Fri, Aug 12, 2011 at 01:41:29PM +0200, Werner LEMBERG wrote: Yes. I disallow commas in @section headings because IMO we should always have the @section heading match the @node -- doing otherwise is just begging for trouble down the road. OK. I'll fix the two that slipped through, although they look a little strange without the commas. I second that. IMHO it's a very bad idea that we have to limit correct use of English due to restrictions in a program (which are in this case even non-existent)! I thought this was going to be a new feature of the next version of texinfo. (do you have any clue when this will be? AFAIK the latest version is 4.13a from 2008) What I can imagine is that node names get automatically derived from section names. For example, a script might check that, stripping off all texinfo commands and other forbidden characters like the comma. sure, we already have scripts/auxiliar/node-menuify.py that could be expanded to handle this. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: script for auto-indenting .scm files.
On 8/12/11 5:39 AM, Reinhold Kainhofer reinh...@kainhofer.com wrote: Do you know anything about the license? Thanks for this reminder. I've renamed the file to guileindent.scm, making it clear that it's a derivative work, rather than just a copy. I've sent an email to Dorai asking if it's OK with him to put the derivative work under a GPL 3 or newer license. I'll work it out and let you know what I find. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Can Hairpin support line-spanner-interface?
Hey guys, Could the Hairpin grob be changed to support the line-spanner-interface? If not, is there a way to fine-tune the left- and right-endpoints of Hairpins independently from the NoteColumns? Does Hairpin inherit the X-extent property from DynamicLineSpanner? If so, how does a user adjust something that is hard-coded? I'm afraid my recent absence from developer-land is making me look more like a casual user, but maybe that's a good thing: I'm seeing how confusing some things really must be for the novice. Thanks. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Commas in section headings
I second that. IMHO it's a very bad idea that we have to limit correct use of English due to restrictions in a program (which are in this case even non-existent)! I thought this was going to be a new feature of the next version of texinfo. Commas in section names? No, this was always possible. Commas in node names are still forbidden. (do you have any clue when this will be? AFAIK the latest version is 4.13a from 2008) Don't expect a release soon. It's still not really compatible to the good old makeinfo binary (and additionally at least 20 times slower). In particular, it's not possible yet to build lilypond's documentation with the CVS version of the makeinfo replacement, AFAIK. Do you want to try? It's probably worth to report all bugs to the texinfo people. What I can imagine is that node names get automatically derived from section names. For example, a script might check that, stripping off all texinfo commands and other forbidden characters like the comma. sure, we already have scripts/auxiliar/node-menuify.py that could be expanded to handle this. Aah, an almost completely undocumented script, lacking any source comments also :-) Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
lexer.ll: remove unused patterns, avoid backing up (issue4871041)
Reviewers: ,
Message:
While we are cleaning up warnings, here is a patch for the lexer
warnings.
This is all code cleanup, no behavior change, so I don't think a tracker
issue is appropriate. Regression tests are unchanged.
http://codereview.appspot.com/4871041/diff/3001/lily/lexer.ll
File lily/lexer.ll (right):
http://codereview.appspot.com/4871041/diff/3001/lily/lexer.ll#newcode23
lily/lexer.ll:23: backup rules
This comment instruction was violated, so this patch brings the code
back in compliance, but it is awkward.
Why are we avoiding backup states?
http://codereview.appspot.com/4871041/diff/3001/lily/lexer.ll#newcode265
lily/lexer.ll:265: version{ANY_CHAR}{
Include \n in the pattern, to avoid warning about fall back to the
default match. (The \n should never match, because the rules that leave
us in version never leave \n on the input stream.)
http://codereview.appspot.com/4871041/diff/3001/lily/lexer.ll#newcode309
lily/lexer.ll:309: incl\\{BLACK}*{WHITE}? { /* got the include
identifier */
Accept \include fooEOF without backing up
http://codereview.appspot.com/4871041/diff/3001/lily/lexer.ll#newcode621
lily/lexer.ll:621: if (YY_START == longcomment)
Error reporting moved from line 287, to avoid warning for two matching
rules for EOF
http://codereview.appspot.com/4871041/diff/3001/lily/lexer.ll#newcode653
lily/lexer.ll:653: {REAL}|-{UNSIGNED} {
I'll add comment // backup rule, -123 versus -123.
Description:
lexer.ll: remove unused patterns, avoid backing up
This removes the rest of the warnings from Lilypond `make bin`
... except for a type conversion warning in out/parser.cc generated
by Bison -- I don't see a way to remove that warning.
Please review this at http://codereview.appspot.com/4871041/
Affected files:
M lily/lexer.ll
Index: lily/lexer.ll
diff --git a/lily/lexer.ll b/lily/lexer.ll
index
83a7940b6938dc634083fe9936ee389635713412..bd3a2abb6915f3c6e564bc7db10df86ed4842b0e
100644
--- a/lily/lexer.ll
+++ b/lily/lexer.ll
@@ -135,7 +135,6 @@ PUNCT [?!:'`]
ACCENT \\[`'^]
NATIONAL [\001-\006\021-\027\031\036]
TEX{AA}|-|{PUNCT}|{ACCENT}|{NATIONAL}
-WORD {A}{AN}*
DASHED_WORD{A}({AN}|-)*
DASHED_KEY_WORD\\{DASHED_WORD}
@@ -148,7 +147,6 @@ E_UNSIGNED \\{N}+
FRACTION {N}+\/{N}+
INT-?{UNSIGNED}
REAL ({INT}\.{N}*)|(-?\.{N}+)
-KEYWORD\\{WORD}
WHITE [ \n\t\f\r]
HORIZONTALWHITE[ \t]
BLACK [^ \n\t\f\r]
@@ -165,7 +163,7 @@ BOM_UTF8\357\273\277
*\r{
- // windows-suck-suck-suck
+ // swallow and ignore carriage returns
}
extratoken{ANY_CHAR} {
@@ -264,15 +262,15 @@ BOM_UTF8 \357\273\277
this-here_input ().get_source_file ()-set_line (here_input ().start (),
i);
}
-version. {
+version{ANY_CHAR} {
LexerError (_ (quoted string expected after \\version).c_str ());
yy_pop_state ();
}
-sourcefilename.{
+sourcefilename{ANY_CHAR} {
LexerError (_ (quoted string expected after \\sourcefilename).c_str
());
yy_pop_state ();
}
-sourcefileline.{
+sourcefileline{ANY_CHAR} {
LexerError (_ (integer expected after \\sourcefileline).c_str ());
yy_pop_state ();
}
@@ -285,12 +283,6 @@ BOM_UTF8 \357\273\277
%+} {
yy_pop_state ();
}
- EOF {
- LexerError (_ (EOF found inside a comment).c_str ());
- is_main_input_ = false; // should be safe , can't have \include in
--safe.
- if (! close_input ())
- yyterminate (); // can't move this, since it actually rets a
YY_NULL
- }
}
@@ -314,7 +306,7 @@ BOM_UTF8\357\273\277
new_input (s, sources_);
yy_pop_state ();
}
-incl\\{BLACK}*{WHITE} { /* got the include identifier */
+incl\\{BLACK}*{WHITE}? { /* got the include identifier */
string s = YYText () + 1;
strip_trailing_white (s);
if (s.length () (s[s.length () - 1] == ';'))
@@ -333,7 +325,7 @@ BOM_UTF8\357\273\277
scm_display (sid, err);
}
}
-incl\[^]* { // backup rule
+incl,version,sourcefilename\[^]* { // backup rule
error (_ (end quote missing));
exit (1);
}
@@ -420,7 +412,13 @@ BOM_UTF8 \357\273\277
yylval.scm = scan_fraction (YYText ());
return FRACTION;
}
-
+ {UNSIGNED}\/{
+ // handle two tokens in 5/ without using backup states
+ yylval.i = String_convert::dec2int (string (YYText ()));
+ unput ('/');
+ char_count_stack_.back ()--;
+ return UNSIGNED;
+ }
{DIGIT} {
yylval.i = String_convert::dec2int (string (YYText ()));
return DIGIT;
@@ -465,6 +463,13 @@ BOM_UTF8 \357\273\277
yylval.scm = scan_fraction (YYText ());
Re: Prevents nested tuplets from colliding. (issue4808082)
On Mon, Aug 8, 2011 at 3:21 PM, mts...@gmail.com wrote: Reviewers: , Message: This fixes Issue 509 and passes regtests. Cheers, MS Description: Prevents nested tuplets from colliding. Please review this at http://codereview.appspot.com/**4808082/http://codereview.appspot.com/4808082/ Affected files: M input/regression/tuplet-nest.**ly http://tuplet-nest.ly M lily/tuplet-bracket.cc M scm/define-grob-properties.scm M scm/define-grobs.scm This is very much appreciated, btw. :-) Trevor. -- Trevor Bača trevorb...@gmail.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Commas in section headings
Graham Percival wrote Friday, August 12, 2011 5:09 PM On Fri, Aug 12, 2011 at 01:41:29PM +0200, Werner LEMBERG wrote: What I can imagine is that node names get automatically derived from section names. For example, a script might check that, stripping off all texinfo commands and other forbidden characters like the comma. sure, we already have scripts/auxiliar/node-menuify.py that could be expanded to handle this. AFAICS that script simply generates the menus from the node names. It doesn't touch section names. I don't see what difficulties arise from having section names that differ slightly from the node name, other than maybe a doc editor looking at the section name rather than the node name when writing a cross-reference. This would soon be picked up as a broken ref. Unless there's a sound reason for this restriction I'd rather go back to permitting commas in section names. Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3829 - Release Date: 08/12/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Commas in section headings
On Fri, Aug 12, 2011 at 07:01:14PM +0200, Werner LEMBERG wrote: (do you have any clue when this will be? AFAIK the latest version is 4.13a from 2008) Don't expect a release soon. It's still not really compatible to the good old makeinfo binary (and additionally at least 20 times slower). In particular, it's not possible yet to build lilypond's documentation with the CVS version of the makeinfo replacement, AFAIK. Do you want to try? It's probably worth to report all bugs to the texinfo people. I agree that it would be good to do, but I'm already seriously thinking about cancelling next week's GOP-PROP due to not enough time. Until both GOP and GLISS are over, I won't have any time for anything fun like documentation. sure, we already have scripts/auxiliar/node-menuify.py that could be expanded to handle this. Aah, an almost completely undocumented script, lacking any source comments also :-) Welcome to lilypond development. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Commas in section headings
On Fri, Aug 12, 2011 at 10:22:49PM +0100, Trevor Daniels wrote:
Graham Percival wrote Friday, August 12, 2011 5:09 PM
On Fri, Aug 12, 2011 at 01:41:29PM +0200, Werner LEMBERG wrote:
What I can imagine is that node names get automatically derived
from
section names. For example, a script might check that,
stripping off
all texinfo commands and other forbidden characters like the
comma.
scripts/auxiliar/node-menuify.py
AFAICS that script simply generates the menus
from the node names. It doesn't touch section
names.
Yes, but I could imagine that script regenerating node names from
section names, then using those new node names to generate the
menus.
I don't see what difficulties arise from having
section names that differ slightly from the node
name, other than maybe a doc editor looking at
the section name rather than the node name when
writing a cross-reference.
Because some new doc editor -- quite possibly with relatively poor
English skills -- will write something new and @ref{} the section
name they see in the HMTL docs. Why would they bother checking
for an obscure rule about removing commas in the node name? (for
that matter, why should they know or care that the node name can
differ from the section name?)
This would soon be picked up as a broken ref.
How often do people check for those? (a broken @rlearning{}, say,
rather than a broken @ref{})
I think I've done it 3 or 4 times in the past eight years. I'd be
surprised if James knows what we're talking about.
Unless there's a sound reason for this restriction
I'd rather go back to permitting commas in section
names.
It adds extra confusion for casual doc editors, and I don't think
we should be making it harder for contributors. Besides, it's not
hard to describe a section without using commas.
I really don't see a good confusion-vs-niceness ratio for the use
of commas in section names. Making a new section name is much
less rare than adding a reference, so let's keep the confusion
isolated to that case.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Commas in section headings
Graham Percival wrote Friday, August 12, 2011 10:44 PM
On Fri, Aug 12, 2011 at 10:22:49PM +0100, Trevor Daniels wrote:
Graham Percival wrote Friday, August 12, 2011 5:09 PM
I don't see what difficulties arise from having
section names that differ slightly from the node
name, other than maybe a doc editor looking at
the section name rather than the node name when
writing a cross-reference.
Because some new doc editor -- quite possibly with relatively poor
English skills -- will write something new and @ref{} the section
name they see in the HMTL docs. Why would they bother checking
for an obscure rule about removing commas in the node name?
In that case I'll not bother adding an obscure
rule to the CG about removing commas in section
names. Why would anyone bother reading it?
This would soon be picked up as a broken ref.
How often do people check for those? (a broken @rlearning{}, say,
rather than a broken @ref{})
I think I've done it 3 or 4 times in the past eight years. I'd be
surprised if James knows what we're talking about.
I check all the English docs every time I edit
a file. It's in my script. I'd expect every
doc editor to use it.
See scripts/auxiliar/ref_check.py
This found the broken ref that started this discussion
when I checked one of James' recent (unrelated) patches.
(It wasn't broken because of the commas, it was
because James/Mark had changed the node and
section names without changing the ref.)
Unless there's a sound reason for this restriction
I'd rather go back to permitting commas in section
names.
It adds extra confusion for casual doc editors, and I don't think
we should be making it harder for contributors. Besides, it's not
hard to describe a section without using commas.
What would you suggest for
Creating titles, headers, and footers
Custom headers, footers, and titles
?
I really don't see a good confusion-vs-niceness ratio for the use
of commas in section names. Making a new section name is much
less rare than adding a reference, so let's keep the confusion
isolated to that case.
Well, I disagree (not for the first time)
but you're the boss :)
(BTW, I believe there are commas in some of the
other language docs.)
Trevor
-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1392 / Virus Database: 1520/3829 - Release Date: 08/12/11
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
FW: Derivative work of scmindent.scm
Here is the permission from Dorai to distribute as GPL 3+. Thanks, Carl -- Forwarded Message From: Dorai Sitaram ds26...@yahoo.com Reply-To: Dorai Sitaram ds26...@yahoo.com Date: Fri, 12 Aug 2011 17:59:02 -0600 To: Carl Sorensen c_soren...@byu.edu Conversation: Derivative work of scmindent.scm Subject: Re: Derivative work of scmindent.scm Hi Carl! Yes, you may distribute your derivative under any license you choose. scmindent.scm may be considered LGPL as the home page says. best regards, --dorai - Original Message - From: Carl Sorensen c_soren...@byu.edu To: ds26...@yahoo.com ds26...@yahoo.com Cc: Sent: Friday, August 12, 2011 12:07 PM Subject: Derivative work of scmindent.scm Dear Dorai, I have made a derivative work of scmindent.scm, called guileindent.scm. It's modified to use guile, rather than Racket. I would like to distribute this as part of the GNU/LilyPond distribution. We are distributing under a GPL 3 or newer license. Would distributing this derivative work under GPL3 or newer match your license for scmindent.scm? There is no license information in the file itself; the COPYING file at evalwhen.com shows a very permissive license. (use as long as the copyright notice is included). The neuindex.html page says we can use LGPL to bundle. Anyway, I've attached the file I'd like to use for distribution with LilyPond. If you would let me know whether you approve, I'd be grateful. Thanks, Carl Sorensen -- End of Forwarded Message ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable decision)
Graham Percival graham at percival-music.ca writes: We will make a “Type-Critical”; a new stable release will only occur if there are 0 type-Critical issues. [...] it also attracts the attention of potential contributors, so we should avoid having any glaring problems which would stop somebody from contributing and turn them away – we do not want to put our “stamp of approval” on something which might cost us potential contributors. [...] * anything which stops contributors from helping out Trevor Daniels t.daniels at treda.co.uk writes: I agree this is important, but I don't see why it should prevent a new release per se. Issue 1809 is an interesting test of this policy. `make test` sometimes crashes for some programmers, making it very hard for them to contribute, but it crashes in the Guile garbage collection, so we might be powerless to resolve the issue. Probably this will stay critical until we fix it (by some miracle) work around it assign blame, and push the bug report, upstream, or give up ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable decision)
Keith OHara k-ohara5...@oco.net writes: Graham Percival graham at percival-music.ca writes: We will make a “Type-Critical”; a new stable release will only occur if there are 0 type-Critical issues. [...] it also attracts the attention of potential contributors, so we should avoid having any glaring problems which would stop somebody from contributing and turn them away – we do not want to put our “stamp of approval” on something which might cost us potential contributors. [...] * anything which stops contributors from helping out Trevor Daniels t.daniels at treda.co.uk writes: I agree this is important, but I don't see why it should prevent a new release per se. Issue 1809 is an interesting test of this policy. `make test` sometimes crashes for some programmers, making it very hard for them to contribute, but it crashes in the Guile garbage collection, so we might be powerless to resolve the issue. It crashes because the internal garbage collector data structures have been clobbered. Which is likely due to some Lilypond code problem (like data available too early for collection). So it is likely that we are not powerless to resolve the issue, but since the crash is happening at a point rather remote from the likely bug and is quite sensitive to the memory layout of the code, it is really hard to track down. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
