I'm surprised that whatever IO primitive is used on Mac doesn't work on OpenBSD. Mac has select and some variant of kqueue, right? What is ghostty doing there that doesn't work on OpenBSD?
Might not be that different to add OpenBSD. Someone would begin here: https://github.com/mitchellh/libxev/blob/main/src/backend/kq...
It's about 1/3 tests and 2/3 mostly-designed-to-be-portable code. Some existing gaps for FreeBSD, but fixing those (and adding OpenBSD to some switch/enums) should get you most of the way there.
i know freebsd and macos have similar implementations, but it is just different enough that it is nontrivial to make work. i had started fixing it locally but didn't quite get it working, since i'm not really that familiar with zig, although i like the idea of the language.
my one gripe after using mc for a few years is no parallel transfer support. it slows down significantly when transferring small files compared to one large file.
That I agree with. In Total Commander I typically do F5 copy and then put it in the background F2. Then start another.
This isn't possible in MC. And also a concrete parallelization is not available. This sounds like a feasible feature request to the upstream MC project! I'm sure Gnu Parallel or just pure C code would be able to handle parallelization of copy jobs.
EDIT:
Wait! It does have background transfer now. Which means my technique of how I do it in Total Commander will work in MC now as well. It is almost like having Parallelization.
> All parts of Go's simplicity push that seems to assume people don't need anything else other than Array Lists and hash maps.
you can see some of this in the work of the progenitors of Go.
quoth pike style, from rob pike:
Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.
The following data structures are a complete list for almost all practical programs:
array
linked list
hash table
binary tree
Of course, you must also be prepared to collect these into compound data structures. For instance, a symbol table might be implemented as a hash table containing linked lists of arrays of characters.
I like that the author went very in depth reverse engineering the proprietary update program, but it boiled down to what amounts to a single or few ata commands that can be manually invoked on linux. it's a shame they don't just publish these commands for linux users, and let the windows users have the fancy bespoke tools.
for a long time I've actually really wanted the plumber [1] here but a more networked and cross platform protocol for it. I really just want to be able to plumb urls from my android phone to Linux desktop or vice versa and have it work according to the plumber rules.
The Rust compiler statically links everything into a single binary. This can be changed, but is generally discouraged as there are no ABI stability guarantees at this point.
You can use the C ABI if you want something stable, and there are custom crates that will help with translating from the Rust to the C ABI. (This also helps because the resulting shared objects can potentially be FFI'd with from any language, not just Rust. They might as well be plain C libraries as far as anyone is concerned, only with the usual Rust safety requirements.)
Also, even in "the" C ABI provided by Rust out of the box there's a certain amount of "Well, this is probably what your C compiler does here, but there's no requirement" rather than an actual hard ABI document. A lot of the "We're ABI stable" claims in C and C++ are "We daren't change anything or stuff breaks" which isn't so much an ABI as it is paralysis and Rust is confident it doesn't want to do that.
> "We're ABI stable" claims in C and C++ are "We daren't change anything or stuff breaks" which isn't so much an ABI as it is paralysis and Rust is confident it doesn't want to do that.
For C++, yes sure, but I thought C usually has a pretty well specified ABI on most platforms, no?
reply