PERL Miscellaneous - Embedded Perl

Author

Embedded Perl

Guenther Sohler

2005-04-25, 8:58 am

Hallo Rob, ( and all the Others).
Defintely I will have a look at the Inline::C Routine.
At the w

end 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

2005-04-25, 8:57 pm

Also sprach Guenther Sohler:

> Hallo Rob, ( and all the Others).
> Defintely I will have a look at the Inline::C Routine.
> At the w

end 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
--
use bigint;
$n=7142335034377028016139702633033737113
9054411854220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);

Guenther Sohler

2005-04-26, 8:58 am

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

2005-04-26, 8:58 am

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
--
use bigint;
$n=7142335034377028016139702633033737113
9054411854220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);

Sponsored Links