GOP-PROP: pause in proposals
We have a number of maintainability problems, such as an inability to build releases and delayed implementation of some previous accepted proposals. I am therefore not introducing any new proposals for the next two weeks. New proposals will tentatively start on the week of 2011-Sep-07, but this may be delayed another week or two if I believe that my time would be better spent putting out fires elsewhere. The exisiting two proposals (make doc, scheme indentation) will continue going through the system since they seem to have widespread support; no point delaying them. Updated schedule: http://lilypond.org/~graham/gop/ Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lily-guile updates and CG: Scheme-C interface section. (issue 4917044)
On 2011/08/19 23:03:37, Neil Puttock wrote: On 2011/08/19 21:08:10, Carl wrote: As an aside, I think that we should change the definition of the property align-dir. It should no longer be called a direction, since it's not limited to the values -1, 0, and 1. It's unused. I think it's superseded by stacking-dir. It's used in fret-diagram markups. See Notation Reference A.9.5. Thanks, Carl http://codereview.appspot.com/4917044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES: 48-hour countdown
To be pushed after 00:01 PST on Monday Aug 15. I know there's a lot of big things in here to review, but we need to tackle them! CG: revise CG instructions for commit access http://code.google.com/p/lilypond/issues/detail?id=1824 http://codereview.appspot.com/4898058/ Lilypond-book music runs off right side of the page http://code.google.com/p/lilypond/issues/detail?id=1816 http://codereview.appspot.com/4888046/ Doc: NR - Polymetric Notation \compoundMeter isn't documented http://code.google.com/p/lilypond/issues/detail?id=1776 http://codereview.appspot.com/4837050 % (single patch does both issues) accidentaled notes too far from the barline http://code.google.com/p/lilypond/issues/detail?id=1779 Compressible space before the first note of a line ? http://code.google.com/p/lilypond/issues/detail?id=1785 http://codereview.appspot.com/4188051/ Revise warning re cueDuring font size http://code.google.com/p/lilypond/issues/detail?id=1811 http://codereview.appspot.com/4850051 Guile 2.0 compat: Scheme macros must be defined/autocompiled before they are used. http://code.google.com/p/lilypond/issues/detail?id=1349 http://www.codereview.appspot.com/4849054 Code cleaning: checking types-conversion issues and other build warnings http://code.google.com/p/lilypond/issues/detail?id=804 % lexer.ll: remove unused patterns, avoid backing up http://codereview.appspot.com/4871041/ changing shape of the G clef http://codereview.appspot.com/4664070/ collision glissando accidental http://code.google.com/p/lilypond/issues/detail?id=40 http://codereview.appspot.com/4801083 Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Creates pure closures (issue 4894052)
On Aug 20, 2011, at 12:02 AM, Neil Puttock wrote: On 18 August 2011 13:44, Mike Solomon mike...@ufl.edu wrote: What about pure-container ? unpure-pure-container ? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Prevents nested tuplets from colliding. (issue 4808082)
On Aug 19, 2011, at 11:58 PM, n.putt...@gmail.com wrote: http://codereview.appspot.com/4808082/diff/13002/lily/tuplet-bracket.cc#newcode283 lily/tuplet-bracket.cc:283: SCM scm_x_span = me-get_property (X-positions); I seem to recall we discussed the option of splitting control-points into separate X/Y properties (can't remember exactly which grob it was for :). Beams (I think...). My main concern was the naming since 'positions should be changed to Y-positions, but this would be disruptive for other grobs. This could be done in a separate patch. http://codereview.appspot.com/4808082/diff/13002/lily/tuplet-bracket.cc#newcode669 lily/tuplet-bracket.cc:669: // have to re_run numbers to check for number-on-number collisions This is getting a bit complicated. Do you think it's feasible to have a grob which would collect the colliding brackets and do the collision avoidance as a separate positioning-done callback? This would certainly avoid the guestimation of the numbers' positions... I'll do some digging and get back to you! Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Moving away from make
Han-Wen Nienhuys writes: Given that Cmake has a large following (examples include KDE and LLVM), I'd be comfortable with switching to that. Interesting; have you ever used Cmake? Last time I looked (migrated a cmake project to autotools), Cmake did only have proprietary documentation (I hear most documentation is in a wiki now), introduced a rather crappy home brew language, cached make information in generated makefiles that do not use variables for $(CC) or $(CFLAGS), has a IMHO nasty way of overriding such variables on the cmake command line. Also, it did not have an easy way to create help from the command line or a facility to have virtual targets or a nice way to say: `make -C lily out/parser.o' because all file names were absolute, fully expanded names. Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
changing e-mail address
Hi everyone, sorry for disappearing without a notice... I'm back and digging my way through e-mails. I've created myself a dedicated mailbox for Lily purposes: janek.lilyp...@gmail.com - please use it instead of this one! thanks, Janek PS please add janek.lilyp...@gmail.com to the tracker and wherever else is needed. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changing e-mail address
- Original Message - From: Janek Warchol lemniskata.bernoull...@gmail.com To: lilypond-devel@gnu.org Sent: Saturday, August 20, 2011 1:22 PM Subject: changing e-mail address Hi everyone, sorry for disappearing without a notice... I'm back and digging my way through e-mails. I've created myself a dedicated mailbox for Lily purposes: janek.lilyp...@gmail.com - please use it instead of this one! thanks, Janek PS please add janek.lilyp...@gmail.com to the tracker and wherever else is needed. That's a bit easier to remember than the lemniskata one :-) You want me to delete the old one from the tracker, too? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changing e-mail address
2011/8/20 Phil Holmes m...@philholmes.net: - Original Message - From: Janek Warchol lemniskata.bernoull...@gmail.com PS please add janek.lilyp...@gmail.com to the tracker and wherever else is needed. That's a bit easier to remember than the lemniskata one :-) Indeed :) You want me to delete the old one from the tracker, too? Yes, please. thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how many patches can we review?
2011/8/16 Graham Percival gra...@percival-music.ca: We're up to 59 patches now, plus 17 patches on the plz review; no known problems list. We're losing ground quickly, and this will soon become a serious problem for developers and contributors (if it isn't already). I see three options, none of which fill me with joy. 1) encourage more pushing without reviews. 2) assign certain people to be in charge of certain areas (e.g. Carl has final say over anything beaming-related), and encourage that person to review+push patches in his area ASAP. 3) double or triple the rate of patches in the countdown. Out of those options, I dislike #3 the least. I'm thinking of having 10 patches per countdown, 48 hours for each countdown. I know that's a lot of reviewing, but if we want to keep the opportunity for reviews, that's the kind of workload we need to handle. +1 cheers, Janek 2011/8/16 Mike Solomon mike...@ufl.edu: That said, I find that there is a positive correlation between the amount of my music that gets played / paid / enjoyed and the amount of development I do for LilyPond (I have no clue how this works, as in theory this means I have less time, but oh well!). So, I don't anticipate stopping my quest to eliminate all collisions[1] from LilyPond in the near future. :D ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable 2)
LGTM 2011/8/16 Graham Percival gra...@percival-music.ca: Minor update for clarity and discussion from the past few days. We're aiming to accept the final proposal on Thursday. http://lilypond.org/~graham/gop/gop_8.html ** Proposal summary Let’s get rid of priorities. We will simply describe bugs in neutral terms; each contributor can search and interpret the results as he or she sees fit. We will make a “Type-Critical”; a new stable release will only occur if there are 0 type-Critical issues. ** Rationale There is wide disagreement on what “priorities” should mean, or how they should be interpreted. Do they represent which “milestone” we want a fix by? How bad are crashes? How important are matters which hinder future development? Given that we treat developers as independent volunteers, the notion of an externally-imposed “priority” seems a stretch. The remaining question concerns Critical issues, and more generally, “what does a release mean?”. Our source tree is open; anybody can download and try any version. Our unstable development releases are freely available. The only distinction between git master and a “stable release” is our mark of approval. A new stable release indicates that we think the software is usable, and attracts more attention than an unstable release. In addition to user attention, it also attracts the attention of potential contributors, so we should avoid having any glaring problems which would stop somebody from contributing and turn them away – we do not want to put our “stamp of approval” on something which might cost us potential contributors. ** Proposal details We will delete “priority” altogether. The “type” system will be tweaked. Type-critical: * a reproducible failure to build either make or make doc, from an empty build tree, in a first run, if configure does not report any errors. * any program behaviour which is unintentionally worse than the previous stable version or the current development version. Developers may always use the “this is intentional”, or even the “this is an unavoidable effect of * an improvement in another area”, reason to move this to a different type. * anything which stops contributors from helping out (e.g. lily-git.tcl not working, source tree(s) not being available, lilydev being unable to compile git master, inaccurate instructions in the Contributor’s Guide 2 Quick start). To limit this scope of this point, we will assume that the contributor is using the latest lilydev and has read the relevant part(s) of the Contributor’s Guide. Problems in other chapters of the CG are not sufficient to qualify as Type-Critical. ** More new/changed types and labels Unless otherwise specified, the current types and labels will continue to be used. * Type-crash: any segfault, regardless of what the input file looks like or which options are given. Disclaimer: this might not be possible in some cases, for example certain guile programs (we certainly can’t predict if a piece of scheme will ever stop running, i.e. the halting problem), or if we rely on other programs (i.e. ghostscript). If there are any such cases that make segfault-prevention impossible, we will document those exceptions (and the issue will remain as a crash instead of documentation until the warning has been pushed). * Type-maintainability: anything which makes it difficult for serious contributors to help out (e.g. difficult to find the relevant source tree(s), confusing policies, problems with automatic indentation tools, etc). * Type-ugly: replaces Type-collision, and it will include things like bad slurs in addition to actual collision. * (label) Needs_evidence: it is not clear what the correct output should look like. We need scans, references, examples, etc. ** Shutting up users We can remind users that they can “star” an issue to indicate that they care about it. I could not possibly care less about what users think, but if any contributors want to look at that info and organize their work schedule according to that, they’re welcome to do so. Also, the stars might serve as a placebo for users. ** Implementation notes Yes, revising the current issue tracker will take a fair amount of effort, but I have a plan for this. Don’t waste time pointing this out. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Kievan square notation in LilyPond
Hi Aleksandr, i'm finally back to this. How much experience do you have with git and Lily source code? I ask because i don't know how detailed explanations should i provide :) I've looked at the metafont code you provided. It won't be hard to include it in Feta font as a separate group of glyphs, i've prepared a patch that begins this process. Please examine the attached patch and add it to your git repository; it adds all necessary meta files and one kievan glyph. I had some problem translating u into staff_spaces - did i guess correctly that u = 2 staff_spaces? I attach a simple test file that uses an override to choose kievan quarter glyph, therefore checking that it is available in Feta font. What should be done now: code of remaining glyphs should be added to feta-kievan.mf. Plese let me know if you have any problems or questions (or if you don't know where to start!). I hope to answer much faster now :) hope this helps, Janek kievan-test.pdf Description: Adobe PDF document kievan-test.ly Description: Binary data 0001-add-basic-infrastructure-for-kievan-font.patch Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changing e-mail address
- Original Message - From: Janek Warchoł lemniskata.bernoull...@gmail.com To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org Sent: Saturday, August 20, 2011 1:30 PM Subject: Re: changing e-mail address 2011/8/20 Phil Holmes m...@philholmes.net: - Original Message - From: Janek Warchol lemniskata.bernoull...@gmail.com PS please add janek.lilyp...@gmail.com to the tracker and wherever else is needed. That's a bit easier to remember than the lemniskata one :-) Indeed :) You want me to delete the old one from the tracker, too? Yes, please. thanks, Janek Done -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Moving away from make
On Sat, Aug 20, 2011 at 11:06:29AM +0200, Jan Nieuwenhuizen wrote: Han-Wen Nienhuys writes: Given that Cmake has a large following (examples include KDE and LLVM), I'd be comfortable with switching to that. Interesting; have you ever used Cmake? I migrated Marsyas (a moderately-sized project; 200,000 lines of code) from a combination of autotools and qmake (i.e. two separate build systems, maintained in tandem!) to cmake. Last time I looked (migrated a cmake project to autotools), Cmake did only have proprietary documentation Yes. Most of my cmake knowledge from reading slides of conference presentations and bug reports on their mailing list (or on blogs). introduced a rather crappy home brew language, Change that to extremely crappy home-brew language. Their crappy home-brew language is ridiculously far away from the readability of modern scripting languages like python and lua. That said, it still avoids the confusing $ $@ syntax from make. cached make information in generated makefiles that do not use variables for $(CC) or $(CFLAGS), I know it's extremely easy for users to change CC/CFLAGS/CXXFLAGS variables during the cmake configure stage. IMO, the generated makefiles aren't particularly intended to be human-readable. has a IMHO nasty way of overriding such variables on the cmake command line. Never use the cmake command line; always use ccmake (or even the graphical one, although I've never done that myself). Also, it did not have an easy way to create help from the command line There's good help strings in ccmake; I'm not bothered by this one. or a facility to have virtual targets or a nice way to say: `make -C lily out/parser.o' because all file names were absolute, fully expanded names. Hmm, I can't comment either way on this one. I'd be surprised if there was no way to do this, but OTOH I've been surprised about some brain-dead cmake stuff in the past. Most recently: in cmake 2.6, you can specify a working directory for a compile target, but you can't specify a working directory for a unit test. Recommended solution: write a python wrapper that changes to the relevant directory and runs your command, then exports the exit code. Overall, cmake is not an unambiguous win... but if I were starting a new moderate-sized project, I'd probably use cmake rather than any of the other build systems. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's SVG output
Op 19-08-11 10:19, Mike Solomon schreef: On Aug 19, 2011, at 10:04 AM, Sandor Spruit wrote: [snip] - In what version, exactly, did Lilypond drop the use of groups (svg:g) in its output? LilyPond still uses groups. grep g in scm/output-svg.scm. OK, thanks. I stand corrected. Let me rephase my comment. When looking at the very nice example Tim Sawyer (percussion360.com) posted on the user list this afternoon, I think the use of svg:g needs a bit of work to enable that sort of app. I read a debate on this issue, where the key argument against groups was the trouble people have in editing grouped SVG elements in Inkscape. I can, however, imagine all sorts of situations in which group elements could be very useful - from a developer's point of view at least. This leads to the second question: - For what purpose are people putting music up on the web; what's the typical use case? Check the list archives for an e-mail from Michael Geary. He's working on this. I do it too for my musical compositions (http://www.apollinemike.com/norman1). OK. I think I've found the mail you're referring too. Just publishing it for others to read? Hyperlinking to it, from it? Annotations? Keeping bits and pieces of music for later reference? Learning? Studying? Comparing versions? There is no formal hub that groups these efforts together, but as the SVG standard becomes better supported by more and more browsers, I'm sure it'll get picked up by more and mor epeople. There's a number of additional comments on the list that I missed the first time round. I may, at some point, be in the position to do some work on this. But I'm hesitant to dive in at the deep end - meaning Lilypond tens of thousands of lines of code ... You don't need to jump into tens and thousands of lines of LilyPond code - all of the svg backend is present in output-svg.scm. Michael Geary is likely to be sponsoring some work on this too - I'll keep you posted if/when this happens. Well, I do feel I need to have some insight into the inner workings of Lilypond before I can do anything meaningfull here, i.e. more than just the backend. A solution enabling a more general use of the features Tim demonstrates may be use in research too, so maybe I can work on this during office hours... cheers, Sandor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Make doc is broken
I think Reinhold's commit cfcb9efdbd7c6600fc89fc912ba80529010b31e7 has broken make doc. I've just done a clean build (fresh build directory) and get this at the end of a failed make doc: LILYPOND_VERSION=2.15.9 /usr/bin/python /home/phil/lilypond-git/scripts/lilypond-book.py -I /home/phil/lilypond-git/input/regression/musicxml/ -I ./out-www -I /home/phil/lilypond-git/input -I /home/phil/lilypond-git/Documentation -I /home/phil/lilypond-git/Documentation/snippets -I /home/phil/lilypond-git/input/regression/ -I /home/phil/lilypond-git/Documentation/included/ -I /home/phil/lilypond-git/build/mf/out/ -I /home/phil/lilypond-git/build/mf/out/ -I /home/phil/lilypond-git/Documentation/pictures -I /home/phil/lilypond-git/build/Documentation/pictures/./out-www --process='/home/phil/lilypond-git/build/out/bin/lilypond -I /home/phil/lilypond-git/input/regression/musicxml/ -I ./out-www -I /home/phil/lilypond-git/input -I /home/phil/lilypond-git/Documentation -I /home/phil/lilypond-git/Documentation/snippets -I /home/phil/lilypond-git/input/regression/ -I /home/phil/lilypond-git/Documentation/included/ -I /home/phil/lilypond-git/build/mf/out/ -I /home/phil/lilypond-git/build/mf/out/ -I /home/phil/lilypond-git/Documentation/pictures -I /home/phil/lilypond-git/build/Documentation/pictures/./out-www -dbackend=eps --formats=ps,png,pdf -dinclude-eps-fonts -dgs-load-fonts --header=doctitle --header=doctitlecs --header=doctitlede --header=doctitlees --header=doctitlefr --header=doctitlehu --header=doctitleit --header=doctitleja --header=doctitlenl --header=doctitlezh --header=texidoc --header=texidoccs --header=texidocde --header=texidoces --header=texidocfr --header=texidochu --header=texidocit --header=texidocja --header=texidocnl --header=texidoczh -dcheck-internal-types -ddump-signatures -danti-alias-factor=2' --output=./out-www --format=texi-html --verbose --lily-output-dir /home/phil/lilypond-git/build/out/lybook-db --load-custom-package=book-musicxml-testsuite.py out-www/collated-files.tely langdefs.py: warning: lilypond-doc gettext domain not found. Traceback (most recent call last): File /home/phil/lilypond-git/scripts/lilypond-book.py, line 693, in module main () File /home/phil/lilypond-git/scripts/lilypond-book.py, line 624, in main files = do_options () File /home/phil/lilypond-git/scripts/lilypond-book.py, line 610, in do_options print imp.load_source (book_custom_package%s % nr, i) In my previous succesful make, there was no --load-custom-package=book-musicxml-testsuite.py option. git grep -e 'load-custom-package' input/regression/musicxml/GNUmakefile:LILYPOND_BOOK_FLAGS += --load-custom-packa This line was added with the commit above. Could you have a look at this, please, Reinhold? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fwd: [Bug 503290] too thick barlines from GNU LilyPond PDF
Dear friends, I forward this from the poppler team. Amigos, os reenvío esto que me llega del equipo de Poppler. -- Mensaje reenviado -- De: evince bugzi...@gnome.org Fecha: 20/08/2011 12:22 Asunto: [Bug 503290] too thick barlines from GNU LilyPond PDF Para: francisco.v...@hispalinux.es https://bugzilla.gnome.org/show_bug.cgi?id=503290 evince | printing | 2.20.x Adrian Johnson ajohnson changed: What|Removed |Added CC||ajohn...@redneon.com --- Comment #9 from Adrian Johnson ajohn...@redneon.com 2011-08-20 10:22:19 UTC --- The problem has been fixed in poppler git. It was caused by stroking a zero width line. This is supposed to draw the thinnest line possible on the output device. As cairo does not support 0 width lines, poppler was setting the line width of a 0 width line to 1 unit. This is correct for the screen where 1 unit == 1 pixel is the thinnest line. But when printing 1 unit == 1/72 which is too thick. I'm not sure why LilyPond wants to fill a rectangle then stroke a 0 width line around it. The second step seems to be redundant. The PDF Reference says that 0 width lines should not be used because the result is device dependent. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug. -- Analizado antispam/virus. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make doc is broken
Le 20/08/2011 16:26, Phil Holmes disait : I think Reinhold's commit cfcb9efdbd7c6600fc89fc912ba80529010b31e7 has broken make doc. I've just done a clean build (fresh build directory) and get this at the end of a failed make doc: [...] I had made a fresh build and make doc before pushing, and have not encountered this... Let me try it again while translating on a local clone, and saving the logs just in case. Without a -j3, it will last about 90mn. Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make doc is broken
On Sat, Aug 20, 2011 at 03:26:48PM +0100, Phil Holmes wrote: File /home/phil/lilypond-git/scripts/lilypond-book.py, line 624, in main files = do_options () File /home/phil/lilypond-git/scripts/lilypond-book.py, line 610, in do_options print imp.load_source (book_custom_package%s % nr, i) I saw the same thing, but it went away when I did a complete rebuild from source. I think in this case lilypond-book is not being rebuilt when it should be, but I personally just deleted the build dir and rebuilt instead of investigating further. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make doc is broken
Hi Phil, Am Saturday, 20. August 2011, 16:26:48 schrieb Phil Holmes: I think Reinhold's commit cfcb9efdbd7c6600fc89fc912ba80529010b31e7 has broken make doc. I've just done a clean build (fresh build directory) and get this at the end of a failed make doc: [...] Traceback (most recent call last): File /home/phil/lilypond-git/scripts/lilypond-book.py, line 693, in module main () File /home/phil/lilypond-git/scripts/lilypond-book.py, line 624, in main files = do_options () File /home/phil/lilypond-git/scripts/lilypond-book.py, line 610, in do_options print imp.load_source (book_custom_package%s % nr, i) Do you also have any error message from python? This is just the traceback, i.e. it tells you where a problem appeared, but without the actual error message, it's really hard to tell what's wrong and how to fix it... In my previous succesful make, there was no --load-custom-package=book-musicxml-testsuite.py option. git grep -e 'load-custom-package' input/regression/musicxml/GNUmakefile:LILYPOND_BOOK_FLAGS += --load-custom-packa This line was added with the commit above. Could you have a look at this, please, Reinhold? Here it works just fine. [...] -danti-alias-factor=2' --output=./out-www --format=texi-html --lily-output- dir /home/reinhold/lilypond/lilypond/out/lybook-db --load-custom-package=book- musicxml-testsuite.py out-www/collated-files.tely langdefs.py: warning: lilypond-doc gettext domain not found. module 'book_custom_package1' from 'book-musicxml-testsuite.py' lilypond-book.py (GNU LilyPond) 2.15.9 Reading out-www/collated-files.tely... Dissecting... [...] Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Check for null pointer
On 2011-08-18, at 10:11 , Carl Sorensen wrote: On 8/17/11 10:41 PM, Dan Eble d...@faithful.be wrote: What I have so far is a backtrace: http://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00494.html and a large amount of input spread across many files, which is why I chose to review the lilypond source first. It may also be of interest that I am generating PartCombineMusic with scheme functions other than the stock part combiner. -- Two questions: 1) Is the segfault repeatable? After extensive testing, the answer is yes, but it's complicated. It is repeatable, but the result doesn't depend only on the input. When I build, I prefer to use a program called color that captures standard output and standard error and highlights the errors. Here's what happens. In the following list, X is a makefile target, and Y is the lilypond command line that make X runs. color make X - crash make X - OK time make X- OK color Y- OK Y - OK time Y - OK make X 2err.txt out.txt - OK 2) If so, can you test it on the latest development release? I tried Graham's experimental 2.15.9 (from last week) and it worked fine at first, but then I tried running it via gdb and it crashed with similar but not identical backtrace as 2.14.2. (The caller of kill_mmrest is Part_combine_iterator::process instead of Part_combine_iterator::unisono). -- Dan ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \once \revert
Carl Sorensen c_soren...@byu.edu writes: On 8/19/11 10:15 AM, David Kastrup d...@gnu.org wrote: Up to now, \once \revert is not really documented nor used. I have not yet dug through the existing code in order to figure out what it does if anything (most likely ignoring \once, but not sure). I would expect that \once \revert would revert an \override for the current time step only (meaning events whose start time is the current moment). For any events whose start time is other than the current moment, the \override would continue to apply. In order to not have the override/revert stack get into unexpected interactions, I want to change \once\override to be impervious to normal reverts. This seems to me to be a wise decision. \once \override is a statement that you are creating an override for everything happening at the current moment; reverts would not seem to apply. The main problem is that \once\override comes with its own implicit revert at the end of the time step, and when this implicit revert applies to a different \override, things get surprising. If this implicit revert is made special so that it will only ever apply to its corresponding \override, then having other \reverts match the \once\override will seem surprising. That would mean that \once\revert is an obvious candidate for reverting a \once\override before its time. However, I have no idea whether there is an actual sensible use for that functionality. I can see no sensible use for that functionality. You would have conflicting statements about what should happen at this time. Well, overrides are operating in a stack, so the last one wins. Not too difficult too understand. \once\revert could also mean to let a current non-once override become inactive just for the current time step. As I mentioned above, I think this is the logically consistent meaning. That's likely harder to implement, I think. You have *clearly* studied this and thought about it much more than I (and I'm grateful for your tackling this issue). I would think that a \once command would not need a stack. \once means create a new setting from the current setting, and apply it at this moment, but don't carry it forward. But again, you have much more basis for your observations than I have for mine. Don't carry it forward naively means reinstate the previous state, but that would cancel any other changes happening after the \once\whatever. This is what happens right now with \once\override, and it is confusing. So a cleaner interpretation is make things as if the \once\whatever never occured. However, the definition of \revert is make things as if the \override on top of the stack never occured. That would mean that \once\revert would have to disable the override, but let it keep its position on the stack. And temporarily disabling an override is an operation that requires its own implementation that is different from the other implemented operations. Basically, we need to store the \revert on the stack, when we only store instances of \override there usually. What happens if you do \once\revert \revert? Is the \override reverted by \once\revert now protected from the second \revert and resurfaces after our current time step? Is it affected by the non-\once revert? Is it invisible to it, so that the non-\once revert picks the next \override in the stack to revert? I don't think there is sufficient need for investing the effort of defining clear and consistent semantics for all that. I have no idea whether there is a sensible use, either, but it is logically consistent, IMO. It is also logically consistent to let the prefix \once make the following operation work on the set of \once overrides, as opposed to the set of not-\once overrides. And the sets differ by having the \once overrides be autocleared at the end of the timestep. Since the parser permits \once\revert, I tend towards making it match the last \once\override. It likely does not make much sense, but then it is sort of easy to understand. I lean to the opposite use, as I have described. Then you should make a convincing proposal for resolving the cases I described above. To me, \once \override x = #y \once \revert x should be an undefined state, since there are two conflicting commands. Why should the second one have preference over the first? Just because it comes later in the text stream? Yup. Because overrides and reverts work on a stack. I'd be fine with having the documentation say something like When two \once commands conflict, the resulting state is indeterminate. You should never have two \once commands at the same musical moment that affect the same property setting. We need a stack, anyway, so there is no point in treating \once commands different regarding the order relations. In fact, I think I would be in favor of removing \once \revert from the parser. The semantics of \once \revert can be
Re: Make doc is broken
Le 20/08/2011 17:26, Jean-Charles Malahieude disait : Le 20/08/2011 16:26, Phil Holmes disait : I think Reinhold's commit cfcb9efdbd7c6600fc89fc912ba80529010b31e7 has broken make doc. I've just done a clean build (fresh build directory) and get this at the end of a failed make doc: [...] I had made a fresh build and make doc before pushing, and have not encountered this... Let me try it again while translating on a local clone, and saving the logs just in case. Without a -j3, it will last about 90mn. Verdict: success Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Check for null pointer
Am Saturday, 20. August 2011, 19:29:38 schrieb Dan Eble: On 2011-08-18, at 10:11 , Carl Sorensen wrote: On 8/17/11 10:41 PM, Dan Eble d...@faithful.be wrote: What I have so far is a backtrace: http://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00494.html and a large amount of input spread across many files, which is why I chose to review the lilypond source first. It may also be of interest that I am generating PartCombineMusic with scheme functions other than the stock part combiner. -- Two questions: 1) Is the segfault repeatable? After extensive testing, the answer is yes, but it's complicated. It is repeatable, but the result doesn't depend only on the input. When I build, I prefer to use a program called color that captures standard output and standard error and highlights the errors. Here's what happens. In the following list, X is a makefile target, and Y is the lilypond command line that make X runs. color make X - crash make X - OK time make X- OK color Y- OK Y - OK time Y - OK make X 2err.txt out.txt - OK So, basically, you are saying that whenever you run make X through color, it will crash, but it will not crash in any other cases? Are you sure this is not a problem of color together with make (I had some strange problems that only occured when something was called by make, because the locale settings were messed up)? 2) If so, can you test it on the latest development release? I tried Graham's experimental 2.15.9 (from last week) and it worked fine at first, but then I tried running it via gdb and it crashed with similar but not identical backtrace as 2.14.2. (The caller of kill_mmrest is Part_combine_iterator::process instead of Part_combine_iterator::unisono). Hmm, do you have any example file where this appears (even if it's not minimal, for now it's just important that we can reproduce it somehow). Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Creates pure closures (issue 4894052)
On Aug 20, 2011, at 12:39 AM, n.putt...@gmail.com wrote: http://codereview.appspot.com/4894052/diff/9001/input/regression/pure-closure.ly File input/regression/pure-closure.ly (right): http://codereview.appspot.com/4894052/diff/9001/input/regression/pure-closure.ly#newcode18 input/regression/pure-closure.ly:18: #(ly:make-pure-closure ly:stem::height '(-3 . 10)) I'm a bit worried this is too close to an extra-spacing-height override to make a good test example. I'll try to think of something better...if you have any suggestions in the meantime, they're certainly welcome! http://codereview.appspot.com/4894052/diff/9001/lily/pure-closure.cc File lily/pure-closure.cc (right): http://codereview.appspot.com/4894052/diff/9001/lily/pure-closure.cc#newcode36 lily/pure-closure.cc:36: return (SCM) SCM_CELL_WORD_1 (smob); SCM_PACK (SCM_CELL_WORD_1 (smob)); (if you want to be strict :) I have no clue how these SCM functions work, but I'll take your word for it! http://codereview.appspot.com/4894052/diff/9001/lily/pure-closure.cc#newcode43 lily/pure-closure.cc:43: return (SCM) SCM_CELL_WORD_2 (smob); SCM_PACK (SCM_CELL_WORD_2 (smob)); Ditto. http://codereview.appspot.com/4894052/diff/9001/lily/pure-closure.cc#newcode60 lily/pure-closure.cc:60: SCM_NEWSMOB2 (z, pure_closure_tag, unpure, pure); SCM_UNPACK (unpure), SCM_UNPACK (pure) Done. http://codereview.appspot.com/4894052/diff/9001/lily/pure-closure.cc#newcode68 lily/pure-closure.cc:68: assert (is_pure_closure (pc)); optimized builds will segfault on invalid args, so you should use LY_ASSERT_TYPE () here Done. http://codereview.appspot.com/4894052/diff/9001/lily/pure-closure.cc#newcode76 lily/pure-closure.cc:76: assert (is_pure_closure (pc)); LY_ASSERT_TYPE () Done. http://codereview.appspot.com/4894052/diff/9001/scm/define-grobs.scm File scm/define-grobs.scm (left): http://codereview.appspot.com/4894052/diff/9001/scm/define-grobs.scm#oldcode2655 scm/define-grobs.scm:2655: (if (not (procedure? unpure)) I think you want this instead: (let ((pure (ly:pure-closure-pure-part unpure))) (if (not (procedure? pure)) pure (apply pure (append (list (car args) start end) (cdr args) I've added a hideous code dup to cover all cases. This will be attenuated and removed if I can find the time to move all of LilyPond's pure code over to unpure-pure-containers. New patchset up. Thanks Neil! Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
beamlets and tuplets
For several weeks now, I've been working in fits and starts, with lots of dead ends, on the oldest bug in the LilyPond issue tracker -- issue #11 Beamlet on wrong side of tuplet sixteenth. The good news is, I think I have a fix for that bug (and it's only 5 years old). But before I push a patch for review, I'd like to verify that the beamlet is in the right position on all of notes in the attached png. If you could review it and be sure that I've got it right, then I'll clean up the patch, run the files through fixcc.py, and post them for review. Thanks, Carl beamlet-test.png Description: beamlet-test.png ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Check for null pointer
On 2011-08-20, at 16:00 , Reinhold Kainhofer wrote: So, basically, you are saying that whenever you run make X through color, it will crash, but it will not crash in any other cases? Are you sure this is not a problem of color together with make (I had some strange problems that only occured when something was called by make, because the locale settings were messed up)? I've been using color with make for years without any problems (really that's the only thing I use it with!); however, I just recently started using OS X 10.7, so I wouldn't rule it out. On the other hand, I did observe a very similar crash running 2.15.9 in gdb without either of them. I tried Graham's experimental 2.15.9 (from last week) and it worked fine at first, but then I tried running it via gdb and it crashed with similar but not identical backtrace as 2.14.2. (The caller of kill_mmrest is Part_combine_iterator::process instead of Part_combine_iterator::unisono). Hmm, do you have any example file where this appears (even if it's not minimal, for now it's just important that we can reproduce it somehow). Be my guest. 1. extract http://faithful.be/sheet-music/dfe-books-20110820.tar.bz2 2. edit the top-level Makefile to set the LILYPOND variable 3. make PraiseAndPrayer PARTS=piano Once the output directories are created you should be able to run it again without make, if you want. (Running in gdb is when I see 2.15.9 crash.) The command would be lilypond -Iinclude -dno-point-and-click -e '(begin (primitive-load src/scm/part-analyzer.scm) (primitive-load src/scm/part-combiner.scm))' -Iinclude/part/piano -Isrc -o piano src/books/PraiseAndPrayer.ly Thanks for your help, -- Dan ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Improves horizontal spacing of axis groups that SpanBar grobs traverse. (issue 4917046)
Reviewers: , Message: Hey all, I've been thinking about Neil's comment regarding a better interface for cross-staff stems. While this patch has nothing to do with stems per se, it lays down the framework for dealing with cross-staff stems via a test-case with SpanBar grobs (which are like cross-staff stems insofar as they span between staves and take their alignment anchors from grobs with pure height approximations). In doing so, it fixes issue 910 (regest added to show this) and gets rid of an unreported but bad problem that SpanBar pure heights are either empty or not depending on the common refpoint being used. In theory, a pure height should return the same value for .length () every time. Cheers, MS Description: Improves horizontal spacing of axis groups that span bars traverse. Please review this at http://codereview.appspot.com/4917046/ Affected files: A input/regression/span-bar-allow-span-bar.ly M lily/align-interface.cc M lily/include/align-interface.hh A lily/pure-from-neighbor-engraver.cc A lily/pure-from-neighbor-interface.cc M lily/span-bar-engraver.cc A lily/span-bar-stub-engraver.cc M lily/span-bar.cc M ly/engraver-init.ly M scm/define-grob-properties.scm M scm/define-grobs.scm M scm/output-lib.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: beamlets and tuplets
Can you send a test case without dots (i.e. \times 4/5 { c8 [ c16 c8 c16 c8 c8
] } to see if that's changed in the new patch ?
Cheers,
MS
On Aug 20, 2011, at 10:47 PM, Carl Sorensen wrote:
For several weeks now, I've been working in fits and starts, with lots of
dead ends, on the oldest bug in the LilyPond issue tracker -- issue #11
Beamlet on wrong side of tuplet sixteenth.
The good news is, I think I have a fix for that bug (and it's only 5 years
old).
But before I push a patch for review, I'd like to verify that the beamlet is
in the right position on all of notes in the attached png.
If you could review it and be sure that I've got it right, then I'll clean
up the patch, run the files through fixcc.py, and post them for review.
Thanks,
Carl
beamlet-test.png___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make doc is broken
- Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes em...@philholmes.net Cc: Devel lilypond-devel@gnu.org Sent: Saturday, August 20, 2011 6:22 PM Subject: Re: Make doc is broken On Sat, Aug 20, 2011 at 03:26:48PM +0100, Phil Holmes wrote: File /home/phil/lilypond-git/scripts/lilypond-book.py, line 624, in main files = do_options () File /home/phil/lilypond-git/scripts/lilypond-book.py, line 610, in do_options print imp.load_source (book_custom_package%s % nr, i) I saw the same thing, but it went away when I did a complete rebuild from source. I think in this case lilypond-book is not being rebuilt when it should be, but I personally just deleted the build dir and rebuilt instead of investigating further. Cheers, - Graham This was a fresh build directory, with make/make doc. I'll try another - it might be a sequencing thing. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: beamlets and tuplets
It looks good.
Is this also working with complex cases such as { \times 4/5 { a8 a32 a8
a16. a8 a8 } } ?
I think (not sure) the beamlets should be: 32 to the right, 16. to the left.
Bertrand
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: beamlets and tuplets
The good news is, I think I have a fix for that bug (and it's only 5 years old). Great! But before I push a patch for review, I'd like to verify that the beamlet is in the right position on all of notes in the attached png. Making the beamlet always point to the dot looks OK. What about O. O O. O || || | -| | -| ++--++ Does this work correctly also? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
@example is discouraged in docs
Why is there an @example in the NR-3.2 titling change: 6810d727b278d15825eecb2b497d1a966241d4eb James spent a lot of work to allow us to easily create small, complete-page, @lilypond. In fact, this is done on line 617 of that same file! Please revert that doc change and put it on Rietveld for review. James spent a few weeks working on that section. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: oops! I've changed files in the `snippet' directory
On Fri, Aug 19, 2011 at 10:29:12AM +0200, Werner LEMBERG wrote: No, it is not safe. Your changes will be elminated the next time Neil (or Valentin, or anybody who cares about LSR) does a full import. Historically, this only happens every 3-4 months, but it should be happening much more often than that. What about the following: There are a lot of things that could be done to improve our development process. This is sadly not even in the top 20. (2) The next time makelsr gets called, start with the status at commit 12345678 as a base, *not* with HEAD. Doing so, later fixes to the snippets within lilypond's git repository are saved. ... can you do this automatically in a python script, assuming a complete ignorance of git from the script-runner? If so, then patches appreciated. I think it's overkill, though. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: not all doc clean-ups are good
On Fri, Aug 19, 2011 at 07:32:20AM +0200, Werner LEMBERG wrote: Please read: http://lilypond.org/doc/v2.15/Documentation/contributor/lilypond-formatting in particular the point about #. ... I interpret as being used for inline samples and the like. Ah, good point! I glanced at the subject line and didn't notice that you were only changing the text parts and not @lilypond parts. I withdraw this complaint. Please be more specific what I'm missing. In particular, many locations which I've fixed (at least in my opinion) were talking about, say, `#t' and `#foo' at the same time, which I consider *very* confusing. There are two possiblities to fix it: Either by saying `#t' and `foo', or by saying `##t' and `#foo'. Hmm. I still have no clue about the difference between #t and #foo, which certainly emphasizes that there *is* confusion. The decision to always prepend with a # for any lilypond input which accepts it (even if not strictly necessary) was made in GDP, but that only narrows it down to Sep 2007 - Aug 2008. I think it was in the first half, but that doesn't help much. :( I spent a few minutes looking through the email archives without finding the discussion, sorry. However, that discussion was specifically about @lilypond stuff, not the text. So I'm now ok with this change; thanks for explaining it to me. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: not all doc clean-ups are good
On 8/20/11 4:16 PM, Graham Percival gra...@percival-music.ca wrote: Hmm. I still have no clue about the difference between #t and #foo, which certainly emphasizes that there *is* confusion. #t is a Scheme value, as is foo ##t is a lilypond input value to get the scheme value #t #foo is a lilypond input value to get the scheme value foo. #t in lilypond gets the scheme value t, not the scheme value #t So we need either #foo and ##t or foo and #t. We should never mix those. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: not all doc clean-ups are good
On Fri, Aug 19, 2011 at 07:32:20AM +0200, Werner LEMBERG wrote: I'm also not convinced that the insert breakpoints after slashes is a great change. This makes the documentation source look really cludgy; is there no way that the breakpoints could be specified automatically? No, there isn't. Hmm. The next question would be how important is it to avoid (or permit? I've lost track of what we're doing here) line-breaks for slashes ? I'm not certain that it's worth fiddling with this. I mean, if I were writing any docs these days, I would not personally bother with the /@/ format. With that in mind, I can't find it in myself to reject other doc-patches for not using /@/. If that's the case, then is it really a step forward to half inconsistent doc source in this respect? That would confuse inexperienced (i.e. less than 2 years) doc editors. Actually, slashes should be completely avoided within normal prose, ... Maybe there is a native speaker who could remove many of the `/@/' stuff by reformulating the affected phrases if possible? Hmm. I agree for the more formal technical reference sections, but I would prefer to leave them in the chattier Learning manual. In my opinion, the primary goal is to produce excellent documentation in the *target output*, right? This means that the resulting PDF and HTML should be excellent, and we should do everything to reach this goal. To do so, I accept some cludginess in the documentation... I don't accept this as a general principle. What if we could produce excellent-looking documentation by moving to raw tex? Our pool of possible doc editors would instantly shrink by 90%; I do not think that is a good plan for long-term *maintained* documentation. I think it's already a bit too hard to get involved in doc work. I mean, just look at James! He's spent almost two years learning this stuff, but he still doesn't feel terribly confident. Yes, his background is windows rather than linux -- but approximately half of our new developers in the past 4 years come from that background. Our docs are stagnating badly. I've been hoping to have the Grand Documentation Project 2 in the near future, but at the moment it looks like it's a choice of GLISS vs. GDP 2. There's just too many emergencies that keep on cropping up. :( Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: not all doc clean-ups are good
On Sat, Aug 20, 2011 at 04:21:38PM -0600, Carl Sorensen wrote: On 8/20/11 4:16 PM, Graham Percival gra...@percival-music.ca wrote: Hmm. I still have no clue about the difference between #t and #foo, which certainly emphasizes that there *is* confusion. #t is a Scheme value, as is foo ##t is a lilypond input value to get the scheme value #t #foo is a lilypond input value to get the scheme value foo. #t in lilypond gets the scheme value t, not the scheme value #t So we need either #foo and ##t or foo and #t. We should never mix those. Don't tell me; tell the documentation. James is away. Colin, when you get back from your grandkids, do you want to look for any confusion in the docs about this? Or Trevor, are you interested in picking it up? (iirc Colin doesn't know much scheme) Or are there any other volunteers? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: beamlets and tuplets
On 8/20/11 3:40 PM, Werner LEMBERG w...@gnu.org wrote:
What about
O. O O. O
|| ||
| -| | -|
++--++
Does this work correctly also?
Yes. See attached PNG.
On 8/20/11 2:53 PM, Mike Solomon mike...@ufl.edu wrote:
Can you send a test case without dots (i.e. \times 4/5 { c8 [ c16 c8 c16 c8 c8
] } to see if that's changed in the new patch ?
I think it's correct. The flags point away from the normal beat and into
the syncopated beat. See the PNG.
On 8/20/11 3:23 PM, Bertrand Bordage bordage.bertr...@gmail.com wrote:
It looks good.
Is this also working with complex cases such as { \times 4/5 { a8 a32 a8 a16.
a8 a8 } } ?
I think (not sure) the beamlets should be: 32 to the right, 16. to the left.
I agree with you. I think it's right (but I'm not sure either). At any
rate, the current patch produces 32 to the right, 16. to the left. See the
PNG.
Having had this much confirmation, I'll go ahead and clean up my patch and
send it to Rietveld, where you all can test it out with as many difficult
beaming patterns as you want to throw at it.
Thanks for the pre-review,
Carl
beamlet-test-2.png
Description: beamlet-test-2.png
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix issue 11 -- beamlet points in wrong direction on tuplet (issue 4941041)
Reviewers: , Message: I believe that this fixes issue 11. Please review. Thanks, Carl Description: Fix issue 11 -- beamlet points in wrong direction on tuplet Please review this at http://codereview.appspot.com/4941041/ Affected files: A input/regression/beamlet-test.ly M lily/auto-beam-engraver.cc M lily/beam-engraver.cc M lily/beaming-pattern.cc M lily/include/beaming-pattern.hh ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: not all doc clean-ups are good
Graham Percival wrote Saturday, August 20, 2011 11:29 PM So we need either #foo and ##t or foo and #t. We should never mix those. Don't tell me; tell the documentation. It's already partially covered: http://www.lilypond.org/doc/v2.15/Documentation/learning/modifying-context-properties Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3846 - Release Date: 08/20/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \once \revert
On 8/19/11 2:57 PM, David Kastrup d...@gnu.org wrote: Carl Sorensen c_soren...@byu.edu writes: On 8/19/11 10:15 AM, David Kastrup d...@gnu.org wrote: Up to now, \once \revert is not really documented nor used. I have not yet dug through the existing code in order to figure out what it does if anything (most likely ignoring \once, but not sure). I would expect that \once \revert would revert an \override for the current time step only (meaning events whose start time is the current moment). For any events whose start time is other than the current moment, the \override would continue to apply. In order to not have the override/revert stack get into unexpected interactions, I want to change \once\override to be impervious to normal reverts. This seems to me to be a wise decision. \once \override is a statement that you are creating an override for everything happening at the current moment; reverts would not seem to apply. The main problem is that \once\override comes with its own implicit revert at the end of the time step, and when this implicit revert applies to a different \override, things get surprising. If this implicit revert is made special so that it will only ever apply to its corresponding \override, then having other \reverts match the \once\override will seem surprising. Let me see if I can state your concern with an example. \override x = 1 \once \override x = 2 \override x = 3 At the current time step, you want to have x = 3, because of the last-encountered override. Then at the next time step, you want to have x = 3, because of the last encountered override. But if the \once \override x = 2 is canceled by an implicit revert, there is the potential to have x = 1 at the next time step, which is a counterintuitive and therefore wrong result. I can see that this is not a desirable outcome. My thought for the architecture is to have two sets of properties -- the context set and the \once set. Let me explain my thought. Before any of these commands is issued, the context property set has x = 4. The \once set is empty, because there has been no \once issued at this time. when \override x = 1 is received, the context set gets an x=1 prepended (and put on the stack, I suppose -- I'm not sure exactly how this is implemented as a stack). When \once \override x=2 is received, the context set gets copied to the \once set, because we want to base the \once set on the current context set. Then x=2 is put on the \once set, but not on the context set. When \override x=3 is received, it's put on both the \once set and the context set. When it's time to get a property, since the \once set is not null, we get the value from the \once set. At the next time step, we set the \once set back to null, because there are no \once overrides. We don't need an implicit revert; we just forget the \once set. This comes at the price of carrying a second set of context properties when we have a \once. But that happens very rarely. So really, we have the cost of carrying an empty list around. Under this architecture, \once means if the \once set is empty, copy it from the current context properties \override means apply the override to the context set. If the \once set is not empty, also apply it to the \once set. \revert means apply the revert to the context set. If the \once set is not empty, also apply it to the \once set. With this architecture, I don't think there are any surprises. I have no idea whether there is a sensible use, either, but it is logically consistent, IMO. It is also logically consistent to let the prefix \once make the following operation work on the set of \once overrides, as opposed to the set of not-\once overrides. And the sets differ by having the \once overrides be autocleared at the end of the timestep. As described above, I'd have \once work on the \once overrides, but I'd have not-\once work on both sets. Thanks for listening. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES: 48-hour countdown
Graham Percival graham at percival-music.ca writes: I know there's a lot of big things in here to review, I should make it two issues fewer. These two were on the list finished Friday, I've just not been on linux to push. % (single patch does both issues) accidentaled notes too far from the barline http://code.google.com/p/lilypond/issues/detail?id=1779 Compressible space before the first note of a line ? http://code.google.com/p/lilypond/issues/detail?id=1785 http://codereview.appspot.com/4188051/ I'll remove the 'patch' label on the trackers (which I suppose I could have done Friday). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Check for null pointer
On 2011-08-20, at 16:00 , Reinhold Kainhofer wrote: So, basically, you are saying that whenever you run make X through color, it will crash, but it will not crash in any other cases? Are you sure this is not a problem of color together with make (I had some strange problems that only occured when something was called by make, because the locale settings were messed up)? I've been using color with make for years without any problems (really that's the only thing I use it with!); however, I just recently started using OS X 10.7, so I wouldn't rule it out. On the other hand, I did observe a very similar crash running 2.15.9 in gdb without either of them. I tried Graham's experimental 2.15.9 (from last week) and it worked fine at first, but then I tried running it via gdb and it crashed with similar but not identical backtrace as 2.14.2. (The caller of kill_mmrest is Part_combine_iterator::process instead of Part_combine_iterator::unisono). Hmm, do you have any example file where this appears (even if it's not minimal, for now it's just important that we can reproduce it somehow). I wonder if this has anything to do with it: http://article.gmane.org/gmane.comp.gnu.lilypond.bugs/27176 I discovered that using Ubuntu. I am not up to building on OS X to try to establish a connection with the crashes I observed, but it seems possible. -- Dan ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: oops! I've changed files in the `snippet' directory
(2) The next time makelsr gets called, start with the status at commit 12345678 as a base, *not* with HEAD. Doing so, later fixes to the snippets within lilypond's git repository are saved. can you do this automatically in a python script, assuming a complete ignorance of git from the script-runner? Will have a look. I think it's overkill, though. Is it? You want to silently override fixes to the better? BTW, what about using git tags to mark the commits used for global/local LSR imports? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: oops! I've changed files in the `snippet' directory
On Sun, Aug 21, 2011 at 06:55:02AM +0200, Werner LEMBERG wrote: I think it's overkill, though. Is it? You want to silently override fixes to the better? If somebody edits a file specifically marked %% DO NOT EDIT this file manually; it is automatically %% generated from LSR http://lsr.dsi.unimi.it ? BTW, what about using git tags to mark the commits used for global/local LSR imports? I think the commit message is enough for that? LSR: local import LSR: full import ? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: not all doc clean-ups are good
I'm also not convinced that the insert breakpoints after slashes is a great change. This makes the documentation source look really cludgy; is there no way that the breakpoints could be specified automatically? No, there isn't. Hmm. The next question would be how important is it to avoid (or permit? I've lost track of what we're doing here) line-breaks for slashes? I'm not certain that it's worth fiddling with this. Well, it helps in situations like this This is a paragraph with some text to demonstrate that a path name like /usr/local/share/lilypond/foo.bar should be split after backslashes. which looks better with a break after the backslash: This is a paragraph with some text to demonstrate that a path name like /usr/ local/share/lilypond/foo.bar should be split after backslashes. The much worse situation is this This is a paragraph with some text to demonstrate that a path name like /usr/local/share/lilypond/longfilename.itely should be split after backslashes. which gets improved to This is a paragraph with some text to demonstrate that a path name like /usr/ local/share/lilypond/longfilename.itely should be split after backslashes. I mean, if I were writing any docs these days, I would not personally bother with the /@/ format. Alas, most people don't care about formatting, and this can be seen in zillion badly aformatted documents in the internet. Is this desired? With that in mind, I can't find it in myself to reject other doc-patches for not using /@/. Of course not! It's an additional means to improve legibility in the PDF. Ragged-right documents don't really need this. If that's the case, then is it really a step forward to half inconsistent doc source in this respect? That would confuse inexperienced (i.e. less than 2 years) doc editors. Look, I'm walking over the docs to fix such instances. I haven't said that adding `@/' is a mandatory thing. If an inexperienced doc editor stumbles across `@/', she will look it up once, the she knows what it is good for. If she forgets to use it, it doesn't matter. Where's the problem? In my opinion, the primary goal is to produce excellent documentation in the *target output*, right? This means that the resulting PDF and HTML should be excellent, and we should do everything to reach this goal. To do so, I accept some cludginess in the documentation... I don't accept this as a general principle. What if we could produce excellent-looking documentation by moving to raw tex? This is a bad argument, and you know that :-) We want good HTML at the same time. I think it's already a bit too hard to get involved in doc work. I mean, just look at James! He's spent almost two years learning this stuff, but he still doesn't feel terribly confident. You are mixing apples and oranges. Most issues I see discussed here are related to producing good contents, and this is OK. My main concern with my recent patches is *not* contents but formatting. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: not all doc clean-ups are good
So we need either #foo and ##t or foo and #t. We should never mix those. Don't tell me; tell the documentation. It's already there. Or are there any other volunteers? Obviously, I volunteered to walk over all instances to clean this up... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \once \revert
Under this architecture, \once means if the \once set is empty, copy it from the current context properties \override means apply the override to the context set. If the \once set is not empty, also apply it to the \once set. \revert means apply the revert to the context set. If the \once set is not empty, also apply it to the \once set. With this architecture, I don't think there are any surprises. +1 As described above, I'd have \once work on the \once overrides, but I'd have not-\once work on both sets. +1 also. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: oops! I've changed files in the `snippet' directory
Is it? You want to silently override fixes to the better? If somebody edits a file specifically marked %% DO NOT EDIT this file manually; it is automatically %% generated from LSR http://lsr.dsi.unimi.it ? Hehe, you have a point. BTW, what about using git tags to mark the commits used for global/local LSR imports? I think the commit message is enough for that? LSR: local import LSR: full import ? Is the format of this commit message fixed? I'm asking because a script might search for it. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
