Ideally in an IDE like VSCode. If only command line is possible, that’s ok for now.
I don’t know about using a debugger as part of an embedded workflow directly, but I’ve been pretty happy with Debugger.jl (gdb-like) for general debugging.
The julia VSCode plugin has some custom infrastructure for this though, maybe you can make use of this/their expertise?
I think a better solution might be running Julia in a separate process and IPC to communicate with it. That way Julia can be debugged via VSCode as normal and the latencies are less important as well. Modules can load in the Julia process and tell the C++ process when they are ready for use.
In my mental model of how julia works, that’s basically the same as embedding julia in the first place, except embedding already gives you a programmatic API to interact with the julia process.
So it does! I’m now trying to figure out how to attach a VSCode session to that external process and debug specific scripts. If anyone knows about this kind of stuff I’d appreciate the help.
One issue I haven’t been able to address in embedding Julia in C++ is the ~10 seconds it takes to load all the Julia dlls on startup in a debug session. If I can’t figure it out, it might still be worth running Julia as a second process and communicate through IPC.
So I exhausted the possibilities and got responses from the VSCode folks and there is no direct way to do this. My only solution is to run the Julia side on a separate project and process in it’s own VSCode workspace, so it can be ran and debugged in VSCode. Then have the C++ code communicate with the Julia process via some inter process communication (IPC) method. It’s not terrible to be honest, but not ideal in the long run.
We could probably add support for attaching the debugger to existing Julia sessions directly, but it probably wouldn’t do what you want. E.g. if you have a message handler server or whatever running normally and then attach the debugger to that process, nothing will actually be debugged because you’re already running compiled code. So you’d need to dynamically re-define and restart your code to run interpreted.
1 Like
Thanks for the response. I didn’t realize that aspect of the language. I’ve been primarily a C++ dev where you can attach debuggers at any time to processes. If there’s a better way you can envision of Julia running alongside C++ such that the Julia scripts are debuggable in VSCode, I’d love to hear it.
To explain an alternative a bit better. I can not embed Julia and run it on its own in VSCode with breakpoints and normal debugging and there would be an IPC receiver taking commands from C++. The only other thing I can think of is relying on print based debugging.
IPC is your best bet, imho. But I feel like I should also warn you that Julia’s debugger isn’t known to be particularly robust (or fast).
As I mentioned in another thread of yours, while julia looks like a scripting language (in that it looks more like python than your “traditionally compiled” C, C++, Java or Rust, i.e. lack of curly braces), it’s very much a compiled language. So debugging via gdb or using valgrind are options, though they require way more intricate knowledge about how they & julia work than (what I assume) your designers know/should know. That avenue also isn’t exposed in high-leve tooling, mostly because that level of detail is useful to language developers, not language users (who live a little removed from the nitty-gritty details).
Does your engine have a debugging console at runtime? If so, you could give your designers a “debug mode” there which would drop them in a prepared Debugger.jl session that’s running in the embedded julia process. This won’t solve the inspection of already compiled code or show variables in an existing editor, but may (together with Revise.jl) ease exploratory development. Still, there will be an up-front tech/time investment required if you want to have an introspective debugger of compiled julia code.
I suspect though that this capability of inspecting compiled code will be more developed in the years to come, with the plans for supporting more static compilation of julia code. It’ll be necessary, simply because inspecting where in a compiled library code something goes wrong will probably become more interesting.
@solaris sorry for only thinking of it now, but there’s also Infiltrator.jl, which allows inspection of compiled code. This comes at the cost of not being able to step around at will though, since the code remains compiled.
And also requires an active REPL session, which typically wouldn’t be the case for embedded code.