The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Mozilla развивает прослойку для обеспечения переносимости ме..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Mozilla развивает прослойку для обеспечения переносимости ме..."  +/
Сообщение от opennews on 06-Апр-18, 10:08 
Разработчик из команды Mozilla представил (https://hacks.mozilla.org/2018/04/javascript-to-rust-and-bac.../) проект wasm-bindgen (https://github.com/alexcrichton/wasm-bindgen), в рамках которого ведётся разработка прослойки для организации взаимодействия между JavaScript  и кодом, скомпилированным в представление WebAssembly. В текущем виде проект сосредоточен на предоставление связки между языками JavaScript  и Rust, но в будущем ожидается появление поддержки и других языков, включая C/C++.

Wasm-bindgen позволяет из частей на разных языках организовать доступ к строкам, объекткам, классам и прочими структурам. Например,  можно импортировать в Rust функциональность JavaScript, такую как манипуляции с DOM, или наоборот экспортировать функциональность  Rust в JavaScript, такую как классы и функции, обеспечить совместную работу со сложными типами, такими как строки, классы и объекты, несмотря на то, что спецификация WebAssembly предусматривает манипуляцию только с низкоуровневыми числовыми типами (u32, i32,  f32, f64).


URL: https://hacks.mozilla.org/2018/04/javascript-to-rust-and-bac.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=48399

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


4. "Mozilla развивает прослойку для обеспечения переносимости ме..."  –3 +/
Сообщение от Диалектик on 06-Апр-18, 10:56 
Вместо того чтобы наконец запилить аппаратное ускорение видео надмозги из мозиллы который год занимаются прокрастинацией. Печально.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +3 +/
Сообщение от nazarpc on 06-Апр-18, 11:31 
Вы уверены что данным проектом занимается разработчик что разбирается в аппаратном ускорении видео?
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

20. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +3 +/
Сообщение от Аноним (??) on 06-Апр-18, 13:18 
А у них есть разработчик, который разбирается в аппаратном ускорении видео? Как правило, такие разовые задачи ставятся тому разработчику, который есть, а потом уже он разбирается в том, что для этого требуется.
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

30. "Mozilla развивает прослойку для обеспечения переносимости ме..."  –1 +/
Сообщение от Аноним (??) on 06-Апр-18, 20:20 
Есть. В Windows и MacOS X же ускорение работает. Просто в линуксе вместо графической подсистемы иксы.
Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

32. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +8 +/
Сообщение от Аноним (??) on 06-Апр-18, 20:23 
> в линуксе вместо графической подсистемы иксы.

а вместо браузера файрфокс, ага.

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

36. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +/
Сообщение от Афаф on 07-Апр-18, 03:24 
Вам никто не мешает поставить хр... Яндекс браузер
Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

40. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +/
Сообщение от Аноним (??) on 07-Апр-18, 13:39 
> Вам никто не мешает

А вам никто не мешает поставить вейланд.

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

39. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +/
Сообщение от Хряк on 07-Апр-18, 10:08 
в линуксе вместо графической подсистемы иксы.

Были иксы, их выкинули на свалку. А под вейланд они еще сам бройзер не перевели.

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

25. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +/
Сообщение от Anonim (??) on 06-Апр-18, 14:31 
Сейчас тендентиция идёт к тому, что во всех плеерах будет использоваться системный плеер с системными декодерами. Пилить что-то своё, а тем более под каждую железку, глупо.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

29. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +/
Сообщение от Аноним (??) on 06-Апр-18, 18:17 
системный это типа MPV или это типа встроенный в браузер в рамках HTML5 <video> ?
Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

33. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +/
Сообщение от Аноним (??) on 06-Апр-18, 21:34 
А то ещё одной уязвимости в stagefright давно не находили!
Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

43. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +1 +/
Сообщение от irinat (ok) on 08-Апр-18, 18:32 
Правильно. Давайте ныть об этом на локальном веб-сайте. Это ведь так помогает...
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +2 +/
Сообщение от IB on 06-Апр-18, 11:43 
Только я споткнулся глазом о WASM?
Watcom как много в этом слове :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

37. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +/
Сообщение от Валик228 on 07-Апр-18, 07:51 
> Watcom как много в этом слове :)

ничего там нет, в слове этом. компилятор(ы) от Watcom были популярны только под МС-ДОС из-за отсутствия нормальной поддержки 32-битного режима в борланд и МС-овских компиляторах, а так же наличия Дос-екстендера в поставке.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

41. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +/
Сообщение от Аноним (??) on 07-Апр-18, 13:42 
> > Watcom как много в этом слове :)
> ничего там нет, в слове этом. компилятор(ы) от Watcom

... вроде как оптимизировали гораздо лучше, чем микрософтские (про борланд вообще молчу, у них оптимизации были лишь самые базовые).

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

7. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +1 +/
Сообщение от Аноним (??) on 06-Апр-18, 11:48 
А они не хотят таки запилить такую спецификацию WebAssembly, которая бы позволяла обходится без ЖС совсем?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Mozilla развивает прослойку для обеспечения переносимости ме..."  –1 +/
Сообщение от Аноним (??) on 06-Апр-18, 12:06 
ты думаешь оно будет лучше, надежнее и быстрее? Но ведь оно будет тормознее потому что к дуум придется обращаться костылями и глючнее потому что webassembly сборщика мусора нет.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

10. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +3 +/
Сообщение от Аноним (??) on 06-Апр-18, 12:32 
Так он про это и говорит, чтобы уже наконец сделали апи для сборщика мусора и нормально обращение к дом апи, т.к. сейчас надо это всё делать через JS, то есть через те самые костыли
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

9. "Mozilla развивает прослойку для обеспечения переносимости ме..."  –6 +/
Сообщение от Аноним (??) on 06-Апр-18, 12:07 
есть же typescript и 100500 других языков. И webassembly для этого не нужна
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

11. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +3 +/
Сообщение от Аноним (??) on 06-Апр-18, 12:35 
TS - компилируется в жс и в рантайме проблемы JS остаются, всё остальное работает очень медленно и потребляет больше ресурсов
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

18. "Mozilla развивает прослойку для обеспечения переносимости ме..."  –4 +/
Сообщение от th3m3 (ok) on 06-Апр-18, 13:10 
TS - это костыль. В конечном итоге, на выходе все равно js. Уж лучше сразу на js писать.
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

26. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +1 +/
Сообщение от афаф on 06-Апр-18, 15:54 
На моей практике, обычный разработчик при переводе проекта на TS сталкивается с немного меньшим количеством попыток обращения к undefined.

Но этот вебпак, gulp, tslint и прочие сборочные инструменты на крупных проектах так жестко тупят, что хотелось бы их больше никогда не видеть

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

28. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +/
Сообщение от Аноним (??) on 06-Апр-18, 17:56 
Вы просто не умеете их готовить
Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

13. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +1 +/
Сообщение от Анонимусис on 06-Апр-18, 12:50 
это java апплеты и флеш, лол. Но тогда браузер превратится в примитивный wget, а на таком денег не попилишь
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

42. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +/
Сообщение от Аноним (??) on 08-Апр-18, 11:42 
Oracle в 9 версии отказался от аплетов и даже web start (потому что ему Java не нужна). От flash пока не отказались кажется, но пытаются.
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

14. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +/
Сообщение от Crazy Alex (ok) on 06-Апр-18, 12:51 
Хотят. В принципе, описанное - один из шагов.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

15. "Mozilla развивает прослойку для обеспечения переносимости ме..."  –1 +/
Сообщение от имя on 06-Апр-18, 12:57 
это будет очень весело! сейчас жс-хейтеры ноют о тяжелых сайтах (вот в веб2.0 были времена), а потом как они взвоют от неотключаемых бинарных блобов!
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

17. "Mozilla развивает прослойку для обеспечения переносимости ме..."  –1 +/
Сообщение от Аноним (??) on 06-Апр-18, 13:03 
>А они не хотят таки запилить такую спецификацию WebAssembly, которая бы позволяла обходится без ЖС совсем?

ХD. Ты видать очень мало знаешь о Rust. Повесишь внутри функции onclick на элемент.. а Раст его по завершению функции почистил))) или попробуй одну и ту же функцию повесить на разные onclick - компилятор скажет что переменная уже заимствована. Да и область видимости у раста.. не видит переменные вне функции..

Не знаю как этом идти в hrml DOM

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

34. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +1 +/
Сообщение от Ordu email(ok) on 06-Апр-18, 22:35 
> Повесишь внутри функции onclick на элемент.. а Раст его по завершению функции почистил

"его" -- это кого? Элемент? Каким образом этот элемент попал в функцию? Был создан в ней, и никуда не передан? Да, тогда rust его просто удалит. Или может ты передал его в set_onclick? В этом случае, не удалит. Или ты не создавал элемент, а получил его при помощи get_element_by_id? В этом случае ты получишь ссылку на элемент, и будет удалена ссылка на элемент, а не элемент.

> попробуй одну и ту же функцию повесить на разные onclick - компилятор скажет что переменная уже заимствована.

Не скажет. Ты ведь можешь одну и ту же функцию использовать в rust'е штатно из многих мест? Можешь. Почему же нельзя передать эту функцию во много разных мест?

Если это глобальная функция, то правила работы с ней примерно такие же, как правила работы с глобальными const переменными. Если это замыкание... Ну, тут надо уметь работать с замыканиями. Надо открыть соответствующую главу rust book, и прочитать её вдумчиво. Можно ещё порыться в документации к std::sync::Mutex и std::refcell::RefCell, там AFAIR был где-то пример, как можно создавать _много_ замыканий работающих с одними и теми же объектами. Я думаю, это всё же было в Mutex, там вроде был цикл, который создавал тучу потоков, каждый из которых был замыканием, работающим с одними и теми же объектами -- Mutex тут был бы адекватнее, чем RefCell. Но, всё же, каждое замыкание было отдельным объектом, в том смысле, что для каждого создавалось собственное окружение, которое он захватывал в move-семантике. То есть, функция была одна, а замыкания разные.

Все эти сложности с Mutex, RefCell и Arc может и не нужны, если замыкание работает с const переменными, но помимо того, чтобы быть const, они должны ещё жить не на стеке. Либо статически, либо в куче. Но во втором случае возникнет вопрос "когда освобождать память", и поэтому тебе придётся использовать Arc, и делать clone этого Arc'а на каждое замыкание. Если же переменные живут статически, то тут вообще будет не замыкание, а заурядная функция, объявленная при помощи fn, и проблем возникнуть не должно.

> Не знаю как этом идти в hrml DOM

"Не знаю, как с этим идти в html DOM"? Ты это хотел сказать?

Раст ведь очень много чего позволяет. Чего он не позволяет делать, так это глупостей: если ты меняешь переменную из разных мест асинхронно, то будь добр, сделай это так, чтобы не создавать data race.

Чтобы знать как написать safe API к html DOM, надо учиться. Взять и написать что-нибудь на расте. Надо пойти на github, и почитать чужой код. Надо не стесняться нажимать на кнопочку src, рядом с описанием функций в документации: если ты не понимаешь, как такую функцию написать на rust'е, сходи и посмотри. Rust -- это не жабаскрипт, в нём всё же полезно понимать, что там происходит под капотом. Почитай rustonomicon -- там очень подробно обсасывается грань между safe и unsafe, объясняется когда нужен unsafe, и как им пользоваться так, чтобы создавать safe API, и там же объясняется мотивация почему именно так сделано, а не как-то иначе. Можешь ещё поискать в гугле по слова rust+"too many linked lists", это замечательный гайд, который долго обсирает linked list как структуру данных, мотивируя отказ от linked lists в стандартной библиотеке rust'а, а потом создаёт эти linked list в различных вариантах, чтобы объяснить как это можно делать, если первая демотивирующая часть не отвращает от затеи. Демотиватор можно не читать, а вот всё остальное почитать полезно: LinkedList вынуждает решать множество проблем с data race, так что если ты осилишь LinkedList, то тебе никакое дерево DOM уже не будет страшно.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

44. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +1 +/
Сообщение от Ordu email(ok) on 08-Апр-18, 21:41 
> А они не хотят таки запилить такую спецификацию WebAssembly, которая бы позволяла
> обходится без ЖС совсем?

Может и хотят, но пока рано рыпаться. Надо подождать, когда через все эти wasm-bindgen'ы появятся API для разных языков. Вот тогда можно будет оценить накопленный опыт и подумать о том, чтобы создать единый API, поверх которого будут строится эти. Тогда можно будет не просто скопировать жабаскриптовый API, но сделать лучше.

Помимо этого, с этим API ведь есть ещё проблема, что mozilla не может решать такие проблемы в одиночку. То есть может наверное, но не факт, что гуглы всякие пойдут следом и подхватят. Надо сначала обсудить с гуглом и прочими и придти к консенсусу относительно этого API. А это время, во-первых, а во-вторых, надо иметь аргументы, а чтобы иметь аргументы нужен опыт, и тут мы возвращаемся к тому, что ещё не время. Вот когда будет на github'е десяток пристойных сайтов с активным использованием wasm, чтобы можно было пощупать и внутрь заглянуть, вот тогда можно будет о чём-то говорить.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

12. "Mozilla развивает прослойку для обеспечения переносимости ме..."  –7 +/
Сообщение от Диносуслик on 06-Апр-18, 12:38 
Используйте ClojureScript
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "Mozilla развивает прослойку для обеспечения переносимости ме..."  –1 +/
Сообщение от Ne01eX (ok) on 06-Апр-18, 13:02 
Ребята, может кто в курсе - есть ли движок JS, поставляемый отдельно от всего остального и не требующий для сборки стопицот ненужных вещей (autotools или cmake в самый раз)?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

21. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +1 +/
Сообщение от Аноним (??) on 06-Апр-18, 13:26 
> Ребята, может кто в курсе - есть ли движок JS, поставляемый отдельно
> от всего остального и не требующий для сборки стопицот ненужных вещей
> (autotools или cmake в самый раз)?

https://en.wikipedia.org/wiki/JavaScript_engine#Active_projects
JerryScript вроде соответствует.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

22. "Mozilla развивает прослойку для обеспечения переносимости ме..."  –1 +/
Сообщение от Ne01eX (ok) on 06-Апр-18, 13:30 
>> Ребята, может кто в курсе - есть ли движок JS, поставляемый отдельно
>> от всего остального и не требующий для сборки стопицот ненужных вещей
>> (autotools или cmake в самый раз)?
> https://en.wikipedia.org/wiki/JavaScript_engine#Active_projects
> JerryScript вроде соответствует.

Ваще ништяк, всё в цвет! То что нужно, беру. :-D Респект. :-)

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

23. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +4 +/
Сообщение от Аноним84701 (ok) on 06-Апр-18, 13:31 
> Ребята, может кто в курсе - есть ли движок JS, поставляемый отдельно
> от всего остального и не требующий для сборки стопицот ненужных вещей
> (autotools или cmake в самый раз)?

duktape
http://duktape.org/


$ gcc -std=c99 -otest test.c duktape.c -lm
$ ./test
1+2=3

https://mujs.com/
gcc test.c -lmujs


cat test.c
#include <stdio.h>
#include <mujs.h>

int main(int argc, char **argv)
{
        char line[256];
        js_State *J = js_newstate(NULL, NULL, JS_STRICT);
        while (fgets(line, sizeof line, stdin))
                js_dostring(J, line);
        js_freestate(J);
}


Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

24. "Mozilla развивает прослойку для обеспечения переносимости ме..."  –1 +/
Сообщение от Ne01eX (ok) on 06-Апр-18, 13:38 
>[оверквотинг удален]
>         char line[256];
>         js_State *J = js_newstate(NULL,
> NULL, JS_STRICT);
>         while (fgets(line, sizeof line,
> stdin))
>            
>     js_dostring(J, line);
>         js_freestate(J);
> }
>

ducktape - не подходит. :-(
muJS - тоже ништяк, тоже беру.

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

27. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +/
Сообщение от qweo on 06-Апр-18, 16:33 
> есть ли движок JS, поставляемый отдельно от всего остального

А что ты пилишь-то?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

35. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +1 +/
Сообщение от Ne01eX (ok) on 07-Апр-18, 01:53 
Пока только выпиливаю.

Видят боги, я был фанатом продуктов Mozilla Foundation со времён основания Mozilla Foundation. Но настала пора прощаться. :-(

Пока в качестве браузера использую links2, в качестве смотрелки youtube - palemoon, ну а дальше - видно будет. WebKitGTK в последней версии что-то тоже становится жирноват, так что вопрос с нормальным браузером для RTK неожиданно открыт. :-)

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

45. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +/
Сообщение от freehck email(ok) on 09-Апр-18, 09:19 
> Пока только выпиливаю.
> Видят боги, я был фанатом продуктов Mozilla Foundation со времён основания Mozilla
> Foundation. Но настала пора прощаться. :-(
> Пока в качестве браузера использую links2, в качестве смотрелки youtube - palemoon,
> ну а дальше - видно будет. WebKitGTK в последней версии что-то
> тоже становится жирноват, так что вопрос с нормальным браузером для RTK
> неожиданно открыт. :-)

Кстати да, проблема с palemoon, не всё там можно делать. Я было подумал на него перейти с firefox, но выяснилось, что он уже протух сто лет в обед. Например он-лайн платежи через яндекс у меня в palemoon идти отказались.

Лучше, чем links2, считаю -- w3m. У него ещё и обёртка в emacs есть. Но вообще это извращение.

Обидно терять Firefox, столько на него было завязано в workflow. Но с тех пор, как они дропнули свои аддоны, делать ничего не остаётся.

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

31. "Mozilla развивает прослойку для обеспечения переносимости ме..."  –1 +/
Сообщение от Аноним (??) on 06-Апр-18, 20:21 
А, вот теперь ниша раста стала ясна. Через пару лет раст в 95% проектов будет транслироваться в яваскрипт и выполняться на ноде. Ещё через пару лет об этой прослойке между яваскриптом и программистом все забудут и раст превратится в очередной кофескрипт.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

38. "Mozilla развивает прослойку для обеспечения переносимости ме..."  +2 +/
Сообщение от Sfinx (ok) on 07-Апр-18, 07:52 
ага, бесполезная трата времени - создавать каждый раз новую х#рь/язык чтобы оно появилось как еще один npm пакет из сотни строк.
а вообще-то у анонимусов короткая память - первый javascript был сделан в Netscape. То-то чуваки подохр#нели во что он теперь превратился ;) Ну и все уже давно знают чем разницу между микрософтом и царем Мидасом - у царя все, к чему он прикасался, превращалось в золото, а у микрософта в г#вно.. Поэтому тут весьма показателен пример рукож#пого г#внософта, который не только не смог его испоганить своим жскриптом этот эту технологию но и феереично похоронил своего осла, тупо из-за врожденной неспособности скопировать дух языка...
Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру