Re: make info has failed for more than one day.
Neil Puttock n.putt...@gmail.com writes: On 8 April 2010 19:24, David Kastrup d...@gnu.org wrote: And so forth and so on. I've pushed a compile fix which should sort this out for you. Thanks. Appears to work here. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: PATCH: Lyrics break estimation of vertical spacing
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 empty vector of offsets when called from
System::part_of_line_pure_height(),
but the corresponding vector of staves is non-empty, which causes
a segfault when trying to translate the 0th staff.
On Sun, 04 Apr 2010 11:47:48 -0700, Joe Neeman wrote:
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:
@@ -512,7 524,6 @@ Line_details::Line_details (Prob *pb, Output_def
*paper)
last_column_ = 0;
force_ = 0;
- extent_ = unsmob_stencil (pb-get_property (stencil)) -extent
You'll need to do something better here, rather than just leaving all
the extent information out for markup blocks.
(Y_AXIS);
bottom_padding_ = 0;
space_ = 0.0;
inverse_hooke_ = 1.0;
@@ -530,3 541,33 @@ Line_details::Line_details (Prob *pb, Output_def
*paper)
SCM first_scm = pb-get_property (first-markup-line);
first_markup_line_ = to_boolean (first_scm);
}
/*
* I measure hanging from top of page. It is positive for everything
* below the top of page. Lower things have bigger hanging.
* NB!!! These hangings are artificial in that they do not take into
* account any padding/spacing.
hangings need to take padding (but not spacing) into account, because
padding is non-stretchable space. See (the old version of)
Page_breaking::min_page_count, which uses padding.
They are as if systems were stacked
* on top of each other; as such, hangings are only used/useful for
the
* calculation of ext_len in Page_breaking.
*/
void Line_details::compute_hangings (double previous_begin, double
previous_rest)
we use Real rather than double (not quite sure why, but let's be
consistent). Also, the code style is
void
Line_details::compute_hangings ...
{
double a = begin_of_line_extent_[UP];
double b = rest_of_line_extent_[UP];
double midline_hanging = max (previous_begin a, previous_rest
b);
hanging_begin_ = midline_hanging - begin_of_line_extent_[DOWN];
hanging_rest_ = midline_hanging - rest_of_line_extent_[DOWN];
}
double Line_details::hanging ()
double
Line_details::hanging ()
{
return max (hanging_begin_, hanging_rest_);
}
double Line_details::full_height ()
{
Interval ret;
ret.unite(begin_of_line_extent_);
ret.unite(rest_of_line_extent_);
return ret.length();
}
diff --git a/lily/include/constrained-breaking.hh
b/lily/include/constrained-breaking.hh
index e6d898e..1f0e952 100644
--- a/lily/include/constrained-breaking.hh
b/lily/include/constrained-breaking.hh
@@ -27,7 27,11 @@
struct Line_details {
Grob *last_column_;
Real force_;
- Interval extent_; /* Y-extent of the system */
Interval begin_of_line_extent_;
Interval rest_of_line_extent_;
double hanging_begin_;
double hanging_rest_;
double y_extent_; /* Y-extent, adjusted according to
When do you set this? Doesn't full_height() remove the need for this
anyway?
begin/rest-of-line*/
Real padding_; /* compulsory space after this system (if we're not
last on a page) */
@@ -78,6 82,16 @@ struct Line_details {
}
Line_details (Prob *pb, Output_def *paper);
/*
* Pure procedure.
* Based on the arguments which indicate how low the previous
system
* hangs, and on the internal state (*_of_line_extents), store into
* internal state (hanging_*) how low our own low margin hangs.
*/
void compute_hangings (double previous_begin, double
previous_rest);
double hanging ();
double full_height ();
};
/*
diff --git a/lily/include/system.hh b/lily/include/system.hh
index 509a65d..b8fa664 100644
--- a/lily/include/system.hh
b/lily/include/system.hh
@@ -65,9 65,15 @@ public:
void typeset_grob (Grob *);
void pre_processing ();
Interval begin_of_line_pure_height (vsize start, vsize end);
Interval rest_of_line_pure_height (vsize start, vsize end);
protected:
virtual void derived_mark () const;
virtual Grob *clone () const;
private:
Interval part_of_line_pure_height (vsize start, vsize end, bool
begin);
};
void set_loose_columns (System *which, Column_x_positions const
*posns);
diff --git
Re: PATCH: Lyrics break estimation of vertical spacing
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 to find the minimum amounts that each staff must be moved down so that no collisions occur. 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 empty vector of offsets when called from System::part_of_line_pure_height(), but the corresponding vector of staves is non-empty, which causes a segfault when trying to translate the 0th staff. get_skylines modifies its elems argument, removing all staves that are empty. If every staff is empty (which happens in hara-kiri-pianostaff, IIRC) then get_skylines doesn't return any skylines and hence get_minimum_translations (see align-interface.cc:226) returns an empty vector. I'm not actually sure why it does this (instead of returning, say, a vector of zeros) so if the regression tests pass, I'd be ok with changing this. Alternatively, you could just check explicitly for an empty result in System::part_of_line_pure_height. Cheers, Joe ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: PATCH: Lyrics break estimation of vertical spacing
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 do, just don't crash. Joe ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: PATCH: Lyrics break estimation of vertical spacing
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 nor on our book anyway. So ok, I'll do as you suggest, but I'll add a comment explaining that this is somewhat arbitrary. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: PATCH: Lyrics break estimation of vertical spacing
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 am just running Lilypond on all the files from a bash script, as I can't seem to find the script that would be supposed to run the suite -- if such a beast exists. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: PATCH: Lyrics break estimation of vertical spacing
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 gets us. BTW, what is the correct (supposed) way to run the regtests? I am just running Lilypond on all the files from a bash script, as I can't seem to find the script that would be supposed to run the suite -- if such a beast exists. Checkout a known good commit (eg. origin/master) make test-baseline git checkout my-branch make make test-clean make check There's probably something in the contributor's guide about this... Joe ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Percents repeats confused by polyphony
The first of a group of full measure percent repeat
symbols doesn't get printed when the music expression is
polyphonic (see the attached png); and the following errors
are generated:
programming error: must have Item for spanner bound of PercentRepeat
programming error: Multi_measure_rest::get_rods (): I am not spanned!
Also, a pdf file is produced, despite getting these:
error: failed files: percent_repeats.ly
shell returned 1
Here's a test file:
\version 2.13.18
\relative c'' {
\repeat percent 4 {
{ c4 c c c } \\ { f,4 f f f }
}
}
One workaround is to have the user manually add:
\set countPercentRepeats = ##f
...but I assume this is a needless burden. I glanced at
percent-repeat-engraver.cc, but I still don't know any C++,
so I'm unable to solve it myself. Is there a way to have
the countPercentRepeats context property set to #f by
default? Or is the real problem some sort of flawed
assumption within the PercentRepeat or Multi_measure_rest
code? I have no idea.
But I presume this is a bug which hopefully is easy to fix.
Any insights?
- Mark
attachment: percent-repeats.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Download
Hi Dad! What's up. Hope your good. Come back up if you have it. Ben ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
