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
> disc
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 wrapp
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 "A
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 a
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 reco
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
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/lil
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 recognizi
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/lin
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
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 -
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
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
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
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 namin
15 matches
Mail list logo