On Wed, Jan 19, 2005 at 06:36:22PM -0500, Ben Hyde wrote:
missing close quote
Fixed, but it's supposed to be closed *before* not after ./configure ;)
53$ svn diff README.dev
Index: README.dev
===
--- README.dev(revision
On Wednesday 19 January 2005 18:33, Ryan Bloom wrote:
One of my biggest mistakes when initially designing APR was that I
forced each platform to have completely distinct implementations for
simple functions if the structures were distinct. This has led to a
great amount of duplicate code in
On Wed, Jan 19, 2005 at 08:49:51AM -0800, Justin Erenkrantz wrote:
--On Wednesday, January 19, 2005 12:21 PM + Joe Orton
[EMAIL PROTECTED] wrote:
They say to use the gnu-libtool port rather than one of the versioned
libtool ports, and that the latter are deliberately broken^Wdifferent
This isn't win32 specific, which is why it isn't in the other patch,
but it's a trivial fix. option_set_tls never actually returns anything.
--
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Index: apr_ldap_option.c
gr, should have sent this to the list.
Ryan
-- Forwarded message --
From: Ryan Bloom [EMAIL PROTECTED]
Date: Wed, 19 Jan 2005 15:05:10 -0500
Subject: Re: Re-architecture for 2.0 tree
To: William A. Rowe, Jr. [EMAIL PROTECTED]
So, I took a few shortcuts in my original
Colm MacCarthaigh said:
Not being able to compile apr-util was starting to get annoying :)
Fixed thanks :)
Regards,
Graham
--
Ryan Bloom said:
+1
Is it time for apr/trunk to become v2.0?
The LDAP stuff has some fundamental flaws that I need to fix, but I have
no sandbox to play in :(
Regards,
Graham
--
On Thu, Jan 20, 2005 at 03:42:18PM +0200, Graham Leggett wrote:
Colm MacCarthaigh said:
This isn't win32 specific, which is why it isn't in the other patch,
but it's a trivial fix. option_set_tls never actually returns anything.
The return codes are passed back inside the result_err
Colm MacCarthaigh said:
No, but the function is typed int, and it doesn't return ever one :)
Either return result-rc, like option_set_cert, or make the function
void :) But you can't have it both ways.
Sorry I misunderstood you - I thought the functions were not returning
result codes, in
On Thu, 2005-01-20 at 07:36, Graham Leggett wrote:
Ryan Bloom said:
+1
Is it time for apr/trunk to become v2.0?
The LDAP stuff has some fundamental flaws that I need to fix, but I have
no sandbox to play in :(
Might I suggest making a private branch? Branches are cheap and easy in
Brian W. Fitzpatrick said:
Might I suggest making a private branch? Branches are cheap and easy in
Subversion. While I abhor branching in CVS, in Subversion, I prefer to
work on a branch cause it's so easy to manage.
Can do - but I am going to need some handholding to set it up, haven't yet
Graham Leggett [EMAIL PROTECTED] writes:
Brian W. Fitzpatrick said:
Might I suggest making a private branch? Branches are cheap and easy in
Subversion. While I abhor branching in CVS, in Subversion, I prefer to
work on a branch cause it's so easy to manage.
Can do - but I am going to
On Tue, Jan 18, 2005 at 12:45:12AM +, Julian Foad wrote:
May I request re-insertion of the duplicate SAVE_FILES=... line and
an explanatory comment, as below? I don't like duplication, so
alternatives are welcome, but this is the best solution I can see at
present.
With autoconf 2.5x it
Should not the second argument to apr_brigade_create be named
bucket_alloc, rather than list.
It's not a list. It's not going in the list field of the resulting
apr_bucket_brigade.
There's some deep reason why this makes sense or is an immovable
object, isn't there?
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
15 matches
Mail list logo
