Alexander
остальное все равно ты будешь делать middleware
Alexander
остальное (типа возможности асинхронного вывода, настройки часов и т.п.) либа может
Alexander
но похоже в этой либе нету дуракцих решений из di и katip и есть шанс сделать хороший логгер
Dmitrii
@chshersh прикольный логгер, точнее то, что база без лишнего и можно на его основе нормальный сделать.
Вообще в логгере нужно примерно как в di, иметь структуру, стек [path_or_context]
Спасибо! 😊`CallStack` уже добавляется и показывается номер строки кода, в которой было логирование сделано. ThreadId использовался в прошлом проекте, где я работал. Расширить можно просто. Я надеюсь, что после использования станет лучше видно, чего не хватает и что надо допилить.
Alexander
мне наверное ещё хотелось бы возможность иметь какой-то стейт между сообщениями для эффективности
Alexander
callstack не нужен
Dmitrii
но похоже в этой либе нету дуракцих решений из di и katip и есть шанс сделать хороший логгер
А какие там дурацкие решения?
Alexander
нужен стек тегов
Dmitrii
мне наверное ещё хотелось бы возможность иметь какой-то стейт между сообщениями для эффективности
А что значит стейт между сообщениями?
Dmitrii
нужен стек тегов
Это тоже не так сложно сделать, интерфейс вроде позволяет. Можно считать, что CallStack — это такой самый простой работающий из коробки автоматический стэк тегов.
Alexander
katip притащили в пакет слишком много:
1. можно добавлять много scribe (на самом деле всегда можно сделать 1 который делает много)
2. есть много лишнего, что логируется: environment, processid и т.д и тащится
3. не эффективное представление тегов
4. не конфигурируемый вывод сообщения, в итоге приходится scribe переписывать
di:
1. не конфигурируемая асинхронность
2. только monad-approach
Alexander
Это тоже не так сложно сделать, интерфейс вроде позволяет. Можно считать, что CallStack — это такой самый простой работающий из коробки автоматический стэк тегов.
или я что-то не знаю про стек тегов или мы понимаем под этим совсем разное
Alexander
стек тегов это возможность ко всем сообщениям в этом же стеке добавить какую-либо информацию, например, user id,
Alexander
и компонент
Alexander
для того, чтобы при сериализации сообщения можно было собрать структурированный json
Dmitrii
или я что-то не знаю про стек тегов или мы понимаем под этим совсем разное
Пока что CallStack используется, как простой способ показывать строку кода, в которой вызвалось логирование. Прикольная фича, и иногда бывает полезно. Конечно, можно отключить, чтобы этого не было.
Dmitrii
стек тегов это возможность ко всем сообщениям в этом же стеке добавить какую-либо информацию, например, user id,
А, кажется, это как раз того, для чего в библиотеке есть комонады 🙂 С их помощью можно вроде решить эту проблему, и она станет не проблемой
Alexander
в katip это не стек, это просто большой Aeson.Value
Alexander
и на каждой записи в лог он сериализуется, (идеально было бы как-то переиспользовать работу) но я не знаю как
Alexander
в di это как и надо стек
Alexander
в одной прикольной закрытой сишной программе там dsl для управления стейт машинами логов
Alexander
но, к сожалению, у них патенты на это решение
Alexander
у вас в либе прикольно, что она не делает лишнего (судя по блогу)
Alexander
и делает то, что надо
Dmitrii
у вас в либе прикольно, что она не делает лишнего (судя по блогу)
Это и было одной из основных целей библиотеки. Сделать гибкий и простой базовый интерфейс, поверх которого можно уже сделать все, что душе захочется.
Alexander
т.к. меня достало, что с катипом я начинаю переписывать куски
Alexander
400 строк переизобретения
Igor
Кто-то тут когда писал, что им удалось сериализовывать программу на Free Monads, тем самым обеспечивая факт, что программу можно будет запустить после инцидента, восстановив и десериализовав ее. Я правильно понял?
Igor
По-моему это был @graninas, если не ошибаюсь
Alexander
Это был я
Alexander
Программу перезапустить после инцидента - да. Можно прибить kill -9 раннер, запустить другой (потенциально на другой машине), и программа начнет работать с того же места.
Работало это так:
- У нас всегда был текст этого workflow в БД в виде PureScript-кода.
- Мы отправляли в БД результат каждого шага.
- Мы умели взять список результатов от шагов скрипта и прокрутить скрипт, не выполняя операции, до места, когда он сдох.
Alexander
Мы также могли считать, сколько шагов скрипт выполняется, и если нужно, его обрывать.
Igor
Программу перезапустить после инцидента - да. Можно прибить kill -9 раннер, запустить другой (потенциально на другой машине), и программа начнет работать с того же места.
Работало это так:
- У нас всегда был текст этого workflow в БД в виде PureScript-кода.
- Мы отправляли в БД результат каждого шага.
- Мы умели взять список результатов от шагов скрипта и прокрутить скрипт, не выполняя операции, до места, когда он сдох.
Интересно было бы узнать мотивацию этого, если, например, можно буферизировать входные данные программы в некоей персистентной очереди.
Alexander
Про буферизацию и персистентную очередь не понял
Мы сделали эти workflow для бизнес-сценариев, которые могут длиться оооочень долго. Хоть час, хоть день, хоть неделю.
Alexander
Типа, ты задал программе входные данные, и можешь в следующий раз задать те же данные, и программа пойдет тем же путем? Нет, наши workflow интерактивные, они общаются с внешним миром, в них есть развилки и все такое
Igor
Alexander
у нас так тоже было
Alexander
там был граф + куча воркеров работающих, и умеющих персиститься
Alexander
Да только ленивый не писал свои workflow ;)
Alexander
сишники такое любят, но они без free monad обходятся
Alexander
лучше бы мы без free monad обходились
Alexander
accidental complexity там огромный
Alexander
Ну мы еще могли подменять сценарии на ходу при некоторых условиях.
Alexander
accidental complexity там огромный
У нас крайне малый. Может, у вас неправильно все сделано было
Alexander
может
Alexander
Я ж скрины где-то постил
Alexander
вообще тот кусок пыталсь сделать 3 человека, почему-то по разному
Alexander
я уже забил все переделывать и просто довел до разумной семантики то, что было
Alexander
но по хорошему надо было все выкинуть к чертям
NC
И переписать!
Alexander
да
NC
На колве итераций сходящейся к бесконечности, получилось бы обязательно найти нужный дизайн
Alexander
нужно было сделать апи к очереди и базе
Alexander
и дать писать скрипты на lua
Alexander
Ну, если там сугубо Haskell, то сложнее, конечно. Нас спасало то, что PureScript - это, на самом деле, JavaScript, только в обертке. Чтобы персистить сам текст программы и потом запускать его на node.js использовался простой, но все же трюк из мира JS
Alexander
и сказать заказчику, вам надо - вы и пишите
NC
> lua
/me triggered
Alexander
Алексей
стек тегов это возможность ко всем сообщениям в этом же стеке добавить какую-либо информацию, например, user id,
Я для этого namepsace в катипе импользую
Igor
Ну, если там сугубо Haskell, то сложнее, конечно. Нас спасало то, что PureScript - это, на самом деле, JavaScript, только в обертке. Чтобы персистить сам текст программы и потом запускать его на node.js использовался простой, но все же трюк из мира JS
Да, мне вот интересно насколько это применимо к другим рантаймам (более конкретно, JVM)
Alexander
класть структурированные данные в namespace странно
Alexander
вообще namespace и environment по функциональности пересекаются там
Alexander
Алексей
Там очень просты данные. Типа какая подсистема
Alexander
в общем-то это tagged dsl
Alexander
в namespace - да подсистемы
Alexander
ещё мне нужно теги, типа user, workbook, session, transactionid
Alexander
Да, мне вот интересно насколько это применимо к другим рантаймам (более конкретно, JVM)
Для Clojure, думаю, проблем не будет, она динамическая. Для других языков можно, в принципе, хранить текст на исходном языке, а потом, наверное, его компилировать перед запуском. Или даже хранить байт-код
Alexander
чтобы можно было искать по логам в разных программах и разные срезы
NC
Для llvm бекендов нет проблем с байткодом
NC
Хаскелль через ghc api тоже можно в байткод прогнать
Alexander
> lua
/me triggered
нужен простой (для случайного программиста) встраиваемый, интерпретируемый язык, с возможностью динамического обновления
NC
Меня всегда останавливало, что непонятно какие вообще там оптимизации остаются
Alexander
для записи не очень больших скриптов
Alexander
есть что получше?
NC
есть ещё angel script, он поприятнее
Alexander
для людей которые знают питон и си
NC
есть наноси
Alexander
Для Clojure, думаю, проблем не будет, она динамическая. Для других языков можно, в принципе, хранить текст на исходном языке, а потом, наверное, его компилировать перед запуском. Или даже хранить байт-код
всегда можно сделать closure map как в distributed-process