The type system for effects is an ongoing research effort. For now you get unhandled effect exceptions at runtime.
With Multicore OCaml we gained thread sanitizer support and a reasonable memory model. Combined they give you tools for reasoning about data races and finding them. https://ocaml.org/manual/5.3/tsan.html
Strongly agree, plus OCaml has an expressive type system that lets you build abstractions that just aren’t possible with Go. The original article gives poor reasons for choosing Go.
It's really fascinating the different little evaluators that exist in DWARF. I started writing one for the DWARF expression format (https://github.com/tmcgilchrist/durin/pull/7) that I'm integrating with a debugger and free-monad/effect handler style code to lookup the missing data to provide for the Requires* callbacks.
Then there is the line number evaluation, which I haven't started on.
Building a Debugger by Sy Brand (https://nostarch.com/building-a-debugger) is an awesome book if you want to learn more about this. It covers DWARF 4 and you build a full debugger in C++17 for Linux/x86_64. Can't recommend that book highly enough!
It is heavily WIP at the moment so I haven't published to opam just yet. You'll need to compile from source if you want to try it out. I'm filling in examples as I need them and publishing code when it isn't too terrible to look at.
Author here, a bit cringe to see your WIP project posted here.
My motivation for writing this from scratch is to simultaneously understand DWARF 5 in all its gory details, develop tooling to support my work on the OCaml compiler, and to build a source debugger in OCaml. The performance or lack of isn't a focus right now, I'm sure it doesn't compare to gimli-rs for performance but it does fully support DWARF 5 which gimli-rs doesn't (missing debug_info section support https://github.com/gimli-rs/gimli/pull/807).
Currently I'm working on the read support, and various bits of tooling around understanding Call Frame Information and simulating the DWARF expression evaluation. I'm unhappy with the tooling GDB/LLDB provide for displaying and debugging this information, I've personally spent far too much time staring at CFI expressions and walking memory looking for where it goes wrong. In the OCaml compiler we have few people that understand or work on this area.
Pretty much. I guess it’s open source but it’s not in the spirit of open source contribution.
Plus it puts the burden of reviewing the AI slop onto the project maintainers and the future maintenance is not the submitters problem. So you’ve generated lots of code using AI, nice work that’s faster for you but slower for everyone else around you.
The fact that Itanium had register windows was such a strange choice. I thought they had been shown to not be worthwhile like branch delay slots in MIPS. Basically hangovers from the early constraints of hardware implementations.
Thanks for sharing, I had no idea about this project.
Could you share some more details about where this project is used? Links to those open positions for OCaml developers would be interesting too, not for myself :-)
Using DAP with VSCode and OCaml's bytecode debugger (https://github.com/hackwaly/ocamlearlybird) works reasonably well already. My blog post above can be modified to work with VSCode, but I'm primarily an Emacs user. The main issue with Emacs and DAP is the DAP modes are not very polished.
The missing piece for OCaml is debugging native code, the compiler doesn't emit enough DWARF information and debuggers like LLDB or GDB, need to be modified to understand OCaml's DWARF information. Even there DAP with LLDB/GDB works, it's just the debugger doesn't have enough information to work well. You end up working with debugging assembly or C (if it's parts of the runtime). I've written up a PR documenting native debugging here https://github.com/ocaml/ocaml/pull/13747.
With Multicore OCaml we gained thread sanitizer support and a reasonable memory model. Combined they give you tools for reasoning about data races and finding them. https://ocaml.org/manual/5.3/tsan.html