They don't play nicely with arena allocators. And arenas is what you reach for if you have clear lifetime bounds: e.g. a single request with arena never de-allocates individual objects, nukes arena when done. That gives you an easy verifiable protection against leaks, data (and cache) locality and deallocation that cost zero cpu cycles.
It's technically possible to perform arena-based allocation and still have compiler checks. The compiler just need to track objects allocated with an allocator and prevent destructing the allocator itself as long as there is at least one object using it.
It's like view span objects in rust. The compiler knowns that a span is logically connected to the parent object and don't allow destroying it when such span exists.
Have a boxed object have implemented drop, then when the box leaves some scope the Box will clean up it's stuff (drop implementation if there is any) and deallocate it's memory using the allocator (which the arena will treat as noop).
The internal string encoding of a programming language doesn't matter as long as it supports UTF-8 at the boundaries. E.g. the text encoding standard on the web is clearly UTF-8, even though JS strings may be internally stored as UTF-16 (or any other encoding).
Same on macOS/iOS btw: AFAIK NSString is internally UTF-16, but I've never seen a UTF-16 text file on macOS, it's all UTF-8 (unless the file originated on Windows of course).
The number of glyphs available by adding additional bytes drops exponentially because each subsequent byte has one less bit available.
So I think if we ever were in a situation where > 1 million code points isn’t enough, then we should look at an entirely new way to serialise those code points.
I don't quite get it. 5-byte utf-8 encoding gets extra 5 bits compared to 4 byte, and 6-byte gets extra 10 bits. If you were thinking about bits in leading byte, then yes, you are losing one bit for every extra trailing byte, but you also get 6 bits from it. So adding a byte gives you extra 5 bits.
It seems when designing Unicode most energy went into emoji. And there was nothing left for fancy things like fixed-length string buffers. The only explaination why UTF8 Buffers aren't compatible with UTF16 Buffers... is a really strong emoji...
in my .inputrc for years. I think, this is how command line worked in tcsh.
It changes unconditional prev/next to prefix search. With empty command line it is the same as the old behavior. But if you enter "ls" and then press up-arrow, it will scroll through all commands in history that have "ls" as a prefix. I use it much more often than C-r.
> Are you sure? According to wiki, there are plenty allowed 5GHz channels in Turkey.
Pretty, yeah. Doesn't the same wiki page list a bunch of not-allowed 5Ghz channels too? Or only allowed ones?
I didn't mean to claim it's completely banned, but some channels are, which leads to some hardware makers to just eschew the entire 5Ghz stuff instead of just specific channels, like what this submission is about.
Objects belonging to multiple double-linked lists at the same time. Easily done with intrusive lists. Safe rust would require Rc/Arc: penalty both on memory usage and cpu time.
The code is sloppy. They check existance of kdialog binary using full path; next step they rely on PATH search by shell. If would've been much safer to just do execve directly.
> There can be overload, but the backpressure should propagate downstream and senders and intermediaries should buffer locally if needed.
You're only delaying the inevitable. Even with local buffering, you can arrive at a point where you can buffer no more and have either to choke the production workload or start dropping messages.
I wouldn't call that "inevitable." Buffering exists for a reason--to buy you a bit of safety for short-lived busy periods (or, in the case of queues, delayed or temporarily failed consumers). It also amortizes the cost of I/O. Buffering isn't just for logging; it's all over the networking and I/O stacks.
reply