Re: Weird doc output with @rlearning.
On Thu, Jan 01, 2009 at 09:23:24AM +1100, Joe Neeman wrote:
> Towards the bottom of the page, we have the sentences "(The location of this
> directory is installation-dependent - see of information Other sources of
> information)." and "Alternatively, the more important of these files are
> discussed in sources of information Other sources of information."
Yes, texinfo screws up if a @macro{is spread
over two lines}. IIRC this was listed in the old texinfo-todo.txt
(list of technical problems with the docs).
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: guile and i10n
Le 31 déc. 08 à 19:02, Han-Wen Nienhuys a écrit : Hi, I think GUILE (like other LISPS) do not evaluate the On Wed, Dec 31, 2008 at 2:10 PM, Werner LEMBERG wrote: I see the following remark in a recent git commit: Scrap localization wrapper around music functions docstrings. The l10n wrapper _i seems to prevent GUILE from recognizing the docstrings as such. Looks like a bug or a bad `feature'. Have you already contacted the GUILE people for a workaround? If anything, this is not a GUILE problem, but a lilypond one. define-music-function as _i are Scheme macros. It could be that the expansion does not occur correctly, but I know too little of macros to say something useful about this. Nicolas? Huh, the only definition of _i that I find in the sources is (defmacro-public _i (x) x) What is the point of that? Shouldn't it expand into the result of a call to gettext? Anyway, it seems that even with the current definition of _i, it cannot be used for docstrings (I don't understand why). guile> (macroexpand '(define-music-function (parser location) () (_i "blahblah") (make-music 'Music))) (ly:make-music-function (list) (lambda (parser location) (_i "blahblah") (make-music (quote Music Currently, no literal string is found after the arguments of lambda, so no docstring is detected. However, it is possible to call gettext during the expansion of define-music-function, for instance: guile> (defmacro-public define-music-function (args signature . body) (if (and (pair? body) (string? (car body))) (let ((docstring (gettext (car body))) (body (cdr body))) `(ly:make-music-function (list ,@signature) (lambda (,@args) ,docstring ,@body))) `(ly:make-music-function (list ,@signature) (lambda (,@args) ,@body guile> (macroexpand '(define-music-function (parser location) () "new tremolo format" (make-music 'Music))) (ly:make-music-function (list) (lambda (parser location) "nouveau format de tremolo" (make-music (quote Music Nicolas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Weird doc output with @rlearning.
Have a look at http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Including-LilyPond- files#Including-LilyPond-files Towards the bottom of the page, we have the sentences "(The location of this directory is installation-dependent - see of information Other sources of information)." and "Alternatively, the more important of these files are discussed in sources of information Other sources of information." The texidoc source for these 2 sentences looks OK, but the output doesn't. A common feature of these 2 sentences is that they use the @rlearning macro. On the other hand, the same page contains a link using @ref that looks fine. Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc patch for relative includes.
LGTM.
Ideally we'd want an example in there, but I'm not certain how to
do it without breaking compiling (other than putting it inside
@examlpe rather than @lilypond). But this is the kind of thing
that a new doc contributor should play with, not you. :)
Cheers,
- Graham
On Thu, Jan 01, 2009 at 09:18:15AM +1100, Joe Neeman wrote:
> Here is a patch to the documentation regarding bug 391 (relative \include
> paths). Could a doc writer please take a quick look?
>
> Joe
>
> From 85333ead871d09ad4a40f8096b6c71a2086ceb76 Mon Sep 17 00:00:00 2001
> From: Joe Neeman
> Date: Thu, 1 Jan 2009 09:09:46 +1100
> Subject: [PATCH] Add documentation recommending the use of
> -drelative-includes.
>
> ---
> Documentation/user/input.itely | 12 ++--
> 1 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/user/input.itely b/Documentation/user/input.itely
> index c990b3b..13a8612 100644
> --- a/Documentation/user/input.itely
> +++ b/Documentation/user/input.itely
> @@ -849,11 +849,19 @@ subdirectory called @file{parts} within the current
> directory, use
> @end example
>
> Files which are to be included can also contain @code{\include}
> -statements of their own. These second-level
> +statements of their own. By default, these second-level
> @code{\include} statements are not interpreted until they have
> been brought into the main file, so the file names they specify
> must all be relative to the directory containing the main file,
> -not the directory containing the included file.
> +not the directory containing the included file. However,
> +this behavior can be changed by passing the option
> +...@code{-drelative-includes} option at the command line
> +(or by adding using @code{#(ly:set-option 'relative-includes #t)}
> +at the top of the main input file). With @code{relative-includes}
> +set, the path for each @code{\include} command will be taken
> +relative to the file containing that command. This behavior is
> +recommended and it will become the default behavior in a future
> +version of lilypond.
>
> Files can also be included from a directory in a search path
> specified as an option when invoking LilyPond from the command
> --
> 1.6.0.2
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc patch for relative includes.
Here is a patch to the documentation regarding bug 391 (relative \include
paths). Could a doc writer please take a quick look?
Joe
From 85333ead871d09ad4a40f8096b6c71a2086ceb76 Mon Sep 17 00:00:00 2001
From: Joe Neeman
Date: Thu, 1 Jan 2009 09:09:46 +1100
Subject: [PATCH] Add documentation recommending the use of -drelative-includes.
---
Documentation/user/input.itely | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/Documentation/user/input.itely b/Documentation/user/input.itely
index c990b3b..13a8612 100644
--- a/Documentation/user/input.itely
+++ b/Documentation/user/input.itely
@@ -849,11 +849,19 @@ subdirectory called @file{parts} within the current directory, use
@end example
Files which are to be included can also contain @code{\include}
-statements of their own. These second-level
+statements of their own. By default, these second-level
@code{\include} statements are not interpreted until they have
been brought into the main file, so the file names they specify
must all be relative to the directory containing the main file,
-not the directory containing the included file.
+not the directory containing the included file. However,
+this behavior can be changed by passing the option
+...@code{-drelative-includes} option at the command line
+(or by adding using @code{#(ly:set-option 'relative-includes #t)}
+at the top of the main input file). With @code{relative-includes}
+set, the path for each @code{\include} command will be taken
+relative to the file containing that command. This behavior is
+recommended and it will become the default behavior in a future
+version of lilypond.
Files can also be included from a directory in a search path
specified as an option when invoking LilyPond from the command
--
1.6.0.2
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
using rietveld for patch review
Happy new year, all! I've completed a major patch of fret diagrams, adding a new orientation and cleaning up a bunch of ugly stuff in the code. Please review the patch at http://codereview.appspot.com/11857/diff/1/3 Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
gub3 LDFLAGS error
Hi Jan, The latest commit to gub3 seems to have broken guile: building package: tools::guile *** Stage: untar (guile, tools) *** Stage: patch (guile, tools) *** Stage: autoupdate (guile, tools) *** Stage: configure (guile, tools) *** Stage: compile (guile, tools) Command barfed: cd /home/lilypond/gub/target/tools/build/guile-release_1-8-5 && make LDFLAGS='-Wl,-rpath -Wl,\$$ORIGIN/../lib' ... gcc -DHAVE_CONFIG_H -I.. -I/home/lilypond/gub/target/tools/src /guile-release_1-8-5 -I..-I/home/lilypond/gub/target/tools/root/usr/include -Wall -Wmissing-prototypes -c -o gen-scmconfig.o /home/lilypond/gub/target/too ls/src/guile-release_1-8-5/libguile/gen-scmconfig.c; \ fi if [ "no" = "yes" ]; then \ gcc -o gen-scmconfig gen-scmconfig.o; \ else \ /bin/sh ../libtool --tag=CC --mode=link gcc -I/home/lilypond /gub/target/tools/root/usr/include -Wall -Wmissing-prototypes -Wl,-rpath -Wl,\ $ORIGIN/../lib -o gen-scmconfig gen-scmconfig.o -lgmp -lcrypt -lm -lltdl ; \ fi mkdir .libs gcc -I/home/lilypond/gub/target/tools/root/usr/include -Wall -Wmissing-prototypes -Wl,-rpath -Wl,\$ORIGIN/../lib -o gen-scmconfig gen-scmconfig.o /home/lilypond/gub/target/tools/root/usr/lib/libgmp.so -lcrypt -lm /home/lilypond/gub/target/tools/root/usr/lib/libltdl.so -ldl rm -f scmconfig.h.tmp cat /home/lilypond/gub/target/tools/src/guile-release_1-8-5/libguile/scmconfig.h.top > scmconfig.h.tmp ./gen-scmconfig >> scmconfig.h.tmp ./gen-scmconfig: error while loading shared libraries: libltdl.so.3: cannot open shared object file: No such file or directory make[4]: *** [scmconfig.h] Error 127 lilyp...@server:~/gub$ dpkg -l libltdl* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- pn libltdl3(no description available) pn libltdl3-dev(no description available) ii libltdl7 2.2.4-0ubuntu4 A system independent dlopen wrapper for GNU ii libltdl7-dev 2.2.4-0ubuntu4 A system independent dlopen wrapper for GNU I'm suspicious about the $ORIGIN. This computer previous compiled gub with pre-dec31 gub up until the darwin-ppc crossplaftform odcctools step. I tried doing a "make clean", but that didn't do anything. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: guile and i10n
Hi, I think GUILE (like other LISPS) do not evaluate the On Wed, Dec 31, 2008 at 2:10 PM, Werner LEMBERG wrote: > > I see the following remark in a recent git commit: > > Scrap localization wrapper around music functions docstrings. > > The l10n wrapper _i seems to prevent GUILE from recognizing the > docstrings as such. > > Looks like a bug or a bad `feature'. Have you already contacted the > GUILE people for a workaround? If anything, this is not a GUILE problem, but a lilypond one. define-music-function as _i are Scheme macros. It could be that the expansion does not occur correctly, but I know too little of macros to say something useful about this. Nicolas? -- 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: gub3 build fail: fonts
On Wed, Dec 31, 2008 at 03:43:23PM +0100, Jan Nieuwenhuizen wrote: > Op zondag 21-12-2008 om 20:58 uur [tijdzone -0800], schreef Graham > Percival: > > > and building with > > ABI=32 make lilypond > > IWBN to do this ABI=32 think automagically (and from bin/gub or > gub/settings.py or gub/linux.py or something.) Very true, but right now my priority is being able to take over release building. I don't care what command-line black magick I need to use. :) > > the tools are built and the lilypond binary appears to build. > > However, the overall build process dies with font-related errors: Sorry, this has automagically been fixed. Quite possibly when Reinhold upgraded the server to the next ubuntu release (Inteprid). Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
New German PO file for 'lilypond' (version 2.12.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'lilypond' has been submitted by the German team of translators. The file is available at: http://translationproject.org/latest/lilypond/de.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: http://translationproject.org/latest/lilypond/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/lilypond.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: why is Dutch the default language for note-entry?
Op woensdag 17-12-2008 om 09:52 uur [tijdzone +0100], schreef Werner LEMBERG: > Hmm. I don't know either. Maybe a question for emacs-devel? Yep, turned out to be an Emacs bug. http://lists.gnu.org/archive/html/emacs-devel/2008-12/msg00877.html Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
guile and i10n
I see the following remark in a recent git commit: Scrap localization wrapper around music functions docstrings. The l10n wrapper _i seems to prevent GUILE from recognizing the docstrings as such. Looks like a bug or a bad `feature'. Have you already contacted the GUILE people for a workaround? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gub3 build fail: fonts
Op zondag 21-12-2008 om 20:58 uur [tijdzone -0800], schreef Graham Percival: > With the attached patch I've fully removed the LD_LIBRARY_PREFIX from these files. It seems we only need[ed] that for GIT, but that's been taken care of by repository.py, I hope. > and building with > ABI=32 make lilypond IWBN to do this ABI=32 think automagically (and from bin/gub or gub/settings.py or gub/linux.py or something.) > the tools are built and the lilypond binary appears to build. > However, the overall build process dies with font-related errors: > > ... > Renaming input to: > `/home/lilypond/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/input/regression/predefined-fretboards.ly'] > Interpreting music... > elapsed time: 0.01 seconds > Element count 15 (spanners 5) > Preprocessing graphical objects... > Grob count 21[sans_4.5966796875][sans_3.25][sans_2.318359375] > (process:2929): Pango-WARNING **: Error loading GSUB table 57005 > [sans_1.9326171875]GLib: Cannot convert message: Could not open > converter from 'UTF-8' to 'ANSI_X3.4-1968' > > (process:2929): Pango-CRITICAL **: No fonts found: > This probably means that the fontconfig > library is not correctly configured. You may need to > edit the fonts.conf configuration file. More information > about fontconfig can be found in the fontconfig(3) manual > page and on http://fontconfig.org > > (process:2929): Pango-WARNING **: failed to find shape engine, > expect ugly output. engine-type='PangoRenderFc', script='latin' > > (process:2929): Pango-CRITICAL **: pango_fc_font_lock_face: > assertion `PANGO_IS_FC_FONT (font)' failed Han-Wen? Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
New French PO file for 'lilypond' (version 2.12.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'lilypond' has been submitted by the French team of translators. The file is available at: http://translationproject.org/latest/lilypond/fr.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: http://translationproject.org/latest/lilypond/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/lilypond.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Fix naming of two Scheme type predicates
On Wed, Dec 31, 2008 at 12:29 AM, Patrick McCarty wrote: > Hello, > > There are two exported Scheme functions that should be renamed. They > are noticeably out of order in the list of Scheme functions in the IR. > > This patch fixes their names accordingly to agree with the > type-predicate naming convention. LGTM. -- 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
