Re: critical issues
m...@apollinemike.com m...@apollinemike.com writes: On Jan 5, 2012, at 1:20 AM, Janek Warchoł wrote: Correct me if i'm wrong, but my impression is that there is no particular direction in which we are going. I'm sure that other people have their pet projects as well. The ensemble of these projects is the direction of LilyPond, and I don't see why it would need more of a direction that that. Because a) LilyPond becomes unmaintainable if everybody implementing his own pet project implements his own pet infrastructure and pet APIs for it. b) LilyPond becomes unusable if everybody implementing his own pet project does not bother paving the path for slightly similar pet projects. c) Implementors are scarcer than users. In fact, I think that it is because of some sorta unified direction that for-profit programs can often miss out on adding experimental or innovative features. Mike, just recently you said something like you had implemented something along the line of spanbars, did not actually understand what you were doing, it could not actually do the work you intended it to do, but you thought there was nothing wrong with leaving it in until somebody hit bugs caused by this code. You can't debug or understand this sort of experimental and innovative code, and if you can't yourself, how can you expect anybody else to do? This sort of bit rot which nobody know how to either fix or remove(!) is _lethal_ to a project. A few dozen things like that, and nobody can make the product stable again with reasonable amounts of efforts. Instead you get symptom-fixing, taking _huge_ amounts of resources in order to let code nobody understand not hit fatal situations. And the code not actually doing anything useful or reliable is causing man-months of maintenance work. As opposed to an artwork, _any_ corner of LilyPond, no matter how small, can _ruin_ the rest. You tend to think of bugs and bad code of blemishes at most, when they are actually more like fungi that will eat through the whole canvas and cause it to fall apart. Features and innovations come at a cost. With good modularization and infrastructure, their cost and benefits are mostly separable from others: don't use them, and you don't get troubled by them. LilyPond is not modular enough for that, and it does not have the infrastructure. Those don't fall from the sky, and if they are to fit their purpose, they will require very little experimentation or innovation but will be perfectly boring. And if the LilyPond code does not make great strides in the direction of becoming boring by doing everything the same way, projects like use linear programming will be dead in the water since you can't streamline a garbage heap of disparate code into doing linear programming if you can't even make it do the same things in the same way everywhere before changing that way to a linear programming one. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
On Jan 5, 2012, at 9:14 AM, David Kastrup wrote: m...@apollinemike.com m...@apollinemike.com writes: On Jan 5, 2012, at 1:20 AM, Janek Warchoł wrote: Correct me if i'm wrong, but my impression is that there is no particular direction in which we are going. I'm sure that other people have their pet projects as well. The ensemble of these projects is the direction of LilyPond, and I don't see why it would need more of a direction that that. Because a) LilyPond becomes unmaintainable if everybody implementing his own pet project implements his own pet infrastructure and pet APIs for it. b) LilyPond becomes unusable if everybody implementing his own pet project does not bother paving the path for slightly similar pet projects. I agree with this - I should have added that those who are contributing to LilyPond should do so in a way that favors extensibility. c) Implementors are scarcer than users. In fact, I think that it is because of some sorta unified direction that for-profit programs can often miss out on adding experimental or innovative features. Mike, just recently you said something like you had implemented something along the line of spanbars, did not actually understand what you were doing, it could not actually do the work you intended it to do, but you thought there was nothing wrong with leaving it in until somebody hit bugs caused by this code. I agree with the something like part of your statement. As opposed to an artwork, _any_ corner of LilyPond, no matter how small, can _ruin_ the rest. You tend to think of bugs and bad code of blemishes at most, when they are actually more like fungi that will eat through the whole canvas and cause it to fall apart. This is not how I think of bugs. If I thought of bugs like this, I wouldn't have taken the time to squash so many bugs in LilyPond over the past several months. And if the LilyPond code does not make great strides in the direction of becoming boring by doing everything the same way, projects like use linear programming will be dead in the water since you can't streamline a garbage heap of disparate code into doing linear programming if you can't even make it do the same things in the same way everywhere before changing that way to a linear programming one. I agree. For example: The new StemTremolo code does less internal moving of the stencil and farms this out to callbacks. The new Stem code is decoupled from the Flag code and now behaves (along with the flag) more like other grobs. The Beam scoring code now looks more like the Stem and Tie scoring code on the inside. I did not work on these projects expressly in order to make LilyPond more uniform, but in working on them, I tried to move LilyPond to a state where its code was uniform. I think a good policy is that, when working on that which one wants to work on, one should always strive to do it in a way that leads to better maintainability and extensibility. Perhaps this is my American bias, but I strongly believe that the value of LilyPond is in the innovativeness of those who care enough about it to work on it. LilyPond's becoming more maintainable and extensible is a result of the good coding practices of these people. However, I do not think that a grand unified vision of where LilyPond should go (short of several guidelines on style and common practice (many of which are already in the CG)) is necessary or desirable. taken only slightly out of context There are again two methods of removing the causes of faction: the one, by destroying the liberty which is essential to its existence; the other, by giving to every citizen the same opinions, the same passions, and the same interests. It could never be more truly said than of the first remedy, that it was worse than the disease. Liberty is to faction what air is to fire, an aliment without which it instantly expires. But it could not be less folly to abolish liberty, which is essential to political life, because it nourishes faction, than it would be to wish the annihilation of air, which is essential to animal life, because it imparts to fire its destructive agency. The second expedient is as impracticable as the first would be unwise. As long as the reason of man continues fallible, and he is at liberty to exercise it, different opinions will be formed. As long as the connection subsists between his reason and his self-love, his opinions and his passions will have a reciprocal influence on each other; and the former will be objects to which the latter will attach themselves. The diversity in the faculties of men, from which the rights of property originate, is not less an insuperable obstacle to a uniformity of interests. The protection of these faculties is the first object of government. From the protection of different and unequal faculties of acquiring property, the possession of different degrees and kinds of property immediately
Re: critical issues
m...@apollinemike.com m...@apollinemike.com writes: On Jan 5, 2012, at 9:14 AM, David Kastrup wrote: m...@apollinemike.com m...@apollinemike.com writes: On Jan 5, 2012, at 1:20 AM, Janek Warchoł wrote: Correct me if i'm wrong, but my impression is that there is no particular direction in which we are going. I'm sure that other people have their pet projects as well. The ensemble of these projects is the direction of LilyPond, and I don't see why it would need more of a direction that that. Because a) LilyPond becomes unmaintainable if everybody implementing his own pet project implements his own pet infrastructure and pet APIs for it. b) LilyPond becomes unusable if everybody implementing his own pet project does not bother paving the path for slightly similar pet projects. I agree with this - I should have added that those who are contributing to LilyPond should do so in a way that favors extensibility. If everybody does it in his own local way, it is more a distraction than anything else. How does one do x in LilyPond? Depends on whether you are talking about functionality written by Mike, David, Han-Wen, Jan, Graham, Carl or Werner. That's not what a user wants to hear. I agree with the something like part of your statement. If I have something like a fire-breathing dragon with a hunger for human flesh in my backyard, that is scary enough as a starting point for me. Even if I got the details wrong. As opposed to an artwork, _any_ corner of LilyPond, no matter how small, can _ruin_ the rest. You tend to think of bugs and bad code of blemishes at most, when they are actually more like fungi that will eat through the whole canvas and cause it to fall apart. This is not how I think of bugs. If I thought of bugs like this, I wouldn't have taken the time to squash so many bugs in LilyPond over the past several months. Well, bug was probably the wrong word to use here. A bug is an isolated phenomenon. Squashing bugs is fine in itself, but if you find yourself excelling at it, at one point of time you should probably rather think about how to better lock your alimentaries away. And if the LilyPond code does not make great strides in the direction of becoming boring by doing everything the same way, projects like use linear programming will be dead in the water since you can't streamline a garbage heap of disparate code into doing linear programming if you can't even make it do the same things in the same way everywhere before changing that way to a linear programming one. I agree. For example: The new StemTremolo code does less internal moving of the stencil and farms this out to callbacks. The new Stem code is decoupled from the Flag code and now behaves (along with the flag) more like other grobs. The Beam scoring code now looks more like the Stem and Tie scoring code on the inside. I did not work on these projects expressly in order to make LilyPond more uniform, but in working on them, I tried to move LilyPond to a state where its code was uniform. Well, uniform code is nice, modular code is better. You don't need to worry about uniformity if everything actually calls the same code. And if you need to change how it works, being able to do it in one place is much less likely to cause problems. Of course, that needs to touch foreign code in a lot of places instead of just leading by example. And that's where actual leadership is helpful since it can _make_ people change their _own_ code, and they usually are much better qualified to see problems in connection with those changes than a self-appointed global janitor can hope to be. I think a good policy is that, when working on that which one wants to work on, one should always strive to do it in a way that leads to better maintainability and extensibility. If those efforts are not coordinated, there is no end user benefit. He'll still have to learn the individual ways of every part of LilyPond he is going to work with. And if the individual ways are all different but still over-generalized, this becomes more of a distraction than a benefit. Generalization is not useful as an example or a proposal in some corner of the code. It makes only sense if it is pervasive. And if it is left to the individual's discretion, it can only become pervasive when the individual is working _everywhere_. LilyPond has grown beyond the scope of a single-person project, however. taken only slightly out of context There are again two methods of removing the causes of faction: the one, by destroying the liberty which is essential to its existence; the other, by giving to every citizen the same opinions, the same passions, and the same interests. [...] Diversity is nice in a community. It isn't in a program. And it isn't all too much in a single entity like a person, either. There is not much you can sensibly talk about with a fanatic conservative liberal antisemitic orthodox catholic
Re: Segfault 2.15.23 Span_bar_stub_engraver
On Jan 5, 2012, at 7:51 AM, David Kastrup wrote: Grob::get_vertical_axis_group is not protected against the case where g has an axis group interface but no Y_AXIs parent. I thought it was. If g has no Y_AXIS parent, then when get_vertical_axis_group (g-get_parent (Y_AXIS)); is called, the first test if (!g) will return 0, no? The second if in Grob::vertical_less has a test that can obviously not be true. This is true - fix pushed to staging. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Segfault 2.15.23 Span_bar_stub_engraver
m...@apollinemike.com writes:
On Jan 5, 2012, at 7:51 AM, David Kastrup wrote:
Grob::get_vertical_axis_group is not protected against the case where g
has an axis group interface but no Y_AXIs parent.
I thought it was. If g has no Y_AXIS parent, then when
get_vertical_axis_group (g-get_parent (Y_AXIS)); is called, the first
test if (!g) will return 0, no?
Grob::get_vertical_axis_group (Grob *g)
{
if (!g)
return 0;
if (Axis_group_interface::has_interface (g)
Align_interface::has_interface (g-get_parent (Y_AXIS)))
return g;
return get_vertical_axis_group (g-get_parent (Y_AXIS));
}
You call Align_interface::has_interface (g-get_parent (Y_AXIS)) here
before you call get_vertical_axis_group.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Segfault 2.15.23 Span_bar_stub_engraver
On Jan 5, 2012, at 11:24 AM, David Kastrup wrote:
m...@apollinemike.com writes:
On Jan 5, 2012, at 7:51 AM, David Kastrup wrote:
Grob::get_vertical_axis_group is not protected against the case where g
has an axis group interface but no Y_AXIs parent.
I thought it was. If g has no Y_AXIS parent, then when
get_vertical_axis_group (g-get_parent (Y_AXIS)); is called, the first
test if (!g) will return 0, no?
Grob::get_vertical_axis_group (Grob *g)
{
if (!g)
return 0;
if (Axis_group_interface::has_interface (g)
Align_interface::has_interface (g-get_parent (Y_AXIS)))
return g;
return get_vertical_axis_group (g-get_parent (Y_AXIS));
}
You call Align_interface::has_interface (g-get_parent (Y_AXIS)) here
before you call get_vertical_axis_group.
Fixed.
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Segfault 2.15.23 Span_bar_stub_engraver
m...@apollinemike.com m...@apollinemike.com writes:
On Jan 5, 2012, at 11:24 AM, David Kastrup wrote:
m...@apollinemike.com writes:
On Jan 5, 2012, at 7:51 AM, David Kastrup wrote:
Grob::get_vertical_axis_group is not protected against the case where g
has an axis group interface but no Y_AXIs parent.
I thought it was. If g has no Y_AXIS parent, then when
get_vertical_axis_group (g-get_parent (Y_AXIS)); is called, the first
test if (!g) will return 0, no?
Grob::get_vertical_axis_group (Grob *g)
{
if (!g)
return 0;
if (Axis_group_interface::has_interface (g)
Align_interface::has_interface (g-get_parent (Y_AXIS)))
return g;
return get_vertical_axis_group (g-get_parent (Y_AXIS));
}
You call Align_interface::has_interface (g-get_parent (Y_AXIS)) here
before you call get_vertical_axis_group.
Fixed.
Note: I have no clue about what the code does. This was just one thing
that did not earn extra credit in the obviously not wrong category
with me. I don't have more to go by at the moment. And it is scary to
me if that may, at times, be enough.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (was) Some drum notation questions - (now) problem with noteheads in doc?
Am 04.01.2012 19:59, schrieb James:
On 4 January 2012 18:55, Jamespkx1...@gmail.com wrote:
Hello,
On 4 January 2012 18:32, Vaylor Trucksvay...@gmail.com wrote:
I have been using lilypond for years for my own projects and have recently
introduced it to a friend of mine. He is a drum instructor and has been reading
drum notation for many years. He's pointed out some things that are
non-standard about the way lilypond handles some drum notation tasks. Most of
these I have been able to correct using a #(define block. There are, however,
some things I have not yet been able to crack.
First, for hi-hat, the notation for open and closed are correct, but for the
half-open he would like to appear exactly like the open hi-hat notation, except
the o above the stem of the note needs to have a single slash through it.
Also, the note head for a China cymbal he notes by having a standard cross note
head, but with a box around it.
Can anyone point me in the right direction for making these changes?
I have no experience of doing this but you might want to start here
http://lilypond.org/doc/v2.14/Documentation/notation/modifying-stencils
The percussion notes are all here:
http://lilypond.org/doc/v2.14/Documentation/notation/percussion-notes
I've just noticed that most of the note heads on
http://lilypond.org/doc/v2.14/Documentation/notation/percussion-notes
here are semibreves insetad of I assume lots of crosses and circles etc.
The PDF from 2.15.22 also show this.
Can someone verify this?
In the documentation, namely
Documentation/included/percussion-chart.ly
the notes are defined as whole notes:
\drummode {
\cadenzaOn
bda1^\markup { \center-align acousticbassdrum: bda }
As whole notes make not much sense in percussion parts IMHO,
a change to
bda4^\
should Do The Right Thing (tm).
Marc
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
include music-function
Dear lily-list-members, first of all: A happy new year! In my projects I often combine several files, each containing one piece, to a book. In fact, I store the music in a scheme-based structure to instantiate it later. The included files shall intentionally not create a PDF, so that instantiation can be organized in bookparts as needed. But when I work on a specific piece I want to debug it without compiling the whole book. One solution would be to use frescobaldi and a comment %%master: ../main.ly at the end of the file. But then I have to create a master-file for each part. So I created a music-function to include a testfile wich contains instructions to instantiate the music stored in my structures only if I am compiling this file directly: --snip-- #(define-public includeLocal (define-music-function (parser location file)(string?) (let ((outname (format ~A.ly (ly:parser-output-name parser))) (locname (car (ly:input-file-line-char-column location (if (or (string=? outname locname)(string-suffix? outname locname)) (let ((content (ly:gulp-file file))) (ly:parser-include-string parser content))) (make-music 'SequentialMusic 'void #t \includeLocal test.ly --snip-- This function first compares the outname with the location name and only includes the file if they match. (This should not work, if you have set some output-suffix!) This is a usable solution to me. But I would like to have the correct location info available, while parsing the included file. Is it possible to create an arbitrary include-music-function? This would make it possible, to (for example) include all files in a directory or matching a specific pattern. Cheers, Jan-Peter ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: include music-function
Jan-Peter Voigt jp.vo...@gmx.de writes:
I am compiling this file directly:
--snip--
#(define-public includeLocal (define-music-function (parser location
file)(string?)
(let ((outname (format ~A.ly (ly:parser-output-name parser)))
(locname (car (ly:input-file-line-char-column location
(if (or (string=? outname locname)(string-suffix? outname
locname))
(let ((content (ly:gulp-file file)))
(ly:parser-include-string parser content)))
(make-music 'SequentialMusic 'void #t
\includeLocal test.ly
--snip--
This function first compares the outname with the location name and
only includes the file if they match. (This should not work, if you
have set some output-suffix!)
This is a usable solution to me. But I would like to have the correct
location info available, while parsing the included file.
Is it possible to create an arbitrary include-music-function? This
would make it possible, to (for example) include all files in a
directory or matching a specific pattern.
Any reason you don't just do #{ \include #file #} here?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
@rlsrnamed{Name,Translation} translates also the name in the URI
Issue 1721 reported that @rlsr{Name} keeps the text in english but
translates the link in the translated manuals (no idea where the
translation comes from).
So it recommends to use @rlsrnamed{Name,Translation} instead.
But it looks like @rlsrnamed is affected by the same bug.
Looking through the log file of make doc I've found a lot of errors like
this:
WARNING: Unable to find node 'Hauteurs' in book snippets.
(look at NR 1.1, you'll find a lot of these broken links)
In general, go to the french NR and search for Morceaux choisis ::
you'll see that most of the links are broken.
There are some exceptions, for example this works:
http://lilypond.org/doc/v2.15/Documentation/notation/piano.fr.html
(Claviers link down on the page)
The syntax used is the same: @rlsrnamed{Name,Translation}.
Putting a space after the comma makes any difference.
I can't understand the reason of this weird behaviour.
Can you please explain what's happening?
Thanks,
Federico
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: include music-function
Hello David,
Any reason you don't just do #{ \include #file #} here?
yes there is:
--snip--
\version 2.15.21
#(define-public includeLocal (define-music-function (parser location
file)(string?)
(let ((outname (format ~A.ly (ly:parser-output-name parser)))
(locname (car (ly:input-file-line-char-column location
(if (or (string=? outname locname)(string-suffix? outname
locname))
#{ \include $file #}
(make-music 'SequentialMusic 'void #t)
\includeLocal test.ily
--snip--
this places the include in some context, generated by #{ #}.
So if I have:
--snip-- (test.ily)
\version 2.15.21
mus = \relative c' {
c4 e g c
}
{ \mus }
--snip--
it will fail, because I try to assign mus here in a contained context.
Cheers,
Jan-Peter
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: include music-function
Jan-Peter Voigt jp.vo...@gmx.de writes:
Hello David,
Any reason you don't just do #{ \include #file #} here?
yes there is:
--snip--
\version 2.15.21
#(define-public includeLocal (define-music-function (parser location
file)(string?)
(let ((outname (format ~A.ly (ly:parser-output-name parser)))
(locname (car (ly:input-file-line-char-column location
(if (or (string=? outname locname)(string-suffix? outname
locname))
#{ \include $file #}
(make-music 'SequentialMusic 'void #t)
\includeLocal test.ily
--snip--
this places the include in some context, generated by #{ #}.
Ah yes. ly:parse-file does not help either?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: include music-function
Hello David,
Am 05.01.2012 13:50, schrieb David Kastrup:
Ah yes. ly:parse-file does not help either?
yes it does, thanks ... but ...
--snip--
#(define-public includeLoc (define-music-function (parser location
file)(string?)
(let ((outname (format ~A.ly (ly:parser-output-name parser)))
(locname (car (ly:input-file-line-char-column location
(if (or (string=? outname locname)(string-suffix? outname
locname))
(ly:parse-file file))
(make-music 'SequentialMusic 'void #t
--snip--
I nowadays store the music in a scheme structure saved as a singleton in
a self-made module. If the included file refers to this singleton, the
music will appear ... great!
Before this, I created variables
--snip--
music = \relative c' { c4 e g c }
\includeLocal test-music.ly
--snip--
and used a file
--snip-- (test-music.ly)
{ \music }
--snip--
This does not work ... the var music is not known in the file included
with ly:parse-file.
There has been a function ly:parser-parse-file in 2.12 - and if my
memory doesn't trick me, there has been discussion on devel why and how
to remove it.
This might or might not have been useful in this context.
So a question remains: How could I carry defined variables between
inside-outside ly:parse-file ?
Cheers,
Jan-Peter
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: include music-function
Jan-Peter Voigt jp.vo...@gmx.de writes: This does not work ... the var music is not known in the file included with ly:parse-file. There has been a function ly:parser-parse-file in 2.12 - and if my memory doesn't trick me, there has been discussion on devel why and how to remove it. This might or might not have been useful in this context. Maybe. At that time, I was not acquainted with the code. So a question remains: How could I carry defined variables between inside-outside ly:parse-file ? With the current tools, I don't have much of an idea. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: include music-function
Jan-Peter Voigt jp.vo...@gmx.de writes: #(define-public includeLocal (define-music-function (parser location file)(string?) (let ((outname (format ~A.ly (ly:parser-output-name parser))) (locname (car (ly:input-file-line-char-column location (if (or (string=? outname locname)(string-suffix? outname locname)) (let ((content (ly:gulp-file file))) (ly:parser-include-string parser content))) (make-music 'SequentialMusic 'void #t \includeLocal test.ly --snip-- This function first compares the outname with the location name and only includes the file if they match. (This should not work, if you have set some output-suffix!) This is a usable solution to me. But I would like to have the correct location info available, while parsing the included file. Is it possible to create an arbitrary include-music-function? This would make it possible, to (for example) include all files in a directory or matching a specific pattern. You can start your string with \sourcefilename and \sourcefileline. ly:parser-parse-expression has optional arguments for that purpose. If you would consider this helpful, I might try fudging this into parser-include-string as well. I have not followed the reasons why we would not have parser-include-file. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Countdown to 20120108
For Sunday January 8th Issue 2170 http://code.google.com/p/lilypond/issues/detail?id=2170: Patch: Updates makelsr to point to lilypond exe - R5489134 http://codereview.appspot.com/5489134/ Some syntax comments from Graham, but they shouldn't hold up the countdown. Cheers, Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Implements DOM-id property for grobs. (issue 5504106)
LGTM https://codereview.appspot.com/5504106/diff/1/scm/output-ps.scm File scm/output-ps.scm (right): https://codereview.appspot.com/5504106/diff/1/scm/output-ps.scm#newcode258 scm/output-ps.scm:258: (define (open-node n) n) I don't see this procedure used anywhere... https://codereview.appspot.com/5504106/diff/1/scm/output-ps.scm#newcode261 scm/output-ps.scm:261: (define (close-node n) n) .. or this one. https://codereview.appspot.com/5504106/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
