On 11/30/10 4:24 AM, "Graham Percival" <gra...@percival-music.ca> wrote:
> This is an attempt to collaboratively solve issue 1336. (that said, > if anybody can jump in and solve it instantly with a patch, go right > ahead! if this issue is solved, we'll just pick another one) > http://code.google.com/p/lilypond/issues/detail?id=1336 > > There is a theory about why this happens, from Neil: >> It looks to me like the MultiMeasureRest has invalid bounds when cloned, so >> the cloned object is NULL when the MultiMeasureRestNumber is aligned (the >> parent object no longer exists) > > Can anybody think of a way to test this theory? i.e. I'm not asking > how to stop this from happening. I'm not even asking for solid > evidence that this is, in fact, happening. I'm just asking how we > could *begin* the *attempt* to gather such evidence. I've identified that it is in fact the MultiMeasureRestNumber that is causing the problem. My version of your patch that sets the offset to zero rather than exiting results in the MMRNumber showing up at the far left of the page. The "invalid bounds" part of it is demonstrated in the error message when bad.ly is run: bad.ly:8:2: programming error: Spanner `MultiMeasureRest' is not fully contained in parent spanner. Ignoring orphaned part This error message comes from lily/spanner.cc. There is a method in lily/spanner.cc called clone: 29 Grob * 30 Spanner::clone () const 31 { 32 return new Spanner (*this); 33 } The clone method is called from Spanner::do_break_processing 60 else if (bound->get_system ()) 61 { 62 Spanner *span = dynamic_cast<Spanner *> (clone ()); 63 span->set_bound (LEFT, bound); 64 span->set_bound (RIGHT, bound); 65 66 assert (span->get_system ()); 67 span->get_system ()->typeset_grob (span); 68 broken_intos_.push_back (span); 69 } Also, the clone method would be called if the error message weren't issued: 113 bool ok = parent_rank_slice.contains (bounds[LEFT]->get_column ()- >get_rank ()); 114 ok = ok && parent_rank_slice.contains (bounds[RIGHT]->get_column ( )->get_rank ()); 115 116 if (!ok) 117 { 118 programming_error (to_string ("Spanner `%s' is not fully conta ined in parent spanner. Ignoring orphaned part", 119 name ().c_str ())); 120 continue; 121 } 122 123 124 Spanner *span = dynamic_cast<Spanner *> (clone ()); 125 span->set_bound (LEFT, bounds[LEFT]); 126 span->set_bound (RIGHT, bounds[RIGHT]); I actually think this may be a profitable place to investigate. My attempts have taken a slightly different tack. I'm looking up the backtrace, trying to see if I can do something with understanding the delayed evaluation chain (frames 4-6). Going above the delayed evaluation, I get to get_offset and relative_coordinate, both in lily/grob.cc. Looking in relative_coordinate, I see 300 Real 301 Grob::relative_coordinate (Grob const *refp, Axis a) const 302 { 303 /* eaa - hmmm, should we do a programming_error() here? */ 304 if ((this == NULL) || (refp == this)) 305 return 0.0; 306 307 /* We catch PARENT_L_ == nil case with this, but we crash if we did 308 not ask for the absolute coordinate (ie. REFP == nil.) */ 309 Real off = get_offset (a); 310 if (refp == dim_cache_[a].parent_) 311 return off; 312 313 off += dim_cache_[a].parent_->relative_coordinate (refp, a); 314 315 return off; 316 } This looks like a promising place to investigate some more, because I don't really see that we "catch PARENT_L_ == nil case". But I haven't yet had the time to investigate this. HTH, Carl _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
