Skip to content

debugonce() functions are not considered as debugged

4 messages · Tomas Kalibera, Gábor Csárdi

Original
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:
1 day later
Gábor Csárdi
# 
On Mon, May 21, 2018 at 5:01 PM Tomas Kalibera <tomas.kalibera at gmail.com>
wrote:
[...]
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
flag
Tomas Kalibera
#
On 05/22/2018 06:07 PM, G?bor Cs?rdi wrote:
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.
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
Gábor Csárdi
# 
On Wed, May 23, 2018 at 11:03 AM Tomas Kalibera <tomas.kalibera at gmail.com>
wrote:
[...]
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