VS Code - some process and useful tips

[adrifoster]

@samsrabin and I are users of VS Code (perhaps others are as well?) and we've been getting requests for showcasing how we use VS Code.

In particular, I just figured out how to use the remote configuration of VS Code - so I'm using it on my own personal computer, but I'm viewing and editing files on cheyenne.

So, here are (hopefully complete) instructions for getting VS Code to work for editing and debugging code on cheyenne or some other remote machine.

Basics

1. Download and install VS Code on your personal machine. Download it here. I installed this a while ago and I believe it was easy? Note that I have a Mac (Ventura 13.5.1) with an Intel chip. I know this works great on Linux machines. Not sure about Windows, but since Microsoft makes it I really feel like it should work??

2. Open VS Code! First do this from your Applications folder.

3. Set VS Code up so that you can open it form the terminal with code or code $filename.
   - Type Ctrl (or Command) + Shift + P to open the Command Palette
   - Type "shell command" to find Shell Command: Install 'code' command in PATH command and hit enter
   - Restart the terminal for this to work.

4. Open up a test workspace - use this to start
   src.zip
   - Inside VS Code, use Cmd + O to open the src folder
   - This should open up a workspace and you should see the folder and files on the left hand Explorer panel
   - Click on fibonacci.f90
   - If you just downloaded VS Code it probably doesn't have any syntax highlighting (Boo) but we'll fix that later

5. Open a terminal inside VS Code.

   • Click the box with the white rectangle on the bottom on the top panel - all the way to the right
   • Then open the "Terminal" section that just popped up on the bottom. You'll also see some other sections like "Debug Console"
     

6. Try to compile and run this program - it should work - inside that terminal window. I used gfortran -o fibonacci fibonacci.f90 get_integer.f90 After compilation you can try to run it as well: ./a.out
   

In general I move around files, do git stuff, etc. inside terminal windows in VS Code, but you of course don't need to.

7. Add some extensions!

   • Click on the Extensions tab on the left panel (looks kind of like a Tetris game?)
     

   • You can search (e.g., "Fortran") for ones you want

   • Ones I'd recommend: Modern Fortran, C/C++, Remote - SSH

   • I use some Python ones, but I think those come standard?

8. You may have to install fortran-language-server for this to work. In the terminal, you can do this using pip, e.g., pip3 install fortran-language-server

   • Then you might also need to tell the Modern Fortran extension where your fortls binary is. Try using the which fortls command in your terminal. Then go to the Modern Fortran extension's settings and add that path in the Fortran > Linter: Compiler Path and Fortran > Fortls: Path settings. Please note that I also unsynced these (by clicking the gear icon) so that these wouldn't (?) sync between my local and remote settings, since they will be different. I'm not sure this is necessary but it seems to be working.
   • Now you will need to reload your workspace for it to work. Type "Cmd + Shift + P" again and type reload, you should see Developer: Reload Window - click that.

Now you should be able to see syntax highlighting, as well as some Intellisense features for Fortran. For example, if you hover your mouse over a variable or function, you should see some information pop up about it. You can also "Command + Click" on a function/module/subroutine to take you to its definition. VS Code will open the relevant file and go to the function/variable/subroutine definition.

Remote Usage

Okay so the cool thing I just figured out how to do was using this remotely on Cheyenne.

1. Make sure you have the Remote - SSH extension installed
2. Type Cmd + Shift + P for the command palette and type "remote"
3. You should see some different options - click on "Connect Current Window to Host"
4. You might see some options if you've already set this up, or you can enter in the same command as you would in a terminal, etc. username@cheyenne.ucar.edu and then hit enter
5. You will be prompted to enter your password (then go to Duo for the corresponding verification)
6. I think you may get asked if you want to configure this host, so click yes. cheyenne.ucar.edu will then pop up as a configured host you can just click on
7. Now you should be on Cheyenne! You can open folders on the left like you would on your personal computer - though you may ?) need to re-enter your pw which is a bit annoying.
8. You'll notice that you've lost syntax highlighting. This is because you need to install the extensions on your remote host as well, so probably again Modern Fortran and C/C++, and anything else you'd like.
9. Again, you'll probably need to install fortran-language server. On Cheyenne, I did module load python and then pip install fortran-language-server Then you will need to update the remote settings for this Extension to tell Modern Fortran where your fortls is. Go back to the extension page, click the gear icon to go to settings, and then you should see a tab for "User" and then some kind of "ssh" tab. Click on the "ssh" tab to make sure you only update that version of the setting.

Tasks and Debugging

VS Code lets you create tasks that you can have it kick off. For my purposes I created a folder (.vscode inside my CTSM repo. My CTSM repo is the top level of my VS Code workspace. I don't think this will work otherwise? Tasks can then be executed by Cmd + Shift + P and then typing Tasks. Once you have set up tasks, they should populate here.

Inside this folder I created a file tasks.json:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "build",
      "type": "shell",
      "command": "./case.build",
      "options": {
        "cwd": "/glade/work/afoster/test_cases/cases/BONA_test_run"
      },
      "group": {
        "kind": "build",
        "isDefault": true
      }
    },
    {
      "label": "create",
      "type": "shell",
      "command": "./create_test_case",
      "options": {
        "cwd": "/glade/work/afoster/test_cases"
      },
      "args": [
              "BONA"
      ],

    },
  ]
}

The "create" task submits a script I wrote create_test_case, you can see this on my cheyenne work directory in /glade/work/afoster/test_cases.

The "build" task builds this specific case I made. By putting it in the "build" group I can actually do Cmd + Shift + B to build this case

After building we can actually try debugging (with gdb)! I created another file inside the .vscode dir called launch.json:

{
  "version": "0.2.0",
  "configurations": [
      {
          "name": "Run GDB",
          "type": "cppdbg",
          "request": "launch",
          "program": "/glade/work/afoster/test_cases/output/BONA_test_run/bld/cesm.exe",
          "args": [],
          "stopAtEntry": false,
          "cwd": "/glade/work/afoster/test_cases/output/BONA_test_run/run",
          "externalConsole": false,
          "MIMode": "gdb",
      }
  ]
}

To use either of these files you'll need to update some of the file paths, etc.

So first open a file in the CTSM repo (say clm_initaliazeMod.F90 and click to the left on the line numbers somewhere - lets say line 246) to create a breakpoint. You should see a little red circle pop up.

Click on the little debug icon on the left (triangle with a bug). Then you should see "Run GDB" (or whatever you named it in launch.json). Click the green triangle.

After a bit (model is running...), if this is all working, you should see the Debug Console populate, and then on the file you placed a breakpoint you should see a green/yellow line across where the breakpoint is. Woohoo! We've reached a breakpoint.

To the left you should see some variables you can investigate, and then up top there should be some arrows you can use to "step over" - step forward one task, "step into" - actually go into a method you are on, "step out of" - step out of a method, and even "stop" the run... You'll notice that VS Code will actually bring up new files as you are moving around in the code.

Okay...this was a lot...

Please let me know if this is useful to you, and if you encounter any problems. I am a bit concerned about the Remote SSH because they just did an update to VS Code and I think it might have caused an issue. But I am still able to connect after some finagling - let me know if you run into an issue with this step.

[adrifoster]

@samsrabin I'd love to see what your process/extensions are!

[billsacks]

Cool, thanks so much for putting this together @adrifoster - this is really useful to have this documentation of how to set up the remote ssh, build & debugging for CTSM in VSCode!!

[samsrabin]

Thanks so much for this writeup, @adrifoster! So far I've only experimented with the Remote SSH feature. Some notes on my experience with that:

• I did have to be logged on to the GlobalProtect VPN, at least from my house. I think; it didn't connect to Cheyenne at first without it but that might have just been a fluke.
• I initially wasn't able to search across files I don't have open. That was resolved when I installed the "FORTRAN IntelliSense" extension in addition to Modern Fortran.
• It looks like I had installed fortls on Cheyenne back when I first started here, so I had a binary at ~/bin/fortls I could use. I don't remember how I did it there. On Izumi, I had to do pip-3 install --user fortls; then the binary was at ~/.local/bin/fortls. However, pointing Modern Fortran at that binary gave an error, and when I tried restarting VSCode it failed to connect to Izumi at all, just timing out. Will let you know if I make progress.

[ekluzek]

I added fortran-language-server to my ctsm_pylib conda env. An advantage is that I didn't have to mess with the path. It didn't change the base ctsm_pylib env much. But, possibly I should do a different environment for developing with VS Code? But, we could also add it to our ctsm_pylib environment, but I'm not sure...

[adrifoster]

Thanks @ekluzek this is a great idea. I guess I am worried about how it will work in VS Code. Will we have to activate it for VS Code to have the path work?

[samsrabin]

I think that we could set VSCode's Python interpreter to use whichever conda environment we have it installed in, then not provide a custom path to the binary.

[ekluzek]

@samsrabin I also can't seem to do the remote ssh to cheyenne in VS code, unless I'm using the NCAR VPN. I also have a personal Window's laptop that I use for work that hasn't been able to connect, and I'm thinking it's the same reason since I don't have VPN setup for it. So I'll look into getting the VPN setup for it.

For general use of SSH to cheyenne you don't have to have VPN on, but there must be something specific about the connection for VS Code that doesn't allow it, unless VPN is on.

[ekluzek]

I did figure out how to use the ctsm_pylib environment in VS Code for my python code. You use "Command Palette" and then type in "Python: Select interpreter", and it will list your python environments as well as specific versions of python. So you select ctsm_pylib and then it remembers it. I'm not sure if it remembers it for each instance you have of VS Code on each desktop, but it seems to remember it after setting it.

As a result of that the linting works correctly, and its editor suggestions are correct for that environment. I think for the terminal you have to enter it explicitly.

[ekluzek]

I think a useful thing we should consider for the future is to add the .vscode directory and a few tasks for it that we would all find useful. We probably need more time to figure out how useful that would be. But, that would add the directory for everyone, and might be a good way for individuals to get started in adding their own tasks for their use. It demonstrates how to do it.

Actually, this sort of thing could be useful to have available for everyone's use. So for example, possibly VIM and EMACS things could be shared in a similar space for developers that use those different editors...

[ekluzek]

Here's a quick video tutorial I found that is the official VS Code channel. So there likely are others that are useful there. I'll post if I find others that look useful.

https://www.youtube.com/watch?v=B-s71n0dHUk

It's nice because it's short, but it also goes over the major functionality and shows usage. So it somewhat overlaps with what @adrifoster shows above, but also has different things as well.

[wkchuang]

I am setting up VSCode with Remote SSH and coming across issues maintaining the session when my laptop goes to sleep. I found microsoft/vscode-jupyter#1378 but it currently does not have a good solution. Have you created workarounds that retains the terminals/windows you have open during a session?

[samsrabin]

Unfortunately no, I just reauthenticate.

[ekluzek]

Same here. I do set my laptop up to NOT go to sleep when it's plugged in. This helps keep all of my remote connections intact which is helpful all around.

[jedwards4b]

You might try adjusting ServerAliveInterval in your .ssh/config file, I have:
ServerAliveInterval 300

[wkchuang]

Thanks Jim, I adjusted that setting when it took a long time to connect to derecho and let me log in, in the few days after the latest derecho update. vscode would time out and close the connection, so this setting kept it alive.

Regarding my original question, retaining open windows is no longer an issue by using workspaces, but workspaces do not retain terminals.

[jedwards4b]

I left my VS code session active overnight and my inbox is full of messages:

Violation of usage policy

A violation of the usage policy by jedwards (James Edwards,UCAR/CSEG,303-497-1842) on derecho6 was automatically detected starting at 06:12 on 03/07.
Process 	Average core usage (%) 	Average memory usage (GB)
other processes** (1) 	0.84 	0.00
node (6) 	0.17 	0.59
fortls (5) 	0.00 	5.64

[samsrabin]

Hmm. What even is the violation here? I know @adrifoster got alerted about her memory usage when she opened her entire home directory as a workspace, but this looks like it's just fortls taking < 6 GB. Is the threshold for memory use on login nodes really that low?

[jedwards4b]

Good question - I'm going to query user services.

[adrifoster]

I think the memory limit is that low:

@jedwards4b what was your base workspace in VS Code?

[jedwards4b]

Yes the limit is 5GB - I spoke with user services about this and they recommended minimizing the number of files or directories open in the vs code file explorer.

[jedwards4b]

I put in a request to the github NCAR organization a couple of days ago for approval to use git-copilot. I haven't heard anything - what experience have others had with this? Do you know who to contact?

[wkchuang]

Login node limit is ~~4 GB~~ 5 GB (See #2139 (reply in thread)), and I have heard that linters unfortunately can eat up a lot of memory. I haven't been able to get fortls working on my system despite a lot of troubleshooting

…

On Thu, Mar 7, 2024, 10:58 Jim Edwards ***@***.***> wrote: Good question - I'm going to query user services. — Reply to this email directly, view it on GitHub <#2139 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK2GOYZG6XHIG3NSCMKVCKLYXCFBRAVCNFSM6AAAAAA4PPRBWGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DOMBZGQ3DC> . You are receiving this because you commented.Message ID: ***@***.***>

[billsacks]

The new (or at least new by default?) "sticky scroll" feature (where the function header is kept in the top line(s) of your window) is neat, but I just stumbled upon something that can arguably make it more useful (if you have enough screen real estate, at least): If you change "Editor: Sticky Scroll: Default Model" from outlineModel to foldingProviderModel, you see all of the levels of nesting above the current point (loops, conditionals, etc.). The video in microsoft/vscode#159198 illustrates this. You can also click on any level to jump to the top of that level of nesting. I'd recommend then also increasing "Editor: Sticky Scroll: Max Line Count".

I have tried this in Python and Fortran files. I haven't used it enough to know for sure if I like it, but I see potential.

[wkchuang]

I agree, it's a great feature and I didn't notice it until now. Thanks for bringing it up and for pointing to the Max Line Count!

[bitterbark]

Would this be a good place to post the links to Adrianna's and Sam's (and others'?) recent talks about VS Code? Was there info in there regarding linking somehow with JupyterHub?

[samsrabin]

Good idea!

Recordings from the CESM Software Engineering Working Group meeting (March 2024):

• Timestamp for Adrianna's talk: "VS Code and You: Why You Should Make Your Computer Work for You (and How!): https://youtu.be/8CYoJHoN2Gc?feature=shared&t=6824
• Timestamp for my talk (demo of various features): https://www.youtube.com/watch?v=8CYoJHoN2Gc&t=7995s
• Timestamp for Supreeth's talk: "Accelerate productivity with Al: Github CoPilot": https://youtu.be/8CYoJHoN2Gc?feature=shared&t=9369

There's not really a way we know of to link to JupyterHub per se. However, you can totally write and work with Jupyter notebooks within VS Code, as described here. If you want to run those notebooks on Casper or Derecho as you would in JupyterHub, you can use Remote SSH as Adrianna described. However, note that by default this will put you on a login node, not a compute node! That's fine for small jobs, but anything that requires much CPU or memory might get shut down. (It is possible to SSH directly to compute nodes, but I bet the cluster admins don't like that very much because it seems to bypass the queueing system.)

[adrifoster]

Actually I think it is fine to connect to a compute node - you just need to request one first. You can check out this blog post for more about VS Code and Jupyter notebooks - https://nhug.readthedocs.io/en/latest/blog/jupyter-for-vscode/

I believe CISL is trying to figure out a nice way of connecting to the compute nodes via VS Code...

[bitterbark]

thank you!

[samsrabin]

Some tips from @negin513 on managing memory use on remote systems, if you're getting nastygrams about your login taking up too many resources:

These vscode settings significantly improved the memory usage for me:

"files.watcherExclude": {
        "**/.git/objects/**": true,
        "**/.git/subtree-cache/**": true,
        "**/node_modules/**": true,
        "**/dist/**": true,
        "**/conda-envs/**": true
        "**/env/**": true,
},
"files.exclude": {
        "**/.git/objects/**": true,
        "**/node_modules/**": true,
},
"search.exclude": {
        "**/node_modules/**": true,
        "**/dist/**": true,
        "**/tmp/**": true,
        "**/.git/objects/**": true,
        "**/.git/subtree-cache/**": true,
        "**/.DS_Store": true,
        "**/.vscode": true,
        "**/__pycache__": true,
        "**/.pytest_cache": true,
},

I also disabled search.followSymlinks to my settings file which was recommended in several github discussions and it helped:

"search.followSymlinks": false