82163

Разработка отладчика для программ на языке haXe и целевой платформы Adobe Flash 9

Дипломная

Информатика, кибернетика и программирование

По указанным причинам, стало удобно и выгодно создавать web-приложения, направленные на предоставление пользователю функций, которые могут не зависеть от операционной системы. В качестве примера можно привести редактирование текстовых документов, обработку фотографий, показ презентаций...

Русский

2015-02-26

2 MB

1 чел.

Санкт-Петербургский государственный университет

Математико-механический факультет

Кафедра системного программирования

Разработка отладчика для программ на

языке haXe и

целевой платформы Adobe Flash 9

Дипломная работа студента 544 группы

Красько Николая Леонидовича

Научный руководитель

Ведущий программист НИИ ИТ СПбГУ           ……………   /М.М. Плискин/

                     /подпись /

Рецензент

Старший разработчик ЗАО "Ланит-Терком" ……………   /Н.И.Артамонов/

                / подпись /

«Допустить к защите»

Заведующий кафедрой,

д. ф.-м. н., профессор                                           ……………  /А. Н. Терехов/

               / подпись /

Санкт-Петербург

2008
Оглавление

[1]
1. Введение

[2]
2. Постановка задачи

[2.1] 2.1 Особенности технологии haXe

[2.1.1] 2.1.1 Философия haXe

[2.2]
2.2 Платформа Flash

[2.3] 2.3 Adobe Flex SDK (Standard Development Kit)

[2.4] 2.4 Платформа Eclipse

[2.4.1] 2.4.1 Архитектура Eclipse

[2.4.2] 2.4.2 Вывод

[3]
3. Поддержка отладки кода на языке haXe, скомпилированного в SWF-файл версии 9

[3.1] 3.1 Внутренняя структура  SWF-файлов версии 9

[3.2] 3.2 Байткод AVM2

[3.2.1] 3.2.1 Отладочные инструкции AVM2

[3.3] 3.3 Проверка расстановки отладочных инструкций

[3.4] 3.4 Внесение в компилятор изменений, корректирующих создаваемый SWF-файл.

[4] 4. Проект EclihX

[4.1] 4.1 Обзор проекта

[4.2] 4.2 Архитектура

[4.3] 4.3 Модуль eclihx.core

[4.3.1] 4.3.1 Реализация класса для haXe-проектов

[4.4] 4.4 Модуль eclihx.ui

[4.5] 4.5 Модуль eclihx.launching

[4.6] 4.6 Модуль eclihx.debug

[4.6.1] 4.6.1 Eclipse Debug Framework

[4.6.2] 4.6.2 Flex SDK Debug Framework

[4.6.3] 4.6.3 Реализация

[4.7] 4.7 Модуль eclihx.debug.ui

[5]
5. Заключение

[6]
6. Список литературы


1. Введение

На рынке современного программного обеспечения наметилась тенденция постепенного отказа от классической модели настольных приложений (desktop application). Такие проекты как, Google Maps, Photoshop Express, Zoho доказали возможность создания качественных   web-ориентированных программных продуктов. Кратко перечислим причины данного явления:

  •  Доступ к интернету является стандартом де-факто как для домашней, так и для корпоративной рабочей станции. Более того, на данный момент выходом в Интернет снабжаются не только персональные компьютеры, но и различные портативные устройства.
  •  Стремление увеличить количество потенциальных пользователей привело к  желанию создавать кроссплатформенные приложения, которые бы одинаково работали с различными операционными системами.
  •  Распространение быстрого интернета позволило отказаться от минимализма статических HTML-страниц и делать сложные приложения с богатым графическим интерфейсом, по удобству и красоте не уступающим настольным приложениям.
  •  Корпоративные политики безопасности компаний часто запрещают сотрудникам устанавливать на рабочие компьютеры  новые приложения.
  •  Отказ от настольных приложений упростил процесс синхронизации данных пользователя в случае, если он пользуется несколькими компьютерами. Это также решает вопрос с лицензированием коммерческих приложений — в случае web-ориентированных проектов лицензия выдается для пользователя, а не для рабочей станции.

По указанным причинам, стало удобно и выгодно создавать web-приложения, направленные на предоставление пользователю функций, которые могут не зависеть от операционной системы. В качестве примера можно привести редактирование текстовых документов, обработку фотографий, показ презентаций или даже управление информационной системой.

К сожалению, неожиданным препятствием для развития web-приложений явилось отсутствие специализированных технологий для их разработки. Программирование для web до недавнего времени подразумевало под собой использование нескольких технологий и языков.  Чаще всего выбирали для создания серверной части между C#, Ruby, PHP и Java, а для разработки клиентского интерфейса между HTML или Flash. Ситуация усугубляется тем, что обычно для сложных страниц приходится одновременно использовать и HTML, и Flash, и javascript. Стала очевидной необходимость создания нового языка, при помощи которого можно было бы пройти весь цикл разработки web-приложения. Таким языком стал haXe.

haXe[7] — объектно-ориентированный строго типизированный язык программирования высокого уровня, ориентированный на разработку web-приложений. Разработка его началась в конце 2005 года французским программистом Николя Канассом (Niсolas Cannasse). Выход версии 1.0 состоялся в марте 2006 года. На данный момент язык продолжает развиваться, последний релиз состоялся  в марте 2008 — версия 1.19.

Не смотря на то, что язык очень молод, уже существует ряд коммерческих и open-source проектов реализованных с его помощью, среди них haXe Website[7], MyMiniCity[17], Alpha Bounce[19], Comapping[18].

Компилятор языка haXe поддерживает несколько платформ:

  1.  Javascript — обычно, по нескольким классам, написанным на языке haXe, генерируется один «js» файл, который будет использоваться в web-приложении. В коде на haXe можно использовать все стандартные Javascript классы, в том числе и XmlHttpRequest, что делает haXe удобным для разработки Ajax приложений.
  2.  Flash — haXe может быть скомпилирован в swf-файл 6, 7, 8 и 9-ой версии.
  3.  Neko — haXe также может быть скомпилирован в байткод Neko Virtual Machine[10], которая интегрируется с web-сервером Apache. Это позволяет использовать язык для разработки серверной части web-приложений.  Доступны библиотеки для управления файловой системой, базами данных, сетевыми операциями, а также охватывающие другие аспекты программирования.

Таким образом, используя один лишь только haXe можно написать полноценное web-приложение.

Но при выборе технологии немаловажным фактором является наличие удобной среды разработки. Действительно, продуманная IDE (Integrated Development Environment) позволяет программисту сосредоточиться на написании логики приложения, уменьшает вероятность появления ошибок, а также берет на себя часть рутинной работы по управлению, написанию и сопровождению кода. Все это позволяет уменьшить время работы над проектом, снизить его стоимость и повысить качество программного обеспечения.

Несмотря на появление и распространение идеи юнит-тестирования, встроенный отладчик по-прежнему является необходимым атрибутом современной среды разработки. Контроль над ходом исполнения программы при помощи точек останова позволяет в большинстве случаев достаточно быстро локализовать и устранить ошибку. К сожалению, по различным причинам, для языка haXe отладчика не существовало. Решить эту проблему для целевой платформы Flash 9 и было основной целью данной дипломной работы.


2. Постановка задачи

Задачей данной работы была разработка отладчика для программ на языке haXe и целевой платформы Adobe Flash 9 в среде Eclipse 3.3. В  рамках работы выделены три основные подзадачи:

  •  Проверка и коррекция компилятора haXe в области генерации отладочных инструкций для swf-файлов версии 9
  •  Реализация поддержки языка haXe в среде Eclipse.
  •  Поддержка функции отладки для целевой платформы Flash 9

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

2.1 Особенности технологии haXe

Прежде чем переходить непосредственно к описанию Eclipse и Adobe Flash, рассмотрим аспекты, которые можно было бы назвать философией haXe и которые определяют место языка в конкурентной борьбе web-технологий.

2.1.1 Философия haXe

Прежде всего, haXe является проектом с открытым исходным кодом, что неоднократно подчеркивалось создателем языка на его сайте и на различных конференциях. Более того, выбор этой стратегии рассматривается им как вынужденная и необходимая мера. Согласно выступлению Николя Канасса на 24C3, язык haXe специально разрабатывался таким образом, чтобы иметь возможность абсорбировать технологии от различных производителей. Автор намеренно отказался от всех существующих языков и создал свой, где проводится четкая грань между общим кодом и кодом, специфичным для конкретной технологии. Такой подход позволяет максимально полно поддерживать функциональность целевых платформ.

Open Source стратегия в таком контексте является гарантией того, что язык будет развиваться и обеспечивает максимально плодотворную почву для разработки компиляторов или интерпретаторов в новые целевые платформы. Открытость также снимает запрет на использование сторонних технологий в коммерческих целях: haXe не стремится конкурировать с Flash, Javascript или новым Silverlight – это, прежде всего, инструмент для разработчика, помогающий комфортно использовать распространенные web-платформы и не тратить дополнительных усилий для переноса независимого кода между ними.

Так как язык ориентирован на разработку web-приложений, позволяющим абстрагироваться от установленной на компьютере операционной системы, инструментарию для haXe, в свою очередь, также желательно обладать свойством кроссплатформенным. В перспективе это может снять неудобства, связанные с необходимостью использования нескольких операционных систем и сократить циклы тестирования создаваемых приложений. В частности, связка из лексера, парсера и компилятора для haXe реализована на языке Caml[11], поддержка которого существует во всех основных современных ОС. Итак, кроссплатформенность – вторая особенность, которую предстоит учитывать при выборе технологий для разрабатываемого  отладчика.


2.2 Платформа Flash

Несмотря на то, что haXe может быть скомпилирован в три целевые платформы, описанные выше, на данном этапе развития язык чаще всего используется для создания Flash-приложений. Именно поэтому в рамках данной дипломной работы было решено сосредоточиться на создании отладчика для кода, скомпилированного в swf.

SWF – формат для передачи мультимедиа контента и векторной графики. Предпосылкой для его создания стало желание получать небольшие по размеру файлы для отображения анимации. Постепенно формат стал поддерживать видео, аудио и интерактивные возможности. В 2005 году компания Macromedia, обладающая правами на swf-формат, была куплена корпорацией Adobe.

SWF-файлы проигрываются Flash Player-ом, который может быть интегрирован в web-браузер, или являться самостоятельным приложением. Во втором случае возможно создание самопроигрывающихся исполняемых файлов, в которых swf-файл предварительно интегрирован с проигрывателем.

Для создания интерактивного интерфейса, управления данными и решения других задач, связанных с нелинейным отображением медиа контента в рамках Flash-приложений, компания Adobe предлагает использовать объектно-ориентированный язык программирования ActionScript. Написанный на нем программный код компилируется в байткод и записывается в специально отведенное место в swf-файле. Его последующее исполнение производится виртуальной машиной (ActionScript Virtual Machine), которая является составной частью Flash Player.

ActionScript как язык появился с выходом 5 версии Flash. В 2004 году Macromedia представила новую версию ActionScript 2.0 вместе с выходом Flash 7 (MX 2004) в котором наиболее значительными изменениями стало введение статической типизации и поддержки концепций объектно-ориентированного программирования. Тем не менее, ActionScript 2.0 является не более чем надстройкой над ActionScript  версии 1.0, то есть на этапе компиляции компилятор ActionScript 2.0 осуществляет проверку типов и превращает класcы и методы ActionScript 2.0 в прежние прототипы и функции ActionScript 1.0.

В 2006 году одновременно с выпуском Adobe Flex 2 и соответствующим проигрывателем Adobe Flash 9 состоялся релиз ActionScript 3.0.

ActionScript 3.0 содержит в себе, по сравнению с предыдущей версией, обширные  качественные изменения. Прежде всего, Flash Player 9 опирается на написанную практически с нуля, высоко оптимизированную ActionScript Virtual Machine 2.0 (AVM2). Новая виртуальная машина призвана обеспечить производительность и функциональное наполнение, необходимое для разработки Rich Internet Application. AVM2 поддерживает встроенную проверку ошибок времени выполнения и встроенную поддержку отладки. Инструкции ActionScript3 компилируется в байткод, который не может исполняться на виртуальной машине предыдущей версией, поэтому для поддержки обратной совместимости Flash Player 9 также содержит AVM1.

Напомним, что haXe поддерживает компиляцию во Flash всех версий, начиная с шестой. Тем не менее, данная работа сосредоточена на разработке отладчика только для последней – девятой версии. Действительно, в связи с тем, что Flash Player 9 уже достаточно распространен  (95% компьютеров с выходом в интернет по состоянию на март 2008[13]), а новая виртуальной машины дает значительный выигрыш в производительности и позволяет использовать последние достижения Flash-технологий, разработка новых приложений производится при помощи Flash 9. Приложения, работающие с устаревшими версиями проигрывателя, также переводятся на новую платформу. Законченные приложения или приложения, лишенные поддержки, разработанные при помощи старых версий Flash, как правило, в отладке не нуждаются. Эти соображения, а также сложности написания отладчика для AVM1, связанные с устареванием технологии и отсутствием достаточного количества документации, привели к идее сосредоточиться в данной дипломной работе только на поддержке отладки для виртуальной машины версии 2.

2.3 Adobe Flex SDK (Standard Development Kit)

Это еще одна технология, которая должна быть упомянута в рамках данной дипломной работы. Компания Adobe описывает Flex SDK[8], как высокопроизводительную платформу разработки (framework) с открытым исходным кодом для создания и поддержки богатых web-приложений. В SDK входит программное обеспечение для разработки Flex приложений – это, прежде всего, компилятор и отладчик, а также большой набор различных библиотек с элементами управления и работы с данными.

Так как результатом компиляции Flex приложения является swf-файл версии 9, который может быть отлажен при помощи поставляемого консольного отладчика fdb.exe, инструменты, содержащиеся в SDK, могут быть использованы для разработки в контексте haXe + Flash 9.

Важно, что в конце 2007 года компания Adobe решила открыть исходный код среды Flex и начать распространение этого продукта на условиях Mozilla Public License (MPL). Таким образом, стало возможным задействовать SDK для задач, решаемых в данной дипломной работе.

2.4 Платформа Eclipse

Eclipse Platform[5] представляет собой написанную на Java среду разработки самого общего назначения, архитектура которой обеспечивает возможность для интеграции различных инструментов и языков программирования. Механизмы подобной интеграции позволяют использовать Eclipse Platform для построения развитых сред разработки и освобождают от рутины написания базовых средств в пользу создания сложных, специализированных функций.

2.4.1 Архитектура Eclipse

Основой архитектуры Eclipse Platform является принцип использования подключаемых модулей (plug-in). Платформа реализует механизмы их обнаружения, интеграции и выполнения. Типовое подключение состоит из кода Java в библиотеке JAR и различных ресурсов, таких, как изображения, файлы справки, библиотеки в кодах аппаратной платформы.

Каждый подключаемый модуль имеет файл манифеста (manifest), объявляющий его соединение с другими подключениями. Модель соединения модулей использует механизм точек расширения (extension point). Плагин может, как объявлять точки расширения для последующего использования, так и расширять любое количество из ранее объявленных. Например, подключаемый модуль, реализующий функциональность стандартного текстового редактора предоставляет точку расширения и связанный с ней API, при помощи которого модули-пользователи могут произвести настройку и доработку существующей базовой функциональности.

Общую картину архитектуры можно увидеть на рисунке из онлайн справки к архитектуре Eclipse:

Рис.  Архитектура платформы Eclipse

При запуске среды разработки на базе Eclipse Platform компонент Platform Runtime определяет набор доступных подключаемых модулей, читает их манифестные файлы и строит реестр модулей. При этом полная загрузка plug-in’а происходит только, когда понадобится непосредственно исполнить принадлежащий ему код. Данный механизм обеспечивает возможность поддерживать большую базу инсталлированных подключаемых модулей.

Платформа предоставляет точки расширения с интерфейсами и базовой реализацией практически для всех абстракций и функциональности, которая может понадобиться при разработке современной IDE. Рассмотрим наиболее значимые.

  •  Рабочее пространство (workspace) – это компонент, определяющий основные объекты, с которыми могут работать пользователи и приложения Eclipse и предоставляющий  средства по структуризации и управления ими. В техническом плане основная задача, которую решает этот компонент – унифицированный доступ к локальным и удаленным объектам. Базовые понятия, определяемые Workspace –это проект (project), папка (folder) и файл (file). В терминологии Eclipse все эти объекты называются ресурсами (resources).
  •  Компонент рабочая область (workbench) определяет базовый пользовательский интерфейс (UI) Eclipse, а также предоставляет другим компонентам средства для создания своих собственных интерфейсов. Основные объекты интерфейса, с которыми работает Workbench – это редакторы (editors), виды (views) и перспективы (perspectives).

Фундаментом, на котором построены все графические средства Eclipse, является входящий в Workbench компонент SWT (Standard Widget Toolkit), который используется в качестве основного средства создания пользовательского интерфейса для приложений на основе Eclipse. Поскольку для прорисовки элементов интерфейса SWT максимально использует средства конкретной операционной системы, приложения, построенные на базе SWT, выглядят привычно для пользователя. При этом они сохраняют совместимость со всеми ОС, поддерживаемыми Eclipse.

На основе SWT построен компонент JFace, который решает более высокоуровневые задачи построения пользовательского интерфейса. JFace содержит классы для создания диалогов, страниц свойств, управления шрифтами, поддержки архитектуры MVC и т.п.

2.4.2 Вывод

Заметим, что реализация визуального отладчика обычно является не первым шагом в разработке интегрированной среды разработки. К моменту начала работы над функцией отладки необходимо иметь возможность локализовывать и просматривать файлы с кодом проекта, а также производить обычную компиляцию и сборку. Требование о наличии визуального интерфейса также подразумевает большой объем предварительной работы. По этим соображениям была категорически отвергнута идея создания среды для отладки с нуля в пользу существующих расширяемых решений.

C учетом рассмотренной архитектуры, а также указанных особенностей философии языка haXe, платформа Eclipse выглядит наиболее удачным решением для использования в качестве базы для разрабатываемого отладчика.


3. Поддержка отладки кода на языке haXe, скомпилированного в SWF-файл версии 9

Первоочередной задачей при разработке функции поддержки отладки, стала работа с компилятором языка haXe в целевую платформу Flash 9. На данном этапе были выделены следующие подзадачи:

  1.  Изучение бинарного формата swf9 с целью поиска путей поддержки отладки;
  2.  Проверка корректности генерации байткода для целевой платформы в рамках изучаемой задачи;
  3.  Внесение в код компилятора изменений, направленных на коррекцию создаваемого SWF-файла.

Рассмотрим подробнее работу, проделанную на этом этапе, а также полученные результаты.

3.1 Внутренняя структура  SWF-файлов версии 9

Любой SWF-файл начинается с заголовка (header), за которым следует набор тегов (tags). В заголовке содержится основная информация о текущем файле: флаг, говорящий о том, применено ли сжатие, версия поддерживаемого проигрывателя,  размер файла и др. Теги, в свою очередь, несут информацию о содержании и свойствах отображения данного Flash-клипа.

Содержанию тега в обязательном порядке предшествует информация с уникальным номером и длиной тега. Такая структура позволяет парсерам, которые не могут интерпретировать тег с текущим номером, смещаться к началу следующего тега и продолжать работу.

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

  •  Тег FileAttributes должен быть первым в файлах версий 8 и выше
  •  Тег может использовать только ту информацию, которая была получена до его считывания
  •  Последовательность тегов должна завершиться специальным тегом окончания (End Tag)

Спецификация SWF-формата девятой версии определяет около шестидесяти тегов с номерами от 0 до 89 в десятичной записи. Пропуски в индексации постепенно заполняются при появлении новых тегов.

Заметим, что с целью максимально минимизировать размер SWF-файла, в формате часто используется сохранение цепочки значений без побайтового выравнивания. Это обстоятельство, а также применение little-endian подхода при сохранении значений, сильно затрудняет работу с SWF-файлами без дополнительных технических средств. В качестве простого примера рассмотрим тег SetBackgroundColor  с номером 9. Данный тег устанавливает цвет фона во Flash-клипе: три байта, отведенные под информацию, используются для хранения цвета в RGB записи.

 

При компиляции haXe практически не использует декларативные теги (Definitions Tags), отвечающие за определения медиа контента (фигуры, текст, рисунки и т.п.), главным образом ориентируясь на управленческие теги (Controls Tags).

3.2 Байткод AVM2

Согласно спецификации формата swf9[6], для хранения байткода виртуальной машины используется тег с номером 82 и именем DoABC(абривеатура ABC происходит от Action Script Bytecode). Он состоит из двух областей: Flags и ABCData.

Тег DoABC

Область данных

Размер области

Комментарии

Flags

Четырехбайтовое беззнаковое целое

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

ABCData

Массив байтов

Блок, содержащий байткод AVM2

Компилятора языка haXe для хранения байткода использует тег номер 72. Этот тег отсутствует в спецификации формата, однако исследование исходных кодов Flex SDK показало, что единственное отличие от 82 тега в пропуске области Flags (флаг, откладывающий исполнение байткода, при этом выставляется автоматически). Использование недокументированного тега может быть объяснено тем, что официальный документ, описывающий формат swf9 появился лишь в августе 2007 года и при создании компилятора не использовался.

Область ABCData присутствует в обоих тегах, и различий в ее обработке нет. Для подробного изучения структуры этой области спецификация предлагает ознакомиться с документом ActionScript Virtual Machine 2 (AVM2) Overview[3]. Для дальнейшего повествования будут использованы обозначения из этого документа.

ABCData, согласно pdf-файлу с описанием AVM2, есть массив байтов, хранящий структуру данных abcFile. Она, в свою очередь, определяет несколько именованных областей, оптимизированных для работы с виртуальной машиной. В качестве примера можно привести,  область констант, использованных в коде (constant pool), области описания  методов и классов, а также область для размещения исполняемых блоков.

Большая часть кода на языке haXe, а именно реализация методов и функций, отображается в область исполняемых блоков. Для этого каждая конструкция языка haXe записывается в виде последовательности команд виртуальной машины. Такие команды принято называть инструкциями. Каждая инструкция неким образом изменяет внутреннее состояние виртуальной машины, или производит взаимодействие с окружающей средой, при помощи операции ввода/вывода.

3.2.1 Отладочные инструкции AVM2

В новой, значительно переработанной виртуальной машине поддержка возможности отладки реализуется посредством вставки в байткод отлаживаемой программы специальных инструкций. Так как на их исполнение затрачивается некоторое время, а также требуется дополнительное место для их хранения, то, как правило, их генерация уместна только во время разработки. Обычно компиляторы предоставляют специальную опцию, которая регулирует включение генерации этих инструкций. Компилятор haXe использует параметр командной строки «–debug».

Приведем краткое описание инструкций отладки:

  •  debug ( 0xef ) – данная инструкция используется для именования регистра с целью обеспечения внешнего доступа к данным отлаживаемого приложения. При помощи присвоенного имени производится мониторинг и изменения значений переменных
  •  debugfile ( 0xf1 ) явное указание о том, в каков файле находится код, породивший последующие инструкции. Единственным параметром инструкции, является индекс строки в пуле констант, содержащей полное имя файла. Отладчик будет считать, что он находится в одном и том же файле, пока он не встретит debugfile инструкцию с указанием другого файла. Фактически предлагается, что эта инструкция должна встречаться каждый раз перед debugline.
  •  debugline ( 0xf0 ) – указывает к какой строке файла относятся последующие инструкции. В качестве параметра инструкция принимает число – номер строки файла. Отладчик будет считать, что все последующие инструкции выполняются в одной строке, пока не встретит debugline с другим параметром.

Рассмотрим простейший пример, показывающий использование инструкций отладки:

Функция на haXe:

1 class InstructionsExample {

2     static function localFunction(i: Int) {

3         var changeParam = i * 2;

4     }

5     static function main() {

6         var intVariable = 1;

7         localFunction(intVariable);

8     }

9 }

AVM2 Bytecode:

class InstructionsExample extends Object

{

 … // Конструктор, сгенерированный компилятором

 static function localFunction(int):void /* disp_id 1*/

 {

   // local_count=3 max_scope=0 max_stack=2 code_len=23

   0       debugfile      "InstructionsExample.hx"

   2       debugline      2

   4       debug          reg: 1 name: i

   9       debugline      3

   11      debug          reg: 2 name: changeParam

   16      getlocal1      

   17      pushbyte       2

   19      multiply_i     

   20      convert_i      

   21      setlocal2      

   22      returnvoid     

 }

 static function main():void /* disp_id 2*/ { … }

}

3.3 Проверка расстановки отладочных инструкций

Для проверки правильности генерации отладочных инструкций были написаны тесты, содержащие базовые конструкции языка haXe. Их удобное использование обеспечивается bat-файлами (Windows Batch Files[12]), которые вызывают компилятор haXe для списка тестовых классов, указанных в специальном текстовом файле, и получают соответствующие swf-файлы.

Далее, для упрощения чтения файлами в формате swf в программу haxe.exe была добавлена возможность перевода бинарного представления в текстовое. Для написания этой функции были задействованы возможности haXe библиотек, а именно парсинг swf-файлов и печать полученного дерева в бинарный файл. Опция может быть использована из командной строки

Структура работы добавленной опции, а алгоритм ее возможного использования может быть наглядно продемонстрирован на следующей картинке:

Скрипты производят компиляцию, используя последнюю официально выпущенную версию haXe (на момент написания дипломной работы это версия 1.19), а также при помощи версии компилятора, собранного из исходных файлов в которые внесены текущие изменения. Такой подход позволил следить за изменениями, вызванными правкой кода компилятора.

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

3.4 Внесение в компилятор изменений, корректирующих создаваемый SWF-файл.

Как показали проведенные тесты, существовавшие механизмы расстановки отладочных инструкций работают правильно в большинстве случаев. Тем не менее, в ходе тестирования были обнаружены следующие недочеты:

  •  Использование в отладочных инструкциях относительных путей к исходным файлам делает невозможным автоматическую локализацию кода;
  •  Отсутствие инструкции debugline перед выходом из метода, возвращающего тип «Void», приводит к преждевременной потере контекста и невозможности инспекции состояния после выполнения последней инструкции метода.

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

4. Проект EclihX

4.1 Обзор проекта

Несмотря на подзадачу, связанную с изучением формата swf9, проверкой корректности генерации байткода haXe-компилятором и внесением в него изменений, основной вектор разработки в рамках этой дипломной работы был направлен на интегрирование языка haXe с платформой Eclipse. Как уже отмечалось, отладчик не может быть написан без обширной предварительной работы, направленной на реализацию поддержки языка. Фактически, разработка визуального отладчика подразумевает под собой создание интегрированной среды разработки. Как раз такой средой и стал проект EclihX, созданный мной.

Из-за большого объема задач и так как работу над EclihX планируется продолжить, было решено оформить разрабатываемую среду в качестве проекта с открытым исходным кодом. Таким образом, файлы EclihX могут быть скачаны с сайта Google Code по адресу:

http://code.google.com/p/eclihx/

Версия, которая была разработана к моменту окончанию дипломной работы, обладает следующей функциональностью:

  •  Управление кодом проекта;
  •  Подсветка кода на языке haXe;
  •  Поиск и настройка компилятора haXe;
  •  Сборка проекта
  •  Поддержка функции отладки для целевой платформы Flash 9

Далее приведено описание архитектуры проекта и раскрыты подробности реализации.

4.2 Архитектура

Как упоминалось ранее, приложения, построенные на основе платформы Eclipse, состоят из одного или нескольких плагинов. Как правило, решения, построенные на базе одного расширяемого модуля, используется в случае небольшого узконаправленного приложения. Так как проект нацелен на поддержку обширной функциональности, которая может быть разделена как логически, так и во времени, то были выделены несколько плагинов:

  •  eclihx.core – содержит интерфейсы и классы на языке Java, призванные абстрагировать и обеспечить безопасный доступ к функциям и понятиям, определяемых языком haXe. Также данный модуль содержит расширения стандартных ресурсов Eclipse (проект, файл, рабочая область) возможностями, направленными на работу c haXe;
  •  eclihx.debug – содержит реализацию для функции отладки;
  •  eclihx.debug.ui – включает в себя дополнения графического интерфейса, которые используются при активизации функции отладки;
  •  eclihx.launching – расширяемый модуль, реализующий базовую функциональность по сборке haXe проектов. При помощи этого модуля производится обработка параметров текущей сборки и принимается решения об использовании функции отладки;
  •  eclihx.ui – в этом модуле содержатся основные настройки и расширения графического интерфейса, предоставляемого пользователю при работе с haXe.

Структуру зависимостей между подключаемыми модулями можно увидеть на картинке (под зависимостью в данном случае понимается использование классов и интерфейсов одного модуля объектами другого):

Такое разделение на модули не только позволяет улучшить структуру приложения, разделить его на логически независимые компоненты, которые можно заменять и поддерживать отдельно, но также следует одному из основных правил Eclipse:

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

Если пользователь не будет работать с проектом EclihX, а будет использовать среду разработки Eclipse для работы с другими функциями, не один из модулей eclihx не будет загружен. Аналогично, если программист не будет запускать отладчик проектов haXe, то активизации eclihx.debug не произойдет.

Несмотря на то, что eclihx.core повторяется несколько раз посредством вторичных зависимостей,  среда выполнения платформы (Platform Runtime Environment) отслеживает и поддерживает в оперативной памяти только одну копию классов eclihx.core.

Рассказывая об архитектуре, упомянем, что одним из плюсов, который был получен, благодаря выбору платформы Eclipse в качестве базы для проекта EclihX – большое количество примеров: как правило, разработки для платформы Eclipse поставляются с открытым исходным кодом, что дало возможность использовать проверенные решения для данного проекта. При работе надо EclihX были исследованы архитектуры Java Development Tools[14] – наиболее крупного и известного проекта, построенного на базе Eclipse SDK, представляющего из себя среду разработки для языка Java, Aptana[16] – среды разработки для платформы RadRails, OCaml Development Tool[15] и других.

Стоит заметить также, что платформа Eclipse отчасти закрепляет архитектуру разрабатываемых модулей, предоставляя базовую реализацию и интерфейсы, для многих широко используемых понятий. А опираясь на еще одно правило из книжки «Расширения Eclipse»[2], которое гласит, что плагины должны соответствовать всем стандартным интерфейсам, эти реализации можно и нужно использовать.

Далее указанные модули рассмотрены подробнее.

4.3 Модуль eclihx.core

Этот плагин содержит базовую функциональность, которая будет использоваться всеми модулями проекта EclihX. Его главное предназначение – инкапсулировать работу с языком haXe.

В модуле реализованы:

  1.  Общий логгер для всех модулей проекта (класс EclihxLogger);
  2.  Парсер параметров, передаваемых программе haxe.exe;
  3.  Создание класса для haXe-проектов (HaxeProject);
  4.  Создание рабочей области Eclipse функциями работы с haXe-проектами.

Первый и второй пункты довольно очевидны, 4 полностью опирается и реализует те же подходы что и третий. Поэтому рассмотрим подробнее 3 пункт. Одновременно это позволит продемонстрировать механизм использования точек расширения Eclipse, кратко описанный во введении.

4.3.1 Реализация класса для haXe-проектов

Проект – одно из основных понятий платформы Eclipse. Его можно определить, как именованную коллекцию файлов и папок. Так как работа с проектом не может зависеть от того, какие плагины установлены в системе, единственная возможность наследования кода – использование композиции.  Для доступа к функциональности проекта используется интерфейс IProject, определенный в Java-пакете org.eclipse.core.resources.

Итак, модуль eclihx.core реализует следущую архитектуру для обеспечения функциональности специфичной для haXe-проектов:

  •  Интерфейс IHaxeProject определяет операции, применимые к haXe-проектов;
  •  Класс HaxeProject реализует интерфейс IHaxeProject. Конструктору класса передается объект, реализующий интерфейс IProject,  который впоследствии используется для обеспечения базовой функциональности проекта.
  •  IProjectPathManager – интерфейс, при помощи которого происходит доступ к различным путям, специфичным для haXe-проекта (адреса папок с исходными кодами, папка, куда будут помещены скомпилированные файлы, а также адреса файлов используемых библиотек);
  •  ProjectPathManager – класс, реализующий IProjectPathManager.
  •  HaxeProjectNature класс реализующий интерфейс IProjectNature.

Взаимодействие интерфейсов и классов приведено на диаграмме:

Рис.  Архитектура реализации haXe-проекта

Остановимся подробнее на классе HaxeProjectNature и на интерфейсе IProjectNature.

Для того чтобы обозначить, что проект принадлежит определенному типу, платформа Eclipse вводит понятие сущность проекта (project nature). Для реализации этого понятия используется уникальная строковая константа, называемая идентификатор сущности (nature id), которая ассоциируется с определенным проектом и сохраняется между сессиями путем сериализации в файл. Платформа Eclipse может получить информации о наличии у проекта той или иной сущности при помощи метода hasNature(String) интерфейса IProject.

Для того чтобы обозначить haXe-проекты, используется идентификатор сущности "eclihx.core.haxenature". При создании объекта HaxeProject, происходит добавление этой строки в информацию о проекте. Далее, проверка сущности проекта часто используется в пользовательском интерфейсе, когда необходимо применить какое-то действие только к haXe-проектам.

Так как прямое наследование от классов ресурсов запрещено, для решения задач, связанных с необходимостью выполнить некие действия при добавлении или удаления сущности проекта, используется механизм точек расширения. Платформа Eclipse предоставляет возможность использовать точку расширения с идентификатором

org.eclipse.core.resources.natures

После загрузки плагина, определяющего расширения для данной точки, каждый раз, когда платформа будет изменять сущность проекта с идентификатором, указанным в параметре id, будут вызываться методы класс, записанного в параметре runtime->class. Для реализации этой возможности Eclipse требует, чтобы класс реализовывал интерфейс

org.eclipse.core.resources.IProjectNature

Таким образом, файл plugin.xml подключаемого модуля eclihx.core содержит следующие строки:

<extension

  id="eclihx.core.haxenature"

  name="%haxeNatureName"

  point="org.eclipse.core.resources.natures">

  <runtime>

     <run class="eclihx.core.haxe.model.HaxeProjectNature"/>

  </runtime>

</extension>

А метод deconfigure(), определяемый в интерфейсе IProjectNature и реализованный в классе HaxeProjectNature, используется для удаления файла, хранящего сериализованные пути класса ProjectPathManager.

4.4 Модуль eclihx.ui

В этом модуле содержится реализации всего не специфичного для режима отладки интерфейса. Ввиду большого объема кода, содержащего в этом плагине, не будем подробно описывать реализацию, а лишь перечислим использованные точки расширения и дадим описания реализованной функциональности.

org.eclipse.ui.editors

Дает указание платформе Eclipse, что в случае открытия пользователем файлов с расширением «hx» необходимо использовать специализированный редактор (класс HXEditor). На данном этапе в редакторе реализованы только функции подсветки и форматирования текста.

org.eclipse.ui.preferencePages

Создает пункт EclihX в стандартном окне настроек платформы (Window->Preferences…). Сейчас имеются две страницы с настройками – настройки используемого компилятора и настройки редактора кода haXe.

org.eclipse.ui.newWizards

Добавляют в меню создания нового объекта (File->New) категорию с именем “haXe(EclihX)” которая содержит три пункта: создание проекта (haXe Project), создание файла с исходным кодом haXe (haXe File) и создание файла с конфигураций сборки (haXe Build File). В текущей версии детально проработан только мастер создания проектов: пользователь может выбрать местоположение проекта, его имя, имя hxml-файла, который будет использоваться для сборки проекта, а также имена для папок с исходными и с собранными файлами. По введенным параметрам производится автоматическая генерация haXe-проекта. Для оставшихся двух пунктов меню пока используется стандартный мастер создания файлов платформы Eclipse.

org.eclipse.ui.perspectives

Конфигурирует вид и расположение инструментов, которые будут включаться по умолчанию при переходе пользователем в режим разработки haXe-проектов.

org.eclipse.ui.propertyPages

Добавляет в настройки haXe-проекта дополнительную страницу с настройками, специфичными для конкретного проекта.

org.eclipse.debug.ui.launchShortcuts

Добавляет пункт меню “haXe application” в меню «Run As», при условии выделения файла с расширением «hxml».

org.eclipse.debug.ui.launchConfigurationTypeImages

Определяет файл иконки(icon), которая будет использоваться при визуализации запускаемых конфигураций для haXe-проектов.

org.eclipse.ui.views

Добавляет в диалог “Show View” категорию haXe(EclihX) с визуальным контейнером haXe Package Explorer.

org.eclipse.ui.navigator.viewer

Настраивает функциональность haXe Package Explorer путем расширения стандартного визуального контейнера просмотра ресурсов для работы с haXe-проектами. Этот компонент планируется использовать для отображения внутренней структуры файл с кодом на языке haXe.

org.eclipse.ui.navigator.navigatorContent

Добавляет в визуальный контейнер фильтр, для отображения только haXe-проектов.

4.5 Модуль eclihx.launching

В этом модуле при помощи точки расширения

org.eclipse.debug.core.launchConfigurationTypes

для проектов на языке haXe определена запускаемая конфигурация (Launch Configuration). Одна и та же конфигурация применяется для режима обычной сборки проекта и для режима отладки.

Запускаемая конфигурация представляет набор параметров, необходимых для запуска приложения. Она реализуется в платформе Eclipse при помощи интерфейса ILaunchConfiguration. С каждой конфигурацией, определенной в системе должен быть связан запускающий ее делегат. Для EclihX этот делегат представлен классом HaxeLaunchDelegate, реализующим стандартный интерфейс ILaunchConfigurationDelegate.

ILaunchConfigurationDelegate определяет единственный метод:

void launch(

   ILaunchConfiguration configuration,

   String mode,

   ILaunch launch,

   IProgressMonitor monitor) throws CoreException

В этом методе происходит разбор режима(mode), для которого была запущена данная конфигурация, и исполнение метода run либо в объекте классе SimpleHaxeRunner в случае, когда строка режима отладки равна “run”, либо вызов этого же метода в объекте FlashDebugRunner, если параметр mode сопоставим со строчкой “debug”. Оба класса реализуют интерфейс IHaxeRunner.

SimpleHaxeRunner вызывает  haxe.exe  для файла hxml, находящегося в проекте, что выполняет обычную сборку проекта. На механизмы сборки EclihX накладывалось ограничение, работать также, как работал бы запуск haxe.exe из консоли.

FlashDebugRunner выполняет проверку валидности конфигурации для режима отладки и делегирует запрос классу FlashRunner, определенному в модуле eclihx.debug.

Также, для удобства работы с параметрами конфигурации, модуль eclihx.launching содержит класс HaxeRunnerConfiguration, который позволяет абстрагировать работу с неименованными методами получения значения настроек интерфейса ILaunchConfiguration.

4.6 Модуль eclihx.debug 

Так как функция, реализуемая в этом модуле, является основной целью дипломной работы, дадим развернутое описание процессу разработки этого модуля.

4.6.1 Eclipse Debug Framework

Eclipse SDK предоставляет платформу для разработки и интеграции отладчиков. Она определяет серию Java интерфейсов для формализации понятий и действий, общих для множества отладчиков. В качестве примера таких понятий, можно привести потоки, стек, переменные и точки останова. Общими действиями являются прерывание хода исполнения программы, совершение одного шага отладки,  возобновление исполнения. Платформа Eclipse не предлагает кода по реализации этих интерфейсов, так как эта область слишком специфична и зависит от конкретного языка, для которого разрабатывается функция отладки.

Общую структуру интерфейсом и их взаимодействие можно увидеть на рисунке

Рис.  Диагармма классов для Eclipse Debug API

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

4.6.2 Flex SDK Debug Framework

Как уже упоминалось, компания Adobe открыла исходные коды Flex SDK для общего доступа и решила продолжать дальнейшую разработку платформы в рамках лицензии Mozilla Public License(MPL)[9]. Этот шаг дал возможность использовать код Flex SDK в проекте EclihX.

Наиболее востребованными для этой дипломной работы являются классы и интерфейсы, управляющие сессией Flash Player’a в режиме отладки. Они расположены в пакете flash.tools.debugger. Бинарные файлы, которые являются результатом компиляции классов этого пакета, упаковываются в файл fdb.jar. Плагин eclihx.debug использует этот файл в качестве сторонней библиотеки и опирается на функциональность, предоставляемую им.

Рассмотрим три главных типа, используемых в EclihX:

  1.  flash.tools.debugger.SessionManager – определяет интерфейс для контроля настроек и состояния всех отладочных сессий Flash-плеера.
  2.  flash.tools.debugger.Bootstrap – класс, определяющий статические методы для доступа к Debug Framework. В частности, при помощи метода sessionManager() клиентом может быть получен объект, реализующий интерфейс SessionManager.
  3.  flash.tools.debugger.Session – интерфейс, при помощи которого осуществляется контроль Flash-плеера. Доступны операции остановки, продолжения, пошаговой отладки. Также пользователю этого интерфейса предоставляется возможность получения значений переменных сессии.

Рис.  Интерфейсы SessionManager и Session

Таким образом, перед расширяемым модулем eclihx.debug поставлена задача реализации интерфейсов Eclipse Debug Framework путем обращения к компонентам к классам из Flex SDK Debug Framework

4.6.3 Реализация

Отметим две важных детали, которые необходимо учитывать при разработке отладчика:

  •  Платформа Eclipse многопоточна, поэтому важно чтобы все классы отладчика были потокобезопасны. Это наиболее сложная часть отладчика, так как постоянно необходимо согласовывать политики потоко-безопасности между API, предоставляемым Flex SDK и тем API, которое просит Eclipse.
  •  Все долговременные действия должны быть реализованы в отдельных потоках. Если рассматривать процесс одного шага отладчика, то необходимо помнить, что он не должен блокировать весь пользовательский интерфейс. Пользователь не должен ждать, пока проигрывателем будет достигнута следующая точка останова. Поэтому, как правило, для общения с виртуальной машиной или интерпретатором используется событийно-ориентированная модель.

Для реализации интерфейсов, указанных в Eclipse Debug Framework, плагин eclihx.core определяет классы с префиксами Flash. Таким образом, FlashDebugElement реализует IDebugElement, FlashThread реализует IThread и так далее. Набор этих классов объединен в Java-пакет eclihx.debug.flash.

Запуск сессии Flash-плеера в режиме отладке происходит в классе eclihx.debug.flash.FlashDebug

Основной метод этого класса – метод run:

// Класс eclihx.debug.flash.FlashDebug

public void run(

 ILaunch launch,

 String buildFileName,

 String outputFolder) throws CoreException

{

}

Вызов этого метода происходит из класса FlashDebugRunner, определенного в модуле eclihx.launching. Параметр buildFileName – имя hxml-файла, при помощи которого была построена конфигурация отладки. Используя парсер параметров языка haXe, реализованный в модуле  eclihx.core, метод run получает имя отлаживаемого swf-файла. Наконец, объединяя полученное имя со значением параметра outputFolder, получается полный путь файла – uriPath.

Далее, используя класс Bootstrap и интерфейс SessionManager, происходит запуск FlashPlayer'а

SessionManager flashManager = Bootstrap.sessionManager();

Session debugSession = flashManager.launch(

                           uriPath, null, true, null);

Дальнейшее управление сессией осуществляется при помощи класса FlashDebugTarget, реализующего интерфейс IDebugTarget. Для этого объект debugSession передается конструктору FlashDebugTarget. Так как интерфейсы IDebugTarget и Session схожи, то реализация многих методов – простое делегирование запросов, например:

public boolean isSuspended() {

 return fSession.isSuspended();

}

Для регистрации сообщений от Flash-проигрывателя используется класс EventDispatchJob, который наследуется от класса org.eclipse.core.runtime.jobs.Job. Этот класс создает отдельный поток и проверяет очередь сообщений сессии при помощи метода Session.nextMessage().

На этом мы закончим обзор данного модуля, заметив, что мы не коснулись очень большого количества деталей, общих для многих отладчиков, например, необходимости регистрировать точки останова, поставленных пользователем во время редактирования текста, связывание элементов отладки с  их визуальным представлением, синхронизации состояния сессии и т.д. Более подробная информация о применении Eclipse Debug Framework для создания отладчиков, может быть получена из статьи “How to write an Eclipse Debugger.”[4].

4.7 Модуль eclihx.debug.ui

Наконец, обратимся к последнему модулю проекта EclihX. eclihx.debug.ui отвечает за интерфейс, доступный пользователю во время отладки приложения.

Плагин использует следующие точки расширения:

org.eclipse.debug.ui.debugModelPresentations

org.eclipse.core.runtime.adapters

org.eclipse.debug.ui.launchConfigurationTabGroups

Архитектура связи графического интерфейса с внутренним представлением отладчика довольно сложна. Это связано с тем, что Eclipse стремится сделать ядро отладчика максимально независимым от пользовательского интерфейса.

При помощи точки расширения org.eclipse.debug.ui.debugModelPresentations проект EclihX определяет, как будут выглядеть различные компоненты отладчика в платформе Eclipse.

Точка org.eclipse.core.runtime.adapters расширяет редактор кода на языке haXe, определенный в модуле eclihx.ui, возможностью отображать точки останова.

Точка org.eclipse.debug.ui.launchConfigurationTabGroups используется для того, чтобы определить интерфейс, предоставляемый пользователю при создании запускаемой конфигурации.


5. Заключение

Данная работа закладывает фундамент для создания интегрированной среды разработки для языка haXe на базе платформы Eclipse. Текущая версия среды предоставляет базовую функциональность, необходимую разработчику при создании приложений на языке haXe:

  •  Управление кодом проекта;
  •  Подсветка кода;
  •  Поиск и настройка компилятора haXe;
  •  Сборка проекта

Основным результатом работы стала поддержка функции визуальной отладки программ на языке haXe, скомпилированных в целевую платформу Adobe Flash 9.

Также в рамках данной работы были внесены изменения в код компилятора языка haXe, направленные на улучшение алгоритмов генерации отладочных инструкций. Эти изменения приняты автором языка и будут доступны в версии haXe 2.0


6. Список литературы

  1.  Eric Clayberg, Dan Rubel “Eclipse: Building Commercial-Quality Plug-ins, Second Edition” // Addison Wesley Professional, 2006
  2.  Erich Gamma, Kent Beck “Contributing to Eclipse: Principles, Patterns, and Plug-Ins” // Addison Wesley Professional, 2003
  3.  ActionScript Virtual Machine 2(AVM2) Overview [Electronic resource]
    Adobe System Incorporated, June 2007, April 2008
    http://www.adobe.com/devnet/actionscript/articles/avm2overview.pdf
  4.  Bjorn Freeman-Benson, Darin Wright, “How to write an Eclipse debugger” [Electronic resource]
    IBM, Bjorn Freeman-Benson, August 27, 2004
    http://www.eclipse.org/articles/Article-Debugger/how-to.html
  5.  Platform Plug-in Developer Guide [Electronic resource]
    IBM Corporation and others, 2000, 2007
    http://help.eclipse.org/help33/index.jsp
  6.  SWF File Format Specification Version 9  [Electronic resource]
    Adobe System Incorporated, May 2007
    http://www.adobe.com/devnet/swf/pdf/swf_file_format_spec_v9.pdf
  7.  Haxe Website http://haxe.org
  8.  Flex SDK http://opensource.adobe.com/wiki/display/flexsdk/
  9.  Mozilla Public Licence(MPL) http://www.mozilla.org/MPL/
  10.  Neko Virtual Machine http://nekovm.org/
  11.  The Caml Language http://caml.inria.fr/index.en.html
  12.  Windows Batch Files http://www.computerhope.com/batch.htm
  13.  График распространения Flash Player 9
    http://www.adobe.com/products/player_census/flashplayer/version_penetration.html
  14.  Eclipse Java Development Tools (JDT) http://www.eclipse.org/jdt/
  15.  OCaml Development Tool(ODT) http://ocamldt.free.fr/
  16.  Aptana IDE http://www.aptana.com/
  17.  MyMiniCity http://myminicity.com/
  18.  comapping.com http://www.comapping.com/ 
  19.  Alpha Bounce http://www.alphabounce.com/


Header

Tag

Tag

Tag

End Tag

Рис.  SEQ Рис. \* ARABIC 2 Структура swf-файла

Рис.  SEQ Рис. \* ARABIC 3 Пример разбора бинарного представления тега SetBackgroundColor

Бинарное представление тега SetBackgroundColor: 43 02 ff ff ff

ff ff ff - Белый цвет

43 02 - Заголовок тега

Происходит обмен байтов из-за little-endian нотации

02 43 = 0000 0010 0100 0011

Первые 10 бит – номер тега

00 0000 1001 = 9

Оставшиеся 6 бит – длина тега

00 0011 = 3

Компиляция

Опции haxe.exe

-swf

-swf-version 9

-main

пции haxe.exe

--dump-swf

.hx

.txt

haXe парсер

haXe лексер

haXe интерпретатор

AST

SWF parser

Text Writer

AST

SWF binary

writer

.swf

Рис.  SEQ Рис. \* ARABIC 5 Структура зависимости подключаемых модулей проекта EclihX

eclihx.core

eclihx.debug

eclihx.debug.ui

eclihx.launching

eclihx.ui

Рис.  SEQ Рис. \* ARABIC 4 Cхема использования haxe.exe при анализе генерируемых swf-файлов


 

А также другие работы, которые могут Вас заинтересовать

79802. Технология DVD в курсе мультимедиа лекций по дисциплине Компьютерная графика 8.37 MB
  Существует достаточно много интерактивных обучающих курсов, как правило, лабораторные работы, или различные виды материалов для дистанционного обучения. Особенностью данной работы является то, что подготовленный материал предназначается для очного образования и для потоковых лекций. Конечный продукт данной работы –DVD диск, который служит как вспомогательный материал для проведения лекций, но никак самостоятельный обучающий курс. Данный продукт повышает интерес студентов к читаемой дисциплине и повышает качество образовательного процесса.
79804. Создание общей дизайн-концепции полиграфии для Ивангородской детской музыкальной школы 1.55 MB
  Первый слой в файле – символ Ивангорода – крепость обернутая в клавиши фортепиано – прозрачное объяснение названия музыкальной школы – Ивангородская. Далее идет слой с текстом обтекающим лиру со всех сторон. Слой Lyer 12 находится ниже остальных и отвечает за нотный стан. Поскольку размер изображения очень большой первый слой был залит белым цветом а не оставлен прозрачным так как это визуально осложнило бы работу над элементами в целом.
79805. Создание интерактивного тренажера «Видеостудия» 4.24 MB
  Создание интерактивного тренажера «Видеостудия», необходимого для иллюстрирования лекционного материала, а так же для дополнения к практическим работам со средствами съемочной студии.
79806. Разработка устройства для измерения освещенности и коэффициента пульсации светового потока 4.02 MB
  Задача дипломного проекта заключается в разработке функциональной и принципиальной схем устройства, позволяющего произвести измерение освещенности в установленных пределах, а также коэффициента пульсации светового потока с погрешностью
79807. Разработка Программы-Робота для автоматического выполнения Биржевых операций с ценными бумагами 2.74 MB
  Разработка торгового робота (автомата), работающего в связке с торговой платформой QUIK, генерирующего сигналы для входа и/или выхода в короткие и/или длинные позиции, с возможностью установки стоп-заявок.
79808. Разработка программного средства криптографической защиты файлов и исследования современных подходов к построению блочных алгоритмов шифрования 3.45 MB
  В данной работе представлен обзор методов зашифрования и расшифрования файлов, методов аутентификации и противодействие атакам на зашифрованные данные. Приводится структура и тестирование рассматриваемого алгоритма шифрования, построенного на основе современных тенденций построения блочных алгоритмов шифрования.
79809. Фестиваль бардовской песни «Зелёные Сростки» 585 KB
  Открытие фестиваля. Итак цели исследования: Обобщение и систематизация теоретических и практических наработок в области режиссуры неофициальных элитарных празднеств на примере организации и режиссуры фестиваля АП; Исследование воздействия на сознание личности карнавальных ситуаций и методов воздействия ведущих к карнавализации сознания участников неофициальных празднеств.