I've used LEB128 (with canonicalisation) extensively and... this looks so much nicer for most use-cases (length prefixed, supports the full uint64 range without that extra 10th byte).
The downside is the encoding size. LEB128 quickly grows to 2 bytes, but stays at 2 bytes all the way to 2^14. This is important if you're using these numbers as tags/identifiers as we were in the multicodec [1] project, or for network message lengths. bijou64 only gives you 500 <= 2 byte numbers.
> I’ve used LEB128 (with canonicalisation) extensively and... this looks so much nicer for most use-cases (length prefixed, supports the full uint64 range without that extra 10th byte)
If you only want to encode uint64 numbers LEB128 could easily be tweaked to fit in 9 bytes in several ways:
- using the offset trick described in this article would remove non-unique encodings (0x80 0x00 would encode 128)
- never allowing encodings longer than 9 bytes would mean the MSB of any ninth byte would always be zero, so you could reuse that, and store 8 bits in any ninth byte, for a total of 7 bits in each of the first eight bytes plus 8 in the ninth = 64
Both tweaks would lose LEB128’s property that you can find where each number starts from any byte in the stream, but the encoding discussed here doesn’t have that property either.
I keep trying it (coming from EXWM) but I get lots of lag, stutters, and poor fractional scaling. I'm not sure how much of that is "GTK under wayland", Emacs's PGTK build (known to have lag/rendering issues), AMD kernel drivers (?), or EWM itself; but it's not yet a replacement for EXWM in my experience.
Lagging is super annoying, and regretfully it comes mostly from very slow pgtk cairo implementation.
I'm getting the Skia branch to a usable shape this week. A bit too early to say, but the approach looks promising. Running it for almost a week with a 4k 120hz external monitor, no issues noticed so far.
Have you tried enabling MTP? Those numbers are similar to what I was getting on my Strix Halo box, but configuring/enabling MTP doubled the TG speed of the 27B model (18-20 t/s now).
Thanks - I’m in the process. I’ve tried briefly, but so far it appears marginally slower. (Noting that llama-bench doesn’t support MTP yet so you’re reduced to running different prompts and eyeballing the log.)
So I’m assuming I’ve done something wrong along the way, but I’ve not had time yet to explore it.
Features like the magic cursor look cool: an infinitely flexible context menu. However, context menus make it clear what you can and cannot do. If the magic cursor can't "do everything reasonable", it'll be just as usable as Siri.
I'd be more likely to believe them if they had already implemented this feature on their Pixel phones, but they haven't so I expect it probably isn't "done".
Nix and Lix daemon implementations are affected by buffer overflows vulnerabilities that allow a local attacker to gain arbitrary code execution as the daemon user (root in multi-user installations).
This seems like a very reasonable system to ensure e.g. you and your classmate/friends can still interact as you grow up and switch age brackets. I wonder how families etc deal with it though? Can you play with your younger sibling/cousin? Is there some sort of parental approval/override?
Box<str> is still two words (length and pointer). That's better than the 3 words (length, pointer, capacity) for strings, but Box<String> is one word (not including the heap allocation).
I've actually spent some time debugging why git causes so many issues with the backup software I use (restic).
Ironically, I believe you have it backwards: pack files, git's solution to the "too many tiny files" problem, are the issue here; not the tiny files themselves.
In my experience, incremental backup software works best with many small files that never change. Scanning is usually just a matter of checking modification times and moving on. This isn't fast, but it's fast enough for backups and can be optimized by monitoring for file changes in a long-running daemon.
However, lots of mostly identical files ARE an issue for filesystems as they tend to waste a lot of space. Git solves this issue by packing these small objects into larger pack files, then compressing them.
Unfortunately, it's those pack files that cause issues for backup software: any time git "garbage collects" and creates new pack files, it ends up deleting and creating a bunch of large files filled with what looks like random data (due to compression). Constantly creating/deleting large files filled with random data wreaks havoc on incremental/deduplicating backup systems.
My experience is that Emacs wants to be your everything, and works best if you let it. Have you tried putting your terminals inside of Emacs instead of the other way around?
The downside is the encoding size. LEB128 quickly grows to 2 bytes, but stays at 2 bytes all the way to 2^14. This is important if you're using these numbers as tags/identifiers as we were in the multicodec [1] project, or for network message lengths. bijou64 only gives you 500 <= 2 byte numbers.
[1]: https://github.com/multiformats/multicodec
reply