let ofObj value = match value with null -> None | _ -> Some value

я не уверен что этот гард так уж полезен, я обмазываю все вызовы Newtonsoft.Json так: maybe { let! id = jTok.SelectToken("object.values[0].id") |> Option.ofObj }

ну у меня понятно есть инлайн функция вида let inline selectToken : JToken -> JToken option

А как называется подход, когда всё IO делается либо в начале (чтение), либо в самом конце процесса, а внутри всё из чистых функций?

Это же не луковичная архитектура?

А как называется подход, когда всё IO делается либо в начале (чтение), либо в самом конце процесса, а внутри всё из чистых функций?

в NASA так на сях писали\пишут

А не, совсем. Там только чтение вначале

Это же не луковичная архитектура?

нет

А как называется подход, когда всё IO делается либо в начале (чтение), либо в самом конце процесса, а внутри всё из чистых функций?

Марк Симан называет это "impure/pure/impure sandwich"

Я бы с таким ником точно банил

Его брат близнец?

Никто не знает есть ли стандартная функция на такое |> function | Some (x, y) -> Some x, Some y | None -> None, None преобразовать опшн тупля в тупль опшнов

Ну стандартной нет,но option.bind должен справиться

Ну я ж не Option возвращаю, как тут bind поможет?

Да, согласен

Я невнимателен

Вобще интересно.

в акторе можно mailbox.Defer вызвать чтобы он диспоуз на стопе актора делал

Вроде бы в Akkling нет context.Defer.

Да, это я прогнал

Он есть, но api другой, насколько я помню

https://github.com/Horusiath/Akkling/issues/68

Честно говоря дичЪ

Он есть, но api другой, насколько я помню

Есть LifecycleEvent Stop, но это совсем другое.

Вроде бы в Akkling нет context.Defer.

?

@Kleidemos Шаришь в Akkling эффектах?

@Kleidemos Шаришь в Akkling эффектах?

Лучше сразу вопрос.

Я думаю, как жить без mailbox.Defer

Нужно как-то правильно эффекты хендлить. Как?

Я ловлю Stop. Эффекты тут не причем.

Я ловлю Stop. Эффекты тут не причем.

Stop — это..?

Stop — это..?

Это LifecycleEvent. В этом случае твой актор теряет типизацию.

Это LifecycleEvent. В этом случае твой актор теряет типизацию.

Не подходит.

Иначе никак.

В теории можно посмотреть context.UntypedContext.Defer.... Может есть что.

Иначе никак.

Это довольно странно. Раньше были Behavior<'T>, которые позволяли хендлить системные сообщения.

Потом их заменили на эффекты.

Это довольно странно. Раньше были Behavior<'T>, которые позволяли хендлить системные сообщения.

Я второй месяц с акклинг, не знаю как было раньше.

Или это был только прототип... ?

Вообще если ты создашь Props<int>, то ты не получишь сообщения LifecycleEvent. Там фильтр установлен такой, что часть сообщений даже не высылается.

Ок.

@VagifAbilov ^

Потом их заменили на эффекты.

Эффекты были очень давно и их пытались выпилить из условной акклинг.кор насколько я помню.

По моему достаточно удобная штука получилась.

Я ловлю Stop. Эффекты тут не причем.

Поправочка, там PostStop.

Довольно странно, конечно. Итого есть два места без типизации: - mailbox.Sender(), но это лечится передачей типизированной ссылки на отправителя в сообщении - обработка сообщений системы

Ладно, я Unit-1 почти закончил. Надо бы порядок навести, наприме, избавиться от actor { ... } в коде.

Мне почему-то интерфейс через CE здесь не нравится. :)

@gsomix

закрой дверь, они на свет ползут ?

Мне почему-то интерфейс через CE здесь не нравится. :)

Норм. Автор akkling где-то в issue-ях говорил, что хотел бы избавиться от actor {...}. Правда я не помню, собирается ли он это реально делать.

Мне тоже не хватало Defer, давно ещё issue открыл, потом как-то выкрутился, уже не помню деталей. Бартош был сейчас в Осло на NDC, делал доклад по Streams с демо на Akkling. Я его спросил о будущем библиотеки, он сказал, что подумывает ещё раз радикально изменить API, чтобы получились настоящие типизированные акторы, без всех этих typed - untyped. Но когда, пока неизвестно.

Было бы круто.

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

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

Кажется, уже что-то было такое, но убрали.

Когда я перешёл на акклинг, уже не было.

Привет.

прет

В бан

@neftedollar @gsomix @vshapenko @AnutaU Hi there, a short update on questions: 1) Type providers parameterized by types - is being developed by only one person, so ETA - next major F# release after this person will be ready, but we are strongly encouraged to help; 2) SRTP fixes - ETA F# 5 3) Traits, type classes or something like that - when general architecture picture will be agreed with rest of .NET language architects, specifically Mads, ETA unknown, but maybe around C# 8.0; 4) Anonymous records - they are ready, but the reason why they are not in F# 4.5 - not enough feedbacks and tests from the community, ETA - F# 5.0; 5) Reason why there are no parameterized modules in F# in the same way as in OCaml - primarily because of possible community split like in Scala, when 50% use it, and another 50% don't use it, and missing of clear picture how to constraint such feature in a right way, but it could be added if there would be enough requests; 6) Task computational expression recognizable by the compiler - ETA F# 5.0;

@psdarr Thanks a lot!

@psdarr Thanks a lot!

You are welcome!

https://sergeytihon.com/2018/06/16/f-weekly-24-2018-fable-conf-2018-26-27-october-berlin/

Рыба знаменитый. :)

@neftedollar @gsomix @vshapenko @AnutaU Hi there, a short update on questions: 1) Type providers parameterized by types - is being developed by only one person, so ETA - next major F# release after this person will be ready, but we are strongly encouraged to help; 2) SRTP fixes - ETA F# 5 3) Traits, type classes or something like that - when general architecture picture will be agreed with rest of .NET language architects, specifically Mads, ETA unknown, but maybe around C# 8.0; 4) Anonymous records - they are ready, but the reason why they are not in F# 4.5 - not enough feedbacks and tests from the community, ETA - F# 5.0; 5) Reason why there are no parameterized modules in F# in the same way as in OCaml - primarily because of possible community split like in Scala, when 50% use it, and another 50% don't use it, and missing of clear picture how to constraint such feature in a right way, but it could be added if there would be enough requests; 6) Task computational expression recognizable by the compiler - ETA F# 5.0;

thnx!

@gsomix для ocaml модулей у нас мне кажется достаточно человек, чтоб сделать "достаточно" requets

@gsomix для ocaml модулей у нас мне кажется достаточно человек, чтоб сделать "достаточно" requets

Я не думаю, что это будет большой вин.

Как yaml провайдеру объяснить, что поле может быть option?

Как yaml провайдеру объяснить, что поле может быть option?

Боюсь, что никак.

Привет!

https://marketplace.visualstudio.com/items?itemName=georgewfraser.fsharp-language-server пробовал кто? работает?

Привет!

привет)

@gsomix, помнишь там был нативный язык пони (даж чат был)?

его тут в одном чате сегодня даже вспоминали :D

//offtop mode off

https://marketplace.visualstudio.com/items?itemName=georgewfraser.fsharp-language-server пробовал кто? работает?

что брать для вскода? это или ионид?

что брать для вскода? это или ионид?

Ионид.

fsharp-language-server -- очень молодой проект.

@suddengunter У ионид много хороших фич, но если будет тормозить, рекомендую поковыряться в настройках.

Я себе, кажется, отключил линзы и анализаторы некоторые.

fsharp-language-server -- очень молодой проект.

угу (скачал->не может даже запуститься, но не пишет причину ошибки) просто у F#ls там в описании гифка с сравнением его и ионида оч показательная в плане скорости работы

значит ионид

угу (скачал->не может даже запуститься, но не пишет причину ошибки) просто у F#ls там в описании гифка с сравнением его и ионида оч показательная в плане скорости работы

Я читал в слаке спор на эту тему. Кажется, там сравнение некорректное, fsls сильно отстаёт по фичам, поэтому работает быстрее из коробки.