Версия 0.x намекает на то что скорее всего нет

Версия 0.x намекает на то что скорее всего нет

Аха )

Но мы хотим его в прод тянуть, пока допишем будет стабильным

Но мы хотим его в прод тянуть, пока допишем будет стабильным

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

Нууу. Может завтра апи поменяют.. Кто знает

Господа, как в Ktor прочитать значение из application.conf в варианте с embeddedServer?

Апну свой вопрос ?

Апну свой вопрос ?

val env = applicationEngineEnvironment { module { main() } // Private API connector { host = "127.0.0.1" port = 9090 } // Public API connector { host = "0.0.0.0" port = 8080 } } embeddedServer(Netty, env).start(true)Внутри applicationEngineEnvironment есть доступ к кофигу вроде, но сам не проверял

Добрий день, ктор это vertx+kotlin+coroutines ?

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

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

Ммм да, но сам по себя нетти очень низко урвенний ,по моему )

вертикс тоже же на нетти

пофиг, надо туда свой сервер запихать =)

вертикс тоже же на нетти

Откуда это

я недавно ковырял их новый асинхронный драйвер, там под капотом нетти, логично предположить что вертикс целиком на нем

да, там нетти, долго гуглить не пришлось

А чо там, 1.2.61 вышел? где ченжлог глянуть?

А чо там, 1.2.61 вышел? где ченжлог глянуть?

Вышел, плагин обновился и на главной странице инкрементнули версию. Но чейнджлоги (по крайне мере, на гите) крайне часто запаздывают

А чо там, 1.2.61 вышел? где ченжлог глянуть?

https://github.com/JetBrains/kotlin/blob/1.2.60/ChangeLog.md

Ничего особо интересного. Ждем 1.3

уже немного осталось)

RecentlyNullable — это что?

Барсик, еще капельку?

так есть же 1.3-M1, чего ждать?

Лень репозитории в конфиги добавлять

RecentlyNullable — это что?

это в новом android sdk типа NonNull, который генерит wwarning, а не error

это в новом android sdk типа NonNull, который генерит wwarning, а не error

прикольно, спасибо

А у нас тут есть авторы Ktor?

я думаю, быстрее их найти в slack

У них там ~~гнездо~~ канал

И мардаун работает

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

Вот кстати тут недавно поднимался вопрос о гарантии того, что лямбда ничего не захватывает. В Kotlin/Native такая гарантия требуется для staticCFunction, но это интринсик и он может себе позволить дополнительные проверки :)

Для работы с датами нужно использовать java класс Date из java.util?

Смотря где. Если нет приязки к фрэймворку, лучше LocalDate из java.time

Спасибо

Вот есть у меня такая фтука: fun List<Double>.cumulativeSum() и еще две таких же для Int и Long. Получаю platform declaration clash. Как победить?

Вот есть у меня такая фтука: fun List<Double>.cumulativeSum() и еще две таких же для Int и Long. Получаю platform declaration clash. Как победить?

@JvmName

Вот есть у меня такая фтука: fun List<Double>.cumulativeSum() и еще две таких же для Int и Long. Получаю platform declaration clash. Как победить?

ну дженериков же нет, @JvmName

Щас попробую

Вот есть у меня такая фтука: fun List<Double>.cumulativeSum() и еще две таких же для Int и Long. Получаю platform declaration clash. Как победить?

ну вариант заинлайнить (если можно)

Заинлайнить не работает, инлайн игнроируется почемуто

Вроде компилится

Вроде компилится

@JvmName - только если не нужен интертоп с джавой

?

Ну не очень нужен. Я кстати не до конца понимаю, почему clash вообще происходит. Вроде в аналогичных случаях из stdlib все работает

Вот тут например: https://github.com/JetBrains/kotlin/blob/feb5a3040fcc988c15f23f05b0f389668deefbaa/libraries/stdlib/common/src/generated/_Collections.kt#L1510

Ну не очень нужен. Я кстати не до конца понимаю, почему clash вообще происходит. Вроде в аналогичных случаях из stdlib все работает

потому что генерики стираются и сигнатуры получаются одинаковыми

Это я понимаю. Не понимаю, почему в stdlib работает

Вот тут например: https://github.com/JetBrains/kotlin/blob/feb5a3040fcc988c15f23f05b0f389668deefbaa/libraries/stdlib/common/src/generated/_Collections.kt#L1510

можно скрин, с телефона неудобно

public fun Iterable<Double>.max(): Double? {

ну и так далее

можно скрин, с телефона неудобно

@SinceKotlin("1.1") public fun Iterable<Double>.max(): Double? { ... } @SinceKotlin("1.1") public fun Iterable<Float>.max(): Float? { ... } Тоже интересно стало, как так.

Это я понимаю. Не понимаю, почему в stdlib работает

а ты в одном файле сделал функции ? В разных не должно. А конкреттно почему у них так, они разрабы)

В одном. То что они разработчики, не значит, что у них магия

В одном. То что они разработчики, не значит, что у них магия

не магия, а компляция в байткод

У них там есть аннотация @file:kotlin.jvm.JvmMultifileClass, может в ней дело?

У них там есть аннотация @file:kotlin.jvm.JvmMultifileClass, может в ней дело?

Она по-моему позволяет нескольким kt-файлам сливаться в один JVM-класс.

У них там есть аннотация @file:kotlin.jvm.JvmMultifileClass, может в ней дело?

это вроде, что разные файлы объеденятся в один класс

Она по-моему позволяет нескольким kt-файлам сливаться в один JVM-класс.

+

то, что в байткод идет без исходников

В том же файле сумма сделана через JvmName

а напомните, генерики у аргументов стираются же?

а напомните, генерики у аргументов стираются же?

+

да

В одном. То что они разработчики, не значит, что у них магия

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

а напомните, генерики у аргументов стираются же?

Частично решаемо с помощью inline fun <reified T>

ERROR: S client not available

Частично решаемо с помощью inline fun <reified T>

+, но @noraltavir говорит что инлайн не работает

А что реифицировать, дженерика-то нет

Здесь нечего, конечно, я просто стандартное дополнение к вопросу об erasure оставил.

А что реифицировать, дженерика-то нет

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

Ну JvmName - это неплохой вариант. Библиотека только для котлины и ориентирована на мультиплатформу

И байт-код, как назло, не показывает IDEA.

Ну JvmName - это неплохой вариант. Библиотека только для котлины и ориентирована на мультиплатформу

JvmName как раз привязан к платформе, это скорей что бы покрыть такие случаи как сейчас, еще название классов

И байт-код, как назло, не показывает IDEA.

? показывает же

или в том месте ?

Я понял, тело этих .max() определено в common-модуле, там JVM-байткода и не будет.

И байт-код, как назло, не показывает IDEA.

я думаю нада скомпилить и пройтись https://github.com/ingokegel/jclasslib

Эт я уже сегодня не успею.

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

Ну не очень нужен. Я кстати не до конца понимаю, почему clash вообще происходит. Вроде в аналогичных случаях из stdlib все работает

Platform declaration clash репортится когда *полностью* совпадают JVM-сигнатуры, в которые входит и return-тип тоже. Поэтому max в stdlib работает -- у него return-типы разные. Так что тут мы чисты, никакой эксклюзивной стдлибной магии ?

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

Platform declaration clash репортится когда *полностью* совпадают JVM-сигнатуры, в которые входит и return-тип тоже. Поэтому max в stdlib работает -- у него return-типы разные. Так что тут мы чисты, никакой эксклюзивной стдлибной магии ?

дак у товарища в его примере типы возвращаемых значений тоже разные очевидно

дак у товарища в его примере типы возвращаемых значений тоже разные очевидно

@noraltavir ^^^ ?

Если различаются, то надо больше кода посмотреть :)

дак у товарища в его примере типы возвращаемых значений тоже разные очевидно

Видимо, он их не указал, ожидая, что оно всё равно будет работать как в джаве)

Не отличаются. Там итерабли с разными дженериками

Platform declaration clash репортится когда *полностью* совпадают JVM-сигнатуры, в которые входит и return-тип тоже. Поэтому max в stdlib работает -- у него return-типы разные. Так что тут мы чисты, никакой эксклюзивной стдлибной магии ?

кстати, тогда такой код должен компилиться: public class Foo { int getBar() { ...} long getBar() { ... } } что-то не сходится

Не отличаются. Там итерабли с разными дженериками

По теме исходного вопроса: мне кажется, JvmName с суффиксом Int/Double/etc - вполне норм решение

По теме исходного вопроса: мне кажется, JvmName с суффиксом Int/Double/etc - вполне норм решение

+

кстати, тогда такой код должен компилиться: public class Foo { int getBar() { ...} long getBar() { ... } } что-то не сходится

Это же Java Да и Kotlin в такой ситуации не сможет выбрать перегрузку

Это же Java Да и Kotlin в такой ситуации не сможет выбрать перегрузку

какая разница, jvm ведь

какая разница, jvm ведь

джава запрещает

JVm нет

@kotlin.jvm.JvmName("sumOfDouble") public fun Iterable<Double>.sum(): Double { ну вот тут типы различаются

джава запрещает

тогда как это будет выглядеть в декомпайле?

какая разница, jvm ведь

Разница в том, что сигнатуры методов в JVM разные, но Java такое запрещает во всех проявлениях

тогда как это будет выглядеть в декомпайле?

в рантайме типы не чекаются