У тебя же все женерики при AOT инстанцируются, и будет просто код, со всеми типами подставленными. Дальше компиль может его инлайнить как нужно.

Ну и, да, AOT в полной мере будет работать только для конечного EXE-приложения без плагинов и пр. динамики. Просто так DLL'ку с женерик-определениями классов ты не AOT'нешь.

А при AOT женерики могут работать в точности так же, как темплейты в C++. А там это работает нормально (ну, с точки зрения быстродействия итогового кода, во всяком случае).

Тоесть у нас есть 10 дженерик классов, есть 10 value типов, мы получим 10^2 классов в AOT?

Тоесть у нас есть 10 дженерик классов, есть 10 value типов, мы получим 10^2 классов в AOT?

У тебя реально каждый из 10 классов в программе был использован со всеми 10 value-типами?

Или есть flow анализ аля tree shaking?

Если да, то получим.

Я не знаю, как устроен настоящий AOT в Mono.

Но можем поспекулировать

Насколько я помню, наш настоящий JIT сейчас делает по специализации для каждого value-типа и одну специализацию для всех ref-типов.

Мб value-типы как-то ещё по размерам можно смержить, тут хз. Нужен специалист :)

Насколько я помню, наш настоящий JIT сейчас делает по специализации для каждого value-типа и одну специализацию для всех ref-типов.

Это я тоже слышал, поэитому и спросил про вэлью типы

Или есть flow анализ аля tree shaking?

Вообще, я _слышал_, что .NET Native для UWP-приложений делался при помощи C++-компилятора, так что моя аналогия с темплейтами не случайна. Те же самые методики и должны были применяться, в т.ч. попытки сократить количество лишнего кода (а C++-компилятор в этом хорош).

Из того, что мне на днях встречалось — это https://github.com/amaneureka/AtomOS (ось на C#, натурально).

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

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

Кроме шуток, возьми и багу оформи.

кроме шуток, как это сделать?

Вон, на тревисе-то собирается, судя по всему: https://github.com/amaneureka/AtomOS/blob/master/.travis.yml

кроме шуток, как это сделать?

Заходишь в список багов: https://github.com/amaneureka/AtomOS/issues И создаёшь свой с описанием, что и на какой ОС пробуешь, и какие логи у тебя получаются.

мб и я не с того начал, лол) через пару часов повторю на норм железе, домой пора)

Вон, на тревисе-то собирается, судя по всему: https://github.com/amaneureka/AtomOS/blob/master/.travis.yml

Как оно вообще работает?

Точнее как там C# исполняется?

Ребята, простите, мой лимит компетентности в этом вопросе исчерпан, я не знаю :(

Точнее как там C# исполняется?

https://github.com/amaneureka/AtomOS/wiki/Compiler возможно как-то так

ну можно посмотреть а потом спрашивать. )) там был пример про асинхронный messagebox, ты спросил как такое сделать или нагуглить, я тебе кинул книжку м указанием страницы как это делается

это не то, о чем я говорил

или он будед ждать пока предыдущий вызов функции не отработал?

В тот же файл?

В любом случае, никто никого ждать не будет)

имя файла зависит от времени

а что будет то?

Одновременно писаться в два файла

Если у тебя в этот файл идёт уже запись, то вывалит ошибку

ясно, если имя совпадет, то свалится с ошибкой)

Я не знаю, что здесь происходит, но все выглядит НЕПРАВИЛЬНО

А что находится в line[1] ?

Ожидание завершение таски можно сделать через t.Wait(); в твоём случае

это класс, описывающий линию, подключенную к порту компа

А зачем тебе ждать вообще? Ты не хочешь чтобы одновременно несколько файлов писалось?

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

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

Зачем тогда тебе асинхронная запись

по-моему, стоит пересмотреть описание задачи, которую необходимо реализовать расписать её ещё раз по пунктам это больше половины дела "без внятного ТЗ - результат хз" и всё такое

Зачем тогда тебе асинхронная запись

данные поступают в COM-порт непрерывно, я хочу чтобы не было потерь пакетов, если записываемый файл будет очень большим или запись будет тормозить по какой-то причине

начать с бизнес-логики и проектирования на бумажке

данные поступают в COM-порт непрерывно, я хочу чтобы не было потерь пакетов, если записываемый файл будет очень большим или запись будет тормозить по какой-то причине

Где ты их агрегируешь? Данные. В массиве line? Или только в line[0].

в line

// класс описывающий телефонную линию class Line { //физический номер линии на плате int _portNumber = 0; //байтовый поток public MemoryStream memory = new MemoryStream(); //копия массива для асинхронного сохранения public byte[] SoundArray; //конструктор public Line (int port) { _portNumber = port; } // описание линии данное пользователем public string UserName { get; set; } // установка физического номера линии public int Port { get { return _portNumber; } set { _portNumber = value; } } // есть ли сигнал в линии public bool Signal { get; set; } // прослушивать линию или нет public bool OnLine { get; set; } // набранный, входящий номер public string TelephoneNumber { get; set; } }

Почему тогда у тебя везде в коде захардкодено line[0] ? Если их много.

Ужос

{ get; set; } четыре строчки вместо 0

{ get; set; } четыре строчки вместо 0

Это уже придирки!

{ get; set; } четыре строчки вместо 0

Красота)

Почему тогда у тебя везде в коде захардкодено line[0] ? Если их много.

я пока эксперементирую

Ожидание завершение таски можно сделать через t.Wait(); в твоём случае

но мне не ждать надо, а узнать что таск уже закончился

get { return _portNumber; } set { _portNumber = value; } это тоже не очень

get => _portNumber; set => value;

get => _portNumber; set => value;

Это дело вкуса все, не путай человека

в репозиториях скроллить полотна геттеров и сеттеров не очень доставляет

А что C#7 уже в RTM?

я пока эксперементирую

Опиши полностью сценарий во времени. У тебя есть эти телефоны. Что происходит дальше? Ты ловишь какой-то ивент, выбираешь уже готовую линию (создаешь?) и начинаешь писать в ее стрим? Потом заканчиваешь и хочешь сохранить в файл? В это время может еще раз сработать тот же ивент?

но мне не ждать надо, а узнать что таск уже закончился

t.IsCompleted тогда

в репозиториях скроллить полотна геттеров и сеттеров не очень доставляет

Так-то тут вообще на автопроперти можно поменять.

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

Перфекционисты блин :)

get => _portNumber; set => value;

А что, set => value — это в C# 7 уже так можно?

ERROR: S client not available

Да не, чёт вроде такого нету!

Затралил меня как лалку :(

set => propName = value; есть

ну почти

Ох щи, да, так можно. Правда, решарпер мне там всё красным расцветил %)

Видимо, чуваки из JB сами ещё в C# 7 не разобрались, или впилить поддержку этой содомии не успели.

Так и представляю себе ченжлог решарпера: "R# 2017.1: добавлена содомия"

Видимо, чуваки из JB сами ещё в C# 7 не разобрались, или впилить поддержку этой содомии не успели.

решарпер в 2017 студии вообще отвратительно работает

Ну, блин, она вчера вышла :)

Ок, позавчера.

решарпер в 2017 студии вообще отвратительно работает

хуже то, что нет расширений пока нихуя под решарпер

Я им уже репортил кой-чего про System.ValueTuple.

Предварительная версия (TP3) облачной платформы Azure Stack доступна для загрузки https://blogs.msdn.microsoft.com/rudevnews/2017/03/09/the-preliminary-version-of-azure-stack-is-available-for-download/ Компания Microsoft выпустила последнюю предварительную версию (ТР3) для платформы Azure Stack, которая доступна для загрузки с 1 марта 2017 года. Обновление содержит улучшения в инфраструктуре и настройках безопасности платформы. Кроме того, новые функции позволяют работать даже в местах, где отсутствует подключение к  Azure. Создание инновационных приложений с помощью облачных технологий имеет важнейшее значение для организации,...

Опиши полностью сценарий во времени. У тебя есть эти телефоны. Что происходит дальше? Ты ловишь какой-то ивент, выбираешь уже готовую линию (создаешь?) и начинаешь писать в ее стрим? Потом заканчиваешь и хочешь сохранить в файл? В это время может еще раз сработать тот же ивент?

да, теоретически может, поэтому хочу понять что делать в этой ситуации

да, теоретически может, поэтому хочу понять что делать в этой ситуации

Тогда у тебя асинхронность с обработчика и должна начинаться. Покажи обработчик.

не совсем понимаю, с какого именно обработчика?

Посоветуйте библиотеки для работы с svg. Пробовал Svg.dll/ magick.net, но первая выбрасывает исключение при рисовании в битмэп, а вторая тяжеловата... Сейчас использую msxml.dll для парсинга получаемых от эски "графиков" . Не знает наш одинэсник других вариантов. Добавляю атрибут viewbox и заменяю ширину/высоту стилем css. И сохраняю это обратно в html файл . Извращение то еще. Самое печальное, что как надо отображает это только фаерфокс. Есть вариант вытянуть svg разметку в отдельный файл, но парсить ее всю не хочется. Нужна библиотека

не совсем понимаю, с какого именно обработчика?

каким образом ты понимаешь, что надо что-то писать в мемористрим?

Я что-то пропустил. Зачем вызывать Control.Invoke?

Чтобы не получить cross thread operation not valid

А кто-нибудь работал с azure stack? Сегодня слышал что они в этом году из превью не выйдут.

А кто-нибудь работал с azure stack? Сегодня слышал что они в этом году из превью не выйдут.

а где слышал?

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

а где слышал?

В офисе у нас

Пусть пользователи тестируют. Можно роадмапы проносить.

Пусть пользователи тестируют. Можно роадмапы проносить.

Я думаю, что в данном случае это полезно провайдерам, чтобы к релизу ажура выкатить и свое решение

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

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

так что всякое бывает

Чтобы не получить cross thread operation not valid

ну так доработать под что то подобное

private readonly SynchronizationContext _synchronizationContext = SynchronizationContext.Current; Task.Run(() => { ..... }) .ContinueWith(task => { _synchronizationContext.Post(state => { //тут вызов контролов }, task.Result); });

А ты сидишь и думаешь. Пилить продукт под ажуру (нет кор или вставить очередную долгоожидаемую технологию), ждать релиза, смотреть аналоги или быть готовым к "ой, мы тут в который раз подумали и редизайнили все к hooyam"

У меня сегодня нытье