ZhangHanDong

use std::fs::File;
use std::io::prelude::*;
use std::mem;

fn layernorm_forward(output: &mut [f32], mean: &mut [f32], rstd: &mut [f32],
                      input: &[f32], weight: &[f32], bias: &[f32],
                      batch_size: usize, time_steps: usize, channels: usize) {
    let epsilon = 1e-5;
    for b in 0..batch_size {
        for t in 0..time_steps {

ZhangHanDong

#![allow(unused)]
use std::marker::PhantomData;

/// Our beloved house
#[derive(Debug)]
struct House {
    floors: u32,
    rooms: u32,
    has_garage: bool,
}

ZhangHanDong

note: I wrote this for our internal documentation & guidelines at Embark so not all of it is likely relevant for other companies, but sharing here as others expressed interest in seeing it

---

What to evaluate and consider before adding usage of new third-party crates.

These are not exact requirements but questions to investigate and discuss to help reason around the health, safety, maintainability, and more around crates.

This can also be read as an opinionated guide for crate authors of what our (Embark's) guidelines and recommendations are, though should not be taken too literally.

ZhangHanDong

// This is a technique to emulate lifetime GATs (generic associated types) on stable rust starting
// with rustc 1.33.
//
// I haven't seen this exact technique before, but I would be surprised if no one else came up with
// it. I think this avoids most downsides of other lifetime GAT workarounds I've seen.
//
// In particular, neither implementing nor using traits with emulated lifetime GATs requires adding
// any helper items. Only defining the trait requires a single helper trait (+ a single helper impl
// for the 2nd variant) per GAT. This also makes the technique viable without any boilerplate
// reducing macros.

ZhangHanDong

mod jit {
    use libc::{c_void, dlclose, dlopen, dlsym, RTLD_NOW};
    use std::ffi::CString;
    use std::fs::File;
    use std::io::prelude::*;
    use std::io::SeekFrom;
    use std::process::Command;

    const SOURCE_PATH: &'static str = "/tmp/jit.rs";
    const LIB_PATH: &'static str = "/tmp/librsjit.so";

ZhangHanDong

// these aren't _quite_ functional tests,
// and should all be compile_fail,
// but may be illustrative

#[test]
fn concurrent_set() {
    use std::sync::Arc;
    let x = Arc::new(Cell::new(42));
    let x1 = Arc::clone(&x);
    std::thread::spawn(move || {

ZhangHanDong

#![no_std]
#![no_main]
#![feature(asm)]

#[panic_handler]
fn panic(_info: &core::panic::PanicInfo) -> ! {
    loop {}
}

#[no_mangle]

ZhangHanDong

#![feature(core_intrinsics)]

// This requires unstable features to compile so we can print out the type names.  The type
// arithmetic itself works fine on stable.

use std::marker::PhantomData;

enum Zero {}
enum Succ<T> {
    Succ(PhantomData<T>), // only required to satisfy the compiler

ZhangHanDong

Follow-up to Method on Emulating Higher-Kinded Types (HKTs) in Rust

First off, thanks for all the comments and kind words on the original writeup; I've been meaning to follow up on some of the suggestions and write about the different ways to represent monads (and functors, HKTs, etc) that now exist, but a month of being busy has kind of gotten in the way (mainly with three new kittens!).

And for sure, I do not expect (nor do I want) this to become the norm for production-level Rust: rather, I hope that this can contribute to the foundations of programming with higher-level abstractions in Rust, somewhat like how early template metaprogramming in C++ and typeclass-constraint-unification metaprogramming in Haskell have contributed, perhaps indirectly, to later innovations in their respective languages and ecosystems that were much more reasoned, sound and usable.

Changes, Edits, Refinements

One of the things suggested in the com

ZhangHanDong

Rust in Large Organizations

Initially taken by Niko Matsakis and lightly edited by Ryan Levick

Agenda

• Introductions
• Cargo inside large build systems
• FFI
• Foundations and financial support