Conditional debugger breakpoint?
sepsol opened this issue · 16 comments
This is supported by this debugger and by the builtin VSCode debugger already.
Hmmm, that is weird. For some reason, this is not working for me.
2023-08-30_11-04-31.mp4
Am I doing anything wrong here?
This is strange. Do the usual unconditional breakpoints (or debugger
statements) work there?
@awto Yes sir! In fact, I do demonstrate them in the first 30 seconds of the recording. The second 30 seconds is for Effectful.
EDIT 1:
Sorry, I got your question wrong. I just tested and apparently, they don't.
EDIT 2:
I did a few more tests and apparently the only place the breakpoints (usual or conditional) work with Effectful config, is in the custom index.js
file I created as the entry point of my debugger.
In the screenshot below, I opened the index.js
file and highlighted it with red arrows. Any other breakpoints I put inside the directory highlighted with yellow rectangle (the 0.2
branch of the repository for the open-source pdfmake
package) don't work.
Although, all breakpoints (usual or conditional) work inside or outside that directory.
Also, below is my launch.json
, also visible in the recording I shared earlier:
{
"version": "0.2.0",
"configurations": [
{
"name": "Custom (Basic)",
"type": "node",
"request": "launch",
"skipFiles": [
"<node_internals>/**",
],
"program": "${workspaceFolder}/index.js",
},
{
"name": "Custom (Effectful)",
"type": "effectful",
"request": "launch",
"preset": "node",
"cwd": "${workspaceFolder}",
"command": "node",
"args": [
"index.js"
],
"console": "integratedTerminal",
"timeTravel": true,
},
],
}
It looks like a known problem described here - interoperating-with-runtimenative-modules. It's likely there is some builtin node streams callback or anything native calling your function, or from some not-instrumented 3rd party JS.
Could you send the stack trace where it stops in the vscode built-in debugger to be sure?
Unfortunately, if this is the problem, I cannot do much. It's too heavy to implement for me alone, at least now.
On the positive side, such breakpoints should still work when you run backward or forward but with the already executed and recorded traces. This works only if you use effectful with time traveling enabled (why would you use effectful without, though).
So Effectful debugger should still be helpful if you first run the whole program without stopping, but after this, run backward/forward to the interesting points. All breakpoints, including conditional and data breakpoints, should work. Please, let me know if not.
I see. Here's the call stack for the built-in debugger along with the file that has the breakpoint and its condition:
You're right! The "time-travel" feature is exactly what I found interesting about the Effectful debugger.
I tried setting a conditional breakpoint inside a file in my pdfmake/src
directory and another one inside the root index.js
that I created for the debugger entry point, right before the program finished execution. Even in this case, the outer breakpoint worked fine while the inner breakpoints didn't work (I couldn't "Reverse" or "Continue"). Although, I was able to manually "Step Back" as you described. But no luck with the inner breakpoints.
This is interesting. I thought the problem was the node streams, but it's not even called from the node streams but the initial constructor. I'll check but I'm not sure when. Could you run it with the following added into launch.json:
"env": {
"BABEL_DISABLE_CACHE": "1",
"EFFECTFUL_DEBUGGER_VERBOSE": "2",
"EFFECTFUL_VERBOSE": "1",
"EFFECTFUL_DEBUG_DEBUGGER": "1"
}
and send the output here?
Sure thing, I've pasted the logs in this gist. Thank you for looking into this issue!
Does it also output anything into the Debugger output? I also need some docDefinition and index.js to reproduce this. Could you send them?
Sure, here's the output of the debug console. I also created this repo as a reproducible example.
This should be fixed in 1.4.9. I also implemented stopping in node streams and node events callback. The node streams, however, will need some config. There are details here.
Please let me know if this works for you, and thanks for the report.
Thank you for your efforts on the project! I just tried the update. I can now set unconditional usual breakpoints in the nested pdfmake
directory, but I can't set conditional breakpoints using builtin VS Code debugger for some reason. The only way for me to set conditional breakpoints is to use the inline if (i === 3) debugger;
syntax in JavaScript which is not ideal since one has to remember to remove them before committing their changes.
The built-in VS Code debugger isn't from my department. I don't even use it (as an author of Effectful Debugger, it would be a shame if I did). This is something for the VSCode GitHub ticket. Please feel free to reopen this ticket or make a new one if anything needs to be fixed with Effectful Debugger or if you have questions. Thanks!
I might have expressed the matter wrong. By "VS Code debugger" I meant the "red breakpoint dots" that you can set on the left side of code lines instead of using the debugger
keyword in languages like JavaScript (See the issue description above).
Basically what I'm saying is that the debugger
now always works anywhere within the project, but for the breakpoints that are set using the "red-dot", only the usual ones work in the files nested inside the pdfmake/src
directory but the conditional "red dots" don't work.
The actual builtin VS Code debugger works fine in all cases: usual/conditional, red-dot/debugger.
The same breakpoint as in your example works for me. Except this is line 638 in the file layoutBuilder.js I cloned from your repository. And not 656 like in your example. But I don't expect any problems with this. Could you rerun it with:
"env": {
"BABEL_DISABLE_CACHE": "1",
"EFFECTFUL_DEBUGGER_VERBOSE": "2",
"EFFECTFUL_VERBOSE": "1",
"EFFECTFUL_DEBUG_DEBUGGER": "1"
}
in launch.json. And send me the whole output from the terminal (not from the Debug tab). On running it should create a terminal called "Effectful Debugger Console".
I just tried again and confirmed that the issue has indeed been resolved as you said. Thank you so much for taking the time to fix it; I really appreciate your hard work. Sorry for the confusion.