Bernal ???

или хотя бы withIndex https://scalafiddle.io/sf/nURwxPA/1

На джаве весело. Столько увлекательных рантайм-эксепшенов. И NullPointerExeption и ClassNotFoundException и Exceptionininitializererror. И вся эта вариативность xml-конфигов и аннотаций. Никогда не соскучишься!

С sbt тоже её соскучишься, btw.

я сам этот сайт терпеть не могу за офигенный респонсив дизайн

вот код оттуда import cats._ import cats.data.{NonEmptyVector, State} import cats.syntax.traverse._ import cats.instances.option._ import State.{set, get} def zipWithIndex[F[_] : Traverse, A](xs: F[A]): F[(A, Int)] = { def indexStep(x: A): State[Int, (A, Int)] = for { idx ← get _ ← set(idx + 1) } yield (x, idx) xs.traverseU(indexStep).runA(0).value } println(zipWithIndex(NonEmptyVector(4, Vector(5, 6)))) println(zipWithIndex(Option(4)))

в 2.12 c partial unification можно просто .traverse

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

"далекие ветки" -- один и тот же проект, разбить на несколько нельзя

2 и более локальных репо

ну вот это как раз не вариант

хотелось (в идеале) иметь один файл со всем-всем стейтом от sbt/scalaс, и его шарить в гите

мб кто слышал про обсуждения на эту тему, идея-то несложная

мб кто слышал про обсуждения на эту тему, идея-то несложная

когда-то был вот такой доклад https://www.youtube.com/watch?v=WxyyJyB_Ssc суть в том, что в текущем компиляторе стейт мутабельный, каждый этап компиляции что-то мутирует и для частично изменившихся исходников \зависимостей придётся большую часть запускать с нуля. А в дотти, они, вроде навернули подходящую архитектуру

Т.е. набор функциональных зависимостей между иммутабельными суб-стейтами, которые можно куда-то заперсистить в теории

опа, от самого Мартина, интересно, спасибо

я примерно представляю, сколько тут проблем будет, но и профит для скалы (с её скоростью компиляции) огромен

https://github.com/scalameta/sbt-semantic-example/blob/master/README.md

https://github.com/scalameta/sbt-semantic-example/blob/master/README.md

в курсе, поэтому и спросил)

Архитектура такая, в основном была сделана для супер-эфективного кеширования, но в качестве побочных плюсов может поддерживать общение с приложениями a-la language server protocol, персистентность, и параллельные\многосерверные билды

звучит вкусно, верим и ждем

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

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

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

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

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

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

вариант, но не подойдет к моему случаю -- ветки содержат примерно одни и те же файлы, в почти той же файловой структуре

вариант, но не подойдет к моему случаю -- ветки содержат примерно одни и те же файлы, в почти той же файловой структуре

чем? ведь это идентично тому, что ты делаешь - только не надо постоянно свитч делать.

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

типа project_folder1/2/3... ?

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

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

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

угу, наконец-то дошло :) интересный подход, попробую, спасибо

Я так часто делаю на основных проектах. У гита свежего есть особый чекаут ветки в отдельную директорию

Я так часто делаю на основных проектах. У гита свежего есть особый чекаут ветки в отдельную директорию

поподробней плз

Я так часто делаю на основных проектах. У гита свежего есть особый чекаут ветки в отдельную директорию

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

Я так часто делаю на основных проектах. У гита свежего есть особый чекаут ветки в отдельную директорию

А что за чекаут такой? Что за ключи или команды?

https://erikbern.com/2017/03/15/the-eigenvector-of-why-we-moved-from-language-x-to-language-y.html

лол со скалы больше всего на яву

это что то из области девиантного поведения

http://stackoverflow.com/questions/6270193/multiple-working-directories-with-git

это что то из области девиантного поведения

неосиляторы

лол со скалы больше всего на яву

java--[8702]->scala java<-[2779]--scala

Тут просто легче всего прыгать туда-обратно.

там не учитываются оставшиеся и молчуны => нерепрезентативно

там не учитываются оставшиеся и молчуны => нерепрезентативно

да и эти числа - выхлоп от предобработки гуглом, а не честный опрос. Тут вся выборка сплошной биас

А что за чекаут такой? Что за ключи или команды?

я worktree имел ввиду

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

так похоже на гоферов

пхпшник бывший 100%

благо эти олени ушли на го кодить

благо эти олени ушли на го кодить

не язык делает из человека оленя, а человек делает из языка го-вно

в этом и посыл. пусть они гавняют на го, чем делают гавно из пхп)

%) сколько эмоций то

накипело))

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

И график языков которые знала команда с html

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

А что эт?)

В гошечке ж корутины. Зачем знать о потоках)

Народ, а кто-нить пробовал штанишки? http://www.pantsbuild.org/ Интересно как оно со скалой и шаред-кешом компиляции

В гошечке ж корутины. Зачем знать о потоках)

...и блокировках... и синхронизациях?

ИНтересно прям вот в отзывах пишут "Scala compilation is notoriously slow, making build times prohibitively long at scale. Pants' fine-grained dependency management and robust shared build cache helped us shrink build times and increase productivity despite the fast growth of our codebase. Its modularity and extensibility made it easy for us to add custom build steps, such as code generation, and to reason programmatically about dependencies. Pants has proven to be a core part of a powerful toolchain that has scaled up well with our codebase." -- Benjy Weinberger, Foursquare

про штаны я только слышал один раз на скаладейзе на докладе йокоты про сбт 1.0

было это кстати полтора года назад а воз и ныне там

интересно хоть в этом году 1.0 порелизят

было это кстати полтора года назад а воз и ныне там

что не очень хороший знак, как мне кажется

http://eed3si9n.com/sbt-1-roadmap There’s sbt/io, sbt/util, sbt/librarymanagement, sbt/incrementalcompiler already. Given that the incremental compiler is probably the most complex aspect of sbt at least in terms of implementation, that has been our focus on modularization. When we’re comfortable with all the module APIs being stable, that’s when we can put 1.0 on sbt itself.

ERROR: S client not available

судя по коммитам, "мы" это сам йокота и есть :) а учитывая традиционный японский перфекционизм..

интересно хоть в этом году 1.0 порелизят

Дык нужно контрибьютить

Там два с половиной калеки

там же вроде целая команда была, не?

на докладе с ним еще 1 чувак выступал, это точно

о, штаны :) штаны прикольные.

о, штаны :) штаны прикольные.

А есть ли опыт использования?

Автозамены... и выключить жалко, и иногда так "помогают".

А есть ли опыт использования?

Ну так, ковырял немного. Мы им спонсируем Artifactory и Bintray, так я ради интереса покрутил

Знает ли кто-нибуь крупные годные продакшн-проекты на ScalaJS? Или может быть у вас такой есть, и вы буквально пару слов про него сказать/дать ссылку? Вот тут http://www.scala-js.org/community/ только seventh sense серьезно выглядит, и то там написано "legacy application".

http://www.fluentcode.com/ как я понял

автор Li Haoyi

> The world's fastest online code explorer хм

https://scala.fluentcode.com/source/sbt/1.0.x/1.0.x/notes/0.13.11.markdown

есть расширение для браузера, приложение оффлайн розницы. - https://chrome.google.com/webstore/detail/%D0%BC%D0%BE%D0%B9%D1%81%D0%BA%D0%BB%D0%B0%D0%B4-%D1%80%D0%BE%D0%B7%D0%BD%D0%B8%D1%86%D0%B0-3/cpbnahkfbhiamlmpbllnbnaongbdomji?hl=en-US

есть расширение для браузера, приложение оффлайн розницы. - https://chrome.google.com/webstore/detail/%D0%BC%D0%BE%D0%B9%D1%81%D0%BA%D0%BB%D0%B0%D0%B4-%D1%80%D0%BE%D0%B7%D0%BD%D0%B8%D1%86%D0%B0-3/cpbnahkfbhiamlmpbllnbnaongbdomji?hl=en-US

О, а это ваше приложение?

Ага

Всмысле я в команде разрабов этого приложения

А вы сами пилили фасад для хром апи, или использовали https://github.com/lucidd/scala-js-chrome ?

Был уже запилен фасад для старой версии, через post message общаемся с ним

всм вы на scalajs сделали обертку над старым своим js кодом?

а что в качестве гуй либы использовали? scala-js-react?

Все так

круто

а исходники не открыты?

Неа

Юрий и как вам ScalaJS в продакшне? Сталкивались с какими-то особо острыми подводными камнями?

И как нашли людей, если не секрет? старую команду на энтузиазме перевели на scalajs?

И забыл сказать спасибо за ссылку!

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

ок, может от команды слышали отзывы?