Продолжал эксперименты с #imgui

Выяснил, что оно фигачит 60rps даже в моменты, когда это не требуется от слова совсем - https://github.com/ocornut/imgui/pull/5116

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

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

Нет в жизни счастья :(

https://github.com/carbon-language/carbon-lang/issues/1519#issuecomment-1192285832

"We think we've made it pretty low-overhead to grab Carbon and start building all the same. And no one else should need to interface with us at this point, it is much much too early. So for now, it seems reasonable to just focus on what works well for the team. Does that make sense?"

UPD: тут вот меня спрашивают - зачем писать, если все равно ничего не поменяется?

Как говорит моя любимая Шульман, "только сопротивление дает субъектность".

Я напишу, что не согласен, ты полайкаешь, или тоже напишешь - глядишь(с вероятностью 5%) что-то и поменяется.

А не напишешь - точно ничего не поменяется.

Вот так вот поторопишься, похвалишь, а потом БАЦ!

* emptty жрет по 10 мегабайт памяти на процесс, и это только чтобы залогинить меня в систему. На 5 tty будет 50 мегабайт. mingetty жрет примерно в 100 - 1000 раз меньше.

*

go: downloading github.com/google/g
    o-querystring v1.1.0
# github.com/gopasspw/gopass/
    internal/backend
    internal/backend/registry.go:85:45:
    internal compiler error: 
    assertion failed

Please file a bug report 
including a short program 
that triggers the error.
https://go.dev/issue/new

Причем, что важно, компилятор Go написан на Go, и double bootstrapped, то есть, следа от моего кода, который мог бы быть бажным(типа musl + allocator) в нем нет.

У меня тут сегодня замес про Go и разработчиков на нем. Прочтите посты под тегом #школота перед прочтением, это довольно важно.

Я там сформулировал следующую мысль - развитие программиста процесс многосторонний, и, что, когда программист вообще научается программировать, у него и код падать перестает, благодаря накопленному опыту.

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

Тогда был пример про #rust, сегодня будет пример про #go.

По ссылкам я писал, что хотел бы часть репозитория написать на Rust/C++ - конкретно, выполнялку графа и process supervisor.

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

Но тут я решил, что, наверняка же, так как задача очень хорошо ложится на Go, то ее уже решили, и нефиг велосипедить.

Вот, пожалуйста, https://taskfile.dev - 5.5К звезд на гитхабе, хорошая, популярная вещь. Принимает граф в виде yaml/json, не совсем как у меня, но за полчаса я написал конвертор графа.

Мой тестовый граф был 5 мегабайт yaml, пара сотен нод.

Эта МЕРЗОТА на этом графе съела 5 ГИГАБАЙТ физической памяти, заняла 16 ядер моего CPU только под свой код, и так и не выполнила задачу, вот с таким сообщением:

task: [/ix/store/oZAVqMSU6AQOJIdR/touch] 
    echo aW1wb3J0IGFwgbmV3KQojIGV1Yw== | 
    base64 -d | /bin/ix misc runpy 
    /ix/store/5qYMWLFMqGDGHJII/automake-1.16.5.tar.xz 
    /ix/store/oZAVqMSU6AQOJIdR/automake-1.16.5.tar.xz 
    sha:f01d58cd6d9d77fbdca....69
task: maximum task call exceeded (100) for task 
"/ix/store/XG2mYVvSFINEVPWm-bin-file/touch": 
probably an cyclic dep or infinite loop

ЕБАТЬ, кто это написал, что это за пионеры, кто это вообще может использовать в проде?!?! СУКА, у тебя весь граф с зависимостями на руках, какой, в жопу, "probably"???

#goвно, #наgoнакодили, у меня для этого только такие теги.

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

А теперь наезд на go по существу.

Компания Google умеет ставить задачи, и умеет решать задачи.

Компания Google поставила себе задачу "запилить язык, чтобы даже долбоебы могли на нем программировать". Они эту задачу успешно решили, но зато теперь долбоебы программируют именно на Go.

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

Это было за упокой, а теперь за здравие.

После такого печального опыта я решил, что уж как-нить напишу очередную выполнялку графа сам, и написал!

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/assemble/as.go

Заняло это у меня часа 3 времени, потому что по сути, до этого больше 5 строк на Go я не писал, а тут примерно все - и парсинг json, и корутины, и запуск процессов, и IO.

Программа успешно выполняет мой граф, жрет 0% CPU, 20 мегабайт памяти, по сути, только загруженный json. Я тут поддержал все фичи старого выполнителя, в том числе, отдельные пулы для CPU и network узлов, выполнение сверху вниз, а не снизу вверх(если цель готова, то не проверять сначала ее зависимости, этим много кто грешит), и так далее.

КМК, я там даже придумал пару вещей, которых не видел в интернетах, например, как из sync.Once сделать элегантную кеширующую future. Семафор "бедного человека" на каналах - это довольно общее место.

Я тут принципиально не хотел брать готовые библиотеки:

* Ну c'mon, а вы первую часть поста прочли?

* чтобы не зависеть от закачки из интернета, мне тут нужно принципиально "чистую" сборку.

Короче, написал, и уже успел заменить старый executor на питоне в моем проде. Размер бинаря упал с 10 до полутора мегабайт.

А теперь самая "постыдная" часть этого поста.

Мне, неожиданно, понравилось! Без всяких скидок. Вот этот вот класс программ - fail fast в качестве обработок ошибок, IO, граф, корутинки - писать удобно и приятно, я думаю, я потратил меньше времени, чем бы сделав это на python, ну и результат "интереснее".

Думаю, если бы там появилась серьезная обработка ошибок, я бы что-то сделал на тему https://stackoverflow.com/questions/25025467/catching-panics-in-golang

#panic

Но, я еще раз повторю, разработчики на Go - это та еще школота, и скачав рандомный пакет из инторнетов, даже с кучей звезд, ты заранее не узнаешь, кто его написал - седой аксакал из Google(и там все будет заебись), или вот такое вот "taskfile".

https://thephd.dev/finally-embed-in-c23
https://news.ycombinator.com/item?id=32201951

Наверное, только ленивый не рассказал про embed в C, я же хочу сосредоточиться вот на каком аспекте этого события - про комитеты, лоббирование, и почему С/С++ #cplpl_doomed

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

https://news.ycombinator.com/item?id=32202627
https://news.ycombinator.com/item?id=32204481

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

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

* Есть платформы, на которых даже нет файлов.

* Есть платформы, на которых byte - 32 бита, и это не PDP в музее.

* Наши ошибки могут стоить ажно 1% перфа(тут я хочу напомнить, что недавно из-за ABI комитет по С++ отказался ускорить С++ на 5 - 10%).

И, поэтому, конечно, совершенно нормально, что на мелкую фичу, которая НИКАК с этим не связана:

"Are we're really talking about compiling on such platforms?"

"No, I'm mainly talking about targeting. My point is not so much about embed, but rather that, almost anything you assume you think you know about how computers work isn't necessarily true, because C targets such a wide group of platforms."

потрачено 5 лет.

Ну, то есть, нам рассказывают как все сложно на target, чтобы потом сказать, что 5 лет обсуждали, есть ли понятие "файла для embed" на host платформе, или нет.

Про комитеты, С/C++, и вообще:

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

* Если ты разобрался в сложной теме, например, в модели памяти С/C++, то у тебя довольно мало реальных стимулов эту модель упрощать. Если в ней станет легко разобраться - а зачем нужен ты и твой ценный сейчас опыт? А сложных и интересных задач "приделай сюда еще одну заклепку", которые все еще более усложнят - завались.

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

По какому номеру в списке идет упрощение модели памяти и починка range-based-for-loop, вы сами можете дофантазировать.

https://www.bmj.com/content/378/bmj.o1808.full

Не очень про IT, но, КМК, подходит для данной аудитории. Красивое.

https://news.ycombinator.com/item?id=32160703
https://www.reddit.com/r/worldnews/comments/w3hy8i

Немного отполировал новый executor, теперь он выглядит неплохо даже с точки зрения человека, привыкшего к динамическим исключениям:

Небольшой runtime, https://github.com/pg83/ix/blob/621140f98bb48fe06e42702813551d23ee94a8f4/pkgs/bin/assemble/as.go#L14-L60, и можно писать вот так:

https://github.com/pg83/ix/blob/621140f98bb48fe06e42702813551d23ee94a8f4/pkgs/bin/assemble/as.go#L332-L336 - поимка исключения.

https://github.com/pg83/ix/blob/621140f98bb48fe06e42702813551d23ee94a8f4/pkgs/bin/assemble/as.go#L298 - бросание исключения.

Можно написать еще немножко кода, чтобы работал return value из этих блоков try/catch, но пока не нужно.

Я соврешенно не претендую на первенство, или на то, что это написано наилучшим образом, но, КМК, написать вот такие 50 строк кода очень полезно для понимания того, как работает runtime языка.

Ну и это необходимо, чтобы сделать библиотеку из executor engine, потому что обрабатывать ошибки по всему стеку, как принято в go, я не хочу, но и паниковать в библиотеке нельзя.

To be absolutely clear: летать исключениям между модулями - не надо. Но в рамках одного модуля считаю вполне ОК. Про историю с переписыванием парсера json с такой схемы на обычные return value, и про небольшой профит в перфе - знаю, КМК, тут этот опыт нерелевантен.

А еще улучшил свой текстовый редактор, чтобы он вызывал gofmt на выходе. https://github.com/pg83/ted/blob/main/ted#L1097!

https://www.opennet.ru/opennews/art.shtml?num=57552
https://lwn.net/Articles/901816/ (к сожалению, за paywall)

Две статьи про весьма схожие темы.

Фактически, речь идет про взаимодействие торговых марок и распространение кода.

TL;DR - то, что тебе дали право скомпилять Rust, и даже раздавать результат, ты не факт, что можешь назвать конечный продукт Rust. А то, что Debian состоит из OSS, не дает тебе право завести сайт debian.suxx, и поливать его там грязью.

Интересные вопросы, на которые я не умею отвечать:

* Могут ли авторы gccrs и mristc называть свои компиляторы "компиляторами языка Rust".

* Нужна ли тут добрая воля со стороны владельцев на Rust trademark.

* А если gccrs/mrustc отойдут от политики партии, и начнут сами как-то модифицировать язык? Сможет ли владелец на trademark запретить распространять это как "компилятор Rust"?

* Может ли сторонний компилятор называться в системе "rustc"?

* Короче, может ли Rust Core Team устроить тут vendor lock in?

И другая плоскость.

* Насколько open source защищен вот с точки зрения "тивоизации" торговыми марками? Ну, то есть, реально себе представить систему, в которой компилятор rust не может называться никак, кроме как rustc, а торговая марка запрещает так называть производные работы.

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

А как еще надо назвать сайт, который рассказывает про проблемы debian? А https://nosystemd.org тоже надо закрыть, если бы systemd была бы торговой маркой IBM/RH?

#harfbuzz

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

Родина помнит, Родина ждет, Родина тебя непременно найдет

Вышел harfbuzz 5.0.0(а через 2 часа 5.0.1, хе-хе), и я вспомнил про эту кольцевую зависимость.

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

Кстати, надо как-нибудь рассказать про прикопанную кольцевую зависимость между EGL и wayland, которая разрешается с помощью inline кода в момент генерации протоколов из .xml файлов.

Откуда там кольцевая зависимость?

Ну, каждый же хочет быть "точкой входа" для всех остальных. поэтому:

auto drm = createDRMContext();
auto egl = createEGLContext(drm);
auto wayland = createWaylandContext(drm);
// alternative
auto eglWayland = createEGLContext(wayland->drm);

никому не подходит, это же зашквар! Это же признать, что ты не являешься первичным провайдером графического контекста!

Все хотят форму

xxx = createXXXContext(/* no args */);

И прикапывают возникающую кольцевую зависимость через какой-нить глобальный контекст.

#carbon - это какой-то фрод.

Уже 20к звезд на гитхабе, но.

pg-> find . | grep '\.cpp' | wc -l
94

Кодогенератором там даже и не пахнет, есть лексер и куски парсера, видимо, для поддержки compiler explorer.

Мне стало интересно, как там выглядят исключения.

Лично я бы надеялся на что-то типа автоматического превращения вызываемой функции в OrError<V, Dyn<std::exception>>, или что-то в таком духе(ну и чтобы pure carbon программа не требовала бы С++ runtime), и даже решил почитать про это design doc.

Увы, меня ждала неудача, все(!) что я нашел, это вот этот вот огрызок:

### Support for C++ exceptions without bridge code

Carbon may not provide seamless interoperability support for C++ exceptions. For example, translating C++ exceptions to or from Carbon errors might require annotations or bridge code, and those translations may have some performance overhead or lose information. Furthermore, if Carbon code calls a C++ function without suitable annotations or bridging, and that function exits with an exception, the program might terminate.

Про обработку ошибок в целом тоже ничего интересного не нашел, плохо искал?

Короче, это пока даже не декларация о намерениях, это сбор дешевого PR.

Лежит ffmpeg.org. Хорошо так лежит, качественно, git, список зеркал - все лежит.

Скачать исходники непонятно как, последняя версия, которую положили на sourceforge - 3.0. На github непонятно какого качества mirror, без релизов - https://github.com/FFmpeg/FFmpeg. Можно взять тег, но это такое, конечно.

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

Короче, не кладите все яйца в одну корзину.

А я, конечно, и хотел бы завести кеш, но негде пока.

https://nnethercote.github.io/2022/07/27/twenty-years-of-valgrind.html

20 лет valgrind.

К сожалению, в свое время valgrind не сумел стать тем, чем стали asan и mssan сейчас.

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

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

Ну и в прод такое не выложить, под нагрузку, а asan/msan - вполне можно, если аккуратно.

Впрочем, какие-то тяжелые ночные тесты даже и сейчас гоняются под valgrind, потому что он ловит, все же, больше, чем asan и msan.

А профайлу от valgrind(про IC) я и сейчас доверяю больше, чем perf record.

Я, знаете ли, крохобор.

Поэтому:

* Редко используемые программы я сжимаю с помощью upx. Ну, вот, например, бинарь пакетного менеджера ix - это статически слинкованный питон с кучей frozen модулей, в несжатом виде занимает 20 метров, в сжатом - 8. Люди его запускают редко, зачем хранить нули на диске?

(кстати, хозяйке на заметку - upx(для сжатия бинаря) - это очень простой способ сделать mlock для бинаря, который вы не можете пересобрать, при условии, что у вас нет swap. Потому что без swap системе некуда вытеснить анонимный mapping)

* Бинари, которые нужны для функционирования самого пакетного менеджера, типа bsdtar, или curl - я собираю в lite конфигурациях, без ненужных опций. Мне тут, на днях, пришло в голову, что тот же curl я использую без проверки подлинности скачанных данных, потому что у меня есть md5/sha, полученные по другому каналу. Поэтому я собрал curl с mbedtls вместо openssl, и без поддержки сертификатов вообще. Получилось 700к вместо почти 10 мегабайт. Пару ссылок оно скачать не смогло с какой-то странной ошибкой, ну и ладно, всегда есть запасной вариант.

* Осталась важная вещь - убрать python из executor вообще, чтобы духу его не было в базовой системе, прямо сейчас он используется на самых ранних стадиях bootstrap.