поэтому надо брать плазму на 150 дюймов! кек!

нужен эталонный экран

Вася, а сколько у тебя акторов?))

Инстансов?

в целом вот этот вопрос и интересен, если актор растёт по коду его надо делить, точно как и функцию?

Не обязательно делить на акторы, (подсказка у PF есть orElse)

в длину или ширину?

Мы же на скале пишем, а не на какой то там джаве. Конечно в ширину.

Не обязательно делить на акторы, (подсказка у PF есть orElse)

более того там есть andThen

А у Monoid есть combine

Вася, а сколько у тебя акторов?))

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

норм

более того там есть andThen

Если две PartialFunction связать через andThen ничего хорошего не получится

Опрос по акторам, кто использует, каково на вскидку среднее кол-во типов сообщений обрабатываемых в ваших акторах (среднее по актору)?

1-2 обычно

Не обязательно делить на акторы, (подсказка у PF есть orElse)

чёт, да простенько, можно же описать все вне receive

Если две PartialFunction связать через andThen ничего хорошего не получится

я просто намекнул что есть возможность. логгировать, например чо там прилетело. там же выходит PF[Any, Any] andThen PF[Any, Unit] что сам по себе такое

я просто намекнул что есть возможность. логгировать, например чо там прилетело. там же выходит PF[Any, Any] andThen PF[Any, Unit] что сам по себе такое

то есть по функциональности разбить на слои?

типа логирование (обработка всех типов), затем бизнес логика и тд

ну типа того

как инструмент при отладке, не более того

1-2 обычно

String + Map[String, Any] ?

тоже интересная мысль

а почему только для отладки?

String + Map[String, Any] ?

Нет, просто 95% акторов маленькие и делают что-то одно)

можно просто тогда тру фолс слать

а почему только для отладки?

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

можно просто тогда тру фолс слать

Нет, без стринги никак

"true" и "false"

treu

flase

truse

truse

Нечёткая логика уже какая-то

нечеткая это когда "almost true"

"not really true but can't say false too"

вот это нечеткая

Вы что, до сих пор про Акку? Даже при Москаленко такого не было

Вы что, до сих пор про Акку? Даже при Москаленко такого не было

пока оне не убрал имя из профиля вернее

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

А его нету тут ?

Вот это поворот

вроде есть

или нет

@CapDev ты тут?

тут он тут, он не пишет потому что все его коммнетарии обычно про акку да монгу были) и мы затралили его

Ты не так зовёшь

Акка монга призываю @CapDev

мы такие токсичные

Да не, это большая любовь просто

большая как кластер?

Как твой акка кластер

Или лучше мой

Опрос по акторам, кто использует, каково на вскидку среднее кол-во типов сообщений обрабатываемых в ваших акторах (среднее по актору)?

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

Народ можно как то из класса получить доступ к параметрам build.sbt без плагинов?

Народ можно как то из класса получить доступ к параметрам build.sbt без плагинов?

сгенерить файл и положить в него то что тебе хочется

Что то такое ищу: https://stackoverflow.com/questions/8957025/sbt-including-the-version-number-in-a-program

http://www.scala-sbt.org/1.x/docs/Howto-Generating-Files.html

Что то такое ищу: https://stackoverflow.com/questions/8957025/sbt-including-the-version-number-in-a-program

https://github.com/sbt/sbt-buildinfo

sourceGenerators in Compile += Def.task { val file = (sourceManaged in Compile).value / "demo" / "Test.scala" IO.write(file, """package core.utils |object Info { | val version = "%s" | val name = "%s" |} |""".stripMargin.format(v, n)) Seq(file) }.taskValue

^ пример как не только версию класть

Спасибо!

buildInfoKeys := Seq[BuildInfoKey](name, version, scalaVersion, sbtVersion) В рантайме напечатает что-то вроде: name: blablabla, version: 1.3.1, scalaVersion: 2.11.11, sbtVersion: 0.13.16

Супер думаю с этим справлюсь

Народ кому то приходилось автоматизировать развертывание aws labmda на Scala?

это не должно отличаться от джавы. собрал большой джар и запулил

собрал залил на s3, сейчас проблема сгенерировать cloudFormationTemplate и скормить в CF консоль

Господа, подскажите как разрешить такую проблему trait Message[T] { def version: Int = 1 def subsystemId: String = "system-1" def writes: Writes[Message[T]] final def json: JsValue = Json.obj( "version" -> version, "subsystemId" -> subsystemId, "content" -> Json.writes(this)(writes) ) } Вот как должен быть описан trait Messages с T, что бы def writes заработал? Или это как то проще можно сделать

можно добавить implicit val jsonFormat: JsonFormat[T] как поле трейта

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

ERROR: S client not available

"content" -> Json.toJson(this)(writes)

а блджад не увидел;

а на что ругается? вроде все верно +-

"content" -> Json.toJson(this)(writes)

...

: D

Да, там опечатка, toJson

собрал залил на s3, сейчас проблема сгенерировать cloudFormationTemplate и скормить в CF консоль

тогда это не в этот чатик. тут про скалу

Ругается, что недостаточно доказательств) Error:(75, 22) No Json serializer found for type Message[T]. Try to implement an implicit Writes or Format for this type. "payload" -> content Error:(75, 22) not enough arguments for method content: (implicit ev: Message[T]])play.api.libs.json.JsValue. Unspecified value parameter ev. "payload" -> content

а... наверно достаточно будет снаружи implicit val: Writes, а внутри implicit def m[T](implicit t: T): Message[T]

я думаю ты хочешь в content записать T а не Message[T]. И writes тебе нужен для T а не для Message[T]

я думаю ты хочешь в content записать T а не Message[T]. И writes тебе нужен для T а не для Message[T]

он хочет свой класс extend'ить от этого трейта и чтобы все его поля попадали в json

и вообще нужно не так сделать :) нужно сделать контейнер Message[T], и сделать implicit def writesForMessage[T: Writes]: Writes[Message[T]]

ну, на это у меня один ответ - композиция а не наследование

да, но иногда нужно быть проще)

вот и вопрос, как сделать проще :)

В общем, да, композиция в очередной раз спасла отца русской демократии

Опрос по акторам, кто использует, каково на вскидку среднее кол-во типов сообщений обрабатываемых в ваших акторах (среднее по актору)?

главное соблюдать Сингл респосибилити принцип, 6-7 всреднем

в целом вот этот вопрос и интересен, если актор растёт по коду его надо делить, точно как и функцию?

если есть профит то нада делить

trait Message[T <: Message[_]] extends DefaultJsonProtocol with NullOptions{ def version: Int = 1 def subsystemId: String = "system-1" implicit def writes: JsonWriter[T] def json: JsObject = JsObject( "version" -> JsNumber(version), "subsystemId" -> JsString(subsystemId), "content" -> this.asInstanceOf[T].toJson ) } case class MyMsg(text: String, int: Int) extends Message[MyMsg]{ override implicit def writes: JsonWriter[MyMsg] = jsonFormat(MyMsg.apply, "text", "int") } но Дично я бы не стал так делать)

Опрос по акторам, кто использует, каково на вскидку среднее кол-во типов сообщений обрабатываемых в ваших акторах (среднее по актору)?

Все операции, которые надо производить над единицой mutable state - все в одном акторе

Все операции, которые надо производить над единицой mutable state - все в одном акторе

Если есть допустим User и у него есть набор операций: - купить - продать - изменить данные На каждую операцию - один тип И все типы обрабатываются одним актором

ну да, принципы те же что и обычно

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

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

trait Message[T <: Message[_]] extends DefaultJsonProtocol with NullOptions{ def version: Int = 1 def subsystemId: String = "system-1" implicit def writes: JsonWriter[T] def json: JsObject = JsObject( "version" -> JsNumber(version), "subsystemId" -> JsString(subsystemId), "content" -> this.asInstanceOf[T].toJson ) } case class MyMsg(text: String, int: Int) extends Message[MyMsg]{ override implicit def writes: JsonWriter[MyMsg] = jsonFormat(MyMsg.apply, "text", "int") } но Дично я бы не стал так делать)

Ну да, выглядит омезительно. Без наследования все гораздо симпатичнее выходит.

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

> в системе акторов можно же стейт в других разрезах рассматривать. Это уже как душе угодно. Но в итоге получится что есть кусок mutable state, который надо атомарно менять набором каких-то операций.

Акторы же не какая то магия - это всего лишь одна из абстракций, которая позволяет работать с mutable state

да, да. я тоже об этом, что это абстракция чуть более низкоуровневая чем ООП

Если надо location transparency и работа с mutable state - акторы збс! Иначе есть другие варианты

Сегодня не пятница конечно, но ладно напишу... Акторы это и есть true ООП А то что сейчас считается ООП - лучше назвать ToolBox Ящик с инструментами, каждый объект как инструмент, методы которого мы дёргаем. Это как бы мёртвые объекты, которыми мы управляем снаружи. А в акторной модели они живые, активные

с душой