Here is a small patch to add $r->header_(in/out)() to Apache::compat
No tests for it yet, but it does work.
NOTE: table_set_get might be usefull elsewhere than in compat.pm.
/home/gozer/sources/mod_perl2/deps/perl/bin/perl build/cvsdiff lib/Apache/compat.pm
todo
Index: lib/Apache/compat.pm
===
Scans, Generate, Builds and Works fine for me ;-)
There is one small little thing though...
> +static XS(MPXS_apr_table_get)
> +{
> +dXSARGS;
* +APR__Table t = modperl_hash_tied_object(aTHX_ "APR::Table", ST(0));
* +const char *key = (const char *)SvPV_nolen(ST(1));
> +
> +if (it
On Thu, Sep 27, 2001 at 07:07:48PM -0700, Doug MacEachern wrote:
> On Fri, 28 Sep 2001, Philippe M . Chiasson wrote:
>
> > Well, sounds more like a perl "bonus undocumented feature" to me. I don't
> > see why FETCH shouldn't be able to use wantarray() and return whatever it
> > wants Or am I
On Fri, 28 Sep 2001, Philippe M . Chiasson wrote:
> Well, sounds more like a perl "bonus undocumented feature" to me. I don't
> see why FETCH shouldn't be able to use wantarray() and return whatever it
> wants Or am I missing something here ?
$foo = $bar{baz}; where %bar is tied goes someth
On Thu, 27 Sep 2001, Doug MacEachern wrote:
> On Fri, 28 Sep 2001, Stas Bekman wrote:
>
> > issues:
> > - missing ALIAS for Apache::Server::dir_config (don't know how to make it
> > work with auto-auto-auto-generator :)
>
> add the common function to modperl_util.c, then it can be called from
>
On Thu, Sep 27, 2001 at 11:27:21AM -0500, Ken Williams wrote:
>
>
> Doug MacEachern <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 27 Sep 2001, Philippe M . Chiasson wrote:
> >
> >> Regarding that lengty thread about the list context version of the
> >> APR::Table->get/FETCH, here is what I found
On Thu, Sep 27, 2001 at 07:42:03AM -0700, Doug MacEachern wrote:
> On Thu, 27 Sep 2001, Philippe M . Chiasson wrote:
>
> > Regarding that lengty thread about the list context version of the
>APR::Table->get/FETCH,
> > here is what I found
> >
> ...
> > TIE=nope
> > METHOD=wantarray
>
> hm
On Fri, 28 Sep 2001, Stas Bekman wrote:
> issues:
> - missing ALIAS for Apache::Server::dir_config (don't know how to make it
> work with auto-auto-auto-generator :)
add the common function to modperl_util.c, then it can be called from
anywhere.
> - this patch is weird as it includes 3 diffe
On Thu, 27 Sep 2001, Stas Bekman wrote:
> 2. use normal C and prototype the functions as (table, key=NULL,
> val=NULL) instead of table, key=NULL, ...)
yeah, use the (table, key=NULL, val=NULL) prototype, dunno why 1.x didn't
do that.
-
On Fri, 28 Sep 2001, Stas Bekman wrote:
> - this patch implements the list context get
looks perfect stas, +1 !
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
- this patch implements Apache::RequestRec::dir_config
- adds tests for dir_config, PerlSetVar and PerlAddVar
issues:
- missing ALIAS for Apache::Server::dir_config (don't know how to make it
work with auto-auto-auto-generator :)
- this patch is weird as it includes 3 different implementations
- this patch implements PerlSetVar and PerlAddVar
(the tests are in the dir_config patch to follow)
Index: src/modules/perl/mod_perl.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
retrieving revision 1.71
diff -
- this patch implements the list context get
Index: t/response/TestAPR/table.pm
===
RCS file: /home/cvs/modperl-2.0/t/response/TestAPR/table.pm,v
retrieving revision 1.3
diff -u -r1.3 table.pm
--- t/response/TestAPR/table.pm 2001/09/
Doug MacEachern <[EMAIL PROTECTED]> wrote:
> On Thu, 27 Sep 2001, Philippe M . Chiasson wrote:
>
>> Regarding that lengty thread about the list context version of the
>> APR::Table->get/FETCH, here is what I found
>>
> ...
>> TIE=nope
>> METHOD=wantarray
>
> hmm, could be that @a = $table->
On Thu, 27 Sep 2001, Stas Bekman wrote:
> ok, but what's the drawback of be tied to xsubpp if we use it anyway?
so if we decide to not use xsubpp we don't need to untangle anything.
> I was just thinking that if your C function wants to mess up with SVs,
> and the wrapper always convert thes
Doug MacEachern wrote:
> On Thu, 27 Sep 2001, Stas Bekman wrote:
>
>
>>why the following pseudo-code screws everything. I think it messes up
>>the SP, but I cannot tell since I cannot run the debugger :( I guess I
>>could test it outside of mod_perl env.
>>
>
> perldoc perlapi
> =item dSP
>
Doug MacEachern wrote:
> On Thu, 27 Sep 2001, Stas Bekman wrote:
>
>
>>why do we write C functions in Foo__Bar.h files and end up with XS
>>wrapper doing extra function call and sometimes doing redundant args
>>conversion, instead of writing in pure XS like 1.x does? Isn't it
>>slowing thin
On Thu, 27 Sep 2001, Stas Bekman wrote:
> but nothing prevents us from doing it our way, that's why I was
> suggesting the map file. We do change the API, so I don't see a reason
> not to change constants.
i would prefer not to change the api in this case. we do not change the
names of any
On Thu, 27 Sep 2001, Stas Bekman wrote:
> why the following pseudo-code screws everything. I think it messes up
> the SP, but I cannot tell since I cannot run the debugger :( I guess I
> could test it outside of mod_perl env.
perldoc perlapi
=item dSP
Declares a local copy of perl's stack poi
On Thu, 27 Sep 2001, Stas Bekman wrote:
> why do we write C functions in Foo__Bar.h files and end up with XS
> wrapper doing extra function call and sometimes doing redundant args
> conversion, instead of writing in pure XS like 1.x does? Isn't it
> slowing things down? (the extra call and co
On Thu, 27 Sep 2001, Gerald Richter wrote:
> I have played along this line a few hours, taken the grammer from Inline::C
> and Inline::Struct and now have a nearly working replacement for C::Scan. I
> think this is the right way to go, since the RecDecent parser grammer is
> much easier to exten
On Thu, 27 Sep 2001, Philippe M . Chiasson wrote:
> Regarding that lengty thread about the list context version of the
>APR::Table->get/FETCH,
> here is what I found
>
...
> TIE=nope
> METHOD=wantarray
hmm, could be that @a = $table->{foo}; doesn't work in 1.x either. which
would be good
Doug MacEachern wrote:
> On Thu, 27 Sep 2001, Stas Bekman wrote:
>
>
>>>yeah. i just wish those names were prefixed APR_TABLE_*, but i'm tired of
>>>renaming apr stuff.
>>>
>>so we need something like xs/map/apr_constants.map or are you doing this
>>elsewhere already?
>>
>
> no, i mean i wis
On Thu, 27 Sep 2001, Stas Bekman wrote:
> > yeah. i just wish those names were prefixed APR_TABLE_*, but i'm tired of
> > renaming apr stuff.
>
> so we need something like xs/map/apr_constants.map or are you doing this
> elsewhere already?
no, i mean i wish they were prefixed APR_TABLE_ in ap
why the following pseudo-code screws everything. I think it messes up
the SP, but I cannot tell since I cannot run the debugger :( I guess I
could test it outside of mod_perl env.
XS(XS_foo)
{
dXSARGS;
RETVAL = foo();
#line 310 "RequestUtil.c"
ST(0) = RETVAL;
sv_2m
why do we write C functions in Foo__Bar.h files and end up with XS
wrapper doing extra function call and sometimes doing redundant args
conversion, instead of writing in pure XS like 1.x does? Isn't it
slowing things down? (the extra call and conversions)
I understand that the wrapper is usef
Doug,
> gerald, i would be happy to see the source parser usable outside of
> modperl. first i would like to solve the C::Scan problem. it just isn't
> usable on every system.
Agreed
> i think one option would be to ditch C::Scan and
> see if Parse::RecDecent can be used in place of it. i
27 matches
Mail list logo
