Re: Distributions upgrading to Python 3
Patrick McCarty wrote: Huh. I've been following the Arch Linux development list for a while, but it didn't occur to me that they were doing something radically different than the recommended policy. This is the procedure they are following, and I think they are nearly finished with the task: http://wiki.archlinux.org/index.php/DeveloperWiki:Python_Todo_List Their advice is pretty clear (quoted from above link): Packages pointing at python binary (lilypond appears in this list) Packages which have /usr/bin/python or /usr/bin/env python in their files and will need to change to python2 if not already compatible with python-3.x. Note that some of these are fixed by just building against a python2 binary, while others require some sed magic... - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Distributions upgrading to Python 3
On Mon, Oct 18, 2010 at 2:38 AM, Patrick McCarty pnor...@gmail.com wrote: Arch Linux will be migrating to Python 3 very soon, and I'm trying to figure out what to do with regard to LilyPond's build system. I don't know if Arch Linux is the first distribution upgrading to Python 3, but this migration will be happening any day now. Hi Patrick, I'm not sure if you're subscribed to Arch mailing lists, but it seems to be causing a bloody mess amongst users and contributors. (I'm not following Arch's ML, but the same situation is happening on Frugalware MLs). I *highly* doubt any other distro (especially mainstream distros, not even Fedora) will consider migrating anytime soon. Cheers, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
TODO in vocal
Valentin There's a TODO in vocal.itely that I don't understand: 902 @c TODO: document \new Staff Voice \lyricsto bug If it really is a bug then we shouldn't be documenting it anyway, but I'd like to know what it means first. Do you know which bug it is referring to? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Build: another hack for translations (fix 1323). (issue2520041)
AFAICT after a few hours of fiddling this issue is fixed, let's wait for release to verify it (and not hopefully reopen it :-P). Let me know how is current master. I've built and have checked both online and offline targets, both split and big-page manuals, both docs in English and Italian (so I've checked 8 output files). You may ignore details below to save time. Il giorno lun, 18/10/2010 alle 00.35 +0100, Graham Percival ha scritto: Ok. A few things spring to mind: - maybe the DEPTH environment variable isn't always set to the depth of the git source tree? I mean, that would be profoundly messed up, but this might explain why the offline docs (normally, before today at least) work? I mean, maybe the GNUmakefile in the translation pass in the depth-1 ? It could be, but but it's not the case, see find -name 'GNUmakefile*' -or -name '*.make' |xargs grep -B3 -n --color DEPTH - maybe there's something else in postprocess.py (or some related file) which automatically removes a ../ layer from the translations? I think this is much more likely. But if this is true, then fixing the my $reldir line in the texi2html init is going to make the later fix produce broken links. AFAICS it's no longer the case in current master branch. I suspect that there used to be a kind of something you decribe that used to caught the URLs for back to documentation index, but I can't find it in the makefiles or *.py files in current master Git tree (I grepped for '\.\.'). Cheers, John signature.asc Description: This is a digitally signed message part ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: TODO in vocal
Valentin Villenave wrote Monday, October 18, 2010 1:47 PM On Mon, Oct 18, 2010 at 12:03 PM, Trevor Daniels t.dani...@treda.co.uk wrote: There's a TODO in vocal.itely that I don't understand: 902 @c TODO: document \new Staff Voice \lyricsto bug If it really is a bug then we shouldn't be documenting it anyway, but I'd like to know what it means first. Do you know which bug it is referring to? I don't know, it seems that Han-Wen added it in the first place: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=7fd51755d9bdf40766a612b3c3e9a00f68238082 Of course, we didn't use the tracker back then, so it's hard for me to pinpoint what he was referring to. Perhaps something like http://lists.gnu.org/archive/html/bug-lilypond/2004-01/msg00190.html or http://lists.gnu.org/archive/html/bug-lilypond/2004-01/msg00276.html ? Well, neither of those problems still exist ... Anyway, back then lyricsto had just appeared (replacing \newaddlyrics), the syntax was still quite different from what we now know, so I guess this todo: can just go away quietly. .. so, yes, I'll just quietly remove this TODO Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: font defects in scripts.varsegno and accordion.push
I wrote: I've attached fontforge images of two broken glyphs; [...] Listmaster, please approve this mail sitting in the queue! Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Distributions upgrading to Python 3
On Mon, Oct 18, 2010 at 2:50 AM, Valentin Villenave valen...@villenave.net wrote: On Mon, Oct 18, 2010 at 2:38 AM, Patrick McCarty pnor...@gmail.com wrote: Arch Linux will be migrating to Python 3 very soon, and I'm trying to figure out what to do with regard to LilyPond's build system. I don't know if Arch Linux is the first distribution upgrading to Python 3, but this migration will be happening any day now. I'm not sure if you're subscribed to Arch mailing lists, but it seems to be causing a bloody mess amongst users and contributors. (I'm not following Arch's ML, but the same situation is happening on Frugalware MLs). I *highly* doubt any other distro (especially mainstream distros, not even Fedora) will consider migrating anytime soon. It's not really creating much controversy yet, but as with everything, once python3 and all of the rebuilds hit the main repos (today or tomorrow), there will probably be mass confusion. :P Here is the new announcement draft thread from today: http://mailman.archlinux.org/pipermail/arch-dev-public/2010-October/018195.html -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: font defects in scripts.varsegno and accordion.push
On 10/18/10 9:21 AM, Werner LEMBERG w...@gnu.org wrote: I wrote: I've attached fontforge images of two broken glyphs; [...] Werner, Can you open an issue directly on the tracker and post your attachments there? It seems that there ought to be three issues: 1) varsegno 2) accordion.push 3) Shape note heads at small font sizes. I'll take over 2 and 3. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Distributions upgrading to Python 3
On Sun, Oct 17, 2010 at 11:19 PM, Mark Polesky markpole...@yahoo.com wrote: Patrick McCarty wrote: Huh. I've been following the Arch Linux development list for a while, but it didn't occur to me that they were doing something radically different than the recommended policy. This is the procedure they are following, and I think they are nearly finished with the task: http://wiki.archlinux.org/index.php/DeveloperWiki:Python_Todo_List Their advice is pretty clear (quoted from above link): Packages pointing at python binary (lilypond appears in this list) Packages which have /usr/bin/python or /usr/bin/env python in their files and will need to change to python2 if not already compatible with python-3.x. Note that some of these are fixed by just building against a python2 binary, while others require some sed magic... Yes, but unfortunately, LilyPond needs special sed treatment, since many substitutions are made *after* configure time. I will need to file a bug report... Specifically, I am looking for a way to make life easier when building LilyPond without package management (instead of running a sed script over all the python scripts every time I need to use them). A simple change to stepmake/aclocal.m4 would ease the process, but I think I'll keep this as a local patch for a while... Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Distributions upgrading to Python 3
On Sun, Oct 17, 2010 at 5:59 PM, Graham Percival gra...@percival-music.ca wrote: On Sun, Oct 17, 2010 at 05:38:20PM -0700, Patrick McCarty wrote: --) Two scripts still have /usr/bin/python lines (python/auxiliar/manuals_definitions.py, and scripts/build/pytt.py). Those should be changed to @PYTHON@, right? python/ yes, since it's not something that people call manually. But stuff in scripts/build/ shouldn't have @PYTHON@, otherwise it'll bork if you call it manually. Um, I should have phrased my question differently: Most python scripts in python/ and scripts/ use @PYTHON@, @TARGET_PYTHON@, or /usr/bin/env python. There are two exceptions, one in python/ and one in scripts/, that use a fixed path to the executable (/usr/bin/python). If you do a git grep, you'll see what I mean. Are these two scripts special, or should they be changed to use @PYTHON@ ? Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Distributions upgrading to Python 3
Il giorno lun, 18/10/2010 alle 09.02 -0700, Patrick McCarty ha scritto: Yes, but unfortunately, LilyPond needs special sed treatment, since many substitutions are made *after* configure time. I will need to file a bug report... Specifically, I am looking for a way to make life easier when building LilyPond without package management (instead of running a sed script over all the python scripts every time I need to use them). A simple change to stepmake/aclocal.m4 would ease the process, but I think I'll keep this as a local patch for a while... I don't understand the issue; can't you just set PYTHON=python2 when calling configure, and in case you need some scripts in auxiliar call them by prepending python2 instead of relying on the shebang? If you're afraid of forgetting to pass these options, a solution is to define a couple of bash aliases in an shell environment dedicated for lily development. Best, John signature.asc Description: This is a digitally signed message part ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Distributions upgrading to Python 3
On Mon, Oct 18, 2010 at 9:17 AM, John Mandereau john.mander...@gmail.com wrote: Il giorno lun, 18/10/2010 alle 09.02 -0700, Patrick McCarty ha scritto: Yes, but unfortunately, LilyPond needs special sed treatment, since many substitutions are made *after* configure time. I will need to file a bug report... Specifically, I am looking for a way to make life easier when building LilyPond without package management (instead of running a sed script over all the python scripts every time I need to use them). A simple change to stepmake/aclocal.m4 would ease the process, but I think I'll keep this as a local patch for a while... I don't understand the issue; can't you just set PYTHON=python2 when calling configure, and in case you need some scripts in auxiliar call them by prepending python2 instead of relying on the shebang? Thanks! I didn't think of doing this... -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: T1265 - Remove deprecation warnings when running with Guile V2 (issue2204044)
http://codereview.appspot.com/2204044/diff/14001/flower/include/guile-compatibility.hh File flower/include/guile-compatibility.hh (right): http://codereview.appspot.com/2204044/diff/14001/flower/include/guile-compatibility.hh#newcode28 flower/include/guile-compatibility.hh:28: #define scm_to_unsigned(x) scm_to_uint (x) On 2010/10/08 02:35:44, Patrick McCarty wrote: This macro is not needed, either, AFAICS. If you say #define FOO 1 all instances of FOO are replaced with 1. With this patch, you do away with the one instance of scm_to_unsigned(x), replacing it with scm_to_uint(x). Since scm_to_unsigned(x) no longer appears in the code base (after applying this patch), this macro does nothing. Done. http://codereview.appspot.com/2204044/diff/14001/flower/include/guile-compatibility.hh#newcode30 flower/include/guile-compatibility.hh:30: #else // SCM_MINOR_VERSION 6 SCM_MINOR_VERSION = 9 On 2010/10/08 02:35:44, Patrick McCarty wrote: Just about :) The comment is now redundant... This should be #else // SCM_MINOR_VERSION = 9 Done. http://codereview.appspot.com/2204044/diff/14001/lily/dispatcher.cc File lily/dispatcher.cc (right): http://codereview.appspot.com/2204044/diff/14001/lily/dispatcher.cc#newcode195 lily/dispatcher.cc:195: } On 2010/10/08 02:35:44, Patrick McCarty wrote: Please fix the indentation here (revert to using a tab). Done. http://codereview.appspot.com/2204044/diff/14001/lily/include/lily-guile-macros.hh File lily/include/lily-guile-macros.hh (right): http://codereview.appspot.com/2204044/diff/14001/lily/include/lily-guile-macros.hh#newcode146 lily/include/lily-guile-macros.hh:146: TYPE ## _ ## FUNC ## _init_functions); On 2010/10/08 02:35:44, Patrick McCarty wrote: Revert back to tabs here. Done. http://codereview.appspot.com/2204044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: T1265 - Remove deprecation warnings when running with Guile V2 (issue2204044)
LGTM. Ian, please send me the git patch, and I'll apply it for you. Thanks, Patrick http://codereview.appspot.com/2204044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: font defects in scripts.varsegno and accordion.push
Can you open an issue directly on the tracker and post your attachments there? Done. It's issue #1335. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anybody understand the instrumentCueName docs?
On mailing list lilypond-user, Trevor Daniels wrote:
Keith E OHara wrote Wednesday, October 06, 2010 9:40 AM
I no longer see any reason to use instrumentCueName for the labels
that identify the instrument playing cue notes.
OK. I'll see what you suggest.
I suggest (diff attached) removing the part about instrumentCueName in favor of
a fuller example for \killCues. The manual teaches markup elsewhere; the
challenge with cue-note labels is to let the label appear with the cue notes in
parts, but not in the score.
bassoon = \relative c {
\clef bass
R1
\tag #'part {
\clef treble
s1*0^\markup { \tiny flute }
}
\cueDuring #flute #UP { R1 }
\tag #'part \clef bass
g4. b8 d2
%{%}
Corresponding suggestions for vocal.itely will follow shortly.
Related changes (in the same diff) that you can take if you like :
1) \cueDuring #flute may be used *before* \addQuote flute \flute appears
in the source file, and knowing that empowers users to write parts that quote each other.
2) Two pieces of instruction were a bit vague :
It is possible to tag cued parts with unique names in order to process them in
different ways.
[...] when cue notes end, the name of the original instrument should be printed,
and any other changes introduced by the cued part should be undone. This can be
accomplished by using @code{\addInstrumentDefinition}
I think the intent was to teach how to handle clef changes (as in the thread
http://lists.gnu.org/archive/html/lilypond-user/2008-02/msg00278.html)
As replacement I suggest, after the fuller \killCues example, :
+The @code{\killCues} command removes only the notes and events
+that were quoted by @code{\cueDuring}. Other markup associated
+with cues, such as clef changes and a label identifying the source
+instrument, can be tagged for selective inclusion in the score;
+see @ref{Using tags}. Clef changes and instrument labels can be
+collected into an instrument definition for repeated use, using
+...@code{\addinstrumentdefinition} described in @ref{Instrument
+names}.
3) The description of transposedCueDuring might have been wrong (or I
interpreted it wrongly) in the case of transposing instruments.
My suggested replacement comes from experiment and inspection of
quote-iterator.cc.
-Keith
staff.itely.diff
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Distributions upgrading to Python 3
On Mon, Oct 18, 2010 at 11:57 PM, Matthias Kilian k...@outback.escape.de wrote: (unlurking, i didn't spend much time on lilypond recently) python/ yes, since it's not something that people call manually. But stuff in scripts/build/ shouldn't have @PYTHON@, otherwise it'll bork if you call it manually. But are those scripts supposed to be used without runnig autogen.sh (and implied configure) first? Anything that's used to build the website (as opposed to the html version of the docs) cannot rely on configure. This affects scripts/build/ create-*.py website_post.py bib2texi.py ... admittedly, those are getting called with python scripts/build/foo.py , probably precisely to avoid this problem. So I guess that's not a concern. I was incorrect in a previous email -- it's stuff in scripts/auxiliar/ that I run manually, not stuff in scripts/build/. scripts/auxiliar/ makelsr.py node-menify.py strip-whitespace.py Would it be feasible to use #!/usr/bin/env @PYTHON@ or #!/usr/bin/env @TARGET_PYTHON@ for all Python scripts, using the basename of the appropriate Python executable in place of the Make variables? #!/usr/bin/env YOUR_FAVORITE_INTERPRETER should not be used ever. At least not for scripts that will be installed system-wide. Why not? IIRC, we had to add this to work around some problem in OSX. The discussion is in the email archives... hopefully somebody can dig it out for us. If there's a good reason not to do this, and a better way of solving whatever problem we solved with /usr/bin/env python, I welcome a change. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anybody understand the instrumentCueName docs?
On Mon, 18 Oct 2010 15:40:54 -0700, Keith E OHara wrote:
Corresponding suggestions for vocal.itely will follow shortly.
One thing worth discussing is that I use the verb to cue differently from the
original author.
I believe that to cue is to *give* a signal for someone else to begin action.
So the instrument playing just before the singer begins is the cue-ing
instrument (or the quoted instrument) and the singer is cued. Similarly, the
notes are 'cue notes', which we might have hyphenated fifty years ago, rather
than 'cued notes'.
Suggestions attached as a diff,
except that the cueWhile function is in a snippet, not the .itely, so the
corresponding change is below :
cueWhile =
#(define-music-function
(parser location instrument name dir music)
(string? string? ly:dir? ly:music?)
#{
\cueDuring $instrument #$dir {
\once \override TextScript #'self-alignment-X = #RIGHT
\once \override TextScript #'direction = $dir
s1*0-\markup { \tiny $name }
$music
}
#}
)
-Keith
vocal.itely.diff
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Distributions upgrading to Python 3
(unlurking, i didn't spend much time on lilypond recently) On Mon, Oct 18, 2010 at 01:59:15AM +0100, Graham Percival wrote: --) Two scripts still have /usr/bin/python lines (python/auxiliar/manuals_definitions.py, and scripts/build/pytt.py). Those should be changed to @PYTHON@, right? python/ yes, since it's not something that people call manually. But stuff in scripts/build/ shouldn't have @PYTHON@, otherwise it'll bork if you call it manually. But are those scripts supposed to be used without runnig autogen.sh (and implied configure) first? I may have some time during the next two weeks and arrange things so those scripts will use the python detected by (or passed via environment to) configure. If you want it. Would it be feasible to use #!/usr/bin/env @PYTHON@ or #!/usr/bin/env @TARGET_PYTHON@ for all Python scripts, using the basename of the appropriate Python executable in place of the Make variables? #!/usr/bin/env YOUR_FAVORITE_INTERPRETER should not be used ever. At least not for scripts that will be installed system-wide. And if possible, not even for local scripts (like scripts/build in lilypond). Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
