Для разнообразия напишу о том "с чем я сейчас играюсь". Это опять #emacs, но в необычном даже для имаксоводов ключе.

В мире Emacs принято структурировать знания в Org Mode — это наш Notion, Roam (org-roam я тоже начал осваивать наконец-то).

А если структурируемые знания связаны с программированием, то многие присовокупляют и Babel. Это такой способ добавить в заметку фрагмент кода, который можно "запустить", получить результат выполнения в желаемом виде тут же в документе и подать на вход другому фрагменту, потенциально написанному на другом языке — потому название и отсылает к Вавилонской башне. Ещё Babel позволяет писать код с использованием подхода Literate Programming (у меня даже демо использования babel есть). Я этот подход когда-то пытался в массы продвигать, правда, без видимого успеха :Р. Среди имаксоводов LP тоже не то чтобы слишком широко распространился, но многие в таком виде описывают свою конфигурацию, так что умеренный успех всё же имеется!

Это всё очень интересно, но, как я в начале обмолвился, вполне привычно для пользователей Emacs. А рассказать я хотел об eev. Описать вкратце, что же из себя eev представляет, довольно сложно. Это одновременно и способ закреплять знания о собственном исследовании Emacs и не только, так и, в каком-то смысле, стиль жизни — последнее как раз очень по-имаксовски!

eev как подход родился в 90х в результате неудовлетворённости тем, как было принято изучать Emacs как платформу. Изначально это были расставляемые прямо в прозе s-expressions вида (find-file "…/foo.el"), выполнение (evaluation) которых командовало Emacs'у открыть нужный файл с исходниками. Потом в дополнение к искоробочным функциям добавились более выразительные варианты, могущие прыгнуть к нужному месту файла через поиск подстрок. Названы такие фрагменты были исполняемыми ссылками.

Причём сделано было всё максимально агностично к формату самой прозы: все ссылки всегда являются однострочниками на Emacs Lisp, выполняются по принципу "прыгнуть в конец текущей строки и выполнить s-exp, чья закрывающая скобка стоит в конце строки" — да, в середину текста ссылку просто так не вставить, но зато можно ссылки иметь коде на любом языке, в котором есть построчные комментарии. При этом отсутствие сокрытия "адреса" ссылки за описанием преподносится как плюс: вы всегда видите код, который собираетесь выполнить, а значит можете его исследовать — уже благодаря интроспекции самого Emacs. Это с одной стороны перекладывает на вас заботы о безопасности выполняемого кода, с другой же стороны побуждает исследовать саму систему, хакать её в изначальном смысле этого слова. Получаются эдакие hackable notes.

В какой-то момент eev заметил и даже одобрил Столлман. Но он же в итоге и посетовал на то, что пользователь видит код на Lisp, чего в норме быть не должно — это прямо таки маленькая драма в истории eev, упоминаемая в каждом докладе о проекте :Р

За годы были наработаны "find functions" буквально для всего. Можно сослаться на страницу или подзаголовок PDF-файла, на видео в YouTube с указанием временной метки — "переход" по ссылке откроет адрес во внешней программе или, наоборот, отобразит результат в виде тестовой выжимки во временном буфере Emacs. Да, в org-mode тоже кое-какая функциональность для подобных задач есть, но тут целый параллельный мир для меня открылся! В дополнение к наработанным "открывалкам" есть богатый инструментарий по созданию своих, это всё тоже очень по-имаксовски.

Помимо ссылок ещё есть "сессии", когда вы записываете блок команд для пошагового исполнения. Блок начинается с парочки s-exps, открывающих в соседней панели сеанс диалога с интерпретатором, скажем, Python. Затем в блоке идут уже команды для этого интерпретатора. Блок нарочно исполняется не целиком, как это было бы сделано в Babel, а именно построчно — и нарочно же выполняется с демонстрацией результата выполнения каждой команды в соседней панели. Это тоже своего рода исполняемые заметки, но не "сниппеты", а "демо", они же test blocks. Вы, наверняка, встречались с проектом tldr, так вот тут то же самое, но примеры можно выполнять прямо тут же, не копируя в shell. Опять же, очень интересно и очень не мейнстримово :)

Я пока пробую смешивать Org с eev в заметках для себя. Тут я всё же скорее согласен со Столлманом — негоже неподготовленного читателя бросать в яму с острыми с непривычки скобками. К тому же eev привязывает заметки к Emacs в большей степени, чем Org, который за пределами Babel хотя бы просто "рендерить" умеют многие инструменты (pandoc, GitHub/Gist). И тем не менее сама идея исполняемых ссылок мне очень понравилась, буду продолжать исследовать эту тему.

Забыл ссылку дать на вот это видео: https://www.youtube.com/watch?v=86yiRG8YJD0
Там и про драму со Столлманом есть, и про иторию повяления проекта, и вообще видение автора можно прочувствовать. Занятное.

Не могу не поделиться ссылкой на прекрасное:

https://ianthehenry.com/posts/janet-game/

Автор хотел рассказать, как у него получилось пописать игру на языке Janet — это такой маленький диалект Lisp — в связке с Raylib — а это уже библиотечка для кросс-платформенного игростроя. Причем изначально предполагалось, что это будет игра в технологии, а не использование технологий для построения игры (всё, как я люблю!) :)

Начал автор с изучения экосистемы языка. Мне, например, такое нравится читать. И сравнивать с экосистемами, знакомыми мне. В процессе использовался Nix, чтобы тот же Raylib нормально собрался под MacOS (начинаем записывать, про что же ещё эта серия заметок, кроме геймдева!).

Буквально после написания пары функций у автора возникла необходимость тестировать код. Нормальными assertions. А это уже пахнет макросами! В процессе изучения макросоводства в лиспах в целом и в Janet в частности автор и шишек набил, и посравнивал Lisp-1 с Lisp-2 (ссылки на пейперы, цитаты, красота!). Исследовал он всё это в разрезе борьбы с проблемами, которые возникают при разворачивании макроса в окружении, где функции, использованные в теле макроса, были переопределены. Не каждый с такими проблемами вообще сталкивается и уж точно далеко не каждый думает о надёжности макросов наперёд! В итоге автор наделал себе макросов для генерации макросов и сваял тестовый фреймворк — да, для тестирования логики игры, если вернуться по стеку.

Тесты автор решил понаделать и для рендеринга — чтобы глазами видеть косяки. Тут ему пригодился Emacs, который умеет вставлять картинки прямо в код (ага, как DrRacket). Вот только хранить картинки высокого разрешения рядом с кодом автору не хотелось, тем более что игра предполагалась пиксельная и машинерию рисования стоило тестировать на картинках низкого разрешения. Но Emacs-то картинки сглаживает при растягивании так, что пиксели за мылом не видно! А значит нужно… запатчить Emacs. Под MacOS, напомню. С помощью Nix, конечно же! :D

Спойлер: игра в итоге так и не была доделана, хоть и был в итоге написан код, отвечающий за построение области видимости (FOV) — игра предполагала stealth-механики. Про это тоже было довольно интересно почитать!

P.S. В статье есть ссылки на оды любви в языку Janet в стиле "это мой последний язык" (в смысле, что больше ничего не понадобится, настолько хорош). Ходил, читал — забавное!

Я давно интересуюсь хранением знаний, пусть и не выработал пока привычки сохранять всё, что хотел бы хранить. Но способы разные я периодически изучаю.

Когда-то давно, в середине 00х, ещё сидя на Windows, пробовал вести заметки в отдельном ПО, но дело не пошло. Зато написал свою реализацию липких листочков на Delphi, с красивой иконкой, с окном, не использующим стандартные декораций! Но сами заметки так и не приучился оставлять :Р

Уже в 10х были попытки начать вести ZimWiki, заметок десять я туда сохранил, но, опять же, процесс не пошёл. Не прижились и личные блоги. Более-менее что-то начало копиться, когда пересел на #Emacs и Org mode.

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

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

Я даже уже начал обустраивать эту итерацию exobrain по своему вкусу. Сделал себе hotkey, который открывает заметку с именем текущего режима (или создаёт, если таковой нет). Иметь такие заметки очень удобно, когда нужно вспомнить ссылку на документацию к языку или, скажем, функцию Emacs, которая для данного контекста полезна, но нужна редко. Например, внутри заметки к lisp-mode есть Org-Babel-скрипт, который скачивает документацию к ASDF (это инструмент для работы с проектами в Common Lisp) и несколько исполняемых ссылок, открывающих локальную копию документации во внешнем браузере и в eww встроенном в Emacs.

И вот тут хочется отметить саму возможность расширения функциональности ПО, которое хранит ваши знания. Emacs для меня очень ценен тем, что я могу его расширять написанием действительно небольшого количества кода. Да, те же расширения Org Roam невелики и нужны только мне, но на то это и Personal Information Manager!

* * *

Не так давно читал интересную статью: Programmable Notes. Если сократить её до минимума, то автор видит пользу от

- агентов, эдаких пользовательских мини-программ, которые в диалоговом режиме запрашивают у вас данные и уже по ним генерируют заметки;
- программируемых кнопок (в тексте заметок или просто где-то), нажатие которых инициирует запуск агентов или другие действия по автоматизации рутины;
- скриптов, которые перерабатывают данные и находят в них паттерны, связывают заметки вместе, словом, "думают" за вас;
- AI, которые вёл бы с вами разговор хотя бы в виде echo chamber).

А ещё автор несколько раз упоминает агентность) пользователя, вот даже цитата про это:

> Enabling users to design and share their own (tools) is the only way to give people agency over their knowledge bases.

Фантазии автора статьи по поводу AI меня пока лишь позабавили, а вот всё остальное, наоборот, срезонировало! Я могу иметь у себя в Emacs — и имею(!) — и агентов, и кнопки, и скрипты:

- агенты, это org capture — автоматизируемая система создания заметок по шаблонам;
- про кнопки я планирую написать позже, но по сути это могут быть просто функции на Emacs Lisp;
- скрипты тоже пишутся на Emacs Lisp, а для Org Mode есть пакеты вроде org-ql для написания запросов, да и тот же Org Roam хранит метаданные в SQLite.

(опять Телеграм не опубликовал одним сообщением)

Конечно, всё это может показаться сложным для человека, который не хочет ничего "программировать", а хочет создавать интерактивные шаблоны в Notion (есть мнение, что это вполне себе программирование). Люди делают в Notion очень сложные и мощные штуки. И я рад раз них! А мне, вот, не хочется завязываться на сервис. И я строю мою персональную базу знаний :)

Так, подключил дискуссии. Посмотрим, как пойдёт. Предыдущие сообщения нельзя сделать обсуждаемыми, поэтому можно те два выше обсудить под этим.

Buttons

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

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

Emacs ушёл на шаг вперёд: в Org Mode можно добавлять свои типы ссылок, да и встроенных типов предостаточно. Вы можете ссылаться на файлы, статьи встроенной документации, emails (такие ссылки работают как mailto-ссылки в браузере). Можно даже выполнять при клике на ссылку elisp-код или shell-command. Так что в рамках org-файлов ссылки можно смело считать кнопками!

Вот только всю ли информацию можно хранить в .org? Представим, что вы хотите фиксировать процесс изучения языка программирования или хотите сохранить для будущего себя заметки к проекту. Да, всегда можно приложить сбоку .org-файл и располагать в нём ссылки на места в коде, но такой путь привнесёт неявности: вы не видите в коде ссылок на заметки.

Частично решить проблему со ссылками в коде можно решить с помощью комментариев, в тексте которых могут быть написаны ссылки, но это потребует наличия поддержки таких ссылок в редакторе. И это всё ещё будут ссылки для перехода, а не кнопки. А ведь иногда хочется не перейти к заметке, а, скажем, выполнить код примера.

> Но ведь есть же docstrings, скажете вы. И будете правы — есть! Но, увы, не для каждого языка. И Literate Programming тоже не всегда получается применять.

Применительно к Emacs я знаю две реализации кнопок: eev (который я уже упоминал) и GNU Hyperbole. Оба проекта — реальные долгожители. И оба ну очень персональные!

evv

Этот проект опирается на то, что раз уж у нас не редактор, а среда исполнения Emacs Lisp, то почему бы не писать короткие s-expressions в любом месте и не позволять таковые "кликать". С одной стороны человеку, отторгающему скобочки из принципа, такой вариант точно не подойдёт, с другой стороны каждую ссылку видно. То есть вы видите имя функции, которая будет вызвана при выполнении кода. В Org Mode код elisp-ссылок не виден по умолчанию, что может кого-то очень даже насторожить.

Очевидно, что добавить свои виды ссылок/кнопок легко: вы просто пишете больше функций! Автор eev тут не чурается макросов и генерирует функции для открытия PDF в ваших любимых читалках на нужной странице или в позиции первого вхождения такой-то подстроки. В итоге при должной консистентности именования (генераторы её вполне успешно обеспечивают) ссылки ещё и самодокументируются, да и вызвать describe-function можно в любой момент.

Недостаток такого подхода тоже очевиден: вы прямо в файлах, не являющихся кодом на elisp, оставляете кусочки оного. Но для себя так делать можно! Зато кнопки хранятся всегда рядом с тем, к чему относятся и при желании могут быть "выполнены в уме", если Emacs с eev не окажется под рукой (тут тоже важна самодокументируемость).

GNU Hyperbole

Этот проект существует дольше, чем Org Mode, ещё с середины 90х, и успел за это время стать вещью в себе и целой экосистемой. Автор положил в одну коробку всё, что хотел иметь в Emacs: тут и свой outliner, и средство для управления окнами редактора, и система гиперссылок. К счастью, можно использовать не всё и сразу, а только сами гиперссылки (на остальное можно посмотреть, как образчик "проекта на всю жизнь").

Hyperbole предоставляет возможность оставлять в любом тексте ссылки (называемые implicit buttons) либо вообще без какой либо разметки, либо с минимальной вида {google this}. Вы нажимаете сочетание клавиш или кликаете мышью на текст кнопки, а Hyperbole по расширяемому набору эвристик пытается понять, как кнопка должна сработать. Плюс всегда есть способ не выполнить действие, а получить описание того, что будет выполнено при "нажатии" кнопки.

Во многом кнопки Hyperbole похожи на автоссылки в разных системах. Например, вы можете сделать так, чтобы текст вида "foo#12234" работал как ссылка на ticket под номером 12234 в bug tracker к проекту foo — и текст останется просто текстом, дополнительная разметка не потребуется! Строго говоря, {} нужны только для кнопок, которые нельзя описать одним "словом" и это минимальная цена, которую можно заплатить за поддержку "кнопок с параметрами".

Ещё у Hyperbole есть механизм explicit buttons. Эти кнопки называются явными, потому что требуют явного создания. В отдельном файле, связанном с текущим текстом, сохраняется метаинформация о том, что такой-то участок текста является кнопкой такого-то типа и с такими-то параметрами. В результате в тексте вы видите emacs button — это "нажимаемые" (ага, то же имя при другом смысле) объекты в документе, не связанные с содержимым документа напрямую, а создаваемые в интерфейсе редактора при открытии документа. Org Mode, встроенная справочная система, просмотрщик man pages — все они использую emacs buttons для показа ссылок/кнопок в интерфейсе, так что Hyperbole тут выступает вполне последовательно.

Минус explicit buttons понятен сразу: вне Emacs не получится даже увидеть, что какой-то фрагмент текста, это кнопка. И нужно не забывать поставлять файл кнопок вместе с файлом, в который кнопки вставлены. Зато никаких s-expressions на виду! Опять же, очень персонально!

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

Сравнение и общие мысли

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

Но подход Hyperbole интересен поддержкой ссылок без разметки — можно попробовать реализовать такое в миниатюре, без подключения сверху целой развесистой системы. А ещё можно попробовать размечать eev-кнопки как emacs buttons, потому что это выделит их визуально и даст возможность привязать контекстно-зависимые сочетания клавиш.

Ещё eev мне нравится тем, что это по сути обёртка над встроенными действиями "перейти в конец текущей строки"+"выполнить elisp s-expression перед курсором"! Всё остальное — функции для оживления ссылок. Но таковых и у самого Emacs в избытке, пусть иногда и не настолько самодокументируемых.

Я только прошёлся по верхам, оба проекта слишком велики, чтобы в пару абзацев описать каждый. Про GNU Hyperbole автор буквально недавно написал на Reddit и рассказал, что же это такое и для чего он делает уже третий десяток лет :) Если вдруг читатель тяготеет к Emacs, как к средству управления знаниями, рекомендую приобщиться к тому или другому проекту пусть даже кругозора расширения ради!

Есть ещё один проект, не связанный с Emacs, который тоже про вот это вот всё и который мне очень нравится как явление. Но про него я расскажу как-нибудь в другой раз.

The Stubborn Computing Manifesto

Прочитал недавно статейку с таким названием. Процитирую вступление:

> Stubborn computing is about using computers the way you want to.
> 
> Stubborn computing is about being able to pick — and stick to — what you think is the best tool for the job. It's an investment in software over time: As with the carpenter's hammer, the chef's knife or the weaver's loom, it's about subconscious and intrinsic mastery of the tools of one's craft - a deep-seated skill growing along with a never-ending creative process. Ars longa, vita brevis.

Закончил читать с мыслью "так это же про меня!". И более того, манифест хорошо описывает то, чем я занимался всю мою около-компьютерную жизнь!

Сидел на DOS, писал на Pascal, хотя слышал уже, что надо на Си писать. И мне было хорошо. Потом под Windows использовал Delphi. И тоже было отлично.

Слез с Windows на Ubuntu/Debian Linux и мне хорошо, а до этого было хорошо на Windows XP. Причём мне было хорошо на XP, когда все уже сидели на Win7. Сейчас мне на дебианах хорошо, хотя окружающие постоянно пытаются меня куда-то перетащить — то в "дивный мир Эппла", то на "настоящий Linux" (arch).

Несколько лет пользовал Sublime Text, пропуская мимо ушей то, насколько лучше жить на PyCharm. Потом сам решил пересесть на Emacs. И с тех пор только и слышу, насколько он старый, насколько уродлива цветовая схема, насколько больше плюшек у VSCode. А мне норм. Вот эта цитата хорошо соотносится моим выбором Emacs:

 Stubborn computing is about working — sometimes hard — towards maximizing personal computational enjoyment.

Да, я использую то, в изучение чего я вложил силы. И то, чего мне сейчас достаточно. Почувствую, что перестало хватать — пересяду на MacOS, IntelliJ IDEA. Сейчас же ThinkPad мой меня радует больше, чем оставшийся от работы MacBook. Привык, настроил, пользуюсь успешно и с удовольствием.

И это не ностальгия, не ретроградство, не недовольство засильем bloatware, не фанатичное стремление к использованию suckless software, не гонка за мифическим Unix Way. Такие явления формируют вокруг себя субкультурки, причисляя себя к которым нужно всё время соответствовать — обычно соответствовать ожиданиям других. Кому-то может и нравится подобное. А я слишком упрям :)

Вот уже некоторое время я занят тем, что провожу сеансы live coding с параллельным общением. Собираемся раз в неделю и потихоньку реализуем на #haskell проект LHX (Line Hyper-eXpander) — эдакий упрощённый awk(1) "для людей", перегоняющий один текст в другой построчно с применением шаблона.

Задача проекта: поделать что-то условно конечное и практичное, в процессе и с экосистемой поработать, а не просто очередную текстовую RPG написать на основе одной лишь стандартной библиотеки. При этом хотелось пощупать сильные стороны Haskell — те же парсеры пописать — но без ухода в глубокую типоту, попользовать "boring haskell", если вам это что-то скажет :Р А для большего размаху решили сделать для единого ядра шаблонизации несколько интерфейсов:

- неинтерактивный CLI
- интерактивный TUI
- GUI на веб-технологиях (есть подходящая библиотечка для такого)
- классический Web-интерфейс (а может и JSON API в будущем)

Идею я даже не из воздуха взял, а откопал в памяти виденную когда-то программу NimbleText, вольную интерпретацию которой мы теперь и воплощаем.

Сейчас готовы ядро, CLI и Web-based GUI — всё сделано в лучших традициях MVP, то есть работает, но расширять можно ещё долго. Пока получается не слишком закапываться в один конкретный аспект и на каждый тратим одну-две сессии. Пока в основном код писал я, но сейчас уже pull requests появляются, в какой-то момент ещё больше распараллелимся. Есть, например, желающие в Nix проект завернуть, CI сделать с кэшированием артефактов сборки — тут уже я буду учиться у других!

Такое вот еженедельное развлечение — пописать в расслабленном режиме что-то обозримое, но расширяемое, и, что немаловажно, потенциально небесполезное!

Проект LHX, про который я рассказывал в прошлой заметке, продолжает развиваться. Мы провели уже восемь сессий субботнего кодирования — это прилично, если вдуматься. Энтузиазм в целом уменьшился, хоть пока и не сошёл на нет, регулярно приходят два-три человека, но видео, кажется, кто-то да смотрит :) А ведь на первой встрече кто-то хотел завернуть весь инструментарий разработки в Nix, другие хотели заняться сборкой релизов для разных ОС. Но, как это часто со мной бывает, мотивация под конец осталась только у меня…

Тем не менее, мы успели написать CLI-версию, TUI, реактивный внутрибраузерный GUI на специализированной библиотеке, классический web-app с формой ввода. В какой-то момент в обсуждении я упомянул, что успел поиграться с библиотекой HTMX в связке с Haskell, и в итоге мы реализовали интерфейс в виде реактивной же странички, общающейся с сервером по WebSocket — получилось вполне неплохо!

HTMX берёт на себя обновление уже загруженного документа кусочками HTML, которые сервер отправляет в ответ на AJAX-запросы или асинхронно через WebSocket. Вы же можете вообще не писать клиентский код, а вместо этого всего лишь декларативно размечать интерактивные элементы в HTML и добавлять соответствующую логику на сервере.

Из того, что в LHX ещё стоит порешать, хочу упомянуть стенку, которую я не смог сходу перепрыгнуть. Пока не получилось сделать ни один из интерактивных вариантов пригодным к использованию в рамках конвейера.

Хотелось мочь вызывать программу так:

 ls -l | lhx | cat ...

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

Проблема в том, что при запуске программы в роли части конвейера, программа не может себе позволить показывать пользовательский интерфейс в терминале — это как раз понятно. Но даже есть решить, что подобный способ запуска доступен только для версий с Web-интерфейсом, то оказывается, что не так-то и просто остановить сервер, когда диалог считается законченным. Я уж молчу о том, что страница в браузере остаётся открытой, а в случае использования WebSocket ещё и ругается на разрыв связи. А ещё серверы любят по делу и не очень писать что-то в STDOUT! И в случае threepenny-gui (библиотека для построения реактивного GUI в браузере) вообще нет возможности подавить некоторые сообщения вроде "я запустилась на таком-то порту" и "соединение оборвано". И я бы потерпел, если бы это всё падало в STDERR, но оно в STDOUT выводится!

Получается, что требуемое поведение можно сделать без хаков только в программе с честным desktop GUI — там вы можете завершить работу интерфейсной части, но оставить работать кусочек конвейер. Или показывать тот же TUI в новом окне терминала, которое ещё предстоит открыть. Или реализовать протокол terminal multiplexor и позволять к себе подключаться с помощью tmux, либо просто выставить telnet наружу и уже на удалённом — и в обоих случаях выводить TUI на "удалённых терминалах". Впрочем, всё это звучит довольно весело :)

Кроме того, я решил радикально переделать язык шаблонов LHX и уйти от awk-style разбивки строчек по заранее заданному разделителю. Хочу дать возможность описывать разбиения строки ввода по подстроке, регуляркой, по индексу и давать обращаться из шаблона к каждому разбиению, в том числе и к нескольким сразу. Чтобы можно было написать "разбить по запятым, взять второй элемент, разобрать его как дату (Y, m, d), взять последний элемент, ...":

csv=re-split:\s*,\s*
ymd=re:\d{4}\.\d{2}\.\d{2}
$date=csv:2:ymd
---
$date:1;-$date:2;-$date:3; - $csv:1;

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

Мде, докатился, завёл второй канал. Чтобы туда писать неструктурированные мысли (подразумевается, что тут они структурированные (нет?)).

Хотел сделать блог в очередной раз, с разделами "TIL" и "мои проекты" — специально чтобы писать ради написания, а не корпеть над каждой статьёй. Но предвкушение мук по настройке пока что не даёт снова окунуться в блоговодство вне silos, пусть даже в виде умолчательной автоматики GH Pages.

Потому что даже в случае Pages нужно что-то запускать, генерить какие-то .md, заполнять какие-то front matters. Хочу отправлять по нажатию Enter и всё тут. Поэтому канал. Потом перенесу может быть. Как только придумаю, как из Org Roam публиковать просто навешиванием тега на заметку (опять программировать нужно, но пока не хочется).

Не уверен, что это вообще стоит кому-то читать, но ссылку всё равно дам: https://t.me/brain_leakage_etc Повторюсь, если тут я пишу не всё подряд, что в голову приходит, то там всё будет сильно более сумбурное вроде тех самых TIL и просто ссылок на всё подряд с моими комментариями (в основном для будущего меня самого).

Давече я задумался, а как бы мне запускать внешние программы из #Emacs — ну знаете, нужно иногда PDF reader открыть или окно терминала, связанные с ткущим проектом.

Да, у emacs есть возможность запускать процессы синхронно и не очень, в shell и без. Вот только мне не хотелось, чтобы запущенные программы продолжали быть связаны с Emacs как его подпроцессы. Но чьи-то дочки это должны быть! Вот бы иметь процесс, который всегда запущен и которому можно скомандовать "запусти-ка вот это вот". И такой процесс у меня есть: systemd!

Ага, знаю, многие systemd не любят, но мне-то он как раз подходит: он и так запускает тот же Emacs server. Но делать по unit на каждую программу, которую я когда-либо захочу запускать, мне точно было бы лень. Так родился basher.bash — скрипт, который командует соответствующему basher@.service запустить себя же, но в режиме "замени себя такой-то программой".

Замещающая программа при этом запускается в той директории, из которой был интерактивно запущен basher.bash — это дело я пробрасываю через временный файл с переменными окружения. Да, костыльненько, но зато а) работает, б) позволяет посмотреть, что за программа была запущена и в какой директории. Второе возможно потому, что каждый файл получает UUID в качестве имени и этот же UUID становится частью имени запущенного сервиса. А уникальные имена сервисов нужны для того, чтобы можно было иметь запущенными несколько экземпляров одновременно.

В довесок я получаю логирование запущенных программ, поскольку systemd это умеет. Может быть я потом получу кучку мусорных логов. Но пока меня это не сильно беспокоит. А как начнёт, сделаю service, который будет чистить логи :) Вот такое велосипедостроение! Зато хоть systemd потрогал наконец.

---

UPD: оказалось, что велосипед изобретать не стоило, а нужно было просто взять systemd-run. Ну да ладно, зато я покопался в разном для меня новом и нескучно провёл время! Ссылки поправил на исторические, потому что велосипед свой удалю из dotfilles, но в анналах истории пусть остаётся :)

​​Так уж вышло, что есть у меня сколько-то программ, написанных на Python, которые если и дебианизированы, то в виде пакетов обновляются сильно позже/реже, чем на PyPI.

Например, youtube-dl можно поставить силами apt, но версия будет не самая свежая, вот только это как раз та программа, которую вы захотите иметь максимально свежей — "API" разных платформ меняются часто и код, отвечающий за скачивание, устаревает быстро. Более того, yt-dlp — форк такой, более активный, чем оригинал — всё ещё не дебианизирован.

Как же устанавливать всякое околопитоновое? Авторы пакетов часто предлагают делать "pip install ..." иногда даже с применением sudo. Но этот вариант ничем не лучше "sudo make install"! Даже если знать, что можно использовать флаг --user и ставить всё "только себе", то конфликты версий пакетов вы получите довольно быстро, потому что пользовательское окружение — это всё ещё глобальное окружение, пусть и "чуть менее".

Да, существуют всякие надстройки над pip вроде pipx и pipsi — эти создают по виртуальному окружению (это такие питоновские песочницы) на каждое приложение и обновлять в последствии. Более того, pipx вообще, можно сказать, "официальный" инструмент — развивается силами pypa, а это те же люди, которые сделали сам pip!

Я сам использовал pipsi, а потом и pipx и вполне успешно. Но в какой-то момент понял, что собственно напитонового ПО у меня в принципе мало, чтобы иметь отдельный инструмент для установки. Это когда-то раньше я ставил десятка два всяких percol — и не пользовался ни разу :Р В итоге я решил отдаться тяге к suckless в данном конкретном случае и просто создавать venvs руками и пакеты ставить и обновлять руками же. С тех пор всё лежит у меня в ~/.software, доступно в PATH через symlinks в ~/.local/bin, есть не просит.

Вот только на очередном витке эволюции я решил "минимально, но достаточно автоматизировать" обслуживание. Запилил venv&run, теперь этот скрипт создаёт venvs и устанавливает туда пакеты. Но веселье тут в том, как вы добавляете новое ПО: вы делаете symlink на этот скрипт, называя так, как будет называться устанавливаемая программа — скажем, "dogesay", а потом скрипт уже видит, что имя у него новое, и запускает нужную программу (заменяет себя оной через execv). Чтобы создать venv и установить пакет или обновить его, нужно новую команду запустить в виде "INSTALL=t dogesay". Вот такой вот минимализм ради минимализма, дёшево-сердито :)

Не обошлось и без неприятных сюрпризов. Когда учил скрипт создавать симлинки, то оказалось, что если запустить себя, а потом в пытаться создать venv, то директории создаются, но файлы не копируются, в итоге песочница получается без песка. Пока не понял, почему так. Так что моё suckless решение пока kinda sucks, но не настолько сильно, чтобы не пользоваться :P

Дослушиваю выпуск Changelog Podcast "A guided tour through ID3 esoterica". Ведущие беседуют с автором библиотеки для Elixir, работающей с ID3 тегами. Причём разработку библиотеки авторы подкаста же и заказали, чтобы иметь возможность размечать главы в записях подкастов — да, в ID3 есть и такое! Но спешу отметить, что выпуск интересен сам по себе в отрыве от Elixir, потому что позволяет погрузиться в историю и прощупать глубины тегирования MP3 — там есть, на что посмотреть!

Например, знали ли вы, что есть тег, отвечающий за количество прослушиваний конкретного файла? Предполагалось, что проигрыватели будут инкрементить этот счётчик при каждом прослушивании! Так же есть теги, касающиеся монетизации контента. А ещё есть возможность приложить произвольный файл. Который в свою очередь может быть MP3-файлом или даже целым альбомом! Словом, подкаст получился и познавательно-развлекательный, и рассуждательно-юмористический — отличная альтернатива типичным "новостям мира АйТи".

Мне было слушать особенно интересно, потому что я летом добил таки Practical Common Lisp, а в книге приличная часть выделена на разработку библиотеки для работы со всё теми же ID3-тегами. Глава очень мощная, включает и реализацию DSL для описания фреймов c тегами, и matching по заголовкам с помощью мультиметодов — именно за это книгу и любят, ведь она показывает практическое применение тех довольно необычных возможностей языка, которые в иных источниках упоминают вскользь.

И пусть я приличную часть книги читал, держа в голове мысль "да, круто, конечно, но я точно не захочу это использовать сам!", но в целом про работу с бинарными данными, предполагающими разные кодировки и разную компоновку в зависимости от версии формата было интересно даже просто пролистывать. Я даже задавался мыслью "а насколько удобнее такие штуки матчить в Erlang?", так что упомянутый выпуск подкаста попал в благодатную почву :)

Есть такая программка — jq. Используется для работы с JSON, делает выборки данных из глубоко вложенных структур, может что-то подменять на лету. Применяется, как правило, в сценариях автоматизации. Думаю, что слышали про неё многие. Казалось бы, ну что тут такого нового и интересного? Вот и я так думал до сегодняшнего дня.

Да, я слышал, что язык скриптов jq достаточно богат. Но оказалось, что это неслабое преуменьшение. У jq приличная часть встроенных функций написана на jq же, имеется оптимизация хвостовых вызовов, всякие генераторы, ввод-вывод, система модулей.

То есть сегодня jq — это вполне себе язык большой программирования! На Rosetta Code можно найти реализацию алгоритма Дейкстры и некоторого подобия алгебраических типов данных, помимо прочего.

Для jq есть "среды разработки" с живыми предпросмотром результатов, интерактивные построители запросов, интегрируемые в ваш zsh, внутрибраузерная версия, работающая на базе настоящего jq, скомпилированного в WebAssembly. Вот соответствующий "awesome list" разных штук в экосистеме jq — да, уже можно сказать, что таковая имеется. Из интересного для себя отметил:

- jc — препроцессор "выхлопа" разных популярных программ, преобразующий всё в JSON, который уже можно обрабатывать силами jq
- fq — "jq для бинарных форматов", позволяет делать запросы по EXIF и ID3 тегам, сообщениям Protobuf, и тому подобным штукам, которые jq не переваривает самостоятельно
- jqt — шаблонизатор, размещающий данные из JSON внутри шаблонов — да, можно сайтик написать на jq теперь

Решил ли я научиться писать на jq и делать всё с его помощью? Нет, конечно :) Но знать о том, какие задачи теперь можно решать с помощью jq, будет полезно!