Julia-vscode: Feature Request: Support re-execution of code at arbitrary module level (like in Juno)

[schlichtanders]

Dear julia-vscode team,

currently I still work in Atom Juno, which is mainly because of one power feature: Re-executing arbitrary code chunks which then get executed in the right module namespace.

For instance, if I have a module MyModule which includes a file like

include("./MySubModule.jl")
using .MySubModule

in Juno, I can actually just go to the file MySubModule.jl, change a function definition and re-execute it pressing CTRL+ENTER, and it will be loaded correctly into MyModule.MySubModule.

This makes for super fast super intuitive package development and I was wondering whether this already exists in julia-vscode or whether it is planned.

[ZacLN]

We did have this feature in the past but removed it in favour of supporting a Revise based workflow. Revise seems ideal for your use case here, have you tried it?

[schlichtanders]

Revise.jl was buggy and took long, hence I was positively surprised finding the selective re-execution feature in Juno

maybe it is better today, but still Revise.jl has to be slower because it does not know which specific part to re-execute, but always have to check whole files for change.

EDIT: For instance I had especial problems with Revise.jl and macros, which work seamlessly with Juno-like re-execution.

[schlichtanders]

I think Juno-like re-execution is definitely a power feature good to have in a Julia-like IDE.

There is nothing like that in R or Python, I already advertised this feature to newcomers, because it is intuitive, very stable and super powerful (Revise.jl is only powerful it seems to me, neither intuitive in the sense of being transparent nor very stable in the sense of working for all kinds of situations where you would expect it to work).

[vchuravy]

I personally always found that particular Juno feature to be rather confusing and to work against my mental model of how code-loading and execution in Julia woks. Revise on the other hand takes that mental burden on it (and yes sometimes it can't do it).

As an example I don't expect it to work on macros, but neither does the Juno feature -- I have to mentally keep track of the fact that I changed a macro and re-evaluate transitively all invocations of the macro. At that point I rather just restart my session...

[schlichtanders]

yes that very well describes the process how you would update a macro. It is completely fine for me because:

• it works (compared to Revise.jl which just fails. EDIT: apparently it seems to work good now)
• it is very intuitive how it works, i.e. that you have to re-execute your respective macro call if you want changes in the macro to take effect
• I usually work on a specific part of a project where I know which functions I need to change/inspect more. So for small changes it is really important for a fast workflow that I can re-execute selectively instead of always having to reload the whole session.

In case you need to execute a couple of more functions at a time, remember that you can just re-execute the whole module for instance and it just works like you would expect it to work

[KristofferC]

Revise works pretty well with macros and other code that defines functions now.

[schlichtanders]

another downside of revise.jl:

• it triggers everytime you change something, and execute something in the code. Even you may not be ready right now but only want to test something related but not requiring a reload. Revise always introduces a time-lag on the REPL for me which was in the range of being annoying so that I turned it off even before I got to know the alternative workflow in Juno.

EDIT: another one just encountered:

• in Juno selective re-execution workflow you directly get an error message at the correct place when you re-execute and something was wrong in there like forgetting a parentheses.

[davidanthoff]

I think there is some stuff that we need to do to make the revise story smoother, and maybe we should just ship it out-of-the-box...

[schlichtanders]

In Juno you have both of course
if you want, you can activate Revise.jl there too

It is not that I want to speak against Revise.jl, many apparently make good use of it. I just wanted to point out that the selective re-execution feature of Juno is very useful in its own right and it would be great if julia-VSCode could support it too.

[jebej]

I would also like the eval-in-module feature. It's not really confusing, Juno always shows the module the code will be evaluated in at the bottom.

[oschulz]

Personally, I really like Revise, and would prefer it over a manual re-execution solution.

[davidanthoff]

@ZacLN I think the only thing we need from LS for this is a custom request Type where we send a URI and Position, and LS returns the module name for that position, right?

The way I would implement the rest now is that we request the module whenever the cursor moves, then have status bar item that shows the current module (based on the return value from the LS) and then use that module name for the execution.

Maybe bonus we could switch between an auto mode, where the status bar detects the active module of the current cursor location, and a manual mode where one just picks a certain module from a list.

The request to the LS would happen very often in this design (every time the cursor moves), so it would need to be fast :) @ZacLN, do you think that might be an issue?

[pfitzseb]

That's exactly how we're doing it in Juno, and speed hasn't been an issue at all so far.

[oschulz]

It will still be possible to use Revise instead, though, right?

[ZacLN]

https://github.com/julia-vscode/LanguageServer.jl/pull/697. Speed isn't an issue.

It will still be possible to use Revise instead, though, right?

Yes

[davidanthoff]

Great! I’ll do the stuff on the client side.

[schlichtanders]

@pfitzseb can you explain why this issue was closed?

[pfitzseb]

Because the feature is implemented in the latest version of the extension.

[schlichtanders]

awesome! thanks a lot!

[oschulz]

Now that @pfitzseb is joining forces with @davidanthoff here, I have a feeling that things will move even faster than before (which was already fast). :-)

Thanks so much, you two, for all your work on the tools we use so much!

[davidanthoff]

And @aviatesk!!

[oschulz]

Oh, yes!