Re: Several thoughts for implementing accordion standard bass support
Han-Wen Nienhuys writes: > On Tue, Jan 19, 2010 at 11:55 AM, David Kastrup wrote: > StdbassEngraver = #`((listeners (note-event . ,(lambda (engraver event) (let* ((pitch (ly:event-property event 'pitch))) (ly:event-set-property! event 'pitch >>> >>> This looks wrong - engravers should not modify their inputs. Rather, >>> the engraver should create the Grob that you are interested in, or it >>> should acknowledge the grob created by another engraver. >> >> Obviously, I have no clue whatsoever about what I am doing, and this is >> the "poke with a stick until it works(TM)" approach. >> >> Could you give a code example or outline for either of the possibilities >> that you outlined? > > I am completely unsure what you are trying to achieve. Are you really > trying to typeset noteheads on a staff, or is it something else? I am trying to do exactly what the posted code _does_ right now. It works (maps notes to different octaves than entered, in particular mapping chord notes to the -1 octave ignoring inversions). At a future point of time, the criteria might get more intricate and I may want to analyze the resulting chords. But that is reasonably straightforward to do. So right now, I just want to do what the code already does. You are saying that it does this in a wrong way. So I am interested in the right way. One that does not work just by luck and won't fall apart into pieces in more complex situations. Thanks, -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Ties and slurs going into repeat alternatives
Han-Wen Nienhuys writes: > On Tue, Jan 19, 2010 at 7:36 PM, David Kastrup wrote: >> at a line break, ties and slurs are cloned in order to reappear after >> the line break. >> >> The same cloning should happen for repeat alternatives: a slur or tie >> that is started before the alternatives block needs to be present/cloned >> at the start of _all_ alternatives, not just the first alternative. >> >> Is there a routine that does most of the cloning business so that it is >> reasonably easy to fix the behavior of \repeat volta? > > The problem is that the 2nd slur needs to be wired to other > noteheads/stems/etc. for the formatting to come out correctly, while > around linebreaks, all of the rewiring can be done generically. I am not sure I understand. For all but the first repeat alternative (which would retain the current behavior), the alternative _is_ detached from the common repeat part. So it would appear that the situation is quite comparable to a linebreak. There is a problem concerning editor support: a tie started in the common repeat part will need to be ended in all alternatives, so the input contains what looks like unbalanced ties (more closing than opening ones). I don't see that anything else makes sense, however. One possibility would be to provide strict aliases \startTie and \endTie for ( and ) that would presumably be transparent to editors' paren matching facilities. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch: issue #659
Trevor Daniels schrieb: [...] I would not worry about this. As Alexander has pointed out, examples showing the staff lines extending through the sign and not extending through the sign can be found. It is easy for a user to move the sign to the end of the staff lines with \once \override Score.BarLine #'extra-offset = #'(1 . 0) \once \override Score.SpanBar #'extra-offset = #'(1 . 0) if this was really wanted, although this would admittedly push it into the right margin. Trevor, Alexander, thanks for your messages and your suggestions. Would it make sense to provide another varsegno symbol which looks exactly as the one I have drawn, but has no positive witdh (to the right of the center)? When I use this sign in "S." situations, the staff lines would end in the middle of the sign, as it is in the example mentioned in the tracker. Or is there a more elegant solution? Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch: issue #659
Marc Hohl wrote: Trevor Daniels schrieb: It is easy for a user to move the sign to the end of the staff lines with \once \override Score.BarLine #'extra-offset = #'(1 . 0) \once \override Score.SpanBar #'extra-offset = #'(1 . 0) if this was really wanted, although this would admittedly push it into the right margin. Indeed. It's not quite exactly '(1 . 0), but just slightly less, but this is nearly not noticeable. Would it make sense to provide another varsegno symbol which looks exactly as the one I have drawn, but has no positive witdh (to the right of the center)? This sounds more elegant than the tweak above, but I'm not sure if this alone is worth the effort of an additional symbol. Another idea: Is it possible to have a double bar line at the end of a line, and the segno bar line at the beginning of the next? What about ".S" doing this, as opposed to "S", or have an additional "||S" and "S||"? Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
doc correction
In the german documentation : 2.4.1 Übliche Notation für gebundene Saiteninstrumente Angepasste Tabulaturen 3. paragraph last sentence: "Die vordefinierten Stimmungen finden sich in scm/output-lib.scm." This should read: "Die vordefinierten Stimmungen finden sich in scm/tabulature.scm." html-page = Common-notation-for-fretted-strings#Custom-tag All the best Hajo --- ... indessen wandelt harmlos droben das Gestirn ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enhancement: Page breaking to avoid widow lines
Quoting Joe Neeman : Again, I'd suggest uploading patches to codereview.appspot.com, which provides nice formatting and makes it easy to have multiple reviewers. Are there lilypond patches discussed there already? I looked around the list of repositories, but I can't find Lilypond. Is there anything special that I missed? Boris Shingarov Work on Lilypond under grant from Sonus Paradisi / Jiri Zurek (Prague), Czech Science Foundation, Project No. 401/09/0419 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB buiding from a local source tree?
Quoting Graham Percival : I'm completely serious. My GUB tree is *filled* with ugly hacks like this. It would be nice if they weren't needed, but it'll probably take 20-50 more hours of work until this is the case. Oh, I completely understand this. And this is the exact reason why I am asking questions, because when the code is this rough, there are things that are better to just ask, rather than to try to figure out "why" -- because we are not dealing with something finished but a thought-in-progress. If you're frustrated already, then I honestly think you should give up now, because it will only get worse from now on I completely realize what kind of complexity we are talking about. And no, I am not at all frustrated. Not from a technical viewpoint anyway. But for me the whole thing about GUB is driven by the organizational side: as a developer, I am completely happy with the Linux development platform, and am much more interested in furthering Lilypond rather than trying to deploy it on a platform I don't even use. But then there is the end-users who want to see it on Windows, but then again they want to see progress in Lilypond development, and the prospect of losing weeks to porting to Windows, makes them want to reconsider their platform preferences. We'll see. As I already said, at this point it's about organizational questions, not technical ones. Boris Shingarov Work on Lilypond under grant from Sonus Paradisi / Jiri Zurek (Prague), Czech Science Foundation, Project No. 401/09/0419 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enhancement: Page breaking to avoid widow lines
On Wed, 2010-01-20 at 10:36 -0500, Boris Shingarov wrote: > Quoting Joe Neeman : > > > Again, I'd suggest uploading patches to codereview.appspot.com, which > > provides nice formatting and makes it easy to have multiple reviewers. > > Are there lilypond patches discussed there already? I looked around > the list of repositories, but I can't find Lilypond. Is there anything > special that I missed? We regularly use it for lilypond patches (http://codereview.appspot.com/186054/show for example). I don't know what the list of repositories is for, but anyone with a google account can upload patches. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB buiding from a local source tree?
On Wed, Jan 20, 2010 at 11:01:24AM -0500, Boris Shingarov wrote: > But for me the whole thing about GUB is driven by the organizational > side: as a developer, I am completely happy with the Linux development > platform, and am much more interested in furthering Lilypond rather than > trying to deploy it on a platform I don't even use. But then there is > the end-users who want to see it on Windows, but then again they want to > see progress in Lilypond development, and the prospect of losing weeks to > porting to Windows, makes them want to reconsider their platform > preferences. 2.13 releases happen approximately every two weeks. If there's more development, I'm happy to reduce that to every week. If there's a *lot* of development, and no (or few) broken regtests, I wouldn't mind doing it twice a week. Granted, this is all based on patches accepted to the main repository, and such patches need to go through extra scrutiny and discussion. If you're doing a lot of rough hacking, without a lot of thought about code style or unintended side effects, then releases from master won't help you. But if you do careful, quality work, then the extra scrutiny from developers won't be a big hurdle, and your patches will be accepted into master. In that case, you wouldn't need to fuss with GUB at all; I could make the releases as appropriate, and your collaborators / end-users could just use the regular 2.13.x mingw versions. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] programming-interface.itely: add backquote to Scheme example with comma.
On Tue, 2010-01-19 at 22:25 +0100, David Kastrup wrote:
> ---
> .../extending/programming-interface.itely |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/extending/programming-interface.itely
> b/Documentation/extending/programming-interface.itely
> index 4bae49a..3806d35 100644
> --- a/Documentation/extending/programming-interface.itely
> +++ b/Documentation/extending/programming-interface.itely
> @@ -894,7 +894,7 @@ can be inserted with a grob closure. Here is a setting
> from
> @code{AccidentalSuggestion},
>
> @example
> -(X-offset .
> +`(X-offset .
>,(ly:make-simple-closure
> `(,+
> ,(ly:make-simple-closure
This code is lifted from scm/define-grobs.scm, where it appears without
the backtick. Perhaps the real problem is that it is presented out of
context. That is, maybe we should have
\override AccidentalSuggestion #'X-offset = (ly:make-simple-closure ...)
instead.
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] programming-interface.itely: add backquote to Scheme example with comma.
Joe Neeman writes:
> On Tue, 2010-01-19 at 22:25 +0100, David Kastrup wrote:
>> ---
>> .../extending/programming-interface.itely |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/Documentation/extending/programming-interface.itely
>> b/Documentation/extending/programming-interface.itely
>> index 4bae49a..3806d35 100644
>> --- a/Documentation/extending/programming-interface.itely
>> +++ b/Documentation/extending/programming-interface.itely
>> @@ -894,7 +894,7 @@ can be inserted with a grob closure. Here is a setting
>> from
>> @code{AccidentalSuggestion},
>>
>> @example
>> -(X-offset .
>> +`(X-offset .
>>,(ly:make-simple-closure
>> `(,+
>> ,(ly:make-simple-closure
>
> This code is lifted from scm/define-grobs.scm, where it appears without
> the backtick.
No, it doesn't. The backtick is just at some outer layer in the
definition. Not printing it makes as little sense as not printing an
initial quote character when quoting stuff with string escapes: the
example makes no syntactical sense without this added context.
> Perhaps the real problem is that it is presented out of context. That
> is, maybe we should have
>
> \override AccidentalSuggestion #'X-offset = (ly:make-simple-closure ...)
>
> instead.
The whole context that is needed is "`" as far as I am concerned.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] programming-interface.itely: add backquote to Scheme example with comma.
On Wed, 2010-01-20 at 20:28 +0100, David Kastrup wrote:
> Joe Neeman writes:
>
> > On Tue, 2010-01-19 at 22:25 +0100, David Kastrup wrote:
> >> ---
> >> .../extending/programming-interface.itely |2 +-
> >> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/Documentation/extending/programming-interface.itely
> >> b/Documentation/extending/programming-interface.itely
> >> index 4bae49a..3806d35 100644
> >> --- a/Documentation/extending/programming-interface.itely
> >> +++ b/Documentation/extending/programming-interface.itely
> >> @@ -894,7 +894,7 @@ can be inserted with a grob closure. Here is a
> >> setting from
> >> @code{AccidentalSuggestion},
> >>
> >> @example
> >> -(X-offset .
> >> +`(X-offset .
> >>,(ly:make-simple-closure
> >> `(,+
> >> ,(ly:make-simple-closure
> >
> > This code is lifted from scm/define-grobs.scm, where it appears without
> > the backtick.
>
> No, it doesn't. The backtick is just at some outer layer in the
> definition. Not printing it makes as little sense as not printing an
> initial quote character when quoting stuff with string escapes: the
> example makes no syntactical sense without this added context.
>
> > Perhaps the real problem is that it is presented out of context. That
> > is, maybe we should have
> >
> > \override AccidentalSuggestion #'X-offset = (ly:make-simple-closure ...)
> >
> > instead.
>
> The whole context that is needed is "`" as far as I am concerned.
Ok, pushed.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] programming-interface.itely: add backquote to Scheme example with comma.
Joe Neeman writes: > On Wed, 2010-01-20 at 20:28 +0100, David Kastrup wrote: >> >> > Perhaps the real problem is that it is presented out of context. That >> > is, maybe we should have >> > >> > \override AccidentalSuggestion #'X-offset = (ly:make-simple-closure ...) >> > >> > instead. >> >> The whole context that is needed is "`" as far as I am concerned. > > Ok, pushed. Thanks. I consider that the best fix short of completely redesigning this part, which does not seem worth the trouble. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Several thoughts for implementing accordion standard bass support
On Wed, Jan 20, 2010 at 6:11 AM, David Kastrup wrote: > StdbassEngraver = #`((listeners > (note-event . > ,(lambda (engraver event) > (let* ((pitch (ly:event-property event 'pitch))) > (ly:event-set-property! event 'pitch This looks wrong - engravers should not modify their inputs. Rather, the engraver should create the Grob that you are interested in, or it should acknowledge the grob created by another engraver. >>> >>> Obviously, I have no clue whatsoever about what I am doing, and this is >>> the "poke with a stick until it works(TM)" approach. >>> >>> Could you give a code example or outline for either of the possibilities >>> that you outlined? >> >> I am completely unsure what you are trying to achieve. Are you really >> trying to typeset noteheads on a staff, or is it something else? > > I am trying to do exactly what the posted code _does_ right now. It > works (maps notes to different octaves than entered, in particular > mapping chord notes to the -1 octave ignoring inversions). At a future > point of time, the criteria might get more intricate and I may want to > analyze the resulting chords. But that is reasonably straightforward to > do. I recommend a music function for this. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Ties and slurs going into repeat alternatives
On Wed, Jan 20, 2010 at 6:19 AM, David Kastrup wrote: >>> Is there a routine that does most of the cloning business so that it is >>> reasonably easy to fix the behavior of \repeat volta? >> >> The problem is that the 2nd slur needs to be wired to other >> noteheads/stems/etc. for the formatting to come out correctly, while >> around linebreaks, all of the rewiring can be done generically. > > I am not sure I understand. For all but the first repeat alternative > (which would retain the current behavior), the alternative _is_ detached > from the common repeat part. So it would appear that the situation is > quite comparable to a linebreak. No, it's not comparable. The slur engraver generates one big slur that encompasses all notes; after line breaking, a routine generates a copy and trims all grob pointers (including the note head ones) that are not in the same system as the copied slur. The correct solution would be to hack the appropriate engravers to remember the state at the start of the alternative and recreate that at the following alternatives. That would be very hairy though. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Ties and slurs going into repeat alternatives
Han-Wen Nienhuys writes: > On Wed, Jan 20, 2010 at 6:19 AM, David Kastrup wrote: > Is there a routine that does most of the cloning business so that it is reasonably easy to fix the behavior of \repeat volta? >>> >>> The problem is that the 2nd slur needs to be wired to other >>> noteheads/stems/etc. for the formatting to come out correctly, while >>> around linebreaks, all of the rewiring can be done generically. >> >> I am not sure I understand. For all but the first repeat alternative >> (which would retain the current behavior), the alternative _is_ detached >> from the common repeat part. So it would appear that the situation is >> quite comparable to a linebreak. > > No, it's not comparable. The slur engraver generates one big slur that > encompasses all notes; after line breaking, a routine generates a copy > and trims all grob pointers (including the note head ones) that are > not in the same system as the copied slur. I suppose this has the potential to become another case where you explain the same thing over and over to me and I don't get it. > The correct solution would be to hack the appropriate engravers to > remember the state at the start of the alternative and recreate that > at the following alternatives. That would be very hairy though. How much state from before the first alternative would actually remain after trimming all grob pointers from the first alternative (which get replaced by the different alternative) as well as those from the common repeat part (which are the equivalent of "line above")? Probably not much more than slur orientation and possibly system entry position? For ties, the situation should be rather simple: one just needs to trigger \repeatTie automatically, possibly retaining orientation. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
How to modify chordmode parser?
Hi, accordion entry again... I want to distinguish single bass buttons from chord buttons. Single basses are usually located in a lower octave. When written out, you usually arrive at something like c,:1 c:m g,:1 c:m Now that is cumbersome to write, so I would like to be able to write C c:m G c:m instead which corresponds better with accordion notation. This appears to involve two components: a) additional capital notenames that are one octave lower b) and that don't trigger chord buildup. C:m would be an error, actually. It would also be nice to write c:m/C which would not create an actual inversion, but just tack the (lower octave) bass tone to the bottom without rearranging the chord. How much work for the chordmode parser to achieve this? Can this be done from Scheme, or is C++ hackery needed? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch: issue #659
Marc Hohl wrote Wednesday, January 20, 2010 9:54 AM Trevor Daniels schrieb: [...] I would not worry about this. As Alexander has pointed out, examples showing the staff lines extending through the sign and not extending through the sign can be found. It is easy for a user to move the sign to the end of the staff lines with \once \override Score.BarLine #'extra-offset = #'(1 . 0) \once \override Score.SpanBar #'extra-offset = #'(1 . 0) if this was really wanted, although this would admittedly push it into the right margin. Trevor, Alexander, thanks for your messages and your suggestions. Would it make sense to provide another varsegno symbol which looks exactly as the one I have drawn, but has no positive witdh (to the right of the center)? When I use this sign in "S." situations, the staff lines would end in the middle of the sign, as it is in the example mentioned in the tracker. I'm not sure. I tried overriding the X-extent of BarLine, but the right extent seems to be ignored. I've not been able to discover what controls the ending of the staff lines (other than reaching the right margin), or the placement of a final bar line relative to the end of the staff lines. Or is there a more elegant solution? Probably, but it eludes me. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Working on scheme engravers
Hello, I was asked to start posting here with my questions about scheme engravers. I'm also learning scheme so my questions will be naive, and my code is probably not up to scheme conventions. I have started with the scheme-engraver.ly sample. I'm using Lilypond 2.13.11 on OS X and Linux. I attached the full file with my current code. Here is the part I have added to the sample. My goal is to determine the fingering number and the string number and draw the notehead and the string indicator with custom code and add a fret number that is calculated. My code: (cons 'note-event (lambda (engraver event) (let* ( (artics (ly:event-property event 'articulations)) (fingers (car artics)) (strings (car (cdr artics))) (digitNum (ly:event-property fingers 'digit)) (stringNum (ly:event-property strings 'string-number)) ) (display (list "\n\nArticulations: \n\n" artics "\n\n")) (display (list "\nfinger: \n" fingers "\n\n")) (display (list "\nstrings: \n" strings "\n\n")) (display (list "\ndigit: " digitNum "\n\n")) (display (list "\nstring: " stringNum "\n\n")) ) This will work with this music code: Here are my questions. Is this the best way to determine the digit and string-number? The first flaw I see with this code is if the music is entered like this: In that case my code won't work. Is there a way to determine the digit and string-number directly by name? It looks like the articulations are a list. Would it be possible to loop through the list and determine what each one is? Thanks for the scheme engraver capability. This will let me finally crack the notation system of the Chapman Stick. I have started a project with a few other programmers/Chapman Stick players. We are determine to bring Lilypond to the Stick world. Thanks for your help. -Eric -- Eric Knapp IT Instructor Information Technology Madison College http://matcmadison.edu 3550 Anderson Street Madison, Wisconsin 53704 Telephone: 608.246.6641 Fax: 608.243.4754 Email: ekn...@gmail.com firstSuccessEngraver.ly Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Update program requirements.
Here's a patch to update the following requirements:
* New running requirements:
- guile 1.8.2
- ghostscript 8.60
* New compiling requirements:
- GCC 4.0
This is based on Graham's recommendation here:
http://n2.nabble.com/CG-chapter-3-first-draft-td4418540.html#a4420899
Okay to push?
- Mark
From 4c65920c3a6d32c9538e81407d68ea9f87c45a95 Mon Sep 17 00:00:00 2001
From: Mark Polesky
Date: Wed, 20 Jan 2010 19:04:12 -0800
Subject: [PATCH] Update program requirements.
* New running requirements:
- guile 1.8.2
- ghostscript 8.60
* New compiling requirements:
- GCC 4.0
---
Documentation/contributor/basic-compile.itexi | 16 ++--
configure.in | 14 ++
2 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/Documentation/contributor/basic-compile.itexi b/Documentation/contributor/basic-compile.itexi
index 17b4f31..f4f2240 100644
--- a/Documentation/contributor/basic-compile.itexi
+++ b/Documentation/contributor/basic-compile.itexi
@@ -97,8 +97,8 @@ install guile-devel or guile-dev or libguile-dev too.
@item @uref{ftp://ftp.gnu.org/gnu/texinfo/,Texinfo} (version 4.11 or newer).
-...@item @uref{http://gcc.gnu.org/, The GNU c++ compiler} (version 3.4 or
-newer. 4.x is strongly recommended).
+...@item @uref{http://gcc.gnu.org/, The GNU Compiler Collection}
+(version 4.0 or newer).
@item @uref{http://www.python.org,Python} (version 2.4 or newer)
@@ -129,11 +129,10 @@ Running LilyPond requires proper installation of the following software
@item @uref{http://fontconfig.org/,FontConfig} (version 2.2 or newer).
@item @uref{http://www.pango.org/,Pango} (version 1.12 or newer).
@item @uref{http://www.gnu.org/software/guile/guile.html,GUILE}
-(version 1.8.2 or newer), or patch 1.8.1 with
-...@uref{http://lilypond.org/vc/gub.darcs/patches/guile-1.8-rational.patch}.
+(version 1.8.2 or newer)
@item @uref{http://www.python.org,Python} (version 2.4 or newer).
-...@item @uref{http://www.ghostscript.com,Ghostscript} (version 8.15 or
-newer. 8.60 recommended)
+...@item @uref{http://www.ghostscript.com,Ghostscript} (version 8.60 or
+newer).
@item Dejaview. (This is normally installed by default)
@end itemize
@@ -153,10 +152,7 @@ additional tools and packages:
@item ImageMagick
@item International fonts (see input/regression/utf-8.ly for hints
about which font packages are necessary for your platform)
-...@item Ghostscript 8.60 or newer, or 8.50 with the patch from
-...@uref{http://bugs.ghostscript.com/show_bug.cgi?id=688154}
-and the patch from
-...@uref{http://bugs.ghostscript.com/show_bug.cgi?id=688017}.
+...@item Ghostscript 8.60 or newer
@item @uref{http://www.nongnu.org/texi2html/,Texi2HTML} 1.82
@item rsync
@end itemize
diff --git a/configure.in b/configure.in
index 6253b66..f0aea5f 100644
--- a/configure.in
+++ b/configure.in
@@ -1,5 +1,5 @@
dnl configure.in -*-shell-script-*-
-dnl Process this file with autoconf to produce a configure script.
+dnl Process this file with autoconf to produce a configure script.
# Bootstrap the init proces.
AC_INIT
@@ -90,10 +90,10 @@ AC_MSG_RESULT($NCSB_SOURCE_FILES)
STEPMAKE_PYTHON(REQUIRED, 2.4)
-STEPMAKE_GCC(REQUIRED, 3.4)
+STEPMAKE_GCC(REQUIRED, 4.0)
STEPMAKE_CXX(REQUIRED)
-STEPMAKE_GXX(REQUIRED, 3.4)
+STEPMAKE_GXX(REQUIRED, 4.0)
STEPMAKE_CXXTEMPLATE
STEPMAKE_STL_DATA_METHOD
STEPMAKE_LIB(REQUIRED)
@@ -110,9 +110,7 @@ STEPMAKE_GETTEXT
STEPMAKE_MSGFMT(REQUIRED)
STEPMAKE_TEXMF(REQUIRED)
STEPMAKE_TEXMF_DIRS
-
-## should check for 1.8.2 ?
-STEPMAKE_GUILE_DEVEL(REQUIRED, 1.8.0)
+STEPMAKE_GUILE_DEVEL(REQUIRED, 1.8.2)
## check rational bugfix.
@@ -122,7 +120,7 @@ AC_MSG_CHECKING(GUILE rational bugfix)
AC_TRY_CPP(
#include
#ifdef SCM_FRACTION_REDUCED_BIT
-#error
+#error
#endif
,
AC_MSG_RESULT(ok),
@@ -133,7 +131,7 @@ CPPFLAGS="$save_CPPFLAGS"
STEPMAKE_PYTHON_DEVEL(REQUIRED)
-STEPMAKE_PATH_PROG(GHOSTSCRIPT, gs, OPTIONAL, 8.15)
+STEPMAKE_PATH_PROG(GHOSTSCRIPT, gs, OPTIONAL, 8.60)
STEPMAKE_PATH_PROG(FONTFORGE, fontforge, REQUIRED, 20050624)
--
1.6.3.3
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Update program requirements.
On Wed, Jan 20, 2010 at 7:12 PM, Mark Polesky wrote: > Here's a patch to update the following requirements: > > * New running requirements: > - guile 1.8.2 > - ghostscript 8.60 This is probably okay. Later Ghostscript versions have fixed various font embedding issues. > * New compiling requirements: > - GCC 4.0 Are you sure this is required? OpenBSD's gcc 3.3.5 apparently works okay with this patch: http://lists.gnu.org/archive/html/lilypond-devel/2009-12/msg00324.html -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Update program requirements.
Patrick McCarty wrote: >> * New compiling requirements: >> - GCC 4.0 > Are you sure this is required? > OpenBSD's gcc 3.3.5 apparently works okay with this patch: > http://lists.gnu.org/archive/html/lilypond-devel/2009-12/msg00324.html I think Graham was suggesting that by updating the requirement, we're not saying that older versions will fail, but rather that we are no longer officially supporting them. GCC 3.3.5 is from 2004 (http://gcc.gnu.org/viewcvs/tags/gcc_3_3_5_release/?view=log) and there have been six major releases since then. GCC 4.0 came in 2005, so it's not such a huge leap. Besides, shouldn't GCC 3.3 users be upgrading anyway? Or is there something I don't know? Looks like it's easy enough to get GCC 4.2.4 on OpenBSD: http://www.openbsd.org/4.6_packages/i386/gcc-4.2.4p2.tgz-long.html Because of this, I wouldn't mind moving the requirement up to 4.2.4, but there may be some issues I'm not aware of. Let me know if there are. Otherwise, what do you think? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch: issue #659
Alexander Kobel schrieb: Marc Hohl wrote: Trevor Daniels schrieb: It is easy for a user to move the sign to the end of the staff lines with \once \override Score.BarLine #'extra-offset = #'(1 . 0) \once \override Score.SpanBar #'extra-offset = #'(1 . 0) if this was really wanted, although this would admittedly push it into the right margin. Indeed. It's not quite exactly '(1 . 0), but just slightly less, but this is nearly not noticeable. Would it make sense to provide another varsegno symbol which looks exactly as the one I have drawn, but has no positive witdh (to the right of the center)? This sounds more elegant than the tweak above, but I'm not sure if this alone is worth the effort of an additional symbol. Me, too. It still feels somewhat clumsy to do it in this way, but on the other hand - if it looks alright, one more sign in the font should not be a big problem. Another idea: Is it possible to have a double bar line at the end of a line, and the segno bar line at the beginning of the next? What about ".S" doing this, as opposed to "S", or have an additional "||S" and "S||"? I must admit that I don't have lots of references for this symbol and its use. If this is a sensible default, there is no problem in defining ".S" just doing what you proposed. Can you do some investigations? As you posted the examples in the tracker, I think you are the most important source of informations here ;-) Thanks, Marc Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
