Я й досі використовую #Qbs як білд-систему. Не тому, що він прям суперкрутий, а тому, що #CMake я не можу терпіти ще більше. На додачу ми в пет-проєкті використовуємо #Conan, щоб ставити деякі залежності типу того ж spdlog.

Ізі-пізі все, на маку потестив — працює збс. На вінді друган потестив — теж працює. А на віндовому CI, бляха, ні!

Перша проблема: для конана треба, щоб профіль існував. І я начебто навіть всі необхідні дані й так через команд-лайн передаю, але чогось скаржиться все одно. Найпростіший спосіб створити — це викликати:

conan profile detect

Втім не все так просто. Наш self-hosted ранер для GitHub Actions працює як сервіс від імені NETWORK SERVICES, щоб після ребуту він одразу запускався, а не чекав, доки користувач залогіниться. Тож я не можу просто зайти на віндову тачку та викликати цю команду. Ну ок, додав та прибрав степ, який це один раз робить. З цим порішали.

Та не збирається все одно, собака! І найболячіше те, що з одним і тим самим команд-лайном воно видає різні помилки залежно від того, чи я запускаю це сам руками від свого імені, чи це робить ранер.

Схема така, що за задумом треба використовувати Conan як точку входу, а той своєю чергою вже викликає Qbs. Але мене це дратувало, тож я написав так звану Probe для Qbs, яка перед всіма іншими діями викликає Conan, а вже потім продовжує свою роботу. І навіть тут якась чортівня: результати виклику conan install з однаковими параметрами й всім однаковим під тим самим користувачем(!) відрізняються, коли я запускаю це через Qbs або коли вручну. Тобто у мене вже є щонайменше три різні помилки, і я тупо не бачу жодного звʼязку між ними. Наче сліпий навпомацки, намагаюся щось правити й «дивлюся» на результат.

З самим Conan до речі окрема історія теж. У нього налаштування залежать від платформи. Наприклад, на macOS треба передавати os.version, а на Windows версію не можна вказувати. Тобто воно його не ігнорує, а прям каже: «Ти шо, не передавай мені це!» — і падає з помилкою.

Яке ж лайно! 💩 …в якому мені доведеться порпатися далі.

Добре, попередній допис я ще вчора написав. Але вдень у мене відпустка, тож пофіксив я все вночі 😅

Проблема №1: ручний запуск #Conan відрізнявся від запуску зсередини #Qbs. Для останнього є приблизно такий код:

const p = new Process()
p.start(executable, args)

Тут args — це список рядків. І у мене там були рядки виду '-s:a compiler=msvc', '-s:a compiler.cppstd=20' тощо. Прикол у тому, що, схоже, Qbs їх додатково бере у лапки, і це неправильно парситься саме на деяких компах з віндою 🤯 Пофіксив, замінивши кожен з сеттінгів на ['-s:a', 'compiler=msvc'], а потім зробивши .flat(). Важко сказати, як я до цього прийшов — чисто чуйка.

Проблема №2: ручний запуск qbs build з тими самими параметрами, що на CI, видавав інший результат. Виявилося, що… 🥁 параметри були не тими самими. Я помилився в одному символі, коли вказував архітектуру 🤡, а Qbs нічого проти не має. Хочете x64_86 — легко! Хочете x86_65 — будь ласка! Яке ж дно 🤦🏻‍♂️ Але принаймні на тому самому компі зібралося успішно.

Проблема №3: білд на CI все одно не працював. Тут було вкрай важко збагнути, що не так. Допомогла тільки тулза PsExec від SysInternals, бо на вінді немає простого вбудованого способу запустити щось від імені іншого користувача. Коли вже отримав термінал під NETWORK SERVICES, то виявилося, що… conan.exe просто відсутній 😂 І Qbs на це навіть ексепшн не кинув. Типу: «немає бінаря, що я маю запускати? та й хуй з ним, поїхали далі!»

Як так трапилося? Раніше у мене стояв Conan 1.x, який я встановив через Chocolatey. Ну й, власне, він бінарь кудись до себе кидав у C:\ProgramData\chocolatey\bin\, який є у Path. Але я зробив апгрейд до Conan 2.x (власне, у цьому й полягала задача). І виявляється, що для другої версії Chocolatey просто качає інстолер, котрий раніше не існував, і запускає його. А останній ставиться у C:\Program Files\Conan\conan\ та додає цей шлях в Path тільки для поточного користувача 🤦🏻‍♂️ Короч, додав у системний — і все полетіло.

І шо я думаю… Збирання C++ — це, звісно, доволі важка задача, бо є купа нюансів, є легасі рішення тощо. Але це все не виправдовує погані #тулзи. Чи можна на C++ писати хороший тулінг? Та звісно! Але таке враження, що більшість плюсистів просто не знає, що це таке, бо не має досвіду з іншими адекватнішими мовами з нормальною інфраструктурою. Тобто звикли постійно страждати, і вже важко цього позбутися, чи шо? Нє, ну серйозно…

Друган підкинув кльову статтю про порівняння архітектурних рішень NT та Unix. Дуже цікава!

Якщо зараз різниця між операційними системами з погляду на набір фічей по моїх особистих відчуттях і справді дещо розмита, то на початку 90-х ситуація була прямо протилежна, й NT завоював своє місце під сонцем корпоратів не дарма. Тож хороша архітектура має свої очевидні переваги, навіть якщо за 30 років так вже не здається.

Було б цікаво ще щось подібне почитати про BeOS. Для мене це трохи міфічна ОС, бо до моменту, як у мене зʼявився компʼютер, вона вже померла. Тож я поверхнево знайомий тільки з її нащадком Haiku OS.

До речі про останні 30 років… Якщо поміркувати, то не так вже й багато за цей час зʼявилося нових операційних систем на власному ядрі, які б мали бодай якийсь комерційний успіх чи хоча б потенціал для цього. Окрім Haiku (буквально синонім успіху… ахах 🤣) на думку спадають тільки Fuchsia від гугла, HarmonyOS від Huawei та, може, ще та ОС, що стоїть у Nintendo Switch.

Що ще? macOS/iOS? Ні, там якийсь мікс Mach та BSD, які зʼявилися раніше. Symbian? Теж ядро зʼявилося раніше. Всілякі Android та Tizen — це Linux.

Серед хобі-проєктів ще є чи були якісь цікаві. Той же TempleOS, Redox (хоча це юнікс, але ядро своє наче), ReactOS (з притиреними частинами з вінди). Ще щось?

Я чого питаю… Ось інженери, що розробляли NT-ядро, сіли, зважили все і розробили нову архітектуру з нуля з урахуванням тих знань та уроків, які пропонувала історія. А чого зараз так не роблять?

Зізнавайтеся, кого ще компанія сьогодні привітала з «міжнародним» Днем програміста 💩? Так мило з їхнього боку 😡

О ні, здається, я вже знаю, до чого все йде…

Пан Соловйов такий якось: «Он ту книжку по 💻 Clojure почитай», — каже. Й ось у мене вже 📝 імакс на компі! 😰

Є у мене значить плагін для MkDocs, який перетворює посилання виду

[[some folder/some page]]

у посилання виду

[some folder/some page](full-path/to/some%20folder/some%20page.md)

так, як це робить Obsidian. Тобто можна навіть не повний шлях вказувати, й воно знаходить найближчий файл з таким іменем і підставляє все правильно.

У ⬇️ фіча, що зображення вставляються абсолютно аналогічним способом, тільки треба ! додати перед цим. І обсідіан цим скористався, тож в ньому ![[image.jpg]] теж працює. І для цього мені навіть плагін не довелося модифікувати, бо перетворення [[...]] на [...](...) спрацьовує до того, а знак оклику там вже є.

А от з відосами в обсідіані працює, а у мене ні. Це тому, що MkDocs на синтаксис виду ![alt](url) генерує

<img src="url" alt="alt" />

Звісно, браузер тільки зображення так вбудовувати вміє.

Знайшов якийсь чужий екстеншн для Python-Markdown, який наче мав би працювати з коробки, але якогось хєра ні, тож сів писати свій.

Роблю приблизно таке: якщо знаходжу <img>, в якому src вказує на відео, наприклад, video.mp4, то заміняю його на

<video>
  Формат не підтримується
  <a href="video.mp4">video.mp4</a>
  <source src="video.mp4" type="video/mp4" />
</video>

Ну, так воно мало б працювати принаймні, але ж ні! Натомість було

<video>
  Формат не підтримується
  <a href="../video.mp4">video.mp4</a>
  <source src="video.mp4" type="video/mp4" />
</video>

Бачите? Воно ../ додало. І прикол у тому, що це як раз правильний URL згідно з тією структурою, яку генерить MkDocs.

Я дуже довго дуплився і не міг збагнути, в який момент і хто це робить, аж доки не втямив, що в самому MkDocs на цей випадок свій додатковий Treeprocessor, котрий відносні посилання адаптує, от тільки робить він це виключно для <a> та <img>, але не для <source>. Наразі просто захардкодив додавання ../, але треба зробити аналогічним чином, як у них, мабуть.

Та допис насправді навіть не про це, бо це був вступ 😅

Спробував я тут ваш хвалений uv замість poetry, якщо вже нагода випала. Він типу на расті написаний, все вміє, мовляв, дуже швидкий і все таке (як з рекламного буклета). І знаєте шо? Виявляється, що він і справді норм!

Але є певні «але».

По-перше, не всі #тулзи можна ним поставити. От наприклад, ansible — поки що ні на відміну від pipx. По-друге, білд-система все одно потрібна, тож наразі використовую hatch, бо poetry не по стандарту пише у pyproject.toml.

По-третє, я якось не певен щодо підходу писати тули для якоїсь однієї мови — іншою мовою. Про це вже пан yakimka писав у себе в каналі, тож краще там почитайте. З одного боку кожен хороший програміст володіє багатьма мовами anyway, проте, з іншого є відчуття, що в довгостроковій перспективі це може негативно вплинути на спільноту 🤔 Хз.

Та що я точно можу сказати про uv: працює ця падлюка напрочуд швидко. Мені як раз друган днями жалівся, що доки тестував автоматизації робочих процесів у своїй 💻-репі на GitHub Actions, то виюзав всі халявні 2000 хвилин. І ось тут ця тула прям стане в пригоді, бо, думаю, можна на порядок пришвидшити встановлення всіх залежностей.

Думайте, що вам важливіше 🎤

Ух, як же я ненавиджу, коли хтось наламує юзкейси, що у користувачів вже буквально у мʼязовій памʼяті!

Днями в черговий раз спаплюжив #UX для всіх Telegram Desktop. Я вже бачив купу битих посилань в каналах, тож проблема не тільки моя.

Короч, раніше як було, якщо хочеш посилання додати в текст? Виділяєш, тиснеш ⌘K, відкриваєтся попап, в ньому вставляєш лінку через ⌘V, тиснеш Enter. Все.

Якийсь, не побоюся цього слова, геній в телеграмі вирішив щось заімпрувати і зробив так, що при відкритті попапа вміст буфера обміну вже там — залишається тільки Enter натиснути або OK.

От тільки текст посилання в попапі не виділений, тому якщо суто механічно натиснути ⌘V, то воно його ще раз додасть в кінець 🤬 Уїбанство.

(Ну принаймні скопійовані з 1Password паролі не світить — я перевірив. Схоже, фільтрує по майм-типам вміст буфера, перш ніж вставляти).

Якщо хтось чекав на можливість нарешті використовувати #QML у ваших WPF-програмах під 💻 (вже ніхто не чекав), wait no more.

Схоже, втративши купу ринків, 💻 раптово збагнула, що було б непогано мати офіційні байндінги до інших мов окрім 💻 та 💻, і хтось там у них написав кастомний нейтів хост під .NET.

Можливо, #QML — це наразі одна з найвагоміших причин, чого я досі тримаюся C++. Я просто дуже полюбляю робити UI, і саме завдяки цим двом мовам я здатен досягати найшвидших та найякісніших результатів. Python відштовхує своєю повільністю виконання та труднощами розповсюдження готових програм. А під інші мови всі байндінги сумнівної якості й написані хтозна-ким.

Це не значить, звісно, що я зараз раптово перейду на 💻, але може вони нарешті подивляться в бік чогось зручнішого та сучаснішого.

Ух, 💻 прям активізувалася 🤔 Нещодавно релізнули екстеншн до vscode 💻 з language server для #QML (екстеншн лайно, проте, як перший крок норм), а зараз ось зробили плагін для Gradle, щоб легше було під Android 💻 збирати.

«Цікава» штука тут у мене трапилася. Є проєкт, в якому прописані деякі депенденси на пакети в #Conan:

fmt/9.1.0
spdlog/1.11.0

Чудово все працювало. От тільки останній реліз був один рік тому, а відтоді ми його майже не чіпали.

А сьогодні я сів його зібрати, а він мені каже: «Хєр тобі! Конфлікт версій, йопта!» — Типу fmt/9.1.0 конфліктує з вимогою fmt/10.0.0, що вписана в spdlog.
WHAT. THE. ACTUAL. FUCK⁉️

Як таке взагалі можливо? Який прикол у існуванні пекедж-менеджера, якщо можна поміняти залежність заднім числом? Та навіть у пайтоні такого немає! 🤯

І тепер я ставлю fmt/10.0.0, а воно не збирається, бо там зник якийсь template, від якого ми наслідувалися. Оце жесть. Щиро дякую за можливість вбити зайвий день на рівному місці.

Тему керування залежностями вже обсмоктали всі підряд по своїх каналах, і я був певен, що втримаюся, але дупця згоріла добряче з цього. Отож…

Нагадую, що єдине адекватне рішення для депенденсі-менеджера — це:
1) не давати можливості заливати різні пакети під однією й тією ж версією: якщо версія вже існує — то або інкременти її й роби нову, або досвідос;
2) не давати можливості вказувати в залежностях діапазони версій на кшталт pkg/[>=6.4 <6.8], pkg/[~1] тощо — тільки повна версія;
3) бажано ще й не давати видаляти 😄

«А як же автоматично отримувати мінорні оновлення?» — спитаєте ви. А ніяк! У ваші semver я не повірю доти, доки у прийнятті рішення, яку частину (major/minor/patch) версії треба інкрементити, бере участь людина.

Хтось тут може сказати, що це давно автоматизується за допомогою conventional commits, по яких потім воно нарощує версію в залежності від наявності feat: або fix:. Але ж рішення, що ставити, feat чи fix, все одно приймає людина, тож яка різниця?

Скоро так дограємося, що пральна машинка не ввімкнеться, якщо два тижні нею не користувався через відпустку.

Розповім ще невеличку історію про 💻 та #QML, але не стільки з технічними деталями, скільки з архітектурними.

Отже, частиною Qt є UI-фреймворк під назвою Qt Quick. Він звісно на С++ написаний, але користувачі переважно на QML пишуть. Всі візуальні елементи там є нащадками Item. Ну й за роки розвитку він вже добряче навбирав у себе різних спільних властивостей та став дещо важкеньким.

Серед базових важливих властивостей, що були там з самого початку, є так звані anchors — механізм дуже легко робити flexible UI. Наприклад, пишете

height: 35
anchors.bottom: parent.bottom

і поточний елемент завжди буде 35 пікселів заввишки і завжди прикріплений до нижнього краю контейнера, в якому лежить. Виглядає, як якась потойбічна магія для тих, хто пише на CSS, я розумію.

Хоч на анкорах майже будь-що можна зробити, та не завжди це зручно. Якихось більш високорівневих лейаутів не було, й згодом їх додали окремим модулем QtQuick.Layouts. Відтоді стало можна писати якось отак:

RowLayout {
  TextField { Layout.fillWidth: true }
  Button { text: 'Submit' }
}

Ця штука автоматично позиціює елементи в рядок. Причому поле для вводу текста розтягнеться на всю можливу ширину, а кнопка буде мінімально можливого для себе розміру. Доволі зручно, хоча в певних випадках вкрай важко змусити ці лейаути робити те, що тобі треба, бо вони переускладнені відчутно. Не flexbox, звісно, але у мене в голові червона лампочка складності вже мерехтить.

Та весь кайф був у тому, що ніхто QtQuick.Layouts не навʼязував. Не подобається, як вони працюють? То напиши свій (на C++)! Так і зробив мій друган, що тоді був девелопером у моїй команді. І тепер його лейаут «катається» у сотнях тисяч Мерседесів з MBUX.

Та, схоже, не всім це було до душі. Виявилося, що комусь занадто складно розставляти fillWidth/fillHeight у потрібних місцях 🤦🏻‍♂️ Це, як на мій погляд, не велика проблема, бо QML дозволяє це суперлегко вирішити створенням нових компонентів. Для цього треба або новий файл створити (1 компонент = 1 файл), або прям inline написати на кшталт:

component FormField: TextField {
  Layout.fillWidth: true
}

RowLayout {
  FormField {}
  Button {}
}

Ну, типу… все! Що може бути краще?

Але якийсь черговий геній в Qt знайшов можливість «пакращєння»:
1) він додав у базовий Item властивість sizePolicy, яка має вказувати кьютовому лейауту, чи розтягувати елемент, чи він мусить мати фіксований розмір.
2) Потім він нахуєвертив «sensible defaults» в усі контроли, що наслідують Item, тобто всі кнопки, текст-філди, слайдери й таке інше.
3) Ці sensible(!) defaults миттєво наламали KDE Plasma, де все поплило, бо не такі вони й sensible виявилося.
4) І на додачу, sizePolicy ще й частина private API, тобто для своїх кастомних лейаутів це буде проблематично використати. Отже, QtQuick.Layout тепер прибитий цвяхами до QtQuick.
Наразі вирішили цю фічу зробити тимчасово opt in, однак, проперті вже там, тож кожен Item позаяк займає більше памʼяті, ніж раніше.

А які задачі ви вигадуєте собі на роботі, щоб не складалося враження, що сидите без діла? 🤣

Всі кинулися писати (раз, два) про свій олімпіадний досвід програмування, а у мене такого немає (я тільки був на олімпіадах з історії, української мови та правознавства 😅).

Олімпіади з програмування мені завжди здавалися занадто нудними (і досі здаються), а от усілякі контести я полюбляв. І 15 років тому ми з друзями з універу абсолютно випадково в такому взяли участь.

Це був Sapka Contest, який влаштувала українська компанія Stanfy, що нині вже наче навіть не існує. На все відводився тиждень, під час котрого ми майже не спали та трохи підзабивали на універ 😄

Цікавинкою було те, що вони просто дали jar-ник без зайвих деталей. Тобто жодного завдання не було. Але хтось доволі швидко виявив, що до нього можна підʼєднатися Telnetʼом. Коли ти це робиш, програма тебе вітає та вимагає ввести пароль. Звісно, паролем було слово «пароль» (password). Та програма потребувала ще! )) Підійшли деякі відомі чіти на кшталт iddqd та show me the money.

Коли ти вводив якийсь пароль, програма «активувала» якісь додаткові підсистеми типу «engine» або «satellites». Що це значило, ми не розуміли, та продовжували копати. Окрім цього, на кожен пароль вона видавала якусь нову додаткову інфу. Тут стало зрозуміло, що для пошуку решти паролів доведеться вирішувати алгоритмічні задачки по типу кубика Рубіка, яку вони закодили неправильно 😁, та купи інших (на жаль вже не згадаю конкретніше). Це все через telnet відбувалося, нагадую.

Якусь частину кодів ми дістали шляхом розвʼязання цих задач. Дуже зручно було, що вони одна від одної не залежали, тож легко було займатися цим паралельно. Тим часом деякі інші команди пішли іншим шляхом, та просто відреверсили той jar-ник, діставши всі коди одразу. Ми спочатку вагалися, але врешті десь на четвертий день просто зробили те саме та заюзали всі чинні коди одразу.

І зʼясувалося, що цей jar-ник — сервер для мультиплеєрної гри на кшталт Bomberman 💣🤯 (always has been, так би мовити). А всі ті «підсистеми», що ми активували кодами — це ввімкнення capabilities для вашої апішки. Наприклад, engine дозволяє вашому гравцю рухатися, а satellites дозволяє орієнтуватися у просторі (грубо кажучи, запитувати, що в сусідніх клітинках). HOW COOL IS THAT⁉️

Отже, справжньою задачею цього контесту було перемогти у поєдинку bomberman-ботів! І ми сіли писати власного бота: BFS й ось все це. Деякі коди активували бонуси, що рандомно зʼявлялися на полі: на швидкість переміщення, кількість бомб, розмір вибуху і т.і. — як у справжньому бомбермені. Чомусь ми зробили ставку на кількість бомб, до того ж наш алгоритм переміщення був трохи глючний, тож врешті ми зайняли всього шосте місце.

Фінальне змагання проходило в Києві. Ми не могли цього пропустити, тож, звісно, поїхали. Там була купа народу, і якщо дивитися відос дуже уважно, то можна навіть побачити нас і ще багато кого. Макса Іщенко, наприклад )

Перемогла врешті команда THIRTEEN, один з представників якої пізніше писав на Haskell транслятор з Pascal у JS, а з іншим я згодом працював в одній компанії. І їхня перемога була максимально епічною.

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

Врешті у фінальному поєдинку їхній бот ставив бомбу у центральну клітинку і лишався в ній. За пару тактів до вибуху бот відходив з зони ураження й тут же повертався назад і ставив нову бомбу. І так ігрове поле звужувалося доти, доки не зʼїло всіх, а їхній бот лишився стояти на власній бомбі )

Шкода, що іншого подібного контесту врешті так і не відбулося.

В коментарях до останнього допису про Conan декілька людей зазначили, що найкращим варіантом встановлення залежностей, якщо хочеться, щоб вони самі по собі не наламувалися, досі є кляті git-сабмодулі.

Я їх не люблю, бо в низці випадків працювати з ними незручно. Та чимдалі, то більше схиляюся до тієї ж думки. Це вікове, мабуть.

Але з сабмодулями звісно мало просто додати лінк на чужу репу — треба мати власну копію.

Раніше у мене на NAS стояв GitLab, і це жесть. Я через нього навіть додав оперативи та 2 SSD вставив для кешування операцій, бо інакше воно ледве ворушилося. Там Docker-контейнер, в якому одразу усе: база якась, купа коду на #Ruby ♦️ чи шо там, конфіг на дохуїльйон рядків, Grafana(!) тощо. Потім створюєш собі репу на якийсь прототип, який шкода викинути, а воно там одразу якісь авто-DevOps врубає, ще купу непотрібної хєрні, налаштувань 10 сторінок…

Цього року змігрував на Forgejo, про який згадував, коли писав про Tailscale. А ще це той, на якому Codeberg.org хоститься. Спочатку за звичкою фігачнув у docker-compose сам Forgejo + базу Postgres 🐘 + Tailscale 💠 + nginx… А потім подумав: а нащо мені той Postgres взагалі? З моїми обʼємами даних це 100% оверкіл. І перевстановив з дефолтним SQLite 🪶.

І знаєте, що? Та офігезно взагалі!

По-перше, воно літає. Дуже легке та швидке навіть на моєму Intel Celeron.

По-друге, по фічах мені взагалі нічого не бракує. Майже GitHub зразку пʼятирічної давнини. Але навіть CI вбудований є.

По-третє, є прикольна фіча, коли пуш на ремоут створює репозиторій, якщо його не було. Для домашнього використання — те що треба.

По-четверте, ґітлаб дуже всрато зберігає дані. Там стопіцот тек вкладених і взагалі хтозна-що діється. А у Forgejo просто все розкладене по <org>/<repo>.git. Схоже, тупо голі (bare) репи лежать — легше бекапити, чи, точніш, потім відновлювати.

Ну й наостанок: віддзеркалення працює ізічно, й не треба для нього там якусь Super Pro Enterprise версію за всі гроші планети. Я так налаштував собі декілька мірорів «важливих» репозиторіїв з публічного GitHub, і воно їх само постійно сінкає без проблем. Навіть yt-dlp туди закинув чисто на всяк, бо хто знає, коли «правовласники» знов викрутять ґітгабу яйця.

Щоб ви розуміли ступінь моєї довіри до GitHub: я навіть свої власні репозиторії, що там лежать, на всяк дзеркалюю до себе на NAS цим механізмом. А в деяких випадках взагалі навпаки почав робити: origin вказує на локальний Forgejo, а звідти вже час від часу автоматом пушиться на GitHub.

Короч, Gitea/Forgejo — рекомендую.

P.S. Зі святом всіх, хто боронить Україну будь-яким доступним чином.