Не совсем по теме, но... Правильно ли я понимаю, ч...
# russian
a
Не совсем по теме, но... Правильно ли я понимаю, что если использовать любой логер, пишущий метод в лог, обязательно вызывает создание Throwable и потрошение его стектрейса? Например logback Причём это (очень небыстрая) операция идёт синхронно- иначе никак... В kotlin всё так же? StackWalker не используется нигде?
a
Ну логгер и генерация ошибок - это как бы не напрямую связанная штука. Для JVM используюстя логгеры из Java, так что если там это делается быстро, то и в котлин будет быстро.
a
Именно напрямую. Чтобы записать в лог вызываемый метод нужно создать исключение и взять из него стектрейс. Я ссылку приводил - строка 280. Так это делается в logback.
a
Апи логгера получаетс инстанс Throwable. Что он там с ним делает - это детали его внутренней реализации. В зависимости от того, какой фреймворк вы используете, результат будет разный. По-умолчанию обычно используют slf4j, но это спецификация, а не реализация. Поставляйте какой хотите.
a
Вы не понимаете. Чтобы написать в логах метод откуда вызвано логирование, надо создать Throwable. При этом заполняется stacktrace. На каждом вызове лога. Каждый (сработавший) logger.info(…) - это сбор полного стектрейса. https://habr.com/ru/company/jugru/blog/324932/ - это миллисекунда примерно.
a
Понял теперь. Но опять же, деталь реалзиации. slf4j сам по себе это не делает
a
Конечно- это делает logback/log4j/все. Вопрос- кто-нибудь (например в kotlin) перешёл на StackWalker? Кстати, про 1мс я ошибся- в той же статье есть примеры на десятки мс (если стектрейс большой- привет спрингу/EE и AOP)
a
Мой мысль в том, что котлин почти везде использует обертки над готовыми решениями из Java. Можно @lewik спросить
l
Сам не знаю. В моем логгере используется slf4j
a
А что за “мой логгер“? А то я kotlin-logging по native пока допиливаю, но может зря
a
Kotlin-logging хорошая штука.
l
"мой логгер" https://github.com/Lewik/klog
Он конечно же, не совсем мой) Просто kotlin-logging долго не был мультиплатформенным.
a
А он Native поддерживает?
l
Нет, надо допиливать.
Я думаю это просто что в kotlin-logging что в klog
a
В вашем попроще. Только надо 1.4 дождаться, чтобы 3 раза не дублировать код.
Но проблема с получение строки та же самая, конечно. Видимо вежде так.
l
Несли я правильно понимаю, обычно logback используется?
a
Да На самом деле я написал это не потому, что нашёл проблемы перформанса, а потому, что стал писать KN-ветку для kotlin-logging и дошёл до этапа “получить метод, откуда вызван лог“. И задумался 🙂
l
Я думал они это не сами считают...
a
“Они” это кто?
l
"Конкуренты" из kotlin-logging))) а зачем им это?
a
Что “это“? Они тоже slf4j берут в JDK, но в native мне над самому делать- вот и полез читать исходники logback
l
В js я ограничился только именем класса. Без метода
a
Это должно настраиваться. Магические заклинания из log4j/logback мне не нравятся, пока так попробовал: https://github.com/alekseytomin/kotlin-logging/blob/native-macos/src/macosMain/kotlin/mu/KotlinLoggingConfiguration.kt
b
logback будет вычислять имя метода только если в шаблоне логгера есть поле
${m}
a
@lewik внезапно https://github.com/Lewik/klog/pull/2 Я не знаю, как лучше расшарить код на все три платформы, кроме как копипастой. До 1.4 вроде нет хорошего способа.
l
@aleksey.tomin Надо признать, я и зам не знаю. Может @altavir Знает? Если это технически невозможно/неудобно, то ничего против копипасты не имею.
a
Посмотрите пока версию для мака. В винде не получается номер строки (завтра уточню ещё). Докину тестов ещё
l
@aleksey.tomin Дык... у меня мака нет... )
a
Я про стиль вообще. Там posix голый
a
Нет пока времени смотреть, но вы похоже хотите hmpp
a
Что такое hmpp? Гугл в растерянности
a
hierachical multi-platform mpoject
a
Да, я и говорил, что до 1.4 никак Но могу (если не против) перевести на 1.4-M2
a
Ну недолго ждать осталось.
l
Ну, можно перевести на будущее. Задел сделать
a
Добавил тест. Сейчас hmpp попробую на 1.4-M2
Что-то от js и groovy у меня мозги в трубочку сворачиваются- не понимаю ни то ни то 😞
l
По поводу груви я вас очень понимаю. Может, на kts перейти?
А зачем вам js?
a
Да мне пишет, мол
Copy code
Please choose a JavaScript environment to build distributions and run tests.
Not choosing any of them will be an error in the future releases.
kotlin {
    js {
        // To build distributions for and run tests on browser or Node.js use one or both of:
        browser()
        nodejs()
    }
}
При
gradlew build
Может, на kts перейти?
Ну тут хозяин - барин 🙂 Заодно можно gradle до 6.3 хотя бы подтянуть.
a
ну так да. надо выбрать или то или другое, или все вместе. Там разная модель сборки
лучше сразу до 6.5
l
Я только за, сейчас отвлечься на это не могу, но не думаю что это особо сложно.
Так что pr are welcome)
Я вот правда считаю что .idea должно быть в локальном gitignore, но все упорно его пихают в репозиторий. Не знаю почему. Но раз так - ну что, пусть будет в репозитории) ну это мелочи
a
Я тоже его игнорю
l
@aleksey.tomin Если вы можете апнуть до 6.5 - я только за
И на kts - я только за.
Единственно что хочется - чтобы этот логер был как можно более простым и легким.
Я вот не знаю, как там с логированием на native. Получается, надо самим формат делать?
a
Ну и вы должны объяснить людЯм (мне например), чем оно лучше kotlin-logging. У меня тестов не много, поэтому не понятно, какая разница
l
А почему оно должно быть лучше?)
Вот, @aleksey.tomin, а почему вы это делаете не на kotlin-logging а на klog?
a
Я делаю это для себя. Сделал аналогичную работу по kotlin-logging, но там просто много кода и возможностей, много работы. Пока не решился p/r кинуть. Тут проще, плюс можно пообщаться спокойно, а не в рамках p/r 🙂
a
Ну просто мне кажется, что если нет критических недостатков, лучше иметь одну мощную либу, чем много частичных.
l
Ну вот.. "тут проще" для меня тоже было начальной точкой. Мотороллер то не мой, код стащил у @maxim.shafirov он просто очень долго отвечал.
a
Может и лучше. Но там p/r на linux полгода висит - что-то страшно 🙂