#prog #meme про старые программы

Люблю, когда у меня в руках толстый кошель 🤤

Самая привлекательная вещь в парнях — это их девушки.

Чушь какая-то

Так, причин переезжать в Армению не осталось

#prog #rust #article

Writing a Test Case Generator for a Programming Language

В статье автор шаг за шагом строит генератор валидных WASM-программ — который, кстати, оказался полезным для нахождения багов в инструментах анализа WASM-кода.

Принципы, которые излагает автор, достаточно общие, чтобы помочь с написанием произвольного случайного структурированного входа.

#prog #meme

А что не так?

(#math?) #meme

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

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

#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, это сильно повышает полезность данной подсказки.

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