https://github.com/meln1k/reactive-telegrambot

правда неплохо бы ее обновить когда-нибудь будет

а не ботное апи к телеграму кто-нибудь видел приличное и не старое?

а не ботное апи к телеграму кто-нибудь видел приличное и не старое?

Я так понимаю что у @levkhomich генерация кода, по этому все всегда в актуальном состоянии. Вот только отсутствие вебхуков это печаль.

если бы возникла необходимость, запилить-то недолго

так мне же не ботное надо, а обычное апи надо)

меня больше сам DSL интересует. чтобы flow нормальный был и inline keyboards по-человечески работали

так мне же не ботное надо, а обычное апи надо)

оно тоже есть

сейчас узнаю, опенсорсное ли уже)

нет, не релизили

и с этим была беда — в андроид-клиенте перешли на си, всё остальное из скалы использовать неудобно

понятно, придется тоже самому написать) спс

не самое приятное занятие, с их-то сериализацией boolean

если нет высоких требований к производительности, лучше сразу тащить scodec

> в андроид-клиенте перешли на си O_o

только для сетевого стэка

только для сетевого стэка

А чем занимаетесь ?

Продукт какой

https://github.com/igorynia/TelegramBotApi начинал писать

Я так понимаю что у @levkhomich генерация кода, по этому все всегда в актуальном состоянии. Вот только отсутствие вебхуков это печаль.

Кодогенерация из чего? Есть схема бот апи?

А чем занимаетесь ?

день на день не приходится =)

Кодогенерация из чего? Есть схема бот апи?

прямо из HTML

=(

Уффф

вообще, с ними надо поговорить. сами они страницу Bot API генерируют, судя по всему

день на день не приходится =)

Ну продукт какой )

Ну продукт какой )

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

Кто поедет на http://fpconf.ru ?

слет мазохистов)

по логотипу все ясно ?

я был в 2015, отличная конфа кстати.

там нет программы выступлений?

видимо еще рано

Да они только-только заанонсили, что сама конфа будет.

В прошлый раз там был Кметт.

Кто нибудь делал интероп из скалы со спринговым сервис дискавери через ZK ?

:)

а так я бы сходил.. правда у черта на рогах опять :(

а есть для скалы сторонние либы коллекций?

например, immutable.Map весьма неэффективная

dogs, но хз как там с производительностью

scala blitz ))

Подозреваю, если мапа стала боттлнеком, не грех и мутабельную поюзать

например, immutable.Map весьма неэффективная

смотря для каких операций, опять же

apply, get, getOrElse, ничего особенного

в Map все через get работает, а он дергает Option всегда

бенчмарки недавно у lihaoyi были

http://www.lihaoyi.com/post/BenchmarkingScalaCollections.html нашел

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

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

второе

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

пока это не на рефакторинг кода, а для размышлений на будущее

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

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

ну и это очень плохо

"терять" - это когда было быстро, а стало медленно)

не думай о милисекундах свысока)

а разве не так? на ассемблере быстро было, теперь все кругом медленно

мелочь к мелочи складывается

а как ты по значениям массива итерируешь в скале?

на счет аллокации Option'а – JIT вполне может скаляризовать операцию

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

надо знать меру

менее эффективный по сравнению с чем?

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

так все же. приведи кусок кода как ты итерируешь по массиву в скале? )

так все же. приведи кусок кода как ты итерируешь по массиву в скале? )

форич?

ой, а что же сразу такой медленный способ то

еще вопрос сколько элементов в мапке

менее эффективный по сравнению с чем?

с j.u.HashMap, хотя бы

так j.u.HashMap мутабельный

почему не while ? он намного быстрее. ты же с фором на ровном месте теряешь спички коробками

теряю

насчет намного быстрее -- это совсем ге так

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

там куда меньше разница, чем между MMap и Map

@ivovk плюсую

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

это не к "юзерспейсу" претензия, а к стдлибе

им-то надо думать про спички

насчет намного быстрее -- это совсем ге так

почему не так? while - в скале линейная конструкция с джампом, а фор - подвызов

jit

@dveim в стдлибе есть две мапы: scala.collection.immutable.Map и scala.collection.mutable.Map

если хочется "как j.u.HashMap" - используй мутабельную

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

иммутабельность сама по себе менее производительная. case class'ы тоже дают оверхед по памяти и производительности. Я помню, как пришел с Java в Scala сначала переживал по-поводу этого всего. А потом перестал :)

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

dogs, но хз как там с производительностью

Мелкая и стремная. Там из коробки всякие конвертации из list в range не работают, хотя документация утверждает обратрное. Но начинание хорошее, нужны усиленные коммиты

Даже паттерн матчинг на a :: b :: tail нельзя написать.

естественно, ведь :: и ::: приезжают из Predef для листа из стдлиб

однако уже после этого "dogs.List is invariant instead of covariant" желание контрибьютить туда отпало

естественно, ведь :: и ::: приезжают из Predef для листа из стдлиб

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

однако уже после этого "dogs.List is invariant instead of covariant" желание контрибьютить туда отпало

А он объясняет почему?

https://stew.github.io/dogs/tut/list - не нашёл объяснения

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

и при импорте он клэшнется

однако уже после этого "dogs.List is invariant instead of covariant" желание контрибьютить туда отпало

Да,это раздражает. Еще нету коммон вещей типа sortedBy, это странно.

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

хотя, "dogs offers an alternate Predef"

и при импорте он клэшнется

Сейчас проверю. Вроде не должен.

А вообще есть возможность расширить существующий predef, не заменяя его полностью?