Будни #bootstrap #gold #gir

Гля чо у меня есть!

pg:~/ix ls .../...-bin-gir/lib/girepository-1.0
cairo-1.0.typelib
DBus-1.0.typelib
DBusGLib-1.0.typelib
fontconfig-2.0.typelib
freetype2-2.0.typelib
Gio-2.0.typelib
GIRepository-2.0.typelib
GL-1.0.typelib
GLib-2.0.typelib
GModule-2.0.typelib
GObject-2.0.typelib
libxml2-2.0.typelib
Vulkan-1.0.typelib
win32-1.0.typelib
xfixes-4.0.typelib
xft-2.0.typelib
xlib-2.0.typelib
xrandr-1.3.typelib

На самом деле, это значит, что у меня случился локальный прорыв в борьбе с gobject introspection (писал про это в https://xn--r1a.website/itpgchannel/1253)

Я сумел собрать g-ir-scanner в статически слинкованный бинарь (напомню, там python, .py скрипты, и модуль _giscanner, который в оригинале идет в виде .so)

Вкратце скетч построения:

* Сборка этого пакета хочет за один присест построить как тулзы, так и _giscanner.so, ну и сгенерить .typelib файлы для всего glib. Мне пришлось это декомпозировать на части. Первым делом я собираю питонячий модуль в виде .a файла, при этом мне нужно убедить родную сборку этого пакета, что у нее уже есть готовые тулзы. Я заменил готовые тулзы на пустой скрипт, который ничего не делает - https://github.com/pg83/ix/blob/main/pkgs/lib/gi/repository/bootstrap/t/ix.sh#L10-L11

* Так как он ничего не делает, то потом надо убедить make install, что нужныке файлы таки сгенерились (они будут пустые) - https://github.com/pg83/ix/blob/main/pkgs/lib/gi/repository/bootstrap/t/ix.sh#L16-L19C20

* Далее я раскидываю поличившиеся артефакты (модуль, и скрипты) правильным образом, как будет ожидать дальнейший шаг - https://github.com/pg83/ix/blob/main/pkgs/lib/gi/repository/py/ix.sh

* После чего я строю статический конструктор, который зарегистрирует модуль _giscanner в машинерии питона по импорту модулей - https://github.com/pg83/ix/blob/main/pkgs/lib/gi/repository/py/register/ix.sh#L14 (боже, благолови Сишку, что там можно везде написать void*, без всякого дурацкого манглинга!)

* Дальше я линкую все 3 сущности, которые я описал выше, в один модуль - https://github.com/pg83/ix/blob/main/pkgs/bld/gir/scanner/unwrap/ix.sh#L17-L20, который, по удачному стелению обстоятельств, представляет из себя монобинарь с g-ir-scanner. На ходу пришлось подпатчить скрипт, чтобы модуль _giscanner импортировался корректно.

* Ну а дальше, имея готовый https://github.com/pg83/ix/blob/main/pkgs/bld/gir/unwrap/ix.sh#L12, и используя фичу сборки этого пакета с внешним g-ir-scanner (для кросс-компиляции), можно построить настоящие .typelib.

Отдельно можно упомянуть:

* https://github.com/pg83/ix/blob/main/pkgs/bld/gir/unwrap/ix.sh#L22 - если компилятор, который дергает g-ir-scanner, собирает с -O2, то все обламывается на том, что g-ir-scanner не может просканировать заголовки glib, из-за разного поведения G_LIKELY/G_UNLIKELY в дебаге и релизе.

* В процессе работы g-ir-scanner компилирует тулзу, слинкованную со всеми нужнымии библиотеками, и через ldd пытается определить, что же это за библиотеки. Это пришлось зафейкать - https://github.com/pg83/ix/blob/main/pkgs/lib/gi/repository/py/ix.sh#L13-L14

* https://github.com/pg83/ix/blob/main/pkgs/bld/gir/unwrap/ix.sh#L5-L7 - ну и пришлось влинковать в разные программы кучу всякого рода заглушек, которые строят фабрику для dlopen() - https://github.com/pg83/ix/blob/main/pkgs/lib/glib/dl/gobject/ix.sh - вот так, например, выглядит экспорт всех символов из libgobject-2.0.a в мою машинерию.

Короче, это такой маленький шедевр, искусство статической сборки!

(телегу я пока с этим g-ir-scanner не собрал, по причинам, непосредственно с этим текстом не связанным)

Пересобрал. Удивительно, но оно даже работает.

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

Вот, например, набор патчей, связанных с ranges - https://github.com/pg83/ix/blob/main/pkgs/bin/telegram/desktop/unwrap/ix.sh#L122-L139

Не знаю, современный С++, наверное, уже слишком сложный, чтобы там завелась жизнь компиляторы могли его понимать однозначно.

Наверняка функция, на которую я заменил ranges::contains, компилируется в 100500 раз быстрее, но кому это важно?

https://www.phoronix.com/news/wlroots-Tearing-Control-Merged
https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3871?s=09

Я так понимаю, это дает нам объяснение того, почему Hyprland прогнулся под атакой #ddv.

Потому что от Hyprland есть какое-то количество PR в wlroots. И, вот, например, PR по ссылке выше - висел себе 10 месяцев, а тут взял и смержился.

Совпадение?

Вышел python 3.12

Думаю, самая крутая его фишка - это https://docs.python.org/3.12/howto/perf_profiling.html#perf-profiling

Одной строкой - интеграция с perf record/report.

Да, да, в python появился нормальный профайлер!

Тут, конечно, можно устроить срач на тему, что, если вы запускаете профайлер для python, то вы заранее делаете что-то не так. Но, тем не менее, штука очень крутая.

https://www.cppstories.com/2023/monadic-optional-ops-cpp23

Текст про расширения std::optional в c++23.

Чувак, на голубом глазу, считает, что пример из https://www.cppstories.com/2023/monadic-optional-ops-cpp23/#the-c23-way-monadic-extensions лучше читается, чем пример из https://www.cppstories.com/2023/monadic-optional-ops-cpp23/#traditional-approach-with-ifelse-and-optional-c20

Первый пример, конечно, более компактен, но проще читается код по второй ссылке, потому что он:

* немного более рыхлый
* не требует держать в голове дополнительной семантики для своего понимания
* явный control flow

С точки зрения перфа, кстати, не очень понятно - в первом примере, кажется, кода может быть выполнено больше, потому что nullopt нужно "пробулькать" по всей цепочке, но это не точно.

https://cstheory.stackexchange.com/questions/53343/recent-advances-in-computer-science-since-2010

Коллега задается вопросом, а что интересного случилось в CS с 2010 года?

А ничего интересного не случилось, инкрементальные улучшения там и тут.

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

https://www.bitecode.dev/p/python-312-what-didnt-make-the-headlines#%C2%A7the-performance-let-down

Тут вот коллега пишет, что python 3.12 не быстрее 3.11 на 5%, а довольно значимо медленнее (для теста использовался https://github.com/python/pyperformance).

"You'll notice that 14 tests run faster, but 79 run slower"

Да и даже по wall time всего теста там видно замедление.

Эх, где те (недавние) времена, когда нам обещали 50%-ое ускорение на каждый мажорный релиз?

#fast_python

https://www.phoronix.com/news/Glibc-LD-Nasty-Root-Bug

"We successfully exploited this vulnerability and obtained full root privileges on the default installations of Fedora 37 and 38, Ubuntu 22.04 and 23.04, Debian 12 and 13; other distributions are probably also vulnerable and exploitable (one notable exception is Alpine Linux, which uses musl libc, not the glibc)"

#stal/ix, по понятным причинам, данной уязвимости не подвержен.

Астрологи уже в IT

Programmer memes

У нас уже 6 зеркал, и есть дока, как запилить свое!

https://github.com/stal-ix/stal-ix.github.io/blob/main/MIRROR.md

Одно из зеркал - http://ix.samokhvalov.xyz/ - мое.

Я совершенно случайно прочел договор с провайдером, и выяснил, что белый IP у меня уже давно есть, просто по умолчанию. Ну а домен я зарегал уже очень давно, просто на всякий случай.

Под это дело я запилил runit юнит для #stal/IX:

# ix mut system bin/ix/mirror \
    --port=8080 \
    --user=mirror \
    --wd=/home/mirror
# mkdir /home/mirror
# chown mirror /home/mirror

Не могу не похвастаться тем, как этот юнит устроен, конкретно - программная его генерация:

https://github.com/pg83/ix/blob/main/pkgs/bin/ix/mirror/unwrap/ix.sh

Прямо классно, как я его собрал из маленьких запчастей. Особенно доставляет, что я забыл, как в Go делается парсинг command line (бывает, когда в голове с 5 языков на постоянной основе), и просто сгенерил программу, в которую зашиты настройки из вызова ix mut выше:

https://github.com/pg83/ix/blob/main/pkgs/bin/ix/mirror/serve/serve.go#L6-L7

(я не уверен, что эта простая программа не сможет прочесть что-нибудь не то, но у меня кроме кеша там вообще ничего нет, поэтому пофиг)

https://github.com/pg83/ix/blob/main/pkgs/bin/ix/mirror/serve/ix.sh#L5

Можно было бы вообще inline, без sed, но так проще, потому что не надо думать про escaping.

(do not do this, kids, at home)

#mirror

#rant

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

Вот, и 3.12 версия - не исключение.

Система сборки стала игнорировать *disabled* модули в Setup.* - https://github.com/python/cpython/blob/main/Modules/Setup#L19-L21

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

Как я когда-то уже шутил, мне кажется, что авторы некоторых OSS проектов зарабатывают деньги на том, что готовят желающим сборки без всех этих извращений с динамическими #plugins.

Иначе я это объяснить не могу.

Ладно, конечно могу - всем просто похер на этот механизм, вот он и ломается, почем зря.

К счастью, мой враппер над компилятором давно, и с легкостью, справляется с такой засадой (он просто собирает .a из тех же .o, вместо .so) - https://github.com/pg83/ix/blob/main/pkgs/lib/python/3/12/ix.sh#L19

Еще они украли к себе в исходники какую-то более хорошую модную автоматически верифицируемую реализацию хеш-функций (https://github.com/python/cpython/tree/main/Modules/_hacl), а вот addincl не сделали, пришлось сделать самому - https://github.com/pg83/ix/blob/main/pkgs/lib/python/3/12/ix.sh#L14

Снова похвастаюсь своими сборочными файлами - https://github.com/pg83/ix/blob/main/pkgs/lib/python/3/12/ix.sh

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

Все же, нет сборочной системы хуже, чем gnu #autohell.

(давние читатели, наверное, заметили, что я держу две системы сборки в "самых худших" - cmake, и gnu autohell, а вот кто из них хуже - это уже дело ситуативное)

У нее есть такой хитрый режим сборки, когда в одну папку можно положить несколько отдельных проектов на autohell, написать один общий configure, и оно будет как-то пытаться все это собрать.

Прямо очень условное устройство таких проектов:

# cat configure
...
sh A/configure
sh B/configure
sh libC/configure
...

Так собираются gcc, gdb, и, вот, gettext - https://github.com/autotools-mirror/gettext.

Иногда мне нужно декомпозировать сборку таких проектов, например, в случае gettext - чтобы отдельно собирать инструментарий gettext, и отдельно - libintl.

Так как такая схема сборки косая и кривая, разработчикам, которые ее используют, приходится жестить:

* разработчики gettext/tools захотели напрямую заиспользовать исходничек из соседнего проекта - https://github.com/autotools-mirror/gettext/blob/master/gettext-tools/src/Makefile.am#L295. Ну и просто добавили его в свой Makefile!

Казалось бы, что может пойти не так?

Все шло совершенно так, пока кто-то не захотел в этот вот localealias.c добавить include на генерируемый в процессе сборки файл (вот исходник для файла - https://github.com/autotools-mirror/gettext/blob/master/gettext-runtime/intl/libgnuintl.in.h,как он по цепочке попадает в localealias.c - неважно)

Понятное дело, что теперь сборка всего проекта получила race, и теперь он не может быть собран параллельно, нужно в определенном порядке позвать configure и make в этой общей структуре проектов, чтобы эти неучтенные зависимости были готовы, когда реально нужны.

Можно ли это как-то починить (если считать, что эта зависимость там реально нужна)? Без перехода на более хорошую систему сборки, или глубокого рефакторинга сборочных файлов старой - сомневаюсь.

Я это починил так:

* https://github.com/pg83/ix/blob/main/pkgs/bin/gettext/unwrap/ix.sh#L34 - занулил плохой файл

* добавил зависимость от libintl (где есть нужный объектный код) в сборку gettext/tools - https://github.com/pg83/ix/blob/main/pkgs/bin/gettext/unwrap/ix.sh#L11

Мораль? Как обычно, ее нет.

Ну не прошло и двух лет, как коллеги озаботились проблемой воспроизводимости сборки Python - https://sethmlarson.dev/security-developer-in-residence-weekly-report-13

Им тоже, наверное, надоело, что кто-то где-то накосипорил, и потом получаются битые и хуй знает как работающие configure скрипты.

Я уже как-то писал (https://xn--r1a.website/itpgchannel/776), и напишу еще раз - при всех прочих равных я стараюсь брать автоматически сгенеренный tgz из системы контроля версий (ну или напрямую git clone), нежели чем tar.xz, "сваренный" каким-то человеком из хрен знает каких исходников. Большое поле для злоупотреблений, или для человеческих ошибок.

#maskray, #llvmweekly

Очередной зажигательный текст от нашего коллеги - https://reviews.llvm.org/rG904b3f66f59e

TL;DR - новая эвристика в алгоритме, который пытается наиболее оптимальным образом (видимо, с точки зрения заданного perf/call graph) распределить код функций по бинарнику.

Говорят, более хорошо учли instruction cache, и все такое.

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

Наверное, можно примерно себе представить самый тупой алгоритм, который попробует все возможные взаиморасположения функций, посчитает для каждого такого расположения теоретический perf (с точки зрения кеша инструкций), например, запустив монтекарлу (вероятности перехода между функциями мы знаем из call graph, вроде, больше ничего и не нужно).

Ну а как сделать что-то такое "быстро", с ходу совсем не очевидно.

Пишут, что ажно +1% перфа, по сравнению с предыдущим алгоритмом.