https://github.com/hyprwm/Hyprland/pull/3366

#ddv - хуемразь и ебаный нарцисс, не знаю, что про него еще добавить.

Пара цитат:

https://github.com/hyprwm/Hyprland/pull/3366#discussion_r1329091508

"Do not harass, intimidate, or in any other way discriminate against anyone, particularly with respect to traits including but not limited to their sex, religion, race, appearance, gender, identity, sexuality, and so on."

А теперь для самых наблюдательных - какие споры посчитал возможным иметь #ddv? (спойлер - про политику сраться можно)

https://github.com/hyprwm/Hyprland/pull/3366#issuecomment-1727815552

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

https://github.com/hyprwm/Hyprland/pull/3366#issuecomment-1728007656

Тут он пишет, что назвать его "нарциссом" - это нарушение CoC, nuff said.

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

#hashicorp

OpenTF переименовали в OpenTofu.

Переименовали, да и хер с ними. Просто хороший повод, чтобы вспомнить всю эту ситуацию.

Мне в голову пришла мысль, что у компаний, когда они начинают говорить "ну вы знаете, нам нужны бабки на развитие продукта, поэтому хер вам теперь, а не open source", на самом деле, есть разумный способ получить финансирование разработки.

Отдай проект community, например, в ту же Linux/Apache Foundation, сообщество получит контроль над разработкой, а взамен (от крупных корпораций, которые получат представительство в этом проекте) предоставит деньги.

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

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

https://marc.info/?l=openbsd-tech&m=169519004327392&w=2

Короткий текст про hardened malloc из openbsd, и как он помогает отлавливать ошибки:

"I'm happy to say two of the more complex ones are (being) fixed: one turned out to be a reference counting bug in firefox. See http://undeadly.org/cgi?action=article;sid=20230912094727

The other, a write after free that crashed the X server when running picard was diagnosed by me. This one was a bit nasty, as it required instrumenting malloc to print some extra info to find the root cause.

The bug is that the call in https://github.com/openbsd/xenocara/blob/master/xserver/Xext/xvdisp.c#L1002 overwrites the first 4 bytes of the chunk next to the one allocated on line 995"

И, попутно, текст про внутренности SCUDO (тоже hardened malloc, используется в Android) - https://trenchant.io/scudo-hardened-allocator-unofficial-internals-documentation/

В очередной раз дебажил проблему в #mesa.

Это уже какое-то дежавю - каждый новый релиз mesa приносит мне новый веселый черный экран.

Самое забавное - что я не могу написать ни одного нового слова по этому поводу, потому что про все эти проблемы в mesa я уже писал, просто они стреляют снова и снова:

* https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/amd/vulkan/radv_physical_device.c?ref_type=heads#L1839-1842 - ошибка случается вот тут. И тут же происходит полная херня, потому что мы меняем текстовое описание ошибки на целое число, значение которого позже теряется в потрохах всего этого лапшеобразного кода. То есть, вместо простого grep мне пришлось пару часов трассировать этот код в gdb.

* https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/amd/vulkan/radv_physical_device.c?ref_type=heads#L121-122 - а вот тут суть ошибки. Про него я тоже рассказывал. Эти упыри хотят кешировать шейдеры (кстати, отдельная тема - где это вообще нужно, кроме как на перфтесте какого-то сотрудника Valve, которому нужно натянуть на очередное фиолетовое?), а в качестве части ключа хотят использовать некую сущность, которая однозначно бы идентифицировала эту конкретную сборку mesa, чтобы в кеше не было пересечения. А для этого они используют какую-то магию динамического линковщика, чтобы узнать что-то персистентное для какого-то заранее известного адреса в своей программе - https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/util/disk_cache.h#L111

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

Вот нахуй так говнокодить? Почему нельзя попросить вендоров просто записать при сборке какой-то build id?

Я залечил это, подменив реализацию этих функций на более подходящую для статлинковки реализацию - https://github.com/pg83/ix/blob/main/pkgs/lib/mesa/t/ix.sh#L84-L93

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

https://archlinux.org/packages/extra/x86_64/gumbo-parser/

Так, ну раз Arch переехал на Гришину версию (https://gitlab.archlinux.org/archlinux/packaging/packages/gumbo-parser/-/commit/55a259dddedfac62147b6a042fbddf1ba817dee0), то и нам не зазорно, так думаю!

Снова про #mesa

В цитируемом посте я писал, как ловко запилил процедуры "вычитания" одной статической библиотеки из другой, и почему мне пришлось так делать для сборки mesa.

К сожалению, эта процедура оказалась не очень "робастной" (то есть, апдейт на новую версию был сопряжен с трудностями) - иногда в этих .a оказывался символ с одинаковым именем, но с разной семантикой. В обычной жизни это был какой-нибудь неэкспортируемый из .so символ, и оно как-то жило, ну а у меня случались всякие разные артефакты из-за этой процедуры "вычитания".

Поэтому, в итоге, я решил прекратить экономить на спичках, и сделал по рабоче-крестьянски:

* Условный загрузчик плагинов я оставил как есть
* Ко всем символам, которые были в драйвере opengl, я добавил префикс "o_"
* Ко всем символам, которые были в драйвере vulkan, я добавил префикс "v_"

После чего слил драйвера для opengl и для vulkan в одну общую библиотеку. Да, она получилась больше по размеру, потому что некоторые одинаковые символы получили уникальные имена, но зато это стало лучше отражать то, как жти символы используются в .so (они там тоже дублируются). Ну и исчезли ошибки линковки, когда один и тот же символ объявлен в двух библиотеках.

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

https://flak.tedunangst.com/post/www-which-wasm-works

Вот, коллега тоже сталкивается с проблемами "а как же запустить простую программу, собранную в WebAssembly".

При этом коллега не собирал ничего сложного, а "всего лишь" собрал JpegXL кодек.

В общем, пользовательский опыт в #wasm, если не брать песочницы браузеров, пока довольно неубедительный.

Будни #bootstrap

Вот есть такой https://github.com/microsoft/DirectXShaderCompiler

Он мне, сам по себе, не нужен (хотя стараниями Valve теперь DirectX есть и под Linux), но он нужен для сборки #AMDVLK (мне все хочется пощупать альтернативную #mesa-е реализацию).

В целом, он собрался без особых проблем, за исключением получения version info из git при сборке. Вообще, получить свою версию из .git чекаута хотят многие проекты, и бОльшая часть из них косячат.

Вот, и этот проект смешно накосячил.

https://github.com/microsoft/DirectXShaderCompiler/blob/main/utils/version/gen_version.py - скрипт, пытающийся получить version.

Обратим внимание на https://github.com/microsoft/DirectXShaderCompiler/blob/main/utils/version/gen_version.py#L39-L42, тут сразу несколько ошибок:

* самая очевидная - нельзя так ловить все ошибки, потому что можно проглотить ошибку в ситуации, когда глотать ее нельзя (например, .git есть, но он как-то испорчен)

* чуть менее очевидная - этот скрипт ведет себя неожиданно, когда команды git нет в PATH. Потому что subprocess в этом случае кидает FileNotFoundError (поубивал бы за это, если честно), а не CalledProcessError.

* парсинг информации от git не обернут вот в такой fail safe try/catch. То есть, ошибку от git игнорируем, а невозможность распарсить кривой результат - не игнорируем.

Ну, то есть, коллеги не смогли правильно закодить то, что они на самом деле хотели - вернуть какое-то дефолтное значение, если получить реальную информацию не получилось.

Поэтому мне пришлось запилить специальный fakegit для этого проекта, который всегда выходит с ошибкой:

https://github.com/pg83/ix/blob/main/pkgs/bin/dxsc/ix.sh#L25

Потому что мой стандартный fakegit не сработал, по причинам, изложенным выше.

Мораль? Мораль, наверное, такая - код по обработки ошибок гикто не тестирует, потому что это сложно, и он способен сам давать наведенные ошибки, когда начинает срабатывать!

https://github.com/epasveer/seer

А вот вам классный GUI над gdb в ленту.

Я, знаете ли, не люблю пользоваться таким в реальной жизни, потому что:

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

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

Но вот, на днях, пришлось дебажить #mesa, недавно рассказывал про это, а она написана так, как будто у ее разработчиков есть очень хороший визуальный отладчик, если вы понимаете, о чем я. В таком случае можно, потому что построить ментальную модель это лапши уже решительно невозможно!

Ну и наткнулся на этот seer:

* Не требует KDE/GNOME, работает на чистом QT6
* Просто собрался и заработал, без завязок на X11, и вот это вот все.

Понятно, что это не интегрированный отладчик - языка он не знает, по клику мышкой переменнные не показывает. Но исходники цепляет исправно, за переменными можно следить через консоль в gdb, и этого мне хватило.

После перехода на clang17, в выходные перешел на libc++17.

В отличие от прошлого раза (можно почитать в цитируемом посте), все прошло более-менее норм, даже получилось избавиться от polyfill на ranges и fmtlib, потому что в libc++17 format и ranges уже норм.

Из интересного - libc++ перестали поддерживать использование себя с кодом на старых стандартах (с++11 точно, а может, еще и старше тоже). Заметил я это при сборке gcc, для них пришлось оставить libc++16. Благо, сборка это позволяет - https://github.com/pg83/ix/blob/main/pkgs/bin/gcc/10/ix.sh#L4

Самый страшный код, который может встретить разработчик на C++:

struct X {
    X() {
        Initialized = true;
    }

    ~X() {
        Initialized = false;
    }

    auto y() {
        if (Initialized) {
            ...
        }
    }
};

(тут не надо искать подвоха, что y() вызывается в конструкторе или деструкторе, нет)

Будни #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 нужно "пробулькать" по всей цепочке, но это не точно.