Должен быть return! messageLoop

let! context = inbox.Receive() sendCat context можно как-то заменить на подобное: inbox.Receive() |> sendCat

?

Как же мне нравится развальцовывать дутых оопшников

Ох, можно и поработать

let! context = inbox.Receive() sendCat context можно как-то заменить на подобное: inbox.Receive() |> sendCat

Не стоит, имхо

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

Насколько я успел заметить, с мейлбоксами всегда идет немного бойлерплейта. @vshapenko как думаешь, имеет смысл что-нить вроде этого вынести в нугет? https://github.com/kagetoki/SnakeGame/blob/master/PostOffice/Mailbox.fs

ну там рашпилем немного доработать - пробросить Dispose например

Ну насчёт Kill не уверен

Скорее мейлбокс должен принимать список обработчиков

Разных типов

Но как это красиво засунуть в f# ,я пока не придумал :)

Там понятно, что словарь по типу сообщения, но это же фуфуфу

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

Скорее мейлбокс должен принимать список обработчиков

типа разные applyMessage с разным входным типом message?

типа разные applyMessage с разным входным типом message?

Угу

И тут вот неясно

То ли делать кучу мелких мейлбоксов

ну самые отважные такое решают через IoC, но от одной мысли воротит

Как импротировать только maybe из ExtCore.Control?

ну самые отважные такое решают через IoC, но от одной мысли воротит

Ну вот и я о том

То ли делать кучу мелких мейлбоксов

можно объединить входные типы сообщений в DU

можно объединить входные типы сообщений в DU

А если их неизвестное количество?

а кейс реальный есть? Мб если их неизвестное кол-во, то что-то не так с дизайном?

а кейс реальный есть? Мб если их неизвестное кол-во, то что-то не так с дизайном?

Ну ты же хелпер хочешь

Который можно было бы юзать для уменьшения бойлерплейта

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

Тогда зачем Kill?

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

Если есть CancellableToken

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

поэтому не уверен, стоит ли оставлять такой функционал. С другой стороны - каши не просит

поэтому не уверен, стоит ли оставлять такой функционал. С другой стороны - каши не просит

Ну я вот тоже не уверен

ну а если сценарий, что поток сообщений теоретически бесконечен, и когда-то таки надо остановиться и перестать?

без kill трудно реализовать

Тогда зачем Kill?

это же PoisonPill из акки, нет?

смешное название

Как же мне нравится развальцовывать дутых оопшников

Предпочитаешь на британский флаг или на японский?

Предпочитаешь на британский флаг или на японский?

=) Тут проблема в том что аргументы те же

ну а если сценарий, что поток сообщений теоретически бесконечен, и когда-то таки надо остановиться и перестать?

CancellationToken

У мейлбокса есть перегрузка

о, прикольно. Добавлю тогда

С другой стороны, если нужно детерминированную,то лучше килл

ну как бы можно наверное и самому на каждой итерации чекать токен

сделать то же самое, только не через вызов килл, а через отзыв токена

А post не тормозит?

@FSharpBot тыкните пожалуйста пару раз :)

/meow

Задержки есть, но сообщения вроде не теряет

Тыкнул. Пишет что отправляет фото - и тишина

Фото не пришло

Ну, значит, заломали

Надо код смотреть

@FSharpBot тыкните пожалуйста пару раз :)

3 из 3 фото пришло

Так, а юзеров не считает

Мне котиков отдаёт

Плохо

/stats если что

А тыкните ещё раз @FSharpBot

Вроде поперло

Хмм, почему-то стейт не сохраняется

У меня мяу отвалилось

задудосил

в хлам

А мне задуддосить не вышло

Так

А тыкните ещё раз

Арбайтен

Спасибо

Несколько мяу в одном сообщении не понимает

Несколько мяу в одном сообщении не понимает

Так и должно быть

https://github.com/Dolfik1/ItMeetupCats/blob/dev/Program.fs

Вот код, посмотрите :)

Ошибка есть

Где?

При изменении стейта делай return! messageLoop newState

Всмысле?

А сейчас как?

Аа