I use Revise, but I frequently change struct definitions, which requires to exit Julia and start another REPL, wait for my package to compile. You know the drill; there must be a better way! How do you handle this?
The perfect solution would be for VSCode to always have two REPLs open, automatically opening a new one and loading my code whenever I close a stale REPL.
We provide very tight integration between the REPL and the UI in VS code with things like the workspace explorer etc, and those UI elements currently all assume that there is only one Julia REPL. We do plan to support more than one, but it will require a fair bit of work in the extension to robustly support that scenario.
You can of course always run multiple instances of Julia in shell instances that you start inside VS Code, but those won’t be hooked up to the integration points that the Julia extension provides (code execution, plot gallery etc.)
I’d suggest using inline evaluation to re-define your whole module, which allows for structs to be changed all you want (with the caveat that you need to redefine all previous instances of your structs to work with the “new” module’s functions). That usually gets you around needing to restart.
The idea of keeping multiple Julia process around to connect to is something we had in Juno, but usually caused more issues than it was worth. Without trying to restore at least the loaded packages it’s also not a tremendous time saver.
Maybe you also repeated using .ToyMod after redefining ToyMod? If you did, then you should have seen something like:
WARNING: using ToyMod.Toy in module Main conflicts with an existing identifier.
This would mean that there is already a definition of the struct Toy in Main (the one imported the first time you executed using .ToyMod), and you are trying to modify it, which is not allowed. If you redefine the whole module, but don’t export Toy (or don’t try to import it twice), there should be no conflict, and ToyMod.Toy should reflect the new definition. (But if you already have some Toy object created with the older definition, then the situation can be messy.)
(This doesn’t work if you are tracking the module definition with Revise. You must really rebind ToyMod to a new module object, not just try to modify the definitions inside it, as said before regarding Maain.)
Right, having Revise enabled won’t affect. What I meant is that the problem happens if you track the module with Revise. For instance, if you have the code of ToyMod in a file and load it with includet (not include).