Infiltrator.jl VS JuliaInterpreter.jl

Also Infiltrator is very fast and useful but don't try to use it from the Vscode integrated terminal.

The package Infiltrator.jl might be what you seek. It's not as good as inserting breakpoints like in Matlab but it's still better than printing everywhere haha

Yes, it uses Debugger.jl, which relies on JuliaInterpreter.jl under the hood, so while you can tell the debugger to compile functions in certain modules, it will mostly interpret your code.

You might be interested in https://github.com/JuliaDebug/Infiltrator.jl, which uses an approach more similar to what you describe.

Another small thing is in the REPL when you trigger an error in Common lisp it drops you into the debugger where you can redefine code and retry directly from the stack without unwinding the entire stack. Does Julia have functionality similar to this? Currently when I trigger an error Julia just throw the error and goes right back to the top level prompt. To resolve this issue I've tried sprinkling my code with a combination of GitHub - JuliaDebug/Infiltrator.jl + Stack Traces · The Julia Language wrapped in try catch blocks so that if an error is singled it drops into a debugger of sorts. This is ok and it works but it isn't really as good. Is there a current package that can emulate what I am trying to do? I think that the REPL workflow is good in julia but the workflow stalls out when you run into errors that don't drop into debuggers and such.

Have you ever tried Infiltrator.jl and Chain.jl?

The projects page is a list of suggestions of projects that someone has already said they want to run. If you can find a mentor, you can submit a project for anything. For potential performance improvements, I'd look at https://github.com/JuliaDebug/JuliaInterpreter.jl/issues/206, https://github.com/JuliaDebug/JuliaInterpreter.jl/issues/312, and https://github.com/JuliaDebug/JuliaInterpreter.jl/issues/314. I'm not sure if Tim Holy or Kristoffer have time to mentor a project, but if you're interested in doing a gsoc, ask around in the Julia slack/zulip, and you might be able to find a mentor.

I would not go as far as calling it very naive, there has certainly been some work put into optimizing performance within the current design.

There are probably some gains to be had by using a different storage format for the IR though as proposed in [1], but it is difficult to say how much of a difference that will make in practice.

[1] https://github.com/JuliaDebug/JuliaInterpreter.jl/pull/309

You're right, done some more research and there seems to be an interpreter in the compiler: https://github.com/JuliaDebug/JuliaInterpreter.jl. It's only enabled by putting an annotation, and is mainly used for the debugger, but it's still there.

Still, it still seems to try executing the internal SSA IR in its raw form (which is more geared towards compiling rather than dynamic execution in a VM). I was talking more towards a conventional bytecode interpreter (which you can optimize the hell out of it like LuaJIT did). A bytecode format that is carefully designed for fast execution (in either a stack-based or register-based VM) would be much better for interpreters, but I'm not sure if Julia's language semantics / object model can allow it. Maybe some intelligent people out there can make the whole thing work, is what I was trying to say.

It could, but that is a lot more work than it sounds. It might be easier to make it possible to swap out the compiler for one that is much faster (LLVM is slow but does good optimisations, other compilers like cranelift are faster but produce slower code). There is a Julia interpreter but it was written in Julia itself (it was written to support debuggers), so it doesn't really solve the latency issues.

If you need to run small scripts and can't switch to a persistent-REPL-based workflow, you might consider starting Julia with the `--compile=min` option. You can also reduce startup times dramatically by building a sysimg with PackageCompiler.jl

There is also technically an interpreter if you want to go that way [1], so in principle it might be possible to do the same trick javascript does, but someone would have to implement that.

[1] https://github.com/JuliaDebug/JuliaInterpreter.jl