#werror #rant

В копилку проектов, желающих мне смерти заебаться:

https://github.com/harfbuzz/harfbuzz/blob/main/src/hb.hh#L49-L97 - конечно, мы не только включим в meson Werror по умолчанию, так еще и досыпем всяких полезных (нет) предупреждений, которым сами не будем соответствовать!

Или вот - https://github.com/GNOME/pango/blob/main/meson.build#L91-L108

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

Ладно, не обязуетесь, но если вы так не делаете - то вы больной на всю голову упырь зачем-то заставляете заебаться много людей на пустом месте!

#gnulib #rant

gnulib - это такая библиотека от #GNU, которая якобы должна приводить интерфейс системной библиотеки libc, к богоугодному столлманоугодному виду.

У нее есть ряд проблем, которые, в основном, вызваны тем, что у проекта GNU все принято делать через жопу:

* ее не существует в виде отдельной либы. Нельзя собрать libgnulib.a и установить ее к себе на хост

* она поставляется (и разрабатывается) в виде M4 макросов, которые, по странным правилам, генерируют исходники на машине, где собирается то или иное приложение от GNU

* эти псевдоисходники вендорятся каждым проектом от GNU, с патчами от этих проектов

Для этих исходников генерируются (в процессе configure, ага), заголовки, мимикрирующие заголовки несуществующей libc от несуществующей gnu os (!= linux, потому что на linux непустое множество кода, добавляющегося в эти заголовки).

Там куча ifdef, которые либо что-то скрывают из системной libc, либо что-то добавляют (например, функции, которых нет в системе).

Как это работает? Хуево это работает!

Все это барахло очень хрупкО по отношению ко входным параметрам (способам autodetect в configure скриптах фич компилятора и наличия определенных функций в libc), не cross-friendly (например, фишка этой библиотеки - переопределять malloc/realloc, когда системные реализации могут вернуть 0(что разрешено стандартом!), а для этого нужно код реально запустить под target платформу).

Перепоределяется это все с помощью макросов, хотя, казалось бы, нужен тебе realloc с определенным свойством - ну запили ты себе GNU_realloc, и используй консистентно. Это, конечно, слишком прямое решение для проекта GNU.

https://gist.github.com/pg83/55712a369912405fcf9c4063533722eb

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

Что тут написано?

configure скрипты вывели несовместимые определение для эмуляции inline в С, и определение для пометки чего-то, как потенциально неиспользуемое.

Вот так выглядит их склейка:

# define _GL_INLINE static _GL_UNUSED

Ну, вот, реально эти затычки по отдельности могут работать, а вместе - нет, на что и ругается компилятор.

Самое безумие этой ситуации - что исправить это невозможно (а, точнее, запретительно дорого), потому что, даже если прийти в gnulib, и исправить это там, то по проектам это говно будет растекаться несколько лет!

Мораль?

Держитесь как можно дальше от проекта GNU, если у вас есть такая возможность.

https://www.opennet.ru/opennews/art.shtml?num=60104

https://www.opennet.ru/opennews/art.shtml?num=60107

Теперь ждем, когда релизы от сообщества начнут выходить чуть раньше, чем релизы от RedHat, если вы понимаете, о чем я!

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

Вот есть, например, crud rpc сервер, он обладает "естественной", простой, параллельностью, которая висит низко - бери да ешь.

Но проекты имеют тенденцию скатываться от естественной параллельности к сложной. От низковисящих фруктов к высоко висящим.

Для очень небольшого числа проектов это оправдано, но, чаще всего, лучше перейти к рядом стоящему дереву, где еще полно фруктов на самых нижних ветвях.

Для системы сборки естественная параллельность - это файлы или модули, зависит от языка.

Но, когда это съедено, люди зачем-то начинают делать вот это вот - https://www.opennet.ru/opennews/art.shtml?num=60095

"Для поддержки распараллеливания фронтэнд переведён на использование библиотеки Rayon и значительно переработан, например, многие его части теперь синхронизируются с помощью мьютексов и блокировок чтения/записи, а в коде используются атомарные типы. При тестировании производительности новая распараллеливаемая реализация могла выполнять компиляцию до 2% медленнее при работе в однопоточном режиме (-Z threads=1), но когда потоков больше одного скорость значительно возрастала. Например, при установке 8 потоков (-Z threads=8) в некоторых ситуациях время компиляции удавалось сократить на 50%."

Я не знаю, по мне эти цифры говорят, что не надо ЭТО делать!

Это же жесть - простой код стал сложным, в него будет сложнее внедрять продуктовые фичи и другие оптимизации!

Мьютексы! Атомики! Danger, Will Robinson!

И все ради чего?

Чтобы в некоторых случаях, при использовании 8!!! потоков, ускорить все на 50%?

Я не знаю.

Писал, и буду писать, что иногда надо остановиться, и не делать улучшения, которые сложны непропорционально профиту.

https://xn--r1a.website/itpgchannel/353
https://xn--r1a.website/itpgchannel/1179
https://xn--r1a.website/itpgchannel/22
https://xn--r1a.website/itpgchannel/539

Нам нравится unix way.

Это когда есть инструмент, он хорошо делает одну задачу, и эти инструменты composable, например, через пайпы.

Но почему unix получился именно таким?

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

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

Как side effect получаем пресловутый "unix way".

Ну и, конечно, все пошло по пизде, когда в unix завезли динамическую линковку, потому что такая вот декомпозиция на изолированные процессы - это же сложно, надо много думать, а тут взял и позвал нужную функцию, и OS даже сделает так, что это не потратит дополнительной памяти (ну, почти).

#sat

https://www.uber.com/blog/nilaway-practical-nil-panic-detection-for-go/

Компания Uber (эта та самая, которая хвасталась тем, что у нее 100500 git репозиториев, а потом сливала их все в монорепку), кажется, запилила нечто весьма годное - штуку, которая ловит разыменовывания nil в go.

При этом, не какой-нить дурацкой эвристикой, а вполне разумно:

"Our main idea is that nilability flows in code can be modeled as a system of global typing constraints, which can then be solved using a 2-SAT algorithm to determine potential contradictions"

Надо брать, пока дают!

https://www.opennet.ru/opennews/art.shtml?num=60133

"Реализован третий уровень поддержки для платформы i686-pc-windows-gnullvm. Третий уровень подразумевает базовую поддержку, но без автоматизированного тестирования, публикации официальных сборок и проверки возможности сборки кода"

Я чет ору, и не могу остановиться.

"i686-pc-windows-gnullvm" - что это? Что это за кадавр, зачем он появился на свет, кому он нужен, и зачем для него нужен Rust?

https://www.phoronix.com/news/Louvre-Wayland-Library
https://github.com/CuarzoSoftware/Louvre

Wlroots - по сути, безальтернативная библиотека, если вы хотите запилить wayland композитор.

Потому что, знаете ли, кто первый встал, того и тапки - вот, представители kwin, mutter, и wlroots по сути, пишут предложения и расширения к wayland. А считать первые два хоть сколько нибудь отделимыми от своих DE может только сумасшедший.

И ничего хорошего в этом нет, потому что:

* Дрю ДеВолт #ddv, как оказалось, еще тот SJW-гондон.
* Мало конкуренции - плохо для продукта.

Собственно, поэтому нельзя не радоваться еще одной полностью независимой реализации библиотеки для разработки #wayland композитора!

Факт того, что она написана на каком-то разумном С++, без мономорфизации во все дырки, тоже не может не радовать.

Конечно, ее авторы ничего не понимают в сборке, потому что она принудительно лезет в вашу систему - https://github.com/CuarzoSoftware/Louvre/blob/main/src/meson.build#L31-L34

В общем, штука интересная, конкуренция - хорошо.

#cross, будни #bootstrap

Продолжаю тему кросс-компиляции в macos, https://xn--r1a.website/itpgchannel/1444

Прошла буквально неделя, а я уже умею собирать кросс-сборки довольно нетривиальных (использующих графику и прочие GUI) программ.

Вот, например, вам бинарник dosbox, статически слинкованный под macos-arm64, с linux-x86_64 host.

Без зависимостей от всяких всратых libSDL.dylib/libSDL2.dylib/etc.

(понятное дело, что он не полностью статически слинкован, это невозможно под macos, потому что там поверхность взаимодействия с системой - 100500 closed source фреймворков)

Мне интересно, будут ли с этим бинарником какие-то проблемы, связанные с таким необычным способом сборки, позапускайте (malware not included).

Решил посмотреть, что там в стане врага у конкурентов, у них все тоже неплохо - есть как минимум одна популярная библиотека для разработки композиторов - https://github.com/Smithay Там, конечно, не весь стек на Rust, но, тем не менее.

И, вот, интересный scrollable (https://xn--r1a.website/itpgchannel/1437) tiling compositor на его основе - https://github.com/YaLTeR/niri Посмотреть я его пока не посмотрел, но выглядит неплохо.

https://github.com/CuarzoSoftware/Louvre/blob/main/LICENSE

Слона-то я и не заметил.

Бибилиотека под GPLv3, а, значит, использовать ее никто не будет.

А если у библиотеки нет пользовательской базы, то в ней нет багфиксов и развития.

Есть, конечно, небольшое количество устоявшихся библиотек под #GPL, но они погоды не далают.

Забавно, я все еще думал, что такое бывает только в интернете, пока не нашел у себя в логах CI:

libc++abi: terminating due to uncaught exception of type std::__1::system_error: thread constructor failed: Resource temporarily unavailable
libc++abi: terminating due to uncaught exception of type std::__1::system_error: thread constructor failed: Resource temporarily unavailable
libc++abi: terminating due to uncaught exception of type std::__1::system_error: thread constructor failed: Resource temporarily unavailable

Теперь думаю, как чинить.

Потому что, понятное дело, libc++/musl такой патч не возьмут.

Вообще, конечно, надо бы устроить рубрику "смешное в сборочных логах", вот сегодняшний улов:

ld.lld: error: undefined symbol: thiswillneverbedefinedIhope

https://github.com/ocornut/imgui/releases/tag/v1.90

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

Это вообще какая-то совершенно потрясающая вещь - в списке каждый раз 10 - 20 новых приложений, это примерно столько же, сколько во всем Gnome core.

Судя по всему, на imgui очень легко писать сложные gui, нужные для тулинга, и которые нужно написать быстро, а завтра - выкинуть. И в этом процессе нет места вылизыванию blur на уголках окон по 100500 раз.

Короче, промышленный инструмент, а не вот эти ваши изыски над css.

Мне очень импонирует идея gui как очень тонкой прослойки над системным 3D API, потому что все классические gui типа qt/gtk, которые интегрировали 3d постфактум, сделали это плохо, неполно, и поэтому ты не знаешь, какая часть сцены у тебя отрендерится в 3d, и что приведет к тому, что случится 100500 копирований какого-нибудь буффера из/в память видеокарты.

К сожалению, в Linux 3d драйвера - это .so в userspace, вместо того, чтобы быть каким-нибудь dbus daemon, который бы умел кешировать и компилировать шейдерные программы, что не очень изящно ложится в мою модель статической линковки (бинари довольно заметно распухают, это не то чтобы сильно важно, но как-то "неаккуратно").

Поэтому я, конечно, очень жду, когда gui можно будет компилировать в что-то типа #WASM #WASI, и чтобы 3d драйвера жили исключительно в одном бинаре с WebAssembly VM, о как. Это, если что, не влажная фантазия, у вас прямо сейчас так работает webgl в браузере!

За последние несколько дней вышло:

* 3 минорных версии libheif
* 2 минорных версии libde265
* 2 минорных версии libaom

Это жжж неспроста, они там явно что-то судорожно чинят!