DEV Community: TakaakiFuruse

Tell me your job hunting jokes and funny stories

TakaakiFuruse — Mon, 05 Aug 2019 23:04:18 +0000

I was contacted by one of a head hunter, his name is John, via LinkedIn one day.

Since my pay wasn't so good (I was a bootcamp grad with no working experience as a dev), I was looking for a job with better pay.

I chatted with John on the phone and he had promised me to introduce some good positions he had at that time. Just after the first chat, my phone rung. That was John.

John: Hi, hello sir. I found a nice position for you. You might like it.

Me: Thank you!! What's the name of the company?

John: It's called MyBook.com, they're building a financial web service. You might know the name.

Me: I know the company. They are building an accounting system. Thanks for that, but I don't like accounting.

John: Oh, is it? OK. I will find another opportunity for you.

Me: Thanks for that.

John: See you.

Me: See you.

I just got back to work. Few hours later. I got another phone call. John again.

John: Hello sir! I found a good opportunity for you again.

Me: (So quick!!) Would you tell me the position?

John: Sure!! Their name is MyBook.com. They are building a financial web service. You'll like it.

This is a real story, not jokes, yes it's real......

(All the names are fake!!)

Rust ProcMacro 101

TakaakiFuruse — Sun, 04 Aug 2019 22:53:50 +0000

Intro

You know this works....

fn greetings(var: String) {
    println!("{}", var)
}

greetings("Valar Morghulis!".to_string());

You know also this never works ....
If it works. It's a magic.

fn greetings_generator(var1: String, var2: String) {
    fn var2(var: String){
     var1("{}", var)
   }
}

greeetings_generator(println!, greetings1)
greetings1("Valar Morghulis!".to_string!)

There's a way to make it work.
Use Rust macro.
Macro allows you to write Rust code as if you are dealing with function.

macro_rules! greetings_generator {
    ($var1:ident, $var2:ident) => {
        fn $var2(var: String) {
            $var1!("{}", var)
        }
    };
}

greetings_generator!(print, greetings2);
greetings2("Valar Morghulis from greeting2\n".to_string());

greetings_generator!(println, greetings3);
greetings3("Valar Morghulis from greeting3".to_string());

Code on Rust Playground

Normal Approach

Now, let's order our Seven Gods whatever you want.

#[derive(Debug)]
pub enum Gods {
    Father,
    Mother,
    Maiden,
    Crone,
    Warrior,
    Smith,
    Stranger,
}

fn my_gods_order(god:&Gods) -> u32{
    match god {
        Gods::Father => 1,
        Gods::Mother => 2,
        Gods::Maiden => 3,
        Gods::Crone => 4,
        Gods::Warrior => 5,
        Gods::Smith => 6,
        Gods::Stranger => 7,
    }
}

fn your_gods_order(god:&Gods) -> u32{
    match god {
        Gods::Father => 7,
        Gods::Mother => 6,
        Gods::Maiden => 5,
        Gods::Crone => 4,
        Gods::Warrior => 3,
        Gods::Smith => 2,
        Gods::Stranger => 1,
    }
}


fn main() {
    let mut gods = vec![Gods::Stranger, Gods::Father, Gods::Mother];
    gods.sort_by(|a, b| my_gods_order(a).partial_cmp(&my_gods_order(b)).unwrap());
    println!("{:?}", gods);

    let mut gods = vec![Gods::Smith, Gods::Crone, Gods::Stranger];
    gods.sort_by(|a, b| your_gods_order(a).partial_cmp(&your_gods_order(b)).unwrap());
    println!("{:?}", gods);

}

Use Macro

The more you have orders, you'll get the more and more match statemtns...
It works, but really annoying...

What you do....?

Macro...

That's Better...

macro_rules! gods_order1 {
    ($a:ident, $b:ident,  $c:ident) => {
        fn my_gods_order1(var: &Gods) -> u32 {
            match var {
                Gods::$a => 1,
                Gods::$b => 2,
                Gods::$c => 3,
                _ => 100,
            }
        }
    };
}

fn main() {
    gods_order1!(my_gods_order1, Stranger, Father, Mother);
    let mut gods = vec![Gods::Mother, Gods::Father, Gods::Stranger];
    gods.sort_by(|a, b| my_gods_order1(a).partial_cmp(&my_gods_order1(&b)).unwrap());
    println!("{:?}", gods);

    gods_order1!(your_gods_order1, Mother, Father, Stranger);
    let mut gods = vec![Gods::Mother, Gods::Father, Gods::Stranger];
    gods.sort_by(|a, b| your_gods_order1(a).partial_cmp(&your_gods_order1(&b)).unwrap());
    println!("{:?}", gods);

}

Even better...

macro_rules! gods_order2 {
    ($func:ident, [$(($elm:tt, $i:expr)),*]) => {
        fn $func(var: &Gods) -> u32 {
            match var {
                $(Gods::$elm => $i,)*
                _ => 0,
            }
        }
    };
}

fn main() {

    gods_order2!(my_gods_order2, [(Stranger, 3), (Father, 2), (Mother, 1)]);
    let mut gods = vec![Gods::Mother, Gods::Father, Gods::Stranger];
    gods.sort_by(|a, b| my_gods_order2(a).partial_cmp(&my_gods_order2(&b)).unwrap());
    println!("{:?}", gods);

    gods_order2!(your_gods_order2, [(Mother, 1), (Father, 2), (Stranger, 3)]);
    let mut gods = vec![Gods::Mother, Gods::Father, Gods::Stranger];
    gods.sort_by(|a, b| your_gods_order2(a).partial_cmp(&your_gods_order2(&b)).unwrap());
    println!("{:?}", gods);

}

Code on Rust Playground

Use Proc Macro

Now, what if we can define order from strings.

Let's say order is pre-defined in config.toml and macro parse the order and returns defined order.

First, do cargo new enum_builder .

In src/config.toml

order="Stranger,Smith,Warrior,Crone,Maiden,Mother,Father"

Since we use proc macro, we add followings in cargo.toml

[lib]
proc-macro = true

[dependencies]
syn = { version =  "0.15.42", features = ["extra-traits", "full"] }
proc-macro2 = "0.4.30"
quote = "0.6.12"
toml = "0.4.2"

Then, src/main.rs will be...

pub mod enum_builder {
    use enum_from_string::order;

    #[derive(Debug, order)]
    pub enum Gods {
        Father,
        Mother,
        Maiden,
        Crone,
        Warrior,
        Smith,
        Stranger,
    }
}

fn main() {
    assert_eq!(enum_builder::Gods::Father.order(), 6);
    assert_eq!(enum_builder::Gods::Stranger.order(), 0);
}

Finally, lib.rs is..

extern crate proc_macro;
extern crate toml;

use proc_macro::TokenStream;
use quote::quote;
use std::fs;
use std::io::{BufReader, Read};
use toml::Value;

use syn::{parse_macro_input, DeriveInput};

fn file_open(path: String) -> Result<String, String> {
    let mut file_content = String::new();

    let mut fr = fs::File::open(path)
        .map(|f| BufReader::new(f))
        .map_err(|e| e.to_string())?;

    fr.read_to_string(&mut file_content)
        .map_err(|e| e.to_string())?;

    Ok(file_content)
}

#[proc_macro_derive(order)]
pub fn order_builder(item: TokenStream) -> TokenStream {
    let ast = parse_macro_input!(item as DeriveInput);
    let name = &ast.ident;
    let enum_variants = if let syn::Data::Enum(syn::DataEnum { variants, .. }) = ast.data {
        variants
    } else {
        unimplemented!();
    };
    let enum_len = &enum_variants.len();

    let order_config: toml::Value = file_open("src/config.toml".to_string())
        .unwrap()
        .parse::<Value>()
        .unwrap();

    let orders: Vec<&str> = order_config["order"].as_str().unwrap().split(",").collect();

    assert_eq!(&orders.len(), enum_len);

    let enum_fields = orders.iter().enumerate().map(|(i, elm)| {
        let elm_ident = syn::Ident::new(&elm, name.span());
        let arm = quote! {
            #name::#elm_ident => #i as i32,
        };
        arm
    });

    let order_func = quote! {
        impl #name {
            pub fn order(&self) -> i32{
                match self {
                    #(#enum_fields)*
                }
            }
        }
    };
    order_func.into()
}

Refs

For Proc macro basic...
https://github.com/azriel91/proc_macro_rules

For advanced proc macro learners
https://github.com/dtolnay/proc-macro-workshop

proc-macro-workshop has many fork repos and you can find good solutions, such as...
https://github.com/ELD/proc-macro-workshop
https://github.com/jonhoo/proc-macro-workshop
https://github.com/gobanos/proc-macro-workshop

Rust lifetimes, a high wall for Rust newbies

TakaakiFuruse — Thu, 03 Jan 2019 02:27:26 +0000

Learning Rust is hard

I recently start learning Rust. The language is famous but at the same time is infamous. Everybody says it has steep learning curves and some concepts (mostly borrowing, ownership and lifetimes) are hard to grasp.

Let me explain some of the concepts related to lifetime. (Don't assume me as an expert of lifetime, even though I deciced to write this article, I feel I still don't get the concept. Also, this article is just a paraphase of the book and the nomicon.)

If you want to run your code on your machine, run it with Rust 1.31.1, current (2019 Jan) stalbe.

Most of the codes are copied from the book, the nomicon.

Lifetime Basics

This does not compile, but

fn main() {
    {
        let r;

        {
            let x = 5;
            r = &x;
        }

        println!("r: {}", r);
    }
}

This does compile

fn main() {
    let r;

    let x = 5;
    r = &x;

    println!("r: {}", r);
}

Why? Rust's variables live within their scope (between "{" and "}"). If they go out boundries, compiler kills them, just like a prison.

The problem of the first code is var r. r has a borrowed value from x and we ask Rust to print out on final line. Notice that x dies soon after he loaned his value to r. So, on final line, we basically trying to priting out a value which does not exists. Rust yells ERROR.

The solution is simple. Just remove the scope and let r an x live til the end of main func.

Rust decides how long each vars live, according to nomicon.

This simple code


fn main() {
    let x = 0;
    let y = &x;
    let z = &y;
}

is just a sugared one. If we desugar, it looks like this.

fn main() {
    'a: {
        let x: i32 = 0;
        'b: {
            let y: &'b i32 = &'b x;
            'c: {
                // ditto on 'c
                let z: &'c &'b i32 = &'c y;
            }
        }
    }
}

The nomicon says lifetimes are just a regions. Yes, it looks like code blocks.

(Unfortunately, lifetime boundries are not visualized and there's no way to do it. I wish if it were. Nashenas88 is working on the visualization project. Good Luck!!)

Function and Lifetime

This code does not compile

#[allow(unused_variables)]
fn main() {
    let string1 = String::from("abcd");
    let string2 = "xyz";

    let result = longest(string1.as_str(), string2);
}


fn longest(x: &str, y: &str) -> &str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

Rust says...

error[E0106]: missing lifetime specifier
  --> src/main.rs:11:33
   |
11 | fn longest(x: &str, y: &str) -> &str {
   |                                 ^ expected lifetime parameter
   |
   = help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `x` or `y`

The longest function returns either x or y. Nobody knows exactly which.

In most cases Rust tries to assume var's lifetimes based on simple rules (it's called lifetime elission). In this case, the rules does not apply. So we need to add lifetimes manually, let's do it.

This compiles

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

How about giving different lifetimes for x and y?

That won't work, since the function made to return only 1 result. The result comes with 1 lifetime, but which lifetime, x's or y's (we can't say either or both)?

Lifetime subtypes

Let's try another example.
In this example, I strucutrued that Parser contains Context object and parse_context does parsing job.

struct Context(&str);

struct Parser {
    context: &Context,
}

impl Parser {
    fn parse(&self) -> Result<(), &str> {
        Err(&self.context.0[1..])
    }
}

fn parse_context(context: Context) -> Result<(), &str> {
    Parser { context: &context }.parse()
}

If we compile, we'll get error.

error[E0106]: missing lifetime specifier
 --> src/lib.rs:1:16
  |
1 | struct Context(&str);
  |                ^ expected lifetime parameter

error[E0106]: missing lifetime specifier
 --> src/lib.rs:4:14
  |
4 |     context: &Context,
  |              ^ expected lifetime parameter

error[E0106]: missing lifetime specifier
  --> src/lib.rs:13:50
   |
13 | fn parse_context(context: Context) -> Result<(), &str> {
   |                                                  ^ help: consider giving it an explicit bounded or 'static lifetime: `&'static`
   |
   = help: this function's return type contains a borrowed value with an elided lifetime, but the lifetime cannot be derived from the arguments

Let's add a lifetime.

struct Context<'a>(&'a str);

struct Parser<'a> {
    context: &'a Context<'a>,
}

impl<'a> Parser<'a> {
    fn parse(&self) -> Result<(), &'a str> {
        Err(&self.context.0[1..])
    }
}

fn parse_context<'a>(context: Context<'a>) -> Result<(), &'a str> {
    Parser { context: &context }.parse()
}

and we'll get error....

error[E0515]: cannot return value referencing function parameter `context`
  --> src/lib.rs:14:5
   |
14 |     Parser { context: &context }.parse()
   |     ^^^^^^^^^^^^^^^^^^--------^^^^^^^^^^
   |     |                 |
   |     |                 `context` is borrowed here
   |     returns a value referencing data owned by the current function

The var context is only available in parse_context function. So, at the end of function, Parser will reffer to a var which does not exist.

What should we do?

We need 2 lifetimes.
This will compile (only on 1.31.1, not other versions.)

#![allow(dead_code)]

struct Context<'s>(&'s str);

struct Parser<'c, 's> {
    context: &'c Context<'s>,
}

impl<'c, 's> Parser<'c, 's> {
    fn parse(&self) -> Result<(), &'s str> {
        Err(&self.context.0[1..])
    }
}

fn parse_context(context: Context) -> Result<(), &str> {
    Parser { context: &context }.parse()
}

Parser contains Context and Parser reffers Context through "parse" method.

This means that Context has to live longer than Parser. So, we should at least tell Rust that both lifetimes are different.

(Although I'm writing "we need 2 lifetimes", I still don't get why we need 2 lifetims. Single lifetime means Context and Parser dies at the same time. What's the problem!)

(Do you think reading RFC for non-lexical lifetimes would be good for understanding lifetimes, although it's super lengthy? )