Классы в скрипте

DimaBr

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

Имеет ли смысл развивать этот проект, или в будущем всё же появится реализация классов в скрипте ???

muaddib

DimaBr написал: »

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

Имеет ли смысл развивать этот проект, или в будущем всё же появится реализация классов в скрипте ???

Вот пример:

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

DimaBr

Как можно использовать скриптовые классы в программе, если на момент компиляции о их существовании ничего не известно. Что-то вы путаете.
Можно легко использовать записи (record), учитывая что запись-простейший класс, хотя можно подумать и о реализации самих записей.

muaddib

DimaBr написал: »

Как можно использовать скриптовые классы в программе, если на момент компиляции о их существовании ничего не известно. Что-то вы путаете.
Можно легко использовать записи (record), учитывая что запись-простейший класс, хотя можно подумать и о реализации самих записей.

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

addClass(TPoint,'');

DimaBr

Добавил реализацию записей в скрипте, пример обновлен.

muaddib

DimaBr написал: »

Добавил реализацию записей в скрипте, пример обновлен.

Архив повержден

DimaBr

Пример обновлен.

muaddib

DimaBr написал: »

Пример обновлен.

Demo.rar - неожиданный конец архива

DimaBr

Не знаю, прекрасно качается и открывается
файлообенник

vlad-mal

Пример понятный, возможности замечательные.

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

Реакция разработчиков непонятна.

DimaBr

Спасибо огромное. Я уже думал что это вообще никому не нужно.

Михаил

Да, очень интересно было бы использовать такой функционал.

muaddib

DimaBr написал: »

Спасибо огромное. Я уже думал что это вообще никому не нужно.

Напиши здесь как можно использовать записи как классы, архив открыть не могу.

DimaBr

Архив открывается. Вот пара скринов:

DeusEx

Архив не открывается . Прошу, выложите еще раз, возникла потребность в классах и типах внутри скриптов. Спасибо.

DimaBr

Если вы думаете что в архиве есть исходники, то вы ошибаетесь. Был задан вопрос, на который никто так и не ответил.

-=Den=-

Скажите, а какое реальное использование у этих классов, кроме красивого обращения к полям ?

Мы практически ничего не можем сделать с такими классами, не переопределить методы, а уж тем более наследоваться от абстрактных классов.
Это фактически просто красивая обертка для объединения переменных.
То же самое и структуры, обычно когда просят добавить структуры в скрипт, имеют введу не обертку для доступа к переменным того же скрипта, а обертку для реальных структур, чтобы можно было использовать функции со структурами в качестве параметров для внешних функций. Что сделать на автоматизме не возможно, структуры это область данных доступ к которой осуществляется по смещению, которое считает компилятор.

А объявления в скрипте никакого функционала не добавляют, кроме "красивого" кода

DimaBr

>Скажите, а какое реальное использование у этих классов, кроме красивого обращения к полям ?
Реальное - например использование FastScript для выполнения программ написанных на Delphi, уменьшение повторяющегося кода.

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

>Что сделать на автоматизме не возможно, структуры это область данных доступ к которой осуществляется по смещению, которое считает компилятор.
Запись - это тот же класс без свойств и методов. Реализовав классы - легко реализуются структуры


Не в упрёк будет сказано, но FastScript остановился в развитии. Я понимаю, что он написан для FastReport и выполняет практически все его потребности, но раз уж вы позиционируете его как отдельный продукт стоит ли останавливаться на достигнутом ? Мне кажется многие бы хотели иметь в приложении полноценный Delphi-Scripter. Сделал Script.LoadFromFile('MyForm.pas') и всё работает. К тому же скорость FastScript ну совсем уж не Fast (

-=Den=-

DimaBr написал: »

Реальное - например использование FastScript для выполнения программ написанных на Delphi, уменьшение повторяющегося кода.

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

DimaBr написал: »

Если вы смотрели демку, то в первом наследовании это реализовано

Смотрел, я говорю не про доступ к полям предка, а про виртуальные функции и vmt.
Т.е. чтобы работала такая конструкция(а так же возможность вызова inherited).

type
TTest = class
  private
    fAAA: string;
    procedure SetA(Value: string); virtual;
  published
    property AAA: string read fAAA write SetA;
end;

TTest2 = class(TTest)
  private
    fBBB: integer;
  published
    procedure SetA(Value: string); overload;
    property BBB: integer read fBBB write fBBB;
end;

{ TTest }
procedure TTest.SetA(Value: string);
begin
  fAAA := Value;
end;

procedure TTest2.SetA(Value: string);
begin
 // do something
end;

// --------------------------------------------
var Test: TTest2;
begin
  Test := TTest2.Create;
//  Test.AAA := 'ГІГҐГЄГ±ГІ1';
//  Test.fAAA := 'ГІГҐГЄГ±ГІ2';
  Test.SetA('ГІГҐГЄГ±ГІ3');
  Test.BBB := 12345;
  ShowMessage(Test.AAA+' - '+IntToStr(Test.BBB));
  Test.Free;
end.

Иначе все это сводится до красивой обертки данных, о чем я и говорил.

DimaBr написал: »

Запись - это тот же класс без свойств и методов. Реализовав классы - легко реализуются структуры

В скрипте, да. А я говорю об обертке между кодом Delphi. Т.е. AddRecord(TRect) - невозможно, у TRect нет rtti.

DimaBr написал: »

Не в упрёк будет сказано, но FastScript остановился в развитии. Я понимаю, что он написан для FastReport и выполняет практически все его потребности, но раз уж вы позиционируете его как отдельный продукт стоит ли останавливаться на достигнутом ? Мне кажется многие бы хотели иметь в приложении полноценный Delphi-Scripter. Сделал Script.LoadFromFile('MyForm.pas') и всё работает. К тому же скорость FastScript ну совсем уж не Fast (

Скрипт компилируется в промежуточный XML, следовательно , чем больше код скрипта, тем дольше время исполнения.
К слову последние версии скрипта немного оптимизированы и исполняют большие скрипты быстрей чем предыдущие версии.
Для FS на данный момент можно сделать многое, если его переключить на новый rtti D2009-XE, т.е. автоматическое добавление всех динамических методов, событий , без AddEvent итд. Вот только теряется поддержка младших версий Delphi у которых бедный rtti.

tisker

DimaBr написал: »

Не в упрёк будет сказано, но FastScript остановился в развитии. Я понимаю, что он написан для FastReport и выполняет практически все его потребности, но раз уж вы позиционируете его как отдельный продукт стоит ли останавливаться на достигнутом ? Мне кажется многие бы хотели иметь в приложении полноценный Delphi-Scripter. Сделал Script.LoadFromFile('MyForm.pas') и всё работает. К тому же скорость FastScript ну совсем уж не Fast (

Не в упрёк будет сказано, это Вы остановились в развитии. При должном желании и усердии "Сделал Script.LoadFromFile('MyForm.pas') и всё работает" это уже давно работает, только немного головой надо подумать (читай покопать немного исходники FastScript).

И это "К тому же скорость FastScript ну совсем уж не Fast" ложь. Всё работает как надо если запускать скомпилированный предварительно скрипт. FastScript делает компиляцию в xml и потом уже её выполняет. Так вот, компиляция действительно не быстрая, но там как-бы скорость и не нужна...

Stalker4

tisker написал: »

Всё работает как надо если запускать скомпилированный предварительно скрипт.

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

DimaBr

tisker написал: »

"Сделал Script.LoadFromFile('MyForm.pas') и всё работает" это уже давно работает

Вы хотите сказать, что FS может проглотить файл с классами, секцией interface, initialization, fnalization, с "человеческой" секцией uses, с рядом лежащим файлом DFM ?
Тогда может я что-то пропустил ? Это всё уже реализовано ???

tisker написал: »

И это "К тому же скорость FastScript ну совсем уж не Fast" ложь.

Простой тест доказывает обратное, у меня FS выполняет 30 секунд, а Delphi меньше 1

var I: integer;
    X: extended;
begin
  for i := 0 to 10000000 do
    X := Sqrt(I);
  ShowMessage('1');
end.

DeusEx

DimaBr написал: »

Вы хотите сказать, что FS может проглотить файл с классами, секцией interface, initialization, fnalization, с "человеческой" секцией uses, с рядом лежащим файлом DFM ?
Тогда может я что-то пропустил ? Это всё уже реализовано ???
Простой тест доказывает обратное, у меня FS выполняет 30 секунд, а Delphi меньше 1

var I: integer;
    X: extended;
begin
  for i := 0 to 10000000 do
    X := Sqrt(I);
  ShowMessage('1');
end.

+1.

Никто не задумывался над вариантом компилировать код обычным delphi-компилятором, который генерирует машинный код? Компилировать pas файлы в библиотеки (dll) или приложения (exe) и запускать их из памяти?

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


p.s. архив все равно битый. Может стоит заархивировать его zip?
p.s.s. ответ на вопрос - да, конечно стоит.

DimaBr

DeusEx написал: »

Никто не задумывался над вариантом компилировать код обычным delphi-компилятором, который генерирует машинный код?

Для этого нужно таскать компилятор с собой + все дополнительные библиотеки

DeusEx

DimaBr написал: »

Для этого нужно таскать компилятор с собой + все дополнительные библиотеки

Скрипты обычно используются в достаточно крупных высоконагруженных системах, думаю проблема не в объеме компилятора и библиотек.
Например, в моем случае - объем не имеет значения, важна только скорость работы откомпилированных скриптов. (сервер ММОРПГ игры обслуживающий миллионы пользователей)

DimaBr

Это вы работаете в такой сфере, и других сфер не замечаете. Я, например уже сотне пользователей написал мини-скрипты в VBA, дабы сократить монотонную работу И думаю что таких как я - много, а программистов серверов ММОРПГ единицы.

-=Den=-

DeusEx написал: »

+1.

Никто не задумывался над вариантом компилировать код обычным delphi-компилятором, который генерирует машинный код? Компилировать pas файлы в библиотеки (dll) или приложения (exe) и запускать их из памяти?

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

А что мешает вам сделать это сейчас, непосредственно с использованием компилятора. Просто разнести логику скриптов на классы в разные DLL/BPL.
Распространение компилятора со своим приложением - нарушение лицензии, т.е. пользоваться таким скриптом могут только те, кто купил Delphi.

К слову для игр, компилятор Delphi далеко не самый лучший выбор. Текущие версии поддерживают простой набор команд x86, т.е. ни о какой оптимизации see или даже простого mmx и речи не идет. В вашем случае лучше использовать связку VC++ и Lua, и не ждать от интерпретатора, предназначенного в первую очередь для работы с отчетной системой компилируемого кода

tisker

написал: »

А что мешает вам сделать это сейчас, непосредственно с использованием компилятора. Просто разнести логику скриптов на классы в разные DLL/BPL.
Распространение компилятора со своим приложением - нарушение лицензии, т.е. пользоваться таким скриптом могут только те, кто купил Delphi.

К слову для игр, компилятор Delphi далеко не самый лучший выбор. Текущие версии поддерживают простой набор команд x86, т.е. ни о какой оптимизации see или даже простого mmx и речи не идет. В вашем случае лучше использовать связку VC++ и Lua, и не ждать от интерпретатора, предназначенного в первую очередь для работы с отчетной системой компилируемого кода

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

DeusEx

написал: »

А что мешает вам сделать это сейчас, непосредственно с использованием компилятора. Просто разнести логику скриптов на классы в разные DLL/BPL.
Распространение компилятора со своим приложением - нарушение лицензии, т.е. пользоваться таким скриптом могут только те, кто купил Delphi.

К слову для игр, компилятор Delphi далеко не самый лучший выбор. Текущие версии поддерживают простой набор команд x86, т.е. ни о какой оптимизации see или даже простого mmx и речи не идет. В вашем случае лучше использовать связку VC++ и Lua, и не ждать от интерпретатора, предназначенного в первую очередь для работы с отчетной системой компилируемого кода

Сервер не распространяется, поэтому такой вариант возможен. Об этом сейчас и думаю.

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

написал: »

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

Да, народ может и путает, но в моем случае БД используется только для постепенной загрузки данных в кеш-сервер, и дальше работа с кеш-сервером (также периодический дамп данных в БД обратно). И узкими местами в данный момент являются - количество поддерживаемых соединений, более 33000 пока не удается и вся нагрузка идет на процессор, который обрабатывает tcp-ip соединения. А если часто используемые скрипты тоже будут кушать процессор, то количество соединений еще больше упадет. Да, 33000 очень высокая цифра, но на нее никто и не ориентируется, в нашем случае достаточно будет 5000 игроков на 1 сервер, но тем не менее важно определить на сколько сильно влияет на производительность в целом каждый элемент системы.

Скрипты очень хорошо подходят для "квестов" (заданий). Но слабо подходят для реализаций интеллекта NPC, которых одновременно на сервере может находится более 10.000. Хотя мне был бы интересен вариант вынести логику NPC в скрипты и дать возможность сторонним разработчикам пробовать выстраивать свою логику, к тому же это полезно будет, если движок будет переносится для другой игры и логику придется менять.

Еще скрипты полезны тем, что многие обновления можно реализовать без перезагрузки сервера, это очень удобно

Ладно, не буду навязывать свои проблемы Кто ищет работу - есть вакансии (Киев)

DimaBr

написал: »

Без виртуальных методов и без их переопределения, это не возможно.
Т.е. чтобы работала такая конструкция(а так же возможность вызова inherited).

Специально для вас "взял новый напильник".

-=Den=-

DeusEx написал: »

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

Конечно, каждому свое
Просто если приложение оперирует большим потоком данных такими, как вектора и координаты, то лучше выбирать компилятор поддерживающий хотя бы mmx. Естественно все выбирается под конкретную задачу.
Насчет ассемблерных вставок, разве делфийский asm может обрабатывать команды mmx/sse (movups/movq/CVTPD2PS/CVTPD2DQ) ?
У меня он бывало и более простые инструкции x86 не принимал.

DeusEx написал: »

Скрипты очень хорошо подходят для "квестов" (заданий). Но слабо подходят для реализаций интеллекта NPC, которых одновременно на сервере может находится более 10.000. Хотя мне был бы интересен вариант вынести логику NPC в скрипты и дать возможность сторонним разработчикам пробовать выстраивать свою логику, к тому же это полезно будет, если движок будет переносится для другой игры и логику придется менять.

Еще скрипты полезны тем, что многие обновления можно реализовать без перезагрузки сервера, это очень удобно

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


DimaBr
Методы теперь вызываются, но вот полиморфизма нет.
Т.е. у вас жестко привязывается к типу объявленной переменной, а не созданного класса.
Достаточно поменять объявление Test2: TTest2 на Test2: TTest :

var Test: TTest;
    Test2: TTest;
begin
  Test := TTest.Create;
  Test2 := TTest2.Create;
  ShowMessage(Test.AAA+' - '+ Test2.AAA);
  Test.Free;
  Test2.Free;
end.

и функции у вас почему-то не работают:

type
TTest = class
  public
    function GetA: string; virtual;
end;

TTest2 = class(TTest)
  public
    function GetA: string; override;
end;

{ TTest }
function TTest.GetA: string;
begin
  Result := 'TTest';
end;

{ TTest2 }
function TTest2.GetA: string;
begin
  Result := 'TTest2/' + inherited GetA;
end;

// --------------------------------------------
var Test: TTest;
    Test2: TTest;
begin
  Test := TTest.Create;
  Test2 := TTest2.Create;
  ShowMessage(Test.GetA+' - '+ Test2.GetA);
  Test.Free;
  Test2.Free;
end.