Рубрика «V8» - 5

I. Возможности

Когда я прочитал на MDN про String.raw(): «The static String.raw() method is a tag function of template literals, similar to the r prefix in Python or the @ prefix in C# for string literals» — я здорово обрадовался, потому что мне часто не хватало в JavaScript чего-то вроде одиночных кавычек в Perl.

Я сразу придумал несколько видов использования и стал активно применять их в скриптах.

1. Определение путей к файлам Windows без двойного экранирования.

const r = String.raw;

const test_module = require(r`e:DOCprgjsnode-libtest.js`);

2. Определение путей к ключам реестра Windows.

const r = String.raw;

const Winreg = require('winreg');

const regKey = new Winreg({
  hive: Winreg.HKCU,
  key: r`SoftwareMPC-HCMPC-HCSettings`
});

3. Создание сложных регулярных выражений из составных литералов.

См. пример кода в одной из недавних статей.

II. Ограничения

Однако со временем я стал натыкаться на неожиданные ограничения. Написав об одном из них в багтрекер V8, я получил отрезвляющее объяснение. Оказывается, хоть String.raw и выдаёт строку без интерпретации экранированных литералов, на стадии парсинга кода анализатор всё равно требует, чтобы литералы соответствовали правилам. Из этого следуют неочевидные ограничения для упомянутых случаев применения. Читать полностью »

С выходом Node.js 6.0 мы из коробки получили готовый набор компонентов для организации честного DI. В данном случае я имею в виду DI, который пытается найти и загрузить нужный модуль только в момент запроса его по имени и находится в глобальной области видимости для текущего модуля, при этом не вмешиваясь в работу сторонних модулей. Написано по мотивам статей Node.JS Избавься от require() навсегда и Загрузчик модулей для node js с поддержкой локальных модулей и загрузки модулей по требованию.

Данная статья носит больше исследовательский характер, а ее целью является показать особенности работы Node.js, показать реальную пользу от нововведений ES 2015 и по новому взглянуть на уже имеющиеся возможности JS. Замечу, что этот подход опробован в продакшене, но все же имеет несколько ловушек и требует вдумчивого применения, в конце статьи я опишу это подробнее. Данный DI может легко использоваться в прикладных программах.

Читать полностью »

1. C чего всё началось

Недавно у меня возникла необходимость написать очередную утилиту, обрабатывающую текстовый файл в формате, похожем на упрощённый BBCode, а именно в формате исходников для словарей ABBYY Lingvo — DSL (Dictionary Specification Language). (Не путать с другим DSL (Domain-specific language) — интересный случай, когда гипоним является омонимом к гиперониму).

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

Одной из задач утилиты было как раз нахождение этих тегов с исключением экранированных сочетаний.

Поскольку в регулярных выражениях JavaScript с недавнего времени можно пользоваться lookbehind assertions (в личных целях), я подумал, нельзя ли реализовать поиск при помощи этого средства, — тем более что в данной разновидности lookbehind можно использовать выражения переменной длины. Читать полностью »

Регулярные выражения в JavaScript понемногу догоняют PCRE.

Недавно упомянутая возможность lookbehind перешла на стадию флага --es_staging.

Разработчики V8 также начали добавлять в регулярные выражения свойства Юникода (см. общее описание и спецификацию этой характеристики символов).

В продвижении lookbehind и character properties, на мой взгляд, есть две разницы: первая возможность вводит совсем немного нового синтаксиса по сравнению со второй, зато вторая меньше изменяет поведение всего процесса (сравните количество затрагиваемых изменениями файлов в исходниках V8 по двум упомянутым ссылкам). По сути, свойства Юникода — всего лишь удобные сокращения, синонимы для разных групп codepoint-ов, поэтому от них можно ожидать минимум подвохов при интеграции в систему.

Конечно, обе возможности не советуют применять в продукции (кроме Google Chrome, они нигде в браузерах не реализованы, а Node.js только-только переходит на соответствующую им версию V8, в которой они всё равно пока под флагами).

Но для личных нужд (утилиты по обработке текста и т.д.), мне кажется, они вполне применимы. Возможно, коду разработчиков V8, даже экспериментальному, можно порой доверять с ничуть не большим риском, чем разнообразным библиотекам на npmjs или GitHub.Читать полностью »

Кажется, прошла незамеченной хорошая новость.

Разработчики V8 активно взялись за добавление lookbehind assertions в регулярные выражения JavaScript.

Несмотря на уверения в последнем абзаце статьи, я не смог проверить эту возможность в Google Chrome Canary.

Но.

В этом месяце выходит шестая версия Node.js, основанная на V8 5.0, и в ней уже можно включить поддержку lookbehind при помощи флага командной строки --harmony_regexp_lookbehind.

Если совсем не терпится, можно потестировать на последней ночной сборке шестой версии (она, правда, старовата, месячной давности, но в неё включена V8 4.9, где как раз появилась поддержка lookbehind). Для Windows можно даже просто скачать портабельные бинарники из папок win-x64 или win-x86. Читать полностью »

Вот весь код: var x = []; x[0x7fffffff]=1; JSON.stringify(x);

Для желающих попробовать: jsfiddle

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

Самое примечательное в этом то, что зависание происходит на уровне нативного кода функции JSON.stringify, что не позволяет прервать выполнение в том же firefox'е, как это обычно бывает при простом while(true);.

При выполнении внутри WebWorker'а в chrome, страница продолжает отвечать, но terminate не может завершить поток.

Так же по понятным причинам, такой код не обнаруживается jslint'ом.

Читать полностью »

Google, Microsoft и Mozilla на этой неделе синхронно выпустили экспериментальные билды браузеров с поддержкой WebAssembly (wasm) — эффективного низкоуровневого языка программирования, выполняющегося в браузере с производительностью гораздо выше, чем у самых современных и скоростных компиляторов JavaScript.

Разработчик из Mozilla Люк Вагнер рассказал на Mozilla Hacks о преимуществах WebAssembly, а также сообщил о портировании на WebAssembly научно-фантастического шутера Angry Bots. Демка запускается в браузерах с поддержкой WebAssembly — это последние версии Chrome Canary, Firefox Nightly и Microsoft Edge. Скоро к ним присоединится Safari на WebKit.
Читать полностью »

Как уже сообщалось ранее, Microsoft сделал пулл реквест с добавлением поддержки открытого JS-движка Chakra собственной разработки в Node.js. Разработчики Microsoft предложили сделать весьма спорное изменение, что вызвало ожесточенную дискуссию среди участников проекта: звучали обвинения в адрес MS, с последующими блокировками ветки обсуждения, а трезвая критика местами тонула среди чрезмерно восторженных комментариев. И несмотря на то, что пулл реквест до сих пор не был принят, Microsoft получил официальную поддержку сообщества Node.js. Читать полностью »

image

В этом посте изложены советы, как не написать код, производительность которого окажется гораздо ниже ожидаемой. Особенно это касается ситуаций, когда движок V8 (используемый в Node.js, Opera, Chromium и т. д.) отказывается оптимизировать какие-то функции.
Читать полностью »

image

В английском есть такая аббревиатура — TIFU. Привести здесь её точное значение мы не можем, но вы без труда найдёте его в Сети. А после «литературной обработки» TIFU можно перевести как «сегодня я всё испортил». В контексте этого поста данная фраза относится к использованию функции Math.random() в JavaScript-движке V8. Хотя случилось это не сегодня, а пару лет назад. Да и дров я наломал не по своей вине, корень зла таится в самой этой функции.

«Многие генераторы случайных чисел, используемые сегодня, работают не слишком хорошо. Разработчики обычно стараются не вникать, как устроены такие подпрограммы. И часто бывает так, что какой-то старый, неудовлетворительно работающий метод раз за разом слепо перенимается многими программистами, которые зачастую просто не знают о присущих ему недостатках.»

Дональд Кнут, «Искусство программирования», том 2.

Надеюсь, что к концу этого поста вы согласитесь с двумя утверждениями:

  • Мы были идиотами, поскольку использовали генератор псевдослучайных чисел в V8, не понимая его ограничений. И если очень лень, то безопаснее использовать криптографически стойкие генераторы псевдослучайных чисел.
  • В V8 необходима новая реализация Math.random(). Работу текущего алгоритма, кочующего от одного программиста к другому, нельзя считать удовлетворительной из-за слабой, неочевидной деградации, часто встречающейся в реальных проектах.

Хочу подчеркнуть, что сам движок V8 — замечательный продукт и его создатели очень талантливы. Я ни в коей мере не обвиняю их. Просто эта ситуация иллюстрирует, насколько сильно влияют на процесс разработки даже небольшие нюансы.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js