Re: [Rd] 'unique' error message is printed despite silent=TRUE (PR#13547)

From: Wacek Kusnierczyk <Waclaw.Marcin.Kusnierczyk_at_idi.ntnu.no>
Date: Mon, 23 Feb 2009 00:22:10 +0100

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_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Sun 22 Feb 2009 - 22:25:18 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Mon 23 Feb 2009 - 01:30:35 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.

list of date sections of archive