| <!DOCTYPE html> | |
| <html lang="en"> | |
| <head> | |
| <meta charset="UTF-8" /> | |
| <meta name="viewport" content="width=device-width, initial-scale=1.0" /> | |
| <title>Document</title> | |
| </head> | |
| <body> | |
| <div id="app"></div> | |
| <script type="module"> |
| ## ------------------------------------------------------------------------------------------------ | |
| # Schema published automatically on the website. This allows TOML language | |
| # servers to autocomplete and show documentation for the entries below. | |
| # | |
| # I use the prerelease version as my builds on my machines are often from trunk. | |
| "$schema" = "https://jj-vcs.github.io/jj/prerelease/config-schema.json" | |
| ## ------------------------------------------------------------------------------------------------ | |
| ## ---- Basic settings |
This is inspired by https://fasterthanli.me/blog/2020/a-half-hour-to-learn-rust/
the command zig run my_code.zig will compile and immediately run your Zig
program. Each of these cells contains a zig program that you can try to run
(some of them contain compile-time errors that you can comment out to play
with)
Update
RPi4 now supports booting directly from USB. First update to get an eeprom which supports USB Boot, then configure the bootloader to boot from USB.
Original guide
- Download Raspbian from the official site
Download the latest ugw3 package from https://github.com/Lochnair/vyatta-wireguard/releases and install it on your USG using dpkg -i wireguard-ugw3-<version>.deb.
cd /config/auth
umask 077
mkdir wireguard
cd wireguard
wg genkey > wg_private.key
wg pubkey < wg_private.key > wg_public.keyReact recently introduced an experimental profiler API. This page gives instructions on how to use this API in a production release of your app.
Table of Contents
React DOM automatically supports profiling in development mode for v16.5+, but since profiling adds some small additional overhead it is opt-in for production mode. This gist explains how to opt-in.
| // cc -g2 example_journal_reader.c -lsystemd | |
| #include <stdio.h> | |
| #include <time.h> | |
| #include <errno.h> | |
| #include <sys/poll.h> | |
| #include <stdlib.h> | |
| #include <string.h> | |
| #include <assert.h> | |
| #include <systemd/sd-journal.h> |
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