Вверх ↑
Этот топик читают: Гость
Ответов: 54
Рейтинг: 1
#16: 2016-12-27 17:20:51 ЛС | профиль | цитата
Dilma писал(а):
Попробуйте выполнить из командой строки в папке, где лежит CodeGen.dll

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



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

Netspirit писал(а):
Для этого существовала специальная сборка GCC. Но лучше возьми это: make dll template NS.zip.
Собирается имеющимся там же батником с помощью компилятора Delphi.
make_rtcg.dpr - это исходник библиотеки, можно править в блокноте.


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

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

0
Администрация
Ответов: 15295
Рейтинг: 1519
#17: 2016-12-27 18:57:21 ЛС | профиль | цитата
brown-aleks писал(а):
Вот так? Что должно было произойти?

Если бы библиотека не загружалась, то вывелось бы сообщение об ошибке, а так все работает.
карма: 27
0
Ответов: 54
Рейтинг: 1
#18: 2016-12-27 20:04:16 ЛС | профиль | цитата
Dilma писал(а):
Потому, что в этом смысла никакого нет. Если вы хотите сделать свой пакет, то знания языков вам необходимы. Если вы не знакомы с языками, то пакет вы не создадите - это будет пустая трата времени. Кроме того PackCreator упрощает лишь начальную конфигурацию и на работу кодогенераторов повлиять никак не может - это задача разработчика пакета, т.к. вы должны уметь собирать кодогенератор под вашу ОС ибо правится он регулярно, а делать актуальные сборки под Windows сейчас никто не будет.


Очень жаль... Очень жаль, что на эту тему вы смотрите субъективно. А если взглянуть объективно, то вот вам живой пример: Я не программист, я экономист. В школе на Балгарских правца 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

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


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

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

0
Администрация
Ответов: 15295
Рейтинг: 1519
#19: 2016-12-27 22:03:30 ЛС | профиль | цитата
brown-aleks писал(а):
Может быть взять готовый пакет на основе RTCG, клонировать его и перековырять на RTCG_pack???

Вот этот пакет на RTCG построен http://svn.hiasm.com/packs/CNET/. Все библиотеки там лежат в сборке, можете попробовать.
карма: 27
0
Ответов: 5227
Рейтинг: 587
#20: 2016-12-28 10:05:25 ЛС | профиль | цитата
brown-aleks, FTCG и RTCG всё это надстройки (по мне так излишние), лучше сделать упор для кодо-генератора целевого языка, т.е написать свою CodeGen.dll. Время конечно много уйдёт, но я думаю оно с лихвой окупится при написании компонентов на целевом языке а не при симбиозе как предлагается. По мне так это только и убило многие пакеты, т.к поддерживать их кому то ещё "это секс ещё тот"...
карма: 4
Мой форум - http://hiasm.bbtalk.me/ схемы, компоненты...
0
Ответов: 4629
Рейтинг: 749
#21: 2016-12-28 11:58:08 ЛС | профиль | цитата
andrestudio писал(а):
т.е написать свою CodeGen.dll

Поскольку
brown-aleks писал(а):
А при том, что я столкнулся с некоторыми сложностями в FTCG, при разработки MQL5_pack. В силу своей простоты, возможностей FTCG не хватает

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

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

0
Администрация
Ответов: 15295
Рейтинг: 1519
#22: 2016-12-28 12:05:52 ЛС | профиль | цитата
andrestudio писал(а):
(по мне так излишние), лучше сделать упор для кодо-генератора целевого языка, т.е написать свою CodeGen.dll.

Т.е. вы унификацию хотите заменить на зоопарк самопала? Во всем мире однако тенденция с точностью до наоборот идет и мне даже стыдно рассказать, почему единый формат лучше множества отдельных. Разве это не очевидно должно быть?
карма: 27
0
Ответов: 5227
Рейтинг: 587
#23: 2016-12-28 12:30:46 ЛС | профиль | цитата
Тут куда ни крути "и тат и там" самопал получается. Нужно было использовать интерфейсы для связи со средой, что бы не иметь проблем с другими ЯВУ. Но что сделано то сделано, я же против ничего не имею.
карма: 4
Мой форум - http://hiasm.bbtalk.me/ схемы, компоненты...
0
Администрация
Ответов: 15295
Рейтинг: 1519
#24: 2016-12-28 12:41:33 ЛС | профиль | цитата
andrestudio писал(а):
Нужно было использовать интерфейсы для связи со средой

А сейчас что используется? И кто проблемы со связью со средой имеет? Из того, что озвучивалось я лично слышал только "нехватка возможностей кодогенератора" и "не могу собрать то-то и то-то". Не могли бы вы привести ссылку на тему, в которой озвучена проблема связи со средой?
карма: 27
0
Ответов: 54
Рейтинг: 1
#25: 2016-12-28 13:11:49 ЛС | профиль | цитата
andrestudio, andrestudio, andrestudio,
Dilma писал(а):
Т.е. вы унификацию хотите заменить на зоопарк самопала? Во всем мире однако тенденция с точностью до наоборот идет и мне даже стыдно рассказать, почему единый формат лучше множества отдельных. Разве это не очевидно должно быть?


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

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

0
Администрация
Ответов: 15295
Рейтинг: 1519
#26: 2016-12-28 13:28:50 ЛС | профиль | цитата
brown-aleks писал(а):
И наполнить вновь созданную палитру - элементами, в фирменном стиле HiAsm, не прибегая к написанию кода, а рисованием схемы каждого элемента.

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

После того, как кодогенератор будет полностью закончен и обрастет всем необходимым для использования в любых целевых языках арсеналом можно будет уже внедрять функцию создания элементов пакета на этих же самых элементах.
карма: 27
0
Ответов: 54
Рейтинг: 1
#27: 2016-12-28 13:36:38 ЛС | профиль | цитата
Dilma писал(а):
После того, как кодогенератор будет полностью закончен и обрастет всем необходимым для использования в любых целевых языках арсеналом можно будет уже внедрять функцию создания элементов пакета на этих же самых элементах.


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

0
Ответов: 5227
Рейтинг: 587
#28: 2016-12-28 13:38:58 ЛС | профиль | цитата
Сейчас используется API про которое в справке упомянуто в виде двух скудных страниц (даже с натяжкой назвать это как SDK нельзя)
1) Интерфейс кодогенератора
2) Интерфейс модуля Make

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

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

р.s (посему и подозреваю что в симбиозе что то писать желающих немного)
карма: 4
Мой форум - http://hiasm.bbtalk.me/ схемы, компоненты...
0
Ответов: 54
Рейтинг: 1
#29: 2016-12-28 14:10:07 ЛС | профиль | цитата
Dilma писал(а):
Вот этот пакет на RTCG построен http://svn.hiasm.com/packs/CNET/. Все библиотеки там лежат в сборке, можете попробовать.


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

0
Администрация
Ответов: 15295
Рейтинг: 1519
#30: 2016-12-28 14:13:51 ЛС | профиль | цитата
brown-aleks писал(а):
У меня остаётся только один вопрос - КОГДА ???

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

andrestudio писал(а):
Да и интерфейсами как бы тоже нельзя назвать, обмен данными через процедуры и функции.

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

andrestudio писал(а):
В COM интерфейсы как раз и предназначены для того чтобы стандартизировать обмен данными в приложениях разработанных различными ЯВУ.

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

andrestudio писал(а):
Насчёт что считаю "Лишним" пускай это будет моим субъективным мнением, и не надо к этому придираться

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

andrestudio писал(а):
А факты таковы "Кто создал пакет, тот его и пишет, пока интерес к нему не потеряет" не больше и не меньше.

Вы действительно считаете, что это происходит исключительно потому, что пакет использует не те кодогенераторы? Не могли бы вы привести хотя бы пару пакетов в качестве примера, которые позволяли бы создавать нормальные приложения уже сейчас и которые не нужно бы было допиливать еще столько же, чтобы они начали выдавать хоть что-то полезное?
карма: 27
0
Сообщение
...
Прикрепленные файлы
(файлы не залиты)