You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Doug MacEachern <do...@covalent.net> on 2002/08/09 19:01:50 UTC
Re: cvs commit: modperl-2.0 Changes
On 31 Jul 2002 stas@apache.org wrote:
> stas 2002/07/31 09:32:40
>
> Modified: t/response/TestApache compat2.pm
> lib/Apache compat.pm
> . Changes
> Log:
> added $r->get_remote_host to compat.pm + test
i don't think you greped enough. r->connection->remote_host and
ap_get_remote_host are not the same. this patch should be backed out.
and instead figure out why ap_get_remote_host is not being wrapped
(probably just needs a wrapper).
> --- Changes 21 Jun 2002 22:35:49 -0000 1.29
> +++ Changes 31 Jul 2002 16:32:40 -0000 1.30
> @@ -12,6 +12,8 @@
>
> =item 1.99_04 - June 21, 2002
>
> +added $r->get_remote_host to compat.pm + test [Stas Bekman]
> +
and, um, 1.99_04 was already released. new changes should be under
1.99_05-dev.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: cvs commit: modperl-2.0 Changes
Posted by Doug MacEachern <do...@covalent.net>.
On Thu, 15 Aug 2002, Stas Bekman wrote:
>
> >>that's said should the XS generator generate a fatal error when an XS
> >>wrapper is not created, because one of the argument's typemap is unknown?
> >
> >
> > maybe. i found it better the way it is now for early development, using
> > the util/xs_check.pl to tell me whats not getting mapped in a summary.
>
> are we still in the early development?
no. but the other reason for it not being fatal was one of the main ideas
behind WrapXS. that we would run source_scan when building, and we could
adjust to httpd/apr versions without #ifdefs. for example, c->keepalive
is an ap_conn_keepalive_e in newer httpds, was an int in older ones. so
when i just ran source_scan and built against 2.0.36, the c->keepalive
method was not generated since we didn't have support for
ap_conn_keepalive_e. and modperl was able to compile without changes. of
course, it also didn't have the c->keepalive method. anyhow, i've sort of
given up on this idea, since source_scan clearly cannot be run on every
system. if you want to make it fatal error, feel free. there should be
at least a debug trace in there at the moment when a function/member
cannot be mapped.
> I doubt mod_perl programmers will find any use for $str_is_ip. So I've
> added a wrapper ala mod_perl 1.0, plus an optional dir_config arg:
>
> mpxs_Apache__Connection_get_remote_host | | c, type=REMOTE_NAME,
> dir_config=Nullsv
>
> and the 1.0 wrapper in compat. Hope it's OK.
ok, except that dir_config is an ap_conf_vector_t* (aka void*), not an
apr_table_t* :-) and in any case, a Nullsv cannot be assigned to either
type, MP_CCOPTS=-Wall -Werror caught that for me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: cvs commit: modperl-2.0 Changes
Posted by Stas Bekman <st...@stason.org>.
Doug MacEachern wrote:
> On Mon, 12 Aug 2002, Stas Bekman wrote:
>
>
>>it failed to create the wrapper because the API included an 'int *'
>>arg, whose typemap was undefined. Is it safe to use 'int * | PTR'
>>typemap? I've checked the conversion functions and they seem to do the
>>right thing:
>
>
> that's fine for the typemap.
added
>>that's said should the XS generator generate a fatal error when an XS
>>wrapper is not created, because one of the argument's typemap is unknown?
>
>
> maybe. i found it better the way it is now for early development, using
> the util/xs_check.pl to tell me whats not getting mapped in a summary.
are we still in the early development?
>>in any case, the automatic wrapper now gets added. But its arguments are:
>>
>>const char *
>>ap_get_remote_host(conn, dir_config, type, str_is_ip)
>> Apache::Connection conn
>> void * dir_config
>> int type
>> int * str_is_ip
>>
>>should the wrapper accept $r instead of $c (requiring a manual wrapper)?
>
>
> no. should be able to use $c->get_remote_host(...) in a protocol handler
> that does not have an $r. but the Apache::compat method can take care of
> that.
>
>
>>should we NULL the str_is_ip argument?
>
>
> default to NULL, i think. i don't actually know what it is used for.
> looks like dir_config should also default to NULL.
> and type to REMOTE_NAME (like 1.x).
> with $dir_config and $str_is_ip being optional args after type.
I doubt mod_perl programmers will find any use for $str_is_ip. So I've
added a wrapper ala mod_perl 1.0, plus an optional dir_config arg:
mpxs_Apache__Connection_get_remote_host | | c, type=REMOTE_NAME,
dir_config=Nullsv
and the 1.0 wrapper in compat. Hope it's OK.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: cvs commit: modperl-2.0 Changes
Posted by Doug MacEachern <do...@covalent.net>.
On Mon, 12 Aug 2002, Stas Bekman wrote:
> it failed to create the wrapper because the API included an 'int *'
> arg, whose typemap was undefined. Is it safe to use 'int * | PTR'
> typemap? I've checked the conversion functions and they seem to do the
> right thing:
that's fine for the typemap.
> that's said should the XS generator generate a fatal error when an XS
> wrapper is not created, because one of the argument's typemap is unknown?
maybe. i found it better the way it is now for early development, using
the util/xs_check.pl to tell me whats not getting mapped in a summary.
> in any case, the automatic wrapper now gets added. But its arguments are:
>
> const char *
> ap_get_remote_host(conn, dir_config, type, str_is_ip)
> Apache::Connection conn
> void * dir_config
> int type
> int * str_is_ip
>
> should the wrapper accept $r instead of $c (requiring a manual wrapper)?
no. should be able to use $c->get_remote_host(...) in a protocol handler
that does not have an $r. but the Apache::compat method can take care of
that.
> should we NULL the str_is_ip argument?
default to NULL, i think. i don't actually know what it is used for.
looks like dir_config should also default to NULL.
and type to REMOTE_NAME (like 1.x).
with $dir_config and $str_is_ip being optional args after type.
> It seems to me that the Perl interface should be:
>
> $r->get_remote_host($type);
>
> ($type is new to 2.0)
$type is not new to 2.0. did you look at the 1.x code in Apache.xs?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: cvs commit: modperl-2.0 Changes
Posted by Stas Bekman <st...@stason.org>.
Doug MacEachern wrote:
> On 31 Jul 2002 stas@apache.org wrote:
>
>
>>stas 2002/07/31 09:32:40
>>
>> Modified: t/response/TestApache compat2.pm
>> lib/Apache compat.pm
>> . Changes
>> Log:
>> added $r->get_remote_host to compat.pm + test
>
>
> i don't think you greped enough. r->connection->remote_host and
> ap_get_remote_host are not the same. this patch should be backed out.
> and instead figure out why ap_get_remote_host is not being wrapped
> (probably just needs a wrapper).
it failed to create the wrapper because the API included an 'int *'
arg, whose typemap was undefined. Is it safe to use 'int * | PTR'
typemap? I've checked the conversion functions and they seem to do the
right thing:
Index: xs/maps/apache_types.map
===================================================================
RCS file: /home/cvs/modperl-2.0/xs/maps/apache_types.map,v
retrieving revision 1.7
diff -u -r1.7 apache_types.map
--- xs/maps/apache_types.map 26 Mar 2002 01:52:12 -0000 1.7
+++ xs/maps/apache_types.map 12 Aug 2002 08:16:41 -0000
@@ -43,7 +43,7 @@
########## Standard types ##########
int | IV
-int * | UNDEFINED
+int * | PTR
unsigned int | UV
signed int | IV
long | IV
that's said should the XS generator generate a fatal error when an XS
wrapper is not created, because one of the argument's typemap is unknown?
in any case, the automatic wrapper now gets added. But its arguments are:
const char *
ap_get_remote_host(conn, dir_config, type, str_is_ip)
Apache::Connection conn
void * dir_config
int type
int * str_is_ip
should the wrapper accept $r instead of $c (requiring a manual wrapper)?
should we NULL the str_is_ip argument? It seems to me that the Perl
interface should be:
$r->get_remote_host($type);
($type is new to 2.0)
>> --- Changes 21 Jun 2002 22:35:49 -0000 1.29
>> +++ Changes 31 Jul 2002 16:32:40 -0000 1.30
>> @@ -12,6 +12,8 @@
>>
>> =item 1.99_04 - June 21, 2002
>>
>> +added $r->get_remote_host to compat.pm + test [Stas Bekman]
>> +
>
>
> and, um, 1.99_04 was already released. new changes should be under
> 1.99_05-dev.
sorry about that, will fix.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org