сейчас вот такая штука есть

еще можно вроде через ScriptEngine который в JSR

https://stackoverflow.com/a/16883802

что-то типа такого

я последний раз использовал twitter utils. ScriptEngine тоже пробовал

что в итоге зашло?

но это чисто для проверки было, я не внедрял нигде на проде это

то есть даже какие-то моменты с удобством и сложностями интеграции я не могу рассказать

ага интересно спасибо, посмотрю в сторону этих либ

jsr223 + scala был очень медленный (3 года назад) не факт что ситуация исправилась

по-моему, была таска в трекере на эту тему, можно поискать

скорость не критичная - операции простые и достаточно редкие

Олег, я правильно понимаю, что с Iterant можно реализовать автозакрытие сессии, после считывания? Iterant[Session, A]? Не совсем понимаю, как это происходит

/** Given a routine make sure to execute it whenever * the consumer executes the current `stop` action. */ final def doOnEarlyStop(f: F[Unit])(implicit F: Sync[F]): Iterant[F, A] /** Returns a new enumerator in which `f` is scheduled to be executed * on [[Iterant.Halt halt]] or on [[earlyStop]]. */ final def doOnFinish(f: Option[Throwable] => F[Unit])(implicit F: Sync[F]): Iterant[F, A

Но это гипотетически

Ну и у Observable куча методов doOn

да, в обсервабле как раз doOnFinish и юзаю

просто не совсем понимаю смысл наличия Session в Iterant[Session, Record]]

чем Iterant отличается от Observable...

https://github.com/dos65/scala_ru_stickers - зашарил пдфки под стикеры с размеченными краями под резку

https://github.com/dos65/scala_ru_stickers/blob/master/yellow_face.pdf

https://github.com/dos65/scala_ru_stickers - зашарил пдфки под стикеры с размеченными краями под резку

круто, с листочком бы ещё

которая сейчас лого чата

вот этими парнями нужно выкладывать дорожку до конференций и митапов

чем Iterant отличается от Observable...

Если ты не намереваешься ничего такого Session scoped делать, и вся суть - закрыть что-то там после потребления потока, то хватит и Observable

Но просто это не даёт тебе реюзабельности

Alexandru Nedelcu @alexandru 17:09 Observable is push-based with back-pressure (a hybrid), Iterant is pull-based.

А вот запихнуть что-то внутрь Session, которая конвертится в IO через инициализацию какого-то ресурса, запуск всех действий и потом освобождения ресурса - валидный реюзабельный подход

Тогда тебе не нужно on... в Iterant

круто, с листочком бы ещё

а кто автор? кидайте реквесты)

ты делаешь просто определение своего стрима, который возвращает Iterant[Session, E], потребляешь этот стрим, получая Session[Result] и дальше конвертируешь это во всю совокупность действий IO[Result]

а кто автор? кидайте реквесты)

не знаю, но картинка классная)

ты делаешь просто определение своего стрима, который возвращает Iterant[Session, E], потребляешь этот стрим, получая Session[Result] и дальше конвертируешь это во всю совокупность действий IO[Result]

а в какой момент close() вызывается?

Ну логично было бы. Этим ты как раз и объявляешь, что твой эффект заключается в том, что ты предлагаешь комбинировать действия внутри Session, и предоставляешь какой-то Session[T]{ runSession(...): IO[T] } который создаст новую сессию, запустит всё, что скомбинировано и закроет её. И для того, чтобы можно было туда и простой IO засовывать, реализуешь явно LiftIO[Session]

а в какой момент close() вызывается?

в конце runSession

@dos65 лицензию добавь

дело в том, что мне не надо потреблять стрим, а нужно отдать его выше, а без этого в runSession закрыть её не получится, только onFinish

@dos65 лицензию добавь

какую?)

а кто автор? кидайте реквесты)

@Angel608

spark web framework

creative commons же

какую?)

медийная какая-то криатив подсмотри у @Angel608

только лицензия обычно предполагает что-то свое)

только лицензия обычно предполагает что-то свое)

или отсуствие притензий на нечто не свое?

про такое не слышал

дело в том, что мне не надо потреблять стрим, а нужно отдать его выше, а без этого в runSession закрыть её не получится, только onFinish

Дело в том, что ты можешь это сделать

Ты просто делаешь монадку и StreamT на ней

И далее не заботишься о том, как юзер с ними обходится

Потому что потребляя твой StreamT[Session, ...] юзер получает Session[X]

И чтобы юзеру получить из Session[X] какой-то результат, ему нужно будет все эти залифтенные действия как-то запустить

А для этого нужно будет запустить runSession. Другого выхода из твоей монадки нет

А сам по себе StreamT\Iterant\Enumerator из твоей монады тоже выходить не умеет

А в runSession будет вся инициализация, потом все действия, потом вся деинициализация

И даже полученный таким образом IO будет реюзабельный

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

но разве Session это монада? Как должна композиция close происходить во flatMap - непонятно, учитывая, что там может быть и стрим и значение

Тебе не нужно делать композицию close

https://gist.github.com/Odomontois/e978d7e6597cb40ebb9299394917c9c0

open и close будут происходить вне flatMap

Внутри ты композируешь действия в форме reader монады, как будто у тебя всё уже инициализировано

И только при runSession инициализируешь, запускаешь, закрываешь один раз

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

Для стримов используй StreamT\Iterant\Enumerator

Ребят, вопрос из соседнего чата, почему скалиста не любят Котлин? Боятся?

прикинуться стеной - не лучший способ доказать что-либо

ERROR: S client not available

ребят, а объясните плиз, чем плох play. медленный? мало/много настроек? сложный в использовании?

Личное мнение: плох потому что это фреймворк, он диктует структуру приложения. Монструозный, часто нужен просто REST сервис, а он слишком много умеет.

Личное мнение: плох потому что это фреймворк, он диктует структуру приложения. Монструозный, часто нужен просто REST сервис, а он слишком много умеет.

что включает "просто REST"? JSON нужен? Обработка ошибок? Работа с сообщениями?

Ругать фреймворк за то, что он фреймворк

Что лишнего у Play?

понеслась)

Если REST, то есть какой-нибудь Lagom или http://spray.io/

десант холивара высажен: котлин и добивка плеем

скале не хватает фреймворков уровня спринг

в этом вся проблема

парни, он _мне_ не нравится, он не плох

Если REST, то есть какой-нибудь Lagom или http://spray.io/

некрофилы в треде

некрофилы в треде

Архивариусы

ага, akka-http

Я б попросил

Если REST, то есть какой-нибудь Lagom или http://spray.io/

его же закрыли ради akka-http, нет разве ?

его же закрыли ради akka-http, нет разве ?

Да я навскидку

десант холивара высажен: котлин и добивка плеем

про котлин уже забыли

не закрыли, перенесли, переименовали и отрефактороили

чо там плеем добивать то

парни, он _мне_ не нравится, он не плох

Ты написал, что плох, но это так, буквоедство

И вообще, вот чо надо юзать http://ktor.io/quickstart/application.html

Ты написал, что плох, но это так, буквоедство

?По этому и были уточняющие вопросы

Вообще akka-http это мой идеал, абсолютно прозрачно, можешь вмешаться на любом уровне в работу. Используется как библиотека. Канфэтка а нэ библиатэка.

Правда говорят, не сильно производительный, но тут не с play сравнивать.

Вообще akka-http это мой идеал, абсолютно прозрачно, можешь вмешаться на любом уровне в работу. Используется как библиотека. Канфэтка а нэ библиатэка.

И еще нож, вилка и тарелка, чтобы есть эту конфетку

ребят, а объясните плиз, чем плох play. медленный? мало/много настроек? сложный в использовании?

не медленный. если нужно сделать какой-то прототип - хорошо подходит. мне не нравятся некоторые выбранные дефолты в нем - например runtime DI, и их либа для json-а. но все это можно заменить

Если попытаться объективно: play для тех кому нужны готовые решения DI тот же, json, cookie, сессии, и тд. и тп. akka-http для тех кто хочет простроить все сам, относительно низкоуровневая штука

капитанство конечно))

кстати, часто как раз ненависть к play от тех кто хотел http api сделать, и взял play

Я взял play исключительно из за того что он мне позволил сосредоточиться на логике игры, избежав вот этого всего про http