Вот, компилятор GCC. Чуть-чуть не хватило лимита, чтобы залить на наш файлообменник.
Установка:
1) Распаковать в папку compiler
2) Перетащить на значок HiAsm файл install.his

[offtop]Не понимаю, зачем было делать пакет Modules на С?[/offtop]

debug в vbs не работает. Опция в make была включена с прицелом на будущее, если бы я разобрался со способом отладки.
Кроме delphi пакета, я бы ещё посмотрел на FASM пакет, где debug функционирует с некоторыми оговорками.

lev, а вы проверили прежде чем это утверждать?

Так как сам это делал, берусь утверждать обратное.

Не работает только анимация.

В моём не работала, прямо сейчас перепроверять лень.
Верю на слово, беру свои слова обратно.

[flood]Спасибо за мануал,
Вот, компилятор GCC. - не люблю такие файлообменники.
Лучше использовать этот - http://files.gameworld.kz/
Но все равно спасибо !
[/flood]

Редактировалось 5 раз(а), последний 2021-06-24 05:30:55

А что, отладка средствами HiAsm так необходима? Генерируй код, из make-библиотеки вызывай, например, сторонний эмулятор (или отладчик - что там ещё применяется).
Cosinus,
[flood]У меня там просто аккаунт, файл будет лежать 2 месяца после последнего скачивания. Если я что-то выкладываю временное, то ложу на tempfile.ru[/flood]

Netspirit,
[flood]
поддержим отечественного производителя 4shared.com файлы без регистрации на сайте хранятся 180 дней.[/flood]

А Вы без компиляции make.dll под свой проект хотели обойтись? Ну Вы даете... У меня к Вам деловое предложение. Вы хотите сделать свой проект, я свой. давайте я чем смогу помогу Вам, а Вы чем сможете мне. Если еще зубры-прорфи этого форума нам помогут, то дело пойдет. Жду Вашего ответа.
------------ Дoбавленo в 20.00:
Мне, также как и Вам, пригодится отладчик для моего проекта. Посему, предлагаю разобраться как реализована отладка в пакетах delphi и vbs. В пакете delphi разобраться предпочтительней, т.к. отладка полностью реализован.
Только давайте вынесем это обсуждение в отдельную, чтобы не зафлуживать эту. Надеюсь модераторы перенесут наши сообщения в новую тему. Предлагаю:
1) создать тему "Режим отладки для новых пакетов"
2) обсудить принципиальную схему отладки в Хасме.
Из моего небольшого опыта изучения отладки в пакетом Виндовс (delphi), схемы такова:
1) каждый "кубик" (элемент) компилируется в отдельный блок (объект), из которых и складывается конечная программа. И у каждого такого блока (объекта) есть некоторая функция (или несколько функций), которые добавляются в конечный код при компиляции для режима отладки. Одна и та же схема компилируется по разному для режима отладки и для обычного режима.
2) при компиляции в режиме отладки каждый готовый объект (блок) программы хранит в себе некоторую информацию об элементе ("кубике"), из которого он получился. Как минимум ИД элемента и/или ИД связи (еще не уточнял детали)
3) когда очередь, при выполнении программы, доходит до конкретного объекта, то этот объект шлет по сети (через UDP) некоторую информацию в среду Хайсм и останавливает выполнение программы до ожидания ответа от Хайсм.
Остальное, по-моему, не требует пояснений.
Для отладчика, работающего с Хайсм, нужно либо чтобы отладчик посылал нужную информацию через UDP (удаленная отладка), либо использовало некий плагин к среде (локальная отладка, которую придется сделать своими руками), либо оба этих варианта отладки в зависимости от настроек (универсальная отладка).
Каким путем пойдем?

Редактировалось 5 раз(а), последний 2021-06-24 05:30:55

Lehij73, я сейчас на работе. Если получиться, отвечу чуть позднее. А из этой темы наверное уходить не стоит, она для того и создана. FTCG, и все что с ним связано.
Вы правы! Не стоит переносить нашу дискуссию в отдельную ветку (только сейчас это осознал).
Я думал что для программы-дебагерра нужен некоторый язык сообщений, компилируемых в режиме выполнения debug=on. А потом подумал, а зачем городить огород, создавая еще один язык сообщений?.. Что если интерпретатор языка FTCG/RTCG вынести из codegen.dll в отдельный dll или exe файл, и пусть именно он занимается дебагом самого себя?
Конечно мы проиграем в скорости компиляции проектов, вызывая интерпретатор из отдельного dll. Но настолько ли критична скорость компиляции?
Зато:
1) упрощаем codegen.dll
2) стандартизируем FTCG/RTCG для любого пакета
3) решаем проблему дебага для любого пакета
Причем, писать интерпретатор FTCG/RTCG с нуля не надо. Достаточно грамотно "выковырнуть" его из исходника любой codegen.dll, и добавить интерфейсы для удаленной и локальной отладки.

Редактировалось 6 раз(а), последний 2022-09-20 04:18:48

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

Как идея, могу предложить проработать концепцию самих компонентов такого пакета: в главном компоненте ставится свойство, например, DebugMode=True. Затем делается компонент Debug. Этот компонент проверяет DebugMode и если True, выводит значения полученные из связи, в которой он находится, во время тестирования во внешнем отладчике. Каким образом он их выводит - это зависит от целевого языка (MessageBox, консоль, отдельное окно, ещё как-то...).

Переработать make-библиотеку, чтобы при нажатии на кнопку запуска она открывала полученный файл во внешнем отладчике и отображала наши отладочные сообщения. Этим же способом можно приостанавливать выполнение кода в указанном месте: компонент Debug должен сгенерировать код, который приостановит выполнение до ответа пользователя.

Переключив DebugMode=False, мы получим финальный код, пригодный к исполнению, без необходимости удалять расставленные Debug-и из схемы. Кроме того, можно включать/выключать отдельные компоненты Debug с помощью их свойства, например, Enabled.

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

Мне просто хочется сделать по максимуму что в моих силах для развития Хайсмса вв первую очередь. Проект этот молодой, живой и революционно меняющийся от версии к версии. В далеком будущем Хаймс может "научится" компилировать в машинный код и стать полноправным языком программирования.
Для своего проекта мне нужна отладка именно в Хайсмсе, и я постараюсь его сделать. ИМХО, такой отладчик может быть полезен в довольно большом количестве проектов.
------------ Дoбавленo в 14.40:

Вы правы, но не до конца.
Более того, если рассматривать FTCG только исключительно как генератор целевого кода, то Вы абсолютно правы. Но FTCG в пакете Windows не только генерирует код, но и эмулирует соответствующие этому коду действия и значения. Причем, великолепно с этим справляется.
Я хочу создать под Хайсм пакет ECMAScript с несколькими отдельными подпатеками. ИМХО, для эмуляции функций семейства данного семейства языков возможностей FTCG, думаю, хватит с головой.

Я просто не в курсе, а анимационная (или хотя бы обычная) отладка работает внутри FTCG-контейнера стандартного пакета?
Да и не забывай: в любом случае в стандартном пакете отлаживается исполнимый файл, а не код FTCG.