сам ensime или плагин?

@codenamestif а разве идеалогически это не тоже самое?

ensime в vscode

vscode же на базе атома

я вот не знаю, на атоме у меня нихера не работает с тоннами ошибок

жду дотти чтобы писать в vscode и забыть об идее

на vscode все четко, немного подождать - поднимаются индексы и можно уже бегать по коду, что-то пробовать писать

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

там сортировочку можно добавить еще с приоритетами

vscode же на базе атома

На базе электрона?

http://underscore.io/blog/posts/2017/06/02/uniting-church-and-state.html

жду дотти чтобы писать в vscode и забыть об идее

Набирайся терпения

@rudogma а ведь под scalajs должно без проблем собраться? https://github.com/Rudogma/scala-supertagged

запаблишил для скалажиэс libraryDependencies += "org.rudogma" %%% "supertagged" % "1.1"

implicit def recurС[TagNew, TaggedNew <: Tagged[Raw, TagNew], TagIn, Raw, InnerC[_], OuterC[_]](implicit nested: Tagger[TagIn, TaggedNew, TagNew, Raw, InnerC[Raw @@ TagIn]]): Aux[OuterC[InnerC[Raw @@ (TagIn with TagNew)]], OuterC[InnerC[Raw @@ TagNew]], OuterC[InnerC[Raw]], TagIn, TaggedNew, TagNew, InnerC[Raw @@ TagIn], OuterC[InnerC[Raw @@ TagIn]]] = dummyTagger

Не так страшно как кажется, если на 3 блока разбить (первый блок [..], имплисит и Aux[...]). Там логика сразу видна должна быть. Но форматирование все равно довольно убогое получается при вставке переносов, поэтому не стал этого делать)

@rudogma а можешь добавить пару слов для обьяснения магии?

@rudogma а можешь добавить пару слов для обьяснения магии?

если все обьяснять, то надо по шагам прям идти. это будет довольно большая портянка, потому что неясно что читателю известно, а что не очень. Но если спросишь чуть конкретнее - то постараюсь простыми словами обьяснить. Тут немаловажный момент, что если бы нужно просто рекурсивно тип поднять - это в полтора раза проще и соответственно компактнее гораздо. Нюансы появляются, когда попутно требуется еще и при спуске при встрече целевого якоря для остановки разбить его на составные части T @@ U

ну я думаю, что можно ожидать от потенциального пользователя знания имплиститов, но не шейплесс-стайл хаков с ними (по себе сужу :) PR с хотя бы общим подходом наверняка был бы полезен

@gurinderu поддерживаю, но встречаться лучше в офисе, чтобы конфеденшал обсуждать, многие вопросы только лично решаются

@gurinderu поддерживаю, но встречаться лучше в офисе, чтобы конфеденшал обсуждать, многие вопросы только лично решаются

Zoom

Zoom

хорошая вещь, но по нему угражать расправой тяжело )

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

@gurinderu поддерживаю, но встречаться лучше в офисе, чтобы конфеденшал обсуждать, многие вопросы только лично решаются

Yegor256.jpg

Yegor256.jpg

) ну у вас в подкастах часто было !! я на вас ссылаюсь

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

я бы заменил потому на если

и в общем - то тогда пофиг удалённая или нет

хорошая вещь, но по нему угражать расправой тяжело )

Отлично, я проверял

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

%)

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

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

@optician_owl а чем проекты отличаются?

На один видимо насрать)

требованиями к коммуникациям в рамках второго надо постоянно и в команде обсуждать и с аналитиками и с бизнесом

И к нему не цепляется безопасность

на уделнке лаг сильно заметен будет

на уделнке лаг сильно заметен будет

Эт смотря как коммуницировать, принципе можно и без лага

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

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

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

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

это решается все

те пробелмы которые ты говоришь есть и в офисе

есть, но они меньше

именно эта проблема меньше

не знаю; от сотрудников зависимость

есть, но они меньше

а есть более точные цифры?

процент?

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

Эт значит тот человек получает бабки зря) если нужно ждать

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

там можно еще что-то померить

Эт значит тот человек получает бабки зря) если нужно ждать

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

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

да счаззз без воды это вообще боль

зато человек на удаленке и после конца рабочего дня находится как бы на рабочем месте, а тут бац ты ушел из офиса в 18 00, а в 19 30 все сломалось, надо в офис гнать?

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

зато человек на удаленке и после конца рабочего дня находится как бы на рабочем месте, а тут бац ты ушел из офиса в 18 00, а в 19 30 все сломалось, надо в офис гнать?

Эт вопрос про нормирование рабочего дня

зато человек на удаленке и после конца рабочего дня находится как бы на рабочем месте, а тут бац ты ушел из офиса в 18 00, а в 19 30 все сломалось, надо в офис гнать?

удаленка тут у всех есть кто имеет такие требования

удаленка тут у всех есть кто имеет такие требования

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

есть возможность (зависит от руководителя) работать частично на удаленке например, если больничный не хочется брать ради пары дней

а если нет настроения пилить в офис?

а если нет настроения пилить в офис?

не комментирую публично ?

почему не коммнетируешь?

почему?

нормальная практика)

согласен )

неокторые даже официально договариваются что типа 2 дня офис 3 дня не офис

ну или чет такое

в более развитых странах так вообще 4 дневка бывает

угу, ящитаю идеальная практика

топовое руководство строго против удаленки она здесь больше как поблажка до каких то расширенных вариантов уговорить пока не удалось

и при том должность сотрудника не особо влияет на это; у нас лид одной команды 2 месяа в испании жил и заодно фламенко играл

в более развитых странах так вообще 4 дневка бывает

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

я бы заменил потому на если

Если нет, то распределенная разработка вообще не работает. То есть распределенность заставляет стоить более грамотные процессы, которые при разработке в офисе затыкаются "живым общением".

Плюсы/минусы есть и там и там =) Как и везде

дыа, и опять же все индивидуально

Плюсы/минусы есть и там и там =) Как и везде

о том и речь, да

Плюсы/минусы есть и там и там =) Как и везде

потому я выше написал — мне идеальным видится совмещение

потому я выше написал — мне идеальным видится совмещение

а это уже субъективно для каждого видел людей, которые хотят ходить в офис и видел противоположности

сам бы предпочел середину

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

зато человек на удаленке и после конца рабочего дня находится как бы на рабочем месте, а тут бац ты ушел из офиса в 18 00, а в 19 30 все сломалось, надо в офис гнать?

я и в три ночи реагирую)

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

неокторые даже официально договариваются что типа 2 дня офис 3 дня не офис

в ибм так , до 4 дней народ из дома работал

топовое руководство строго против удаленки она здесь больше как поблажка до каких то расширенных вариантов уговорить пока не удалось

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

Если нет, то распределенная разработка вообще не работает. То есть распределенность заставляет стоить более грамотные процессы, которые при разработке в офисе затыкаются "живым общением".

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

ну я думаю, что можно ожидать от потенциального пользователя знания имплиститов, но не шейплесс-стайл хаков с ними (по себе сужу :) PR с хотя бы общим подходом наверняка был бы полезен

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

для правильных вопросов надо знать половину ответа

для правильных вопросов надо знать половину ответа

чтобы по точкам задавать - необязательно знать половину всего) например многим новичкам-середнячкам наверняка может быть интересно, почему я везде использую cast(v) вместо tagger.attachTag(v). Отвечаю: потому, что все что там есть служит только для того, чтобы кастануть какой-то нестед тип. asInstanceOf ничего не делает с данными, поэтому имея доказанный возвращаемый тип :tagger.Out, можно сразу кастануть все, вместо отдельного кастования на каждом уровне. - результат тотже(тип уже доказан), но код гораздо чище и для джита это тоже гораздо проще (чем меньше глубина стека, тем проще)

для правильных вопросов надо знать половину ответа

dummyTaggerStub - тоже по вполне очевидным причинам. Несмотря на то, что сгенерированные имплиситы джит охотно почистит, сгенерированный байткод никуда до этого момента не денется и будет постоянно выполняться бессмысленное new AnyRef (16 bytes... или сколько там * nested level) - это может быть довольно существенным, если будет большой фрупут, сборка мусора успеет поднасрать, прежде чем джит вырежит создание этих пустышек. А так получается, что при вызове любых @@ в имплиситах гоняется только один физический обьект. Используется val, а не lazy val - потому что lazy тоже на самом деле дорогой и под чистую джитом не оптимизируется (хотя не, вот тут вру немного. стоит заменить на var (не помню насколько разница между val & lazy val, но val сам по себе точно дорогой относительно var)

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

dummyTaggerStub - тоже по вполне очевидным причинам. Несмотря на то, что сгенерированные имплиситы джит охотно почистит, сгенерированный байткод никуда до этого момента не денется и будет постоянно выполняться бессмысленное new AnyRef (16 bytes... или сколько там * nested level) - это может быть довольно существенным, если будет большой фрупут, сборка мусора успеет поднасрать, прежде чем джит вырежит создание этих пустышек. А так получается, что при вызове любых @@ в имплиситах гоняется только один физический обьект. Используется val, а не lazy val - потому что lazy тоже на самом деле дорогой и под чистую джитом не оптимизируется (хотя не, вот тут вру немного. стоит заменить на var (не помню насколько разница между val & lazy val, но val сам по себе точно дорогой относительно var)

А про val/var где почитать можно?

@dveim если обратить внимание на методы внутри Tagger, можно заметить что там 3 логических типа по 2 метода на каждом уровне (1 для случаев, когда нет тега у целевого типа, 2-ой когда есть) _ - может быть любым, хоть примитив хоть комплексный F1[....FN[...]], не важно 1. recurC2 + recurC - для захвата всех F![.....FN[_]] , те кто зайдут сюда остановятся в итоге на тип 2 2. baseC + baseCRaw - для остановки на F[_] 3. baseTagged + baseRaw - для остановки на неконтейнерных типах ( case class MyClass(inner:OtherClass) - также не контейнерный F[_]) каждый из уровней может быть входом, но остановка только на 2 и 3 2-ой уровень наверное можно переписать, чтобы он использовал имплисит 3-го уровня, но зачем? это только усложнит код. Но без 2-го чисто 1 + 3 , тоже не смогут найти переходник между собой

А про val/var где почитать можно?

есть только базовая дока по скале. я не встречал подробных разборов исполняемого байткода для var|val|lazy val после джита. А копаться самому в байткоде после джита в рантайме, чтобы доказать проверенные опытом вещи) ну так себе удовольствие) есть собственный опыт, мне достаточно)

@rudogma ? если бы ты эти мысли перевел на англ и оформил где-то рядом в комменте, оно бы наверняка помогло распостранению либы) насчет "копаться самому в байткоде после джита в рантайме" — в смысле уже в маш коде? и как это удобнее делать? (кроме PrintOptoAssembly — то есть как запускать код, чтобы левого мусора было поменьше, и все такое) (мне-то покопать интересно было бы)

А про val/var где почитать можно?

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

@rudogma ? если бы ты эти мысли перевел на англ и оформил где-то рядом в комменте, оно бы наверняка помогло распостранению либы) насчет "копаться самому в байткоде после джита в рантайме" — в смысле уже в маш коде? и как это удобнее делать? (кроме PrintOptoAssembly — то есть как запускать код, чтобы левого мусора было поменьше, и все такое) (мне-то покопать интересно было бы)

это скорее к Шипилеву и компании) они там вроде большие любители) (про копаться в оптимизированном байткоде)

https://dev.to/danlebrero/the-broken-promise-of-static-typing

pure sofa data analisys

dummyTaggerStub - тоже по вполне очевидным причинам. Несмотря на то, что сгенерированные имплиситы джит охотно почистит, сгенерированный байткод никуда до этого момента не денется и будет постоянно выполняться бессмысленное new AnyRef (16 bytes... или сколько там * nested level) - это может быть довольно существенным, если будет большой фрупут, сборка мусора успеет поднасрать, прежде чем джит вырежит создание этих пустышек. А так получается, что при вызове любых @@ в имплиситах гоняется только один физический обьект. Используется val, а не lazy val - потому что lazy тоже на самом деле дорогой и под чистую джитом не оптимизируется (хотя не, вот тут вру немного. стоит заменить на var (не помню насколько разница между val & lazy val, но val сам по себе точно дорогой относительно var)

откуда инфа про джит? эт ж рулетка