Brian Pane wrote:
William A. Rowe, Jr. wrote:
Ultimately, we must be able to roundtrip from a stat() into a utime()
style call without loosing the old value... at least down to the usec.
Many systems will track file times down to the msec, at a minimum.
Doesn't Posix require these fields to be in
Greg Stein wrote:
And that 0.9.0 is going to be whatever is in APR today. If somebody wants
their darned pet feature in 1.0, then they can get it code before that date.
But I want something *versioned* *today*. SVN users are dyin' cuz we can't
point people at a specific APR release. The best we
At 02:02 PM 8/13/2002, Cliff Woolley wrote:
On Tue, 13 Aug 2002 [EMAIL PROTECTED] wrote:
I continue to state that APR's time format should stay as it is. If you
want seconds, use time_t.
Agreed.
And agreed here too.
Doesn't that completely ignore Cliff's message early in this thread that
At 02:06 PM 8/13/2002, Ryan Bloom wrote:
On Tue, 13 Aug 2002, Jim Jagielski wrote:
Ryan Bloom wrote:
Why are we waiting for Bill to come back? I thought the whole point of
OSS was that no one person was so important that we couldn't continue
without them?
I'm not saying that Bill is so
At 02:02 PM 8/13/2002, Jim Jagielski wrote:
At 2:54 PM -0400 8/13/02, [EMAIL PROTECTED] wrote:
I continue to state that APR's time format should stay as it is. If you
want seconds, use time_t. The only change that I can see as appropriate,
is to make the interval_time_t a 32-bit value, which
At 06:15 PM 8/13/2002, [EMAIL PROTECTED] wrote:
The time formatting features are for apr_time_t, and should require
microseconds. If you want to use time formatting functions for seconds,
then you have to use the ANSI standard functions. Essentially, using a
time_t in an apr_time_t function just
At 08:47 AM 8/14/2002, Bill Stoddard wrote:
And that 0.9.0 is going to be whatever is in APR today. If somebody wants
their darned pet feature in 1.0, then they can get it code before
that date.
But I want something *versioned* *today*. SVN users are dyin' cuz we can't
point people at a
William A. Rowe, Jr. wrote:
At 06:15 PM 8/13/2002, [EMAIL PROTECTED] wrote:
The time formatting features are for apr_time_t, and should require
microseconds. If you want to use time formatting functions for seconds,
then you have to use the ANSI standard functions. Essentially, using a
time_t in
On Tue, 13 Aug 2002, Brian Pane wrote:
[EMAIL PROTECTED] wrote:
I continue to state that APR's time format should stay as it is. If you
want seconds, use time_t. The only change that I can see as appropriate,
is to make the interval_time_t a 32-bit value, which would mean that any
[EMAIL PROTECTED] wrote:
On Tue, 13 Aug 2002, Brian Pane wrote:
[EMAIL PROTECTED] wrote:
I continue to state that APR's time format should stay as it is. If you
want seconds, use time_t. The only change that I can see as appropriate,
is to make the interval_time_t a 32-bit value, which
On Tue, 13 Aug 2002, Brian Pane wrote:
[EMAIL PROTECTED] wrote:
On Tue, 13 Aug 2002, Brian Pane wrote:
[EMAIL PROTECTED] wrote:
I continue to state that APR's time format should stay as it is. If you
want seconds, use time_t. The only change that I can see as appropriate,
is to make
[EMAIL PROTECTED] wrote:
To use time_t in a portable app, though, I expect that we'll still
need to rely on APR to provide a portability wrapper. The code for
even simple things like getting the current time is different between
Unix and Win32. (I wouldn't mind leaving apr_time_t as-is if we
[EMAIL PROTECTED] wrote:
yOn Tue, 13 Aug 2002, Brian Pane wrote:
[EMAIL PROTECTED] wrote:
To use time_t in a portable app, though, I expect that we'll still
need to rely on APR to provide a portability wrapper. The code for
even simple things like getting the current time is different
On Tue, Aug 13, 2002 at 02:12:36PM -0700, Justin Erenkrantz wrote:
On Tue, Aug 13, 2002 at 03:25:49PM -0400, Ryan Bloom wrote:
Dude, settled how? We have run-time versioning, Greg committed it a
long time ago, and it is being used by APR and Subversion.
Nope. There isn't a way to
On Tue, Aug 13, 2002 at 11:05:29AM -0700, Aaron Bannert wrote:
On Tue, Aug 13, 2002 at 05:42:06PM -, [EMAIL PROTECTED] wrote:
gstein 2002/08/13 10:42:06
Modified:.versioning.html
Log:
Functions actually *cannot* be replace via macros, so note this and
the
And that 0.9.0 is going to be whatever is in APR today. If somebody wants
their darned pet feature in 1.0, then they can get it code before
that date.
But I want something *versioned* *today*. SVN users are dyin' cuz we can't
point people at a specific APR release. The best we can do is use
Bill Stoddard wrote:
And that 0.9.0 is going to be whatever is in APR today. If somebody wants
their darned pet feature in 1.0, then they can get it code before
that date.
But I want something *versioned* *today*. SVN users are dyin' cuz we can't
point people at a specific APR
And that 0.9.0 is going to be whatever is in APR today. If somebody wants
their darned pet feature in 1.0, then they can get it code before
that date.
But I want something *versioned* *today*. SVN users are dyin' cuz we can't
point people at a specific APR release. The best we can
On Tue, Aug 13, 2002 at 05:42:06PM -, [EMAIL PROTECTED] wrote:
gstein 2002/08/13 10:42:06
Modified:.versioning.html
Log:
Functions actually *cannot* be replace via macros, so note this and
the reasons why. Clarify that pre-1.0 releases are not subject to
Aaron Bannert wrote:
I move that we implement a runtime version checking scheme in APR and
then release 1.0 as soon as possible, at the same time adopting the
above versioning definitions.
Assuming that we all sign up to the statement that APR is 1.0 ready, or
soon will be, I'm +1 on this.
Jim Jagielski wrote:
Aaron Bannert wrote:
I move that we implement a runtime version checking scheme in APR and
then release 1.0 as soon as possible, at the same time adopting the
above versioning definitions.
Assuming that we all sign up to the statement that APR is 1.0 ready, or
soon
On Tue, Aug 13, 2002 at 11:15:48AM -0700, Brian Pane wrote:
I think APR is close to being ready for 1.0. We still need to
fix the apr_time_t performance problems (the old 64-bit division
issue), though.
Can we plan on doing this for 1.1 once we have the versioning in
place and a solid
On Tue, 13 Aug 2002, Aaron Bannert wrote:
On Tue, Aug 13, 2002 at 11:15:48AM -0700, Brian Pane wrote:
I think APR is close to being ready for 1.0. We still need to
fix the apr_time_t performance problems (the old 64-bit division
issue), though.
Can we plan on doing this for 1.1 once we
Aaron Bannert wrote:
On Tue, Aug 13, 2002 at 11:15:48AM -0700, Brian Pane wrote:
I think APR is close to being ready for 1.0. We still need to
fix the apr_time_t performance problems (the old 64-bit division
issue), though.
Can we plan on doing this for 1.1 once we have the versioning
Can we plan on doing this for 1.1 once we have the versioning in
place and a solid release?
As long as we remain transparent. If not, then we should do it
right in 1.0 (IMO).
My main concern is that if we go down that path now then it may be a
long time before we become stable again, and
Ryan Bloom wrote:
On Tue, 13 Aug 2002, Aaron Bannert wrote:
On Tue, Aug 13, 2002 at 11:15:48AM -0700, Brian Pane wrote:
I think APR is close to being ready for 1.0. We still need to
fix the apr_time_t performance problems (the old 64-bit division
issue), though.
Can we plan on
Aaron Bannert wrote:
My main concern is that if we go down that path now then it may be a
long time before we become stable again, and it will take time for our
dependent projects to sync up too. It seems that we are at a point that
we could call stable now, and if we want to redo the time
On Tue, 13 Aug 2002, Jim Jagielski wrote:
Aaron Bannert wrote:
My main concern is that if we go down that path now then it may be a
long time before we become stable again, and it will take time for our
dependent projects to sync up too. It seems that we are at a point that
we could
On Tue, 13 Aug 2002, Brian Pane wrote:
Ryan Bloom wrote:
On Tue, 13 Aug 2002, Aaron Bannert wrote:
On Tue, Aug 13, 2002 at 11:15:48AM -0700, Brian Pane wrote:
I think APR is close to being ready for 1.0. We still need to
fix the apr_time_t performance problems (the old
Ryan Bloom wrote:
Why are we waiting for Bill to come back? I thought the whole point of
OSS was that no one person was so important that we couldn't continue
without them?
I'm not saying that Bill is so important just that I know that he's
done quite a bit of investigating into this
I have a better question. Has anybody come up with a design
that we can
agree on for this? If there is no design, then we really
can't solve the
problem quickly. The last I saw about this issue, nobody
agreed on how to
fix it, or even that there was a real problem.
There were
At 2:54 PM -0400 8/13/02, [EMAIL PROTECTED] wrote:
Toward the end of that last round of discussions, I thus proposed
that APR get out of the business of managing microseconds:
http://marc.theaimsgroup.com/?l=apr-devm=102678180413988
I'm interested in hearing people's comments on that
On Tue, 13 Aug 2002, Bill Stoddard wrote:
I have a better question. Has anybody come up with a design
that we can
agree on for this? If there is no design, then we really
can't solve the
problem quickly. The last I saw about this issue, nobody
agreed on how to
fix it, or
On Tue, 13 Aug 2002, Jim Jagielski wrote:
Ryan Bloom wrote:
Why are we waiting for Bill to come back? I thought the whole point of
OSS was that no one person was so important that we couldn't continue
without them?
I'm not saying that Bill is so important just that I know that
On Tue, 13 Aug 2002 [EMAIL PROTECTED] wrote:
I continue to state that APR's time format should stay as it is. If you
want seconds, use time_t.
Agreed.
Doesn't that completely ignore Cliff's message early in this thread that
specifically stated that he needed microsecond resolution?
As
-Original Message-
From: Ryan Bloom [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 13, 2002 3:05 PM
To: Bill Stoddard
Cc: APR Development List
Subject: RE: cvs commit: apr-site versioning.html
On Tue, 13 Aug 2002, Bill Stoddard wrote:
I have a better question. Has
Ryan Bloom wrote:
Ok. I don't honestly think we will get a release out the door this week
anyway, but I also don't believe that Will has done a lot with the
licensing stuff. Most of that was Greg Stein, and AFAIK, we do have a
run-time versioing scheme already.
My point was that if the
Uh oh. Looks like we'll be hashing this out again :)
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
A society that will trade a little liberty for a little order
will lose
On Tue, 13 Aug 2002, Jim Jagielski wrote:
Ryan Bloom wrote:
Ok. I don't honestly think we will get a release out the door this week
anyway, but I also don't believe that Will has done a lot with the
licensing stuff. Most of that was Greg Stein, and AFAIK, we do have a
run-time
On Tue, Aug 13, 2002 at 03:10:14PM -0400, Jim Jagielski wrote:
Uh oh. Looks like we'll be hashing this out again :)
Uh oh is right.
Can we pleeease table this until we have the versioning code settled?
(I'd like to make a release once we get the versioning into code, but
you already knew
AFAIK, we do have a run-time versioing scheme already.
I don't think so, but I may have missed it...
-aaron
On Tue, 13 Aug 2002, Aaron Bannert wrote:
On Tue, Aug 13, 2002 at 03:10:14PM -0400, Jim Jagielski wrote:
Uh oh. Looks like we'll be hashing this out again :)
Uh oh is right.
Can we pleeease table this until we have the versioning code settled?
(I'd like to make a release once we get
Take a look at apr/misc/unix/version.c.
Ryan
On Tue, 13 Aug 2002, Ryan Bloom wrote:
On Tue, 13 Aug 2002, Aaron Bannert wrote:
On Tue, Aug 13, 2002 at 03:10:14PM -0400, Jim Jagielski wrote:
Uh oh. Looks like we'll be hashing this out again :)
Uh oh is right.
Can we
Aaron Bannert wrote:
Can we pleeease table this until we have the versioning code settled?
(I'd like to make a release once we get the versioning into code, but
you already knew that. :)
I thought we did. Didn't Greg submit something?
--
[EMAIL PROTECTED] wrote:
Toward the end of that last round of discussions, I thus proposed
that APR get out of the business of managing microseconds:
http://marc.theaimsgroup.com/?l=apr-devm=102678180413988
I'm interested in hearing people's comments on that proposal.
Doesn't that completely
Ryan Bloom wrote:
That is in Apache, which has nothing to do with APR. The proposal
specifically states that APR will stop dealing with microseconds, which
makes it useless for an app outside of httpd that wants microsecond
resolution.
On the contrary, removing the microsecond manipulation from
On Tue, Aug 13, 2002 at 03:25:49PM -0400, Ryan Bloom wrote:
Dude, settled how? We have run-time versioning, Greg committed it a
long time ago, and it is being used by APR and Subversion.
Nope. There isn't a way to enforce it. apr_initialize needs to
take in the expected MAJOR/MINOR
47 matches
Mail list logo
