Are you (or know) a blind programmer? What is your set-up? TTS or Braille? What OS do you use? IDE/editor? What limitations, annoyances or show-stopper issues have you encountered? Particularly interested if you use Rust, but happy to hear about the state of developer experience for blind programmers more generally.
The process is reasonably straightforward if you can figure out what an instruction actually does.
Combined with another open PR (not by me) we can now run most zlib-rs tests with miri on x86_64. We skip some tests that call out to C libraries, but miri now tests our cursed allocator shenanigans and simd implementations.
We have a serious amount of unsafe code, so this additional validation is crucial!
I've done it! After literal months of work, I've finally finished my (rather long) blog post about how AES-GCM works and how it's security guarantees can be completely broken when a nonce is reused:
It includes more than 10 interactive widgets for you to try out AES-GCM, GHASH and the nonce reuse attack right in your browser! (Powered by #RustLang and #WASM )
🎉 We have news: We've updated #Ferrocene to #RustLang 1.76.0 and you can now purchase your license online in our shop. @pietroalbini fills in the details over on the blog 👉
extremely excited that today is the day that the #RustLang PR from hell gets merged!
we had to fight performance issues, GitHub spectres, compiler bugs, flaky tests, and CI failures, but finally, we'll be able to have all the unchecked arithmetic functions checked in debug mode!
That’s often what #rustlang feels like. I started learning C in the late 80s and BASIC before that. Since then I’ve become an expert in several languages and proficient in several others. I’m an experienced #polyglot and though the rust compiler is by far the most helpful - and pushing other compilers to improve - there’s a lot of sharp edges in the grammar itself. Some other polyglots I’m getting into the language agree.
"#Rust development is going too fast (because they are stabilizing features I don't care about) and going too slow (because they are not stabilizing features I care about!"
There are only so many #RustLang contributors, hours in a day, days in a year to get to everything now, and some features are reliant on other, less flashy work that needs to happen before they can be even attempted.
But people are putting in a lot of work, the codebase changes so quickly that it is hard to keep up.
It's fascinating to me looking at beginning language guides and thinking "what does this say about the culture of the language"
When I was delving into #OCaml it was (with affection) "here's hello world and here's a dense academic paper on implementing event systems in OCaml 5!"
#Java guides used to be centered on the assumption that you were a web programmer looking to do applets, even long after that assumption died.
#RustLang generally seems to assume a background in programming w/ a CLI.
I'll certainly have more observations as I dig more into The Rust Book and Rust by Example on #RustLang, but it is interesting to me to see the baked in assumption that you are pretty comfortable with concepts like package management (I mean Rust By Example talks about creating a library before it talks about using a library and The Rust Book is similar, glossing over nuances here), CLI tools, and build tools.
To be clear, this is all fine, it is just informing me who the target audience is.
I've been helping to investigate a few LLVM and Rust bugs recently, and I keep running into pet peeves with how these bugs are reported, so I'm going to put together some #RulesForBugFiling
I don't want to discourage anyone from filing a bug, please do! But... be aware with how you represent the issue that you're seeing.
I also know that there are folks on here who are vastly more knowledgeable than I am, so feel free to suggest corrections, perhaps by filing some sort of report...
If you're going to claim something is a security issue, please explain what the attacker has gained by exploiting the bug. That is, what they can now do they couldn't before.
The more specific you can be on when a regression occurred, the better. A range of versions is good, a single version is great, a single commit is amazing.
Tools like git bisect are really helpful for this.
Providing a standalone example that reproduces the issue so that someone else can do that work is also great, with the bonus that it can be added to the regression tests.
This was tried a couple of years ago, but there some issues with mingw - so kudos to the folks that investigated and fixed those (sorry that I don't have links)!
Next step, the MSVC builders, which will require bumping the version of Clang that's used to build LLVM first...