а если он и нас перебанит? 😱

Главное не давать ему много власти

Интересно, можно ли запилить бота F# REPL, чтобы ты ему кодяру, а он тебе результат вычислений

Кстати, пилил когда-то :)

Кстати, пилил когда-то :)

воу! на гитхабе есть?

воу! на гитхабе есть?

Нет, он потерялся где-то на харде

Щас напишем

Придумаю ток как назвать

Придумал!

Интересно, можно ли запилить бота F# REPL, чтобы ты ему кодяру, а он тебе результат вычислений

Дык. MBrace

Я просто раньше никогда про это не думала

а идея кажется банальна :)

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

А system и ActorRef надо в какой-то рекорд заворачивать, или ещё куда-то?

Или можно прямо пилить в модуле?

И к модулю обращаться

Ты систему через контекст актора получить можешь

Ну вопрос остаётся :)

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

Так а как актора в актора передать?

А system и ActorRef надо в какой-то рекорд заворачивать, или ещё куда-то?

Две системы тебе не понадобятся. Можешь для удобства хранитьсистему в модуле, но только в main.

Так а как актора в актора передать?

АкторРеф можно перекидывать.

Селекты нет.

Суть вот в чём: Есть разные акторы, которые будут какие-то действия выполнять, и есть актор, через который будут все сообщения в телеграм апи уходить, так вот как из других акторов получить доступ к этому актору?

Селектом?

ActorSelection

Т.е. он достаточно быстрый?

Если он один - ты ж всегда актор реф по заранее известному адресу можешь получить

Окей, спасибо

Если он один - ты ж всегда актор реф по заранее известному адресу можешь получить

не, акторреф по адресу не получить. только селекш

А как принято хранить имена акторов?

не, акторреф по адресу не получить. только селекш

можно же разрезолвить вроде

В DU там, или Literal'ом?

(но неточно)

не, акторреф по адресу не получить. только селекш

Акторселекшн + Identity message = actroRef

можно же разрезолвить вроде

Можно, но не нужно 100%

Акторселекшн + Identity message = actroRef

Да, забыл об этом способе

Оба этих способа применять не стоит =)

А как принято хранить имена акторов?

🌚

Оба этих способа применять не стоит =)

Ага

🌚

В литералах:D

А как принято хранить имена акторов?

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

Оба этих способа применять не стоит =)

Тогда глобальный акторреф через который пусть всё уходит

Тогда глобальный акторреф через который пусть всё уходит

Router называется)

Я с аккой давно игрался :) но это ж флудилка :)

let requestProcessor = select context.System RequestProcessor let req = sendMessage 1L "Hello, world!" requestProcessor <! req

Так же можно?

Или tell оператор нужно применять только к IActorRef?

(<!) (actorRef : #ICanTell<'Message>) (msg : 'Message) : unit - tell operator, sends a message to target actor through it's actor ref.

Но при этом ошибки нет

Или tell оператор нужно применять только к IActorRef?

tell в оригинале к ICanTell применяется. ActorSelection и ActorRef оба такие

Спасибо)

Так, я снова с глупыми вопросами. Если актора не существует, а я select делаю, всё равно TypedActorSelection вернётся?

Так, я снова с глупыми вопросами. Если актора не существует, а я select делаю, всё равно TypedActorSelection вернётся?

Да

И как узнать, есть ли актор?

И если нет - создать

Шли сообщение Identity

Если ответит, значит есть

Ненененене, так делать не стоит

Ненененене, так делать не стоит

Почему?

И что взамен?

Ща абисню

Роутер Post?

Я помню слова Вагифа, что Ask не надо юзать

Tell don't ask там было вроде

Я помню слова Вагифа, что Ask не надо юзать

Да не через аск опрашивать же)

Tell don't ask там было вроде

Это тут не причем

Короче, мне нужен некий selectOrSpawn

Предположим мы допускаем в нашей программе что возможны ситуации когда актора на той стороне нет, тогда мы или получаем постоянные deadletters (потерю логики блин!) или мы постоянно сами себе злобные буратины и должны КАЖДЫЙ раз по селекшнеу резолвить акторреф, т.е. замедлять каждый tell на порядок Оба варианта катастрофично снижают отзывчивость и работоспособность.

А акторреф в мессаже же нельзя?

Лучше не надо

Он же поменяться может

Как актору ответить не родителю, не сендеру

Предположим мы допускаем в нашей программе что возможны ситуации когда актора на той стороне нет, тогда мы или получаем постоянные deadletters (потерю логики блин!) или мы постоянно сами себе злобные буратины и должны КАЖДЫЙ раз по селекшнеу резолвить акторреф, т.е. замедлять каждый tell на порядок Оба варианта катастрофично снижают отзывчивость и работоспособность.

Так это если каждый

А тут спрашивают по конкретный)

Но если говорит про "каждый" то тут я, согласен

Как лучше сделать. Если надо создавать акторов в динамике и так же их удалять, делать это через актора диспетчера который будет заведовать лайфтаймом акторов. например - кто-то посылает NewUserChat сообщение в систему. Актора под такого юзера нет, поэтому у нас есть актор UserChatsDispatcher через которого проходят все сообщения для UserChat акторов. Он видит что такого актора нет, создаёт его и роутит сообщение туда. Он в себе держит все ActorRef чтобы их убивать при необходимости. Таким образом мы не получим потери сообщений и не надо ресолвить каждый раз все акторселекшны

Как актору ответить не родителю, не сендеру

Селект сделать

Ну мы опять вернулись к началу

А акторреф в мессаже же нельзя?

ни в коем случае! акторреф при стоп/старте меняется. Акторселекшн вечный

@Dolfik посмотри на орлинс