Re: utf-8-string
Hi Mike,
On Mon, Feb 6, 2012 at 4:55 AM, m...@apollinemike.com
m...@apollinemike.com wrote:
Hey all,
I see a shortcut for utf-8-strings in pango-font.cc. This is
all well and good except that it is hard to do box
approximations on these guys (it'd require adding lots of code).
How mad would LilyPond be if I just deleted all of the
utf-8-string business? I don't think it'd change the visual
output...it'd just get rid of a shortcut. Does anyone have any
justification for keeping this shortcut?
Yes :) It's not actually a shortcut, despite the code comment.
Every backend is a Pango-based backend if it uses a text
stencil.
utf-8-string is absolutely critical for the SVG backend (not sure
about the socket backend)...
In the code, description_string() (see lily/pango-font.cc:378)
returns a string in the PangoFontDescription format. This format
is best described in the pygtk docs:
http://www.pygtk.org/docs/pygtk/class-pangofontdescription.html
The SVG backend uses this information (font style, weight, etc.)
to assign accurate attribute values. Then they are output as SVG
text elements with the appropriate font-weight, style, etc. If
this information did not exist, any string in the SVG output not
using a LilyPond font would likely display incorrectly.
utf-8-string is not used in the PS backend because Pango takes
care of the processing internally, calculating kerning, font
weight, and other attributes before the stencil expression is
evaluated in the backend. IIRC, every string of text using a
non-LilyPond font is a glyph-string in the PS backend.
That said, what issues are you seeing with the box approximations
for utf-8-string? I'm seeing tight fits when running `lilypond
-dbackend=svg -dpreview', for example with
\version 2.15.28
\markup { Lily }
Regards,
Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: utf-8-string
On Tue, Feb 7, 2012 at 7:19 PM, Patrick McCarty pnor...@gmail.com wrote: On Mon, Feb 6, 2012 at 4:55 AM, m...@apollinemike.com m...@apollinemike.com wrote: Hey all, I see a shortcut for utf-8-strings in pango-font.cc. This is all well and good except that it is hard to do box approximations on these guys (it'd require adding lots of code). How mad would LilyPond be if I just deleted all of the utf-8-string business? I don't think it'd change the visual output...it'd just get rid of a shortcut. Does anyone have any justification for keeping this shortcut? utf-8-string is absolutely critical for the SVG backend (not sure about the socket backend)... To follow up, I just noticed your patch that reworks vertical skylines, and I assume that your concern about utf-8-string is related to this. Let me know if I'm wrong. For now, here's an idea: - Introduce a new argument to 'utf-8-string' that exposes vertical extent information for each glyph in the string. It could be a simple list of pairs. For example: (utf-8-string Century Schoolbook L Bold 16 test '((0.0 . 1) (0.0 . 0.6) (0.0 . 0.6) (0.0 . 1))) The number of pairs in the list will match the length of the (UTF-8) string, of course. I don't think the glyph width, offsets, and characters are really needed in the list, unless you can think of a use for them in your vertical skyline calculations. In the long term, it may be better to unify the stencil expressions used for text, but as it stands, I think it would be easier to add information to the existing stencil expressions (as you are doing for 'glyph-string' in your patchset). Regards, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Finding commits
On Sun, Sep 11, 2011 at 8:52 AM, Phil Holmes em...@philholmes.net wrote: To verify that a patch Issue has been fixed, we check the commit. Using the git web interface, is there a way to find the commit from the commitish? I've tried but can't find a way, but I'm assuming I'm missing something. There is no way to search for a committish (AFAIK) through the gitweb interface. That said, notice that the committish is part of the URL for a particular commit/commitdiff. So, you can craft a URL to display the commit you are looking for. For example, the diff for commit d63744cb5e26c4ec8e125a05f9f45654496c248b is shown here: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=d63744cb5e26c4ec8e125a05f9f45654496c248b Regards, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: T1349 - Fix load order for running with Guile V2 (issue 4849054)
On Thu, Aug 18, 2011 at 3:30 AM, Ian Hulin ianhuli...@gmail.com wrote: On Thu 18 Aug 2011 07:50:28 BST, pnor...@gmail.com wrote: The load-order issue appears to be fixed, testing with git and guile 1.8 and 2.0.2. Ignoring whitespace changes, this patch LGTM. Some more shuffling is needed to make sure we have markup commands defined where they need to be, but that's beyond the scope of this patch. Should we have a Lilypond Markup Syntax/Guile V2 Tracker, then? I think we should have one tracker per issue that we encounter. It becomes difficult to handle what has been fixed (and where) when we have umbrella issues. If there are any dependencies in the load list that you know about that can still bite us could we record these in the tracker, for instance the markup command itself works with both Guile 1.8 and 2.0 if it is loaded later in the list in a module apart from markup-macros.scm, but fails with 2.0 if you move the definition from markup.scm to the bottom of markup-macros.scm. Yes, any issues we find like this should have separate tracker issues. I've just opened one: https://code.google.com/p/lilypond/issues/detail?id=1826 I'll open more later today if I find time. There are also some design issues to consider like: Would the markup.scm and markup-macros.scm definitions work better as a SCM module? Possibly. Should we/can we move over to making the markup subsystem hygienic by using define-syntax? (This is quite a big piece of work, and last time I tried looking at it, it seemed like it should be simple but made my head hurt). It's a translation exercise very like doing the document translation, and currently definitely needs to be done by a human being rather than software. If we want backwards compatibility with Guile 1.8, we shouldn't move to define-syntax, as it's not implemented in Guile 1.8. :P Current plans once this is pushed is to tackle Tracker 1780 (Guile V2 squawking with deprecation errors because of (format) calls without a destination parameter) and then get back to Tracker 1686 (tackling the issue of scheme compilation). Sounds good, thanks Ian! ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 1: python formatting
On Sun, Jun 5, 2011 at 4:01 PM, Graham Percival gra...@percival-music.ca wrote: Proposal: let’s follow PEP-8. http://www.python.org/dev/peps/pep-0008/ * use 4 spaces per indentation level * never max tabs and spaces * Code indented with a mixture of tabs and spaces should be converted to using spaces exclusively Sounds good to me. Regards, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: sorting out branch conflicts
On Sun, Jun 5, 2011 at 4:18 PM, Graham Percival gra...@percival-music.ca wrote: To whoever enjoys this stuff, :-) 2) make release/unstable be exactly what we have in master. I've just taken care of this. Regards, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: guile 2.0 and ghostscript 9.0
On Mon, Jun 6, 2011 at 8:15 AM, Graham Percival gra...@percival-music.ca wrote: What's the plan+status of these? I'd like to have the first release candidate for 2.16 in 3-4 months. If we think that we can sort out any problems with those dependencies... or any other build dependencies, for that matter... then let's start merging them. If not, they can wait until 2.17. I can only speak for the status of LilyPond + Guile 2 on LilyPond's side. - Issues in the Scheme code base. This is mostly backwards-compat work dealing with macro usage. - Build system support for compiling and installing Guile 2 .go (Guile Object) files; without using the .go cache, Guile 2 is *very* slow... - Issues with garbage collection. LilyPond may not be using smobs correctly to work well with Guile 2, since memory usage is very high, especially when processing multiple files in sequence. - The decision of whether we want to support both Guile 1.8 and 2.0 moving forward. At this point, it still looks possible, but I haven't done a full-scale investigation of the previous issues yet. I've done preliminary work (in dev/patrick), but none of it is ready to be merged. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Parsed object should be dead
Hi Mike, On Mon, May 30, 2011 at 4:08 PM, m...@apollinemike.com m...@apollinemike.com wrote: I've been getting this from LilyPond recently: programming error: Parsed object should be dead: static scm_unused_struct* Prob::mark_smob(scm_unused_struct*) continuing, cross fingers This usually means that there is a memory leak happening somewhere. Is anyone else getting this too? About a month ago (last time I compiled LilyPond), I did not see it. This was after compiling with --disable-optimising. Do you recall when you started seeing the programming error? Regards, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond errors with gcc 4.6
Hi Bernardo, On Wed, Mar 30, 2011 at 9:10 PM, Patrick McCarty pnor...@gmail.com wrote: On 2011-03-29, Bernardo Barros wrote: I think we might need some little changes to compile lilypond with gcc 4. I'm getting the following errors with latest git. http://pastebin.com/gjsLv0Fe My guess is that the gcc 4.6.0 rebuild is buggy. Let's wait to see if this makes it into core or not. :) I just did a test run with the second GCC 4.6 rebuild (in [testing]), and I can still reproduce the issue. Since I'm pretty sure this is not a LilyPond bug, I filed a bug for Arch Linux: https://bugs.archlinux.org/task/23685 Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond errors with gcc 4.6
Hi, In the future, please send messages like this to -devel. I don't think everyone on -user wants to see these nasty linker errors... On 2011-03-29, Bernardo Barros wrote: I think we might need some little changes to compile lilypond with gcc 4. I'm getting the following errors with latest git. http://pastebin.com/gjsLv0Fe I did a test run with Arch [testing], and yes, I can (mostly) reproduce. [snip] ./out/skyline-pair.o: In function `std::listBuilding, std::allocatorBuilding ::_M_erase(std::_List_iteratorBuilding)': /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_list.h:1532: undefined reference to `std::__detail::_List_node_base::_M_unhook()' I don't see any errors from `./out/skyline-pair.o'. There are also fewer errors in my log than in yours. See the attached log. My guess is that the gcc 4.6.0 rebuild is buggy. Let's wait to see if this makes it into core or not. :) Thanks, Patrick ./out/accidental-placement.o: In function `std::listBuilding, std::allocatorBuilding ::_M_erase(std::_List_iteratorBuilding)': /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_list.h:1532: undefined reference to `std::__detail::_List_node_base::_M_unhook()' ./out/accidental-placement.o: In function `std::listBuilding, std::allocatorBuilding ::_M_transfer(std::_List_iteratorBuilding, std::_List_iteratorBuilding, std::_List_iteratorBuilding)': /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_list.h:1508: undefined reference to `std::__detail::_List_node_base::_M_transfer(std::__detail::_List_node_base*, std::__detail::_List_node_base*)' ./out/accidental-placement.o: In function `std::listBuilding, std::allocatorBuilding ::_M_insert(std::_List_iteratorBuilding, Building const)': /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_list.h:1516: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)' ./out/skyline.o: In function `std::listBuilding, std::allocatorBuilding ::reverse()': /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_list.h:1416: undefined reference to `std::__detail::_List_node_base::_M_reverse()' ./out/skyline.o: In function `std::listBox, std::allocatorBox ::_M_erase(std::_List_iteratorBox)': /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_list.h:1532: undefined reference to `std::__detail::_List_node_base::_M_unhook()' ./out/skyline.o: In function `std::listBox, std::allocatorBox ::swap(std::listBox, std::allocatorBox )': /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_list.h:1179: undefined reference to `std::__detail::_List_node_base::swap(std::__detail::_List_node_base, std::__detail::_List_node_base)' ./out/skyline.o: In function `std::listBox, std::allocatorBox ::_M_insert(std::_List_iteratorBox, Box const)': /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_list.h:1516: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)' ./out/skyline.o: In function `std::listBox, std::allocatorBox ::_M_transfer(std::_List_iteratorBox, std::_List_iteratorBox, std::_List_iteratorBox)': /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_list.h:1508: undefined reference to `std::__detail::_List_node_base::_M_transfer(std::__detail::_List_node_base*, std::__detail::_List_node_base*)' ./out/tie-performer.o: In function `std::listHead_audio_event_tuple, std::allocatorHead_audio_event_tuple ::_M_insert(std::_List_iteratorHead_audio_event_tuple, Head_audio_event_tuple const)': /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_list.h:1516: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)' ./out/tie-performer.o: In function `std::listHead_audio_event_tuple, std::allocatorHead_audio_event_tuple ::_M_erase(std::_List_iteratorHead_audio_event_tuple)': /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_list.h:1532: undefined reference to `std::__detail::_List_node_base::_M_unhook()' ./out/tie-performer.o: In function `std::listHead_audio_event_tuple, std::allocatorHead_audio_event_tuple ::_M_transfer(std::_List_iteratorHead_audio_event_tuple, std::_List_iteratorHead_audio_event_tuple, std::_List_iteratorHead_audio_event_tuple)': /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_list.h:1508: undefined reference to `std::__detail::_List_node_base::_M_transfer(std::__detail::_List_node_base*, std::__detail::_List_node_base*)' collect2: ld returned 1 exit status make[1]: *** [out/lilypond] Error 1 make: *** [all] Error 2 ___ lilypond-devel mailing list lilypond-devel@gnu.org
Re: git rebase and gitk
On Sun, Feb 27, 2011 at 7:00 AM, Graham Percival gra...@percival-music.ca wrote: Hi Mike, Could I introduce you to the wonders of git-rebase ? In particular: git rebase -i master^^ (however many ^ you need to cover all your recent work) This lets you clean up your git history before pushing to master, thereby giving us a much less cluttered history. This is an excellent suggestion. It is worth noting that `git rebase' is a very powerful command, since you can potentially rewrite all of git history with it. So, in general, be careful that you're not modifying commits that have already been pushed to savannah. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: T1247 - Conditionally do (use-modules (ice-9 curried-definitions)) if running with Guile V2, (issue2219044)
On Sun, Feb 20, 2011 at 4:38 AM, Ian Hulin ianhuli...@gmail.com wrote: Hi Patrick, On 18/02/11 02:13, pnor...@gmail.com wrote: LGTM. Can you email me your patch so I can apply it? Here's the patch. I retested everything, and the patch checks out just fine. I've pushed it. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: guile 2.0.0 out
On Wed, Feb 16, 2011 at 10:04 AM, Graham Percival gra...@percival-music.ca wrote: I don't see a need to support both guile 1.8.x and guile 2.0.x at the same time -- as far as I'm concerned, we can drop any guile-1.x-isms as soon as 2.15 begins. Uh, I'm not sure what you mean here. I have a patch queue with (potential) fixes for LilyPond so that we can support both Guile 1.8 and 2.0. I don't think it's wise to drop support for Guile 1.8, as long as the Guile developers continue to fix backward-compatibility issues with the 2.0 series, just like they have in the 1.9 series. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: guile 2.0.0 out
On Wed, Feb 16, 2011 at 7:22 PM, Graham Percival gra...@percival-music.ca wrote: On Wed, Feb 16, 2011 at 07:08:29PM -0800, Patrick McCarty wrote: I have a patch queue with (potential) fixes for LilyPond so that we can support both Guile 1.8 and 2.0. Great! Comment 5 of http://code.google.com/p/lilypond/issues/detail?id=1247 is no longer valid? Yeah, I'm pretty sure Jan's recent commit in master (05514c83a49dd) removed the rest of the currying functions that Ian and I were puzzling over. The reason I'm only pretty sure is because I will be doing further tests tonight to see if that's really true. I'll comment on Ian's patch after I test-compile 2.0 without it. I wasn't trying to force us to drop guile 1.8; I was just making sure that we agreed that guile 2.0 wasn't going into 2.14, and fishing for comments like we can support both Guile 1.8 and 2.0. :) I agree with you there. I intend to continue working on backward-compatibility patches for 2.14 that will work on both Guile 1.8 and 2.0, but the Guile-2.0-specific patches (if needed) will have to wait for 2.15. I only slightly misunderstood your email after all... ;) Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: harmonics and slides
On Sun, Feb 13, 2011 at 6:28 AM, Patrick Schmidt p.l.schm...@gmx.de wrote: I tried to upload three patches to rietveld. I got the message: pls@pls:~/lilypond-git$ git pull -r Current branch master is up to date. pls@pls:~/lilypond-git$ git cl upload origin/master Cannot upload with a dirty tree. You must commit locally first. What do I have to do? This means, in git terminology, that you have unstaged changes in your local git tree. Run `git status' to see what files are included in the unstaged changes, and run `git diff' to see what the specific changes are. If you want to submit these unstaged changes to Rietveld, commit them first before running the `git cl' command. If not, run `git stash' to temporarily stow the changes away. (A `git stash pop' can restore the stowed-away changes.) Hope this helps! Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1294 - Lyric ties
On Sat, Feb 12, 2011 at 9:51 AM, Phil Holmes m...@philholmes.net wrote:
I'm checking some of the lyric-based issues in case they've been fixed in
the latest release, and came back across
http://code.google.com/p/lilypond/issues/detail?id=1294
[snip]
{
\time 3/4
\relative c' { c2 e4 g2 e4 }
\addlyrics { gran- de_a- mi- go }
\addlyrics { pu- ro y ho- nes- to }
\addlyrics { pu- ro~y~ho- nes- to }
\addlyrics {
\override LyricText #'font-name = #DejaVu Sans
pu- ro~y~ho- nes- to
}
}
Now - there's one other interesting feature here. If I delete the fourth
line of the lyrics above (the one with the explicit font) and run Lily
2.13.49, saving the PS file, it has the following in the postscript header:
%%DocumentMedia: a4 595.28 841.89 80 () ()
%%DocumentSuppliedResources: font CenturySchL-Roma
%%DocumentSuppliedResources: font Emmentaler-20
%%DocumentSuppliedResources: font MS-Gothic
%%EndComments
If I run the same file in 2.12.3 I get:
%%DocumentMedia: a4 595.28 841.89 80 () ()
%%DocumentSuppliedResources: font CenturySchL-Roma
%%DocumentSuppliedResources: font DejaVuSans
%%DocumentSuppliedResources: font Emmentaler-20
%%DocumentSuppliedResources: font feta-alphabet20
%%EndComments
which is interesting - 2.12 has found a font with the glyph in, and has
automatically used it. 2.13 doesn't do this.
Sorry - but this, for me, is back to looking like a regression.
Yes, looking back at the tracker, my focus was in finding the reason
why 2.13 was not loading fonts correctly. I completely disregarded
the regression from 2.12.3, and as a result, I didn't really
investigate the behavior of 2.12.3...
We need to revisit this issue to figure out why it works in 2.12.3,
but not in 2.13.
However... I'm almost certain that this is an issue with the build
system. Do we really want to block 2.13 for a font-related build
system regression? There are other build system regressions, notably
when we bumped Pango from 1.24.4 to 1.26.0. Over time, I'm starting
to believe that some regressions were introduced between Guile 1.8.0
and 1.8.7, too.
I am willing to bump this back to a critical regression, since it *is*
a regression. But the question is if it should block a stable release
or not.
Thanks,
Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1294 - Lyric ties
On Sat, Feb 12, 2011 at 1:04 PM, Graham Percival gra...@percival-music.ca wrote: We have two ways of making it not a Critical issue: 1) make the output the same. If that means fiddling with the release-2.14 branch of GUB, fine. If that means changing stuff in lilypond git, fine. If that means six weeks of making GUB master compile, the testing, then fixing bugs, then more testing, then more fixing bugs, then extra patches against ghostscript, then more testing, then finally merging GUB master to release-2.14 and then *not*. *touching*. *the*. *build*. *system*., then fine. 2) metaphorically look our users in the eye and tell them that we no longer support that feature. This means adding the following line to Documentation/changes.tely: @item Lyric ties are no longer supported. I'll give a LGTM to any such patch. Other developers -- particularly anybody who writes vocal music -- may disagree, and I'm not going to quibble to any such disagreement. But as far as releases go, that's the story. It wasn't my intent to be controversial with my assessment of the situation. Sorry. I'll work on the issue, and we'll fix this for 2.14. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1294 - Lyric ties
On Sat, Feb 12, 2011 at 9:51 AM, Phil Holmes m...@philholmes.net wrote: Now - there's one other interesting feature here. If I delete the fourth line of the lyrics above (the one with the explicit font) and run Lily 2.13.49, saving the PS file, it has the following in the postscript header: %%DocumentMedia: a4 595.28 841.89 80 () () %%DocumentSuppliedResources: font CenturySchL-Roma %%DocumentSuppliedResources: font Emmentaler-20 %%DocumentSuppliedResources: font MS-Gothic %%EndComments If I run the same file in 2.12.3 I get: %%DocumentMedia: a4 595.28 841.89 80 () () %%DocumentSuppliedResources: font CenturySchL-Roma %%DocumentSuppliedResources: font DejaVuSans %%DocumentSuppliedResources: font Emmentaler-20 %%DocumentSuppliedResources: font feta-alphabet20 %%EndComments I just pushed a fix for this in git. Only one file was affected (scm/font.scm). Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: further update to CSS files
On Fri, Feb 11, 2011 at 3:56 AM, Phil Holmes m...@philholmes.net wrote: Francisco Vila reported that postprocess-html.py also has references to CSS files. This patch corrects that file to use the new CSS filenames and get rid of the alternatives. It makes clean on my system. Could someone push it, please? Looks good, so I've pushed it. Thanks! Regards, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GUB] Github tracker issue
On Sat, Jan 29, 2011 at 8:45 AM, Carl Sorensen c_soren...@byu.edu wrote: On 1/29/11 6:20 AM, Graham Percival gra...@percival-music.ca wrote: On Fri, Jan 28, 2011 at 11:19:10PM -0800, Patrick McCarty wrote: I meant to post this to -devel a while ago, but I opened a Github tracker issue for GUB. https://github.com/janneke/gub/issues#issue/2 Interesting. How do I get a proper git format-patch version of this? The raw link gives me a plain diff. The download gives me a tarball, which contains a plain diff. Why does it seem like every code review tool out there strips out the commit message and author from git patches? :( I can vaguely excuse codereview, since it was intended for svn... but github?! Please tell me that my old eyes completely missed some get patch button somewhere. It appears to me that the desired work flow for this is for the submitter (Patrick in this case) to make a pull request, at which time the applier can do the pull and the patch will have the original author stuff. Yes, this is the typical work flow for Github. Once we figure out a proper patch to merge, we have the option of submitting a pull request. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[GUB] Github tracker issue
Hello, I meant to post this to -devel a while ago, but I opened a Github tracker issue for GUB. Here's the link: https://github.com/janneke/gub/issues#issue/2 Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lily dances
Hi Mike, On 2010-12-22, Mike Solomon wrote: Hey all, I am embarking on a new project to make lily dance. Attached are 3 files: 1) svgdance.svg (best viewed in something that's not Internet Explorer - click on the notes and/or accidentals and see what happens!) Very cool! 3) 0001-Implements-metadata-for-SVG-manipulation.patch (needs to be applied to the current master - then, recompile everything in lily and scm and install) Looks pretty straightforward. As you can see, it's not too difficult to sneak new data into the backends. :-) I think the applications of this are broader than making grobs dance. I am going to use it for a composition, but I think it can also be used for animated Schenker graphs, annotated scores, pedagogical sites, etc.. Sure, I think it definitely has further applications, even ones we can't imagine right now. As always with my side projects, I could use some help! If you are interested in this sorta thing and want to help make the code better, lemme know. Before I work on integrating this into the post-2.14 source, I'd like for several people to play with it and share their thoughts! Some random thoughts: I find your implementation of the 'metadata property value very interesting. :-) It's nice, but it doesn't feel very LilyPondy to me. Not sure how to improve it right now. What about SVG+SMIL? More browser makers are adding support for it... I think it would be nice to add prewritten JavaScript functions, or entire JavaScript libraries that users can pull in to use for animation, or other purposes. Of course, your set-svg-header could be used to write custom functions, but it would be easier to include functions (from the user's point of view) from separate JavaScript files. I tried to load svgdance.svg in Batik Squiggle, and an error was generated: file:/home/pnorcks/svgdance.svg: The attribute style represents an invalid CSS declaration (cursor:hand;). Original message: The hand identifier is not a valid value for the cursor property. --- Thanks for your work, and I'm looking forward to see how this progresses. Regards, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: accidental.ly regtest
On Tue, Dec 14, 2010 at 4:29 AM, Phil Holmes m...@philholmes.net wrote: David Kastrup d...@gnu.org wrote: Phil Holmes m...@philholmes.net writes: Well - because it's unusual. Far more common to have a sharp on a natural note in the key sig, or a natural on a flat, for example. And a regtest should not test unusual things? I still fail to see why. It's not actually testing the use of a natural-sharp in a flats key sig. It's testing the display of accidentals on the subsequent notes. My reason for suggesting changing it is that, if you've limited exposure to all forms of music, and you're looking at this test to see if it's working properly, then you may concentrate on the unusual aspect of the flat-to-sharp change, and miss an error elsewhere. I agree that this regtest may be confusing if you are trying to understand it based on the texinfo description. IMO it would be best, as others have mentioned, to clarify the regtest description. The notation of using a natural-sharp (or a natural-flat) is pretty standard. I'm thinking of Beethoven's Op. 26 (mvt. 3), where natural-flats are used to clarify that particular notes no longer have double-flats, and instead use a single flat. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issues to verify
On Tue, Dec 14, 2010 at 3:53 PM, Carl Sorensen c_soren...@byu.edu wrote: On 12/14/10 10:26 AM, Phil Holmes m...@philholmes.net wrote: There are currently 8 issues to verify that could and should have been verified. I've asked the bug squad to check them, and I've been over them myself and I don't have the skills to check them. Could any developer who can, please look at http://code.google.com/p/lilypond/issues/list?can=7 and verify any that they can? Given that we're close to a release candidate, we desperately need to clear this list. Issues 1249 and 1265 require somebody who can use the Guile V2 stuff. Patrick, I think this is you, isn't it? Since it's Ian's patch, can you verify it? Yes, I'll verify it after I check the state of my Guile 2 branch. I've asked Patrick for a regtest for 1407 so that somebody can validate that issue. I've added a comment to 1407 about the process for verification. If nobody wants to tackle it, I've just verified with 2.13.43 :) A proper regtest will have to wait until we add a new font to GUB. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
`make doc' fails
Hello,
I can't run `make doc' due to a compile failure on git master (as of
commit 75cdeeefba1e4762a29b5f418b8d6294a0eba18e).
The relevant snippet that fails is in fretted-strings.itely:
\version 2.13.42
\include predefined-ukulele-fretboards.ly
myChords = \chordmode { a1 a:m a:aug }
\new ChordNames {
\myChords
}
\new FretBoards {
\set stringTunings = #ukulele-tuning
\myChords
}
If I revert the latest commit (75cdeee), the compile failure is
resolved.
Valentin, do you have a fix for this?
Thanks,
Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `make doc' fails
On 2010-12-11, Patrick McCarty wrote:
I can't run `make doc' due to a compile failure on git master (as of
commit 75cdeeefba1e4762a29b5f418b8d6294a0eba18e).
Valentin, do you have a fix for this?
The patch below seems to work. Is this the correct fix?
diff --git a/ly/predefined-ukulele-fretboards.ly
b/ly/predefined-ukulele-fretboards.ly
index 827b04d..1dc5fa4 100644
--- a/ly/predefined-ukulele-fretboards.ly
+++ b/ly/predefined-ukulele-fretboards.ly
@@ -22,8 +22,7 @@
kiwi ukulele website (http://www.kiwiukulele.co.nz/)
% chord definitions require default pitchnames
-#(define prev-pitchnames pitchnames)
-#(set! pitchnames default-language)
+\languageSaveAndChange #default-language
%%% a chords
@@ -807,4 +806,4 @@
#ukulele-tuning
#1-1;o;2-3;1-2;
-#(set! pitchnames prev-pitchnames)
+\languageRestore
Thanks,
Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `make doc' fails
On 2010-12-12, Valentin Villenave wrote: On Sat, Dec 11, 2010 at 11:17 PM, Patrick McCarty pnor...@gmail.com wrote: The patch below seems to work. Is this the correct fix? Of course! Please push asap. Okay, pushed. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: @var in program's msgid/msgstr
On Thu, Dec 9, 2010 at 1:50 AM, Francisco Vila paconet@gmail.com wrote:
Hello. I am translating the program gettext file. What's the point of
emphasizing words with @var{} in msgid's? Is the output
(warning/errors etc) of the program to be processed by texinfo?
I think the intent is to *eventually* generate a list of
publicly-available functions for the Internals Reference, and some of
these functions use @var{} in their docstrings to indicate function
parameter names. There are inconsistencies here, in that some
docstrings are internationalized and some are not, and some public
functions don't have docstrings at all.
Also, note that many of these functions are LilyPond music functions
defined in .ly files, and the PO template generation does not notice
these docstrings. Perhaps this is a point we can address during GOP?
For example, in ly/music-functions-init.ly, you see
applyContext =
#(define-music-function (parser location proc) (procedure?)
(_i Modify context properties with Scheme procedure @var{proc}.)
but this string is not found in lilypond.pot.
I hope this clarifies things a bit for you.
Thanks,
Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Need help with lilypond-2.12.3 documentation build failure
On Fri, Dec 10, 2010 at 6:40 AM, Graham Percival gra...@percival-music.ca wrote: On Fri, Dec 10, 2010 at 04:19:59PM +0200, Dave Plater wrote: I'll try the texlive-bin maintainer. Is this going to be a problem with 2.13.42 do you think? I expect it would still be a problem. Or rather, if 2.13.42 works when 2.12.3 doesn't, then it would be an accident rather than on purpose. I can't remember fixing any bug related to this when I made bib2texi, but it's just possible that the general refactoring allowed us to avoid this specific problem. Perhaps this is related? http://lists.gnu.org/archive/html/lilypond-devel/2010-01/msg00524.html The fix is here in master: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=da009bcd6532ed1564440ddff73a1a92019d5420 Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: paper-defaults-init.ly questions
On Wed, Dec 1, 2010 at 5:02 PM, Mark Polesky markpole...@yahoo.com wrote: I found these in paper-defaults-init.ly: #(define make-header (...)) #(define make-footer (...)) #(define font-defaults '((...))) #(define text-font-defaults `((...))) 1) Do we need the quasiquote ` for text-font-defaults? Wouldn't a regular quote ' be fine? A regular quote is fine in this case. If there was an `unquote' or `unquote-splicing' in the quoted list, then the quasiquote would be required. 2) Are these \paper variables like the others or is that a misconception? Is there value in declaring them like the rest of the \paper variables? Like so: make-header = #(...) make-footer = #(...) font-defaults = #'((...)) text-font-defaults = #'((...)) I think this style looks more appealing, but I can't tell if this change would have any effect. I can run a regression-test check if you send a patch... Should they be listed alongside the other \paper variables in NR 4.1? Might as well, just as long as you can document them ;) 3) I'd like to change this... mm = 1.0 in = 25.4 pt = #(/ in 72.27) cm = #(* 10 mm) ...to this... mm = #1.0 cm = #(* 10 mm) in = #(* 25.4 mm) pt = #(/ in 72.27) Would that be better? I was considering this about a year ago, but then I discovered the parallel definitions (mm, in, etc.) in ly/declarations-init.ly. It's confusing to me why the variables are declared in two different places, and in two different ways. 4) These numbers should have a # in front of them, right? blank-after-score-page-force = 2 blank-last-page-force = 0 blank-page-force = 5 Yes, I believe so. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14 release, or GOP now (part 2)
On Sun, Nov 28, 2010 at 11:33 PM, Graham Percival gra...@percival-music.ca wrote: 2) release 2.14 ASAP with no critical flaws, but with some kind of code freeze. Many software projects implement a freeze before a release -- when the project is frozen, this means that no changes are allowed, unless they have a very good reason why they absolutely must be changed before the next release. With git, there's no technical reason why we might want to freeze anything (I could just branch a stable/2.14, and just cherry-pick individual commits to apply to this branch). However, there are social reasons for a freeze. We (implicitly) have a freeze on policy decisions, to avoid spending time on those instead of release-critical work. We could add a freeze on patches and code, to avoid spending time on those instead of release-critical work. I like the idea of branching master to stable/2.14 and cherry-picking fixes for critical issues (and compile/build fixes for Guile 1.9, etc). Merging translations work from lilypond/translation to stable/2.14 would be just as easy. This would allow work in master to proceed uninterrupted. I also think it would be useful to have two code freezes on stable/2.14: one for code/docs, and one for translations (right before the release). Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14 release, or GOP now (part 2)
On Mon, Nov 29, 2010 at 9:29 AM, Valentin Villenave valen...@villenave.net wrote: On Mon, Nov 29, 2010 at 6:22 PM, Patrick McCarty pnor...@gmail.com wrote: I also think it would be useful to have two code freezes on stable/2.14: one for code/docs, and one for translations (right before the release). (Of course it depends on how much new work is done after stable/2.14 is branched off, but) don't you think translators would be better off keeping in sync with the *stable* branch until the release? This way we might have a chance that most languages are in the same state when the release happens. Yeah, this situation is tricky. One idea would be to branch stable/2.14 *only* after the (English) documentation is in a state good enough for 2.14 (a topic for another thread), and then we branch stable/2.14, and translation work commences for documentation on stable/2.14. I think that would work... :) Once stable is released, then lilypond/translations can be rebased onto master, until the next branching stage. Would probably be easier to merge it, since most (if not all) translation work, before the 2.14 release, would be based off stable/2.14. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: questioning doc policy for @item
On Sat, Nov 20, 2010 at 10:56 AM, Mark Polesky markpole...@yahoo.com wrote: Trevor Daniels wrote: ...I'd prefer a blank line before and after every @item including the first one... +1 But only because I'm too lazy to fix the paragraph formatting command in Vim (gqap), which turns this: @item line 1 here could join line 2 here into this: @item line 1 here could join line 2 here instead of this: @item line 1 here could join line 2 here For this situation, I would arrow down to the second line and type `J' to join the lines. Or, if there is more than one line to join, and I have a specific `textwidth' setting, I would do a linewise highlight (with `V j j j' etc.) and type `gqap'. If the paragraphs are very large, I would search (in linewise visual mode) for the next @item or @end, and then move up a couple of lines. Anyone already have a solution? The closest I find is this: http://www.vim.org/scripts/script.php?script_id=2187 Sure, it would be nice to have an automated solution like this for Texinfo, but using the commands above are quick and work just fine for me. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Universe of syntax possibilities, ONLY to skip over non-notes/chords
On Sat, Nov 13, 2010 at 8:17 AM, David Santamauro david.santama...@gmail.com wrote: On Sat, 13 Nov 2010 07:32:06 -0700 Carl Sorensen c_soren...@byu.edu wrote: The second state is in the form of scheme music expressions. The job of the parser is to convert lilypond music expressions into scheme music expressions. Most user-defined music functions are evaluated This, I assume, is what is output with -dbackend=scm, correct? The output from -dbackend=scm contains the final *stencil* expression for a page of music (and all succeeding pages, if they exist). This final stencil expression is evaluated at a later stage than when music functions and scheme music expressions are evaluated, so I don't think you'll find its output very useful in this case... -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: T1249 - Remove (define define-ly-syntax define-public). (issue2313044)
On Wed, Nov 10, 2010 at 12:11 PM, Ian Hulin ianhuli...@gmail.com wrote: Patch with amended title attached. Thanks Ian. I've pushed your patch to git master. Regards, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Renaming the 'space alist-key
On Sun, Nov 7, 2010 at 7:30 AM, Mark Polesky markpole...@yahoo.com wrote: All right, hopefully everyone here won't mind one last vote, so please state your preference among the following: SPACE MINIMUM-DISTANCE -- -- 1) basic-distance minimum-distance 2) initial-distance minimum-distance 3) basic-separation minimum-separation 4) initial-separation minimum-separation Here's my vote: Alexander: Carl: David: Joe: Mark: 1 Patrick: 2 Trevor: Valentin: 2 Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond 2.13.38
On Sun, Oct 31, 2010 at 7:55 AM, Graham Percival gra...@percival-music.ca wrote: Bug squad: Phil is busy with the opening of a musical, so it would be nice if somebody else could check the regression test comparisons for both 2.13.37 and 2.13.38. It would be a shame if some horrible bug was introduced in the past two weeks and nobody noticed. For the record, I just checked the comparisons, and everything looks fine between 2.13.37 and 2.13.38. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: SVG Point Click
On Fri, Oct 29, 2010 at 5:32 AM, Christoph s...@smurky.de wrote: Is there a way to have point-click-behavoir or any semantic meta-information about the correspondending postion in the .ly-file in SVGs that a generated with the SVG-Backend (like in PDFs?). Not currently, but it should be possible to add some metadata about line/column position by implementing a grob-cause procedure in the SVG backend. I am interested in working on this eventually, but I can't say when. So I will add it to the tracker for now: http://code.google.com/p/lilypond/issues/detail?id=1372 Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] display-lily.scm question
Hi Ian, On Wed, Oct 27, 2010 at 2:31 PM, Ian Hulin i...@hulin.org.uk wrote: I've just done some stuff with this file to ensure it compiles OK when running using Guile V1.9. It declares all it stuff in a module (define-module (scm dislplay-lily) It currently gets loaded by lily.scm as part of the dynamic load list near the end of the file. However, things declared as modules for use in the base 'lily' module are pulled in via a (use-modules) statement near the start of the file. Should display-lily.scm move from the ly:load list to the (use-modules) list? I'm a bit confused by this question... As I understand it, module (scm display-lily) is loaded via (use-modules ...) in music-functions.scm, on line 216. So, when the Guile 1.9 scheme compiler compiles music-functions.scm, it compiles display-lily.scm automatically at that point. Then, at the bottom of display-lily.scm, define-music-display-methods.scm is loaded. Is this the spot you are asking about? Thanks, Patrick PS. I can't review your latest curried-definitions patch until this weekend, at the earliest. Sorry about that. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14 release, or GOP now?
On Sat, Oct 23, 2010 at 8:22 PM, Graham Percival gra...@percival-music.ca wrote: We're about 10-20 hours of work away from having 0 Critical issues. On one hand, that sounds great; we're almost there! On the other hand, we've been in this state for the past month. I'm not seeing a lot of excitement and work towards 2.14. IMO, we should try to release 2.14 before starting GOP, primarily because there hasn't been a stable release in 9 months; we're not currently making any more 2.12 bug/build-fix releases, and I think most users that have tried the latest 2.13 releases would agree that it's close to stable. Regarding critical issues, the only one that is within grasping distance (for me) is #1336, but I don't have any strong leads yet. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Segfault with define-music-function
On Fri, Oct 22, 2010 at 6:06 AM, Valentin Villenave valen...@villenave.net wrote: On Fri, Oct 22, 2010 at 3:02 PM, Carl Sorensen c_soren...@byu.edu wrote: As near as I can tell, this code is triggering an infinite loop that fails when the scheme heap overflows. Interesting. arg is *not* a stream-event, it's a music-event. Indeed. But I wasn't expecting it to cause a segfault. Segfaults are supposed to always be critical errors, but I think that in the case of incorrect Scheme code, we shouldn't label it as a LilyPond error. I agree. That's why I didn't open a tracker page. The segfault occurs in LilyPond code though, so we should exit gracefully. Reported as #1355: http://code.google.com/p/lilypond/issues/detail?id=1355 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 Tue, Oct 19, 2010 at 8:02 AM, John Mandereau john.mander...@gmail.com wrote: Il giorno lun, 18/10/2010 alle 09.20 -0700, Patrick McCarty ha scritto: On Mon, Oct 18, 2010 at 9:17 AM, John Mandereau john.mander...@gmail.com wrote: 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... If you think it's worth adding these suggestions to the CG, given that ArchLinux users and packagers may be expected to read compilation instructions, I'll do it. Sure, if you would like to, go for it. Thanks, 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)
On Tue, Oct 19, 2010 at 11:31 AM, Ian Hulin ianhuli...@gmail.com wrote: Hi Patrick, Patch is attached. Thanks, I've pushed it. Regards, Patrick ___ 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: 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
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
Distributions upgrading to Python 3
Hello, 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. The distribution-wide policy is as follows: Any applications that still need Python 2 will depend on the python2 package, which provides a python2 symlink to the currently installed Python 2 executable (in this case, soon to be python2.7). I know that LilyPond proper is not going to migrate yet, understandably, so I will soon need to use the python2 package. There are two issues I am running into: --) 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? --) Some scripts use /usr/bin/env python, which IIRC, is the best solution for Mac OS X users. However, I would need /usr/bin/env python2 instead for these scripts to work. The rest of the scripts use either @PYTHON@ or @TARGET_PYTHON@, which are substituted early in the make process. This is just a matter of detecting the appropriate Python at the configure stage. 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? Any thoughts about this? 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 8:30 PM, Benjamin Peterson benja...@python.org wrote: Patrick McCarty pnorcks at gmail.com writes: Arch Linux will be migrating to Python 3 very soon, What does this mean? $ python will give Python 3? Yes. If so, that's no good. python3 is supposed to be the name of the Python 3 executable for time in memoriam. 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 -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Compile failure with commit edd89894
Hi Graham,
With GCC 4.5.1, I'm seeing a compile failure with latest git.
Reverting your commit edd89894 fixes it. Here's the error:
context-def.cc: In static member function 'static scm_unused_struct*
Context_def::mark_smob(scm_unused_struct*)':
context-def.cc:118:1: error: expected 'while' before 'Context_def'
context-def.cc:118:1: error: expected '(' before 'Context_def'
context-def.cc:118:35: error: expected primary-expression before 'mod'
context-def.cc:119:1: error: expected ')' before '{' token
context-def.cc:119:1: error: expected ';' before '{' token
context-def.cc:120:22: error: 'mod' was not declared in this scope
./include/context-def.hh:44:7: error: invalid use of member
'Context_def::description_' in static member function
context-def.cc:123:7: error: from this location
context-def.cc:124:7: error: return-statement with no value, in function
returning 'scm_unused_struct*'
./include/context-def.hh:48:7: error: invalid use of member
'Context_def::default_child_' in static member function
context-def.cc:135:5: error: from this location
./include/context-def.hh:41:7: error: invalid use of member
'Context_def::translator_mods_' in static member function
context-def.cc:139:7: error: from this location
./include/context-def.hh:41:7: error: invalid use of member
'Context_def::translator_mods_' in static member function
context-def.cc:139:59: error: from this location
./include/context-def.hh:42:7: error: invalid use of member
'Context_def::accept_mods_' in static member function
context-def.cc:143:5: error: from this location
./include/context-def.hh:42:7: error: invalid use of member
'Context_def::accept_mods_' in static member function
context-def.cc:143:53: error: from this location
./include/context-def.hh:43:7: error: invalid use of member
'Context_def::property_ops_' in static member function
context-def.cc:148:5: error: from this location
./include/context-def.hh:43:7: error: invalid use of member
'Context_def::property_ops_' in static member function
context-def.cc:148:36: error: from this location
./include/context-def.hh:46:7: error: invalid use of member
'Context_def::context_aliases_' in static member function
context-def.cc:150:5: error: from this location
./include/context-def.hh:46:7: error: invalid use of member
'Context_def::context_aliases_' in static member function
context-def.cc:150:39: error: from this location
./include/context-def.hh:47:7: error: invalid use of member
'Context_def::translator_group_type_' in static member function
context-def.cc:152:5: error: from this location
./include/context-def.hh:45:7: error: invalid use of member
'Context_def::context_name_' in static member function
context-def.cc:154:5: error: from this location
context-def.cc:161:1: error: a function-definition is not allowed here before
'{' token
context-def.cc:349:1: error: expected '}' at end of input
make[1]: *** [out/context-def.o] Error 1
make[1]: Leaving directory `/home/pnorcks/git/lilypond/lily'
make: *** [all] Error 2
-Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Compile failure with commit edd89894
On Mon, Oct 11, 2010 at 6:54 PM, Graham Percival
gra...@percival-music.ca wrote:
On Tue, Oct 12, 2010 at 2:30 AM, Patrick McCarty pnor...@gmail.com wrote:
With GCC 4.5.1, I'm seeing a compile failure with latest git.
Reverting your commit edd89894 fixes it. Here's the error:
context-def.cc: In static member function 'static scm_unused_struct*
Context_def::mark_smob(scm_unused_struct*)':
context-def.cc:118:1: error: expected 'while' before 'Context_def'
???
There's definitely a while in the macro defintion. Unless gcc 4.5
doesn't honour \ symbols in macro definitions?
Or might it be unhappy with the
do { }
part? (should it be do { ; } ?)
If nothing spots anything before tomorrow, I'll compile gcc 4.5 and
see what I can do.
Sorry for the noise. I just figured it out and pushed a fix.
Thanks,
Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: T1249 - Remove (define define-ly-syntax define-public). (issue2313044)
On Sat, Oct 9, 2010 at 10:27 AM, pnor...@gmail.com wrote: I just tested this change with Guile 1.9, and everything checked out, though I didn't test Guile 1.8. I did a build from scratch and eliminated the cache from ~/.cache/guile just to be sure. Can you verify? I'm testing with the commit at the top of http://repo.or.cz/w/lilypond/patrick.git/shortlog/refs/heads/guile I just retested and saw the compile failure that you were likely seeing. Uploaded a new Take 3 commit. Can you test it? http://repo.or.cz/w/lilypond/patrick.git/shortlog/refs/heads/guile Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Question about 'odd' messages when running git pull -r
On Thu, Oct 7, 2010 at 7:29 AM, James james.l...@datacore.com wrote: Hello, Occasionally when i run 'git pull -r' in a terminal I get the following jl...@jlowenetbuntu:~/lilypond-git$ git pull -r usage: git merge-base [-a|--all] commit commit... -a, --all outputs all common ancestors usage: git merge-base [-a|--all] commit commit... -a, --all outputs all common ancestors [...] I just wondered why I am getting these 'usage' prompts. I even did a clean install of the whole repository a few days ago to see if this was just 'one of those things' but it seems that it comes and goes. It's not a big deal but I wondered if anyone had had the same issues? I've never seen these usage prompts before. It's probably just a harmless issue with your version of Git. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to start a fork at repo.or.cz?
On 2010-09-12, Mark Polesky wrote: So, I'm trying to start a fork at http://repo.or.cz/w/lilypond/mpolesky.git, but I get: $ git push --dry-run ow...@repo.or.cz's password: [3 attempts here, then...] Permission denied (publickey,password). fatal: The remote end hung up unexpectedly I have... 1. registered my public key at http://repo.or.cz/reguser.cgi I remember having trouble registering my public key at this site before, but I think the last time I registered one, it was fixed... 3. added these lines to .git/config: [remote mpolesky] url = ssh://repo.or.cz/srv/git/lilypond/mpolesky.git For my fork, I have url = git+ssh://repo.or.cz/srv/git/lilypond/patrick.git so you might need the git+ part. fetch = +refs/heads/*:refs/remotes/mpolesky/* I can't remember the details about this, because my fork is set to mirror mode and I never pull or fetch from my repo. FWIW, here are the lines from my .git/config : [remote cz] url = git+ssh://repo.or.cz/srv/git/lilypond/patrick.git mirror = true Then when I want to back up my local branches, I just run $ git push cz 4. $ git checkout pictograms $ git push --dry-run And that's where I get the above password request. I'm assuming I'm missing something obvious, like doing an initial clone, which I've not done, because I don't know how! I don't think you can clone a repo.or.cz repository until you've actually pushed a branch. Hope this helps, -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.12.3 source tarball changed (back in january)
Hi, On Mon, Aug 30, 2010 at 11:53 AM, Matthias Kilian k...@outback.escape.de wrote: a fellow openbsd developer noticed that the 2.12.3 source tarball (http://download.linuxaudio.org/lilypond/sources/v2.12/lilypond-2.12.3.tar.gz) differs from the same version from late december (december, 20th, I think). Please avoid such changes in the future, they make the live of port/packages maintainers very hard, because checksums are changing, mirrors of the source tarballs have to be noticed etc. We released 2.12.3-1 on 15 Dec 2009 and 2.12.3-2 on 12 Jan 2010, so this would account for the checksum change. We could potentially avoid this issue by appending build numbers to the source tarballs. What do you think? Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bad typo fix :(
On Thu, Aug 19, 2010 at 10:10 PM, Graham Percival gra...@percival-music.ca wrote: Hi Patrick, I disagree most vehemently with your fix in af68a98e6c142e3479498b49ae924919efa94c77 Yes, it wasn't really a typo fix, but the word experimented doesn't really make sense to me in this context. What would you suggest? Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bad typo fix :(
On Thu, Aug 19, 2010 at 10:17 PM, Patrick McCarty pnor...@gmail.com wrote: On Thu, Aug 19, 2010 at 10:10 PM, Graham Percival gra...@percival-music.ca wrote: Hi Patrick, I disagree most vehemently with your fix in af68a98e6c142e3479498b49ae924919efa94c77 Yes, it wasn't really a typo fix, but the word experimented doesn't really make sense to me in this context. What would you suggest? How about other translators ? -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with 2.13.30?
On Sat, Aug 14, 2010 at 5:23 PM, Patrick McCarty pnor...@gmail.com wrote: On Sat, Aug 14, 2010 at 4:10 PM, Trevor Daniels t.dani...@treda.co.uk wrote: The mingw binary of 2.13.30 gives the following error under Vista on my system: Running lilypond-book Traceback (most recent call last): File c:/program files/lilypond/usr/bin/lilypond-book.py, line 86, in ? import book_base as BookBase File out/book_base.py, line 4, in ? File out/book_snippets.py, line 9, in ? File c:\Program Files\LilyPond\usr\lib\python2.4\subprocess.py, line 352, in ? import msvcrt ImportError: No module named msvcrt Lilypond-book returned code 1 Could someone else please try this to see if this is a problem with the release or my system. I can reproduce the problem with Wine, running the following: $ wine python.exe lilypond-book.py I've never tried this before, so I don't know whether or not this worked with 2.11.29 or earlier. One further note: This could be related to Jan's recent changes to the MinGW Python build in GUB. Something related to msvcrt was added here: http://github.com/janneke/gub/commit/e3d46689d881045ceb2dbf31d7d4573709f781d8#L1R136 Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with 2.13.30?
On Sat, Aug 14, 2010 at 4:10 PM, Trevor Daniels t.dani...@treda.co.uk wrote: The mingw binary of 2.13.30 gives the following error under Vista on my system: Running lilypond-book Traceback (most recent call last): File c:/program files/lilypond/usr/bin/lilypond-book.py, line 86, in ? import book_base as BookBase File out/book_base.py, line 4, in ? File out/book_snippets.py, line 9, in ? File c:\Program Files\LilyPond\usr\lib\python2.4\subprocess.py, line 352, in ? import msvcrt ImportError: No module named msvcrt Lilypond-book returned code 1 Could someone else please try this to see if this is a problem with the release or my system. I can reproduce the problem with Wine, running the following: $ wine python.exe lilypond-book.py I've never tried this before, so I don't know whether or not this worked with 2.11.29 or earlier. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Alternate css files
On 2010-08-11, Graham Percival wrote: On Wed, Aug 11, 2010 at 08:32:24AM +0100, Trevor Daniels wrote: Is there any requirement to continue with the alternate css files in the web? These were set up, IIRC, to enable people to view and comment on alternative designs, but we seem to have settled the design now. As far as I'm concerned, they can be deleted. Maybe give them a quick glance to see if there's anything potentially interesting in them, but I'm happy to trust anybody if they say that they did that and didn't see anything neat. From what I remember, the alternate *web* stylesheets were completely experimental; we had a lot of back-and-forth design changes and we kept some of the experimental changes in the alternate ones. Also, the alternate web stylesheets no longer work as expected, so unless something can be salvaged from them, they should be removed. The alternate docs stylesheets (lilypond-blue.css, lilypond.css), on the other hand, are legitimate stylesheets, so their respective authors (Kurt and Andrew) should have the final say about whether we keep them or not. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Which css file should the new web be using?
On Wed, Aug 4, 2010 at 4:45 AM, Trevor Daniels t.dani...@treda.co.uk wrote: While looking into the @help in download.itexi (the font size used for smallexample) I noticed that the css file currently being used to build the web is css/lilypond-web.css. Is this correct? The css title is Patrick McCarty's design and there is a beautifully-laid out css file called css/lilypond-mccarty.css, but this seems not to be used. The file lilypond-mccarty.css is used for the docs (everything except the website), and lilypond-web.css is used for the website. There is quite a bit of overlap between the two CSS files, and as Graham mentioned, combining them into one CSS file would be an ideal solution. Patrick's file has entries for smallexample but lilypond-web does not. We did do some copy-and-paste between CSS files about a year ago, IIRC, so smallexample must have been overlooked. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: T1055: Avoid using deprecated %module-public-interface in guile initialisation. (issue1160044)
On Sun, Aug 1, 2010 at 1:03 PM, pnor...@gmail.com wrote: On 2010/07/29 19:24:46, Neil Puttock wrote: + = scm_list_3 (ly_symbol2scm (module-use!), mod, used); This effectively exports all bindings, so all local defines are now exported. In the case of `profile-property-access.ly', the format call ends up using `ergonomic-simple-format' from lily.scm. Thanks for this observation, Neil. The reason why I suggested this change is to prevent a compile failure with Guile 1.9. The backtrace is below. Perhaps there is a bug in the `module-public-interface' procedure? Not really sure how to test if this is the case though... I think I found the problem. With Guile 1.9, `module-public-interface' doesn't return an interface for `the-scm-module', which we rely on: scheme@(guile-user) (module-public-interface the-scm-module) $1 = #f scheme@(guile-user) I'll report this upstream. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: T1055: Avoid using deprecated %module-public-interface in guile initialisation. (issue1160044)
On Sun, Aug 1, 2010 at 2:02 PM, Neil Puttock n.putt...@gmail.com wrote: On 1 August 2010 21:49, Patrick McCarty pnor...@gmail.com wrote: I think I found the problem. With Guile 1.9, `module-public-interface' doesn't return an interface for `the-scm-module', which we rely on: scheme@(guile-user) (module-public-interface the-scm-module) $1 = #f scheme@(guile-user) I'll report this upstream. OK. I was just about to reply, since I've seen that error using 1.8 (trying to use `resolve-interface' instead of module-public-interface). This is quite interesting. :) I just did a little more research, and these three calls all return the same interface, but the last one doesn't work with Guile 1.9: guile (resolve-interface '(guile)) #interface (guile) 7f3f91117840 guile (module-public-interface the-root-module) #interface (guile) 7f3f91117840 guile (module-public-interface the-scm-module) #interface (guile) 7f3f91117840 guile So, it looks like we might want to do this: - SCM scm_module = ly_lily_module_constant (the-scm-module); + SCM scm_module = ly_lily_module_constant (the-root-module); Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: vim filetype off
On Tue, Jul 27, 2010 at 10:49 AM, Graham Percival gra...@percival-music.ca wrote: Why on earth do we have a filetype off set runtimepath filetype on in the suggested .vimrc ? Those lines should be unnecessary. I need those lines to work around behavior that (I think) changed in very recent Vim versions. Basically, if I remove the filetype lines, the set runtimepath occurs too late in the filetype detection sequence to have any effect. By turning off filetype detection, modifying the runtimepath, and re-enabling filetype detection, the new runtimepath will be recognized. For background, see this thread: http://groups.google.com/group/vim_use/browse_thread/thread/c896684d209503e Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: vim filetype off
On 2010-07-27, Graham Percival wrote: On Tue, Jul 27, 2010 at 11:15:36AM -0700, Patrick McCarty wrote: On Tue, Jul 27, 2010 at 10:49 AM, Graham Percival gra...@percival-music.ca wrote: Why on earth do we have a filetype off set runtimepath filetype on in the suggested .vimrc ? Those lines should be unnecessary. Basically, if I remove the filetype lines, the set runtimepath occurs too late in the filetype detection sequence to have any effect. By turning off filetype detection, modifying the runtimepath, and re-enabling filetype detection, the new runtimepath will be recognized. Hmm. I'd prefer doing set runtimepath+= syntax on since that's IMO more understandable. According to that thread, it will have the same effect. That doesn't work for me, unfortunately. Sourcing $VIMRUNTIME/vimrc_example.vim executes syntax on filetype plugin indent on which means that the runtimepath has already been searched before any commands in ~/.vimrc are executed. Looking into this a bit more, I found another incantation that works: set runtimepath+=/path/to/lilypond/current/vim runtime! ftdetect/lilypond.vim Would you prefer this over the filetype off/on version? Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: vim instructions change
On Mon, Jul 26, 2010 at 4:50 PM, Graham Percival
gra...@percival-music.ca wrote:
On Sun, Jul 25, 2010 at 12:43:40PM -0700, Patrick McCarty wrote:
IMO, that method is more reliable, and I don't have to worry about
modifying a ~/.vim/filetype.vim for LilyPond.
Dudes! This is way simpler than we thought.
The docs should be:
--
@node Vim mode
For VIM, a ‘vimrc’ is supplied, along with syntax coloring tools.
A Vim mode for entering music and running LilyPond is contained in
the source archive in $VIM directory. To use our vim mode, create
(or modify) your $HOME/.vimrc to contain:
@example
set runtimepath+=/usr/local/share/lilypond/current/vim/
@end example
@noindent
If LilyPond was not installed in /usr/local, change the path
appropriately as discussed in
@rlearning{that node that has the lilypond install dir info}.
--
That's it. Fin, or Fine.
(I missed out some texinfo formatting, so fix that)
I fix it shortly.
Thanks,
Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: vim instructions change
On Mon, Jul 26, 2010 at 4:58 PM, Patrick McCarty pnor...@gmail.com wrote:
On Mon, Jul 26, 2010 at 4:50 PM, Graham Percival
gra...@percival-music.ca wrote:
On Sun, Jul 25, 2010 at 12:43:40PM -0700, Patrick McCarty wrote:
IMO, that method is more reliable, and I don't have to worry about
modifying a ~/.vim/filetype.vim for LilyPond.
Dudes! This is way simpler than we thought.
The docs should be:
--
@node Vim mode
For VIM, a ‘vimrc’ is supplied, along with syntax coloring tools.
A Vim mode for entering music and running LilyPond is contained in
the source archive in $VIM directory. To use our vim mode, create
(or modify) your $HOME/.vimrc to contain:
@example
set runtimepath+=/usr/local/share/lilypond/current/vim/
@end example
@noindent
If LilyPond was not installed in /usr/local, change the path
appropriately as discussed in
@rlearning{that node that has the lilypond install dir info}.
--
That's it. Fin, or Fine.
(I missed out some texinfo formatting, so fix that)
I fix it shortly.
Oops... :) Bad grammar.
-Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: vim instructions change
On Mon, Jul 26, 2010 at 4:50 PM, Graham Percival
gra...@percival-music.ca wrote:
On Sun, Jul 25, 2010 at 12:43:40PM -0700, Patrick McCarty wrote:
IMO, that method is more reliable, and I don't have to worry about
modifying a ~/.vim/filetype.vim for LilyPond.
Dudes! This is way simpler than we thought.
The docs should be:
--
@node Vim mode
For VIM, a ‘vimrc’ is supplied, along with syntax coloring tools.
A Vim mode for entering music and running LilyPond is contained in
the source archive in $VIM directory. To use our vim mode, create
(or modify) your $HOME/.vimrc to contain:
@example
set runtimepath+=/usr/local/share/lilypond/current/vim/
@end example
@noindent
If LilyPond was not installed in /usr/local, change the path
appropriately as discussed in
@rlearning{that node that has the lilypond install dir info}.
--
That's it. Fin, or Fine.
I've modified and pushed the new instructions, and I've thoroughly
tested it to make sure everything works correctly.
Thanks,
Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: vim instructions change
On Sun, Jul 25, 2010 at 11:45 AM, Graham Percival gra...@percival-music.ca wrote: I'm a bit suspicious about commit 4578dfbfdab5704ffc5317adfb252cb242f30115 1. AFAIK, we definitely want people creating or modifying ~/.vim/filetype.vim It's just possible that it might be on a different location on windows, but most people using vim on windows would probably be using cygwin, so that would still be ~/.vim/ If somebody's doing something else, they probably know enough to adjust the dir accordingly. They *definitely* should not be modifying anything inside /usr/share/vim/... 2. Unless somebody has manually created a ~/.vim/filetype.vim, they need to create a new file with the lines which were removed in the commit. FWIW, I don't have a ~/.vim/filetype.vim configuration at all. The current LilyPond source file vim/lilypond-ftdetect.vim overrides any filetype detection in filetype.vim, since it uses au! BufNewFile,BufRead *.ly,*.ily set ft=lilypond instead of au! BufNewFile,BufRead *.ly,*.ily setf lilypond IMO, that method is more reliable, and I don't have to worry about modifying a ~/.vim/filetype.vim for LilyPond. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: vim instructions change
Hi Colin,
On 2010-07-25, Colin Campbell wrote:
As I understand it, the supported filetype.vim and vimrc are only
found in the /vim directory of a source tree.
I wouldn't call either of files *supported*, since as far as I can
see, neither of them have ever been installed on a user's system.
3. create ~/.vim/filetype.vim if it doesn't exist, by copying from
{lilypond source}/vim/filetype.vim
I don't think this is necessary.
On my system, I have a copy of vim/lilypond-ftdetect.vim (from the
source tree) installed in ~/.vim/ftdetect/lilypond.vim , and the
LilyPond filetype for LY files is automatically detected, without
using a ~/.vim/filetype.vim.
Do you need a filetype.vim?
I'm running Vim 7.2, and it's possible that older versions of Vim might
actually need it, I don't know.
If that states the case accurately, I'll reword the section to suit.
The rest of your points look fine, IMO, but I'm not sure about the
filetype.vim parts.
Thanks,
Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Font metric unused variable
On Wed, Jul 21, 2010 at 4:51 AM, Mike Solomon mike...@ufl.edu wrote:
Hey all,
In compiling lilypond this morning, I saw this:
font-metric.cc:82: warning: unused parameter 'k'
Checking out the function in question, I saw this:
Box
Font_metric::get_indexed_char_dimensions (size_t k) const
{
return Box (Interval (0, 0), Interval (0, 0));
}
Not knowing what this function is supposed to do, I am not sure if this is a
problem, but if k is not necessary, perhaps:
Box
Font_metric::get_indexed_char_dimensions (size_t) const
{
return Box (Interval (0, 0), Interval (0, 0));
}
would be better?
Yeah, these type of warnings show up once in a while. Another one
appears when compiling pango-font.cc.
I'll fix them shortly.
Thanks,
Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Font metric unused variable
On Wed, Jul 21, 2010 at 11:43 AM, Patrick McCarty pnor...@gmail.com wrote:
On Wed, Jul 21, 2010 at 4:51 AM, Mike Solomon mike...@ufl.edu wrote:
Hey all,
In compiling lilypond this morning, I saw this:
font-metric.cc:82: warning: unused parameter 'k'
Checking out the function in question, I saw this:
Box
Font_metric::get_indexed_char_dimensions (size_t k) const
{
return Box (Interval (0, 0), Interval (0, 0));
}
Not knowing what this function is supposed to do, I am not sure if this is a
problem, but if k is not necessary, perhaps:
Box
Font_metric::get_indexed_char_dimensions (size_t) const
{
return Box (Interval (0, 0), Interval (0, 0));
}
would be better?
Yeah, these type of warnings show up once in a while. Another one
appears when compiling pango-font.cc.
I'll fix them shortly.
On second thought, I won't bother for now, since this patch (still to
be reviewed) fixes it:
http://codereview.appspot.com/1724041/show
Thanks,
Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypad for windows
Hi Jan, On Sun, Jul 18, 2010 at 1:56 AM, Jan Nieuwenhuizen janneke-l...@xs4all.nl wrote: While I appreciate your working on lilypad, I doubt whether this is an efficient way of spending our efforts. Yeah, I'm getting a little carried away. :) I'm starting to think it would be difficult expanding on the current LilyPad, since it really lacks features, and I'm starting to not enjoy working with the win32 API... Also, many people want to see syntax highlighting, etc., and the current solution isn't going to cut it. While it's interesting, I agree that working on a cross-platform editor would be a much wiser use of time. Why not write a simple editor in pygtk? Indeed, I wanted to write a simple editor to get you going and found gummi: http://gummi.midnightcoding.org/ Cool! I got it running on my Linux box, and it looks promising. It could be smart to work together with gummi, possibly there are better programs than gummi, possibly we're better off stealing their technology (poppler pdf display) and rolling our own. What do you think? I think if we roll our own LilyPad, and borrow a lot of ideas from gummi or other similar projects, we'll be on the right track. Thanks a lot for posting about this. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypad for windows
On Sun, Jul 18, 2010 at 6:20 AM, Carl Sorensen c_soren...@byu.edu wrote: On 7/18/10 2:56 AM, Jan Nieuwenhuizen janneke-l...@xs4all.nl wrote: It could be smart to work together with gummi, possibly there are better programs than gummi, possibly we're better off stealing their technology (poppler pdf display) and rolling our own. What do you think? One good thing about doing this is that we could have the application for both Windows and OSX. One bad thing about this is that it will add a new dependency (python-poppler). On the whole, if somebody wants to pursue this, I think it would be a good feature to add (but I guess it's not available for 2.14 because of dependency freezing). Well, I'm not sure if we would want to develop the editor in the same source tree as LilyPond... I think, at least for now, it would be best to work in a separate repo, add the editor to GUB eventually, and see where things go from there. So, in order words, if we keep it in a separate code base, we don't need to worry about the 2.14 dependency freeze. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypad for windows
On Sun, Jul 18, 2010 at 6:25 PM, Carl Sorensen c_soren...@byu.edu wrote: On 7/18/10 3:11 PM, Jan Nieuwenhuizen janneke-l...@xs4all.nl wrote: Op zondag 18-07-2010 om 13:35 uur [tijdzone -0700], schreef Patrick McCarty: I think if we roll our own LilyPad, and borrow a lot of ideas from gummi or other similar projects, we'll be on the right track. Yeah, probably maybe. I'm not too comfortable with this tex-ness, otoh, sharing efforts would be nice. I'm not trying to rain on anybody's parade, and I think I might know the answer, but ... Why do we want to roll our own when we already have LilyPondTool/Jedit, and Frescobaldi? I think the answers are 1) Jedit is not very lightweight, and we want something lightweight; and 2) Frescobaldi is specific to KDE and we want to develop something that is cross-platform. Yeah, the heaviness is the main problem. I think Frescobaldi is pretty lightweight, though it carries a massive dependency (KDE). Also, the JRE (or OpenJDK) for Jedit is pretty heavy. Is it possible to separate the KDE4 stuff from Frescobaldi, and use pygtk instead? Perhaps we could use the same core functionality. We could try porting some of the code to pygtk, though I haven't looked into it to see how difficult it would be. It seems better to not reinvent the wheel if we can avoid it. I agree. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] for GUB - NSIS: rework uninstall logic for LilyPad.
Hi,
Here is a patch for GUB that fixes an uninstallation issue for Windows
LilyPad:
http://code.google.com/p/lilypond/issues/detail?id=1179
Thanks,
Patrick
From 8cab842cd79ca0fcb9b1d26a361c19441feea057 Mon Sep 17 00:00:00 2001
From: Patrick McCarty pnor...@gmail.com
Date: Sun, 11 Jul 2010 14:01:44 -0700
Subject: [PATCH 2/2] NSIS: rework uninstall logic for LilyPad.
Before this commit, the NSIS installer created three versions of LilyPad
(lilypad.exe, lilypad-ascii.exe, and lilypad-unicode.exe), but we should
only need two of them.
If the underlying OS does not support Unicode, we only need
lilypad.exe
lilypad-unicode.exe
and if Unicode *is* supported, then we need
lilypad.exe
lilypad-ascii.exe
Then, the default LilyPad is always lilypad.exe, and we don't have the
extra, duplicated executable.
This commit implements the above logic, and adds lilypad-unicode.exe
to the list of installed files if necessary.
---
nsis/lilypond-prepost.nsh | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/nsis/lilypond-prepost.nsh b/nsis/lilypond-prepost.nsh
index 29451be..b7fa216 100644
--- a/nsis/lilypond-prepost.nsh
+++ b/nsis/lilypond-prepost.nsh
@@ -93,14 +93,22 @@ FunctionEnd
Function postinstall_lilypad
- StrCpy $0 $INSTDIR\usr\bin\lilypad
- CopyFiles /silent $0.exe $0-unicode.exe
ClearErrors
ReadRegStr $R0 HKLM \
SOFTWARE\Microsoft\Windows NT\CurrentVersion CurrentVersion
IfErrors dos exit
dos:
- CopyFiles /silent $0-ascii.exe $0.exe
+ # In this case, the underlying OS does not support Unicode,
+ # so the ASCII LilyPad should be the default.
+ StrCpy $0 $INSTDIR\usr\bin\lilypad
+ Rename $0.exe $0-unicode.exe
+ Rename $0-ascii.exe $0.exe
+ # Add lilypad-unicode.exe to files.txt to ensure complete uninstall.
+ SetFileAttributes $INSTDIR\${UninstLog} NORMAL
+ FileOpen $UninstLog $INSTDIR\${UninstLog} a
+ FileSeek $UninstLog 0 END
+ FileWrite $UninstLog \usr\bin\lilypad-unicode.exe$\r$\n
+ FileClose $UninstLog
exit:
FunctionEnd
--
1.7.1.1
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] for GUB - NSIS: Speed up uninstallers.
Hello,
The changes found in this patch make the GUB Windows uninstallers
*much* faster. Before, uninstalling LilyPond on Windows could take up
to 10 minutes, and these changes appear to have cut that time down to
about 20 seconds.
As the commit description notes, I incorporated the recent script
improvements from this wiki page:
http://nsis.sourceforge.net/Uninstall_only_installed_files
Let me know if there are any problems.
Thanks,
Patrick
From eadbbae85fa146c57e806b98a96653987c1635af Mon Sep 17 00:00:00 2001
From: Patrick McCarty pnor...@gmail.com
Date: Sat, 10 Jul 2010 20:44:02 -0700
Subject: [PATCH] NSIS: Speed up uninstallers.
Taken (and slightly adapted) from the latest revision of the code on
this page:
http://nsis.sourceforge.net/Uninstall_only_installed_files
---
nsis/denemo.nsi| 34 --
nsis/git.nsi | 34 --
nsis/installer.nsi | 34 --
nsis/lilypond.nsi | 34 --
4 files changed, 64 insertions(+), 72 deletions(-)
diff --git a/nsis/denemo.nsi b/nsis/denemo.nsi
index 2162409..30de321 100644
--- a/nsis/denemo.nsi
+++ b/nsis/denemo.nsi
@@ -128,31 +128,29 @@ Function un.install_installed_files
Push $R2
SetFileAttributes $INSTDIR\${UninstLog} NORMAL
FileOpen $UninstLog $INSTDIR\${UninstLog} r
- StrCpy $R1 0
+ StrCpy $R1 -1
GetLineCount:
ClearErrors
- FileRead $UninstLog $R0
- IntOp $R1 $R1 + 1
- IfErrors 0 GetLineCount
+ FileRead $UninstLog $R0
+ IntOp $R1 $R1 + 1
+ StrCpy $R0 $INSTDIR\$R0 -2
+ Push $R0
+ IfErrors 0 GetLineCount
+
+ Pop $R0
LoopRead:
- FileSeek $UninstLog 0 SET
- StrCpy $R2 0
- FindLine:
- FileRead $UninstLog $R0
- IntOp $R2 $R2 + 1
- StrCmp $R1 $R2 0 FindLine
-
- StrCpy $R0 $INSTDIR\$R0 -2
- IfFileExists $R0\*.* 0 +3
-RMDir $R0 #is dir
- Goto +3
- IfFileExists $R0 0 +2
-Delete $R0 #is file
+ StrCmp $R1 0 LoopDone
+ Pop $R0
+
+ IfFileExists $R0\*.* 0 +3
+ RMDir $R0 #is dir
+ Goto +3
+ IfFileExists $R0 0 +2
+ Delete $R0 #is file
IntOp $R1 $R1 - 1
- StrCmp $R1 0 LoopDone
Goto LoopRead
LoopDone:
FileClose $UninstLog
diff --git a/nsis/git.nsi b/nsis/git.nsi
index a0ea17e..82c32d0 100644
--- a/nsis/git.nsi
+++ b/nsis/git.nsi
@@ -115,31 +115,29 @@ Function un.install_installed_files
Push $R2
SetFileAttributes $INSTDIR\${UninstLog} NORMAL
FileOpen $UninstLog $INSTDIR\${UninstLog} r
- StrCpy $R1 0
+ StrCpy $R1 -1
GetLineCount:
ClearErrors
- FileRead $UninstLog $R0
- IntOp $R1 $R1 + 1
- IfErrors 0 GetLineCount
+ FileRead $UninstLog $R0
+ IntOp $R1 $R1 + 1
+ StrCpy $R0 $INSTDIR\$R0 -2
+ Push $R0
+ IfErrors 0 GetLineCount
+
+ Pop $R0
LoopRead:
- FileSeek $UninstLog 0 SET
- StrCpy $R2 0
- FindLine:
- FileRead $UninstLog $R0
- IntOp $R2 $R2 + 1
- StrCmp $R1 $R2 0 FindLine
-
- StrCpy $R0 $INSTDIR\$R0 -2
- IfFileExists $R0\*.* 0 +3
-RMDir $R0 #is dir
- Goto +3
- IfFileExists $R0 0 +2
-Delete $R0 #is file
+ StrCmp $R1 0 LoopDone
+ Pop $R0
+
+ IfFileExists $R0\*.* 0 +3
+ RMDir $R0 #is dir
+ Goto +3
+ IfFileExists $R0 0 +2
+ Delete $R0 #is file
IntOp $R1 $R1 - 1
- StrCmp $R1 0 LoopDone
Goto LoopRead
LoopDone:
FileClose $UninstLog
diff --git a/nsis/installer.nsi b/nsis/installer.nsi
index fb028f7..47f1d9c 100644
--- a/nsis/installer.nsi
+++ b/nsis/installer.nsi
@@ -113,31 +113,29 @@ Function un.install_installed_files
Push $R2
SetFileAttributes $INSTDIR\${UninstLog} NORMAL
FileOpen $UninstLog $INSTDIR\${UninstLog} r
- StrCpy $R1 0
+ StrCpy $R1 -1
GetLineCount:
ClearErrors
- FileRead $UninstLog $R0
- IntOp $R1 $R1 + 1
- IfErrors 0 GetLineCount
+ FileRead $UninstLog $R0
+ IntOp $R1 $R1 + 1
+ StrCpy $R0 $INSTDIR\$R0 -2
+ Push $R0
+ IfErrors 0 GetLineCount
+
+ Pop $R0
LoopRead:
- FileSeek $UninstLog 0 SET
- StrCpy $R2 0
- FindLine:
- FileRead $UninstLog $R0
- IntOp $R2 $R2 + 1
- StrCmp $R1 $R2 0 FindLine
-
- StrCpy $R0 $INSTDIR\$R0 -2
- IfFileExists $R0\*.* 0 +3
-RMDir $R0 #is dir
- Goto +3
- IfFileExists $R0 0 +2
-Delete $R0 #is file
+ StrCmp $R1 0 LoopDone
+ Pop $R0
+
+ IfFileExists $R0\*.* 0 +3
+ RMDir $R0 #is dir
+ Goto +3
+ IfFileExists $R0 0 +2
+ Delete $R0 #is file
IntOp $R1 $R1 - 1
- StrCmp $R1 0 LoopDone
Goto LoopRead
LoopDone:
FileClose $UninstLog
diff --git a/nsis/lilypond.nsi b/nsis/lilypond.nsi
index 8d3c3f8..07884f2 100644
--- a/nsis/lilypond.nsi
+++ b/nsis/lilypond.nsi
@@ -180,31 +180,29 @@ Function un.install_installed_files
Push $R2
SetFileAttributes $INSTDIR\${UninstLog} NORMAL
FileOpen $UninstLog $INSTDIR\${UninstLog} r
- StrCpy $R1 0
+ StrCpy $R1 -1
GetLineCount:
ClearErrors
- FileRead $UninstLog $R0
- IntOp $R1 $R1 + 1
- IfErrors 0 GetLineCount
+ FileRead $UninstLog $R0
+ IntOp $R1 $R1 + 1
+ StrCpy $R0 $INSTDIR\$R0 -2
+ Push $R0
+ IfErrors 0 GetLineCount
+
+ Pop $R0
LoopRead
Re: Changing conducting signs
On Wed, Jun 16, 2010 at 5:47 AM, Carl Sorensen c_soren...@byu.edu wrote: On 6/16/10 1:58 AM, flup2 phili...@philmassart.net wrote: I would like to know if somebody knows how conductng signs ( http://lsr.dsi.unimi.it/LSR/Item?id=259 http://lsr.dsi.unimi.it/LSR/Item?id=259 ) are created by Lilypond. In a lot of books (Kurt Stone for instance) I noticed that beats divided by 3 are noted by a full triangle, no a two-parts triangle like Lilypond does. Is this a bug in LilyPond? Does anybody ever want the incomplete triangle? The thing that is printed is *called* a triangle. It would be trivial for me to make it be a closed triangle. Good catch, Carl. It's a regression, and I've logged it here: http://code.google.com/p/lilypond/issues/detail?id=1153 Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Add \path markup command, and use it for \eyeglasses.
On Sun, Jun 20, 2010 at 5:34 AM, Werner LEMBERG w...@gnu.org wrote: From a syntactical point of view, I can't see an immediate benefit of saying #path:miter instead of #'miter Hm? Could you explain what constitutes a syntactical point of view in your book? I probably misformulated. I simply mean that the `path:' prefix is an additional burden to type, and it somewhat looks redundant to me. Thank you, Werner and David, for your suggestions. I have decided to use properties to override the cap, join, and fill parameters, and will be uploading a new patch set shortly. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Add \path markup command, and use it for \eyeglasses.
Hello, This is a feature I've wanted to add to LilyPond for a while, and I've posted a patch set on Rietveld: http://codereview.appspot.com/1730044/show Any comments are appreciated, especially regarding the syntactic requirements of the new command. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make check weirdness
On Thu, Jun 17, 2010 at 3:24 PM, Carl Sorensen c_soren...@byu.edu wrote: I'm trying to do regression test checking, but it doesn't seem to be working right. I did make test-baseline Then I switched to my new branch and did make make check I found some differences, so I patched the code, then did make test-redo make check After this, I got a comparison output that only listed tree.gittxt, with 762 below threshold, and 1459 unchanged. This doesn't seem right, because output-distance.ly should have changed. Any ideas as to what I'm doing wrong? I've never used `make test-redo' before, so I can't claim to know if it works correctly or not. Since I don't trust the build system to do the right thing, I use this canned command sequence to test new changes against an existing baseline: make find . -name 'out-test' | xargs rm -rf rm -rf ./out/lybook-testdb/ ./out/test-results/ make check Does that work for you? -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 100+ warnings and some cosmetics along the way (issue1724041)
On Fri, Jun 18, 2010 at 6:09 PM, Pap Lôrinc paplor...@yahoo.com wrote: HTH - Thanks Carl, but I've applied the imagemagick patch, did a long clean and make all, but the make check failed in the same place. Version: ImageMagick 6.5.7-8 2009-11-26 Q16 http://www.imagemagick.org Copyright: Copyright (C) 1999-2009 ImageMagick Studio LLC Features: OpenMP Is it too old? It's the latest ImageMagick for Ubuntu. Any ideas? Did you run make test-baseline in the beginning? Running `make test-baseline' is a prerequisite for checking the regression test output. See http://lilypond.org/doc/v2.13/Documentation/contributor/identifying-code-regressions -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Eyeglasses (was Re: -dbackend=svg ... warning: missing stencil expression `embedded-ps')
On Sun, Jun 6, 2010 at 6:43 AM, Carl Sorensen c_soren...@byu.edu wrote: So I'd like to propose that we have the task of changing \eyeglasses from make-postscript-markup to 'path be a Frog task. Any takers? I'll take care of it. I've added new issues to keep track of my progress: http://code.google.com/p/lilypond/issues/detail?id=1124 http://code.google.com/p/lilypond/issues/detail?id=1125 Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Troubles with make check
On Thu, Jun 17, 2010 at 9:17 AM, Carl Sorensen c_soren...@byu.edu wrote: On 6/17/10 9:48 AM, Neil Puttock n.putt...@gmail.com wrote: On 17 June 2010 16:42, Carl Sorensen c_soren...@byu.edu wrote: The problem I have is that after the assertion fails, the temp directory is removed: assert stat == 0 AssertionError rm -rf /var/folders/Rv/RvqP2cCoEOawyy1FGSxWZU+++TI/-Tmp-/tmphOUJQb So my crop1 file is now gone, and I can't do the compare by hand. http://code.google.com/p/lilypond/issues/detail?id=908 I've had the same problem since upgrading to Ubuntu 10.04. I've been applying Patrick's patch whenever it fails. Thanks, Neil. I'll try it as soon as I get the chance. This looks like just the right thing. Yes, this AssertionError is the same error I see whenever I forget to apply that patch. :-) -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cap in path routine (was: Re: Eyeglasses (was Re: -dbackend=svg ... warning: missing stencil expression `embedded-ps'))
2010/6/6 josé henrique padovani zepadov...@gmail.com: Just to be sure: Is it possible to set different caps with the path routine? (I didn't found this option) If not, would it be possible to add an optional variable to set it and have it working on both ps and svg backends? It's not possible right now, but I'll plan on adding support for it shortly. Thank you for the suggestion. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cap in path routine (was: Re: Eyeglasses (was Re: -dbackend=svg ... warning: missing stencil expression `embedded-ps'))
2010/6/6 Patrick McCarty pnor...@gmail.com: 2010/6/6 josé henrique padovani zepadov...@gmail.com: Just to be sure: Is it possible to set different caps with the path routine? (I didn't found this option) If not, would it be possible to add an optional variable to set it and have it working on both ps and svg backends? It's not possible right now, but I'll plan on adding support for it shortly. Looking into this more, I see two issues: 1) What names should we use for the different linecap options? 2) Where should these values be specified? For 1), we could use the PostScript naming convention, though it is somewhat difficult to remember. The SVG naming convention is easier to understand, but more wordy. For 2), I don't really know at the moment. :-) I think it would be best to find a general solution that will work for all routines capable of supporting linecap settings (for example, 'draw-line and 'polygon). Any thoughts (about syntax, or otherwise)? Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fontforge requirement
On Sun, Jun 6, 2010 at 10:44 AM, Graham Percival gra...@percival-music.ca wrote: Since Issue 963: check dependency versions for 2.14 http://code.google.com/p/lilypond/issues/detail?id=963 is closed, I am extremely reluctant to bump requirements now. According to configure.in, STEPMAKE_PATH_PROG(FONTFORGE, fontforge, REQUIRED, 20050624) Jan, are you hoping to merge Woff fonts before 2.14 ? if so, we have a problem. Since it needs to be so new ( 20100501 ), I would really like to postpone that until 2.15. (unless it can be added in such a way that normal lilypond usage is fine with 20050624... I'm not certain what the woff stuff is; I'm just anticipating a potential problem). I was going to bring this up when I have a chance to thoroughly review Jan's patch, but I suppose I'll leave a quick comment right now. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: -dbackend=svg ... warning: missing stencil expression `embedded-ps'
On Sun, Jun 6, 2010 at 6:36 AM, Neil Puttock n.putt...@gmail.com wrote: 2010/6/4 Patrick McCarty pnor...@gmail.com: Another option is to use the 'path routine. This isn't documented yet and is a little cumbersome to use, but you can find an example that uses 'path in this snippet: http://lsr.dsi.unimi.it/LSR/Item?id=623 I see \eyeglasses uses make-postscript-markup; I guess it should be rewritten using 'path (or ideally, implemented as a glyph). Unfortunately it uses `arc' to create the lenses, which will be a pain to approximate using curveto (the usual suggestion being four bezier quadrants as a fair approximation. :) Yeah, it's unfortunate that the SVG Tiny 1.2 spec doesn't support the arc path commands. SVG 1.1 does, but I want to make sure we support Tiny 1.2 too. Using four bezier curves to approximate a circle is probably close enough. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Eyeglasses (was Re: -dbackend=svg ... warning: missing stencil expression `embedded-ps')
On Sun, Jun 6, 2010 at 6:43 AM, Carl Sorensen c_soren...@byu.edu wrote: On 6/6/10 7:36 AM, Neil Puttock n.putt...@gmail.com wrote: 2010/6/4 Patrick McCarty pnor...@gmail.com: Another option is to use the 'path routine. This isn't documented yet and is a little cumbersome to use, but you can find an example that uses 'path in this snippet: http://lsr.dsi.unimi.it/LSR/Item?id=623 I see \eyeglasses uses make-postscript-markup; I guess it should be rewritten using 'path (or ideally, implemented as a glyph). Unfortunately it uses `arc' to create the lenses, which will be a pain to approximate using curveto (the usual suggestion being four bezier quadrants as a fair approximation. :) I'd be happy to add it as a glyph. I've got enough experience in the fonts now with my work on shape notes that it wouldn't take long. However, I think there's some value in having something in the distribution that uses 'path, because that's an easy way for users to add new shapes. I think that using 'path would be the better option, also the circles and semicircle will be a little tricky to code. So I'd like to propose that we have the task of changing \eyeglasses from make-postscript-markup to 'path be a Frog task. To make everything easier, we should probably add a new markup command, \path, so that we can use `make-path-markup' when redefining \eyeglasses. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Eyeglasses (was Re: -dbackend=svg ... warning: missing stencil expression `embedded-ps')
On Sun, Jun 6, 2010 at 12:16 PM, Patrick McCarty pnor...@gmail.com wrote: I think that using 'path would be the better option, also the circles and semicircle will be a little tricky to code. This should say ... though the circles and semicircle will be a little tricky to code. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cap in path routine
2010/6/6 josé henrique padovani zepadov...@gmail.com: Em 06/06/10 15:33, Patrick McCarty escreveu: Looking into this more, I see two issues: 1) What names should we use for the different linecap options? 2) Where should these values be specified? Any thoughts (about syntax, or otherwise)? well.. I think that would be good to preserve the ps-like words (simply to avoid confusion between svg and ps syntaxes) It would be nice to add both setlinecap and setlinejoin to the 'path defs... They could be added as optional arguments (not sure about the guile syntax as I am more (use-modules (ice-9 optargs)) ;; is this module already loaded by LilyPond? (define* (path thickness exps #:optional cap join ) ...) or, using keywords (more elegant?)... and then if linecap or linejoin are not supplied by the user they can have their actual default values... (maybe path could be extendend in this way?) (use-modules (ice-9 optargs)) ;; is this module already loaded by LilyPond? (define my-proc (lambda* (thickness exps #amp;key linecap linejoin) What do you think? This looks like an easy way of implementing these extra configurable options. I've already started fiddling with the 'path routines, and I'll let you know when I have worked everything out. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: -dbackend=svg ... warning: missing stencil expression `embedded-ps'
2010/6/4 josé henrique padovani zepadov...@gmail.com: I am trying to generate svg files of my score, where I use some \postscript markups. Everything goes ok, except those markups... I get this warning and the svg file comes without the postcript drawings... warning: missing stencil expression `embedded-ps' Is this a bug? If not, is there some work-around? It's not a bug. :-) The \postscript command is one of the few commands that uses native PostScript code in the output. Since SVG doesn't support embedded PostScript, there is no easy way to support \postscript in the SVG backend. If your PostScript code is simple enough, you could try trying creating custom figures with the 'embedded-svg routine. This permits entering native SVG code that can be used with the SVG backend. For an example, see this code: http://uoregon.edu/~pmccarty/svg/src/embedded-svg/embedded-svg.ly Note that 'embedded-svg will not work with the PostScript/PDF output. Another option is to use the 'path routine. This isn't documented yet and is a little cumbersome to use, but you can find an example that uses 'path in this snippet: http://lsr.dsi.unimi.it/LSR/Item?id=623 In other words, there is no *easy* workaround... yet. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Initialize interval in grob_stencil_extent().
Hello,
Is this patch correct?
The reason I ask is because, after applying this patch, the results of
`make check' show many spacing changes, and I don't know if those
changes occur because the patch is incorrect or if there are
spacing-related workarounds in the codebase that need to be adjusted.
Also, the new regtest `stem-length-estimation.ly' will need to be
reworked to fit all systems on one page again, and I'll take of that
if this patch is okay.
One example of the spacing changes is attached.
Thanks,
Patrick
From e45c647771360e6809c437c98ca6ea7bd54a99fe Mon Sep 17 00:00:00 2001
From: Patrick McCarty pnor...@gmail.com
Date: Sun, 23 May 2010 13:30:06 -0700
Subject: [PATCH] Initialize interval in grob_stencil_extent().
There is a chance of returning garbage values from grob_stencil_extent()
due to this uninitialized variable issue.
---
lily/grob.cc |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lily/grob.cc b/lily/grob.cc
index 911243b..d5d5309 100644
--- a/lily/grob.cc
+++ b/lily/grob.cc
@@ -682,7 +682,7 @@ static SCM
grob_stencil_extent (Grob *me, Axis a)
{
Stencil *m = me-get_stencil ();
- Interval e;
+ Interval e (0, 0);
if (m)
e = m-extent (a);
return ly_interval2scm (e);
--
1.7.1
attachment: song-melisma.pngattachment: song-melisma.compare.jpeg___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Initialize interval in grob_stencil_extent().
On Sun, May 23, 2010 at 3:39 PM, Han-Wen Nienhuys hanw...@gmail.com wrote: On Mon, May 24, 2010 at 12:30 AM, Patrick McCarty pnor...@gmail.com wrote: Hello, Is this patch correct? Interval has a default constructor, so in general addinig initialization is not necessary. You can check the constructor to undersand why your patch is not correct. Oops, thanks for the correction. Sorry for the noise. -Patrck ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR removed @knownissue for X-staff tremelos
On Wed, May 12, 2010 at 7:25 AM, Graham Percival
gra...@percival-music.ca wrote:
On Wed, May 12, 2010 at 11:19 AM, James Lowe james.l...@datacore.com wrote:
Hello,
Mark Polesky wrote:
Did you guys not see Neil's reply?
http://lists.gnu.org/archive/html/lilypond-devel/2010-05/msg8.html
Cross-staff unstemmed tremolos (note the spelling)
... look terrible:
\new PianoStaff
\new Staff = up \relative c' {
s1
}
\new Staff = down \relative c'' {
\voiceOne
\repeat tremolo 16 {
a e'32
{
\change Staff = up
\voiceTwo
cis a'32
}
}
}
Well, if somebody submitted this bug now, I wouldn't add it as a
@knownissue; I'd just expect it to be added as Defect-medium or
Defect-High. Patrick, could you check if we have such an issue
(potentially at a different priority) ?
I couldn't find any open issues dealing with this, so I've just added it:
http://code.google.com/p/lilypond/issues/detail?id=1087
Thanks,
Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: temporary bug squad member needed
On 2010-05-09, Graham Percival wrote: Sorry to do this, but we need another bug squad person, starting from 1 week ago and lasting until 1 month after 2.14.0. Patrick? Mark? Trevor? Any of you willing? Sure, I could devote some time for this. We'll skip over the customary review of all regtests (which is a nice introduction for new bug squad members); all you need to do is add items to the tracker for good bug reports. We've had approximately 5 bug reports in the past week, and possibly 2 or 3 in the week before that; I don't want these to get lost. I seem to recall that there were some regressions from a few releases ago, so I'll check that out before rereading the recent bug-lilypond archives. I know it's a piss-poor use of resources to ask highly skilled developers (able to use git, compile, write scheme, etc.) to do this, but there's no indication of any users willing to pick up the slack, and in any case I'm not willing to train anybody who I don't know will follow through. After 2.14 is out, we'll start GOP and I'll do precisely that, but I'm not up for it right now. It's not a problem. I don't know how much I can help out with the remaining criticial issues, since they're either not interesting to me or they will require too much of my time, but I know I can manage to help out with this (at least temporarily). Estimated workload: not counting time spent reading bug-lilypond (which I'm pretty sure you all do anyway), 30 minutes a week, lasting until 1 month after 2.14.0. Plus maybe 1 or 1.5 hours to catch up on the backlog and learn any of the ropes that you don't already know. Okay, sounds reasonable. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: xref to @unnumbered* bug
On Wed, May 5, 2010 at 11:24 AM, Graham Percival gra...@percival-music.ca wrote: I'm not certain it's a texi2html bug, or a bug in our texi2html init file, but either way it should be in the tracker. Bug Squad: please add this. Type-build, priority-medium. Added as: http://code.google.com/p/lilypond/issues/detail?id=1081 Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Critical issue: flag glyphs changing shape
Hi Carl, After looking through the regtest comparison for 2.13.19/2.13.20, I noticed that flag glyphs have changed shape. I posted a tracker issue for this: http://code.google.com/p/lilypond/issues/detail?id=1075 I assume this is related to your recent changes to the Metafont code, but I can't claim to know why. Can you have a look? Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Eliminate PDF deletion in Windows
On Thu, Apr 29, 2010 at 8:32 PM, Carl Sorensen c_soren...@byu.edu wrote: On 4/27/10 10:49 PM, Nathan Reed nathaniel.r...@gmail.com wrote: Lilypond would attempt to delete the output PDF before overwriting it in Windows (but no other platforms). This is unnecessary and causes problems with certain PDF viewers, e.g. Sumatra, where the PDF is kept open in a way that allows overwriting but not deletion. See also the discussion on bug-lilypond[1]. I've reviewed this patch, and it looks good to me. I don't run LilyPond on Windows. Nathan has tested with multiple PDF viewers, and it seems to be better on some and no worse on any of them that have been tested. It looks fine to me too. Are there any objections to having me push this patch? I've just pushed it. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Critical issue: flag glyphs changing shape
On Wed, May 5, 2010 at 11:53 PM, Patrick McCarty pnor...@gmail.com wrote: After looking through the regtest comparison for 2.13.19/2.13.20, I noticed that flag glyphs have changed shape. I posted a tracker issue for this: http://code.google.com/p/lilypond/issues/detail?id=1075 I assume this is related to your recent changes to the Metafont code, but I can't claim to know why. I've confirmed that if I revert commit 6aa858, the correct shapes for flags are restored. I still have no idea why this is happening. Just a guess: maybe the flag glyphs are dependent on some of the refactoring work from that commit? Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
