kekekeks
+1
Под айос оно весит 70Мб, а UWP — 3Мб.

Так вы поди на Xamarin его пишете. И в случае с iOS оно внутри себя содержит цельнотянутый Mono-рантайм.

kekekeks
+5
во времена более примитивного BIOS их столько не было

Было-было. Просто в момент массового перехода на EFI биосы за два с лишним десятилетия уже успели стабилизироваться, а тут всё переписывать пришлось.

kekekeks
–1

Если у меня 30К объектов на игровом поле, как их прикажете обсчитывать?

kekekeks
+2

База данных и пинг HTTP, они асинхронны и процессорное время внутри приложения не кушают. А вот код — вполне себе. Полмиллисекунды здесь, полторы там, всё это внутри часто вызываемой процедурки, а потом сервер полностью жрёт 8-ядерный Xeon на сотне пользователей.

kekekeks
+1

Учитывая, что в статье единственная ссылка ведёт на вполне определённый анализатор кода, целью её написания явно является product placement.

kekekeks
+2
Читаемость кода и производительность (мне кажется) в большинстве случаев находятся по разные стороны.

Но данный совет может привести к деградации производительности на несколько порядков (особенно если где-то в конце цепочки else if идёт запрос к базе, а в предыдущих его нет) при весьма сомнительном улучшении читаемости в стиле паскалевского "объявить все переменные в начале процедуры, так всем понятнее будет".

kekekeks
+14

В подходе с "запишите всё в переменные перед условием" есть проблема, если у вас цепочка из else if. Вынос всех этих вычислений до цепочки, во-первых, не всегда возможен, во-вторых, может дать проблемы с производительностью из-за вычисления кучи всего разного, что не потребуется при срабатывании первого условия. И вот второе хорошо видно на вашем же примере из начала статьи.


И эти люди нам пытаются продать анализатор кода.

kekekeks
+1

mkdir до двух букв в MSDOS/Windows зато сократили, не волнуйтесь, хоть где-то справедливость торжествует.

kekekeks
+2
Есть коллекция отпечатков DateTime

А теперь подумайте, что случится при смене системного времени по тем или иным причинам. Для таких целей следует использовать монотонный таймер. В .NET таковым является Stopwatch.

kekekeks
+4

Так они shared source и так раздают чуть ли не кому попало, только NDA подпиши. Для WinCE вообще был в свободном доступе, качай триальный platform builder да смотри.

kekekeks
+1
Для нас в ключе идеи tty-абстракции это означает следующее: когда пользователь хочет запустить эмулятор терминала, XServer обращается к /dev/ptmx с просьбой создать виртуальное устройство /dev/pts/X. Могущественный «мультиплексер» /dev/ptmx любезно делает это, закрепляет файл устройства за экземпляром терминала и … /dev/pts/X занимает место /dev/ttyX, ему назначается драйвер слоя TTY_LINE_DISCIPLINE, его ласково принимает в свои объятия TTY_DRIVER.

XServer ничем подобным не занимается

kekekeks
+1

C Xamarin.Forms работает? С eto.Forms?

kekekeks
+1

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

kekekeks
+5

Раз хром работает, то Skia у вас завелась. Поддержка .NET Core не планируется? А то есть вариант завести дотнетный гуй на полностью опенсорсном стеке.

kekekeks
+8

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

kekekeks
+1

Статья всё же про ANTLR и парсеры, а не про очередной шаблонизатор.

kekekeks
0

Берёте на выбор Mono.Cecil/dnlib/System.Reflection.Metadata и загружаете полученную от Razor-а сборку. Дальше просто анализируете набор импортированых токенов типов и методов, ибо чтобы вызвать хоть что-то, нужно на него сначала сослаться, даже для работы dynamic нужен специальный набор типов и методов, которые можно в белый список не включать.


Временный каталог Razor-у (старому, который не в ASP .NET Core) нужен для сохранения шарповых исходников, которые тот скармливает csc.exe и полученных на выходе dll-ок. Они-то вам и нужны.

kekekeks
+2

Вообще говоря с Razor-ом можно было подружиться посредством верификации перечня подключенных к сборке типов по белому списку. Есть подозрение, что это было бы более простой задачей.

kekekeks
+2

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

kekekeks
+5

Тем более что можно выехать и пользоваться вконтаком из европы.

kekekeks
0

С браузером не сравнивали, но уже сейчас быстрее чем WPF на Windows на определённых сценариях (авалония поверх Direct2D начинается с 1:30).


И такой немаловажный момент. У нас (как во всех нормальных UI-тулкитах) есть виртуализация списков. В браузеры её не завезли и приходится изобретать криво работающие костыли. Соответственно на задачах "показать список на несколько тысяч элементов" работать будет шустрее, а памяти кушать на порядки меньше.

kekekeks
0

Ну у нас есть возможность статической подписки на уже зарегистрированные свойства, примерно вот так.

kekekeks
+1

1) Есть штатная тема, которую можно заменить на свою и в которой можно заменить цвета. Мимикрию под конкретные ОС пока не делали и наврятли будем делать до версии 1.0, если, конечно, не найдётся желающих этим делом заняться.
2) В качестве платного продукта оно бы неплохо зашло на всякого рода встраиваемых устройствах (Avalonia+Linux кушают порядка 100 мегабайт (x86, fbdev, наш каталог контролов в качестве объекта замера) против полугигабайтного аппетита Windows for IoT), а так же в качестве UI для игр. Там наблюдается некоторый голод в плане хорошего UI, так что можно было бы продавать за хорошую цену.

kekekeks
+3

Обычно выкладывают перед следующей конференцией. С декабрьской уже есть на ютубе.

kekekeks
0

#984. Когда определимся с как правильно и смержим — будет доступно в nuget-фиде с ночными сборками.

kekekeks
+1

Да, это явный баг с layout-ом у нас.

kekekeks
0

Я оригинальный CEFGlue использовал в WinForms и в целом был доволен. Порт для авалонии, насколько я знаю, делался по-возможности построчным копированием с WPF. Имеет смысл попробовать его погонять и попинать автора порта, если есть какие-то проблемы. Ну и следует понимать, что сейчас это не коробочное решение, а в какой-то мере конструктор "собери сам". Порт стал возможен только недавно после появления инфраструктуры WritableBitmap.

kekekeks
+1

Что-то с Layout-ом перемудрили. Если сделать вот так, то работает.


<Window xmlns="https://github.com/avaloniaui" Title="Test app" WindowState="Maximized" MinWidth="500" MinHeight="300">
    <Grid Name="MainGrid">
        <Button Content="Button text" VerticalAlignment="Top" HorizontalAlignment="Left" Margin="40,65,0,0" >
            <Border Width="201" Height="65">
                <TextBlock HorizontalAlignment="Center" VerticalAlignment="Center">Button Text</TextBlock>
            </Border>
        </Button>
    </Grid>
</Window>

Пойму, что там именно происходит и заведу issue.

kekekeks
+1

А весь XAML можно привести? Текстом.

kekekeks
+1

Авалония и формы — вещи ортогональные. В том плане, что у нас подход "рисуем всё сами и одинаково" (минус — гуй выглядит не "нативно", частично решается мимикрией через темы), а forms оборачивает нативные контролы (минусы — удачи с вёрсткой макета от дизайнера и весельем с реализацией хоть чего-то сложного или нестандартного для каждой из платформ в отдельности).


Каждый из подходов хорош для своих применений. Так что тут скорее будет интеграция одного с другим, а не наоборот. Причём на Android/iOS уже сейчас есть принципиальная возможность встраивать куски интерфейса на авалонии в forms, нужно только рендереры соответствующие написать. На досуге надо будет заняться

kekekeks
+1

Наша встроенная система работает на базе ReactiveExtensions. Альтернативный механизм биндингов прикручивается примерно так же как и к WPF-написанием этого самого механизма и реализацией соответствующего MarkupExtension.


Что именно имеется ввиду под "подпиской на изменения вызываемым кодом"?

kekekeks
+6

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

kekekeks
+3

Смотря для чего нужны. На десктопе сейчас разве что API для работы со шрифтами не хватает.


У нас пока в планах на 0.6 доделать deferred-рендеринг (который в отдельном потоке), переехать на Portable.Xaml (OmniXAML тормозной очень и хуже поддерживается), сделать нормальный превьювер для *nix-платформ и воткнуть его хотя бы в MonoDevelop, сделать уже наконец генерацию линуксовых пакетов и бандлов для OSX в один клик, сделать бакэнд на базе MonoMac.

kekekeks
+3
В "-vs-binding" мы указали, что Visual Studio должна вызывать задачу "webpack-script" (Которую студия теперь видит, благодаря установленному расширению) каждый раз перед построением проекта.

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


<Target Name="AfterBuild">
    <Exec Command="npm run webpack-script" />
</Target>

См. более полный пример.

kekekeks
0
когда у него за спиной стоят страшные вражины, которые из-за плеча так и палят, какой же там пароль придумывается

Вроде как давно придумали галку "Показывать пароль"

kekekeks
+1

Да есть всякие в шарпе NancyFx и прочая хипстерщина. Но зачем они нужны, если сейчас завезли ASP.NET Core, который покрывает все возможные нужды? Раньше ещё отдельно WebAPI был, но его в основной аспнет интегрировали.

kekekeks
+9

В переводе с "мне-платят-за-1000-знаков" на русский: есть куча убунтоспецифичных-PPA со всяким разным софтом, пакеты из которых на дебиан ставить лучше не пытаться

kekekeks
+1

Вставку по средней кнопке в протоколе Нового Более Лучшего Дисплейного Сервера убрали, кстати. Во всяких федорах её сбоку изолентой прикрутили

kekekeks
+3

Компилятору сиренево, где брать эти типы, в mscorlib или в вашей вручную изготовленной dll-ке. Я так LINQ и async/await на .NET 2.0 заводил.