Опубликован (https://github.com/svaarala/duktape/releases/tag/v2.4.0) выпуск JavaScript-движка Duktape 2.4.0 (https://duktape.org/), ориентированного на встраивание в кодовую базу проектов на языке C/C++. Движок отличается компактным размером, высокой переносимостью и низким потреблением ресурсов. Исходные тексты движка написаны на языке Си и распространяются (https://github.com/svaarala/duktape) под лицензией MIT.Код Duktape занимает около 160 kB и потребляет всего 70kB ОЗУ, а в режиме низкого потребления памяти 27kB ОЗУ. Для интеграции Duktape в код на C/C++ достаточно (http://duktape.org/guide.html#gettingstarted) добавить в проект файлы duktape.c и duktape.h, и использовать Duktape API (http://duktape.org/api.html) для вызова функций на JavaScript из кода на C/C++ или наоборот. Для освобождения неиспользуемых объектов из памяти применяется сборщик мусора с финализатором, построенный на основе комбинации алгоритма (https://ru.wikipedia.org/wiki/%D0%A1%D0%... подсчёта ссылок с алгоритмом пометок (Mark and Sweep). Движок применяется для обработки JavaScript в браузере NetSurf (https://www.netsurf-browser.org/).
Обеспечивается полная совместимость со спецификациями Ecmascript 5.1 и частичная поддержка (http://wiki.duktape.org/PostEs5Features.html) Ecmascript 2015 и 2016 (E6 и E7), в том числе поддержка объекта Proxy для виртуализации свойств, типизированные массивы, ArrayBuffer, Node.js Buffer, Encoding API, объект Symbol и т.п. В состав входит встроенный отладчик, движок для выполнения регулярных выражений и подсистема для поддержки Unicode. Также предоставляются специфичные расширения, такие как поддержка сопрограмм, встроенный фреймворк для журналирования, механизм загрузки модулей на основе CommonJS, система кэширования байткода, позволяющая сохранять и загружать скомпилированные функции.
В новом выпуске реализованы (https://github.com/svaarala/duktape/blob/master/RELEASES.rst... новые вызовы duk_to_stacktrace() и duk_safe_to_stacktrace() для получения трассировок стека, duk_push_bare_array() для добавления независимых экземпляров массивов. В число публичных переведены функции duk_require_constructable() и duk_require_constructor_call(). Улучшена совместимость со спецификацией ES2017. Оптимизирована работа с массивами и объектами. В CLI-интерфейс duk добавлена опция "--no-auto-complete" для отключения аводополнения ввода.
URL: https://github.com/svaarala/duktape/releases/tag/v
Новость: https://www.opennet.dev/opennews/art.shtml?num=51220
Мне вот одно интересно, где эти самописные движки реально применяются.
Во-первых, не самописные. Во-вторых, radare2.
Все движки - самописные.
Исключения - только программы, написанные искусственным интеллектом.
Имелось ввиду те которые разрабатывают на коленке, а не гуглами и фаирфоксами.
Вы что эбокситкой умываетесь? Когда научитесь различать суть и иллюзию?
Качество продукта зависит исключительно от профессионализма и добросовестности автора,
а не от его корпоративной принадлежности.
Вот мне и интересно кто пользуется этими продуктами (или велосипедами, как вам хочется), в эпоху электронов на движке хрома)
Я пользовался, когда-то давно, в какой-то поделке, что это вам дает?
И поделка загнулась, именно потому, что не было легковесного движка, а тот что был протух и разложился на атомы
Используют:1. Во встраиваемых системах где основной язык Си
2. Используют в системах развертывания этих же систем
3. Используют в системах тестирования - легко можно написать деяточек асинхронных тестов на базе каких-то сишных библиотек (экономия огромная времени)В целом зависит от стека компании в компаниях где стек Linux почти в любой области может быть использовано.
Конечно много сейчас еще стеков Java и С#, но они все лезут в контейнеры и в Linux.
вот тебе пример использования мною QScriptEngine (текущий нужно протестировать на скорость). Задача ставилась создать бэк для обработки большого кол-ва запросов и расчетов. Бэк писался на сpp, для асинхронных ответов (работа с потоками) применялся epoll. Особенно критичные вычисления писались на с++. для доработки функционала применил движок js. получился очень быстрый бэк с возможностью расширить функционал на js
Это понятно. Вы объясните это манагеру из конторы уровня сотового оператора большой тройки.
Что вот эту прекрасную прогу можно включить в продакшн-среду и ничего не упадет или никто не сольёт данные на сторону. Пробовали такое сделать?
> и ничего не упадетМне кажется, оратор выше требует принести ему на блюдечке _доказательство отсутствия_.
> Это понятно. Вы объясните это манагеру из конторы уровня сотового оператора большой тройки.мне до них дела нет, у меня свои обязанности и компетенции.
мне за травлю чужих тараканов не платят.
Кажется у корпораций собственный мирок и там принадлежность к гуглу действительно может иметь значение (я считаю).
Но не потому, что им важно как работает, людям просто важно найти крайнего (наверное), именно по этому (думаю) в корпорациях процветают (вроде бы) угрёбищные решения All In One втридорога.
Выбирая такое решение можно быть несколько более уверенным в том, что тебя не назначат виноватым за его выбор и положиться на поддержку, а так же одинаковость важна для заменяемости людей.Но если им действительно захочется узнать, сольёт ли кто-то на сторону что-нибудь, а не просто полагаться на авторитеты, то им проще будет провести аудит именно маленькой штуковины.
Это зависит от того кто объясняет в большей степени.
> уровня сотового оператора большой тройки.Те ещё быдло-кодеры. Не поголовно. Но работать туда не надо.
Справедливости ради, такие программы да, могут быть гораздо качественнее, безопаснее и надёжнее гугловых и прочих, но как-никак для написания документации, сопровождения репозиториев и архитектур, форумов для коммунити нужны большие ресурсы (в людях). К тому же коммерцию никто не отменял - помимо того чтобы ему доверился какой-нибудь билайн как сказали выше, довериться должны так же производители популярных фреймворков и ЯП, хостинги и тд.
Но и обратное справедливо - если он станет достаточно популярным и крутым то сможет сам закрутить маховик вот этой всей коммерции и юридической фигни.
А чем это отличается от Гугла? Там так же, человек может взять запилить что-то. Возможно даже в нерабочее время. А тот же Гугл, может потом с ним договориться и завернуть так, якобы это разработка Гугла. Но код пишется конкретным человеком или несколькими. Чем это написанное на коленке, отличается от другого? У того же Гугла, куча проектов с приставкой Beta.
не удивляйтесь если услышите в свой адрес гадкие слова
скайнет, матрица?
я знаю два места в системе где нужен джаваскрипт и где я бы не хотел видеть ни в8 ни спайдерманки:1) правила полисикита. зачем-то пишутся на джаваскрипте.
2) парсинг файлов автоконфигурации прокси-сервера. исторически сложилось так что они на джаваскрипте.
Он мёртвый, к сожалению. Автор не хочет ковырять компилятор и доводить язык до ecma-2018
Ничего, тут недавно Фабри Беллард движок выпустил ...
Что за движек как называеться
> Что за движек как называеться
>мёртвый
>Выпуск встраиваемого JavaScript-движка Duktape 2.4.0тебе не кажется, что здесь что-то не сходится?
Хот фиксит можно хоть сколько времени а 2018 так и не появится.
а зачем?
зачем развиваются яп? ясно, понятно
Ну в данном случае это приведет к большим тормозам и больше размеру. Да и в других языках тоже.
откуда это следует? развитие яп направлено в том числе на уменьшение потребления ресурсов
Для встроенных скриптов это развитие на фиг не нужно. А ducktape - это ж тебе не V8, его дело - обеспечить простенькую автоматизацию.
для встроеных скриптов это как раз нужно - новые старндарты ecma позволяют использовать новые патерны, которые в свою очередь писать более компактный код, а его исполнение более эффективно
Если вам надо хоть какое-то эффективное исполнение - это не к ducktape, а к V8 сотоварищи. И получите ускорение на порядок. А если надо просто воткнуть простой и компактный скриптовый движок - то это, как правило, не о скорости и не о написании хоть как-то сложного кода на этих скриптах. ТАм, по большому счёту, можно (и нужно) не добавлять фичи, а урезать. Вон, в том же lua проблема отнюдь не в недостатке фич (собственно, единственная его беда - некторая инопланетность).
причем тут ускорение? речь идет возможностях языка, внедряемых через новые стандарты, что приводит к возможности более эффективного как написания кода, так и его исполнения без дополнительных затрат на ресурсы. встраиваемость - не обязательно функциональная ограниченность, как раз хотелось бы, например, иметь полную совместимость с современными движками, пусть и засчет более низкой скорости
Зачем делать хотфиксы? Ну хотя бы для того чтобы делать вид что все ОК.
Зачем фиксы - понятно, и они делаются. А вот зачем для встроенного движка поддержка распоследней версии ECMAScript - непонятно. Это ж не вебчик, применение совсем другое.
> А вот зачем для встроенного
> движка поддержка распоследней версии ECMAScript - непонятно. Это ж не вебчик, применение совсем другое.Видимо, по примеру одной системной софтины [не будем называть имен, но название оканчивается на d], от Красной Шляпы.
Там тянется полноценный движок JS от мозиллы, mozjs 60.
> Rules files are written in the JavaScript programming language and interface with[...]
> While the JavaScript interpreter used in particular versions [...] may support non-standard features [...] rules must conform to ECMA-262 edition 5 (in other words, the JavaScript interpreter used may change in future versionsИ вообще, что-то они долго ждут с переходом на Electron. Стесняются наверное :)
Классы там появились вот зачем ж)
к питону можно прикрутить?
К гтк3, чтобы оно перестало жрать по 3гб озу, где qt жрет пару сотен мб, это прикрутить можно?
Этот движок в заббикс 4.2 впилили. Пока до ограничений не дошёл. Работает и ладно