asb

The fine-grained tokens have some surprising permissions for "read only" https://github.com/orgs/community/discussions/180063

Even better (IMHO!) is `git config branch.sort -committerdate` (note the `-`). This will sort newest committer date first.

Here's my notes on the device from last year with various setup tips https://muxup.com/2025q2/chuwi-minibook-x-n150

I can't say I agree with the author's assessment of the keyboard in this submission. I find it more pleasant to use than the other laptops I have access to.

Beware the license. They misleadingly state on the blog post "Open-weight — Download, fine-tune, and deploy without restrictions". But if you read their license <https://huggingface.co/LiquidAI/LFM2.5-8B-A1B/blob/main/LICE...> it has significant restrictions for any org with other $10M in revenue.

The situation is very confusing, but the tweet that went out with the announcement indicates it's not full 131k context yet and that is coming "soon"https://xcancel.com/CerebrasSystems/status/19437653011094202...

Note the announcement at the end, that they're moving away from the non-commercial only license used in some of their models in favour of Apache:

We’re renewing our commitment to using Apache 2.0 license for our general purpose models, as we progressively move away from MRL-licensed models

I think this is a really interesting area. I wrote a command line took for web reading with some similar motivations. In my case, you queue up the articles to read the next day.

https://muxup.com/pwr

If you're playing on the Steam Deck, mapping 'touch' on the left and right trackpads to the left and right bongo, and a touch on either joystick (they have capacitive touch) as a clap works rather well.

Oh that's interesting, I wonder what's different about your SVG favicon vs mine.

I used this trick for a quick favicon on my site https://muxup.com/ - though unfortunately Google/Bing/DuckDuckGo doesn't like svg favicons and so it's not displayed in search results. I should really add a proper favicon...

I think they should probably set LoopMicroOpBufferSize to a non-zero value even if its not microarchitecturally accurate. This value is used in LLVM to control whether partial and runtime loop unrolling are enabled (actually only for that). Although some targets override this default behaviour, AArch64 only overrides it to enable partial and runtime unrolling for in-order models. I've left a review comment https://github.com/llvm/llvm-project/pull/91022/files#r16026... and as I note there, the setting seems to have become very divorced from microarchitectural reality if you look at how and why different scheduling models set it in-tree (e.g. all the Neoverse cores, set it to 16 with a comment they just copied it from the A57).

I somehow hadn't come across this library, but have a whole blog post on the various ways people store data in pointers (and when+why it's safe) https://muxup.com/2023q4/storing-data-in-pointers

Yes that's what I meant. Just an assumption I'd had, perhaps the joking about Emacs vs Vim preference in programmers made me assume the groups were of similar size.

One source of stats is the 2023 Annual Rust Survey. The question on text editors allowed multiple responses (so percentages naturally don't add up to 100%), but 5.5% of respondents reported using Emacs for Rust vs ~30% for Vim/Neovim, vs ~61% for VS Code. I was shocked that Emacs and Vim weren't closer.

Obviously, it's possible this is a quirk of the Rust community. Though the Go survey shows similarly small Emacs usage numbers https://go.dev/blog/survey2023-h2-results (3% Emacs vs 16% Vim/Neovim).

(Article author here). I'm typically executing the same compile command from shell history (or via an alias) so missing off the `'; bell` isn't really a concern, but I agree that automatically triggering it after commands of a certain duration is a nicer way of avoiding that mental overhead if you're executing a wider variety of commands.

On https://muxup.com/ you should see pastel-coloured randomly drawn 'roguh' highlights for the site title and for the titles of individual articles. If you mouse over, they'll be redrawn while your mouse is hovering. If you're on mobile, you won't see that, and that's fine. It worked just fine on Android (FF or Chrome) and iPhone last time I checked, but do let me know if you're not seeing that.

It's really very simple, just thought the distillation of the 'rough' drawing technique to a couple of dozen lines of code for this use case might be of interest to some.

Yes, redrawing on hover was a desired effect - sorry if you find it offputting.

Also see RoughNotation <https://roughnotation.com/>, which uses RoughJS to support underlines, highlights etc.

I took some inspiration for my website (mouse over any highlighted title) <https://muxup.com/>. The write-up here aims to summarise how it works https://muxup.com/2022q3/muxup-implementation-notes#randomly... - if you click through you'll see it's really very little code.

Thanks for pointing that out - definitely a better choice for C++.

LLVM has a LoopIdiomRecognize pass which will, amongst other patterns, try to detect a loop implementing popcount [1] and convert it to the llvm.ctpop.* intrinsic [2]. I've not looked at why it's not matching this loop, but the sibling comment suggesting to just use `.count_ones` seems like the right answer for Rust. In C or C++ I'd strongly recommend using `__builtin_popcount` (provided by both Clang and GCC).

[1]: https://github.com/llvm/llvm-project/blob/08a6968127f04a40d7... [2]: https://llvm.org/docs/LangRef.html#llvm-ctpop-intrinsic

I've tweaked the wording - thanks again!

Article author here. Thanks for calling that out - the intent wasn't to make readers who might not have been aware feel bad. It really came from my worry about being seen to write about something that is trivial and everyone knows already!

Perhaps I'd be better just dropping "I think it's quite well known that"?

Do you have a reference on that? This summary of the Alpha AXP <https://danluu.com/dick-sites-alpha-axp-architecture.pdf> states "Normal load or store instructions that specify an unaligned address take a precise data alignment trap to PALcode (which may do the access using two aligned accesses or report a fatal error, depending on the operating system design)"

> Here’s the reality of the matter, though: whether or not you agree with the Sutskever/Shear tribe, the board’s charter and responsibility is not to make money. This is not a for-profit corporation with a fiduciary duty to its shareholders; [...] to the extent the board believes that Altman and his tribe were not “build[ing] general-purpose artificial intelligence that benefits humanity” it is empowered to fire him; they do, and so they did.

I would quibble with this slightly. They do have a right to fire, but they're doing a poor job of working in the not-for-profit's interests if they do so in a way that collapses the value of their biggest asset (the for-profit), especially when other options are potentially available. e.g. a negotiated exit, providing proper warning to their investors etc etc.

99.9% of my clang invocations are from the build dir of the git tree I'm working on, so I could be missing something known to others on the distribution side - but let me try my best answer.

Firstly, as you probably know the Clang/LLVM model is quite different to binutils in terms of build-time configuration. Any clang can target any architecture (unless it was disabled at build time) using --target=$TRIPLE (see <https://clang.llvm.org/docs/CrossCompilation.html#target-tri...>). In practice it's not as useful as it sounds of course because you need appropriate sysroots. You can control the default with LLVM_DEFAULT_TARGET_TRIPLE, but without patching clang it's going to enabled compressed for the riscv64-unknown-linux-gnu triple. I think the standard way of controlling other default flags would be to deploy a configuration file <https://clang.llvm.org/docs/UsersManual.html#configuration-f...> - though I'd need to check which logic took precedent if you explicitly passed --target=riscv64-unknown-linux-gnu. Ultimately we'd need to change the meaning of the current linux triples, or decide upon new ones.

Thanks for sharing that doc - really helpful. I don't know if it's different with GNU as, but not that if a file contains `.option rvc` that _isn't_ sufficient to set the EF_RISCV_RVC ELF flag with LLVM. Additionally, I'd imagine in general that people using .option in inline asm may see different behaviour for Clang vs GCC. Clang doesn't generate assembly output that then gets passed to the assembly - ELF emission happens directly (of course, with the assembler being invoked as needed for inline asm blocks), and so it's rather difficult to replicate the effect you'd see with GCC generating a .s file that's then assembled.

You could certainly change the default `-march` to rv64g (plus whatever extensions you want) rather than rv64gc. That provides mostly what you'd want, though there's some small chance that inline asm or hand-written assembly using `.option rvc` or `.option arch, +c` inappropriately causes issues. I just posted some thoughts on this here: https://lists.riscv.org/g/tech-profiles/message/348