а, оказывается в "новом" XAML 2009 добавили поддержку generics - https://msdn.microsoft.com/ru-ru/library/ee956431(v=vs.110).aspx

Кажется, тулинг Visual Studio так и не умеет в этот XAML 2009.

Ну то есть эффективно эта часть стандарта — мёртвая.

Кажется, тулинг Visual Studio так и не умеет в этот XAML 2009.

WPF поддерживает XAML 2009 только для некомпилируемых файлов. Надо убрать классы и перевести .xaml из page в resource.

Можно его как персистентное хранилище использовать?

можно только если внутри агента MailboxProcessor выражение let! msg = inbox.Receive() будет единственным асинхронным вызовом. Иначе шедулер может вызвать код агента дважды одновременно в разных потоках.

и в этом случае досвидания консистентность данных

можно только если внутри агента MailboxProcessor выражение let! msg = inbox.Receive() будет единственным асинхронным вызовом. Иначе шедулер может вызвать код агента дважды одновременно в разных потоках.

Спасибо, конечно за такой технический совет. Я правда еще не начал даже вопрос изучать .

у меня MailboxProcessor - очень ненадёжная и непредсказуемая такая штука на практике. Любое предположение о его работе (даже казалось бы самое очевидное), надо подтверждать тестами (как правило сложными), иначе - грабли. Достоинство - намного проще чем akka net

https://github.com/Dolfik1/AvaloniaDSL/blob/master/DSL/Main.fs осталось прописать все варианты - для каждого класса, который есть в ХАМЛе, сделать отдельный "билдер", в котором прописать все его проперти, ивенты и команды, а также все возможные свойства зависимостей, которые могут этот класс расширять, потом прописать все стандартные конверторы. И только псоле этого можно будет засучив рукава садится за реализацию темплейтов разметки, стилей и датабиндинга. Легион индусов в помощь и good luck!

@nevoroman появился интересный вопрос по json type provider. Предыстория: трепался я вчера со своим другом с Брестского Епама, я ему намедне скормил твой прошлогодний доклад. Ему, C# девелоперу понравились тайп провайдеры, он решил подумать, как они ему могу помочь на проде, но упёрся в то, что у них сервак не отправляет некоторые поля, если они пустые, в целях оптимизации. Он вот может сейчас отдать их, а через 10 милисекунд уже не отдавать. ВОПРОС: как поведёт себя в такой ситуации json TypeProvider, когда поля то приходят, то не приходят ?

Я думаю, надо задать json, где все поля указаны, при создании провайдера

Так себе ведет. Но можно локально сохранить "полный" json и обращаться к нему

Но они почти рандомные. Зависят от множества факторов: страна, настройки юзера, наличие контента и т.д

Ну, вообще я не уверен, что это нормальная практика при работе с JSON

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

Тут скорее про оптимизацию пропускной способности

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

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

Smells like bad code

Smells like bad code

+

Неа, это оптимизация, вполне здравая. Сервер не отправляет 100500 пропертей.

Модель данных должна быть одна

если они пустые - зачем их слать?

Другой вопрос, что не все надо отправлять

Неа, это оптимизация, вполне здравая. Сервер не отправляет 100500 пропертей.

Ну так оптимизации часто порождают хреновый код

Ну дык вот, ответ на вопрос - взять полный json

Хотя, мнится мне, парни просто выбрали не тот формат хранения данных

Выглядит как словарь

@nevoroman ну это прожект из Брестского Епама. Можешь поинтересоваться думаю о подробностях и может подготовить чего из этого кейса на дотнексте, мы бы послушали решение для этой задачи. Мне он описал минимально, что бы не спойлерить технические подробности по понятным причинам.

Но, поскольку они не хотят оверхеда

Вот да. Что-то мне подсказывает, что там летают здоровенные словари в JSON, что как-то так себе затея

Как вариант - взять DTO, AutoFixture и сгенерировать полностью заполненный json

То пишут {"a:"b"} вместо {[{Name:"a",Value:"b"}]}

https://github.com/Dolfik1/AvaloniaDSL/blob/master/DSL/Main.fs осталось прописать все варианты - для каждого класса, который есть в ХАМЛе, сделать отдельный "билдер", в котором прописать все его проперти, ивенты и команды, а также все возможные свойства зависимостей, которые могут этот класс расширять, потом прописать все стандартные конверторы. И только псоле этого можно будет засучив рукава садится за реализацию темплейтов разметки, стилей и датабиндинга. Легион индусов в помощь и good luck!

Type provider/T4 + Reflection, не?

@nevoroman ну это прожект из Брестского Епама. Можешь поинтересоваться думаю о подробностях и может подготовить чего из этого кейса на дотнексте, мы бы послушали решение для этой задачи. Мне он описал минимально, что бы не спойлерить технические подробности по понятным причинам.

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

Предпочтительнее первое

@nevoroman хм, мне он говорит, что он часто работает на проектах с такими серверами.

Jser, шоле?

@nevoroman появился интересный вопрос по json type provider. Предыстория: трепался я вчера со своим другом с Брестского Епама, я ему намедне скормил твой прошлогодний доклад. Ему, C# девелоперу понравились тайп провайдеры, он решил подумать, как они ему могу помочь на проде, но упёрся в то, что у них сервак не отправляет некоторые поля, если они пустые, в целях оптимизации. Он вот может сейчас отдать их, а через 10 милисекунд уже не отдавать. ВОПРОС: как поведёт себя в такой ситуации json TypeProvider, когда поля то приходят, то не приходят ?

надо использовать не хелувордный jsonprovider, а нормальную библиотеку сериализации json. напрмиер мою) Объявляешь тип проперти, которой может не быть в ответе сервака, как Optional. Разумная стратегия десериализации для таких типов - None by default. А то, что кому-то там ответ сервера не кошерный, так это не проблема сервера

Vasily виндовсфонщик

и замаринщик по совместимости

Хмм... ну там все ок должно же быть

проблема понятна в целом

Dictionary их спасет мб

В общем вчера пол часа трепались про этот кейс. Я пообещал что спрошу у @nevoroman лично =)

А я тут ничего интересного не отвечу, потому что юзаю провайдеры совсем в других кейсах :)

Мне-то они обычно нужны чтобы поковырять некоторое публичное api/датасет, где таких проблем не бывает

@nevoroman у вас там никакого внутреннего Епамовского чатика нету ? Я могу просто его данные дать, мб он по точнее расскажет кейс, т.к наверное внутри компании вы можете же делиться подробностями продакшена.

Да если ему интересно - пускай пишет, либо во внутреннем линке, либо в обычном скайпе, логин у меня там тот же

хм, как ему написать тогда твои данные?

Ну, по которым он тебя может найти в вашем "внутреннем линке" ?

Имени и фамилии вполне достаточно

Ну, вообще я не уверен, что это нормальная практика при работе с JSON

Уверяю, практика самая обыкновенная. Динамически типизированные клиенты обычно даже вообще не чувствуют разницы между null и undefined, так сказать.

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

А вот это стрёмно, да.

С моей точки зрения - очень спорно использование тайп провайдеров при десериализации

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

По идее должно быть что-то вроде 'TDto->'TSerialized

Я их использую так: беру примеры формируемых документов, строгаю по ним провайдеры (получается местами стрёмно, но мне пофиг), а потом снаружи навешиваю фасад, типизированный уже в нормальных терминах.

И наоборот

А вот TSerialized уже сериализовывать

https://github.com/ForNeVeR/Tesla.Csxcad/blob/develop/Tesla.Csxcad/CsxWriter.fs — вот так, например (преобразовалка из "красивых" типов в провайдеровые)

Точнее, не TSerialized, а некий набор трансформов

А вот это стрёмно, да.

Я именно про "стремно" и говорил :)

Написать такое преобразование намного проще и надёжнее, чем прямое из доменных типов сразу в JSON/XML.

let metals = properties |> Utils.ofType<Metal> |> Seq.map makeMetal |> Seq.toArray let materials = properties |> Utils.ofType<Material> |> Seq.map makeMaterial |> Seq.toArray

Чет жесско

Нормас, там этих пропертей обычно от 10 до 100 штук.

Мне ж это для продакшена, а не для академической красоты :)

копипаста же

В одну функцию же можно свернуть

Можно.

@nevoroman @fvnever скорей всего я может не правильно его понял, и там совсем иначе.

@nevoroman по этому я и говорю, мол обсудите между собой, внутри епама =)

@nevoroman если что, тебе будет писать Евгений Сампир

Окей :)

@nevoroman а ещё я нечайно твой доклад всем, с кем общаюсь из одногруппников скинул. Уж очень меня воодушивил он на подвиги.

Хочется ещё попробовать R провайдер, нужно бы найти для этого время.

https://learn-anything.xyz/programming/programming_languages/f_sharp

:)

Хочется ещё попробовать R провайдер, нужно бы найти для этого время.

Чет напомнило - драмкружок, кружок по фото, а еще и петь охота :)

Кстати моя issue потихоньку двигается: https://github.com/Microsoft/visualfsharp/issues/3141#issuecomment-306186126

Забавно. Обнаружил что в модуле Option появились новые функции. Типа ifElse, defaultValue и много других полезных, а документации по ним не нашел ни в msdn, ни где то ещё.

Не успели написать.

Понятно что документация особо не нужна, но всё же странно.

https://github.com/fsharp/fslang-design/blob/master/FSharp-4.1/FS-1007-additional-Option-module-functions.md

Получается что я F# 4.1 использую. Забавно, вроде третий должен быть. Завтра проверю.

Roman Или ты используешь какую-нибудь библиотеку с расширениями для option.

А в ситуации с документацией ничего странного нет. Пока мы сами не напишем, ее и не будет. :)

Roman Или ты используешь какую-нибудь библиотеку с расширениями для option.

Вроде не подключал ничего.

А в ситуации с документацией ничего странного нет. Пока мы сами не напишем, ее и не будет. :)

Так вроде Майкрософт. Или они уже не настолько саппортят? Проверю на наличие библиотек завтра.

Roman Не, Microsoft нам ничего не должны. Документация у них, кстати, сейчас открытая. https://github.com/dotnet/docs

Roman Не, Microsoft нам ничего не должны. Документация у них, кстати, сейчас открытая. https://github.com/dotnet/docs

Спасибо, я похоже совсем от жизни отстал.

https://learn-anything.xyz/programming/programming_languages/f_sharp

ух ты, а что это такое?

ух ты, а что это такое?

Вводишь что ты изучить хочешь, и он тебе показывает статьи и т.п.

Mind map называется

@Dolfik прикольно

^_^ https://learn-anything.xyz/mathematics/category_theory

А это оно само генерирует ?

Roman Не, Microsoft нам ничего не должны. Документация у них, кстати, сейчас открытая. https://github.com/dotnet/docs

http://www.deepml.net/ не очень приятный API, но выглядит мощно

«compilation to CUDA GPUs» ничоси