Pavel Можешь для диагностики расписать конкретные типы у аргументов конструктора?

да, тоже только что про это подумал

потому что там тоже obj

@gsomix ты не вспомнил? :)

Вспомнил и сразу забыл!

да, тоже только что про это подумал

Обычно рекомендуется во всех внешних API прописывать явные типы.

type MessagingManager<'C> ( cts: CancellationTokenSource, raftRequestProcessor : RequestData<'C> -> Async<SenderInfo * ResponseMessage>, raftResponseProcessor : ResponseProcessingResult<'C> -> unit, config : RaftConfig) as self =

Теперь, наверное, нужно осмотреть код рядом с вызовом этих функций.

а не является ли вывод типов поверх явно прописанных ошибкой само по себе?

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

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

Иногда бывает сложно проследить явные зависимости в том, как компилятор выводит типы.

Поздний код влияет на более ранний, и наоборот.

понятно, ок, значит надо не что-то непонятное ловить, а тупую ошибку

Pavel Я бы это отлаживал так: сначала закомментировал бы все, потом добавлял код и смотрел, как это влияет на вывод.

спасибо, видимо, уже завтра буду тырситься с этим :)

спасибо, видимо, уже завтра буду тырситься с этим :)

Хорошо. Пиши, если что!

ок, постараюсь сделать маленький пример, как разберусь

Доброго дня, товарищи! Такой вопрос - вы тут недавно ковырялись в провайдерах и мне бы хотелось знать, какие неожиданные или неочевидные штуки вы при этом встречали? Как обычно, интересуюсь с корыстными целями использования в докладе :)

Ну, в общем, мне показались интересными вот эти разрозненные факты. (Пишу не только для Романа — он-то почти всё это наверняка и так знает, а остальным может быть интересно.) 1. Провайдеры типов — это не фича компилятора F# в чистом виде. У этого механизма есть две части: одна живёт в компиляторе, а вторая живёт в Type Provider SDK (который нужно подключать ко всем создаваемым провайдерам). Можно писать провайдеры, не пользуясь SDK, но это (кажется) сложнее. 2. Существуют т.н. generative и erased-провайдеры. Generative-провайдеры создают настоящие типы, которые потом можно увидеть и из других языков, если подключить к ним F#-сборку. Erased-провайдеры ближе к макросам, поскольку сгенерированные типы и методы заменяются в итоговой сборке на код, который находится внутри них — можно сказать, что они сразу инлайнятся. 3. Забавный факт: изначально провайдеры типов вообще создавались не как механизм, работающий исключительно с F#-кодом. Generative-провайдеры типов появились для того, чтобы код можно было генерировать на других языках, и отдавать нашему компилятору готовые сборки. Подробнее от Сайма тут: https://github.com/Microsoft/visualfsharp/issues/2406#issuecomment-335328819 4. API для generative- и erased-провайдеров почти не отличается — основная часть поведения регулируется одним флагом, который передаётся при создании провайдера. 5. Чтобы написать свой провайдер типов, нужно включить в проект несколько файлов из Type Provider SDK. Не подключить библиотеку, а именно включить файлы — например, скопировав их. Это поначалу кажется весьма неаккуратным, но было сделано специально чтобы не добавлять DLL-зависимостей в провайдеры. На практике больших проблем не вызывает, поскольку народ делает это достаточно аккуратно (например, с помощью Paket), так что копипаста не процветает. 6. Generative-провайдеры во время своего выполнения создают настоящую .NET-сборку (которая включает в себя только сгенерированные типы), и отдают эту сборку компилятору в виде массива байтов. Компилятор на своей стороне разбирает эту сборку и копирует типы из неё в результирующий код (который будет включать в себя как сгенерированные типы, так и пользовательский код, к которому этот тайп-провайдер был подключен). Долгое время это создавало проблемы для работы generative-провайдеров в окружениях, в которых нельзя сохранять сгенерированные сборки (.NET Core), и только недавно Дон Сайм перенёс часть кода из компилятора в Type Provider SDK, чтобы окончательно решить эту проблему. В ближайшее время у нас начнут работать все провайдеры под .NET Core.

Простите, если немного разорвал чат :)

Схоронить бы такое куда-нибудь

Ну, в общем, мне показались интересными вот эти разрозненные факты. (Пишу не только для Романа — он-то почти всё это наверняка и так знает, а остальным может быть интересно.) 1. Провайдеры типов — это не фича компилятора F# в чистом виде. У этого механизма есть две части: одна живёт в компиляторе, а вторая живёт в Type Provider SDK (который нужно подключать ко всем создаваемым провайдерам). Можно писать провайдеры, не пользуясь SDK, но это (кажется) сложнее. 2. Существуют т.н. generative и erased-провайдеры. Generative-провайдеры создают настоящие типы, которые потом можно увидеть и из других языков, если подключить к ним F#-сборку. Erased-провайдеры ближе к макросам, поскольку сгенерированные типы и методы заменяются в итоговой сборке на код, который находится внутри них — можно сказать, что они сразу инлайнятся. 3. Забавный факт: изначально провайдеры типов вообще создавались не как механизм, работающий исключительно с F#-кодом. Generative-провайдеры типов появились для того, чтобы код можно было генерировать на других языках, и отдавать нашему компилятору готовые сборки. Подробнее от Сайма тут: https://github.com/Microsoft/visualfsharp/issues/2406#issuecomment-335328819 4. API для generative- и erased-провайдеров почти не отличается — основная часть поведения регулируется одним флагом, который передаётся при создании провайдера. 5. Чтобы написать свой провайдер типов, нужно включить в проект несколько файлов из Type Provider SDK. Не подключить библиотеку, а именно включить файлы — например, скопировав их. Это поначалу кажется весьма неаккуратным, но было сделано специально чтобы не добавлять DLL-зависимостей в провайдеры. На практике больших проблем не вызывает, поскольку народ делает это достаточно аккуратно (например, с помощью Paket), так что копипаста не процветает. 6. Generative-провайдеры во время своего выполнения создают настоящую .NET-сборку (которая включает в себя только сгенерированные типы), и отдают эту сборку компилятору в виде массива байтов. Компилятор на своей стороне разбирает эту сборку и копирует типы из неё в результирующий код (который будет включать в себя как сгенерированные типы, так и пользовательский код, к которому этот тайп-провайдер был подключен). Долгое время это создавало проблемы для работы generative-провайдеров в окружениях, в которых нельзя сохранять сгенерированные сборки (.NET Core), и только недавно Дон Сайм перенёс часть кода из компилятора в Type Provider SDK, чтобы окончательно решить эту проблему. В ближайшее время у нас начнут работать все провайдеры под .NET Core.

Вот, копирование файлов это печально

Хоть на сайт добавляй

#паста

Прямо на статейку для блога тянет.)

Краткую, но полезную.

«шесть ШОКИРУЮЩИХ фактов о провайдерах типов»

О, и название уже есть. ?

@fvnever теперь вопрос - результирующую сборку же можно из c# использовать для генерик провайдеров?

@fvnever теперь вопрос - результирующую сборку же можно из c# использовать для генерик провайдеров?

Да.

@fvnever теперь вопрос - результирующую сборку же можно из c# использовать для генерик провайдеров?

В Generative провайдерах можно

Как все шоколадно

Осталось только вкорячить генерацию типов из метаданных

Хотя вроде sql такие есть провайдеры

Которые dbml жрут

Хоть на сайт добавляй

Было бы куда. :)

Ошибся чатом, прошу прощения

Было бы куда. :)

Ну блог сайту нужен.

@fvnever Я бы еще приправил это описание ссылками. И это действительно достойно статьи.

Ну блог сайту нужен.

Мы на самом деле хотели прикрутить (как в том же ruhaskell сделано — уж больно мне нравится), но просто у нас рук на всё не хватает :(

Вообще, хороша ли идея перенести сайт на какую-нибудь CMS (например, www.orchardproject.net)? Тогда контентом управлять проще будет, наверное. P.S.: Сам с вебом не работаю, но что из себя CMS представляет, более менее в курсе. :)

Там просто готовый движок блога должен быть.

Я думаю, тут даже статически генерируемый блог подойдет.

Вообще, хороша ли идея перенести сайт на какую-нибудь CMS (например, www.orchardproject.net)? Тогда контентом управлять проще будет, наверное. P.S.: Сам с вебом не работаю, но что из себя CMS представляет, более менее в курсе. :)

У нас с @neftedollar есть план запилить простенький движок с публикацией статей из markdown на F#.

Мой персональный бложик (https://github.com/ForNeVeR/fornever.me реклама бесстыдна) уже так и работает.

У нас с @neftedollar есть план запилить простенький движок с публикацией статей из markdown на F#.

Автоматический? Почему не обычный тупой статический блог?

На первое время хотя бы.

Автоматический? Почему не обычный тупой статический блог?

Тупой статический блог на F# ничем не лучше и не хуже динамического блога на F#. Потому что нахаляву генерировать его на тех же github pages всё равно не выйдет — у них там токо Jekyll.

Ну в случае с CMS и пилить ничего не нужно. Вроде как более быстрый вариант. Только там тему сайта настроить.

Тупой статический блог на F# ничем не лучше и не хуже динамического блога на F#. Потому что нахаляву генерировать его на тех же github pages всё равно не выйдет — у них там токо Jekyll.

Не на халяву. Ручками.

Ну то есть мне лично без разницы, можно на FSharp.Formatting сделать генератор и будет ок, я всеми руками «за».

Сгенерировал, залил.

Ну в случае с CMS и пилить ничего не нужно. Вроде как более быстрый вариант. Только там тему сайта настроить.

Охота на F#, это статусное!

Ну то есть мне лично без разницы, можно на FSharp.Formatting сделать генератор и будет ок, я всеми руками «за».

Есть же Fornax.

Сгенерировал, залил.

А вот так я делаю в https://github.com/ForNeVeR/Jabber-Net/tree/develop/docs

Есть же Fornax.

Нормас, берём!

У меня была мысль, что можно CMS на WebSharper сделать. Но чересчур масштабно для одного, да ещё и не веб-разработчика. :)

А материал я перелью, наверное, себе в бложик всё-таки. Была такая мысль. Позже, когда раздел со статьями для fsharplang.ru будем делать, я туда этот материал задоначу :)

Я попробую в свободное время посмотреть Fornax, наверное.

Я попробую в свободное время посмотреть Fornax, наверное.

RFC закончил?

RFC закончил?

Нет.

Нет.

Ленивая задница :)

Ленивая задница :)

Да, давай я тебе делегирую!

Посмотри Fornax. :)

А я еще давно хочу личный блог собрать. Может и мне пригодится в итоге.

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

Сделать тайп провайдер, который генерирует билдеры

Посмотри Fornax. :)

еще можно посмотреть https://github.com/fable-compiler/static-page-generator )

Котрые генерируют фабрики абстрактных классов, с виртуальными методами, позволяющими переопределить реализацию методов интерфейсов, которые эти абстрактные классы реализуют) Больше абстракций богу абстракций)

/шутка)

Java там —----->

Но но - дотнет ван лав.

Больше абстракций богу абстракций- это в яву

да то шутка была, не более)

Сделать тайп провайдер, который генерирует билдеры

Должно быть несложно, учитывая, что это обычные классы с аннотированными методами.

@gsomix Спасибо большое, учту :)

@gsomix Спасибо большое, учту :)

А? Что? Я тут ни при чем.

Ты имел в виду @fvnever?

Кто тут!

@nevoroman я советую к докладу приготовить обстоятельный ответ на вопросы про .NET Core. Сам понимаешь, тема достаточно хайповая, и наверняка про неё спрашивать будут — когда же провайдеры, наконец, под .NET Core заработают :)

@nevoroman я советую к докладу приготовить обстоятельный ответ на вопросы про .NET Core. Сам понимаешь, тема достаточно хайповая, и наверняка про неё спрашивать будут — когда же провайдеры, наконец, под .NET Core заработают :)

так они же в теории уже работает под неткор, а на практике не работают пока нигде потому что Дон приболел =(

так они же в теории уже работает под неткор, а на практике не работают пока нигде потому что Дон приболел =(

Ну вот это и нужно будет ответить, да.

Маленько уже осталось и всё заработает.

На это уже есть отдельный слайд!

Как же, как же без неткора!

Просто это вопрос, который сильно мешает евангелировать за F#. Обязательно найдётся кто-нибудь, кто знает про проблемы с неткором (или просто добросовестно интересуется), и будут неудобные вопросы!

Но теперь уже удобные, ха :)

Главное, чтобы не было неудобных ответов

Да, это верно.

Вот да

С моей точки зрения, важен не столько неткор, сколько интеграция с тем же с#

Неудобные вопросы - это нормально, это вообще одна из целей доклада

С моей точки зрения, важен не столько неткор, сколько интеграция с тем же с#

Да тут все понятно, generative интегрируются, erased - увы

Еще вопрос - интеграция всего этого добра в билд систему

Вернее, erased могут работать в F# либе, но использовать типы в C# коде нельзя

В теории можно, но через рефлексию

Можно (пытаться) использовать то, что из них получится :)