On Mon, 22 Nov 2004, William A. Rowe, Jr. wrote:
Yes - I understand that this means 1.x will never be used by
httpd. Version numbers are cheap. The APR project should
become used to this, if they are active, and httpd moves at
it's normal pace, it would be easy to go through APR 2.x, 3.x,
On Mon, 22 Nov 2004, Julian Foad wrote:
Joe Orton wrote:
On Mon, Nov 22, 2004 at 08:14:26PM -, Paul Querna wrote:
+memcpy( (void*)uuid_data, (const void *)g, sizeof( uuid_t ) );
Please watch the code style, Paul!
Not sure exactly what Joe is referring to, but note that it should
On Wed, 24 Nov 2004, Allan Edwards wrote:
First order of business now that we are on SVN is to focus on
the APR changes that are needed. It's not clear to me though,
now that we have an APR 1.0 branch, is the trunk open for
API-breaking changes or do we need a separate branch for that work?
On Wed, 24 Nov 2004, William A. Rowe, Jr. wrote:
Allan - your last patches were to try to -wedge- the current
API into httpd. Can you share the patch just to fix APR?
Then we can start to comprehend scope. NO CASTS - just the
correct declarations in the first place.
Since this is obviously
On Wed, 24 Nov 2004, Garrett Rooney wrote:
I guess I'm just arguing for a single branch that's the target of the
current development, as opposed to one 64 bit dev branch and one trunk
which holds other changes, thus requiring us to either invest constant
effort in merging changes from the
On Wed, 24 Nov 2004, Justin Erenkrantz wrote:
Oh, please don't. We have *no* idea what the changes are or whether we'll
even ultimately accept them. Please branch Allen's changes off in a
sandbox (cp trunk branches/64-bit-changes) - let him get a workable version
that we can then review,
On Wed, 24 Nov 2004, Justin Erenkrantz wrote:
To be clear, I'm perfectly happy with merging to trunk in Allen's changes
*once* completed and reviewed and moving trunk to 2.x if need be - but I
Nevertheless, the question at hand is what action to take RIGHT NOW.
Let's just wait for... with no
On Wed, 24 Nov 2004, [ISO-8859-15] André Malo wrote:
As you might have noticed, I'm currently cleaning up the properties that are
left over from cvs and cvs2svn. In particular:
- removing cvs2svn:cvs-rev
- adjusting svn:executable (leaving only the real executables)
- adjusting
On Thu, 25 Nov 2004, Joe Orton wrote:
Or if it does, -1 veto on either bumping the APR major version or
creating a branch or making toast with jam before Allan submits a patch
for review on [EMAIL PROTECTED]
Okay, well, that means that for progress to be made, some form of patch
needs to get
On Tue, 30 Nov 2004, Jeff Trawick wrote:
* @param pwbuf Buffer to store the password
* @param bufsize The length of the password buffer.
+ * @remark If the password entered must be truncated to fit in
+ * the provided buffer, APR_ENAMETOOLONG will be returned.
*/
On Wed, 1 Dec 2004, David Barrett wrote:
A couple questions about the XML parser built into apr_util:
1) Does it support anything other than pure ASCII files?
2) Is there any way to parse UTF-8 files?
3) Does it use the Xerces XML back end?
My understanding is that it's just a wrapper
On Tue, 7 Dec 2004, Stas Bekman wrote:
Well, I see why it was made like this. this is because of the cleanup
wrapper:
Originally apr_brigade_cleanup() itself was the pool cleanup callback and
thus the void* argument type was necessary. Later on it was causing
badness on Win32 due (I think) to
On Tue, 7 Dec 2004, Stas Bekman wrote:
As explained in the other reply, it's not this code that causes the crash,
but (maybe) the wrapper that calls it. The wrapper is autogenerated based
on the prototype. I have no details of the crash, I hate talking on behalf
of someone, when I don't know
On Thu, 9 Dec 2004, Nick Kew wrote:
Why does the close function take a void arg? Can't we just pass it an
apr_dbt_t *?
To pass to apr_pool_cleanup funcs without a cast :-)
Don't do this. This is exactly the sort of thing that got us into trouble
with apr_brigade_cleanup(). In
On Thu, 9 Dec 2004, Nick Kew wrote:
If it is accepted as a startingpoint for an apr-util module, I'll
donate it to ASF and license it all under ASF terms.
If not, all rights reserved.
Concept definitely seems appealing...
On Wed, 15 Dec 2004, Brad Nicholes wrote:
release of APR 1.0. Since then there has been a lot of activity in
TRUNK as compared to almost no activity in the 1.0.x branch.
After the 1.0.x branch was created at ApacheCon, Justin and Thom
backported everything that they thought could be
On Mon, 27 Dec 2004, Garrett Rooney wrote:
This seems to defeat the point of having an APR_SUCCESS in the first
place. It's also (at least in my eyes) slightly less intuitive than
explicit testing.
Part of the definition of apr_status_t is the fact that APR_SUCCESS is
defined to be zero.
On Mon, 27 Dec 2004, Garrett Rooney wrote:
Ok, I think we may be talking about two different cases...
There's the check if a call returned an error, and if so return that to
your caller case, which personally I think is easist to read as:
if (rv)
return rv;
No, that's just me mixing up
On Mon, 27 Dec 2004, Mihai Limbasan wrote:
In reply to my earlier question - went ahead and did it.
What this patch does is fix all conditionals that depend implicitely
on APR_SUCCESS being zero to perform an explicit test against its
*macro definition* and not against the numeric literal or
On Thu, 20 Jan 2005, Ben Hyde wrote:
Should not the second argument to apr_brigade_create be named
bucket_alloc, rather than list.
It was supposed to mean freelist. It got its name before we came up
with a name for the bucket allocator (cleverly named bucket_alloc).
In other words, sure, go
On Thu, 20 Jan 2005, Ben Hyde wrote:
The mnemonic b is widely used for both buckets and brigades.
Sometimes e means bucket. :)
Buckets and brigades both have a field named list, but one is a
doubly linked list and the other is one of the many flavors of heap.
heh
I don't think anybody
On Sun, 30 Jan 2005, Nick Kew wrote:
If anyone with APR karma would like to take responsibility for committing
it, please contact me within 24 hours to discuss logistics.
This was me dropping the ball, and the problem is being corrected...
On Fri, 18 Feb 2005, Damir Dezeljin wrote:
I'm developing an application using APR on AS/400 (OS400) platform. As I
know only apr (no apr-utils) was ported to OS400 by IBM to run Apache2. Do
anyone know if there is any issue on compiling apr-utils on OS400?
apr-util is supposed to all be code
On Sun, 27 Feb 2005, Luca Renzi wrote:
I'm a student and I need to use apr_lib for a little
project.
The question is:
I don't understand what are data and key parameter for
the function
apr_socket_data_set.
Could somebody explain?
Several APR data types include a userdata member that is
@@ -46,6 +46,13 @@
apr_bucket_alloc_t *list = data;
apr_allocator_free(list-allocator, list-blocks);
+
+#if APR_POOL_DEBUG
+if (list-pool list-allocator != apr_pool_allocator_get(list-pool))
{
+apr_allocator_destroy(list-allocator);
+}
+#endif
+
On Thu, 17 Mar 2005, Justin Erenkrantz wrote:
he rolled it, I get 1 vote. Not 3. This is an absolute violation
of our charter and operating guidelines.
With that, the counter is at four hours, and I will pull
down this apr-iconv tarball unless the vote concludes
in favor of this
On Thu, 17 Mar 2005, Paul Querna wrote:
When I counted the votes, I interpreted all of the +1s to be for the
entire group (apr, apr-util, apr-iconv). I am sorry if I misinterpreted
any of the votes. This was not my intention.
This is, I think, the real question, and one I was asking myself.
On Thu, 17 Mar 2005, Jim Jagielski wrote:
Anyway, anyone who has ever been an RM has done something
to tick people off, it comes with the job ;)
amen to that...
On Thu, 17 Mar 2005, William A. Rowe, Jr. wrote:
If you two (and anyone else with an explicit vote on the apr-iconv
1.0.2 tarball) vote in the next hour it would clarify things quite
a bit.
My original vote was intended to be +1 for release. Apparently such a
vote at this point is of little
On Fri, 18 Mar 2005, Ryan Bloom wrote:
disabling sendfile solved it immediately. Seems to me that until our
sendfile support is better, we should err on the side of always
sending the data correctly instead of absolutely as fast as possible.
I would much rather have APR default to not using
On Tue, 22 Mar 2005, Marco Spinetti wrote:
I'd like to know the download and upload speed of clients with my server.
Can use some apr functions toknow these statistics?
I assume you're talking about Apache 2.0.x. If so, then it's the httpd
that you'll need to query for statistics like this,
On Thu, 31 Mar 2005, Sander Striker wrote:
Ryan Bloom wrote:
I really don't think we should take a function like apr_pcalloc and
convert it to a macro. The only reason to go to a macro is for
performance reasons. First, the performance boost should be
relatively minimal, and for
On Tue, 12 Apr 2005, Paul Querna wrote:
I believe APR 0.9.x is under CTR.
I was also under the impression that all branches of APR were CTR.
However, I agree that discussion on API changes would be good, even in a
CTR system. That has always been the basic idea with CTR -- you can
commit
On Thu, 26 May 2005, Daniel Rall wrote:
* apr/include/apr_thread_proc.h
(apr_thread_data_set): Corrected spelling of the word thread.
Got it, thanks!
On Tue, 12 Jul 2005, Dan Johnson wrote:
The problem is that I need to compile using MinGW under Cygwin, and
MinGW doesn't provide any of the shared memory header files (shm.h,
sys/mmap.h, sys/mman.h, etc.) so the test fails.
A quick Google shows that a few other people have had this problem
On Wed, 20 Jul 2005, Paul Querna wrote:
-1 for Win32, the condvars deadlock is a serious bug. I knew this is not
news, but as the patch had been available for quite a while, is it
possible to get it fixed?
No.
I will not commit such a platform specific patch. Anyone who actually
On Mon, 25 Jul 2005, Wilson, Brian A wrote:
I'm trying to track down an error when closing a program using apr. In
the jxta-c shell it calls apr_terminate upon exit but it ends up in an
infinite while loop in apr_allocator_destroy. I've traced it down to a
point where the while loop is
On Wed, 17 Aug 2005, Joe Orton wrote:
On Tue, Aug 16, 2005 at 01:49:55AM -0500, William Rowe wrote:
At 09:24 PM 8/15/2005, Garrett Rooney wrote:
So back in Dec 2003 Sander Striker suggested [1] adding Subversion's
macros for manipulating apr arrays (APR_ARRAY_IDX, which automates the
501 - 538 of 538 matches
Mail list logo
