Calling procedure of library via a script ?

[Fred vS]

Hello great fpc people.

Here the story :

A program uses a library.

That library is fpc and can be modified.

Is it possible to access procedures of the library with a variable from the main application ?

Something like this :

=> Library side :

Code: [Select]

library mylib;
...
procedure one_of_library_procedure(x, y, z : integer);  /// NOT EXPORTED
begin
// something...
end;

procedure run_procedure(theproc : string) ; cdecl;  /// EXPORTED
begin
run(theproc) ;  //// this the thing...
end;
...
export
run_procedure name 'run_procedure';
end.

=> Main program side :

Code: [Select]

...
run_procedure('one_of_library_procedure(2,4,5)') ;
...

Many thanks.

[skalogryz]

the described approach will work, as long as you're able to parse the passed script (theproc : string).
Thinks about the case

Code: [Select]

run_procedure('one_of_library_procedure((2+5)*getsomeval() div 4,4,5)')


is there a problem exporting the procedure?

btw, OpenGL is using "extensions" mechanism, to describe supported extensions. Each extensions comes with certain set of variables and functions - available as library exported functions.

Thus the main program would parse the extensions list and import functions based of the list. Is this is something you're looking for?

[marcov]

Very hypothetical it could work, but of course FPC in library form would hit FPC's GPL license that means that your main program also should be GPL compatible.

There are some practical problems to fix though:
- FPC has no "to memory" abilities only to disc. On most targets external assemblers and linkers are used that expect their input on disc. All this disc writing would be slow.
- FPC generates a new EXE or DLL, and has no facilities for running at all. You would have to engineer for loading and interfacing the compiled result into your own environment.

All of which is non trivial, which is probably why it is not done already.

[Fred vS]

@ marcov and skalogryz => many thanks => 

is there a problem exporting the procedure?

Hum, exporting the procedures is not the problem, but there are so much to declare that i would prefer to do it via variable.
That library uses AggPas and i want to find a trick to not export all the AggPas functions...
So if the developer want to use some AggPas procedures, he can call it via a variable.

Thus the main program would parse the extensions list and import functions based of the list. Is this is something you're looking for?

Maybe, not sure i understood what you explained...

Very hypothetical it could work, but of course FPC in library form would hit FPC's GPL license that means that your main program also should be GPL compatible.

Aaargh, not sure i understood that too, why this "calling procedures via variable" would alter the license ?

So, to resume, if a library uses AggPas, must each AggPas procedure be exported inside the library or is there a trick to uses that Aggpas procedures without exporting all the procedures ?

Many thanks.

Fred

[marcov]

Very hypothetical it could work, but of course FPC in library form would hit FPC's GPL license that means that your main program also should be GPL compatible.

Aaargh, not sure i understood that too, why this "calling procedures via variable" would alter the license ?

No integrating the compiler into your application would.  As DLL or not.

So, to resume, if a library uses AggPas, must each AggPas procedure be exported inside the library or is there a trick to uses that Aggpas procedures without exporting all the procedures ?

You are mixing too many things. In  Windows it must be exported. But while on Linux you might not need to, you only could get the function that way, and still need a declaration to call it.

But calling code in a string is near impossible.

[skalogryz]

But calling code in a string is near impossible.

But that's scripting task. That's what PascalScript is doing right now - not 100% Pascal compatible, but at least could do the trick.
However, using a pascal script or a built-in compiler would be to sluggish and an over-engineering for the task of exporting functions.

That library uses AggPas and i want to find a trick to not export all the AggPas functions...
So if the developer want to use some AggPas procedures, he can call it via a variable.

I certainty recommend the following:
* export all the AggPas libraries, and a way to determine what is the AggPas library version number. The version number will allow to identify what functions and what parameters are available.
* do not require a developer to use exported functions. If they find the need to use AggPas function directly they could always load the function reference in run-time.

[skalogryz]

Another alternative:

Code: [Select]

procedure RunProc(const nm: string; const params: array of const)
begin
  if (nm = 'one_of_library_procedure') and length(params=3) then
     one_of_library_procedure ( params[0], params[1], params[2])
  else if nm = 'another_library_procedure') and length(params=2) then
     another_library_procedure ( params[0], params[1] )
  ...
end;
completely eliminates a need of building and parsing of "the call string".

[marcov]

But calling code in a string is near impossible.

But that's scripting task. That's what PascalScript is doing right now - not 100% Pascal compatible, but at least could do the trick.

If Fred was asking for ways to let the user plug-in or parametrize the program with code, I'd steer him in the direction of scripting.

I didn't get that impression though, so I didn't want to confuse the picture with scripting.

[Fred vS]

Wow, lot ot very interesting things here... many thanks.

Now, with your help, i see better what i want and i will try to explain it.

In a normal world, when you create a library, you have to export each function/procedure you want be accessible.

Here a traditional library :

Code: [Select]

library mylib;
...
begin
...
procedure proc1(x, y, z : integer);  ///  EXPORTED
begin
// something...
end;

procedure proc2(x : string);  /// EXPORTED
begin
// something...
end;

procedure proc3(x : boolean);  /// EXPORTED
begin
// something...
end;
...
export
proc1 name 'proc1';
proc2 name 'proc2';
proc3 name 'proc3';
end.
You need a wrapper/header for your main program, with declaration of the exported procedures..
And your main application will use the library like this :

Code: [Select]

program myprog;
uses
...
mylib,   // the header of the library
...
begin
proc1(1,2,3);
proc2('yep');
proc3(false);
end.

In the not classical library,  only one procedure will be exported .
And that alone procedure will run script that call procedure who are part of the library, but NOT exported.

Code: [Select]

library mynotnormallib;
...
begin
...
procedure proc1(x, y, z : integer);  /// NOT EXPORTED
begin
// something...
end;

procedure proc2(x : string);  /// NOT EXPORTED
begin
// something...
end;

procedure proc3(x : boolean);  ///NOT EXPORTED
begin
// something...
end;

procedure run_lib_script(thescript : string) ; cdecl;  /// THIS IS EXPORTED
begin
fpc_run_script(thescript) ;  //// here run the script and HOW to DO that ?
end;
...
export
run_lib_script name 'run_lib_script'; /// only one procedure exported
end.
And your main application will use the library like this :

Code: [Select]

program myprog;
uses
...
mynotnormallib,   // the header of the library with only one exported proc.
...
begin
run_lib_script('proc3(false)');
run_lib_script('proc2('yep')');
run_lib_script('proc1(1,2,3)');
end.

Hum, is it possible ?

[skalogryz]

Hum, is it possible ?

it is possible.

[Fred vS]

it is possible.

Yep, great news (but i knew it, with fpc, everything is possible.) 

So => much easier because same syntax for all languages who use the library (C, python, delphi, basic, java,...) => unique universal library (only 2 exported procedures, one for classic native and one for java native) => possibility to use text-files for script => lot of other great things...

Hum, other little question...=> how to do it, what fpc command to use to run the script ? 

Thanks.

[skalogryz]

let me reiterate the bitter truth.
There's no built-in pascal language features to do that. (yet... let's give Embracradero a few more releases).
Reason is simple - Pascal is compiled language.

Thus, in order to execute a code passed in runtime via string, you'd need to use additional library that can do the script evaluation.

It can be:
FP Expression Parser
Pascal Script
Lua (extremely popular these days)
or a self written parser (as simple as get the name of routine, get list of parameters).

[skalogryz]

So => much easier because same syntax for all languages who use the library (C, python, delphi, basic, java,...) => unique universal library (only 2 exported procedures, one for classic native and one for java native) => possibility to use text-files for script => lot of other great things.

Some thoughts here. Languages would still need to import at least 2 functions. So if they can do it for two, they could do it for X-number of functions.
Would other language developers be happy to learn a new syntax? I doubt that.

Please condider debugging abilities for thr scripting feature. If a script hard to debug, it will be avoided

[marcov]

(I don't think he wants scripting. Rather maybe one exported procedure that sets a record with procedure variables?)

[Fred vS]

There's no built-in pascal language features to do that.

Aaaargh...

It can be:
FP Expression Parser
Pascal Script
Lua (extremely popular these days)
or a self written parser (as simple as get the name of routine, get list of parameters).

Ok, i will take a look (but it will be much heavier)...

Some thoughts here. Languages would still need to import at least 2 functions. So if they can do it for two, they could do it for X-number of functions.

More or less... Languages will need to import only one (of 2 available), one for Java programs (because of personal-exotic-native Java library syntax), one for all others.
But, yes, if it can be for 1, it can be for thousands too. 

Would other language developers be happy to learn a new syntax? I doubt that.

Hum, even if all the procedures are exported, they need to study the syntax of that new procedures => with the "script" way, of course they have to learn that syntax... but it will be the same for all languages.

Please condider debugging abilities for thr scripting feature. If a script hard to debug, it will be avoided

I agree, with scripting feature => difficult to debug the script.

(I don't think he wants scripting.)

Yep, i was hoping that script will be the miracle-solution, but if i must install external tools, that is not a light solution...

Rather maybe one exported procedure that sets a record with procedure variables

Hum, maybe that way ( how to ? ).... ?

PS : This is prototyping, maybe that idea is totally utopia and the "traditional way" (exporting all needed procedures) is the only realistic way.

PS2: I have perfect results with the "traditional way". I only try to find a more "universal" way.

Many thanks.

Fred

Many thanks.