to post messages and comments.

Ломаем хаКс полностью. Читаем машинные коды как открытую книгу
Если haXe оттранслирован в C++, а из него — в машинные коды, это может показаться безнадёжным, тем более, на первый взгляд этот код пестрит вызовами виртуальных методов, которые, не запуская отладчик, трудно соотнести с адресами тел методов.

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

Рабочая заметка. Я просто оставлю это здесь.
Если Haxe (3.2.0) при попытке запустить в NekoVM на маке проект с Nape – ругается на uncaught exception, в xml проекта надо добавить:

<haxedef name="no-inline" if="neko" />
<haxedef name="dce=full" if="neko" />

Ошибка связана с тем, что проект слишком большой для неки.
Есть одно "но". После полного DCE и выключения инлайнов — он все равно может остаться слишком большим.
В некоторых случаях придется делать lime test mac и ждать компиляции, вместо lime test neko.

Оу йес. Я наконец-то сделал это. Поднял на крайней OS X полноценный стек haxe + flixel + neko + lime + openfl + hxcpp + работающий flixel-ui. Так как в смутном мире haxe традиционно стоит разброд и шатания (версия X библиотеки Y, не работает с компилятором версии Z)— задача была слегка нетривиальной.

Вопросы хаксоводам:
1. Действительно ли код универсален при компиляции в любой из доступных яп (прям написал один раз и откомпилял в десяток целевых яп разом), или все же приходится под разные целевые яп разные хаки/велосипеды/костыли использовать?
2. Насколько реально осилить его при реальном опыте прогпаммирования только на питоне?

Повтыкав недельку в код, который получается, если скомпилировать haXe через C++ в ARM, я уже могу нормально смотреть на эти инструкции. Благодаря неявной метаинформации haXe код читаю пока ещё не как открытую книгу, но всё же на удивление много информации получается извлечь. Собственно, самый интересный метод — это hx.Object.__Field, который в каждом классе переопределяется. Находить этот метод можно по VMT. Смещения в VMT я вычислил, вглядевшись в hx/Object.h и отметив там каждый virtual. Дальше у любого другого класса можно находить все те же методы, но __Field — самый интерсный. Если смотреть его реализацию, он сравнивает свой аргумент со всем, что есть в классе, и при совпадении создаёт завёрнутый в Dynamic объект. Если это было поле, он вызывает конструктор, который завернёт число, строку или объект в Dynamic, и так можно понять, по какому смещению и какого типа находится поле. Каждый метод haXe соответствует собственно его реализации в C++, а также есть невиртуальная обёртка, которая на вход получает аргументы типа Dynamic&, и результат у неё тоже Dynamic. В __Field оно идёт подряд — memcmp с названием методом, и если да, то обёртка заворачивается в Dynamic. Смотрим, что внутри обёртки, а там, допустим, в первых строках:

LDR.W R2, [R0,#0xEC]Это значит, что реализация метода будет по смещению EC. Так, прочесав реализацию __Field, можно понять структуру и экземпляров, и VMT. Кроме того, в Dynamic–обёртках для методов делается приведение типов к Dynamic и обратно, и так можно определить типы аргументов и результата. Тип аргумента–объекта видно по вызовам __dynamic_cast. RTTI G++ не богат, но там есть замангленное название класса, а по обратной ссылке (Xref) можно от RTTI перейти к VMT, в VMT найти __Field и тоже проименовать все функции. Таким образом, когда читаешь код метода, можно понять, с объектами какого типа он работает и какие методы аргументов косвенно вызываются. А вот с полями и результатами такое не получается. Надо полагать, в обратном направлении любой объект к hx.Object перед завёртыванием в Dynamic приводится без RTTI, поэтому нет __dynamic_cast, и его точный тип статическим анализом не определить так просто.

IDA грешит тем, что не всегда в теле __Field нормально определяет адреса названий методов и Dynamic–обёрток. Смотришь, а там тупо большие числа, что странно. Ситуацию усугубляет то, что смещения везде относительные. Во многих местах IDA эти относительные смещения нормально просчитывает, но в __Field очень часто почему–то — нет. Лечится Ctrl+R, "_GLOBAL_OFFSET_TABLE_", Enter на каждом странном большом числе.

OpenFL Setup Windows
In order to build Neko applications for Windows, no further dependencies are required. However, in order to build C++ applications for Windows, you must have a compatible version of Visual Studio C++ installed on your system.
Currently, OpenFL requires a version of Visual Studio capable of targeting Win32. For newer versions of Visual Studio, this requires the "Windows Desktop" version of the software.
Что у них вместо мозгов? Выбирать компилятор от Microsoft? Чем они вообще думали? У меня уже есть компилятор C++, интегрированный с компилятором Ады и есть совместимый с Delphi C++ Builder. Зачем кто–то тащит ничем не интересный компилятор от Microsoft?

Это уже напоминает Яндекс.Бар, производитель которого доплачивает тем, кто спамит этим УГ в своих программах.

You can only target Windows from a Windows system right now
Ну ещё бы. Думать же надо было

При попытке удаления обработчика события, который не был назначен, получаем сегфолт.
```
stage.removeEventListener(KeyboardEvent.KEY_UP, handler);
```

Разчехлил все свои старые и новые библиотеки и взялся все приводить в порядок. Ждите скоро bindx новый (в очередной раз), скоро глядишь и hml (mxml для хакса) зарелижу. Правда пока без биндингов будет. Ну или таки впилю ))) Параллельно выкатил пару своих наработок в отдельную либу, но там еще куча легаси кода и ноль тестов.

Вчера взялся обновлять try-haxe до адекватной версии хакса, оказалось что codeMirror не обновлялся там с мая 2013 года, обновление выявило полностью невалидный код. Из всех вариантов решил откатить CM обратно и попровить только версию компилятора

Haxe плагин собирается на ура, но вот компилить haxe проекты на отрез перестал. В plugin.xml прописан <compiler implementation="com.intellij.plugins.haxe.compilation.HaxeCompiler"/> но ни один метод в этом классе не вызывается ( В офф доке вопрос компиляции вообще не раскрыт confluence.jetbrains.com Пичаль

Это HaXe + nekovm + lime (и openfl целиком) на Asus TF101 (Android 4.0.3). Флэш и HTML5 таргеты собираются без видимых проблем.

Fuck, yeah! Я почти год эту связку пытался собрать под ведроидом хоть в каком-то виде. Недо-тутор напишу, ждите на haxe.ru

Сбацали тут игрушку на остро-политическую тему.
Собсно, вопрос (даже, просьба, скорее) к неспящим камрадам с мобильными девайсами: не могли бы вы потестить версию HTML5 и сказать что работает а что — нет? Особо интересуют ябло-устройства, т.к. хотя бы один ведроид дома есть.

Линки:

640x480: maidan.momingmy.tk
Во всё окно браузера: maidan.momingmy.tk

Флэш билд, на всякий случай, тут: maidan.momingmy.tk

Нативный Андроид-билд будет завтра, если кому интересно.
Нативный виндовый тоже, если он кому-то вообще нужен.
Нативных MacOS и iOS скорей всего не будет совсем, извините.
Линуксоиды — серьёзные ребята, им не до игрушек. :P

Ах, да! Слава Україні!

Товарищи, помогите, пожалуйста, решить проблему — не ставится OpenFL.


fzzr:~ ak$ haxelib install openfl
Downloading openfl-1,0,6.zip...
Download complete : 344919 bytes in 0.5s (622KB/s)
...
Current version is now 1.0.6
Done
fzzr:~ ak$ haxelib run openfl setup
Downloading openfl-tools-1,0,10.zip...
Download complete : 21205379 bytes in 66.6s (310.7KB/s)
...
Current version is now 1.0.10
Done
Called from flash/utils/ByteArray.hx line 713
Called from flash/Lib.hx line 233
Called from flash/Lib.hx line 308
Called from flash/Lib.hx line 180
Called from /usr/lib/haxe/std/neko/Lib.hx line 30
Uncaught exception — load.c(237) : Failed to load library
(....../libs/openfl-tools/1,0,10//ndll/Mac64/nme.ndll: mach-o, but wrong architecture)


Смотрел на github.com , всё как сказано ( gist.github.com ) сделал, суть беды вроде понимаю, но КАК это всё сделать правильно?

только в h2d я увидил максимально простую и понятную двух этапную систему валидации. дающую правильный результат для авторесайз контейнеров.

Портировал AS3 либу https://code.google.com/p/bezier/ на Haxe. На гитхабе все тесты плюс немного моих github.com Можно установить через haxelib install bezier

IDEA сказала, что не может найти стд, SL2 сказал что нет доступа из консоли все собирается тем же hxml файлом наотлично )

Очень редко стречаю использование необязательных аргументов в haxe. А особенно их интересное свойство. например

function ls(?path:String, ?patps:Array<String>);

который можно вызвать

ls("dirName);
ls("dirName", dirsList);
и даже
ls(dirsList); // без указания нулл для первого параметра.

по сути это такая перегрузка оператора в пределах одного оператора. Николас так часто делает, когда ожидается один элемент или массив элементов. Или когда ожидается переменных разных типов gotoAndPlay(?frame:Int, ?frameName:String)