Здравствуйте, vdimas, Вы писали:
V>>>"Ополовинить" имелось ввиду отрезать снизить почти вдвое надобность в интеропе. I>>А разве .NET Core не убирает вагоны лишних нативных вызовов?
V>Не понял вопроса. V>.Net Core тащит за собой нейтивные либы-обертки, которые компиляются уникально для каждой платформы, предоставляя вызываемому .Net коду унифицированный АПИ платформы.
Именно. Потому дотнету навроде как не надо делать сто вызовов мелких функций из ВинАпи, а вместо этого сделать один вызов этой унифицированой платформы.
Кроме того, куча вещей в Core были переписаны полностью на менеджед, что бы убрать значительную часть нативных вызовов.
Re[38]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
V>Уже попросила ориентироваться только на .Net 5.0, а с выходом LTS .Net 6.1 (скорее всего именно такая версия будет LTS) — и вовсе .Net Standart уйдёт в неподдерживаемое состояние. V>И тогда степень совместимости с .Net Core разработчики Хamarin будут обеспечивать только по своей доброй воле, как грится.
Xamarin-то как раз полностью на 6-й .net переводят в ноябре. Вот c UWP не повезло.
Здравствуйте, Sinclair, Вы писали:
V>>А для моих задач — нет, не дорос еще дотнет. V>>Под линуха свой интероп, под винду свой, под макос свой.
V>>Реализация банального poll по нескольким хендлам в дотнете безобразная — каждый раз создаётся массив в куче, невозможно ожидать в одном списке сокеты и какие-нить eventfd. S>Ну так это же выносится в библиотечку размером в несколько килобайт, которая пилится под основные платформы; а всё остальное — platform independent.
Именно так.
Под каждую такую задачку — отдельная мини-борьба с кроссплатформенностью.
Это был просто один из примеров, который дотнет еще не покрыл.
Я не сомневаюсь, что рано или поздно донет покроет последние дыры, как грится, это просто пример того, что "кроссплатформенность" в своей сути — это умение обыгрывать различия платформ на некоем уровне, давая возможность приложению в целевом уровне оставаться одинаковым для большого кол-ва платформ.
И я именно этим занят плотно примерно с 1998-1999-х годов, как и большинство нейтивных разработчиков.
(последние "чисто виндовые" сишники ушли с арены примерно в середине нулевых, их с тех пор слаборазличимое кол-во)
Просто на Си (даже не С++) инструментарий обыгрывания различий удобнее из-за макропроцесора.
"Удобнее" означает меньше трудозатрат в пересчёте на каждое такое обыгрывание.
Плюс, по правилам велосипедостроения, уже очень мало кто изобретает велосипеды, т.к. эти задачи давно и многократно решены, т.е. стоимость "обыгрывания" порой примерно нулевая.
S>Если не хотите выделять каждый раз массив в куче — велком в Span<T>, и можете его хоть в стеке, хоть в пуле, хоть в куче держать. Делов-то.
Здравствуйте, Ikemefula, Вы писали:
I>Если вы оба про эмуляцию repl
Нет, я про test runner, который покрывает значительную часть потребностей в REPL. REPL, кстати, в шарпе тоже есть, но мало кто пользуется.
I>Скажем, в дебаге не получится добавишь штукенцию вида I>
Здравствуйте, vdimas, Вы писали:
НС>>Ангуляр и Vue это не фронтенд? Или 2 из 3 основных фронтовых фреймворков это никак не вытесняет? V>И какая разница, на чём написаны сами эти фреймворки?
А зачем их написали на TS? Их разработчики какие то мазохисты, идущие поперек волны?
НС>>Вот так новость. V>Угу, многовато новостей для тебя одного. ))
Здравствуйте, alex_public, Вы писали:
V>>Думаю, в пределе это приведёт к тому, что не браузер будет эдакой виртуальной ОС, а именно wasm-машинка, где браузер будет пользоваться сервисами той. _>Вряд ли. Т.е. сервис такой наверняка появится (собственно можно будет из текущего node.js выдрать js и предустановить во все ОС — получится именно такой сервис), но он наверняка будет отдельно от браузера. Потому что у браузера другая модель безопасности, в которой предполагается враждебность запускаемого кода и соответственно максимальная песочница. Т.е. я думаю, что будет параллельное развитие браузерных движков wasm и так сказать системных.
Так всё-равно для каждой страницы запускается независимый экземпляр wasm, вот его и можно запускать из песочницы.
Просто, если прямо по стандарту из wasm торчат прямые выходы на ту же графику, то это может быть один и тот же кроссплатформенный код, которым пользуется как wasm-машинка, так и сам браузер, вот что имелось ввиду.
Т.е., по инженерной логике, коль wasm будет уметь работать вне браузера, будет разумным такой код включить в состав именно wasm, и тогда браузер сможет выступать чем-то вроде клиента к либе, которую представляет из себя wasm-машинка.
Еще это может привести к независимому деплою wasm и браузеров, т.е. они могли бы обновляться независимо.
Разумеется, нейтивной виртуальной машинки не хватало.
А LLVM что-то уж очень медленно набирает жиру, к тому же, это слишком низкоуровневая абстракция, но хочется как в управляемых средах — практически полный слой абстракции от OS.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
V>>>Еще раз, медленно — интероп в C# медленный. V>>>Требуется сокращать его до минимума. S>> Ну вот новые ссылки на функции вполне себе быстрые. https://dev.to/jeikabu/native-code-in-net-5-0-and-c-9-0-39h7
V>Медленные, согласно твоей ссылки — в 6 раз медленее. V>Но это потому что руки у ребят по ссылке кривые, они не в состоянии вычесть общие для всех расходы из тестов. V>Там разница примерно в 17 раз. V>http://www.rsdn.org/forum/flame.comp/8081536.1
Ну вызов дольше на 16 наносекунд. Сам метод занимает 1 миллисекунду. Затраты на вызов в данном случае минимальны.
V>>>А что именно ты проверил? V>>>Создай прямо сейчас в VS2019 приложение из шаблона Xamarin class library. S>> Я создавал Xamarin.Forms там есть поддержка 2.1. Библиотеки независимы от ксамарин или чего еще. Это же .Net Standard!
V>Просто открой студию 2019 прямо сейчас, просто создай проект "Xamarin class library", просто посмотри зависимости. V>Библиотеки зависимы еще как.
Нет там Android ест .NetStandard или .Net Core V>Еще ни разу у меня не получалось гладко привести некий код из .Net Core стандарта в .Net Standart. V>Твои представления о совместимости стандартов не отвечают объективной реальности.
А вот подключил к проекту с
Установил пакет https://www.nuget.org/packages/Microsoft.EntityFrameworkCore/5.0.9https://www.nuget.org/packages/Microsoft.EntityFrameworkCore/5.0.9
у нег в Dependencies 2.1 Ты сам попробуй. И признай ошибку!
V>Ну и, MS прямо сказала, что лавочку .Net Standart-ов будут прикрывать, бо это бардак. V>Уже попросила ориентироваться только на .Net 5.0, а с выходом LTS .Net 6.1 (скорее всего именно такая версия будет LTS) — и вовсе .Net Standart уйдёт в неподдерживаемое состояние. V>И тогда степень совместимости с .Net Core разработчики Хamarin будут обеспечивать только по своей доброй воле, как грится.
Да .Net 6 это и будет стандартом для всех продуктов.
V>>>Пока что на сегодня только в нейтиве на все случаи жизни и есть. V>>>Любой не-нейтив в большинстве своём биндится к нейтивным библиотекам. V>>>А которая оригинальная в не-нейтивных платформах библиотечная функциональность — так её кот наплакал. V>>>Обычно оригинальное обитает в нише поддержки разработки, по понятной причине. S>> Угу. На Java и C# пишут наверное поболее библиоетек и главное используют их!
V>Это ты сейчас серьёзно?
Конечно. Посмотри сколько библиотек на Java и шарпе
S>>Да вначале они так и делали, затем отказались. То же самое и с Java.
V>Никто не думал отказываться. V>Наоборот, в Андроиде к 7-8-м версиям появилось больше нейтива в том же GUI, он стал заметно более отзывчивый, им с тех пор можно пользоваться.
Гуй это отдельная песня. Там нативый апи для всех вариаций. В UWP там аналог COM
S>> Ты давай .Net Standard 2.1 Я что зря время тратил?
V>По-моему, ты ничего не тратил, помимо времени на общение здесь. ))
Угу. То есть создавал пиложения, давал ссылки. Но ты даже для подтверждения своих слов даже пальцем не пошевелил, однако утверждаешь.
Мне вот интересно в чем я не прав? Подтверди свои утверждения ссылками или кодом!
и солнце б утром не вставало, когда бы не было меня
Re[47]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Ангуляр и Vue это не фронтенд? Или 2 из 3 основных фронтовых фреймворков это никак не вытесняет? V>>И какая разница, на чём написаны сами эти фреймворки? НС>А зачем их написали на TS?
Потому что язык удобней, а у тебя какая версия?
В моей практике бывало часть кода на своём DSL, а из него под разные языки генерится.
НС>Их разработчики какие то мазохисты, идущие поперек волны?
Это ты уже споришь, лишь бы спорить, уходя в риторические вопросы. ))
Достаточно нажать F12 и посмотреть, где на сайтах и самих страницах вручную написанные JS-скрипты, а где автогенерённый код.
Еще лучше будет, если при этом включить внимательность и отделить третьесторонние готовые фреймворки от целевого кода клиентской части веб-приложения.
И еще обратить внимание на ID элементов в HTML, бо всякие почти "дотфускаторы"-уплотнители JS тоже порой вручную писанный код доводят до невменяемого состояния.
Ключевое для тех технологий — ID элементов HTML будут автонумерованной абракадаброй.
НС>>>Вот так новость. V>>Угу, многовато новостей для тебя одного. )) НС>Скорее ты опять
Скорее, твои слова расходятся с объективной реальностью.
Было сказано "TS вытесняет JS неактивно", т.е. никто не утверждал, что нет сайтов, написанных на TS.
Но доля их всё еще мала.
А взять сайты и embedded сниппеты от того же гугла — там вообще непонятно, то ли с Dart этот автогенерённый код, то ли с TS, то ли еще с чего.
Здравствуйте, Ikemefula, Вы писали:
I>Потому дотнету навроде как не надо делать сто вызовов мелких функций из ВинАпи, а вместо этого сделать один вызов этой унифицированой платформы.
Теоретически согласен, а по-факту конкретно для IO это не так.
Унутре, например, для асинхронного чтения сокета (даже в самой последней реализации, заточенной под ValueTask-методы) из дотнета унутре вызывается регистрация хенлдера для наследника SocketAsyncEventArgs, затем запуск асинхронной операции.
Т.е., в дотнетную часть вынесено слишком много.
Более того, ручное использование угрёбищного SocketAsyncEventArgs, доступного еще с середины нулевых, всё-равно оказывается эффективней всех новомодных способов, даже которые через VaueTask. ))
Сравнить с node.js, где одна точка входа при инициализации чтения и обратная при получении уже прочтённых данных.
И оба раза пересечение нейтива и VM-среды бесплатное, как в обычных нейтивных вызовах, в отличие от дотнета, где вызов нейтива дорогой, а из нейтива обратно — еще в два раза дороже.
I>Кроме того, куча вещей в Core были переписаны полностью на менеджед, что бы убрать значительную часть нативных вызовов.
А куча, наоборот, была вынесена в нейтив, что слегка ускорило тот же SSL, который сегодня является основной технологией подключения к веб-ресурсам.
В .Net Framework эффективность SSL была ниже плинтуса.
Сейчас тоже всё еще не айс, но я вижу, что ведутся активные работы, т.е. исходники меняются до неузнаваемости от .Net Core 1.x до .Net Core 2.x, до 3.x, до 5.0 и до 6.x
Наверно, это единственный участок .Net Core, который не разрабатывается последовательно, как вся остальная функциональность, а чуть ли не всерьёз пересматривается каждый раз.
(кроме 5.0 -> 6.x, там только вижу добавления к существующей функциональности, но вряд ли нынешняя реализация будет окончательной, т.к. после столь серьезных переделок код обычно попадает в категорию "нового", "сырого" и т.д.)
Здравствуйте, Евгений Акиньшин, Вы писали:
V>>Уже попросила ориентироваться только на .Net 5.0, а с выходом LTS .Net 6.1 (скорее всего именно такая версия будет LTS) — и вовсе .Net Standart уйдёт в неподдерживаемое состояние. V>>И тогда степень совместимости с .Net Core разработчики Хamarin будут обеспечивать только по своей доброй воле, как грится. ЕА>Xamarin-то как раз полностью на 6-й .net переводят в ноябре.
Дай бог.
Тогда это уже будет не Xamarin (т.е. не mono).
Т.е., развели названий на ровном месте.
ЕА>Вот c UWP не повезло.
Ну, дело такое...
Хотя я и ругаюсь на некоторую несовместимость описания GUI Silverlight/WPF/UWP/Xamarin и вот теперь выкатили Win UI 3/.NET MAUI, но в целом портирование проектов с одной технологии на другую позволяет сэкономить тонну уже имеющегося кода, т.е. ситуация не смертельная — старые наработки не пропадут.
Это регистрируется хук для дебага, экспериментов. Можно опрашивать состояние приложения таким же способом, когда меня интересуют не все данные, а только какой то срез.
Re[48]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
НС>>А зачем их написали на TS? V>Потому что язык удобней
Ну то есть фронт таки использует TS, не так ли?
V>В моей практике бывало часть кода на своём DSL, а из него под разные языки генерится.
Репы и ангуляра и vue открыты, можешь проверить свою теорию.
НС>>Их разработчики какие то мазохисты, идущие поперек волны? V>Это ты уже споришь, лишь бы спорить, уходя в риторические вопросы. ))
Внезапно какие то вопросы ко мне образовались? Я вообще то указал на то, что см. видео. И привел доказательства.
V>Скорее, твои слова расходятся с объективной реальностью.
Объективная реальность — 2 из 3 основных фронтовых фреймворка написаны на TS. А Ангуляр даже не написан, а переписан. Что прямо противоречит твоим заявлениям.
V>Было сказано "TS вытесняет JS неактивно"
Нет, было сказано "никак не вытесняет". Вот зачем так глупо пытаться отказываться от своих же заявлений?
V>, т.е. никто не утверждал, что нет сайтов, написанных на TS. V>Но доля их всё еще мала.
Есть подтверждения очередным твоим заявлениям?
V>А взять сайты и embedded сниппеты от того же гугла — там вообще непонятно, то ли с Dart этот автогенерённый код, то ли с TS, то ли еще с чего.
Зато с ангуляром гугловым все понятно.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[42]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ikemefula, Вы писали:
НС>>Можно пояснения что это и зачем? I>Это регистрируется хук для дебага, экспериментов.
А зачем оно в дотнете? Там хук рантайм сам внедряет при необходимости, и не только хук, см. Profiling API. Писать руками инструментальный код — сомнительное достоинство, с REPL оно или без.
I> Можно опрашивать состояние приложения таким же способом, когда меня интересуют не все данные, а только какой то срез.
И в дотнете можно. Но дописывать в код при этом ничего не нужно руками.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[43]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Это регистрируется хук для дебага, экспериментов.
НС>А зачем оно в дотнете? Там хук рантайм сам внедряет при необходимости, и не только хук, см. Profiling API. Писать руками инструментальный код — сомнительное достоинство, с REPL оно или без.
Это для отладки — я хочу в консоль получать кое какие сведения о запросе.
I>> Можно опрашивать состояние приложения таким же способом, когда меня интересуют не все данные, а только какой то срез.
НС>И в дотнете можно. Но дописывать в код при этом ничего не нужно руками.
Это слабенько, нужно иметь заготовки на все случаи жизни.
Re[39]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Serginio1, Вы писали: V>>Медленные, согласно твоей ссылки — в 6 раз медленее. V>>Но это потому что руки у ребят по ссылке кривые, они не в состоянии вычесть общие для всех расходы из тестов. V>>Там разница примерно в 17 раз. V>>http://www.rsdn.org/forum/flame.comp/8081536.1 S> Ну вызов дольше на 16 наносекунд. Сам метод занимает 1 миллисекунду. Затраты на вызов в данном случае минимальны.
У меня в тестах выше безусловный единичный вызов занимает примерно 0.35 наносекунд.
Собсно, в современных процах команды jump/call при отсутствии сброса конвейера бесплатные — автомат проца самостоятельно заранее "изменяет" IP-регистр, делая предвыборку кода.
Сам нейтивный метод тоже занимает несколько наносекунд.
Например, наполнение буфера команд графического драйвера какого-нить Vulkan.
Т.е., там суть работы такая — итерируемся (включая рекурсивно) по сцене, закидываем команды её построения в буфер команд.
Потом отправляем этот буфер (сразу, или частями, для повышения оперативности) драйверу.
На один кадр могут быть миллионы вызовов, в нейтиве это быстро — на миллион вызовов будет что-то 350 микросекунд расходов, а в твойм случае 16 миллисекунд только стоимость самих вызовов, это 60 FPS ограничение сверху еще безо-всякой полезной работы, в нейтиве ограничение на той же сцене будет под 3 тыс FPS.
V>>Просто открой студию 2019 прямо сейчас, просто создай проект "Xamarin class library", просто посмотри зависимости. S> Нет там Android ест .NetStandard или .Net Core
Открой Visual Studio Installer и установи тулчейн под Андроид.
Вот какой пустой проект генерится:
V>>Еще ни разу у меня не получалось гладко привести некий код из .Net Core стандарта в .Net Standart. V>>Твои представления о совместимости стандартов не отвечают объективной реальности. S> А вот подключил к проекту с S>
Почему я должен что-то признавать, если наш продукт, например, поставляемый в виде либы, на Андроиде заведомо не заведётся?
Пока что только винды, линуха и макось.
С Андроидом пока некоторая борьба.
И да, неужели ты всерьёз решил утверждать, что все библиотеки, писанные на дотнете (пусть даже Core) подходят подо все платформы?
Даже которые специализированные для конкретной платформы?
Зачем же тогда нужен Xamarin, если тогда можно было бы пользовать WPF? ))
S>>> Угу. На Java и C# пишут наверное поболее библиоетек и главное используют их! V>>Это ты сейчас серьёзно? S>Конечно. Посмотри сколько библиотек на Java и шарпе
Из них чуть ли не половина — вспомогательных для этих сред, в основном для целей разработки.
А целевых прикладных — тут до нейтива как до Европы раком еще.
Например, Windows.Forms — относительно тонкая обертка над WinAPI User32/GDI и плюсовой либой GDI+.
GTK# — тоже.
Любые GPU-хелперы — тем более, просто генерят код "шейдеров" и отправляют в нейтив.
И т.д. до бесконечности.
Т.е., завернуть, приготовить, упаковать и отправить в некую "черную дыру" (по вашим представлениям), где всё полезное и происходит, собсно.
Re[49]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>А зачем их написали на TS? V>>Потому что язык удобней НС>Ну то есть фронт таки использует TS, не так ли?
Сам с собой решил поспорить?
V>>Это ты уже споришь, лишь бы спорить, уходя в риторические вопросы. )) НС>Внезапно какие то вопросы ко мне образовались? Я вообще то указал на то, что см. видео. И привел доказательства.
Ты пока что продолжаешь косячить — споришь не с моими тезисами, а с голосами в голове.
V>>А взять сайты и embedded сниппеты от того же гугла — там вообще непонятно, то ли с Dart этот автогенерённый код, то ли с TS, то ли еще с чего. НС>Зато с ангуляром гугловым все понятно.
Ангулар — это не готовое приложение, а лишь ср-во для построения оного.
И даже применение Ангулара не требует применения TS в целевом проекте, аналогично с Vue.
Но главное — мне (и не только) скучно спорить со слабым собеседником, который вместо приведения своих данных, которые можно принять за хоть какую-то аргументацию, постоянно требует данных от своего собеседника.
Ты тут в роли попрошайки пока.
ОК, продолжаю кормить крестьян с рук:
Обращаю внимание, что Angular и Angular.js идут одной строкой.
Здравствуйте, Ikemefula, Вы писали:
НС>>А зачем оно в дотнете? Там хук рантайм сам внедряет при необходимости, и не только хук, см. Profiling API. Писать руками инструментальный код — сомнительное достоинство, с REPL оно или без. I>Это для отладки — я хочу в консоль получать кое какие сведения о запросе.
Debugging и Profiling API в дотнете это тоже для отладки. И вывод в лог должен быть не разовой операцией, а постоянной настраиваемой через конфиги фичей. Слышал, к примеру, про open telemetry?
I>>> Можно опрашивать состояние приложения таким же способом, когда меня интересуют не все данные, а только какой то срез. НС>>И в дотнете можно. Но дописывать в код при этом ничего не нужно руками. I>Это слабенько
Что слабенько? Слабенько это закат солнца вручную, который ты продемонстрировал.
I>, нужно иметь заготовки на все случаи жизни.
Какие такие заготовки? О чем ты?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[50]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
НС>>Ну то есть фронт таки использует TS, не так ли? V>Сам с собой решил поспорить?
Нет, с тобой.
V>>>Это ты уже споришь, лишь бы спорить, уходя в риторические вопросы. )) НС>>Внезапно какие то вопросы ко мне образовались? Я вообще то указал на то, что см. видео. И привел доказательства. V>Ты пока что продолжаешь косячить — споришь не с моими тезисами, а с голосами в голове.
КОсячишь пока тут только ты, выдавая раз за разом бред, и прикрывая свои просеры личными нападками.
V>>>А взять сайты и embedded сниппеты от того же гугла — там вообще непонятно, то ли с Dart этот автогенерённый код, то ли с TS, то ли еще с чего. НС>>Зато с ангуляром гугловым все понятно. V>Ангулар — это не готовое приложение, а лишь ср-во для построения оного.
И что?
V>И даже применение Ангулара не требует применения TS в целевом проекте, аналогично с Vue.
Одно время требовало. Сейчас очень рекомендуется.
V>Но главное — мне (и не только) скучно спорить со слабым собеседником
И опять прикрываешь свой просер манерами бомжа. У тебя все собеседники, как я погляжу, херовые. Один ты стоишь весь в белом красивый.
V>Image: cec2b007d6f062695f3fd0b8a7df66ec.png
Ссылка на исследование где? Откуда эти данные, как и когда получены?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[43]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
V>>Это с рождения условие существования. V>>(тут маты, маты, маты...) S>А должны быть ссылки, ссылки, ссылки. Увы.
Кому должны?
V>>Буквально одной извилинкой шевельни — иначе как бы одни и те же программы или либы запросто распространялись что-то под сотню одновременно существующих сегодня независимых пакетных менеджеров и даже несколькими десятками сдохших на сегодня? S>Да я-то шевельнул. Не очень понятно, что имеется в виду под "программа не знает о пакете".
Это одна из практик проектирования ПО, только здесь в области деплоя.
То бишь, конечные библиотеки и программы не должны самостоятельно заботиться о своём обновлении.
Понятно, что в Windows это десятилетиями было не так, отсюда у тебя сложности с пониманием пресловутого unix way.
Но в UWP уже так, а до этого так стало в iOS и Android.
S>В бинаре, понятное дело, никаких следов пакетного менеджера нет.
В виндовых классических Win32 API программах часто сидит собственный/уникальный менеджер пакета, связанный с некоей личной точкой деплоя в сети.
S>А вот с точки зрения сборки и поставки — сейчас собственно "программа" или "библиотека" и есть пакет.
Пакет — это не просто целевые программы/библиотеки, а еще некоторая метаинформация сверху, необходимая пакетному менеджеру.
S>То есть именно он является результатом труда разработчика. Сборка пакета является частью билд-системы, за которую отвечает собсно исходный автор.
Не всегда, вернее, почти никогда.
Ментейнеры линухов собирают свои сборки из многих тысяч программ/библиотек.
И тот факт, что программы "не знают" о пакетах как раз позволяет это делать.
S>Те случаи, когда опакечивание выполняется посторонними, являются частным случаем — просто исходники собственно кода разрабатывает кто-то другой.
Это мейнстримовый случай в никсах чуть ли не от рождения.
S>Т.е. вот я являюсь автором пакета, который сам при сборке зависит от чего-то внешнего — например, исходников, вытащенных из гитхаба или битбакета. Или бинарей, которые уже были кем-то собраны для моей целевой архитектуры, но не оформлены для моего пакетного менеджера.
Поздравляю.
Так какие тебе ссылки дать?
На RPM, Deb, Zypper?
Что-то мне подсказывает, что будь у тебя желание, ты бы мог сам найти произвольное кол-во ссылок на эти темы.
S>Поэтому никакого предусловия типа "автор исходного проекта не знает о пакетном менеджере" нет и быть не может.
Смело, лихо...
Тебе разве в детстве не говорили, что Деда Мороза не существует?
Вот, говорю.
V>>Поэтому на выходе произведение. V>>А задачей пакетных менеджеров отродясь было давать сумму. S>Вы, похоже, не понимаете основную мысль.
В трёх соснах заблудился ты, а не понимаю я? ))
Молодец, чо!
Еще раз (в третий) — в описанной Алексом системе каждая программа/либа тащит с собой свои зависимости.
Неважно, статически или динамически линкованные, в последнем случае тащит их как файлы, копируемые в некую личную для программы директорию.
Это как выполнить dotnet publish — и все зависимости скопировались с твоей программой.
У второй программы dotnet publish опять скопирует зависимости.
...
У десятой аналогично.
Поэтому — произведение.
В классическом unix way зависимости повторно не тащат, поэтому на выходе сумма.
Доходчиво на пальцах объяснил?
==============
Вдогонку — и да, в одной системе могут сосуществовать одни и те же либы разных своих версий.
V>Т.е., там суть работы такая — итерируемся (включая рекурсивно) по сцене, закидываем команды её построения в буфер команд. V>Потом отправляем этот буфер (сразу, или частями, для повышения оперативности) драйверу.
V>На один кадр могут быть миллионы вызовов, в нейтиве это быстро — на миллион вызовов будет что-то 350 микросекунд расходов, а в твойм случае 16 миллисекунд только стоимость самих вызовов, это 60 FPS ограничение сверху еще безо-всякой полезной работы, в нейтиве ограничение на той же сцене будет под 3 тыс FPS.
Нахрена тогда манагед код? Манагед как ты говоришь это скрипты, а тут он пополам с нативным кодом работает
V>>>Просто открой студию 2019 прямо сейчас, просто создай проект "Xamarin class library", просто посмотри зависимости. S>> Нет там Android ест .NetStandard или .Net Core
V>Открой Visual Studio Installer и установи тулчейн под Андроид. V>Вот какой пустой проект генерится:
И где там .NetStandard? там есть TargetFrameworkVersion>v11.0</TargetFrameworkVersion>
а он поддерживает .Net Standard 2.1
V>>>Еще ни разу у меня не получалось гладко привести некий код из .Net Core стандарта в .Net Standart. V>>>Твои представления о совместимости стандартов не отвечают объективной реальности. S>> А вот подключил к проекту с S>>
S>>Установил пакет https://www.nuget.org/packages/Microsoft.EntityFrameworkCore/5.0.9https://www.nuget.org/packages/Microsoft.EntityFrameworkCore/5.0.9 S>>у нег в Dependencies 2.1 Ты сам попробуй. И признай ошибку!
V>Почему я должен что-то признавать, если наш продукт, например, поставляемый в виде либы, на Андроиде заведомо не заведётся? V>Пока что только винды, линуха и макось. V>С Андроидом пока некоторая борьба.
Потому что платформозависимый? Или все таки сделанный под .NetStandard 2.1?
V>И да, неужели ты всерьёз решил утверждать, что все библиотеки, писанные на дотнете (пусть даже Core) подходят подо все платформы? V>Даже которые специализированные для конкретной платформы? V>Зачем же тогда нужен Xamarin, если тогда можно было бы пользовать WPF? ))
Нет поэтому и помечаются как платформозависимые. Часть можно сделать через условную компиляцию.
Поэтому и развивают Xamarin.Forms где тот же гуй один для всех, а реализация для каждой платформы своя.
S>>>> Угу. На Java и C# пишут наверное поболее библиоетек и главное используют их! V>>>Это ты сейчас серьёзно? S>>Конечно. Посмотри сколько библиотек на Java и шарпе
V>Из них чуть ли не половина — вспомогательных для этих сред, в основном для целей разработки. V>А целевых прикладных — тут до нейтива как до Европы раком еще.
Да любые библиотеки начиная от xml,json заканчивая EntityFramework и прочими тяжеловесными продуктами.
V>Например, Windows.Forms — относительно тонкая обертка над WinAPI User32/GDI и плюсовой либой GDI+. V>GTK# — тоже. V>Любые GPU-хелперы — тем более, просто генерят код "шейдеров" и отправляют в нейтив. V>И т.д. до бесконечности. V>Т.е., завернуть, приготовить, упаковать и отправить в некую "черную дыру" (по вашим представлениям), где всё полезное и происходит, собсно.
Там есть апи, и довольно жидкое. А вот EntityFramework там и генерация кода в рантайме и тот же любимый сишниками Sourcecode Generator.
и солнце б утром не вставало, когда бы не было меня
и предустановить во все ОС — получится именно такой сервис), но он наверняка будет отдельно от браузера. Потому что у браузера другая модель безопасности, в которой предполагается враждебность запускаемого кода и соответственно максимальная песочница. Т.е. я думаю, что будет параллельное развитие браузерных движков wasm и так сказать системных.
