У меня выработалась хорошая привычка сразу документировать safety требования и обоснования вокруг unsafe кода.
unsafe fn - сразу пишу как не получить с ней UB.
unsafe {} - почему тут не будет UB. Для этого есть clippy lint clippy::undocumented_unsafe_blocks. Также всегда советую делать #![forbid(unsafe_op_in_unsafe_fn)] если нету #![forbid(unsafe)].

Но есть один случай, когда приходится писать

// SAFETY: Practically safe, but generally nope.
unsafe { ... }

И ничего тут не поделаешь. Можно сколько угодно протаскивать unsafe наверх, хоть до main, но там придется сделать вот такой unsafe блок.
Что ж это за жестокая ирония и когда крабам приходится идти на трюки и соглашаться на "безопасно на практике" вместо полной гарантии безопасности?

Первый написавший правильный ответ в комментарии к посту заслужит почет и уважение.

Давненько ничего не писал. Ни тут не писал, ни на Rust.
Хватит это терпеть, как говориться.

Сегодня добавил еще одну структуру данных в свой арсенал.
Сей арсенал запакован в crate amity (англ. peaceful relations, as between nations; friendship).
Который я и опубликовал. https://docs.rs/amity/latest/amity/

Верхнеуровневая документация хромает, но стараюсь хотя бы типы и методы задокументировать как следует.

Что есть в этой библиотеке. От простого к сложному
1. `CacheAlign и CachePadded` позволяют выравнивать данные по краям кэш-линий, избегая ситуации false sharing.
False sharing происходит когда два потока одновременно обращаются к двум разным областям памяти, которые разделяют кэш-линию.
Один поток делает запись и инвалидирует всю кэш-линию, второй поток вынужден ее обновлять, хотя данные, которые нужны потоку вовсе не поменялись.
Предоставленные типы могут быть использованы для конструирования других конкурентных структур данных.

2. `TripleBuffer` - очень простой в использовании и эффективный single-producer single-consumer канал с емкостью очереди 1.
Особенно полезен, когда consumer читает значения и их можно переиспользовать в producer-е, экономя гига-циклы.
Например когда значения содержат ссылки на ресурсы или аллоцирую память.
К тому же producer знает, было ли значение прочитано consumer-ом или нет и обновить его соответствующе, что может дать не только бонус к производительности, но и вовсе сделать алгоритм невозможный с обычным каналом.

3. `BackOff` используется в различных алгоритмах ожидания, что бы делать сначала busy spin, переходить к более энергоэффективным thread yield и наконец остановке треда.

4. `RawSpin` - самая простая имплементация блокировки на основе busy spin. Использует BackOff. Совместим в lock_api.

5. `FlipBuffer` - кольцевой буфер с возможностью добавлять в значения параллельно и без блокировок. Но только пока вместимости хватает.
`FlipQueue` - надстройка над FlipBuffer, которая добавляет значения под shared lock, пока хватает вместимости и делает unique lock при необходимости, а так же что бы забрать значения.
Оба варианта могут быть использованы в fork-join сценариях, где fork-и могут эффективно добавлять значения в очередь, а забираются они после join или очень редко в fork-ах.

6. `park` - модуль с абстрактным thread parking. С `std` можно использовать Thread и стандартный паркинг. Без std остается thread yield. Но пользователь может использовать кастомную реализацию.
Блокирующие алгоритмы (кроме spin) могут использовать любую реализацию.

7. `PtrState и AtomicPtrState` - комбинирует указатель и состояние в одном значении и позволяет атомарно читать и модифицировать. Неатомарная версия предоставлена для полноты.
`AtomicPtrState` занимает 1 usize и позволяет совершать те же операции что и AtomicUsize или AtomicPtr. Для состояния используются биты, которые гарантируются быть нулевыми в указателе в результате выравнивания. Адрес и состояние аккуратно разделяются и смешиваются, гарантируя сохранение provenance указателя.

8. `CondVar` - классический conditional variable на основе AtomicPtrState. Все операции требуют не более одного CAS вы цикле. Может использовать любой thread parking из модуля выше.
Позволяет закодировать 8 бит состояния и обновлять, записывать, ожидать его.

И другие экспериментальные вещи.

У этого crate-а нет зависимостей кроме lock_api для реализации трейтов из него и объявления синонимов типов.
Можно использовать с/без std и alloc.

Библиотеке явно не хватает серьезного тестирования, но как минимум некоторые тесты под miri она проходит.

Сегодня я обновил egui в egui-snarl и egui-probe.
Решил за одно и добавить все ломающие изменения.

На скрине пример, показывающий, что получится если некоторые пины будут задавать не стандартный WireStyle

Получился вот такой вот проводок.
Ваши мысли?

После небольшого отдыха я продолжил работать над движком.
Обновил зависимости и порефакторил.
После чего занялся той самой задачей, от которой выгорел в прошлый раз - gpu work graph.
И вот оно работает.

Опять я отвлекаюсь от графики.

Недавно я сделал библиотеку egui-probe для генерации UI редактирования значения любых типов с помощью EguiProbe трейта, который можно задерайвить.

Но это редактирование конкретного типа. А что если типа нет?
Совсем без схемы делать ну такое.
Хоче рантаймовую опциональную схему и генерировать UI для неё.

Поэтому сегодня я сделал новую библиотеку.

Она предоставляет тип Value который может принимать несколько классических вариантов данных.

А так же тип Desc, который описыает схему.
Сам он при этом может редактироваться с помощью EguiProbe.

А объединяя Value и Desc можно получить ValueProbe, который может быть использован для редактирования значения согласно схеме.

Самое замечательное, что почти не пришлось писать UI кода в этот раз.
Всю тяжелую UI работу делает egui-probe

На видео показан demo example.

И конечно можно указать Desc на любом уровне, где его нет.

"Почему бы не добавить конфигурацию рендерджобам прямо в граф?" подумал я пару дней назад

Пора бы уже соединять чуть более сложный граф, чем draw -> present.

Конечно же нашлось чуть более чем ноль багов.

Добавил хуки к рендерграфу и научил эдитор показывать каждый выход если это Image2D.

Ну все, я официально умею в нейронки теперь.
Закончил писать обучение и предсказание на HLSL.
Оно еще и быстрее местами работает, чем из фреймворка.

Добавил бы в движок, но в движке до сих пор нету 3д.
Видимо пора :)

Начал тут описывать архитектуру движка какая выходит.

https://github.com/zakarumych/nothing/blob/wip/README.md

Возможно многие как и я ждут эту фичу.
Она должны быть в следующием релизе на stable.
Она позволяет исправить следующий код что бы тот компилился.

fn get_iter<'a, T>(q: Option<&'a VecDeque<T>>) -> std::collections::vec_deque::Iter<'a, T> {
  q.unwrap_or(&VecDeque::new()).iter()
}

Что же это за фича?

Правильный ответ - inline const
https://doc.rust-lang.org/unstable-book/language-features/inline-const.html

Фикс

fn get_iter<'a, T>(q: Option<&'a VecDeque<T>>) -> std::collections::vec_deque::Iter<'a, T> {
  q.unwrap_or(const { &VecDeque::new() }).iter()
}

Q: Почему это работает?
A: Создаваемая ссылка становится &'static.
Q: Почему нужен блок?
A: Потому что иначе rustc берет ссылку уже в runtime контексте и она на temporary значение.

Визуальное программирование!

Пока что немного ограниченно - нельзя задать значения в аргументы.
А еще нельзя добавить граф к сущности в редакторе, потому что нету инспектора сущностей.
Можно только в коде.

Ноды создаются из самых обычных функций.
Плагин просто перечисляет их.

Макрос для экспорта всего и вся из плагина стал слишком большим и неудобным.

Что ж, долой его, теперь все экспортируется из плагина прямо на месте.

#[arcana::system]
#[arcana::filter]
#[arcana::job]
#[arcana::init]

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

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

И вот представляю вам, релиз кандидат номер 2

https://crates.io/crates/edict/1.0.0-rc2

Вы когда-нибудь уходили в отпуск, что бы работать над пет-проектом?

Я снова так сделал, но на этот раз пет это стол для настолок.

Я не делал мебель со школы. Пожелайте мне удачи