ивообще Transactor[monix.Task]?

вместе с дубёй

дуби идет с fs2

там есть транзакторы в fs2.Task, IOLite

в 0.4

в monix.Task вроде не было

как я по доке понял, и моникс по идее

Similar types like scalaz.effect.IO, scalaz.concurrent.Task, fs2.Task, and monix.Task also work fine.

Из каробки не забработает

кароч

M[_]: Catchable: Suspendable]

если будет monix.Task: fs2.Catchable: fs2.Suspendable

Роджер. Жаль, что так. Хотел намешать себе смузи из библиотек, которые ни разу в глаза не видел. Видимо стоит расслабиться и выкинуть моникс в таком случае.

если будет monix.Task: fs2.Catchable: fs2.Suspendable

то заработает

https://github.com/monix/monix/issues/299

типа того

можно попробовать

О, спасибо! Вечерком попробую. Для начала сооружу хоть что-то работающее на fs2

@steveOrElse в твоем случаем, мне кажется ты гдет импорт потерял

жаль, но нет

какие есть best practice чтобы передавать контекст в акковских стримах? например flowId для каждого элемента. я пока лучше враппера ничего еще не придумал, но это выглядит некрасиво и костыльно

жаль, но нет

а ну да, моникс. Не заметил

https://github.com/typelevel/general/issues/74#issuecomment-301990373 продолжение банкета

юзает кто fs2 (таски, стримы), как вам? По сравнению с Monix например

А речь о стримах или тасках?

Ребят как мокать play.api.Logger?

trait Logger[F[_]] { def debug(message: String): F[Unit] }

trait Logger[F[_]] { def debug(message: String): F[Unit] }

Но-но! message: => String

твоя правда

как бы много я отдал за forall в скале чтоб можно было писать def foo[M[_[_]], A](f: forAll F[_]. M[F] => F[A]]): Foo = ... foo[Logger](_.debug("bar"))

или хотя бы f: (M[F] => F[A]) forAll { type F[_] }

для консистентности с forSome

Так это же object

че то намешал в кучу два синтаксиса и не понятно что имелось ввиду то ли функция, то ли экземпляр класса

Вопрос скорее в том как мокать object

делай явный синглтон с инжектом, если di есть, например

а для чего мокать логгер?

просто любопытно

Причины две: тестировать корректный вызов логгера, игнорировать печать логов в тестах

тогда лучше инжектить абстрактный интерфейс

и в тестах подсовывать свою реализацию с Vector[String] а в проде с play.api.Logger

Походу так и надо делать

Спасибо

Размышлял над этим но думал есть же что то готовое от плэй

trait Logger[F[_]] { def debug(message: String): F[Unit] }

я не шутил когда это писал :) просто это next левел

Причины две: тестировать корректный вызов логгера, игнорировать печать логов в тестах

для этого нужно в properties файле отключить логи, а не херню придумывать)

ну а если логирование важный эффект?

и важно проверить что там

запись в базу через логи)

запись в логи через логи

через блоги

"в прод мне логи" (с)

ну а если логирование важный эффект?

Значит ты что-то делаешь не так

Раз вместо бизнес логики тестируешь логирование

так то да

Херню придумывать приходиться по тому что Logger object

точка

Разве там еще не все, включая логгер инжектить надо?

но то, что его инжектить можно, это факт

Херню придумывать приходиться по тому что Logger object

а чем должен быть?

ну инстансом видимо

а object не инстанс? )

Как Configuration мне подойдет

Как Configuration мне подойдет

дык всегда можно сделать getLogger и для него сделать свою конфигурацию

Не всегда в том то и дело

в каких случаях нельзя?

Когда нет времени все переписывать

эм

кстати всеми любимый LazyLogging берет имя класса когда делает getLogger, дальше можно просто в каком нибудеь logback.xml чо угодно навернуть

вообще ничего не переписывая

навернуть верное слово

на днях попробую разобраться

нет времени переписывать логер, но есть время его тестировать? я не понимаю кейс и так обидно становится =(

зачем его переписывать?

и тем более мокать)

его можно конечно через powermock замокать, но зачем?

Ну давай прикинем что ловим исключение и пишем в лог. Какая тут альтернатива?

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

А есть какая-то классная библиотека, которая позволяет сделать def a(b: Int, c: Int) = b + c a.tupled ? То есть оно же работает вот так (a : (Int, Int) => Int).tupled Неужели сложно написать макрос/метод, который всегда будет требовать function в типе?

Надоело писать (a _), это уродство

а то, что идея не переваривает дуби, это норм или лечится?

кто читает скала чат, тот в цирке не смеется ?

а то, что идея не переваривает дуби, это норм или лечится?

Норм

А есть какая-то классная библиотека, которая позволяет сделать def a(b: Int, c: Int) = b + c a.tupled ? То есть оно же работает вот так (a : (Int, Int) => Int).tupled Неужели сложно написать макрос/метод, который всегда будет требовать function в типе?

Не совсем понял, что ты хочешь сделать?

Не совсем понял, что ты хочешь сделать?

Я хочу уметь вызывать tupled сразу у метода, не конвертя его явно в функцию перед этим

или хочу синтаксис methodName.toFunction.tupled

Определи a сразу с tuple )))

Надоело писать (a _), это уродство

пиши def prettyTupled[T1,T2,T3](a:Function2[T1,T2,T3]) = a.tupled val b = prettyTupled(a)

кстати, то что slick все сливают - это я понял.. но почему doobie, а не quill например? расскажите неопытному..

typelevel ибо

кстати, то что slick все сливают - это я понял.. но почему doobie, а не quill например? расскажите неопытному..

Шо, опять?

doobie это фриалгебра по сути

Не орм

Не фрм