Оказывается, инкапсуляция - это вот это вот, а не то что вы там себе думали!

Как я и говорил, случился релиз, и даже +1 patch - https://github.com/transmission/transmission/releases/tag/4.0.1

Я сразу не написал про это, потому что у меня, почему-то, падал gtk port.

Наконец, разобрался, рассказываю.

Там, по всему коду, появились вот такие вот глобальные объекты - https://github.com/transmission/transmission/blob/main/gtk/DetailsDialog.cc#L2008

Они стали предметом initialization order fiasco, потому что, в случае использования динамических библиотек, порядок выполнения конструкторов более определен, чем в случае статической линковки (например, можно гарантировать, что статические объекты зависимой .so будут сконструированы раньше, чем объекты программы).

Запилил следующее преобразование всех исходников - https://github.com/stal-ix/ix/blob/main/pkgs/bin/transmission/gtk/unwrap/ix.sh#L67

Оно все такие глобальные объекты заменяет на синглтон Майерса. И перенаправляет все вызовы в него, с помощью препроцессора - https://github.com/stal-ix/ix/blob/main/pkgs/bin/transmission/gtk/unwrap/ix.sh#L68

Вроде, работает!

Xочет кто-нибудь это запушить в upstream? Почет, слава, вот это вот все.

#gavin, будни #bootstrap

Коллега сошел с ума, и запилил зависимость bc install script от bc, что, конечно, доставляет - https://github.com/gavinhoward/bc/issues/63

https://github.com/gavinhoward/bc/blob/master/scripts/safe-install.sh#L28

Я эту проблему решил, собрав bc 2 раза - один раз для host, и тогда мы можем пользоваться свежесобранным bc - https://github.com/pg83/ix/blob/main/pkgs/bld/bc/ix.sh#L8, и второй раз для target, где мы просто делаем зависимость на предыдущий target - https://github.com/pg83/ix/blob/main/pkgs/bin/bc/gavin/ix.sh#L9

Ну, такое.

Правда, такой финт ушами приходится делать вообще для всех скриптовых языков (perl - https://github.com/pg83/ix/blob/main/pkgs/bin/perl/ix.sh#L11, python, ruby), которым вынь да положь свой рабочий интерпретатор во время сборки.

А чем bc хуже?..

Не сошел с ума, а просто ошибся! https://github.com/gavinhoward/bc/issues/63#issuecomment-1443908686

(кстати, напомню тем, кто к нам недавно присоединился, что мы тут любим сумасшедших, они делают все самое интересное)

https://www.phoronix.com/news/Mesa-Zink-DB-Descriptor-Mode
https://www.phoronix.com/news/Mesa-RADV-Cyberpunk-2077-RT

Несколько новостей про #mesa, в том числе, вышла новая мажорная ее версия, 23 - https://www.opennet.ru/opennews/art.shtml?num=58705

И я решил, что больше ждать не могу, надо обновляться. Обновиться я не мог целый год, потому что в 22.1 сломали настройку контекса в #zink + radv, так, что у меня по разному в разных релизах отваливались куски браузера #epiphany.

В итоге, я обновился, но #webkit использует канву без 3d ускорения, все остальные приложения работают "как надо".

Я было соорудил кадавра, чтобы WebKitWebProcess использовал старую mesa, 22.0, но потом решил, что поддерживтаь такое в долгосроке не хочу.

Так же я попробовал, например, собрать весь мир с radv + zink, а браузер и webkitproc c radeonsi, но оно тоже, почему-то, не полетело.

https://research.swtch.com/telemetry-opt-in

shit storm победил, и телеметрия будет opt-in

https://www.kitware.com/import-cmake-c20-modules/

А вот, например, текст от Kitware, про поддержку модулей в cmake.

Про то, как они пропихивали динамические зависимости в разные там ninja/clang/gcc.

Если честно, когда я прочел про то, что они запилили свой форк ninja в 2015 году, для поддержки модулей в fortran, и смогли его смержить в upstream только недавно, после появления модулей в C++, я заплакал кровавыми слезами, и дальше читать не стал.

#cmake

https://github.com/harfbuzz/harfbuzz/issues/2524#issuecomment-1437382934 #harfbuzz

Потрындел с matthiasclasen и behdad про эту circular dep.

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

В целом, я их понимаю (хотя понять != простить), потому что запилить новый пакет и протащить его во все downstream дистрибутивы - то еще развлечение.

#mesa #rant

https://gitlab.freedesktop.org/mesa/mesa/-/issues/6578#note_1795307

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

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

Дело еще осложняется тем, что падает worker в webkit, которых всегда запускается строго больше 1, это число не конфигурируется, и падает оно прямо на старте. То есть, нельзя получить устоявшуюся конфигурацию процессов, приаттачиться к нужному, и подебажить.

Такое ощущение, что в #mesa, что в #webkit, славно потрудились над job security, ага. Отлаживать это невозможно от слова совсем.

#bootstrap

У меня, знаете ли, часто зудит мысль, что clang + musl - не самая популярная связка компилятора и libc. А один умный человек мне однажды сказал, что наиболее безглючный код - это тот, который позвали наибольшим возможным числом способов, желательно, в gdb.

Код под Linux чаще всего собирается с gcc + glibc, а под mac, где используется clang, собирается другой набор программ, и с другой libc.

Поэтому, когда я вижу вот такое, с новым выпуском clang:

.../parameter/array.h:85:23: warning: 
    object backing the pointer 
    will be destroyed at the end 
    of the full-expression 
    [-Wdangling-gsl]
        gchar * str = g_strdup(os.str().c_str());
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~
.../include/glib-2.0/glib/gstrfuncs.h:212:51: 
    note: expanded from macro 'g_strdup'
    const char *const __str = _G_STR_NONNULL (___str);
                                                  ^~~
.../include/glib-2.0/glib/gstrfuncs.h:157:29: 
    note: expanded from macro '_G_STR_NONNULL'
#define _G_STR_NONNULL(x) ((x) + !(x))

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

https://gitlab.gnome.org/GNOME/glib/-/blob/main/glib/gstrfuncs.h#L207 - вот тут написано, буквально, следующее - "для константных строк в gcc применим какую-то всратую оптимизацию, без нормально определенной семантики, и которая будет ломаться от gcc к gcc, потому что это не С, и на этот код примерно всем насрать". А когда clang решит, что достаточно хорошо поддержал эту никому не известную упячку из gcc, будем в нем ломаться вдвойне.

Я, от греха подальше, раздефайнил эти оптимизации к херам - https://github.com/pg83/ix/commit/b38e152954363020588192f88c70b47b410c2257

Это, так сказать, был пассивный #hardening.

А есть еще и активный.

Например, по тем же соображениям, я "отменил" UB при переполнении целых чисел, ну и strict aliasing заодно. https://github.com/pg83/ix/blob/main/pkgs/lib/build/opt/safe/ix.sh

Ну потому что clang смотрит на код не совсем так, и, наверняка, проэксплуатирует UB, незаметный при сборке с gcc.

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

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

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

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

Для этого начал пилить свой xdg portal - https://github.com/pg83/portal

Для этого мне пришлось познакомиться с dbus вплотную, хотя я очень не хотел это делать, потому что было понятно, что это страшное УГ. Ниже не исчерпывающий список, а так, для примера:

* https://github.com/godbus/dbus/blob/master/_examples/server.go#L12 - куски xml, которые напрямую пишутся в wire protocol, для интроспекции. (Во flathub xdg portal оно еще и конкатенацией строится, да).

* Нет общего дерева сервисов, ну или я что-то сильно не понял. Казалось бы, сервис - это путь объекта в какой-то иерархичной модели + интерфейс, которй он реализует. Но нет, сервис уникально идентифицирует (service_name, path, interface), то есть, иерархий объектов произвольно много. Я не понимаю, как это объяснить, кроме как пресловутого "не договорились" - кто-то хотел путь в виде A.B.C, а кто-то - A/B/C, сделали оба варианта.

* Великолепное решение проблемы долгих ответов в асинхронной модели. https://flatpak.github.io/xdg-desktop-portal/#idm9 TL;DR - клиент присылает уникальный endpoint, по которому клиент поднимает микросервис с одной ручкой, которую должен дернуть хендлер оригинального запроса в сервере. Леденящий душу пиздец, чо.

Красивое про #sat

https://ahelwer.ca/post/2018-02-13-z3-firewall/

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

"ix run" (или любая другая метапоисковая система), конечно, сильно меняет подход к разработке. #ix_run #dev_shell

Свой go-шный portal я собираю, например, вот так - https://github.com/pg83/portal/blob/main/build.sh

ix run set/dev/go -- go build

"Где-то там" строится временный #realm, со всем нужным окружением, в котором запускается свежесобранный go build на мой проект. Оверхед - доли секунды.

Хочется cgo, и зависимость от какий-то C-шной библиотеки?

ix run set/dev/go --cgo lib/gtk/3 -- go build ...

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

Анонс курса про Rust в вышке, например

Анонс курса раста в следующем году. Распространяйте среди первокурсников, чтобы все выбирали нас!

Тут вот Данила "наше все" #Lemire запилил бенчмарк https://lemire.me/blog/2023/03/03/float-parsing-benchmark-regular-visual-studio-clangcl-and-linux-gcc/

Что он бенчмаркал, непонятно (может, свою fast_float, может, компиляторы, а может, виндовый шедулер), потому что:

Под винду сравнил VS/std vs. VS/fastfloat vs. clang/fastfloat, ну и добавил, для пикантности, сравнение с gcc/wsl/???.

Знаете, когда смотрят на перф, то стараются изменять 1 параметр, и пишут, что меняют, чтобы было понятно, что происходит.

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

Не бенчмаркайте так, как это сделал Лемир!