<trollmode> Собирать не через гредл </trollmode>

Шутки про скорость gradle ещё актуальны?

Шутки про скорость gradle ещё актуальны?

Всегда. Я молчал, когда Кирилл писал про медленность сборки, но теперь меня никто не сдержит. Там процентов 30 (времени) можно убрать, уйдя с грыдлы

*богомерзкой грыдлы

В гредле есть пробемы с инкрементальной сборкой многомодульных проектов. Во первых - долгие up-to-date чеки (он всегда считает хэш всех джарников), во вторых - инкрементальная компиляция не всегда работает между модулями (из за того что api гредла не позволяет по хорошему определить что кокнретно изменилось в джарнике). В JPS таких проблем нет (JPS - это внутреняя собиралка в идее)

гредл и есть проблема

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

Я бы посмотрел как вы получите повторяемые сборки без gradle

кстате про котлин: начиная с 1.2.60 (который пока eap), jps поддерживает мультиплатформенный котлин (common, jvm, js)

в том числе инкрементально (с некоторыми нюансами)

кстате про котлин: начиная с 1.2.60 (который пока eap), jps поддерживает мультиплатформенный котлин (common, jvm, js)

Как у него с документацией?

Как у него с документацией?

Немного документация есть в help-е идеи, но врядли она нужна. А работает это как обычно: импортируем проект из гредла и запускаем make project. (Галка Delegate build / run actions to gradle при этом должна быть снята, но она снята по умолчанию).

до 1.2.60, make project для MPP проектов всегда собирал через гредл, независимо от галки описанной выше. Теперь галка (снова) учитвается.

Немного документация есть в help-е идеи, но врядли она нужна. А работает это как обычно: импортируем проект из гредла и запускаем make project. (Галка Delegate build / run actions to gradle при этом должна быть снята, но она снята по умолчанию).

А есть шансы, что jps будет выделен из идеи в standalone приложение? Судя по миграции git репозиториев, вряд ли. Но с такими характеристиками по произоводительности, почему бы и нет?

есть ?

?

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

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

а не было попыток разговора с командой gradle, может есть возможность добавить необходимую функциональность в gradle?

Я время от времени пользуюсь внутренней сборкой идеи, но честно говоря, я совершенно не готов рассматривать всерьез систему сборки без декларативного dsl.

а не было попыток разговора с командой gradle, может есть возможность добавить необходимую функциональность в gradle?

разговор идет постоянно, и, я уверен, в конце концов проблемы решаться. лично мне кажется что гредлу нужно сделать некий api по partial build, чтобы можно было явно указывать какие файлы изменены. но конкретно это еще не обсуждалось. а вот фиксы для инкрементальной межмдульной компиляции как раз в процессе

Я время от времени пользуюсь внутренней сборкой идеи, но честно говоря, я совершенно не готов рассматривать всерьез систему сборки без декларативного dsl.

выше как раз речь про такой dsl

вот как пример

Ну там в скрипте есть всякие lazy - это уже немного напрягает.

Кроме того, в градле главное - задачи и их зависимости. Опять же, без этого никуда.

Что делает * когда я передаю vararg принятый классом в функцию? оно работает )) но что именно он делает ?

Он превращает массив в то, что можно скормить vararg

class UserMenu(private val data: GeneralData, vararg text: AppText) { val actor = create(*text)

Масив делает вид, что он просто параметры, переданные через запятую.

Он превращает массив в то, что можно скормить vararg

то есть опять создает одиночные значения ?

Типа того. Я не знаю, что там внутри творится, но с точки зрения кода - да

Типа того. Я не знаю, что там внутри творится, но с точки зрения кода - да

ясно )

привет. вопрос - почему лямбда в качестве последнего аргумента функции может выноситься за скобки? меня смущает синтаксис

чем обосновано

когда 1 аргумент выглядит симпатично, вместо func( { a } ) = func{ a }, но func( a, {b} ) = func (a){b} ?

когда 1 аргумент выглядит симпатично, вместо func( { a } ) = func{ a }, но func( a, {b} ) = func (a){b} ?

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

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

когда 1 аргумент выглядит симпатично, вместо func( { a } ) = func{ a }, но func( a, {b} ) = func (a){b} ?

Ты можешь не выносить. По код стайлу не помню как правильней делать

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

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

глядя на код я вижу метод с 1 аргументом. печаль

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

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

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

Мне норм. Всегда хотел от скобок избавится в джаве

глядя на код я вижу метод с 1 аргументом. печаль

Это дело привычки. Лямбду сбоку видно всегда, вопрос только в том, что надо пару раз самому написать. В среднем случае это намного лучше выглядит, чем куча скобок, тянущихся рядом.

а несколько выносятся?

a, {b}, {c} ?

Только последняя. И тут уже действительно валидный кейс, чтобы не выносить вообще.

ясн, спасибо за прояснение

Там огромный пласт задач по генерации DSL с помощью этих лямбд вынесенных решается

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

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

+

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

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

Вот только что писал такой код. Все равно путанница возникает. Лучше каждый параметр на отдельной строке и закрывающую круглую скобку тоже.

Что взять под REST API ktor или spring и почему?

Что взять под REST API ktor или spring и почему?

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

val a = Array(N) { Array(N) { (0..9).random() } }

5 5 5 5 5 5 5 5 5 5 4 4 4 4 4 4 4 4 4 4 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 3 3 3 3 3 3 3 3 3 3 8 8 8 8 8 8 8 8 8 8 4 4 4 4 4 4 4 4 4 4 6 6 6 6 6 6 6 6 6 6 1 1 1 1 1 1 1 1 1 1 4 4 4 4 4 4 4 4 4 4

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

Где эффективнее и проще найти инфу, так как не то не то не знаю?

Как сделать чтобы вызвал 100 раз, а не 10?

Где эффективнее и проще найти инфу, так как не то не то не знаю?

на ktor.io :)

на ktor.io :)

то есть легче будет с ктором? ?

то есть легче будет с ктором? ?

да)

Если совсем без бэкграунда, то да

да)

спасибо

Спринг - это такая вещь с большим наследием

val a = Array(N) { Array(N) { (0..9).random() } }

Что за random(), ext-function? Попробуй ее явно передавать один раз созданный Random() как параметр, а не создавай его внутри.

Что за random(), ext-function? Попробуй ее явно передавать один раз созданный Random() как параметр, а не создавай его внутри.

Спасибо. Сейчас попробую.

Не, то же самое. Функция вот так выглядит:

на ktor.io :)

а гибернейт с ним норм работает или там лучше другую ормку подыскать?

а гибернейт с ним норм работает или там лучше другую ормку подыскать?

ой, я бы в любом случае чё-нибудь другое искал :)

я брал kwery, но пришлось форкнуть и допилить

привет. вопрос - почему лямбда в качестве последнего аргумента функции может выноситься за скобки? меня смущает синтаксис

Скорее всего пришло из функциональных ЯП. Чего-нибудь типа Haskell. Там функции каррированные всегда, а применение функции к аргументу обозначается пробелом. Например f 1 обозначает применение функции f к литералу 1 В Kotlin такой синтаксис возможен только для лямбд, притом несколько негомогенно: fun <A, B, C> compose(f: (A) -> B): ((B) -> C) -> (A) -> C = { g -> { g(f(it)) } } fun main(args: Array<String>) = println( compose<String, Int, String> { it.length }() { it.toString() }("foo") ) Если убрать () из строки compose<String, Int, String> { it.length }() { it.toString() }("foo"), то не скомпилируется, хотя анализатор кода в IDEA говорит, что () не нужны.

ой, я бы в любом случае чё-нибудь другое искал :)

почему?

проверенный временем и вск такое не?)

почему?

генерация кода, конфиги, вот это всё

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

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

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

а гибернейт с ним норм работает или там лучше другую ормку подыскать?

https://github.com/JetBrains/Exposed

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

Вообще в другом месте проблема была. Распечатываю криво) Спасибо.

https://github.com/JetBrains/Exposed

вот это можно посмотреть

Скорее всего пришло из функциональных ЯП. Чего-нибудь типа Haskell. Там функции каррированные всегда, а применение функции к аргументу обозначается пробелом. Например f 1 обозначает применение функции f к литералу 1 В Kotlin такой синтаксис возможен только для лямбд, притом несколько негомогенно: fun <A, B, C> compose(f: (A) -> B): ((B) -> C) -> (A) -> C = { g -> { g(f(it)) } } fun main(args: Array<String>) = println( compose<String, Int, String> { it.length }() { it.toString() }("foo") ) Если убрать () из строки compose<String, Int, String> { it.length }() { it.toString() }("foo"), то не скомпилируется, хотя анализатор кода в IDEA говорит, что () не нужны.

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

но спасибо за объясняшки

пытался как то хаскель попробовать, пару раз даже, но дальше 3-й страницы ниразу не ушел

Именно поэтому лямбды имеют такой клевый синтаксис

что позволяет писать очень красивый код

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

Так людям и хорошо, эту штуку хорошо откатали в Groovy :)

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

вот это можно посмотреть

Кто-то пробовал и то и то? Интересно впечатления после него услышать)

А что у ктора с di?

Кто-то пробовал и то и то? Интересно впечатления после него услышать)

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

А что у ктора с di?

нет

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

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

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

Совершенно разный стиль и разные задачи