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

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

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