Duncan Murdoch wrote: > On 22/02/2009 4:38 PM, Wacek Kusnierczyk wrote: >> Duncan Murdoch wrote: >>>> hmm, why wouldn't you use something like >>>> >>>> DEBUG(x) >>>> >>>> with DEBUG being a macro defined so that it's replacement is void >>>> unless >>>> a specific flag or environment variable is set specifically for the >>>> purpose of debugging? you would then avoid confusing users' code just >>>> because one PrintValue has been inadvertently left in the sources. >>> But then we'd confuse developers, who would see a huge dump of messages >>> from every other debugging session, when they just wanted to see their >>> own, and who would be forced to wade through leftover never-used >>> DEBUG(x) calls in code when they were reading the source. >>> >> >> my point was not that such DEBUG statements should be left there in the >> code for all eternity. to the contrary, their role would be quite the >> same as that of the PrintValue discussed here. it would, however, be >> easier to switch between printing and not printing such debugging >> messages, and also easier to spot DEBUG statements inadvertently left in >> the code. > > Sorry, I misunderstood. Yes, that might be handy. > > The main problem is agreeing on what macros to write, and what should > happen when the external flag is set. In my experience, people who are > good at debugging have long-established idiosyncratic habits, and are > just annoyed when things change. >
well, ok, but it sounds odd to me that in a large multideveloper project where not only people are allowed to use their idiosyncratic habits (and leave bug-inducing footprints behind), but even the idea of having a consistent way of printing debug messages seems not to have been discussed (how much am i off here?). > For example, a number of people have suggested that compiles should > switch to optimization level 0 when compiling for debugging. This > makes stepping through code easier, because (as far as I recall) > variables aren't optimized out, code isn't rearranged, etc. But it > means some bugs change their behaviour: and I really hate that. So I > wouldn't mind if it were possible to request that, but I'd want to > make sure the default is to ask for debugging support without it: I > don't want to waste my time looking at a different program when I'm > trying to track something down. > > If we had DEBUG(x) which became PrintValue(x) when a certain flag was > set, I probably wouldn't use it, because it requires two things: set > the flag as well as add the statement. I'd find that just irritating. > (I rarely use PrintValue in any case: most of the types of bugs I'm > looking for need Rprintf or REprintf instead. So we'd need at least > three macros.) > it was just a loose suggestion, and you certainly know better both the r sources and the developers' habits. i have no vote. >>> This is not a common error: as far as I know, there are no other >>> unintentional PrintValue calls anywhere in the source. So I think the >>> current system (just take them out before committing) is working. >> >> grep --include=*.c -R '\bPrintValue\b' src | wc -l >> >> reports 21 occurrences of PrintValue, though of course i cannot say >> anything about their being intentional or not unless i examine the >> sources. if they were DEBUGs, you'd know for sure they're not supposed >> to stay there in a release version. > > I did a quick examination of the source and I think the ones that > aren't commented out look intentional. (I was following my rule 5 of > debugging: look for similar errors elsewhere.) > >> it's just to wish that those who introduce debugging PrintValues >> examined diffs carefully before their code is released. given the size >> of r sources (and their fairly ad hoc shape here and there), few others >> than the author will know for sure whether the PrintValue is a debugger >> or not? apparently, no one has noticed in this case. were it DEBUG >> instead of PrintValue, it would suffice to run a grep to catch it. > > People who commit any changes should examine them carefully, and in > general they do. Sometimes things slip by. In this case, the slip > was there for 5 years before anyone noticed it, and I don't think it > caused a lot of harm: it was an error message that printed incorrectly. yes, though irrespectively of the consequences, it still was a bug, no? (have you thanked stavros for reporting it?) vQ ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
