[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
als
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 appro
[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 wo
On Tue, 13 Aug 2002, Justin Erenkrantz 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 :)
>
> Which is exactly why we should table the time discussion until
> we have a versioning system *enforced*.
>
> Aaron has expli
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
The following patch and file allows for the detection and use of POSIX
large file implentations that exist in most modern OSes.
"Large files" refers to files that are greater than 2GB in size. Without
LF support, a program will typically crash or otherwise fail if an attempt
is made to open or wr
Justin Erenkrantz 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 :)
Which is exactly why we should table the time discussion until
we have a versioning system *enforced*.
I must object. The performance problems in the
On Tue, 13 Aug 2002, Justin Erenkrantz wrote:
> I'd avoid 2.53 at all costs since it introduces autom4te.cache which
> was just a really bad idea. -- justin
AFAIK all versions of httpd >= 2.0.36 have been rolled with 2.53 -- we
just delete with autom4te.cache with extreme prejudice. :)
--Cliff
On Tue, 13 Aug 2002, Justin Erenkrantz wrote:
| On Tue, Aug 13, 2002 at 04:51:38PM -0400, Dale Ghent wrote:
| >
| > what version are we standardized on? 2.5x?
|
| 2.13+ are supported.
|
| I'd avoid 2.53 at all costs since it introduces autom4te.cache which
| was just a really bad idea. -- justin
On Tue, Aug 13, 2002 at 04:51:38PM -0400, Dale Ghent wrote:
>
> what version are we standardized on? 2.5x?
2.13+ are supported.
I'd avoid 2.53 at all costs since it introduces autom4te.cache which
was just a really bad idea. -- justin
On Tue, Aug 13, 2002 at 03:10:14PM -0400, Jim Jagielski wrote:
> Uh oh. Looks like we'll be hashing this out again :)
Which is exactly why we should table the time discussion until
we have a versioning system *enforced*.
Aaron has explicitly veto'd any changes to apr_time_t that cause
broken bina
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 numb
what version are we standardized on? 2.5x?
/dale
Is there any interest in adding a generalized version of worker's
fdqueue to apr-util (this is a FIFO not a stack btw) ???
this is different to the resource list posted by aaron, as it just
manages a work queue.
the api:
apr_status_t apr_queue_init(apr_queue_t **queue,
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 AP
[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-dev&m=102678180413988
I'm interested in hearing people's comments on that proposal.
Doesn't that completely
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?
--
==
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
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
> AFAIK, we do have a run-time versioing scheme already.
I don't think so, but I may have missed it...
-aaron
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 th
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-
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
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
> -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
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
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
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 t
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-dev&m=102678180413988
>>
>> I'm interested in hearing people's comments
> > >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.
> >
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 thi
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 perform
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
> >
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 ti
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 doing
> > 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
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 v
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
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 relea
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 will
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 t
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
>
Jeff Trawick <[EMAIL PROTECTED]> writes:
> It isn't clear to me that you can disable Berkeley db detection, gdbm
> detection, etc., but before hacking on this I'd like to see if anybody
> else knows how to solve this.
silly me, it appears to be as simple as adding "--without-berkeley-db
--without
It isn't clear to me that you can disable Berkeley db detection, gdbm
detection, etc., but before hacking on this I'd like to see if anybody
else knows how to solve this.
Disabling optional db support can be useful if you want to avoid
prereqs on the target machine.
--
Jeff Trawick | [EMAIL PROT
44 matches
Mail list logo
