Продолжение истории про #lunasvg. #svg

Я закончил на том, что у меня часть иконок была отренжерена через lunasvg в процессе построения пакета с иконками, а часть(которая вне этого пакета) - в процессе работы приложения.

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

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

Я бы тут хотел ткнуть вас куском кода из rsvg/cairo/gdk, который страдает такой херней, но я не сумел, там все слишком запутано.

Чего только стоят несовпадения ARGB/RGBA, где-то используется premultiplied alpha, где-то - нет, premultiplied alpha по разным формулам, все эти поверхности постоянно туда-сюда преобразуются.

Я решил просто потвикать r, g, b, a каналы в разные стороны, и посмотреть, что получится.

В процессе я выяснил:

* g, b каналы никак не использовались, ну, то есть, я мог туда записать все, что угодно.

* r канал давал изменение от цвета фона к ярко-желтому цвету. 0 - фон, 255 - ярко-желтый(нет, это не cmyk, и не прочие модели, по крайней мере, не те, что я знаю).

* alpha канал работал, как надо.

Мое лучшее предположение - что рендеринг symbolic иконки - это, собственно, отбрасывание r, g, b, и использование только alpha компоненты для блендинга между фоном и цветом для рисования.

Желтый? Хер его знает, может, для дебага, может, я вообще неверно все понял.

В итоге, решение вида "оставить только alpha канал для svg, которые загружаются как symbolic иконки", вполне себе сработало, я с лупой не нашел отличий. https://github.com/pg83/ix/blob/main/pkgs/lib/lunasvg/gdk/io.cpp#L100

Так-то это достаточно логично - а как еще наиболее дешево "оконтурить" произвольную svg?

Где это происходит в связке rsvg/gdk/cairo, я не нашел, они большие мастера прятать такое говнецо.

Не помню, рассказывал про свое микросоревнование с самим собой, или нет, беглый поиск по каналу ничего такого не нашел, поэтому рассказываю, тем более, есть повод!

Просто писать код - скучно, это уже давно доведено до автоматизма.

Поэтому я, по крайней мере, для pet project, изобретаю какие-нибудь ограничения, которым дополнительно должен удовлетворять код.

В #ix такое ограничение - это размер ядра(интерпретация пакетов и подготовка графа) в байтах.

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

Нужно мне длинное название метода - значит, будет длинное название! https://github.com/pg83/ix/blob/main/core/package.py#L261

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

Основные источники профита:

* Вынос кода из ядра в шаблоны. Это, кстати, хорошо по многим причинам - чем больше информации в шаблонах, и меньше в ядре, тем точнее uid ноды меняется в зависимости от фактических изменений результата.

* Поиск дублирующегося "смысла" (например, в какой-то момент мне довольно сильно помогло сократить размер понимание, что #realm/env - это точно такая же нода, как и любой прочий пакет, и обрабатывать ее надо тем же кодом)

Довольно долго я держал планку в 40к, при этом добавляя новые фичи, потом, полгода, держался на 50к, но вот последние месяца 2 - 3 забрался за 51, и оно никак не ужималось.

Сегодня я отыграл до 49к, бесплатно добавил новую команду "let", и очень рад этому факту!

"let" - это такой аналог "mut", который не перемещает глобальную симлинку на свежеподготовленный realm/env. Эта команда полезна, когда хочется перед переключением системы на новый root, посмотреть, чего там в нем таки лежит.

(напомню, что, по сути, мой корень - это симлинка на вот такой read only realm)

Как я это ужал?

Я отрефакторил команды mut/let/run/build в фасады к одной простой функции, которая умеет подготовить набор realm для заданной командной строки:

* let - это просто вызов этой функции

* mut - это let + несколько вызовов os.symlink()

Дальше интереснее:

* build - это интерпретация заданного command line в контексте создания нового эфемерного realm.

* run - это build, в финале которого еще запускаем одну команду в свежесозданном окружении.

https://github.com/pg83/ix/blob/main/core/cmd_realm.py#L27 - собственно, вот эти 5 функций, которые позволили мне стереть 1.5k кода!

https://github.com/scandum/rotate

Интересная подборка про разные способы "провернуть"(поменять левую и правую часть с сохранением порядка в каждой из частей) массив.

У меня, когда в таком возникает нужда, в голову всегда приходит один и тот же алгоритм, который по ссылке назвали "Triple Reversal Rotation".

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

В #ix даже как-то возникла такая задача, потому что я принял не очень верное решение, что "верхние(элементы списка) переопределяют нижних", то есть, список зависимостей

{% block deps %}
A
B
C
{% endblock %}

превратится в "-I A/include -I B/include ..."

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

Например, вот тут - https://github.com/pg83/ix/blob/main/core/realm.py#L72-L73

Или вот тут, но тут сложнее заметить - https://github.com/pg83/ix/blob/main/core/package.py#L56

https://github.com/RomanHotsiy/commitgpt

"Automatically generate commit messages using ChatGPT"

Это мы используем.

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

Пишут, что нового кода в Android на Rust становится больше, а на С(и, в меньшей степени, на С++) - меньше.

Это, конечно, очень хорошо.

Думаю, вы уже знаете мою точку зрения, что, с точки зрения безопасности, современный С++(с RAII, контейнерами, и санитайзерами), на практике не сильно опаснее Rust(хотя Rust, конечно, сильно более хайповее!), но вот писать новый системный код на С - так себе идея.

Если честно, то мне, конечно, жаль, что гонку с С выиграл не С++, но и так неплохо получается.

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

И вторая забавная новость.

Чуваки не могут поддерживать проект, потому что чувак с доступами не выходит на связь и не отвечает на звонки.

"Услугами FossHost пользовались такие открытые проекты, как GNOME, KDE, GNU Guix, Xiph.Org, Rocky Linux, Debian, OpenIndiana, Armbian, BlackArch, Qubes, FreeCAD, IP Fire, ActivityPub (W3), Manjaro, Whonix, QEMU, Xfce, Xubuntu, Ubuntu DDE и Ubuntu Unity. "

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

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

Чтобы 1 человек не мог взять все ключи, и не помахать ручкой на прощание.

Вытащу из комментариев.

https://crates.io/crates/fake-static

Баг в компиляторе Rust(висит с 15 года), позволяющий, без применения unsafe, произвольно менять lifetime.

Рекомендуется не использовать в проде! В целом, я всем тоже советую не использовать SEGFAULT в проде, да.

https://daniel.haxx.se/blog/2022/12/06/faster-base64-in-curl/

Тут вот автор curl решил похвастаться, как он ускорил свою же реализацию base64, в xy раз(даже не процентов!).

С точки зрения perf инженегра, это все, конечно, очень слабо:

* Нужно было не велосипедить, а соревноваться со state of the art, хотя бы https://github.com/lemire/fastbase64, или turbo base64.

* Соревновался он с линейным поиском символа в массиве 64 символов - "const char *p = strchr(base64, *s);"

* Таблицы - это для бенчмарков, в цикле. В реальном коде на современных процессорах лучше обращения к памяти не использовать.

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

Мы тут с коллегами выясняли, зачем вдруг antlr стал зависеть от abseil.

Раскопали красивое.

https://github.com/antlr/antlr4/pull/3694/commits/41beb8fe3540114943cb4ee93dafcc170f143c61

"[C++] Introduce synchronization and container abstractions"

А вот так выглядит "container abstraction":

#if ANTLR4CPP_USING_ABSEIL
#include "absl/container/flat_hash_map.h"
#else
#include <unordered_map>
#endif

Я не шучу.

Лучшее предположение - что Гугл занес в antlr, чтобы они, зачем-то, начали использовать велосипед от Гугла, вместо общепринятого класса.

Потому что этот леденящий душу пиздец из макросов я не понимаю как еще объяснить.

В контексте разработческих окружений.

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

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

Что у нас тут интересного?

* Автор пытается делать релоцируемые на fs проекты, вместо content based address. "Пакеты размещаются в отдельном каталоге ~/.tea и не привязываются к абсолютным путям (могут быть перемещены)" Это интересно, но прямо реально сложно, и я пока не нашел у него механизмов, отвечающих за то, чтобы это делать "просто".

* Мякотка, описание сборочного скрипта. https://github.com/teaxyz/pantry.core/blob/main/projects/deno.land/package.yml#L22 - вот это выглядит так себе. Я как-то рассказывал, во что я погружал свою сборку. В yaml я ее тоже погружал, это несложно, потому что большинство того, что я использую - это списки и конкатенация списков. Выглядело это примерно так, как в tea, по ссылке. Проблема с inline shell скриптами, они, на мой вкус, что в yaml, что в языке nix, выглядят херово.

* Довольно богатая метаинформация, например, он знает, что deno умеет интерпретировать javascript/typescript - https://github.com/teaxyz/pantry.core/blob/main/projects/deno.land/package.yml#L11 Это интересно, хотя, с ходу, непонятно, что он с этим делает.

https://www.phoronix.com/news/Linux-6.2-funsigned-char

Интересная (узким специалистам) новость, ядро Linux переходит на сборку с char == unsigned char по умолчанию.

Есть три возможных состояния:

* Везде signed
* Везде unsigned
* На разных платформах по разному

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

Наша монорепа фиксирует везде signed char, это nop на x86_64, и смена дефолта для linux-aarch64 (сюрприз, сюрприз, но там char unsigned по умолчанию).

В целом, я считаю, что unsigned по умолчанию лучше, просто потому что unsigned - это понятный тип, а signed - непонятное нечто. В нашей вселенной не бывает отрицательных чисел так-то! Но, если ты не контролируешь всю кодовую базу(например, тащишь код извне в contrib/), то unsigned char весьма сложно, если вообще не невозможно, пофорсить.

Пожелаем удачи ядру Линуса, особенно вспоминая его способ бороться с багами - https://en.wikipedia.org/wiki/Linus%27s_law

(TL;DR - падать и коркаться будет на наших компах)

Ну и, конечно, с заголовками, которые потребляет userspace, придется быть аккуратнее.

**: про один такой забавный случай - в следующей серии!