13 messages · Stavros Macrakis, Wacek Kusnierczyk, Peter Dalgaard +1 more
In 2.8.0/Windows Vista: When 'unique' gives a type error message, it prints out even if errors are being caught:
try(unique(quote(hello)),silent=TRUE)
hello This comes from the .Internal unique routine:
try(.Internal(unique(quote(hello),NULL,NULL)),silent=TRUE)
hello
I guess it is using the internal equivalent of print rather than the
internal equivalent of stop.
-s
In 2.8.0/Windows Vista: When 'unique' gives a type error message, it prints out even if errors are being caught:
try(unique(quote(hello)),silent=TRUE)
hello This comes from the .Internal unique routine:
try(.Internal(unique(quote(hello),NULL,NULL)),silent=TRUE)
hello I guess it is using the internal equivalent of print rather than the internal equivalent of stop.
line 454+ in src/main/unique.c:
if (!isVector(x)) {
PrintValue(x);
error(_("%s() applies only to vectors"),
(PRIMVAL(op) == 0 ? "duplicated" : "unique"));
}
in your example, quote() produces a non-vector, hence the output before
the error message.
vQ
In 2.8.0/Windows Vista: When 'unique' gives a type error message, it prints out even if errors are being caught:
try(unique(quote(hello)),silent=TRUE)
hello This comes from the .Internal unique routine:
try(.Internal(unique(quote(hello),NULL,NULL)),silent=TRUE)
hello I guess it is using the internal equivalent of print rather than the internal equivalent of stop.
Still there in R-devel; I'll see if I can fix it. Duncan Murdoch
In 2.8.0/Windows Vista: When 'unique' gives a type error message, it prints out even if errors are being caught:
try(unique(quote(hello)),silent=TRUE)
hello This comes from the .Internal unique routine:
try(.Internal(unique(quote(hello),NULL,NULL)),silent=TRUE)
hello I guess it is using the internal equivalent of print rather than the internal equivalent of stop.
silent=TRUE is a red herring (this has nothing to do with try()).
However, inside do_duplicated (unique.c) we have
if (!isVector(x)) {
PrintValue(x);
error(_("%s() applies only to vectors"),
(PRIMVAL(op) == 0 ? "duplicated" : "unique"));
}
This is due to
------------------------------------------------------------------------
r32306 | ripley | 2004-12-23 22:06:27 +0100 (Thu, 23 Dec 2004) | 2 lines
Apparently unique/duplicated are supposed to work on NULL, despite their
help!
...which makes little sense to explain the PrintValue(x). I suspect this
is a debugging printout that was inadvertently left in.
O__ ---- Peter Dalgaard ?ster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907
macrakis at alum.mit.edu wrote:
In 2.8.0/Windows Vista: When 'unique' gives a type error message, it prints out even if errors are being caught:
try(unique(quote(hello)),silent=TRUE)
hello This comes from the .Internal unique routine:
try(.Internal(unique(quote(hello),NULL,NULL)),silent=TRUE)
hello I guess it is using the internal equivalent of print rather than the internal equivalent of stop.
silent=TRUE is a red herring (this has nothing to do with try()).
However, inside do_duplicated (unique.c) we have
if (!isVector(x)) {
PrintValue(x);
error(_("%s() applies only to vectors"),
(PRIMVAL(op) == 0 ? "duplicated" : "unique"));
}
This is due to
------------------------------------------------------------------------
r32306 | ripley | 2004-12-23 22:06:27 +0100 (Thu, 23 Dec 2004) | 2 lines
Apparently unique/duplicated are supposed to work on NULL, despite their
help!
...which makes little sense to explain the PrintValue(x). I suspect this
is a debugging printout that was inadvertently left in.
Now removed. Duncan Murdoch
macrakis at alum.mit.edu wrote:
<snip>
try(.Internal(unique(quote(hello),NULL,NULL)),silent=TRUE)
hello I guess it is using the internal equivalent of print rather than the internal equivalent of stop.
silent=TRUE is a red herring (this has nothing to do with try()).
However, inside do_duplicated (unique.c) we have
if (!isVector(x)) {
PrintValue(x);
error(_("%s() applies only to vectors"),
(PRIMVAL(op) == 0 ? "duplicated" : "unique"));
}
This is due to
------------------------------------------------------------------------
r32306 | ripley | 2004-12-23 22:06:27 +0100 (Thu, 23 Dec 2004) | 2 lines
Apparently unique/duplicated are supposed to work on NULL, despite
their help!
...which makes little sense to explain the PrintValue(x). I suspect
this is a debugging printout that was inadvertently left in.
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.
vQ
Peter Dalgaard wrote:
macrakis at alum.mit.edu wrote:
<snip>
try(.Internal(unique(quote(hello),NULL,NULL)),silent=TRUE)
hello I guess it is using the internal equivalent of print rather than the internal equivalent of stop.
silent=TRUE is a red herring (this has nothing to do with try()).
However, inside do_duplicated (unique.c) we have
if (!isVector(x)) {
PrintValue(x);
error(_("%s() applies only to vectors"),
(PRIMVAL(op) == 0 ? "duplicated" : "unique"));
}
This is due to
------------------------------------------------------------------------
r32306 | ripley | 2004-12-23 22:06:27 +0100 (Thu, 23 Dec 2004) | 2 lines
Apparently unique/duplicated are supposed to work on NULL, despite
their help!
...which makes little sense to explain the PrintValue(x). I suspect
this is a debugging printout that was inadvertently left in.
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. 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. Duncan Murdoch
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.
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. 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. vQ
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. 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.)
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. Duncan Murdoch
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
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?).
I think you are just trolling now. How could we stop people from using whatever method they wanted when debugging? And we don't "allow" people to leave bugs behind, but sometimes (being fallible) they do anyways.
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?)
I hope he realizes that we do appreciate the report. That's why it got such quick attention. (I don't expect him to thank me for fixing it, either.) Duncan Murdoch
I hope he realizes that we do appreciate the report. That's why it got such quick attention. (I don't expect him to thank me for fixing it, either.)
Thanks for the amazingly quick fix.
-s
<snip>
On 22/02/2009 6:22 PM, Wacek Kusnierczyk wrote:
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?).
I think you are just trolling now. How could we stop people from using whatever method they wanted when debugging? And we don't "allow" people to leave bugs behind, but sometimes (being fallible) they do anyways.
i wasn't trolling, it was a genuine question. you're probably too sensitive. i don't see anything wrong in at least trying to achieve consensus on policies for how code is altered by various developers. <snip>
yes, though irrespectively of the consequences, it still was a bug, no? (have you thanked stavros for reporting it?)
I hope he realizes that we do appreciate the report. That's why it got such quick attention. (I don't expect him to thank me for fixing it, either.)
and why not? is it usual (an polite) to make (and express) the assumption that no one will thank you for removing a bug? vQ