Re: wrong position of rhythmic dots
I wonder whether a patch similar to * lily/stem.cc (position_noteheads): rounding error robustness. (from 2004-01-25) can fix the problem with incorrectly positioned rhythmic dots -- you told me that you can't repeat the problem. It *is* a rounding issue! In file dot-column.cc, function Dot_column::do_shifts, there is the call int p = int (Staff_symbol_referencer::get_position (dp.dot_)); in line 274. In file staff-symbol-referencer, function Staff_symbol_referencer::get_position, there is p += 2.0 * y / Staff_symbol::staff_space (st); in line 74. Checking with bc (setting the precision to 50 digits), there is the following arithmetic operation for this line (the values have been taken from a gdb session): 2.0 * -0.94494078742115484 / 0.6299605249474366 -2.99980951187376381606835665928357567868 Consequently, rounding with `int' gives -2 instead of the correct result -3. Doh, I don't want to check the lilypond source code for similar rounding problems... Werner ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: wrong position of rhythmic dots
[EMAIL PROTECTED] writes: Doh, I don't want to check the lilypond source code for similar rounding problems... I've now fixed all calls to Staff_symbol_referencer::get_positions. Thanks. Since this is a oft-recurring pattern, I've replaced all calls with a new function Staff_symbol_referencer::get_rounded_position() -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
problem with ties
[EMAIL PROTECTED] writes: I know that the code for ties and slurs needs a rewrite, but the positioning should be fine already, shouldn't it? IIRC, this also didn't work in 2.0 - I am deferring any fixes to 2.3. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: Documentation of Architecture / Design?
I have also misinterpreted the name Program Reference as Programming Reference. I don't really have any better suggestion, though. A long name could be Full documentation of all contexts, objects, properties, ... but we need something shorter. Mats Han-Wen Nienhuys wrote: [EMAIL PROTECTED] writes: All, I've recently gotten involved in the lilypond cause (2 bug fixes submitted, a couple of features underway). My problem is I don't have a firm understanding of how everything comes together. I've read through the Programmer's Reference (PR), but it isn't what I'm looking for. this document should be renamed. Any ideas for a better name? Maybe Program definitions? -- = Mats Bengtsson Signal Processing Signals, Sensors and Systems Royal Institute of Technology SE-100 44 STOCKHOLM Sweden Phone: (+46) 8 790 8463 Fax: (+46) 8 790 7260 Email: [EMAIL PROTECTED] WWW: http://www.s3.kth.se/~mabe = ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
RE: Documentation of Architecture / Design?
I think advanced users often use this reference, so what about calling it Advanced Reference or a similar name, which is from a user's point of view. I have also misinterpreted the name Program Reference as Programming Reference. I don't really have any better suggestion, though. A long name could be Full documentation of all contexts, objects, properties, ... but we need something shorter. ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: info problems
Date: Fri, 19 Mar 2004 10:37:04 +0100 (CET) From: Werner LEMBERG [EMAIL PROTECTED] Hmm. If I now say `info lilypond', I don't see the top lilypond page but `5 Invoking LilyPond', one level too deep. That is because that node name is an exact match: * lilypond: (lilypond/lilypond)Invoking LilyPond. Titling LilyPond scores. If you type `info GNU LilyPond', you get the top page. If the Invoking LilyPond node is renamed to something that matches worse, you get the top page. Do we want that. Suggestions for a name? The name is OK -- there is no better name. Other info files like that for dvips have the same problem. I suggest to add a new command to texinfo which maps certain command line arguments to certain nodes, e.g. @commandlineargtonode lilypond,top This will cause more trouble than help, I think: when a user types info lilypond it is not at all clear to me that she wants to see the Top node. It is IMHO much better to modify the @direntry line so that the resultant DIR menu item says * Using lilypond: (lilypond/lilypond)Invoking LilyPond. Titling LilyPond scores. or some such. In general, it's a bad idea to have Usage style nodes referenced by menu items that are labeled with the program's name. ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: install-info problems
install-info: menu item `mup2ly' already exists, for file `lilypond/lilypond' Well, the error message is misleading (I'll look into that), but install-info sorts entries within sections. I think that's why nothing is happening? k P.S. Thanks for reporting the offset bug. I'm going to be gone for a couple days, but I'll work on it when I get back later this week, if Alper doesn't get to it first. (Alper, I'll send you the input files in case ...) ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: info problems
Hello, On Sat, Mar 20, 2004 at 04:55:21PM +0200, Eli Zaretskii wrote: How about info libc printf vs info bash printf the former doesn't get me to the printf basics, though. I have to use: info (libc)Formatted Output But that's not problem of info. The later doesn't exist on my system; one has to know that info coreutils printf is the right one. I'm afraid man 1 and man 3 was much easier to remember. And if I forget what's the number of section 5, I can always run eg. man mount and go to the SEE ALSO section. Have a nice day, Stepan Kasal ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
problematic output v2.1.33.hwn1
When I saw Han-Wen's post on info-lilypond about serious problems with
randomly misplaced symbols being fixed I was optimistic. I compiled
and tried it out. While some of the issues were fixed (no more
phantom beams floating around, for example...) I'm now getting some
really bizarre spacing problems. I've got bar lines slicing through
whole measure rests. (!!!)
Also, if I recall correctly, there was a short thread recently about key
changes and bar lines. I remember that this same topic came up some
months back because I brought it up. I had to use break-align-order (or
somesuch) to change it to suit me. Then, soon thereafter, the default
behavior of Lily was altered to do exactly what I wanted. Now it seems
to have been changed again.
Two or three revisions ago, at a linebreak/key change Lily did:
bar line / cancelled key / new key / new line
Now, as of 2.1.33.hwn1:
cancelled key / new key / barline / new line
This short example illustrates it:
\score {
\notes {
\clef F
\time 4/4
\key f \major
f1 \bar || \break
\key g \major
g1
}
\paper {linewidth = 6 \cm}
}
I performed a reality check to be sure I was not talking nonsense. I
looked at linebreak/keychanges in rehearsal this morning and it was as I
thought it should be. That is: barline / cancelled key (optional) / new
key / line break
This was in a couple of Breitkopf H\artel printings as well as a
Boosey and Hawkes printing. After rehearsal I looked through my library
and found that no matter what kind of printing, the practice was:
barline / cancelled key / new key / line break
Whether it was real engraved (with stamps, hammers, and gougers) music,
photoreproduced manuscript or even gasp
Finale/Sibelius/Score/What-have-you. **Occasionally** the order was:
cancelled key / barline / new key
..but this was the exception rather than the rule.
I don't mean to lecture anybody on the topic. I'm just saying that
until very recently LilyPond was doing this chore just fine and now I
think it has gone wrong.
I'm also wondering if this has anything to do with the weird spacing.
-David
___
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel
squished rests [was: problematic output]
I don't have a demo *.ly file just yet, but a bit of experimentation has led me to believe that perhaps there is something amiss with the default value of MultiMeasureRest #'minimum-length. At least when I did \override I could force them wider. In one case when I did this I found that a bar line which occured after a 4 bar rest had been pushed so far to the left (before \override-ing ) that it was actually to the left of the 4-bar rest symbol. I checked to see if I had forced the minimum-length to some tiny amount but all of my \override commands were done with '\once', and done to make the rests wider not narrower. If this is still not enough information for you to track this down I'll try to make a demo *.ly file. -David ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: wrong position of rhythmic dots
Since this is a oft-recurring pattern, I've replaced all calls with a new function Staff_symbol_referencer::get_rounded_position() I was just about to commit an overloaded function for `int'. :-) Werner ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
script-abbreciations.ly: text attatchments broken
Hi,
I just built 2.1.33, and since the script-abbreviations.ly is still
completely broken, I kind of repaired it (see attachment).
Unfortunately, it's still incorrect (wrong characters for `|' and `'
due to math mode), but at least now it displays something reasonable.
Ciao,
Kili
% this chart is used in the manual too.
\version 2.1.33
\header { texidoc = @cindex Script Abbreviations
Some articulations may be entered using an abbreviation.
}
\score {
\notes \context Voice {
\override TextScript #'font-family = #'typewriter
\override TextScript #'font-shape = #'upright
c''4-._c-. s4
c''4--_c-{}-s4
c''4-+_c-+ s4
c''4-|_c-$|$s4
c''4-_c-$$s4
c''4-^_c-\^~s4
c''4-__c-\_ s4
}
}
___
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel
script-abbreciations.ly: text attatchments broken
[EMAIL PROTECTED] writes: Hi, I just built 2.1.33, and since the script-abbreviations.ly is still completely broken, I kind of repaired it (see attachment). This is already fixed in CVS. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: reading material?
Agreed. We're off target. And I'm not trying to start a flame war. I really
don't want to start an argument. I just want to I promise not to post any more
to this thread (unless, of course I change my mind ;) ).
We're going off-topic here, but I'm pretty sure that you know as well
as I that Hi and there are (char const*). The STL is better than
nothing, but to me a library does not qualify as built-in.
Yes, Hi and there are char const*, but in my example, the strings were x and
y.
string x = Hi ;
string y = there.;
cout x + y endl; // concatenation
The string objects have all the expected member functions, like length,
substring access, the == operator, the operator, etc.
And the STL is fully standardized and an integral part of the new C++
definition. It's kind of like saying the base C language doesn't support output
because printf is supported in the standard library. If you think this, then at
least you're consistent, and we know where our differences are.
First-class means first-class citizens, that is, objects of that type
can be used in all language constructs just like other objects. For
example, a function that returns a function in Scheme is natural,
(define (iterate func k)
Produce the function x - FUNC(FUNC .. (x) .. )
(if ( k 0)
(lambda (x) (func ((iterate func (1- k)) x)))
(lambda (x) x)))
(define to-6th-power (iterate sqr 3))
If you're suitably masochistic, then you could come up with a C++
solution, but I doubt it would be natural or elegant. Besides, I don't
appreciate masochism when it comes to programming.
Actually, this will calculate x ^ (2 ^ 3), so the procedure should be named
to-eighth-power, but be that as it may...
The C++ solution is both natural and elegant. Two example solutions follow, the
first not using templates, the second using templates. By the way, my favorite
reference for using the Standard Template library, as well as things like these
functor classes, is Nicolai M. Josuttis, The C++ Standard Library, 1999.
Example 1:
==
#include iostream
using namespace std;
class Function
{
public:
virtual int operator() (int x) = 0;
};
class Square : public Function
{
public:
virtual int operator() (int x) { return x * x; }
};
class Iterate
{
public:
Iterate (Function f, unsigned int i) : func(f), iters(i) { }
int operator() (int operand)
{
for (int i = 0; i iters; ++i)
{
operand = func(operand);
}
return operand;
}
private:
Function func;
int iters;
};
int main()
{
Square s;
Iterate tripleSquared(s, 3);
cout tripleSquared(2) endl;
return 0;
}
==
Example 2:
==
#include iostream
using namespace std;
class Square
{
public:
virtual int operator() (int x) { return x * x; }
};
template typename FUNCTOR, typename TYPE
class Iterate
{
public:
Iterate (unsigned int i) : iters(i) { }
TYPE operator() (TYPE operand)
{
FUNCTOR func;
for (int i = 0; i iters; ++i)
{
operand = func(operand);
}
return operand;
}
private:
int iters;
};
int main()
{
IterateSquare, int tripleSquared(3);
cout tripleSquared(2) endl;
return 0;
}
___
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel
Why not to implement everything in scheme?
Why not to implement everything in scheme and get rid of gcc -compiling of the source? Or, is it the lexical parser which forces the use of gcc? -- Heikki Junes ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: reading material?
On Mon, Mar 22, 2004 at 12:51:12PM -0600, Douglas A Linhardt wrote: Agreed. We're off target. And I'm not trying to start a flame war. I really don't want to start an argument. I just want to I promise not to post any more to this thread (unless, of course I change my mind ;) ). Please don't take any of my comments on this as being flames in any way, either. But I can't resist a good language debate. First-class means first-class citizens, that is, objects of that type can be used in all language constructs just like other objects. For example, a function that returns a function in Scheme is natural, (define (iterate func k) Produce the function x - FUNC(FUNC .. (x) .. ) (if ( k 0) (lambda (x) (func ((iterate func (1- k)) x))) (lambda (x) x))) (define to-6th-power (iterate sqr 3)) ... The C++ solution is both natural and elegant. Two example solutions follow, the first not using templates, the second using templates. By the way, my favorite reference for using the Standard Template library, as well as things like these functor classes, is Nicolai M. Josuttis, The C++ Standard Library, 1999. Frankly, I would suggest that after studying some of these languages more, particularly ocaml, haskell, and common lisp, you might have a different attitude. What you did idiomatically in 34 lines, he did idiomatically in 7 lines, counting whitespace and comments. Also, his version has no problems if the function takes a string instead of an int, for example. And, if it were written in ocaml, like so: let rec iterate f k = if k == 0 then fun x - x else iterate (fun x - f x) (k - 1) ;; let sqr x = x * x;; let laugh x = x ^ ha;; Then one can do: let pow_8 = iterate sqr 3;; let guffaw = iterate laugh 5;; Printf.printf %d %s\n (pow_8 2) (guffaw bwa);; and yet, (guffaw 2) or (pow_8 bwa) will be detected as an error at compile time, not run-time. Now imagine you'd like to iterate (really, composite) functions with various type signatures. Or partially apply a function, like: let nonsense prefix suffix = prefix ^ bar ^ suffix;; let n = nonsense foo;; Printf.printf %s\n (n baz);; These are just a few things among many that are much more arduous to do in C++, certainly more lengthy, when one's time is better spent on better tasks than housekeeping. [Let's hope all that code is correct, I haven't checked it carefully... hopefully you get the point. ;-)] Arguments like these can go on forever, but truly, (and I feel sad for saying this, as I'll explain momentarily,) I recommend some of Paul Graham's essays: http://www.paulgraham.com/avg.html or http://www.paulgraham.com/icad.html I give the caveat that when I came across the first, I was highly skeptical, and though I still don't agree entirely with what Graham is saying, it wasn't until I spent a while writing some serious code in a few languages more expressive than C++ that I finally conceded that he has a point. I still have to write a lot of C++ at work, but at least now I know better than to propose it when I have the choice. Cheers. -- Julian Squires ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: Why not to implement everything in scheme?
On Mon, Mar 22, 2004 at 09:01:17PM +0200, Heikki Johannes Junes wrote: Why not to implement everything in scheme and get rid of gcc -compiling of the source? Or, is it the lexical parser which forces the use of gcc? Let's not forget that scheme can be compiled into fast code (see bigloo etc). I'd love to see lilypond become 100% scheme (or, in my preference, common lisp, simply for the standard environment... also, some of the compilers still seem to produce faster code). But I suspect that would be a rather mammoth undertaking. Cheers. -- Julian Squires ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: Why not to implement everything in scheme?
On Mon, Mar 22, 2004 at 08:37:24PM +0100, Nicolas Sceaux wrote: I'm not sure that there will be pletor of volonteers for recoding thousands of C++ LOC in whatever other language. You just have to write a C++2scm translator ;-) hmmm, thinking of it... I volonteer for LilyPond in Common Lisp!!! cliclypond is so easier to pronounce. I'd prefer RubyPond :-) To be serious: the current implementation is o.k., and, IIRC, Han-Wen mentioned in the interview at linuxmusician.com that the C++ part is planned to shrink away. I also thought a lot of wether using scheme/guile as semi-backend is the best choice. It's a matter of taste and readability. Personally, I don't like scheme very much; allthough it's small and easy to learn, it's IMHO difficult to read and looks ugly. Thus, using something like Ruby *may* be an alternative, possibly attracting more volunteers, possibly not. Anyways. Wether you like/disklike C++, Scheme, Ruby, Python, Haskell, whatever: those who do participate in active LilyPond development should concentrate on improving LilyPond, not in using endless time by changing the languages used. At least not until a certain point of stabilization has been reached. Ciao, Kili ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: Why not to implement everything in scheme?
Mon, 22 Mar 2004 21:00:01 +0100, Matthias a dit : On Mon, Mar 22, 2004 at 08:37:24PM +0100, Nicolas Sceaux wrote: I'm not sure that there will be pletor of volonteers for recoding thousands of C++ LOC in whatever other language. You just have to write a C++2scm translator ;-) hmmm, thinking of it... I volonteer for LilyPond in Common Lisp!!! cliclypond is so easier to pronounce. I'd prefer RubyPond :-) To be serious: the current implementation is o.k., and, IIRC, Han-Wen mentioned in the interview at linuxmusician.com that the C++ part is planned to shrink away. I also thought a lot of wether using scheme/guile as semi-backend is the best choice. It's a matter of taste and readability. Personally, I don't like scheme very much; allthough it's small and easy to learn, it's IMHO difficult to read and looks ugly. Thus, using something like Ruby *may* be an alternative, possibly attracting more volunteers, possibly not. Anyways. Wether you like/disklike C++, Scheme, Ruby, Python, Haskell, whatever: those who do participate in active LilyPond development should concentrate on improving LilyPond, not in using endless time by changing the languages used. At least not until a certain point of stabilization has been reached. Ciao, Kili You're unfair, you have deleted my smiley when quoting me. It was the short way for expressing your last paragraph (sort of). ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: reading material?
[EMAIL PROTECTED] writes: If you're suitably masochistic, then you could come up with a C++ solution, but I doubt it would be natural or elegant. Besides, I don't appreciate masochism when it comes to programming. Actually, this will calculate x ^ (2 ^ 3), so the procedure should be named to-eighth-power, but be that as it may... The C++ solution is both natural and elegant. Two example solutions follow, the I think we have a fundamental disagreement about the meaning of natural and elegant. Let's not continue this discussion. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: Why not to implement everything in scheme?
Julian Squires wrote: On Mon, Mar 22, 2004 at 09:01:17PM +0200, Heikki Johannes Junes wrote: Why not to implement everything in scheme and get rid of gcc -compiling of the source? Or, is it the lexical parser which forces the use of gcc? Let's not forget that scheme can be compiled into fast code (see bigloo etc). I'd love to see lilypond become 100% scheme (or, in my preference, common lisp, simply for the standard environment... also, some of the compilers still seem to produce faster code). But I suspect that would be a rather mammoth undertaking. Bigloo produces C code which would then have to be compiled with gcc anyway. Paul ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Why not to implement everything in scheme?
[EMAIL PROTECTED] writes: Why not to implement everything in scheme and get rid of gcc -compiling of the source? Or, is it the lexical parser which forces the use of gcc? I like Scheme very much, but I'm not sure still whether it's a comfortable system for implementing large systems. I have my doubts about code readability, and the fact that it is rather weakly and dynamically typed. Anyway, this discussion is academic, since we have a huge body of working C++ code, and we are not going to scrap that. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: Why not to implement everything in scheme?
[EMAIL PROTECTED] writes: I'd prefer RubyPond :-) To be serious: the current implementation is o.k., and, IIRC, Han-Wen mentioned in the interview at linuxmusician.com that the C++ part is planned to shrink away. I also thought a lot of wether using scheme/guile as semi-backend is the best choice. It's a matter of taste and readability. Personally, I don't like scheme very much; allthough it's small and easy to learn, it's IMHO difficult to read and looks ugly. Thus, using something like Ruby *may* be an alternative, possibly attracting more volunteers, possibly not. Anyways. Wether you like/disklike C++, Scheme, Ruby, Python, Haskell, whatever: those who do participate in active LilyPond development should concentrate on improving LilyPond, not in using endless time by changing the languages used. At least not until a certain point of stabilization has been reached. For the interested reader - when we were considering an extension system, we also thought about Python. However, python did not have garbage collection, its objects seemed rather heavyweight (memory wise) and the scoping rules were counter intuitive. A big bonus point for Scheme/LISP was the #( .. ) lexer hack, which is not really possible in other languages. That hack made it really very easy to gradually migrate the file format to syntactic sugar for Scheme. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
'make all' fails
CVS ChangeLog 1.939 exits thusly: cp -p /usr/src/lilypond/config.h out/config.h rm -f ./out/accidental.dep; DEPENDENCIES_OUTPUT=./out/accidental.dep ./out/accidental.o g++ -c -DHAVE_CONFIG_H -DSTRING_UTILS_INLINED -Iinclude -I./out -I../flower/include -I../flower/./out -I../flower/include -O2 -finline-functions -g -pipe -I/usr/include/python2.2 -O2 -finline-functions -g -pipe -I/usr/include/python2.2 -W -Wall -Wconversion -o out/accidental.o accidental.cc rm -f ./out/accidental-engraver.dep; DEPENDENCIES_OUTPUT=./out/accidental-engraver.dep ./out/accidental-engraver.o g++ -c -DHAVE_CONFIG_H -DSTRING_UTILS_INLINED -Iinclude -I./out -I../flower/include -I../flower/./out -I../flower/include -O2 -finline-functions -g -pipe -I/usr/include/python2.2 -O2 -finline-functions -g -pipe -I/usr/include/python2.2 -W -Wall -Wconversion -o out/accidental-engraver.o accidental-engraver.cc accidental-engraver.cc: In member function `virtual void Accidental_engraver::acknowledge_grob(Grob_info)': accidental-engraver.cc:444: cannot convert `const char*' to `scm_unused_struct* ' for argument `1' to `bool to_boolean(scm_unused_struct*)' make[1]: *** [out/accidental-engraver.o] Error 1 make[1]: Leaving directory `/usr/src/lilypond/lily' make: *** [all] Error 2 [EMAIL PROTECTED] lilypond]# -David ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
