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

← →
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 с ограниченными правами. Никакого доступа к диску или к сети по их велению.

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

Иа (29.05.09 17:25) [29]

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

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

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

← →
AndreyV © (2009-05-29 20:22) [31]

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

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

← →
Unknown user © (2009-05-29 22:10) [32]

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

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

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

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

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

← →
TUser © (2009-05-29 22:24) [33]

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

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

← →
AndreyV © (2009-05-29 23:24) [34]

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

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

← →
Unknown user © (2009-05-30 00:41) [35]

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

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

← →
turbouser © (2009-05-30 01:16) [36]

> Unknown user ©

а почему бы и не FPC?

← →
AndreyV © (2009-05-30 01:20) [37]

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

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

← →
AndreyV © (2009-05-30 01:48) [38]

> [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);

← →
Petr V. Abramov © (2009-05-30 11:57) [39]

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

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

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

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

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

Вы таки понятия не имеете, что такое байт-код.

← →
_oxffff_ (2009-05-30 18:59) [43]

>@!!ex © (30.05.09 12:03) [40]
> Интрепретируемые языки значительно богаче, одна только объектная
> модель Java поражает,

C этого момента поподробней пожалуйста.
Надеюсь модель JAVA измеряется не в деньгах вложенных в модель JAVA.

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

Действительно, посмотрел детальнее. Полноценный компилятор. Постарались ребята. И функционал дебагера больше, чем в упомянутых выше интерпретаторах. Использовал paxcompiler в своих проектах? Интересно услышать отзывы.

> Вы таки понятия не имеете, что такое байт-код.

> Байт-код называется так, потому что длина каждого кода операции
> — один байт, но длина кода команды различна. Каждая инструкция
> представляет собой однобайтовый код операции от 0 до 255,
> за которым следуют такие параметры, как регистры или адреса
> памяти.
>

Это из wiki. Видим, что байт-код это двоичный формат но никак не XML дерево, которое создает компилятор RemObjects при парсинге скрипта.

> <Operations>
> <Operation Name="Sum" UID="{D9821C1A-A084-4120-
> 93F3-BCE6CF2AE0F4}" Documentation="">
> <Parameters>
> <Parameter Name="A" DataType="Integer" Flag="In"
> />
> <Parameter Name="B" DataType="Integer" Flag="In"
> />
> <Parameter Name="Result" DataType="Integer" Flag="Result"
> />
> </Parameters>
>

Может он умеет генерить и сохранять также байт-код. Не разбирался.

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

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

> А если скрипт считает НДС в десктопном приложении, разницу
> никто не заметит.

Нет, не НДС. Приложение работает с векторной графикой, векторных объектов может быть очень много, из скрипта нужно обеспечить доступ к каждому объекту документа. Скорость очень важна. Есть опыт использования Fast Script. Результат не удовлетворил. Работает медленно.

> [43] _oxffff_ (30.05.09 18:59)
> C этого момента поподробней пожалуйста.
> Надеюсь модель JAVA измеряется не в деньгах вложенных в
> модель JAVA.

Честно говоря мне лень это разжевывать. ОДин пример, который лично мне доставляет: Возможность в Lua переопределить метод в конкретном экземпляре класса. Ну и само понятие таблицы вещь ИМХО чрезвычайно гениальная.

> Это из wiki. Видим, что байт-код это двоичный формат но
> никак не XML дерево, которое создает компилятор RemObjects
> при парсинге скрипта.

Вот так и пишите "RemObjects не создает байт кода".
Фраза "в этих скриптовых языках называется компилцией" вызывает недоумение. Кстати, наверняка и RemObjects тоже создает байт код, в случае использования байт кода огрмный прирост производительности(говорю как чиловек писавший собственный скриптовый движок(проект Shootiah в инете доступен)). Врядли они принебрегли таким инстурментом.

> Мне, пожалуйста, без виртуальной машины. Или чтобы она была
> интегрирована в скриптовый движок.

Я таки за Lua. :) ВМ встроенная.

> [44] Unknown user © (30.05.09 19:50)
>
> > Не на порядок а в 1000 раз быстрее.:) Проверь в демке
> > http://www.paxcompiler.com/downloads/pax_tester.zip
> > свой цикл из
>
> Действительно, посмотрел детальнее. Полноценный компилятор.
> Постарались ребята. И функционал дебагера больше, чем в
> упомянутых выше интерпретаторах. Использовал paxcompiler
> в своих проектах? Интересно услышать отзывы.

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

Однако

> [42] @!!ex © (30.05.09 12:14)
> > Аналогичный цикл в Делфи выполняется за 50 мс.
>
> Lua
> function Test_Func()
> i2 = 0;
> for i=0,10000000 do
> i2 = i - 1;
> end
> end
> 844 мс

Т.е. уже всего на порядок хуже, но такая проверка, конечно не показатель.

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

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

> Честно говоря мне лень это разжевывать. ОДин пример, который
> лично мне доставляет: Возможность в Lua переопределить метод
> в конкретном экземпляре класса. Ну и само понятие таблицы
> вещь ИМХО чрезвычайно гениальная.

Акцент делался на Java. Там, насколько я знаю, VM близка к императивной.

> @!!ex © (30.05.09 23:57) [45]
> > [43] _oxffff_ (30.05.09 18:59)
> > C этого момента поподробней пожалуйста.
> > Надеюсь модель JAVA измеряется не в деньгах вложенных
> в
> > модель JAVA.
>
> Честно говоря мне лень это разжевывать. ОДин пример, который
> лично мне доставляет: Возможность в Lua переопределить метод
> в конкретном экземпляре класса. Ну и само понятие таблицы
> вещь ИМХО чрезвычайно гениальная.

Честно говоря мне трудно слушать бред про другую объектную модель.

> @!!ex © (30.05.09 23:57) [45]
> > [43] _oxffff_ (30.05.09 18:59)
> > C этого момента поподробней пожалуйста.
> > Надеюсь модель JAVA измеряется не в деньгах вложенных
> в
> > модель JAVA.
>
> Честно говоря мне лень это разжевывать.

Если ты внимательно читал мой пост.
Я тебя спросил про объектную модель JAVA.
Хотелось бы услышать про ее богатую объектную модель.
Уж снизойди с небес и приведи аргументы.

> Это из wiki. Видим, что байт-код это двоичный формат но
> никак не XML дерево, которое создает компилятор RemObjects
> при парсинге скрипта.

чего чего там RemObjects создает? по подробней пожалуйста, с примерами.

> [48] oxffff © (31.05.09 16:55)
> Честно говоря мне трудно слушать бред про другую объектную
> модель.

Уйди и не слушай. Мне трудно слышать ваши излияния и срач в каждой ветке по 50 постов. Я стараюсь игнорировать, чего и вам желаю.

> [52] oxffff © (31.05.09 18:33)

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

> @!!ex © (31.05.09 18:50) [53]

Не волнуйся ты так.
Посмотри на CIL набор .Net.
Ты увидишь что ничего из сверх ООП там нет.

Если ты прочитаешь
Technical Overview of the Common Language Runtime
(or why the JVM is not my favorite execution environment) Erik Meijer and Jim Miller

То увидишь, что .NET поддерживает обобщенную операцию копирования типа с версии 1.0. Чего нельзя сказать о JAVA.

Поэтому в .NET и уж тем более JAVA нет ничего сверх ООП.

>Честно говоря мне лень это разжевывать.

Представь если все будут так писать. Будет ли польза от форума?

>чего чего там RemObjects создает? по подробней пожалуйста, с примерами.

Я не изучал тщательно RemObjects. Сразу откинул его из-за медленности интерпретатора. Рекомендую paxcompiler, имеется встроенный дебагер, можно писать не только на паскале но и на бейсике. Мне он больше всего понравился из перечисленного.

> Я не изучал тщательно RemObjects.

И что? Фразу про построение компилятором XML дерева ты просто так что ли сказал, для умности?

> Рекомендую paxcompiler,

Я просил мне что то порекомендовать?

> имеется встроенный дебагер

Что такое встроенный дебаггер? Инструменты отладки? Таковые есть и у RemObjects, и hint"ы там есть и warningi, помимо них есть и препроцессор.

> можно писать не только на паскале но и на бейсике

а используя msscriptcontrol, можно писать на множестве диалектов.

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