lambda_foo
Joined 17 years ago
Karma
101
Submissions
27
Member since
Sep 19
Recent submissions
Comment · 1 month ago
Early on with OSX I would update early because the new features in the OS were truely interesting (AFP, Dtrace, Spotlight, Early Siri, Messages sync with iPhone). Yes all very developer oriented, but I am a developer and that's primarily what I use my machines for. Releases like Snow Leopard and Tiger were full of novel features. Now I find most of the copy is dedicated to things I couldn't care less about like generative AI images or questionable redesigns of the UI.
I would love a review of the new developer and OS level features for macOS releases. The WWDC content is close to unwatchable, it never goes into enough depth and the video only delivery is not the primary way I want to consume technical content. Give me the cool highlights of the virtualisation framework, what still works with Dtrace , explain the infernal code signing permissions system, etc.
So far I've kept to Sequoia as the least annoying version, and avoided the Liquid Glass rounded corners mess.
Comment · 1 month ago
GTK4 bindings https://github.com/chris-armstrong/ocgtk
Comment · 8 months ago
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
Comment · 8 months ago
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.
Comment · 8 months ago
With OCaml 5 supporting effect handlers I expect MirageOS will go in that direction. It’ll make for more readable code than LWT.
Comment · 11 months ago
My own repo in the OP :-)
Comment · 11 months ago
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!
Comment · 11 months ago
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.
Comment · 11 months ago
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.
Comment · 11 months ago
Why have the OP in the loop at all if he’s just sending prompts to AI? Surely it’s a wonderful piece of performance art.
Comment · 11 months ago
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.
Comment · 1 year ago
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.
Comment · 1 year ago
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 :-)
:-)