[EMAIL PROTECTED] wrote:
joes2004/10/03 19:16:43
Index: in_out_filters.t
===
RCS file: /home/cvs/modperl-2.0/t/api/in_out_filters.t,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- in_out_
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Stas Bekman wrote:
[EMAIL PROTECTED] wrote:
gozer 2004/09/09 15:16:38
+/* XXX: There is no XS accessible splice() */
+static void modperl_av_remove_entry(pTHX_ AV *av, I32 index)
+{
+I32 i
Philippe M. Chiasson wrote:
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Stas Bekman wrote:
[EMAIL PROTECTED] wrote:
gozer 2004/09/09 15:16:38
+/* XXX: There is no XS accessible splice() */
+static void modperl_av_remove_entry(pTHX_ AV *av, I32 index)
+{
+I32 i;
+AV *tmpav = ne
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Stas Bekman wrote:
[EMAIL PROTECTED] wrote:
gozer 2004/09/09 15:16:38
+/* XXX: There is no XS accessible splice() */
+static void modperl_av_remove_entry(pTHX_ AV *av, I32 index)
+{
+I32 i;
+AV *tmpav = newAV();
+
+/* stash the e
Philippe M. Chiasson wrote:
Stas Bekman wrote:
[EMAIL PROTECTED] wrote:
gozer 2004/09/09 15:16:38
+/* XXX: There is no XS accessible splice() */
+static void modperl_av_remove_entry(pTHX_ AV *av, I32 index)
+{
+I32 i;
+AV *tmpav = newAV();
+
+/* stash the entries _before
Stas Bekman wrote:
[EMAIL PROTECTED] wrote:
gozer 2004/09/09 15:16:38
+/* XXX: There is no XS accessible splice() */
+static void modperl_av_remove_entry(pTHX_ AV *av, I32 index)
+{
+I32 i;
+AV *tmpav = newAV();
+
+/* stash the entries _before_ the item to delete */
+
[EMAIL PROTECTED] wrote:
gozer 2004/09/09 15:16:38
+/* XXX: There is no XS accessible splice() */
+static void modperl_av_remove_entry(pTHX_ AV *av, I32 index)
+{
+I32 i;
+AV *tmpav = newAV();
+
+/* stash the entries _before_ the item to delete */
+for (i=0; i
On Sat, 14 Feb 2004, Geoffrey Young wrote:
>
> [EMAIL PROTECTED] wrote:
> > randyk 2004/02/14 09:00:27
> >
> > Modified:xs/tables/current/ModPerl FunctionTable.pm
> > Log:
> > add missing env functions to FunctionTable
>
> drat, terribly sorry about that. thanks for cleaning up afte
[EMAIL PROTECTED] wrote:
> randyk 2004/02/14 09:00:27
>
> Modified:xs/tables/current/ModPerl FunctionTable.pm
> Log:
> add missing env functions to FunctionTable
drat, terribly sorry about that. thanks for cleaning up after me randy :)
--Geoff
Geoffrey Young wrote:
You are correct. I didn't realize that pflatten was a cheat (plus scary
comment in apr_brigade_pflatten: 'XXX This is dangerous beyond
belief..'). I thought it didn't call apr_brigade_length, but did flatten
at one pass. I should have looked at the source. Sorry about that.
> You are correct. I didn't realize that pflatten was a cheat (plus scary
> comment in apr_brigade_pflatten: 'XXX This is dangerous beyond
> belief..'). I thought it didn't call apr_brigade_length, but did flatten
> at one pass. I should have looked at the source. Sorry about that.
np. I guess w
Geoffrey Young wrote:
Stas Bekman wrote:
Doh! since my suggested change drops the use of apr_brigade_pflatten,
all this magic is no longer needed. just use the grow macro like all
other functions do and pass SvPVX to flatter. and whoah, no longer we
need the pool object! that's a goodness.
which
Stas Bekman wrote:
> Doh! since my suggested change drops the use of apr_brigade_pflatten,
> all this magic is no longer needed. just use the grow macro like all
> other functions do and pass SvPVX to flatter. and whoah, no longer we
> need the pool object! that's a goodness.
which makes it look
Doh! since my suggested change drops the use of apr_brigade_pflatten, all this
magic is no longer needed. just use the grow macro like all other functions do
and pass SvPVX to flatter. and whoah, no longer we need the pool object!
that's a goodness.
Here's the reworked patch (against cvs):
Ind
Geoffrey Young wrote:
but this is the same as newSVpvn(buffer, length);. You still allocate
the buffer twice (second time in mpxs_sv_grow which calls SvGROW). I've
attached the adjusted patch (of only this file), which allocates memory
only once. we should make it into a macro.
well, I was just d
> but this is the same as newSVpvn(buffer, length);. You still allocate
> the buffer twice (second time in mpxs_sv_grow which calls SvGROW). I've
> attached the adjusted patch (of only this file), which allocates memory
> only once. we should make it into a macro.
well, I was just doing it the wa
Geoffrey Young wrote:
ok, both of these issues are addressed in the attached patch.
looks good, a few efficiency fixes are due
pcalloc shouldn't be used, unless you really need to 0 all the bytes. palloc
is faster.
-return newSVpvn(buffer, length);
+mpxs_sv_grow(data, length);
+SvP
>
> Not only not intuitive, but wrong. Consider this case: some function
> returns the wanted amount of chars to slurp, let's say it decides that
> it doesn't want any more chars and sets $wanted to 0 and you passed it
> to $bb->flatten($pool, $wanted); now instead of getting an empty string,
>
Geoffrey Young wrote:
+return newSVpvn(buffer, length);
this is a bad idea. You should install the buffer into the SV not copy it.
what SV?
a new SV that you return.
__
Stas BekmanJAm_pH --> Just Another mod_p
> I see, now I understand why you had this 0 case special. You need to
> manipulate the perl stack here like other '...' functions do. In which
> case the last argument is optional.
yeah, ok
>
>> +return newSVpvn(buffer, length);
>
>
> this is a bad idea. You should install the buffer i
[EMAIL PROTECTED] wrote:
[...]
-# test that other length variants - such as constants and
-# subroutine returns - don't segfault
+# syntax: flatten($p, 0) is equivalent to flatten($p)
{
-my $rc = $bb->flatten(my $data, 30);
+my $data = $bb->flatten($
Geoffrey Young wrote:
Hmm, how come there are deprecated? This is from
apr/include/apr_network_io.h APR_0_9_BRANCH
you need to look at 1.0, of course.
Why? httpd-2.0 runs with APR_0_9_BRANCH, not 1.0. Or doesn't it?
well, it does for the moment, yes. but I've been cleaning things up so that
>>> Hmm, how come there are deprecated? This is from
>>> apr/include/apr_network_io.h APR_0_9_BRANCH
>>
>>
>>
>> you need to look at 1.0, of course.
>
>
> Why? httpd-2.0 runs with APR_0_9_BRANCH, not 1.0. Or doesn't it?
well, it does for the moment, yes. but I've been cleaning things up so tha
Geoffrey Young wrote:
Stas Bekman wrote:
[EMAIL PROTECTED] wrote:
geoff 2003/12/08 11:31:53
Modified:xs/APR/SockAddr APR__SockAddr.h
xs/maps apr_functions.map
xs/tables/current/Apache FunctionTable.pm
xs/tables/current/ModPerl FunctionTable.
Stas Bekman wrote:
> [EMAIL PROTECTED] wrote:
>
>> geoff 2003/12/08 11:31:53
>>
>> Modified:xs/APR/SockAddr APR__SockAddr.h
>>xs/maps apr_functions.map
>>xs/tables/current/Apache FunctionTable.pm
>>xs/tables/current/ModPerl FunctionTab
[EMAIL PROTECTED] wrote:
geoff 2003/12/08 11:31:53
Modified:xs/APR/SockAddr APR__SockAddr.h
xs/maps apr_functions.map
xs/tables/current/Apache FunctionTable.pm
xs/tables/current/ModPerl FunctionTable.pm
Log:
more APR deprecation: apr_so
Geoffrey Young wrote:
[EMAIL PROTECTED] wrote:
geoff 2003/11/25 10:56:34
Modified:xs/maps apache_functions.map modperl_functions.map
xs/tables/current/ModPerl FunctionTable.pm
Added: t/response/TestAPI mpm_query.pm show_mpm.pm
xs/Apache/MPM Apache__M
[EMAIL PROTECTED] wrote:
> geoff 2003/11/25 10:56:34
>
> Modified:xs/maps apache_functions.map modperl_functions.map
>xs/tables/current/ModPerl FunctionTable.pm
> Added: t/response/TestAPI mpm_query.pm show_mpm.pm
>xs/Apache/MPM Apache__MPM.h
On Mon, 2003-11-17 at 15:27, [EMAIL PROTECTED] wrote:
> geoff 2003/11/17 15:27:11
>
> Modified:xs/maps apr_functions.map apr_structures.map apr_types.map
>xs/tables/current/ModPerl FunctionTable.pm
> Added: xs/APR/Finfo APR__Finfo.h
> Log:
> add access to $
[EMAIL PROTECTED] wrote:
gozer 2003/03/04 01:42:42
Modified:.Changes STATUS
src/modules/perl modperl_cmd.c modperl_util.c modperl_util.h
t/conf extra.last.conf.in
t/response/TestDirective perldo.pm
xs/tables/current/
Can the xs wizards please verify that I did the reference counting
right? I'm afraid I might have a leak here.
+static MP_INLINE SV *mpxs_Apache__Filter_ctx(pTHX_
+ ap_filter_t *filter,
+ SV *data)
+{
Apache::server_root_relative is now fully 1.x compat and there is
a new Apache::server_root constant (no trailing /).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> maybe what we should do is have Apache->server_root_relative that behaves
> just like 1.x in Apache::compat and have 2.0's function be named
> Apache::server_root() which returns ap_server_root if fname == NULL and
> calls ap_server_root_relative() otherwise. this would also fix the
> current c
On Thu, 15 Nov 2001, Stas Bekman wrote:
> ok, that sounds good. I say we should change it. My reasoning is that
> the API never defined the case where fname==NULL, so it wasn't a part of
> the public API and users weren't supposed to use this method with
> fname==NULL => we can safely add t
Doug MacEachern wrote:
> On Wed, 14 Nov 2001, Stas Bekman wrote:
>
>
>>I've tested, it has a trailing /
>>
>
> then changing it to not have a trailing / could break people's
> existing code.
>
>
>>Do you think this patch makes sense? or should this be handled on the
>>apr_filepath_merge l
On Wed, 14 Nov 2001, Stas Bekman wrote:
> I've tested, it has a trailing /
then changing it to not have a trailing / could break people's
existing code.
> Do you think this patch makes sense? or should this be handled on the
> apr_filepath_merge level?
no, ap_server_root_relative() shouldn'
Doug MacEachern wrote:
> On Tue, 13 Nov 2001, Stas Bekman wrote:
>
>
>>ap_server_root_relative return the dir incliding the trailing / if
>>fname==NULL, which is bad.
>>
>
> need to do some research here:
> - what does 1.x do? if adds trailing /, then leave it alone
I've tested, it has a
On Tue, 13 Nov 2001, Stas Bekman wrote:
> ap_server_root_relative return the dir incliding the trailing / if
> fname==NULL, which is bad.
need to do some research here:
- what does 1.x do? if adds trailing /, then leave it alone
if no trailing /, bug is in apache-2.0
-
>#define mpxs_Apache_server(classname) \
>modperl_global_get_server_rec()
> +
> +static MP_INLINE char *mpxs_ap_server_root_relative(pTHX_
> +const char *fname,
> +apr_pool_t *p
On Sun, 16 Sep 2001, Stas wrote:
>
> Style police (should have pointed it out earlier):
>
> > +{
> > +local $| = 0;
> > +ok 9 == $r->print("buffered\n");
> > +ok 0 == $r->print();
> > +local $| = 1;
> > +ok 13 == $r->print('n','o','t',' ','b','u','f','f','e'
Style police (should have pointed it out earlier):
> +{
> +local $| = 0;
> +ok 9 == $r->print("buffered\n");
> +ok 0 == $r->print();
> +local $| = 1;
> +ok 13 == $r->print('n','o','t',' ','b','u','f','f','e','r','e','d',"\n");
> +}
> +
shouldn't
41 matches
Mail list logo
