и мб просто переопределить resolvers

resolvers := Seq(...)

Ну в общем убрал централ. теперь везде Failed to read descriptor dependency

раньше так же было, а потом он шел в мейвен и там скачивал что-то без чексуммы

pizdec.jpg

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

сработало что ли О_О

addMavenResolverPlugin в plugins.sbt удалил

ошибки пропали, точнее теперь пишет [warn] Host repo.t2v.jp not found. url=http://www.t2v.jp/maven-repo/org/ow2/asm/asm-parent/4.1/asm-parent-4.1.jar [info] You probably access the destination server through a proxy server that is not well configured. Посмотрим, как это скажется

А он зачем был нужен?

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

у тебя какие-то репозитории странные)

Для apache common logging? :)

вообще

да и apache common logging нах не нужен)

-_-

нормальные люди slf4j юзают

У нормальных людей есть транзитивные зависимости

плохая практика)

Транзитивные зависимости? Это троллинг?

да)))

понятно

на самом деле, если не юзаешь logging сделай на него exclude

Кто-нибудь юзал: https://github.com/strongtyped/fun-cqrs ?

Давно rc стал релизом?)

github release

хэй - новый выпуск http://scalalaz.ru/series-03.html

класс

спс!

Akka 2.4.10 http://akka.io/news/2016/09/07/akka-2.4.10-released.html

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

Typesafe Logging?

да, скала логгинг который

лично мне тайпсейф не нужон

В каком смысле?

https://github.com/typesafehub/scala-logging

ну вот там в исходниках какая-то магия происходит с макросами. Зачем всё это? Разве нельзя сделать тончайший враппер с меодами в стиле: def trace(message: String, arguments: Any *) = if (log.isTraceEnabled) log.trace(message, arguments)? Тайпсейф - я так понимаю это когда у нас есть форматированная строка и несколько параметров, дык вот если параметры разъезжаются с форматированной строкой то в тайпсейф логгере у нас будет ошибка компиляции. Мне такая фича не нужна

Там тайпсейф это просто название

+

они спцом переименовались в лайтбенд

Макросы нужны, чтобы не вычислять аргументы

А зачем вообще тогда враппер

У них там 5 методов всего логгеров который 90% времени юзаются

чтобы написать with Logger

и не создавать филд логгера

Ну трейт можно написать

Ну там так и сделано

да тож самое получится а эта депенся из пары классов

не тяжелая ниразу

Не я не спорю что враппер норм

Я сам его использую

Просто зачем человеку враппер без явных преимуществ

Макросы это типо преимущество

При компиляции вычисляет параметры а не в рантайме

не все

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

и решается эт как раз в рантаиме

всё так

кстати если бы был call by value для varargs то можно было бы и без макросов

call ba value разворачивается в куда более сложный байткод, чем просто иф, вставленный макросом

ERROR: S client not available

не страшно

jit уберет)

как раз таки страшно. Потому что экономия, которую дает макрос - она не очень значительная. А если везде все параметры передавать как call by value, то там на каждый арумент фактически будет передаваться фунгкция. А это объект класса. А это уже довольно жирно.

в итоге вся экономия сойдет на нет

и враппер только жыра добавит

не стоит быть таким категоричным

не известно какие оптимизации делает scalac

возможно есть какой-то escape analyze

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

кто-нибудь в курсе, существует ли возможность в параллель запустить несколько совершенно разных Future, а потом дождаться всех сразу одним таймаутом? хочется чего-то такого: def f(a: Int): Either[ErrorResponse, ResponseForF] = ??? def g(b: String): Either[ErrorResponse, ResponseForG] = ??? def parallel[T, E](f: => Either[ErrorResponse, T], g: => Either[ErrorResponse, E], timeout: Duration): Either[ErrorResponse, (T, E)] мне как раз parallel нужен. можно написать самому с корректным учетом истекаемого таймаута, но не хочется, если уже есть библиотечная функция

Await может ждать только одну Future и не комбинируется, вроде бы

Future тоже комбинируется только в последовательность. ну или можно из List[A] и f: A => Future[B] получить List[Future[B]] - но это не то, что нужно

Future.sequence

Не из той оперы?

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

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

превращается в цепочку f(1).flatMap(_ => f(2)).flatMap(_ => f(3))

Если последовательность, то в for засунь

Ну или так

in.foldLeft(successful(cbf(in))) { (fr, fa) => for (r <- fr; a <- fa) yield (r += a) } map (_.result())

а мне нужно не последовательно, а одновременно двух фьючей дождаться именно)

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

хм. хотя я что-то ступил. flatMap выполняет фьючи параллельно

по крайней мере простой тест вида https://gist.github.com/menchauser/260d5d2653f4a3eafb28fe1351da01ce отрабатывает успешно

хм. хотя я что-то ступил. flatMap выполняет фьючи параллельно

Нет

Просто в твоем примере ты запустил их ДО того как скомбинировал в for

Попробуй val f1 = ... заменить на def

оу

опять ступил, спасибо

А если нужно параллельно, то Future.traverse/sequence/zip

спасибо, попробую!

> sbt 0.13.9 release note > @cunei in #1223 discovered that sbt leaks PermGen when it creates classloaders to call Scala Compilers. sbt 0.13.9 will call GC on a set interval (default: 60s).