val task: Stream[F, Unit] = for { taskId <- Stream.eval[F, TaskId](api.azaza()) status <- scheduler.retry[F, StatusResponse](api.status(taskId), 3 seconds, d => d.plus(3 seconds), 30, { case NonFatal(ex) => logger.warn(s"Status ${ex.getMessage}") true }) _ <- Stream.eval[F, ResultResponse](api.result(taskId)) } yield { println(status) }

так вот, azaza возвращает F[_] (в данном случае IO]

when(api.status(any()).thenAnswer(_ => IO.pure(Status))

а тебе стримы нужны ради ретраев?

when(api.status(any()).thenAnswer(_ => IO.pure(Status))

все правильно, но ток thenReturn

Ну так ты каждый раз вернёшь новый IO

и след thenReturn не сработает, потому что будет переиспользоваться IO

api.status вызовется 1 разик бро)

Ну дык thenAnswer?

Ну дык thenAnswer?

нет

api.status вызовется 1 разик бро)

Схерали?

Схерали?

ну иди посмотри))))

etry[F, StatusResponse](api.status(taskId), ...)

только один раз

потому что нет смысла несколько раз вызывать

так как никаких сайд эффектов нет

Тааак, а что он тогда ретрает?

выполнение

IO

IO[A] - описывает действия

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

Денис молодец

IO(println("1234")).flatMap(_ => IO(println("1234"))) это тоже самое что val a = IO(println("1234")); a.flatMap(_ => a)

Понимает

чего нельзя сказать про Future

scheduler.retry какие ограничения на F[_] накладывает?

scheduler.retry какие ограничения на F[_] накладывает?

Да, должен быть инстанс Effect вроде , надо глянуть

Ясн, я подумал, что IO одноразовые

Ну зачем ты так

Ясн, я подумал, что IO одноразовые

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

какое ты хочешь поведение от api.status? у тебя же IO в руках, значит можно что угодно сделать

какое ты хочешь поведение от api.status? у тебя же IO в руках, значит можно что угодно сделать

+ можно просто FSM сделать если надо для разных вызовов сделать разное поведение внутри IO

т.к. одноразовость явно противоречит referential transparency

какое ты хочешь поведение от api.status? у тебя же IO в руках, значит можно что угодно сделать

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

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

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

Ну камон бро)

def foo: IO[A] = { val i = AtomicInt(0) IO.defer { if (i.incrementAndGet < 3) IO.raiseError(lol) else IO(a) } }

хочешь прям совсем красиво прикрути MVar

а в скалаз будет IORef кекек

но как бы тебе нужен IO с памятю вне этого IO

def foo: IO[A] = { val i = AtomicInt(0) IO.defer { if (i.incrementAndGet < 3) IO.raiseError(lol) else IO(a) } }

это псевдокот (meow)

на самм деле я думаю, можно замокать runAsync

но .when(io.runAsync(any[Either[Throwable,StatusResponse]=>IO[Unit]]())) не работает)

@eld0727 предложи вариант лучше)

def foo: IO[A] = { val i = AtomicInt(0) IO.defer { if (i.incrementAndGet < 3) IO.raiseError(lol) else IO(a) } }

вот же

на самм деле я думаю, можно замокать runAsync

OMG

ну блин, мой перфекционизм все портит)

какой перфекционизм если ты юзаешь мокито

Ты хочешь стейт без стейта

какой перфекционизм если ты юзаешь мокито

ок, а что юзать?

@eld0727 предложи вариант лучше)

Я воспользуюсь методом ответить, не читая истории, А может сделать свой эффект с Async и liftIO, тогда и мокать не придётся?

IO :)

Я воспользуюсь методом ответить, не читая истории, А может сделать свой эффект с Async и liftIO, тогда и мокать не придётся?

как вариант, но я чет ленивый

Ну ты всё равно же будешь где то хранить, что ты сделал N вызовов

Ты хочешь стейт без стейта

на самом деле не совсем так, мокито то имеет стейт)

не я, а мокито

сам ж сказал что thenReturn можно несколько раз юзать)

I'm outta here

I'm outta here

уговорил, так и сделал

Мне кажется или в Scala 2.12 вывод типа параметра у анонимной функции стал работать лучше? Типа теперь во многих местах вместо object.method { parameter: Type => ... } можно писать просто object.method { parameter => ... }

Мне кажется или в Scala 2.12 вывод типа параметра у анонимной функции стал работать лучше? Типа теперь во многих местах вместо object.method { parameter: Type => ... } можно писать просто object.method { parameter => ... }

есть такое. Т.е. лямбды переписывались под жвм 8, там пофиксили по пути что-то

Мне кажется или в Scala 2.12 вывод типа параметра у анонимной функции стал работать лучше? Типа теперь во многих местах вместо object.method { parameter: Type => ... } можно писать просто object.method { parameter => ... }

в скала 2.12 там вобще много чего лучше стало, но не проси список - у меня его нет)

ERROR: S client not available

какой перфекционизм если ты юзаешь мокито

Вслух засмеялся.

Пацаны ваще финчята! Подскажите плиз, как подружить скалячью или твитерячью фьчу с финч эндпоинтом? Код val executeJob: Endpoint[JobId] = post("executeJob" :: jsonBody[AppParams]) { params: AppParams => val result: Future[JobId] = ... чо делать с result? Как Ok послать? }

Пацаны ваще финчята! Подскажите плиз, как подружить скалячью или твитерячью фьчу с финч эндпоинтом? Код val executeJob: Endpoint[JobId] = post("executeJob" :: jsonBody[AppParams]) { params: AppParams => val result: Future[JobId] = ... чо делать с result? Как Ok послать? }

ничего не понял, но возможно тебе нужно http://finagle.github.io/finch/cookbook.html#converting-between-scala-futures-and-twitter-futures

я конвертнул

теперь мне надо Ok вернуть

у меня есть Ок у меня есть фьюча с результатом

там же есть пример, возвращай

val e = get("foo") { Future.successful(Ok("bar")) }

то есть я могу сделать так? val executeJob: Endpoint[JobId] = post("executeJob" :: jsonBody[AppParams]) { params: AppParams => val result: Future[JobId] = ... result.map(Ok("беззаговорочный успех")) }

да

спрашивается зачем спрашивать когда можно проверить)

вобщем спасиб)

just do it

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

запили правки в доку) там только рады будут 2.5 мейнтейнера

А что, {implicit param: SomeType => foo()} foo(...)(implicit param: SomeType ) = ... implicit параметр в теле функции подхватывается как implicit val?

оформи код как код, непонятно ничего

А что, {implicit param: SomeType => foo()} foo(...)(implicit param: SomeType ) = ... implicit параметр в теле функции подхватывается как implicit val?

как implicit, да не обязательно как val

Но как stable reference, как минимум

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

А если параметорм будет функция, скала сделает преобразование типов при необходимости?

А если параметорм будет функция, скала сделает преобразование типов при необходимости?

к несчастью, скорее всего, да

хвала небесам, это намереваются выпилить

по производительности большое проседание , встречал кто цифры ?

У нас в 2-3 раза общая производительность с Kamon упала. Выбросили. Правда, это 3 года назад было. Может, сейчас получше уже.

У нас в 2-3 раза общая производительность с Kamon упала. Выбросили. Правда, это 3 года назад было. Может, сейчас получше уже.

А зачем вы агент использовали?

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

У нас в 2-3 раза общая производительность с Kamon упала. Выбросили. Правда, это 3 года назад было. Может, сейчас получше уже.

у нас незначительно повлиял на нагруженном спарко проекте

А зачем вы агент использовали?

Думали по-быстрому заиметь метрики внутренностей Акки для перформанс-тестирования и получили совсем ужасные результаты. В итоге понаписывали собственных велосипедов на базе Scala Metrics / Dropwizard - где-то напрямую в коде, где-то через наследование и aroundReceive()

Думали по-быстрому заиметь метрики внутренностей Акки для перформанс-тестирования и получили совсем ужасные результаты. В итоге понаписывали собственных велосипедов на базе Scala Metrics / Dropwizard - где-то напрямую в коде, где-то через наследование и aroundReceive()

А почему просто не выкинули агент и не использовали обычные метрики камона?

Думали по-быстрому заиметь метрики внутренностей Акки для перформанс-тестирования и получили совсем ужасные результаты. В итоге понаписывали собственных велосипедов на базе Scala Metrics / Dropwizard - где-то напрямую в коде, где-то через наследование и aroundReceive()

что считаете, если не секрет

Народ, а вот насчет камона. В дропвизарде можно метрики строить иерархично - делаешь Registry и вкладываешь друг в друга. И имя метрики строится также иерархично. В камоне я чёт такого не вижу. Там так можно? Или все метрики там идут как top level?