Joe Orton wrote:
On Mon, Nov 22, 2004 at 08:14:26PM -, Paul Querna wrote:
Author: pquerna
Date: Mon Nov 22 12:14:25 2004
New Revision: 106214
Modified:
apr/apr/trunk/CHANGES
apr/apr/trunk/configure.in
apr/apr/trunk/include/apr.h.in
apr/apr/trunk/misc/unix/rand.c
Log:
Use uuid_generate()
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 th
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 never be
necessary to cast anything to "const voi
On Mon, Nov 22, 2004 at 08:14:26PM -, Paul Querna wrote:
> Author: pquerna
> Date: Mon Nov 22 12:14:25 2004
> New Revision: 106214
>
> Modified:
>apr/apr/trunk/CHANGES
>apr/apr/trunk/configure.in
>apr/apr/trunk/include/apr.h.in
>apr/apr/trunk/misc/unix/rand.c
> Log:
> Use uuid_
--On Monday, November 22, 2004 1:08 PM -0600 "William A. Rowe, Jr."
<[EMAIL PROTECTED]> wrote:
That *will* affect the 2.2 uptake rate because our third parties will
take a lot of time to get their modules 64-bit clean (if they do at all).
WHO CARES?!? That's on them. They can release bug fixes
At 12:17 PM 11/22/2004, Justin Erenkrantz wrote:
>I expect that as it stands right now most 2.0 modules will compile for 2.2
>with very minor (if any) changes. If we 'fix' 64-bit issues now, then that
>means that their modules are going to undergo massive changes.
This I will attest to; port
--On Monday, November 22, 2004 11:27 AM -0500 Jim Jagielski <[EMAIL PROTECTED]>
wrote:
I agree... Otherwise, we won't see many people move to
2.2 since 3rd party modules won't be available for it,
since module developers will know that within a "short"
amount of time, they'll need to "redo" their
Justin Erenkrantz wrote:
Can we please get some feedback on the following releases:
http://www.apache.org/~jerenkrantz/0.9.5/
(The directory actually contains 0.9.5 and 1.0.1.)
1.0.1 builds successfully as an RPM under RHEL3.
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signatur
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
At 11:08 AM 11/22/2004, Cliff Woolley wrote:
>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 norma
Bill Stoddard wrote:
>
> William A. Rowe, Jr. wrote:
>
> > At 08:23 AM 11/20/2004, Jim Jagielski wrote:
> >
> >
> >>On Nov 20, 2004, at 12:03 AM, Justin Erenkrantz wrote:
> >>
> >>>So, my opinion is that we let Allen branch apr off now and let him go at
> >>>it at a measured pace, but we shoul
At 10:08 AM 11/22/2004, Bill Stoddard wrote:
>William A. Rowe, Jr. wrote:
>
>>At 08:23 AM 11/20/2004, Jim Jagielski wrote:
>>
>>>On Nov 20, 2004, at 12:03 AM, Justin Erenkrantz wrote:
>>>
So, my opinion is that we let Allen branch apr off now and let him go at it
at a measured pace, but we
William A. Rowe, Jr. wrote:
At 08:23 AM 11/20/2004, Jim Jagielski wrote:
On Nov 20, 2004, at 12:03 AM, Justin Erenkrantz wrote:
So, my opinion is that we let Allen branch apr off now and let him go at it at a measured pace, but we shouldn't intend to hold httpd 2.2 for that. -- justin
+1. Of cour
On Mon, Nov 22, 2004 at 06:26:33AM -0500, Jeff Trawick wrote:
> On Mon, 22 Nov 2004 11:34:10 +0100, Uwe Zeisberger
> <[EMAIL PROTECTED]> wrote:
> > Joe Orton wrote:
> > > Here's what I propose to fix this, anything I'm missing?
>
> it makes sense to me
OK, thanks, I've committed that fix to the t
On Mon, 22 Nov 2004 11:34:10 +0100, Uwe Zeisberger
<[EMAIL PROTECTED]> wrote:
> Joe Orton wrote:
> > Here's what I propose to fix this, anything I'm missing?
it makes sense to me
Joe Orton wrote:
> Here's what I propose to fix this, anything I'm missing?
Thats nearly the same as the patch I made in my wc. (Well, I didn't fix
the documentation in apr_xlate.h.) My code does the same as yours, so
it should be ok.
In my opinion, what's missing is the test, that apr_xlate_co
Here's what I propose to fix this, anything I'm missing?
Index: include/apr_xlate.h
===
--- include/apr_xlate.h (revision 106171)
+++ include/apr_xlate.h (working copy)
@@ -102,8 +102,15 @@
* @param outbytes_left Input: the size of
Branko Äibej wrote:
Garrett Rooney wrote:
+def win32ify_paths(paths):
+ rpaths = []
+ for p in paths:
+segs = re.split('/', p)
+rp = '.\\' + string.join(segs, '\\')
+rpaths.append(rp)
+
+ return rpaths
Hmmm
def win32ify_paths(paths):
return map(lambda x: '.\\'+string
Garrett Rooney wrote:
+def win32ify_paths(paths):
+ rpaths = []
+ for p in paths:
+segs = re.split('/', p)
+rp = '.\\' + string.join(segs, '\\')
+rpaths.append(rp)
+
+ return rpaths
Hmmm
def win32ify_paths(paths):
return map(lambda x: '.\\'+string.replace(x, '/', '\\
Here's the first version of the auto-generate DSP files patch that might
actually work. When diffed against the old DSP files the differences
all seem minor enough that this should work, although I have no real
proof since I don't have VC6 for testing.
This uses a similar approach to the DSP g
20 matches
Mail list logo
