И про кодирование экзистенциальных типов с помощью Visitor.

И про линзы!

А как объявить два типа, ссылающихся друг на друга? type A { test: B; } type B { test: A; }

type Chicken = | Eggs of Egg list and Egg = | Chickens of Chicken list

Или внутри рекурсивного модуля/неймспейса!

Спасибо

А как объявить два типа, ссылающихся друг на друга? type A { test: B; } type B { test: A; }

type A { test: B} and B { test :A }

Или внутри рекурсивного модуля/неймспейса!

Но лучше без этого. :)

Послушал доклад про .Net Core и F#.

Выглядит неплохо.

Кажется, VS не умеет до сих пор в F# проекты на Core?

Кажется, VS не умеет до сих пор в F# проекты на Core?

Не умеет

Жаль.

Пожалуй, попробую инфраструктуру Core для написания небольшой математической библиотеки.

Я пишу сейчас в VS Code, в целом нормально

Хотя в студии на F# не писал толком

Пожалуй, попробую инфраструктуру Core для написания небольшой математической библиотеки.

В vscode нормально, а главное кросплатформенно)

Мне тоже нравится VS Code.

Я просто сегодня увидел, что там дебаг работает для Core.

Я просто сегодня увидел, что там дебаг работает для Core.

Там много дебаггеров, что оч круто.

Возможно и для матлаба есть xD

Матлаба нет.

Я проверял. :)

Ну, и для F# на .Net Framework тоже дебаггера нет.

Ну, и для F# на .Net Framework тоже дебаггера нет.

Да? Я как-то дебажил.

https://github.com/ionide/ionide-vscode-fsharp/pull/344

В разработке.

А, я же fable дебажил.

Мне очень нравится сама идея Core.

Было бы круто, например, запилить шаблон для FsLab проекта.

Чтобы быстро развертывать среду для какого-нибудь дейтасаенса.

Правда, до этого нужно дождаться .Net Standard 2.0, реализацию тайппровайдеров для этого стандарта, и портированные версии библиотек...

Нескоро это будет.

А в чём фишка 2.0?

А то я не очень вкурсе

@Dolfik Единая полноценная BCL для .Net Framework, Xamarin, .Net Core.

А 1.6 это типа неполная?

Типа того.

https://github.com/Microsoft/visualfsharp/issues/1496#issuecomment-244315047

Кто шарит в том, как работают тайппровайдеры?

Я думал, что надо рефакторить и улучшать FSharp.Charting.

Оказалось, что все пользуются XPlot на самом деле.

Который через Plotly (JS) графики рисует интерактивные.

Что за времена сейчас.

Кажется, JS -- это лучшая платформа для визуализации сейчас.

Так ему же нужен JS движок

Это не очень

@Dolfik Браузеры-то у всех есть. Ну, я не имею в виду написание полноценных приложений, а скорее написание скриптов для обработки и визуализации данных.

Если нужно написать приложение с графиками, то тут достаточно взять OxyPlot. FSharp.Charting опять не нужен.

Ну если тебе нужно какие-нибудь графики для PDF отчёта генерить в приложении, JS за собой тащить не очень

Ну или у меня бот есть на Go, присылающий график по команде, для такой задачи тащить js не очень

Plotly умеет экспортировать в изображения.

@Dolfik Ну, это уже приложение. :)

Ну я к тому, что FSharp.Charting может быть полезным)

@Dolfik Хотя это и звучит странно. Зачем отправлять график, когда нужно отправлять данные? :)

Чтобы было красивенько ;)

Замечательно. Поставил на чистую машину .Net Core и VSCode, все работает. :)

Даже не верится.

Даже не верится.

Единственный минус что интерпретатор работает на моно

Единственный минус что интерпретатор работает на моно

Почему так?

@angmarr На каком Mono? Нет у меня его.

@angmarr На каком Mono? Нет у меня его.

У тебя винда?

Да.

@angmarr Нифига непонятно. С чего ты решил, что это так?

@angmarr Нифига непонятно. С чего ты решил, что это так?

Этот тест проходит http://stackoverflow.com/a/721194/7235355

Да.

Значит у тебя на полном .NET

Печально.

Значит у тебя на полном .NET

почему?

.net core подтягиваетсвой рантайм. и если проект создан и билдтся с помощью dotnet то он именно на core

.net core подтягиваетсвой рантайм. и если проект создан и билдтся с помощью dotnet то он именно на core

Я не про проект говорю, а про F# Interactive

Я не про проект говорю, а про F# Interactive

а, да. Скорее всего

@angmarr @neftedollar Надо ишшуй завести.

@gsomix не использовали https://storm.apache.org/ ?

@neftedollar Неа.

@neftedollar Неа.

если что тм есть отличные биндинги к F#

https://github.com/FsStorm/FsStorm а тут можно поковырять

https://github.com/FsStorm/FsStorm а тут можно поковырять

исправил ссыль

Я уже запутался в этих распределенных технологиях. %)

> Heh, I did some hacking on ProvidedTypes.fs and seem to be able to use simple DUs now. I've only verified field-less DU's, but maybe with some additional fiddling field-having DUs are possible?

Но это неточно. :)

Но это неточно. :)

ты мне скажи, зачем в softmax e^x? когда можно просто использовать x?

x/ Seq.sum(z) где x это i-тый элемент z.

вместо e**x/ Seq.sum( seq { for x in z -> e**x }) где x в числителе i-тый элемент z

https://m.youtube.com/watch?feature=youtu.be&v=9SOFqWYpf9Y

@neftedollar Я не шарю. http://cs231n.github.io/linear-classify/#softmax

> Heh, I did some hacking on ProvidedTypes.fs and seem to be able to use simple DUs now. I've only verified field-less DU's, but maybe with some additional fiddling field-having DUs are possible?

А я говорил, что там не в компиляторе, а в этой дурной портянке все проблемы!

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

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

Звучит как нормальный подход в принципе. Ну то есть затыка на количестве акторов не должно быть.

Но будь осторожен с такой архитектурой. Я так делал XMPP-бота на Scala+Akka, и архитектура в итоге путаная вышла.

Мне не понравилось всё делать акторами. Я в итоге считаю, что какая-то структура дополнительная нужна.

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

На каждый чат хочу создавать отдельный коннект к БД

Хотя это тоже сомнительный подход, но лучшего пока не придумал

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

Да, ок, попробовать и понять преимущества/недостатки решения — это отличная идея. Пробуй :)

На каждый чат хочу создавать отдельный коннект к БД

А вот тут я не уверен. Лично я в итоге у себя, чтоб нагрузки лишней не было, всю работу с БД делал через отдельного актора.

Ему все шлют сообщения, а он делает работу с БД.

Если вдруг оказалось бы, что пропускной способности недостаточно — я бы сделал, чтобы он проксировал запросы пулу акторов из нескольких коннектов. (Но не потребовалось)