на скорую руку набросал

possibleAttacks - ради пешки

вот ещё пример (мне нравится идея что фигурка имеет метод "могу сходить туда-то" это выглядит натурально) https://github.com/xnull/xnull/blob/master/chess/src/main/scala/chess/Piece.scala

Да, спасибо за примеры, есть над чем подумать

На счет натурально

Фигурку вроде бы как шахматист двигает

тоже верно)

И он у себя в голове все просчитывает))

#планпоездки

http://www.lihaoyi.com/post/StrategicScalaStyleConcisenessNames.html

Кто-нибудь использовал Akka FSM в связке с БД? Задом чую, что будут проблемы из-за асинхронности, но уж больно хорошо в задачу вписывается. Persistence FSM идеально бы зашла, но она в альфе

А в чем там могут быть проблемы?

Если я не хочу делать в акторе блокирующие вызовы, придется либо делать ему дополнительный state "Working", при котором он будет отбрасывать запросы на смену состояния, либо городить Stash

> дополнительный state "Working", при котором он будет отбрасывать запросы на смену состояния отбрасывать - в смысле отвечать Status.Failed?

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

Сработает?

так @leammas об этом и говорит, насколько я понимаю

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

Сработает?

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

ну, это личный опыт. может быть у кого-то есть более приятный опыт

Со стешем есть пара акторов, но они просты до безобразия

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

Резиновая :) UnboundedDequeBasedMailbox пока по памяти не просядет

Потери кстати могут быть всегда )

Это не есть хорошо) нужно backpressure сделать

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

https://twitter.com/eed3si9n/status/728240804800536576 это как раз с изменениями, которые должны значительно улучшить инкрементальную компиляцию

https://github.com/sbt/sbt/issues/1104 интересно, выходит так, что это появится только в sbt 1.0. а она не так скоро выйдет вроде

Народ, кто какую scala либу для Redis юзает?

юзаем джавовую jedis

А почему не скаловую?

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

исторически сложилось

Народ, кто какую scala либу для Redis юзает?

scredis

юзаем джавовую jedis

завидую ?

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

натыкаюсь только на очень теоретические курсы

"Сделать полку, которая бы хитро опускалась" - зачем там конструирование/механика? Теория для всяких маховиков, коробок передач и так далее. Для полок common sense должно хватить.

Можно найти туториалы и по ним компоновать. В курс вряд ли кто то такое объединял.

в личку отвечу

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

а рекурсивный рекавери в busy-waiting не вырождается в конечном счете? Мб то что внутри в blocking обернуть?

Фьючуры что поднялись после рекавера наверно не те которых дождалась фьючура листа

да

это не понятно; это новые фуьючеры похоже

накатал на коленке https://gist.github.com/pomadchin/33b53086cbf81a6256ddb452090e4e3b

но эта штука блочится в треде

и надо сделать нормальый афтер / авейт

сделай на акке - передаёшь фьючер вновь созданному актору, он всё контролирует. Вместо Thread.sleep используешь context.system.cheduler.scheduleOnce(...)

да после серфинга в сети выглядит как единсвтенное решение

):

но я сейчас кжсперментирую с таймером

def delay[T](delay: Long)(block: => Future[T]): Future[T] = { val promise = Promise[T]() timer.schedule(new TimerTask { override def run(): Unit = { promise.completeWith(block) timer.purge() } }, delay) promise.future }

val timer = new Timer() // это джава таймер

если есть мысли по этому поводу то это очень привествуется; потому что смахивает на некую костыльность

и я не очень верю таймеру

о

я знаю где ты этот снипет взял

cj

so

и точно скажу что он работает

отлично)

ну я изменил его

там тип T передавался

и в промис вставлялась complete(block)

пурджа не было (не уврене что он нужен)

BetManagementRoutes

ах

private def delay[T](delay: Long)(block: => Future[T]): Future[T] = { val promise = Promise[T]() val t = new Timer() t.schedule(new TimerTask { override def run(): Unit = { promise.completeWith(block) } }, delay) promise.future }

вот такой снипет я юзаю

и он работает

отлично пашет знач

создает дилеи на фьюче

мне не нравится что он тамеры плодит и не чистит

подругому некак

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

как воркэраунд я на функцию имею общий таймер

ну так треды то коллектятся как закончат работу

таймер то заново создается каждый раз

да у мя сложно) я такую фигню делаю в каждой партиции спарка

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

акка есть ?

можешь через scheduler сдеать тоже самое

ну блин спарк же да :\ да хотел без акки сейчас со всем пробую хз как более элегантно

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

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

+ спс за фидбек по поводу таймера

сча минут через 20 вброшу как чо

ci прогонит)

я на таймерах юзал такое

таймер который из netty

в общем не получилось

поведение Task'a из scalaz не повторить O:

футуры создаются чуть чуть не в тот момент и чуть чуть не вовремя синхрятся

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