Вот так? Что должно было произойти?



--- Добавлено в 2016-12-27 17:38:31



Спасибо. make_rtcg.dll да, батником в Delphi компилируется. Подставил в папку make, переименовал как нужно. Бац, бац - результат тот-же...

Редактировалось 1 раз(а), последний 2016-12-27 17:38:31

Если бы библиотека не загружалась, то вывелось бы сообщение об ошибке, а так все работает.

Очень жаль... Очень жаль, что на эту тему вы смотрите субъективно. А если взглянуть объективно, то вот вам живой пример: Я не программист, я экономист. В школе на Балгарских правца BASIC изучал. Первое высшее образование инженер АСУ (автоматизированные системы управления). Программирование как смежное направление изучал Pascal. Дополнительно для себя как любитель не профи, увлекался С++. Второе высшее экономическое и это моё профессиональное направление, как хобби FOREX. 10 лет назад я наткнулся на торговый терминал MetaTrader4 в котором торговую стратегию можно строить путём программирования на MQL. Тогда MQL был простеньким (14 зарезервированных слов и 122 функции) я его освоил за два вечера. Это было очень удобно, особо на отвлекаясь на грамматику программирования, можно было строить торговые стратегии. Но на сегодняшний день MQL5 очень сложный, гибкий язык. Фактически приближен к C++. И программируя на MQL5 зарываясь в нюансах грамматики и синтаксиса, мысли отвлекаются от построении стратегии. А учесть специфику, конъюнктуру и психологию рынка - это наука ни чуть не легче. HiAsm, в ознакомительных целях пробовал лет восемь назад. Покрутил, повертел... идея рисования программ как схему, тогда очень понравилась. Но особо не пригодилось. А после того как я наткнулся на заготовки Торопчина http://forum.hiasm.com/topic/57817, меня это сильно зацепило. Я не успокоюсь пока эту тему не доведу до приемлемого результата. Примерно год назад я FTCG освоил за пару вечеров. В течении пару месяцев FTCG_pack перебрал и дополнил. Начал на нём строить элементы MQL5_pack. Точнее доделывать, то что начал Торопчин. То что Торопчин начал разрабатывать эти пакеты, он конечно большой молодец... браво! Но то содержимое, которое в них есть - капля в море от того что в них могло бы быть. Именно по этому они не пользуются популярностью. А ведь про эти пакеты народ спрашивает, то тут, то там, на различных форумах раз за три месяца, до сих пор. Собственно говоря, причём тут RTCG??? А при том, что я столкнулся с некоторыми сложностями в FTCG, при разработки MQL5_pack. В силу своей простоты, возможностей FTCG не хватает. Схема, код получается очень громоздким, и при работе с переменными типа массив много сложностей, особенно многомерными. Именно по этому я решил всё с нуля сделать только на RTCG. А ведь таких как я (в большей или меньшей степенью владения языками прграмирования). Которым HiAsm с пакетами RTCG и MQL5 был бы очень интересен, порядка десяти тысяч юзеров, как минимум. Для чего оттачивать механизм создания нового пакета? Потому, что каждый из тех кто будет заинтересован пакетом MQL5 (каким бы он совершенным не был) полностью юзер удовлетворён не будет. Это примерно та же аналогия, что и в ФотоШопе - палитра инструментов. Хочешь ползуешся стандартной палитрой, не нравится настраиваешь под кривизну своих рук. Или создаёшь несколько новых палитр под решение задач на разные тематики, но во всё том-же MQL5.

Вот как, то так.

Может быть взять готовый пакет на основе RTCG, клонировать его и перековырять на RTCG_pack???

--- Добавлено в 2016-12-27 20:15:22



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

Редактировалось 3 раз(а), последний 2016-12-27 20:24:58

Вот этот пакет на RTCG построен http://svn.hiasm.com/packs/CNET/. Все библиотеки там лежат в сборке, можете попробовать.

brown-aleks, FTCG и RTCG всё это надстройки (по мне так излишние), лучше сделать упор для кодо-генератора целевого языка, т.е написать свою CodeGen.dll. Время конечно много уйдёт, но я думаю оно с лихвой окупится при написании компонентов на целевом языке а не при симбиозе как предлагается. По мне так это только и убило многие пакеты, т.к поддерживать их кому то ещё "это секс ещё тот"...

Поскольку

то более рационально в существующий CodeGen.dll добавить то, чего не хватает.

Ну, FTCG и пр. не от нечего делать придумали. Написание на целевом языке накладывает жесткие ограничения на строение компонента, что тянет за собой проблемы с оптимизацией целевого кода. Нет, предполагаю, можно написать кодогенератор так, чтобы он парсил исходники компонентов и строил окончательный код на основе каких-то шаблонов подстановки или макросов в файлах компонентов (типа препроцессора); плюс, код примитивных языковых конструкций (типа, конвертации типов, объявления локальных переменных и т.п.) был вшит прямо в кодогенератор. Но я не представляю себе этого.

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

Тут куда ни крути "и тат и там" самопал получается. Нужно было использовать интерфейсы для связи со средой, что бы не иметь проблем с другими ЯВУ. Но что сделано то сделано, я же против ничего не имею.

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

andrestudio, andrestudio, andrestudio,

Однозначно! Должна быть единая унифицированная модель. Которая служит про-родителем целевого кода. То есть при помощи которой создаётся инструментарий, которым в свою очередь создаётся целевой код. Но в каком виде подаётся эта модель? CodeGen.dll и всё?

К примеру бы для меня как для продвинутого пользователя (не программиста), было бы очень удобно, если я из рабочей панели HiAsm -> Сервис -> Редактор Палитры Элементов смогу создать новый пакет или новую палитру к уже существующему пакету - это раз. И наполнить вновь созданную палитру - элементами, в фирменном стиле HiAsm, не прибегая к написанию кода, а рисованием схемы каждого элемента. Пусть эти про-родительские элементы будут написаны на RTCG или ещё на каком _TCG уже значение не имеет - Это два. И останется для разработчиков совсем не много хлопот, поддерживать актуальность одного лишь пакета про-родительского. А Все остальные родительские пакеты будут плодиться как кролики в руках конечных юзеров - это три. То есть из этой цепочки от CodeGen.dll до целевого языка нужно исключить все моменты где конечный юзер должен прибегать к использованию кнопко-печатания кода или командных строк. Я глубоко убеждён, что в таком виде HiAsm получит гораздо большую популярность. Ну а там где популярность, там и место где снять dividendum найдётся.

brown-aleks, так именно для этого и создавались FTCG/RTCG (то, чего andrestudio считает сейчас лишним). Поскольку в этих пакетах элементы могут быть сколь угодно низкоуровневыми (т.е. один элемент может предоставлять из себя конкретную синтаксическую конструкцию языка), то в теории из них можно будет составить любой более сложный элемент, который не создаст код с сильно заниженной производительностью (как это происходит например в пакете Windows). Кроме того подавляющее большинство элементов (логические операторы, работа со строками, работа с массивами и т.д.) переносится между пакетами фактически с изменением только лишь названий операторов и функций, т.к. вся логика работы вынесена в скрипт FTCG\RTCG.

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

У меня остаётся только один вопрос - КОГДА ???

Сейчас используется API про которое в справке упомянуто в виде двух скудных страниц (даже с натяжкой назвать это как SDK нельзя)
1) Интерфейс кодогенератора
2) Интерфейс модуля Make

Да и интерфейсами как бы тоже нельзя назвать, обмен данными через процедуры и функции.
В COM интерфейсы как раз и предназначены для того чтобы стандартизировать обмен данными в приложениях разработанных различными ЯВУ.
(плагины достаточно успешно применяют эту технологию)

Насчёт что считаю "Лишним" пускай это будет моим субъективным мнением, и не надо к этому придираться, выводы то делаю на основании фактов. А факты таковы "Кто создал пакет, тот его и пишет, пока интерес к нему не потеряет" не больше и не меньше.

р.s (посему и подозреваю что в симбиозе что то писать желающих немного)

Если я ...\HiAsm\HiSvn.exe запускаю, CNET должен обновиться из http://svn.hiasm.com/packs/CNET/ правильно?

Работа не быстро, но идет


Интерфейс кодогенератора и модуля Make состоит всего из ~10 ф-ций и ни для какого обмена он не предназначен. Для общения кодогенератора и среды существует интерфейс CGT, ссылка на который приходит в ф-ции buildProcessProc кодогенератора и который полностью описан для Delphi и для C++ с комментарием к каждому методу.


Да, одно только - интерфейс разработан Microsoft для использования в продуктах Microsoft. А мы все же хотим иметь нормальную кроссплатформенную версию.


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


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