Re: critical issues
> Look, we simply *cannot* offer users anything that would be > "reasonable" by most standards. We have "highly embarrassing" bugs > from 2006 that we're not even *pretending* to be working on. We've > been in "release crunch" mode for at least six months. The only > glimmer of hope on the horizon is that, under the most strict > interpretation of "critical regression", almost none of those bugs > were introduced recently. So there's a chance that once we "catch > up" on the old critical regressions, we won't have many new ones, > and thus we can move forward with a stable foundation. What we would need is a payed full-time developer. However, this is expensive. Assuming that the programmer has a family with children, an appartment, etc., and to provide a reasonably good living for him or her, this would be about 3000 Euros a month here in Austria or Germany (one third of the amount would immediately vanish as taxes and social security payments). But maybe there is a group of LilyPond philanthropists who can afford this and are willing to do so... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
> What we would need is a payed full-time developer. I have forgotten to say that such a developer needs certain skills in addition to C++ and Scheme, namely being a musician... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
On Sat, Jan 01, 2011 at 09:10:49AM +0100, Werner LEMBERG wrote: > What we would need is a payed full-time developer. That could help. Or at least having a sponsorship page up, which brings us back to the GOP policy list and the current decision not to begin discussing those until we've gotten 2.14 out the door. > But maybe there is a group of LilyPond philanthropists who can afford > this and are willing to do so... I'm not optimistic about that; I think a more realistic opportunity would be to get some grant money from some artistic organization. Either a music-composition grant (of which a composer might dedicate x% towards lilypond sponsorship), or an art history / research grant. I think the latter is more likely... for example, if somebody got a grant to typeset 17th century Norweigan folk songs, and decided to use lilypond, and spent x% of the grant towards "improving community-oriented tools for folk music archival", etc. Of course, writing artistic and research grants is a non-trivial amount of work, and it's hardly guaranteed to have any results. But I think that with the right angle -- be that "collaborative folk music archival", or "high-quality, specialized music notation", or "educational software for cheap 3rd-world donated computers", I could imagine getting a grant. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
> I'm not optimistic about that; I think a more realistic opportunity > would be to get some grant money from some artistic organization. Mhmm. `Programming' in its broadest sense is research, thus getting grants limits the number of persons enormously. However, the number of music researchers (this is, persons who work in the academical field and who can actually apply for a grant) who can program is very limited, I believe. And normally, grants are always too limited to be shared with external resources... In particular, grants are not applicable by persons like me who are musicians and not music researchers. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
Graham Percival wrote Saturday, January 01, 2011 7:16 AM Nope, for precisely the reason you gave earlier: our documentation generally has zero input from programmers, so it's not at all a good representation of "what's intended". We have a set of "intended to be working" examples. They're called the regression tests. No more, no less. If a patch breaks those, then we reject the patch. If we notice in time. Look, we simply *cannot* offer users anything that would be "reasonable" by most standards. [snip persuasive argument] You're right (as usual :) In our circumstances we must be pragmatic. I think our best bet is: 1. stabilize and release 2.14, using the most restrictive interpretation of "stabilize" and "critical issue" we can. 2. drastically reduce (or abandon entirely) development for 3 months while we sort out the GOP policy questions (many of which should ease future development) 3. start picking up the pieces and try to recruit more contributors. OK, I can go along with this. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
2011/1/1 Werner LEMBERG : > What we would need is a payed full-time developer. However, this is > expensive. Assuming that the programmer has a family with children, > an appartment, etc., and to provide a reasonably good living for him > or her, this would be about 3000 Euros a month here in Austria or > Germany (one third of the amount would immediately vanish as taxes and > social security payments). > > But maybe there is a group of LilyPond philanthropists who can afford > this and are willing to do so... I'd gladly help with that, however my input would be limited :( Let's say 15 euro/month. Now let's find another 200 people like me :-| yours Pondly, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
On Sat, Jan 01, 2011 at 09:39:37AM +0100, Werner LEMBERG wrote: > > > I'm not optimistic about that; I think a more realistic opportunity > > would be to get some grant money from some artistic organization. > > Mhmm. `Programming' in its broadest sense is research, thus getting > grants limits the number of persons enormously. However, the number > of music researchers (this is, persons who work in the academical > field and who can actually apply for a grant) who can program is very > limited, I believe. And normally, grants are always too limited to be > shared with external resources... ? Hiring outside talent is not unusual for Canadian and UK research grants. A music professor using part of a grant to hire a programmer (generally to do the "technical side" of an electroacoustic composition), or an engineering professor using part of a grant to hire professional musicians to perform something (which he will then analyze), is entirely normal. I readily acknowledge that writing grant applications is a very specific skill -- each granting agency wants to see something slightly different in its applications; a perfect application for one agency might be a terrible application for another one. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
"Keith OHara" writes: > On Fri, 31 Dec 2010 16:31:23 -0800, Trevor Daniels > wrote: >> ... the concern I had was this. Quite a lot of the >> documentation was written, not by inspecting the code >> to see what was intended, but by experimenting and >> writing up what was found. I certainly worked that >> way, and I think Mark and Keith did recently in >> documenting the new spacing stuff. > > Pretty much. If it makes you feel better, I did read a fair bit of > the code to help build up a mental model of how things worked. The problem is that one is documenting the implementation, not the designed interface. Which is fixating things at the wrong end of the stick: the implementation should be free to gravitate towards its best state without having to change the documentation and/or the interface. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond too noisy on the cmd line
Hello all! First is first: thanks for a great piece of software. This is a long standing feature request for me which you probably got from hundreds of other users but I sent it anyway since I see it as a major pain. When I run lilypond it is too noisy. It prints out lots of stuff (version, progress and more) to standard error. This has several problems: - It does not allow me to differentiate between good messages and bad. The basic idea of standard output and error was to enable such a distinction. Lilypond does away with this. - Since I build lots of lily files in a makefile then I do not wish to see any of the progress, version and standard messages, as I only want to see real errors if they occur. This forces me to wrap lilypond invocation in a script which collects it's output, waits for the return code and in the case that the return code indicates an error with the lilypond process (probably parsing error) then I print out the output which is still too verbose because it contains a lot more than the errors. - Other translators or even huge compilers (gcc to name famous ones) manage to remain silent even though they do quite a lot under the hood so this is not an unreasonable request. Suggestions: - version, progress and general messages which are not error messages should go to stdout and NOT stderr. - a --quiet flag should be added to shut down all of the regular messages which are not error messages (meaning those going to stdout). - In the long run I suggest that --quiet become the default since that is how most compilers/translators behave (do their work quietly unless errors occur or verbose mode is requested). Please reply to my email as I am not a subscriber. Cheers, Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
Graham Percival writes: > In my idle moments, I like to discourage myself by trying to > figure out how long it would take to achieve something > "reasonable" for users. Let's play this game now, and start > making some unrealistic-but-just-possible assumptions: > 1. "reasonable" means 100 bugs. Let's also assume that these can > be the 100 most problematic bugs (i.e. we can fix the easy ones > first without penalizing this "reasonable" goal). > 2. with the new lilydev iso, we can gather 10 new programmers. > Keith, Phil, Janek, etc. > 3. each of those 10 programmers can fix an average of 1 issue > every 10 days. By "fix", I mean "understand the problem, read the > code, produce patches for review, respond to comments, make new > drafts, and have somebody push the final fix". > 4. the existing developers are capable of doing all the reviewing > for all these patches. > 5. we continue to get approximately 1 new issue every 3 days. That's developing logistics for pails in order to deal with an unfinished roof because nobody remembers where the trapdoor to the attic was. The number of bugs is not the problem. The problem is that the skills needed to deal with the bugs and other problems are not in a sensible relation to the complexity of the bugs. A _sensible_ investment of time would be to move a considerable number of engravers to Scheme. And keep them _there_ rather than just doing it as an example. Presto, we get a bunch of code (_iff_ the style of Scheme is not wallowing inscrutably in macros and idiosyncrasies like some of the C++ code) that can be maintained with more confidence than "poke with a stick and see what happens". Then the roof at least leaks in accessible places. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond too noisy on the cmd line
On Sat, Jan 01, 2011 at 09:49:10AM +, Mark Veltzer wrote: > - version, progress and general messages which are not error messages should > go > to stdout and NOT stderr. Good point; I've added this as http://code.google.com/p/lilypond/issues/detail?id=1468 > - a --quiet flag should be added to shut down all of the regular messages > which > are not error messages (meaning those going to stdout). http://code.google.com/p/lilypond/issues/detail?id=1074 Patches appreciated. Unfortunately I doubt that anything will happen unless you personally work on it, but it's "on the books". Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond too noisy on the cmd line
Mark Veltzer writes: > First is first: thanks for a great piece of software. > > This is a long standing feature request for me which you probably got from > hundreds of other users but I sent it anyway since I see it as a major pain. > > When I run lilypond it is too noisy. It prints out lots of stuff (version, > progress and more) to standard error. This has several problems: > > - It does not allow me to differentiate between good messages and > bad. The basic > idea of standard output and error was to enable such a distinction. No. The basic idea is that standard output contains output for further processing stages, while standard error contains diagnostic output intended for human consumption. > Suggestions: > - version, progress and general messages which are not error messages should > go > to stdout and NOT stderr. No, that is nonsense. > - a --quiet flag should be added to shut down all of the regular > messages which are not error messages (meaning those going to stdout). Progress messages don't belong on any output as long as verbose output has not explicitly been requested. > - In the long run I suggest that --quiet become the default since that > is how most compilers/translators behave (do their work quietly unless > errors occur or verbose mode is requested). The difference between "quiet" and normal mode should mostly be that startup and finishing messages are omitted. "quiet" is for the situation where any console output is an indication of a problem. The normal output should not be significantly more verbose than that. On a console not in quiet mode, a self-erasing progress bar or status display that does not take any permanent space is nice to have. But all material that remains permanently on-screen (and scrolls off it) should, apart from startup and finishing messages, be an indication of a problem. At least that's the usual stderr philosophy. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
Graham: > On Sat, Jan 01, 2011 at 09:10:49AM +0100, Werner LEMBERG wrote: ... > > But maybe there is a group of LilyPond philanthropists who can afford > > this and are willing to do so... > I'm not optimistic about that; I think a more realistic > opportunity would be to get some grant money from some artistic > organization. ... > > Of course, writing artistic and research grants is a non-trivial > amount of work, and it's hardly guaranteed to have any results. > But I think that with the right angle -- be that "collaborative > folk music archival", or "high-quality, specialized music > notation", or "educational software for cheap 3rd-world donated > computers", I could imagine getting a grant. In Uppsala there is one person at the music institution who is interested in Schenker analysis. Could that be a lead? Regards, /Karl Hammar - Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: default .ly file in Windows Install seems to be
- Original Message - From: "Jonathan Kulp" To: "Graham Percival" Cc: "James Lowe" ; Sent: Saturday, January 01, 2011 1:33 AM Subject: Re: default .ly file in Windows Install seems to be On Fri, Dec 31, 2010 at 5:59 PM, Graham Percival wrote: On Wed, Dec 29, 2010 at 11:30:29AM +, James Lowe wrote: I have just downloaded and installed the windows version of 2.13.44-1 and the 'welcome to lilypond' default file seems to have completely changed. I can't reproduce on linux with wine; the initial file looks like normal to me, and the ly/welcome_to_lilypond.ly file is still present in the uncompressed exe, and has the contents I expect. I can test it here if you want me too, but I don't know what it was supposed to look like in the first place. I don't think I've ever seen it. Jon -- I've got 13.44 installed on native windows (Vista Home Premium, 64 bit). When I double click the LilyPond icon on the desktop, I get a "Welcome to LilyPond" file displayed in LilyPad. I think this is the first time I've ever done this -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond too noisy on the cmd line
Hello all, This is in response to David Kastrup. - startup and shutdown messages. These are not usually omitted to stderr, or at least 99.99% of the tools out there do not do it. Most tools actually *have no* startup and shutdown messages. If you have other info then I'd appreciate a list of famous tools which emit startup and shutdown messages to stderr (and I'm not talking about daemons but regular command line tools). I doubt that you will find any and most of the ones which you will find will have bug reports filed against that behavior. To prove my point here is gcc: m...@cantor:~$ gcc -o test.o test.c m...@cantor:~$ No startup/shutdown messages. No version. No progress. Quiet and nice. This is the default behavior as no --quiet flag was required to enforce it. Compare this to the lilypond behavior: m...@cantor:~/links/lilypond$ lilypond test.ly > out GNU LilyPond 2.12.3 Processing `test.ly' Parsing... Interpreting music... [8][16][24] Preprocessing graphical objects... Interpreting music... MIDI output to `test.midi'... Finding the ideal number of pages... Fitting music on 1 page... Drawing systems... Layout output to `test.ps'... Converting to `./test.pdf'... m...@cantor:~/links/lilypond$ Wow! This is all standard error messages (as the redirection above proves) and none of these are errors. - stderr is called stderr and not stddiag since it is intended for errors. I agree that stdout is intended for further processing but lilypond *does not* create any further data for further processing so stdout could be used for version and other stuff much like other tools. To prove my point here are a bunch of tools: m...@cantor:~$ ls --version > out m...@cantor:~$ grep --version > out m...@cantor:~$ nm --version > out m...@cantor:~$ gcc --version > out m...@cantor:~$ as --version > out m...@cantor:~$ make --version > out m...@cantor:~$ ld --version > out m...@cantor:~$ The list could go on and on. This output proves that version info goes to stdout and not stderr and that stderr is quiet *all the time* unless errors occur. No startup message. No shutdown message. No progress reports. No "mighty gcc version 4.5 was here" messages. In summary: stderr is for *errors* and not *diagnostics*. Seeing two pages of data in stderr (which is the current situation by the way) is absolutely counter productive. It may be cool for developers who want to understand where a problem occurs but it is useless to users. If someone has to suffer from supplying an extra flag it should be the developers and not the users (as a general rule). This is actually what forces every big project that I saw to wrap the lilypond executable with a script (which is really bad!). All that being said I don't really care about version info, startup and shutdown messages and the rest at all - You can keep directing them to stderr if you feel like it - *just as long as they stay out of my way* - meaning that I have an easy to use option to disable them. The current implementation has no option to keep them out of my way and this option should actually be the default (as demonstrated for all the standard tools above). And again, there is also progress data there so what is the end result? When compiling 20 big lily files which are perfectly fine I'm getting 10 pages of output which is useless to me since I have no mental wish to process it instead of 20 lines of compilation. I'm solving this with a wrapper that hides this useless output from me but I expect every serious lilypond user has written a wrapper for him/her self. Cheers, Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond too noisy on the cmd line
Hi, On Sat, 1 Jan 2011 10:19:18 + Graham Percival wrote: > On Sat, Jan 01, 2011 at 09:49:10AM +, Mark Veltzer wrote: > > - version, progress and general messages which are not error > > messages should go to stdout and NOT stderr. > > Good point; I've added this as > http://code.google.com/p/lilypond/issues/detail?id=1468 > > > - a --quiet flag should be added to shut down all of the regular > > messages which are not error messages (meaning those going to > > stdout). > > http://code.google.com/p/lilypond/issues/detail?id=1074 > Patches appreciated. Unfortunately I doubt that anything will > happen unless you personally work on it, but it's "on the books". This is something I'd be interested in jumping in on. I've more-or-less already done it in my sandbox. Question: Should the be_verbose_global variable control this? I'm not sure a new command line argument is really needed as long as it is agreed upon what verbose is and isn't. I added a be_quiet_global in my sandbox but reading the thread makes me think that simplification is needed and not an expansion. David ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond too noisy on the cmd line
Mark Veltzer writes: > - stderr is called stderr and not stddiag since it is intended for errors. I > agree that stdout is intended for further processing but lilypond *does not* > create any further data for further processing so stdout could be used for > version and other stuff much like other tools. To prove my point here are a > bunch of tools: > m...@cantor:~$ ls --version > out > m...@cantor:~$ grep --version > out > m...@cantor:~$ nm --version > out > m...@cantor:~$ gcc --version > out > m...@cantor:~$ as --version > out > m...@cantor:~$ make --version > out > m...@cantor:~$ ld --version > out Uh, the _output_ is defined to be the version info in this case. In a similar vein, for all those tools specifying bad options results in a an error message and a list of all possible options on stderr -- diagnostic output. In contrast, calling them with --help tells you all possible options on stdout -- regular and intended output. So your contention that "stdout is used for version and other stuff much like other tools" is just wrong. stdout is used for the requested output. If you ask for version info or help, the version info or help _is_ the requested output. If you don't ask for it, it isn't. And the given tools (namely GNU tools) consistently distinguish those two cases, contrary to what you claim. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Updates to bagpipe.ly
On 31 December 2010 23:53, Graham Percival wrote:
> On Thu, Dec 30, 2010 at 05:35:43PM +0100, Sven Axelsson wrote:
>> Perhaps a starting point would be if someone could have a look at what
>> I'm doing in https://github.com/svenax/bagpipemusic/. The relevant
>> file is bagpipe_new.ly, and there are lots of examples on how to use
>> it in the repo as well.
>>
>> The new mode is not backwards compatible with the old one, so I would
>> have to include some convert-ly rules if approved.
>
> Are there any parts of your new file that can be added without
> tweaking the score and layout? If so, why not prepare a patch for
> those "un-controversial" parts, and get those accepted first?
>
> Are your layout tweaks any less severe than stuff we do for
> gregorian? If so, that could be a good reason to accept them. If
> not, you could just make a few macros which do the tweaks, so that
> users only have to do
> \include "bagpipe.ly"
> \paper {
> \bagpipeSpacing
> }
Quite correct. Here's a patch that only introduces the improved
gracenote spacing and adds a few more complex grace notes. That should
be fairly uncontroversial I believe.
http://codereview.appspot.com/3825043
--
Sven Axelsson
++[>++>+++>++>++
><-]>.+..>+.>+.<<-.>>+.>.<<.
+++.>-.<<++.>>.<++.>>>++..>>.<.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
issue 1464 (was: a plea to new contributors)
On Sat, Jan 01, 2011 at 06:51:49AM +, Graham Percival wrote:
> The next step in issue 1464 is just to create a backtrace.
See the blurb below this mail (no, I'm not going to sign up at google
for adding it there).
I don't know why gdb doesn't find paper-column.hh, but anyaway...
it looks like Item::get_column() returns NULL, because its parent's
get_column() returns NULL (I checked that the parent on the X_AXIS
itself is not NULL).
{ = {_vptr$Grob = 0x7e75b0, static smob_name_ = 0x7e4af3
"Grob", static smob_tag_ = 16767, self_scm_ = 0x214b69740,
protection_cons_ = 0x404, dim_cache_ = {{extent_ = 0x0, offset_ =
0x0, parent_ = 0x210133500}, {extent_ = 0x0, offset_ = 0x0, parent_
= 0x210133000}}, layout_ = 0x20f3c7880, original_ = 0x0,
immutable_property_alist_ = 0x21504cf40, mutable_property_alist_ =
0x214b64db0, object_alist_ = 0x214b60600, interfaces_ = 0x214fcdfc0,
static x_parent_positioning_proc = 0x20f176600, static
y_parent_positioning_proc = 0x20f175a10, static stencil_height_proc
= 0x20f174960, static stencil_width_proc = 0x20f177520, static
interface_symbol_ = 0x210c36d40}, broken_to_drul_ = {array_ =
{0x210124900, 0x210124d00}}, static interface_symbol_ = 0x210c3a560,
cached_pure_height_valid_ = false, cached_pure_height_ =
{> = {array_ = {0, -0}}, }}
And here's the parent in question (*this->dim_cache_[0].parent_):
{_vptr$Grob = 0x804c90, static smob_name_ = 0x7e4af3 "Grob", static
smob_tag_ = 16767, self_scm_ = 0x214b69fd0, protection_cons_ =
0x404, dim_cache_ = {{extent_ = 0x0, offset_ = 0x0, parent_ =
0x207824b00}, {extent_ = 0x0, offset_ = 0x2075ae240, parent_ =
0x210133000}}, layout_ = 0x20f3c7880, original_ = 0x0,
immutable_property_alist_ = 0x21504d310, mutable_property_alist_ =
0x2149c7540, object_alist_ = 0x214b63410, interfaces_ = 0x214fcb720,
static x_parent_positioning_proc = 0x20f176600, static
y_parent_positioning_proc = 0x20f175a10, static stencil_height_proc
= 0x20f174960, static stencil_width_proc = 0x20f177520, static
interface_symbol_ = 0x210c36d40}
It could be possible to check the result of get_column() in
Item::spanned_rank_interval(), but I'm not sure wether this is the
*proper* bug fix (nor what interval should be returned in this
case).
Ciao,
Kili
#0 0x0041a7b0 in Paper_column::get_rank (this=0x0) at
paper-column.hh:47
47 paper-column.hh: No such file or directory.
in paper-column.hh
(gdb) bt
#0 0x0041a7b0 in Paper_column::get_rank (this=0x0) at
paper-column.hh:47
#1 0x004ff7b4 in Item::spanned_rank_interval (this=0x210133600) at
item.cc:199
#2 0x0043813b in Axis_group_interface::adjacent_pure_heights
(smob=0x214b64d80) at axis-group-interface.cc:197
#3 0x0002047115cf in scm_dapply () from /usr/local/lib/libguile.so.20.0
#4 0x004e326f in Grob::try_callback_on_alist (this=0x210133000,
alist=0x210133060, sym=0x211eb9b00, proc=0x20f0d13e0) at grob-property.cc:231
#5 0x004e3e9c in Grob::internal_get_property (this=0x210133000,
sym=0x211eb9b00) at grob-property.cc:188
#6 0x00438a04 in Axis_group_interface::begin_of_line_pure_height
(me=0x210133000, start=0) at axis-group-interface.cc:116
#7 0x00438be6 in Axis_group_interface::cached_pure_height
(me=0x210133000, start=0, end=2147483647) at axis-group-interface.cc:95
#8 0x00438ce5 in Axis_group_interface::relative_pure_height
(me=0x210133000, start=0, end=2147483647) at axis-group-interface.cc:263
#9 0x004390c9 in Axis_group_interface::pure_group_height
(me=0x210133000, start=0, end=2147483647) at axis-group-interface.cc:494
#10 0x004f45c1 in Hara_kiri_group_spanner::pure_height
(smob=0x214b64d80, start_scm=0x2, end_scm=0x1fffe) at
hara-kiri-group-spanner.cc:58
#11 0x000204711ca3 in scm_dapply () from /usr/local/lib/libguile.so.20.0
#12 0x000204716c84 in deval () from /usr/local/lib/libguile.so.20.0
#13 0x000204711cbf in scm_dapply () from /usr/local/lib/libguile.so.20.0
#14 0x004e2cd8 in call_pure_function (unpure=0x20f17ab30,
args=0x2149c2960, start=0, end=2147483647) at grob-property.cc:331
#15 0x004e2ff6 in Grob::internal_get_pure_property (this=0x210133000,
sym=0x211ec4be0, start=0, end=2147483647) at grob-property.cc:200
#16 0x004ee4e4 in Grob::pure_height (this=0x210133000,
refp=0x210133000, start=0, end=2147483647) at grob.cc:464
#17 0x0041b49d in get_skylines (me=0x210133f00,
elements=0x7f7e7350, a=Y_AXIS, pure=true, start=0, end=2147483647,
ret=0x7f7e7330) at align-interface.cc:102
#18 0x0041b9c9 in Align_interface::internal_get_minimum_translations
(me=0x210133f00, all_gro...@0x2046169e0, a=Y_AXIS, include_fixed_spacing=true,
pure=true, start=0, end=2147483647)
at align-interface.cc:191
#19 0x0041c25b in Align_interface::get_pure_minimum_translations
(me=0x210133f00, all_gro...@0x2046169e0, a=Y_AXIS, start=0, end=2147483647) at
align-interface.cc:159
#20 0x0041c2f7 in Align_inter
Re: Issue 1268 in lilypond: [PATCH] span-bar problem
hi Joe, >> do you think my patch is a good start? > > Yes, but you need to be careful about what happens when bar-size is set. > Currently, your patch will break (for example) input/regression/drums.ly > because it ignores bar-size. well, I admit I haven't run regtests, but I did now and (having found and fixed an unrelated error) I can see no unintended change (i.e. drums.ly works as before). actually I don't know what to expect with changed bar-size - I attached two more tests: spantest1 is a modification of my original spantest, and the result looks the same; spantest3 is a modification of spantest2, and it's consistent, perhaps even good. >> I removed the center setting code and that >> (with my patch still active) made my example perfect; >> however, the attached complementary test (with bar >> lines only within staff, not between them) failed, >> but it's perfect with current center setting >> (independently whether my original patch is active or not). > > Since Bar_line::compound_barline is used in both BarLine and SpanBar, you > will need to find some solution that works for both cases. It won't be as > simple as just enabling or disabling the centering code. oh, uh. thanks for this hint as well; I'll investigate. p spantest1.ly Description: Binary data spantest3.ly Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue 1464 (was: a plea to new contributors)
On Sat, Jan 01, 2011 at 02:10:04PM +0100, Matthias Kilian wrote:
> I don't know why gdb doesn't find paper-column.hh, but anyaway...
> it looks like Item::get_column() returns NULL, because its parent's
> get_column() returns NULL (I checked that the parent on the X_AXIS
> itself is not NULL).
Bisected to this one (cc'd Neil):
commit 6d28aebbaaab1be9961a00bf15a1ef93acb91e30
Author: Neil Puttock
Date: Mon Sep 6 22:49:28 2010 +0100
Fix metronome alignment.
Don't align on KeySignature unless explicitly requested via
'break-align-symbols and make order of 'break-align-symbols
significant.
* remove `key-signature' from 'break-align-symbols
* acknowledge break_alignment, and set this as X-parent
instead of break_aligned, but only if found break_aligned
is visible
* add regression test to test ordering
* tweak existing test to reflect change in default for
'break-align-symbols
[...]
I tried the diff below, which `fixed' the segfault, but it may be
completely wrong (I'm currently not familiar with the LilyPond code
at all). Unfortunately, I don't have a new enough ImageMagick on my
system, so I can't run the regression tests.
diff --git a/lily/metronome-engraver.cc b/lily/metronome-engraver.cc
index 0a41fc9..e34c0ad 100644
--- a/lily/metronome-engraver.cc
+++ b/lily/metronome-engraver.cc
@@ -95,7 +95,10 @@ Metronome_mark_engraver::acknowledge_break_aligned
(Grob_info info)
&& safe_is_member (g->get_property ("break-align-symbol"),
text_->get_property ("break-align-symbols"))
&& Item::break_visible (g))
-support_ = g;
+{
+ support_ = g;
+ text_->set_parent (g, X_AXIS);
+}
}
void
Ciao,
Kili
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Updates to bagpipe.ly (issue3825043)
looks mostly ok, but I don't know what's up with those beaming rules. http://codereview.appspot.com/3825043/diff/1/ly/bagpipe.ly File ly/bagpipe.ly (right): http://codereview.appspot.com/3825043/diff/1/ly/bagpipe.ly#newcode72 ly/bagpipe.ly:72: #(override-auto-beam-setting '(end * * * *) 1 2 'Staff) err, why are you removing the good beaming rules, and replacing them with old beaming rules? http://codereview.appspot.com/3825043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PDF hyperlinks
On 2010-12-27, at 15:14 , Dan Eble wrote: > Here's some prototype code which works for me in 2.13.9. Correction: 2.13.18. -- Dan ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix 1464 (segfault with R1 and metronome) (issue3858041)
Reviewers: ,
Message:
Fixes a segfault, passes the regtest comparison, code by Matthias
Kilian.
Description:
Fix 1464 (segfault with R1 and metronome)
This code came from Mathias Kilian.
Please review this at http://codereview.appspot.com/3858041/
Affected files:
A input/regression/metronome-multimeasure-rest-no-segfault.ly
M lily/metronome-engraver.cc
Index: input/regression/metronome-multimeasure-rest-no-segfault.ly
diff --git a/input/regression/metronome-multimeasure-rest-no-segfault.ly
b/input/regression/metronome-multimeasure-rest-no-segfault.ly
new file mode 100644
index
..b3def2a59146f56bca113f878a55779dae790641
--- /dev/null
+++ b/input/regression/metronome-multimeasure-rest-no-segfault.ly
@@ -0,0 +1,28 @@
+\version "2.13.44"
+\header {
+ texidoc = "
+A metronome marking can be added to a multimeasure rest whose
+engraver was moved to the Staff, without segfaulting.
+"
+}
+
+
+\score {
+ \new Staff {
+ \tempo 4=150
+ R1 |
+ }
+ \layout {
+ \context {
+ \Score
+ \remove "Metronome_mark_engraver"
+ \remove "Staff_collecting_engraver"
+ }
+ \context {
+ \Staff
+ \consists "Metronome_mark_engraver"
+ \consists "Staff_collecting_engraver"
+ }
+ }
+}
+
Index: lily/metronome-engraver.cc
diff --git a/lily/metronome-engraver.cc b/lily/metronome-engraver.cc
index
0a41fc97abdb61fb1dde875722a7a565716b55a6..e34c0add2e7aefdd174323483967ddf777241990
100644
--- a/lily/metronome-engraver.cc
+++ b/lily/metronome-engraver.cc
@@ -95,7 +95,10 @@ Metronome_mark_engraver::acknowledge_break_aligned
(Grob_info info)
&& safe_is_member (g->get_property ("break-align-symbol"),
text_->get_property ("break-align-symbols"))
&& Item::break_visible (g))
-support_ = g;
+{
+ support_ = g;
+ text_->set_parent (g, X_AXIS);
+}
}
void
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue 1464 (was: a plea to new contributors)
On Sat, Jan 01, 2011 at 08:14:36PM +0100, Matthias Kilian wrote: > On Sat, Jan 01, 2011 at 02:10:04PM +0100, Matthias Kilian wrote: > > I don't know why gdb doesn't find paper-column.hh, but anyaway... > > it looks like Item::get_column() returns NULL, because its parent's > > get_column() returns NULL (I checked that the parent on the X_AXIS > > itself is not NULL). > > Bisected to this one (cc'd Neil): Fantastic! Bisecting is one of the most useful, yet also time-consuming, parts of fixing regressions. > I tried the diff below, which `fixed' the segfault, but it may be > completely wrong (I'm currently not familiar with the LilyPond code > at all). Unfortunately, I don't have a new enough ImageMagick on my > system, so I can't run the regression tests. Sorry, my fault. You can run the regtest comparison is you revert 49dc60e9 , or just remove "-dissimilarity-threshold" from scripts/build/output-distance.py Anyway, this patch works fine in the regtest comparison, so I've uploaded it to reitveld for wider review. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 1290
I have a patch for Issue 1290 that fixes the improper spacing. I am currently doing a regression test. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a plea to new contributors
On Sat, Jan 01, 2011 at 12:21:24PM +0100, m...@apollinemike.com wrote: > > I have a flight on January 4th from London to New York. I would be happy to > devote the entire flight to solving two issues, but I do not want to > duplicate the work of someone else. These are the current Critical issues: http://code.google.com/p/lilypond/issues/list?can=2&q=Priority%3DCritical but Matthias has created a patch for 1464, and Carl is testing a patch for 1290. So the only remaining issue at the moment is 1465: http://code.google.com/p/lilypond/issues/detail?id=1465 I will release the next beta test as soon as I know what's happening with the patches for 1464 and 1290. When people start testing that version, they might discover additional problems, so we might have extra Critical issues before your flight. But at the moment, 1465 looks like the best bet to work on. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue 1464 (was: a plea to new contributors)
On Sun, Jan 2, 2011 at 2:14 AM, Matthias Kilian wrote:
> On Sat, Jan 01, 2011 at 02:10:04PM +0100, Matthias Kilian wrote:
> > I don't know why gdb doesn't find paper-column.hh, but anyaway...
> > it looks like Item::get_column() returns NULL, because its parent's
> > get_column() returns NULL (I checked that the parent on the X_AXIS
> > itself is not NULL).
>
> Bisected to this one (cc'd Neil):
>
>
> commit 6d28aebbaaab1be9961a00bf15a1ef93acb91e30
> Author: Neil Puttock
> Date: Mon Sep 6 22:49:28 2010 +0100
>
>Fix metronome alignment.
>
>Don't align on KeySignature unless explicitly requested via
>'break-align-symbols and make order of 'break-align-symbols
>significant.
>
>* remove `key-signature' from 'break-align-symbols
>
>* acknowledge break_alignment, and set this as X-parent
> instead of break_aligned, but only if found break_aligned
> is visible
>
>* add regression test to test ordering
>
>* tweak existing test to reflect change in default for
> 'break-align-symbols
>
> [...]
>
>
> I tried the diff below, which `fixed' the segfault, but it may be
> completely wrong (I'm currently not familiar with the LilyPond code
> at all). Unfortunately, I don't have a new enough ImageMagick on my
> system, so I can't run the regression tests.
>
> diff --git a/lily/metronome-engraver.cc b/lily/metronome-engraver.cc
> index 0a41fc9..e34c0ad 100644
> --- a/lily/metronome-engraver.cc
> +++ b/lily/metronome-engraver.cc
> @@ -95,7 +95,10 @@ Metronome_mark_engraver::acknowledge_break_aligned
> (Grob_info info)
> && safe_is_member (g->get_property ("break-align-symbol"),
> text_->get_property ("break-align-symbols"))
> && Item::break_visible (g))
> -support_ = g;
> +{
> + support_ = g;
> + text_->set_parent (g, X_AXIS);
> +}
> }
>
In your original backtrace, is the X_AXIS parent of the Item in frame #2
0x0? If so, I'm fine with the patch.
Cheers,
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond too noisy on the cmd line
On Sat, Jan 01, 2011 at 02:25:57AM -0500, David Santamauro wrote: > > On Sat, 1 Jan 2011 10:19:18 + > Graham Percival wrote: > > > http://code.google.com/p/lilypond/issues/detail?id=1074 > > Patches appreciated. Unfortunately I doubt that anything will > > happen unless you personally work on it, but it's "on the books". > > Question: Should the be_verbose_global variable control this? I'm not > sure a new command line argument is really needed as long as it is > agreed upon what verbose is and isn't. > I added a be_quiet_global in my sandbox but reading the thread makes me > think that simplification is needed and not an expansion. Since we already have a be_verbose_global variable, I can't imagine much serious objection to having a be_quiet_global. My initial guess would be that we want three different types of output: - verbose - normal - quiet However, this is definitely outside my depth. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Broken Link in CG to http://kainhofer.com/~lilypond/linkdoc/
On Fri, Dec 31, 2010 at 03:38:47PM +, James Lowe wrote: > In CG 5.4.3 Checking Cross References there is a para that refers to Thanks, added as http://code.google.com/p/lilypond/issues/detail?id=1469 Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
On Sat, Jan 01, 2011 at 01:06:04PM +0100, Karl Hammar wrote: > Graham: > > Of course, writing artistic and research grants is a non-trivial > > amount of work, and it's hardly guaranteed to have any results. > > But I think that with the right angle -- be that "collaborative > > folk music archival", or "high-quality, specialized music > > notation", or "educational software for cheap 3rd-world donated > > computers", I could imagine getting a grant. > > In Uppsala there is one person at the music institution who is > interested in Schenker analysis. Could that be a lead? I'm not certain that it's worth approaching somebody who doesn't already use lilypond. Also, I don't think it's worth discussing this on the -devel list. If you're interested in organizing this kind of thing, I'd recommend asking on -user. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix Issue 1290 (issue3832046)
Reviewers: ,
Message:
Here is a patch to fix issue 1290.
It works, but it may need to be cleaned up. I'm not sure the code is as
elegant as it could be. I'm not really comfortable with all of the C++
syntax used in lilypond.
Please review it carefully, and let me know how it can be improved.
Thanks,
Carl
Description:
Fix Issue 1290
Create an optional horizontal-padding parameter to Skyline::distance
When horizontal-padding is not zero, padding is added to both systems
when calculating the distance.
Get the System's skyline-horizontal-padding property, and pass
it to distance () in page-layout-problem.cc
Add regression test for this feature.
Please review this at http://codereview.appspot.com/3832046/
Affected files:
A input/regression/skyline-horizontal-padding.ly
M lily/include/skyline.hh
M lily/page-layout-problem.cc
M lily/skyline.cc
Index: input/regression/skyline-horizontal-padding.ly
diff --git a/input/regression/skyline-horizontal-padding.ly
b/input/regression/skyline-horizontal-padding.ly
new file mode 100644
index
..c3e96211304a824c5d8304c2faf43d1b638aa24d
--- /dev/null
+++ b/input/regression/skyline-horizontal-padding.ly
@@ -0,0 +1,20 @@
+\version "2.13.45"
+
+\header {
+ texidoc = "
+The skyline-horizontal-padding property can be set for System
+in order to keep systems from being spaced too closely together.
+In this example, the low notes from a system should not be
+interleaved with the high notes from the next system.
+"
+}
+
+\score {
+\repeat unfold 80 { c' c' }
+ \layout {
+\context {
+ \Score
+ \override System #'skyline-horizontal-padding = #2
+}
+ }
+}
Index: lily/include/skyline.hh
diff --git a/lily/include/skyline.hh b/lily/include/skyline.hh
index
a11b21dde6ce27d06a3e54b177e32940da779589..93b6e1155605d4c03fb8d8b566c40bf8ce80bd6e
100644
--- a/lily/include/skyline.hh
+++ b/lily/include/skyline.hh
@@ -53,7 +53,7 @@ class Skyline
private:
list buildings_;
Direction sky_;
-
+
void internal_merge_skyline (list*, list*,
list *const result);
list internal_build_skyline (list*, Real, Axis,
Direction);
@@ -63,10 +63,11 @@ private:
public:
Skyline ();
Skyline (Skyline const &src);
+ Skyline (Skyline const &src, Real horizon_padding, Axis a);
Skyline (Direction sky);
Skyline (vector const &bldgs, Real horizon_padding, Axis a,
Direction sky);
Skyline (Box const &b, Real horizon_padding, Axis a, Direction sky);
-
+
vector to_points (Axis) const;
void merge (Skyline const &);
void insert (Box const &, Real horizon_padding, Axis);
@@ -74,7 +75,7 @@ public:
void print_points () const;
void raise (Real);
void shift (Real);
- Real distance (Skyline const &) const;
+ Real distance (Skyline const &, Real horizon_padding = 0) const;
Real height (Real airplane) const;
Real max_height () const;
void set_minimum_height (Real height);
Index: lily/page-layout-problem.cc
diff --git a/lily/page-layout-problem.cc b/lily/page-layout-problem.cc
index
673278f69c6fc9490ab118d406610531064b6d9e..c30f43d84a40464278e078313fe34ae0b3d89a9d
100644
--- a/lily/page-layout-problem.cc
+++ b/lily/page-layout-problem.cc
@@ -271,7 +271,7 @@ Page_layout_problem::append_prob (Prob *prob, Spring
const& spring, Real padding
if (sky)
{
- minimum_distance = (*sky)[UP].distance (bottom_skyline_);
+ minimum_distance = (*sky)[UP].distance (bottom_skyline_,
scm_to_double (prob->get_property ("skyline-horizontal-padding")));
bottom_skyline_ = (*sky)[DOWN];
}
else if (Stencil *sten = unsmob_stencil (prob->get_property ("stencil")))
Index: lily/skyline.cc
diff --git a/lily/skyline.cc b/lily/skyline.cc
index
d8105e669b910eaadc3fe8e34286ae9d613c8e50..5283cd25cee6f1bce634269eb0b5fa33e48acd90
100644
--- a/lily/skyline.cc
+++ b/lily/skyline.cc
@@ -119,7 +119,7 @@ Building::precompute (Real start, Real start_height,
Real end_height, Real end)
y_intercept_ = start_height - slope_ * start;
}
-Real
+Real
Building::height (Real x) const
{
return isinf (x) ? y_intercept_ : slope_*x + y_intercept_;
@@ -248,7 +248,7 @@ single_skyline (Building b, Real start, Real
horizon_padding, list *co
-infinity_f, infinity_f));
if (sloped_neighbours)
ret->push_front (b.sloped_neighbour (start, horizon_padding, RIGHT));
-
+
if (b.end_ > start + EPS)
ret->push_front (b);
@@ -367,7 +367,7 @@ Skyline::Skyline ()
Skyline::Skyline (Skyline const &src)
{
sky_ = src.sky_;
-
+
/* doesn't a list's copy constructor do this? -- jneem */
for (list::const_iterator i = src.buildings_.begin ();
i != src.buildings_.end (); i++)
@@ -383,6 +383,26 @@ Skyline::Skyline (Direction sky)
}
/*
+ build padded skyline from an existing skyline with padding
+ added to it.
+*/
+
+Skyline::Skyline (Skyline const &src, Real horizon_padding, Axis a)
+{
+ Real start = -in
Re: Fix Issue 1290 (issue3832046)
I don't know if it's important, but it may be worth mentioning somewhere
that skyline-horizontal-padding works differently for VerticalAxisGroup
and System. (Because in VerticalAxisGroup, skyline-horizontal-padding
takes effect while the outside-staff-grobs are being placed).
http://codereview.appspot.com/3832046/diff/2001/lily/page-layout-problem.cc
File lily/page-layout-problem.cc (right):
http://codereview.appspot.com/3832046/diff/2001/lily/page-layout-problem.cc#newcode274
lily/page-layout-problem.cc:274: minimum_distance = (*sky)[UP].distance
(bottom_skyline_, scm_to_double (prob->get_property
("skyline-horizontal-padding")));
robust_scm2double is probably better
http://codereview.appspot.com/3832046/diff/2001/lily/skyline.cc
File lily/skyline.cc (right):
http://codereview.appspot.com/3832046/diff/2001/lily/skyline.cc#newcode396
lily/skyline.cc:396: if ((i->slope_ == 0) && !isinf (i->y_intercept_) &&
i->y_intercept_ >= 0)
Why restrict to y_intercept_ < 0?
http://codereview.appspot.com/3832046/diff/2001/lily/skyline.cc#newcode398
lily/skyline.cc:398: Interval (i->y_intercept_ < 0 ? i->y_intercept_ : 0
, i->y_intercept_)));
...and if you do restrict to y_intercept_ < 0, then this is redundant.
http://codereview.appspot.com/3832046/diff/2001/lily/skyline.cc#newcode399
lily/skyline.cc:399: Skyline padSky = Skyline (boxes, horizon_padding,
a, (Direction) 1);
pad_sky instead of padSky
UP instead of (Direction) 1
and perhaps a comment about why you need to use UP instead of sky_
(which would seem intuitive)
http://codereview.appspot.com/3832046/diff/2001/lily/skyline.cc#newcode498
lily/skyline.cc:498: const Skyline *padded_other = &other;
I'm not sure, but I think "Skyline const *" is more consistent with the
rest of the code.
http://codereview.appspot.com/3832046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
