Show HN: Plexe – ML Models from a Prompt (github.com)
74 points by vaibhavdubey97 6h ago 37 comments
Show HN: Pinggy – A free RSS reader for the web (pinggy.com)
6 points by vasanthv 20h ago 1 comments
Show HN: MP3 File Editor for Bulk Processing (cjmapp.net)
28 points by cutandjoin 2d ago 17 comments
Nnd – a TUI debugger alternative to GDB, LLDB
190 zX41ZdbW 58 5/6/2025, 1:58:03 PM github.com ↗
Didn't expect it to be posted, readme maybe doesn't have enough context. It just says "Essential features are there". What are those? Most of what I've ever used in any debugger:
* Showing code, disassembly, threads, stack traces, local variables.
* Watches, with a little custom expression language. E.g. you can do pointer arithmetic, type casts, turn a pointer+length into an array, show as hex, etc. Access to local and global variables, thread-local variables, registers. Type introspection (e.g. sizeof and offsets of fields).
* Pretty printers for most C++ and Rust standard library types. Probably fragile and version-dependent (e.g. fields names often changes across versions), please report when they don't work.
* Automatically down-casting abstract classes to concrete classes.
* Breakpoints, conditional breakpoints (but no data breakpoints yet).
* Stepping: into/over/out a source code line, into/over a disassembly instruction, over a source code column (when there are multple statements one line, e.g. to skip evaluation of arguments of a function call). All places where control can stop (statements) are highlighted in the code, so you usually don't get surprised by where a step takes you. (...except when there's garbage in debug info, and you end up temporarily on line 0 or something. This happens frustratingly often, and there's not much I can do about it. I already added quite a few workarounds to make stepping less janky in such cases. If a step takes you to an unexpected place, it usually under-steps rather than over-steps, so you can just step again until you end up in the correct place.)
* Various searches: file by name, function by name, function by address (like addr2line), type by name, global variable by name, thread by stack trace.
* Debugging core dumps. There's also a gdump-like tool built in (`nnd --dump-core`) that makes core dump of a running process without killing it; it uses fork to minimize downtime (usually around a second even if there are tens of GB of memory to dump).
* Customizable key bindings, see `nnd --help-files` or `nnd --help-state`.
* TUI with mouse support, tooltips, etc.
For example, a crate that could be linked in to provide some "well-known" object shapes (hashmaps, vec, hashset, etc) with marker values that could be heuristically analyzed to understand the debuggability of those objects?
Alternatively, I'd love to have a crate with recognizers and/or heuristics that could be somewhat debugger-independent and could be worked on for the benefit of other users. I'm quite an experienced Rust developer, just not really with debuggers, happy to help if there's a sandbox project that this could be plugged into.
I cannot tell you how much respect I feel for you
[^1]: https://www.timdbg.com/posts/writing-a-debugger-from-scratch... [^2]: https://nostarch.com/building-a-debugger
[1]:https://keowu.re/posts/Writing-a-Windows-ARM64-Debugger-for-...
--
1: https://github.com/munificent/craftinginterpreters/issues/92...
Another book added to my To-Read list
Operations that can't be instantaneous (loading debug info, searching for functions and types) should be reasonably efficient, multi-threaded, asynchronous, cancellable, and have progress bars.
I wish this were more common, especially the progress bars thing.
(It shows only about 500 MB of machine code, and the rest of the gigabytes are debug info.)
Not sure about ClickHouse though.
No comments yet
https://github.com/EpicGamesExt/raddebugger/issues/23
https://cgdb.github.io/
Command line often requires a lot of switch memorization. Command Line doesn't offer the full interactive/graphical power in this sort of situation. Command line is great for scripts and long running apps, or super simple interfaces.
Different apps have different requirements. Not everything needs a TUI, not everything needs a GUI, and if you want something similar to a GUI while staying in the terminal. Perhaps you don't have access to a windowing environment for some reason; perhaps you want to keep your requirements low in general.
Finally, why do you care? Some people like it others don't. Nobody comes in and shits on any programs that are GUI if they don't like it, they just don't use it. So, to quote The Dude: "That's just, like, your opinion man". Sorry for the snark, but... It really is, and you're free to have it. But it seems an irrelevant point, and there may be better forums/posts (maybe an "Ask HN" question would be a good option) to discuss this question in depth beyond snark.
Short summary: No animations, No symbols, No touch optimization, no responsive design and I do most of the other stuff in the Terminal anyways so TUI is better "integration" YMMV :)
You don't have to make a GUI with any of those.
edit: and a reason you would do this locally using ssh is debugging the UI layer itself. if you have to step through the window server, you can't be using the window server at the same time. Remote lldb/gdb debugging is often just flaky. I don't know why they're so unreliable, but they are.
Linux may not be so pretty, but it's far more comfortable.
My "all Thinkpad, all the time" strategy has generally served me well (though I was disappointed by the most recent one, a T14, which would never sleep properly).
I don't want to go through the curl | bash either for security reasons.
It would be nice to have some package manager support, but it looks cool.
All you need to do otherwise is add it in PATH.
> Linux only > x86 only > 64-bit only