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,
[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
[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
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]
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
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:
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
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
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
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
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
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
%
[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
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
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]
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
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).
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!!!
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,
[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
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
[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
[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
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
24 matches
Mail list logo
