View ROOT Files directly in VS Code!

[autoblog]

As a heavy user of ROOT, many of the results of my data analysis are saved in ROOT Files and, honestly, I always found it a bit annoying to glance over them. The good news are that that isn’t the case any longer! Let me present ROOT File Viewer, an extension for Visual Studio Code that makes use of the wonderful JavaScript ROOT to display ROOT Files directly within VS Code, with just a click!

---

This is a companion discussion topic for the original entry at https://root.cern/blog/vscode-extension-announcement/

[eguiraud]

Many thanks to Alberto for his amazing work on a ROOT file viewer for VS Code I know a few ROOT developers that are already using it Read all about it here or in the original post on our website.

[Wile_E_Coyote]

For me, there are two problems with the new toy.

1. When VS Code works in one of the “SSH TARGETS” in the “Remote Explorer”, it doesn’t seem to be able to browse remote ROOT files at all (well, at least I wasn’t able to get it working).

2. It is only well suited for simple / flat ntuples which use ordinary C++ data types. It does not really understand C++ classes, including ROOT’s own classes, so it “flattens” all available data. Assume that you have a “TTree” which keeps some “objects”. Take a simple “TVector3” and all three coordinates are mixed together (and there is no way to draw, e.g., the “X()” or the “Mag()”).

Well, ROOT provides a standalone tool (needs the python feature): rootbrowse
Without python, you can simply execute (e.g., create a shell alias): root -e "TBrowser b"
Of course, you do need a working ROOT binary distribution for them … but if you work on ROOT related source code, you anyhow must have it on your “target machine”.
These standard ROOT executables do understand all standard ROOT classes, and if your ROOT files use some nonstandard ones, you can simply load the corresponding shared libraries to be able to inspect them.

[bellenot]

You need to install ROOT to use rootbrowse, while you don’t need ROOT to use the VS Code plugin…

[Axel]

Yeah this is more: say I’m coding my analysis, need to enter that branch name, what was that again? And here, thanks to this plugin, it’s all part of the IDE: I can browse ROOT files, trees, see histograms, and adjust the code appropriately. That’s the beauty!

[enpg_qz]

Excellent job, thanks!

[xtovo]

Nice!
I’m trying to build it from github sources
… but node_modules dir is missing
Is it OK? (I’m newbie with VScode extensions)

[AlbertoPdRF]

Hey!

First of all, thanks everyone for the kind words! The support that the extension has received so far has been awesome

@xtovo: how are you trying to build it? After clonning the repository, running yarn && yarn run compile from the base folder should do it. Feel free to reach out to me if you have problems or something is not clear enough!

[xtovo]

Thanks. It’s OK.
I found “vscode:prepublish”: “yarn run compile” in package.json

I’m newbie with VScode extensions and on the learning curve.

• where dependency on the node_modules located?
  … oops. I found it’s in package.json
  “dependencies”: {
  “jsroot”: “^6.0.1”
  }
  Does it mean node_modules (jsroot) should be registered in globally-installed JavaScript tools?
  Does it mean that “yarn cache-folder” contains all globally-installed JavaScript tools?
  It could be huge! in the future
  If it’s so, useful to set “yarn cache-folder” on non-system disk,
  like this yarn config set cache-folder d:\yarn
• can you add “build from scratch” instructions?

[AlbertoPdRF]

I just added the basic instructions to build and run the extension locally to the README, please check it out at GitHub - AlbertoPdRF/root-file-viewer: View ROOT files directly in VS Code!

The node_modules folder contains all the dependencies of a given project – there’s no need for these dependencies to get installed globally. Of course, this means that you can have several installations of the same library on your system, but this way it’s ensured that you always have the correct version of each one installed for each project. As you point out, these folders can grow huge, so a good practice (IMHO) is to delete them when you are not working on a project anymore, as installing all the dependencies again is quite straight forward if you need to

[xtovo]

Thanks.
Is it possible to extend this extension to run ROOT macro from inside VS code?
See the following scenario:

• edit hsimple.C macro
• press F5 to run macro or “Run->Start Debugging”
  which invoke root.exe -l -q hsimple.C
• after macro execution a new tab is created with hsimple.root content

ROOT allows to set breakpoints inside a macro and step-by-step execution,
so it would be good to add key bindings:

• F9 - toggle breakpoint
• F10 - step execution

I also want to have possibility compile, compile&execute macro.

[AlbertoPdRF]

Hey @xtovo!

Please note that you can already run a ROOT macro from inside VS Code, with breakpoints and everything. For that, you need to install the ms-vscode.cpptools extension, and tell it where to find ROOT headers through the settings.json file placed on the .vscode folder:

{
  "C_Cpp.default.includePath": [
    "${default}",
    "/path/to/root/install/dir/include"
  ],
}

On that same folder, you also need to place the proper launch.json configuration file. For instance:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "(gdb) Launch",
      "type": "cppdbg",
      "request": "launch",
      "program": "/path/to/root/install/dir/bin/root.exe",
      "args": [
        "-l",
        "-q",
        "MyMacro.C+g"
      ],
      "stopAtEntry": false,
      "cwd": "${workspaceFolder}",
      "environment": [],
      "externalConsole": false,
      "MIMode": "gdb",
      "setupCommands": [
        {
          "description": "Enable pretty-printing for gdb",
          "text": "-enable-pretty-printing",
          "ignoreFailures": true
        }
      ]
    }
  ]
}

I hope that helps!

[xtovo]

Thanks.
he-he, I’m outdated.
I’m struggling with your receipt.
Probably It’d be good to mate these beasts to have a single extension
with one click installation.

[AlbertoPdRF]

No worries @xtovo!

I’ve set up an example repo to show you how it works. I’ve gone with a slightly different approach than what I depicted on my last reply, but hopefully it’s clear enough!

[eguiraud]

Wow that could easily be another blog post xD

[AlbertoPdRF]

Hahaha, I can come up with something if you guys want!

[eguiraud]

That would be great! Certainly useful for a lot of users to know this is possible.

[Wile_E_Coyote]

You currently need to hardcode your local ROOT installation ("/home/apdrf/programs/root-6.22/install") in two “project / workspace”-specific files: “.vscode/root-on-vscode.code-workspace” and “.vscode/launch.json”

It seems to me that the “project / workspace”-specific VS Code setup files should be ROOT version agnostic (e.g., one often needs to verify that a macro works with different ROOT versions on different operating systems, compilers, …).

They could simply call the “root-config” to grab the currently preferred ROOT version (and its “--cc”, “--cxx”, “--cflags”, “--libs”, …).

Well, the user would first need to call “thisroot.sh” before running VS Code. This would require exiting VS Code and relaunching it when the user wants to try another ROOT version, of course.

It seems to me that a good idea would be to design something like the standard “CMake Tools -> CMake: Scan for Kits”, which keeps all available compilers in the “${HOME}/.local/share/CMakeTools/cmake-tools-kits.json” file.
One could create a similar “${HOME}/.local/share/ROOTTools/ROOT-tools-kits.json” file, which would internally keep the pointers to all available “thisroot.sh” scripts, which could then be used to set all ROOT related variables (and maybe then it would be possible to switch between ROOT versions from inside of a running VS Code instance on the fly).
Acually, one may need to source several scripts in order to setup some ROOT version (e.g., something like: “source /my/compilers/setup.sh; source /my/ROOT/bin/thisroot.sh”).
Of course, if the user did not explicitly choose the ROOT version from inside of VS Code, then an “[Unspecified]” ROOT kit would be used (i.e., expect that the user provides a “root-config” in the “${PATH}” before running VS Code).
Note that these would be “user”-specific settings (kept in a file specific to a machine), not “project / workspace”-specific ones (so, moving “projects / workspaces” between machines or different users would not require any modifications in them).

[AlbertoPdRF]

That’s right @Wile_E_Coyote – I was thinking that if someone needs something more elaborated, maybe it’s just better to integrate ROOT within a custom CMake project? The example repository I created was to just show how to quickly get a ROOT Macro running within VS Code, and for that I think that hard-coding the path to your ROOT installation shouldn’t be a big deal. This approach also let’s you easily test different ROOT versions by just modifying said path.