Использование компилятора в своих программах

← →
Unknown user © (2009-05-28 17:53) [0]

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

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

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

Если написать дебагер то можно будет ставить точки останова и смотреть значения переменных (если компилировать с отладочной информацией). Вообщем, получаем почти полноценную IDE прямо внутри своей программы.

Жду критики :)

← →
DVM © (2009-05-28 18:01) [1]

> Жду критики :)

Нафига именно КОМПИЛЯТОР то? Интерпретатора не достаточно? Есть же готовые реализации интерпретаторов в том числе и на паскале и для Delphi.

← →
Alkid © (2009-05-28 18:02) [2]

Ты хочешь dcc32 использовать для чего? Напрямую писать "скрипты" для своей программы на дельфи или использовать его как backend для своего встроенного языка?

← →
Юрий Зотов © (2009-05-28 18:03) [3]

> Например, делфийский dcc32

Нельзя. Нарушение лицензии.

← →
Unknown user © (2009-05-28 18:14) [4]

>Ты хочешь dcc32 использовать для чего? Напрямую писать "скрипты" для своей программы на дельфи или использовать его как backend для своего встроенного языка?

Писать скрипты на Делфи

>Нельзя. Нарушение лицензии..

Можно фрипаскалевский применить. dcc32 для примера взял.

>Нафига именно КОМПИЛЯТОР то?

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

← →
turbouser © (2009-05-28 18:16) [5]

> Unknown user © (28.05.09 18:14) [4]
> Писать скрипты на Делфи

RemObjects PascalScript http://www.remobjects.com/free.aspx

← →
oldman © (2009-05-28 18:37) [6]

Удалено модератором

← →
@!!ex © (2009-05-28 18:52) [7]

> [4] Unknown user © (28.05.09 18:14)
> Большая скорость, пошаговая отладка с просмотром значений
> переменныъ, строгая проверка синтаксиса, написание простых
> плагинов прямо из приложения. Ну это если еще дебагер добавить.

Для этого есть скриптовые языки. Много.

← →
VICTOR_ (2009-05-28 19:08) [8]

Есть такие компоненты (правда платные)
http://www.tmssoftware.com/site/scriptstudio.asp
Скачивал демо-версию - выглядит красиво.

← →
Сергей М. © (2009-05-28 20:56) [9]

> Unknown user

Ты там чего, брата Лазарю сотворяешь что ли ?)

← →
Unknown user © (2009-05-28 22:19) [10]

>Ты там чего, брата Лазарю сотворяешь что ли ?)

Нет, что-то попроще. Только для своих целей.

>Для этого есть скриптовые языки. Много.

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

Интересно, высказывалась эта идея кем-то раньше? И есть ли здесь кто-то кто меня поддерживает?

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

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

← →
DVM © (2009-05-28 23:09) [11]

> Unknown user © (28.05.09 22:19) [10]

> Согласитесь, нативный Делфи компилятор все равно выдаст
> более быстрый код.

Как правило, там где нужны скрипты, нет необходимости в сверхскоростях. Даже если и есть, то скрипты должны вызывать уже скомпилированный код. Пример - скрипты для пакетной или любой другой обработки изображений в Photoshop. Скрипты как правило служат для адаптации довольно гибкого движка к конкретным условиям работы. Для удобства они нужны.

← →
Rouse_ © (2009-05-28 23:26) [12]

> Если написать дебагер то ....
> Жду критики :)

Буду краток - пиши :)
Будет интересно, и тебе и нам (если реализуешь - будет что поанализировать)

← →
Petr V. Abramov © (2009-05-28 23:27) [13]

> Unknown user © (28.05.09 22:19) [10]

если стоЯт такие задачи, лучше посмотреть в сторону .Net или Java. Есть более-менее понятное API компилятора. А насчет скорости - JIT проблему почти решает.

← →
Petr V. Abramov © (2009-05-28 23:31) [14]

> Rouse_ © (28.05.09 23:26) [12]

это к [13]
что native, что CLR, что жабный дебаггер - гимр одного порядка. Не реализовывал, но изучал возможность та и там.

← →
Unknown user © (2009-05-29 00:05) [15]

>Будет интересно, и тебе и нам (если реализуешь - будет что поанализировать)

Пока нечего показывать. Сделал лишь парсер pas файлов и отображение полученного дерева в Code Explorer, также сделал управление компилятором и вывод ошибок компиляции с навигацией по коду. Пробовал ставить точки останова и получать значения переменных (пока лишь 4-х байтных, используя отладочную инфу в TD32 формате и JEDI Code Library).

>Как правило, там где нужны скрипты, нет необходимости в сверхскоростях.

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

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

Или, к примеру, скрипт, реализующий полный перебор всех объектов в документе (их может быть сотни тысяч) однозначно быстрым не будет, пусть даже для анализа объектов он будет вызывать скомпилированный код приложения.

>если стоЯт такие задачи, лучше посмотреть в сторону .Net или Java. Есть более-менее понятное API компилятора

Можно подробнее? Это API входит в Win API? Виртуальные машины действительно работают шустро, за счет on fly компиляции байт кода в машинный код при выполнении программы.

← →
Германн © (2009-05-29 00:54) [16]

> также сделал управление компилятором и вывод ошибок компиляции
> с навигацией по коду.

Кстати. Интересно мне. Сильно ли изменилась ситуация по сравнению с ТП? Ведь уже там была заложена возможность "вывода ошибок с навигацией по коду"?

← →
Игорь Шевченко © (2009-05-29 01:39) [17]

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

Вообще-то подобное делается сплошь и рядом в движках СУБД (может и еще где-то делается, просто эта область мне ближе и более или менее за много лет изучена). То есть, программы на ихнем псевдоязыке, будь то PL/SQL оракла или язык процедур Firebird компилируется в некий байт-код, каковой байт-код потом успешно интерпретируется исполнительным механизмом той самой СУБД. Я к чему это говорю - никто из мне известных не использует никакую нативную компиляцию - им интересно задействовать базовые механизмы самой системы, в случае СУБД - доступ и к данным и их изменение, сами механизмы в разумных пределах оптимизированы по быстродействию донельзя, причем, так как обычно СУБД многоплатформенные, то под каждую платформу имеется своя, соответсвующая платформе, оптимизация. А тот байт-код, в который превращаются программы на их языке - это клей между механизмами, который заставляет их работать в нужной последовательности нужным образом.

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

← →
SPeller © (2009-05-29 02:10) [18]

Владимир Кладов делал систему Collapse для компиляции работы с байт-кодом. Глянь вот это: http://kolmck.net/Collapse.zip , может поможет.

← →
Иа (2009-05-29 04:47) [19]

> это к [13]
> что native, что CLR, что жабный дебаггер - гимр одного
> порядка. Не реализовывал, но изучал возможность та и там.
>

Использовать в дотнете CodeDom это не гемор а настолько легко насколько мне кажется вообще можно.

compiler = CSharpCodeProvier.CreateCompiler();
results = compiler.CompileAssemblyFromSource(compileParams, myCodeText);
results.CompiledAssembly.GetType("MyType").InvokeMember("Execute", parameters);

Генерить сам код с помощью того же CodeDom можно легко и непринужденно.

← →
oxffff © (2009-05-29 09:00) [20]

> Unknown user © (29.05.09 00:05) [15]
> >Будет интересно, и тебе и нам (если реализуешь - будет
> что поанализировать)
>
> Пока нечего показывать. Сделал лишь парсер pas файлов

Какая у тебя грамматика LL или LR?

← →
Amoeba © (2009-05-29 11:27) [21]

Использование компилятора Delphi (dcc32.exe) в прикладных программах
http://www.delphikingdom.com/asp/viewitem.asp?catalogid=454

← →
Petr V. Abramov © (2009-05-29 11:55) [22]

> Иа (29.05.09 04:47) [19]

> Генерить сам код с помощью того же CodeDom можно легко и
> непринужденно.

генерить - да. А API дебаггера - жуть в ночи.

← →
Unknown user © (2009-05-29 15:07) [23]

>Какая у тебя грамматика LL или LR?

Честно не знаю :) Я не использовал научный подход, мне нужен был парсер и я сел и написал его. Если интересно могу выслать код.

>Использование компилятора Delphi (dcc32.exe) в прикладных программах

Читал. Эта статья как раз и натолкнула на размышления.

>Кстати. Интересно мне. Сильно ли изменилась ситуация по сравнению с ТП? Ведь уже там была заложена возможность "вывода ошибок с навигацией по коду"?

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

>Игорь Шевченко

Спасибо за подробное разъяснение. Но как известно все мощные СУБД стремятся к кросс-платформенности. А там где нужна кросс-платформенность, а интерпретатор не подходит в силу своей медленности, используют байт-код. Так устроена JAVA, так устроен Erlang. Достаточно написать виртуальную машину для каждой целевой платформы. Программы скомпилированные в байт-код имеют полную переносимость и выполняются фактически с той же скоростью, что и программы в нативных машинных кодах. Очевидно за этой технологией будущее. Подтверждение тому .NET.

Однако я к кросс-платформенности не стремлюсь. Очевидно для большинства задач действительно хватит интерпретируемого языка. Но если, используя нативную компиляцию получаешь все возможности интерпретируемого языка плюс намного большее быстродействие, то почему бы этим не воспользоваться? В качестве интерпретатора можно использовать Windows Script Host или, упомянутый выше, TMS компонент для Делфи, можно использовать и Fast Script. Однако в этом случае нужно будет создавать свою библиотеку функций для вызова из интерпретируемого языка. Используя Делфи достаточно будет подключить SysUtils или свой, уже готовый модуль.

Вообщем, я вижу много преимуществ такого подхода. Главным недостатком (который может в итоге обернутся достоинством) я вижу необходимость разбивать свое приложение на несколько процессов.

← →
Unknown user © (2009-05-29 15:11) [24]

>Ты хочешь dcc32 использовать для чего? Напрямую писать "скрипты" для своей программы на дельфи или использовать его как backend для своего встроенного языка?

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

← →
Игорь Шевченко © (2009-05-29 15:19) [25]

Unknown user © (29.05.09 15:07) [23]

Грубо говоря, используя компилятор нативного языка ты обеспечиваешь простой механизм написания Format C: /U

Оно надо ?

← →
Unknown user © (2009-05-29 15:29) [26]

>Грубо говоря, используя компилятор нативного языка ты обеспечиваешь простой механизм написания Format C: /U

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

← →
Игорь Шевченко © (2009-05-29 15:35) [27]

> Ну функции работы с файловой системой есть в любом более
> менее серьезном скриптовом языке.

На PL/SQL мне написать такую процедуру будет несколько затруднительно.

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

← →
Mystic © (2009-05-29 16:33) [28]

> Но если, используя нативную компиляцию получаешь все возможности
> интерпретируемого языка

Не все. Например, достаточно проблематично реализовать closure, Динамическое построение кода и т. п. Многие скриптовые языки имеют сборку мусора, удобные средства для работы ос списками, ...

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

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

← →
Иа (2009-05-29 17:25) [29]

> Игорь Шевченко © (29.05.09 15:19) [25]
> Unknown user © (29.05.09 15:07) [23]
>
> Грубо говоря, используя компилятор нативного языка ты обеспечиваешь
> простой механизм написания Format C: /U
>
> Оно надо ?

Решаемо - в .NET я компилированные классы запускал в их собственном appdomain с ограниченными правами. Никакого доступа к диску или к сети по их велению.

Иа (29.05.09 17:25) [29]

> Решаемо - в .NET я компилированные классы запускал в их
> собственном appdomain с ограниченными правами. Никакого
> доступа к диску или к сети по их велению.

Это и есть песочница, об чем писалось в [27]

Давая возможность писать код на Delphi и компилируя его штатным компилятором отследить такого рода проблемы будет крайне затруднительно, если вообще возможно

> [23] Unknown user © (29.05.09 15:07)
> можно использовать и Fast Script. Однако в этом случае нужно будет
> создавать свою библиотеку функций для вызова из интерпретируемого
> языка. Используя Делфи достаточно будет подключить SysUtils
> или свой, уже готовый модуль.

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

Провел небольшой тест на быстродействие. Сравнил в скорости выполнения два скриптовых движка, которые рекомендовали здесь выше: tmsScript и RemObjects Pascal Script. Использовал простенький цикл.

for i := 0 to 10000000 do i2 := I - 1; showmessage(inttostr(i2));

Результаты tmsScript - 15 сек, RemObjects Pascal Script - 45 сек. Хотя похоже, что первый просто устанавливает исполняющему скрипт потоку выше приоритет.

Аналогичный цикл в Делфи выполняется за 50 мс. Разница, как видим существенна.

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

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

<offtop>
Между прочим, похожее вполне может использоваться хоть в программах обработки векторной графики, хоть в авиабазах, если надо. Где-то (кажется в phyton"е) есть бибилиотека, генерирующая случайные числа на основе погодных прогнозов (качает с тырнета). Ну а случайные чисал много где нужны. :)
</offtop>

> [32] Unknown user © (29.05.09 22:10)
> То что в этих скриптовых движках называется компиляцией
> есть лишь парсинг исходных модулей с записью результатов
> в своем формате (не байт-код).

А вот это не пробовал?
http://paxcompiler.com

> А вот это не пробовал?
> http://paxcompiler.com

Попробовал, действительно на порядок быстрее работает. Интересно как авторы добились такого быстродействия?

> [35] Unknown user © (30.05.09 00:41)
>
> > А вот это не пробовал?
> > http://paxcompiler.com
>
> Попробовал, действительно на порядок быстрее работает. Интересно
> как авторы добились такого быстродействия?

Это компилятор в машинный код. Код получается несколько специфичным, но тем не менее. Если читал, в нём и отладчик уже есть готовый.

> [35] Unknown user © (30.05.09 00:41)
> Попробовал, действительно на порядок быстрее работает.

Не на порядок а в 1000 раз быстрее.:) Проверь в демке
http://www.paxcompiler.com/downloads/pax_tester.zip
свой цикл из

> [32] Unknown user © (29.05.09 22:10)
> for i := 0 to 10000000 do
> i2 := I - 1;

writeln(I2);

> Результаты tmsScript - 15 сек, RemObjects Pascal Script
> - 45 сек. Хотя похоже, что первый просто устанавливает исполняющему
> скрипт потоку выше приоритет.
>
> Аналогичный цикл в Делфи выполняется за 50 мс. Разница,
> как видим существенна.

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

> И язык богаче и возможностей больше.

LOL. Интрепретируемые языки значительно богаче, одна только объектная модель Java или Lua поражает, в нативных языках такое пока и не снилось.

Использование компилятора в своих программах Найти похожие ветки