https://monaspace.githubnext.com/

Новые #monospace шрифты от github, а это всегда событие!

Из интересного, и чего я раньше не встречал:

"Texture healing works by finding each pair of adjacent characters where one wants more space, and one has too much. Narrow characters are swapped for ones that cede some of their whitespace, and wider characters are swapped for ones that extend to the very edge of their box. This swapping is powered by an OpenType feature called “contextual alternates,” which is widely supported by both operating systems and browser engines"

В каком эмуляторе терминала это работает, кто за это отвечает (#harfbuzz?), и как проверить,что оно срабатывает - я пока не понял.

Будни #bootstrap, #cross

У меня уже довольно давно была поддержка кросс-компиляции с любого host на любой linux, и на всякие нишевые платформы типа #WASI

Вот, добавил darwin-{amr64,x86_64} - https://github.com/pg83/ix/commit/85c66407c092677519f45ee55b265bc272759ad5.

В коммите всякие мелочи, типа {% if linux %} на зависимости, которые не собираются под darwin, типа libsigsegv, libbsd, и так далее.

Так как у меня cross compile даже для host == target, ничего особо сложного в этом не было, все заработало из коробки.

Почему я не сделал это раньше?

Потому что все это время я думал, как половчее попиздить macos sdk!

Компания Apple, как и MS, не очень поощряет сборку не на своих OS/железе. У них это написано в лицензии.

Поэтому есть такой небезызвестный https://github.com/phracker/MacOSX-SDKs - смотреть можно, трогать пользоваться, кажется, нельзя.

При этом, я решал следующие задачи:

* Рандомный васян, скачав #IX, должен "из коробки" уметь собрать любую программулю под macos. Украдет он при этом что-то, или нет, - не мои проблемы.

* Если это запускается на родной платформе для macos, то, по умолчанию, надо брать установленные в систему SDK, и ничего не воровать.

* Если этот код запускается в каком-то частном контуре, то должна быть возможность указать на url, по которому будет лежать цельнопижженый легальный (с точки зрения владельца этого контура) слепок macos sdk. Например, он его купил, но за пределы контура распространять не может.

Соответственно, для васяна я качаю SDK с инторнетов, для host == target сборки даю возможность использовать родную SDK, ну а злые корпорации пусть в своем контуре используют то, что считают нужным, это не мое дело.

Все это я сделал моим любимым способом "dispatch по настройкам во все более специализированный таргет" - https://github.com/pg83/ix/blob/main/pkgs/lib/darwin/c/ix.sh#L3-L12

И сразу добавил нужные мне таргеты в мой CI - https://github.com/pg83/ix/blob/main/pkgs/set/ci/unwrap/ix.sh#L8-L9, это было совсем просто!

С windows sdk все будет, кажется, существенно хуже, потому что найти прямые ссылки на даже "серые" их версии у меня не получается. Везде всратый windows installer, который даже cabextract не берет. А выкладывать пижженый контент от своего имени мне бы не хотелось.

#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 в браузере!