Re: developer IRC or skype chat
On 11-06-07 03:28 PM, Graham Percival wrote: Anybody interested in setting up a weekly chat? I'd be in, although 19:00UTC on a weekday does not really work for me. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Coredump and orphan avoidance code.
Hi Han-Wen,
Thank you for pointing out this defect.
I have created patch 4236027 to address it:
http://codereview.appspot.com/4236047
To answer your question, what the "if" was supposed to be doing: the
idea was to guard against the situation where there the whole paragraph
consists of only one line, because a one-line paragraph is allowed to be
orphaned. But what I was not seeing, was that the increment-statement
of the "for" had already advanced "list" to point to EOL by the time we
reached that "if". Quite embarrassing actually.
Boris
On 11-02-22 09:33 AM, Han-Wen Nienhuys wrote:
Hi Boris,
I was looking at why
\markuplines{}
is dumping core, and came across code committed in
commit 4878fcdb04b335041f1440c8d31b0b4b80ecaea9
Author: Boris Shingarov
Prob *ps;
SCM list;
for (list = texts ; scm_is_pair (list) ; list = scm_cdr (list))
...
if (list == texts)
{
complaints:
1. this code leaves ps and list uninitialized. Always initialize *all*
local variables.
2. the if never fires, unless tests==SCM_EOL in the first place
3. Given that the if never fires, do we have a regression test that
covers this code, and are you sure this actually does something
useful?
Can you please fix this, both the esthetics and the functionality; it
is a release blocking problem.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: markup to string function?
On 11-01-26 10:32 AM, Reinhold Kainhofer wrote: I need a function that extracts only the text (in this case "Title of the piece"). Many times, I also find myself in need of such function -- it would be absolutely awesome to have one. I have never gotten around to actually implementing one; but maybe now is the time. Maybe attach an object-property to the markup, called 'text, and then in interpret-markup-list, concatenate them? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
On 11-01-01 03:24 AM, Graham Percival wrote: 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. This is exactly what we have been doing here for a while. In act, it absolutely amazes me how closely you are describing our project. Only 100 years off (16th century instead of 17th), and only a few hundred kilometers off. But as I was trying to explain last summer, there are some problems. The Lilypond project has a very specific set of objectives. There is a defined set of procedures, a roadmap, a set of criteria of what is acceptable to go into the codebase, etc. The music history research project, has its own set of objectives. And its own set of rules. And procedures. And criteria of what is acceptable. When these rules contradict Lilypond rules, I follow the history research project's rules, not the Lilypond project's rules, because it is the music history research project that pays me. How contradictory are these rules, and how big is the problem? Well on one hand, none of today's Critical Issues in Lilypond, are on the list of priorities for our project. So even if we had 20 full-time developers, it wouldn't help with releasing the next stable version. On the other hand, we have implemented some major new functionality. Seamless markup-to-embedded-score integration, automatic endnotes, merging and visual indication of used sources, and a lot of other things. Can it be contributed back? Hardly in its current form. It causes a ton of regressions: basically, it does not work on anything but Gregorian plainchant. It will immediately crash on any piano music or orchestral music. Will I fix it? Not unless someone pays me to, and I know the music historians will not, because they don't care. What they (and your Norwegian friends with their 17th century songs) care about, is whether or not it is possible to typeset Norwegian lyrics. Which it isn't -- and it's not even Lilypond's fault: SRFI-13 in Guile does not work with Unicode. So we have all this work done, but it would be an even bigger effort to merge it back. Who will do it? In the current situation, I don't know. However, I am making aggressive steps to change this. As we attract more attention from serious organizations, we get into position to bring forward some conditions for the next project. Namely, it will become imperative that all contributions get merged back into the community codebase. It still does not mean helping with things like releasing the next stable version of Lilypond, or similarly, with any part of Lilypond agenda; although I am not sure if it is a bad thing -- if we want to transition from being "a volunteer project with limited resources" to "professional open-source", we will need to face the fact that there are things which customers are willing to pay for, and things which no-one finds important enough to either work on themselves or pay for. But first we will have to be successful to engage in the new project. It is still unclear whether it will happen or not. I will keep you posted. Boris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Black mensural notation
This looks like Issue 1098. That one was closed due to lack of reproducible scenario: my scores, too, were crashing Lilypond after growing above a certain size, but just like in your case, I can not reproduce it with a simple \repeat. On 11-01-16 12:57 PM, Benkő Pál wrote: following up myself: [ after complaining about my large scores ] This seems to work (at least, the regtests are OK and it doesn't appear to break the interaction between page-count and systems-per-page): [...] I don't know why, though. :) it works for me in the sense that there's no memory problem, but doesn't work in the sense that now I get an overflow message. those larger scores mean about 30 pages, chunked into 14 \score's. when I comment them out one by one, there's a stage (at about 10 \score's over 27 pages) when compilation with the official version achieves similar results: gets through without swapping but with overflow messages. when compiling, about 30 seconds are needed to reach the "Fitting music on 26 or 27 pages..." message, then for 3 more minutes nothing happens (even memory usage is at the same level (minus a slight increase from 864m to 906mat half time)), then it's over in about 10 seconds. adding one more score induces immediate swapping in the "Fitting music..." stage - I've killed compilation at 44 seconds after eating 3600m. after applying your patch the breaks are different, the overall result is of about the same quality, but the middle section takes 3 seconds instead of minutes. unfortunately I couldn't reproduce this behaviour with a file with \repeat unfold music copy-pasted into 20 \score's. I'll try to understand what goes on, but am not too confident. if needed, I can post my .ly files. p ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Installing ddd on LilyBuntu
On 10-12-12 01:13 PM, Phil Holmes wrote: I thought it'd be interesting to install the ddd graphical debugger on my LilyBuntu instance. I downloaded it OK, but when I run ./configure I get: "configure: error: The X toolkit library '-lXt' could not be found." You are missing the libxt-dev package. But, why do you want to build DDD yourself? If you simply want to use it to debug LilyPond, you can just install it from the repository. A lot easier, and will save you a lot of headache in the future. Also, is there a particular reason to prefer DDD for C++ debugging? I find Eclipse CDT a lot better in any thinkable respect. (But then again, I am biased, being one of the founders of the Eclipse project). ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Simplification of live-elements-list, why not?
On 10-11-16 05:37 PM, Neil Puttock wrote: I'm not sure what I'm guilty of here; in the absence of an exported function which turns grob-arrays into lists (which I did contemplate adding at the time), the code I added seems unobjectionable. That's it: you are basically saying "it's perfect except there is a hugely better way" :-) http://codereview.appspot.com/3104044/ Looks perfect to me. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Simplification of live-elements-list, why not?
On 10-11-14 11:59 PM, Joe Neeman wrote: Any specific reason why not just filter on the is-live? predicate? Doesn't filter just work on plain scheme lists? elements is a grob-array object. Of course, if filter doesn't work on such objects it might be better to write a version of filter rather than replicating it many times. filter works on things that understand car and cdr; which elements clearly doesn't, because it's just a "boxing" wrapper around Grob_array*. What I am doing is go to a list first, and then filtering: (define (live-elements-list me) (filter grob::is-live? (grob-array->list (ly:grob-object me 'elements where grob-array->list is a function which I just made. The reason I am asking, is because even after spending 10 minutes looking at the procedural-style code in the current live-elements-list, I am still not sure what the answer is to the question, "what does this function do?" Does it just filter the elements according to grob::is-live?? Or does it do something more / less / different? Quite seriously, it's just hard to be sure. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Simplification of live-elements-list, why not?
In scm/output-lib.scm, the (internally used) function live-elements-list is defined like this: (define (live-elements-list me) (let* ((elements (ly:grob-object me 'elements)) (elts-length (ly:grob-array-length elements)) (live-elements '())) (let get-live ((len elts-length)) (if (> len 0) (let ((elt (ly:grob-array-ref elements (1- len (if (grob::is-live? elt) (set! live-elements (cons elt live-elements))) (get-live (1- len) live-elements)) Any specific reason why not just filter on the is-live? predicate? Also, is there a real difference between grob::is-live? and ly:is-live? predicates? (I would be inclined to get rid of grob::is-live? version...) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lyrics break estimation of vertical spacing
Please forgive me for bumping this discussion, but I was wondering if Valentin, I am sorry I have disappeared from the Lilypond scene for a while. My work on Lilypond development has been temporarily put on the back burner. Right now, we are concentrating on something slightly different: we are working to secure a very large Lilypond-based contract, for a major series of critical editions by a major publisher (I'm not allowed to divulge any details yet including who the publisher is, but I am sure everyone on this list is familiar with the name). IF we are successful, it will mean a radical breakthrough in acceptance for Lilypond. Some time ago, I was talking about how I wanted to transform Lilypond from "a volunteer project with limited resources" (Graham's definition), into a professional open-source project where at least some of the core people can afford to spend non-trivial amounts of time on their passion. I'll come back as soon as I have something to announce (either good or bad). Boris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: vertical spacing: Rename dimensions. (issue2505041)
But, it breaks all my scores! Those which use the old names, I mean. On 10-10-17 01:20 PM, percival.music...@gmail.com wrote: LGTM, and compiles cleanly from scratch. http://codereview.appspot.com/2505041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On 07/11/2010 07:22 PM, Arno Waschk wrote: Thanks again, that wokrs at least for some displaying, buit still i need that handy conversion from this type of scheme list into something i can deal with with c. Please!!! No, no, the main question is, what are you going to do with that "something"? Ok, the keys are probably Scheme strings, so you can transform them into UTF byte-arrays which you can then feed into functions like "printf". But in Scheme, you frequently work with lists of things (lists themselves, or atoms) -- this is what a "data structure" looks like. So when you say "something i can DEAL with with c", what exactly is this DEALing you want to do? And with which objects? some of them are Scheme wrappers around C structs. For those, there is smob/unsmob. But for true Scheme data structures, you really want to deal with them using Scheme code -- that is, using scm_call_X(), as Carl already suggested. Boris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On 07/11/2010 06:47 PM, Arno Waschk wrote: okay, what are arg1 and arg2, and what is the type of result beyond being called "SCM"? An ID for a Scheme entity. This is a fundamental concept in languages such as Scheme, Smalltalk, Self of Java. The value of the SCM itself is completely opaque to the client of the VM. It can be an index into a table, or it can be a direct address. The entity that it refers to, can in turn be any Scheme object: it can be a pair, or an atom, or the entity may even be immediately encoded in the SCM itself (for example, in Guile, #f is encoded in a special SCM). If you are familiar with JNI, then you can think of SCM as something similar to "jobject". In Smalltalk, the equivalent concept is "OOP". If you want to understand the communication between the Scheme and C++ code, the best reading explaining the underlying concepts are books on implementation of functional programming languages. But any VM book will do just as well (I started from Goldberg&Robson's Smalltalk Blue Book back in 1994; Simon Jones is more directly applicable to Scheme). Boris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Vertical spacing regression !?
On 06/30/2010 01:04 AM, David Kastrup wrote:
until after line-breaking. Also, the vertical collision avoidance means
that in { c1^"long long markup" c1^"long long markup" }, we cannot
calculate the height of the second bar without considering the first bar
too (and the answer will change if they are on different lines).
Maybe I am dull, but we need the line heights (or skyline) for a given
line breakpoint sequence, and a given line breakpoint sequence has a
given skyline for each line.
Correct. And there is O(2^N) breakpoint sequences for N possible
breakpoint places (roughly, for N bars); so we need O(2^N)
heights/skylines and page breakings. The dynamic programming algorithm
deals with this complexity, but even though there are less than O(2^N)
actual configurations to calculate a demerit score for, it is still
prohibitively expensive to perform a full layout every time we need a
demerit score.
Maybe the problem can be alleviated by not associating a fixed line
height/skyline with each bar, but something that is dependent on the
current breakpoint sequence being considered.
Not sure what you mean. We do not and can not have a fixed line height
/ skyline for each bar -- as Joe just explained. For example, consider
music in the G clef; if a particular bar comes after a line break, it
will have a clef, making the bar much taller. So I am not sure what you
have in mind here... something else that I do not see?
Originally, the skyline was approximated by its bounding rectangle. In
other words, there was only one measurement: the "line height". About a
year ago, to address the problem with G clefs, Joe added the distinction
between "begin-" and "rest-of-line", for inter-staff, intra-system
space. (So instead of one point we have two). This worked reasonably
well for music with many staves per system; but for music on one staff
(e.g. instrument parts, or monody) this does no good, because all the
space is inter-system. So about two months ago I introduced the
"begin/rest" distinction for inter-system space (i.e. for computing
pure-height of a whole system). This still left some unaddressed things
like 1062, which is what today's discussion is about.
Boris
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Vertical spacing regression !?
On 06/27/2010 01:25 PM, Joe Neeman wrote: On Sun, 2010-06-27 at 06:56 -0400, Boris Shingarov wrote: > This was discussed on this list only a few weeks ago. I think we are on > our way to get rid of global page*line breaking. Although I am happy to have an option to do full line-breaking before page-breaking, I am very much against getting rid of the line and page-breaking interaction. For example, if we did that then we would have to scrap the new vertical layout since it relies on being able to stretch the systems after the pages are determined. And while I have a personal bias against scrapping the vertical layout (since I wrote it), I do think that it is a big improvement over the previous layout algorithm and I have heard comments to that effect on the lists too. Also, the page-turn-breaker can't function without some interaction between line- and page-breaking. I understand the bad effects of divorcing line- from page-breaking. Another one (of those which I personally care about) is that it will negate the window/orphan handling feature I added. At least to my users, this is important. And yes, I do agree that the new layout algorithm *is* a big improvement over the previous one. But what do we do about the height estimation problems? No matter how important the positive effects of line/page-breaking interaction are, a score with staves cut at the bottom, is unusable. And a score with the opposite problem, is equally unusable. Can we realistically hope to fix enough bugs so that real publications will look usable? I don't know. I started working on the estimations because the user's book suffered the problem. I fixed five, and pulled your fixes for a few. And yet the book is still suffering the same problem. I know what causes it *now*, but I do not know if this is going to be the last one *for this book*, and I am now facing problems of customer value when talking about fixing height estimation bugs. So what are we going to do, keep fixing these bugs, under the theory that there is only finite number of them? One thing that makes me nervous is that a lot of the time the fixes involve increase of computational complexity. We are moving from simple height estimation to more and more complex height estimation; can it be that as we approach being more and more correct in our estimation, the complexity also approaches that of full layout? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Vertical spacing regression !?
Hi Arno, Here are some design remarks about what I understood from my work on the breaker. Hopefully a sum of a few [dozen?] of mails like this will together constitute something to transform into a chapter in the CG... Thanks, I've reverted the patch in the meantime. However, the information that you see in annotate-spacing is actually computed after line-breaking, ok, so why can't it then be taken into account for page-breaking? The problem is that page-breaking does not come *after* page-breaking. Well, conceptually, it sort of does. But the optimization of breaking is global over the product space of all line breaking possibilities by all page breaking possibilities. It is done in the hope to get more optimal breaks. The downside is that we are forced to use "height estimations" instead of real heights of things; otherwise we would need to do page layout for every possible break configuration, which would be prohibitively expensive. This was discussed on this list only a few weeks ago. I think we are on our way to get rid of global page*line breaking. Height estimation is just too inaccurate, so you either have music running off the page at the bottom, or (no less ugly) empty space. We did fix a bunch of height estimation issues, but I do not know how many more are left. This one we are discussing right now, is another example of problem caused by height estimation. Since it more than doubles the computation time (often by far) there must be something redundant, no? No, because the height used in page breaking, is not the actual height; it is just an estimate (often wrong). This is what Joe means when he says, "...and they aren't actually correct to begin with". Boris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Presentation: "Publisher-grade LilyPond" in Ottawa
On 06/09/2010 10:52 AM, David Kastrup wrote: Uh, am I by now in everybody's killfile I do not know why you keep saying these things, but to avoid any misunderstanding I must publicly state that David is in the top half-dozen on *my* list of most respected LilyPond people. On 06/13/2010 09:22 AM, David Kastrup wrote: So if of three examples you give, one is in reference to a posting of mine (and I don't agree with the sentiment of it, but that's a different issue), and two are of postings of mine, it would appear that all Lilypond needs for becoming more developer-friendly would be to get rid of me. David, if what I said made you feel bad, I sincerely apologize. Let me try to clarify what I meant by those quotes: Interestingly, if we mentally take away those postings for a moment, all we then have left is no other help. So, those posts are the only real attempt at an analysis of the problem and possible solutions. So actually, they were the best constructive answer. But that's exactly the problem I am describing: a major critical-edition project asked for a couple of features, offering non-trivial rewards for them, and the best answer was a (very good) technical analysis concluding with an explanation why these features are unworkable. The request, with the bounty offered, did not even make it into the bug-tracker. Neil Puttock writes: "Your post is absolutely unnecessary" http://www.mail-archive.com/lilypond-u...@gnu.org/msg52334.html That comment wasn't directed at Jiříi; it was part of a reply to David Kastrup. I put that link to Jiri's reply, instead of to the original Nicolas' post, for a reason. The post has created the impression for the end-user (willing to pay for development) that it was directed at him; this is proven by the reply. But if you actually look at the _original_ postings from which those quotes from me were pulled, you'll notice that the quotes have been rather carefully pruned in order to construct something unconstructive that has not been there in the original posting. The message I tried to construct, is this: the user's requests did not result in solutions which would help the publication of the book. The user was even under the impression that he was told that his posts were completely unnecessary. Even though your original postings do contain a rather excellent technical analysis of many sides of the problem. If you think this message is "unconstructive" and do not agree with the original postings, tell me how. On 06/13/2010 10:55 AM, Carl Sorensen wrote: Where are the thousands of Euros bounties for the LaTeX-based solution? I'm not aware of *any* thousands of Euros bounties for anything on LilyPond. This is a serious question, not a rhetorical question, by the way. I have looked at the issues with Bounty tags, and the only one I can find that seems to be relevant to this discussion is "support for footnotes and/or endnotes". That issue makes no mention of a LaTeX-based solution. On the mailing list, and when that didn't help, even around a bunch of music-related forums. There were several requests with such bounties. As you just mentioned, none of them even got into the tracker. Boris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Outstanding patches
Hi Joe, Could you send me a list of the unreviewed patches that you have on rietveld? I should have time in the next week or so to review them. This issue is not so much the patches being "unreviewed" but rather "sitting stuck missing an ingredient like a test case". And this is partly a practical and partly a philosophical issue for us here: as I am trying very hard to explain (in the presentation and many posts on the lists), *my* focus is not advancing LilyPond along its main direction (there already is an excellent team doing that), but taking it to other, orthogonal, dimensions -- such as making it useful to a musicologist preparing a major critical edition. In this work, we have our own limitations which make it very difficult to do proper disciplined software development. Right now, when presented with a technical requirement, I have to take the shortest path to satisfy the requirement *for this book only*. I have very limited time to care if the solution breaks all other books. Not that I have a low code standard, but many times I have to consciously go against my own standards. This exercise going against developer values is deliberate. It has to do with being customer-centric vs software-centric. If the solution happens to be close enough to being useful for everybody else (this is what I earlier called "10% extra work to get the patch accepted"), I submit the patch for review. But sometimes, "the shortest way" differs from the "proper" say by 500%; these are the patches I classify within the "future work" category. This is going to change. Hopefully, with the success of the work on the first volume of the book, will be able to launch a project supporting proper mainline LilyPond development. Now, on to the actual list. Off the top of my head, there are three. "Page-spacer gets confused", sits wanting a test case: http://thread.gmane.org/gmane.comp.gnu.lilypond.bugs/17443/focus=18865 This issue has a duplicate, "Vertical spacing: over-estimation of markups height", recently reported by Nicolas: http://thread.gmane.org/gmane.comp.gnu.lilypond.bugs/18831/focus=18857 "Pure-height of stems", sits wanting a test case: http://thread.gmane.org/gmane.comp.gnu.lilypond.bugs/18449/focus=18450 Homogeneous treatment of markup and markup-list things, discussed back in February and again recently: http://lists.gnu.org/archive/html/lilypond-devel/2010-02/msg00268.html http://thread.gmane.org/gmane.comp.gnu.lilypond.devel/28717/focus=28813 http://codereview.appspot.com/207105 With this one, the situations is somewhat more complex because I can see the reasons for Nicolas' assessment that the patch makes one markup command behave differently from all other markup commands. I am not yet sure if this is ok or bad. The whole idea of the patch is that a markup command can return either a stencil or a list of stencils, and the code consuming the result, automatically decides on how to deal with what came from the command. If we take this standpoint, then the patch only needs those minor formatting fixes that Carl pointed out. But one could also take Nicolas' standpoint. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Presentation: "Publisher-grade LilyPond" in Ottawa
Hi Graham and all Lilyponders, I was quite astonished to hear that my slides were understood to mean anything pessimistic or negative. If they give people this impression, then it is a defect of the slides which I will fix. But right now, let me address some of the apparent misunderstandings. Are you seriously going to submit a paper to CMJ saying "a volunteer open-source project has limited resources for fixing bugs" ??? This is not what we are saying in our presentation and/or paper. What we are saying is: "We attempted a publication of a major critical edition through a major publishing house, using software from a volunteer open-source project with limited resources. We first hoped that this software would be immediately (or almost immediately) suitable for critical-edition work. We found issues blocking this work. These issues are orthogonal to the main direction of the LilyPond project. We fixed them, making the book possible. Future work includes making these solutions useful for the wide LilyPond audience, not just for the immediate needs of this particular book". Oh, and I hope that this "paper to appear" includes an excellent reason why you didn't use lilypond-book and LaTeX, which unlike lilypond itself is*designed* to mix music and text. Two reasons, really. Reason one, we did investigate that route. Lilypond-book and LaTeX do not achieve the kind of music/text integration that the editor demanded. Another issue was integrating with their existing database of variant readings. And for me, there was the obstacle that it was not what the end user was asked for. Reason two, the cry for help was heard all over the mailing list starting many, many months ago. Anyone with a LaTeX-based solution yet? Anyone even *suggesting* a LaTeX-based solution yet? After a year and non-trivial (thousands of Euros) bounties offered? I agree that the presentation has a disproportionately large first (introductory) part, which makes it seem like a "presentation about LilyPond", while it is really the second part which is the essence. There is a background why I chose to extend this first part to be somewhat detailed. Before the presentation at OCLUG, there were two "micro-presentations" I did in a more informal setting. They ended in somewhat curious Q&A discussions. The first question -- asked by a guy who is well-known to everyone in the digital typography and content engineering field through dozens of papers and monographs -- he couldn't believe that today, in 2010, when everything programmable into a computer had already been programmed, today there are still books that can not be printed using already written software. He demanded examples of problems (in music typesetting) which still waited for their programming solutions. So 45 minutes were devoted to these examples. At another micro-presentation, there was another question. "I thought music typography was completely solved by Unicode? That is, all you need to publish any score, is LaTeX and a font with all the music symbols in it?" So, another 15 minutes to explain why LaTeX+Feta != music engraving system. So this is the kind of questions typically asked by those in the audience who care at all. This is why I felt an extended introduction to LilyPond was needed -- although the real subject of the presentation is mostly orthogonal to LilyPond per se. his slides would discourage any potential developers from joining If there is a person who gets this impression from the slides, then the slides are definitely defective and need fixing ASAP. I am not sure if the presentation had the same defect or it's just the slides (there certainly was a lot more explaining of the reasons and the background), but they are most definitely not supposed to convey any negative ideas. "The community showed no interest in addressing these issues", well I am certainly not saying it's the community's *fault* -- the point is that there are other dimensions, which are of concern to [at least one] top publisher, in connection with [at least one] type of book, and which are orthogonal to the dimension of the direction of work of the LilyPond project. After all, none of these issues originated from me; they originated from the musicologist doing the chant research, and the editor of the book -- before I even started looking at LilyPond -- and were rejected as not even being valid LilyPond problems. The typical answers were, "I think that you'll be better served by others" http://www.mail-archive.com/lilypond-u...@gnu.org/msg52031.html "Your post is absolutely unnecessary" http://www.mail-archive.com/lilypond-u...@gnu.org/msg52334.html "I recommend magic" http://www.mail-archive.com/lilypond-u...@gnu.org/msg52026.html Does this represent a problem enough to "discourage" people? I think it does not, for two reasons. First, people are smart to take such things with a grain
Re: before-title-spacing mess up with automatic page breaks
Thanks Xavier, I opened Bug 1112. I have been fixing bugs and implementing new features in the area of page breaking for some past while, so in all probability I'll end up being the one fixing this, too -- because it is the kind of bug which is likely to affect our book here, too. BTW should I send this to bug-lilypond, at least to keep a track of this issue Since both Joe and I are subscribed to both -bug and -devel, and to keep track of issues there is the tracker which now contains the bug anyway, I'd say re-posting in -bug would not be very useful. But for the future, yes, -bug is the more natural place for reports like yours. Boris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Initialize interval in grob_stencil_extent().
There is a chance of returning garbage values from grob_stencil_extent() due to this uninitialized variable issue. No there is not: because this is C++, not C. The existing code is guaranteed to initialize e to the empty interval (i.e., the special interval [+inf, -inf]); your code initializes it to a different interval -- the single-point interval [0,0] -- which is not a difference in "uninitialized garbage" but a question of semantics. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB and mipsel architecture
I'm wondering if it is worth having a mipsel package on lilypond.org (when 2.14 comes out, maybe). I'd be happy to do it, if I can. A chance to help and learn something new. This should be discussed on -devel rather than -user. I would be happy to build+include mipsel packages, as long as somebody else modifies GUB to handle it, and they fix any breakage in those packages. If they stop GUB from compiling a release, I would simply comment out the mipsel compilation and release the rest. However, cross-compiling is a fairly involved process and requires a great deal of technical knowledge. Don't expect much help, because very few people have any experience with it. The main question is, does anyone really want it done. I did a lot of mipsel development in the past, so cross-compilation is not a problem, but it all comes to user value. A few months ago, I had a pressing request, from a real-life user for whom I do custom features in Lilypond, to produce Win32 builds, and I started looking at digging inside GUB; but when I presented to them an estimate of how many days it would take to have a functional GUB platform, it became clear that my time would be much wiser spent on actual Lilypond development (score layout functionality), rather than GUB, and that using Linux instead of Windows was not *that* unsurmountable a problem to justify potentially up to two weeks lost to GUB work. So if one is about to do something with a real purpose (mipsel Lilypond appliance?? completeness of a distro??) I would expect many people with the right skills to be able to do it; on the other hand, as an academic exercise I personally would not find it the most attractive to jump on -- there are many other interesting problems to solve. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Aligning single systems?
On Fri, 07 May 2010 21:53:54 0200, David Kastrup wrote: If we had something like that, one would not need to meddle with > paddings and the resulting spurious spacings. Like in the old joke of a composition student being given advice to take the easy route and just write his professor's Praeludien backwards: "I already tried, Songs by Schubert come out". I already tried a number of ways to improve the vertical alignment of embedded scores, including \vcenter. The resulting alignment is good, but having good alignment does NOT solve the spurious spacing. The problem of spurious spacing is that the shape of the staff is approximated by its bounding box. In the case of text, such approximations work ok, because the optical "density distribution" is reasonably close to rectangular. But for music, it is far from rectangular, we have things sticking out of the staff, like the tip of the G clef. So visually, the white space above a staff begins from the 5th line, but the machine starts measuring it from the highest point of the clef. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Aligning single systems?
Hi David,
for theoretical work it often is necessary to write several short
> systems in one line, interspersed with text.
This is exactly what we are doing.
> I don't manage to have
> a) new systems continue aligned to the previous system in a line, like
> when doing
> \line { \score { ... \layout {} } some text \score { ... \layout {} } }
I am not sure I understand what the problem is.
Do you mean having several embedded scores on one line? Like this:
\markuplines {
\justified-lines {
some text
\score { ... \layout {} }
more text
\score { ... \layout {} }
}
}
What is the functionality missing from this?
b) to have interspersed text appear at useful height with relation to
> the surrounding score.
We were able to obtain nice looking results via a combination of
adjustments to baseline-skip, minimum-Y-extent, staff-space, and other
similar standard settings, I can't remember off the top of my head what
they were, but the idea is, achieving it did not require any custom
programming work, nor even Scheme scripting. What I am struggling
with right now, is the crappy vertical spacing of lines that results.
Because the "padding" / "spacing" specifications are only specific to
text lines, and embedded scores *are* text lines to the page layout
algorithm, my text-only lines are spaced visually much more tightly
than lines containing embedded scores. I think the G clef is (at
least partly) to blame.
> Would it be possible to have some Staff property, say, baseline-height
> that specifies a Staff line to be aligned with the baseline of
> surrounding constructs?
Hmm... so it would be relative to what, the bottom of the bounding
rectangle? Or I think more usefully, to the middle staff line? so
one could say: "the middle lines of all embedded staves are always 1mm
above the baseline of the text". That would be way cool, and I don't
see why it would be too hard to implement.
Boris
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: markup-command and markup-command-list signatures
On Mon, 03 May 2010 09:02:55 0200, David Kastrup wrote: "Boris Shingarov" writes: > Markup functions being able to return a list of stencils. > > Markup lists don't do the trick here? No; if you look at patch 207105, you'll see what I mean. I don't see that you stand a chance with the standard processes here. [...] > Basically you'll be on your own going against the tide until you are > finished. The work flows here are designed to achieve code quality by > making it harder for a would-be contributor to get sub-par code through, > not by making others participate with the work. I guess even that assessment is overly optimistic. The real problem here is not of process, but of fundamental interests. I am scratching *my* itch, which is, make top-publication-grade work possible with Lilypond. Lilypond did not reach this grade before. So this work is beneficial to the Lilypond community in two ways: proving we can go on that territory, as well as purely technical contributions. Now, with technical contributions that are easy enough to integrate back upstream, ok I can spend the extra 30% effort to integrate; but 500% does not seem justifiable and then we take the GPL as the guideline: here is the new code, enjoy doing whatever you please with it. But I am open to any suggestion how to make it more useful to the community. Boris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: markup-command and markup-command-list signatures
I am working on a system of markups which allows to specify more flexible formatting rules. WE are using it for things like multi-line embedded scores, mixing them with markup lines, rules about what things / combinations of things should not start / end a line, also there are rules like "no line break between certain words and beginning ebmbedded score", that kind of formatting rules. I had described some of these ideas in my earlier posts on this list. Markup functions being able to return a list of stencils. Much more importantly, markups need to be aware of what was placed before, and what is to follow, therefore when processing the markup-list, we need to pass a continuation at each step, instead of iterating over the list. This kind of ideas. It even sort of works. Well, works enough for production use by non-programmer users. But still far from being a general Lilypond improvement. The other, easier improvements (orphan-avoiding functionality, page-breaking fixes), are making it fine into the upstream repo: for those, going from the happy state of having the user's problem fixed, to the happier state of fixing it for everyone, is of a reasonable proportion compared to the whole amount of work. But with my markup changes, it's much different. Even the first and simplest of these changes (patch 207105), to go from the current state to an actual submittable patch, will take like 2x the time it took to get it to solve the user's probem. For the bigger problems, like the "markup needs to know what's before and what's ahead", or for the integrated text/embedded-score flow, I don't know, could be up to 5x, and now we are suddenly looking at problems of user value, and all the repercussions. So there is development happening which is important to users (= enables a serious academic publication through a top-name publisher), but those contributions can not be used better than just being thrown away by the community. I remember reading on the LKML, kernel guys having somewhat similar problems with vendor patches and integration with the vanilla tree. I don't (yet) know how we should deal with this, just thinking aloud while there is this discussion about the same area of code... > that is, any number of scheme arguments, then any number of single markup > > arguments, then any number of markup-list arguments, even though I don't > > know if having several markup list arguments is useful or not (and if it's > > doable). ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: news item for new G clef?
I must have missed something -- I don't understand what you are discussing. Are you saying that when a contributor submits a patch, the patchset should include an update to the CHANGES file? On Sat, 24 Apr 2010 00:19:33 0100, Graham Percival wrote: On Sat, Apr 24, 2010 at 12:29:45AM 0200, Francisco Vila wrote: > > 0ce6fe9 introduced a new 1,5 degrees rotated G clef, does this deserve > > a news item? I think so. > > Entries in the Changes are completely up to individual > contributors. As a general rule, I'd say that when in doubt, add > an entry. > > Cheers, > - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Lyrics break estimation of vertical spacing
What makes me really depressed about the situation with pure-height, is that we have fixed a number of "reasonable" bugs in this area (intersystem begin/rest, overridden stem length, deprecated space, padding of markup -- these are the ones that I did in the immediate past, -- the slur fix from Joe yesterday, and I also recall a bunch of other fixes in this area in the last few months), but we are not only not closer to having reasonable trouble-free page layout, but starting to look at page overfill/underfill problems which are very deeply rooted in the nature of pure-height estimation. So much so that I am starting to think that sacrificing the benefit of linebreaking/pagebreaking integration in the sake of always running real (non-pure) height, would be the path to having a reasonable layout for our book. That is, calculate the line breaks disregarding page breaking; calculate tallness of all lines; then run the page breaking algorithm. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Lyrics break estimation of vertical spacing
On Wed, 21 Apr 2010 20:37:52 -0400, Boris Shingarov wrote: not closer to having reasonable trouble-free page layout, but starting > to look at page overfill/underfill problems which are very deeply > rooted in the nature of pure-height estimation. I meant Bug 1061 in particular. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can not make install
The problem is happening with 18. I believe there is no issue with 17, because the last large bunch of my work was based off a pull *after* 17, and it has been installing fine; so the offending change has to be somewhere between 17 and 18; but I'll go double-check 17. On Wed, 21 Apr 2010 17:59:43 -0400, Boris Shingarov wrote: Must be something else. > I upgraded texinfo (and related packages) from 4.11.dfsg.1-4 (which it > is in lilybuntu) to 4.13a.dfsg.1-4ubuntu1, it diesn't make a difference. > Doing lilypond version dichotomy now. > > On Wed, 21 Apr 2010 14:00:29 -0700, Patrick McCarty wrote: > On Wed, Apr 21, 2010 at 1:44 PM, Graham Percival > > wrote: > > > On Wed, Apr 21, 2010 at 04:19:37PM -0400, Boris Shingarov wrote: > > >> I wouldn't even care about this at all -- because I am not experiencing > > >> this problem on my development machine -- if not the outcry of my users > > >> who today can not use any of what I wrote in the past weeks. > > > > > > Well, we need somebody who sees those errors to do more > > > investigation. Does the source for 2.13.18 work? If not, what > > > about 2.13.17 ? If not, what about 2.13.16 ? etc. If we know > > > what range of commits we need to examine, we have a better chance > > > at finding the problem. > > > > Graham, > > > > FWIW, I just did a clean build, testing `make install' and `make doc' > > too, and I did not run into any build failures. > > > > I have texinfo 4.13a installed on my machine. > > > > Thanks, > > Patrick > > > > > > > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can not make install
Must be something else. I upgraded texinfo (and related packages) from 4.11.dfsg.1-4 (which it is in lilybuntu) to 4.13a.dfsg.1-4ubuntu1, it diesn't make a difference. Doing lilypond version dichotomy now. On Wed, 21 Apr 2010 14:00:29 -0700, Patrick McCarty wrote: On Wed, Apr 21, 2010 at 1:44 PM, Graham Percival > wrote: > > On Wed, Apr 21, 2010 at 04:19:37PM -0400, Boris Shingarov wrote: > >> I wouldn't even care about this at all -- because I am not experiencing > >> this problem on my development machine -- if not the outcry of my users > >> who today can not use any of what I wrote in the past weeks. > > > > Well, we need somebody who sees those errors to do more > > investigation. Does the source for 2.13.18 work? If not, what > > about 2.13.17 ? If not, what about 2.13.16 ? etc. If we know > > what range of commits we need to examine, we have a better chance > > at finding the problem. > > Graham, > > FWIW, I just did a clean build, testing `make install' and `make doc' > too, and I did not run into any build failures. > > I have texinfo 4.13a installed on my machine. > > Thanks, > Patrick > > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can not make install
oh, also, "does it occur on make doc, or on make install" ? Maybe that's just a missed dependency. It occurs on "make install" after a successful "make all". The error message is this: # make install .. // bunch of successful stuff... .. make[1]: Entering directory `/home/boris/lilypond/Documentation' cp -p contributor.texi out/contributor.texi export LILYPOND_DATADIR= export PYTHONPATH=/home/boris/lilypond/python/out:../python/auxiliar:/home/boris/lilypond/python/out:./python/auxiliar: /usr/bin/python /home/boris/lilypond/stepmake/bin/install.py -c -d /usr/local/share/info install-info --remove --info-dir=/usr/local/share/info ./out/lilypond-usage.info ; install-info --remove --info-dir=/usr/local/share/info ./out/lilypond-changes.info ; install-info --remove --info-dir=/usr/local/share/info ./out/lilypond-contributor.info ; install-info --remove --info-dir=/usr/local/share/info ./out/lilypond-internals.info ; install-info --remove --info-dir=/usr/local/share/info ./out/lilypond-essay.info ; install-info --remove --info-dir=/usr/local/share/info ./out/lilypond-learning.info ; install-info --remove --info-dir=/usr/local/share/info ./out/lilypond-notation.info ; install-info --remove --info-dir=/usr/local/share/info ./out/music-glossary.info ; install-info --remove --info-dir=/usr/local/share/info ./out/lilypond-web.info ; install-info --remove --info-dir=/usr/local/share/info ./out/lilypond-extending.info ; true install-info(./out/lilypond-usage.info): no entry for file `lilypond-usage' install-info(./out/lilypond-changes.info): no entry for file `lilypond-changes' install-info(./out/lilypond-contributor.info): no entry for file `lilypond-contributor' install-info(./out/lilypond-internals.info): deleting entry `* LilyPond Internals Reference: (lilypond-internals) ...' install-info(./out/lilypond-essay.info): no entry for file `lilypond-essay' install-info(./out/lilypond-learning.info): deleting entry `* LilyPond Learning Manual: (lilypond-learning) ...' install-info(./out/lilypond-notation.info): deleting entry `* LilyPond: (lilypond-notation) ...' install-info(./out/music-glossary.info): deleting entry `* Music Glossary: (music-glossary) ...' install-info(./out/lilypond-web.info): no entry for file `lilypond-web' install-info(./out/lilypond-extending.info): no entry for file `lilypond-extending' install-info --info-dir=/usr/local/share/info ./out/lilypond-web.info No `START-INFO-DIR-ENTRY' and no `This file documents'. install-info(./out/lilypond-web.info): unable to determine description for `dir' entry - giving up make[1]: *** [local-install-info] Error 1 make[1]: Leaving directory `/home/boris/lilypond/Documentation' make: *** [install] Error 2 # Now, after that, invoking "make doc" results in building things I am positive were not required for "install" before. I'm not particularly concerned if "make install" is broken with old libraries, since only package managers need to run that. My end users run that. I don't want to get into that old thread about "release early" and "cathedral" stuff; but for me, your argument in that thread was convincing because I see Lilypond as in some sense similar to Debian, where "stable" means dynosaur bones. I fix bugs that my users are saying get in the way of their production work, and implement and contribute back features that they need to continue their production work. I could base this work off the stable 2.12, but are you willing to look at patches against 2.12's page-breaking code, which is completely replaced in 2.13? Therefore, I obviously must do development against the latest master. But the direction this development is driven by my users; in fact, my patches get tested in the field on production manuscripts before they even get uploaded on appspot. If "make install" is broken for users, this whole model of development breaks down. I wouldn't even care about this at all -- because I am not experiencing this problem on my development machine -- if not the outcry of my users who today can not use any of what I wrote in the past weeks. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can not make install
I think this should be marked as Critical, because it affects all Lilybuntu installations, and Lilybuntu is a supported reference platform for Lilypond. If it were happening on some strange "Green Elephant Linux" distro, I'd say it's small, but this is our own reference platform that's broken. On Wed, 21 Apr 2010 15:34:59 0100, Graham Percival wrote: On Wed, Apr 21, 2010 at 2:57 AM, Carl Sorensen wrote: > > On 4/20/10 10:50 AM, "Graham Percival" wrote: > > > >> On Tue, Apr 20, 2010 at 10:34:37AM 0200, Francisco Vila wrote: > >>> Hello. I guess this means I have to upgrade my compiler or something. > >> > >> If anything, it would be makeinfo, not your compiler. > > What happens if you use texinfo 4.13a? > > > After doing make clean && make && make doc (and with the font stuff > > reverted) I get the following: > > > > /Users/Carl/lilypond/Documentation/out-www//rhythms.texi:1: Prev reference > > to nonexistent node `Pitches' (perhaps incorrect sectioning?). > > Can't reproduce here -- either of the reports. I built from scratch > (starting from a completely empty build directory). > > There's no string "nonexistent" in the entire build log. > > Cheers, > - Graham > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Any way to use lilypond as a library? (embeded)
Hi Alejandro, For what you are doing, you probably want to use libmidi; lilypond is more like if your program created a tune and needed to render the score on paper or on the screen. If your program is in C , you can use libmidi directly. If it is in another language, there are many wrappers around libmidi available. On Wed, 7 Apr 2010 11:32:42 (UTC), Alejandro Piñeiro wrote: I would to ask if there are any way to use parts of lilypond as a library of a > different application (use lilypond embeded). > > Right now I'm using Ubuntu, and there are only available lilypond, lilypond-data > or lilypond-doc packages. There isn't anything similar to lilypond-dev > > As far as I see lilypond only includes executables. > > Why I ask that? > > I'm creating a little application and I would like to create simple midi files > on the fly, but I would like to avoid to enter in midi internals (avoid to waste > my time reinventing the wheel). And lilypond file format is really easy to use. > > So my idea is: > > * My program creates a tune. > * Create a string with the lilypond description. > * Calls a function, and it creates a external midi file > * My program uses the midi file. > > Of course, other alternative could be: > * My program creates a tune > * Creates a external lilypond file > * Calls lilypond to parse this string->creates midi file > * Uses the file > > But, I think that the second one is more slow. > > Thanks for your attention. > > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Critical defects and collisions
1027 Accepted Critical nobody Lyrics ignore minimum-Y-extent This one, I have a suspicion that it may be related to the "Lyrics break estimation of vertical spacing" bug I am working on. If no one else is looking at 1027, it *might* make sense to treat them together while I am in that area of code. But for either/both to happen, I'd need a little help from Joe, to push me in the right direction re: understanding the design of the axis group interface. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Line breaking, simple-spacer, etc.
Quoting Joe Neeman : We create lots of extra grobs (eg. a BarNumber at every bar line) but most of them are not drawn. See the break-visibility property in item-interface. Thanks Joe, this explanation does help a lot. I hope I am not abusing your (and the list's) patience by asking another question: In define-markup-commands.scm, there are references to things like wordwrap-internal-markup-list and make-wordwrap-internal-markup-list. For example, in the function define-builtin-markup-list-command, there is the application (make-wordwrap-internal-markup-list #t args). I can not find where these functions are defined. Grepping the whole source tree only yields occurrences where they are applied. I presume there must be some sort of dynamic building of the name and binding it to the the body (also there is the question then, how is the body constructed)? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Line breaking, simple-spacer, etc.
I am experimenting with some modifications to the line breaking code, and I am stuck trying to understand how some of it works. So far my understanding is that Simple_spacer operates on a vector of Grobs, and it is a well-known Constrained-QP problem (rods = constraints, springs = quadratic function to minimize). What I don't understand is, if the spacer operates at the level of Grobs, which are built at an earlier stage in the pipeline, how are the changes necessitated by differences in line breaking, taken into account? in other words, if I take the last measure of a line and place it on the next line, it is not just a matter of literally moving that graphic to where the start of the next line is, but I also need to draw a clef, key signature, and possibly other fundamental things -- but at that stage in the rendering pipeline, is it not too late?? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoid orphan/widow lines (issue190102)
lgtm, modulo some more formatting nitpicking. If you fix the formatting
and mail me the patch, I'll push it.
Here it is.
--
Boris Shingarov
Work on Lilypond under grant from Sonus Paradisi / Jiri Zurek (Prague),
Czech Science Foundation, Project No. 401/09/0419
diff --git a/lily/constrained-breaking.cc b/lily/constrained-breaking.cc
index 2fead24..31d2cf0 100644
--- a/lily/constrained-breaking.cc
+++ b/lily/constrained-breaking.cc
@@ -525,4 +525,8 @@ Line_details::Line_details (Prob *pb, Output_def *paper)
title_ = to_boolean (pb->get_property ("is-title"));
compressed_lines_count_ = 1;
compressed_nontitle_lines_count_ = title_ ? 0 : 1;
+ SCM last_scm = pb->get_property ("last-markup-line");
+ last_markup_line_ = to_boolean (last_scm);
+ SCM first_scm = pb->get_property ("first-markup-line");
+ first_markup_line_ = to_boolean (first_scm);
}
diff --git a/lily/include/constrained-breaking.hh b/lily/include/constrained-breaking.hh
index bb8a1d0..f36ab74 100644
--- a/lily/include/constrained-breaking.hh
+++ b/lily/include/constrained-breaking.hh
@@ -52,6 +52,8 @@ struct Line_details {
class. */
int compressed_lines_count_;
int compressed_nontitle_lines_count_;
+ bool last_markup_line_;
+ bool first_markup_line_;
Line_details ()
{
@@ -71,6 +73,8 @@ struct Line_details {
title_ = false;
compressed_lines_count_ = 1;
compressed_nontitle_lines_count_ = 1;
+last_markup_line_ = false;
+first_markup_line_ = false;
}
Line_details (Prob *pb, Output_def *paper);
diff --git a/lily/include/page-breaking.hh b/lily/include/page-breaking.hh
index 2e5283d..d497d49 100644
--- a/lily/include/page-breaking.hh
+++ b/lily/include/page-breaking.hh
@@ -127,6 +127,7 @@ public:
bool too_few_lines (int line_count) const;
Real min_whitespace_at_top_of_page (Line_details const&) const;
Real min_whitespace_at_bottom_of_page (Line_details const&) const;
+ int orphan_penalty () const;
protected:
Paper_book *book_;
@@ -179,6 +180,7 @@ private:
int max_systems_per_page_;
int min_systems_per_page_;
vsize system_count_;
+ int orphan_penalty_;
vector current_configurations_;
vector current_chunks_;
diff --git a/lily/page-breaking.cc b/lily/page-breaking.cc
index e0a08c0..dc71659 100644
--- a/lily/page-breaking.cc
+++ b/lily/page-breaking.cc
@@ -174,6 +174,7 @@ Page_breaking::Page_breaking (Paper_book *pb, Break_predicate is_break)
systems_per_page_ = max (0, robust_scm2int (pb->paper_->c_variable ("systems-per-page"), 0));
max_systems_per_page_ = max (0, robust_scm2int (pb->paper_->c_variable ("max-systems-per-page"), 0));
min_systems_per_page_ = max (0, robust_scm2int (pb->paper_->c_variable ("min-systems-per-page"), 0));
+ orphan_penalty_ = robust_scm2int (pb->paper_->c_variable ("orphan-penalty"), 10);
if (systems_per_page_ && (max_systems_per_page_ || min_systems_per_page_))
{
@@ -1415,3 +1416,9 @@ Page_breaking::min_whitespace_at_bottom_of_page (Line_details const &line) const
// FIXME: take into account the height of the footer
return max (0.0, max (padding, min_distance + line.extent_[DOWN]));
}
+
+int
+Page_breaking::orphan_penalty () const
+{
+ return orphan_penalty_;
+}
diff --git a/lily/page-spacing.cc b/lily/page-spacing.cc
index 8919257..8dbf183 100644
--- a/lily/page-spacing.cc
+++ b/lily/page-spacing.cc
@@ -245,6 +245,18 @@ Page_spacer::calc_subproblem (vsize page, vsize line)
penalty += lines_[page_start-1].page_penalty_
+ (page % 2 == 0) ? lines_[page_start-1].turn_penalty_ : 0;
+ /* Deal with widow/orphan lines */
+ /* Last line of paragraph is first line on the new page */
+ if ((page_start > 0) &&
+ (page_start < lines_.size ()) &&
+ (lines_[page_start].last_markup_line_))
+ penalty += breaker_->orphan_penalty ();
+ /* First line of paragraph is last line on the previous page */
+ if ((page_start > 0) &&
+ (page_start < lines_.size ()) &&
+ (lines_[page_start-1].first_markup_line_))
+ penalty += breaker_->orphan_penalty ();
+
demerits += penalty;
if (demerits < cur.demerits_ || page_start == line)
{
diff --git a/lily/paper-book.cc b/lily/paper-book.cc
index 79896e6..f1ee2ec 100644
--- a/lily/paper-book.cc
+++ b/lily/paper-book.cc
@@ -516,15 +516,20 @@ Paper_book::get_system_specs ()
paper_->self_scm (),
page_properties,
scm_car (s));
- for (SCM list = texts ; scm_is_pair (list) ; list = scm_cdr (list))
+ Prob *ps;
+ SCM list;
+ for (list = texts ; scm_is_pair (list) ; list = scm_cdr (list))
{
SCM t = scm_car (list);
// TODO: init props
- Prob *ps = make_paper_system (SCM_EOL);
+ ps = make_paper_system (SCM_EOL);
ps->set_property ("page-break-permission",
Re: Enhancement: Page breaking to avoid widow lines
Quoting Joe Neeman : Again, I'd suggest uploading patches to codereview.appspot.com, which provides nice formatting and makes it easy to have multiple reviewers. Ok, I've created Issue 190102 for this. One inconvenience that I see with the "upload.py" tool, is that I don't see a way to specify the exact target of the diff -- i.e. which files to run the diff against, or even make some tweaking to the diff contents before submitting them. This is useful because the working copy usually contains other, temporary, changes, that I do not want to be submitted. In this particular case, there is the workaround for the incorrect page height estimation, which got its way into the submitted patch because upload.py just grabbed all the changes. Use to_boolean Done. put this on two lines Done. false instead of 0 Done. (2) seems to be pretty important, no? If there is only one line then the current code will avoid placing it first or last on any page. Implemented. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB buiding from a local source tree?
Quoting Graham Percival : I'm completely serious. My GUB tree is *filled* with ugly hacks like this. It would be nice if they weren't needed, but it'll probably take 20-50 more hours of work until this is the case. Oh, I completely understand this. And this is the exact reason why I am asking questions, because when the code is this rough, there are things that are better to just ask, rather than to try to figure out "why" -- because we are not dealing with something finished but a thought-in-progress. If you're frustrated already, then I honestly think you should give up now, because it will only get worse from now on I completely realize what kind of complexity we are talking about. And no, I am not at all frustrated. Not from a technical viewpoint anyway. But for me the whole thing about GUB is driven by the organizational side: as a developer, I am completely happy with the Linux development platform, and am much more interested in furthering Lilypond rather than trying to deploy it on a platform I don't even use. But then there is the end-users who want to see it on Windows, but then again they want to see progress in Lilypond development, and the prospect of losing weeks to porting to Windows, makes them want to reconsider their platform preferences. We'll see. As I already said, at this point it's about organizational questions, not technical ones. Boris Shingarov Work on Lilypond under grant from Sonus Paradisi / Jiri Zurek (Prague), Czech Science Foundation, Project No. 401/09/0419 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enhancement: Page breaking to avoid widow lines
Quoting Joe Neeman : Again, I'd suggest uploading patches to codereview.appspot.com, which provides nice formatting and makes it easy to have multiple reviewers. Are there lilypond patches discussed there already? I looked around the list of repositories, but I can't find Lilypond. Is there anything special that I missed? Boris Shingarov Work on Lilypond under grant from Sonus Paradisi / Jiri Zurek (Prague), Czech Science Foundation, Project No. 401/09/0419 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB buiding from a local source tree?
Umm. It would be *way*, ***way*** easier to download lilybuntu and do a normal compile in there Then I probably had misunderstood the purpose of Lilybuntu -- I thought this was for people who did not have a real linux setup for doing lilypond development -- like, having all the prerequisites in place etc. For *development*, I am completely fine and happy. It's that I am now happy with the development results and need to deploy, and the ultimate users do not use linux. How does lilybuntu produce the win32 binary anyway? wouldn't it need to do the exact same crosscompile as what would happen in a physical ubuntu box? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB buiding from a local source tree?
By the way, do you have a good reason to build using GUB anyway? Because I read on the maillist that it was not possible to do a native build of lilypond for win32. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB buiding from a local source tree?
Quoting Graham Percival :
Didn't you read the part where I said you had to read the source, and
that there was probably something wrong in the above line?
Line 17 of lilypond.make is:
LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git
That's not hard to find, and I think it's pretty clear that this is
what I meant.
That's the very first thing I found, but that's NOT what you were
talking about in the first e-mail.
It is LILYPOND_REPO, which is a separate variable.
You see, I read both the head revision and 2.11.64-1, and they both
contain LILYPOND_REPO_URL. But 2.11.64-1 contains LILYPOND_REPO as
well as LILYPOND_REPO_URL, and it is LILYPOND_REPO that got removed.
Now, my real question is, does LILYPOND_REPO_URL help, i.e. did it
absorb the functionality which used to be achieved via LILYPOND_REPO.
My understanding is that LILYPOND_REPO_URL is passed as an argument to
git, and then the easiest way is to create a local git server and
commit the changes to it.
But right now, we are not even there, as even simply building the
current official head from the main lilypond repository, does not work.
It hangs when trying to download from the standard url:
$ make -f lilypond.make lilypond-installers
python bin/gub --platform=linux-64
'git://git.sv.gnu.org/lilypond.git?branch=master'
mingw::'git://git.sv.gnu.org/lilypond.git?branch=master'
calculating dependencies
cd: 1: can't cd to /home/boris/work/lilypond/gub/gub/downloads/lilypond/git
read_pipe failed: cd
/home/boris/work/lilypond/gub/gub/downloads/lilypond/git && git show
git.sv.gnu.org/lilypond.git/master:VERSION
cd: 1: can't cd to /home/boris/work/lilypond/gub/gub/downloads/lilypond/git
read_pipe failed: cd
/home/boris/work/lilypond/gub/gub/downloads/lilypond/git && git show
git.sv.gnu.org/lilypond.git/master:VERSION
cd: 1: can't cd to /home/boris/work/lilypond/gub/gub/downloads/lilypond/git
read_pipe failed: cd
/home/boris/work/lilypond/gub/gub/downloads/lilypond/git && git show
git.sv.gnu.org/lilypond.git/master:VERSION
^C
Tail of log/gub.log
Running read_pipe
('cd /home/boris/work/lilypond/gub/gub/downloads/lilypond/git &&
git show git.sv.gnu.org/lilypond.git/master:VERSION',)
{'ignore_errors': False, 'env': {'PATH':
'/home/boris/work/lilypond/gub/gub/target/tools/root/usr/bin:/home/boris/work/lilypond/gub/gub/target/tools/root/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/cuda/bin:/usr/jdk1.6.0_10/bin:/usr/local/cuda/bin:/usr/jdk1.6.0_10/bin', 'LD_LIBRARY_PATH':
'/home/boris/work/lilypond/gub/gub/target/tools/root/usr/lib'}}
invoking cd . && git clone --depth 10 --bare
git://git.sv.gnu.org/lilypond.git
/home/boris/work/lilypond/gub/gub/downloads/lilypond/git
Tail of log/gub.log
Traceback (most recent call last):
File "bin/gub", line 233, in exceptional_build
build (settings, options, files)
File "bin/gub", line 199, in build
specs[name].download ()
File "bin/../gub/build.py", line 242, in download
logging.default_logger.write_log (self.stage_message ('download'),
File "bin/../gub/build.py", line 108, in stage_message
env=locals ())
File "bin/../gub/context.py", line 179, in expand
d = self.get_substitution_dict (env)
File "bin/../gub/target.py", line 182, in get_substitution_dict
d = build.AutoBuild.get_substitution_dict (self, dict).copy ()
File "bin/../gub/build.py", line 232, in get_substitution_dict
d = context.RunnableContext.get_substitution_dict (self, dict).copy ()
File "bin/../gub/context.py", line 146, in get_substitution_dict
self._substitution_dict = self.get_constant_substitution_dict ()
File "bin/../gub/context.py", line 125, in get_constant_substitution_dict
val = method ()
File "bin/../gub/build.py", line 260, in source_checksum
return self.source.checksum ()
File "bin/../gub/repository.py", line 657, in checksum
self.download ()
File "bin/../gub/repository.py", line 639, in download
self.git ('clone --depth 10 --bare %(source)s %(dir)s' % locals
(), dir='.')
File "bin/../gub/repository.py", line 605, in git
ignore_errors=ignore_errors, env=self.get_env ())
File "bin/../gub/repository.py", line 213, in logged
return loggedos_func (self.logger, *args, **kwargs)
File "bin/../gub/loggedos.py", line 80, in system
line = proc.stdout.readline ()
KeyboardInterrupt
make: *** [packages] Error 1
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB buiding from a local source tree?
Oh, and make sure you're using the latest GUB; IIRC there are 2 or 3 different git repositories floating around. You want the one at github. git://github.com/janneke/gub.git -- this one, right? I believe you'll want something like make -f lilypond.make LILYPOND_REPO=/location/of/your/tree lilypond Looks like LILYPOND_REPO was removed from recent revisions? I can see it being in lilypond.make as of 2.11.64-1: http://github.com/janneke/gub/blob/build/lilypond-gub/2.11.64-1/lilypond.make but simple 'git clone git://github.com/janneke/gub.git' ends up with a revision not having it. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB buiding from a local source tree?
Hi, How do I tell GUB to build Lilypond from a modified source tree which I have locally, instead of getting it from git? In general, where is the best place to start reading more on GUB, the info on the GUB page is very sketchy, and GUB-related messages on lilypond-devel seem far apart and browsing the list archive for a while, did not get me very far. My immediate need is to test out my patches on the mingw platform. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enhancement: Page breaking to avoid widow lines
Here is the new code -- implementing all that's been discussed. (Ok,
not quite all -- the line length functionality is not implemented, but
all the style remarks have been taken into account, the markup-list-id
has been replaced with is-last-line, penalty made configurable, and
also, (new, was not discussed yet), the opposite case of lonely first
(as opposed to last) line is now properly handled.
Quoting Joe Neeman :
On Wed, 2010-01-13 at 09:11 -0500, Boris Shingarov wrote:
> Joe,
>
> > Paper_book::get_system_specs then you wouldn't even need the
> > markup-list-id property: you could add an avoid-orphan property that
> > only gets set for the last line of a multi-line markup list if it is
> > short. That might also simplify Page_spacer::calc_subproblem.
>
> This is the first idea that came to my mind when I started implementing
> this code.
> I wanted to have a member called "is_last_line_" instead of
> "markup_list_id_", that way the nested ifs in calc_subproblem() become
> much more readable. But I wasn't sure how to calculate that property
> inside the Line_details(...) constructor.
Can't you do it in Paper_book::get_system_specs and store it in the Prob
(and then read it from the Prob in Line_details(Prob*))?
Joe
diff --git a/lily/constrained-breaking.cc b/lily/constrained-breaking.cc
index 2fead24..6497cd5 100644
--- a/lily/constrained-breaking.cc
+++ b/lily/constrained-breaking.cc
@@ -525,4 +525,8 @@ Line_details::Line_details (Prob *pb, Output_def *paper)
title_ = to_boolean (pb->get_property ("is-title"));
compressed_lines_count_ = 1;
compressed_nontitle_lines_count_ = title_ ? 0 : 1;
+ SCM last_scm = pb->get_property ("last-markup-line");
+ last_markup_line_ = SCM_BOOLP(last_scm) ? scm_to_bool (last_scm) : 0;
+ SCM first_scm = pb->get_property ("first-markup-line");
+ first_markup_line_ = SCM_BOOLP(first_scm) ? scm_to_bool (first_scm) : 0;
}
diff --git a/lily/include/constrained-breaking.hh b/lily/include/constrained-breaking.hh
index bb8a1d0..b9590a9 100644
--- a/lily/include/constrained-breaking.hh
+++ b/lily/include/constrained-breaking.hh
@@ -52,6 +52,7 @@ struct Line_details {
class. */
int compressed_lines_count_;
int compressed_nontitle_lines_count_;
+ bool last_markup_line_, first_markup_line_;
Line_details ()
{
@@ -71,6 +72,8 @@ struct Line_details {
title_ = false;
compressed_lines_count_ = 1;
compressed_nontitle_lines_count_ = 1;
+last_markup_line_ = 0;
+first_markup_line_ = 0;
}
Line_details (Prob *pb, Output_def *paper);
diff --git a/lily/include/page-breaking.hh b/lily/include/page-breaking.hh
index 2e5283d..d497d49 100644
--- a/lily/include/page-breaking.hh
+++ b/lily/include/page-breaking.hh
@@ -127,6 +127,7 @@ public:
bool too_few_lines (int line_count) const;
Real min_whitespace_at_top_of_page (Line_details const&) const;
Real min_whitespace_at_bottom_of_page (Line_details const&) const;
+ int orphan_penalty () const;
protected:
Paper_book *book_;
@@ -179,6 +180,7 @@ private:
int max_systems_per_page_;
int min_systems_per_page_;
vsize system_count_;
+ int orphan_penalty_;
vector current_configurations_;
vector current_chunks_;
diff --git a/lily/page-breaking.cc b/lily/page-breaking.cc
index e0a08c0..dc71659 100644
--- a/lily/page-breaking.cc
+++ b/lily/page-breaking.cc
@@ -174,6 +174,7 @@ Page_breaking::Page_breaking (Paper_book *pb, Break_predicate is_break)
systems_per_page_ = max (0, robust_scm2int (pb->paper_->c_variable ("systems-per-page"), 0));
max_systems_per_page_ = max (0, robust_scm2int (pb->paper_->c_variable ("max-systems-per-page"), 0));
min_systems_per_page_ = max (0, robust_scm2int (pb->paper_->c_variable ("min-systems-per-page"), 0));
+ orphan_penalty_ = robust_scm2int (pb->paper_->c_variable ("orphan-penalty"), 10);
if (systems_per_page_ && (max_systems_per_page_ || min_systems_per_page_))
{
@@ -1415,3 +1416,9 @@ Page_breaking::min_whitespace_at_bottom_of_page (Line_details const &line) const
// FIXME: take into account the height of the footer
return max (0.0, max (padding, min_distance + line.extent_[DOWN]));
}
+
+int
+Page_breaking::orphan_penalty () const
+{
+ return orphan_penalty_;
+}
diff --git a/lily/page-spacing.cc b/lily/page-spacing.cc
index 8919257..8dbf183 100644
--- a/lily/page-spacing.cc
+++ b/lily/page-spacing.cc
@@ -245,6 +245,18 @@ Page_spacer::calc_subproblem (vsize page, vsize line)
penalty += lines_[page_start-1].page_penalty_
+ (page % 2 == 0) ? lines_[page_start-1].turn_penalty_ : 0;
+ /* Deal with widow/orphan lines */
+ /* Last line of paragraph is first line on the new page */
+ if ((page_start > 0) &&
+ (page_start < lines_.s
Re: Enhancement: Page breaking to avoid widow lines
Joe, Paper_book::get_system_specs then you wouldn't even need the markup-list-id property: you could add an avoid-orphan property that only gets set for the last line of a multi-line markup list if it is short. That might also simplify Page_spacer::calc_subproblem. This is the first idea that came to my mind when I started implementing this code. I wanted to have a member called "is_last_line_" instead of "markup_list_id_", that way the nested ifs in calc_subproblem() become much more readable. But I wasn't sure how to calculate that property inside the Line_details(...) constructor. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
