Re: lilypond documentation build issue (both 2.18.2 and 2.19.16)
Petr Gajdos pgaj...@suse.cz writes: On Fri, Mar 06, 2015 at 03:33:21PM +0100, Petr Gajdos wrote: On Fri, Mar 06, 2015 at 03:09:36PM +0100, David Kastrup wrote: So the problem is not one with fretted-strings.texi but rather with what causes your build procedure to run texi2pdf on it in the first place. Thanks for the pointer, will try to look in this direction. The issue in question begins sooner: $ cat internals.bigtexi.log Undefined subroutine main::get_index called at /home/abuild/rpmbuild/BUILD/lilypond-2.18.2/Documentation/lilypond-texi2html.init line 2127. If this is relevant, texi2html-5.0/texi2html.pl do not contain sub get_index in contrast of texi2html-1.82/texi2html.pl. Whoa. That one certainly looks like it will need attention soonish. I did not realize that we had what amounts to such a large modification of texi2html in our code base. Reinhold, any idea how to proceed here? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond documentation build issue (both 2.18.2 and 2.19.16)
On Fri, Mar 06, 2015 at 03:33:21PM +0100, Petr Gajdos wrote: On Fri, Mar 06, 2015 at 03:09:36PM +0100, David Kastrup wrote: So the problem is not one with fretted-strings.texi but rather with what causes your build procedure to run texi2pdf on it in the first place. Thanks for the pointer, will try to look in this direction. The issue in question begins sooner: $ cat internals.bigtexi.log Undefined subroutine main::get_index called at /home/abuild/rpmbuild/BUILD/lilypond-2.18.2/Documentation/lilypond-texi2html.init line 2127. If this is relevant, texi2html-5.0/texi2html.pl do not contain sub get_index in contrast of texi2html-1.82/texi2html.pl. Petr signature.asc Description: Digital signature ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond documentation build issue (both 2.18.2 and 2.19.16)
On Mon, Mar 09, 2015 at 01:29:39PM +0100, David Kastrup wrote: Petr Gajdos pgaj...@suse.cz writes: If this is relevant, texi2html-5.0/texi2html.pl do not contain sub get_index in contrast of texi2html-1.82/texi2html.pl. Whoa. That one certainly looks like it will need attention soonish. I did not realize that we had what amounts to such a large modification of texi2html in our code base. Oh, there's a pretty big chunk of custom stuff in lilypond texi2html. See past discussion here: https://code.google.com/p/lilypond/issues/detail?id=1000 Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
toward-stem-shift-in-column should only consider 'script-interface (issue 207620043 by david.nales...@gmail.com)
Reviewers: , Message: Please review. Thanks. Description: toward-stem-shift-in-column should only consider 'script-interface Previously, toward-stem-shift-in-column did not discriminate between different types of grobs in the 'scripts grob-array. This meant that TextScript, StringNumber, and Fingering objects would be caught as well. This patch only shifts an articulation in the presence of another Script grob. Please review this at https://codereview.appspot.com/207620043/ Affected files (+8, -1 lines): M scm/output-lib.scm Index: scm/output-lib.scm diff --git a/scm/output-lib.scm b/scm/output-lib.scm index 96456b1b77fb436ae4a90b6b7ae851c30fa01678..23de7381f62b4c8d8d1c0186e6f33bffd2d9d01f 100644 --- a/scm/output-lib.scm +++ b/scm/output-lib.scm @@ -1187,7 +1187,14 @@ parent or the parent has no setting. (let* ((shift-when-alone (ly:grob-property grob 'toward-stem-shift 0.0)) (shift-in-column (ly:grob-property grob 'toward-stem-shift-in-column)) (script-column (ly:grob-object grob 'script-column)) - (shift (if (and (ly:grob? script-column) (number? shift-in-column)) + (shift (if (and (ly:grob? script-column) + (number? shift-in-column) + ;; ScriptColumn can contain grobs other than Script. These + ;; should not result in a shift. + (any (lambda (s) +(and (not (eq? s grob)) + (grob::has-interface s 'script-interface))) + (ly:grob-array-list (ly:grob-object script-column 'scripts shift-in-column shift-when-alone)) (note-head-location (ly:self-alignment-interface::aligned-on-x-parent grob)) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
removing `max-stretch'
Folks, the old vertical layout parameter `max-stretch', non-functional since 2.13.4 (from 2009), should be removed – this is a trivial patch. However, I wonder whether we should provide a rule for convert-ly and how it should look like... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add support for unicode filenames on Windows (issue 206640043 by pkx1...@gmail.com)
Thank you for the mail. I've written reply to the tracker web page. https://code.google.com/p/lilypond/issues/detail?id=4317 Reviewers: , Message: Pasting update in Tracker by David K for Masamichi's benefit: --snip-- by d...@gnu.org: Patch: Add support for unicode filenames on Windows https://code.google.com/p/lilypond/issues/detail?id=4317 Ok, I've been stalling on this patch for about a week because I don't have a good idea how to address it properly. So let's start with the worst first: at the current point of time, I don't see it making sense, and in addition I will not be able to spend significant amount of time addressing the problems arising in connection with it for about a month, so I'd like a moratorium on it for about that time. The main problem is that the next step needed for GUILEv2 migration (which nobody is really interested in working on apart from myself) is to get the coding mess sorted out. GUILEv1 is basically working with byte streams in its strings and string ports and files. GUILEv2 is coding system aware, uses either Latin-1 or UTF-32 as its string internals, uses UTF-8 for string ports (necessitating copies and conversions rather than being able to work in-place) and converts back and forth all the time. Since LilyPond has a lexer working on an UTF-8 coded byte stream and data is liberally bounced around between files, strings, and string ports, and the respective position pointers are not distinguished. It does not help that GUILEv2 changes its ways to pick particular encodings basically every 3 or 4 stable versions in the 2.0 series, and 2.1 is different again. So we need to carefully refactor the code in order to have a chance of it working in both GUILEv1 and GUILEv2 (and at all in GUILEv2). This is an ugly and ungrateful task that has been at the front of my this-is-really-up-next-so-let's-procrastinate-instead queue the last month or so. Letting a patch like this in right now would make the situation worse. Viewed realistically, this patch also needs Ghostscript updates in GUB to make any sense. There is no reason _those_ cannot go ahead first: having a buffer of a few developer releases where we might discover and sort out possible problems with newer versions of GhostScript on our crosscompiled distributions seems sensible. Personally, I don't really like the look of this patch at all as it is very specifically useful only for one platform, and apart from that I'd very much want to avoid seeing any wide character functions in LilyPond code: that's rarely exercised library code of often dubious reliability or availability, and most programmers are not overly comfortable utilizing it. I'd very much prefer that we'd find a better encapsulated solution, probably by utilizing the encoding support of GUILEv2. Which again suggests that a moratorium on this patch makes sense, but that one would not be until David gets encodings sorted out so that we can compile and test on GUILEv2 but rather on until we are able to ditch GUILEv1 altogether. And given the current enthusiasm for working on the GUILEv2 migration and the likelihood of necessary bug fixes in GUILE itself becoming available as we discover problems, the latter is likely quite longer than a month away. The problem this patch tries to address is not a recent problem, and the workaround (don't use special Unicode characters in filenames) is obvious. So the urgency seems limited. I very much agree that LilyPond should not balk at file and directory names containing accented characters on all platforms. But I think we will be doing ourselves our favor to postpone addressing this problem until we have moved LilyPond to GUILEv2, and then look for the best-matching solution within _this_ framework. Otherwise we complicate the coding issue work for GUILEv2 migration and that's something we can afford less than prolonging the current filename encoding situation. -- You received this message because you are the owner of the issue. You may adjust your notification preferences at: https://code.google.com/hosting/settings Reply to this email to add a comment or make updates. Description: Add support for unicode filenames on Windows On Windows, LilyPond can't handle unicode filenames. The patch replaces main(), and hooks filename related functions. This converts between UTF-16 unicode (Windows) and UTF-8 unicode (LilyPond, libguile etc.). LilyPond can handle unicode filenames for *.ly, *.mid, *.ps. *.pdf is not supported yet. Ghostscript-8.70 that is included in the binary distribution of LilyPond can't handle unicode filenames. This requires Ghostscript-9.10 or later Please review this at https://codereview.appspot.com/206640043/ Affected files (+523, -0 lines): A flower/include/mingw-utf8.hh A flower/include/mingw-utf8-conv.hh A flower/include/mingw-utf8-func.hh A
Re: toward-stem-shift-in-column should only consider 'script-interface (issue 207620043 by david.nales...@gmail.com)
https://codereview.appspot.com/207620043/diff/20001/scm/output-lib.scm File scm/output-lib.scm (right): https://codereview.appspot.com/207620043/diff/20001/scm/output-lib.scm#newcode1195 scm/output-lib.scm:1195: (and (not (eq? s grob)) I am recognizing Script grobs in the orthodox way--i.e., through interfaces. This would be considerably less cluttered if I used (grob::name s 'Script) instead. https://codereview.appspot.com/207620043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: toward-stem-shift-in-column should only consider 'script-interface (issue 207620043 by david.nales...@gmail.com)
https://codereview.appspot.com/207620043/diff/20001/scm/output-lib.scm File scm/output-lib.scm (right): https://codereview.appspot.com/207620043/diff/20001/scm/output-lib.scm#newcode1195 scm/output-lib.scm:1195: (and (not (eq? s grob)) On 2015/03/09 17:09:23, david.nalesnik wrote: I am recognizing Script grobs in the orthodox way--i.e., through interfaces. This would be considerably less cluttered if I used (grob::name s 'Script) instead. That would be (eq? (grob::name s) 'Script) https://codereview.appspot.com/207620043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES: Countdown for March 12th 2015
Hello, Here is the current patch countdown list. The next countdown will be on March 12th. You can always view the most current countdown list here: http://code.google.com/p/lilypond/issues/list?q=Patch%3Apush%2Ccountdown%2Creview%2Cnew%2Cwaitingcolspec=Patch%20Owner%20ID%20Summarysort=patch PUSH: David Kastrup: Patch: Make multimeasure rests obey tweaks http://code.google.com/p/lilypond/issues/detail?id=4311 Trevor Daniels: Clarify the warning about 'bare durations' http://code.google.com/p/lilypond/issues/detail?id=4309 Trevor Daniels: Misleading documentation of bar checks in lyrics http://code.google.com/p/lilypond/issues/detail?id=4303 COUNTDOWN: James Lowe: Patch: Web: Aurélien Bello's Der Rosenkavalier http://code.google.com/p/lilypond/issues/detail?id=4318 Colin Campbell: Patch: Fix unset PATH crash http://code.google.com/p/lilypond/issues/detail?id=4315 David Kastrup: Patch: Remove forgotten debug output in articulate.ly http://code.google.com/p/lilypond/issues/detail?id=4314 Urs Liska: Patch: Remove redundant (and) in ly/init.ly http://code.google.com/p/lilypond/issues/detail?id=4313 James Lowe: Patch: Web: revise home page and old news page http://code.google.com/p/lilypond/issues/detail?id=4312 Trevor Daniels: \stemUp and \stemDown predefs should be exposed less http://code.google.com/p/lilypond/issues/detail?id=4181 Trevor Daniels: Code improvements to satb.ly built-in template http://code.google.com/p/lilypond/issues/detail?id=3777 NEW: David Nalesnik: Patch: toward-stem-shift-in-column should only consider 'script-interface http://code.google.com/p/lilypond/issues/detail?id=4319 WAITING: Urs Liska: Patch: Issue 3916: Add \alternatingTimeSignatures http://code.google.com/p/lilypond/issues/detail?id=3918 Mike Solomon: Patch: Prevents vertical axis groups with empty skylines http://code.google.com/p/lilypond/issues/detail?id=3156 Mike Solomon: Patch: Removes the translate_axis call from axis-group-interface outside-staff positioning. http://code.google.com/p/lilypond/issues/detail?id=3134 David Kastrup: Patch: Implement music functions in Scheme rather than C++ http://code.google.com/p/lilypond/issues/detail?id=2716 Thank you, James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: revise home page and old news page (issue 211190043 by paulwmor...@gmail.com)
Patch on countdown for March 12th https://codereview.appspot.com/211190043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Add support for unicode filenames on Windows (issue 206640043 by pkx1...@gmail.com)
Reviewers: , Message: Pasting update in Tracker by David K for Masamichi's benefit: --snip-- by d...@gnu.org: Patch: Add support for unicode filenames on Windows https://code.google.com/p/lilypond/issues/detail?id=4317 Ok, I've been stalling on this patch for about a week because I don't have a good idea how to address it properly. So let's start with the worst first: at the current point of time, I don't see it making sense, and in addition I will not be able to spend significant amount of time addressing the problems arising in connection with it for about a month, so I'd like a moratorium on it for about that time. The main problem is that the next step needed for GUILEv2 migration (which nobody is really interested in working on apart from myself) is to get the coding mess sorted out. GUILEv1 is basically working with byte streams in its strings and string ports and files. GUILEv2 is coding system aware, uses either Latin-1 or UTF-32 as its string internals, uses UTF-8 for string ports (necessitating copies and conversions rather than being able to work in-place) and converts back and forth all the time. Since LilyPond has a lexer working on an UTF-8 coded byte stream and data is liberally bounced around between files, strings, and string ports, and the respective position pointers are not distinguished. It does not help that GUILEv2 changes its ways to pick particular encodings basically every 3 or 4 stable versions in the 2.0 series, and 2.1 is different again. So we need to carefully refactor the code in order to have a chance of it working in both GUILEv1 and GUILEv2 (and at all in GUILEv2). This is an ugly and ungrateful task that has been at the front of my this-is-really-up-next-so-let's-procrastinate-instead queue the last month or so. Letting a patch like this in right now would make the situation worse. Viewed realistically, this patch also needs Ghostscript updates in GUB to make any sense. There is no reason _those_ cannot go ahead first: having a buffer of a few developer releases where we might discover and sort out possible problems with newer versions of GhostScript on our crosscompiled distributions seems sensible. Personally, I don't really like the look of this patch at all as it is very specifically useful only for one platform, and apart from that I'd very much want to avoid seeing any wide character functions in LilyPond code: that's rarely exercised library code of often dubious reliability or availability, and most programmers are not overly comfortable utilizing it. I'd very much prefer that we'd find a better encapsulated solution, probably by utilizing the encoding support of GUILEv2. Which again suggests that a moratorium on this patch makes sense, but that one would not be until David gets encodings sorted out so that we can compile and test on GUILEv2 but rather on until we are able to ditch GUILEv1 altogether. And given the current enthusiasm for working on the GUILEv2 migration and the likelihood of necessary bug fixes in GUILE itself becoming available as we discover problems, the latter is likely quite longer than a month away. The problem this patch tries to address is not a recent problem, and the workaround (don't use special Unicode characters in filenames) is obvious. So the urgency seems limited. I very much agree that LilyPond should not balk at file and directory names containing accented characters on all platforms. But I think we will be doing ourselves our favor to postpone addressing this problem until we have moved LilyPond to GUILEv2, and then look for the best-matching solution within _this_ framework. Otherwise we complicate the coding issue work for GUILEv2 migration and that's something we can afford less than prolonging the current filename encoding situation. -- You received this message because you are the owner of the issue. You may adjust your notification preferences at: https://code.google.com/hosting/settings Reply to this email to add a comment or make updates. Description: Add support for unicode filenames on Windows On Windows, LilyPond can't handle unicode filenames. The patch replaces main(), and hooks filename related functions. This converts between UTF-16 unicode (Windows) and UTF-8 unicode (LilyPond, libguile etc.). LilyPond can handle unicode filenames for *.ly, *.mid, *.ps. *.pdf is not supported yet. Ghostscript-8.70 that is included in the binary distribution of LilyPond can't handle unicode filenames. This requires Ghostscript-9.10 or later Please review this at https://codereview.appspot.com/206640043/ Affected files (+523, -0 lines): A flower/include/mingw-utf8.hh A flower/include/mingw-utf8-conv.hh A flower/include/mingw-utf8-func.hh A flower/include/mingw-utf8-hook.hh A flower/mingw-utf8-conv.cc A flower/mingw-utf8-func.cc A flower/mingw-utf8-hook.cc A flower/mingw-utf8-main.cc M lily/GNUmakefile M lily/main.cc ___
