My name is Tiago and have recently started to develop using Motoko (graduate from Motoko Bootcamp).
One of the things I miss the most is a basic Debug experience, with a breakpoint, where a developer can see the memory/variables state, stack, and then proceed to next line / step in, etc.
This is critical for better understanding what the code does. Not only for begginners, but anyone developing on the IC. Whenever a function’s behavior starts to be unexpected, it’s very important to have this tool for faster verification and proof of where things are going wrong.
It is very frustrating and time-consuming not to have this feature.
Have checked in Discord with the “Developer Tooling” Working Group and came to understand that for such a feature to be available, it would need to be a separate compiler, like Rust Analyzer.
Since there are probably very few people that feel confortable with the compiler, am wondering if Dfinity has any plans to support and provide this to the developers.
You can see the “debugging” feature of the Rust Analyzer in this screenshot:
We are aware of the need for this and have experimented with various approaches in the past:
using Visual Studio to debug a translation of non-IC Motoko Wasm to .NET IL, exploiting the rich debugger of VS.
using wasm sourcemap and name section info to debug non-IC Motoko Wasm code in a browser (e.g. Chrome or Firefox), debugging using the developer tools.
adding Dwarf 5 debug info to wasm code to enable debugging of non-IC Wasm via wasmtime and lldb.
the recent motoko-vm project adds time-travel debugging to a Motoko interpreter, but is not yet at full parity with Motoko and IC features.
The first three would be suitable for debugging library code, not full canisters.
The last will hopefully span more scenarios.
None of the early approaches gave you the full debug experience of a symbolic source code debugger people have come to expect for languages like C# and Java, but some weren’t terrible. Part of the problem is that debug support for Wasm itself is not great and doesn’t seem to be receiving enough attention, for example, there is no standard for full debug information so efforts seem to abuse existing format like Dwarf and JS sourcemaps, which aren’t necessarily a good fit.
Hi @claudio, I came across an analyzer for an eDSL of some chain (I won’t name it here to be in line with community guidelines ) released recently. I know that Motoko is more than an eDSL, but nevertheless, we could all benefit from better tooling for this very practical and purpose built language. Anything new we can try?
) released recently. I know that Motoko is more than an eDSL, but nevertheless, we could all benefit from better tooling for this very practical and purpose built language. Anything new we can try?