brain_leakage_etc

Вчера сделал для своего winu (от "WIndow meNU") сортировку списка окон по последнему переключению на каждое. Всё предельно просто: любое новое окно при запросе у ОС списка окон добавляется в конец списка, а когда я переключаюсь на какое-то окно, оно перемещается в начало списка. Далее, в интерфейсе окна выводятся в том порядке, в котором они располагаются в этой внутренней очереди с перестановками. И если всегда считать окном для переключения по умолчанию — когда не нужно ничего выбирать, просто вызвать winu и нажать Return — второе окно в списке, то получится быстрое переключение между парой самых "горячих" окон. И это ровно то, что мне нужно обычно. Все остальные окна я выбираю, вводя строку для нечёткого поиска, там уже ранжирование по "близости" название окна к введённому запросу делается — эт о всё ещё быстрее, чем стрелками выбирать из списка. Хотя и такой вариант у меня есть, разумеется, и не только стрелками, но и по C-n=/=C-p с подтверждением и по Return и по C-j. Что же происходит, когда я переключаюсь между виртуальными рабочими столами? Поскольку список recency у меня никогда не забывает окна, то даже когда я получаю список видимых окон только для текущего Space, ранжирование по недавности не ломается, потому что относительный порядок сохраняется! А это значит, что я бесплатно получаю свою группу "горячих" окон для каждого Space 😎 И даже не пришлось делать по выделенному списку окон на каждое пространство! Да, порядок может слегка ломаться, если таскать окно с одного пространства на другое, но всё восстанавливается после пары переключений. Из проблем, которые ещё предстоит решить, наиболее заметная заключается в том, что моё winu ничего не знает о том, как пользователь переключается между окнами вне его. Но, опять же, если оглянуться на то, что мне ещё не пришлось получать доступ к Accessibility API и в фоне отслеживать активность окон, как делают все "большие" программы, то и текущий вариант очень даже неплох! А уж когда я сделаю динамическое подвешивание окон на буквы и цифры, то меня в принципе порядок станет волновать меньше 🤓 P.S. Может быть сортировку по недавности все так делают, не исключено. Но я лично всё сам придумал, в этом часть удовольствия от процесса!

Начал использовать свой переключатель окон в macOS! Потому что хоть я и натыкался на "почти то, что мне нужно", уже начав делать свой, но и то приложение было слишком bloat. Если интересно, то пробовал я AltTab и BetterCmdTab. Первое больше про красоту, но буквально одна маленькая возможность, нужная мне, находится за pay-wall вместе со всем ворохом того, что я никогда использовать не буду. Да и работал этот AltTab нестабильно. Я хотел им переключать видимые окна, а "все-все" окна переключал бы ванильный механизм — как раз более чем один режим переключения окон у AltTab платный. Так вот, я с помощью Karabiner подвесил AltTab.app на Cmd+Tab, а оригинальный переключатель переместил на Cmd+Option+Tab. А в итоге AltTab начал очень странно реагировать на Cmd+Shift+Tab, то есть сразу закрываться с выбором предыдущего окна. И я не смог это отдебажить и побороть. Где-то в процессе починки AltTab очередной brew update показал, что есть такая штука — BetterCmdTab. FOSS, бесплатно навсегда, keyboard-driven — звучало вкусно! Поставил, начал подстраиваться под него и его подстраивать под себя. В итоге программа умудряется ломаться регулярно и показывать невидимо окно, которое захватывает фокус, но переключать ничто и никуда не даёт. Да, вроде бы где-то автор это как-то подтыкал, но у меня не починилось после того патча. В итоге я и эту программку снёс, хоть она и была близка к тому, что я конкретно хочу. А мой переключатель тупой, не умеет ничего красивого, но пока не отваливается! И я его могу чинить сам, если придётся 😜 Буквально сегодня я сделал для своей переключалки показ по глобальному сочетанию клавиш. Причём я не хочу пока влезать в Accessibility API и выдачу соответствующих прав. А раз уж у меня уже есть keyboard shortcut manager в лице Karabiner, то нужно было всего-то дать уже запущенной программе знать, что ей нужно окошко показать. Я чуть-было не кинулся делать IPC на named-pipes, но вовремя вспомнил про SIGUSR1 — это же буквально то, что нужно для данной задачи, максимально дёшево и сердито 🌚

Копаюсь дальше в профиле Safari 🔬 В процессе написал программку, которая дампает plist в JSON, потому что кое-что у Safari в plists хранится — у Apple ещё со времён Next любовь к property lists. Благо, для Rust есть готовая либа, которая умеет читать и XML-вариант и бинарный. Так что я просто сделал plist->raw_dict->JSON, а дальше с jq развлекался. Ну да это всё цветочки. Теперь по ягодкам. У Safari в History.db есть табличка history_tags, которая относится m2m к history_items, то есть каждая посещённая страничка потегана более чем одним тегом. Тегов у меня в табличке 1700 с лишним! Причём первым по id идёт "GNU Emacs"! Потыкался, погонял уточку запросами с джойнами. По тегу "GNU Emacs" нашлись вполне релевантные сайты. А вот сайт языка Factor имеет ярлычок "Arch Linux", хе-хе 🤓 Причём, судя по всему, Safari делает некий NLP локальный, чтобы теги выцепить — и вот это прям интересно! Но, увы, нигде не задокументировано. Надо будет посмотреть, что можно понять про меня по этим тегам, интересно же! 😎

Снова порадовался тому, что Safari хранит историю в SQLite, хоть и добраться до файла не так уж и просто из-за огораживания macOS. У меня отключена очистка истории в настройках браузера, уж и не помню с каких пор. И когда я перключаю настройку в "забывать всё, спустя год", Safari говорит, мол, ты точно хочешь удалить 100000 записей? При этом сам Safari колдобится от такого объёма истории, но продолжает терпеть, раз я решил хранить всё 🤪 Короче говоря, я периодически хожу и грохаю поиски, ссылки на youtube, на Gmail. Последний вообще любит намусорить в историю, хотя сама идея вынести состояние в URL и неплохая. Вот и сегодня я сходил, для разнообразия с помощью duckdb, вспомнил схему, прогнал парочку "DELETE FROM ... WHERE url LIKE ...", а потом полирнул с помощью VACUUM. Прямо приятно стало от такой мощи в моих ручищах!

Вообще всё это мне вернуло слегка те ощущения из времени, когда я писал для себя всякие GUI-надстройки для Windows на Delphi. Правда, такого уровня удобства "от мысли, до первого запуска" так никто и не достиг с тех пор, только усложнили всё. Я уж молчу про возможность в оффлайне всё делать, имея и всю документацию на руках с ворохом примеров на все случаи жизни. Нейросетки позволяют превозмочь ступор чистого листа — как раньше тебя прямо-таки звала "Form1" уже готовая и даже запускабельная. Но всё таки ощущения другие: да, можно больше, но не самому...

И, да, чтобы получиться список окон на текущем мониторе на активном Space, надо потыкать постоянной отгнивающий приватный API, а публичного и стабильного просто нет. При этом Acessibility API простойные, но им тоже как-то наплевать на "текущий десктоп того монитора, на котором сейчас фокус", официально есть только способ перечислить окна, видимые и не только, но ника не поэкраново. В итоге все открытые и не очень решения обёртывают эти самые приватные API в либу, собирают отдельные версии для разных релизов ОС со своими наборами костылей для каждого релиза. Фу так жить. Вот я и не буду — для себя же делаю, остановлюсь там, где станет уже не весело.

Вчера не смог удержаться, решил написать свою переключалку окон для macOS. Потому что иcкоробочный вариант переключает окошки, лежащие на всех десктопах, мне это неудобно. Да, есть какие-то аналоги, которые в той или иной степени платные или навязчиво просят денег даже в бесплатном режиме. И все какие-то толстые. А мне не хватает dmenu/rofi. Решил в итоге свою версию сделать. Конечно же решил вайбкодить, поэтому скормил все нейронке и сказал, мол, "вот тебе Swift, вот тебе базовые библиотеки, давай, делай". И, собственно, надиктовал за часик MVP. Причем базовая функциональность заработала с первого промпта, то есть в течении минут пяти! Дальше я уже просто специально микро-шашками двигался и смотрел заодно, как и что делается в их мире. Вот как-то так. Сам я, конечно же, такое писать не стал бы, хоть Swift и не ужасен и даже местами приятный. А вот яблочный SDK сомнительный для был всегда на мой лично вкус. А теперь можно машину запрячь, пускай работает!

Жёлтые тюльпа-аны Это не для зву-ука! Красные тюльпа-аны Вам не композит!

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

А ещё можно через TRAMP запускать фрагменты кода из вашего локального Org файла на удалённых машинах и спутывать (tangle) ваши конфиги тоже в удалённые файлы. При этом можно на одной машине выполнить скрипт, результат которого подставить в конфиг, заливаемый на другую машину — простор для вариаций широчайший! Собственно, Literate Ops вокруг этого всего и построен 😎

Вчера собрал в докере python, uv, LSP сервер (pyrefly, через uv tool install). Запустил контейнер. В Emacs зашёл по пути /docker:urly-swan/app/foo.py и открылся файл в контейнере, как будто локальный. Вызвал eglot— тот запустил и подконнектился к LSP-серверу в контейнере. Сервер увидел сорцы, зависимости и остальное. Потом я вызвал eshell при активном буфере с файлом в контейнере — и shell открылся тоже внутри контейнера. А можно было просто в eshell сделать cd /docker:crazy-donkey/app и перепрыгнуть в контейнер. Вместо Docker весь сетап мог быть спрятан за SSH и всё работало бы так же! Что характерно, это всё встроенные в Emacs штуки: - eglot — поддержка LSP - TRAMP — поддержка всяких "удалённых машин", то есть работа через SSH, scp, Docker, последовательный порт и проч. - eshell — shell с возможностью писать команды на elisp, куда уж без этого

https://unix.foo/posts/it-will-never-be-the-year-of-the-linux-desktop/ The problem is that Linux can make almost anything exist, but it cannot make almost everyone agree to care about it at the same time. Увы и ах, всё так и есть...

>>> from pydantic import BaseModel, BeforeValidator >>> from typing import Annotated >>> type CommaSeparated[T] = Annotated[list[T], BeforeValidator(lambda v: v.split(","))] >>> class Buckets(BaseModel): ... REQUEST_DURATION_BUCKETS: CommaSeparated[float] | None = None ... >>> import os >>> Buckets.model_validate(os.environ) Buckets(REQUEST_DURATION_BUCKETS=None) >>> >>> os.environ["REQUEST_DURATION_BUCKETS"] = "1.2,5" >>> Buckets.model_validate(os.environ) Buckets(REQUEST_DURATION_BUCKETS=[1.2, 5.0]) >>> >>> os.environ["REQUEST_DURATION_BUCKETS"] = "1.2,oops" >>> Buckets.model_validate(os.environ) Traceback (most recent call last): ... REQUEST_DURATION_BUCKETS.1 Input should be a valid number, unable to parse string as a number [type=float_parsing, input_value='oops', input_type=str] Modern type-driven Python may look like that! Вполне себе композабельно и удобненько, особенно когда добавили [T] синтаксис и параметризованные тайп алиасы

Первый раз наткнулся на то, что объявление в классе метода def list(self, ..) ломает тайпчекинг и код просто падает на вычислении аннотаций. Потому что в области видимости класса теперь list — это дескриптор метода экземпляра. То есть произошло затенение (shadowing), которое почти никак не видно в самом коде, потому что вызывается-то метод через точку! А вот аннотации ломаются, потому что они-то в пространстве имён объявления класса живут. В самом Python можно сделать from __future__ import annotations и это даст коду запуститься. А вот ty ругается, мол, ты всё сломал и не починил! Пришлось локально заглушить. И, да, это рабочий проект на Python 3.11. Коллеги просто забивают и пишут from typing import List и аннотируют через него. В итоге половина кода с List[foo], а другая половина с list[bar]. Но всем, кроме меня, пофиг.

https://www.stvn.sh/writing/programming-still-sucks-fqffhyp отзывается.

Эппл поимел меня. Питоновский torch уже не собирают для Intel Mac, только для винды или армовых маков. А собирать torch из сорцов — боль! Там надо подтянуть под конкретный GPU заголовочники и остальные приседания делать...

https://www.reddit.com/r/custommagic/comments/yqujp0/commander_volkov/ просто забавное название карточки. Накопал, пока искал скриншот VC для сегодняшнего стрима

Начал щёлкать левый динамик в макбуке. Для MacBook Pro 16-inch оба канала сидят на одинаковой схеме smart-amp, обычно от Cirrus Logic, управляемой через AppleHDA. Щелчки это типичный сценарий деградации smart-amp (обычно чип от Cirrus Logic), а не самого динамика. К сожалению, для этой модели это обычно означает: - либо жить с отключённым каналом, - либо внешняя акустика / наушники, - либо замена верхнего модуля (дорогой ремонт). Стоит ли чинить? Честно: для 16" 2019 с i9 ремонт часто экономически сомнителен, если только машина не в идеальном состоянии и тебе принципиально важны встроенные динамики. Это не опасная поломка — ничего не «сгорит дальше». Просто канал постепенно станет совсем шумным. Мде