Re: Issue 881 Arpeggios may collide with laissezVibrer ties (was Re: Critical issues)
- This is a multipart MIME message. Karl Hammar: Carl Sorensen: ... I've posted a patch on Rietveld. Can you do the regression test? http://codereview.appspot.com/1195044 After a make test-redo I get: . the mandatory output-distance. . a diff of tree.gittext, showing Carls patch . 314 below threshold . 2062 unchanged From this I assume Carls patch does not affect any present regression test. Sorry to bring this up again, but this conclusion is still unproven, since the test was done with test-redo. As I have found out in the thread for the issue 915, test-redo does not test the things we wanted to test. *** $ git-status # On branch master # Untracked files: # (use git add file... to include in what will be committed) # # issue1195044_1_2.diff # issue1195044_1_3.diff # issue931041_1.diff nothing added to commit but untracked files present (use git add to track) $ git-log | head -1 commit 22d889f4d27469864c31db81445e9de49774ae23 $ cat issue1195044_1_[23].diff | patch -p1 patching file scm/define-grobs.scm patching file scm/output-lib.scm $ make check log 21 ... And I get a distance of 18.406667 in the attached output. The difference seems to be because the c and the b are horizontally closer to each other. Regards, /Karl Hammar attachment: tie-semi-single.compare.jpegattachment: tie-semi-single.png___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 881 Arpeggios may collide with laissezVibrer ties (was Re: Critical issues)
And here comes the test-baseline file. Regards, /Karl Hammar attachment: tie-semi-single.png___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Notes on #1036
2010/5/15 Graham Percival gra...@percival-music.ca: In answer to your main question, my understanding is that anchor links come from the xref is a xref file exists, otherwise they come from the texinfo section commands (like @unnumberedsubsubsec). Yes, this is how it's supposed to work, but it doesn't. We are printing translated anchors instead of anchors taken from the original English section name. xrefs do have these, but we ignore them. [ At least that was the case until I issued my last patch] -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributors manual
On 5/16/10 6:12 PM, Mark Polesky markpole...@yahoo.com wrote: Graham Percival wrote: A larger question is whether we should keep 3.6 Post-installation options. In the first place, the word options implies (to me) something akin to configuration options, not a list of possible commands (which is the meaning used here). How about restructuring the nodes like this (note that I renamed some node names here): 3. Compiling LilyPond 3.1 Overview of compiling 3.2 Requirements 3.3 Getting the source code 3.4 Configuring make 3.5 Compiling 3.6 Installing and testing 3.6.1 Installing from a local build 3.6.2 Testing 3.7 Generating documentation 3.7.1 Documentation editor's edit/compile cycle 3.7.2 Building documentation 3.7.3 Saving time with CPU_COUNT 3.7.4 Installing documentation 3.7.5 Building documentation without compiling 3.8 Problems etc. Second, it might be easier to find relevant material if we just kept 3.6.1 Installing from a local build, and moved the doc-material to the Doc chapter, and the regrest material to the Regression chapter. For my money, I think we should have the regression test stuff in the regression test chapter. I consider the regression test to be completely separate from installation. There's no need to run the regression tests to verify an installation. Any test file will do, IMO. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR: Using \partial with \repeat. (issue1136044)
LGTM. I think the first example is no longer needed. Thanks, Carl http://codereview.appspot.com/1136044/diff/6001/7001 File Documentation/notation/repeats.itely (right): http://codereview.appspot.com/1136044/diff/6001/7001#newcode126 Documentation/notation/repeats.itely:126: Repeats that begin after the initial partial measure of a score: Why have this example here? The repeat doesn't have an upbeat (or pickup, or anacrusis, or \partial ;-) ) so I think this whole example can go away with the rewriting you've done. http://codereview.appspot.com/1136044/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] G clef rotation note to CHANGES
Hello. This patch adds rotation of the G clef change log. I would push
it if I could. The wording may be improved.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
From 7a5ea41a11caea89a846293fd46ff80d5c8764d1 Mon Sep 17 00:00:00 2001
From: Francisco Vila francisco.v...@hispalinux.es
Date: Mon, 17 May 2010 13:03:33 +0200
Subject: [PATCH] Changes: add G clef rotation notice.
---
Documentation/changes.tely | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/Documentation/changes.tely b/Documentation/changes.tely
index 09ac367..d30a21f 100644
--- a/Documentation/changes.tely
+++ b/Documentation/changes.tely
@@ -64,6 +64,17 @@ which scares away people.
@end ignore
+
+...@item
+Our G clef has been rotated 1.5 degrees clockwise for improved
+balance. You can compare the old and new versions by looking at the
+documentation:
+...@uref{http://lilypond.org/doc/v2.12/Documentation/user/lilypond/The-Feta-font.html#Clef-glyphs,
+old version},
+...@uref{http://lilypond.org/doc/v2.13/Documentation/notation/the-feta-font.html#Clef-glyphs,
+new version}.
+
+
@item
Text crescendo spanners can now be added directly using @code{\cresc},
@code{\dim} and @code{\decresc}.
--
1.7.0.4
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] G clef rotation note to CHANGES
Thanks, Pushed (with some minor modifications of wording). Carl On 5/17/10 5:10 AM, Francisco Vila paconet@gmail.com wrote: Hello. This patch adds rotation of the G clef change log. I would push it if I could. The wording may be improved. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] G clef rotation note to CHANGES
2010/5/17 Carl Sorensen c_soren...@byu.edu: Pushed (with some minor modifications of wording). Thank you. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Remove kludge in Module Code to support Guile V1.6 (MODULE_GC_KLUDGE conditional compilation)
We have these blocks in our C++ code base:
$ git grep -A 5 MODULE_GC_KLUDGE
lily/include/ly-module.hh:#define MODULE_GC_KLUDGE
lily/include/ly-module.hh-
lily/include/ly-module.hh-#endif /* LY_MODULE_HH */
lily/include/ly-module.hh-
--
lily/ly-module.cc:#ifdef MODULE_GC_KLUDGE
lily/ly-module.cc-Protected_scm anonymous_modules = SCM_EOL;
lily/ly-module.cc-bool perform_gc_kludge;
lily/ly-module.cc-#endif
lily/ly-module.cc-
lily/ly-module.cc-void
--
lily/ly-module.cc:#ifdef MODULE_GC_KLUDGE
lily/ly-module.cc- for (SCM s = anonymous_modules;
lily/ly-module.cc- scm_is_pair (s);
lily/ly-module.cc- s = scm_cdr (s))
lily/ly-module.cc-{
lily/ly-module.cc- SCM module = scm_car (s);
--
lily/module-scheme.cc:#ifdef MODULE_GC_KLUDGE
lily/module-scheme.cc- clear_anonymous_modules ();
lily/module-scheme.cc-#endif
lily/module-scheme.cc-
lily/module-scheme.cc- return SCM_UNSPECIFIED;
lily/module-scheme.cc-}
$
As I understand it, these are to get round problems with Guile pre V1.8,
which we no longer support.
Please open a tracker so we can delete this code and I will begin work
on a patch.
Cheers,
Ian Hulin
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR: Using \partial with \repeat. (issue1136044)
Looks fine to me. http://codereview.appspot.com/1136044/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Translation errors in German documentation
Am 11.05.10 21:24, schrieb Marc Hohl: Thanks for the hint - I hope everything is ok now ... Marc Sorry, I pushed an earlier patch already (9th of may) onto the translation branch which is not yet merged with master (resulting commitish was f91457a04028a58d48fce829ee2e3cae366241f5, see http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=f91457a04028a58d48fce829ee2e3cae366241f5). But because most of your changes are already online your last patch doesn't apply. Could you check out branch lilypond/translation and make a new patch of your last corrections? Thanks Till ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] hopefully fix #1036
On Mon, May 17, 2010 at 02:03:56PM -0600, Carl Sorensen wrote: On 5/17/10 1:58 PM, Graham Percival gra...@percival-music.ca wrote: Nobody likes Perl, but sadly we're stuck with it for texi2html for the foreseeable future. John Mandereau was working on a texinfo parser in python, which, if it works, should allow us to get away from texi2html. But I don't know what his current status on that is I believe that my phrase for the foreseeable future is accurate. Now, it might occur that once texi2html is merged with texinfo, somebody might create a way of using python functions for the perl texi2html's hooks (I'm certain that a general way of mixing perl+python already exists), and that we could use this to write our own functions in python. Of course, if that's happening, then we might as well send any generally-useful patches upstream (such as writing filenames in lower-case). And also move the translations into a data file instead of having them directly in the init file. Those two items would probably reduce the size of the current init file to about 33% of the current size, making it much more maintainable even without switching to python. That said, I believe that my phrase for the foreseeable future is still accurate. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB and mipsel architecture
On Mon, May 17, 2010 at 08:45:37AM +0200, Federico Bruni wrote: I'm wondering if it is worth having a mipsel package on lilypond.org (when 2.14 comes out, maybe). I'd be happy to do it, if I can. A chance to help and learn something new. This should be discussed on -devel rather than -user. I would be happy to build+include mipsel packages, as long as somebody else modifies GUB to handle it, and they fix any breakage in those packages. If they stop GUB from compiling a release, I would simply comment out the mipsel compilation and release the rest. However, cross-compiling is a fairly involved process and requires a great deal of technical knowledge. Don't expect much help, because very few people have any experience with it. # Tail of target/tools/log/librestrict.log ./xstatconv.c:224: error: 'struct stat' has no member named '__pad2' ./xstatconv.c:266: error: 'struct stat' has no member named '__unused4' ./xstatconv.c:269: error: 'struct stat' has no member named '__unused5' Command barfed: cd /home/fede/src/gub/target/tools/build/librestrict-1.9.a gcc -W -Wall -fno-stack-protector -I. -fPIC -shared -o librestrict-stat.so restrict-stat.c || gcc -W -Wall -I. -fPIC -shared -o librestrict-stat.so restrict-stat.c Tail of target/tools/log/librestrict.log *** Failed target: tools::librestrict ## Just in case, I attach also target/tools/build/librestrict-1.9.a/xstatconv.c How can I fix it? I would begin by searching for this error on google. Also, where in the code does this error occur? What do you see around lines 260-270 in xstatcon.c ? also, what headers does this file include, and are those headers available? PS (a report on a different subject) Please don't report multiple issues in the same email. I've read that you have changed the ./configure in 2.13.21 In previous versions, when I run ./autogen.sh, ./configure failed to recognise my architecture, even though some information were printed on terminal (can't remember) and especially: `uname -m mips64` Since this version I don't have this warning. Maybe next time I can try removing the --build=mips64 option and see what happen. Err... is this a report, or a memo to yourself? By all means, try removing that build option and see what happens. As you said, we've updated the ./configure script, so I wouldn't be surprised if the host architecture detection is better. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR: Using \partial with \repeat. (issue1136044)
LGTM. I'm with Carl on removing the first example. Cheers, Neil http://codereview.appspot.com/1136044/diff/6001/7002 File Documentation/notation/rhythms.itely (right): http://codereview.appspot.com/1136044/diff/6001/7002#newcode2935 Documentation/notation/rhythms.itely:2935: \set Timing.measurePosition = #(ly:make-moment 5 8) remove indent http://codereview.appspot.com/1136044/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB and mipsel architecture
I'm wondering if it is worth having a mipsel package on lilypond.org (when 2.14 comes out, maybe). I'd be happy to do it, if I can. A chance to help and learn something new. This should be discussed on -devel rather than -user. I would be happy to build+include mipsel packages, as long as somebody else modifies GUB to handle it, and they fix any breakage in those packages. If they stop GUB from compiling a release, I would simply comment out the mipsel compilation and release the rest. However, cross-compiling is a fairly involved process and requires a great deal of technical knowledge. Don't expect much help, because very few people have any experience with it. The main question is, does anyone really want it done. I did a lot of mipsel development in the past, so cross-compilation is not a problem, but it all comes to user value. A few months ago, I had a pressing request, from a real-life user for whom I do custom features in Lilypond, to produce Win32 builds, and I started looking at digging inside GUB; but when I presented to them an estimate of how many days it would take to have a functional GUB platform, it became clear that my time would be much wiser spent on actual Lilypond development (score layout functionality), rather than GUB, and that using Linux instead of Windows was not *that* unsurmountable a problem to justify potentially up to two weeks lost to GUB work. So if one is about to do something with a real purpose (mipsel Lilypond appliance?? completeness of a distro??) I would expect many people with the right skills to be able to do it; on the other hand, as an academic exercise I personally would not find it the most attractive to jump on -- there are many other interesting problems to solve. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR: Using \partial with \repeat. (issue1136044)
On Mon, May 17, 2010 at 08:07:33PM +, markpole...@gmail.com wrote: Message: On 2010/05/17 17:40:16, Graham Percival wrote: Looks fine to me. Do you agree with Carl that I should remove this? http://codereview.appspot.com/1136044/diff/6001/7001#newcode126 Yes, it should be removed... but OTOH if you'd pushed the patch as-is, I wouldn't have complained about that. But since you're asking: yes, please remove that example, and then push. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB and mipsel architecture
On Mon, May 17, 2010 at 06:36:14PM -0400, Boris Shingarov wrote: I'm wondering if it is worth having a mipsel package on lilypond.org (when 2.14 comes out, maybe). I'd be happy to do it, if I can. A chance to help and learn something new. However, cross-compiling is a fairly involved process and requires a great deal of technical knowledge. Don't expect much help, because very few people have any experience with it. The main question is, does anyone really want it done. Federico Bruni, apparently. :) unless there's a stress on the really, in which case I'd guess that the answer is nobody. So if one is about to do something with a real purpose (mipsel Lilypond appliance?? completeness of a distro??) I would expect many people with the right skills to be able to do it; on the other hand, as an academic exercise I personally would not find it the most attractive to jump on -- there are many other interesting problems to solve. *shrug* I totally agree that from a learning about lilypond development exercise, just about anything would be more useful than working on GUB. But if Frederico is particularly interested in this project, there's no harm in him trying it out -- as long as he knows that he probably won't get any more help than I did in the previous email (try google / are there any missing headers / etc). I wish I could offer more help -- not because I think this particular project is important, but just as a fostering curiosity type of thing -- but unless I start investigating those steps myself, I can't do anything else. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] hopefully fix #1036
On Mon, May 17, 2010 at 11:36:50PM +0200, Francisco Vila wrote: 2010/5/17 Graham Percival gra...@percival-music.ca: On Mon, May 17, 2010 at 2:33 AM, Francisco Vila paconet@gmail.com wrote: However, it breaks the webpage; we now have links like introduction.html#introduction instead of introduction.html#Introduction As for the scrolled down problem: when it supposedly worked well, it only did because the links were wrong, they did not match with the anchors. So, the browser renders the whole page, because the filename is correct but the target does not exist. Ah, I remember now. I tried to remove the #foo if foo matched the foo.html portion, but I couldn't easily get rid of the #. The best I could do was to make it introduction.html# which either had some problem, or just looked bad. I didn't spend a _lot_ of time poking around on this problem, so if you look into it as well (and maybe ask the texi2html people for help), you might find a solution. Now the anchors and the targets do match. So, if the page scrolls down is only because a flaw in our page design: we'd have to put a link at the top of a page which link to, not rely on that broken links will result on the page being fully showed. No. The solution isn't to add a new link; the solution is to fix texi2html (or maybe the CSS). That can be either done in our init file, or by reporting this problem to texi2html. I think the CSS is fine, btw. I just list it for completeness. I'm also not at all certain about the - return ($id, $target); + return ($target, $target); lines. The correct is ($targed, $id) (i.e. the opposite of what it was). But then the target and the anchor swapped again, and they did continue not matching. They only do match that way (we agree in that target and anchors must match, do we?) No, we don't agree. In 80% of our links, we don't need the #foo portion at all, and they only get in the way. As long as they don't *break* anything, I don't mind having a #foo there, but they *do* break things on the website. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributors manual
On Mon, May 17, 2010 at 04:03:11AM -0600, Carl Sorensen wrote: On 5/16/10 6:12 PM, Mark Polesky markpole...@yahoo.com wrote: Graham Percival wrote: A larger question is whether we should keep 3.6 Post-installation options. In the first place, the word options implies (to me) something akin to configuration options, not a list of possible commands (which is the meaning used here). How about restructuring the nodes like this (note that I renamed some node names here): 3. Compiling LilyPond 3.1 Overview of compiling 3.2 Requirements 3.3 Getting the source code I'm not 100% certain that we need this at all. (then again, I'm not 100% certain that we *don't* need it) if somebody's looking at the CG, they'll already have access to CG 2, and anybody wanting to compile lilypond won't be so abysmally stupid as to think they can compile it without the source, and CG 2 is easy to find. if they're looking at it via the INSTALL.txt file, then they're already staring at the source code now, it wouldn't be good to lose the info about the tarball version archive, but that could probably live in CG 2. 3.4 Configuring make 3.5 Compiling 3.6 Installing and testing 3.6.1 Installing from a local build 3.6.2 Testing See below about testing. 3.7 Generating documentation 3.7.1 Documentation editor's edit/compile cycle 3.7.2 Building documentation 3.7.3 Saving time with CPU_COUNT 3.7.4 Installing documentation 3.7.5 Building documentation without compiling I think this works best as a separate section, but see below about CG 2 vs. the doc chapter. 3.8 Problems etc. If we're having a serious discussion about this chapter, then I don't like the etc. These are obviously tacked on to the end of this chapter as a quick dump this somewhere before we forget about the info; if we're seriously working on CG 3, then we should deal with them properly. Second, it might be easier to find relevant material if we just kept 3.6.1 Installing from a local build, and moved the doc-material to the Doc chapter, and the regrest material to the Regression chapter. I don't think we should burden the Doc chapter with the business of building docs. I see the Doc chapter as being accessible to contributors who won't be compiling. That's actually a reason in favor of moving the doc-building stuff *out* of chapter 2 -- the building the docs without compiling would be more visible to them. For my money, I think we should have the regression test stuff in the regression test chapter. I consider the regression test to be completely separate from installation. In practice, yes. There's no need to run the regression tests to verify an installation. Any test file will do, IMO. Well, not quite. any test file won't necessarily include utf-8 lyrics. It might not include embedded postscript. Etc. I could well imagine a package builder wanting to test his package (on mipsel? :) before distributing it. However, that could be easily covered by leaving a link from the compiling chapter to the relevant part of the regression tests chapter. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
