Show HN: Clippy – 90s UI for local LLMs (felixrieseberg.github.io)

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.

Conscat · 1h ago

At my previous job, the product I worked on would open something like 200 DLL plugins on start-up. This would basically hang GDB while it's indexing the DWARF symbols, but LLDB gives you a very nice asynchronous progress indicator for that.

hippospark · 2h ago

For those interested in writing a debugger: There are a series of tutorials on how to write a debugger from scratch for Windows x86-64 using Rust [1]. Additionally, there is a book titled "Building a Debugger - Write a Native x64 Debugger From Scratch" by Sy Brand [2].

[^1]: https://www.timdbg.com/posts/writing-a-debugger-from-scratch... [^2]: https://nostarch.com/building-a-debugger

phaistra · 5m ago

I recently found a super cool article[1] which also gives a good overview of how a debugger works.

[1]:https://keowu.re/posts/Writing-a-Windows-ARM64-Debugger-for-...

emmanueloga_ · 1h ago

Cool! I did not know about that book. Added to [1]. :-)

1: https://github.com/munificent/craftinginterpreters/issues/92...

_benj · 1h ago

Nice! Thanks for sharing :-)

Another book added to my To-Read list

alfanick · 2h ago

Sideline question: how do you end up with 2.5GB binary (ClickHouse as given in the readme)?

mmoskal · 1h ago

Very typical for anything with CUDA (they tend to compile everything for 10 different architectures times hundreds of template kernel parameters).

Not sure about ClickHouse though.

mrazomor · 46m ago

Heavy use of C++ templates can significantly increase the binary size. Same for the heavy use of generated code (e.g. protocol buffers etc.).

PhilipRoman · 2h ago

#include <iostream>

No comments yet

philsnow · 2h ago

GDB already has a TUI.. it's pretty "vintage" though. I looked at the screenshot at the top of the repo README and it looks like it has a lot more creature comforts (read: any at all compared to GDB).

mbeavitt · 1h ago

check out [cgdb](https://github.com/cgdb/cgdb) - ncurses based gdb tui, with vim bindings. It's no longer actively worked on, but is decently maintained with bugfixes etc AFAIK.

tieze · 1h ago

People here might also be interested in pwndbg, which adds a lot of qol improvements to the typical gdb/lldb experience. Including splitting dialogs over tmux panes, a lot more context info added to debug lines like where do pointers point to. Heap inspection. Colorization. makes for a much more friendly debugging experience.

trollbridge · 2h ago

Awesome work. Reminds me of CodeView back in the day, which I've been wishing I could have back since, and no, a gigantic pile of Emacs or vim plugins is not the equivalent.

tw600040 · 13m ago

Not related to this post, but why in the world is anyone using TUI. Either go with GUI or go with commandline. This no man's land in the middle is the worst of both worlds..

justinrubek · 47s ago

I have many beloved TUI tools at this point, and I am considering investing further in TUI for some further projects I am building that I would want some kind of interface for beyond a command line. I'm not convinced by this argument. Would you mind elaborating on any specifics?

fsckboy · 10m ago

are you considering emacs a tui? vi/vim? if you want to edit without a tui, i gotta recommend teco over ed/ex

KerrAvon · 11m ago

One common use case is remote debugging over serial or ssh.

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.

jebarker · 2h ago

This is nice. I want something like this for python that I can use on remote servers and compute nodes of clusters. I've tried pudb but I find it doesn't behave well with terminal resizing and I wish the interface was a little more configurable.

sys_64738 · 1h ago

I couldn't python without adding -m pudb. That's not to say it's not temperamental, but I can live with the quirks once learned.

jebarker · 14m ago

I should force myself to live with it for a week and see if I get more comfortable. One face of it it certainly does everything I currently rely on vscode remote for

coldblues · 1h ago

The RAD Debugger is getting a Linux port so hopefully we won't have to deal with the sad state of Linux debugging anymore.

dvektor · 2h ago

Very cool! I have been using LLDB quite a bit lately so I am eager to try this out. The state of debuggers dev experience really hasn't caught up to what things like Cargo have done for build systems, so I am glad to see people working on things like this.

worldsavior · 2h ago

Why do you use LLDB on Linux?

fcoury · 1h ago

Is there anything similar to this that would support arm64? Unfortunately lldb is still not on par with even gdb.

danhau · 1h ago

Cool! Looks like the btop of debuggers. That‘s certainly a tool I would love to have.

Zambyte · 2h ago

Cool :D anyone get a chance to try this out with Zig yet?

deagle50 · 1h ago

the macOS drought continues

_bohm · 1h ago

It is really crazy how limited debugger options are on macOS. Is it simply the case that there are not that many people writing code in systems languages on macOS outside of XCode?

marssaxman · 1h ago

I used to be such a person, but after years feeling as though Apple found people like me irritating and wished we would all just stop bothering them, I finally took the hint.

Linux may not be so pretty, but it's far more comfortable.

deagle50 · 38m ago

Linux is great, my issue is laptop hardware.

pimeys · 1h ago

Kind of. I am a systems engineer and want to work on an open OS I can debug with my syseng skills...

worldsavior · 1h ago

It's because macOS has security measures.

Keyframe · 2h ago

great! I already gave up on RemedyBG or RAD/Epic debugger ever on linux to happen.

theoperagoer · 2h ago

Very cool. How many architectures do you support?

baumschubser · 1h ago

It does say so right in the readme:

> Linux only > x86 only > 64-bit only

FpUser · 2h ago

It looks very useful. I will definitely test it. Thank you for such contribution.

jmclnx · 3h ago

Looks very nice, will need to give it a spin :)

colesantiago · 2h ago

How does one install this?

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.

laserbeam · 1h ago

There’s only 1 artifact. A static executable. No “need” for a package manager. If someone builds a package manager they would just need to compile the src and ship the executable.

All you need to do otherwise is add it in PATH.

ablob · 1h ago

You can always build it yourself and put the binary somewhere in your runtime path.