Currently APR::Pool::new() can create only parent pools, since it calls
apr_pool_create which is defined as:
#define apr_pool_create(newpool, parent) \
apr_pool_create_ex(newpool, parent, NULL, NULL)
We probably will need to provide functionality to create sub-pools,
either by extending the
Geoffrey Young wrote:
Stas Bekman wrote:
[EMAIL PROTECTED] wrote:
geoff 2003/09/04 09:39:44
Modified:xs/maps apr_functions.map
Log:
remove deprecated apr_pool_sub_make
in that case shouldn't be the replacement function apr_pool_create_ex
be enabled? I suppose it was disable
Stas Bekman wrote:
[EMAIL PROTECTED] wrote:
geoff 2003/09/04 09:39:44
Modified:xs/maps apr_functions.map
Log:
remove deprecated apr_pool_sub_make
in that case shouldn't be the replacement function apr_pool_create_ex be
enabled? I suppose it was disabled because the apr_pool_
[EMAIL PROTECTED] wrote:
geoff 2003/09/04 09:39:44
Modified:xs/maps apr_functions.map
Log:
remove deprecated apr_pool_sub_make
in that case shouldn't be the replacement function apr_pool_create_ex be
enabled? I suppose it was disabled because the apr_pool_sub_make
wrapper existed
Doug MacEachern wrote:
> On Thu, 31 Jan 2002, Stas Bekman wrote:
>
>
>>But why, Doug? If APR has it wrong, why cannot we fix it Perl? We do
>>adjust APIs to be Perlish, why cannot we set the function into a proper
>>namespace?
>>
>
> ok, now we're on a totally different subject. my response
On Thu, 31 Jan 2002, Stas Bekman wrote:
> But why, Doug? If APR has it wrong, why cannot we fix it Perl? We do
> adjust APIs to be Perlish, why cannot we set the function into a proper
> namespace?
ok, now we're on a totally different subject. my response to your commit
was that the guessing
>>But what about other functions? password_validate,
>>generate_random_bytes, etc...
>>
>>So it should be APR::password_validate?
>>
>
> yes. they should all be the way they were before. those c functions
> don't have _util in their names, so the perl function shouldn't have
> ::Util in their
On Wed, 30 Jan 2002, Stas Bekman wrote:
> But what about other functions? password_validate,
> generate_random_bytes, etc...
>
> So it should be APR::password_validate?
yes. they should all be the way they were before. those c functions
don't have _util in their names, so the perl function
Doug MacEachern wrote:
> On 30 Jan 2002 [EMAIL PROTECTED] wrote:
>
>
>>stas02/01/29 22:57:31
>>
>> Modified:xs/maps apr_functions.map
>> Log:
>> - package guessing was wrong, was using APR::function instead of
>> APR::Util::function. remove guessing.
>>
>
> no, the guessing is
On 30 Jan 2002 [EMAIL PROTECTED] wrote:
> stas02/01/29 22:57:31
>
> Modified:xs/maps apr_functions.map
> Log:
> - package guessing was wrong, was using APR::function instead of
> APR::Util::function. remove guessing.
no, the guessing is correct. APR::strerror is right,
Apa
On Wed, 30 Jan 2002, Stas Bekman wrote:
> done
cool, thanks.
> Should I? My scan generates different tables then yours. If you say it's
> OK, I'll always commit the tables when I change/add APIs.
actually, the tables don't need to be updated now that the apr_strftime
prototype is used in a
Doug MacEachern wrote:
> On 29 Jan 2002 [EMAIL PROTECTED] wrote:
>
>
>> +-apr_strfsize
>>
>
> the stuff below should be here, like:
> apr_strfsize | mpxs_APR__String_strfsize | buf | format_size
>
done
> also, i think you forgot to checkin xs/APR/String/APR__String.h
Sorry, committ
On 29 Jan 2002 [EMAIL PROTECTED] wrote:
> +-apr_strfsize
the stuff below should be here, like:
apr_strfsize | mpxs_APR__String_strfsize | buf | format_size
> --- modperl_functions.map 21 Jan 2002 08:27:30 - 1.33
> +++ modperl_functions.map 29 Jan 2002 07:47:25 -
13 matches
Mail list logo
