Now located at https://github.com/JeffPaine/beautiful_idiomatic_python.
Github gists don't support Pull Requests or any notifications, which made it impossible for me to maintain this (surprisingly popular) gist with fixes, respond to comments and so on. In the interest of maintaining the quality of this resource for others, I've moved it to a proper repo. Cheers!
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
A top-level App component returns <Button /> from its render() method.
What is the relationship between <Button /> and this in that Button’s render()?
Does rendering <Button><Icon /></Button> guarantee that an Icon mounts?
Can the App change anything in the Button output? What and how?
FWIW: I (@rondy) am not the creator of the content shared here, which is an excerpt from Edmond Lau's book. I simply copied and pasted it from another location and saved it as a personal note, before it gained popularity on news.ycombinator.com. Unfortunately, I cannot recall the exact origin of the original source, nor was I able to find the author's name, so I am can't provide the appropriate credits.
futures-rs is the library which will hopefully become a shared foundation for everything async in Rust. However it's already become renowned for having a steep learning curve, even for experienced Rustaceans.
I think one of the best ways to get comfortable with using a library is to look at how it works internally: often API design can seem bizarre or impenetrable and it's only when you put yourself in the shoes of the library author that you can really understand why it was designed that way.
In this post I'll try to put down on "paper" my understanding of how futures work and I'll aim to do it in a visual way. I'm going to assume you're already somewhat familiar with Rust and why futures are a useful tool to have at one's disposal.
For most of this post I'll be talking about how things work today (as of September 2017). At the end I'll touch on what's being proposed next and also make a case for some of the changes I'd like to see.
If you're interested in learning more ab
| #! /usr/sbin/nft -f | |
| chain tc-wan { | |
| # check default priority | |
| mark & 0xff0 == 0x130 ip dscp set af22 return | |
| # real-time application | |
| ## Dota2 | |
| udp dport 27000-27200 \ | |
| meta mark set mark & 0xfffff00f ^ 0x110 ip dscp set af41 return |
For typical use cases, I prefer using nvitop to view detailed information. This script offers a dependency-free implementation.
The script enhances the functionality of nvidia-smi and provides the following info:
Usernamefull process CommandGPU IDPIDThis is useful on multi-user servers and can be used to quickly identify which user is using the GPU and running what kind of program.
This content was presented at a sig-testing meeting on 8/25/2020, available as a video here