rascal
rascal copied to clipboard
Add debugging hint to repl help
It is not easy to "discover" how to start a debugging session in VS Code.
It would be nice to describe it on this page https://www.rascal-mpl.org/docs/GettingStarted/RunningRascal/VScode/
This Stack Overflow answer/comment is how I discovered it.
Hmm, yes, the discoverablity of the debugger is low, which was a bit intentional, as it has some strange behavior we're not completely happy with. But in many ways, it's nice.
However, maybe we should do this change in rascal-language-server, as that's the only place where we support this command. We've extended the :set command in a similar way there.
What do you think @jurgenvinju ?
Codecov Report
Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.
Project coverage is 49%. Comparing base (
4aaee5d) to head (dc052f8). Report is 491 commits behind head on main.
| Files with missing lines | Patch % | Lines |
|---|---|---|
| src/org/rascalmpl/interpreter/Evaluator.java | 0% | 1 Missing :warning: |
Additional details and impacted files
@@ Coverage Diff @@
## main #1994 +/- ##
=======================================
Coverage 49% 49%
- Complexity 6290 6304 +14
=======================================
Files 664 664
Lines 59558 59559 +1
Branches 8639 8639
=======================================
+ Hits 29428 29466 +38
+ Misses 27921 27879 -42
- Partials 2209 2214 +5
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
If we add it here we should make it conditional on the existence of debugging features. I do agree about the low discoversbility.
Another solution would be to activate the debugger when the first breakpoint is set.
Another solution would be to activate the debugger when the first breakpoint is set.
There were quite some limitations on how to start a debug session from VS Code, especially since there is no launch/debug configuration in the project. If we start generating that for every project, it might be doable, but still, what if I have 3 REPLs open, to which one do you connect?
We could also just print a message in the repl at the start of it? Like: did you know...
We could also just print a message in the repl at the start of it? Like: did you know...
That would be better than nothing, but "start of it" disappears pretty quickly. But if you mean "after all the initialization and just before user input", that sounds fine.
Any advice on how to improve this PR?
This is my REPL just now - after not debugging for several weeks...
rascal>:help
Welcome to the Rascal command shell.
Shell commands:
:help Prints this message
:quit or EOF Quits the shell
:set <option> <expression> Sets an option
e.g. profiling true/false
tracing true/false
errors true/false
:edit <modulename> Opens an editor for that module
:test Runs all unit tests currently loaded
Example rascal statements and declarations:
1 + 1; Expressions simply print their output and (static) type
int a; Declarations allocate a name in the current scope
a = 1; Assignments store a value in a (optionally previously declared) variable
int a = 1; Declaration with initialization
import IO; Importing a module makes its public members available
println("Hello World") Function calling
Please read the manual for further information
ok
rascal>:set debug true
ok
rascal>:set debugger true
ok
rascal>:set debuging true
ok
rascal>:set debugging true
Debugging session started.
ok
@urbanfly we should move this towards usethesource/rascal-language-servers as there is where this new command is introduced in the REPL.
For example here: https://github.com/usethesource/rascal-language-servers/blob/3d02641b265a7276082c34836545caf02ff50aa0/rascal-lsp/src/main/java/org/rascalmpl/vscode/lsp/terminal/LSPTerminalREPL.java#L111
But we should also try and change the :set command (in this repo) to properly report unsupported flags, and maybe print out the currently supported flags.
One of the problems is, this code (the REPL) needs to be revised to migrate to jline3, you raise some good points about how this interaction can be improved, but changing the infrastructure around commands (and their relevant help messages) too much right now would be wasted effort, as much will change when switching to jline3.
what if I have 3 REPLs open, to which one do you connect?
all of them that have the given module on their path. That's the way it works for the JDT as well. A breakpoint in a file informs all debugging sessions, no matter wh
Closing this in favour of the following developments:
- jline3 auto complete will include debug as a flag (with some help around it)
- in VS Code we now have a view that lists active terminals (see https://github.com/usethesource/rascal-language-servers/pull/564 for screenshot)