Skip to content

Instantly share code, notes, and snippets.

🐕
Such programming

Hadrien G. HadrienG2

🐕
Such programming
Block or report user

Report or block HadrienG2

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
View udeps.md

Announcing cargo-udeps

One of the biggest issues that most people have with Rust are the long compile times. One of the reasons why compile times are so long is because many projects use quite a few dependencies from crates.io. Your dependencies have dependencies of their own, and they in turn have dependencies as well, and so on. This results in really big graphs of crates that all have to be compiled by cargo. Sometimes however, a crate actually doesn't use anything of some of its dependencies. Then those dependencies can be removed, resulting in faster builds for that crate. But how do you detect them? Often they sit in Cargo.toml for a long time until someone discovers they are actually unused and removes them (example). This is where cargo-udeps comes in. cargo-udeps is an automated tool to find dependencies that were specified in Cargo.toml but never used in the cra

@Matthias247
Matthias247 / async_await_cancellation.md
Created May 28, 2019
Async/Await - The challenges besides syntax - Cancellation
View async_await_cancellation.md

Async/Await - The challenges besides syntax - Cancellation

This is the second article in a series of articles around Rusts new async/await feature. The first article about interfaces can be found here.

In this part of the series we want to a look at a mechanism which behaves very different in Rust than in all other languages which feature async/await support. This mechanism is Cancellation.

View avx_sigh.md

why doesn't radfft support AVX on PC?

So there's two separate issues here: using instructions added in AVX and using 256-bit wide vectors. The former turns out to be much easier than the latter for our use case.

Problem number 1 was that you positively need to put AVX code in a separate file with different compiler settings (/arch:AVX for VC++, -mavx for GCC/Clang) that make all SSE code emitted also use VEX encoding, and at the time radfft was written there was no way in CDep to set compiler flags for just one file, just for the overall build.

[There's the GCC "target" annotations on individual funcs, which in principle fix this, but I ran into nasty problems with this for several compiler versions, and VC++ has no equivalent, so we're not currently using that and just sticking with different compilation units.]

The other issue is to do with CPU power management.

@csherratt
csherratt / ui.md
Last active Jun 29, 2019
Flora's Rust UI ramblings
View ui.md

Rust UI Difficulties

I wanted to give a little bit of a discussion on all my thinking about why UI's are a tricky to get right in Rust. I want to try and differentiate this discussion because there are a number of decent UI frameworks that have been bound to Rust. This is great! I do not want to discourage any of their work, they are wonderful members of our community.

What this is about is how it would be possible to write a good UI framework

You can’t perform that action at this time.