Как вызвать лютую зависть всего за восемь слов (фото упомянутого кота выше на канале):

Я два с половиной часа сидел с котом🥰🥰🥰

#prog #article

Swarm Testing

В тестировании софта есть такое направление, как тестирование на случайном входе. Фаззинг — это то, что на слуху, но этим, как правило, называют тестирование на случайных байтах. Это неплохой подход для тестирования парсеров медиаформатов, архивов, сетевых пакетов и прочего в этом духе, но этот подход не особо полезен для тестирования программ с высокоструктурированным входом — например, компиляторов. Для более эффективного тестирования со случайным входом для таких программ требуются генераторы подобного высокоструктурированного входа (вроде Csmith или wasm-smith).

Подобные генераторы, как правило, имеют ручки для настройки того, какие именно элементы будут генерироваться в их выходе. Скажем, Csmith можно указать, генерировать ли операции с указателями или код с объединениями. Среди пользователей таких генераторов распространено мнение, что для наиболее продуктивного использования подобного рода генераторов нужно использовать все возможные подобные фичи для генерации — возможно, настроив при этом их относительный вес, но всё же. Swarm testing же — это другой подход к использованию таких генераторов: вместо того, чтобы прогонять много тестов с одним и тем же набором активированных фич, прогонять тесты пачками, в каждой из которых активированы только часть фич для генерации.

Данный папир показывает результаты эмпирического исследования, которое показывает, что swarm testing — вопреки ожиданиям — ничуть не хуже "традиционного" случайного тестирования, а по некоторым метрикам даже превосходит, и при этом в состоянии дать б‌о‌льший охват багов при меньших затратах процессорного времени. Авторы также спекулируют на тему того, почему swarm testing настолько эффективно.

#prog #rust #article

Back-end parallelism in the Rust compiler

Очередная статья от Nicholas "nnethercote" Nethercote об ускорении компилятора Rust.

LLVM позволяет разбивать LLVM IR, составляющий программу, на несколько кусков — которые называются codegen units (CGU) — и обрабатывать каждый из этих кусков параллельно. Не смотря на то, что, очевидно, это вредит качеству генерируемого кода — так как LLVM не может проводить оптимизации, требующие глобального анализа — на практике это заметно ускоряет компиляцию и потому используется по умолчанию для отладочных билдов.

В этой статье Николас описывает свои попытки ускорить связанную с CGU часть компиляции. Спойлер: большинство попыток ускорить ничего не добились.

#prog #rust #gamedev

Bevy 0.11

Статья об обновлении движка Bevy. Советую прочитать целиком, ибо контента там порядочно, но сюда хочу принести парочку заинтересовавших меня сугубо технических деталей.

Во-первых, в Bevy теперь есть были и раньше (thanks @SDesya74 за уточнение) derive-макросы для Deref и DerefMut. Для структур с одним полем они автоматически генерируют реализацию трейтов, которые возвращают ссылку на это поле, а для структур с несколькими полями теперь можно указать атрибут #[deref] над нужным полем:

use bevy_derive::{Deref, DerefMut};

#[derive(Deref, DerefMut)]
struct MyStruct {
value: String,
}

#[derive(Deref, DerefMut)]
struct MyStruct<T> {
#[deref]
value: String,
_phantom: PhantomData<T>,
}

Во-вторых, обновилось API для добавления систем (S из ECS) с учётом ограничений на порядок их применения. Скажем, вот такой код:

app.add_systems(Update, (
(attack, defend).in_set(Combat).before(check_health),
check_health,
(handle_death, respawn).after(check_health)
))

настроит движок так, что системы attack и defend будут запущены в параллель, после них будет запущена check_health, а после неё — handle_death и respawn в параллель. При этом добавили и способ для более краткой записи подобной линейной последовательности:

app.add_systems(Update,
(
(attack, defend).in_set(Combat),
check_health,
(handle_death, respawn)
).chain()
)

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

app.add_systems(Update,
(
(a, (b, c, d).chain()),
(e, f),
).chain()
)

В этом случае в параллель будут запущены системы a и цепочка b -> c -> d, а после окончания их работы будут запущены в параллель системы e и f. Наглядная демонстрация пользы от type-level наворотов.

#prog #rust

Хайлайты из rust-analyzer:

* Добавлена новая команда для отображения раскладки типов в памяти. Выглядит, правда, страшненько. С другой стороны, результат этой команды — это просто HTML со стилями, так что поменять это потом будет не так уж сложно. Кстати, тот факт, что просто HTML достаточно — одно из немногих достоинств основанных на Electron редакторов.
* Добавлена команда, которая по impl-блоку генерирует определение трейта и его реализацию для типа из impl-блока.
* rust-analyzer при наведении на константу показывает во всплывающей подсказке значение этой константы. Теперь по возможности для формирования этой подсказки используется реализация Debug для типа константы. Для, скажем, структур, генерируемых bitflags, это сильно повышает полезность данной подсказки.

Копропилот передаëт привет

nice

#prog #julia #rust #rustlib #article

Первая статья — Shelling Out Sucks — рассказывает, что не так с языковыми средствами для запуска шелла (такими, как в Perl и в Ruby с backtick-строками, например). Тезисно:

1. Для интерполяции переменных используется обычная строковая интерполяция, которая не экранирует символы со специальным значением для шелла — что ломает пайплайны, если туда затёсывается, скажем, пробел или кавычка.
2. Для исполнения команды запускается шелл, который, в свою очередь, уже запускает переданную команду — что не слишком эффективно и, вообще говоря, избыточно.
3. Ошибки по умолчанию проглатываются (из-за посредника в виде процесса шелла), а при использовании средств вроде set pipefail ошибки недостаточно подробны, так как не говорят, какая именно команда завершилась ошибкой.
3.1. Некоторые команды оболочки и программы используют код завершения не для передачи статуса ошибки, а для передачи полезной информации (grep, например), что плохо сочетается с set pipefail.

В статье Put This In Your Pipe рассказывается, как эта проблема была решена в Julia. В языке также присутствует синтаксис backtick-строк, но он реализует другой функционал. А именно:

* вместо немедленного запуска команды строка формирует объект, который представляет собой команду. В частности, на этом этапе строка делится на имя запускаемой программы и её аргументы.
* синтаксис для интерполяции значений (не только переменных, но и выражений) уже делает необходимое экранирование.
* интерполяция массивов работает аналогично shell expansion вместо вставки разделённых пробелами строк.
* функции для запуска команд порождают процессы и собирает их коды возврата самостоятельно, без делегации командной оболочке.

В Rust есть библиотеки для запуска команд, основанные на похожих принципах: xshell (от Алексея Кладова) и более продвинутая duct, позволяющая пайпить команды. Документация xshell прямо отсылает к "Shelling out sucks" и "Put this in your pipe", а документация duct дополнительно рассказывает о том, какие ловушки закрывает.

P. S.: тот факт, что в Unix-like системах до сих пор нет вменяемого способа завершить дерево процессов более чем единичной глубины — это охренеть как странно.

Программист на Rust в поисках вакансии

#meme про образование

Даже гугл считает, что фембои > томбои

#prog #meme про React

Так, я понял. У меня нет донатов, потому что мои подписчики не любят толстые кошельки

#prog #article

Unorthodocs: Abandon your DVCS and Return to Sanity