What is the advantage of this circular implementation?

Is it faster than the simple one? Does it use less memory? Is it easier to write? Is it easier to understand?

I think all of the above is false, but I have a limited understanding of Haskell. Please correct me if I'm wrong.

There's no (practical) advantage to the circular implementation; it's just a curiosity.

It is useful for understanding laziness and some interesting theoretical tools for traversing data structures, though. For a more in-depth look at the idea of circular programs for traversal, Bird's paper (linked in the post, https://link.springer.com/article/10.1007/BF00264249) is a good start.

> The algorithm isn’t single-pass in the sense of Adaptive Huffman Coding: it still uses the normal Huffman algorithm, but the input is transformed in the same traversal that builds the tree to transform it.

Limited understanding here too. Sounds like it's not really single pass anyway so it's not usable to process a stream in real-time either, before having all the data?

It's a weird claim about a single pass too. It's more of a "let's replace some iteration with building a tree of functions to call" and then pretends waking/executing that is not another pass.

Why is ELF so much slower and/or more memory hungry than a.out on Linux?

Relocation information, primarily.

ELF supports loading a shared library to some arbitrary memory address and fixing up references to symbols in that library accordingly, including dynamically after load time with dlopen(3).

a.out did not support this. The executable format doesn't have relocation entries, which means every address in the binary was fixed at link time. Shared libraries were supported by maintaining a table of statically-assigned, non-overlapping address spaces, and at link time resolving external references to those fixed addresses.

Loading is faster and simpler when all you do is copy sections into memory then jump to the start address.

Shameless plug: Some of my hobby projects written in C (e.g. https://github.com/pts/bakefat) can be built reproducibly for Linux >=1.0 (1994), FreeBSD (same ELF executable program file as for Linux) and Win32 working on all versions of Windows (Windows NT 3.1 (1993)--Windows 11). The C compiler (running on Linux i386 and amd64 host) used for the release build is self-contained and included in the project, along with the libc.

Doing such backward compatibility is definitiely possible for command-line tools. Once set up, it's automatic, and it needs extra testing after major changes.

If a text-mode process monitor is larger than about 200 KiB, then it sounds bloated to me. If it's loaded with tons of features, then my upper limit is 1 MiB.

This video doesn't explain what the project does and how it does it. Also it's deliberately misleading the viewer, for example it purposefully incorrectly states that C++ is an interpreted language.

Also the music is way is too loud and sudden.

The video is a compliment to the Github repository, the presenter even shows code and brings up the repo in the video. I guess you didn't watch that part and unfortunately you didn't get the joke either.

Well the video is almost entirely a joke and almost every sentence in it is ironically false; that's the point.

This should have been solved in the last 30 years on Linux console, X terminal emulators and through SSH.

It's more of a "just in case" thing for the most part... the actual risk of an escape as part of a sequence showing up over TCP without the rest for over a fraction of a second today is highly unlikely. That said, so many systems seem to add a delay well over half a second like we're using dialup.

I'd probably tune the delay to 100-200ms if I ever really felt it and have the option to change it.

The kitty key protocol solves this, but your app and terminal need to support it. Many do.

The correct spelling is in lowercase: shared_ptr<T> . The title of the article is correct, the title of the HN post is incorrect.

In hindsight this convention seems weird to me by the way. I didn't question it for the decades I was paid money to write C, but after adopting Rust it jumped out more that it's weird how monocase the C and C++ standard libraries are.

Maybe there's a reason I'd never run into, but this seems like a missed opportunity. Even if I have no idea what Goose is, I can see it's a type, that seems like a win.

Yeah I don't know why so many C programmers ended up on a convention where case is entirely unused. I wonder if it's some ancient compatability thing that they have just been keeping self-consistent with forever. To me not using case is like designing a road map in black-and-white just because you didn't have any ideas for what colors should represent.

I believe HN does that automatically.

How is Areal different from Arial? Neither the article nor https://are.al.are.na/ seem to be informative and focused on this.

https://are.al.are.na/ does include some information on what they changed after tracing the original.

Might as well just quote the one single sentence that gives any specific details:

> Stem thicknesses were streamlined, more characters added, a monospace version drawn, dark mode functionality optimized.

I find this style overy verbose, disrepectful, offensive and dumb. (See example dialogue in the screenshot on the project page.) Fortunately, it's possible to change the prompt above.

I find it hilarious and it made my day.

Half of the source code is colored very-light-on-white, which is impossible to read. I'm using Chrome on Android.

Interesting, and thanks; that's not how it's supposed to look for sure. I'll ask someone to look at the whole mobile experience, definitely not my area.