Re: GOP-PROP 11: git repositories (probable decision)
LGTM Trevor - Original Message - From: "Graham Percival" To: Sent: Wednesday, September 14, 2011 11:33 PM Subject: GOP-PROP 11: git repositories (probable decision) I've made a few clarifications to the original proposal, but nothing substantial is changed. http://lilypond.org/~graham/gop/gop_11.html ** Proposal summary Our source code hosting is confused: some branches of lilypond savannah are confusing and should removed, while other parts of our source code aren’t in a repository at all! I propose: * Reserve the savannah lilypond.git repository for logical branches of master. * Create separate savannah lilypond/foo.git repositories for other material, notably lilypad-macos, lilypad-windows, archive-web. * We add an additional website-media repository for material such as our pdf publications (e.g., Erik’s thesis, Han-Wen and Jan’s papers), the compiled ly-examples/, and generated pictures/. * Since GUB is used by other projects, it will remain in its current repository on github. ** Rationale Most of the open-source world abandoned keeping source code primarily in tarballs about 10 years ago. But as far as I know, the official version of the windows lilypad application is a tarball on http://lilypond.org/download/gub-sources/lilypad/! (thankfully Patrick has a mirror of them in http://github.com/pnorcks just in case something bad happens). On the other side of things, some material in the savannah lilypond repository are misleading. We don’t use the web branch any more; that material is part of master. The CG doesn’t point people at the web branch, but it’s still a tempting target for well-meaning contributors to work on, and we’ve had 2 or 3 people send us beautiful (yet heartbreaking) patches for that completely obsolete branch. I don’t want this to happen again. Another hope is that if we clean up our repositories, we may be able to encourage more use of branching. ** Proposal details I think the “remove non-logical branches” is fairly clear. The main repository would remain as: git://git.sv.gnu.org/lilypond.git I can easily get additional repositories created, namely: git://git.sv.gnu.org/lilypond/lilypad-macos.git git://git.sv.gnu.org/lilypond/lilypad-windows.git git://git.sv.gnu.org/lilypond/website-media.git git://git.sv.gnu.org/lilypond/archive.git I think that having an official place for the pdfs will not be a problem. Some people may disagree with having the compiled ly-examples/ and pictures/, though. I think this is warranted due to the pain that uploading these manually causes. I only do it manually 2 or 3 times a year; keeping them in a separate repository would allow anybody to push an update. There’s no security concerns with such an upload of pdf and pngs. Also, having this media stored somewhere would make it significantly easier for relative linux newcomers to start working on the “full” website. The ikebana branch will be migrating to Han-Wen’s github account. ** Unchanged branches master release/unstable lilypond/translation stable/* dev/* cvs/master tarball/master The last two aren’t particularly relevant these days, but they don’t do any harm. ** Other information Old info here: http://code.google.com/p/lilypond/issues/detail?id=980 We will not attempt to standardize on directory locations; in fact, we will remove (most) references to $HOME/lilypond-git. Instead, we will use $LILYPOND_GIT and possibly $LILYPOND_WEBSITE_MEDIA. http://code.google.com/p/lilypond/issues/detail?id=1236 Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 10: scheme indentation
I'd rather interpret no action as tacit approval. As your electronics colleague once said, "Just do it." :) Trevor - Original Message - From: "Graham Percival" To: Sent: Wednesday, September 14, 2011 11:31 PM Subject: GOP-PROP 10: scheme indentation There's been no action on this for a few weeks. I'm starting to wonder if we should abandon this proposal and try bringing it back in a few months. http://lilypond.org/~graham/gop/gop_10.html ** Proposal summary Speaking academically, scheme code style is a “solved problem”. Let’s pick one of the existing solutions, and let a computer deal with this. Humans should not waste their time, energy, and creativity manually adding tabs or spaces to source code. The script will be scripts/auxiliar/fix-scheme.sh ** Rationale New contributors sometimes struggle to follow our indentation and code style – this is especially difficult when parts of our existing source code doesn’t have a consistent style. This is problematic... we want new contributors to be struggling with the lilypond architecture, not playing games in their text editors! Proposal details Use: http://codereview.appspot.com/4896043/ I will auto-indent all ‘.scm’ files in the git tree on 2011 Oct 01. ** Implementation notes The C++ change went quite well, and we have far fewer outstanding patches for scheme code. No problems anticipated. We will not manually specify what the scheme files should look like as part of this proposal; just run that script on your files. Interested parties may add an unofficial description of the scheme indentation to the CG if they are interested. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 10: scheme indentation
On 15 Sep 2011 00:31, "Carl Sorensen" wrote: > > On 9/14/11 4:31 PM, "Graham Percival" wrote: > > > There's been no action on this for a few weeks. I'm starting to > > wonder if we should abandon this proposal and try bringing it back > > in a few months. > > Why? > > The only outstanding issue is that the else indentation is not the same as > Emacs, but Neil hasn't responded to the setting that he would like. I don't mind the else indentation, but there are a few other issues (I mentioned them briefly in another post). I'll post a more thorough review later. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Uses langdefs.py to create language list for create-weblinks-itexi.py (issue 4951047)
- Original Message - From: To: ; Cc: ; Sent: Wednesday, September 14, 2011 8:49 PM Subject: Re: Uses langdefs.py to create language list for create-weblinks-itexi.py (issue 4951047) LGTM, go ahead and push. http://codereview.appspot.com/4951047/ Pushed as a04d1cb5153717523cdafe23faeb2166571603da -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Implement optional music function arguments (issue 5023044)
Regtest is missing (doesn't need to be a useful example, it just needs
to break if that functionality ever breaks!)
Also, does this work for cases like
\relative c' c
Also, I suppose things like
\myfunction [optional-pitch] pitch music
does not work due to the lookahead not looking too far, right?
http://codereview.appspot.com/5023044/diff/2001/lily/parser.yy
File lily/parser.yy (right):
http://codereview.appspot.com/5023044/diff/2001/lily/parser.yy#newcode1184
lily/parser.yy:1184: | EXPECT_MARKUP EXPECT_OPTIONAL function_arglist
function_markup_argument {
Can't we shorten this long list of alternatives somehow?
http://codereview.appspot.com/5023044/diff/2001/scm/music-functions.scm
File scm/music-functions.scm (right):
http://codereview.appspot.com/5023044/diff/2001/scm/music-functions.scm#newcode762
scm/music-functions.scm:762: "Helper macro for `ly:make-music-function'.
It's also a helper for ly:make-scheme-function...
http://codereview.appspot.com/5023044/diff/2001/scm/music-functions.scm#newcode792
scm/music-functions.scm:792: "
Here you should add a description how optional arguments are given! In
particular, the argX-type? is no longer valid in general.
http://codereview.appspot.com/5023044/diff/2001/scm/music-functions.scm#newcode801
scm/music-functions.scm:801: "
Same goes here.
http://codereview.appspot.com/5023044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 10: scheme indentation
On 15/09/11 09:19, Trevor Daniels wrote: > I'd rather interpret no action as tacit approval. As your > electronics colleague once said, "Just do it." :) > > Trevor > 1+ Cheers, Ian ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 10: scheme indentation
Am Thursday, 15. September 2011, 14:47:30 schrieb Ian Hulin: > On 15/09/11 09:19, Trevor Daniels wrote: > > I'd rather interpret no action as tacit approval. As your > > electronics colleague once said, "Just do it." :) > > > > Trevor > > 1+ +1 Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement optional music function arguments (issue 5023044)
Reviewers: Reinhold,
Message:
On 2011/09/15 10:45:11, Reinhold wrote:
Also, does this work for cases like
\relative c' c
Yes, it does. Parameters following non-present optional parameters are
more restricted than those following present optional parameters.
While you can't write \myrelative c' instead of \myrelative { c' },
\myrelative c' c instead of \myrelative c' { c } works just fine since
you can't confuse it with \myrelative { c' } c.
Also, I suppose things like
\myfunction [optional-pitch] pitch music
does not work due to the lookahead not looking too far, right?
Correct. One could try to squeeze appropriate patterns into the syntax
as well, but the current Scheme requires already O(n^2) rules, and
extending the patterns to cover the generalizations of your example
would require O(n^3) rules. Too much pain for the gain.
Description:
Implement optional music function arguments
This allows, say, to define a substitute for \relative that has an
optional pitch argument defaulting to f rather than c.
pitch = #(define-scheme-function (parser location pitch)
(ly:pitch?) pitch)
myrelative = #(define-music-function (parser location pitch music)
((ly:pitch? #{ \pitch f #}) ly:music?)
#{ \relative $pitch $music #})
\relative c' {c' d e f g a b c}
\relative {c' d e f g a b c}
\myrelative c' {c' d e f g a b c}
\myrelative {c' d e f g a b c}
The first uploaded patch is a separate commit with the following
description:
lexer.ll: Allow push_extra_token to take a Scheme value as well.
Please review this at http://codereview.appspot.com/5023044/
Affected files:
M lily/include/lily-lexer.hh
M lily/lexer.ll
M lily/lily-lexer.cc
M lily/parser.yy
M scm/document-identifiers.scm
M scm/lily.scm
M scm/music-functions.scm
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement optional music function arguments (issue 5023044)
http://codereview.appspot.com/5023044/diff/2001/lily/parser.yy
File lily/parser.yy (right):
http://codereview.appspot.com/5023044/diff/2001/lily/parser.yy#newcode1184
lily/parser.yy:1184: | EXPECT_MARKUP EXPECT_OPTIONAL function_arglist
function_markup_argument {
On 2011/09/15 10:45:11, Reinhold wrote:
Can't we shorten this long list of alternatives somehow?
Not really. You need to combine each argument type x with a list of
argument types different from x. So each of the n(n-1) combinations has
no constituents shared with the other constituents. You could factor
out parts of that list. Then you have n different factors for which you
need a good fitting name each. And the amount of rule lines increases
even more, and there is no real advantage in readability because there
is not much of a system except you need to cover the O(n^2) cases.
This is definitely the ugly part of the patch. It will not
significantly affect performance, thanks to Bison and LALR(1), but it is
a headache to read. And I see no way around it.
http://codereview.appspot.com/5023044/diff/2001/scm/music-functions.scm
File scm/music-functions.scm (right):
http://codereview.appspot.com/5023044/diff/2001/scm/music-functions.scm#newcode762
scm/music-functions.scm:762: "Helper macro for `ly:make-music-function'.
On 2011/09/15 10:45:11, Reinhold wrote:
It's also a helper for ly:make-scheme-function...
There is no ly:make-scheme-function, so it can't help it. All syntactic
functions are created with ly:make-music-function.
While I have some leaning towards define-lily-function (as it takes Lily
arguments), this is not actually anything introduced by this patch
(rather part of the define-scheme-function patch series). So if you
want different names/doc strings, you should file them as a separate
issue.
http://codereview.appspot.com/5023044/diff/2001/scm/music-functions.scm#newcode792
scm/music-functions.scm:792: "
On 2011/09/15 10:45:11, Reinhold wrote:
Here you should add a description how optional arguments are given! In
particular, the argX-type? is no longer valid in general.
Yes to the first, not quite to the second. The argX-type? remains
valid. Anybody have a good suggestion what to name the parameters in
the DOC string? They can be either predicate? or (predicate? default)
for an optional parameter taking a default value. The default is
evaluated at definition time, so using #{...#} and similar in the
defaulsts does not impact execution time.
http://codereview.appspot.com/5023044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add support for custom ledger positions, using two new staff-symbol properties (issue 4974075)
On 2011/09/14 22:12:22, Neil Puttock wrote:
http://codereview.appspot.com/4974075/diff/8001/input/regression/staff-ledger-positions.ly
File input/regression/staff-ledger-positions.ly (right):
http://codereview.appspot.com/4974075/diff/8001/input/regression/staff-ledger-positions.ly#newcode4
input/regression/staff-ledger-positions.ly:4: by setting the
@code{ledger-positions} property of the StaffSymbol.
wrap around (no space at start of lines)
http://codereview.appspot.com/4974075/diff/8001/input/regression/staff-ledger-positions.ly#newcode5
input/regression/staff-ledger-positions.ly:5: The given pattern is
repeated.
Bracketed groups are always shown together:
two spaces follow a full stop
http://codereview.appspot.com/4974075/diff/8001/input/regression/staff-ledger-positions.ly#newcode11
input/regression/staff-ledger-positions.ly:11: \version "2.15.11"
2.15.12
http://codereview.appspot.com/4974075/diff/8001/input/regression/staff-ledger-positions.ly#newcode14
input/regression/staff-ledger-positions.ly:14: \new Staff \relative c'
{
c' {
http://codereview.appspot.com/4974075/diff/8001/input/regression/staff-ledger-positions.ly#newcode15
input/regression/staff-ledger-positions.ly:15: \override
Staff.StaffSymbol
#'line-positions = #'( -5 -2 -1 2 5 6 )
(-5 -2 -1 2 5 6)
http://codereview.appspot.com/4974075/diff/8001/input/regression/staff-ledger-positions.ly#newcode16
input/regression/staff-ledger-positions.ly:16: \override
Staff.StaffSymbol
#'ledger-positions = #'( -5 (-2 -1) 2 )
(-5 (-2 -1) 2)
http://codereview.appspot.com/4974075/diff/8001/input/regression/staff-ledger-positions.ly#newcode18
input/regression/staff-ledger-positions.ly:18: g, c e b' c'' e g
g,4
http://codereview.appspot.com/4974075/diff/8001/input/regression/staff-ledger-positions.ly#newcode20
input/regression/staff-ledger-positions.ly:20:
remove extra newlines
http://codereview.appspot.com/4974075/diff/8001/lily/staff-symbol.cc
File lily/staff-symbol.cc (right):
http://codereview.appspot.com/4974075/diff/8001/lily/staff-symbol.cc#newcode105
lily/staff-symbol.cc:105: int line_count = scm_to_int (scm_length
(line_positions));
scm_ilength (line_positions)
http://codereview.appspot.com/4974075/diff/8001/lily/staff-symbol.cc#newcode243
lily/staff-symbol.cc:243: return scm_to_int (scm_length
(line_positions));
scm_ilength (line_positions)
http://codereview.appspot.com/4974075/diff/8001/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):
http://codereview.appspot.com/4974075/diff/8001/scm/define-grob-properties.scm#newcode501
scm/define-grob-properties.scm:501: (ledger-extra ,number? "Extra
distance from
staff line to draw ledger
,ly:dimension?
http://codereview.appspot.com/4974075/diff/8001/scm/define-grob-properties.scm#newcode508
scm/define-grob-properties.scm:508: of ledger lines. Bracketed groups
are always
shown together.")
two spaces after `lines.'
Done, typical beginner imperfections, thanks for pointing out.
http://codereview.appspot.com/4974075/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Introduce a maximum depth for markup evaluation (issue 5032041)
Reviewers: ,
Message:
Please review!
Description:
Introduce a maximum depth for markup evaluation
This will fix cases where a markup function calls itself (or other
functions) recursively with different arguments.
Please review this at http://codereview.appspot.com/5032041/
Affected files:
A input/regression/markup-depth-non-terminating.ly
M lily/text-interface.cc
M scm/lily.scm
Index: input/regression/markup-depth-non-terminating.ly
diff --git a/input/regression/markup-depth-non-terminating.ly
b/input/regression/markup-depth-non-terminating.ly
new file mode 100644
index
..52e0f70ee02aa78a80614c3f8d7a6b73628be09b
--- /dev/null
+++ b/input/regression/markup-depth-non-terminating.ly
@@ -0,0 +1,15 @@
+\version "2.15.12"
+#(ly:set-option 'warning-as-error #f)
+
+\header {
+ texidoc = "Markups have a maximum depth to prevent non-termination."
+
+}
+
+% A simple markup function that calls itself and increases its argument, so
+% it will grow forever, unless we terminate it.
+#(define-markup-command (recursive-explosion layout props nr)
+ (number?)
+ (interpret-markup layout props (make-recursive-explosion-markup (+ nr
1
+
+\markup { Test: \recursive-explosion #1 }
Index: lily/text-interface.cc
diff --git a/lily/text-interface.cc b/lily/text-interface.cc
index
7c9e8f26bbc975136acecfd730b01793c01c960a..92a3c9d8d7cd347649c5f26947aa6cac4865dc7e
100644
--- a/lily/text-interface.cc
+++ b/lily/text-interface.cc
@@ -28,6 +28,7 @@
#include "modified-font-metric.hh"
#include "output-def.hh"
#include "pango-font.hh"
+#include "program-option.hh"
#include "international.hh"
#include "warn.hh"
@@ -119,6 +120,20 @@ Text_interface::interpret_markup (SCM layout_smob, SCM
props, SCM markup)
}
}
+ /* Check for non-terminating markups, e.g. recursive calls with
+ * changing arguments */
+ SCM opt_depth = ly_get_option (ly_symbol2scm ("max-markup-depth"));
+ size_t max_depth = robust_scm2int(opt_depth, 1024);
+ if (depth > max_depth)
+{
+ string name = ly_symbol2string (scm_procedure_name (func));
+ string argstring = "TODO";
+ non_fatal_error (_f("Markup depth exceeds maximal value of %d; "
+ "Markup: %s, arguments: %s",
+ max_depth, name.c_str (), argstring.c_str
()));
+ return Stencil().smobbed_copy ();
+}
+
encountered_markups.push_back (markup);
SCM retval = scm_apply_2 (func, layout_smob, props, args);
encountered_markups.pop_back ();
Index: scm/lily.scm
diff --git a/scm/lily.scm b/scm/lily.scm
index
bbea5afab996462f9eedb9a6ee3613f65581ce5a..105a8b3b670156fc41cab3199db6a13c887045d0
100644
--- a/scm/lily.scm
+++ b/scm/lily.scm
@@ -120,6 +120,9 @@ jobs.")
(log-file #f
"If string FOO is given as argument, redirect
output to log file `FOO.log'.")
+(max-markup-depth 1024
+"Maximum depth for the markup tree. If a markup has more levels, assume
that
+it will not terminate at all and print out a warning, but continue
processing.")
(midi-extension ,(if (eq? PLATFORM 'windows)
"mid"
"midi")
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement optional music function arguments (issue 5023044)
http://codereview.appspot.com/5023044/diff/2001/scm/music-functions.scm File scm/music-functions.scm (right): http://codereview.appspot.com/5023044/diff/2001/scm/music-functions.scm#newcode792 scm/music-functions.scm:792: " On 2011/09/15 10:45:11, Reinhold wrote: Here you should add a description how optional arguments are given! In particular, the argX-type? is no longer valid in general. Done http://codereview.appspot.com/5023044/diff/2001/scm/music-functions.scm#newcode801 scm/music-functions.scm:801: " On 2011/09/15 10:45:11, Reinhold wrote: Same goes here. Done http://codereview.appspot.com/5023044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 10: scheme indentation
On Wed, Sep 14, 2011 at 05:30:35PM -0600, Carl Sorensen wrote: > On 9/14/11 4:31 PM, "Graham Percival" wrote: > > > There's been no action on this for a few weeks. I'm starting to > > wonder if we should abandon this proposal and try bringing it back > > in a few months. > > Why? ... > AFAICS, the script works fine. Neil isn't yet satisfied, but he hasn't > identified any weaknesses; he's just expressed a vague concern. I'm content to interpret silence as consent for most changes, but changing the indentation of multiple files is a relatively destructive policy. 1) almost any existing patch to scheme files will break 2) it makes the git history harder to look through (unless you use the git --ignore-whitespace option) I think we should be conservative about indentation policies; we shouldn't rush forwards if a main developer has concerns. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 10: scheme indentation
Graham Percival writes: > On Wed, Sep 14, 2011 at 05:30:35PM -0600, Carl Sorensen wrote: >> On 9/14/11 4:31 PM, "Graham Percival" wrote: >> >> > There's been no action on this for a few weeks. I'm starting to >> > wonder if we should abandon this proposal and try bringing it back >> > in a few months. >> >> Why? > ... >> AFAICS, the script works fine. Neil isn't yet satisfied, but he hasn't >> identified any weaknesses; he's just expressed a vague concern. > > I'm content to interpret silence as consent for most changes, but > changing the indentation of multiple files is a relatively > destructive policy. > > 1) almost any existing patch to scheme files will break > 2) it makes the git history harder to look through (unless you use > the git --ignore-whitespace option) > > I think we should be conservative about indentation policies; we > shouldn't rush forwards if a main developer has concerns. The main problem is that it is catastrophic with regard to rebasing, and still rather disruptive with regard to merging. Personally, I'd prefer it if we focused on solving rather than creating real problems. It is not like we are talking about fixing machine-generated sources without indentation here. Sources _are_ readable, they just don't look quite uniform. But I think that the non-whitespace parts of our code offer enough and more significant opportunities for cleanup work. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improves some parmesan noteheads. (issue 4639065)
New patch set (inspired by Janek's ideas). On 2011/09/14 21:05:28, benko.pal wrote: > * Use the left-stemmed longa in ligatures. exactly what is this last one? When note_shape is MLP_LONGA and the direction of the stem is UP, then the left-stemmed longa is used. I know, this should be Mensural_ligature_engraver's job. The mensural ligature engraver needs to be rewritten. All the postscript stuff should somehow be replaced with good old MetaFont. Thanks, Bertrand. http://codereview.appspot.com/4639065/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New short and long lyric ties. (issue 4912041)
Thanks Janek. Does someone else thinks the long tie should be removed? Bertrand http://codereview.appspot.com/4912041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add some polyphonically directed grobs (issue 4387046)
Great. I removed the dynamics. Is someone opposed to this patch to be pushed? I suggest we put this issue in the next countdown. Thanks, Bertrand http://codereview.appspot.com/4387046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improves some parmesan noteheads. (issue 4639065)
>> > * Use the left-stemmed longa in ligatures. > >> exactly what is this last one? > > When note_shape is MLP_LONGA and the direction of the stem is UP, then > the left-stemmed longa is used. oh, indeed. I must have messed up my build, now I see it. unfortunately this is bad. look at the first row of the mensural-ligatures.ly regtest: the second LB and the second SS are indistinguishable. > I know, this should be Mensural_ligature_engraver's job. > The mensural ligature engraver needs to be rewritten. All the postscript > stuff should somehow be replaced with good old MetaFont. I don't mind that (I didn't eve know that the Stencil - Interval manipulations were PostScript) and I'm willing to take part. p ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improves some parmesan noteheads. (issue 4639065)
hi Bertrand, sorry, I messed up my build last time, and the mensural-ligatures.ly regtest is still bad. look at the first row: the last LB and last SS are indistinguishable. 2.14 is right. all: what would be the good place for the ligature description in the second attachment of http://lists.gnu.org/archive/html/lilypond-devel/2005-02/msg00198.html ? but let me repeat (and enhance) it here: A ligature consists of breves, longae and maximae, joined by a vertical line. There are some exceptions: 1. at the beginning a. a ligature may begin with two semibreves: this is denoted by a left upward stem. The note shapes are like breves. b. if the second note is lower than the first (descending start), then encoding of the duration of the first note is changed as - a longa is denoted by a simple brevis head; - a brevis is denoted by a left downward stem (and brevis head). 2. at the end if the last note is lower than the penultimate one (descending end), and it is a. a longa, then it is represented by a brevis head; b. a breve, then the last two notes are drawn as parallelogram (ligatura obliqua, flexa). This is possible only if the penultimate note would otherwise have brevis shape, i.e. it must be a brevis, or the ligature must be either LB or SSB Notes: 1. reading a ligature is unabiguous; writing one is not: a. any two brevis heads can be replaced by a flexa (except 2.a. above; can be requested by \obliqua _between_ the two notes) b. stems of maximae are often omitted (this implementation omits them always). 2. theorists claim that a pair of semibreves are admitted anywhere, but I have never seen this usage. 3. any note can be dotted or colored independently of others (even either note of a flexa). 4. stems of longae (and maximae, if used) are always drawn down and on the right side of the note. http://codereview.appspot.com/4639065/diff/32001/lily/mensural-ligature.cc File lily/mensural-ligature.cc (right): http://codereview.appspot.com/4639065/diff/32001/lily/mensural-ligature.cc#newcode150 lily/mensural-ligature.cc:150: Direction stem_dir = stem ? get_grob_direction (stem) : CENTER; throw these two lines out http://codereview.appspot.com/4639065/diff/32001/lily/mensural-ligature.cc#newcode175 lily/mensural-ligature.cc:175: index = prefix + ((stem_dir == UP) ? "sl" : "d"); prefix + "d" http://codereview.appspot.com/4639065/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement optional music function arguments (issue 5023044)
Looks pretty cool, apart from some involved Scheme which I couldn't
really unravel totally (see below).
Will this patch allow us to get rid of the abomination of
\afterGraceFraction by recasting \afterGrace to have an optional
parameter
\afterGrace {note} {gracenotes} [spacing-fraction]
e.g.
c1 \afterGrace d1 { c16[ d] } c1 ;; use default spacing
c1 \afterGrace d1 { c16[ d] } 15/16 c1
;or
c1 \afterGrace d1 { c16[ d] } 1/2 c1
;instead of
#(define afterGraceFraction (cons 15 16))
c1 \afterGrace d1 { c16[ d] } c1
;or
#(define afterGraceFraction (cons 1 2))
c1 \afterGrace d1 { c16[ d] } c1
Keep up the good work, and thanks.
Ian
http://codereview.appspot.com/5023044/diff/9001/scm/document-identifiers.scm
File scm/document-identifiers.scm (right):
http://codereview.appspot.com/5023044/diff/9001/scm/document-identifiers.scm#newcode33
scm/document-identifiers.scm:33: (format $f "(~a)" (type-name pred)
What does $f do in the format destination here, where's it declared? The
Guile documentation mentions #f returning the output as a string,
otherwise it's a port. So what port does $f represent?
Does this tie up with the (define-syntax-function) changes in
music-functions.scm? Is $f definitely not a typo?
Comment this section, please, David.
http://codereview.appspot.com/5023044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improves some parmesan noteheads. (issue 4639065)
Ok Pal, I removed the left-stemmed longa. I don't know where you could put these rules. Maybe we should start a new doc part that references the established engraving rules? Bertrand http://codereview.appspot.com/4639065/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Introduce a maximum depth for markup evaluation (issue 5032041)
http://codereview.appspot.com/5032041/diff/1/scm/lily.scm File scm/lily.scm (right): http://codereview.appspot.com/5032041/diff/1/scm/lily.scm#newcode125 scm/lily.scm:125: it will not terminate at all and print out a warning, but continue processing.") In the regression test the doc-text says "Markups have a maximum depth to prevent non-termination." your doc-text here seems to say something different, i.e. you'll print out the warning and let it carry on until Lily runs our of memory or whatever. Which is right? http://codereview.appspot.com/5032041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Introduce a maximum depth for markup evaluation (issue 5032041)
passes make and reg tests (with other patch applied first and this one on top) http://codereview.appspot.com/5032041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Introduce a maximum depth for markup evaluation (issue 5032041)
Am Thursday, 15. September 2011, 21:57:12 schrieben Sie: > http://codereview.appspot.com/5032041/diff/1/scm/lily.scm > File scm/lily.scm (right): > > http://codereview.appspot.com/5032041/diff/1/scm/lily.scm#newcode125 > scm/lily.scm:125: it will not terminate at all and print out a warning, > but continue processing.") > In the regression test the doc-text says > "Markups have a maximum depth to prevent non-termination." > your doc-text here seems to say something different, i.e. you'll print > out the warning and let it carry on until Lily runs our of memory or > whatever. Which is right? No, I meant that as soon as the maximum depth is reached, I return a null markup, so that the normal processing can continue without the markup looping until we run out of memory. I'll reword the doctitle. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 380: Auto-detect all cyclic references in markups (issue 5027042)
Passes make and reg tests http://codereview.appspot.com/5027042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement optional music function arguments (issue 5023044)
Fails make
--snip--
Backtrace:
In unknown file:
?: 0* [primitive-load-path "documentation-generate.scm"]
In
/home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/documentation-generate.scm:
72: 1* [display ...
73: 2* [identifiers-doc-string]
In
/home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/document-identifiers.scm:
64: 3 [format #f "@table @asis
~a
@end table
" ...
69: 4* [string-join ...
70: 5*[filter # ...
72: 6* [map # (# # # #
...)]
In unknown file:
?: 7* [document-object (acciaccatura . #)]
In
/home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/document-identifiers.scm:
57: 8* (cond (# #) (else #f))
59: 9 [document-music-function (acciaccatura . #)]
21: 10 (let* # #)
/home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/document-identifiers.scm:21:3:
In procedure memoization in expression (let* (# # # ...) (format #f
"@item @code{~a} ~a ~a~a
@funindex ~a
~a
" ...)):
/home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/document-identifiers.scm:21:3:
In file
"/home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/document-identifiers.scm",
line 29: Bad binding (type-names (map (lambda (pred) (if (pair? pred)
(format #f "[~a]" (type-name (car pred))) (format $f "(~a)" (type-name
pred) sign) in expression (let* ((name-sym (car music-func-pair))
(music-func (cdr music-func-pair)) (func (ly:music-function-extract
music-func)) (arg-names (map symbol->string (cddr (cadr
(procedure-source func) (doc (procedure-documentation func)) (sign
(object-property func (quote music-function-signature))) (type-names
(map (lambda (pred) (if (pair? pred) (format #f "[~a]" #) (format $f
"(~a)" # sign) (signature-str (string-join (map (lambda (x) (format
#f "@var{~a} ~a" # #)) (zip arg-names (cdr type-names)) (format #f
"@item @code{~a} ~a ~a~a
@funindex ~a
~a
" name-sym (car type-names) (if (equal? "" signature-str) "" " - ")
signature-str name-sym (if doc doc (begin (ly:warning "music function
`~a' not documented." name-sym) "(undocumented; fixme)".
make[1]: *** [out/internals.texi] Error 1
make[1]: Leaving directory
`/home/jlowe/lilypond-git/build/Documentation'
make: *** [all] Error 2
jlowe@jlowe-lilybuntu2:~/lilypond-git/build$
http://codereview.appspot.com/5023044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 10: scheme indentation
2011/9/15 Graham Percival : > There's been no action on this for a few weeks. I'm starting to > wonder if we should abandon this proposal and try bringing it back > in a few months. That's strange, i had a vague feeling that the last status was a bit of LGTMs and lots of silence, but... 2011/9/15 Reinhold Kainhofer : > Am Thursday, 15. September 2011, 14:47:30 schrieb Ian Hulin: >> On 15/09/11 09:19, Trevor Daniels wrote: >> > I'd rather interpret no action as tacit approval. As your >> > electronics colleague once said, "Just do it." :) >> > >> > Trevor >> >> 1+ > > +1 ++ 2011/9/15 David Kastrup : > Personally, I'd prefer it if we focused on solving rather than creating > real problems. It is not like we are talking about fixing > machine-generated sources without indentation here. Sources _are_ > readable, they just don't look quite uniform. But I think that the > non-whitespace parts of our code offer enough and more significant > opportunities for cleanup work. i'd love to see more comments in the code! Currently i have hard time reading note-collision.cc - after more than an hour i still only have a vague idea what's going on there. If anyone'd like to explain this, i'd be greatful! I cannot write a good fix for 1546 until i understand note-collision.cc cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Introduce a maximum depth for markup evaluation (issue 5032041)
http://codereview.appspot.com/5032041/diff/1/scm/lily.scm File scm/lily.scm (right): http://codereview.appspot.com/5032041/diff/1/scm/lily.scm#newcode125 scm/lily.scm:125: it will not terminate at all and print out a warning, but continue processing.") On 2011/09/15 19:57:12, Ian Hulin (gmail) wrote: In the regression test the doc-text says "Markups have a maximum depth to prevent non-termination." your doc-text here seems to say something different, i.e. you'll print out the warning and let it carry on until Lily runs our of memory or whatever. Which is right? 2nd try: "Maximum depth for the markup tree. If a markup has more levels, assume it will not terminate on its own, print a warning and return a null markup instead." http://codereview.appspot.com/5032041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 10: scheme indentation
Am Thursday, 15. September 2011, 22:29:21 schrieben Sie: > 2011/9/15 David Kastrup : > > Personally, I'd prefer it if we focused on solving rather than creating > > real problems. My experience from the C++ formatting run is that those whitespace changes are really no big deal. Rebasing does not cause that many conflicts usually, and those can be manually fixed easily. > i'd love to see more comments in the code! Currently i have hard time > reading note-collision.cc - after more than an hour i still only have > a vague idea what's going on there. If anyone'd like to explain this, > i'd be greatful! I cannot write a good fix for 1546 until i > understand note-collision.cc I can only second that: Having more comments would really help me understand in many case what's going on and what's the purpose of some particular code and the logic. Personally, I try to include lots of comments, so that whenever I'll look at the code again, I don't have to think it through in detail, bue have the comments tell me all about the code in human-understandable language. In particular, if someone uses some clever code, or a nasty workaround, we really need some comments to understand what's goind on. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 11: git repositories (probable decision)
2011/9/15 Graham Percival : > ** Unchanged branches > (...) > stable/* I'm wondering if we can get rid of them, but i'm not sure about one thing: are they just a point in our history, i.e. ... (lots of commits) ...<2.x stable release commit> ... (lots of commits) ... ? Or are they true branches, i.e. not a subset of master? In the first case maybe we could just use git tags? (or is my question stupid because we are already using them?) cheers, Janek PS overall LGTM ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New short and long lyric ties. (issue 4912041)
Passes make, a full make doc and reg tests. Output of NR example attached here: http://code.google.com/p/lilypond/issues/detail?id=1822#c5 James http://codereview.appspot.com/4912041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Isue 1868: Loglevels in our python scripts (lilypond-book, musicxml2ly, convert-ly) (issue 4908041)
passes make and reg tests http://codereview.appspot.com/4908041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improves some parmesan noteheads. (issue 4639065)
hi Bertrand, > Ok Pal, I removed the left-stemmed longa. thanks, mensural-ligatures.ly is now ok. p ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improves some parmesan noteheads. (issue 4639065)
Passes make and new reg test differences (look ok) attached here http://code.google.com/p/lilypond/issues/detail?id=1839#c17 http://codereview.appspot.com/4639065/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Lilypond-book: Improve options handling by processing everything in one place (issue 5030044)
Reviewers: , Message: Finally clean up the lilypond-book option-handling even more. Please review Description: Lilypond-book: Improve options handling by processing everything in one place Please review this at http://codereview.appspot.com/5030044/ Affected files: M python/book_snippets.py ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
no access to my Lilydev
Hi, i'm travelling and i've tried connecting to my LilyDev-enabled machine using remote desktop, but it's unusable. I will have access to it on Sunday. This means that i cannot push some patches that got through countdown, sorry. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New short and long lyric ties. (issue 4912041)
2011/9/15 : > Passes make, a full make doc and reg tests. > > Output of NR example attached here: > > http://code.google.com/p/lilypond/issues/detail?id=1822#c5 It is indeed strange that short ties don't work with accented e. Can anyone verify Bertrand's suspection that encoding in "make doc" is to blame? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Introduce a maximum depth for markup evaluation (issue 5032041)
On 2011/09/15 20:37:07, Reinhold wrote: http://codereview.appspot.com/5032041/diff/1/scm/lily.scm File scm/lily.scm (right): http://codereview.appspot.com/5032041/diff/1/scm/lily.scm#newcode125 scm/lily.scm:125: it will not terminate at all and print out a warning, but continue processing.") On 2011/09/15 19:57:12, Ian Hulin (gmail) wrote: > In the regression test the doc-text says > "Markups have a maximum depth to prevent non-termination." > your doc-text here seems to say something different, i.e. you'll print out the > warning and let it carry on until Lily runs our of memory or whatever. Which is > right? 2nd try: "Maximum depth for the markup tree. If a markup has more levels, assume it will not terminate on its own, print a warning and return a null markup instead." LGTM Cheers, Ian http://codereview.appspot.com/5032041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Introduce a maximum depth for markup evaluation (issue 5032041)
LGTM with revised doc-text in define-syntax-function. http://codereview.appspot.com/5032041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement optional music function arguments (issue 5023044)
http://codereview.appspot.com/5023044/diff/9001/scm/document-identifiers.scm File scm/document-identifiers.scm (right): http://codereview.appspot.com/5023044/diff/9001/scm/document-identifiers.scm#newcode33 scm/document-identifiers.scm:33: (format $f "(~a)" (type-name pred) On 2011/09/15 19:44:41, Ian Hulin (gmail) wrote: What does $f do in the format destination here, where's it declared? The Guile documentation mentions #f returning the output as a string, otherwise it's a port. So what port does $f represent? Does this tie up with the (define-syntax-function) changes in music-functions.scm? Is $f definitely not a typo? Comment this section, please, David. Typo. I have not rebuilt the documentation. Thanks for catching this. http://codereview.appspot.com/5023044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Another frog job: pepper the documentation with indexing commands
Hello, On Sun, Sep 11, 2011 at 6:49 AM, David Kastrup wrote: > > The documentation is not really indexed all that well: new additions > often are made without indexing entries. Going through the source and > index and trying to make sure that interesting things can be found under > obvious names in the index is a bunch of work requiring mostly editorial > skills. Here is a good (i.e. bad) example of inconsistent and, in my opinion, 'noisy' index entries. This comes from repeats.itely --snip-- @node Written-out repeats @unnumberedsubsubsec Written-out repeats @cindex written-out repeats @cindex repetitious music @cindex repeats, written-out @cindex repeat, unfold @cindex unfold music @cindex unfold repeat @cindex unfold repeat with alternate endings @cindex unfold music with alternate endings @cindex alternate ending in written-out repeats @funindex unfold --snip-- Yes it's nice to have all the possible ways to say the same thing indexed for the 1 user that might choose to look for 'repetitious music' (!!) but please, isn't this just silly? I don't have all the answers but I am sure we could standardize some of the index entries. Regards -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Introduce a maximum depth for markup evaluation (issue 5032041)
On 2011/09/15 21:28:37, Ian Hulin (gmail) wrote: LGTM with revised doc-text in define-syntax-function. Uh, I am revising the doc-text (as well as rewriting some code), but that's a different issue altogether. http://codereview.appspot.com/5032041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Another frog job: pepper the documentation with indexing commands
Peekay Ex writes: > Hello, > > On Sun, Sep 11, 2011 at 6:49 AM, David Kastrup wrote: >> >> The documentation is not really indexed all that well: new additions >> often are made without indexing entries. Going through the source and >> index and trying to make sure that interesting things can be found under >> obvious names in the index is a bunch of work requiring mostly editorial >> skills. > > Here is a good (i.e. bad) example of inconsistent and, in my opinion, > 'noisy' index entries. This comes from repeats.itely > > --snip-- > > @node Written-out repeats > @unnumberedsubsubsec Written-out repeats > > @cindex written-out repeats > @cindex repetitious music > @cindex repeats, written-out > @cindex repeat, unfold > @cindex unfold music > @cindex unfold repeat > @cindex unfold repeat with alternate endings > @cindex unfold music with alternate endings > @cindex alternate ending in written-out repeats > @funindex unfold > > --snip-- > > Yes it's nice to have all the possible ways to say the same thing > indexed for the 1 user that might choose to look for 'repetitious > music' (!!) but please, isn't this just silly? The info readers have TAB completion. You start typing a few letters, then press TAB. Indexing the same section with key phrases starting all the same is nothing but a nuisance. The same holds for the printed index. Similarly for "repetitious music". "alternate ending", in contrast, is a useful additional index entry. There is no harm that it is longer than necessary: if you do tab completion or read the printed version, it gives you an additional clue whether you'll find what you are interested in. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add support for custom ledger positions, using two new staff-symbol properties (issue 4974075)
On 15 September 2011 14:43, wrote: > Done, typical beginner imperfections, thanks for pointing out. Thanks. :) For some reason, your patch fails `make check' on my system. I consistently get SIGABRT thrown soon after running: job 2 terminated with signal: 6 job 1 terminated with signal: 6 job 0 terminated with signal: 6 fatal error: Children (2 1 0) exited with errors. command failed: /home/neil/lilypond/out/bin/lilypond -I ./ -I ./out-test -I ../../input -I /home/neil/lilypond/Documentation -I /home/neil/lilypond/Documentation/snippets -I ../../input/regression/ -I /home/neil/lilypond/Documentation/included/ -I /home/neil/lilypond/mf/out/ -I /home/neil/lilypond/mf/out/ -I /home/neil/lilypond/Documentation/pictures -I /home/neil/lilypond/Documentation/pictures/./out-test -dbackend=eps --formats=ps -djob-count=3 -dseparate-log-files -dinclude-eps-fonts -dgs-load-lily-fonts --header=texidoc -I /home/neil/lilypond/Documentation/included/ -ddump-profile -dcheck-internal-types -ddump-signatures -danti-alias-factor=1 -I "/home/neil/lilypond/out/lybook-testdb" -I "/home/neil/lilypond/input/regression" -I "/home/neil/lilypond/input/regression" -I "/home/neil/lilypond/input/regression/out-test" -I "/home/neil/lilypond/input" -I "/home/neil/lilypond/Documentation" -I "/home/neil/lilypond/Documentation/snippets" -I "/home/neil/lilypond/input/regression" -I "/home/neil/lilypond/Documentation/included" -I "/home/neil/lilypond/mf/out" -I "/home/neil/lilypond/mf/out" -I "/home/neil/lilypond/Documentation/pictures" -I "/home/neil/lilypond/Documentation/pictures/out-test" --formats=eps -deps-box-padding=3.00 -dread-file-list -dno-strip-output-dir "/home/neil/lilypond/out/lybook-testdb/snippet-names--7968346798296354682.ly" Child returned 1 make[2]: *** [out-test/collated-files.texi] Error 1 rm out-test/weblinks.itexi make[2]: Leaving directory `/home/neil/lilypond/input/regression' make[1]: *** [local-test] Error 2 make[1]: Leaving directory `/home/neil/lilypond/input/regression' make: *** [test] Error 2 This is with an unoptimised binary (using --disable-optimising). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add support for custom ledger positions, using two new staff-symbol properties (issue 4974075)
On 2011/09/15 21:41:27, Neil Puttock wrote: For some reason, your patch fails `make check' on my system. Neil, I've just applied this patch - after seeing your note - to the latest 'git pull -r' and 'make ; make check' work fine on my system if that helps? James http://codereview.appspot.com/4974075/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add support for custom ledger positions, using two new staff-symbol properties (issue 4974075)
On 15 September 2011 23:04, wrote: > On 2011/09/15 21:41:27, Neil Puttock wrote: > >> For some reason, your patch fails `make check' on my system. > > Neil, I've just applied this patch - after seeing your note - to the > latest 'git pull -r' and 'make ; make check' work fine on my system if > that helps? Did you build with --disable-optimising (you should be if you're doing regression checking)? Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New alist to replace special characters. (issue 4553056)
New patch set. '&' and '@' have been added to the lexer. '&' is therefore a perfectly working escape character in lyrics. Bertrand http://codereview.appspot.com/4553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add some polyphonically directed grobs (issue 4387046)
LGTM. http://codereview.appspot.com/4387046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 11: git repositories (probable decision)
2011/9/15 Janek Warchoł : > 2011/9/15 Graham Percival : >> ** Unchanged branches >> (...) >> stable/* > > I'm wondering if we can get rid of them, but i'm not sure about one > thing: are they just a point in our history, i.e. > ... (lots of commits) ...<2.x stable release commit> > ... (lots of commits) ... ? No. That looks like a tag in a branch. > Or are they true branches, i.e. not a subset of master? Yes. Branches are not subsets. They keep independent histories. > In the first case maybe we could just use git tags? (or is my question > stupid because we are already using them?) Yes we are already using them, No tags and branches do not provide similar features, and No your question is not stupid. -- 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: Another frog job: pepper the documentation with indexing commands
Peekay Ex wrote Thursday, September 15, 2011 10:30 PM Here is a good (i.e. bad) example of inconsistent and, in my opinion, 'noisy' index entries. This comes from repeats.itely --snip-- @node Written-out repeats @unnumberedsubsubsec Written-out repeats @cindex written-out repeats @cindex repetitious music @cindex repeats, written-out @cindex repeat, unfold @cindex unfold music @cindex unfold repeat @cindex unfold repeat with alternate endings @cindex unfold music with alternate endings @cindex alternate ending in written-out repeats @funindex unfold --snip-- Yes it's nice to have all the possible ways to say the same thing indexed for the 1 user that might choose to look for 'repetitious music' (!!) but please, isn't this just silly? Yes. The index is too long, largely because of the silly See Also entries. I don't have all the answers but I am sure we could standardize some of the index entries. Here are two suggestions for removing index entries: a) remove entries which are adjacent in the index and point to the same section - that removes all those starting with unfold except for unfold repeats (I prefer the plural) b) remove entries which start with variations of the same word, eg repetitious music Leaving @cindex written-out repeats @cindex repeats, written-out @cindex repeats, unfold @cindex unfold repeats @cindex alternate ending in written-out repeats @funindex unfold Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement optional music function arguments (issue 5023044)
On 2011/09/15 21:29:20, dak wrote: http://codereview.appspot.com/5023044/diff/9001/scm/document-identifiers.scm File scm/document-identifiers.scm (right): http://codereview.appspot.com/5023044/diff/9001/scm/document-identifiers.scm#newcode33 scm/document-identifiers.scm:33: (format $f "(~a)" (type-name pred) On 2011/09/15 19:44:41, Ian Hulin (gmail) wrote: > What does $f do in the format destination here, where's it declared? The Guile > documentation mentions #f returning the output as a string, otherwise it's a > port. So what port does $f represent? > Does this tie up with the (define-syntax-function) changes in > music-functions.scm? Is $f definitely not a typo? > Comment this section, please, David. Typo. I have not rebuilt the documentation. Thanks for catching this. Ok, this should now be better. http://codereview.appspot.com/5023044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add scripts/auxiliar/guileindent.scm (issue 4896043)
http://codereview.appspot.com/4896043/diff/10002/scripts/auxiliar/guileindent.scm File scripts/auxiliar/guileindent.scm (right): http://codereview.appspot.com/4896043/diff/10002/scripts/auxiliar/guileindent.scm#newcode38 scripts/auxiliar/guileindent.scm:38: (define (assf test-proc search-list) move to lily-library.scm http://codereview.appspot.com/4896043/diff/10002/scripts/auxiliar/guileindent.scm#newcode65 scripts/auxiliar/guileindent.scm:65: '(block some of these aren't Guile keywords http://codereview.appspot.com/4896043/diff/10002/scripts/auxiliar/guileindent.scm#newcode71 scripts/auxiliar/guileindent.scm:71: '(case some of these aren't Guile keywords http://codereview.appspot.com/4896043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add scripts/auxiliar/guileindent.scm (issue 4896043)
lambda* should have same indentation as lambda comments are broken: ; (margin comment) should be indented (not sure how many spaces emacs does it though) ;;; (top-level comment) shouldn't be indented even inside a form There are a few files which use margin comments by mistake, so we should fix them ideally (e.g., define-markup-commands.scm, slashed-digit-internal). http://codereview.appspot.com/4896043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
