Does it really make sense to have a separate bug-lilypond list?
David
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Han-Wen Nienhuys writes:
> I believe there are issues with STL that we hacked workarounds for. We
> want to loose the workarounds.
Those are in 4.1; we'll probably have to hold off for a bit. I don't
think it makes sense to demand a compiler version that is not
necessary to have yet; better do t
Also index entries using the word blank rather than empty.
David Feuer
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
> > [...], but I can't find out how to generate a sheet of empty
> staves.
>
> Section 8.5.2 Blank music sheet
Perhaps adding index entries, something like
@cindex staves, empty, sheet
@cindex sheet, empty staves
@cindex empty staves, sheet
Werner
__
> I believe there are issues with STL that we hacked workarounds for. We
> want to loose the workarounds.
Hmmm. Is this really of urgent importance? Well, I'll modify
configure.in before compiling...
Werner
___
lilypond-devel mailing list
lil
> > I've fixed it by myself in the CVS :-)
>
> cool! don't forget to backport.
How do I do this?
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Carl D. Sorensen wrote:
[ideas for separate tweaks]
Is this the kind of functionality you're after, David? And is this
doable in lilypond?
note that there is an even much more advanced mechanism for doing
separate tweaks, with the -f gnome backend. Unfortunately, it has fallen
into disuse.
David Feuer wrote:
I think this patch should fix it.
Changelog:
* music-drawing-routines.ps (draw_round_box): removed testing artifact.
(draw_circle): Hopefully fixed regression.
Improved documentation for several procedures.
thanks, applied.
just a nitpick. Could you also add the
200
I think this patch should fix it.
Changelog:
* music-drawing-routines.ps (draw_round_box): removed testing artifact.
(draw_circle): Hopefully fixed regression.
Improved documentation for several procedures.
David Feuer
fix.diff
Description: Binary data
_
I think there are two things that are getting mixed up in this
discussion.
The first is the general layout of the music (fonts, size, etc.) that
can be taken care of by global tweaks, and included at the top of the
.ly file. This capability is just fine. And I don't think that this is
the issue
Han-Wen Nienhuys wrote:
You are partially right. The graphical part is still powerpc. However,
the real typesetting program (which you can find inside the .app folder)
has been compiled for intel natively. If in doubt, you can try to
measure the speed of the ppc version on your intel mac.
Of
On 4/5/06, Erlend Aasland <[EMAIL PROTECTED]> wrote:
> Hi David,
>
> Your recent changes to the PS code makes all circles look rather weird (they
> contain a straigt line from the center to the right of the circle, and the
> circle itself is misplaced). I fixed this with the attached patch, but sin
Joshua Parmenter wrote:
Hi,
The Intel builds listed here:
http://lilypond.org/web/install/
appear to actually be for PPC. Both 2.8 and 2.9 show up as
Applications(PowerPC) when get-info is done from the Finder, rather then
Application(Universal) or Application(Intel).
LiliPond runs okay un
On 5-Apr-06, at 3:21 PM, Seb James wrote:
I've had a look at the tutorials for lilypond. The documentation is
very
good, but I can't find out how to generate a sheet of empty staves. Can
anyone on the list offer a quick pointer or recipe to help me do this?
Section 8.5.2 Blank music sheet
-
Hi,
The Intel builds listed here:
http://lilypond.org/web/install/
appear to actually be for PPC. Both 2.8 and 2.9 show up as
Applications(PowerPC) when get-info is done from the Finder, rather
then Application(Universal) or Application(Intel).
LiliPond runs okay under Rosetta, but I thou
Hi there,
I've had a look at the tutorials for lilypond. The documentation is very
good, but I can't find out how to generate a sheet of empty staves. Can
anyone on the list offer a quick pointer or recipe to help me do this?
kind regards,
Seb James
--
Embedded Software Foundry Ltd. 'Embedded
Werner LEMBERG wrote:
Why do you enforce g++ 4.0 for 2.9?
My g++ 3.3.3 works just fine.
I believe there are issues with STL that we hacked workarounds for. We
want to loose the workarounds.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
--
Werner LEMBERG wrote:
The bug report below surprisingly gives no warning. In real-life
situations I get
warning: junking event: `BeamEvent'
\acciaccatura { f16[ g
] }
Maybe there is a simple fix for it...
I've fixed it by myself in the CVS :-) BTW, the above m
Agree.
But much of the style and markup must be applied to individual notes.
A way to separate the syle from the data is what is needed.
Notes are data, how the notes are displayed is style. So a means needs to
be devised whereby the style and markup can be applied to a certain note
OUTSID
> The bug report below surprisingly gives no warning. In real-life
> situations I get
>
> warning: junking event: `BeamEvent'
> \acciaccatura { f16[ g
> ] }
>
> Maybe there is a simple fix for it...
I've fixed it by myself in the CVS :-) BTW, the above message is
Why do you enforce g++ 4.0 for 2.9?
My g++ 3.3.3 works just fine.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
- Original Message -
From: "David Feuer" <[EMAIL PROTECTED]>
To: "lily-devel"
Sent: Tuesday, April 04, 2006 10:57 AM
Subject: Style
I'm sure someone has brought this up before, but I've been thinking a
bit about the way users tweak output in Lilypond.
As it is, tweaks
are generally
On 4/5/06, Erlend Aasland <[EMAIL PROTECTED]> wrote:
> On 4/5/06, Trevor Bača <[EMAIL PROTECTED]> wrote:
>
> >
> > Yes, actually perhaps a touch smaller. Can we run a couple of examples
> > at maybe 20% less diameter and see?
>
>
> Will do. I've just cleaned the build directory so I'll have to do a
On 4/5/06, Trevor Bača <[EMAIL PROTECTED]> wrote:
Yes, actually perhaps a touch smaller. Can we run a couple of examplesat maybe 20% less diameter and see?Will do. I've just cleaned the build directory so I'll have to do a recompile (I wont do that until tomorrow, have to work now...) I've attached
Hi David,Your recent changes to the PS code makes all circles look rather weird (they contain a straigt line from the center to the right of the circle, and the circle itself is misplaced). I fixed this with the attached patch, but since I'm not PS expert, perhaps you could verify that this look go
On 4/5/06, Erlend Aasland <[EMAIL PROTECTED]> wrote:
> On 4/4/06, Marcus Macauley <[EMAIL PROTECTED]> wrote:
>
> > (If I felt like being nitpicky, I would point out two things. One, IMHO,
> > the circle is still slightly too large. Not much, and arguably not at all,
>
>
> Well, the only real exampl
On 4/4/06, Marcus Macauley <[EMAIL PROTECTED]> wrote:
(If I felt like being nitpicky, I would point out two things. One, IMHO,the circle is still slightly too large. Not much, and arguably not at all,Well, the only real examples I've seen is the scans that Trevor sent me... It is no problem to make
Hi,
On Wed, 5 Apr 2006, Han-Wen Nienhuys wrote:
> Pedro Kröger wrote:
> > Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> >
> > > Hmmm; part of the problem might also stem from using CVS, which
> > > doesn't have good cherry-picking for patches.
> >
> > would it be a solution to use darcs only f
On 5-Apr-06, at 5:23 AM, Han-Wen Nienhuys wrote:
Graham Percival wrote:
In addition, if Erik's music streams are in place in 2.10, then users
who don't want to manually upgrade syntax on old completed files have
the option of using the streams (which is the whole point of them,
right?) If
Han-Wen Nienhuys wrote:
If we go this route, we could better do it right immediately, and setup
a bzr/darcs/monotone/git/etc. based infrastructure rightaway.
I mean, for the entire lilypond repository.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software
Pedro Kröger wrote:
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
Hmmm; part of the problem might also stem from using CVS, which
doesn't have good cherry-picking for patches.
would it be a solution to use darcs only for the manual? I know there
are some ways of syncing darcs and cvs, so maybe
Graham Percival wrote:
In addition, if Erik's music streams are in place in 2.10, then users
who don't want to manually upgrade syntax on old completed files have
the option of using the streams (which is the whole point of them,
right?) If you look at it that way, wouldn't we be absolutely c
Han-Wen Nienhuys wrote:
// Collect all listener lists.
struct { int prio; SCM list; } lists[num_classes+1];
int i = 0;
for (SCM cl = class_list; cl != SCM_EOL; cl = scm_cdr (cl))
also, always use scm_is_pair() iso. checking for SCM_EOL.This will
crash on malformed lists.
--
H
On 5-Apr-06, at 4:49 AM, Han-Wen Nienhuys wrote:
Graham Percival wrote:
If the hackers are fine with this, I'm certainly happy with this
solution. I take it that we're still in the bug-fixing stage?
(since 0 recently came out, we have a lot of new interest, finding
more bugs, pointing out
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Hmmm; part of the problem might also stem from using CVS, which
> doesn't have good cherry-picking for patches.
would it be a solution to use darcs only for the manual? I know there
are some ways of syncing darcs and cvs, so maybe the doc stays in cv
Erik Sandberg wrote:
Some known issues:
- scm/define-event-classes.scm contains rather unsorted functions which are
i'm missing that file.
- The Stream_event class duplicates its 'context property with a context_
member; this was originally intended to give speedups, but it is broken in
thi
Graham Percival <[EMAIL PROTECTED]> writes:
>> 5. Provide a unified documentation and mark features with a version
>>number, say,
> I suppose that this is possible... but IMO this would completely
> clutter the manual with unnecessary info.
I think that a compromise would work. Instead of ha
Erik Sandberg wrote:
On Tuesday 04 April 2006 20.42, Han-Wen Nienhuys wrote:
I'd start with 4. because they're independent from the rest, and we can
readily test the rest of those.
I'm now reworking repeats. While I'm at it, I attempt to generally clean up
the repeat code.
No, better not. I
Graham Percival wrote:
2. -> we've been trying to do this for ages, and for the 2.8 it's
almost worked (9 months).
The real problem is that all hackers should agree on a single period
were nothing but bugfixing happens. It might be a good thing to just
use the Linux 2.6 model, where we have
The bug report below surprisingly gives no warning. In real-life
situations I get
warning: junking event: `BeamEvent'
\acciaccatura { f16[ g
] }
Maybe there is a simple fix for it...
Werner
==
On Tuesday 04 April 2006 20.42, Han-Wen Nienhuys wrote:
> I'd start with 4. because they're independent from the rest, and we can
> readily test the rest of those.
I'm now reworking repeats. While I'm at it, I attempt to generally clean up
the repeat code.
Plan:
- Move some repeat C++ code from
On 5-Apr-06, at 2:51 AM, Han-Wen Nienhuys wrote:
Graham Percival wrote:
2. Much shorter devel periods (say, four months). New users still
get confused and ask questions about things which I've already
clarified,
3. Once a month, somebody goes through the tiresome process of
sifting thro
Graham Percival wrote:
2. Much shorter devel periods (say, four months). New users still get
confused and ask questions about things which I've already clarified,
3. Once a month, somebody goes through the tiresome process of sifting
through differences between the devel and stable manuals
On 5-Apr-06, at 12:45 AM, Werner LEMBERG wrote:
5. Provide a unified documentation and mark features with a version
number, say,
This feature appeared in version 2.7.38.
Ideally, such things belong into the margin, but...
I suppose that this is possible... but IMO this would comp
> 4. For the first half of the development cycle, don't include new
> features in the manual. New things get listed in NEWS, but only there.
> I favor this solution. At first glance, it might suggest that new
> features won't get documented well, but it should have the opposite
> effect:
Hi all,
In the past, there have been periods of half a year (or more) when Mats
and I suggest that users should read the development manual instead of
the stable manual. Most of the changes I make to the manual apply to
the stable branch as well, but due to technical and time
considerations,
46 matches
Mail list logo
