Geoffrey Young wrote:
Stas Bekman wrote:
Guys in the thread below make a good point. Should we accept a multiline
config and split it behind the scenes? Of course since we don't know
whether there are new lines in it we will always need to split.
($r|$s)->add_config($multi_line_config);
doug ori
Geoffrey Young wrote:
Looks good, but what do we need it for, again?
I'm not exactly sure, but I have a few ideas.
shouldn't we work on todo/release first and solving probs that we
encounter or reported?
well, I was working on something where it came into play, so it's kinda
solving my problem :
Stas Bekman wrote:
> Guys in the thread below make a good point. Should we accept a multiline
> config and split it behind the scenes? Of course since we don't know
> whether there are new lines in it we will always need to split.
>
> ($r|$s)->add_config($multi_line_config);
doug originally des
> Looks good, but what do we need it for, again?
I'm not exactly sure, but I have a few ideas.
>
> shouldn't we work on todo/release first and solving probs that we
> encounter or reported?
well, I was working on something where it came into play, so it's kinda
solving my problem :)
--Geoff
[it seems that emails arrive with 5 hours delay]
Geoffrey Young wrote:
hi
within each bucket brigade is a pool. according to the docs (apr_bucket.h),
the pool isn't involved with the allocation of the brigade, but rather is
associated with the brigade.
I think that it would be useful to have acc
hi
within each bucket brigade is a pool. according to the docs (apr_bucket.h),
the pool isn't involved with the allocation of the brigade, but rather is
associated with the brigade.
I think that it would be useful to have access to that pool. in perl, it
would mean that when using a brigade cre
Guys in the thread below make a good point. Should we accept a multiline
config and split it behind the scenes? Of course since we don't know whether
there are new lines in it we will always need to split.
($r|$s)->add_config($multi_line_config);
if we do that I'm not sure whether we should dro
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
Geoffrey Young wrote:
Stas Bekman wrote:
If you have followed the end of the long story on windows with free to
wrong pool, you'd have known that one of the reason for the problem was
the use of the wrong context in add_config in the following snippet:
PerlOptions +Parent
use Apache::ServerUt
As some of you may have followed the discussions here, we are scared to death
from users using the wrong pools and shooting themselves into the foot.
Really, what happens is that we take the cool easy Perl and bring back the
malloc/free issue in a different reincarnation. It's the 'free' part th
[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($
>> the problem with all of these is that it's breaking away from the 1:1
>> mapping of the original apr_brigade_(p)flatten APIs. if we're going
>> to do
>> that to make them more perlish, I'd much rather see
>>
>> my $data = $bb->flatten(30); # calls apr_brigade_flatten
>> my $data = $bb->fl
13 matches
Mail list logo
