Re: potential soak-test / showcase
On Sun, Mar 11, 2012 at 12:23 AM, Adam Spiers wrote: > This would be fun to code ;-) > > http://lostinthecloudblog.com/2010/03/13/john-stump-composer-of-faeries-aire-and-death-waltz/ Looks familiar! I've seen pieces almost like that on http://www.apollinemike.com/mike/ :D I'm not sure about some parts of it, for example do we support beamed 65,536-ths? But it may be doable... cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
potential soak-test / showcase
This would be fun to code ;-) http://lostinthecloudblog.com/2010/03/13/john-stump-composer-of-faeries-aire-and-death-waltz/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Allow music in contextmods (issue 5796052)
David, i'm sorry because i cannot give your patch a proper review, but i appreciate your work. I think Lily really needs changes like this. thanks, Janek http://codereview.appspot.com/5796052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix make error in regression tests coming from midi2ly (issue 5777053)
Reviewers: dak, Message: On 2012/03/10 19:20:31, dak wrote: (I am surprised that your shell had a version of echo not understanding -n). I am, too. My bash shell has echo that understands -n, so I expected it to work. I'll see what I can figure out to make it work. Thanks, Carl Description: Fix make error in regression tests coming from midi2ly I have been unable to complete make test-baseline because of errors in the files coming from midi2ly.py. I tracked the error to make/midi-rules.make. The change in this patch allows me to successfully complete make test-baseline on my computer, running OSX 10.5.8, with GNU Make 3.81. Please review this at http://codereview.appspot.com/5777053/ Affected files: M make/midi-rules.make Index: make/midi-rules.make diff --git a/make/midi-rules.make b/make/midi-rules.make index 7b3f149d9643832dc72e02e23d6a27b286ddbc13..2a23d2cc14a5c0a79341ac2f5c1dd8dbe8ade696 100644 --- a/make/midi-rules.make +++ b/make/midi-rules.make @@ -9,7 +9,7 @@ $(outdir)/%.midi: %.ly $(LILYPOND_BINARY) cp $< $(outdir) $(outdir)/%-midi.ly: $(outdir)/%.midi $(MIDI2LY) - (echo '\header {'; for f in $(HEADER_FIELDS); do echo -n $$f'="'; cat $(outdir)/$*.$$f; echo '"'; done; echo '}') > $(outdir)/$*.header + (echo '\header {'; for f in $(HEADER_FIELDS); do echo $$f'="'; cat $(outdir)/$*.$$f; echo '"'; done; echo '}') > $(outdir)/$*.header $(PYTHON) $(MIDI2LY) $(shell cat $(outdir)/$*.options) --include-header=$(outdir)/$*.header -o $(outdir) $< $(outdir)/%.diff: %.ly $(outdir)/%-midi.ly ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Patchy is trying to merge staging now
Patchy is re-running now. I lost internet connection so it missed the 6pm merge. -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix make error in regression tests coming from midi2ly (issue 5777053)
http://codereview.appspot.com/5777053/diff/1/make/midi-rules.make File make/midi-rules.make (right): http://codereview.appspot.com/5777053/diff/1/make/midi-rules.make#newcode12 make/midi-rules.make:12: (echo '\header {'; for f in $(HEADER_FIELDS); do echo $$f'="'; cat $(outdir)/$*.$$f; echo '"'; done; echo '}') > $(outdir)/$*.header This won't do since it starts generated header strings with a newline that does not belong there (I am surprised that your shell had a version of echo not understanding -n). You can try ... echo $$f'="'"`cat $(outdir)/$*.$$f`"'"'; done ... That is a bit of quoting overkill. It will probably do to write ... echo $$f="\"`cat $(outdir)/$*.$$f`\""; done http://codereview.appspot.com/5777053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
gub help
I am a developer for denemo. I have been struggle to get gub to work for me. I had to edited several of the spec files because the originals referenced packages that were no longer available or had incorrect permissions on the server. I don't know what I should do. Is there a specific git revision number I should use to build denemo with gub? If I were to get everything to compile should I submit patches to the mailing list? Should I mirror the packages so others can build it with the same packages incase of missing packages? At the moment I am stuck on ghostscript. It complains that there are duplicate files. Please advise. I have never been able to get this to work. Jeremiah Sent from my Samsung smartphone on AT&T ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Difference between list and cons*
David Kastrup writes: > Carl Sorensen writes: > >> David, >> >> I noticed that in a recent patch you changed from constructing property >> lists with list to using cons*. >> >> I'm not questioning your decision. However, I'd like to gain some >> understanding. Why was it necessary (or at least desirable) to make the >> change? As far as I understand, the difference between list and cons* is >> that list puts '() at the tail of the list, while cons* puts the last >> argument at the tail of the list. > > And that's exactly what this change was about. In this particular case, > I had constructed a list where the last element was property-path (or > something like it). But the actual form of the entry used elsewhere was > such that the _tail_ of the list represented property-path, not the last > element. While I was trying out something else, some parts of LilyPond > (I think the documentation formatter) blew up around me because I had > missed that difference. > >> Any light you could shed on this would be helpful to me. > > Does the above help? Just reread this, and noticed you were talking about "property lists" here. There are no property lists here. Context mods have a structure that starts with a key symbol in the car, and the data following afterwards. If you take a look at where they get interpreted, you'll see in context-property.cc stuff like if (type == ly_symbol2scm ("push")) { SCM val = scm_cadr (entry); SCM grob_prop_path = scm_cddr (entry); sloppy_general_pushpop_property (tg, context_prop, grob_prop_path, val); } Now you see that we are referencing scm_cadr (entry) and scm_cddr (entry) here for value and property-path, respectively. If property-path were the last _element_ of the list, it would be at scm_caddr (entry), with scm_cdddr (entry) being '(). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Difference between list and cons*
Carl Sorensen writes: > David, > > I noticed that in a recent patch you changed from constructing property > lists with list to using cons*. > > I'm not questioning your decision. However, I'd like to gain some > understanding. Why was it necessary (or at least desirable) to make the > change? As far as I understand, the difference between list and cons* is > that list puts '() at the tail of the list, while cons* puts the last > argument at the tail of the list. And that's exactly what this change was about. In this particular case, I had constructed a list where the last element was property-path (or something like it). But the actual form of the entry used elsewhere was such that the _tail_ of the list represented property-path, not the last element. While I was trying out something else, some parts of LilyPond (I think the documentation formatter) blew up around me because I had missed that difference. > Any light you could shed on this would be helpful to me. Does the above help? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Difference between list and cons*
David, I noticed that in a recent patch you changed from constructing property lists with list to using cons*. I'm not questioning your decision. However, I'd like to gain some understanding. Why was it necessary (or at least desirable) to make the change? As far as I understand, the difference between list and cons* is that list puts '() at the tail of the list, while cons* puts the last argument at the tail of the list. Any light you could shed on this would be helpful to me. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Learning: Use voices in the intended order. (issue 5507050)
The second part of this patch has now been pushed to staging, so (assuming they make it to master) this issue can be closed. http://codereview.appspot.com/5507050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes to auxiliar/doc-section.sh
Hi Phil, you wrote Saturday, March 10, 2012 10:16 AM Once you have a successful make doc, you might be surprised how little time it takes to remake to check changes now. On my admittedly quick machine, make -j9 CPU_COUNT=9 LANGS='' doc takes about 5 seconds. It's certainly a lot better than it was and it would be usable even on my laptop running Ubuntu in 800Mb and 1 processor under VirtualBox. I find make LANGS='' doc takes 4-5 minutes after a trivial change to a single file, which I agree is quite workable now. With the same change the script takes around 2 minutes, but in addition checks all the cross-references and opens up the section's html in a browser automatically. Also there is an option to retain all the snippets between invocations, which reduces the time to less than 30 seconds - very useful if you know the changes are all in straight text. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Learning: Use voices in the intended order. (issue 5507050)
I could see no reason for this patch causing problems with make or make doc - both ran clean here. So I split this into the two unrelated patches to Learning and Notation, corrected the patch to Learning and pushed to staging. I'll check the patch to Notation next. http://codereview.appspot.com/5507050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ice-9/psyntax.scm:1417:32: Syntax error:
David: > k...@aspodata.se (Karl Hammar) writes: > > Do anyone have a clue what to do about this error: ... > > $ ./autogen.sh > http://turkos.aspodata.se/tmp/log.autogen.sh ... > Guilev2 is not supported yet. What does autoconf tell? $ grep -iC2 guile log.autogen.sh checking for working metafont mode... ljfour checking for kpsewhich... kpsewhich checking for guile-config... guile-config checking guile-config version... 2.0.5 checking guile compile flags... -pthread -I/usr/include/guile/2.0 checking guile link flags... -lguile-2.0 -lgc checking libguile.h usability... yes checking libguile.h presence... yes checking for libguile.h... yes checking for scm_boot_guile in -lguile... no checking for scm_boot_guile... yes checking for scm_t_hash_fold_fn... yes checking for scm_t_hash_handle_fn... yes checking for scm_t_subr... yes checking for usable C++ demangler... yes checking GUILE rational bugfix... ok checking for python-config... python-config checking Python.h usability... yes -- checking for -windres... no checking for windres... no checking for guile... guile checking for guile... /usr/bin/guile checking for perl... perl checking for perl... /usr/local/bin/perl $ Ok, I'll try to downgrade guile then, thanks. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ice-9/psyntax.scm:1417:32: Syntax error:
k...@aspodata.se (Karl Hammar) writes: > Do anyone have a clue what to do about this error: > > $ git describe > release/2.15.33-1-4-gb04051d > $ ./autogen.sh > http://turkos.aspodata.se/tmp/log.autogen.sh > $ make all > http://turkos.aspodata.se/tmp/log.make 2>&1 > $ tail log.make > ;;; compiling > /var/home/karl/Net/git/lilypond/out/share/lilypond/current/scm/part-combiner.scm > ;;; WARNING: compilation of > /var/home/karl/Net/git/lilypond/out/share/lilypond/current/scm/part-combiner.scm > failed: > ;;; ERROR: Syntax error: > ;;; unknown location: source expression failed to match any pattern in form > when > ice-9/psyntax.scm:1417:32: In procedure expand-macro: > ice-9/psyntax.scm:1417:32: Syntax error: > unknown location: source expression failed to match any pattern in form when > make[1]: *** [out/internals.texi] Error 1 > make[1]: Leaving directory `/var/home/karl/Net/git/lilypond/Documentation' > make: *** [all] Error 2 > $ Guilev2 is not supported yet. What does autoconf tell? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
ice-9/psyntax.scm:1417:32: Syntax error:
Do anyone have a clue what to do about this error: $ git describe release/2.15.33-1-4-gb04051d $ ./autogen.sh > http://turkos.aspodata.se/tmp/log.autogen.sh $ make all > http://turkos.aspodata.se/tmp/log.make 2>&1 $ tail log.make ;;; compiling /var/home/karl/Net/git/lilypond/out/share/lilypond/current/scm/part-combiner.scm ;;; WARNING: compilation of /var/home/karl/Net/git/lilypond/out/share/lilypond/current/scm/part-combiner.scm failed: ;;; ERROR: Syntax error: ;;; unknown location: source expression failed to match any pattern in form when ice-9/psyntax.scm:1417:32: In procedure expand-macro: ice-9/psyntax.scm:1417:32: Syntax error: unknown location: source expression failed to match any pattern in form when make[1]: *** [out/internals.texi] Error 1 make[1]: Leaving directory `/var/home/karl/Net/git/lilypond/Documentation' make: *** [all] Error 2 $ Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes to auxiliar/doc-section.sh
- Original Message - From: "Trevor Daniels" To: "Lily-Devel List" Sent: Friday, March 09, 2012 11:06 PM Subject: Fixes to auxiliar/doc-section.sh I've just pushed some fixes to auxiliar/doc-section.sh to staging, as several things seemed to have gone wrong with it since I last used it. The script is intended to be used for quickly checking changes made to the English docs. It compiles a section of the docs to html in a minute or so and displays that section in a browser. Far better than waiting an hour or so (that's how long it seems to take on my laptop) for make doc to finish, if all you want to do is check that the texinfo and the cross-refs are valid. It now works fine on my laptop under Ubuntu. I'd be grateful if one or two of the doc editors could check it out too, once it moves into master. Thanks. Trevor Once you have a successful make doc, you might be surprised how little time it takes to remake to check changes now. On my admittedly quick machine, make -j9 CPU_COUNT=9 LANGS='' doc takes about 5 seconds. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel