но в целом это будет не очень хорошо и быстро работать

Привет. Может кто-то подсказать, как работает scalafiddle, scastie в части запуска кода? Какими средствами это может быть реализовано? Я не понимаю:
а) Как запустить sbt из кода
б) Как в открытый sbt отправить новую команду
Буду благодарен, если подскажете, где можно это посмотреть, в гугле не нашел, может плохо искал(

cc @OlegYch_real

прост процесс запускается

скалафидл напрямую с конпилером работает

в теории можно sbt-server юзать

Спасибо)

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

Можно попробовать просто вызывать утилиту protoc в виде отдельного процесса

А чем добавление .proto в хранилище будет отличаться от добавления нормального парсера ? Хочется не выкатывать сервис при изменениях схемы ? В любом случае нужно один раз сгенерировать хотя бы урезанный парсер из прото файла.

Гибкость, вот основная цель. Общее хранилище схем решает много проблем, но это другая тема для обсуждения. Для прото изменяется схема надо менять класс, то есть его перегенерить, это не оч удобно + тесты, но не говорю что это не правильно я не так долго работаю с прото вот и ищу совета у кого есть опыт. Что вы подразумеваете под урезанным парсером? Вы его генерите своим велосипедом или сторонней библой? Основная цель моего вопроса была узнать кто как делает у себя в общих чертах, чтобы как-то оценить текущее свое решение(scalapb) и понять насколько хотелки соотносятся с реальностью

ΤΙΛ "Библа"

ляба

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

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

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

А кто-нибудь использует TiKV?

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

А это чат для маленьких? Если для взрослых то скиньте для маленьких, а пока я вопрос задам:
Допустим есть List[List[Int]], и мне нужно получить из него List[Int] содержащий размеры всех списков, это ведь можно как-то в стиле ФП сделать, а не итерироваться по всему листу?

.map(_.size)