On 05/22/2018 06:07 PM, Gábor Csárdi wrote:
On Mon, May 21, 2018 at 5:01 PM Tomas Kalibera <tomas.kalib...@gmail.com>
wrote:
[...]
Do you have a good use case when it would be useful to query/unset the
mark for debugonce?
Well, I suppose the same use cases when it is useful to query/unset the
other debug
mark.
I asked because the use cases for undebug/debugonce I can think of do
not apply. undebug() is needed once you have run a function through a
debugger few times and figured out there is no bug there but you want to
run again debugging from somewhere else. It is like deleting a
breakpoint in say gdb. undebugonce() would make no sense in this
context, because it is done implicitly. undebugonce() would only make
sense if you called debugonce() but then changed your mind before
running that function, but, that does not seem like a common use case
worth supporting.
Re isdebugged(), I think the current semantics is already problematic.
The name of the function and its existence makes it tempting to believe
it tells us whether a given function is being run in a debugger
currently, but it is not what isdebugged() does, the debugger can be
entered by other means, including via debugonce(). Moreover, writing
code that depends on whether a function is being run in a debugger feels
wrong (e.g. even extra messages or assertions), because that would take
different code path and the person debugging would not have control over
it. It is better to turn on some extra messages/assertions via other
means. Still, isdebugged() is sometimes used in this context and it
sometimes returns the correct value: if a function has been entered as a
result of debug() called on that function, isdebugged() will be TRUE.
isdebuggedonce() would be always wrong in this context when debugging,
because the flag has been cleared, which would add further confusion.
isdebuggedonce() could only again help the user to refresh their memory
on whether they set the flag, but that does not seem to be a use case
worth supporting.
To be more specific, in debug helpers for a tool that works with callbacks
from a central event loop, it is nice to be able to tell which callbacks are
"debugged" currently, either via `debug()` or `debugonce()`.
As I said I think it would be wrong to use such function in code, but in
principle isdebugged() could be changed to detect whether a given
function will be debugged due to debug() or debugonce() or is currently
being run in a debugger for those or any other reason (e.g. via explicit
call to browser(), using "s" in the debugger, etc). This would abstract
away the difference between debug() and debugonce(). It would still
involve confusion when the function is being run in a debugger, but not
on the top of the call stack... Is this the behavior you had in mind for
the "helpers"? And, if so, why? What would the "helpers" do specially
when isdebugged(fun) returned TRUE, why is that an important use case?
Tomas
Gabor
Best,
Tomas
On 04/28/2018 01:57 PM, Gábor Csárdi wrote:
debugonce() sets a different flag (RSTEP), and this is not queried by
isdebugged(), and it is also not unset by undebug().
Is this expected? If yes, is there a way to query and unset the RSTEP
flag
from R code?
❯ f <- function() { }
❯ debugonce(f)
❯ isdebugged(f)
[1] FALSE
❯ undebug(f)
Warning message:
In undebug(f) : argument is not being debugged
❯ f()
debugging in: f()
debug at #1: {
}
Browse[2]>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
