| # Create an API KEY there: https://pushover.net/apps/build | |
| # Find your user TOKEN here: https://pushover.net | |
| # | |
| # Note that the `title` field is optional and don't forget to put double quotes | |
| # around your argument when calling this function. | |
| # | |
| # Here is a small example of pipping logs through pushover: | |
| # | |
| # nohup tail -f nohup.out | while read l; do pushover "$l"; done & | |
| # |
| #!/bin/bash | |
| #author: [email protected] | |
| #ffmpeg command from : https://gist.github.com/kurlov/32cbe841ea9d2b299e15297e54ae8971 | |
| NOCOLOR='\033[0m'; | |
| RED='\033[0;31m'; | |
| GREEN='\033[0;32m'; | |
| [ -d added ] || mkdir added |
| #!/usr/bin/env bash | |
| # usage: memlog.sh $(pidof PROCESS_NAME) [ PATH_FOLDER ] | |
| # on osx pidof can be replaced by pgrep | |
| # usage: memlog.sh $(pgrep PROCESS_NAME) [ PATH_FOLDER ] | |
| set -e | |
| PID=$1 |
4 years after
after the release of Rust 1.0, it seems like Rust is now finally getting close
to getting support for async/await - a language feature which aims to make it
easier to write programs in an asynchronous fashion (where multiple logical
tasks get multiplexed on a lower number of OS threads).
One of the last steps before the feature is stabilized is choosing the best possible syntax. The discussions around syntax have triggered an enormous
| // works as of 2019-03-02 | |
| (function() { | |
| // This function forces rustdoc to collapse documentation for all items, | |
| // except for the methods defined in an impl block and the primary type's | |
| // declaration. This is the most natural view IMO, since it provides the | |
| // primary type along with an easy to scan overview of available methods. | |
| // | |
| // rustdoc does seemingly have user settings that purport to make this the | |
| // default, but I could never cause them to work in a reliably consistent | |
| // way. This is especially useful when writing documents, where you commonly |
Custom format for displaying bytes as kb, mb, gb or tb.
Response to a few places on the internet: https://productforums.google.com/forum/#!topic/docs/x_T_N-yRUYg And here: https://stackoverflow.com/questions/1533811/how-can-i-format-bytes-a-cell-in-excel-as-kb-mb-gb-etc
Here is one that I have been using:
[<1000000]0.00," KB";[<1000000000]0.00,," MB";0.00,,," GB"
Coding practices are a source of a lot of arguments among programmers. Coding standards, to some degree, help us to put certain questions to bed and resolve stylistic debates. No coding standard makes everyone happy. (And even their existence is sure to make some unhappy.) What follows are the standards we put together on the Core team, which have become the general coding standard for all programming teams on new code development. We’ve tried to balance the need for creating a common, recognizable and readable code base with not unduly burdening the programmer with minor code formatting concerns.
| #!/bin/sh | |
| # This env variable is here to permit | |
| # to use a custom `cargo bench` command if needed | |
| CARGO_BENCH_CMD=${CARGO_BENCH_CMD:-cargo bench} | |
| if [ $# -eq 0 ]; then | |
| echo "comparing benchmarks of HEAD~1 and HEAD..." | |
| OLD=$(git rev-parse --short 'HEAD~1') | |
| NEW=$(git rev-parse --short 'HEAD') |
Let's take the first example from the Rust generators RFC:
#[async]
fn print_lines() -> io::Result<()> {
let addr = "127.0.0.1:8080".parse().unwrap();
let tcp = await!(TcpStream::connect(&addr))?;
...
}