218 results for "":
Pin and suffering
Disclaimer:
async fn in trait has shipped in Rust 1.75, about 2.5 years after
this article was written.
I’d like to think that my understanding of “async Rust” has increased over the past year or so. I’m 100% onboard with the basic principle: I would like to handle thousands of concurrent tasks using a handful of threads. That sounds great!
Day 2 (Advent of Code 2020)
Day 2, Day 2! Woo!
The Advent of Code 2020, Day 2 problem talks about passwords. Sounds familiar.
Basically, our input looks like this:
1-3 a: abcde
1-3 b: cdefg
2-9 c: ccccccccc
Each line contains a “password policy” and a “password”. For the first line, the policy is that the password must contain between 1 and 3 (inclusive) times the letter “a”.
Dynamic symbol resolution
Cleaning up and upgrading third-party crates
The bleeding edge of rustc and clippy
Typically, you’d want a production application to use a stable version of Rust. At the time of this writing, that’s Rust 1.65.0, which stabilizes a bunch of long-awaited features (GATs, let-else, MIR inlining, split debug info, etc.).
For every Rust release, Mara makes a wonderful recap thread on Twitter, on top of the official announcement.
Getting in and out of trouble with Rust futures
I started experimenting with asynchronous Rust code back when futures 0.1
was all we had - before async/await. I was a Rust baby then (I’m at least
a toddler now), so I quickly drowned in a sea of .and_then, .map_err
and Either<A, B>.
But that’s all in the past! I guess!
Now everything is fine, and things go smoothly. For the most part. But even
with async/await, there are still some cases where the compiler diagnostics are,
just, so much.
Cross-compilation notes
I’ll keep updating this article as I go, just to put stuff in all the same place.
Platforms
Cross-compiling for Linux
I’m pretty sure it’s possible to cross-compile for Linux on other OSes, seeing as everything is open-source, but I have never done it - and why would I want to? Linux is the friendliest to build on, so it’s better to use it as a build environment.
Running an executable without exec
In part 1, we’ve looked at three executables:
sample, an assembly program that prints “hi there” using thewritesystem call.entry_point, a C program that prints the address ofmainusingprintf- The
/bin/trueexecutable, probably also a C program (because it’s part of GNU coreutils), and which just exits with code 0.
We noticed that when running entry_point through GDB, it always printed the
same address. But when we ran it directly, it printed a different address on
every run.
rock 0.9.6 is on the loose!
Just 8 days after the last release, rock 0.9.6 is out.
To update, run git pull && make rescue as usual. To install from scratch,
clone the repo, cd into it, and run make rescue from there - it’ll download the latest bootstrap, compile itself from
C, then recompile itself from ooc.
Running rock -V should give you something like this:
rock 0.9.6 codename loki, built on Wed Feb 20 15:09:08 2013
FFI-safe types in Rust, newtypes and MaybeUninit
Building poppler for Windows
I know what you’re thinking: haven’t we strayed from the whole “content pipeline” theme in this series?
Well… fair. But compiling and distributing software is part of software engineering, and unless you’re in specific circles, I see that taught a lot less than the “just write code and stuff happens” part.
Technically it’s release engineering, but who’s keeping track.