[ANN] VS Code extension 1.2 released

Definitely not, In Juno I just go to the relevant line and press ESC. This does not work here.

Ah. I always forget about the defaults in the VSCode extension. Give

a go :slight_smile:

Yep. VSCode doesn’t really allow for anything but markdown though.

No, Juno is using indentation. VSCode parses your code and should always pick the biggest non-module code-unit. Please open issues if not, preferably with your code and the exact cursor position.

1 Like

ok, thanks for clarifying… weird. I’ll produce small examples if I can and come back on github.

P.S: I should have found that “clear inline results…” commands myself, sorry about that…

1 Like

Related to or similar this issue?
https://github.com/julia-vscode/julia-vscode/issues/2078

1 Like

I develop inside of a devcontainer on a remote server. As of the upgrade to 1.2, error links in stack traces in the REPL stopped opening in the code viewer when I use alt-click.

I assume this is related to the Julia:Editor setting that (I believe) is new. I see the default is code/code-insiders, but what was it effectively on version 1.1?

JULIA_EDITOR is getting set to "/vscode/vscode-server/bin/x64/054a9295330880ed74ceaedda236253b4f39a335/node" for me on 1.2.1:

julia> ENV["JULIA_EDITOR"]
"\"/vscode/vscode-server/bin/x64/054a9295330880ed74ceaedda236253b4f39a335/node\""

The double quotes are suspicious.

Edit:
Turns out that some links do work.

Example:

julia> query(DataConfig(), PgSQLcon())
ERROR: MethodError: no method matching append!(::Nothing, ::Vector{Outcome})
Closest candidates are:
  append!(::DataStructures.MutableLinkedList, ::Any...) at /root/.julia/packages/DataStructures/ixwFs/src/mutable_list.jl:160
  append!(::SentinelArrays.ChainedVector{T, AT}, ::AT) where {T, AT<:AbstractVector{T}} at /root/.julia/packages/SentinelArrays/hLZPV/src/chainedvector.jl:570
  append!(::SentinelArrays.ChainedVector{T, A} where A<:AbstractVector{T}, ::Any) where T at /root/.julia/packages/SentinelArrays/hLZPV/src/chainedvector.jl:588
  ...
Stacktrace:
 [1] query(config::DataConfig, connObj::PgSQLcon; verbose::Bool, days_per_pull::Int64, parallel::Bool, unique_keys::Vector{String})
   @ Data ~/myproject.jl/Data.jl/src/Data.jl:368
...

The top 3 links do work and open files successfully. The bottom link, to the source of a dev’d package, is greyed out and fails.

That’s a known issue and will be fixed in the next release.

1 Like

WIth the connect to external REPL mode, is there a way to open files in vscode that appear in stack traces? That’s the only thing I’m missing. I tried the number plus ctrl+q thing, but nothing happens. Or do I need to set an editor specifically?

I had the same cumbersome debugging experience and was waiting for this new feature. Very exciting to have it now!

However, with Julia 1.6.1 and VSCode Julia Insider 1.2.2, after setting EVERY module except my own code to “compiled (all)”, the debugging is still very slow - I waited for minutes and the breakpoint set inside my “main” function (i.e. not even in a nested function) is still not hit, while my laptop had been working really hard judging from the fan noise.

The “Compiled mode (experimental)” option is now gone, so I cannot compare to that experimental mode anymore, but that mode used to be quite fast, just I need to manually set a series of breakpoints to “guide” the debugger into the nested function for which I’d like to debug.

Is there tutorial/instruction on how to properly use the new COMPILED CODE feature? Thanks!

(new information) When I tried breaking at “main()” and stepping into the function then keep stepping over, I noticed that most of the very long delay is caused by statements that use XLSX.readtable() to read an Excel sheet (not just the first such statement is slow, but every such statement is slow), although I already set XLSX as “compiled (all)”. I then tried reverting to VSCode Julia 1.1.40 and stepping into main() while “Compiled Mode (experimental)” is enabled, and XLSX.readtable() was pretty fast to step over.

I am beyond excited about that and the other new features.

Thank you so much for all your work on the extension!

Can you try to give a reproducable example of that? And is XLSX set to compiled in your case?

Also, the “Compiled code” toggle isn’t gone, it’s just been moved to the Julia: Compiled Code pane and functionally the same:
grafik

I wanted to test it with a simple example but I keep getting stack overflows

I tested it in a couple of different macos machines, in one of them with a fresh installation of julia 1.6.1, vscode and the julia extention. It stops at the breakpoint the first time, if I try to continue nothing is printed, the breakpoint is not reached again in the second iteration of the for loop and most of the time it dies with a stack overflow.

Here the same issue also with the compile mode disabled just in case

That bug should be fixed on master/insiders.

Thanks for your response. Yes XLSX was set to “compiled (all)” as well.

Here’s a simple example. The input data files are just 10 columns * 2,000 rows of random floating numbers between 0 and 1, with column headers being “Col1”, “Col2”, …, “Col10”. One copy is saved as randomdata_large.xlsx, another copy is saved as randomdata_large.csv. I also created smaller data files with only 20 rows instead.

Unfortunately, uploading non-image files is not permitted, so I zipped up the data files and shared it here: https://u.pcloud.link/publink/show?code=kZkySMXZoA5JO6MiieY13kealFwXsSGY0jck The sharing expires in 3 months.

The code is below:

using DataFrames
using XLSX
using CSV

function main()
    println("Script started.")

    isXLSX = true
    isLarge = true

    fn = "randomdata_" * (isLarge ? "large" : "small")

    if isXLSX
        fullfn = joinpath(@__DIR__, fn * ".xlsx")
        tmp = XLSX.readtable(fullfn, "Sheet1", stop_in_empty_row=false)
        df1 = DataFrame(tmp...)
    else
        fullfn = joinpath(@__DIR__, fn * ".csv")
        df1 = CSV.read(fullfn, DataFrame)
    end

    df2 = filter(x->x.Col1 < 0.5 && x.Col2 < 0.5, df1)
    CSV.write(fn * "_result.csv", df2)

    println("Script finished.")
end

main()

Here’s the execution time:

  • Simply running the script with large input data files, either Excel or CSV: 0.1 to 0.2 sec.
  • With large input data files, stepping over most statements takes less than a couple seconds (including the calls to DataFrame() and filter()), but the following is different:
    • XLSX.readtable(): 2 min 20 sec
    • CSV.read(): 9 sec
    • CSV.write(): 11 sec
  • With small input files, the stepping over time is much shorter. So the majority of this processing time scales with data file size.
  • It seems large file operation is dominant here.

During the debugging, “Julia: Enable Compiled Mode for the debugger” is on (the dot is red), and all modules including the main function are set to “compiled (all)”. Please see screen shots below.

Versions these data/screenshots were taken: Windows 10 Enterprise 64-bit, Julia 1.6.1, VSCode Julia 1.2.1 (tried Insider 1.2.2 earlier as well similar behavior).

@pfitzseb , where you referring to my example or one from a different user? I can still reproduce the stack overflow with the 1.2.2 extension.

Excuse me the silly question but… when the button is red, the hint says “Enable Compiled Mode for the debugger”. Does this mean that it is already enabled, or that you must click on it to enable it?

1 Like

Are there any plans for better support of the Literate.jl workflow? it would be cool to have:

  • support markdown highlighting in the comment blocks
  • run Literate.jl build for active file as a task with automatic opening of the md file / preview
  • maybe use first comment row in the file to define the parameters of Literate execution (like, execute=true, or the output directory and format)

Other than that, already now the workflow is OK, just not that nicely polished as were jl weave files in Atom in the old days…

Thank you very much for giving your time to others by polishing and fixing the VScode Julia experience.

3 Likes

The plot navigator keeps opening up when I make a new plot, is that intended ? it’s quite annoying.

1 Like

Yes, but 1.2.2 makes that behaviour optional.

2 Likes