Re: Handling of open strings in tablature (issue 5695058)
Am 26.02.2012 07:07, schrieb julien.ri...@gmail.com: 1 line adds whitespace errors. That's all. Regards, Julien http://codereview.appspot.com/5695058/diff/6001/input/regression/tablature-open-string-handling.ly File input/regression/tablature-open-string-handling.ly (right): http://codereview.appspot.com/5695058/diff/6001/input/regression/tablature-open-string-handling.ly#newcode19 input/regression/tablature-open-string-handling.ly:19: git complains about a new blank line at EOF here. Ok, corrected. Sorry. http://codereview.appspot.com/5695058/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Handling of open strings in tablature (issue 5695058)
julien.ri...@gmail.com writes: > 1 line adds whitespace errors. That's all. > Regards, > Julien The scripts lilypond-extra/patches/accept-patch.py and lilypond-extra/patches/reject-patch.py are known to you? They take an issue number and a text as argument. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Handling of open strings in tablature (issue 5695058)
1 line adds whitespace errors. That's all. Regards, Julien http://codereview.appspot.com/5695058/diff/6001/input/regression/tablature-open-string-handling.ly File input/regression/tablature-open-string-handling.ly (right): http://codereview.appspot.com/5695058/diff/6001/input/regression/tablature-open-string-handling.ly#newcode19 input/regression/tablature-open-string-handling.ly:19: git complains about a new blank line at EOF here. http://codereview.appspot.com/5695058/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cross-staff stem engraver (was: New frog in an empty pond?)
Quoting Joe Neeman :
The problem is where you ask for the stem Y-extent relative to yref (the
VerticalAlignment): in order to calculate the vertical distance between the
various staves and the VerticalAlignment, line breaking needs to be done
first. (And line breaking doesn't happen until after all the engravers are
done.)
I see. It means that using an engraver it not a solution per se.
Good to know.
I guess I'll need to redefine the stencil for stems. Or maybe you mean
some other callback?
You could redefine stencil, but I think redefining length would be easier.
Of course, that's why I tried it first :)
Can you be more specific about the Y-extent not being calculated yet? When
you ask for the Y-extent, the calculation should be triggered if it hasn't
already happened.
Now I understand what's going on! Apparently this triggering is not
transitive (which is reasonable). I'm attaching the minimal example
when I get
grob Y-extent: (+inf.0 . -inf.0)
I think it should be possible to work around. I'll be perfectly fine
if my code doesn't work with chords spanning three and more staves if
that limitation needs to exist.
As a general approach, setting length sounds like a reasonable way forward.
In addition, I'd suggest creating a new stem in process-acknowledged, then
doing
(set! (ly:grob-object new-stem 'spanned-stems) old-stems)
(set! (ly:grob-property new-stem 'length) your-length-callback)
In your length callback, you read back the spanned-stems object and do your
calculations. Is this similar to what you tried?
I never used an engraver and the length override at the save time.
When doing the length override, I tried this approach:
- find PaperColumn among the grob parents
- scan its elements for stems
- use stems extents to find stems connectable to the given stem
- find the closest stem
- use the length that would extend the given stem to the closest stem
It actually worked, except some corner cases. Now I understand why.
Using an engraver to catch the stems sounds like a good approach. I
could even do some filtering in the engraver. And it should be
possible to replace stems with one rather than connect them together.
It would simplify SVG output, and I suspect the connect point could be
seen in some renderings of the postscript output.
Thank you for your help! I'm getting really close!
--
Regards,
Pavel Roskin
\version "2.14.2"
#(define (grobParentByInterface grob intf axis)
(if (memq intf (ly:grob-interfaces grob))
grob
(grobParentByInterface (ly:grob-parent grob axis) intf axis)))
#(define (crossStaffLength grob)
(let* ((papercolumn (grobParentByInterface grob 'paper-column-interface X))
(elementarray (ly:grob-object papercolumn 'elements))
(elements (ly:grob-array->list elementarray)))
(map (lambda (x)
(ly:grob-extent x x Y)) elements)
(ly:message "grob Y-extent: ~a" (ly:grob-extent grob grob Y))
3))
\score {
\new StaffGroup <<
\new Staff = "staffone" <<
\new Voice {
c'
}
>>
\new Staff = "stafftwo" <<
\new Voice {
\clef bass
\override Stem #'cross-staff = ##t
\override Stem #'length = #crossStaffLength
c
}
>>
\new Staff = "staffthree" <<
\new Voice {
\override Stem #'cross-staff = ##t
\override Stem #'length = #crossStaffLength
\clef bass
g,
}
>>
>>
\layout { }
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Re: New frog in an empty pond?
On 12-02-25 03:32 AM, Phil Holmes wrote: - Original Message - From: "Janek Warchoł" Fortunately it's mostly me whom i'm doing this for :) (is the above proper English, anyway?) cheers, Janek "Fortunately, I'm mostly doing this for me." would be fair idiomatic English. Some people would say "myself" rather than "me". -- Phil Holmes "It is I for whom I do this" grumps a fusty old prescriptivist in the corner. Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Simplify font building. (issue 5695061)
On Sat, Feb 25, 2012 at 02:06:46PM -0800, Joe Neeman wrote: >On Sat, Feb 25, 2012 at 8:23 AM, Graham Percival ><[1]gra...@percival-music.ca> wrote: > > No, and adding this to GUB will be particularly challenging. I'm > afraid that this will probably postpone the patch indefinitely. > :( > >Why would it be particularly challenging? Whenever anybody tries to run GUB, there's a 1-20 hour setup time while they run into various bugs. A few people have tried it; sometimes it "just works", other times it doesn't. For reference, Carl currently cannot build GUB, which is a shame since otherwise he would be a candidate to work on the osx stuff (the only current Critical bug which does not have a patch). Once somebody has GUB running, and has a reasonable amount of familiarity with python, compiling software, packaging, and old python versions (GUB uses 2.4.5 IIRC), it would probably only be about 30 minutes to get it working. The problem is just getting to that stage. > In fact, since GUB builds >fontforge, the python bindings may already be included (I'm attempting >to check this now). ah, that would be nice. We would still need to update lilydev, but that is not too hard. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Simplify font building. (issue 5695061)
On Sat, Feb 25, 2012 at 8:23 AM, Graham Percival wrote: > On Sat, Feb 25, 2012 at 03:57:55PM +, julien.ri...@gmail.com wrote: > > This is good, I now get the error message right away when running > > configure. No problem with the patch after installing the required > > package. Do lilydev and gub already include the fontforge python > > package? > > No, and adding this to GUB will be particularly challenging. I'm > afraid that this will probably postpone the patch indefinitely. > :( > Why would it be particularly challenging? In fact, since GUB builds fontforge, the python bindings may already be included (I'm attempting to check this now). It's just that debian-like distros feel the need to separate each package into 5 pieces... Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB build problems
OK, so I decided to try to start from scratch in building GUB. I created a new virtual machine. Loaded it with lily-dev 1.1, from http://www.et.byu.edu/~sorensen/ubuntu-lilydev-remix-1.1.iso Installed guest additions Installed libmpfr-dev, with sudo apt-get libmpfr-dev Got GUB with git clone http://github.com/gperciva/gub Tried to build gub with cd gub make bootstrap Build failed with http://www.et.byu.edu/~sorensen/ubuntu-lilydev-remix-1.1.iso building package: darwin-ppc::cross/gcc *** Stage: download (cross/gcc, darwin-ppc) *** Stage: compile (cross/gcc, darwin-ppc) *** buffer overflow detected ***: /home/carl/gub/target/darwin-ppc/root/usr/cross/bin/powerpc-apple-darwin7-r anlib terminated === Backtrace: = /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x50)[0x40111390] /lib/tls/i686/cmov/libc.so.6(+0xe12ca)[0x401102ca] /lib/tls/i686/cmov/libc.so.6(+0xe0a08)[0x4010fa08] /lib/tls/i686/cmov/libc.so.6(_IO_default_xsputn+0x9e)[0x40098afe] /lib/tls/i686/cmov/libc.so.6(_IO_padn+0xd8)[0x4008c5f8] /lib/tls/i686/cmov/libc.so.6(_IO_vfprintf+0xfe7)[0x4006cbf7] /lib/tls/i686/cmov/libc.so.6(__vsprintf_chk+0xad)[0x4010fabd] /lib/tls/i686/cmov/libc.so.6(__sprintf_chk+0x2d)[0x4010f9fd] /home/carl/gub/target/darwin-ppc/root/usr/cross/bin/powerpc-apple-darwin7-r anlib[0x804b3cc] /home/carl/gub/target/darwin-ppc/root/usr/cross/bin/powerpc-apple-darwin7-r anlib[0x804c4cd] /home/carl/gub/target/darwin-ppc/root/usr/cross/bin/powerpc-apple-darwin7-r anlib[0x804cb8f] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0x40045bd6] /home/carl/gub/target/darwin-ppc/root/usr/cross/bin/powerpc-apple-darwin7-r anlib[0x8048e31] === Memory map: 08048000-0806c000 r-xp 08:01 941414 /home/carl/gub/target/darwin-ppc/root/usr/cross/bin/powerpc-apple-darwin7-r anlib 0806c000-0806d000 r--p 00023000 08:01 941414 /home/carl/gub/target/darwin-ppc/root/usr/cross/bin/powerpc-apple-darwin7-r anlib 0806d000-0806e000 rw-p 00024000 08:01 941414 /home/carl/gub/target/darwin-ppc/root/usr/cross/bin/powerpc-apple-darwin7-r anlib 0849f000-084c rw-p 00:00 0 [heap] 4000-4001b000 r-xp 08:01 918447 /lib/ld-2.11.1.so 4001b000-4001c000 r--p 0001a000 08:01 918447 /lib/ld-2.11.1.so 4001c000-4001d000 rw-p 0001b000 08:01 918447 /lib/ld-2.11.1.so 4001d000-4001e000 r-xp 00:00 0 [vdso] 4001e000-4002 rw-p 00:00 0 4002f000-40182000 r-xp 08:01 2922 /lib/tls/i686/cmov/libc-2.11.1.so 40182000-40183000 ---p 00153000 08:01 2922 /lib/tls/i686/cmov/libc-2.11.1.so 40183000-40185000 r--p 00153000 08:01 2922 /lib/tls/i686/cmov/libc-2.11.1.so 40185000-40186000 rw-p 00155000 08:01 2922 /lib/tls/i686/cmov/libc-2.11.1.so 40186000-4018a000 rw-p 00:00 0 4018a000-401a7000 rw-p 08:01 279154 /home/carl/gub/target/darwin-ppc/build/cross/gcc-4.1.1/gcc/libgcc_eh.a (deleted) 401a7000-401c4000 r-xp 08:01 918506 /lib/libgcc_s.so.1 401c4000-401c5000 r--p 0001c000 08:01 918506 /lib/libgcc_s.so.1 401c5000-401c6000 rw-p 0001d000 08:01 918506 /lib/libgcc_s.so.1 bfb6f000-bfb87000 rw-p 00:00 0 [stack] Command barfed: cd /home/carl/gub/target/darwin-ppc/build/cross/gcc-4.1.1 && make -j2 tooldir='/home/carl/gub/target/darwin-ppc/root/usr/cross/powerpc-apple-darw in7' gcc_tooldir='/usr/powerpc-apple-darwin7' Tail of target/darwin-ppc/log/cross/gcc.log make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/carl/gub/target/darwin-ppc/build/cross/gcc-4.1.1' make: *** [all] Error 2 Command barfed: cd /home/carl/gub/target/darwin-ppc/build/cross/gcc-4.1.1 && make -j2 tooldir='/home/carl/gub/target/darwin-ppc/root/usr/cross/powerpc-apple-darw in7' gcc_tooldir='/usr/powerpc-apple-darwin7' Tail of target/darwin-ppc/log/cross/gcc.log *** Failed target: darwin-ppc::cross/gcc Looking at the failed command, it appears to me that gcc_tooldir is wrong. There is no directory /usr/powerpc-apple-darwin7 And there shouldn't be one, IMO, since this is neither a powerpc machine nor an osx installation. It seems that gcc_tooldir should either be the same as tooldir, or gcc_tooldir should reflect the current gcc that is being used. Does anybody have any insight on this? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG: add information about Regtest Checking Project (issue 5669047)
On Sat, Feb 25, 2012 at 10:55 PM, Graham Percival wrote: > Up to you. The fancier you make the formatting, the harder it is > to maintain. You should also check how it looks in info. If you > want to play games with that, go ahead -- as I said, we don't > forbid @...named. But I personally would just use the standard > @rglos and accept whatever that produces. Done. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cross-staff stem engraver (was: New frog in an empty pond?)
On Sat, Feb 25, 2012 at 5:49 AM, Pavel Roskin wrote: > Quoting Joe Neeman : > > On Fri, Feb 24, 2012 at 3:04 PM, Pavel Roskin wrote: >> >>> I tried writing an engraver that could be added to the StaffGroup >>> context. Collecting stems is not a problem. The problem is that even >>> the finalize handler is called to early. I'm getting a warning: >>> >>> programming error: vertical alignment called before line breaking >>> continuing, cross fingers >>> >>> >> It's a little hard to guess what's going wrong without knowing exactly >> what >> you've tried. Are you trying to do layout logic in the engraver (ie. by >> collecting stems, reading their properties, doing calculations and then >> setting more properties)? >> > > Yes, except that I'm not setting anything yet. The current file is > attached. The problem is where you ask for the stem Y-extent relative to yref (the VerticalAlignment): in order to calculate the vertical distance between the various staves and the VerticalAlignment, line breaking needs to be done first. (And line breaking doesn't happen until after all the engravers are done.) > If you are, the first step is to move the layout >> logic into grob callbacks. >> > > I guess I'll need to redefine the stencil for stems. Or maybe you mean > some other callback? > You could redefine stencil, but I think redefining length would be easier. I did a similar thing before. I put all the logic into a function that was > used to redefine the length property of the stem. It worked for a simple > case of two stems, but failed when three stems needed to be connected. The > Y-extent for at least one of the stems wasn't calculated yet. > Can you be more specific about the Y-extent not being calculated yet? When you ask for the Y-extent, the calculation should be triggered if it hasn't already happened. As a general approach, setting length sounds like a reasonable way forward. In addition, I'd suggest creating a new stem in process-acknowledged, then doing (set! (ly:grob-object new-stem 'spanned-stems) old-stems) (set! (ly:grob-property new-stem 'length) your-length-callback) In your length callback, you read back the spanned-stems object and do your calculations. Is this similar to what you tried? Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG: add information about Regtest Checking Project (issue 5669047)
On Sat, Feb 25, 2012 at 09:51:31PM +, janek.lilyp...@gmail.com wrote: > I decided not to use @rglos and @rinternals (because from what i > understand it would print the name of the section i'm referring to) but > use @rglosnamed and @rinternalsnamed instead. I discourage (but not forbid) the use of @...named; I think we should just use @rglos and let texinfo figure out what to print. That's what we do elsewhere, so it's good enough. > This worked nice in html > manual, but in pdf i got: > "...explained in our Section “Music Glossary” in Music Glossary > Chapter 9: Regression tests 98 > or Section “Internals Reference” in Internals Reference." > Not perfect... shall i use regular references or don't worry about this? *shrug* Up to you. The fancier you make the formatting, the harder it is to maintain. You should also check how it looks in info. If you want to play games with that, go ahead -- as I said, we don't forbid @...named. But I personally would just use the standard @rglos and accept whatever that produces. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG: add information about Regtest Checking Project (issue 5669047)
New patch set uploaded, it should make doc now. Thanks for the tips, Carl and Graham! You saved me some time. I decided not to use @rglos and @rinternals (because from what i understand it would print the name of the section i'm referring to) but use @rglosnamed and @rinternalsnamed instead. This worked nice in html manual, but in pdf i got: "...explained in our Section “Music Glossary” in Music Glossary Chapter 9: Regression tests 98 or Section “Internals Reference” in Internals Reference." Not perfect... shall i use regular references or don't worry about this? http://codereview.appspot.com/5669047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Output from midi2ly
Midi2ly, as used in the make doc build system, puts 2 types of message on the terminal: "LY output to (filename)" and "Warning, more than 5 voices found. Expect bad output". Seems to me we could: 1) Get rid of the first message completely by deleting the print line. We then have the problem of what to do with the warning. 2) Use run-and-check to push both to logfiles 3) Add an option to midi2ly to suppress output and warnings and use this in the build. 2 is easiest, but adds yet more logfiles and loses a potentially useful warning. Any thoughts? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: More reductions in make doc (issue 5694079)
On Sat, Feb 25, 2012 at 04:58:59PM +, philehol...@googlemail.com wrote: > Pushes the output from making midi .ly files and ly-examples to logfiles > - slightly more controversial - uses the run-and-check shell script to > do this. What's supposed to be controversial here? Seems like an obviously good 'next step'. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Simplify font building. (issue 5695061)
On Sat, Feb 25, 2012 at 04:50:21PM +, Carl Sorensen wrote: > On 2/25/12 9:23 AM, "Graham Percival" wrote: > > >No, and adding this to GUB will be particularly challenging. I'm > >afraid that this will probably postpone the patch indefinitely. > >:( > > Can't we add that package as a requirement for GUB (kind of like we have > done with libmpfr-dev)? And we can add it to lilydev. Hmm, I hadn't thought of that... but I don't like the idea. Any use of stuff from the host system adds variables to the process; we already have too much randomness in terms of being able to compile GUB on some computers but not others. GUB really shouldn't use libmpfr-dev at all, nor fonts from the host system, etc. In fact, after it finishes make bootstrap, it should remove any host system directories from the PATH, and/or use a chroot to avoid picking up host-system stuff. If we did that -- after fixing bugs in the process, of course -- then we could actually have a reliable GUB provided that it completed make bootstrap. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
More reductions in make doc (issue 5694079)
Reviewers: Graham Percival, Julien Rioux, Message: Further update for review Description: More reductions in make doc Pushes the output from making midi .ly files and ly-examples to logfiles - slightly more controversial - uses the run-and-check shell script to do this. However, I think we need something of this sort on these direct invocations of lilypond, and can't see a better way of doing it, given we already use that script elsewhere. It does fail "properly" on bad input, pointing the user to the correct logfile. Please review this at http://codereview.appspot.com/5694079/ Affected files: M Documentation/ly-examples/GNUmakefile M make/midi-rules.make Index: Documentation/ly-examples/GNUmakefile diff --git a/Documentation/ly-examples/GNUmakefile b/Documentation/ly-examples/GNUmakefile index a3ee42280b15fad5e45fbb3d65ae391c2c71513b..b4e4d2c0be13cbeceddfac602103a0fb93e0341a 100644 --- a/Documentation/ly-examples/GNUmakefile +++ b/Documentation/ly-examples/GNUmakefile @@ -14,7 +14,7 @@ all: $(OUT_PNG_FILES) $(OUT_SMALL_PNG_FILES) endif $(outdir)/%.png: %.ly - $(LILYPOND_PREVIEW) -o $(outdir) $< + $(buildscript-dir)/run-and-check "$(LILYPOND_PREVIEW) -o $(outdir) $<" "$*.preview.log" mv $(outdir)/$*.preview.png $@ $(outdir)/%-small.png: $(outdir)/%.png Index: make/midi-rules.make diff --git a/make/midi-rules.make b/make/midi-rules.make index a5cee58b96a226dd70e3eb9b13bdfae9895bac4e..7b3f149d9643832dc72e02e23d6a27b286ddbc13 100644 --- a/make/midi-rules.make +++ b/make/midi-rules.make @@ -5,7 +5,7 @@ $(outdir)/%.ly: %.midi $(outdir)/%.midi: %.ly $(LILYPOND_BINARY) touch $(foreach f, $(HEADER_FIELDS), $(outdir)/$*.$f) - $(LILYPOND_BINARY) $(HEADER_FIELDS:%=-H %) -o $(outdir) $< + $(buildscript-dir)/run-and-check "$(LILYPOND_BINARY) $(HEADER_FIELDS:%=-H %) -o $(outdir) $<" "$*.log" cp $< $(outdir) $(outdir)/%-midi.ly: $(outdir)/%.midi $(MIDI2LY) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Simplify font building. (issue 5695061)
On 2/25/12 9:23 AM, "Graham Percival" wrote: >On Sat, Feb 25, 2012 at 03:57:55PM +, julien.ri...@gmail.com wrote: >> This is good, I now get the error message right away when running >> configure. No problem with the patch after installing the required >> package. Do lilydev and gub already include the fontforge python >> package? > >No, and adding this to GUB will be particularly challenging. I'm >afraid that this will probably postpone the patch indefinitely. >:( Can't we add that package as a requirement for GUB (kind of like we have done with libmpfr-dev)? And we can add it to lilydev. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Removes mutopia-index.py processing (issue 5696073)
- Original Message - From: To: ; Cc: ; Sent: Saturday, February 25, 2012 3:50 PM Subject: Re: Removes mutopia-index.py processing (issue 5696073) Looks good. Can we also remove the mutopia-related stuff in the make folder? Regards, Julien I _think_ so. I was going to make a few other changes to reduce noise in make doc and was then going to experiment with the "odd" make files there. Problem is - does someone, somewhere, use that makefile? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Simplify font building. (issue 5695061)
On Sat, Feb 25, 2012 at 03:57:55PM +, julien.ri...@gmail.com wrote: > This is good, I now get the error message right away when running > configure. No problem with the patch after installing the required > package. Do lilydev and gub already include the fontforge python > package? No, and adding this to GUB will be particularly challenging. I'm afraid that this will probably postpone the patch indefinitely. :( - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Quietens extract-texi-filenames in make doc (issue 5698066)
LGTM, please push directly to staging. http://codereview.appspot.com/5698066/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Quietens extract-texi-filenames in make doc (issue 5698066)
Reviewers: Julien Rioux, Graham Percival, Message: Simple change. Please review. Description: Adds the -q flag to the call to extract-texi-filenames.py during make doc. Gets rid of unnecessary progress messages. Please review this at http://codereview.appspot.com/5698066/ Affected files: M stepmake/stepmake/texinfo-rules.make Index: stepmake/stepmake/texinfo-rules.make diff --git a/stepmake/stepmake/texinfo-rules.make b/stepmake/stepmake/texinfo-rules.make index 7b5da4a65f841673bf4bba89b9ece74bae8c29b8..074060627e1f3f444b37463a011f2c866d8a0cb3 100644 --- a/stepmake/stepmake/texinfo-rules.make +++ b/stepmake/stepmake/texinfo-rules.make @@ -60,10 +60,10 @@ endif ifneq ($(ISOLANG),) $(XREF_MAPS_DIR)/%.$(ISOLANG).xref-map: $(outdir)/%.texi $(XREF_MAPS_DIR)/%.xref-map - $(buildscript-dir)/extract_texi_filenames $(XREF_MAP_FLAGS) -o $(XREF_MAPS_DIR) --master-map-file=$(XREF_MAPS_DIR)/$*.xref-map $< + $(buildscript-dir)/extract_texi_filenames $(XREF_MAP_FLAGS) -q -o $(XREF_MAPS_DIR) --master-map-file=$(XREF_MAPS_DIR)/$*.xref-map $< else $(XREF_MAPS_DIR)/%.xref-map: $(outdir)/%.texi - $(buildscript-dir)/extract_texi_filenames $(XREF_MAP_FLAGS) -o $(XREF_MAPS_DIR) $< + $(buildscript-dir)/extract_texi_filenames $(XREF_MAP_FLAGS) -q -o $(XREF_MAPS_DIR) $< endif $(outdir)/%.info: %.texi $(outdir)/$(INFO_IMAGES_DIR).info-images-dir-dep $(outdir)/version.itexi $(outdir)/weblinks.itexi ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Simplify font building. (issue 5695061)
This is good, I now get the error message right away when running configure. No problem with the patch after installing the required package. Do lilydev and gub already include the fontforge python package? Regards, Julien http://codereview.appspot.com/5695061/diff/3003/configure.in File configure.in (right): http://codereview.appspot.com/5695061/diff/3003/configure.in#newcode175 configure.in:175: REQUIRED="$REQUIRED fontforge-python" On ubuntu the package is named python-fontforge. http://codereview.appspot.com/5695061/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Removes mutopia-index.py processing (issue 5696073)
Looks good. Can we also remove the mutopia-related stuff in the make folder? Regards, Julien http://codereview.appspot.com/5696073/diff/1/GNUmakefile.in File GNUmakefile.in (left): http://codereview.appspot.com/5696073/diff/1/GNUmakefile.in#oldcode142 GNUmakefile.in:142: $(outdir)/examples.html: $(WEB_EXAMPLE_FILES) The definition for WEB_EXAMPLE_FILES in this GNUmakefile should be removed, too. http://codereview.appspot.com/5696073/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Removes mutopia-index.py processing (issue 5696073)
Reviewers: Julien Rioux, Graham Percival, Message: Please review. Description: I checked on -devel and no-one argued for keeping this. The patch stops make doc running mutopia-index.py. I believe the script is an old hangover, and trying to run on files which no longer exist. Please review this at http://codereview.appspot.com/5696073/ Affected files: M GNUmakefile.in D scripts/build/mutopia-index.py ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cross-staff stem engraver (was: New frog in an empty pond?)
Quoting Joe Neeman :
On Fri, Feb 24, 2012 at 3:04 PM, Pavel Roskin wrote:
I tried writing an engraver that could be added to the StaffGroup
context. Collecting stems is not a problem. The problem is that even
the finalize handler is called to early. I'm getting a warning:
programming error: vertical alignment called before line breaking
continuing, cross fingers
It's a little hard to guess what's going wrong without knowing exactly what
you've tried. Are you trying to do layout logic in the engraver (ie. by
collecting stems, reading their properties, doing calculations and then
setting more properties)?
Yes, except that I'm not setting anything yet. The current file is attached.
If you are, the first step is to move the layout
logic into grob callbacks.
I guess I'll need to redefine the stencil for stems. Or maybe you
mean some other callback?
I did a similar thing before. I put all the logic into a function
that was used to redefine the length property of the stem. It worked
for a simple case of two stems, but failed when three stems needed to
be connected. The Y-extent for at least one of the stems wasn't
calculated yet.
I also tried setting Y-extent, but it's read-only.
--
Regards,
Pavel Roskin
\version "2.14.0"
#(define ((connectableStem? xref yref stemone dir below?) stemtwo)
(cond
((not (memq 'stem-interface (ly:grob-interfaces stemtwo))) #f)
((equal? stemone stemtwo) #f)
((inf? (car (ly:grob-extent stemtwo xref X))) #f)
((not (equal? (ly:grob-extent stemone xref X) (ly:grob-extent stemtwo xref X))) #f)
((not (equal? dir (ly:grob-property stemtwo 'direction))) #f)
((below? (car (ly:grob-extent stemtwo yref Y)) (car (ly:grob-extent stemone yref Y))) #f)
(else #t)))
#(define ((lowerStem? ref below?) lower upper)
(below? (car (ly:grob-extent lower ref Y)) (car (ly:grob-extent upper ref Y
#(define (crossStaffLength grob ctx stems)
(let* ((papercolumn (ly:context-property ctx 'currentMusicalColumn))
(foo (ly:message "papercolumn: ~a" papercolumn))
(xref (ly:grob-common-refpoint grob (car stems) X))
(foo (ly:message "xref: ~a" xref))
(yref (ly:grob-common-refpoint grob (car stems) Y))
(foo (ly:message "yref: ~a" yref))
(dir (ly:grob-property grob 'direction))
(below? (if (= dir UP) < >))
(foo (ly:message "stems: ~a" stems))
(goodstems (filter (connectableStem? xref yref grob dir below?) stems))
(foo (ly:message "stems1: ~a" stems))
(beststems (sort goodstems (lowerStem? yref below?)))
(foo (ly:message "stems2: ~a" stems))
(peer (car (append beststems (list grob
(foo (ly:message "peer: ~a" peer)))
(ly:message "grob: ~a" (ly:grob-extent grob yref Y))
(ly:message "peer: ~a" (ly:grob-extent peer yref Y))
(if (equal? grob peer)
(begin (ly:programming-error "No suitable stem to connect to") 4)
(if (> dir 0)
(* 2 (- (car (ly:grob-extent peer yref Y))
(car (ly:grob-extent grob yref Y
(* 2 (- (cdr (ly:grob-extent grob yref Y))
(cdr (ly:grob-extent peer yref Y
#(define (connectStems ctx stems)
(ly:message "stems: ~a" stems)
(if (and (pair? stems) (pair? (cdr stems)))
(let ((stem (car stems))
(otherstems (cdr stems)))
(ly:message "otherstems: ~a" otherstems)
(ly:message "length: ~a"
(crossStaffLength stem ctx otherstems)
#(define (Cross_staff_stem_engraver ctx)
(let ((stems '()))
`((acknowledgers
(stem-interface
. ,(lambda (trans grob source)
(ly:message "acknowledger: ~a" grob)
(set! stems (cons grob stems
(note-column-interface
. ,(lambda (trans grob source)
(ly:message "acknowledger: ~a" grob
(process-music
. ,(lambda (trans) (ly:message "process-music") (connectStems ctx stems)))
(process-acknowledged
. ,(lambda (trans) (ly:message "process-acknowledged")))
(stop-translation-timestep
. ,(lambda (trans) (ly:message "stop-translation-timestep") (connectStems ctx stems)))
(finalize
. ,(lambda (trans) (ly:message "finalize") (connectStems ctx stems))
\layout {
\context {
\StaffGroup
\consists #Cross_staff_stem_engraver
}
}
\new StaffGroup <<
\new Staff { g' }
\new Staff { c' }
>>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Simplify font building. (issue 5695061)
haven't looked in detail, but nice, and simpler than I thought :) now, if you want a real challenge: you could redo mf2pt1 in Fontforge python too! :) http://codereview.appspot.com/5695061/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cross-staff stem engraver (was: New frog in an empty pond?)
On Fri, Feb 24, 2012 at 3:04 PM, Pavel Roskin wrote: > Hello! > > I'm moving the thread to lilypond-devel and changing the subject. I > hope it's OK. > > On Thu, 23 Feb 2012 15:37:02 + > Neil Puttock wrote: > > > On 23 February 2012 15:18, Pavel Roskin wrote: > > > > > I actually wanted to make a stopgap solution in Scheme. I wrote > > > some code that looks for other stems and sets the stem length so it > > > would touch the stem above (attached). But the code is unreliable. > > > Some stems are not calculated yet. > > > > I'd love to be proven wrong, but I don't think you'll have much > > success with this approach. At the very least, you'll need a Scheme > > engraver at the correct context level to collect the stems at the > > right time. If a simple length override were possible with the > > current infrastructure, we wouldn't need a Span_arpeggio_engraver to > > typeset cross-staff arpeggios. > > I tried writing an engraver that could be added to the StaffGroup > context. Collecting stems is not a problem. The problem is that even > the finalize handler is called to early. I'm getting a warning: > > programming error: vertical alignment called before line breaking > continuing, cross fingers > It's a little hard to guess what's going wrong without knowing exactly what you've tried. Are you trying to do layout logic in the engraver (ie. by collecting stems, reading their properties, doing calculations and then setting more properties)? If you are, the first step is to move the layout logic into grob callbacks. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG: Use latest convert-ly for LSR updates (fix 2346) (issue 5696069)
One suggestion. Regards, Julien http://codereview.appspot.com/5696069/diff/1/Documentation/contributor/lsr-work.itexi File Documentation/contributor/lsr-work.itexi (right): http://codereview.appspot.com/5696069/diff/1/Documentation/contributor/lsr-work.itexi#newcode302 Documentation/contributor/lsr-work.itexi:302: @item This isn't per se a new @item in terms of steps to be performed. I suggest merging it with the previous @item. http://codereview.appspot.com/5696069/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Simplify font building. (issue 5695061)
This adds a dependency on the python module fontforge. I think it should be checked during ./configure but I'm not sure where to point you for accomplishing that. Regards, Julien http://codereview.appspot.com/5695061/diff/1/python/mf_table.py File python/mf_table.py (right): http://codereview.appspot.com/5695061/diff/1/python/mf_table.py#newcode3 python/mf_table.py:3: # mf-to-table.py -- convert spacing info in MF logs . mf_table.py ? http://codereview.appspot.com/5695061/diff/1/python/mf_table.py#newcode185 python/mf_table.py:185: git complains about new blank line at EOF here. http://codereview.appspot.com/5695061/diff/1/scripts/build/gen-emmentaler.py File scripts/build/gen-emmentaler.py (right): http://codereview.appspot.com/5695061/diff/1/scripts/build/gen-emmentaler.py#newcode5 scripts/build/gen-emmentaler.py:5: import fontforge I got: Traceback (most recent call last): File "/tmp/lilypond-autobuild/build/scripts/build/out/gen-emmentaler", line 5, in import fontforge ImportError: No module named fontforge make[1]: *** [out/emmentaler-11.svg] Error 1 http://codereview.appspot.com/5695061/diff/1/scripts/build/gen-emmentaler.py#newcode69 scripts/build/gen-emmentaler.py:69: git complains about trailing whitespace here. http://codereview.appspot.com/5695061/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Re: New frog in an empty pond?
- Original Message - From: "Janek Warchoł" Fortunately it's mostly me whom i'm doing this for :) (is the above proper English, anyway?) cheers, Janek "Fortunately, I'm mostly doing this for me." would be fair idiomatic English. Some people would say "myself" rather than "me". -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Re: New frog in an empty pond?
On Sat, Feb 25, 2012 at 10:09 AM, David Kastrup wrote: > Janek Warchoł writes: >> i wrote: "try looking at grid >> lines code". That's definitely not enough for efficient mentoring :( > > "Try asking on the developer list." "Find an angle that makes this > problem interesting for Mike." > > The job of a mentor is not the same as the job of a teacher. You need > not provide answers, just offer advice on how or where to find them. Hmm. I may have been looking at mentoring from wrong perspective. >> I'm already quite often not sleeping because of Lily and it's going to >> be worse. > > Don't give more than you can sustain. Ever. You are not doing anybody > a favor, even though it may seem so to some. But those will be the > first to complain when you are drained. Fortunately it's mostly me whom i'm doing this for :) (is the above proper English, anyway?) cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Re: New frog in an empty pond?
Janek Warchoł writes: > On Thu, Feb 23, 2012 at 1:18 PM, Graham Percival > wrote: >> On Wed, Feb 22, 2012 at 04:52:00PM -0800, Janek Warchol wrote: >>> It would be good indeed if you have a mentor; unfortunately, i don't think >>> you'll find one here, on frogs. It's hard to find a mentor in general... >>> I'm not much Lily-knowledgeable, so i don't think i would be a good mentor >>> for you, >> >> Really? Which responsibility are you unable to fulfill? There >> are 7 responsibilities. Tell me the EXACT number that you cannot >> do. >> http://lilypond.org/doc/v2.15/Documentation/contributor/mentors >> (note that points 4 and 5 should be rewritten for the new patch >> handling and staging) >> >> Pavel Roskin is doing everything right. He's clearly read the CG, >> he's submitted stuff to rietveld, he's actively trying to get help >> in the manner that we want people to ask for help. But once his >> patches get through the countdown, nobody wants to bother taking >> responsibility for getting the final git patch and pushing it. >> He's one of the easiest people to mentor. > > Of course i can do it. (Pavel, if you have problems with getting the > patch pushed, or you have trouble getting reviews, or it seems that > your patch is being overlooked - let me know and i'll try to help!) > My concern was that Pavel's a skilled contributor whose primary need > is advice on coding - for example cross-staff stems thing. All advice > i can provide (without digging through the code myself, which i'd love > to do but don't have time to because of Google Summer of Code and > other organizational stuff) was what i wrote: "try looking at grid > lines code". That's definitely not enough for efficient mentoring :( "Try asking on the developer list." "Find an angle that makes this problem interesting for Mike." The job of a mentor is not the same as the job of a teacher. You need not provide answers, just offer advice on how or where to find them. > I'm already quite often not sleeping because of Lily and it's going to > be worse. Don't give more than you can sustain. Ever. You are not doing anybody a favor, even though it may seem so to some. But those will be the first to complain when you are drained. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
