Re: Issue 1055 in lilypond: guile 2.0
Comment #21 on issue 1055 by ianhuli...@gmail.com: guile 2.0 http://code.google.com/p/lilypond/issues/detail?id=1055 Patrick, 1+, but . . . Thinking about this some more, when Guile does its build, how does it register the fact that $GUILE_ROOT_MODULE/ice9/xxx.go is related to $GUILE_ROOT_MODULE/ice9/xxx.scm? Then how does it how to load the .go file in preference to the .scm file in the absence of AUTOCOMPILE? Would we have to adjust %LOAD_PATH to include our directory containing our xxx.go files during initialization? Cheers, Ian Hulin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1396 in lilypond: Enhancement: an option to turn unterminated ties into slurs
Comment #7 on issue 1396 by reinhold.kainhofer: Enhancement: an option to turn unterminated ties into slurs http://code.google.com/p/lilypond/issues/detail?id=1396 Here's a patch to at least print out a warning and inform the user that a tie could not be created. Otherwise the user will usually not notice that anything is wrong with the input at all... http://codereview.appspot.com/3310042 ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.13.40 regtests
"Neil Puttock" wrote in message news:aanlktim-yd06h47zrvofpp-_qnrm_rwobnfoutokm...@mail.gmail.com... On 24 November 2010 15:47, Phil Holmes wrote: > So if a completely new bit of graphics appears, the regtest checker > wouldn't > spot it? Not sure that's too good. It might not, depending on whether the new grob influences bounding boxes for other grobs. > What's the checker written in? Python: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=scripts/build/output-distance.py Cheers, Neil It wouldn't take me long to write a C# program (less than a day, I'd guess) that reproduced quite a lot of the regtest checker functionality and did a pixel-by-pixel check for image changes. I've done the latter bit in about 20 minutes on the figured bass png that started this discussion. The difference file it produces is attached. I'd be quite happy to do this, but wouldn't do it if it was felt to be stepping on other toes. I don't know python well enough to try looking at the existing file. I realise this couldn't be run as part of the build process, since it's windows only, but I'd be happy to run it locally and when I shuffle off the coil others _could_ do the same. Not suggesting replacing the current checker - adding to it. -- Phil Holmes Bug Squad <>___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.13.40 regtests
On 25 November 2010 17:45, Phil Holmes wrote: > It wouldn't take me long to write a C# program (less than a day, I'd guess) > that reproduced quite a lot of the regtest checker functionality and did a > pixel-by-pixel check for image changes. I've done the latter bit in about > 20 minutes on the figured bass png that started this discussion. That looks interesting, though I assume you wouldn't be doing pixel-by-pixel checks on every pair of images (far too costly in terms of computational load and time taken). Cheers, Neil ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.13.40 regtests
On Thu, Nov 25, 2010 at 05:45:36PM -, Phil Holmes wrote: > It wouldn't take me long to write a C# program (less than a day, I'd > guess) that reproduced quite a lot of the regtest checker > functionality and did a pixel-by-pixel check for image changes. Hmm. It shouldn't take a huge amount of time to compare each pair of regtest images -- they're named, so you'd be comparing something like 500 pairs of .png images. (Neil: were you thinking of something else?) The bigger concern is about false positives. If your program notified you about any pair of images with any pixel differences, you'd be swamped with meaningless changes. Our regtest checker does some kind of thresholding which doesn't display significantly changed images, but I'm not certain how that works. I don't think you can just look at the number of changed pixels. A tiny change to spacing could give you a huge number of changed pixels [which wasn't important], while a missing augmentation dot [a serious problem] would only give you a tiny number of changed pixels. Then again, we're not talking about relying on this new checker exclusively, and the current system isn't perfect either. I don't think that using both systems would add a huge amount of extra time to the Bug Squad duties. > I've done the latter bit in about 20 minutes on the figured bass png > that started this discussion. The difference file it produces is > attached. I'd be quite happy to do this, but wouldn't do it if it > was felt to be stepping on other toes. I don't know python well > enough to try looking at the existing file. I realise this couldn't > be run as part of the build process, since it's windows only, but > I'd be happy to run it locally and when I shuffle off the coil > others _could_ do the same. You wouldn't be stepping on toes, but writing it in C# introduces a few inefficiencies, which you noted: - can't be added to the build process. (no, I cannot forsee ever adding mono to gub) - most developers can't use it [without installing mono]. I have two alternate suggestions: 1) write it in C#, then add a Frog tracker issue to port it to python. If there's an existing, working, program, then writing a python version would be easier. 2) treat this as a long-term project, and slowly write a python version yourself. We use python a lot in lilypond, and it's quite a nice and easy-to-learn language, so learning python could have other benefits down the road. (potentially in your daily job, in addition to lilypond stuff) I'm *not* suggesting that you try to modify the existing python script or the build process -- writing a separate python script to do your comparison would be much easier. Once such a script exists, it could be merged into the build process relatively easily. Cheers, - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.13.40 regtests
On 26 November 2010 00:00, Graham Percival wrote: > Hmm. It shouldn't take a huge amount of time to compare each pair > of regtest images -- they're named, so you'd be comparing > something like 500 pairs of .png images. (Neil: were you thinking > of something else?) I think this would be very slow unless it does something similar to ouput-distance.py to reduce the number: you don't want to be comparing every single pair unless absolutely necessary. While test bugfixes, I've occasionally produced regression checks which have affected lots of tests, and the time for `make check' in such cases rises drastically (from about five minutes to over half an hour), so unless Phil's pixel-by-pixel comparison is much faster than `compare', it's still going to be too slow. Cheers, Neil ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.13.40 regtests
On Fri, Nov 26, 2010 at 12:14:17AM +, Neil Puttock wrote:
> On 26 November 2010 00:00, Graham Percival wrote:
>
> > Hmm. It shouldn't take a huge amount of time to compare each pair
> > of regtest images -- they're named, so you'd be comparing
> > something like 500 pairs of .png images. (Neil: were you thinking
> > of something else?)
>
> I think this would be very slow unless it does something similar to
> ouput-distance.py to reduce the number: you don't want to be comparing
> every single pair unless absolutely necessary.
Hmm. Average png is, what, 400x50 pixels? 20kb? So the program
needs to load 40kb from disk, then do 20,000 comparisons between
pixels. We have roughly 500 regtests, so that gives us 10 million
pixel comparisons.
I wouldn't have thought that this would be a problem for a modern
computer, but I must admit that I've never done any graphics
processing. But if the pixels are in RGB format, then my first
guess would be to compare each color format, and see if the
numbers differ by more than a certain amount. Something like
int changed = 0;
for (int c=0; c<2; c++) {
if (abs(first.color[c] - second.color[c]) > 0.0001) {
changed = 1;
}
}
Running that code 30 million times shouldn't take too long. I
think? I might be off by an order of magnitude, but my violin
physical modeling can generate 30 seconds of audio (that's 1.3e6
samples) in less than 2 seconds of wall-clock, and computing each
audio sample is a lot more complicated than the above code.
Granted, the violin stuff is C++ code, so I'd expect python or C#
to be slower.
My main concern is still with false positives.
> While test bugfixes, I've occasionally produced regression checks
> which have affected lots of tests, and the time for `make check' in
> such cases rises drastically (from about five minutes to over half an
> hour), so unless Phil's pixel-by-pixel comparison is much faster than
> `compare', it's still going to be too slow.
Oh, I was only thinking about this being used for special cases
and in the release-build process. I don't think we need to add
this to the usual "make check".
Cheers,
- Graham
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1428 in lilypond: \book cannot contain \bookpart identifier
Status: Accepted
Owner:
Labels: Type-Defect Priority-Critical
New issue 1428 by n.puttock: \book cannot contain \bookpart identifier
http://code.google.com/p/lilypond/issues/detail?id=1428
Placing a \bookpart identifier inside \book causes a segfault:
\version "2.13.41"
mypart = \bookpart {
\relative c' {
c1
}
}
\book {
\mypart
}
Program received signal SIGSEGV, Segmentation fault.
0x0040bcb1 in ly_cdr (x=0x204) at ./include/lily-guile.hh:199
199 inline SCM ly_cdr (SCM x) { return SCM_CDR (x); }
(gdb) bt
#0 0x0040bcb1 in ly_cdr (x=0x204) at ./include/lily-guile.hh:199
#1 0x0052ec5f in pop_paper (parser=0xae0c80) at lily-parser.cc:275
#2 0x006ea6d8 in yyparse (my_lily_parser=0xae0c80) at parser.yy:669
#3 0x006f5bf2 in Lily_parser::do_yyparse (this=0xae0c80)
at parser.yy:2546
#4 0x0052da75 in Lily_parser::parse_file (this=0xae0c80, init=...,
name=..., out_name=...) at lily-parser.cc:121
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1396 in lilypond: unterminated ties should at least produce a warning.
Updates: Summary: unterminated ties should at least produce a warning. Status: Started Owner: reinhold.kainhofer Labels: -Type-Enhancement Type-Defect Patch Comment #8 on issue 1396 by v.villenave: unterminated ties should at least produce a warning. http://code.google.com/p/lilypond/issues/detail?id=1396 Thanks! I'm reopening this issue until your patch gets applied. (Graham: I know. Bring it on. :-) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Redefining stencils in 'tweaks causes grobs to be printed twice
On Thu, Nov 25, 2010 at 1:06 AM, Neil Puttock wrote:
> #
> #
>
> When a DynamicLineSpanner is created, it gets its event-cause from the
> dynamic grob which triggered its creation:
>
> 98 Dynamic_align_engraver::acknowledge_dynamic (Grob_info info)
> 99 {
> 100 Stream_event *cause = info.event_cause ();
> 101 create_line_spanner (cause);
>
> I think the only thing we can do here to prevent the 'tweaks setting
> from ending up in the DynamicLineSpanner is to change the event-cause
> to the grob instead.
Are you implying that an AbsoluteDynamicEvent, even when not preceded
with a CrescendoEvent, still creates a DynamicLineSpanner? That looks
odd. (Or perhaps I misunderstood?)
Cheers,
Valentin.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.13.40 regtests
On Thu, Nov 25, 2010 at 12:45 PM, Phil Holmes wrote: > It wouldn't take me long to write a C# program (less than a day, I'd guess) > that reproduced quite a lot of the regtest checker functionality and did a > pixel-by-pixel check for image changes. I've done the latter bit in about > 20 minutes on the figured bass png that started this discussion. The It would take me about 10 seconds; imagemagick has this functionality built in (the same one that is used to generate the current images of the regtest). http://www.imagemagick.org/script/compare.php?ImageMagick=cnagfba00ks4srknf1dt82ldo3 The reason I did not do it originally is that it moves the comparison farther away from lilypond itself and pixel-per-pixel changes are not calibrated for the size of the symbols: a large symbol moving place will generate a much higher difference score than a small score. It might have been a quicker way to get started with running comparison tests. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.13.40 regtests
On Fri, Nov 26, 2010 at 02:15:22AM -0500, Han-Wen Nienhuys wrote: > The reason I did not do it originally is that it moves the comparison > farther away from lilypond itself and pixel-per-pixel changes are not > calibrated for the size of the symbols: a large symbol moving place > will generate a much higher difference score than a small score. It > might have been a quicker way to get started with running comparison > tests. True, but at the moment there's no way to catch problems due to ghostscript (or international fonts being installed / not being installed in GUB). Of course, hopefully GUB won't be changing all that often, but it _does_ happen. Would it be possible to have both kinds of regtest comparisons? Maybe not enabled in the usual "make check", but adding a separate "make pixelcheck" or something like that? Cheers, - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.13.40 regtests
On Fri, Nov 26, 2010 at 2:21 AM, Graham Percival wrote: > On Fri, Nov 26, 2010 at 02:15:22AM -0500, Han-Wen Nienhuys wrote: >> The reason I did not do it originally is that it moves the comparison >> farther away from lilypond itself and pixel-per-pixel changes are not >> calibrated for the size of the symbols: a large symbol moving place >> will generate a much higher difference score than a small score. It >> might have been a quicker way to get started with running comparison >> tests. > > True, but at the moment there's no way to catch problems due to > ghostscript (or international fonts being installed / not being > installed in GUB). Of course, hopefully GUB won't be changing all > that often, but it _does_ happen. > Would it be possible to have both kinds of regtest comparisons? > Maybe not enabled in the usual "make check", but adding a separate > "make pixelcheck" or something like that? It should be trivial to add an imagemagick call to do pixel by pixel comparision to output-distance.py -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
