On Thu, Jul 11, 2002 at 03:20:33PM -0700, Ryan Bloom wrote:
Bumping the MMN works for things like Apache, but not for flood,
subversion, or any of the countless other APR-based apps that have
sprung up lately.
I'll agree that changing the typename doesn't solve the problem of
On Friday, July 12, 2002, at 07:05 PM, William A. Rowe, Jr. wrote:
At 08:49 PM 7/12/2002, [EMAIL PROTECTED] wrote:
2) Renaming the function to get rid of apr_time_t vs time_t
confusion,
but keep it ambigious and make no contract with the user
about the
units
To make a certain functionality of Subversion more efficient (namely
svnadmin load), stdin should be allowed to be buffered.
Would anyone have any problems if I commit this?
The other question is how to get stdin buffered from the client. Do
we modify apr_file_open_stdin() to take a flag, or
On Fri, Jul 12, 2002 at 07:57:45PM -0700, Justin Erenkrantz wrote:
To make a certain functionality of Subversion more efficient (namely
svnadmin load), stdin should be allowed to be buffered.
Would anyone have any problems if I commit this?
The other question is how to get stdin buffered
This patch is my attempt to simplify the platform-specific
conditional logic in apr_atomic.h.
I need a few volunteers to test it on Win32, FreeBSD, Netware,
and OS/390 before I commit.
With this patch, the overriding of the default atomic ops is
mow more granular: you can add #defines for
A fine summary of the situation.
On Friday, July 12, 2002, at 12:42 PM, William A. Rowe, Jr. wrote:
I. We represent all time quantum in the same scale throughout APR. That
scale is in microseconds.
Which is goodness, because we don't ever have to go back to docs and ask,
Does that function
On Fri, Jul 12, 2002 at 08:43:05PM -0700, Brian Pane wrote:
@@ -161,6 +162,7 @@
#define apr_atomic_add(mem, val) atomic_add(mem,val)
APR_DECLARE(int) apr_atomic_dec(apr_atomic_t *mem);
+#define apr_override_atomic_dec 1
#define apr_atomic_inc(mem) atomic_inc(mem)
#define
On Fri, 2002-07-12 at 20:58, Justin Erenkrantz wrote:
On Fri, Jul 12, 2002 at 08:43:05PM -0700, Brian Pane wrote:
@@ -161,6 +162,7 @@
#define apr_atomic_add(mem, val) atomic_add(mem,val)
APR_DECLARE(int) apr_atomic_dec(apr_atomic_t *mem);
+#define apr_override_atomic_dec 1
There currently are four options listed in STATUS for changing
the time representation. There are vetoes for two of them. The
other are:
2) Renaming the function to get rid of apr_time_t vs time_t confusion,
but keep it ambigious and make no contract with the user about the
units
On Fri, Jul 12, 2002 at 10:39:10PM -0700, Brian Pane wrote:
If the new time type is an abstract type, the common operations on
it will be:
- Native C scalar + and - operations for time arithmetic
(for performance and simplicity reasons)
- Macros to extract seconds and
On Fri, Jul 12, 2002 at 10:44:33PM -0700, Justin Erenkrantz wrote:
As Roy pointed out, this is partial hiding. I'm now of the mind
that it should be a full ADT under an abstract type. Therefore,
the +/- operations should be handled by an API. (For performance
reasons, it can be a macro -
On Fri, Jul 12, 2002 at 10:50:36PM -0700, Brian Pane wrote:
Agreed. And that API includes:
type_name_tbd operator+(type_name_tbd a, type_name_tbd b);
type_name_tbd operator-(type_name_tbd a, type_name_tbd b);
Right.
If that bugs you (and it well might), then we need to go the
On Fri, Jul 12, 2002 at 10:55:03PM -0700, Aaron Bannert wrote:
On Fri, Jul 12, 2002 at 10:44:33PM -0700, Justin Erenkrantz wrote:
As Roy pointed out, this is partial hiding. I'm now of the mind
that it should be a full ADT under an abstract type. Therefore,
the +/- operations should be
At 12:55 AM 7/13/2002, Aaron Bannert wrote:
On Fri, Jul 12, 2002 at 10:44:33PM -0700, Justin Erenkrantz wrote:
As Roy pointed out, this is partial hiding. I'm now of the mind
that it should be a full ADT under an abstract type.
A full ADT cannot be allocated on the stack... you don't know the
On Sat, Jul 13, 2002 at 01:24:53AM -0500, William A. Rowe, Jr. wrote:
A full ADT cannot be allocated on the stack... you don't know the
size. You will need real functions apr_time_make() to actually
do pool allocations.
Otherwise you are kidding yourself that this is really opaque.
On Sat, 2002-07-13 at 00:08, [EMAIL PROTECTED] wrote:
brianp 2002/07/13 00:08:41
Modified:include apr_tables.h
tables apr_tables.c
Log:
Changed apr_table_elts() and apr_is_empty_table() from macros
to functions to make apr_table_t a fully abstract type
On Fri, 2002-07-12 at 23:12, Justin Erenkrantz wrote:
-1 for renaming any APR time functions: just rename the data type.
If you go to a contract for the time, I think you need to have
specific APR functions that go with that. My earlier example was
that I might want apr_dsec_t as well.
[EMAIL PROTECTED] writes:
brianp 2002/07/13 00:08:41
Modified:include apr_tables.h
tables apr_tables.c
Log:
Changed apr_table_elts() and apr_is_empty_table() from macros
to functions to make apr_table_t a fully abstract type
http_protocol.c: In function
Brian Pane wrote:
apr_dsec_t mytime = apr_time_now();
What's an apr_dsec_t?
I would assume a 'decimal' sec rather than binary sec
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
Justin Erenkrantz wrote:
Therefore, I think it has to be:
apr_dsec_t mytime = apr_time_dsec_now();
apr_busec_t mytime = apr_time_busec_now();
How about apr_time_now(...) with an enum parameter that defines
the return type.
--
From: Aaron Bannert [mailto:[EMAIL PROTECTED]
On Fri, Jul 12, 2002 at 10:44:33PM -0700, Justin Erenkrantz wrote:
As Roy pointed out, this is partial hiding. I'm now of the mind
that it should be a full ADT under an abstract type. Therefore,
the +/- operations should be handled by an
From: Jim Jagielski [mailto:[EMAIL PROTECTED]
Justin Erenkrantz wrote:
Therefore, I think it has to be:
apr_dsec_t mytime = apr_time_dsec_now();
apr_busec_t mytime = apr_time_busec_now();
How about apr_time_now(...) with an enum parameter that defines
the return type.
That
On Sat, Jul 13, 2002 at 09:16:17AM -0700, Ryan Bloom wrote:
I really hate where our time implementation is going. It used to be
VERY simple, and easy to modify and use. From looking at this
conversation, it sounds like we are about to go to a VERY complex
implementation that is hard to
From: Aaron Bannert [mailto:[EMAIL PROTECTED]
On Sat, Jul 13, 2002 at 09:16:17AM -0700, Ryan Bloom wrote:
I really hate where our time implementation is going. It used to be
VERY simple, and easy to modify and use. From looking at this
conversation, it sounds like we are about to go to
On Sat, Jul 13, 2002 at 09:35:58AM -0700, Ryan Bloom wrote:
We need two, one for standard time, and one for intervals, which are
rooted at an arbitrary point in time. However, even with just one
implementation, the ideas being thrown about now are too complex.
(Those are technically the same
At 11:35 AM 7/13/2002, Ryan Bloom wrote:
From: Aaron Bannert [mailto:[EMAIL PROTECTED]
On Sat, Jul 13, 2002 at 09:16:17AM -0700, Ryan Bloom wrote:
I really hate where our time implementation is going. It used to be
VERY simple, and easy to modify and use. From looking at this
On Sat, 2002-07-13 at 06:27, Jim Jagielski wrote:
Justin Erenkrantz wrote:
Therefore, I think it has to be:
apr_dsec_t mytime = apr_time_dsec_now();
apr_busec_t mytime = apr_time_busec_now();
How about apr_time_now(...) with an enum parameter that defines
the return type.
A big reason that they are too complex, is that rather than come up
with
a simple design, we are all afraid of the damned vetos that are being
thrown about. This whole conversation should just start over, with
no
vetos, and no emotions. Vetos should be a last resort, but we don't
use
them
On Sat, Jul 13, 2002 at 11:07:57AM -0700, Ryan Bloom wrote:
Screw that. I have lost votes before, and I can accept that. What is
pissing me off is that the obvious majority would rather keep
apr_time_t, but because of a stupid veto, we are being forced to change
the name.
Stupid veto?
At 01:07 PM 7/13/2002, Ryan Bloom wrote:
Screw that. I have lost votes before, and I can accept that. What is
pissing me off is that the obvious majority would rather keep
apr_time_t, but because of a stupid veto, we are being forced to change
the name.
That is true. +4, with 2 +0's voting with
30 matches
Mail list logo
