хотя, вот если там io...

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

И все блокируются

Количество тредов должно превышать количество ядер в процессоре только в очень редком случае, когда там идут блокирующие вызоы. И даже в этом случае не надо создавать 1000 тредов, надо реющать уже созданные. В корутинах, если нет особой специфики вообще надо использовать CommonPool и не париться

Ну это не совсем так

В какой части? Если в первой, то это сознательное упрощение.

Есть еще всякие диспач-треды, которые живут вечно.

Количество тредов должно превышать количество ядер в процессоре только в очень редком случае, когда там идут блокирующие вызоы. И даже в этом случае не надо создавать 1000 тредов, надо реющать уже созданные. В корутинах, если нет особой специфики вообще надо использовать CommonPool и не париться

Так насколько я понял - если мы не указываем контекст, то CommonPool и используется

да

Ну, а вот попробуйте запустить этот код с CommonPool и посмотрите что получится

Вот так например val rnd = Random() val initList = (0..5000).toList() val asyncIter = initList.channeledCalls() { runBlocking { delay(rnd.nextInt(10000)) } it } asyncIter.forEach { println(it) }

delay неблокирующий, он суспендящий

В какой части? Если в первой, то это сознательное упрощение.

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

Да вырастет медиана

Я сознательно упростил. Подразумевал рабочие треды

Как раз про рабочие треды это втарая часть моего месаджа

Ну, а вот попробуйте запустить этот код с CommonPool и посмотрите что получится

код вообще странный. Вот это: async(start = CoroutineStart.LAZY, context = corCont) { function(it) }.also { def -> def.invokeOnCompletion { runBlocking { channel.send(def.getCompleted()) } } def.start() } не понятно, что должно делать. Почему не async(start = CoroutineStart.LAZY, context = corCont) { channel.send(function(it)) }

Вот так например val rnd = Random() val initList = (0..5000).toList() val asyncIter = initList.channeledCalls() { runBlocking { delay(rnd.nextInt(10000)) } it } asyncIter.forEach { println(it) }

А зачем делать runBlocking там? Понятно что runBlocking заблокирует весь CommonPool

В смысле без lazy старта

``` async { channel.send(function(it)) } ```

Скорее всего проблемы не по памяти, а по cpu. Если ты зарепортишь, то будет большой шанс что проблему починим. Если не зарепортишь -- мы о ней можем даже не узнать :)

кстати похоже - когда перешел на i9 прошку идея перестала лагать

Хорошая реклама. Надо брать.

ор

у меня и на заглушке не лагает

кстати похоже - когда перешел на i9 прошку идея перестала лагать

лол :)

блинблинблин, extension var не в силах перекрыть member val

удивительно

лапы прочь от мемберов и все такое

хочется внутри транзакции добавить сеттер

?‍♂️

Низя. Иначе груви получится, со всеми вытекающими последствиями

Можно сделать инлайн класс и добавить ему один метод.

Или заменить

Низя. Иначе груви получится, со всеми вытекающими последствиями

ну не)

А чего, я люблю груви, но когда его много, он становится слишком похож на питон.

А чего, я люблю груви, но когда его много, он становится слишком похож на питон.

Будто что-то плохое.

Verifier rejected class superpackage.MapFragment: void superpackage.MapFragment.render(superpackage.states$MapState) failed to verify: void superpackage.MapFragment.render(superpackage.states$MapState): [0x58] register v6 has type Reference: java.lang.Object but expected Precise Reference: superpackage.MapboxMapAdapter (declaration of 'superpackage.MapFragment' appears in /super/puper/package-1/base.apk:classes2.dex) У кoгo былo пoхoжее, в чем пpoблема? Пpям пoвальнo началoсь. UPD: кoнкpетнo в мoем случае пpoблема oказалась в тoм, чтo Android Studio и кoтлин плагин слишкoм глупые, чтoбы пoдсказать, чтo где-тo нужен явный тайпкаст Any -> T. В тo вpемя как в байткoде этo местo пpинималoсь за Any == Object и делалo мне такие гадoсти.

Стoит пеpеписать на java и все чики-бpики.

супер пупер

Verifier rejected class superpackage.MapFragment: void superpackage.MapFragment.render(superpackage.states$MapState) failed to verify: void superpackage.MapFragment.render(superpackage.states$MapState): [0x58] register v6 has type Reference: java.lang.Object but expected Precise Reference: superpackage.MapboxMapAdapter (declaration of 'superpackage.MapFragment' appears in /super/puper/package-1/base.apk:classes2.dex) У кoгo былo пoхoжее, в чем пpoблема? Пpям пoвальнo началoсь. UPD: кoнкpетнo в мoем случае пpoблема oказалась в тoм, чтo Android Studio и кoтлин плагин слишкoм глупые, чтoбы пoдсказать, чтo где-тo нужен явный тайпкаст Any -> T. В тo вpемя как в байткoде этo местo пpинималoсь за Any == Object и делалo мне такие гадoсти.

ну у меня ругается, правда в идеи и без андоида

Я подвис. Играюсь с Kotlin gradle DSL как обычный JavaExec настроить. Что надо в classpath писать?

Я подвис. Играюсь с Kotlin gradle DSL как обычный JavaExec настроить. Что надо в classpath писать?

Смотри проекты большие, которые уже перешли, spring fu, например

Поиском не нашел. Один пример только, да и там кастомный classpath. Подобные штуки в энтерпрайзе редко используются. Ну сейчас посмотрю спринг

Нет, JavaExec не встречается

Можешь ещё бил скрипты самого Котлин dsl посмотреть

А я по-моему смотрел

Да, смотрел. Там в потрохах где-то используется но явно не вызывается

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

А зачем такой геморрой?

task jfreechart(type: JavaExec){ group = "example" classpath = sourceSets.main.runtimeClasspath main = 'scientifik.kplot.examples.JFreeChartFrameTestKt' }

А как по-другому?

Вот этот вариант отлично работает в груви варианте.

В kotlin dsl нет sourcesets.

А, ну да, наверное просто можно присваивать конфигурации напрямую

В kotlin dsl нет sourcesets.

Есть

Мне нужна основная compile конфигурация, без выкрутасов

Но не понимаю причем тут сорсетс

Я тоже не понимаю, это магия

Если тебе нужен класспас

Но хочется чтобы магия работала в kotlin тоже

Используй конфигурацию

ERROR: S client not available

Compile

Пробовал, не видит котлин класс

Напрямую

Котлин класс?

Класс + Kt

Из Groovy DSL видит

В тебе нужно ещё и скомпилированные классы?

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

Если бы была одна, то можно было бы использовать application, а мне нужно то же самое, что application, но много.

Аа

Тогда понятно откуда сорсетс взялись ?

sourcesets взялись из официального примера https://docs.gradle.org/current/dsl/org.gradle.api.tasks.JavaExec.html

Ну так ты склей аутпут компилятора и резолвддепенденсиз конфигурации

Вот хочу то же самое, но на kotlin DSL

sourcesets взялись из официального примера https://docs.gradle.org/current/dsl/org.gradle.api.tasks.JavaExec.html

Толку от примера если не понимаешь как он работает?

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

Ну так ты склей аутпут компилятора и резолвддепенденсиз конфигурации

Пример можно? Там даже в Kotlin DSL куча очень похожих полей, которые не понятно чем отличаются. Да еще и без документации

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

Пример можно? Там даже в Kotlin DSL куча очень похожих полей, которые не понятно чем отличаются. Да еще и без документации

Я с телефона ?

С первым утверждением радикально не согласен. Градл как раз таки много того, что понимать не нужно прячет под капот, он на то и декларативный. Проблема в том, что там есть много исторических наслоений и утилок, в которых сложно что-то разобрать.

Но я запускал этот джаваэкзек с пол года назад, из конфигурации зависимости брал

Вот мавен действительно надо было понимать, по крайней мере lifecycle.

Да я потыкался, плюнул и сделал на груви. Мне пока не критично, просто демку надо было сделать.

С первым утверждением радикально не согласен. Градл как раз таки много того, что понимать не нужно прячет под капот, он на то и декларативный. Проблема в том, что там есть много исторических наслоений и утилок, в которых сложно что-то разобрать.

Ну, не буду спорить, это скорее вкусовщина. Лично я не смог на нем писать ничего внятного пока не понял как оно там у него всё устроено

В этом есть разумное зерно. Буду читать пейджер, много думать. Но пока надо чтобы просто работало.

Еще бы найти где это по человечески написано.

Проблема в том, что как только появляется проблема, то решить её без понимания невозможно. А с тем количеством магии которая там есть, проблемы сыплются градом как только ты отходишь на два шага от готовых тасков скопипащенных из примера

Я на котлин дсл делал билд примерно в 300кб

Еще бы найти где это по человечески написано.

Смешно