I'm trying to walk through the Parenscript library to see how it renders, i.e. what actually happens when you make a (ps... ) call.
Ideally, I'd use VSCode to set breakpoints and watches and step into all called functions. There doesn't seem to be any lisp debugging extension in the VSCode marketplace.
Right now, I'm loading sbcl in a terminal window in VSCode and have command-shift-A bound to Terminal: Run Selected Text In Active Terminal, so that anything I write in the editor can be executed in sbcl.
Is there a way to set up the VSCode environment so that I can have access to debugging tools like watches and step-into?
Related
I'm new to contribute to vscode and began to improve some small bug in VSCode builtin extension, markdown-language-features.
when setting breakpoints in TypeScript file (like activeLineMarker.ts
in vscode/extensions/markdown-language-features/preview-src/ or activeLineMarker.js in out directory), the breakpoint become unbound when start debugging.
unbound breakpoint pop-up window
Is there any way or configuration to debug with step-by-step line execution with breakpoints for developping extensions?
The developping environment is just created recently with the official procedure.
Code OSS is successfully launched with Start Debugging (F5) and I can see changes when modifying sources.
The official document says;
The extension host process runs code implemented by a plugin. To debug extensions (including those packaged with VS Code) which run in the extension host process, you can use VS Code itself. Switch to the Debug viewlet, choose the Attach to Extension Host configuration, and press F5.
and doing so results in nothing happening (the debugging seems to want to start but fails, maybe time-out).
After building, there is sourcemap file like activeLineMarker.js.map in out directory.
Ideally, the integrated VS Code terminal, depending on the context, the type of the folder and the extension, executes some commands. For example, when opening a folder containing a Python virtual environment in VS code, the environment is recognized and activated (by the python extension) by default when opening a new integrated terminal instance (situation 1). This is done by running some command similar to source /path/to/venv/bin/activate.
Or, when using the ROS extension to debug nodes, selecting "Start Debugging (F5)" uses the launch.json file to start some nodes and finally starts debugging the desired code. To do so also, there is some command that is executed (also by he ROS extension, I assume) in the integrated terminal (situation 2) to start the debugging process. In case of debugging ROS nodes, the command usually looks something like /usr/bin/env /bin/sh /tmp/someFileName.
But, unfortunately, both of the above mentioned situations fail. I believe this happens because while the extension tries to run these two commands within their respective integrated terminals, the commands do not actually get executed in either situation. Instead, these commands are printed on the top of the terminal, but the state of the terminal is unchanged (as opposed to when the commands would have been executed, in which case depending on the commands some actions are performed). Here are two images to show what I mean. Top, situation 1 and bottom, situation 2.
The fact that these two commands are printed on top of the terminal as soon as the a new terminal instance is opened tells me that the extension tries to execute them, but they do not work for some unknown reasons.
Just to be clear, both of them are run in a seperate VC Code window, they have nothing to do with each other. When I manually run both the commands in their respective terminals I do get the desired results.
Now, I am unsure exactly how to name this issue. But I think this is surely an issue with the integrated terminal, and not a problem of the extensions. I am not sure how one could reproduce this problem.
I did a clean reinstall of VS code by deleting %APPDATA%\Code and %USERPROFILE%\.vscode. Because I am using this on WSL, there is only ~/.vscode-server on the ubuntu side. I manually uninstalled all extensions on WSL but did not delete this folder, in fear of breaking something. The problem still persisted. I have also created an issue on the VS Code GitHub page with nearly the same information.
I am unsure if this is a bug or is there something wrong with my settings. Does anyone know how I could fix this? For smaller use-cases I can still manually enter the command in the terminal. But I am trying to debug a ROS application with nearly 10 different terminals opening up and I cannot be manually entering the command each time to restart the process.
Please let me know if you need any more information. Many thanks in advance.
Edit: both edits to frame the question properly.
Although not related to WSL, I dug a little deeper today as to why in my case the extension commands were not being executed or were being chopped.
I'm an iTerm2 user. iTerm2 has something called Shell Integrations, which allow iTerm to behave differently under certain circumstances, for example, adding markers to each prompt or coloring output with certain text (e.g. WARNING or ERROR)
From time to time, I also use the VSCode Integrated Terminal, which recently added support for reporting whether the previous command errored out with an indicator on the gutter of the Integrated Terminal panel using the exit code.
iTerm can do something similar but the shell integrations mess up completely the VSCode functionality and therefore I changed my .bashrc file to detect if the terminal emulator was iTerm2 or not (which can be done with the it2check utility of iTerm2) so that it only sourced the shell integrations if I was using iTerm2.
The problem is that it2check "eats" some STDIN bytes using dd, specifically, until it finds an n so that it can obtain the name of the emulator. This of course chops the commands on the STDIN until the first n and makes VSCode Extension Terminal commands unusable
The workaround I came up with is to use the value of "$TERM_PROGRAM" as means to distinguish between the different programs. The only caveat is that the value won't be passed if you're inside of a tmux session or similar, but I can live with that.
In your case, I'd check for any process that is either not passing the STDIN to the WSL process or any dot files or shell profile scripts eating up the STDIN they receive.
I suspect that the real problem is that the local process doesn't relay the STDIN contents to the WSL and as a workaround you may try to create a VSCode Integrated Terminal profile that uses SSH to connect to the WSL host so that the STDIN is preserved
I've forked VSCode on Github to try to add a tiny little feature I think would be useful, which adds a new CLI flag to code, to be used inside the VSCode terminal (like code - for stdin). I added the code, wrote tests, and now I want to try out the feature.
I'm developing inside the built-in devcontainer, so I just launched an instance of VSCode from within VSCode, connected to the devcontainer via VNC and tried to use my flag inside the VSCode-OSS terminal. However, I get an error saying "Command is only available in WSL or inside a Visual Studio Code terminal"
According to server.cli.ts, this means that the env variables VSCODE_IPC_HOOK_CLI and VSCODE_CLIENT_COMMAND aren't set, but I don't know who should be setting them, or if I need to launch VSCode in a different way for debugging.
Has anyone using the VSCode DevContainer to write additional CLI flags and knows how to debug them?
I'm new to coding Python in VSCode. Previously I used Spyder but decided to move to VSCode as the project management seems better in it (I could easily switch to other files/folders by clicking on the path, just like in PyCharm). But I really need this one workflow which I still have not managed to do it in VSCode.
write some codes like Selenium.
Click run (F5)
The selenium browser opens up.
I could use the Ipython terminal to access the code interactively (find the element in the browser etc) and send new command.
I would like to have this workflow in VSCode. Im also quite overwhelmed by the difference in these 2 IDEs, for example, in VSCode, you have integrated terminal, a debugging console and an output tab, while im used to have only one-for-all Ipython tab.
Ok, I figured out what I need. Basically I just need to right click on the python file that I want to run on the side bar. Then I have to select 'run current file in interactive window'. The only difference is on the Ipython console, I have to use shift+Enter to send my input instead of just clicking enter. But its not a big deal.
I am working on two projects, one is a library, the other is a program that uses that library. When I make changes to the library the other window (the program) doesn't see these changes, so I do not get updated IntelliSense. Closing the program that uses the library and reopening it does force an update but I really prefer not having to go that far.
Answering the title directly and not the root issue...
You can reset IntelliSense and all Rust code features by running the "Rust: Restart the Rust server" command from the command palette (Ctrl+Shift+P).
Progress will be indicated in the status bar.
Still a blunt tool but it will ensure you're in a fresh state without having to restart VS Code entirely.