Hacker News Reader

Comment by himata4113 | Hacker News Reader

Isn't that an issue with your terminal? Why is stdout so slow?

I think it's due to they are doing a funny business to parse the progress, that's pretty much vibed and no one care. Like instead of using curl's progress, they re-invented a progress tracking with the tracing interface (--trace-ascii), byte by byte :(

https://github.com/anomalyco/opencode/issues/22998 https://github.com/anomalyco/opencode/issues/53702

Okay nevermind this is pretty bad. Although humans do this too and I've also done this without realizing it, only noticed when I was trying to move a file bigger than few kilobytes.

I’m kind of surprised at the overlap in “has progress bar” and “is expected to take a few seconds max”.

I’ve never even debated it for files under hundreds of megs. It’ll show up soon, if I care I’ll do an ls in a loop to look at file sizes. Just log where the file is.

It's one of those paradoxes inherent to software development: even if a tool is designed to work with Big Data, developers are too impatient / feel too unproductive to actually work with Big Data during development, so they only bother testing their tool using small data for 99.9% of development. Problems the tool has under actual Big Data tend to only start being found as of v1.0-rc1.

it's also an inherit bash problem where what you write is what you get, there's no buffer to keep you from slowing something down to a crawl.

I don't think fast gpu rendering terminals should be mandatory for this kind of thing, and if you should have an option that facilitates the need for one then might I suggest falling back to something sensible rather than stalling out for forever when the user doesn't render glyphs as fast as you want them to?

either that or fail outright; dont waste my time.

My terminal has gpu acceleration disabled due to being wasteful with vram and while I don't use opencode I've ran the script and it was completely fine using minimal cpu.

If it doesn't work at least ok with something like xterm, someone really needs to reconsider some life decisions. Htop makes it work, why should a terminal emulator need to crack the engima just to render silly stuff?

Well, stdout is not typically implemented for the purpose of simulating graphics rendering via character manipulation.

htop? btop(meh)? iotop? docker build?

...

claude code?

htop and similar TUIs have a refresh rate of 1 frame per second

anything that can run those applications should be able to run a progressbar, but as I have learned it updated the progress bar based on bytes received and not based on time.

https://github.com/ChrisBuilds/terminaltexteffects

All of the common terminals run TTE surprisingly well. That's 60fps, pushing many megabytes per second of text and control sequences.

Reply on news.ycombinator.com