R devel - May 2018 - debugonce() functions are not considered as debugged

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.

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()`.

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

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

On Wed, May 23, 2018 at 11:03 AM Tomas Kalibera <tomas.kalibera at
gmail.com>
wrote:
[...]
> 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"?
No, not really. What I have is an event loop that performs tasks. A task is

basically a function call. The tasks are scheduled by a scheduler, and it
is painful to debug them, because they are always called from the event
loop,
and the stack is uninformative.

The helper functions aim to help with this, as much as possible.
You can call them from a browser(). They are things like:
- list all tasks
- perform one tick of the event loop
- run the event loop until a task finishes, etc.

There is a helper to debug a task, i.e. to debug() or debugonce() the
function that performs the task. So I get a(nother) browser() when the task
starts.

Now in the list of tasks, it would be nice to see which ones are
flagged with debugging and which ones are not, unset the debug flag, etc.

Anyway, if you think this is not useful, it is not essential for me.
Maybe I can also just use debug(). I just did not understand why
this was not part of the API, and seemed like an omission. If it is
a deliberate choice, that's fine then.

Gabor
> 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