Quick Summary: Pre-requisite skill is the ability to compile your own OCaml compiler. Only macOS and Linux. Breakpoints and single-stepping; no display of OCaml values.
Hopefully it will be the first of several if a few people subscribe or comment. The video, and others that I may make for that new channel, are not for OCaml beginners.
Aside: Personally, I don’t become a beginner in a new subject without first having a glimpse of what I can accomplish in that subject. My expectation is that the people curious about OCaml may land on a few videos and then become beginners.
Since this is my very first YouTube video, I’d appreciate feedback!
Thank you for making this video! The more OCaml content on Youtube the better, subscribed!
So here’s my feedback:
I found hearing your voice visually out of sync with your lips at the beginning of the video quite confusing
I think you need a better mic.
The background music was too loud, especially towards the end
Overall, I understand that I’ll need to compile ocaml on my dev machine if I want to get break points within vscode.
But, even after watching the video and reading the different READMEs, I’m still a little fuzzy on what DKML is exactly, it’s relation to Diskuv/Windows and why I would or wouldn’t want to use those tools.
I’m mainly developing on Linux and for Linux btw, but being able to develop and target the Windows platform with OCaml definitely sounds interesting to me.
Appreciate the feedback! I’ll do some changes for the next video.
This first video was not about DkML or Windows. Sadly, I had to cut a lot of material to fit the YouTube first-timer 15-minute guidelines. But sounds like I should make the next video(s) a deep dive into the DkML “base” compiler and more generally OCaml compiler variants and options: the DkML compiler is one of the foundations for the DkML Windows distribution (and the Android / macOS / etc. cross-compilers).
Oh nice! More OCaml content online! This was a great video!
The animations during explanation were also really good, and the length and pacing of the video were great as well — a nice nutshell of information without dragging on too long. I also liked the outro music.
A slight critisism would be you spend a bit of time describing the extensions you’re using, but eventually it seems like the OCaml platform is the only one that’s required for the content of the video — I guess the video could be more streamlined if you just mentioned the essential plugins.
I’m not familiar with this restriction but we’ve been on YouTube for a number of years and the Houston Functional Programming Users Group can always host videos. That goes for you or any other OCaml videos (and FP in general). If you have a “director’s cut,” we’d love to host it.
Thanks for the constructive criticism. The C extensions are required … it is the C extensions that are controlling GDB and LLDB and providing the breakpoint and stepping functionality, not the OCaml Platform extension (at least on the machine I tested by disabling the C extensions; correct me though if you can get the OCaml Platform extension to do the native debugging!). I may have cut too much content if that requirement wasn’t coming through, although I agree the extensions part is long and repetitive. Food for thought for next time!
Thanks! I’ve now got past the hurdles, so it doesn’t make sense to get the videos hosted indirectly. But for others that may be a really good option.
I’m a bit confused about the need for compiling the OCaml compiler oneself. Because I’m on Linux, using an OCaml compiler directly from opam (without any modification) and can simply attach gdb (e.g. with the C/C++ extension in VSCode) to a native code OCaml binary to get breakpoints and stepping in the OCaml code.
That in itself is not surprising because ocamlopt includes the appropriate debug symbols in the binary which are understood by gdb and perf. Displaying any values on the other hand… we can only dream I think. I don’t know the native code compilation details but as far as I can tell local primitive variables are just in some registers (also seen in VSCode debugger) however the register allocation assigned them. Everything else you’d have traverse to by some pointers.
I think I mentioned that, although I used the word “remote debugging” rather than “attached”. “Attached” is more accurate.
However, I was describing more than just stepping through your own OCaml code. You can also step through the C code (standard library and 3rd party libraries) and assembly code. In short: everything.
As long as you have debug symbols you can step through and disassemble any machine code. But:
there is a (significant) difference between seeing reverse disassembly and seeing original assembly code. I suspect if you look at your GDB you’ll see reversed disassembly (which isn’t too bad these days)
compiling the OCaml compiler guarantees that the standard library (the C code) is actually present on your file system in the exact spot where they were compiled and captured in the DWARF sections. There are other ways to make sure the compiler source code is present at the right locations, or to tell the debugger where the source files are, and I am not going to pretend I know or presented an exhaustive list. opam, for example, will have the ocaml-base-compiler source files in the .opam-switch/build/ directory but will usually delete those source files if you don’t use the --keep-build-dir option
The -g compiler flag is automatically added in OCaml 5. I presented OCaml 4.14, which if I remember correctly only adds -g for Linux but not macOS. But that is minor.
Also, since you mentioned using opam without modification: you won’t get third-party source code without the --keep-build-dir option, and you won’t have your dune-workspace settings propagate to your third party dependencies.
Finally, you mentioned the dream of value printing. If you have real source code debugging (not reverse disassembly), you can attach a printer to a typedef using LLDB because LLDB parses the C source code during the debug session uses clang typedef debug information. Today the typedef printer would exclude the generated assembly code, but you should be able to get a lot of mileage from just setting breakpoints in C code (perhaps instrumenting your OCaml code with external debug_here: something -> unit = "debug_here" statements). And LLDB does let you inspect the registers and stack, especially in their custom frame printers, if someone really cares about printing native assembly code. MSVC has similar features. Not something I will do personally though … I am fine with stepping over pretty-printed log statements the few times I want to debug.
In addition to increasing your subscriber count on YouTube, you’re also very welcome to mirror your content on watch.ocaml.org if you choose. This doesn’t have anything like the network effect of YouTube of course, but it is a nice collection of OCaml-specific things in one place (@davesnx has also been mirroring his podcast up there too). You (or anyone else interested in similar) can create an issue on Issues · ocaml/infrastructure · GitHub if you’d like an account setup for you.
