Ну вот я и зарегистрировался !

Посему, вопрос как насчет
Innerfuse Pascal Script III + HiAsm ?

ИПС 3 Значительно МОЩНЕЕ и удобнее VBS
(Почти дельфи в дельфи )
Полное фриваре и сорцы в свободном доступе .
Единственная проблема - это как отучить ИПС
от VCL (у меня пока не вышло )
Есть упрощенная оболочка упрятанная в мной в DLL
но таскать с собой 246 кб ... (как это тоже не "кузяво" )

Или я опять окрыл "секрет полишенеля" и уже есть
нужный компонент ?.

PS
Innerfuse Pascal Script
: http://www.carlo-kok.com

ps1.3 компонент на базе IFPS
http://vdovin-av.narod.ru/

http://vdovin-av.narod.ru/Components.html

Возможности внутреннего языка
IFPS3 поддерживает:

Переменные, константы
Стандартные конструкции:
[code:1]Begin/End If/Then/Else,
For/To/Downto/Do,
Case x Of,
Repeat/Until,
While,
uses,
Exit,
Continue,
Break [/code:1]Функции (объявленные внутри и "снаружи" скрипта)
Стандартные типы: Byte, Shortint, Char, Word, SmallInt, Cardinal, Longint, Integer, String, Real, Double, Single, Extended, Boolean, Array, Record, Enumerations
Классы, импортированные из Delphi
Вызов функций внешних библиотек (dll)
Важное замечание: IFPS3 не поддерживает типы Pointer и конструкцию class.

Примеры:
[code:1]Program IFSTest; var
i: Longint;
Begin
for i := 0 to 9 do
begin
writeln('hello'+inttostr(i));
end;
End.

Program IFSTest;
var
b: Byte;
Begin
for b := 0 to 2 do begin
case b of
0: writeln('0');
1: writeln('1');
else writeln('>1');
end;
end;
End.

Program IFSTest;
// compile the demo application, minimize delphi and run this.
function FindWindow(C1, C2: PChar): Longint; external 'FindWindowA@user32.dll stdcall';
function ShowWindow(hWnd, nCmdShow: Longint): Integer; external 'ShowWindow@user32.dll stdcall';
function SetWindowText(hWnd: Longint; Text: PChar): Longint; external 'SetWindowTextA@user32.dll stdcall';
var
i: Longint;
wnd: Longint;
Begin
wnd := Findwindow('', 'Innerfuse Pascal Script III');
SetWindowText(Wnd, 'This is DLL demo, it calls some windows user32 routines. This will hide this window for a few seconds');
for i := 0 to 200000 do begin end;
ShowWindow(Wnd, 0); // hide it
for i := 0 to 200000 do begin end;
SetWindowText(Wnd, 'Wasn''t that nice?');
ShowWindow(Wnd, 5); // show it
for i := 0 to 200000 do begin end;
SetWindowText(Wnd, 'Innerfuse Pascal Script III');
End.[/code:1]

Дополнительные особенности
IFPS3 - по сути интерпретатор Pascal. Но он может компилировать программы в своеобразный Pi-код, который выполняется на порядок быстрее, чем если бы он сразу проводил выполнение программы (просто интерпретировал).

A еще есть paxScript
http://www.paxscript.com//
и
FastScript
http://www.fast-report.com/ru/products/products.php?BID=5

Все эти вещи имеют как было указано выше как минимум два недостатка:
1) Требуют VCL
2) Большой размер в любом случае.

Поэтому начиная со 142 билда в состав пакета будет входить компонент для написания скриптов на языках Basic и Java, входящих в состав Windows. Причем размер кода увеличивается всего на 10кб.

Не вижу принципиальных проблем для невизуальной
компоненты (даже не компоненты, а просто библиотеки!)
в преносе на КОЛ .



Судя по VCL версии в КОЛ будет от 20 до 50 кб .
(И если упрятать в DLL то будет очень даже скромно.)
Это с лихвой компенсируется значительным удобством и гибкостью .
(Классов нет но Оbject вполне фунциклирует
да и простой вызов любых внешних функций решает почти все проблемы )



Да, да! Все так, вот только с ФР пока не работает...

Да и зачем мне сразу ДВА разных ЯВУ ?
(А с учетом скиптов и идеологии НиАсм-а можно смело считать что
их будет же ТРИ. "Упростили", однако ! )

Кроме того Паскаль в скрипте значительно удобнее и нагляднее .

Новая верисия с новым названием RemObjects Pascal Script тут

http://www.remobjects.com

[url=http://www.remobjects.com/download.asp?id={C776EBA7-14C0-4861-B4DB-A3BB0085A55E}&nodownloadinfo=now]
Прямо на закачку [/url]

С FPC этот компонент действительно не работает, но упрятав в dll - заработает, т.ч. тут дело за малым.


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

В KOL скрипт занимать менее 50кб никак не может. Нынешний VBScript столько занимает, а он гораздо проще Pascal.

О идея
Бог с ними со скритами в рунтайме , но почему бы не
сделать компонент с возможностью делать прямые
вставки процедуры на паскале в схеме !

(В погоне за визуальностью все забыли что НiAsm
это надстройка над мощнейшим компилятором .)

Почему не дать доступ к его возможностям прямо из
среды дизайнера схем !

Это ведь ни как не отразится на тех кто незахочет
эту возможность использовать .

Просто обычный элемент схемы вроде Хаба
и клик на него открывает текстовый редактор
с шаблоном функции текст которой непосредственно
вставляется в генерируемый код .

AlexKir, попытались, немножко усовершенствовали идею, добавили к ней иконку, и получилось то, чего сегодня называется ЭЛЕМЕНТ

Все верно !

Но зачем нужен например матпарсер если
нет нужды в изменении формулы в РунТайм?

Не логичнее бы было просто вставить
эту формулу ПРЯМО в код!

Или зачем VBS если программист
просто хочет сделать расчет не меняя
его алгоритма в рунтайм ?

( Новый элемент каждый раз
создавать – это все же непроизводительно).

Нужны несколько уровней доступа к коду:
1) Вставить переменную
2) Вставить действие.
3) Вставить формулу.
4) Вставить функцию
И только пятым номером
5) Создать модуль(элемент)

Просто и быстро !

А вообще я думаю, что на самом деле, это старый
спор "Макросы против Процедур".
Но есть очень много ЯП в которых все это
мирно уживается.
(Даже в классическом Паскале есть макро - операторы
вроде Write/Read./Str...и т.д.)

Тем более смешно не применять возможности Макрогенератции в МАКРО ГЕНЕРАТОРЕ.

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

Спасибо за доверие !
Но есть сомнения в осуществимости такого
только на уровне компонентов .

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

Важен баланс между «свободой рук» и «свободой от рутины».
В HiAsm есть шанс выйти на новый уровень развития
«визуального конструирования» ПО и при этом сохранить
и даже облегчить «классическое программирование».






Я попробую сделать такой АнтиСрипт сам .
Но было бы неплохо если потом его интегрировать в дистрибутив.

Кстати, при отладке такого "скрипта" в ДизайнТайм
мог бы пригодится и IFPS для проверки кода ДО его
компиляции.

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

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

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

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

Кто Вам рассказал про "мощнейшесть" имеющихся компиляторов
Как-то обсуждали это на форуме, и я высказывал свое отношение к объему ИИ заложенному в компиляторы. Дельфи образован на уровне шестиклассника, а FPC - не выше третьего

У меня нет Дельфей. Когда надо разобраться, или слепить свое, нажимаю Ctrl+F на выделенном элементе, редактирую (например отладочный Message вклеиваю), сохраняю, переключаюсь в проект, запускаю (вообще-то чаще компилирую, ибо знаю - все начнется с ошибок синтаксиса )


Давайте с этого момента совершенно конкретно.
Делаете следующий INI-файл (ElementsconfExpression.ini):
И пишите следующие коды (ElementscodehiExpression.pas):
И все, этого достаточно. Надеюсь, понятно, где следует писать свою формулу. А назначение всего остального, как и INI-файла, как и неупомянутой иконки - исключительно интерфейсное. Ну вот такой интерфейс получился......
Можно теперь устанавливать эти одинаковые элементики в проект хоть целую толпу. (Правда, чтобы это делать из среды, необходимо его зарегистрировать - прописать в файле Elements.ini)

Рассуждаем дальше. Годится ли такой "шаблон" для канонизации
Вряд ли. Слишком мало степеней свободы. Кому-то захочется иметь нижнюю точку. А кому-то покажется, что верхняя точка - это пижонство. А раз элементов может быть много (так уж устроено в ООП), значит пусть будут параметры, разные для разных экземпляров класса. Есть вопросы нескольких входов и нескольких выходов. Ну и т.д.
Вобщем, надеюсь, что более подробно рассказал смысл фразы: