Здравствуйте, anonymous, Вы писали:

A>А то, что вы какие-то «Мерседесы» придумали и пытаетесь на них выехать, к делу отношения не имеет.

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

Здравствуйте, Codealot, Вы писали:

A>>А то, что вы какие-то «Мерседесы» придумали и пытаетесь на них выехать, к делу отношения не имеет.
C>Их придумал ты, я только воспользовался твоей же аналогией.

Да ну?

M>>Они убоги, и на их основе «делать компоненты на основе этих примитивов» — это себя не любить.
A>А делать компоненты на чистом WinAPI, например — это любить себя?

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

Здравствуйте, vdimas, Вы писали:

V>Ну и, есть та гарантия, что то, что не является UB в С/C++, не будет являться UB и в бинарнике под WebAssembly.
V>Т.е. указатели и ссылки на локальные переменные — это вполне себе доступные адреса памяти.

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

V>>>В любом случае, в чистом нейтиве бывают только пессимистичные GC, т.е. если в стеке лежат только данные — это даже еще лучше.
DM>>Консервативные? Нет, это не так совершенно.
V>Еще и "совершенно"? ))

Ну, из четырех приходящих на ум языков с GC, компилируемых в нативный код, у трех GC не консервативный сейчас. (Haskell, OCaml, Go)
А ты про какие?

DM>>Если текущий фрейм не в куче, то на него не бывает указателей в WebAssembly.
V>Фреймы стека данных живут в стеке данных, т.е. на куче в исполнении WebAssembly.

Разверни мысль, пожалуйста. У васм апплета есть линейный кусок памяти, там он устраивает себе кучу, туда он может ходить по "указателям". У него также есть стек, над которым оперируют все арифметические и логические инструкции. Он живет отдельно от того линейного массива, у его данных нет "адресов" в том пространстве. Что я упускаю?

Здравствуйте, Mamut, Вы писали:

M>>>Они убоги, и на их основе «делать компоненты на основе этих примитивов» — это себя не любить.
A>>А делать компоненты на чистом WinAPI, например — это любить себя?
M>Нет, конечно. И это, помнится, многих бесило, что встроенных в систему компонентов — полторы штуки, и те убогие. Не знаю, как ситуация с контролами в винде сейчас.

Так вот ситуация та же самая. Поверх примитивов создаются библиотеки компонентов и далее все пишут GUI, используя их. Для браузеров такие библиотеки уже есть, и никому не надо каждый раз делать компоненты, и не любить себя.

Здравствуйте, D. Mon, Вы писали:

DM>Разверни мысль, пожалуйста. У васм апплета есть линейный кусок памяти, там он устраивает себе кучу, туда он может ходить по "указателям". У него также есть стек, над которым оперируют все арифметические и логические инструкции. Он живет отдельно от того линейного массива, у его данных нет "адресов" в том пространстве. Что я упускаю?

У wasm 2 стека.
Первый стек — "обычный", используется как стек возвратов или как стек для внутренних/системных вызовов.
Второй стек — это участок в куче, эдакий рукотворный стек данных.
Используется для аргументов при вызове процедур/ф-ий/методов песочницы.
Стек данных тоже растёт в обратную сторону, но это не принципиально, ИМХО.
Принципиально то, что этот стек живёт в обычной куче и адресуется из кода песочницы.

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

Здравствуйте, D. Mon, Вы писали:

DM>Ну, из четырех приходящих на ум языков с GC, компилируемых в нативный код, у трех GC не консервативный сейчас. (Haskell, OCaml, Go)
DM>А ты про какие?

Как минимум Go нельзя назвать нейтивным языком — каждая программа на Go содержит в себе весь Go рантайм + метаинформацию для GC.
В этом смысле и .Net является "нейтивным" после ngen, но ведь нет.

Здравствуйте, vdimas, Вы писали:

V>Стек данных тоже растёт в обратную сторону, но это не принципиально, ИМХО.

Тут не прав, походу.
Принципиально хотя бы для cdecl с переменным кол-вом аргументов, если охота избежать полного перелопачивания кода CRT.

Здравствуйте, bzig, Вы писали:

C>>Зачем снова городить костыли

B>HTML/CSS довольно стройный подход, неоднократно скопированный на десктопных фрэймворках. Костылями эту связку называть как минимум неумно.

Эммммммммммммм... нет, это именно что костыли. Я буквально на днях напоролся на очередной выверт CSS: нужно отобразить модальный диалог на странице, при этом диалог должен подстраиваться под размер контента — если контента мало, то окно уменьшается под него, если много, то окно масштабируется до максимально разрешённого размера, а внутри появляется прокрутка. Казалось бы — просто добавить свойство max-height? Хрен вам — max-height хоть формально и задаёт максимальную высоту, но для ограничения размера контента может использоваться только height — без вариантов. В результате родился хак: если размер контента становится больше, чем области отображения — то скриптом добавляем стиль "height:100%;" (к существующему max-height:75vh). Костылище. А ведь это обычный layouting, над которым на любом нормальном фреймворке даже задумываться не надо. И такие проблемы возникают постоянно — HTML/CSS просто не предназначен для разработки приложений.

Здравствуйте, Codealot, Вы писали:

B>>HTML/CSS довольно стройный подход, неоднократно скопированный на десктопных фрэймворках. Костылями эту связку называть как минимум неумно.
C>Это крайне жирный подход, из-за которого сейчас уже примитивный список пары десятков комментариев еле ворочается на топовом железе.
Это целиком зависит от разработчика: сделать тормозной интерфейс можно на любом фреймворке.

Здравствуйте, vdimas, Вы писали:

V>Как минимум Go нельзя назвать нейтивным языком — каждая программа на Go содержит в себе весь Go рантайм + метаинформацию для GC.

Тогда и С++ не нативный, там программа содержит рантайм + метаинформацию о типах. Это смешной аргумент.

Здравствуйте, vdimas, Вы писали:

DM>>Разверни мысль, пожалуйста. У васм апплета есть линейный кусок памяти, там он устраивает себе кучу, туда он может ходить по "указателям". У него также есть стек, над которым оперируют все арифметические и логические инструкции. Он живет отдельно от того линейного массива, у его данных нет "адресов" в том пространстве. Что я упускаю?

V>У wasm 2 стека.
V>Первый стек — "обычный", используется как стек возвратов или как стек для внутренних/системных вызовов.
V>Второй стек — это участок в куче, эдакий рукотворный стек данных.
V>Используется для аргументов при вызове процедур/ф-ий/методов песочницы.
V>Стек данных тоже растёт в обратную сторону, но это не принципиально, ИМХО.
V>Принципиально то, что этот стек живёт в обычной куче и адресуется из кода песочницы.

Ну вот смотрю я в спеку и вижу совершенно иное:
https://webassembly.github.io/spec/core/bikeshed/index.html
Куда мне надо смотреть? Как для значения на operand stack получить его memidx? Или для значения в locals из localidx получить memidx?

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Даа? Ну покажи какой объём кода на чистом JS (без всяких дополнительных библиотек) тебе понадобится, чтобы реализовать банальное меню.
НС>Банальное меню можно вообще без JS реализовать.

Эмм, мы же говорим не про сайтики (для них я тебе и без css даже менюшку сделаю, просто выстроив набор ссылок в ряд), а про приложения! Т.е. под меню подразумевается такая вполне себе классическая выпадающая штука, в которой есть такие же выпадающие подменю и т.д. Такое кстати и на больших сайтах тоже иногда встречается, но реально необходимо оно для приложений.

_>>Повторяюсь последний раз:
_>>DOM — это слабенькая GUI библиотека (написанная на C++).
_>>HTML/CSS/JS — это единственный (и кривой) интерфейс к ней.
НС>Т.е. GDI в винде это такая слабенькая GUI библиотека, да?

GDI? Нет конечно, это инструмент для кастомизации существующих в Win32 контролов. А вот уже они — это и есть стандартная GUI библиотека винды, которая просто на порядки мощнее того, что предлагает в этой области HTML5.

_>>Плюс к этому всему, JS — это единственное (и крайне убогое) средство расширения этой библиотеки.
НС>В чем убогое?

Ну JS и сам по себе убог, как язык. Но в данном конкретном вопросе это даже не главное. Тут важнее то, что сами контролы, предоставляемые браузером, написаны не на JS — к ним есть только интерфейс на JS. И в итоге, мы не можем применить к этим контролам даже убогие методы расширения, присущие JS. Т.е. как ни странно, но в данном случае архитектурно было бы лучше, если бы DOM был написан на убогом JS, а не на C++ — тогда бы это ещё можно было расширять более менее стройным образом. Но тогда бы это дико тормозило, так что на такой подход естественно не пошли. В итоге имеем почти не расширяемую GUI библиотеку, предоставляемую браузером.

_>>Потому что ООП подход — это пока лучшее, что придумали в отрасли
НС>Докажи

Угу, сейчас прямо побежал.

_>>Что бы на HTML5 можно было делать приличный GUI (ты же говорил, что это была одна из целей! ), без дополнительных диких библиотек.
НС>Чем тебе мешают библиотеки? И почему в С++ библиотеки тебе не мешают? Почему бы не потребовать контролов от драйвера видеокарты?

Ещё раз и по пунктам? В стандарт C++ входит GUI? Нет. В Vulcan входит GUI? Нет. В HTML входит GUI? Да, правда очень убогий. И на мой взгляд он убогий потому, что авторы стандарта никогда не позиционировали его для GUI.

_>>>>И отсутствует это всё не потому, что там какие-то идиоты сидят, а потому что предназначения HTML другое.
НС>>>Нет, потому что все это прекрасно реализуется прикладным кодом и не нужно дополнительно усложнять и так сверхсложный браузерный движок.
_>>Так вообще всё реализуется прикладным кодом.
НС>Да. И никто не требует реализации контролов от библиотечки для рисования.

Так ты уже определись, для чего предназначен HTML. Для документов или для рисования или для GUI? У тебя прямо столько версий на ходу возникает... )))

_>>Что мы делаем в классических ООП библиотеках? Наследуемся от этого контрола и переопределяем ему функции, отвечающие за требующее коррекцию поведение.
НС>Всяко бывает. В WPF, к примеру, совсем не так.

Ну расскажи, как в WPF расширяются контролы. )

_>>, но в крайне узких рамках. Ну или же мы можем наплевать на стандартный код и написать новый контрол с нуля, на базе div/span/canvas, что требует гораздо больших усилий.
НС>Уверен? И почему именно с нуля? Почему в случае JS нельзя взять готовую библиотеку?

Эм, мы же вообще то как раз и обсуждаем написание таких библиотек и почему внутри них творится адский ужас. Понятно, что если ты возьмёшь топовую библиотечку и свой "hello world" проект (в котором точно не понадобится писать свои контролы, т.к. в библиотечке уже есть всё ходовое), то там код будет простенький и красивый.

Ну а насчёт уверенности в гораздо больших усилиях... А ты точно представляешь себе, что требуется, чтобы написать банальный editbox с нуля (т.е. имея только canvas)? Ну что бы он ни в чём не уступал системному...

Здравствуйте, alex_public, Вы писали:

_>Эмм, мы же говорим не про сайтики (для них я тебе и без css даже менюшку сделаю, просто выстроив набор ссылок в ряд), а про приложения! Т.е. под меню подразумевается такая вполне себе классическая выпадающая штука, в которой есть такие же выпадающие подменю и т.д.

По ссылке такое есть. Недостающие фичи легко добавляются небольшим количеством простого JS.

НС>>Т.е. GDI в винде это такая слабенькая GUI библиотека, да?

_>GDI? Нет конечно

Ну вот и голый HTML тоже нет.

_>Ну JS и сам по себе убог, как язык.

Чем?

_> Но в данном конкретном вопросе это даже не главное.

Данный конкретный вопрос как раз в том чем убог HTML и JS. Но ты с него постоянно хочешь сползти.

_>>>Потому что ООП подход — это пока лучшее, что придумали в отрасли
НС>>Докажи
_>Угу, сейчас прямо побежал.

ЧТД.

_>>>Что бы на HTML5 можно было делать приличный GUI (ты же говорил, что это была одна из целей! ), без дополнительных диких библиотек.
НС>>Чем тебе мешают библиотеки? И почему в С++ библиотеки тебе не мешают? Почему бы не потребовать контролов от драйвера видеокарты?
_>Ещё раз и по пунктам? В стандарт C++ входит GUI? Нет.

При чем тут стандарт С++?

_> В Vulcan входит GUI? Нет. В HTML входит GUI? Да, правда очень убогий.

И? Чем он тебе мешает?

_>И на мой взгляд он убогий потому, что авторы стандарта никогда не позиционировали его для GUI.

Это не ответ. Речь не про замшелые времена NN, а про текущую ситуацию. Чем убог, скажем, Vue?

НС>>Да. И никто не требует реализации контролов от библиотечки для рисования.
_>Так ты уже определись, для чего предназначен HTML.

Язык разметки для движка лейаута.

_> Для документов или для рисования или для GUI?

Современный — и для того и для другого.

_>>>Что мы делаем в классических ООП библиотеках? Наследуемся от этого контрола и переопределяем ему функции, отвечающие за требующее коррекцию поведение.
НС>>Всяко бывает. В WPF, к примеру, совсем не так.
_>Ну расскажи, как в WPF расширяются контролы. )

Долго рассказывать. Гугли про display model, content model, behaviors и т.п.

_>>>, но в крайне узких рамках. Ну или же мы можем наплевать на стандартный код и написать новый контрол с нуля, на базе div/span/canvas, что требует гораздо больших усилий.
НС>>Уверен? И почему именно с нуля? Почему в случае JS нельзя взять готовую библиотеку?
_>Эм, мы же вообще то как раз и обсуждаем написание таких библиотек и почему внутри них творится адский ужас.

Ну так переходи уже к адскому ужасу то. Вы тут с Мамутом уже кучу сообщений с намеками понаписали, а ничего привести в пример не можете.

_> Понятно, что если ты возьмёшь топовую библиотечку и свой "hello world" проект (в котором точно не понадобится писать свои контролы, т.к. в библиотечке уже есть всё ходовое), то там код будет простенький и красивый.

Ровно как и с гуями. Внутри классических контролов еще более суровый ужас. Одна дрисня с invalidate rectangles чего стоит, который рукожопые контролописатели порой даже не реализуют.

_>Ну а насчёт уверенности в гораздо больших усилиях... А ты точно представляешь себе, что требуется, чтобы написать банальный editbox с нуля (т.е. имея только canvas)?

Да. И даже писал. А ты сколько контролов для веба написал? Такой же теоретик как и Мамут?

Здравствуйте, Ops, Вы писали:

_>>и всё работает — никаких знаний JS не надо. Понятно, что это внутри DOM вызывается через вызoв JS функции, и это архитектурно некрасиво и не эффективно. Но с точки зрения разработчика на Питоне, он про это может даже не знать. Ну а эффективнось и Питон...
Ops>Это для wasm? Клево. А с эвентами и исключениями что?

Про исключения не смотрел. А события естественно работают классическим образом (код из их демки):

from js import iodide
button = iodide.output.element('button')
button.textContent = "Click me!"
count = 0
def onclick(evt):
    global count
    if elt.style.backgroundColor == 'rgb(255, 255, 255)':
        elt.style.backgroundColor = '#ffcccc'
        elt.innerText = "I've been changed " + str(count) + " times!"
    else:
        elt.style.backgroundColor = '#ffffff'
        elt.innerText = "I've been changed " + str(count) + " times!"
    count += 1
button.addEventListener('click', onclick)

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

С этим я конечно же согласен... Но думаю что ждать пока все "браузеры" договорятся между собой в комитете wasm придётся очень долго... ))) Поэтому народ предпочитает не ждать, а выкручиваться самим уже прямо сейчас.

Здравствуйте, D. Mon, Вы писали:

V>>Как минимум Go нельзя назвать нейтивным языком — каждая программа на Go содержит в себе весь Go рантайм + метаинформацию для GC.
DM>Тогда и С++ не нативный, там программа содержит рантайм + метаинформацию о типах. Это смешной аргумент.

Мде? ))
Если этот аргумент "смешной", тогда управляемых языков в природе не существует, все нейтивные.
Не нейтивными являются только интерпретируемые...

В общем, сам определись, сначала, прежде чем с окружающими спорить.

Здравствуйте, D. Mon, Вы писали:

DM>Ну вот смотрю я в спеку и вижу совершенно иное:
DM>https://webassembly.github.io/spec/core/bikeshed/index.html

Покажи конкретное "иное".

Здравствуйте, anonymous, Вы писали:

M>>Они убоги, и на их основе «делать компоненты на основе этих примитивов» — это себя не любить.
A>А делать компоненты на чистом WinAPI, например — это любить себя?

Ну вообще говоря в Win32 попроще, т.к. оно заметно мощнее (и функции прорисовки и обработка сообщений). Но в любом случае сделать банальный editbox своими силами будет весьма сложно и там и там. Тут главная разница совсем в другом. Даже если ты программируешь на голом Win32, то для очень многих приложений тебе просто не надо будет создавать свои контролы, т.к. стандартных более чем достаточно (https://docs.microsoft.com/en-us/windows/win32/controls/individual-control-info — где аналог хотя бы этого базиса в DOM?). А вот в браузере стандартных контролов не хватит даже на "hello word" (мы естественно говорим про приложения, а не про сайтики)!

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>В том числе TreeGrid. А еще я TreeGrid писал для винформсов, так что есть с чем сравнить.
M>>Ну и расскажи, насколько прекрасно и удобно вручную бороться с div'ами для отображения даже не самых сложных вещей, когда любой css-reset порушит люые самые лучшие начинания (если только, конечно, не прибивать все гвоздями к пискелям с помощью !important)
НС>Намного проще чем делать TreeGrid на основе стандартных виндовых контролов.

Только вот TreeGrid — это довольно специфическая штука, которая нужна далеко не в каждом приложение. А вот TreeView — это уже гораздо более нужная вещь. И вот "сюрприз", в винде его не надо делать руками, а вот в браузере его даже не в каждой библиотеке найдёшь, не то что в базовом API.

Здравствуйте, D. Mon, Вы писали:

DM>Ну вот смотрю я в спеку и вижу совершенно иное:

Я вижу всё то же:

Conversely, non-address taken values which are usually on the stack are instead represented as locals inside functions. This effectively means that WebAssembly has an infinite set of registers, and can choose to spill values as it sees fit in a manner unobservable to the hosted code. This implies that there's a separate stack, unaddressable from hosted code, which is also used to spill return values. This allows strong security properties to be enforced, but does mean that two stacks are maintained (one by the VM, the other by the compiler which targets WebAssembly)

Хотя и здесь ерунда написана.
Какие узколобые ребятки пишут спеки на webasm, js-фрики заполонили... что они вообще видели в своей жизни, что выродили ТАКОЕ? ))

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

Вот вполне обычный пример:

struct SomeStruct { /* a lot of fields */};

SomeStruct getSomeStruct() {...}
void processSomeStruct(const SomeStruct & value) {...}

...

processSomeStruct(getSomeStruct());

В случае RVO "место" под возвращаемое значение создаётся до вызова getSomeStruct(..), адрес этого "места" де-факто подаётся как аргумент.
Спеки в помоечку... ))