Re: Axis group interface ignores column rank for pure-from-neighbor-interface (issue 5843063)
On Mar 20, 2012, at 3:36 AM, k-ohara5...@oco.net wrote: http://codereview.appspot.com/5843063/diff/5001/lily/axis-group-interface.cc#newcode330 lily/axis-group-interface.cc:330: || Pure_from_neighbor_interface::has_interface (me)) Now that the engraver is working correctly, do you still need this change ? It looks like I do, otherwise the problem creeps back in. The solution may be to have pure-from-neighbor-interface stuff only ever factor into extra-spacing-height and never height. So SpanBarStub would need some surgery. But I'm not sure...I'll have a look tomorrow or later today. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: AU - document -dhelp CLI options (issue 5843060)
http://codereview.appspot.com/5843060/diff/1/Documentation/usage/running.itely
File Documentation/usage/running.itely (right):
http://codereview.appspot.com/5843060/diff/1/Documentation/usage/running.itely#newcode56
Documentation/usage/running.itely:56: * Basic command line options for
lilypond::
On 2012/03/19 02:03:46, Graham Percival wrote:
how about:
Command-line options with --help
Command-line options with -dhelp
? I'm not totally confident about this idea, though, so don't take it
as
gospel.
Made it simpler - I used 'Basic' and 'Advanced' command line options for
Lilypond
http://codereview.appspot.com/5843060/diff/1/Documentation/usage/running.itely#newcode201
Documentation/usage/running.itely:201: @option{-dsafe}, see @ref{Command
line options using scheme values}
On 2012/03/19 02:03:46, Graham Percival wrote:
@ref should come at the end of a sentence, or at least have some
strong
punctuation after it (like a semicolon). Or maybe in this case a
parenthesis
makes more sense.
Done.
http://codereview.appspot.com/5843060/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 1320: Rewriting bar-line::print
Hello list,
I want to rewrite most if not all definitions currently settled in
lily/bar-line.cc in scheme. Please see the attached file for my
progress so far; I don't get any error messages, but no bar lines either :-(
Is this a feasible approach? What am I currently doing wrong?
Thanks for any pointers,
Marc
\version 2.15.34
#(define (bar-line::calc-bar-extent grob)
(let ((staff-symbol (ly:grob-object grob 'staff-symbol))
(staff-extent (cons 0 0)))
(if (ly:grob? staff-symbol)
(let* ((bar-line-color (ly:grob-property grob 'color))
(staff-color (ly:grob-property staff-symbol 'color))
(radius (ly:staff-symbol-staff-radius grob))
(line-thickness (ly:staff-symbol-line-thickness grob)))
(set! staff-extent (ly:staff-symbol::height staff-symbol))
(if (and (eq? bar-line-color staff-color)
radius)
(interval-widen staff-extent
(- 1 (* 1/2 (/ line-thickness radius)))
staff-extent))
#(define-public (bar-line::print grob)
(let* ((glyph (ly:grob-property grob 'glyph-name))
(bar-extent (ly:grob-property grob 'bar-extent '(0 . 0)))
(extent (interval-length bar-extent))
(stencil (if (and (not (eq? glyph '()))
( extent 0))
(bar-line::compound-bar-line grob glyph extent #f
stencil))
#(define (bar-line::simple-bar-line grob width extent rounded)
(let ((blot (if rounded
(ly:output-def-lookup layout 'blot-diameter)
0)))
(ly:round-filled-box (cons 0 width)
(cons 0 extent)
blot)))
#(define (bar-line::tick-bar-line grob height rounded)
(let ((half-staff (* 1/2 (ly:staff-symbol-staff-space grob)))
(stafflinethick (ly:staff-symbol-line-thickness grob))
(blot (if rounded
(ly:output-def-lookup layout 'blot-diameter)
0)))
(ly:round-filled-box (cons 0 stafflinethick)
(cons (- height half-staff) (+ height half-staff))
blot)))
#(define bar-line-stencil-alist
'((| . thin-stil)
(. . thick-stil)
( . empty-stil)
))
#(define (bar-line::compound-bar-line grob glyph extent rounded)
(let* ((staff-symbol (ly:grob-object grob 'staff-symbol))
(line-count (if (ly:grob? staff-symbol)
(ly:grob-property staff-symbol 'line-count)
0))
(staff-space (ly:staff-symbol-staff-space grob))
(stafflinethick (ly:staff-symbol-line-thickness grob))
(dist (if (or (odd? line-count)
(zero? line-count))
1
(* staff-space (if ( staff-space 2)
2
1/2
(font (ly:grob-default-font grob))
(dot (ly:font-get-glyph font dots.dot))
(segno (ly:font-get-glyph font scripts.varsegno))
(kievan (ly:font-get-glyph font scripts.barline.kievan))
(kern (* (ly:grob-property grob 'kern 1)
stafflinethick))
(thinkern (* (ly:grob-property grob 'thinkern 1)
stafflinethick))
(hair (* (ly:grob-property grob 'hair-thickness 1)
stafflinethick))
(fatline (* (ly:grob-property grob 'thick-thickness 1)
stafflinethick))
(thin-stil (bar-line::simple-bar-line grob hair extent rounded))
(thick-stil (bar-line::simple-bar-line grob fatline extent rounded))
(empty-stil (make-filled-box-stencil (cons 0 0) (cons 0 extent)))
(stencil (assoc-get glyph bar-line-stencil-alist empty-stil))
)
stencil
))
music = \relative f {
c'4 d e f | f f f f \bar | g g g g \bar . g a b c \bar || c c c c \bar ' c b a g \bar |: f e d c \bar |.
}
\score {
\new Staff {
\new Voice { \music }
}
}
\score {
\new Staff {
\new Voice {
\override Staff.BarLine #'bar-extent = #bar-line::calc-bar-extent
\override Staff.BarLine #'stencil = #bar-line::print
\music
}
}
}___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1320: Rewriting bar-line::print
Marc Hohl m...@hohlart.de writes: Hello list, I want to rewrite most if not all definitions currently settled in lily/bar-line.cc in scheme. Please see the attached file for my progress so far; I don't get any error messages, but no bar lines either :-( Is this a feasible approach? What am I currently doing wrong? Thanks for any pointers, Marc \version 2.15.34 #(define (bar-line::calc-bar-extent grob) (let ((staff-symbol (ly:grob-object grob 'staff-symbol)) (staff-extent (cons 0 0))) (if (ly:grob? staff-symbol) (let* ((bar-line-color (ly:grob-property grob 'color)) (staff-color (ly:grob-property staff-symbol 'color)) (radius (ly:staff-symbol-staff-radius grob)) (line-thickness (ly:staff-symbol-line-thickness grob))) (set! staff-extent (ly:staff-symbol::height staff-symbol)) Shouldn't staff-extent be a cons/interval? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1320: Rewriting bar-line::print
Am 20.03.2012 10:19, schrieb David Kastrup: Marc Hohlm...@hohlart.de writes: Hello list, I want to rewrite most if not all definitions currently settled in lily/bar-line.cc in scheme. Please see the attached file for my progress so far; I don't get any error messages, but no bar lines either :-( Is this a feasible approach? What am I currently doing wrong? Thanks for any pointers, Marc \version 2.15.34 #(define (bar-line::calc-bar-extent grob) (let ((staff-symbol (ly:grob-object grob 'staff-symbol)) (staff-extent (cons 0 0))) (if (ly:grob? staff-symbol) (let* ((bar-line-color (ly:grob-property grob 'color)) (staff-color (ly:grob-property staff-symbol 'color)) (radius (ly:staff-symbol-staff-radius grob)) (line-thickness (ly:staff-symbol-line-thickness grob))) (set! staff-extent (ly:staff-symbol::height staff-symbol)) Shouldn't staff-extent be a cons/interval? IIUC, ly:staff-symbol::height returns an interval (according to the definition in lily/staff-symbol.cc) Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1320: Rewriting bar-line::print
Marc Hohl m...@hohlart.de writes: Am 20.03.2012 10:19, schrieb David Kastrup: Marc Hohlm...@hohlart.de writes: Hello list, I want to rewrite most if not all definitions currently settled in lily/bar-line.cc in scheme. Please see the attached file for my progress so far; I don't get any error messages, but no bar lines either :-( Is this a feasible approach? What am I currently doing wrong? Thanks for any pointers, Marc \version 2.15.34 #(define (bar-line::calc-bar-extent grob) (let ((staff-symbol (ly:grob-object grob 'staff-symbol)) (staff-extent (cons 0 0))) (if (ly:grob? staff-symbol) (let* ((bar-line-color (ly:grob-property grob 'color)) (staff-color (ly:grob-property staff-symbol 'color)) (radius (ly:staff-symbol-staff-radius grob)) (line-thickness (ly:staff-symbol-line-thickness grob))) (set! staff-extent (ly:staff-symbol::height staff-symbol)) Shouldn't staff-extent be a cons/interval? IIUC, ly:staff-symbol::height returns an interval (according to the definition in lily/staff-symbol.cc) I stand corrected. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: new lilypond-auto mailing list
On 2012-03-20 00:28, Graham Percival wrote: On Tue, Mar 20, 2012 at 12:11:46AM +0100, David Kastrup wrote: So instead of surprising volunteers by giving them more information than expected we give them less information than expected? Bug squad members shouldn't be reading tracker messages anyway. It's not about bug squad, but about all developers. The comment of the lilypond users to the bug reports are *extremely* important for development. On the other hand, all those hundreds of automated comments to the bug reports are totally unnecessary. To me the main problem is that we have so many automated comments to a bug report that the bug-lilypond list is swamped with those notifications and the relevant human responses are hard to detect (I now typically ignore all bug mails, since it simply takes to long to find out which of the ~50-70 mails per day are automated and which are relevant). 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: new lilypond-auto mailing list
hello, On 20 March 2012 10:47, Reinhold Kainhofer reinh...@kainhofer.com wrote: On 2012-03-20 00:28, Graham Percival wrote: On Tue, Mar 20, 2012 at 12:11:46AM +0100, David Kastrup wrote: So instead of surprising volunteers by giving them more information than expected we give them less information than expected? Bug squad members shouldn't be reading tracker messages anyway. It's not about bug squad, but about all developers. The comment of the lilypond users to the bug reports are *extremely* important for development. On the other hand, all those hundreds of automated comments to the bug reports are totally unnecessary. The thing is you are damned if you do and you are damned if you don't. I think this auto list is a good idea. Some while complain now that they won't know when a Tracker has been updated from a checkin but only when a user updates the checkin. In that case you can use git-cl to cc the dev list if you so wish for your patch upload. Or devs can use the tracker website instead of just relying on emails - there are filters on this site and they work well, I have a set of bookmarks that list me Patch-new, Patch-review and so on, or they can now subscribe to the auto list. or you can simply add another filter to your email. It may be about the devs in your head, but unless 'someone' creates the trackers (and this includes spotting the bug reported in the first place) the devs have nothing to work on (so to speak). We already know that devs hate the 'admin' :) and the idea of the bug-squad is to make the dev's life easier. It isn't perfect but if anything we should give this a try. -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond 2.15.34 on MacOS X
On Mon, Mar 19, 2012 at 02:50:41PM +, Colin Hall wrote: Hi All, You may have seen the announcement that version 2.15.34 of Lilypond has been released. It would be great to hear if it works for you on your respective platforms so that I can update the table below. I'll post updates as they come in. I've heard from at least one tester on each MacOS X platform now. Thanks very much to all the users for downloading and checking the new release. As with the previous development release we found that Lilypond 2.15.34 works on some commonly used MacOS X releases from 10.4.11 onwards with the exception of MacOS X 10.4.11 on x86 hardware. |-+-++---| | MacOS X | x86/ppc | User | Launches and compiles | | version | || on 2.15.34| |-+-++---| | 10.4.11 | ppc | Ole Schmidt| Yes | | | | Valentin Villenave | | | | | James Worlton | | |-+-++---| | 10.4.11 | x86 | Klaus Foehl| No| |-+-++---| | 10.5.8 | ppc | Stan Sanderson | Yes | |-+-++---| | 10.5.8 | x86 | Stan Sanderson | Yes | |-+-++---| | 10.6.8 | x86 | Ole Schmidt| Yes | | | | Tim McNamara | | |-+-++---| | 10.7.3 | x86 | Eric Schissel | | | | | Hans Aikema| Yes | | | | Brian Alliford | Yes | | | | Phillipe | | | | | Hans Aberg | Yes | |-+-++---| Cheers, Colin. -- Colin Hall ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Axis group interface ignores column rank for pure-from-neighbor-interface (issue 5843063)
On Mon, 19 Mar 2012 23:51:04 -0700, m...@apollinemike.com m...@apollinemike.com wrote: On Mar 20, 2012, at 3:36 AM, k-ohara5...@oco.net wrote: do you still need this change ? It looks like I do, I had expected that separation-item.cc calls pure_height with start=0 and end=INT_MAX for horizontal spacing; then the original test would do just what we want without your change. Now I vaguely remember that breakable columns get their skylines differently. Somebody asks for pure_height of a SpanBarStub with start and end only one measure apart, to which the honest answer from a SpanBarStub would be its height if that measure were alone on a line, but the answer seems to be used for horizontal spacing of longer lines. That is not good. have pure-from-neighbor-interface [affect] only extra-spacing-height That would make more sense, but you need to pick a base Y-extent from which the extra-spacing-height extends. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond-book: Set include path for --output option (issue 2423). (issue 5846075)
LGTM http://codereview.appspot.com/5846075/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Tracks old announcements, news and changelogs. (issue 5843069)
LGTM http://codereview.appspot.com/5843069/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Axis group interface ignores column rank for pure-from-neighbor-interface (issue 5843063)
On Mar 20, 2012, at 6:33 PM, Keith OHara wrote: On Mon, 19 Mar 2012 23:51:04 -0700, m...@apollinemike.com m...@apollinemike.com wrote: On Mar 20, 2012, at 3:36 AM, k-ohara5...@oco.net wrote: do you still need this change ? It looks like I do, I had expected that separation-item.cc calls pure_height with start=0 and end=INT_MAX for horizontal spacing; then the original test would do just what we want without your change. Now I vaguely remember that breakable columns get their skylines differently. This was theoretically buggy, as cached skylines for items should always go from 0 to INT_MAX but they were sometimes being passed other starts and ends. I've rectified this in item.cc in the newest patchset. Somebody asks for pure_height of a SpanBarStub with start and end only one measure apart, to which the honest answer from a SpanBarStub would be its height if that measure were alone on a line, but the answer seems to be used for horizontal spacing of longer lines. That is not good. The extra-spacing-height solution fixes this. have pure-from-neighbor-interface [affect] only extra-spacing-height That would make more sense, but you need to pick a base Y-extent from which the extra-spacing-height extends. My new patchset uses an empty extent, which gets ignored unless extra-spacing-height is tacked on. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: volunteer for patchy new-patches
Hi, 2012/3/16 Graham Percival gra...@percival-music.ca On Fri, Mar 16, 2012 at 09:52:52PM +0100, Marek Klein wrote: I can do it, I think (almost every day). Great! Here's the link to get started: http://lilypond.org/doc/v2.15/Documentation/contributor/patchy ... although apparently that doesn't include a link to the actual code. huh. https://github.com/gperciva/lilypond-extra - Graham what are the next steps? Should I try to run python lilypond-patchy-staging.py ? Marek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tracks old announcements, news and changelogs. (issue 5843069)
On Tue, Mar 20, 2012 at 2:07 PM, gra...@percival-music.ca wrote: LGTM http://codereview.appspot.com/5843069/ Thanks for having a look. By the way, it looks like http://lilypond.org/website just replicates http://lilypong.org at a deeper level -- any reason why this is so? Is that from before the switch to the new website? Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: volunteer for patchy new-patches
On 20/03/2012 4:26 PM, Marek Klein wrote: Hi, 2012/3/16 Graham Percivalgra...@percival-music.ca On Fri, Mar 16, 2012 at 09:52:52PM +0100, Marek Klein wrote: I can do it, I think (almost every day). Great! Here's the link to get started: http://lilypond.org/doc/v2.15/Documentation/contributor/patchy ... although apparently that doesn't include a link to the actual code. huh. https://github.com/gperciva/lilypond-extra - Graham what are the next steps? Should I try to run python lilypond-patchy-staging.py ? Marek python test-patches.py -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: volunteer for patchy new-patches
2012/3/20 Julien Rioux jri...@physics.utoronto.ca python test-patches.py This is the result: Trying issue 2272 Found patch: (2272, '/home/marek/lilypond-patchy/issue5843063_7.diff', 'Long monosyllabic words collide with barlines') Problem compiling master. Patchy cannot reliably continue. Traceback (most recent call last): File test-patches.py, line 16, in module main(issues_id) File test-patches.py, line 12, in main patchy.do_check(issues) File /home/marek/lilypond-patchy/projecthosting_patches.py, line 213, in do_check compile_lilypond_test.main(patches) File /home/marek/lilypond-patchy/compile_lilypond_test.py, line 289, in main raise err Exception: Failed runner: ./autogen.sh --noconfigure See the log file log-None-autogen.sh.txt ? Marek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tracks old announcements, news and changelogs. (issue 5843069)
On Tue, Mar 20, 2012 at 04:41:34PM -0400, Julien Rioux wrote: Thanks for having a look. By the way, it looks like http://lilypond.org/website just replicates http://lilypong.org at a deeper level -- any reason why this is so? Is that from before the switch to the new website? Correct, but it was like that long before the new website. The old website was always /web/; I made the new website in /website/. Not certain why, but I'm not going to poke it unless/until other stuff is moving much smoothly. There's a bunch of weirdness on lilypond.org. See Documentation/website/server/lilypond.org.htaccess for more details. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix crash when unknown grob name is passed to ly:engraver-make-grob (issue 5715053)
http://codereview.appspot.com/5715053/diff/2001/lily/engraver-scheme.cc File lily/engraver-scheme.cc (right): http://codereview.appspot.com/5715053/diff/2001/lily/engraver-scheme.cc#newcode42 lily/engraver-scheme.cc:42: programming_error (cannot create grob); This gives no helpful indication of where the error occured, and triggers problems later in unrelated code. That's not better than a segfault: neither is better than something that shouldn't happened somewhere. You could check whether cause is a grob in which case you can call unsmob_grob (cause)-programming_error on it in order to give the error message a _source_ indicator, or a stream-event in which case unsmob_event (cause)-origin ()-programming_error would deliver a suitable source indicator for the error. http://codereview.appspot.com/5715053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: volunteer for patchy new-patches
On Tue, Mar 20, 2012 at 10:48:57PM +0100, Marek Klein wrote: Exception: Failed runner: ./autogen.sh --noconfigure See the log file log-None-autogen.sh.txt Well, what's in the log file log-None-autgen.sh.txt ? It's in the build directory. This whole infrastructure assumes that you can compile lilypond normally; if there's a problem in autogen.sh, it seems like you don't have autotools installed. You may want to consider trying out lilydev instead of manually installing all required dependencies. It depends on how familiar you are with linux. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: volunteer for patchy new-patches
Graham Percival gra...@percival-music.ca writes: On Tue, Mar 20, 2012 at 10:48:57PM +0100, Marek Klein wrote: Exception: Failed runner: ./autogen.sh --noconfigure See the log file log-None-autogen.sh.txt Well, what's in the log file log-None-autgen.sh.txt ? It's in the build directory. This whole infrastructure assumes that you can compile lilypond normally; if there's a problem in autogen.sh, it seems like you don't have autotools installed. You may want to consider trying out lilydev instead of manually installing all required dependencies. It depends on how familiar you are with linux. sudo apt-get build-dep lilypond should get you pretty far regarding having the required build dependencies installed on dpkg-based systems. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
2.16 release criteria
Well, the good news is that we have not had anything holding up the release without a fix in the pipeline for at least a month (or so it feels). The bad news is that the pipelines still see quite a bit of action. It will be luck more than anything else if we have a pause in the stream of newly discovered regressions that is long enough for making a long-term release. I have the fear that the desire to get to this state might prompt some regression fixes that have not necessarily gotten all the diligence that would have been desirable. So I am not sure that a timed release scheme would not possibly lead to a higher quality/time ratio, even though our current scheme attempts to have monotonically increasing quality over the subset of known bugs. On the plus side, regressions are being addressed vigorously right now. Other bugs, however, get to see this vigor as well, leading to more regressions in their wake. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release criteria
On Wed, Mar 21, 2012 at 01:06:42AM +0100, David Kastrup wrote: I have the fear that the desire to get to this state might prompt some regression fixes that have not necessarily gotten all the diligence that would have been desirable. This is a valid fear in general, but I haven't seen it happen yet. Granted, I don't usually review scheme or C++ patches, so perhaps people have been sneaking bad bugfixes in that way? But I somewhat doubt that. So I am not sure that a timed release No. Absolutely not. Yes, it might be good to change the release policy. But I will not accept any discussion along those lines. We discussed matters to death in GOP. It hasn't even been 12 months! What's the point of having a serious policy discussion if it's going to change in a few months? In the summer, I will begin GOP2, and we will begin by reviewing every single policy decision made in GOP. It will be understood that whatever policies we agree upon in GOP 2 will hold for at least the next year. We may end up having a yearly review of such policies. On the plus side, regressions are being addressed vigorously right now. Other bugs, however, get to see this vigor as well, leading to more regressions in their wake. I think we're looking at about 30% Critical regressions due to code in the past year. Solution? More eyes on reviews and/or more regtests. The bulk of Critical regressions happened during the long 2.13 process. Those block a stable release on the basis of last year's policy discussions. To make matters worse, we've begun a big review of the regression tests. I guessimate that we currently have between 5 and 20 broken regtests; the regtest review will probably find those. In the long term, I think we're doing fine. For the first time ever, we're not regularly breaking regtests. I cannot emphasize how important this is -- back when I was handling bugs, I would see 1-2 broken regtests every devel release. Unforuntately we're in for some more pain in the next few months as we discover previously-broken tests, but once that's shaken down, we'll have a trustworthy set of regression tests. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: Set include path for --output option (issue 2423). (issue 5846075)
http://codereview.appspot.com/5846075/diff/1/scripts/lilypond-book.py File scripts/lilypond-book.py (right): http://codereview.appspot.com/5846075/diff/1/scripts/lilypond-book.py#newcode639 scripts/lilypond-book.py:639: global_options.include_path.insert (0, inverse_relpath (original_dir, global_options.output_dir)) Wouldn't it be easier if you just added the absolute path to original_dir? http://codereview.appspot.com/5846075/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1320: Rewriting bar-line::print
Hi Marc,
Some observations:
the main problem seems to be the storing of the new stencils in an
alist and how to call them. Directly in bar-line::compound-bar-line
works.
Also, I created bar-line-stencil-alist-demo containing new stencils,
which are defined before. Calling them in bar-line::compound-bar-line
works too.
But I didn't manage to make it work with the original alist.
In addition I changed a line in bar-line::simple-bar-line otherwise
the barlines are printed misplaced in Y-direction.
HTH,
Harm
\version 2.15.33
#(define (new-stil-1 grob)
(grob-interpret-markup grob (markup 1)))
#(define (new-stil-2 grob)
(grob-interpret-markup grob (markup 2)))
#(define (new-stil-3 grob)
(grob-interpret-markup grob (markup 3)))
#(define bar-line-stencil-alist-demo
`((| . ,new-stil-1)
(. . ,new-stil-2)
( . ,new-stil-3)
))
#(define (bar-line::calc-bar-extent grob)
(let ((staff-symbol (ly:grob-object grob 'staff-symbol))
(staff-extent (cons 0 0)))
(if (ly:grob? staff-symbol)
(let* ((bar-line-color (ly:grob-property grob 'color))
(staff-color (ly:grob-property staff-symbol 'color))
(radius (ly:staff-symbol-staff-radius grob))
(line-thickness (ly:staff-symbol-line-thickness grob)))
(set! staff-extent (ly:staff-symbol::height staff-symbol))
(if (and (eq? bar-line-color staff-color)
radius)
(interval-widen staff-extent
(- 1 (* 1/2 (/ line-thickness radius)))
staff-extent))
#(define-public (bar-line::print grob)
(let* ((glyph (ly:grob-property grob 'glyph-name))
(bar-extent (ly:grob-property grob 'bar-extent '(0 . 0)))
(extent (interval-length bar-extent))
(stencil (if (and (not (eq? glyph '()))
( extent 0))
(bar-line::compound-bar-line grob glyph extent #f
stencil))
#(define (bar-line::simple-bar-line grob width extent rounded)
(let ((blot (if rounded
(ly:output-def-lookup layout 'blot-diameter)
0)))
(ly:round-filled-box (cons 0 width)
(cons (* -0.5 extent) (* 0.5 extent))
blot)))
%%{
#(define (bar-line::tick-bar-line grob height rounded)
(let* ((half-staff (* 1/2 (ly:staff-symbol-staff-space grob)))
(stafflinethick (ly:staff-symbol-line-thickness grob))
(blot (if rounded
(ly:output-def-lookup layout 'blot-diameter)
0)))
(ly:round-filled-box (cons 0 stafflinethick)
(cons (- height half-staff) (+ height half-staff))
blot)))
%}
#(define bar-line-stencil-alist
`((| . thin-stil)
(. . thick-stil)
( . empty-stil)
))
#(define (bar-line::compound-bar-line grob glyph extent rounded)
(let* ((staff-symbol (ly:grob-object grob 'staff-symbol))
(line-count (if (ly:grob? staff-symbol)
(ly:grob-property staff-symbol 'line-count)
0))
(staff-space (ly:staff-symbol-staff-space grob))
(stafflinethick (ly:staff-symbol-line-thickness grob))
(dist (if (or (odd? line-count)
(zero? line-count))
1
(* staff-space (if ( staff-space 2)
2
1/2
(font (ly:grob-default-font grob))
(dot (ly:font-get-glyph font dots.dot))
(segno (ly:font-get-glyph font scripts.varsegno))
(kievan (ly:font-get-glyph font scripts.barline.kievan))
(kern (* (ly:grob-property grob 'kern 1)
stafflinethick))
(thinkern (* (ly:grob-property grob 'thinkern 1)
stafflinethick))
(hair (* (ly:grob-property grob 'hair-thickness 1)
stafflinethick))
(fatline (* (ly:grob-property grob 'thick-thickness 1)
stafflinethick))
(thin-stil (bar-line::simple-bar-line grob hair extent rounded))
(thick-stil (bar-line::simple-bar-line grob fatline extent rounded))
(empty-stil (make-filled-box-stencil (cons 0 0) (cons 0 extent)))
(stencil (assoc-get glyph bar-line-stencil-alist-demo))
(stencil (cond ((equal? glyph |) thin-stil)
((equal? glyph .) thick-stil)
(else empty-stil
stencil))
music = \relative f {
c'4 d e f | f f f f \bar | g g g g \bar . g a b c \bar ||
c c c c \bar ' c b a g \bar |: f e d c \bar |.
}
\score {
\new Staff {
\new Voice { \music }
}
}
\score {
\new Staff {
\new Voice {
\override Staff.BarLine #'bar-extent = #bar-line::calc-bar-extent
\override Staff.BarLine #'stencil
Re: Issue 1320: Rewriting bar-line::print
Marc Hohl m...@hohlart.de writes: Is this a feasible approach? What am I currently doing wrong? #(define bar-line-stencil-alist '((| . thin-stil) (. . thick-stil) ( . empty-stil) )) (thin-stil (bar-line::simple-bar-line grob hair extent rounded)) (thick-stil (bar-line::simple-bar-line grob fatline extent rounded)) (empty-stil (make-filled-box-stencil (cons 0 0) (cons 0 extent))) (stencil (assoc-get glyph bar-line-stencil-alist empty-stil)) ) stencil )) That does not work. stencil is set to a symbol, and that symbol is never converted to a value. When the function is being executed, the _symbols_ thin-stil, stick-stil and empty-stil have long lost any connection with the expressions that they were associated with while the let-statement was being compiled. You could write (local-eval stencil (the-environment)) to let the lexical environment of the function compilation linger over long enough to make this work, but you would earn a reward for the unnecessarily most ugly and unstable code imaginable. Instead, try using a case statement. There is no need to calculate all stencils and throwing most of them away. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FW: [LilyPond] Your organization application has been rejected.
On 16 March 2012 21:45, Janek Warchoł janek.lilyp...@gmail.com wrote: Can you share your thoughts? Lilypond would never be useful for Google products. There is absolutely no point for Google to pay for code that would never be useful for them. Łukasz ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FW: [LilyPond] Your organization application has been rejected.
Łukasz Czerwiński milimet...@gmail.com writes: On 16 March 2012 21:45, Janek Warchoł janek.lilyp...@gmail.com wrote: Can you share your thoughts? Lilypond would never be useful for Google products. There is absolutely no point for Google to pay for code that would never be useful for them. A music search that pops up the first few bars? Quick indexing of the musical content of videos or midi files? Excerpting of Finale files and similar that are free from rendering rights of Finale? Playalong scores for Youtube movies, possibly after uploading the corresponding Midi? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FW: [LilyPond] Your organization application has been rejected.
2012/3/20 Łukasz Czerwiński milimet...@gmail.com: Can you share your thoughts? Lilypond would never be useful for Google products. There is absolutely no point for Google to pay for code that would never be useful for them. The point of GSOC is not to improve google products. See also: http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/faqs#goals -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Countdown to 20120322
For 20:00 MST Thursday, March 22* Critical: Issue 2272 http://code.google.com/p/lilypond/issues/detail?id=2272: Long monosyllabic words collide with barlines - R 5843063 http://codereview.appspot.com/5843063/ Issue 2397 http://code.google.com/p/lilypond/issues/detail?id=2397: Tuplet number incorrectly placed when using additonal articulations - R 5821051 http://codereview.appspot.com/5821051/ Issue 2423 http://code.google.com/p/lilypond/issues/detail?id=2423: lilypond-book fails to include a file from a parent directory - R 5846075 http://codereview.appspot.com/5846075/ Documentation: Issue 2391 http://code.google.com/p/lilypond/issues/detail?id=2391: Add Appendix entry for Predefined Paper Sizes - R 5783075 http://codereview.appspot.com/5783075/ Patch: Issue 2417 http://code.google.com/p/lilypond/issues/detail?id=2417: Patch: Sets lilypond-id message to type progress - R Other: Issue 1690 http://code.google.com/p/lilypond/issues/detail?id=1690: old announcements+changes on website - R 5843069 http://codereview.appspot.com/5843069/ Cheers, Colin * Yes, I noticed the last batch was dated for Tuesday the 21st; we controllers get a wee bit vague about dates when trying to close a month end with a new V-P Finance who cannot resist tinkering! -- We can't solve problems by using the same kind of thinking we used when we created them. -Albert Einstein, physicist, Nobel laureate (1879-1955) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Axis group interface ignores column rank for pure-from-neighbor-interface (issue 5843063)
Yippee; no more grobs getting their pure_height from their neighbors!
Don't forget to update the commit message. You can also edit this
issue to update the title and summary here on Rietveld.
http://codereview.appspot.com/5843063/diff/7/input/regression/pure-from-neighbor-interface-pure-height.ly
File input/regression/pure-from-neighbor-interface-pure-height.ly
(right):
http://codereview.appspot.com/5843063/diff/7/input/regression/pure-from-neighbor-interface-pure-height.ly#newcode1
input/regression/pure-from-neighbor-interface-pure-height.ly:1: \version
2.15.34
.35
The title makes less sense now. lyrics-spanbarstub.ly ?
http://codereview.appspot.com/5843063/diff/7/input/regression/pure-from-neighbor-interface-pure-height.ly#newcode4
input/regression/pure-from-neighbor-interface-pure-height.ly:4: texidoc
= @code{axis-group-interface::pure-height} does not take spanned
The description no longer fits. Maybe
empty measures do not confuse SpanBarStub. These lyrics should remain
clear of the span bars.
http://codereview.appspot.com/5843063/diff/7/lily/item.cc
File lily/item.cc (right):
http://codereview.appspot.com/5843063/diff/7/lily/item.cc#newcode245
lily/item.cc:245: cache_pure_height (Grob::pure_height (this, 0,
INT_MAX));
This commit :
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=9fe7859a8592a080413b744e3768db41059dbfe3
depended on having 'start' and 'end' passed through, so we should put
this back.
Caching in this way assumes that the pure_height of an Item is
independent of where the line-breaks are.
Anything that gets pure_height from its neighbors would break that
assumption, but now it seems there are no such Items, as they all use
pure-from-neighbors-interface to set their extra-spacing-height.
Tied accidentals break that assumption as well, but that's not our
fault. I'll write a cautionary comment in a separate commit.
http://codereview.appspot.com/5843063/diff/7/scm/define-grobs.scm
File scm/define-grobs.scm (right):
http://codereview.appspot.com/5843063/diff/7/scm/define-grobs.scm#newcode1883
scm/define-grobs.scm:1883: (Y-extent . (1 . -1))
I suggest (Y-extent . #f)
because (1 . -1) looks so much like (-1 . 1), and it also makes
suspicious people like me think it is an uncommented magic number.
http://codereview.appspot.com/5843063/diff/7/scm/output-lib.scm
File scm/output-lib.scm (right):
http://codereview.appspot.com/5843063/diff/7/scm/output-lib.scm#newcode437
scm/output-lib.scm:437: (let* ((height (ly:grob-pure-height grob grob 0
1000))
The C code uses INT_MAX to represent the end of the whole score, so it
would be nice to use the same here, if possible.
http://codereview.appspot.com/5843063/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
