← All posts tagged JavaScript

OCTAGRAM
JavaScript программирование Смотрю я на свой код шестилетней давности и не узнаю себя
if (nameDivSpanNext.nodeType == 3) {

Почему ==, а не ===, ещё как-то можно понять. Не убедил меня тогда ещё JS-Lint, что всё же двойное грешновато. Но почему не if (3 === nameDivSpanNext.nodeType) ?

Как сейчас помню, учил меня Каменский Никита Викторович в НГУ в птичьих языках программирования на всякий случай при сравнении ставить константу всегда влево. Я так и делаю, на птичьих языках — константа влево, а на нормальных языках — гордо ставлю вправо. НГУ был раньше, чем я писал скрипт. Я как будто забыл, а потом вспомнил. Странно это.
OCTAGRAM
web Java JavaScript CheerpJ как я заметил, уже вышел из закрытых альфа-тестов и находится в бете.

Те же разработчики, что делают Cheerp, транслятор C++ в JavaScript/Asm.js/WASM, делают CheerpJ для Java. Позиционируется он как нормально портированная Java. Никаких ограничений, как в GWT. Поддерживается байт-код. Поддерживаются Swing и Java-апплеты как с оффлайн конвертацией, так и в виде шима. Есть плагин для Хрома.
OCTAGRAM
JavaScript iOS ? Android Дорогой жуйк, мне нужна помощь коллективного разума. Какой движок на JavaScript для мобильных платформ по опыту хороший? Не думал, что буду так интересоваться HTML5, но вот так в уме прикинул, чего стоит один раз запинать asm.js и попасть в каждый умный телевизор, и чего стоит запинать набор компиляторов под разные платформы, и ещё с GUI там пострадать, и подумал, что привязки изнутри asm.js к чему-то HTML5'ному были бы неплохим путём отступления. Будет плюсом, если через какой-нибудь Electron можно на компе запускать и получать осмысленное поведение.

Ангуляр не предлагать, я эту пакость как пользователь едва могу терпеть. SproutCore или что там сейчас у Apple, кто-нибудь видел?
OCTAGRAM
AdaMagic JavaScript RAII ada При преобразовании в C++ адские контролируемые типы проецируются на struct, при этом у них нет ни деструктора, ни перегруженной операции присваивания. Вместо этого компилятор оставляет в локальных контекстах rts_master_record, на которые навешиваются все контролируемые типы. Полагаю, это такое тяжёлое наследие ATC, на который в последних версиях компилятора GNAT, допустим, уже забили. Однако, в браузере, даже если я сам не использую ATC, вдруг то, что я написал, долго работало, и юзер нажал «остановить скрипт» — вот, пожалуйста, случился ATC. И AdaMagic сможет из этого выпутаться, при возврате управления понять, что и где нужно освободить. А на обычных платформах современный GNAT скомпилирует без этих штучек.
OCTAGRAM
web C++ JavaScript emscripten Using C++ classes in JavaScript
Вычитал тут такое:
JavaScript will automatically garbage collect any of the wrapped C++ objects when there are no more references. If the C++ object doesn’t require specific clean up (i.e. it doesn’t have a destructor) then no other action needs to be taken.
Это каким, интересно, образом, движок JavaScript залезет в кучу emscripten и пометит область памяти как неиспользуемую именно тем способом, каким это делает текущая версия аллокатора emscripten
OCTAGRAM
pascal JavaScript DOS Разобрался с JS-DOS
Я думал, он подвисает, а, оказывается, там что–то типа лимита на запущенные программы. Первой программой должен быть mount, второй программой — собственно программа, и если я во встроенном Z:\COMMAND.COM намылился выполнить многострочник, то ничего у меня не получится, после второй программы зависнет, а вот в NDOS.COM можно запихать команд сколько влезет.
Теперь осталось скрестить это с PasteBin (именно поэтому оно сначала компилируется, а потом запускается) и разместить по ключевым словам «Паскаль Онлайн». Страница по таким ключевым словам у меня давно была, на неё неплохо ломятся, только ни во что особенное она не вела.
OCTAGRAM
JavaScript wxwidgets wxWebView не богат на события, а задача состояла в том, чтобы сделать такое приложение, которое, если соблюсти ТЗ, будет состоять из сильно переплетённых нативных и скриптовых частей. Если из натива в скрипт ещё можно что–то посылать через RunScript, то обратно пришлось экспериментировать с EVT_WEBVIEW_NEWWINDOW, и он себя неплохо показал для этих целей. Можно в начале html прописать <base target="_blank" />, и все ссылки и даже формы вместо навигации будут вызывать это событие. Это даже лучше, чем JSONP через wxWebViewHandler
OCTAGRAM
JavaScript HTML IE MSHTA Некоторые факты об mshta.exe:
1. Помешать закрыть окно с не сохранёнными данными при помощи beforeunload не получится. Вопрос вылезет, но что ни отвечай, всё равно закроется. Это известный, признанный Microsoft баг.
2. setAttribute для динамически созданных элементов DOM вообще по боку. Только свойствами можно порулить поведением. Пришлось свои библиотечки адаптировать под эту инопланетную среду. Я всегда считал, что манипуляции с DOM первичны, а всякие свойства типа style — это нечто вроде синтаксического сахара. В mshta.exe всё наоборот.
3. Если checkbox вставляется в другой DOM элемент, его checked обнуляется.
4. Скрипт с type="text/javascript" не запустится
5. Свойства приложения описываются в теге HTA:APPLICATION, но никто не знает, какой URI у пространства имён HTA. Его просто нет, и он рвёт шаблоны зияющей пустотой своего отсутствия.
6. Пока не нашёл работающего способа сделать background-size: cover. Библиотеки, которые должны работать даже в IE7, не могут в mshta.exe
7. Динамически навесить обработчик события, записанный строкой, не получится. Подойдёт только настоящее замыкание.

Есть и положительная сторона. Я давно не видел, чтоб что–то браузерное так быстро работало. Electron такого ощущения не давал.
OCTAGRAM
JavaScript IE Непонятно, почему, но у некоторых клиентов с Internet Explorer всегда срабатывает window.top != window.self без всяких видимых причин. Пытался заменить какой–нибудь другой конструкцией, всё без толку. Понакупят блин Люмий, и чё с ними теперь делать. К несчастью для меня, после катастрофы у FirstVDS я ещё несколько месяцев не смогу разбрасываться людьми. Придётся что–то решать с теми, кто остался.
Ещё я выяснил, что в некоторых IE не работает нормально яндексовский (да и вообще, по Интернету если посмотреть, распространённый) код асинхронной подгрузки скрипта, когда находится самый первый тэг скрипта, и в его родителя перед ним добавляется новый скрипт. Это срабатывает только для первого скрипта, а потом либо управление теряется, либо следующие добавленные таким образом скрипты игнорируются, я так и не понял. Долго искал, может, синтаксическая ошибка. Чувство было, что браузер читает скрипты энным местом. Тут выполняю, а тут не хочу.
Всё обёрнуто в try-catch с уведомлением об очередном приколе, но не тут–то было. И скрипт не грузит, и о проблемах молчит. Мне жалуются, а я понять не могу, как такое может быть. Переделал везде, чтоб добавлялось в конец head. Вроде полегчало.
Причём, в моём IE увиденные в логах приколы не воспроизводятся, хотя я в логах вижу странное поведение даже у идентичных моему User-Agent, а не только на Люмиях.
OCTAGRAM
fail JavaScript Microsoft WSH Microsoft реализовали прикольные фичи из современного JavaScript (JSON и defineProperty, например), но забыли сделать их доступными из WSH и ASP. По умолчанию движок JScript застрял на версии 5.7, а чтобы он заработал в режиме версии 5.8, нужно сделать кое–какой вызов COM–интерфейса, и, похоже, никто не знает, как заставить WScript.exe и CScript.exe сделать этот несчастный вызов.

Обсуждение на StackOverflow
Обсуждение на Google Groups
Вал неотвеченных вопросов в блоге анонса JScript 5.8
OCTAGRAM
web PHP JavaScript $_SERVER['HTTP_REFERER'] , но document.referrer. Да что с ними не так?
HTTP referer
Любопытно, что написание английского слова referrer как referer — популярная ошибка. Настолько популярная, что вошла в официальные спецификации протокола HTTP.
Ах, вот оно как. Я–то думал, это только в NMDC такие ляпы. Ну теперь я спокоен.
OCTAGRAM
web JavaScript How may I reference the script tag that loaded the currently-executing script?
Проблема в том, что я могу предоставлять скрипт, который будет подгружаться, и подгружаться он может либо синхронно, либо асинхронно, кому как больше нравится, и неплохо бы реализовать оба варианта одним скриптом. Скрипт этот по своей логике поведения подгружает ещё скрипты, и в этот момент надо знать, как он был сам подгружен, чтобы дочерние скрипты подгрузить так же. Например, здесь я подгружаю скрипт синхронно, и потом результат сразу же используется, и чтобы это работало, detect.php тоже должен подгрузиться синхронно, а на основном сайте я подгружаю немного другое имя файла с асинхронной реализацией.

Все прошлые разы я просто делал разные имена для разных способов подгрузить скрипт, но теперь появилась необходимость сделать всё же единый скрипт. Нашёл свойство document.readyState, когда документ грузится, оно loading. Вот, думал, по readyState буду определять, должен ли я дочерние скрипты через document.write() подгружать или через document.createElement(), а ничего подобного. Асинхронные скрипты и при loading ещё успевают сработать, и их document.write() уходит в молоко. Вот, блин, где бы взять такую функцию, чтоб могла сказать «следующий вызов document.write() уйдёт в молоко или вообще запорет весь документ», как бы жизнь проще стала. Придётся, похоже, перебирать все теги script, находить свой, смотреть в нём, как меня подгрузили.
OCTAGRAM
JavaScript emscripten ada идея asmjs Ada/Em — компилятор/интерпретатор на базе Ada/Ed
Ada/Ed — это компилятор/интерпретатор Ada 83, самый первый, прошедший проверку на соответствие стандарту по тестам Ada Compiler Validation Suite на IBM PC. Так как это интерпретатор, а Ada мыслится как язык, прежде всего компилируемый в машинные коды, да и стандарт хотелось бы не меньше 95–го, то долгое время до него почти никому не было дела, и в июле 2012 его сорцы (на C) выложили в открытый доступ.
Предъистория вопроса: есть у нас доступный в куче браузеров и этим интересный JavaScript, но вот есть у него один большой недостаток: надо время от времени возвращать управление. Программисту, чтобы не свихнуться, проще писать в синхронном стиле, а браузер выполняет только асинхронный код. Это решается часто просто использованием CPS (continuation-passing style). Теоретически можно любую синхронную программу переделать в асинхронную с помощью CPS. Везде, где я смотрел, это сделано руками, как–то все уже попривыкли. Но есть и парсеры/трансляторы, такие, как Wind.js, которые автоматически могут разрезать синхронную программу по швам и превратить в асинхронную CPS–лапшу.
Далее, вот есть у нас Asm.js, чрезвычайно оптимизируемое подмножество JavaScript. Если браузер поддерживает Asm.js и распознал специально помеченный кусок JavaScript кода как соответствующий всем требованиям модуль Asm.js, то генерируется быстрый машинный код. Однако, при написании программ, транслируемых в быстрый машинный код, есть один недостаток. Да всё тот же. Необходимость время от времени возвращать управление на самый верх, к браузеру. Через стек функций, через обработчики исключений — на самый верх. И тоже есть автоматические способы разпилить программу по швам и превратить в лапшу, но не CPS. Wind.js тут сработает, но требования Asm.js будут нарушены применением CPS, зато для Asm.js есть свой аналог: asincify. На его странице так и написано:
Другие возможные реализации
Closures (ломают asm.js)
Далее, читаем сравнение с asincify на странице emterpreter:
ASYNCIFY has a bad worst-case of large code size: If it needs to modify many methods, it can grow code size very significantly (even 10x more was seen).
То есть, подход asyncify может настолько значительно раздувать код, что становится оправданным применение интерпретатора emterpreter.
Далее, читаем статью Почему мобильные web–приложения медленные. Одна из главных идей — не пользоваться сборщиком мусора, особенно в мобильных приложениях. Применительно к JavaScript это значит — применять Asm.js, а не обычный JavaScript, который безальтернативно со сборщиком мусора.
Вот именно такого сравнения не видел, но, когда смотрю на графики в статье, напрашивается предположение, что код, работающий на интерпретаторе в Asm.js, может работать даже быстрее, чем его CPS–аналог на JavaScript, за счёт того, что не вызывает сборку мусора так часто.
И в этот момент мы вспоминаем, что старый забытый Ada/Ed как раз уже устроен таким способом, который, так уж вышло, наилучший для браузеров. Написан на C, интерпретируемый. Так как в MS-DOS не было потоков операционной системы, Ada/Ed приходится содержать в своём составе многозадачный планировщик. В #2785610 я всё думал, где бы мне многозадачный планировщик для Asm.js взять. Вот, нашёл!
Так что берём Ada/Ed, компилируем его интерпретатор или даже компилятор emscripten, и вот она — радость! Пишем код для браузера в синхронном стиле, не сходим с ума от CPS–лапши, и с учётом архитектуры браузеров, работает это наилучшим образом, даже на мобильных устройствах. Для полного счастья нам понадобится мост между emterpreter и интерпретатором Ada/Ed. А то, что получилось, так и напрашивается быть названным Ada/Em.

OCTAGRAM
SOM web CLOS JavaScript А было бы кому–нибудь интересно, если бы я реализовал SOM для JavaScript? Множественное наследование, как в CLOS, метаклассы.

Для тех, кто не знает, в чём разница между множественным наследованием, как в CLOS, и как, например, в C++ (и некоторых других JavaScript библиотечках, которые я тут посмотрел на тему МН):
В C++ для вызова родительского метода он указывается по имени родительского класса. Два родителя — делай два родительских вызова или ещё как–нибудь. Или делай только один из них, и однажды это запорет систему. Или не делай ни одного, но не знающий об этом программист другого компонента может сделать ромб в структуре классов и, чтобы не вызывать код дважды, вызовет только метод твоего класса, и всё запорется. Пример:
// Call the super constructors of the base classes.
Person.call( this, "Ben" );
Monkey.call( this, true );

Для сравнения: в CLOS и SOM родительский вызов — это специальная форма вызова, в которой имя родителя НЕ указывается. В DTS C++ в том виде, как он описан в «Putting Metaclasses to Work», пришлось добавить синтаксис __parent->method(). Так называемые кооперативные методы, будучи переопределены, ОБЯЗАНЫ вызвать родительский метод, за исключением случаев вроде такого, когда цепочка вызова методов образует коньюнкцию или дизъюнкцию, и нам попался false или true, соответственно. Для каждого класса все его родители выстраиваются в упорядоченный список (class precedence list в CLOS, method resolution order в SOM), и семантика вызова родительского метода — это, на самом деле, вызвать реализацию из предъидущего по списку класса, который в случае наследования ромбом может быть более левым родителем дочернего класса, или ещё где–нибудь. Некооперативные методы можно писать иначе, но компилятор потом может запретить наследование из–за потенциального конфликта. Впрочем, в собственно SOM я не видел проверок на кооперативность и я не видел таких пометок у методов, так что некооперативными методами (не вызывающими родителя или вызывающими конкретного родителя/родителей), как я понимаю, при желании всё–таки можно что–нибудь запороть.

За основу можно взять Java–симуляцию, которая прилагалась к книге: bitbucket.org
OCTAGRAM
ParaSail web JavaScript ada asmjs forge.open-do.org
Недавно заметил, что там уже лежит в сорцах LLVM компилятор ParaSail. Точнее, он перегоняет байткод в инструкции LLVM, а байткод генерят компиляторы всех 4х экспериментальных языков, то есть, и Sparkel (Ада–подобный), и Parython (Python–подобный), и Javallel (Java–подобный), и ParaSail, который помесь всех трёх.
Однако, вчитавшись в последние посты по сабжу, увидел такое:
parasail-programming-language.blogspot.ru
At first we thought the built-ins needed to be translated to llvm code to successfully link with our generated llvm. To accomplish this, we used a tool called AdaMagic to convert the Ada source code (in which the built-ins are currently written) and Ada's run time system (RTS) to C source code then used the llvm C front-end "clang" to compile the rest of the way. Clang complained with hundreds of warnings, but, it worked. We were able to print integers, floats, and characters! We couldn't do much more with the built-ins at the time because we didn't yet have type descriptors working (see below).

After all the effort and dealing with the messy generated C code, we found out that the system linker could link object files compiled with the llvm backend called "llc" together with object files produced by the GNAT Ada compiler with no problem. That was a relief, as we really didn't want to go mucking around in the generated C code more than we had to.
Я–то хотел попускать зелёные потоки в web, да ещё в asm.js. А теперь вижу, что сами зелёные потоки скомпилировать в Asm.JS можно, а библиотеку времени выполнения — нет. Впрочем, подумав ещё немного, решил, что оно и не нужно. Поток там, считай, один, это уже немного менять рантайм. Ну или, если с WebWorkers, то, наверное, можно больше потоков, но тогда будет нужна коммуникация, которой в библиотеке для натива всё равно нет.

Наверное, если бы я этим занимался, я бы как–нибудь вообще обошёлся без LLVM, с одним только интерпретатором, зато прикрутил бы стандартный сетевой стек, JSON и XML, и портанул бы мои сетевые быдлоскрипты с node.js на нечто более человеческое и привычное. А если, так уж получилось, есть компиляция в LLVM, то всё это надо двинуть в UI и наладить взаимодействие между зелёными потоками клиентов и сервера. Есть предположение, что AdaCore не хотят пускать язык в массы пока он не устаканился, а создание компилятора в натив — это один из тестов, по результатам которого в языке могут что–то поменять.