Embedded Perl

[Guenther Sohler]

Hallo Rob, ( and all the Others).
Defintely I will have a look at the Inline::C Routine.
At the weekend I had a look at the XS Approch(without beeing able to read
the newsgroup before.
Unfortunately the XS Approach did not really fit into my concept.
Using XS sounded like creating an extra, external Module for perl.

My Intent is following:
* I have a C program with an embedded perl interpreter
* I want to use the perl interpreter to have a scripting language for my
program
* But I want to have special program-related perl commands that act on
my programs database. If I did not want this I could use a normal perl
interpreter from the beginning
* Therefore I somehow want to register C- callback functions under a
dedicated perl function name.

I have written a c callback function, which draws a rectangle. It is
called
draw_rectangle. Then I instanciate a perl interpreter in my C program.
Then I want instruct !!!! "C" !!!! to register the callback function as
a new perl_command "draw_rectangle".
Finally I instruct the perl interpreter to execute a script from a file.
I dont mind, if the c callback functio has to evaluate the perl stack,
but It would be fine, if my function was registered in the main
namespace(no :: in function name) and if there were no measures in the
perl program to load the draw_rectangle from an external module).

There are to reasons why I dont want my "draw_rectangle" from an external
perl module
* I dont want to keep my program as simple as possible - No extra
files if possible
* I fear, that the extern module is not able anymore to access the
program database as it is seperated from the main program


Who has the perfect solution for me ?

 

[Tassilo v. Parseval]

Also sprach Guenther Sohler:

Hallo Rob, ( and all the Others).
Defintely I will have a look at the Inline::C Routine.
At the weekend I had a look at the XS Approch(without beeing able to read
the newsgroup before.
Unfortunately the XS Approach did not really fit into my concept.
Using XS sounded like creating an extra, external Module for perl.

Not necessarily.

My Intent is following:
* I have a C program with an embedded perl interpreter
* I want to use the perl interpreter to have a scripting language for my
program
* But I want to have special program-related perl commands that act on
my programs database. If I did not want this I could use a normal perl
interpreter from the beginning
* Therefore I somehow want to register C- callback functions under a
dedicated perl function name.

So create an XSUB and compile it statically into your program embedding
the Perl interpreter.

The easiest way I can think of:

First create an ordinary XS module using h2xs and write your XS-code.
After doing 'perl Makefile.PL; make' have a look at the .c file
generated by xsubpp (alternatively you can just create the .xs file and
run xsubpp manually on it). From this file you copy all the transformed
XSUBs and the boot-section into your C program. XSUBs look like this:

XS(XS_Module__Name_function); /* prototype to pass -Wmissing-prototypes */
XS(XS_Module__Name_function)
{
...
}

And the special boot-function:

XS(boot_Module__Name); /* prototype to pass -Wmissing-prototypes */
XS(boot_Module__Name)
{
dXSARGS;
char* file = __FILE__;

XS_VERSION_BOOTCHECK ;

newXS("Module::Name::function", XS_Module__Name_function, file);
XSRETURN_YES;
}

The boot thing will register the XSUBs under a fully qualified function
name using newXS(). Since you said that you'd like to make the functions
available in package main, change this line to:

newXS("main::function", XS_Module__Name_function, file);

Your C program now only has to call boot_Module__Name() once after the
Perl interpreter has been constructed and initialized. Always call it
thusly:

boot_Module__Name(aTHX);

The only thing I am not quite sure of is whether the above will work out
of the box for an embedded Perl interpreter. But I think that the 'aTHX'
macro (and the invisible 'pTHX_' that is put in by the XS(name) macro)
handles passing the right Perl interpreter context to each function.

Tassilo

 

[Guenther Sohler]

Hallo Tassilo

Thank you for your tips.
I was able to downtrack the problem to a single function.

This works for me

newXS("main::rectangle", perl_rectangle, file);

but you have to call it AFTER parsing the file, else there will be a
segfault


rds

 

[Tassilo v. Parseval]

Also sprach Guenther Sohler:

Hallo Tassilo

Thank you for your tips.
I was able to downtrack the problem to a single function.

This works for me

newXS("main::rectangle", perl_rectangle, file);

but you have to call it AFTER parsing the file, else there will be a
segfault

Ah, ok. I assume that this is due to perl_parse() doing some necessary
preliminary work such as setting some of the PL_* variables to some
basic values. Most notably, perl_parse() initializes the main stash
(that is, the symbol-table) so it's indeed better to have an initialized
symbol table before making entries in there using newXS.

Tassilo