It has probably already been considered, but the Crystal Interpreter opens up some unique opportunities for IDE debugging even though it already ships with an interactive shell.
I’ve been considering possible approaches to this, and I landed on an embedded TCP server in the interpreter that responds to the Debugging Adapter Protocol.
I made a project clone/fork that implements some basic commands (see diff), and a VSCode extension (see README. Please bear in mind that it is just an illustration.
There are a few reasons where I think it’d be nice to embed a DAP server, as an interpreter binary would work/debug out of the box with IDEs that support it.
There are also some wonky things and drawbacks, but I’d love to hear thoughts on this sort of effort. I’m not in a position to flesh out a refined proof of concept, but I’d love to collaborate if it would make sense and someone were interested.
I also appreciate that there may be technical limitations that make this idea not a good one.
I consider the main issue is: the interpreter is quite originality, in fact, except try some little snippets in REPL, use debugger in a project almost always not work because interpreter bugs, unless a hello world project, most of them seem like quite hard to fix according to the asterite.
so, the hard part not DAP server, instead of, the robust interpreter.
Hm, I haven’t noticed interpreter bugs so far, but a DAP server would be downstream from the interpreter itself - so any bugfixes would automatically apply when using an IDE. So I don’t consider the interpreter to be blocking IDE debugging at all, but rather allowing it to exist.
I second this idea. When I was working on MT, and the interpreter wasn’t started, I wanted a dedicated thread for introspecting the running application.
I would not wait for the interpreter “to be ready” to start this. Having this would help to discover bugs in the interpreter and give the interpreter much more exposure.
Similar to how the playground helped surfacing ToSVisitor bugs.
Awesome! I understand if y’all are too busy, but would anyone have any any interest in a brief technical walk-through of the interpreter code? I have rudimentary knowledge of C and low level Crystal data types, and not very much knowledge of the compiler. I have been following along alright so far (and learning a lot!), but I feel a walk-through would be more efficient than learning by reverse-engineering.
If there is interest, I think it could be really great to record such a session so that anyone could access (and even pick up the work) asynchronously. What I’ve found so far is that the compiler/interpreter codebase is largely intuitive once I connect the dots, but connecting the dots can take me a while from having limited experience with the problem space.
