At 06:30 PM 6/23/2004, David Reid wrote:
I'd like to suggest we hold our horses on apr-util and apr-iconv 1.0 -
they
are seperate subsets with their own set of issues.
APR 1.0 does not require apr-util or apr-iconv, there is no dependency.
So no holdup of David's plans.
Well, I'd agree on
At 12:35 PM 6/25/2004, Branko Čibej wrote:
David Reid wrote:
If the answer to the question does what we have now work is yes then
apr-util 1.0 is good to go.
+1
The apr-iconv API is unfortunate, and the fact that it doesn't support
transliteration like GNU libiconv is worse, but most uses of
Can I get a vote on apr-iconv in this respect?
At 01:12 PM 6/25/2004, William A. Rowe, Jr. wrote:
I'm tempted to say we explicitly declare libapriconv as a private library of
libaprutil, just as the bundled expat is, with no public api support. That
simplifies things to simply @doxygenate
At 04:14 PM 6/27/2004, Paul Querna wrote:
I think we should branch httpd 2.1 into 2.2, and make a new stable
branch. The focus Work on making an APR 1.1 with *any* API changes we
need, and at the same time push 2.1 towards a 2.2 branch. Hopefully in
a month or two, release APR 1.1.0 and HTTPd
At 04:17 AM 6/28/2004, Joe Orton wrote:
OK, the apr_procattr_addrspace_set() interface is sufficient to solve
this problem, right? And there's no issue with back-porting that to the
APR 0.9 branch? The only issue is how to use that interface from
mod_cgi/the Netware MPM without requiring an
At 07:06 AM 6/30/2004, David Reid wrote:
I haven't done apr-iconv as Will Rowe had some reservations about that
module. If someone who's more familiar wants to roll a tarball that's
compatible with rc2 that'd be great.
Doesn't matter - now that you've tagged apr-util-1.0.0 - we are locked
into
At 03:56 AM 6/30/2004, Joe Orton wrote:
On Wed, Jun 30, 2004 at 09:49:48AM +0100, Max Bowsher wrote:
Joe Orton wrote:
On Tue, Jun 29, 2004 at 03:11:30PM -0400, Greg Hudson wrote:
...
So, please change the recently added pkgconfig support to install
apr-1.pc, so that upstream packages will
At 08:17 AM 6/30/2004, Jeff Trawick wrote:
I like Joe's suggestion of catching it in the test suite. If the API is ever
changed so that the caller specifies the length of their buffer, then there
will be an interesting case which apr_snprintf() could catch.
Unfortunately, you would need to
At 04:55 PM 7/1/2004, Joe Orton wrote:
On Thu, Jul 01, 2004 at 11:45:44PM +0200, Graham Leggett wrote:
Joe Orton wrote:
I've noticed that the most recent CVS of 1.0.0 installs both
/usr/bin/apr-config, and /usr/bin/apr-1-config. Is this intentional?
Yes, for the moment.
How do you
While researching -ctime thoughts on list... (the entire thread might be
enlightening to review for those who want some weekend reading :)
Nearly a year ago, At 11:09 AM 6/25/2003, William A. Rowe, Jr. wrote:
At 03:27 AM 6/25/2003, Marc M. Adkins wrote:
* emulating the daemon/services foo within
At 06:41 PM 7/1/2004, Branko Čibej wrote:
Thoughts? I think 1.0 is an auspicious time to make this change, especially if
we declare apr-iconv to be an implementation detail of apr_xlate.
The nifty bit is, if we declare apr-iconv to be an internal, implementation
detail of apr_xlate - we are
to chime in?
At 06:28 PM 7/1/2004, Branko Čibej wrote:
William A. Rowe, Jr. wrote:
As we approach APR 1.0
---
is it time to address the ambiguity between ctime, which is actually the
inode file time stamp for unix, and the creation time stamp for win32?
Persisting either ctime will propogate
At 07:29 PM 7/1/2004, Greg Stein wrote:
On Thu, Jul 01, 2004 at 05:38:34PM -0500, William A. Rowe, Jr. wrote:
If we leave it, and side-by-side installs are broken, this does not seem
like a good initial release point for 1.0 :(
for the moment
Joe said it *twice*. Was it that non-obvious
At 02:24 AM 7/2/2004, William A. Rowe, Jr. wrote:
[...]
And in hind site - I don't see any reason we can't implement signals on
win32 using the existing API. The ctime issue was brought up again
and seems to be pretty important. And mapping ACL's on HPUX/Win32
and Linux/SE seems like it's own
At 11:20 AM 7/2/2004, you wrote:
At 07:29 PM 7/1/2004, Greg Stein wrote:
On Thu, Jul 01, 2004 at 05:38:34PM -0500, William A. Rowe, Jr. wrote:
If we leave it, and side-by-side installs are broken, this does not
seem
like a good initial release point for 1.0 :(
for the moment
Joe said
At 12:46 PM 7/2/2004, Branko Äibej wrote:
William A. Rowe, Jr. wrote:
At 06:41 PM 7/1/2004, Branko Ãibej wrote:
Thoughts? I think 1.0 is an auspicious time to make this change, especially
if we declare apr-iconv to be an implementation detail of apr_xlate.
The nifty bit is, if we declare
Here's the patch for those interested, which splits ctime into crtime
and intime.
An interesting side effect, neither crtime nor intime stay part of the
APR_FINFO_MIN set of information - one bit or the other would be
toggled.
BillIndex: file_io/netware/filestat.c
At 10:45 AM 7/12/2004, Graham Leggett wrote:
I have created a spec file for apr-iconv - but so far it seems apr-iconv is
only necessary on windows. Can anyone confirm whether apr-iconv is needed on
any Unix like platforms at all?
Anyone have other examples for Graham? Inquiring minds want to
At 10:52 AM 7/12/2004, David Reid wrote:
Timetable is RC4 tomorrow, 1.0.0 on Thursday afternoon after my proficiency
checks at work are over!
David, please make sure we don't include STATUS in those final tarballs.
I'd like to roll an RC4 win32 .zip as soon as your are done rolling RC4.
If you
At 10:43 AM 7/14/2004, Joe Orton wrote:
On Wed, Jul 14, 2004 at 04:33:14PM +0100, Max Bowsher wrote:
Joe Orton wrote:
RC4 is still installing prefix/bin/apr-config , so making it impossible
to
install apr 0 and apr 1 side-by-side.
Known issue, will get fixed sometime after 1.0.0 once
introduces intime/crtime (I missed adding
the actual apr_time_t intime member in the last patch - this fixes it.)
The doc_fix patch just documents the deficiency. Let's pick one or the other.
Bill
At 03:06 PM 7/2/2004, William A. Rowe, Jr. wrote:
Here's the patch for those interested, which
At 04:24 PM 7/14/2004, Max Bowsher wrote:
Joe Orton wrote:
On Wed, Jul 14, 2004 at 04:12:29PM +0100, Max Bowsher wrote:
David Reid wrote:
Tarballs available at http://www.apache.org/~dreid/
Test report!
RC4 is still installing prefix/bin/apr-config , so making it impossible
to
install apr
At 10:09 AM 7/15/2004, Justin Erenkrantz wrote:
--On Thursday, July 15, 2004 5:34 AM -0700 Noah Misch [EMAIL PROTECTED]
wrote:
The minimum version field does need to accept two digits. A project could
use an API added in APR 1.X, in which case e.g. APR_FIND_APR(,,, 1.4, 3)
would be appropriate
At 04:11 AM 7/16/2004, Max Bowsher wrote:
4) Because there is no sensible default. [1 0] implies that a project should
work with either. Unless project maintainers decide to maintain testing of
both versions, the secondary choice may well get stale.
Defaulting to [1] will result in projects that
At 06:54 PM 7/19/2004, Nick Kew wrote:
I have a couple of modules using third-party libraries that require me
to supply an abort function (or they'll abort by exiting).
For example, libjpeg in my mod_jpeg.
My preferred approach to this situation is usually to resort to C++,
put my code in a
At 04:06 AM 7/24/2004, Nick Kew wrote:
Is there some fundamental reason why there's no apr_prealloc()?
[...] I can't help thinking this should be
(a) standardised.
(b) optimised to work with pools.
I've thought that for some time, with the understanding that you can't
be playing in the pool
If you toggle the
APR_FILES_AS_SOCKETS constant back to 0
(zero)does this remedy the behavior you are seeing?
Bill
At 05:41 PM 6/30/2004, Jean-Jacques Clar wrote:
I am getting the following error when running CGIs on the current
version of NetWare (6.5 sp2):
(32)Broken pipe:
At 08:18 AM 7/30/2004, David Reid wrote:
However, we need to remove the APR_STATUS_IS_SUCCESS macro before 1.0 goes
out, because otherwise we are stuck with it for a very long time.
There were win32 comments from Brane? Is someone going to commit the changes
needed?
What changes? Note in
Although I agree, with your patch in spirit, if apr_thread_join is never
called, your patch -can- leak handles like a sieve :(
Did we ever define that apr_thread_create() must be partnered with
an apr_thread_join? If not, it seems we need a clever way to mark
the apr_thread_t HANDLE member as
At 12:26 PM 7/30/2004, Graham Leggett wrote:
William A. Rowe, Jr. wrote:
4. our APR_HAS_XXX_LDAPSDK macros are entirely bogus, still,
on unix.
Explain? (so I can fix).
Here's my philosophy. First, we don't set up the HAS_BAR_LDAPSDK 0
values after setting the HAS_FOO_LDAPSDK 1 value. So
At 12:11 PM 8/1/2004, Graham Leggett wrote:
David Reid wrote:
So I see. I'll tag roll APR RC5 later on tonight and hopefully as soon as
apr-util is patched for apr-config I'll be able to roll.
Would it be possible to include the recent LDAP changes in v1.0.0? They fix
some LDAP fooness that
At 04:04 PM 8/2/2004, Graham Leggett wrote:
David Reid wrote:
The main fooness is in apr_ldap_url.c. Can we not mark this code as
deprecated in v1.0, which should hopefully warn alert coders that the code
should not be used, and can be pointed out to coders who are asleep
otherwise if they
At 12:53 PM 8/2/2004, David Reid wrote:
Graham Leggett wrote:
William A. Rowe, Jr. wrote:
I would be +1 to simply remove auth_ldap from APR 1.0, and reintroduce
the entire feature in the new APR 1.1 (which we can start development
on immediately.) And that presumes httpd 2.1/2.2 will depend
At 06:08 AM 8/3/2004, Graham Leggett wrote:
William A. Rowe, Jr. wrote:
Right now it does little. Graham and I agree on the right solution,
to abstract out the logic to do SSL connections in a portable way.
There will be no need for the 'application developer' to know which
toolkit
malc,
is there anything that can be done in our apr/test/ tree to validate
the correct behavior, and tickle these bugs? This would obviously
help validate the patches you propose, and possibly pick up such
bugs in other condition variable implementations.
The emphasis for 1.0.0 is
At 02:49 PM 8/12/2004, James Mansion wrote:
I'd like to offer a replacement for the broken critsec code.
Who can I send it to for review?
I've never contributed before, have filled no paperwork etc. I work through
a contractor umbrella company and I'm at home rather than at a client site,
so I
At 02:24 PM 8/27/2004, Mladen Turk wrote:
Cliff Woolley wrote:
On Fri, 27 Aug 2004, Mladen Turk wrote:
c) If thread_exit was never called before thread_join
do not set the retval but rather return APR_INCOMPLETE.
That's really what the unix impl does?
Probably not :)
Didn't test what
At 03:02 PM 8/28/2004, Cliff Woolley wrote:
Normally Bill Rowe will come along behind and build a .zip of the
distribution that was checked out using a Win32 version of CVS so that
*all* of the files have DOS line endings. The .tar.gz and .tar.Z
distributions always have unix line endings.
At 08:31 PM 8/28/2004, William A. Rowe, Jr. wrote:
On Sat, 28 Aug 2004, Klaus Keppler wrote:
If that's not possible, a small notice in the docs would certainly
help other people ;-)
Seeing as we offer the tool for the job (apr/build/lineends.pl) that
sounds like a wonderful idea! Working
At 01:32 PM 9/1/2004, Mladen Turk wrote:
Bill Stoddard wrote:
Not sure what's the total httpd's time spent for palloc,
but I suppose it's quite a large value.
I saw no significant difference serving a 500 byte file:
Keep in mind that the whole idea behind APR pools is to minimize calls to the
Just thought this might bite some apr dev'ers - The initial SP2
release will not loopback on any port except 127.0.0.1, so if you
use .2, .3 etc in more sophisticated testing, these will bomb
under SP2. They know it, there is a generally unavailable fix
for this condition.
Bill
At 07:53 PM 9/17/2004, you wrote:
and the rename of apr_file_permissions group:
s/APR_/APR_FILEPROT_/
Veto - defer for 2.0
At 09:05 PM 9/17/2004, William A. Rowe, Jr. wrote:
At 06:54 PM 9/17/2004, you wrote:
So any objecttions to the s/APR_/APR_FILETYPE_/ rename?
Veto - defer for 2.0
I don't object to the new names, but find it pretty absurd
to start deprecating interfaces the month we roll out 1.0.
Bill
At 08:34 PM 9/17/2004, you wrote:
This group wasn't discussed before, but it suffers from the same problem.
#define APR_READ 0x1 /** Open the file for reading */
#define APR_WRITE 0x2 /** Open the file for writing */
#define APR_CREATE 0x4 /** Create the
At 10:03 PM 9/17/2004, Max Bowsher wrote:
Stas Bekman wrote:
William A. Rowe, Jr. wrote:
I don't object to the new names, but find it pretty absurd
to start deprecating interfaces the month we roll out 1.0.
You mean, I've missed the train?
Well, we are about to freeze the mod_perl 2 API, and we
At 09:15 AM 9/19/2004, Greg Stein wrote:
On Fri, Sep 17, 2004 at 09:21:17PM -0500, William A. Rowe, Jr. wrote:
At 07:53 PM 9/17/2004, you wrote:
and the rename of apr_file_permissions group:
s/APR_/APR_FILEPROT_/
Veto - defer for 2.0
There is no reason to wait until 2.0. The versioning
At 10:47 AM 9/19/2004, Mladen Turk wrote:
Trying for a third week :).
Keep trying :) Several project releases distracted a number
of users of this list...
so I'm sending them all at once with brief explanation for each.
Actually, it inhibits discussion to do that :( I would like
to see Ben
At 04:20 PM 9/19/2004, Stas Bekman wrote:
So if that's fine with everybody and now Bill has pulled down his veto, the
only thing to wait for is the APR_1_1 branch to appear? Any plans for that?
APR_1_0 should be created soon, before new progress.
HEAD should be 1_1 till we release it.
At 11:53 AM 9/20/2004, you wrote:
The following works on win32 but not on linux. Looks like the name field of
apr_file_t is never set on unix so the value is garbage.
are you testing the .valid bit APR_FINFO_FNAME value?
There are scenarios on every platform when specific fields
cannot be
At 01:21 PM 9/22/2004, [EMAIL PROTECTED] wrote:
--- ap_regkey.c 9 Feb 2004 20:40:49 - 1.11
+++ ap_regkey.c 22 Sep 2004 18:21:29 - 1.12
@@ -185,7 +185,7 @@
*/
LONG rc;
DWORD type;
-DWORD size = 0;
+apr_size_t size = 0;
At 11:33 AM 9/24/2004, [EMAIL PROTECTED] wrote:
clar2004/09/24 09:33:03
added define for DWORD_MAX
Could we -please- use an APR decorated name?
Bill
At 11:06 PM 9/27/2004, David Barrett wrote:
Ok, with Dror's and William's help I'm up and running with APR. Now, what
about static linking with APRICONV?
Starting with Dror's HelloWorld DSW (which compiles, links, and runs fine
with just APR), I added the lines:
# #include apr_iconv.h
# ...
#
At 01:14 PM 9/28/2004, you wrote:
Hi Guys,
We're starting a new open source project, and are looking into using APR
for our portable framework.
Wonderful! Once you have a beta release, we would love to include
you in the list of APR-based projects!
We started with the Win32 side first, and
At 02:49 PM 9/28/2004, [EMAIL PROTECTED] wrote:
First and foremost is httpd server. Version 2.1 (available from
http://httpd.apache.org/dev/dist/) is the version that builds
against APR 1.0, just drop apr and apr-util under it's srclib/ tree.
For Win32, also drop apr-iconv in there.
What's
At 03:30 PM 9/28/2004, William A. Rowe, Jr. wrote:
Win32 does not have the iconv library. We are considering moving to
the BSD distribution of iconv with Win32 specific patches, rather than
attempting to maintain a win32 flavor. For that reason, apr-iconv
should not be considered a permanent
At 05:50 PM 9/28/2004, Jeff Trawick wrote:
-#define DWORD_MAX 4294967295
+#define APR_DWORD_MAX 4294967295
or
#define APR_DWORD_MAX (DWORD_MAX)
since this is a platform which defines it?
or...
#ifdef DWORD_MAX
#define APR_DWORD_MAX DWORD_MAX
#else
#define DWORD_MAX 4294967295UL
#endif
At 11:48 AM 9/30/2004, Joe Orton wrote:
On Thu, Sep 30, 2004 at 11:22:41AM -0400, Allan Edwards wrote:
so I don't see how it could be made private either.
This patch demonstates that it can be made private,
Only if you redefine private :)
This is all pedantic, because you can't make this
At 12:21 PM 10/1/2004, Greg Marr wrote:
#ifdef DWORD_MAX
#define APR_DWORD_MAX DWORD_MAX
#else
#define APR_DWORD_MAX 0xUL
#endif
Defining DWORD_MAX at all could cause problems if it was defined by a later
header file.
++1, this is the right solution, and infinitely more legible.
At 11:12 AM 10/6/2004, you wrote:
As far as not having a bug in the !HAS_WRITEV implementation,
I disagree.
The current implementation does not have a single chance of
being successful if there is more than 1 vector. This does
not make sense to me. Let assume the write part is successful,
the
Daniel,
we really shouldn't be building unix/ on cygwin. In spite
of the built-in support, it simply hasn't been vetted and is
bound to have vulnerabilities if used for Apache 2.0.
Ideally we should modify the configure.in for cygwin to
determine win32/ as the build sources, and toggle
At 04:47 PM 10/14/2004, Max Bowsher wrote:
Cygwin is supposed to be unix-like. Packages shouldn't need to start applying
win32 specific tricks, and when they do, it often compromizes the unix-like
feel that is a major feature of Cygwin.
If cygwin used the unambiguous POSIX file flags and had
I should have added that the pseudo-fork and condition vars
on cygwin would actually be better preserved by using the
unix port. In fact, if the cygwin build simply used the win32
apr_file_io code I'd be quite happy with it relying on the
other (unambiguous) features of the cygwin API.
Bill
At
At 02:02 AM 11/12/2004, David Christie wrote:
Then I tried the dynamic libraries (project libaprutil). It failed immediately
with:
Configuration: libapr - Win32 Debug---
Creating apr.h from apr.hw
Creating Version Resource
Compiling resources...
At 12:04 PM 11/19/2004, Garrett Rooney wrote:
Second there is an awful lot of changing from foo *bar to foo * bar when
pointers are declared
foo * bar implies multiplication to the reader.
foo *bar implies pointer dereference.
Syntactically equal, visually very different.
At 12:30 PM 11/19/2004, Abbate, Joseph M wrote:
Hi Brad,
Now that we have converted to SVN, why doesn't the subject line
include the file that is being changed in the commit message? This
makes it harder to prioritize patches that need to be reviewed.
Even though I'm a newbie as far as
At 05:34 PM 11/19/2004, Garrett Rooney wrote:
Kris Carlgren wrote:
Hi. I know Im new, and I wanted to check out the APR-1.0.0 release. With
the release, APR is receiving a lot of attention at the moment, so I thought
Id post my only problem and solution.
Everything compiled fine under
At 06:52 PM 11/19/2004, Justin Erenkrantz wrote:
--On Saturday, November 20, 2004 1:49 AM +0100 André Malo [EMAIL PROTECTED]
wrote:
Just a question:
Maybe I'm missing the info - is the httpd trunk supposed to work with the
apr 1.0.x branch or just the apr trunk?
We're going to have to decide
At 09:14 PM 11/19/2004, Garrett Rooney wrote:
William A. Rowe, Jr. wrote:
ONLY if svn:eol-style crlf in conjunction with an svn diff produces
an identical result on linux and win32. Even then it creates a
binary diff (mixing line ending codes). This is -not- elegant.
Search for my previous
At 09:35 PM 11/19/2004, Garrett Rooney wrote:
William A. Rowe, Jr. wrote:
Simple. Let me suggest a patch containing
libapr.dsp
apr.dsp
build/config.m4
that effects some change to the build, for private build purposes.
Now, imagine trying to svn co such a patch, and have it apply, on
both
At 11:03 PM 11/19/2004, Justin Erenkrantz wrote:
--On Friday, November 19, 2004 8:01 PM -0600 William A. Rowe, Jr. [EMAIL
PROTECTED] wrote:
I'll offer compelling argument. Allen offered patches, which
Roy vetoed, to fix object sizes on 32/64/64 ILP bit platforms,
and told Allen to go back
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 course, I am assuming that
We have
apr/apr/branches/
1.0.x/
- this is great
APR_0_9_BRANCH
- this should be 0.9.x?
APR/
unlabeled/
- these are duds - delete them?
apr/apr-util/branches/
1.0.x/
- again, dandy
APU_0_9_BRANCH
- this should be 0.9.x?
apr/apr-iconv/branches/
1.0.x/
At 08:23 AM 11/20/2004, Jim Jagielski wrote:
This kind of brings up an idea that's been sloshing around between
that handful of neurons in my noggin: Some sort of API seed
program within httpd/apr where we put a little more effort in
getting the latest API versions out there.
The other
At 12:37 PM 11/20/2004, William A. Rowe, Jr. wrote:
The other alternative is a 'fixed' subset of the httpd API that
we simply don't touch. At least so it's APR compat if not ABI
compat.
s/APR compat/API compat/
http://svn.apache.org/viewcvs.cgi/httpd/mod_aspdotnet/trunk/Apache.Web/Apache.Web.Version.h?rev=105923view=markup
is how I coded the version header for mod_aspdotnet, so that
the .rc file...
http://svn.apache.org/viewcvs.cgi/httpd/mod_aspdotnet/trunk/Apache.Web/Apache.Web.rc?rev=105923view=log
apr/apr/branches/
APR_0_9_BRANCH
- 0.9.x
apr/apr-util/branches/
APU_0_9_BRANCH
- 0.9.x
apr/apr-iconv/branches/
API_0_9_BRANCH
- 0.9.x
All changed... you need to...
cd into your local checkout directories, and switch them.
cd /path-to-local/apr-0.9/
svn switch
At 07:10 PM 11/20/2004, Jim Jagielski wrote:
[EMAIL PROTECTED] wrote:
Author: wrowe
Date: Sat Nov 20 14:46:04 2004
New Revision: 106038
Added:
apr/apr/branches/0.9.x/
- copied from r106037, apr/apr/branches/APR_0_9_BRANCH/
Removed:
apr/apr/branches/APR_0_9_BRANCH/
Log:
At 07:41 AM 11/21/2004, Max Bowsher wrote:
Author: jorton
Date: Sat Nov 20 05:17:18 2004
New Revision: 105961
Modified:
apr/apr-util/trunk/CHANGES
apr/apr-util/trunk/Makefile.in
apr/apr-util/trunk/configure.in
Log:
Link libaprutil against the libraries on which it depends (dropping
support
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 shouldn't intend
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 normal pace
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;
At 01:07 PM 11/24/2004, Friedrich Dominicus wrote:
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
At 08:24 AM 11/24/2004, Friedrich Dominicus wrote:
How about this code then?
/* #ifndef _WIN32_WCE
if (((*new)-td = (HANDLE)_beginthreadex(NULL,
attr attr-stacksize 0
At 12:29 PM 11/24/2004, Allan Edwards wrote:
If we can make good progress towards a stable 64 bit APR 2.0 then
moving httpd 2.1/2.2 to it could make sense. The question is
whether there is enough feature freeze pressure to say that
64 bit does not warrant the wait...
Allan - your last patches
At 01:05 PM 11/24/2004, Cliff Woolley wrote:
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
At 01:29 PM 11/24/2004, Cliff Woolley wrote:
On Wed, 24 Nov 2004, Justin Erenkrantz wrote:
I'm sick of all talk and no action. We tried this last year when we were
almost ready to branch APR 1.0 and all action on that front ceased
entirely for a YEAR. This time it's one or the other. I'll wait
Now that 1.0.x is branched, svn is up and running and most
of the headaches are diminishing with the help of a bit
of advil...
I see no reason for Stas not to commit his APR_ file macro
renames on 1.1.x - it's commit-then-review so be my guest.
Bill
At 03:26 PM 11/26/2004, you wrote:
Author: stas
Date: Fri Nov 26 13:26:37 2004
New Revision: 106663
URL: http://svn.apache.org/viewcvs?view=revrev=106663
Log:
rename the fopen defines (APR_READ, APR_WRITE, etc.) to have prefix
APR_FOPEN_ (keeping the old defines)
Stas, you forgot doxygen
At 10:50 AM 11/29/2004, Stas Bekman wrote:
Also should the deprecated macros stay in this file or can those be moved to
some dedicated file to reduce the noise?
They stay in place. During the next major+1 bump, the RM
trawls through the files looking for @deprecated, and simply
strips them
At 11:51 AM 11/29/2004, Stas Bekman wrote:
Randy Kobes wrote:
I've been testing out some perl scripts to emulate
apxs/apr-config/apu-config on Win32 (under Apache/2.0.x),
and was wondering if there was any interest in developing
them within the appropriate httpd/apr sources. At present
they can be
At 11:45 AM 11/29/2004, Stas Bekman wrote:
William A. Rowe, Jr. wrote:
At 10:50 AM 11/29/2004, Stas Bekman wrote:
Also should the deprecated macros stay in this file or can those be moved to
some dedicated file to reduce the noise?
They stay in place. During the next major+1 bump, the RM
Joe makes a good point, +1 for this change when we roll over into 2.0.
Bill
At 01:30 PM 12/1/2004, Joe Orton wrote:
On Wed, Dec 01, 2004 at 09:36:32AM -0500, Jeff Trawick wrote:
HP-UX apparently has no other function than getpass(), and it silently
truncates after 8 characters. There are
At 11:09 AM 12/3/2004, Jeff Trawick wrote:
On Wed, 1 Dec 2004 19:30:43 +, Joe Orton [EMAIL PROTECTED] wrote:
On Wed, Dec 01, 2004 at 09:36:32AM -0500, Jeff Trawick wrote:
HP-UX apparently has no other function than getpass(), and it silently
truncates after 8 characters. There are
At 07:53 AM 12/5/2004, Joe Orton wrote:
On Sun, Dec 05, 2004 at 12:53:58PM +, Thom May wrote:
You don't say which you propose to change, but either way it's an API
change not really worth bumping the major number for, I'd reckon.
There's an objection to making the md5 functions return void
At 06:32 AM 12/7/2004, Julian Foad wrote:
William A. Rowe, Jr. wrote:
This simply isn't a good idea until 2.0.
Does the project have a standard place to record proposed API changes for the
next major version so that they are not forgotten when that time comes? If
not, may I suggest putting
At 10:15 AM 12/7/2004, Stas Bekman wrote:
apr_brigade_cleanup looks wrong:
APU_DECLARE(apr_status_t) apr_brigade_cleanup(void *data)
{
apr_bucket_brigade *b = data;
apr_bucket *e;
shouldn't it be:
apr_bucket_brigade *b = (apr_bucket_brigade *)data;
why does it have (void *data)
At 10:51 AM 12/9/2004, Tangui Morlier wrote:
I could not acces to the mailing list archive. If this topic has already been
discused here, please tell me how i can read these messages.
I used apr in linux without any problem. Now I would like to use the windows
version. As i could not find the
At 03:42 PM 12/9/2004, Branko Čibej wrote:
Tangui Morlier wrote:
By the way, folks, why on earth do those files have svn:eol-style set to
native instead of CRLF?
* because they contain text
* because 'patch' should always 'just work'
* because other platform maintainers may add/delete sources
At 04:44 PM 12/9/2004, Branko Äibej wrote:
William A. Rowe, Jr. wrote:
At 03:42 PM 12/9/2004, Branko Ãibej wrote:
Tangui Morlier wrote:
By the way, folks, why on earth do those files have svn:eol-style set to
native instead of CRLF?
* because they contain text
What's that have to do
Ok, you have me confused :) There can be no binary breakage
between 1.0.0 and 1.99.999. Nothing (except for unreleased
changes in our svn repository) as we move forward.
Minor bumps introduce new features. Subversion bumps fix bugs.
That's the short story.
I'm increasing concerned that folks
At 04:31 PM 12/15/2004, Paul Querna wrote:
Brad Nicholes wrote:
The reason why it's *not* silly is because of our release schedules. Unless
the APR project wants to do something completely different with
versioning, revision releases (1.0.1 to 1.0.2) are usually on the order
of a few months.
801 - 900 of 3066 matches
Mail list logo
