You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Gerald Richter <ri...@ecos.de> on 2001/05/25 17:17:09 UTC
automaticly created XS in mod_perl 2.0
Hi Doug,
for my implemetation of the interface to mod_dav I again looked thru your
code that generates the XS for mod_perl 2.0. I have done this the first time
when I implemented my HTTP::Webdav (which is a webdav client and will be
soon on CPAN). For this first project that does automaticly generate XS from
C I decided, that your modules are too much connected to the internals of
Apache and wrote my own quick and dirty script that now creates all the XS
glue code for the API and the callbacks. Now for the mod_dav backend, I took
again a look at the XS generation in mod_perl and thought it would be a good
idea to make it a little bit more general, so it could be used outside
mod_perl. My idea is to make a base class (e.g. ExtUtils::XSMaker;
suggestions for better names are welcome), that implements all the general
stuff and your mod_perl/Apache class inherit from this base class and
implement the mod_perl specific stuff. This way another application could
also use the base class and use it without Apache. The idea behind this is,
that mod_dav should now run with mod_perl 1.x, but later with mod_perl 2.x.
If we can make the XS generation stuff more general, I could use it right
now and the port to Apache/mod_perl 2.0 would be much easier.
I know this will be a lot of work, but you already have done a lot of work
for the XS generation and I don't like to reimplement it. What do you think,
should I give it a try ? If I start such a separation, would you take it
into mod_perl, so we can use the same code base, or is this for whatever
reasons a bad idea ?
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
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: automaticly created XS in mod_perl 2.0
Posted by Doug MacEachern <do...@covalent.net>.
On Mon, 28 May 2001, Gerald Richter wrote:
>
> > this looks like one of the problems the hacked version of C::Scan (at
> > perl.apache.org/~dougm/) fixes.
> >
>
> I have the C::Scan from perl.apache.org/~dougm/ . I just rechecked to be
> sure. So maybe you have done some more fixes and not uploaded it to
> perl.apache.org/~dougm/ ? Also the C::Scan->VERSION(0.75); inside
> Apache::ParseSource should give use warning, if I have the wrong version...
hmm, no the fix was added to that version several weeks (months?) ago.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: automaticly created XS in mod_perl 2.0
Posted by Gerald Richter <ri...@ecos.de>.
> this looks like one of the problems the hacked version of C::Scan (at
> perl.apache.org/~dougm/) fixes.
>
I have the C::Scan from perl.apache.org/~dougm/ . I just rechecked to be
sure. So maybe you have done some more fixes and not uploaded it to
perl.apache.org/~dougm/ ? Also the C::Scan->VERSION(0.75); inside
Apache::ParseSource should give use warning, if I have the wrong version...
Gerald
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: automaticly created XS in mod_perl 2.0
Posted by Doug MacEachern <do...@covalent.net>.
On Sun, 27 May 2001, Gerald Richter wrote:
> I tried this already. Addtionaly to add the dav_ prefix, I had to add the
> mod_dav.h to the include files (because it's not in the include directory).
>
> I parses the function correctly, but not the callbacks. As far as I seen,
> you don't create the callbacks automaticly, is this right ?
right.
> The implementation of a mod_dav Perl backend will be about 50% callbacks
> into Perl, so I like to generate them also automaticly.
oh wow, didn't know there's so many callbacks.
> > more work would be involved to get the current tools in shape to
> > generate the client front end to neon.
> >
>
> My quick and dirty script does this at the moment for neon. It generates all
> function call and callbacks (there is no handwritten code in HTTP::Webdav
> :-). Now I like to bring these both together (at least parts of it, other
> parts will stay divided, because my time is limited) and I like to create
> also the mod_dav 1.x backend with these scripts.
>
> I just will play a little bit around (together with Philippe) and we will
> get back to you as soon as we have any results. I think we start to make a
> base class for ModPerl/Apache::PasrseSource, which also is able to parser
> typedefs, and give mode detailed information about callbacks (i.e. splitting
> out the args of the callback function).
ok, sounds good.
> Gerald
>
> P.S. To get uitl/source_scan.pl working I had to add a
>
> use ModPerl::WarpXS ;
right, i've been meaning to fix that.
> and the ModPerl::ParseSource->write_functions_pm dies. See the output from
> the Perl debugger below. I currently use Perl 5.6.1.
>
> main::(util/source_scan.pl:22): $p = ModPerl::ParseSource->new(@ARGV);
> DB<1> n
> main::(util/source_scan.pl:24): $p->parse;
> DB<1> n
> main::(util/source_scan.pl:26): $p->write_functions_pm;
> DB<1> n
> In file included from .apache_includes:4,
> from :1:
> xs/modperl_xs_sv_convert.h:288: warning:
> p_xs_sv2_r' redefined
> xs/modperl_xs_util.h:6: warning: this is the location of the previous
> definition
> In file included from .apache_includes:4,
> from :1:
> xs/modperl_xs_sv_convert.h:288: warning:
> p_xs_sv2_r' redefined
> xs/modperl_xs_util.h:6: warning: this is the location of the previous
> definition
> panic: multiple types without intervening comma in
> regexp*( *regcomp_t ) (register PerlInterpreter *my_perl , char*
> exp, char* xend, PMOP* pm)
> whited-out as
> regexp*( *regcomp_t )
> ( )
this looks like one of the problems the hacked version of C::Scan (at
perl.apache.org/~dougm/) fixes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: automaticly created XS in mod_perl 2.0
Posted by Gerald Richter <ri...@ecos.de>.
>
> the current tools should work for generating a mod_dav backend with 2.0
> i think we just need to add the dav_ prefix to Apache::ParseSource so
> mod_dav.h is parsed into the Apache::{Function,Structure}Table.
>
I tried this already. Addtionaly to add the dav_ prefix, I had to add the
mod_dav.h to the include files (because it's not in the include directory).
I parses the function correctly, but not the callbacks. As far as I seen,
you don't create the callbacks automaticly, is this right ?
The implementation of a mod_dav Perl backend will be about 50% callbacks
into Perl, so I like to generate them also automaticly.
> more work would be involved to get the current tools in shape to
> generate the client front end to neon.
>
My quick and dirty script does this at the moment for neon. It generates all
function call and callbacks (there is no handwritten code in HTTP::Webdav
:-). Now I like to bring these both together (at least parts of it, other
parts will stay divided, because my time is limited) and I like to create
also the mod_dav 1.x backend with these scripts.
I just will play a little bit around (together with Philippe) and we will
get back to you as soon as we have any results. I think we start to make a
base class for ModPerl/Apache::PasrseSource, which also is able to parser
typedefs, and give mode detailed information about callbacks (i.e. splitting
out the args of the callback function).
Gerald
P.S. To get uitl/source_scan.pl working I had to add a
use ModPerl::WarpXS ;
and the ModPerl::ParseSource->write_functions_pm dies. See the output from
the Perl debugger below. I currently use Perl 5.6.1.
main::(util/source_scan.pl:22): $p = ModPerl::ParseSource->new(@ARGV);
DB<1> n
main::(util/source_scan.pl:24): $p->parse;
DB<1> n
main::(util/source_scan.pl:26): $p->write_functions_pm;
DB<1> n
In file included from .apache_includes:4,
from :1:
xs/modperl_xs_sv_convert.h:288: warning:
p_xs_sv2_r' redefined
xs/modperl_xs_util.h:6: warning: this is the location of the previous
definition
In file included from .apache_includes:4,
from :1:
xs/modperl_xs_sv_convert.h:288: warning:
p_xs_sv2_r' redefined
xs/modperl_xs_util.h:6: warning: this is the location of the previous
definition
panic: multiple types without intervening comma in
regexp*( *regcomp_t ) (register PerlInterpreter *my_perl , char*
exp, char* xend, PMOP* pm)
whited-out as
regexp*( *regcomp_t )
( )
Expecting parenth after identifier in egcomp_t *
Perl_Tregcompp_ptr(register PerlInterpreter *my_perl )'
after egcomp_t ' at /opt/perlt5.6.1/lib/site_perl/5.6.1/C/Scan.pm line
783.
C::Scan::do_declaration('extern ^Iregcomp_t *
Perl_Tregcompp_ptr(register PerlInterpre...', 'HASH(0x881669c)',
'HASH(0x8815620)') called at /opt/perlt5.6.1/lib/site_perl/5.6.1/C/Scan.pm
line 738
C::Scan::do_declarations('ARRAY(0x87f113c)', 'HASH(0x881669c)',
'HASH(0x8815620)') called at
/opt/perlt5.6.1/lib/site_perl/5.6.1/Data/Flow.pm line 69
Data::Flow::request('Apache::ParseSource::Scan=ARRAY(0x87f0cec)',
'parsed_fdecls') called at /opt/perlt5.6.1/lib/site_perl/5.6.1/Data/Flow.pm
line 39
Data::Flow::get('Apache::ParseSource::Scan=ARRAY(0x87f0cec)',
'parsed_fdecls') called at lib/Apache/ParseSource.pm line 49
Apache::ParseSource::Scan::get('Apache::ParseSource::Scan=ARRAY(0x87f0cec)',
'parsed_fdecls') called at lib/Apache/ParseSource.pm line 290
Apache::ParseSource::get_functions('ModPerl::ParseSource=HASH(0x8a9de1c)')
called at lib/Apache/ParseSource.pm line 368
Apache::ParseSource::write_functions_pm('ModPerl::ParseSource=HASH(0x8a9de1c
)', 'FunctionTable.pm', 'ModPerl::FunctionTable') called at
lib/ModPerl/ParseSource.pm line 40
ModPerl::ParseSource::write_functions_pm('ModPerl::ParseSource=HASH(0x8a9de1
c)') called at util/source_scan.pl line 26Debugged program terminated. Use
q to quit or R to restart,
use O inhibit_exit to avoid stopping after program termination,
h q, h R or h O to get additional info.
-------------------------------------------------------------
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
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: automaticly created XS in mod_perl 2.0
Posted by Doug MacEachern <do...@covalent.net>.
On Fri, 25 May 2001, Gerald Richter wrote:
> ok, I give it a try. I don't expect it to be a real general tool (I think I
> don't have the time to really abstract all the work you have done in a more
> general way), but something that I can use to build the mod_dav backend for
> mod_perl 1.x and 2.x.
the current tools should work for generating a mod_dav backend with 2.0
i think we just need to add the dav_ prefix to Apache::ParseSource so
mod_dav.h is parsed into the Apache::{Function,Structure}Table.
more work would be involved to get the current tools in shape to
generate the client front end to neon.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: automaticly created XS in mod_perl 2.0
Posted by Gerald Richter <ri...@ecos.de>.
> i intended to make the mod_perl-2.0 code generation tied tight to
> Apache/mod_perl. i didn't want to build a generic tool, like another swig
> or Inline.pm, i only wanted something generic enough to work with the
> entire Apache/APR api, along with Apache modules like mod_dav, mod_proxy,
> etc. my biggest fear in making it more generic was the time it would
> take. but if you're seeing a use/need outside of the Apache/mod_perl
> scope, then by all means, go for it :) i'd be willing to make
> adjustments/use a more generic base class in modperl-2.0.
>
ok, I give it a try. I don't expect it to be a real general tool (I think I
don't have the time to really abstract all the work you have done in a more
general way), but something that I can use to build the mod_dav backend for
mod_perl 1.x and 2.x.
I let you know when I have some results and then we can discuss how this
fits into mod_perl 2.0 or not
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
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: automaticly created XS in mod_perl 2.0
Posted by Doug MacEachern <do...@covalent.net>.
i intended to make the mod_perl-2.0 code generation tied tight to
Apache/mod_perl. i didn't want to build a generic tool, like another swig
or Inline.pm, i only wanted something generic enough to work with the
entire Apache/APR api, along with Apache modules like mod_dav, mod_proxy,
etc. my biggest fear in making it more generic was the time it would
take. but if you're seeing a use/need outside of the Apache/mod_perl
scope, then by all means, go for it :) i'd be willing to make
adjustments/use a more generic base class in modperl-2.0.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org