Re: debugonce() functions are not considered as debugged

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: debugonce() functions are not considered as debugged

Tomas Kalibera
debug(fun) marks "fun" for debugging, it makes sure that whenever "fun"
is called, the debugger is entered
undebug(fun) removes this mark; it won't stop any current debugging of
that function
isdebugged(fun) tells whether this mark is set or not; it does not tell
whether "fun" is currently running in a debugger/browser

debugonce(func) adds a different mark to the function, one that makes
sure the first time "fun" is called, the debugger is entered; this is
the same as when entering that function via "s" while debugging its
caller. There is no way to query or unset this mark.

Do you have a good use case when it would be useful to query/unset the
mark for debugonce?

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]>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: debugonce() functions are not considered as debugged

Gábor Csárdi
On Mon, May 21, 2018 at 5:01 PM Tomas Kalibera <[hidden email]>
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]>
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]>
> 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]>
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: debugonce() functions are not considered as debugged

Gábor Csárdi
On Wed, May 23, 2018 at 11:03 AM Tomas Kalibera <[hidden email]>
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]>
> >>>
> >>> ______________________________________________
> >>> [hidden email] mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel