¡Ya disponible! Investigación de Telegram 2025 — los principales insights del año 
Блог*
Ir al canal en Telegram
Блог со звёздочкой. Много репостов, немножко программирования. Небольшое прикольное комьюнити: @decltype_chat_ptr_t Автор: @insert_reference_here
Mostrar más1 923
Suscriptores
+224 horas
Sin datos7 días
-1130 días
Archivo de publicaciones
1 922
#prog #rust
Хайлайты из rust-analyzer:
* Добавлена новая команда для отображения раскладки типов в памяти. Выглядит, правда, страшненько. С другой стороны, результат этой команды — это просто HTML со стилями, так что поменять это потом будет не так уж сложно. Кстати, тот факт, что просто HTML достаточно — одно из немногих достоинств основанных на Electron редакторов.
* Добавлена команда, которая по impl-блоку генерирует определение трейта и его реализацию для типа из impl-блока.
* rust-analyzer при наведении на константу показывает во всплывающей подсказке значение этой константы. Теперь по возможности для формирования этой подсказки используется реализация Debug для типа константы. Для, скажем, структур, генерируемых bitflags, это сильно повышает полезность данной подсказки.
1 922
#prog #rust #gamedev
Bevy 0.11
Статья об обновлении движка Bevy. Советую прочитать целиком, ибо контента там порядочно, но сюда хочу принести парочку заинтересовавших меня сугубо технических деталей.
Во-первых, в Bevy теперь есть 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 наворотов.1 922
#prog #rust #article
Back-end parallelism in the Rust compiler
Очередная статья от Nicholas "nnethercote" Nethercote об ускорении компилятора Rust.
LLVM позволяет разбивать LLVM IR, составляющий программу, на несколько кусков — которые называются codegen units (CGU) — и обрабатывать каждый из этих кусков параллельно. Не смотря на то, что, очевидно, это вредит качеству генерируемого кода — так как LLVM не может проводить оптимизации, требующие глобального анализа — на практике это заметно ускоряет компиляцию и потому используется по умолчанию для отладочных билдов.
В этой статье Николас описывает свои попытки ускорить связанную с CGU часть компиляции. Спойлер: большинство попыток ускорить ничего не добились.
1 922
#prog #article
Swarm Testing
В тестировании софта есть такое направление, как тестирование на случайном входе. Фаззинг — это то, что на слуху, но этим, как правило, называют тестирование на случайных байтах. Это неплохой подход для тестирования парсеров медиаформатов, архивов, сетевых пакетов и прочего в этом духе, но этот подход не особо полезен для тестирования программ с высокоструктурированным входом — например, компиляторов. Для более эффективного тестирования со случайным входом для таких программ требуются генераторы подобного высокоструктурированного входа (вроде Csmith или wasm-smith).
Подобные генераторы, как правило, имеют ручки для настройки того, какие именно элементы будут генерироваться в их выходе. Скажем, Csmith можно указать, генерировать ли операции с указателями или код с объединениями. Среди пользователей таких генераторов распространено мнение, что для наиболее продуктивного использования подобного рода генераторов нужно использовать все возможные подобные фичи для генерации — возможно, настроив при этом их относительный вес, но всё же. Swarm testing же — это другой подход к использованию таких генераторов: вместо того, чтобы прогонять много тестов с одним и тем же набором активированных фич, прогонять тесты пачками, в каждой из которых активированы только часть фич для генерации.
Данный папир показывает результаты эмпирического исследования, которое показывает, что swarm testing — вопреки ожиданиям — ничуть не хуже "традиционного" случайного тестирования, а по некоторым метрикам даже превосходит, и при этом в состоянии дать б́́о́льший охват багов при меньшей затрате процессорного времени. Авторы также спекулируют на тему того, почему swarm testing настолько эффективно.
1 922
#prog #rust #article
Writing a Test Case Generator for a Programming Language
В статье автор шаг за шагом строит генератор валидных WASM-программ — который, кстати, оказался полезным для нахождения багов в инструментах анализа WASM-кода.
Принципы, которые излагает автор, достаточно общие, чтобы помочь с написанием произвольного случайного структурированного входа.
