Thoughts from TPC: Inlined ext/ modules
Michael G Schwern
As mentioned earlier, XS is kinda nasty. Inline::C automates a lot of it.
Ingy has made the suggestion that if Inline::C is in 5.9 we can eliminate
much of the XS code from the modules in the ext/ directory and make things
much, much simpler.
--
Michael G. Schwern <sch...@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <per...@perl.org> Kwalitee Is Job One
You see, in this world there's two kinds of people. Those with loaded
guns, and those who dig. Dig.
-- Blondie, "The Good, The Bad And The Ugly"
Dan Sugalski
>More chronicles from TPC.
>
>As mentioned earlier, XS is kinda nasty. Inline::C automates a lot of it.
>Ingy has made the suggestion that if Inline::C is in 5.9 we can eliminate
>much of the XS code from the modules in the ext/ directory and make things
>much, much simpler.
I think that would be a bad idea, unless Inline will generate the
code and build the shared library at module build time. (And if it
does, ignore the rest of this)
With XS as it stands, the cost to build the module is entirely
front-loaded--it's paid at perl build time and that's it. Yeah, it
can be a pain (though not really a big one, but I'm a bit biased) but
it's a pain paid by one or two people doing the maintenance.
With inline code, you run the risk of potentially rebuilding the
module with every invocation (which, while unlikely, is still a
possiblity) and that can get awfully pricey. Also, it means that
systems that don't have a C compiler (because they grabbed a prebuilt
perl) or whose C compiler has changed sufficiently from when perl was
built may run into the case where they can't use modules that they
ought to, because the compilation failed.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Michael G Schwern
> At 9:13 AM -0700 8/1/02, Michael G Schwern wrote:
> >More chronicles from TPC.
> >
> >As mentioned earlier, XS is kinda nasty. Inline::C automates a lot of it.
> >Ingy has made the suggestion that if Inline::C is in 5.9 we can eliminate
> >much of the XS code from the modules in the ext/ directory and make things
> >much, much simpler.
>
> I think that would be a bad idea, unless Inline will generate the
> code and build the shared library at module build time. (And if it
> does, ignore the rest of this)
I believe it can. Forwarded it to Ingy for analysis.
--
Michael G. Schwern <sch...@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <per...@perl.org> Kwalitee Is Job One
Don't ask me lady, I live in beer.
Nicholas Clark
related is how we do C constants in perl.
1: IIRC, currently there is cunning in the op generator that will recognise a
subroutine which is prototyped as () and returns one constant value, and
inlines that value in place of a call to the subroutine.
2: We have many modules in ext that export many constants defined by C headers
into the users namespace (by default), which are found by running a small
subroutine which was compiled in C.
Typically most importers use "1, 2 or fewer" of these constants.
Many modules use the AUTOLOAD system to avoid resource use at compile time,
not calling into C to find out the value of constants that would never be
needed, and not having to waste memory creating lots of little
sub FOO () { 42; }
subs.
However, the upshot of the interaction of this with (1) is
a: The constants are not recognised at compile time when compiling the
user's code, so they aren't inlined.
b: When the call is made to find the value of a constant, it's not possible
for the AUTOLOAD subroutine which does the work to prototype &FOO as ()
without warnings, so even now no future compiling that may be done can
benefit from inlining
(ie eval statements, or anyone if we're doing this in a BEGIN)
3: We can stub each sub with a prototype () at import time, to avoid 2a and 2b,
but then we
a: call into the slow part of Exporter (Exporter was optimised for sub
only exports with a special case hack for Carp by IlyaZ, who did a good
job of speeding up the common case).
b: use lots of memory on the stubs
c: use lots of memory on the Exporter structure
(IIRC Ilya found that the memory used by POSIX's data structures passed
to exporter was substantial. Something lie 20% of the total memory
consumed as the result of use POSIX; He was working on a way to reduce
this, but I think hit problems with the speed and memory usage of tied
structures)
So what we need is some way to cheaply flag to the interpreter that a bareword
is a constant, such that the compiler will make a subroutine call out should it
need to find the value.
"Cheap" being that it shouldn't reduce the speed or increase the memory usage
of Exporter significantly.
(maybe the call is direct, and caught by AUTOLOAD, but not necessarily? or
maybe always to AUTOLOAD, with AUTOLOAD having hooks to not define where not
necessary?)
Nicholas Clark
--
Even better than the real thing: http://nms-cgi.sourceforge.net/
Rafael Garcia-Suarez
> >As mentioned earlier, XS is kinda nasty. Inline::C automates a lot of it.
> >Ingy has made the suggestion that if Inline::C is in 5.9 we can eliminate
> >much of the XS code from the modules in the ext/ directory and make things
> >much, much simpler.
>
> I think that would be a bad idea, unless Inline will generate the
> code and build the shared library at module build time. (And if it
> does, ignore the rest of this)
>
> With XS as it stands, the cost to build the module is entirely
> front-loaded--it's paid at perl build time and that's it.
I think that Inline'd modules will be built at 'make test' time --
most people issue a 'make test' before the 'make install'. (Those
who perform automated installs have binary tarballs anyway.)
Nick Ing-Simmons
>On Fri, Aug 02, 2002 at 11:12:48PM -0400, Dan Sugalski wrote:
>> At 9:13 AM -0700 8/1/02, Michael G Schwern wrote:
>> >More chronicles from TPC.
>> >
>> >As mentioned earlier, XS is kinda nasty. Inline::C automates a lot of it.
>> >Ingy has made the suggestion that if Inline::C is in 5.9 we can eliminate
>> >much of the XS code from the modules in the ext/ directory and make things
>> >much, much simpler.
>>
>> I think that would be a bad idea, unless Inline will generate the
>> code and build the shared library at module build time. (And if it
>> does, ignore the rest of this)
>
>I believe it can. Forwarded it to Ingy for analysis.
Is this Ingy person to grand to be added to copy list?
I notice that Inline::C says Parse::RecDescent is a prerequisite.
While RecDescent has Damian's normal elegance it has been a resource hog
in attempts to use it in day-job projects. "make test" on Inline::C is
certainly not speedy - but perhaps it is thorough!
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
Nick Ing-Simmons
>[modules in inline]
>
>related is how we do C constants in perl.
Good stuff snipped.
>
>So what we need is some way to cheaply flag to the interpreter that a bareword
>is a constant, such that the compiler will make a subroutine call out should it
>need to find the value.
The infra-structure to associate a bareword with a subroutine call is
surely comparable with associating the bareword with its constant value?
>"Cheap" being that it shouldn't reduce the speed or increase the memory usage
>of Exporter significantly.
Which reminds me - why should Exporter.pm not itself be XS-ed
(or Inline-d if that is plat du jour)?
>
>(maybe the call is direct, and caught by AUTOLOAD, but not necessarily? or
>maybe always to AUTOLOAD, with AUTOLOAD having hooks to not define where not
>necessary?)
>
>Nicholas Clark
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
Nick Ing-Simmons
I would like to understand how Inline::C handles such cases?
How does a .pm file which has Inline C => ... in it know that it does
not need to parse/compile/link this time? Where is .so or .dll stored
is there any Make-ery involved (time stamp compares)?
Brian Ingerson
> At 9:13 AM -0700 8/1/02, Michael G Schwern wrote:
> >More chronicles from TPC.
> >
> >As mentioned earlier, XS is kinda nasty. Inline::C automates a lot of it.
> >Ingy has made the suggestion that if Inline::C is in 5.9 we can eliminate
> >much of the XS code from the modules in the ext/ directory and make things
> >much, much simpler.
>
> I think that would be a bad idea, unless Inline will generate the
> code and build the shared library at module build time. (And if it
> does, ignore the rest of this)
Modules that use Inline get compiled at build time. After installation they
are indistinguishable from XS based ones. A recompile at run time can never
happen.
The only difference is that the installed module needs Inline.pm to
be on the user's system. But it only needs enough of Inline.pm to invoke
Dynaloader. About 30 lines of code. This is the only part of Inline that
I would like to see distributed with 5.9.
We'll need the full Inline stuff in the Perl distribution to build the
modules during Perl's compile time. But Inline::C et al should not actually
get installed on the users machine.
Why do we want to do all this, then? Because I feel that having the C code of
extension modules right inside the .pm file is a good thing for Perl. If you
have a bug, you read the code, and it's all right there in the module; just
like with Perl.
Cheers, Brian
Nick Ing-Simmons
>
Thanks for joining the discussion.
>Modules that use Inline get compiled at build time. After installation they
>are indistinguishable from XS based ones. A recompile at run time can never
>happen.
>
>The only difference is that the installed module needs Inline.pm to
>be on the user's system. But it only needs enough of Inline.pm to invoke
>Dynaloader.
Can Inline work on platforms which don't have dynamic loading?
Does it work on all the "weird" platfroms perl does? (VMS EBCDIC Mac etc.)
I just tried converting ext/PerlIO/via/... to Inline::C style and
it seemed to work.
Personaly I find the build process worryingly quiet - what is it _doing_
for those 16 seconds (or 4 hours or whatever on Nick C's slow machine).
Given the "chatty" nature of perl's normal Configure and build process it is
a bit of a cluture shock
What is not clear is what the "boiler-plate" should be to cause
ext/Xxxxx/Foo.pm
to be run through Inline.
I am also baffled as to why the generated .xs file failed to export
all the "helper" functions - that happens to be exactly right
in this case but such cleverness suprises me.
e.g. in XS it is "normal" to have
#include <perl.h> /* etc */
SV *
HelperFunction(int a)
{
}
SV *
RealFunction(int a)
{
SV *sv;
/* setup e.g. get a lock */
sv = HelperFunction(a)
/* cleanup */
return sv;
}
MODULE = Whatever, ...
SV *
RealFunction(int a)
How does one supress making HelperFunction() available with Inline?
>About 30 lines of code. This is the only part of Inline that
>I would like to see distributed with 5.9.
>
>We'll need the full Inline stuff in the Perl distribution to build the
>modules during Perl's compile time. But Inline::C et al should not actually
>get installed on the users machine.
That in itself is some work to the Make/Install process (to exclude
things that are in lib from being installed).
>
>Why do we want to do all this, then? Because I feel that having the C code of
>extension modules right inside the .pm file is a good thing for Perl. If you
>have a bug, you read the code, and it's all right there in the module; just
>like with Perl.
>
>Cheers, Brian
Nicholas Clark
> Brian Ingerson <in...@ttul.org> writes:
> >
>
> Thanks for joining the discussion.
>
> >Modules that use Inline get compiled at build time. After installation they
> >are indistinguishable from XS based ones. A recompile at run time can never
> >happen.
> >
> >The only difference is that the installed module needs Inline.pm to
> >be on the user's system. But it only needs enough of Inline.pm to invoke
> >Dynaloader.
>
> Can Inline work on platforms which don't have dynamic loading?
> Does it work on all the "weird" platfroms perl does? (VMS EBCDIC Mac etc.)
>
> I just tried converting ext/PerlIO/via/... to Inline::C style and
> it seemed to work.
>
> Personaly I find the build process worryingly quiet - what is it _doing_
> for those 16 seconds (or 4 hours or whatever on Nick C's slow machine).
No, that's parrot that takes 4 hours on my slow machine.
(4 hours and a couple of minutes of disk rattling as gcc swaps like crazy
compiling the computed goto core. And it's not like it's much better on
sane hardware - that computed goto core hurts a 128M P3 730 Mhz)
make test on Inline 0.43 (after removing the _Inline directory so it has
to rerun stuff):
real 0m35.032s
user 0m24.215s
sys 0m3.031s
somewhat faster than warnings.t
real 1m11.938s
user 0m50.614s
sys 0m14.754s
> Given the "chatty" nature of perl's normal Configure and build process it is
> a bit of a cluture shock
It's very very dry when something goes wrong. I'm used to makefiles and
compilers that spew tons of crap to the screen (for want of a polite way of
describing it) and it's not like that.
[It's also not fair of me to be seeming to criticise it on a public list,
when actually it's something that's minor, and it's not clear to me if there
is a better way for it to handle the situation.
Plus I still owe Ingy a reply to a message from about 3 months ago about
thoughts on static libraries]
Inline is really really cool, and as an example to check that I had the
answer below correct, I wrote the following with that well known editor
cat:
use Inline C => <<'EOT';
void
hello () {
printf ("hello world\n");
}
EOT
hello();
and only messed up two characters that needed correcting with vi.
I can't write XS code with cat, and I doubt anyone can. :-)
> What is not clear is what the "boiler-plate" should be to cause
> ext/Xxxxx/Foo.pm
> to be run through Inline.
>
> I am also baffled as to why the generated .xs file failed to export
> all the "helper" functions - that happens to be exactly right
> in this case but such cleverness suprises me.
run with -MInline=INFO
> >Why do we want to do all this, then? Because I feel that having the C code of
> >extension modules right inside the .pm file is a good thing for Perl. If you
> >have a bug, you read the code, and it's all right there in the module; just
> >like with Perl.
This is good. Why your preference that a perl shipping with Inline that it
uses to build itself and core extensions then doesn't install Inline into
the perl libraries so that it's immediately there for extensions to use?
Particularly as then anyone who finds a bug in (say) POSIX.pm in an
"installed" can't then correct it and rebuild the installed C, because
if I understand you correctly you don't want perl to install the Inline build
system. Having re-read this (which I assume is still an accurate explanation
of Ingy's position)
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-07/msg01109.html
I presume the correct response is that for anyone wishing to recompile
the C in POSIX.pm, downloading Inline from CPAN is easier than the edits
they're about to perform. Am I right in thinking that for 90% of users being
able to look at what the C is going to be more than enough?
[Read the above URL. It's Ingy's reasons as to why he didn't want Inline
in the core for 5.8]
Brian Ingerson
> Brian Ingerson <in...@ttul.org> writes:
> >
>
> Thanks for joining the discussion.
>
> >Modules that use Inline get compiled at build time. After installation they
> >are indistinguishable from XS based ones. A recompile at run time can never
> >happen.
> >
> >The only difference is that the installed module needs Inline.pm to
> >be on the user's system. But it only needs enough of Inline.pm to invoke
> >Dynaloader.
>
> Can Inline work on platforms which don't have dynamic loading?
> Does it work on all the "weird" platfroms perl does? (VMS EBCDIC Mac etc.)
Inline strives to just automate the existing XS build process without adding
anything new. But I know there's still work to be done for VMS and others.
Hopefully not too much work. :)
>
> I just tried converting ext/PerlIO/via/... to Inline::C style and
> it seemed to work.
>
> Personaly I find the build process worryingly quiet - what is it _doing_
> for those 16 seconds (or 4 hours or whatever on Nick C's slow machine).
> Given the "chatty" nature of perl's normal Configure and build process it is
> a bit of a cluture shock
>
> What is not clear is what the "boiler-plate" should be to cause
> ext/Xxxxx/Foo.pm
> to be run through Inline.
>
> I am also baffled as to why the generated .xs file failed to export
> all the "helper" functions - that happens to be exactly right
> in this case but such cleverness suprises me.
The current version of Inline will only bind to the signatures it recognizes,
and silently ignore the rest. Luckily it won't bind to static functions,
which is usally exactly what you want. It also won't bind to functions that
use arguments for which there is no typemap support.
>
> e.g. in XS it is "normal" to have
>
> #include <perl.h> /* etc */
>
> SV *
> HelperFunction(int a)
> {
> }
>
> SV *
> RealFunction(int a)
> {
> SV *sv;
> /* setup e.g. get a lock */
> sv = HelperFunction(a)
> /* cleanup */
> return sv;
> }
>
> MODULE = Whatever, ...
>
> SV *
> RealFunction(int a)
>
> How does one supress making HelperFunction() available with Inline?
>
>
> >About 30 lines of code. This is the only part of Inline that
> >I would like to see distributed with 5.9.
> >
> >We'll need the full Inline stuff in the Perl distribution to build the
> >modules during Perl's compile time. But Inline::C et al should not actually
> >get installed on the users machine.
>
> That in itself is some work to the Make/Install process (to exclude
> things that are in lib from being installed).
I'm sure this will not be a showstopper.
Cheers, Brian
Brian Ingerson
> Michael G Schwern <sch...@pobox.com> writes:
> >On Fri, Aug 02, 2002 at 11:12:48PM -0400, Dan Sugalski wrote:
> >> At 9:13 AM -0700 8/1/02, Michael G Schwern wrote:
> >> >More chronicles from TPC.
> >> >
> >> >As mentioned earlier, XS is kinda nasty. Inline::C automates a lot of it.
> >> >Ingy has made the suggestion that if Inline::C is in 5.9 we can eliminate
> >> >much of the XS code from the modules in the ext/ directory and make things
> >> >much, much simpler.
> >>
> >> I think that would be a bad idea, unless Inline will generate the
> >> code and build the shared library at module build time. (And if it
> >> does, ignore the rest of this)
> >
> >I believe it can. Forwarded it to Ingy for analysis.
>
> Is this Ingy person to grand to be added to copy list?
Nope.
>
> I notice that Inline::C says Parse::RecDescent is a prerequisite.
> While RecDescent has Damian's normal elegance it has been a resource hog
> in attempts to use it in day-job projects. "make test" on Inline::C is
> certainly not speedy - but perhaps it is thorough!
Mitchell Charity wrote a drop in replacement for Inline::C::grammar. This is
the code that requires P::RD. He uses regexes. I just haven't released it
yet.
But the P::RD thing will not be an issue.
Cheers, Brian
Brian Ingerson
Good criticism. That's slated for enhancement.
>
> [It's also not fair of me to be seeming to criticise it on a public list,
> when actually it's something that's minor, and it's not clear to me if there
> is a better way for it to handle the situation.
> Plus I still owe Ingy a reply to a message from about 3 months ago about
> thoughts on static libraries]
>
> Inline is really really cool, and as an example to check that I had the
> answer below correct, I wrote the following with that well known editor
> cat:
>
> use Inline C => <<'EOT';
>
> void
> hello () {
> printf ("hello world\n");
> }
>
> EOT
>
> hello();
>
>
> and only messed up two characters that needed correcting with vi.
>
> I can't write XS code with cat, and I doubt anyone can. :-)
My favorite editor is the command line :)
perl -e 'use Inline C,q{void H(){printf("Hi\n");}};H'
I actually got it right from scratch!
>
> > What is not clear is what the "boiler-plate" should be to cause
> > ext/Xxxxx/Foo.pm
> > to be run through Inline.
> >
> > I am also baffled as to why the generated .xs file failed to export
> > all the "helper" functions - that happens to be exactly right
> > in this case but such cleverness suprises me.
>
> run with -MInline=INFO
>
>
> > >Why do we want to do all this, then? Because I feel that having the C code of
> > >extension modules right inside the .pm file is a good thing for Perl. If you
> > >have a bug, you read the code, and it's all right there in the module; just
> > >like with Perl.
>
> This is good. Why your preference that a perl shipping with Inline that it
> uses to build itself and core extensions then doesn't install Inline into
> the perl libraries so that it's immediately there for extensions to use?
>
> Particularly as then anyone who finds a bug in (say) POSIX.pm in an
> "installed" can't then correct it and rebuild the installed C, because
> if I understand you correctly you don't want perl to install the Inline build
> system. Having re-read this (which I assume is still an accurate explanation
> of Ingy's position)
>
> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-07/msg01109.html
Thanks for doing your homework. This is still my position. But since I am
slightly less interested in Inline development these days, it might be a good
idea to just polish it up and retire it to the core. We'll see. I have a
while to refine my stance :)
>
> I presume the correct response is that for anyone wishing to recompile
> the C in POSIX.pm, downloading Inline from CPAN is easier than the edits
> they're about to perform. Am I right in thinking that for 90% of users being
> able to look at what the C is going to be more than enough?
Yep.
Brian Ingerson
This is not true. They are built at make time. The Inline distro ships with a
sample module called Math::Simple. Try building it to see how it works.
Cheers, Brian
Brian Ingerson
Inline modules use Inline::MakeMaker in the Makefile.PL. This adds a pure_all
rule to the postamble that looks something like this:
/usr/bin/perl -Mblib -MInline=_INSTALL_ -MMath::Simple -e1 1.23 blib/arch
Basically this forces a build of the code and makes sure the objects get
placed in the blib for installation at 'make install' time. The '_INSTALL_'
option tells Inline that this is a module build.
The dependencies work out so that the build won't happen twice, etc. (ie
I did it right :) The stuff also works correctly in recursive build
trees. Even when Inline::MakeMaker and ExtUtils::MakeMaker are interspersed.
If we put Inline into the core, I'll probably want to patch
ExtUtils::MakeMaker to play friendly with Inline. (Or is it
Module::Build now? :)
Cheers, Brian
Nick Ing-Simmons
>On 03/08/02 22:22 +0100, Nick Ing-Simmons wrote:
>> Brian Ingerson <in...@ttul.org> writes:
>> >
>>
>> Thanks for joining the discussion.
>>
>
>anything new.
The fact that XS was still there took me by surprise ;-)
>But I know there's still work to be done for VMS and others.
>Hopefully not too much work. :)
>
>>
>> Personaly I find the build process worryingly quiet - what is it _doing_
>> for those 16 seconds (or 4 hours or whatever on Nick C's slow machine).
>> Given the "chatty" nature of perl's normal Configure and build process it is
>> a bit of a cluture shock
Care to respond to that point? e.g. would it be possible to have
a "verbose" option which gave us all of xsubpp/make/cc/ld stderr?
My concern is that someone trys to build ext/Encode (say). With perl5.8
etc. they would have got a pile of warnings which they could cut-and-paste
to a perlbug and p5p could diagnose the problem (sometimes at least).
With the big silence it would _seem_ we are going to be repeatedly
telling them to re-run things with NOCLEAN, cd into obscure-ish directories
and send us what they find.
>>
>> What is not clear is what the "boiler-plate" should be to cause
>> ext/Xxxxx/Foo.pm
>> to be run through Inline.
>>
>> I am also baffled as to why the generated .xs file failed to export
>> all the "helper" functions - that happens to be exactly right
>> in this case but such cleverness suprises me.
>
>The current version of Inline will only bind to the signatures it recognizes,
>and silently ignore the rest. Luckily it won't bind to static functions,
>which is usally exactly what you want. It also won't bind to functions that
>use arguments for which there is no typemap support.
>
Ah, will have to poke about and see how to pass in custom typemaps
and see what happens. But making helpers static seems
reasonably fool proof - cool.
However my XS code sometimes exports static functions too, so
in general some thought will have to go into .xs -> Inline migration,
(but far less than is needed to develop the .xs in the 1st place).
>>
>> That in itself is some work to the Make/Install process (to exclude
>> things that are in lib from being installed).
>
>I'm sure this will not be a showstopper.
Agreed.
Nick Ing-Simmons
>>
>> I would like to understand how Inline::C handles such cases?
>> How does a .pm file which has Inline C => ... in it know that it does
>> not need to parse/compile/link this time? Where is .so or .dll stored
>> is there any Make-ery involved (time stamp compares)?
>
>Inline modules use Inline::MakeMaker in the Makefile.PL. This adds a pure_all
>rule to the postamble that looks something like this:
>
> /usr/bin/perl -Mblib -MInline=_INSTALL_ -MMath::Simple -e1 1.23 blib/arch
Cool.
Tim Bunce
> More chronicles from TPC.
>
> As mentioned earlier, XS is kinda nasty. Inline::C automates a lot of it.
> Ingy has made the suggestion that if Inline::C is in 5.9 we can eliminate
> much of the XS code from the modules in the ext/ directory and make things
> much, much simpler.
I've only skimmed this thread but I've not seen anyone mention perl6.
Assuming Inline can be ported to (or more likely, rewritten for) perl6
then extensions written using Inline ought to port to perl6 far more
easily than extensions using XS.
I think that's a big win.
Tim.
Dan Sugalski
Doubt it. All that Inline does is remove some of the CODE/PPCODE
stuff. The API the C code uses is the same, and that's where most of
the issues lie.
Brian Ingerson
> At 11:03 PM +0100 8/4/02, Tim Bunce wrote:
> >On Thu, Aug 01, 2002 at 09:13:56AM -0700, Michael G Schwern wrote:
> >> More chronicles from TPC.
> >>
> >> As mentioned earlier, XS is kinda nasty. Inline::C automates a lot of it.
> >> Ingy has made the suggestion that if Inline::C is in 5.9 we can eliminate
> >> much of the XS code from the modules in the ext/ directory and make things
> >> much, much simpler.
> >
> >I've only skimmed this thread but I've not seen anyone mention perl6.
> >
> >Assuming Inline can be ported to (or more likely, rewritten for) perl6
> >then extensions written using Inline ought to port to perl6 far more
> >easily than extensions using XS.
>
> Doubt it. All that Inline does is remove some of the CODE/PPCODE
> stuff. The API the C code uses is the same, and that's where most of
> the issues lie.
Agreed. Inline only hides the glue code. If you use any API calls (and you
probably do) then its no win.
But then again, I do like the idea of starting to think about extension
migration.
Cheers, Brian
Elizabeth Mattijsen
>Agreed. Inline only hides the glue code. If you use any API calls (and you
>probably do) then its no win.
....
>But then again, I do like the idea of starting to think about extension
>migration.
where Ingy's lines...
Liz
Elizabeth Mattijsen
> >Assuming Inline can be ported to (or more likely, rewritten for) perl6
> >then extensions written using Inline ought to port to perl6 far more
> >easily than extensions using XS.
> Doubt it. All that Inline does is remove some of the CODE/PPCODE
> stuff. The API the C code uses is the same, and that's where most of
> the issues lie.
Agreed. Inline only hides the glue code. If you use any API calls (and you
probably do) then its no win.
But in fact, Inline::X is a new kind of API to the outside world. Maybe
what is needed at this point in time is a new API definition that could be:
- used in Parrot / Perl 6
- be a layer on top of XS and the current Perl API
Inline::C from application development point of view, is already quite a
number of steps in that direction, especially if you're _not_ using the
current Perl API.
Such a new API should allow migration from XS to Inline::C in the Perl5
track, with advantages such as having the code all in one place and better
readability and maintainability. And make those modules ready to use the
same new API when ported to Parrot / Perl 6.
But then again, I do like the idea of starting to think about extension
migration.
It may not be worth much, but I'm thinking... ;-)
Liz
Dan Sugalski
>At 08:27 PM 8/4/02 -0700, Brian Ingerson wrote:
>> >Assuming Inline can be ported to (or more likely, rewritten for) perl6
>> >then extensions written using Inline ought to port to perl6 far more
>> >easily than extensions using XS.
>> Doubt it. All that Inline does is remove some of the CODE/PPCODE
>> stuff. The API the C code uses is the same, and that's where most of
>> the issues lie.
>Agreed. Inline only hides the glue code. If you use any API calls (and you
>probably do) then its no win.
>
>But in fact, Inline::X is a new kind of API to the outside world.
>Maybe what is needed at this point in time is a new API definition
>that could be:
>
> - used in Parrot / Perl 6
> - be a layer on top of XS and the current Perl API
We could do this, sure. A good chunk of the API (both for perl 5 and
parrot) will be interpreter-specific--there's not much getting around
some of it--but that doesn't mean we can't provide at least a partial
overlap, and it'll be handy for people writing inline-style xs for
parrot.
>It may not be worth much, but I'm thinking... ;-)
It's a good thought. I've been thinking in the other direction
(providing a perl 5 thunking layer for parrot) but this is a good
thing to think as well.
Elizabeth Mattijsen
>It's a good thought. I've been thinking in the other direction (providing
>a perl 5 thunking layer for parrot) but this is a good thing to think as well.
The reason I wouldn't want to go that way, is that it would "soil" parrot
with too much of perl 5's history. I would rather go the way of cleaning
up Perl 5, making it ready for migration to Parrot, than making Parrot
ready for Perl 5.
In the former case, you would have a maintable Perl 5 track which could
survive on its own if need be. And when Parrot / Perl 6 comes alive
(please note my "when" rather than "if") as the platform of the future,
migration should be easy.
In the latter case, I think you're putting all your eggs in one basket. If
the Parrot initiative should fail (note my "if" and not "when" here),
you're stuck with a poorly maintainable perl 5 and no future.
Just my 2 eurocents worth...
Liz
Joe McMahon
> On Fri, Aug 02, 2002 at 11:12:48PM -0400, Dan Sugalski wrote:
> > I think that would be a bad idea, unless Inline will generate the
> > code and build the shared library at module build time. (And if it
> > does, ignore the rest of this)
>
> I believe it can. Forwarded it to Ingy for analysis.
Gerald Richter told us about a new utility for mod_perl 2.0 that he's
repackaged as a standalone; it automatically generates XS code for a
library. Let me check my notes.
Yeah, here we go. XSBuilder. It autogenerates (modulo a bit of
configuration) XS code for library interfaces. Creates functions for each
C function, classes for each C structure (with a set/get method for each
element). Still a work in progress, but possibly useful.
ftp://ftp.dev.ecos.de/pub/perl/xsbuilder/
--- Joe M.
Brian Ingerson
> Brian Ingerson <in...@ttul.org> writes:
> >On 03/08/02 22:22 +0100, Nick Ing-Simmons wrote:
> >> Personaly I find the build process worryingly quiet - what is it _doing_
> >> for those 16 seconds (or 4 hours or whatever on Nick C's slow machine).
> >> Given the "chatty" nature of perl's normal Configure and build process it is
> >> a bit of a cluture shock
>
> Care to respond to that point? e.g. would it be possible to have
> a "verbose" option which gave us all of xsubpp/make/cc/ld stderr?
> My concern is that someone trys to build ext/Encode (say). With perl5.8
> etc. they would have got a pile of warnings which they could cut-and-paste
> to a perlbug and p5p could diagnose the problem (sometimes at least).
>
> With the big silence it would _seem_ we are going to be repeatedly
> telling them to re-run things with NOCLEAN, cd into obscure-ish directories
> and send us what they find.
Nick,
definitely good points here. Inline is optimized for the scriptor. Silence is
golden. But in a build system, chatty is the way to go. I'll make it happen.
Cheers, Brian