From c@@rdi@g@bor @ending from gm@il@com  Wed May 23 12:16:54 2018
From: c@@rdi@g@bor @ending from gm@il@com (=?UTF-8?B?R8OhYm9yIENzw6FyZGk=?=)
Date: Wed, 23 May 2018 11:16:54 +0100
Subject: [Rd] debugonce() functions are not considered as debugged
In-Reply-To: <155e361e-1d93-295a-560e-29a9aa52ac49@gmail.com>
References: <CABtg=K=Q2k8Qr7uk=XQ2Qa76NWUcG0PmDMseZ37E2RZm4=XqDQ@mail.gmail.com>
 <63f24fd9-a224-7997-fb3a-ef8f87a24306@gmail.com>
 <CABtg=KkU6wEoDWCUK8RqRv=3Z+PW1aNsK1Px7goF_K429vtphA@mail.gmail.com>
 <155e361e-1d93-295a-560e-29a9aa52ac49@gmail.com>
Message-ID: <CABtg=KmskX7Fd1vv8xxvGbpFpnj=-i3Ci01X1_7EB6-n8wQrKQ@mail.gmail.com>

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



[Rd] debugonce() functions are not considered as debugged
=?UTF-8?B?R8OhYm9yIENzw6FyZGk=?=