Hmm, I’m afraid that I still can’t make it work. It still stalls with Julia Process and when I change it to Text I see this error.
You mean, to do the using? It works fast on the normal REPL (I mean, that in PyCharm).
The DISPLAY_IN_VSC? I added it so one can display in VSC plot pane & Notebook (that is the default), or if set to “no” the display shows up in a floating figure.
I got another idea… which OS are you on?
Windows
Yeah. I think that is why. I am currently trying to reproduce it all, hence why I haven’t responded yet. But am on it 
@joa-quim: I finally managed to fully recreate all of your issues locally and fix them.
So now GMT loads:
I did have to also update my code for it so that I am using the same ENV hook you implemented for vscode and also support streamed images, rather than exported files. But it works now!
I will finish up some pending work on other bugfixes and then submit an update later today
You must have had a lot of work given the time you took this time
I see that you add Ghostscript_jll? Why so? It’s a GMT.jl dependency so you should not have needed to do it. But on the other hand there is something broken in it on Windows. If Julia is not in the path (which happens when installed via juliaup) a libz.dll error raises up. Did you cross with that problem?
Yes, exactly - I hit the libz.dll issue you’re describing, and that’s the whole reason why I ended up down the Ghostscript_jll rabbit hole. The plugin does NOT depend on Ghostscript_jll. The message in my screen was only for me during debugging.
The actual requirement is either:
Other issues I ran into: GMT is really heavy with lots of transient dependencies. That broke some of my other dependencies in my test project and also caused a bunch of troubles during test runs…
Sorry to hear that you had all those troubles. Regarding the Ghostscript, I brought it up here Juliaup breakes GMT (via Ghostscript and tmp dir permissions) but it went up unnoticed. I must report it as a bug.
Hmm, can you elaborate a bit more (or open issues i GMT.jl repo)? GMT has only 2 non-stdlibs or *.jll.: Tables and PrecompileTools, so a very minimalist depends chain. What do you mean by: transient dependencies?
I can’t remember the details, but some broke during the notebook session, because another dependency of mine was already including Plots. And I also bumped into issues in combination with Makie and others - chances are those aren’t related though. After a cleanup of the dependencies everything was okay.
The most time I spent on a precompilation issue though. I must have had some bad luck during one of my trials, and afterwards the old stale pids were still left behind. So GMT would never even complete precompilation. I ended up adding a new tool action for us that cleans up these stale pids (that are not bound by an ongoing julia session) - you can find it under Tools - Julia - and also added a check for them during REPL startup.
Lastly: Notebook kernel runs are super slow (you noticed the same problem) because of the precompilation - it is an entirely new session each time, for better or worse, but it means packages need to be reinstalled, which took super long in my case. There was also no indicator other than the top right one that hte session was still ongoing. I now switched the defaults to REPL session and added a cell execution timer underneath the cell that should display during its run.
Ah, I see. GMT, Plots and Makie share several plotting function names, and that may lead to many name clashes if not prefixed.
The precompilations in Julia have been a long time mystery to me. Starting a session on REPL where a precomp cache exists takes ~0.7 sec for me. But (almost)anything else than the normal REPL triggers compilations like crazzy.
I think one of the benefits of doing this project for me is that I get to download, try out and sometimes even understand (parts of) the sources of other Julia projects. It is quite cool actually - so the detour was a welcomed one…
New Release: Flexible Julia 2026.9.18
New Features:
Changes:
Fixes:
include chains (#105)More notebook polish. Live stdout streaming means you actually see println output as it happens instead of all at once. GMT.jl inline rendering is fixed properly now, and the kernel no longer hangs during heavy package loads.
Switched the default notebook kernel to REPL so it reuses your existing Julia session - faster startup and shared state.
Also enabled “Break on error” by default in the debugger. You can still turn it off, but most people seem to want it on.
@joa-quim: Thanks for the continued GMT.jl feedback!
@mvscheven: Appreciate the reports on method overloads and Variables panel duplicates!
@ufechner7: Thanks for the doc-link and include chain fixes!
Gave it a quick test and it works (bravo) but …
You should be able to either scroll down to see the rest of it - or see it in the plots panel In the Julia tab. The rest I will fix for Monday (I got some family event to attend).
Thanks!
Man, take the whole week for that