The Rust async working group is currently actively discusing on ways to improve async/await. Niko Matsakis documented the main goals and ideas in the async vision document.
As part of the improved async ecosytem, users should be able to make use of
all: gifread gifread.asan gifread.ubsan gifread.coverage | |
gifread: gifdec.c gifread.c gifdec.h | |
$(CC) $(CFLAGS) -o $@ gifdec.c gifread.c $(LDFLAGS) | |
gifread.asan: gifdec.c gifread.c gifdec.h | |
$(CC) $(CFLAGS) -g -fsanitize=address -o $@ gifdec.c gifread.c $(LDFLAGS) | |
gifread.ubsan: gifdec.c gifread.c gifdec.h | |
$(CC) $(CFLAGS) -g -fsanitize=undefined -o $@ gifdec.c gifread.c $(LDFLAGS) |
// A nano dependent type-checker featuring inductive types via self encodings. | |
// All computation rules are justified by interaction combinator semantics, | |
// resulting in major simplifications and improvements over old Kind-Core. | |
// Specifically, computable annotations (ANNs) and their counterpart (ANN | |
// binders) and a new self encoding based on equality (rather than dependent | |
// motives) greatly reduce code size. A more complete file, including | |
// superpositions (for optimal unification) is available on the | |
// Interaction-Type-Theory repository. | |
// Credits also to Franchu and T6 for insights. |
The Rust async working group is currently actively discusing on ways to improve async/await. Niko Matsakis documented the main goals and ideas in the async vision document.
As part of the improved async ecosytem, users should be able to make use of
Base C++ class cppbase.cpp
#pragma once
#include <stdio.h>
struct CppBase {
virtual void baseMethod(int arg) {
printf("arg from nim - %d -\n", arg);
pragma solidity ^0.5.15; | |
contract BLS { | |
// Field order | |
uint256 constant N = 21888242871839275222246405745257275088696311157297823662689037894645226208583; | |
// Negated genarator of G2 | |
uint256 constant nG2x1 = 11559732032986387107991004021392285783925812861821192530917403151452391805634; | |
uint256 constant nG2x0 = 10857046999023057135944570762232829481370756359578518086990519993285655852781; | |
uint256 constant nG2y1 = 17805874995975841540914202342111839520379459829704422454583296818431106115052; |
# nim c -r --threads:on --gc:orc | |
import cpuinfo, os, random, locks, deques | |
type | |
WorkReq = ref object | |
id: int | |
WorkRes = ref object | |
id: int |
import math, random | |
proc gauss(mu = 0.0, sigma = 1.0): float = | |
var | |
s = 0.0 | |
u = 0.0 | |
v = 0.0 | |
while s > 1 or s == 0: | |
u = 2.0 * rand(1.0) - 1.0 | |
v = 2.0 * rand(1.0) - 1.0 |
// To compile | |
// gcc -g -o pthread_cond_repro ./pthread_cond_repro.c -lpthread | |
#include <pthread.h> | |
#include <stdio.h> | |
#include <stdlib.h> | |
#include <stdint.h> | |
#include <unistd.h> | |
#include <assert.h> |
“Don’t move to that London” warned my northern grandfather once. “It’s full of spivs”.
The Oxford Dictionary (somewhat chauvinistically) defines a spiv as:
A man, typically a flashy dresser, who makes a living by disreputable dealings
“But I work in IT” I told him. “engineers aren’t like that”.
@Shnatsel wrote...
The following code is unsound:
This uses Rc::as_ref()
to obtain a reference to the underlying data, which does not guarantee uniqueness. It is possible to obtain several mutable references to the same memory location by calling this function repeatedly:
let mycell = Cell::new(vec![1,2,3]);