This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
linux:vscode [2023/10/12 11:38] – [Special case: X11 forwarding (graphics)] jansen | linux:vscode [2025/01/07 08:36] (current) – [Some common pitfalls:] jansen | ||
---|---|---|---|
Line 22: | Line 22: | ||
The page also has information about setting up a local ssh client, if you don't have one yet (Windows; putty is not supported, you need the commandline ssh client here, which is already present on Linux and Mac OS) | The page also has information about setting up a local ssh client, if you don't have one yet (Windows; putty is not supported, you need the commandline ssh client here, which is already present on Linux and Mac OS) | ||
- | Next, set up [[: | + | Next, set up [[: |
The vscode documentation has some more [[https:// | The vscode documentation has some more [[https:// | ||
Line 28: | Line 28: | ||
* Setup ssh to go directly to your target host. Sterrewacht desktops are directly reachable over the internet, no setup needed. But if you want to run on a Sterrewacht compute node, the ALICE cluster or a Institute Lorentz machine, you will need a proxy setup to go through the appropriate gateway. See [[ssh: | * Setup ssh to go directly to your target host. Sterrewacht desktops are directly reachable over the internet, no setup needed. But if you want to run on a Sterrewacht compute node, the ALICE cluster or a Institute Lorentz machine, you will need a proxy setup to go through the appropriate gateway. See [[ssh: | ||
* In the context of vscode, setting up a Proxy is NOT identical to logging in on the gateway, then loggin in to your target; if you configure vscode to go to the gateway only, vscode' | * In the context of vscode, setting up a Proxy is NOT identical to logging in on the gateway, then loggin in to your target; if you configure vscode to go to the gateway only, vscode' | ||
- | * vscode will automatically install some server code on the target to receive and handle your connections. This is conveniently done without any user interaction, | + | * vscode will automatically install some server code on the target to receive and handle your connections. This is conveniently done without any user interaction, |
- | * What usually works (NOT FULLY TESTED YET): first log in to your target server, create a directory .vscode-server on a local disk of that system, and make a symbolic link to that location in your home directory, e.g. | + | * What usually works: first log in to your target server, create a directory .vscode-server on a local disk of that system, and make a symbolic link to that location in your home directory, e.g. |
< | < | ||
ln -s / | ln -s / | ||
Line 83: | Line 83: | ||
===== Special case: remote jupyter notebooks ===== | ===== Special case: remote jupyter notebooks ===== | ||
VScode has a built-in viewer for jupyter notebooks. In the simplest setup, using the remote explorer to browse to the location of the notebook, and double-clicking it, will run the notebook and display in a vscode window. | VScode has a built-in viewer for jupyter notebooks. In the simplest setup, using the remote explorer to browse to the location of the notebook, and double-clicking it, will run the notebook and display in a vscode window. | ||
- | However, the same issues occur that also plague other jobs: you get no easy way to specify the execution environment (eg: loading the AMUSE environment in order to run the notebooks from the AMUSE docs interactive tutorial). | + | |
+ | However, the same issues occur that also plague other jobs: you get no easy way to specify the execution environment (eg: loading the AMUSE environment in order to run the notebooks from the AMUSE docs interactive tutorial). | ||
See also: [[https:// | See also: [[https:// |