Hi there, I was trying for a while to “start without debugging”, but then I learned of F5, but that’s a bit hit and miss and I had to make a tasks.json file and now use Terminal > run task, then select my json task. I did have it setup much slicker before but I can’t remember for the life of me how I did.
Also, I still get quite a few messages that the julia server has crashed and repl is not running, I have no idea why. Is it because I’m using a newer version of Julia than the vscode extension supports?
You definitely cannot use an unsupported Julia version. I’ve got 1.3-alpha installed and symlinked to julia and anytime I do anything with a Julia file in vscode I get absolutely buried with errors about the server crashing and whatnot.
I still get them sometimes when I have 1.1.1 as my “main” julia version but not nearly the same frequency (maybe a couple of times per day compared to every couple of seconds).
I’m currently using 1.1.1, I think I was using 1.1.0 before. Going to try v1.0.4 LTS now to see if that cuts out the server crashing errors.
OK, the server crash messages have stopped but F5 doesn’t work properly, where it used to be fine before I uninstalled VSCode. I am using a custom tasks.json file to execute shell commands to run my files (more through luck than judgement).
Any ideas how to get F5 to work correctly again?
For example F5 just returns 10 with this code when asked how many terms to compute, but when using shell commands in the tasks.json file it correctly runs the 10 terms and outputs their values:
fSize = 0
i1 = 1
fTerm1 = 0
fTerm2 = 1
@printf("Please enter how many Fibonacci terms to calculate: ")
fSize = parse(Int64, readline())
@printf("Fibonacci Series upto term %d:\n",fSize)
for i1 in 1:fSize
# println("$i1:> $fTerm1")
if (fTerm1 % 2) == 0
@printf(" * is an even number!")
# println(" * is an even number!")
global nextTerm = fTerm1 + fTerm2
global fTerm1 = fTerm2
global fTerm2 = nextTerm
And my tasks.json file:
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"label": "Julia: Run Current File",
// Reveal the output only if unrecognized errors occur.
// Use the standard MS compiler pattern to detect errors, warnings and infos
// "problemMatcher": "$msCompile"
@Monkspeed Stick with it. The Julia community here are really helpful.
I use Atom rather than VSCode, so sorry I have no direct hints or tips.
However can I say something cheeky - do not get bount up in the tools. I make that mistake often myself, as a systems guy.
Use the REPL or a Jupyter notebook.
Setting up Jupyter notebooks is a skoosh (*). Use the REPL and install IJulia
I went to the Juno site and they’re abandoning it for VS code, which I think is a horror. Julia is supposed to be easy to use and replace multi-languages. VS code is hard to use and its feature is multi-languages. Why abandon Juno for it? I’ve tried to use VS three times and it errors out on one thing after another. I fix one problem and another pops up. It wants a commenting debugger when there is none available. It wants a special folder besides my program folder. It then errors out on other arcane things, one after another. I want to learn Julia, not $#@!# VS Code. Every other editor I’ve just picked up and ran programs as I went, just refining what I knew about them. You can’t “pick up” VS Code. And why does everyone want to be under the Microsoft umbrella? I remember having to code four different websites years ago - one for standards browsers, then three more for the Three Incompatible Msoft browsers. Msoft is overprogrammed and arrogant. Keep it simple.
FWIW Juno is still perfectly operational, just not actively developed in terms of new features anymore. I still use it almost every day and prefer it over VSCode for the most part.
As to why development focus has shifted onto VSCode, Microsoft basically pulled the plug on Atom development with the acquisition of GitHub, so there’s little point in fosing on an editor (which is also multi-language btw) which isn’t being actively developed anymore.
As you’re already aware of why M$ is a not-so-good company, the answer to this question is: ask why Microsoft told GitHub to abandon Atom editor in favor of their own VS Code when they purchased GitHub
Note the scale of the y axes: VS Code is getting more than an order of magnitude more development effort than Atom is these days. Making and maintaining an IDE is expensive and Microsoft is spending money on VS Code rather than Atom. Unless someone has a plan to fund the maintenance and development of Atom independent of Microsoft, moving over to VS Code and trying to make the Julia part of that experience as smooth as possible is the only viable way forward.
VS Code (the core product) is having quite a focus on data sciency stuff for quite a while now. For example, Microsoft is going to ship a version in a few days that has native Jupyter Notebook support in the core product (i.e. they just finished moving that file format support from the Jupyter extension into VS Code itself). This is obviously great for us: we are building on a foundation that is trying to support some of the very same scenarios that are core to Julia.
Microsoft has been a fantastic partner for the core dev team of the Julia extension. They are open, they are transparent, they listen to our feedback and needs and interact with us, and are actually committed to helping us make the Julia extension work well on VS Code. For the recent notebook integration they even opened some of the crucial PRs and contributed code to the Julia extension and coordinated with us on rollout etc.
The entire design of language support in extensions in VS Code around language servers is actually such that as a side-effect of us providing the VS Code integration, a fair bit of the functionality is also available to entirely unrelated editors (vim, emacs etc.).
But of course @StefanKarpinski’s point is really the most important one here: one of these projects has an enormous momentum, the other one doesn’t.
Right, there’s zero requirement to learn VS Code to use Julia. There is excellent support for Julia in emacs, vim, SublimeText, Jupyter notebooks, etc. If someone wants to keep using Juno, they can also do that. The code still exists, it will continue to be downloadable. The “horror” here seems to be that other people will not be doing free work on the specific project that someone wants them to?
Not wanting to be under the “Microsoft umbrella” but wanting to use Juno, which is based on Atom, which is developed primarily by GitHub which is owned by Microsoft is also amusing. It’s Microsoft either way, man. It’s just a question of using the highly actively developed Microsoft project or the one that’s winding down.