Front page | perl.perl5.porters |
Postings from April 2012
On 04/10/2012 09:31 AM, Karl Williamson wrote: > On 04/10/2012 08:55 AM, Rafael Garcia-Suarez via RT wrote: >> On 9 April 2012 07:00, Karl Williamson via >> RT<perlbug-followup@perl.org> wrote: >>> On Thu Mar 22 14:49:33 2012, perl.p5p@rjbs.manxome.org wrote: >>>> * Rafael Garcia-Suarez<rgs@consttype.org> [2012-03-20T05:59:56] >>>>> I pushed a fix for this to branch rgs/overload. I strongly think that >>>>> more tests are needed in general from overload. (I guess it will be >>>>> for 5.17) >>>> >>>> Thanks, I've added this to early-5.17-stuff. >>>> >>> >>> I have tried testing this by switching to this branch. mktables (which >>> had the original problem) fails to compile because of a missing >>> overloaded op. When I comment out the single heredoc that caused this >>> problem, mktables appears to work fine, but the result file, >>> lib/unicore/lib/Gc/Cs.pl, is now very wrong. That appears to be the >>> only file in error. It is supposed to be one range, the surrogates. >>> >>> I suppose what could be going on is that an op that previously was >>> auto-generated is now not, but now there is a base class op that gets >>> used instead. and that op is wrong. >>> >>> Does this seem like a possibility, or can you think of something else >>> that could be going wrong? >> >> Given that my patch only changes some code inside an if() condition, I >> would tend to think you did not build from a completely clean source >> tree ? >> >> >> > > It's completely reproducible on a clean blead. I have found the > particular Perl line that causes the problem, and will use the debugger > to single step through the overload calls sequence to see where things > go awry. Results to follow > It turns out it is entirely my bug. So, once 5.17 opens, I'll submit fixes for my portion first, then your patch.Thread Previous | Thread Next