#prog #rust

Как относительно просто сделать вполне рабочий string interner на Rust.

matklad.github.io/2020/03/22/fast-simple-rust-interner.html

#prog #rust

Статья о дизайне beef (точнее, о том, как снизить размер beef::Cow ещё сильнее): troubles.md/abusing-rustc
Стоит ли оно того? Да: в Rust-порте simd-json использование beef::Cow вместо std::borrow::Cow привело к увеличение throughput в (почти) всех бенчмарках

#prog #rust #rustlib #amazingopensource

Библиотека, позволяющая хранить данные за указателем, эксплуатируя неиспользуемые биты в указателе

crates.io/crates/tagged-box

#prog #meme

#blogrecommendation

Что объединяет фильм «Форрест Гамп» и роман Шолохова «Тихий Дон»?

t.iss.one/bookswithklishin/375

#prog и, пожалуй, #menacingopensource

Волны твиттера принесли прекрасное: https://twitter.com/vamchale/status/1249076951685398530

TL;DR: в Elm была проблема — паттерн-матчинг по негативным числовым литералам приводил к ошибке парсинга. Эван Чаплицкий не только не исправил этот баг (при этом спросив у автора тикета «Instead of fake examples, can you explain how this comes up?») — он еще и добавил в компилятор текст ошибки, который прилагает использовать вместо паттерн-матчинга if-else.

#gamedev

Когда F. E. A. R. вышла, игру хвалили за сильный, реалистичный AI. Обычным подходом в играх для создания реалистичного AI со сложным поведением является программирование поведения вручную, часто с использованием иерархического конечного автомата. Такой подход трудоёмок, требует большого количества ручной подгонки и непрактичен для создания по-настоящему сложного поведения. Разработчики F. E. A. R. пошли по другому пути: вместо того, чтобы прописывать сложное поведение целиком, AI дали цели и набор возможных действий — и предоставили свободу в выборе достижения целей. Вкупе с небольшим количеством дополнительной логики для группового поведения это позволило добиться реалистичного поведения — того, за что игру 2005 года выпуска вспоминают до сих пор.

alumni.media.mit.edu/~jorkin/gdc2006_orkin_jeff_fear.pdf

"Хочешь найти темы для блога? Зайди в новичковый чат" (c) #моё

#prog #menacingopensource

Как передать аргументы командной строки в make? Разумеется, на костылях и непонятных командах.

stackoverflow.com/questions/6273608/how-to-pass-argument-to-makefile-from-command-line/6273809#6273809

#prog #rust #amazingopensource

Если вам всё же нужен command runner, а не эрзац build system, то имеет смысл посмотреть на just. Проще и без странного поведения, присущего make. И да, в рецепты just можно передавать аргументы командной строки.

#quotes

И да, между поребриком и бордюром действительно есть разница

а чем отличается поребрик от бордюра?

поребрик выглядит как дельта-функция, а бордюр как функция хевисайда

#prog #rust #моё

В Rust есть много хороших вещей. Одна из них — функции как первоклассные значения. Мы можем передать функцию как аргумент, возвращать функцию из функции и даже хранить функции в коллекциях. К сожалению, нацеленность Rust на абстракции нулевой (дополнительной) стоимости создаёт некоторые препятствия к широкому применению этой возможности и часто создаёт вопросы у новичков. Какие могут быть проблемы? Ну... Давайте просто поиграем с функциями, а проблемы возникнут сами 😈.

Сделаем функцию, которая будет принимать на вход два аргумента: функцию из числа в число и число, и которая будет просто применять функцию к этому числу. Неискушённый человек, только постигающий Rust, может написать следующее:

//             vvvvvvvvvvvvvv - это же функция, верно?
fn apply(func: fn(u32) -> u32, x: u32) -> u32 {
    func(x)
}

Попробуем её применить:

fn add_one(x: u32) -> u32 {
    x + 1
}

fn main() {
    println!("{}", apply(add_one, 3));
}

Этот код выводит "4", как и ожидается. Но постойте-ка, у нас же есть замечательный синтаксис для лямбда-функций! Может, применить его?

fn main() {
    println!("{}", apply(|x| x + 1, 3));
}

Этот код тоже выводит "4". Что ж, давайте немного усложним код:

fn main() {
    let one = 1;
    println!("{}", apply(|x| x + one, 3));
}

И этот код выводит... А не, не выводит, он не компилируется:

error[E0308]: mismatched types
 --> src/main.rs:8:26
  |
8 |     println!("{}", apply(|x| x + one, 3));
  |                          ^^^^^^^^^^^ expected fn pointer, found closure
  |
  = note: expected fn pointer `fn(u32) -> u32`
                found closure `[closure@src/main.rs:8:26: 8:37 one:_]`

Но ведь это же функция!

Да, но это не просто функция, это замыкание, т. е. функция, использующая данные за пределами е определения. Для того, чтобы вызвать это замыкание, требуется не только знать адрес, по которому расположен код функции, но и каким-то образом передать захваченные данные. Для каждой лямбда-функции компилятор Rust создаёт создаёт свой собственный уникальный тип. Поля этого типа — это данные, которые захватываются замыканием, в данном случае — поле под значение one. Тип же fn(u32) -> u32 — это функциональный указатель (function pointer), фактически, просто адрес в памяти, по которому располагается код функции. Неудивительно, что apply не удалось вызвать — это разные типы с разными размерами!

Но погодите, почему же удалось вызвать apply с аргументом |x| x + 1?

Потому что лямбда-функция |x| x + 1 не захватывает никаких переменных из окружения, а такие замыкания могут быть приведены к функциональному указателю начиная с версии Rust 1.19. Такое приведение может сработать в ряде различных мест, в число которых входит и аргумент функции при вызове.

Это всё, конечно, очень интересно, но как мне всё-таки вызвать apply с |x| x + one?

Очевидно, поменяв тип apply. Мы не можем дать типу замыканию имя, поэтому правильным решением будет сделать apply обобщённой функцией:

fn apply<F>(func: F, x: u32) -> u32
where
    F: Fn(u32) -> u32,
{
    func(x)
}

Что тут происходит? Мы ввели обобщённый параметр F и добавили на него ограничение Fn(u32) -> u32. Это означает, что значение типа F можно вызвать как функцию с одним аргументом u32, причём неограниченное число раз. Теперь apply можно вызвать в любом варианте:

fn main() {
    println!("{}", apply(add_one, 3));
    println!("{}", apply(|x| x + 1, 3));
    let one = 1;
    println!("{}", apply(|x| x + one, 3));
}

Отлично! Значит, замыкания имеют разные типы, а у обычных функций с одинаковыми сигнатурами типы одинаковые

Ну, не совсем:

type Pair<T> = (T, T);

fn add_one(x: u32) -> u32 {
    x + 1
}

fn add_two(x: u32) -> u32 {
    x + 2
}

fn main() {
    let funcs: Pair<_> = (add_one, add_two);
}

Этот код не компилируется:

error[E0308]: mismatched types
  --> src/main.rs:12:36
   |
12 |     let funcs: Pair<_> = (add_one, add_two);
   |                                    ^^^^^^^ expected fn item, found a different fn item
   |
   = note: expected fn item `fn(_) -> _ {add_one}`
              found fn item `fn(_) -> _ {add_two}`

Так, а что тут не так? И почему не совпадают типы?

Дело в том, что у каждой функции — не только у замыканий — в Rust свой собственный уникальный тип. Здесь мы попытались сохранить значения двух разных типов в паре одинаковых типов, поэтому наш код не компилируется.

Зачем так сложно? В этом же нет никакого смысла!

Вообще-то есть. Компилятор эксплуатирует тот факт, что тип населён единственным значением, и потому не хранит и не передаёт адрес функции, а вставляет его по месту вызова. Таким образом, компилятору предоставляется больше возможностей для встраивания (inlining) функций. Также это влияет на структуры, которые хранят в себе функции: если тип не указан явно как функциональный указатель, обычная функция вообще не занимает места в памяти. Функциональный указатель же занимает столько же места, сколько и указатель:

fn main() {
    assert_eq!(std::mem::size_of_val(&add_one), 0);
    let add_one_ptr: fn(u32) -> u32 = add_one;
    assert_eq!(
        std::mem::size_of_val(&add_one_ptr),
        std::mem::size_of::<usize>()
    );
}

Кстати, на замыкания это тоже распространяется: значение замыкания хранит в себе только захваченные данные, поэтому размер замыкания равен (с поправкой на выравнивание) размеру захваченных данных. Если замыкание ничего не захватывает, то у него нулевой размер:

fn main() {
    assert_eq!(std::mem::size_of_val(&|x: u32| x + 1), 0);
}

Теперь я вижу, что в этом действительно есть смысл. И всё-таки, как скомпилировать тот пример с парой функций?

Просто хранить разнородную пару.

А если нам принципиально, чтобы элементы пары имели одинаковый тип?

В таком случае нам надо привести значения к одинаковому типу. Это можно сделать так:

let funcs: Pair<fn(_) -> _> = (add_one, add_two);

Обратите внимание, выписывать тип точно в этом случае не нужно, достаточно сказать, что это function pointer. Другой способ — явно привести одно из значений в паре:

let funcs: Pair<_> = (add_one as fn(_) -> _, add_two);

Второе значение будет неявно приведено (coerced) к нужному типу. В принципе, ничто не мешает написать явный каст у обоих значений, но надобности в этом в данном примере нет. Кстати, если мы сделаем массив функций, то никаких кастов делать не придётся, rustc сам уравняет типы до функционального указателя:

let arr = [add_one, add_two];

А что, если замыкание возвращает захваченное значение? Если это значение не копируемо, то замыкание можно вызвать только один раз...

А вот про это я расскажу в следующий раз.

Это... Это просто великолепно.

https://youtu.be/y8OnoxKotPQ

#prog #amazingopensource

Если вы когда-нибудь хотели сделать свой блог, но не знали, как сделать комментарии (или не хотели подключать жирный Disqus), то этот вариант может подойти: комментарии, работающие поверх issue в GitHub.

utteranc.es