а что такое представление для форм?

там есть servant-blaze который может выдавать html, из всего у чего есть ToMarkup

я не уверен, что из типа данных он может сгенерить форму

у нас используется swagger, который по API геренирует интерфейс с формами

но это не для пользователя интерфейс

а что такое представление для форм?

тип для представления в программе

и функции его декодирования из запроса

но это не для пользователя интерфейс

зачем формы непользователю?

есть servant-multipart для multipart-formdata

есть тестирование и администрирование

есть тестирование и администрирование

а, так это тоже пользователи, только не конечные

есть servant-multipart для multipart-formdata

спасибо

для urlencoded формы не знаю, поидее оно же через обычный url пойдет, и надо там комбинировать

А на каком примере можно видеть, что хвостовая важна?

forever f = f » forever f ?

А чтоб без монад?

в haskell хвостовая рекурсия не настолько интересна в силу ленивости

fix же

или iterate

Так. Туплю. Обе не хвостовые :)

fix - вообще хитрый

А чтоб без монад?

В любом рекурсивном коде с аккумулятором

а зачем доказывать важность TCO? не важна она. просто есть два стула — можно в язык добавлять особый синтаксис для циклов, а можно просто TCO

ну нет

фп код писать без нормальной tco проблематично

да с TCO всё проще. а если нужна явная форма цикла, она пишется как функция

да не только "форма цикла" нужна, нужно чтоб взаимнорекурсивные функции нормально оптимизировались

иначе никаких комбинаторных парсеров и т.д.

да не только "форма цикла" нужна, нужно чтоб взаимнорекурсивные функции нормально оптимизировались

звучит как возражение на мою реплику, но противоречия нет

@d37284 будет жить. Поприветствуем!

@sukhmel будет жить. Поприветствуем!

@chshersh прикольный логгер, точнее то, что база без лишнего и можно на его основе нормальный сделать. Вообще в логгере нужно примерно как в di, иметь структуру, стек [path_or_context]

т.е. память, processid, threadid на самом деле почти никогда не нужно, а когда нужно можно добавлять через context

остальное все равно ты будешь делать middleware

остальное (типа возможности асинхронного вывода, настройки часов и т.п.) либа может

но похоже в этой либе нету дуракцих решений из di и katip и есть шанс сделать хороший логгер

@chshersh прикольный логгер, точнее то, что база без лишнего и можно на его основе нормальный сделать. Вообще в логгере нужно примерно как в di, иметь структуру, стек [path_or_context]

Спасибо! ?`CallStack` уже добавляется и показывается номер строки кода, в которой было логирование сделано. ThreadId использовался в прошлом проекте, где я работал. Расширить можно просто. Я надеюсь, что после использования станет лучше видно, чего не хватает и что надо допилить.

мне наверное ещё хотелось бы возможность иметь какой-то стейт между сообщениями для эффективности

callstack не нужен

но похоже в этой либе нету дуракцих решений из di и katip и есть шанс сделать хороший логгер

А какие там дурацкие решения?

нужен стек тегов

мне наверное ещё хотелось бы возможность иметь какой-то стейт между сообщениями для эффективности

А что значит стейт между сообщениями?

нужен стек тегов

Это тоже не так сложно сделать, интерфейс вроде позволяет. Можно считать, что CallStack — это такой самый простой работающий из коробки автоматический стэк тегов.

katip притащили в пакет слишком много: 1. можно добавлять много scribe (на самом деле всегда можно сделать 1 который делает много) 2. есть много лишнего, что логируется: environment, processid и т.д и тащится 3. не эффективное представление тегов 4. не конфигурируемый вывод сообщения, в итоге приходится scribe переписывать di: 1. не конфигурируемая асинхронность 2. только monad-approach

Это тоже не так сложно сделать, интерфейс вроде позволяет. Можно считать, что CallStack — это такой самый простой работающий из коробки автоматический стэк тегов.

или я что-то не знаю про стек тегов или мы понимаем под этим совсем разное

стек тегов это возможность ко всем сообщениям в этом же стеке добавить какую-либо информацию, например, user id,

и компонент

для того, чтобы при сериализации сообщения можно было собрать структурированный json

или я что-то не знаю про стек тегов или мы понимаем под этим совсем разное

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

стек тегов это возможность ко всем сообщениям в этом же стеке добавить какую-либо информацию, например, user id,

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

в katip это не стек, это просто большой Aeson.Value

и на каждой записи в лог он сериализуется, (идеально было бы как-то переиспользовать работу) но я не знаю как

в di это как и надо стек

в одной прикольной закрытой сишной программе там dsl для управления стейт машинами логов

но, к сожалению, у них патенты на это решение

у вас в либе прикольно, что она не делает лишнего (судя по блогу)

и делает то, что надо

у вас в либе прикольно, что она не делает лишнего (судя по блогу)

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

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

400 строк переизобретения

Кто-то тут когда писал, что им удалось сериализовывать программу на Free Monads, тем самым обеспечивая факт, что программу можно будет запустить после инцидента, восстановив и десериализовав ее. Я правильно понял?

ERROR: S client not available

По-моему это был @graninas, если не ошибаюсь

Это был я

Программу перезапустить после инцидента - да. Можно прибить kill -9 раннер, запустить другой (потенциально на другой машине), и программа начнет работать с того же места. Работало это так: - У нас всегда был текст этого workflow в БД в виде PureScript-кода. - Мы отправляли в БД результат каждого шага. - Мы умели взять список результатов от шагов скрипта и прокрутить скрипт, не выполняя операции, до места, когда он сдох.

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

Программу перезапустить после инцидента - да. Можно прибить kill -9 раннер, запустить другой (потенциально на другой машине), и программа начнет работать с того же места. Работало это так: - У нас всегда был текст этого workflow в БД в виде PureScript-кода. - Мы отправляли в БД результат каждого шага. - Мы умели взять список результатов от шагов скрипта и прокрутить скрипт, не выполняя операции, до места, когда он сдох.

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

Про буферизацию и персистентную очередь не понял Мы сделали эти workflow для бизнес-сценариев, которые могут длиться оооочень долго. Хоть час, хоть день, хоть неделю.

Типа, ты задал программе входные данные, и можешь в следующий раз задать те же данные, и программа пойдет тем же путем? Нет, наши workflow интерактивные, они общаются с внешним миром, в них есть развилки и все такое

Типа, ты задал программе входные данные, и можешь в следующий раз задать те же данные, и программа пойдет тем же путем? Нет, наши workflow интерактивные, они общаются с внешним миром, в них есть развилки и все такое

Теперь понятно. Крутяк, конечно

у нас так тоже было

там был граф + куча воркеров работающих, и умеющих персиститься

Да только ленивый не писал свои workflow ;)

сишники такое любят, но они без free monad обходятся

лучше бы мы без free monad обходились

accidental complexity там огромный

Ну мы еще могли подменять сценарии на ходу при некоторых условиях.

accidental complexity там огромный

У нас крайне малый. Может, у вас неправильно все сделано было

может

Я ж скрины где-то постил

вообще тот кусок пыталсь сделать 3 человека, почему-то по разному

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

но по хорошему надо было все выкинуть к чертям

И переписать!

да

На колве итераций сходящейся к бесконечности, получилось бы обязательно найти нужный дизайн

нужно было сделать апи к очереди и базе

и дать писать скрипты на lua

Ну, если там сугубо Haskell, то сложнее, конечно. Нас спасало то, что PureScript - это, на самом деле, JavaScript, только в обертке. Чтобы персистить сам текст программы и потом запускать его на node.js использовался простой, но все же трюк из мира JS

и сказать заказчику, вам надо - вы и пишите

> lua /me triggered

Ну, если там сугубо Haskell, то сложнее, конечно. Нас спасало то, что PureScript - это, на самом деле, JavaScript, только в обертке. Чтобы персистить сам текст программы и потом запускать его на node.js использовался простой, но все же трюк из мира JS

у вас кейс несколько другой