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
[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
[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
On Mon, Mar 22, 2004 at 02:06:11PM -0700, Paul Scott wrote:
> Bigloo produces C code which would then have to be compiled with gcc anyway.
g++ produces assembler which would then have to be assembled with gas
anyway. Languages are for the programmer's benefit. (It's interesting
to note that bigl
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 fa
[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 b
Mon, 22 Mar 2004 12:51:12 -0600, Douglas a dit :
>> (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 ma
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 ;-)
>>
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!
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?
The general idea would be that C++ is compiled and scheme is
interpreted. The heavy calculations should often be more e
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 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
Bonjour Heikki!
Mon, 22 Mar 2004 21:01:17 +0200 (EET), tu as dit :
> 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'm not sure that there will be pletor of volonteers for recoding
thousands o
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/
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
[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
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
% t
> 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
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 . 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 re
On Mon, 2004-03-22 at 15:17, Han-Wen Nienhuys wrote: I've got bar lines
slicing through
> > whole measure rests. (!!!)
>
> Can you send a demonstration .ly ?
I'll try. Recently I, and others, have had trouble reproducing strange
output with short files.
>
> Now it seems
> > to have been chan
[EMAIL PROTECTED] writes:
> 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 ge
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
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
> Date: Fri, 19 Mar 2004 12:00:10 -0500
> From: [EMAIL PROTECTED] (Karl Berry)
>
> > * lilypond: (lilypond/lilypond)Invoking LilyPond. Titling LilyPond scores.
>
> How about simply not including that entry, and just have the top-level
> entry?
Indeed.
> This ties into another topic, hand
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
> 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:
> >
> > * lilypo
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
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 PROTECTE
[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/~hanw
[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
I know that the code for ties and slurs needs a rewrite, but the
positioning should be fine already, shouldn't it?
Werner
==
%
% This file shows problems with ties in lilypond
% CVS 2004-03-21 17:12 MET.
%
% . For chords
> 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.
Werner
___
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/lis
> 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, fu
33 matches
Mail list logo
