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: w
On Mon, Nov 15, 2010 at 08:40:26AM +0100, David Kastrup wrote:
>
> In commercial settings, stagnation often means death. With free
> software, stagnation mostly means stagnation.
>
This is one of the strenghts of free software. Another is that over time it
becomes tayored to actual users and a
Boris Shingarov writes:
> 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 publishe
On Wed, Nov 10, 2010 at 2:01 PM, Valentin Villenave
wrote:
> Please forgive me for bumping this discussion, but I was wondering if
> your work on the Lyrics spacing had ever been implemented and merged
> into LilyPond.
Oh, never mind. Just found it:
http://code.google.com/p/lilypond/issues/detail
On Tue, Mar 30, 2010 at 2:08 PM, Boris Shingarov wrote:
> Ok, it's fully functional now. I am going to format and upload a patch.
Greetings Boris,
Please forgive me for bumping this discussion, but I was wondering if
your work on the Lyrics spacing had ever been implemented and merged
into LilyP
On Thu, 22 Apr 2010 13:39:35 -0700, Joe Neeman wrote:
Never mind, I just did that hunk manually and pushed.
Then, I am marking bug 1053 as fixed.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lily
"Boris Shingarov" writes:
> 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 imme
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 Jo
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.
_
Ok, latest patch is uploaded now.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Oops, I had missed it. Reviewed now.
On Mon, 2010-04-19 at 19:48 -0400, Boris Shingarov wrote:
> Hi Joe,
>
> Have you seen the last patchset I uploaded to Rietveld 3 days ago? Is
> there anything expected from me at this point to further the progress
> on this bug?
>
Hi Joe,
Have you seen the last patchset I uploaded to Rietveld 3 days ago? Is
there anything expected from me at this point to further the progress
on this bug?
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinf
Ah, you might want to install git-cl, which is a git interface to the
> upload.py script
Thanks -- this does make life a lot easier!!!
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
On Mon, Apr 12, 2010 at 1:43 PM, Boris Shingarov wrote:
>
>> If you use the same test branch as your original patch (which is
>
> > associated with a particular issue on Rietveld), you can just apply
> > the revised patch and upload again (git-cl will ask you for a
> > description which becomes
Am Montag, 12. April 2010 22:43:30 schrieb Boris Shingarov:
> Hi Neil,
>
> > If you use the same test branch as your original patch (which is
> >
> > associated with a particular issue on Rietveld), you can just apply
> > the revised patch and upload again (git-cl will ask you for a
> > des
Hi Neil,
If you use the same test branch as your original patch (which is
> associated with a particular issue on Rietveld), you can just apply
> the revised patch and upload again (git-cl will ask you for a
> description which becomes the title of the new patch set on Rietveld.)
I am not s
On 12 April 2010 21:03, Boris Shingarov wrote:
> This is the whole patch. I understand your idea, but how do I add it to the
> previous set? Git will not help here, because neither of the two were
> committed yet.
If you use the same test branch as your original patch (which is
associated with
On Mon, 12 Apr 2010 20:57:00 0100, Neil Puttock wrote:
On 12 April 2010 18:46, Boris Shingarov wrote:
> > Ok, this patch is ready for code review:
> > http://codereview.appspot.com/872044
>
> Can you add this to the previous patch set so it's easier to see
> what's changed since the last
On 12 April 2010 18:46, Boris Shingarov wrote:
> Ok, this patch is ready for code review:
> http://codereview.appspot.com/872044
Can you add this to the previous patch set so it's easier to see
what's changed since the last review?
Thanks,
Neil
___
b
Ok, this patch is ready for code review:
http://codereview.appspot.com/872044
On Thu, 08 Apr 2010 23:47:15 -0700, Joe Neeman wrote:
On Mon, 2010-04-05 at 03:00 -0400, Boris Shingarov wrote:
> > > >Grob *alignment = get_vertical_alignment (); //TODO check for null
> > > please check for nul
On Fri, 2010-04-09 at 02:55 -0400, Boris Shingarov wrote:
> > Alternatively, you could just check explicitly for an
> > empty result in System::part_of_line_pure_height.
>
> And if it's empty, then not do the translation at all, right?
> Will do this right now and see how much better this
> ge
Alternatively, you could just check explicitly for an
> empty result in System::part_of_line_pure_height.
And if it's empty, then not do the translation at all, right?
Will do this right now and see how much better this
gets us.
BTW, what is the correct (supposed) way to run the
regtests? I
On Thu, 08 Apr 2010 23:47:15 -0700, Joe Neeman wrote:
> But what do we do if it's null?
> Maybe print a programming_error and return an empty extent? It doesn't
> particularly matter what you do, just don't crash.
But it's never null, on any input that I've seen. Not on any of the regtests
On Mon, 2010-04-05 at 03:00 -0400, Boris Shingarov wrote:
> > >Grob *alignment = get_vertical_alignment (); //TODO check for null
> > please check for null
>
> But what do we do if it's null?
Maybe print a programming_error and return an empty extent? It doesn't
particularly matter what you
On Fri, 2010-04-09 at 02:30 -0400, Boris Shingarov wrote:
> What I am stuck on now, is the function
> Align_interface::get_minimum_translations().
> Could you explain the high-level design of what this is doing?
The function builds a skyline for each staff/lyrics/etc, then compares
the skylines t
What I am stuck on now, is the function
Align_interface::get_minimum_translations().
Could you explain the high-level design of what this is doing?
In all cases in the book I am trying to typeset, everything appears
to work A-ok, but on the "hara-kiri-pianostaff" regtest, this now returns
an emp
Hi Joe,
You'll need to do something better here, rather than just leaving all
> the extent information out for markup blocks.
Right, this is exactly why that oldest version of the patch was segfaulting.
The second version (attached to the bug and formatted
on codreview.appspot, also linked
On Wed, 2010-03-31 at 01:46 -0400, Boris Shingarov wrote:
> Wooo, hang on, my patch is sour! It segfaults if the system is not a
> group of staves -- for example, this is the case of markup. I'm
> fixing it.
Ok, so I'll save the full review for later, but here are a few quick
things I noticed:
1) what's your gmail account address?
2) try logging out and then back in.
When you click on the "Add a comment and make changes" box at the
bottom, it should give you a number of options.
Cheers,
- Graham
On Thu, Apr 1, 2010 at 7:51 AM, Boris Shingarov wrote:
> Ok, I changed the Owner, but I
Ok, I changed the Owner, but I don't see how I am supposed to change
the Status, etc.
Becoming blind?
On Thu, 1 Apr 2010 07:42:08 0100, Graham Percival wrote:
On Thu, Apr 1, 2010 at 5:23 AM, Boris Shingarov wrote:
> > Ok, so I created Issue 1053. The next logical step would be to
assign this
On Thu, Apr 1, 2010 at 5:23 AM, Boris Shingarov wrote:
> Ok, so I created Issue 1053. The next logical step would be to assign this
> to myself, indicating that I am working on the code to fix it, and link from
> the bug report to the patch. Can I do this?
You're now a member of the googlecode l
he low-hanging lyrics were somehow responsible. So I
> named the email, "Lyrics break estimation of vertical spacing". We
> now know exactly what the bug is caused by, and we know that this case
> with lyrics, is only one scenario. The file "lyrics.ly" is one
> min
the low-hanging lyrics were somehow responsible. So I
> named the email, "Lyrics break estimation of vertical spacing". We
> now know exactly what the bug is caused by, and we know that this case
> with lyrics, is only one scenario. The file "lyrics.ly" is one
On Wed, 31 Mar 2010 01:46:12 -0400, Boris Shingarov wrote:
> Here is the patch for the "begin/rest-of-line" problem.
Wooo, hang on, my patch is sour! It segfaults if the system is not a
group of staves -- for example, this is the case of markup. I'm
fixing it.
___
У ср, 2010-03-31 у 04:29 -0400, Boris Shingarov пише:
> Hi Dmytro,
Hi Boris,
> > If you will not add this issue at the tracker (as Graham mentioned), i
> > guess i will.
>
> I'll do it, but I'll ask you qustions
please do :-)
> if I stumble upon something
> unclear, because I am new to the
e. So I
named the email, "Lyrics break estimation of vertical spacing". We
now know exactly what the bug is caused by, and we know that this case
with lyrics, is only one scenario. The file "lyrics.ly" is one
minimal example. But the critical ingredient of the bug, is not
lyric
Hi Dmytro,
If you will not add this issue at the tracker (as Graham mentioned), i
> guess i will.
I'll do it, but I'll ask you qustions if I stumble upon something
unclear, because I am new to the Lilypond bug procedure.
Boris
__
Hi Graham,
I'm doing everything I can to increase the number of people involved
> in lilypond, including the bug squad. If you would like to volunteer
> to help with this, I'd love to have you on board.
My involvement with Lilypond is pragmatic.
I am enabling the publication of a top-quali
On Wed, Mar 31, 2010 at 7:05 AM, Boris Shingarov wrote:
> Hi Graham,
>
> > ... I
> > would expect somebody to add it to the tracker. I'm not certain
> > if that has always happened, though.
> So in other words, not all bugs have bug reports in the tracker?
It depends on how well the Bug Squad
7;s hard to say *what* is a bug, *where*
is it. You say: "Lyrics break estimation of vertical spacing" --- so,
no-lyrics.ly should contain no "unwanted" vertical space? But it does,
with 2.13.16. Or i've missed something?
Next, i've commented out everything in \paper
Hi Graham,
If you send a minimal example to this list, and no developer
> responds within a few days to begin discussing a patch, then I
> would expect somebody to add it to the tracker. I'm not certain
> if that has always happened, though.
So in other words, not all bugs have bug report
On Wed, Mar 31, 2010 at 01:46:12AM -0400, Boris Shingarov wrote:
> Btw, how does one file a proper file report?
> The bug tracker says scary things to the effect of "never create
> a bug report directly in this tracker, or risk being permanently
> killed; instead, write to the -bug maillist." Well
Here is the patch for the "begin/rest-of-line" problem.
(Sorry, couldn't upload to appspot for various reasons).
I have also attached two score examples illustrating the bug.
We should probably augment the test suite, too, for the bug
to be considered done done.
Btw, how does one file a prop
On Tue, 30 Mar 2010 08:08:41 -0400, Boris Shingarov wrote:
Ok, it's fully functional now.
> I am going to format and upload a patch.
Hmmm... still overestimates on my "real-life" manuscript, even though
several different scenarios (with and withou lyrics) which were
restimating, are A-ok now
Ok, it's fully functional now.
I am going to format and upload a patch.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
dynamic_cast? (or maybe my mind is corrupted by 15 years
> of Smalltalk, and this is a standard C quirk?)
Oops, keyboard failure, obviously meant "C quirk"!
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailma
Replace constrained-breaking.cc:461 by
>
> Interval begin_extent = sys->begin_of_line_extent (start, end);
> Interval rest_extent = sys->rest_of_line_extent (start, end);
Ok, experimenting with this, I am inclined to *add* instead of
*replacing*. The extent_ member of Line_details is touche
On Mon, 2010-03-29 at 21:25 -0400, Boris Shingarov wrote:
> Hi Joe,
>
> > Replace constrained-breaking.cc:461 by
> >
> > Interval begin_extent = sys->begin_of_line_extent (start, end);
> > Interval rest_extent = sys->rest_of_line_extent (start, end);
> >
> > and replace constrained-break
On Mon, 2010-03-29 at 20:49 -0400, Boris Shingarov wrote:
> > I'd rather discuss this point now, because I don't like the extension of
> > Interval (and I'd rather you didn't spend a whole lot of time getting it
> > to work if there is a nicer way)
>
> No kidding, neither do I like diluting I
Hi Joe,
Replace constrained-breaking.cc:461 by
>
> Interval begin_extent = sys->begin_of_line_extent (start, end);
> Interval rest_extent = sys->rest_of_line_extent (start, end);
>
> and replace constrained-breaking.cc:485 by something analogous.
Btw, it's not clear to me what the invers
I'd rather discuss this point now, because I don't like the extension of
> Interval (and I'd rather you didn't spend a whole lot of time getting it
> to work if there is a nicer way)
No kidding, neither do I like diluting Interval. One, it is an extremely
hacky way to do things. Two, it *do
On Mon, 2010-03-29 at 17:04 -0400, Boris Shingarov wrote:
> > Do we really need this to be included in every Interval? I'd have
> > thought that the only data structure that needs to change is
> > Line_details.
>
> Right, but how do you get the actual value in there?
Replace constrained-brea
On Mon, 29 Mar 2010 12:04:42 -0700, Joe Neeman wrote:
but I think you don't need to store an
> extra version of rod-height. Just define rod-height to measure the
> bottom of the last staff (whether that bottom comes from
> begin_of_line_extent or rest_of_line_extent). Each time you add a sta
Do we really need this to be included in every Interval? I'd have
> thought that the only data structure that needs to change is
> Line_details.
Right, but how do you get the actual value in there?
It's filled from calling the Y-extent Scheme function, which can be
anything, and in most cases
On Mon, 2010-03-29 at 15:53 -0400, Boris Shingarov wrote:
> On Mon, 29 Mar 2010 08:48:35 -0700, Joe Neeman wrote:
>
> > Keep in mind that a lyric line is the same as a staff to the
> > page-breaker. Don't your one-staffers have lyrics? If so, they are
> > really two-staffers and so the probl
On Mon, 29 Mar 2010 08:48:35 -0700, Joe Neeman wrote:
Keep in mind that a lyric line is the same as a staff to the
> page-breaker. Don't your one-staffers have lyrics? If so, they are
> really two-staffers and so the problem could still be in the
> within-system estimation.
My one-staffe
On Wed, 2010-03-24 at 22:01 -0400, Boris Shingarov wrote:
> First of all, thank you Joe for all the explanations -- now that it
> has dawned on me what the source of confusion was, it all
> makes sense. Thanks!!
>
> > I am now thinking about how to implement this TODO best.
> > One idea that
On Wed, 2010-03-24 at 19:42 -0400, Boris Shingarov wrote:
> On Wed, 24 Mar 2010 18:15:45 -0400, Boris Shingarov wrote:
> > Hmm, let me understand this better.
> > Does it mean that Constrained_breaking::fill_line_details() gets
> > called before the line breaks are calculated, and then again
Looking at Page_breaking::min_page_count(), I am thinking
> about the correct generalization of the concept of "rod_height",
> so that we would still have one "current position", but two
> "current bottom edges" (so the next current position is calculated
> by juxtaposing the next system's tw
First of all, thank you Joe for all the explanations -- now that it
has dawned on me what the source of confusion was, it all
makes sense. Thanks!!
I am now thinking about how to implement this TODO best.
> One idea that immediately comes to mind, is to replace the
> unified heights with be
On Wed, 24 Mar 2010 18:15:45 -0400, Boris Shingarov wrote:
Hmm, let me understand this better.
> Does it mean that Constrained_breaking::fill_line_details() gets
> called before the line breaks are calculated, and then again after
Oh, now I understand why!!! The hack addresses the space
be
Right, the positions of the staff lines relative to each other are not
> yet computed, so each extent is relative to its own staff.
Hmm, let me understand this better.
Does it mean that Constrained_breaking::fill_line_details() gets
called before the line breaks are calculated, and then again a
On Wed, 24 Mar 2010 14:19:21 -0700, Joe Neeman wrote:
Right, but in align-interface.cc:118, we throw away that unite()d extent
> in favour of a begin_of_line_extent and a rest_of_line_extent.
But that, IIUC, is only happening one level (of the grob tree) above,
when it's too late, no? That
On Wed, 2010-03-24 at 16:08 -0400, Boris Shingarov wrote:
> > The skylines are used as part of VerticalAlignment, to figure out how
> > far apart the children of VerticalAlignment (ie. VerticalAxisGroups for
> > staves, lyrics, etc) need to be. Once we compute the translations of the
> > chil
On Wed, 24 Mar 2010 16:08:51 -0400, Boris Shingarov wrote:
What happens in reality, is that pure_height() of the VerticalAxisGroup,
> calling ly:hara-kiri-group-spanner::y-extent in Scheme land,
> calling back Hara_kiri_group_spanner::pure_height(), ultimately
> ends up in Axis_group_interfa
The skylines are used as part of VerticalAlignment, to figure out how
> far apart the children of VerticalAlignment (ie. VerticalAxisGroups for
> staves, lyrics, etc) need to be. Once we compute the translations of the
> children of VerticalAlignment, we can compute the height of
> VerticalAl
On Tue, 2010-03-23 at 22:51 -0400, Boris Shingarov wrote:
> > The estimated height for the whole system _should_ take into account the
> > fact that the lyrics can be squeezed between the systems. Have a look at
> > the comment in align-interface.cc:104 (which should get called as a
> > resul
On Tue, 2010-03-23 at 19:57 -0400, Boris Shingarov wrote:
> > The estimated height for the whole system _should_ take into account the
> > fact that the lyrics can be squeezed between the systems. Have a look at
> > the comment in align-interface.cc:104 (which should get called as a
> > result o
The estimated height for the whole system _should_ take into account the
> fact that the lyrics can be squeezed between the systems. Have a look at
> the comment in align-interface.cc:104 (which should get called as a
> result of sys->pure_height()). The begin_of_line_extent should be zero
>
> The estimated height for the whole system _should_ take into account the
> fact that the lyrics can be squeezed between the systems. Have a look at
> the comment in align-interface.cc:104 (which should get called as a
> result of sys->pure_height())
Trying to make head or tail of which chi
On Fri, 19 Mar 2010 17:15:08 -0400, Boris Shingarov wrote:
> As to the call to get_skylines(), now I am really confused. All this
> (get_property("springs-and-rods") resulting in
> Spacing_spanner::set_springs() and all the other things down the road
> being called), happens much earli
On Fri, 19 Mar 2010 13:39:36 -0700, Joe Neeman wrote:
The begin_of_line_extent should be zero
> for lyrics, which should allow the lines to be close together in the
> height-estimation procedure.
The difficulty of debugging this, is how do I tell which grob is
which. They are Scheme poi
Hi Joe,
Thanks for the tips, and have a nice and safe trip!
> The estimated height for the whole system _should_ take into account the
> fact that the lyrics can be squeezed between the systems. Have a look at
> the comment in align-interface.cc:104 (which should get called as a
> result
Unfortunately, I'm about to go out of town for the weekend, so I don't
have time right now to follow this up properly. But I've left a couple
of hints below.
On Fri, 2010-03-19 at 11:05 -0400, Boris Shingarov wrote:
> On Wed, 13 Jan 2010 19:37:14 1100, Joe Neeman wrote:
>
> > It's nice to see
Here are the two illustrative examples.
On Fri, 19 Mar 2010 11:05:30 -0400, Boris Shingarov wrote:
On Wed, 13 Jan 2010 19:37:14 1100, Joe Neeman wrote:
>
> > It's nice to see someone else touching the page-breaking code
>
> The more I dig into it, the more questions I have.
> Back i
On Wed, 13 Jan 2010 19:37:14 1100, Joe Neeman wrote:
> It's nice to see someone else touching the page-breaking code
The more I dig into it, the more questions I have.
Back in January, we talked about vertical space estimation in the case of Prob
(i.e. markup); now I am investigating vert
76 matches
Mail list logo
