Здравствуйте, vsb, Вы писали:
vsb>https://makepad.github.io/makepad/
vsb>Код написан на Rust и скомпилирован в WASM. Интерфейс рисуется на Canvas через WebGL (т.е. никакого HTML, всё включая рендеринг шрифтов и моргание курсора рисуется кодом). Работает действительно быстро.
IE11
cx_webgl.js (10,5) Syntax error.
Могло бы быть альтернативой флешу, но нет, на ослике не работает.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Kolesiki, Вы писали:
K>>Господи, ему что, так никто и не рассказал про Java???????????????
vsb>Куда тыкать, чтобы запустить Java на айфоне?
эээ... в мозг? Хотя постой... разве он есть у владельцев Эппл-продукции?
В моём понимании вещи, производимые в Apple не имеют отношения к повседневной ИТ-технике. Это просто технологические "гаджеты", аксессуары, что-то вроде Vertu — ну то есть он является как бы телефоном (как и айфон), но физически служит не более, чем дорогущей пустышкой. В которой ты ещё и "никто", потому что за тебя там всё уже решили — что тебе инсталлировать, что слушать, как тыкать, как держать... Разве адекватный человек такое купит?
M>>Языки без GC не спешат компилиться в wasm, вы все не поверите, потому что в wasm'е нет поддержки GC
C>Здесь то ли не хватает слов, то ли наоборот есть лишние. Меня всегда поражает, насколько люди нихера не могут выразить свои мысли, а потом негодуют, что их не поняли.
Все слова на месте. Ты сядь. Почитай вдумчиво. Авось, поймешь. Можешь вслух прочитать, это помогает.
Здравствуйте, alex_public, Вы писали:
_>А вот полноценная GUI библиотека, написанная на таких языках как C++ или Rust, и скомпилированная в wasm — это будет совсем другой уровень работы.
Чем отличается полноценная библиотека от неполноценной?
Здравствуйте, alex_public, Вы писали:
_>1. Выбран низкоуровненый байткод (типа llvm), позволяющий писать под него код на любых языках программирования (а не как у апллетов, привязанных к Java).
Под JVM тоде много всяких языков.
_>2. Исполняющей VM создаётся гарантированная песочница, полностью отрезающая wasm код от остальной части исполняющего процесса (в отличие от апплетов с их неадекватными политиками безопасности).
В апплетах точно такая же песочница.
_>3. Это разработка консорциума всех "браузеров", так что по сути это официальный новый стандарт, поддерживаемый всеми современными браузерами на уровне внутренности движка (а не как некий внешний плагин, который ещё ставить отдельно надо, как было у апплетов).
Здравствуйте, Masterspline, Вы писали:
M>Опциональный сборщик мусора, одинаковый для всех языков с GC, которые будут компилироваться в WebAssembly? Маловероятно.
Здравствуйте, Mamut, Вы писали:
M>>>И тогда скорость работы и загрузки будет такая же, как у известных демок на Qt. Магии не существует. V>>Существует кеширование/переиспользование кода (библиотек). M>Оно и сейчас «существует». Как видно, особо не помогает.
Ну так ты вникни.
Если идёт обращение к одному и тому же ресурсу, где расположено некоторое тяжеловесное приложение, то с кешированием ноу проблема — долго грузиться оно будет лишь однажды.
ИМХО, функциональность кеша будут еще допиливать, чтобы кешировать в том числе уже скомпиллированные бинарные образы.
Здравствуйте, vsb, Вы писали:
DM>>Они отделили стек от "памяти", как теперь языкам с GC сканировать стек на предмет указателей? Кажися, это одна из причин, почему языки с GC пока не спешат компилиться в wasm.
vsb>Я думаю, они сделают опциональный сборщик мусора на уровне VM.
У wasm-апплета память — это линейный массив байтов. Про то, как в ней апплет размещает свои объекты, как делает кучу, как освобождает куски и т.д. — VM про это ничего не знает. Где там указатели, а где числа и строки — тоже. Разные нативные языки делают это очень по-разному. При желании можно сделать какой-то GC, который будет управлять такой кучей и знать про ее структуру, но тогда разные языки надо будет специально сильно переделывать внутри, чтобы они могли использовать это фиксированное представление объектов и указателей. Получится как в JVM, когда одни языки (клоны джавы) легко на нее ложатся, а некоторые другие — с большим скрипом.
Здравствуйте, Codealot, Вы писали:
DM>>Они отделили стек от "памяти", как теперь языкам с GC сканировать стек на предмет указателей?
C>shadow stack
Да, пока это первое, что приходит на ум. Но это требует серьезной переделки рантайма для некоторых нативных языков. Реализуемо, просто затратно, еще одно препятствие.
Здравствуйте, Ops, Вы писали:
_>>Идея буквально та же, а вот реализация на порядки лучше: _>>1. Выбран низкоуровненый байткод (типа llvm), позволяющий писать под него код на любых языках программирования (а не как у апллетов, привязанных к Java). _>>2. Исполняющей VM создаётся гарантированная песочница, полностью отрезающая wasm код от остальной части исполняющего процесса (в отличие от апплетов с их неадекватными политиками безопасности). _>>3. Это разработка консорциума всех "браузеров", так что по сути это официальный новый стандарт, поддерживаемый всеми современными браузерами на уровне внутренности движка (а не как некий внешний плагин, который ещё ставить отдельно надо, как было у апплетов). Ops>И чтобы принять необходимость этого, договориться и начать что-то делать в этом направлении понадобилось 20 лет
На самом деле в это время были ещё другие конкурирующие попытки (ActiveX например, Silverlight и т.п.) и пока они ещё были живы, договориться было трудновато. А вот как только их трупики окончательно застыли, то... )))
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>А вот полноценная GUI библиотека, написанная на таких языках как C++ или Rust, и скомпилированная в wasm — это будет совсем другой уровень работы. НС>Чем отличается полноценная библиотека от неполноценной?
Неполноценная — это построенная поверх html+js. ) Ну если это конечно не решение типа прорисовки всего самостоятельно с помощью WebGL.
Здравствуйте, Ночной Смотрящий, Вы писали:
M>>Опциональный сборщик мусора, одинаковый для всех языков с GC, которые будут компилироваться в WebAssembly? Маловероятно. НС>https://github.com/WebAssembly/proposals/issues/16 НС>Без GC не получится дать прямой доступ к DOM, а без этого wasm так и останется очередной реинкарнацией апплетов.
Вообще говоря, если не требуется особое быстродействие (т.е. wasm используется только для того, чтобы привнести на браузерную платформу нормальный язык), то вполне достаточно и не прямого доступа к DOM: https://alpha.iodide.io/notebooks/300/ — может там повыполнять команды в блокнотике слева и будут изменения в DOM справа.
Но на мой взгляд вообще вся эта тема с DOM является тупиковой, в случае если мы обсуждаем реальное приложение (пускай и web), а не просто сайтик. И как раз изначальный обсуждаемый пример отлично это демонстрирует. От браузера требуется только предоставить WebGL поверхность и захват пользовательского ввода, а всё остальное должна делать современная GUI библиотека, без всяких HTML DOM.
Здравствуйте, D. Mon, Вы писали:
_>> например Питон без проблем работает в wasm DM>Интерпретаторам проще. Проще некуда. Это ж просто сишная программа. Сложно нативно компилируемым языкам, которые хотят быть эффективными.
Если требуется именно эффективность, то всё равно не вижу смысла брать что-то помимо C/C++ или Rust (в будущем). А если эффективность не важна, то тогда уж лучше сразу взять Питон, для максимальной скорости разработки. )
Здравствуйте, Masterspline, Вы писали:
M>Kotlin Native вполне себе может в WebAssembly. И там GC (а не просто ARC, как в Swift).
О, спасибо. Только не понял отличия от Свифта. В Kotlin Native тоже подсчет ссылок плюс сборка оставшихся циклов (как в питоне каком). Чтобы стек не сканировать, они указатели на стеке не размещают, а фреймы функций в куче живут, если я правильно понял. В принципе, вполне разумный подход в рамках ограничений wasm. Интересно на скорость посмотреть. Нативный Kotlin Native очень медленный был, намного хуже JVM-ного.
Здравствуйте, vsb, Вы писали:
vsb>https://makepad.github.io/makepad/
vsb>Код написан на Rust и скомпилирован в WASM. Интерфейс рисуется на Canvas через WebGL (т.е. никакого HTML, всё включая рендеринг шрифтов и моргание курсора рисуется кодом). Работает действительно быстро. Размер кода полмегабайта. Для мини-IDE на мой взгляд очень неплохо.
Штука — огонь. Смешивать её и HTML5/Ангула можно? Это же можно напилить часть UI стандартно, а часть через WASM.
M>>Kotlin Native вполне себе может в WebAssembly. И там GC (а не просто ARC, как в Swift).
DM>О, спасибо. Только не понял отличия от Свифта.
GC в Kotlin Native умеет собирать циклические ссылки, а Swift нет.
Насчет скорости. Kotlin Native ориентировали для написания прикладных приложений, в первую очередь как замена Swift на iOS. Там скорость работы не приоритет (в разумных пределах). Поэтому для написания серверных приложений лучше использовать вариант Kotlin JRE. Например, их Ktor, асинхронный клиент и сервер для Web, не умеет работать на сервере в варианте Native, может только клиентом быть, а JRE вариант может быть и сервером и клиентом.
M>>Опциональный сборщик мусора, одинаковый для всех языков с GC, которые будут компилироваться в WebAssembly? Маловероятно.
НС>https://github.com/WebAssembly/proposals/issues/16
НС>Без GC не получится дать прямой доступ к DOM, а без этого wasm так и останется очередной реинкарнацией апплетов.
Спасибо за ссылку. Теперь я понимаю, про какой GC ты говоришь.
