On Mon, Jul 7, 2008 at 8:07 AM, Mladen Turk [EMAIL PROTECTED] wrote:
Sander Striker wrote:
[...]
I checked on the archives, as I stumbled over the code and wondered
what the heck it was for. I don't seem to find a response as to what
this functionality is actually needed for. In case I
Sander Striker wrote:
Unlike traditional pool it creates standalone pool (and allocator if
provided at creation time).
If *not* provided at creation time. Why not use the global allocator
in that case? If the user really needs a separate allocator, it's two
extra lines. The allocator
Mladen Turk wrote:
Again, the global allocator might get destroyed before the
child pool since for it the owner is global pool.
Interesting observation, hinging on being a bug itself.
Making sure that apr_terminate is called as last makes the need
for tracking the child pools, and it breaks
On Tue, Jul 8, 2008 at 3:26 PM, William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
Mladen Turk wrote:
Again, the global allocator might get destroyed before the
child pool since for it the owner is global pool.
Interesting observation, hinging on being a bug itself.
All pools are guaranteed to
Sander Striker wrote:
On Tue, Jul 8, 2008 at 3:26 PM, William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
Mladen Turk wrote:
Again, the global allocator might get destroyed before the
child pool since for it the owner is global pool.
Interesting observation, hinging on being a bug itself.
All
Sander Striker wrote:
At the very least the docstring should be updated with a big fat
warning saying not to use it unless you know what you are doing. And
maybe mention the typical use case of being in an environment with GC.
Right now, there is nothing in the docstring to protect an
William A. Rowe, Jr. wrote:
Sander Striker wrote:
At the very least the docstring should be updated with a big fat
warning saying not to use it unless you know what you are doing. And
maybe mention the typical use case of being in an environment with GC.
Right now, there is nothing in the
Mladen Turk wrote:
Any problems renaming the API in 1.3.x as well?
Yup, it shipped. So we can @deprecate your original choice of name
and add any new name that's appropriate.
William A. Rowe, Jr. wrote:
Mladen Turk wrote:
Any problems renaming the API in 1.3.x as well?
Yup, it shipped. So we can @deprecate your original choice of name
and add any new name that's appropriate.
Does depreciation means the function must be implemented?
I suppose it should, so
On Tue, Jul 8, 2008 at 5:24 PM, Mladen Turk [EMAIL PROTECTED] wrote:
William A. Rowe, Jr. wrote:
Mladen Turk wrote:
Any problems renaming the API in 1.3.x as well?
Yup, it shipped. So we can @deprecate your original choice of name
and add any new name that's appropriate.
Does
Hi All,
as you can see the recent update of devel/apr from 1.2.12 to 1.3.2
breaks apr-util when building with LDAP on FreeBSD. The log is from a
FreeBSD tinderbox, but can reproduced with the normal build steps.
The attached patch fixes it both in and out of tinderbox.
This particular diff
Resending from an address that will make it through to lists.
Philip M. Gollucci wrote:
Hi All,
as you can see the recent update of devel/apr from 1.2.12 to 1.3.2
breaks apr-util when building with LDAP on FreeBSD. The log is from a
FreeBSD tinderbox, but can reproduced with the normal build
On 07/08/2008 07:55 PM, Philip M. Gollucci wrote:
Resending from an address that will make it through to lists.
Philip M. Gollucci wrote:
Hi All,
as you can see the recent update of devel/apr from 1.2.12 to 1.3.2
breaks apr-util when building with LDAP on FreeBSD. The log is from a
Ruediger Pluem wrote:
if test $apu_has_ldap_openldap = 1; then
+CPPFLAGS=$save_cppflags
+LDFLAGS=$save_ldflags
+LIBS=$save_libs
Shouldn't this be the other way round such that you *safe* the old values
of CPPFLAGS, LDFLAGS and LIBS for later restore in the safe* variables?
You are
On 07/08/2008 09:23 PM, Philip M. Gollucci wrote:
Ruediger Pluem wrote:
if test $apu_has_ldap_openldap = 1; then
+CPPFLAGS=$save_cppflags
+LDFLAGS=$save_ldflags
+LIBS=$save_libs
Shouldn't this be the other way round such that you *safe* the old values
of CPPFLAGS, LDFLAGS and
Ruediger Pluem wrote:
Yes please. For ease of appliance and track of record.
Attached.
TIA
Index: build/apu-conf.m4
===
--- build/apu-conf.m4 (revision 674869)
+++ build/apu-conf.m4 (working copy)
@@ -357,6 +357,12 @@
])
Mladen Turk wrote:
William A. Rowe, Jr. wrote:
Mladen Turk wrote:
Any problems renaming the API in 1.3.x as well?
Yup, it shipped. So we can @deprecate your original choice of name
and add any new name that's appropriate.
Does depreciation means the function must be implemented?
I
On Thu, Jul 3, 2008 at 1:41 PM, Steve Comstock [EMAIL PROTECTED] wrote:
ahem...remember that I said 2.2 was a little more complicated than 2.0 on z/OS?
python? I need to install python?
yes and no. In httpd-2.2, python is used to create make dependency
files srclib/apr[-util]/buildoutputs.mk
Greg Ames wrote:
On Thu, Jul 3, 2008 at 1:41 PM, Steve Comstock [EMAIL PROTECTED] wrote:
ahem...remember that I said 2.2 was a little more complicated than 2.0 on z/OS?
python? I need to install python?
yes and no. In httpd-2.2, python is used to create make dependency
files
On Tue, 2008-07-08 at 17:18 -0400, Philip M. Gollucci wrote:
+CPPFLAGS=$save_cppflags
+LDFLAGS=$save_ldflags
+LIBS=$save_libs
Committed with quotes applied above. Thanks for the patch!
--
Bojan
William A. Rowe, Jr. wrote:
Mladen Turk wrote:
William A. Rowe, Jr. wrote:
Mladen Turk wrote:
Any problems renaming the API in 1.3.x as well?
Yup, it shipped. So we can @deprecate your original choice of name
and add any new name that's appropriate.
Does depreciation means the function
On Wed, 2008-07-09 at 07:27 +0200, Mladen Turk wrote:
What about trunk? Do we need depreciation there as well.
I suppose not, cause it wasn't released.
Trunk is currently marked 1.4.0, so I guess yes - you should have
deprecated function there too. If/when trunk officially goes 2.0, then
we
22 matches
Mail list logo
