а где нет таких заморочек?

вроде умные люди katip советовали :)

а в кардане вашем нет логгирования?

там свой велосипед, Серокельцы что-то своё сделали

мне нужно готовое решение

ReaderT (Text -> IO ()) ?

на хакидж выложили хоть?

ну и катип вроде готовый

@qnikst тыж за katip ратовал?

У katip год назад лог был не сильно читаемый, скажем так.

понапишут на закрытых TF кода, а потом кроме Verb ничего не подходит

я когда auth патчил перевел часть на открытые

катип норм

jq wtf

У katip год назад лог был не сильно читаемый, скажем так.

форматтер плохой или о чём речь?

[timestamp][severity][thread][some][thing][else]:me ssage that you are supposed to read

норм пацаны логают json

Literally. Его, наверное, можно застроить, но искаропки выглядит примерно так

нормально выглядит

kir при тебе же ещё у нас json лог был

или ещё нет?

Ну или в базу лог писать. Если честно, я json-лога не помню. Наверное, всё-таки после меня уже)

вообще стандартный несколько жутковат в основном своим ордерингом

т.е. [timestamp][namespace][tags] message было бы норм

а там было сначала то, что часто менятся, потом, что редко

слоан правда потом требовал назад простые логи

не json

Вообще, в идеале, логи надо класть в базу и читать отдельной программой

одно другому не мешает

у нас какая-то тулза все в стекдрайвер кладет

дурацкая тулза, лучше бы мы сами процессили

в общем если нужно структурированное логирование контексты теги и это все то katip норм

Насколько эти расширения распространены?

Используем повсеместно.

Насколько эти расширения распространены?

Вообще, мы вот это взяли на вооружение: https://gist.github.com/mtesseract/1b69087b0aeeb6ddd7023ff05f7b7e68 Хорошо работает.

> In order to prevent these issues, I suggest to put all lens definitions in one module named e.g. Lenses. This module imports all desired types and uses makeFieldsNoPrefix for generting the lens type classes and instances.

в общем у меня есть множество своих репов которые я добавляю в extra-deps с указанием тега также их все в кабале добавляю и один из них стек не видит. то есть реп скачал, а зависимость такую не находит In the dependencies for yyy-0.1.0.0: xxx needed, but the stack configuration has no specified version как бы мне диагностировать что пошло не так

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

можно у стека спросить какие ему доступны зависимости?

Итого у нас есть: AppName.Context.Domain.всякие_файлы_для_типов.hs AppName.Context.Domain.hs -- Содержит референсы на доменные типы AppName.Context.Lens.hs -- линзы. Импортирует AppName.Context.Domain.hs

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

Этого не понял, если честно

concat <$> sequence [ makeFields ''Foo, makeField ''Bar....] компилируется быстрее чем makeFields ''Foo makeFields ''Bar ...

но для дублирующихся полей надо определять HasFoo класс заранее

Гмм

А оно того стоит вообще? У нас пачки makeFields, и все дела. (Точнее, пачки `makeFieldsNoPrefix`)

? У нас другое в разы замедляет компиляцию. А именно, Type Families для рекордов.

ну вы еще vinyl затащите к себе

вообще да, TH очень тормозит если в одном модуле. если по разным то не так страшно

https://twitter.com/dshevchenko_biz/status/981925201880469505

ну вы еще vinyl затащите к себе

Ужо

?

К счастью, удалось убедить любителя тайпмагии, что это лучше не пускать в бизнеслогику, а оставить для маппинга БД

Там сущий ад. Opaleye+vinyl+кастомные надстройки

o.O

Ну и да, Сервант ещена закуску

сервант норм

винил тоже норм

сервант норм

Это ты еще не пробовал Сервант + freer эффекты

freer не нужен

точнее я не знаю пока ни одного юзкейса где freer нужен, а правильного mtl не хватит

У нас норм зашел, который от Takt

у олега в статье было что-то, но я не уверен что я оценил

Ну моки писать хорошо

винил тоже норм

Смотря сколько и какого размера рекорды. У меня было такое что 8 модулей с операциями с БД компилировались минут 15

день убил на бойлерплейт и переписал на рекорды обычные. теперь тормозят только makeFields, но всего 30 сек (4 минуты весь проект на 8 ядрах)

а вот кстати, коллеги, какие ghc-options нужны для ускорения компиляции?

вернее так: на какие опции нужно обратить внимание прежде всего?

понятно, что убрать оптимизацию

что ещё?

-fno-code

Ну моки писать хорошо

сложностью управлять

для моков free(r) не обязателен

с handle/servce pattern или mtl все прекрасно делатеся

-fno-code

Да, знаю про такое. А ещё что?

Да, делается. Но с freer моки - это паттерн-матчинг. Правда, если много бизнес-логики вовлечено, то там все начинает плохо выглядеть

там для специализаций отлючения было что-то

Да, делается. Но с freer моки - это паттерн-матчинг. Правда, если много бизнес-логики вовлечено, то там все начинает плохо выглядеть

вообще не вижу причин, почему с freer это чем-то проще

я кстати ищу кейсы где freer будет лучше, пока знаю 0

freer+effects

А я, в свою очередь, не вижу предмета спора. Дело вкуса. По крайней мере до тех пор, пока сообщество прочно не поймет плюсы и минусы

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

Не вижу в сообщении знака вопроса ;)

Я человек простой, - вижу вопрос, отвечаю. Не вижу - не отвечаю

...я кстати ищу кейсы где freer будет лучше, пока знаю 0 <- не спор а призвание делиться такими кейсами

free(r) <-> final tagless конвертируются в обе стороны

Я все же не смогу ответить удовлетворительно, потому что это ж надо несколько кейсов иметь, сравнивать их, понимать. У меня пока только 1.

т.е. из одного другое можно легко сделать

(На самом деле, больше, но то уже из другой оперы)

тогда возникает вопрос, может один из вариантов лучше

Просто для информации: наши freer-языки - это такие: OrderL RestaurantL CompanyL ... Каждый из них что-то умеет по своему контексту. А есть контексты более верхнего уровня, они уже пользуют эти вот языки

у олега точно был пейпер, показывающий проблемы инициальных интерпретаторов (фри[р]) и как терминальные интерпретаторы (финал тэглесс) их решают

MonadOrder, MonadRestaurant, MonadCompany

у олега точно был пейпер, показывающий проблемы инициальных интерпретаторов (фри[р]) и как терминальные интерпретаторы (финал тэглесс) их решают

Олег теоретик...

@kana_sama у него было и наоброт

exteff.pdf

когда он extensible-effects вводил, показывал как в mtl у нас чепуха получается, а с эффектами и free все хорошо

ну эксэфф это пара страниц, а там было штук 50 наверное

12

одна из проблем freer что они тормозят

а ты вычел код, референсы, опен юнионы и прочее подводящее к теме? там про плюсы/минусы фри-эффектов пара страниц, но цифра таки с головы

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