You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2001/03/05 03:42:39 UTC
Inline.pm and the future of XS
Doug,
I was wondering whether you have looked at Inline.pm that allows you to
embed C/C++ directly into Perl. Would it make any sense to use it in
mod_perl sources, or is it easier for you to write directly in XS than C?
Would it make sense to let others who aren't familiar with XS to use it in
mod_perl core? Or it makes no difference since you need to know Perl guts
anyway, and once you know them XS is easy?
Also what's your take on XS in the future of Perl/mod_perl, do you think
it'll stick around, or is there going to be something else coming to
replace it. I guess if I had the time to lurk around p5p I'd know the
answer... Thanks...
I've just received an email from Brian Ingerson, Inline.pm has won the
first award at German Perl Workshop... :)
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Inline.pm and the future of XS
Posted by Doug MacEachern <do...@covalent.net>.
On Mon, 5 Mar 2001, Stas Bekman wrote:
> Doug,
>
> I was wondering whether you have looked at Inline.pm that allows you to
> embed C/C++ directly into Perl. Would it make any sense to use it in
> mod_perl sources, or is it easier for you to write directly in XS than C?
i've looked at it, neat tricks, but does not make sense for mod_perl, nor
does swig.
> Also what's your take on XS in the future of Perl/mod_perl, do you think
> it'll stick around, or is there going to be something else coming to
> replace it. I guess if I had the time to lurk around p5p I'd know the
> answer... Thanks...
have a read of modperl_design.pod, i'm preparing to commit the code right
now.
i don't expect "xs" to go away anytime soon, tho perl 6 might use
something totally different. what might go away for mod_perl is the use
of xsubpp, which is really what defines the "xs language". and that
"language" is just a set of keywords and typemap. everything else is Perl
C API, which mod_perl will continue to use of course.
both swig and Inline.pm are very generic tools. the mod_perl generator is
specifically tuned for gluing Apache and allows for complete control over
everything, providing many things neither swig or Inline.pm are designed
to do.
Re: Inline.pm and the future of XS
Posted by Gerald Richter <ri...@ecos.de>.
>
> SB> some new library comes out tomorrow, it takes probably minutes to
write
> SB> the glue.
>
> SB> Of course it'll take the same time to do the same for XS gurus, but
> SB> remember that many aren't.
>
> The first time I had to make a Perl binding for a C library, it took
> me about 2 hours to figure out how to do it. Using XS to bind Perl
> directly to a C API is trivial. Making it perl-ish is the hard part.
>
Using Inline.pm may have taken you only one hour. It does a lot of things
for you that have otherwise to be done manualy. In my eyes it's a great
module for including small C Parts in a Perl program, like writing the glue
to a C library. For larger C projects like mod_perl or Embperl I still
prefer using XS, because it gives me more control over what is happening.
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
Re: Inline.pm and the future of XS
Posted by Vivek Khera <kh...@kciLink.com>.
>>>>> "SB" == Stas Bekman <st...@stason.org> writes:
SB> some new library comes out tomorrow, it takes probably minutes to write
SB> the glue.
SB> Of course it'll take the same time to do the same for XS gurus, but
SB> remember that many aren't.
The first time I had to make a Perl binding for a C library, it took
me about 2 hours to figure out how to do it. Using XS to bind Perl
directly to a C API is trivial. Making it perl-ish is the hard part.
Re: Inline.pm and the future of XS
Posted by Stas Bekman <st...@stason.org>.
On Mon, 5 Mar 2001, Matt Sergeant wrote:
> On Mon, 5 Mar 2001, Stas Bekman wrote:
>
> > Sounds cool, but what are the chances that it'll get into the main Perl
> > distro? If it doesn't it doesn't make sense to exercise to different
> > macro languages.
>
> What are the chances Inline.pm will make it in? Well actually probably
> higher since Brian works for ActiveState...
I believe that the chances are very high, and not because of AS.
If Inline.pm compiles the code on all platforms XS does, it makes much
easier for developers to embed C/C++/other for optimizations, when before
that they didn't do it as they had XS as a barrier. It's especially easy
to use if you need to write a glueing code for some existing C API, so if
some new library comes out tomorrow, it takes probably minutes to write
the glue.
Of course it'll take the same time to do the same for XS gurus, but
remember that many aren't.
So having a low entry point for better code and wider range of Perl
interfaces is a good reason to include Inline.pm in the core distro.
... but I guess we are drifting off the mod_perl topic here
> > IMHO, that's the main reason SWIG wasn't really adopted by the Perl
> > community. If you still need XS to distribute your code on XS, you learn
> > it anyway, so you use it.
>
> SWIG wasn't adopted because for many things it sucked :-)
>
> But yes, I totally understand your point. Hopefully by attacking from the
> XML standpoint, which the core perl people are starting to realise is an
> important part of where Perl needs to be, we might have a chance at that,
> but I'm not going to break my back trying to get it "core" sanctioned -
> they haven't added *any* significant new modules into core in a long time.
>
> Oh, and did I mention that MoC requires Python as a pre-processor right
> now - it kinda has that going against it too :-)
Oh, then it's probably doesn't even worth the effort to try to put it in.
The ego factor is too high :( but as long as it keeps cool people doing
cool things, let them do what they like or do it yourself, if you have
enough power/time...
Well, I'm sure that if you Matt will be in charge of it we will see MoC in
the next perl patch... Were you ever offered a marketing position ? :)
Moreover if you believe that AS has the power to change things, which I
believe is true, why don't you pitch MoC to Dick Hardt? These folks are
looking for new things and they are definitely into python...
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Inline.pm and the future of XS
Posted by Matt Sergeant <ma...@sergeant.org>.
On Mon, 5 Mar 2001, Stas Bekman wrote:
> Sounds cool, but what are the chances that it'll get into the main Perl
> distro? If it doesn't it doesn't make sense to exercise to different
> macro languages.
What are the chances Inline.pm will make it in? Well actually probably
higher since Brian works for ActiveState...
> IMHO, that's the main reason SWIG wasn't really adopted by the Perl
> community. If you still need XS to distribute your code on XS, you learn
> it anyway, so you use it.
SWIG wasn't adopted because for many things it sucked :-)
But yes, I totally understand your point. Hopefully by attacking from the
XML standpoint, which the core perl people are starting to realise is an
important part of where Perl needs to be, we might have a chance at that,
but I'm not going to break my back trying to get it "core" sanctioned -
they haven't added *any* significant new modules into core in a long time.
Oh, and did I mention that MoC requires Python as a pre-processor right
now - it kinda has that going against it too :-)
--
<Matt/>
/|| ** Founder and CTO ** ** http://axkit.com/ **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** mod_perl news and resources: http://take23.org **
\\//
//\\
// \\
Re: Inline.pm and the future of XS
Posted by Stas Bekman <st...@stason.org>.
On Mon, 5 Mar 2001, Matt Sergeant wrote:
> On Mon, 5 Mar 2001, Stas Bekman wrote:
>
> > Doug,
> >
> > I was wondering whether you have looked at Inline.pm that allows you to
> > embed C/C++ directly into Perl. Would it make any sense to use it in
> > mod_perl sources, or is it easier for you to write directly in XS than C?
> >
> > Would it make sense to let others who aren't familiar with XS to use it in
> > mod_perl core? Or it makes no difference since you need to know Perl guts
> > anyway, and once you know them XS is easy?
> >
> > Also what's your take on XS in the future of Perl/mod_perl, do you think
> > it'll stick around, or is there going to be something else coming to
> > replace it. I guess if I had the time to lurk around p5p I'd know the
> > answer... Thanks...
>
> Stas,
>
> While not really applicable to writing mod_perl - XS is the way to go for
> that I think, we have been working on something called Orchard in the
> perl-xml world. This defines a "little language" superset of C called
> Mostly-C (MoC). The language does things like transparently hides
> accessors and property access (hashes to you) which is really nasty in XS
> into a much more familiar "object dot property" method. It also has the
> nice feature that any code you write with it is instantly accessible from
> Python too, using the same data model. It also has built-in garbage
> collection (useful for circular refs) and a built in XML parser (which is
> about 10-20 times faster than XML::Parser).
Sounds cool, but what are the chances that it'll get into the main Perl
distro? If it doesn't it doesn't make sense to exercise to different
macro languages.
IMHO, that's the main reason SWIG wasn't really adopted by the Perl
community. If you still need XS to distribute your code on XS, you learn
it anyway, so you use it.
> We have a talk about it in the XML track at OSS CON, though I doubt we'll
> be going into too much detail about the internals being on the XML
> track. With any luck Nat might see value in including a refereed paper on
> it in the proceedings.
Sounds cool! Thanks for the head's up!
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Inline.pm and the future of XS
Posted by Matt Sergeant <ma...@sergeant.org>.
On Mon, 5 Mar 2001, Stas Bekman wrote:
> Doug,
>
> I was wondering whether you have looked at Inline.pm that allows you to
> embed C/C++ directly into Perl. Would it make any sense to use it in
> mod_perl sources, or is it easier for you to write directly in XS than C?
>
> Would it make sense to let others who aren't familiar with XS to use it in
> mod_perl core? Or it makes no difference since you need to know Perl guts
> anyway, and once you know them XS is easy?
>
> Also what's your take on XS in the future of Perl/mod_perl, do you think
> it'll stick around, or is there going to be something else coming to
> replace it. I guess if I had the time to lurk around p5p I'd know the
> answer... Thanks...
Stas,
While not really applicable to writing mod_perl - XS is the way to go for
that I think, we have been working on something called Orchard in the
perl-xml world. This defines a "little language" superset of C called
Mostly-C (MoC). The language does things like transparently hides
accessors and property access (hashes to you) which is really nasty in XS
into a much more familiar "object dot property" method. It also has the
nice feature that any code you write with it is instantly accessible from
Python too, using the same data model. It also has built-in garbage
collection (useful for circular refs) and a built in XML parser (which is
about 10-20 times faster than XML::Parser).
We have a talk about it in the XML track at OSS CON, though I doubt we'll
be going into too much detail about the internals being on the XML
track. With any luck Nat might see value in including a refereed paper on
it in the proceedings.
--
<Matt/>
/|| ** Founder and CTO ** ** http://axkit.com/ **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** mod_perl news and resources: http://take23.org **
\\//
//\\
// \\