asb

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.

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

https://muxup.com/pwr

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).

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.

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.

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

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

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.

Firstly, as you probably know the Clang/LLVM model is quite different to gcc/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 I think.

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.

I keep meaning to post more, but it's hard to find time. RISC-V, LLVM, and a few other things.

    h3 {
      font-size:2.074rem
    }