Front page | perl.perl5.porters |
Postings from March 2013
On Fri, Mar 08, 2013 at 11:43:38AM -0700, Karl Williamson wrote: > On 03/08/2013 10:17 AM, Peter Rabbitson wrote: > >On Fri, Mar 08, 2013 at 10:08:43AM -0700, Karl Williamson wrote: > >>--- a/dist/Data-Dumper/Dumper.xs > >>+++ b/dist/Data-Dumper/Dumper.xs > >>@@ -12,6 +12,10 @@ > >> # define DD_USE_OLD_ID_FORMAT > >> #endif > >> > >>+#ifndef isWORDCHAR > >>+# define isWORDCHAR(c) isALNUM(c) > >>+#endif > >>+ > >> static I32 num_q (const char *s, STRLEN slen); > >> static I32 esc_q (char *dest, const char *src, STRLEN slen); > >> static I32 esc_q_utf8 (pTHX_ SV *sv, const char *src, STRLEN slen); > > > >I find it ironic that what I said here [1] turned out to be 100% > >correct. So now we have a ton of time wasted by Jim Keenan and tests > >rewritten for no reason other than possibly introducing extra bugs to > >them. Way to go :( > > > >[1] http://www.nntp.perl.org/group/perl.perl5.porters/2013/03/msg199881.html > > > > > I am the one who broke it in the first place, and you were right > that that person could simply add an #ifdef in the right place. > > The reason I didn't notice that I was the culprit is because of the > leading underscore in the error message. I knew I hadn't done that. > Yesterday on #irc, someone pointed out that that the underscore > might be added by some C compilers; something I didn't know. > > My point is that we all come here with varying skill sets and > knowledge; and no one knows it all. Hopefully we learn from our and > others' mistakes, and we make fewer over time. > > I made the change that broke D:D for older Perls. I did not realize > there was an issue in patching a core module in that it could be > dual-lived. perlhack does not address the issue. Our documentation > needs to be updated about this; I don't know what it should say. > Suggestions welcome. > > I haven't been following this thread, because it is out of my area > of expertise, so I don't understand the issues, and don't have an > opinion on what is best. I do believe that your statement "Way to > go" is demotivating of people who have worked on it, and was > unnecessary and anti-constructive. The "way to go" comment was only aimed at the fact that now we have a rewritten D::D test suite, which in my opinion is very anti-constructive (in fact outright dangerous). That despite me earlier chiming in wrt the test suite "problem" being a red herring. I still maintain that this (splitting of the tests) should not have happened. > One lesson that could be learned from this is to use Nicholas > Clark's bisect tool early. That would have pinned me as the > culprit, and I would have gotten involved then. I suspect that you > have enough expertise so that you could have done that yourself. I (apparently wrongly) assumed that the underlying problem (failure to compile the .xs part) was apparent from the first message referencing this issue. As I noted earlier - I do not know much about the lifecycle of a C program (including compilation linking and all other vagaries). Hence I automatically assume to be at the bottom of that particular foodchain, and if *I* see something, then "obviously" everyone else sees the problem too. So my point of view at the time was (and still kinda is): "Anyone with basic C chops knows what the underlying issue is, but refuses to fix it for "unsupported perls" on principle, and instead the remaining folks rather piss about with working around this in the tests". Forgive me for being exasperated given the above. My comments may be harsh but I refuse to qualify them as being "unnecessary". CheersThread Previous | Thread Next