On Tue, Sep 21, 2010 at 04:15:37PM -0700, Ben Morrow wrote: > These patches record whether a given stack frame is for a function or a > method call, by adding a new OPpENTERSUB_PRIVATE bit. I need this for > PRE and POST blocks, which have different behaviour depending on whether > a sub is called as a method or not. Aaargh. Attached patches make it easy (or easier) to do some things, but really damn hard to do others. I can't even reliably get a list of attachments. Anyway, what I wanted to say was that I'd not looked that the detail of the gubbins of this, but the way you've split it up (currently) is going to introduce intermediate states where tests fail. Which to my mind is bad, because 'git bisect' can end up hitting any of these intermediate states. I think that the "add the new file to the MANIFEST" patch should be part of the patch that creates the file. I think that the "some of these fail" comment in a test shouldn't be there, because the fixes to core functions to make them not fail should be earlier in the patch sequence. I see nothing wrong in having the change in to pass the extra flag bit, but nothing actually testing for it until a subsequent patch. > I'm not entirely sure about the parts of this which touch B: it's in > ext/, so I presume it's not dual-life, but there seem to be lots of > dual-life-ish bits of code in there. I haven't made any attempt to > preserve compat with older perls; is this wrong? Historically, when I was doing maint releases of 5.8.x, I was trying to keep one codebase, rather than forking B in maint-5.8 (and subsequently forking 3 ways for blead, maint-5.10 and maint-5.8). IIRC There was also a point when I was (mistakenly) assuming it was actually dual-lived, and being sufficiently defensive to cope with that. Nicholas ClarkThread Previous | Thread Next