Доступен (http://syntensity.blogspot.com/2011/07/emscripten-14.html) релиз проекта Emscripten 1.4 (http://emscripten.org/), в рамках которого развивается компилятор, способный преобразовать байткод LLVM (http://llvm.org/) в представление на языке JavaScript. Байткод LLVM может быть сгенерирован из исходных текстов на Cи/Си++ при помощи (https://github.com/kripken/emscripten/wiki/Getting-started) компиляторов lvm-gcc и clang, а также из кода на любом другом языке программирования для которого имеется LLVM-фронтэнд. После компиляции на выходе получается скрипт на языке JavaScript, который может быть выполнен внутри web-браузера, используя только штатный JavaScript-движок, без необходимости задействования дополнительных плагинов.Компилятор написан на языке JavaScript, а тестовый фреймворк и управляющая утилита - на языке Python. Код открыт под лицензией MIT. Основной целью разработки является создание инструмента, который бы позволил выполнять код в Web независимо от языка программ...
URL: http://syntensity.blogspot.com/2011/07/emscripten-14.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=31155
Ну зачем, зачем это нужно? Я не понимаю что за агония у всех перенести приложения в барузер. Браузер - это не фреймворк, это программа для просмотра гипертекстовых сообщений.
К сожалению, теперь это фреймворк, а скоро будет ОС.
поиграются и бросят
Мощности современных дескторов вполне достаточно, чтоб не бросили.
Гугл, Майкрософт, прочие гиганты хотят что бы народ торчал в их облаках, соответственно им нужно чтобы весь возможный софт мог запускаться под браузером
Начать паниковать можно будет когда внутри браузера будут запускать программы уровня eclipse, а пока это всё игрушки.
Тогда будет уже поздно паниковать.
> Начать паниковать можно будет когда внутри браузера будут запускать программы уровня eclipse,
> а пока это всё игрушки.http://cloud9ide.com/
Причем в отлмчии от Эклипса не тормозит.
> Начать паниковать можно будет когда внутри браузера будут запускать программы уровня eclipse,
> а пока это всё игрушки.RCP вполне себе в браузере работает - RAP в помощь. Eclipse же там пока ещё никому не понадобился, вот и нет его там ))
> Ну зачем, зачем это нужно?Чтобы убить флеш окончательно, например, там где он еще жив и даже более :)
> для просмотра гипертекстовых сообщений.
С тех пор как в них сделали JS, они несколько более чем просто программа для просмотра. JS - полный по Тьюрингу язык. А тут вы видите результаты ;)
Из практических применений: например, можно грузить картинку/документ в формате не понимаемом браузером/ОС юзера изначально, не доустанавливая сомнительные бинарные плагины, на которые юзеры очень нервно реагируют из-за возможности что это будет вирус. А JS довольно сильно обкушен в взаимодействии с внешним миром - его не так сцыкотно запускать.
Например: не все браузеры понимают jpeg2k, а ставить плагин... хм... ну понятно, да? А что если вам хочется показать юзеру картинку в этом формате?
> С тех пор как в них сделали JS, они несколько более чем просто программа для просмотра. JS - полный по Тьюрингу язык. А тут вы видите результаты ;)мы видим результаты что всё работает через задницу. т.е. скомпилить/переписать/написать с нуля что-то вышло, в общем видимость деятельности наблюдаетсая. Но в мелочах везде мрак. И это не потому, что разработчики таких поделий где-то сильно накосячили, просто у браузера нет достаточного API для реализации нужного функционала. Тут говорят о платформонезависимости, но и это фикция. Зависимость таких приложений от браузера ещё большая чем просто приложения от разных платформ. И самое поганое, что браузеродеятелям никакие стандарты не писаны. И именно по этим причинам никогда ничего нормального из таких изделий не получится.
> мы видим результаты что всё работает через задницу. т.е. скомпилить/переписать/написать
> с нуля что-то вышло, в общем видимость деятельности наблюдаетсая. Но в
> мелочах везде мрак. И это не потому, что разработчики таких поделий
> где-то сильно накосячили, просто у браузера нет достаточного API для реализации
> нужного функционала. Тут говорят о платформонезависимости, но и это фикция. Зависимость
> таких приложений от браузера ещё большая чем просто приложения от разных
> платформ. И самое поганое, что браузеродеятелям никакие стандарты не писаны. И
> именно по этим причинам никогда ничего нормального из таких изделий не
> получится.Gmail-ом пользуется больше людей чем десктопным линуксом. Так что из этого поделие?
Это результат:
1) больших ресурсов, вбитых в разработку GMail (удобно реализованные теги, поиск, хорошая фильтрация спама)
2) доступности приложения из любой точки.Всё это реализуется на базе стандартной пары IMAP-сервер/локальный клиент со свистом (по второму пункту - совершенно не проблема скачать подписанный Гулом бинарь и запустить локально). Гугл пошел другим путём, но это вопрос коммерции. Технически нативный клиент удобнее, шустрее и эргономичнее. Кстати, на плохом канале с GMail хочется повеситься - особенно потому что толком кэшировать уже скачанные сообщения он не желает почему-то.
поваренная соль (NaCl, нейтив клиент от гугла) это всем не похожий проект, а действительно тру вей решения задач из топика.
Не портабилен и не нужен. Даже теоретически.
Что не нужен, я согласен. И не потому что не портабелен. в этом проблемы нет, а не нужен просто как класс таких технологий.
Уже почти портабелен. Запланирован переход на LLVM-байткод, поэтому одно и тоже приложение для Native Client будет и на ARM и на x86 работать. Единственный минус, для браузеров кроме Chrome требует установки плагина.
> Единственный минус, для браузеров кроме Chrome требует установки плагина.Это не минус, это gravest fatal bug. Яваскрипту - не требуется, поэтому так явно перспективнее. Рассказывать 85% юзеров "поставьте пожалуйста наш плагин" - редкостный вид садомазо.
Если это будет рассказывать Гугл, да предложив хоть какую-нибудь плюшку - поставит масса народу. Или если рассказывать не будет, а просто окажется, что в NaCl (т.е. в Хроме) лучше работает какой-нибудь видеочат, но при желании это лечится установкой NaCl где угодно. А там уже по цепочке - подтянутся другие, кто захочет пользоваться (вначале - просто как оптимизирующей опцией), и понеслось. А Яваскрипт имеет ровно одно преимущество - как раз встроенность. Язык сам по себе ужасен - нюансов в нём чуть ли не как в плюсах, писать крайне неудобно и чревато ошибками.
Это уже не натив, а очередное Джава. Вам нужна еще одна Джава в браузере?
Это именно натив код - не jit и не интепретатор. То есть в него с гарантией компилируется (и с нормальным быстродействием работает) любой интерпретатор, к примеру (только слегка модифицированный в плане обращения к системным функциям, которые naCl не предоставляет - но это скорее модификации системных библиотек). Компилируются (и с нормальной скоростью работают) нативные библиотеки - к примеру, шифрование или парсер эффективных бинарных форматов сериализации - что для игр, к примеру, часто важно. И самое главное - его возможности явно ограничены его viewport, он не может как JS лезть куда попало на странице, а выборочный доступ можно дать.
Написано было про PNaCl. Голый NaCl непортабилен.
Да плевать, там сборка аж под три архитектуры (x86, amd64 и arm). От операционки оно не зависит. Так что можно и три бинарника генерить, благо тулчайн это всё из коробки умеет.
Моё мнение - это попытка реализации распределённой, единой среды выполнения кода вне зависимости от ОС и оборудования, т.е. в браузере. Довеском через это протаскивают идею мэйнфреймов за деньги.По факту - это тройная надстройка - Оборудование->ОС->Браузер->JavaScript. Тройная надстройка в попытке привести разрозненную среду к единообразию, путём переписывания огромного количества кода, который со временем будет отброшен, как ненужный и бессмысленный (тормозящий DOOM на P4, для которого достаточно и i386).
Это эволюционное движение, о котором говорил Линус, если я не ошибаюсь. Эволюционное движение к распределённой и единообразной ОС, как среде выполнения программ вне зависимости от географического положения.
Совершенствование на этом - есть уменьшение сущностей и стремление к непротиворечивости и законченности минималистичной и достаточной картине реализации данной задачи.
В определённой степени примером, к чему идёт эта эволюция может быть Plan9 и Inferno.
s/Совершенствование на этом/Совершенствование на этом ПУТИ/
Кто-нить пробовал это?
Интересно как будет выглядеть Hello world! из C++ :)
> Интересно как будет выглядеть Hello world! из C++ :)Совершенно обычно - менять сишный сорец не требуется. Куда интереснее, можно ли из SDLной проги задетектить что мы работаем в браузере и скажем дернуть кастомную JS-функцию, например? Т.е. 2-сторонний I/O "то что было C/C++ <-> JS" :)
чушь. требуется пересборка всех библиотек задействованных в неллоу ворде. Если что-то не соберётся (а такого вообще много), то работать не будет.
> чушь. требуется пересборка всех библиотек задействованных в неллоу ворде. Если что-то не
> соберётся (а такого вообще много), то работать не будет.но сам-то исходник приветмира менять не надо. %-)
это смотря куда твой исходник будет выводить привет. там же написано, что привеи мир на чистых плюсах через потоки работать небудет.
куда куда.. на стандартный ввод!
вывод т.е. :))
чтобы написать в стандартый вывод, нужно заюзать библиотечную ф-ю.
Чето чувствуется какой-то бум по отношению к JS - в последнее время его куда ненадо суют, я считаю что скоро этот бум пройдет...
А вот насчет NaCl - это уже действительно реальная вещь.
а я давно говорю, что JS — новый бэкэнд для компиляторов.
JS ― новый ассемблер =).