Схоластика: когда средневековые учоные обсуждают и пытатся рационализировать потребление памяти хаскельной программой

Одно из определений безумия - это делать одно и то же, ожидая другого результата. Одно из свойств безумия - считать, что безумие можно контролировать. Топик, потому, что про управление проектами

Странное вот дело - казалось бы, нет ничего проще UDP. Но даже из протокола на две команды - получается конструкция на тысячи строк кода, это вспоминаю DNS прокси роутерную. Удивительное дело вообще. После дней пяти мучений с модельным сервером — решил посмотреть, что там как у людей, может хорошо уже сделали. Увиденое заставило всплакнуть - видно, что те же самые проблемы были, и судя по прибитым местами IO и ByteStrings - просто сдались в какой-то момент. А всего-то хочется написать обобщенный воркер с поддержкой сессий, а что бы конкретные типы пакетов и сессий определялись его клиентами. Типа, на случай, если протокол состоит из какого-то небольшого числа подпрототоколов со своими workflow. Если всё это загнать в один тип пакетов, например — то очень быстро становится невозможно отлаживать, т.к. каждый конкретный FSM обрастает каким-то дополнительными типами и таймаутами. Кстати, частое явление в этом нашем х-ле — то ли тупо запихнуть всё в один тип, то ли устроить содомию с тайпклассами и обёртками на экзистенциальных типах. Как говорится, есть два стула.

Твоё лицо, когда не любишь сервант, но пишешь какое-то его подобие для UDP

Пока так:
https://gist.github.com/voidlizard/2e27a831bcc295f3c5320802aef42c9b

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

Убрал оптимизацию / скорость выросла

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

сделаешь вот в игрушечном модельном 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, но юзеры в ужасе бегут, полагаю.