This could be due to Gtk!
The really bad thing is, that one doesn’t even notice that Gtk gets loaded…
This is why I recently opened this PR: https://github.com/JuliaGraphics/Gtk.jl/pull/454
Which probably hasn’t been tagged yet…
This could be due to Gtk!
Thanks for your suggestions I disabled the Real-Time protection and to my greatest regret this did not help . It is good to know that it is not an antivirus problem.
But below you will find the solution below.
I removed the Winston package and the problem is now solved . I have no longer the lag problem of typing and Visual Studio runs fast.
This is a real pity since Winston has an amazing syntax and is fast, now I need to look for an other package.
If you think generating that warning is important, you should create a new PR. Looks like the warning added in that PR has been overwritten on master.
@sdanisch Is it then known that Gtk will cause trouble on Windows? And the reported problem does not by itself have anything to do with Winston?
Since it is best not to use Winston plotting package since it is no longer maintained , what plotting package will you suggest to use which does not make usage of DataFrame and does not rely of Gtk since we found that it causes issues?
I need the plots to be relatively fast as I require to plot 100 plots each time and which plots as .svg so I can view the outputs in a browser? It will be nice if the plots offers some flexibility in the design of the plot?
using Winston is fine. While there is indeed currently nobody fully responsible for maintenance, I usually do the releases and look that it is still working because I use Winston in a larger application.
The Windows Gtk issue is, however, something that I do not have a solution for.
I think GR is quite fast and lightweight, and can do SVG.
You can use it directly, or as a backend to Plots.jl.
Just as an idea: It should be relatively easy to build a ‘headless’ Winston, that doesn’t use any windowing toolkit, as all rendering is done via Cairo anyway. Simply opening a SVGSurface, plot to it and save to file.
Silly me. I just forgot that we still don’t have optional imports …
Winston used to be dependent on either Tk or Gtk and you are right that in principle no dependency is required at all. But I will not push this forward since its an ugly workaround. Gtk should be simply fixed on Windows. If Julia’s task system in 1.3 is so advanced as promised, there should be a solution to it. It just needs someone having experience with event loops and Julia’s task machinery. I don’t have experience with both plus and don’t use Windows. So thus I cannot contribute to it…
Thanks for providing me an alternative solution to Winston. I was considering GR of PlotlyJS. Are there advantages of using GR directly rather than by using the backend Plots which may add an other layer of complexity? Thanks for any suggestions.
Generally by using a backend directly you can do things that the generic code may not implement (yet), though GR is one of the backends with highest coverage. OTOH, using Plots.jl allows you to switch backends later if you want to.
Same problem… but didn’t meet any crashes
Regarding the Visual Studio Code language server crashes, these should be fixed in the upcoming plugin version. Related issue: https://github.com/julia-vscode/julia-vscode/issues/876
Thanks for your time and for your suggestions
Thanks for recommending me GR. As you recommended I tested GR as a backend using plots. The plots are beautiful, nevertheless, I am surprised that the plotting seem to be 100 times slower than WINSTON (before Windows update). Do you think that GRUtils will solve the problem of plotting speed?
Well, now that Tk.jl is back in circulation, and with guaranteed installation on all platforms via jll’s, maybe it’s time for Winston to go back to it’s roots and use Tk.
This is good news, to clarify does this mean that we can now use Winston on Windows or do we need to wait for this to happen?
What is the motivation of using Tk instead of Gtk? The code was problematic when it was possible to switch between Tk and Gtk.