[ANN] VS Code extension 1.0.10 released

[pfitzseb]

Hey everyone,

we’ve released v1.0.10 of the VSCode extension for Julia! There are a bunch of fixes, improvements and new features – most notably the fact that you can now interrupt your code – (also see our changelog for what’s been happening in older releases):

[1.0.10] - 2020-11-13

Added

• Support for Julia 1.5.3 and 1.5.4 default installation paths (#1755, #1759).
• New up-to-date changelog (#1750).

Changed

• Inline evaluation now adds the evaluated code to the REPL history if the julia.codeInREPL options is set (#1754).
• The extension now watches the global Manifest as well as Manifests in the workspace for changes and prompts the LS to re-index accordingly (#1756).

Fixed

• Push internal Julia modules to the front of LOAD_PATH to prevent loading code from the workspace instead (#1747).
• Fixed a typo in the tableviewer code (#1749).
• Evaluation now uses unbuffered channels for communication, which might fix a rare off-by-one-result bug (#1762).

[1.0.9] - 2020-11-04

Added

• The workspace now shows errors encountered while rendering the tree view. Furthermore, it now only special cases Array and Dict instead of their Abstract... supertypes (#1709).
• Inline evaluation and the REPL can now be interrupted with the Julia: Interrupt Execution comamnd (or its default keyboard binding ctrl+c) (#1690).
• ProgressLogging.jl’s progress bars are now displayed in the editor (1579).
• The language server process is now started with the JULIA_LANGUAGESERVER environment variable set to 1 (#1707).
• Added commands to re-start the LS or re-index the symbol cache (#1721).
• @edit now works properly on code-server instances (#1737).
• Added commands to cd to the current directory, Pkg.activate the current directory, or Pkg.activate the current files nearest project. These commands are also available in the file explorer (#1743).

Changed

• Updated some JS dependencies.
• The plot pane is now opened in a new column by default, but also remembers it’s last position (#1554).
• The julia.NumThreads setting is now machine-overrideable (#1714).
• Updated the Julia grammar definition (#1720), which fixed various bugs.
• julia.usePlotPane can now be changed without requiring the Julia process to be restarted. Additionally, the related display machinery is now much more robust (#1729).
• The “play” button in the editor toolbar now runs the file in the integrated REPL process (#1728).
• All inline results are now removed when the REPL process exits (#1738).

Fixed

• Stracktraces are now rendered properly (i.e. with linebreaks) once again (#1692).
• The module indicator is now correctly initialized (instead of Main) (#1516).

---

VSCode should update the extension automatically, so there’s nothing you need to do. Please report bugs and feature requests on GitHub and consider opting into crash reporting – it can really help a lot with finding and fixing issues in the extension.

If you’re used to Juno’s keybindings, consider using this file to replicate them in VSCode.

Thanks,
David, Sebastian, Shuhei, and Zac

[oxinabox]

Can you explain what version number convention this is using?
It’s clearly not SemVer since those are great features not bug fixes.

[pfitzseb]

Right now it’s the tried and true “let’s increment something that isn’t the first number and call it a day” convention
1.0.9 probably should’ve been 1.1.0, but oh well.

[ChrisRackauckas]

Are the ProgressLogging.jl things the same as the standard Juno log information? So packages setup with the right loglevel and all of that should be compatible?

[pfitzseb]

The answer is “well, kinda”. We’re picking up log messages with the progress keyword, but only if ProgressLogging is loaded. So

for i in 1:10
    @logmsg 0 "blah" progress=i/10
    sleep(1)
end

will work fine, but only if preceded by a using ProgressLogging somewhere.

I realize this is somewhat inconvenient, but turned out to be the solution with the least amount of code duplication (see here for the reasons).

[Zhong_Pan]

Thanks a lot for the newer version! I like the interrupt feature (Ctrl-C) very much.

Just a couple questions:
(1) After upgrading to 1.0.10, on Windows PyPlot does not work anymore - no plot window can be shown (I have “Use Plot Pane” unchecked properly). I have opened an issue here: https://github.com/julia-vscode/julia-vscode/issues/1782

(2) Maybe this is more for the debugger team, but julia-vscode is where users have the experience, so maybe I’ll ask here: any progress on making the visual debugger a smoother experience? That is, one can put a break point anywhere in the code (maybe layers down), and the debugger can execute at Compile Mode speed, but still not miss the breakpoint (like in the standard, non Compile Mode).

(3) Any plan to make Intellisense and Go to definition work for modules that are loaded by “using XYZ” from a LOAD_PATH location?
Or, how about the approach to “includet XYZ.jl” first then “using .XYZ”? Last time I tried this the intellisense worked partially, not reliable when there are multiple layers of modules with cross-referencing.

Thanks again for the fabulous extension!

[affans]

This is great. I still use very basic features of vscode/julia but maybe it worth it to see how inline code, plot viewer, and logging works.

[tim.holy]

@Zhong_Pan

That is, one can put a break point anywhere in the code (maybe layers down), and the debugger can execute at Compile Mode speed, but still not misse the breakpoint (like in the standard, non Compile Mode).

Sadly, we’re nowhere close to having that capability. See Gallium for the initial attempt and some discussion on A Julia Interpreter and Debugger | Hacker News. We’ll get there eventually I’m sure, but it will take a major investment of resources. Definitely not something to expect in a patch-level release .

[Zhong_Pan]

@tim.holy

Sadly, we’re nowhere close to having that capability. See Gallium for the initial attempt and some discussion on https://news.ycombinator.com/item?id=19455688 . We’ll get there eventually I’m sure, but it will take a major investment of resources. Definitely not something to expect in a patch-level release .

Thanks for the reply! Yes I understand it’s a tall order and easier said than done.

Maybe an intelligent mix of Compile Mode and Interpreted Mode could serve the purpose? That is, automatically run Compile Mode to begin with, automatically break and step into function calls that will finally lead to the break point, and automatically switch to Interpreted Mode before the break point? Basically a pre-processing step to add a bunch of break points and mode switching automatically…

BTW I’d assume the debugging experience being the same using the Julia linked with OpenBLAS (default), or the Julia linked with MKL (by adding MKL and building it). Is this assumption correct?

Thank you again for the great JuliaInterpreter package, among other things.