Лингво #мэмы и взаимная рекурсия

#achievement unlocked: Засадить занозу мандарином.

#WUT

Человек выкашлял четыре чашки мочи, после этого умер и у него в грудной клетке нашли почку.

Именно этому уникальному случаю посвящен case-report, опубликованный аж в 1923 году в голландском журнале Nederlands Tijdschrift voor Geneeskunde (Dutch Journal of Medicine). Как выяснилось это был прикол студентов медиков и их профессора, которым было интересно, насколько дикую фигню можно опубликовать.

Статья была ретрактнута из журнала в 2003, что делает её абсолютным чемпионом в сомнительном соревновании на самый долгий ретракт.

#bio #suckassstory

#prog #rust

Но вообще ответ не вполне корректен. Тип числового литерала уточняется выводом типов, а конкретно i32 выбирается только в том случае, если ограничений на тип недостаточно, чтобы выбрать конкретный числовой тип (и лично я это считаю недостатком Rust)

Вы знали, что в Ansible можно определить переменную в 22х местах?
Вот теперь и живите с этим, вас еще на собесах будут мучать таким вопросом

Официальная дока - тут

Товарищам без VPN - порядок приоритета от наименьшего к наибольшему:

1. Передаваемые значения в adhoc/при запуске ansible [--private-key PRIVATE_KEY_FILE] [-u REMOTE_USER]...
2. Директория defaults в структуре ансибл-роли
3. Переменные группы хостов в инвентори-файле
4. Inventory group_vars/all
5. Playbook group_vars/all
6. Inventory group_vars/*
7. Playbook group_vars/*
8. Переменные хостов в инвентори-файле
9. Inventory host_vars/*
10. Playbook host_vars/*
11. Facts хоста и закешированные set_facts
12. Секция vars в плейбуке
13. Секция vars_prompt в плейбуке
14. Секция vars_files в плейбуке
15. Директория vars в структуре ансибл-роли
16. Переменные объявленного блока
17. Переменные объявленной таски
18. Секция include_vars
19. Переменные из register и set_fact
20. Переменные объявленные в include_role
21. Переменные которые используются внутри include_tasks
22. Extra vars, которые используем через ключ -e при запуске ansible

#шпаргалки

А вы сегодня качаетесь соло или в коопе?

4:19

Зачем MAX при открытии отправляет запрос к серверу Телеграма?
https://qna.habr.com/q/1408720

4:20

#prog #rust #article

В стандартной библиотеке Rust есть несколько ассоциативных контейнеров: HashMap, HashSet, BTreeMap и BTreeSet. Часто на практике в качестве ключей в них хранятся строки — String. Требовать от пользователя для поиска значение типа String неудобно и чревато проблемами в производительности. Потому у этих структур данных есть API, позволяющие использовать для поиска ключи других, "похожие" на те, что хранятся в контейнере.

Возьмём в качестве примера HashMap::get:

fn get<Q>(&self, k: &Q) -> Option<&V>
where
    K: Borrow<Q>,
    Q: Hash + Eq + ?Sized,

Как видно из кода, тип для поиска (Q) не обязан совпадать с типом хранимых ключей (K), но на K есть ограничение K: Borrow<Q>. Трейт Borrow выглядит таким образом:

trait Borrow<Borrowed>
where
    Borrowed: ?Sized,
{
    fn borrow(&self) -> &Borrowed;
}

В процессе поиска значения на хранимых ключах вызывается метод <K as Borrow<Q>>::borrow, и результат возвращаемого значения сравнивается со значением, переданным в get. Именно благодаря этому API (и реализациям в std, разумеется) коллекцию HashMap<String, Thing> можно индексировать значениями типа &str.

Но у этого API есть недостаток. Именно, оно требует, чтобы предоставляемое значение было ссылкой и чтобы из ссылки на ключ можно было получить ссылку на Q. Это ограничивает применимость API. Если, например, в мапе в качестве ключей хранятся (String, String), то логичный невладеющий эквивалент для индексации (&str, &str) не будет работать, потому что это кортеж ссылок, а не ссылка.

В короткой статье Borrowed tuple indexing for HashMap рассказывается, как с некоторым количеством бойлерплейта можно обойти это ограничение.

Для сравнения, hashbrown (поверх которого сделаны мапы в std) от подобных ограничений не страдает, поскольку там в API используется более гибкий трейт Equivalent:

trait Equivalent<K>
where
    K: ?Sized,
{
    fn equivalent(&self, key: &K) -> bool;
}

#meme про котов

BTW это было в Rust std с самой первой версии, то есть с середины 2015 года. В #cpp подобная вещь называется heterogeneous lookup, и хотя она реализована для контейнеров в std, она opt-in. Для упорядоченных контейнеров нужно явно дописывать std::less<> в шаблонные параметры типа, а для неупорядоченных вообще надо самостоятельно писать хешер и явно дописывать is_transparent в определении. Вдобавок heterogeneous lookup на упорядоченных контейнерах был с C++14, а вот на неупорядоченных его не было до выхода C++20 — то есть на четыре года позже, чем в Rust.

https://social.treehouse.systems/@grawity/115452750862767048

#ml #meme?

Я боюсь программировать, я могу заплакать.

Microsoft C/C++ compilation toolchain is quite literally FUBAR for ages. People have written hundreds lines long scripts to simply try to locate all the necessary executables and libraries. Alas, anything short of full filesystem search breaks at one point or the other.

Luckily, Jonathan Marler recently managed to develop a single-file versioned (sic!) installation manager akin to nvm, uv and similar:
https://marler8997.github.io/blog/fixed-windows/