(C-x means ctrl+x, M-x means alt+x)
The default prefix is C-b. If you (or your muscle memory) prefer C-a, you need to add this to ~/.tmux.conf
:
#include <stdio.h> | |
#include <stdint.h> | |
#include <stdlib.h> | |
#include <math.h> | |
#include <string> | |
#include <initializer_list> | |
#include <thread> | |
#include <chrono> |
class ColorComparator implements Comparator<Integer> { | |
private ColorEnumType color; | |
public ColorComparator(ColorEnumType color) { | |
this.color = color; | |
} | |
@Override | |
public int compare(Integer a, Integer b) { | |
int mask = 0xff; |
package spark.example | |
import org.apache.spark.SparkContext | |
import org.apache.spark.SparkContext._ | |
import org.apache.spark.SparkConf | |
object SparkGrep { | |
def main(args: Array[String]) { | |
if (args.length < 3) { | |
System.err.println("Usage: SparkGrep <host> <input_file> <match_term>") |
When parsing things like binary file format headers, you generally need to know three things for each data field:
Buf:0x<0b 00>
)Buf:0x<0b 00>
--> 11
)# Example makefile with some dummy rules | |
.PHONY: all | |
## Make ALL the things; this includes: building the target, testing it, and | |
## deploying to server. | |
all: test deploy | |
.PHONY: build | |
# No documentation; target will be omitted from help display | |
build: |
#include <time.h> // Robert Nystrom | |
#include <stdio.h> // @munificentbob | |
#include <stdlib.h> // for Ginny | |
#define r return // 2008-2019 | |
#define l(a, b, c, d) for (i y=a;y\ | |
<b; y++) for (int x = c; x < d; x++) | |
typedef int i;const i H=40;const i W | |
=80;i m[40][80];i g(i x){r rand()%x; | |
}void cave(i s){i w=g(10)+5;i h=g(6) | |
+3;i t=g(W-w-2)+1;i u=g(H-h-2)+1;l(u |
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