И что мне делать с этим?

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

Помнится, писал заметку об убогости типичных конфигов - yaml, toml, json, ini что там еще бывает. бывает еще dhall, но это спасибо-пожалуйста без меня. TL;DR - шумные, негибкие, нет абстракции. Что интересно, когда такое берёшь в проект, что бы особо не думать — то халявы-то всё равно по факту не получается, там +- куча бойлерплейта. Короче, чем ныть, намутил парсер sexp-ов на мегапарсеке, и немного подшаманил, что бы на топлевеле можно было задавать конструкции без скобок - т.е с первого взгляда даже не похоже на секспы, а если еще добавить синтаксического шума в виде всяких равно и двоеточий, то будет выглядеть, как какой-нибудь yaml-json. Прикол в том, что поскольку это на самом деле секспы, то это можно будет расширять. Например, добавлять функции - ну, например, указывать, что если ключ не занят, то взять его из окружения с именем таким-то. Весь парсер и AST, к слову, получились строк 200+, и это уже оно умеет в принципе красиво ошибки выводить, там же мегапарсек внутри (далее в коментах)

к вопросу о том, что шумно, что не шумно. конструкция

fixme-prefix FIXME:  bugs issues

делает следующее:

говорит, что есть префикс "FIXME:" который относится к категориям bugs, issues. теперь задаём на условном JSON/YAML:

prefixes = {
    "FIXME:" : [  "bugs", "issues" ]
    "TODO:" : [ "bugs", "issues"]
}

ахаха, это провал. я не знаю, можно ли там повторяющиеся ключи, поэтому

prefixes = 
[  ["FIXME:", [["bugs", "issues"]]
,  ["TODO:",  [["bugs", "issues"]]
]

ахаха, а это секспы. покажите, как лучше

Каждый неизбежно в жизни напишет хотя бы одну игру, компилятор/транслятор и распределенный багтрекер.

#offgrid ускоряем протокол, переделываем в сторону упрощения криптографию. делаем для себя, поэтому можем позволить себе сделать как следует

#fixme запилил тем временем утилитку для трекинга FIXME/TODO комментариев в коде вместо багтрекинга. Issue берёт из гитовых блобов (т.е сканит их, а не staged файлы), workflow их управляет при помощи лога операций, который коммитится в тот же гит. Никакой распределенный багтрекинг не прижился пока у нас, git-bug был лучшей попыткой, но что-то тоже не очень. Так что попробую пока вот, что из этого получится. Как-то так сложилось, что в трекеры тикеты писать лень, не говоря о том, что их нет, а вот комментарии TODO/FIXME в код - напротив. Бывает, и кода еще никакого нет, а коментариев таких полно. В общем, пре-альфа-версия для смелых тут: github:voidlizard/fixme

fixmies захватываются прямо из git blobs, и показываются оттуда же. прикрутил внешний пейджер с подсветкой синтаксиса

У меня есть "консольная" считалка планов проектов (даже работает еще, как-то пользовался). Там в виде синтаксиса с отступами описывается WBS проекта с оценками, потом считается проект, потом строится из него всякое - WBS, Гантт. Гантт рендерится в PDF через латех через m4. m4 взял как "внешний" шаблонизатор. В целом, сам не особо использую: получилось 1) сложновато, забывешь синтаксис между использованиями 2) строить детальные планы довольно бессмысленное дело. Плюс m4 в качестве шаблонизатора чот не особо, но непонятно, что лучше. Я то найду какой-то хаскельный внешний шаблонизатор, то потеряю. В общем понятно, что надо это дело переработать — план должен генерироваться из сравнительно небольшого набора фактов и констрейнтов. Причем, для каждой области есть какой-то набор паттернов для этих самых проектов, типичную опердень зачастую можно оценивать просто рисуя некую матрицу, где для каждой задачи есть колонки

фронтенд|бекенд|база|тестирование|интеграция|деплоймент

Т.е каждая задача порождает N шаблонных/типичных "подзадач".

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

С другой стороны, люди (включая меня) падки на халяву. Если им дать возможность за три строчки сгенерить большой план проекта, который бы они опупели бы рисовать в любом редакторе, а потом его постепенно уточнять — то переборят себя и эти три строчки выучат, а потом еще другие строчки, которые уточнят план. Таким образом, план проекта это не "дерево" в виде DSL и каких-то строгих сущностей с атрибутами. Это поток фактов, которые это дерево где-то внутри создают, возможно, из какого-то небольшого числа начальных фактов. В общем, взять мою старую генерилку ганнтов, оторвать DSL, оторвать шаблонизатор, приделать новые на основе suckless-conf.

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

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

Скучаю по временам, когда был XML. Не было особых вопросов с внешней шаблонизацией. XML+XSLT = профит. и XSLT был прекрасен, и xpath в рамках своих допущений (дикий наркоманский SGML-ный синтаксис). А теперь-то что делать? Где стандартный/общепризнанный аналог xslt/xpath для json ?

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

ладно, возьму microstache

к вопросу об ini, yaml и json:

fixme-attribs assigned workflow resolution

fixme-value-set workflow new backlog wip test fixed done


[ fixme-report all json
  (render builtin:microstache report-wip.tpl)
  (post builtin:columns | 10 8 8 10 _)
]

[ fixme-report wip json
  (render builtin:microstache report-wip.tpl)
  (post builtin:columns | 10 8 8 10 _)
  (query ?workflow:test)
  (query ?workflow:wip)
  (query ?workflow:fixed)
  (query ?workflow:done)
]

такое вот на них изображать уже не так весело, да?

#fixme подсветка начало fixme в fixme cat, что бы было видно в контексте, какое именно fixme смотрим

Что произойдёт, если пользователю винды/юристу (т.е всякого рода примочки для разрабов у него точно не установлены) отправить в почте файл в формате markdown c юниксовыми переводами строки? Не откроется вообще? Откроется в нотепаде и и все строки склеятся?

#offgrid #hbs2 шифрование контента для групп подвезли. прямо руки трясутся в предвкушении

 шифрование-для-групп -> AccessControlBlock -> Reference -> DAG -> MVP

Суда по бурлению в nix deployment tools, это такой же святой грааль, как во время PHP - CMS. Имеющееся никому не нравится,
все пытаются сделать своё, нормальное. Несходящийся процесс.

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

colmena ничо так

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