NodeJS and Java are in a similar place (this CVE is a memory safety issue in PHP's C-language interpreter) but Go's compiler/runtime is written in Go and is memory-safe all the way down to the assembly.
Much of Node’s standard library is written in JavaScript, which can’t go on to exploit V8 vulnerabilities even given similar types of bugs, so I wouldn’t say it’s in a similar place. Not as familiar with Java, but I expect PHP is in a class of its own here.
In userspace/application code this isn't giving you all the value you hope for - because of overcommit and fork/exec, you can OOM on simply modifying a variable (in a non-file-backed page).
What Zig does is great, but it is not actually comprehensively checking that all allocations are fallible and handled. That's not possible on Linux.
I'm impressed it didn't seem to mention anything about what tools it was using, just straight to imports. Did you prepare any special tools for it, did you have WinDbg/Ghidra/... set up in Claude already? Or did it do this completely stock? Any idea if it even found pdb/symbols for the binary?
It looked for Ghidra and radare2, but I didn't have those installed (I do have WinDbg, but it didn't use it). So instead it built a bunch of Python scripts using pefile and Capstone (many of them inline). FYI, the linked log has most of the intermediate work removed since some of it contained personal information. It took a little over half an hour total, though some of that might have been waiting on approvals.
> Currently have auto compaction turned off. When the orchestrator's context is getting close to full, I have it write a handoff markdown file and point a fresh agent at it.
In a good harness that should be how auto compaction works anyway
Yes, and I'll probably trust it eventually. But currently I always want to know when compaction is happening, so I can correlate any drops in quality or weird behavior.
If you're focused on lightweight, native and fast, I don't think you should use an immediate-mode GUI toolkit. Why does an app like this need to hit a 60fps framerate? It's not a game.
I was surprised to see an immediate mode gui toolkit.
They're great to integrate into a game loop because you control your loop, (and they're a delight to use) but I thought for perf retained mode was the way to go?
Am I missing something? Then again if the bar needing to be beaten is spotify's existing desktop app maybe it doesn't matter?
Egui doesn't do that. But it's written in Rust and only updates when you interact with it so in practice it's way more efficient than I would have expected.
Author here. Two reasons I chose an immediate mode UI framework:
1. Latency. A click paints on the next frame, because it sidesteps the stages of a retained mode UI: there's no dirty-marking, no layout and paint passes scheduled for later, no cached visual state that can be stale.
2. Simplicity. The UI is a plain function of app state. There's no retained tree to keep in sync and no invalidation bugs: mutate the state and the next frame shows it.
Yes, the drawback is that you have to watch what a frame costs, but it doesn't repaint at every frame. It paints on input and you can schedule repaints yourself. Fastpotify sits at zero CPU when idle, asks for a few frames a second while a track plays, and runs at full rate only while you scroll.
I have no skin in this game, but just because they're doing it doesn't mean it's their focus, the EU is big enough to work on multiple 0.8%-size wins all over the place.
I'm not sure this is a real problem - for embedded you know a priori - for arbitrary desktop/SBC machines, misa will be available in kernel mode and /proc/cpuinfo will be available in user mode.
He actually explains this too. You only know at compile time what you're building for. For example with microblaze-V, I often tweak what ISA I'm generating. If I ran the same elf without thinking about it, who knows what could happen given the instruction collision problem
Well, misa won't be in most cases since you'll be running ins mode rather than m mode for most kernels on an application core (and misa won't tell you about the X* and Z* extensions).
But you'll practically be passed a device tree from SBI that will tell you.
reply