нет

нет

метод fillData покажите как объявлен

@CallSuper open fun fillData(data: Data, position: Int, isEnabled: Boolean) {

override fun fillData(data: ProfPeriod, position: Int, isEnabled: Boolean) {

@CallSuper open fun fillData(data: Data, position: Int, isEnabled: Boolean) {

тело метода покажите

override fun fillData(data: ProfPeriod, position: Int, isEnabled: Boolean) { super.fillData(data, position, isEnabled) startAt = data.start?.toMonthYear() ends_at = data.end?.toMonthYear() fillPeriods() itemView.btn_del.isVisible = isDeletable(position) itemView.divider_del.isVisible = isDeletable(position) }

fillData (Lcom/yamagoo/android/yamagoo/domain/dao/user/ProfPeriod;IZ) - так компилятор ругается на метод с одним параметром типа ProfPeriod

как понять, что конкретно ему не нравится

спросить в слаке, там сидит народ, который пишет компилер. либо завести таск на ютреке, похоже на баг

туда же прикрепить код, который приводит к ошибке

оки, спасибо

А рекурсию в suspend-функции и раньше нельзя было делать? Или это сейчас сломалось?

А как ругается?

А как ругается?

А, нашёл проблему. Ругается если вызывать coroutineScope { ... } Пишет

Type checking has run into a recursive problem. Easiest workaround: specify types of your declarations explicitly

Type checking has run into a recursive problem. Easiest workaround: specify types of your declarations explicitly

Ну дак это подефолту для рекурсии

Ну дак это подефолту для рекурсии

Но возникает только при наличии coroutineScope

Но возникает только при наличии coroutineScope

suspend fun foo(i: Int) = { if(i == 0) 0 else foo(i) }

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

suspend fun foo(i: Int) = { if(i == 0) 0 else foo(i) }

Да, но только от suspend в данном случае нет смысла, если не запускать корутины, а корутины надо куда-то подписывать

Да, но только от suspend в данном случае нет смысла, если не запускать корутины, а корутины надо куда-то подписывать

Т_Т я тебе за синтаксис тру, а не за логику

А как сейчас прицепить какой-нибудь обзёрвер, который вызовет определённый код, когда Job будет отменён? Вижу invokeOnCompletion, но это не то.

А как сейчас прицепить какой-нибудь обзёрвер, который вызовет определённый код, когда Job будет отменён? Вижу invokeOnCompletion, но это не то.

там в параметре nullable exception приходит

чуваки, такой вопрос: на сколько в среднем у людей с бекендов все ок с пониманием того что такое неблокирующие операции?

в среднем по любой теме обычно все плохо

Эт как...

чуваки, такой вопрос: на сколько в среднем у людей с бекендов все ок с пониманием того что такое неблокирующие операции?

Что такое "в среднем"? Типа, очевидно, что среднее зависит от выборки, а она как бы очень сильно отличается обычно.

Что такое "в среднем"? Типа, очевидно, что среднее зависит от выборки, а она как бы очень сильно отличается обычно.

в среднем для людей, которые посещают конфы

в среднем для людей, которые посещают конфы

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

чуваки, такой вопрос: на сколько в среднем у людей с бекендов все ок с пониманием того что такое неблокирующие операции?

что-то сказать могу о чем это, но боюсь

андроидщики точно знают что будет если заблочить главный поток, а вот что такое неблокирующий IO я не уверен)

андроидщики точно знают что будет если заблочить главный поток, а вот что такое неблокирующий IO я не уверен)

ну в js если "заблочить" главный поток то будет беда, ui висит

андроидщики точно знают что будет если заблочить главный поток, а вот что такое неблокирующий IO я не уверен)

так-то не особо понятно, как у нас его использовать и нужно ли

андроидщики точно знают что будет если заблочить главный поток, а вот что такое неблокирующий IO я не уверен)

Не блокирующий io позволяет на уровне приложения не блокировать текущий поток и не создавать новый. На Винде и .net это идёт из коробки и делается за счёт специальных io портов, которые работают на уровне ядра ос. Грубо говоря это что-то типо очередей, которые принимают запрос на какую-то io операцию и континюэйшн в том или ином виде (какие-нибудь низкоуровневые хэндлеры). С jvm наверняка все сложнее, зависит от jvm, os и прочего.

так-то не особо понятно, как у нас его использовать и нужно ли

вроде в последних версиях там тоже NIO подвезли, зачем-то)

вроде в последних версиях там тоже NIO подвезли, зачем-то)

Оно хорошо, но нам нет профита поддерживать два варианта.

чуваки, такой вопрос: на сколько в среднем у людей с бекендов все ок с пониманием того что такое неблокирующие операции?

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

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

думаешь особо не понимают зачем нужны пляски вокруг netty?

думаешь особо не понимают зачем нужны пляски вокруг netty?

все юзают спринг и не парятся

все операции блокирующие, так проще

и на большинстве проектов профита от перехода на неблокирующие либы не будет

все операции блокирующие, так проще

собственно, именно так появляются success stories вроде «перевели сервер на ноду, стало быстрее»

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

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

ну количество процов то не обгонишь, дело как раз в ожидающих операциях

в том числе на базу

например если запрос отрабатывает секунд по 10-15)

ну количество процов то не обгонишь, дело как раз в ожидающих операциях

ну если все потоки ждут на блокирующий операциях, то можно добавить еще, будет больше потоков ждать, общая производительность увеличится, если конечно ресурс, котрого ждут, будет справляться

если запрос в базу обрабатывается 10 секунд, то переход на неблокирующую либу это никак не изменит

если запрос в базу обрабатывается 10 секунд, то переход на неблокирующую либу это никак не изменит

почему же? если поток вернется в пул?

зависит от приложения канеш, но в целом если без боли можно неблокирующие юзать - то почему бы и нет

я переводил на completable feature спринговое приложение, немного профита было

*это был 2015-2016(не помню)

ну если все потоки ждут на блокирующий операциях, то можно добавить еще, будет больше потоков ждать, общая производительность увеличится, если конечно ресурс, котрого ждут, будет справляться

если 100 потоков будут сидеть ждать ресурса и у тебя цепочка из таких вот приложений, ждущих друг друга.. то это трата ресурсов

почему же? если поток вернется в пул?

вернулся, забрал новый запрос на обработку, снова пошел в базу, все упирается в базу, профит будет если есть другие типы запросов, желательно вообще без базы

вернулся, забрал новый запрос на обработку, снова пошел в базу, все упирается в базу, профит будет если есть другие типы запросов, желательно вообще без базы

понятно что профит будет до определенного уровня

если 100 потоков будут сидеть ждать ресурса и у тебя цепочка из таких вот приложений, ждущих друг друга.. то это трата ресурсов

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

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

если писать на webflux реакторах, то тут да. смысла особого нет, даже хуже выйдет

а если корутинки... то тут что блокирующий, что неблокирующий код. все равно одинаковый будет

но так то ты прав да

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

с ktor щас так и происходит, из netty worker -> default dispatcher прыгает постоянно

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

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

интересно, как это работает.. io обычно ждать нужно

ERROR: S client not available

даже если оно неблокирующее, все равно поток должен ждать эвентов на чтение/запись

shared pool?

он поток забирает себе как IO и разрешает для CPU зашедулить новый поток, если не хватает

https://github.com/Kotlin/kotlinx.coroutines/issues/261 тут хорошо описано

чотенько

ОФИГЕВАТ

Видел, что ты форкнул драйвер. Удивляюсь, что прошло совсем немного времени с того момента.

ОФИГЕВАТ

в vertx возможно что из того же потока все и работает, просто абстракций больше

(инфа не сотка)

Видел, что ты форкнул драйвер. Удивляюсь, что прошло совсем немного времени с того момента.

ну я почти месяц с ним ковырялся, не регулярно, но все-таки

Кто может подсказать ide под постгрес на мак?

datagrip

Чет инет покопал, ничего путного

Ей щас пользуюсь

Но нашел такую штуку что она отображает не все таблицы и вьюхи в схеме

DBeaver

Но нашел такую штуку что она отображает не все таблицы и вьюхи в схеме

это странновато, вообще-то, попробуй лучше зарепортить в JB. И ты точно говоришь про public.* ?

Но нашел такую штуку что она отображает не все таблицы и вьюхи в схеме

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

Это я делаю

И из схемы которую выбрал подтягиваются например 10 таблиц, а по факту их 15

Ну ладно, тут не этому тема посвящена, спасибо за помощь )

Ну ладно, тут не этому тема посвящена, спасибо за помощь )

Добрый день. у меня есть Абстрактный презентер`и `Презентер А. Презентер А наследуется от . В конструктор абстрактного презентера нужно передать класс, который инжектится с помощью даггера в теле презентера А . Подскажите, как это реализовать? сделать @inject constructor```в ```презентере А ? или можно как-то по-другому сделать?

Добрый день. у меня есть Абстрактный презентер`и `Презентер А. Презентер А наследуется от . В конструктор абстрактного презентера нужно передать класс, который инжектится с помощью даггера в теле презентера А . Подскажите, как это реализовать? сделать @inject constructor```в ```презентере А ? или можно как-то по-другому сделать?

класс нужно инжектить в конструктор презентера А

класс нужно инжектить в конструктор презентера А

class PresenterA @Inject constructor(myClass: MyClass): AbstractPresenter(myClass) таким образом, правильно?

угу

угу

а если в конструкторе презентра А есть еще другие переменные, которые не нужно инжектить

всё норм будет?)

т.е. они просто передаются туда без инжектинга

где они передаются?

будет не норм

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