[Rd] debugonce() functions are not considered as debugged

[Tomas Kalibera]

On 05/22/2018 06:07 PM, Gábor Csárdi wrote:
> On Mon, May 21, 2018 at 5:01 PM Tomas Kalibera <tomas.kalibera at 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 at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel