Size: a a a

2019 November 09

AN

Alexander Nozik in Kotlin Moscow
Ну тут скорее вопрос был в том, что делать если есть несколько сущностей с независимыми жизненными циклами в одном приложении. Стоит ли их делать глобальными, или надо завести один скоуп на приложение и ему все подчинить
источник

AN

Alexander Nozik in Kotlin Moscow
Ну это уже очень философский вопрос. Если ваще приложение перестает жить только со смертью процесса, то нет разницы есть ли у вас явно такой объект как этот самый "application scope" или вы просто используете GlobalScope.
источник

SM

Sergey Morgunov in Kotlin Moscow
Спасибо!
источник

SM

Sergey Morgunov in Kotlin Moscow
Alexander Nozik
Ну это уже очень философский вопрос. Если ваще приложение перестает жить только со смертью процесса, то нет разницы есть ли у вас явно такой объект как этот самый "application scope" или вы просто используете GlobalScope.
Но в рамках этого философского вопроса вариант когда CoroutineScope = RequestScope тоже уместен, верно? Т.е. не обязательно иметь общего предка ApplicationScope для всех RequestScope, если гарантировать что скоуп корутины умрёт вместе с завершением жизненного цикла запроса, верно?
источник

AN

Alexander Nozik in Kotlin Moscow
Sergey Morgunov
Но в рамках этого философского вопроса вариант когда CoroutineScope = RequestScope тоже уместен, верно? Т.е. не обязательно иметь общего предка ApplicationScope для всех RequestScope, если гарантировать что скоуп корутины умрёт вместе с завершением жизненного цикла запроса, верно?
Не обязательно, но выше уже объясняли, что это обычно логично
источник
2019 November 12

VV

Vladislav Verminsky in Kotlin Moscow
источник

VV

Vladislav Verminsky in Kotlin Moscow
@Sergei_88 ну что, организуем? ;)
источник

SM

Sergey Morgunov in Kotlin Moscow
Мне кажется годная идея 🙂
источник

Ⓢⓔⓡⓖ in Kotlin Moscow
Vladislav Verminsky
@Sergei_88 ну что, организуем? ;)
У нас итак есть поддержка JetBrains.
источник

Ⓢⓔⓡⓖ in Kotlin Moscow
Ну можно организовать
источник

Ⓢⓔⓡⓖ in Kotlin Moscow
Докладчикам респект и дарят футболки с Котлином
источник
2019 November 13

Ⓢⓔⓡⓖ in Kotlin Moscow
https://softer-meetup.timepad.ru/event/1117656/ кто хочет потренироваться в работе с БД ?
источник

MK

Mark Kos in Kotlin Moscow
Ⓢⓔⓡⓖ
https://softer-meetup.timepad.ru/event/1117656/ кто хочет потренироваться в работе с БД ?
Я хотел бы. Оставил заявку
источник
2019 November 14

AL

Alex Levin ★ in Kotlin Moscow
С позволения админа группы, приглашаю подписаться на канал @ITMeeting - агрегатор анонсов о бесплатных митапах и конференциях по разработке в Москве.
источник

И

Илья in Kotlin Moscow
@Sergei_88 тут сомнение, надо ли в спам отправлять
источник

AN

Alexander Nozik in Kotlin Moscow
Илья
@Sergei_88 тут сомнение, надо ли в спам отправлять
нормально. По делу
источник

SM

Sergey Morgunov in Kotlin Moscow
Друзья, привет! Возвращаясь к вопросам по корутинам. Есть тривиальный кейс с вложенными вызовами suspend функций. В последнем из вызовов происходит выброс исключения, которое ловится только в стартовой функции, которая запустила всю эту цепочку вызовов suspend функций, и исключение отправляется в лог.
Утверждается, что стектрейс в логе должен быть полноценным, так как в 1.1 релизнули Stack trace recovery https://github.com/Kotlin/kotlinx.coroutines/issues/74
И это действительно вроде как работает, но только если в промежуточных вызовах не менять диспетчера. А вот если его сменить, что стек трейс получается обрезанным.
Вопрос: Это бай дизайн или это бага? Просто открытого issue по этой теме найти не могу, а мне кажется я не один такой желающий и если бы это была бага, давно бы уже создали.

Ну и если это бай дизайн, то может кто подскажет какой хак, как всё-таки увидеть в логах полную цепочку вызовов suspend функций? Слабо себе представляю, как можно разбирать инцидент на проде, если в логах только стектрейс последней континуации и хз по какому пути мы туда пришли 🙁
источник

AN

Alexander Nozik in Kotlin Moscow
Sergey Morgunov
Друзья, привет! Возвращаясь к вопросам по корутинам. Есть тривиальный кейс с вложенными вызовами suspend функций. В последнем из вызовов происходит выброс исключения, которое ловится только в стартовой функции, которая запустила всю эту цепочку вызовов suspend функций, и исключение отправляется в лог.
Утверждается, что стектрейс в логе должен быть полноценным, так как в 1.1 релизнули Stack trace recovery https://github.com/Kotlin/kotlinx.coroutines/issues/74
И это действительно вроде как работает, но только если в промежуточных вызовах не менять диспетчера. А вот если его сменить, что стек трейс получается обрезанным.
Вопрос: Это бай дизайн или это бага? Просто открытого issue по этой теме найти не могу, а мне кажется я не один такой желающий и если бы это была бага, давно бы уже создали.

Ну и если это бай дизайн, то может кто подскажет какой хак, как всё-таки увидеть в логах полную цепочку вызовов suspend функций? Слабо себе представляю, как можно разбирать инцидент на проде, если в логах только стектрейс последней континуации и хз по какому пути мы туда пришли 🙁
Ну вроде как стак трейс от диспатчера меняться не должен. Надо бы MRE сделать.
источник

SM

Sergey Morgunov in Kotlin Moscow
MRE это что-то от minimal reproduce? 🙂 Не знаком с таким сокращением 🙂
источник

AN

Alexander Nozik in Kotlin Moscow
Sergey Morgunov
MRE это что-то от minimal reproduce? 🙂 Не знаком с таким сокращением 🙂
да, я тоже недавно освоил для краткости. Где-то в чатиках подсмотрел
источник