C from Perl
Shishir K. Singh
I have a C program. In there is a function that I need for perl. This is the first time I am dealing with the C / Perl Interface. Is there any detailed reading material on how it's done ?? Any guidance would be highly appreciated.
Thanks
Shishir
Shishir K. Singh
-----Original Message-----
From: Nikola Janceski [mailto:nikola_...@summithq.com]
Sent: Tuesday, June 18, 2002 10:06 AM
To: Shishir K. Singh; begi...@perl.org
Subject: RE: C from Perl
What's the C function? Is it something standard in C?
Or did you/someone write it?
and the big question:
What does it do? (Most likely if it's general enough someone has written a
module for it in Perl).
> --
> To unsubscribe, e-mail: beginners-...@perl.org
> For additional commands, e-mail: beginne...@perl.org
>
----------------------------------------------------------------------------
--------------------
The views and opinions expressed in this email message are the sender's
own, and do not necessarily represent the views and opinions of Summit
Systems Inc.
Nikola Janceski
Chas Owens
Sight unseen I would say your best bet is the Inline::C module. If it
doesn't do what you need then you need to read perldoc perlxstut (the XS
tutorial), perldoc perlxs (The XS manual), and probably perldoc perlguts
(just what it sounds like).
--
Today is Prickle-Prickle the 23rd day of Confusion in the YOLD 3168
You are what you see.
Missile Address: 33:48:3.521N 84:23:34.786W
Ovid
> It's an custom function in a program. It has relevance to what I am doing and I don't have the
> heart to translate it in perl right now:) (it's a big function). I was hoping maybe I could
> perhaps adapt it to be called from the perl program. And nope, there is no module for that in
> Perl.
Shishir
As mentioned earlier, check out the Inline::C module. I wrote a bit about my experiences
embedding C in Perl with this module and you can find that here:
http://www.perlmonks.org/index.pl?node_id=135353. I might add that this is my personal favorite
post on that site :)
You can also check out the Inline mailing list at http://lists.perl.org/showlist.cgi?name=inline.
The can give you plenty of help on what you need to do to get started. It's *far* easier to use
Inline::C that XS or SWIG, so this is a good choice, if you can make it work for you.
Two quick points: make sure your C compiler is the same one that you compiled Perl with (gcc is
fine on a Linux box, for example) and have a copy of make.
Cheers,
Curtis "Ovid" Poe
=====
"Ovid" on http://www.perlmonks.org/
Someone asked me how to count to 10 in Perl:
push@A,$_ for reverse q.e...q.n.;for(@A){$_=unpack(q|c|,$_);@a=split//;
shift@a;shift@a if $a[$[]eq$[;$_=join q||,@a};print $_,$/for reverse @A
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
John W. Krahn
>
> Hi,
Hello,
You _might_ be able to use syscall.
perldoc -f syscall
John
--
use Perl;
program
fulfillment
Drieux
On Tuesday, June 18, 2002, at 07:45 , Ovid wrote:
[..]
> Two quick points: make sure your C compiler is the same one that you
> compiled Perl with (gcc is fine on a Linux box, for example) and have a
> copy of make.
>
> Cheers,
> Curtis "Ovid" Poe
p0: thanks for the URL's - since they help the general learning.
p1: Traditionally I am accustom to seeing a stack of '*.c' files
each of which covers a sepecific set of 'functions' that are closely
related - with the obligatory
main.c
where main() is stuffed.
hence if Shishir has already broken out these 'big functions'
into such a stack of files - the port will be simpler - as
you suggest. But harder if it is all in one big
myApp.c
file that doesn't allow make to make only the bits that one
is tweeking....
p2: the alternative quandery here is whether the process of
generating up the
libfoo.so
to stash the 'really cool bits' native in 'C' is better? faster?
Cheaper? to maintain???? Or should one use the h2xs to gin up
the specifics into a *.bs set?????
ciao
drieux
---
Shishir K. Singh
main.c
>where main() is stuffed.
> myApp.c
> libfoo.so
>ciao
>drieux
So what's the verdict guys?? Which way is better??
---
Chas Owens
> So what's the verdict guys?? Which way [Inline or XS] is better??
</snip>
Inline is better if you have a compiler on your prod box and don't mind
a slight performance hit at startup (it has to compile the code).
XS is the way to go for existing libraries and when you don't have a
compiler on your target box (mostly windows machines, but I have seen
some production Unix boxes that didn't have either a native compiler or
gcc).
--
Today is Setting Orange the 24th day of Confusion in the YOLD 3168
Hail Eris!
Drieux
On Wednesday, June 19, 2002, at 11:47 , Chas Owens wrote:
> <snip>
>> So what's the verdict guys?? Which way [Inline or XS] is better??
> </snip>
[..]
> XS is the way to go for existing libraries and when you don't have a
> compiler on your target box (mostly windows machines, but I have seen
> some production Unix boxes that didn't have either a native compiler or
> gcc).
I fear that this is going WAY off the deep end - but thought
I would ask you about my other concern here -
We have code_line_foo - that the vendor has up gunned to
deliver not only the source code that builds the specific
middleware suite - but also provides a mechanism for doing
the dynamically loadable -
libfoo.so
That can be installed on the production hosts. Or one can
build their client applications against the
libfoo.a
and do all the resolution at build time...
If I were writing the Perl Module Extention - should I write it
with the expectation that I am going to do the dynamic linking
to libfoo.so - OR - do the h2xs to "statically build" the
Perl Module itself against the libfoo.a ...
My expectation is that we are going to lock-step the
release of Perl Modules to the release of libfoo.a stuff anyway,
just as we do with lock stepping the release of java JNI stuff...
ciao
drieux
---
When we started worrying about going from simple stacks of
lines of code when perl was but a 'scripting language' - we
opted to make the mistake of allowing 'subs' to hide stacks
of lines of code 'internal' to the 'script' - then completely
fell off the band wagon when we started to allow 'libraries'
of just stacks of functionality - to hide the stacks of lines
that we never wanted to write again, nor cut and paste into
the next script - which lead to Perl Modules - so that we could
select sub-sets of just stacks of functionality - so that we
could put more in the Module - but use only what we wanted.....
and it's all turtles, turtles,
turtles all the way down.....