APR-SERF STATUS:-*-text-*-
Last modified at [$Date: 2002/07/01 15:51:57 $]
Release:
RELEASE SHOWSTOPPERS:
We need code. This project's goal is to create an http
client library.
* web pages (go to apr-site)
* decide on
Looks like PR9932 explains why we have the current behavior... Not sure
if the change from (sp = bep) - (sp bep) makes sense in this case.
We most likely need to flush when we are *at* bep, but I'm not really
sure.
--
===
Well, you beat me by about five minutes. I just finished compiling
almost the exact same code.
Thanks for doing to work, your implementation is cleaner than mine was.
:-)
Ryan
--
Ryan Bloom [EMAIL PROTECTED]
645 Howard St.
I really don't see why we moved the file
Just to be clear, I moved the file because poll'ing is no longer tied to
sockets. The previous implementation had a serious limitation, in that
it couldn't poll pipes or files on platforms that supported it. Because
of that limitation, I had put the
At 01:25 AM 7/11/2002, Ryan Bloom wrote:
Well, you beat me by about five minutes. I just finished compiling
almost the exact same code.
Thanks for doing to work, your implementation is cleaner than mine was.
Speaking of which, are these the results you were looking for?
APR Poll Test
Thanks to Will doing the work for Windows, the apr_poll() move is done.
Most of the current platforms are actually using a select() based
implementation, so instead of duplicating logic again, every platform
except for OS/2 is using the Unix poll.c file.
The only implementation that is likely to
Yep, and I just sent mail letting you know that. :-D
Now, you have to run testpipe to make sure that the pipe read is still
working.
Ryan
--
Ryan Bloom [EMAIL PROTECTED]
645 Howard St. [EMAIL PROTECTED]
San Francisco,
Jim Jagielski wrote:
Nuutti Kotivuori wrote:
Jim Jagielski wrote:
So if truncated, what is returned *must* be = the length passed
in.
apr_snprintf is not snprintf.
Agreed, but we want some of the same characteristics. Returning
length upon truncation is one of them.
* In no event
On 11 Jul 2002 05:40:23 -, [EMAIL PROTECTED] wrote:
rbb 2002/07/10 22:40:23
Modified:network_io/os2 Makefile.in
Added: poll/os2 Makefile.in poll.c
Removed: network_io/os2 poll.c
Log:
An attempt at the OS/2 implementation. I have no OS/2 box, so this
At 10:17 AM +0300 7/11/02, Nuutti Kotivuori wrote:
But back to the subject at hand.
I'm a bit uncertain _how_ am I supposed to be using apr_snprintf so
code doesn't break the next time it's behaviour changes? I'm a bit on
a foul mood here, sorry, but this was supposed to be just a minor
checkup
From: Brian Havard [mailto:[EMAIL PROTECTED]
On 11 Jul 2002 05:40:23 -, [EMAIL PROTECTED] wrote:
rbb 2002/07/10 22:40:23
Modified:network_io/os2 Makefile.in
Added: poll/os2 Makefile.in poll.c
Removed: network_io/os2 poll.c
Log:
An attempt at the
I ran a quick profile with this patch and it eliminated a couple of
divisions (calls to __divi64 reduced from 4 to 2 in my test setup. your
mileage may vary) which was good for 493 instructions. Still have 3 __divu64
and 2 __divi64 calls. The three __divu64 calls are in the gettimeofday() CRT
From: Bill Stoddard [mailto:[EMAIL PROTECTED]
I ran a quick profile with this patch and it eliminated a couple of
divisions (calls to __divi64 reduced from 4 to 2 in my test setup.
your
mileage may vary) which was good for 493 instructions. Still have 3
__divu64
and 2 __divi64 calls. The
At 01:33 AM 07/11/2002, William A. Rowe, Jr. wrote:
Ok, attached is the code redone as binary math. I'm tired, could be
any number of major blunders in it, but on first pass, it looked right.
-/** number of microseconds per second */
-#define APR_USEC_PER_SEC APR_TIME_C(100)
+/** number of
Greg Marr wrote:
At 01:33 AM 07/11/2002, William A. Rowe, Jr. wrote:
Ok, attached is the code redone as binary math. I'm tired, could be
any number of major blunders in it, but on first pass, it looked right.
-/** number of microseconds per second */
-#define APR_USEC_PER_SEC
[EMAIL PROTECTED] writes:
rbb 2002/07/10 22:19:45
Modified:.CHANGES configure.in
file_io/unix readwrite.c
include apr_network_io.h
include/arch/unix networkio.h
network_io/unix Makefile.in sendrecv.c
At 10:27 AM 07/11/2002, Jim Jagielski wrote:
Greg Marr wrote:
I keep thinking that APR_USEC_PER_SEC should be (1 20), or now
(1 APR_USEC_BITS) instead of the magical constant. I have no
way
of verifying with a quick glance that 1048576 is really 2^20.
It is :)
Well, yes, I did check it,
On 11 Jul 2002 [EMAIL PROTECTED] wrote:
trawick 2002/07/11 07:39:04
Modified:include apr_poll.h
poll/unix poll.c
support/unix waitio.c
Log:
get the new poll code to build on AIX, which for 32-bit builds has some
extremely unfortunate macros
Jim Jagielski wrote:
At 10:17 AM +0300 7/11/02, Nuutti Kotivuori wrote:
But back to the subject at hand.
I'm a bit uncertain _how_ am I supposed to be using apr_snprintf so
code doesn't break the next time it's behaviour changes? I'm a bit
on a foul mood here, sorry, but this was supposed to
On Thu, 2002-07-11 at 06:58, Bill Stoddard wrote:
I ran a quick profile with this patch and it eliminated a couple of
divisions (calls to __divi64 reduced from 4 to 2 in my test setup. your
mileage may vary) which was good for 493 instructions. Still have 3 __divu64
and 2 __divi64 calls. The
On 11 Jul 2002 15:32:18 -, [EMAIL PROTECTED] wrote:
rbb 2002/07/11 08:32:18
Modified:.apr.dsp libapr.dsp
poll/os2 Makefile.in
poll/unix Makefile.in poll.c
Added: poll/os2 pollacc.c
poll/unix pollacc.c
Log:
Split
At 10:41 AM 7/11/2002, Brian Pane wrote:
On Thu, 2002-07-11 at 06:58, Bill Stoddard wrote:
I ran a quick profile with this patch and it eliminated a couple of
divisions (calls to __divi64 reduced from 4 to 2 in my test setup. your
mileage may vary) which was good for 493 instructions. Still
On Thu, 11 Jul 2002, Greg Marr wrote:
I keep thinking that APR_USEC_PER_SEC should be (1 20), or now
(1 APR_USEC_BITS) instead of the magical constant. I have no way
of verifying with a quick glance that 1048576 is really 2^20.
You don't know your powers of 2? Memorize, Greg, Memorize.
At 11:31 AM 7/11/2002, Brian Pane wrote:
I don't see a way to eliminate the / 1000 to convert usec to
msec. But we may be able to do all the math in 32-bit mode, by
limiting the maximum timeout to the number of milliseconds that
will fit in 32 bits, which works out to a max timeout of about
50
At 11:37 AM 7/11/2002, you wrote:
brianp 2002/07/11 09:37:50
Modified:.STATUS
Log:
Added vote on apr_time_t naming
2) Renaming the function to get rid of apr_time_t vs time_t
confusion,
which wrowe suggests apr_butime_t [binary microtime].
William A. Rowe, Jr. wrote:
At 11:31 AM 7/11/2002, Brian Pane wrote:
I don't see a way to eliminate the / 1000 to convert usec to
msec. But we may be able to do all the math in 32-bit mode, by
limiting the maximum timeout to the number of milliseconds that
will fit in 32 bits, which works out to
Just to clarify the technical reason for vetoing the use of apr_time_t
with a new implementation. The reason I veto this is because I don't
want us to maintain binary compatibility while we're not maintaining
semantic compatibility. There are programs out there that use APR's
apr_time_t and will
At 02:49 PM 07/11/2002, William A. Rowe, Jr. wrote:
The code follows, patch attached is hard to follow. [Like my code
isn't :o]
/* Number of binary microseconds per second is (2^20)
* to keep the math fast and simple [binary arithmetic.]
*/
#define APR_BUSEC_BITS 20
#define APR_BUSEC_PER_SEC
At 02:13 PM 7/11/2002, Brian Pane wrote:
William A. Rowe, Jr. wrote:
apr_int32_t apr_time_sec_get(time) deprecates apr_time_sec(time)
apr_int32_t apr_time_msec_get(time) deprecates apr_time_msec(time)
apr_int32_t apr_time_usec_get(time) deprecates apr_time_usec(time)
apr_int32_t
At 02:20 PM 7/11/2002, Aaron Bannert wrote:
Just to clarify the technical reason for vetoing the use of apr_time_t
with a new implementation. The reason I veto this is because I don't
want us to maintain binary compatibility while we're not maintaining
semantic compatibility. There are programs
Are the poll changes done (cvs update of 20.20 UTC):
/usr/bin/ld: Undefined symbols:
_apr_poll_revents_get
_apr_poll_setup
_apr_poll_socket_add
_apr_poll_socket_clear
_apr_poll_socket_mask
_apr_poll_socket_remove
Did you re-run ./configure?
Ryan
--
Ryan Bloom [EMAIL PROTECTED]
645 Howard St. [EMAIL PROTECTED]
San Francisco, CA
-Original Message-
From: Dirk-Willem van Gulik [mailto:[EMAIL PROTECTED]
Sent: Thursday, July
I do
make distclean cvs update ./buildconf ./configure make
is that enough ?
Dw
--
Dirk-Willem van Gulik
On Thu, 11 Jul 2002, Ryan Bloom wrote:
Did you re-run ./configure?
Ryan
--
Ryan Bloom [EMAIL PROTECTED]
On Thu, Jul 11, 2002 at 02:35:04PM -0500, William A. Rowe, Jr. wrote:
In this case, semantic compatibility has NO IMPACT on binary
compatibility. The code will remain binary compatible, even though
this change breaks the behavior.
APR changes... we are pre-1.0 and our developer/consumers
Yes, that is enough. The changes are done, and since Mac OS/X is using
the standard Unix version, you shouldn't be having any problems. Make
sure that your Makefile in poll/unix references pollacc.lo, because it
doesn't look like it does.
Ryan
I do
make distclean cvs update
On Thu, Jul 11, 2002 at 09:55:39PM +0200, [EMAIL PROTECTED] wrote:
make distclean cvs update ./buildconf ./configure make
check your exports.c and export_vars.h files for the old definitions.
-aaron
I'm assuming this was meant for the whole list. :)
From: William A. Rowe, Jr. [EMAIL PROTECTED]
Subject: Re: [PATCH 3] example binary BUSEC for discussion
At 02:18 PM 7/11/2002, you wrote:
At 02:49 PM 07/11/2002, William A. Rowe, Jr. wrote:
The code follows, patch attached is hard to follow.
Me and Sander Striker made a deal. He and I decided to fix
apr_psprintf the same way - including the removal of the older fix
in apr_vformatter. So, Sander is going to fix and commit the
apr_psprintf and apr_vformatter things - and I am going to supply the
testcases to make sure apr_vformatter and
Jim Jagielski wrote:
After that apr_snprintf returns len-1 if the data just fit and len
if it got truncated. Is this what is wanted?
It would appear so... Certainly not being able to tell truncation
from it just fit is non-ideal.
Well yes. But now that we have really decided on the
William A. Rowe, Jr. wrote:
At 11:37 AM 7/11/2002, you wrote:
brianp 2002/07/11 09:37:50
Modified:.STATUS
Log:
Added vote on apr_time_t naming
2) Renaming the function to get rid of apr_time_t vs time_t
confusion,
which wrowe suggests apr_butime_t
Hmm - on MacOSX 10.1.5 - one for the autoconf experts..
cvs co apr; cd apr
./configure
..
checking for mmap that can map /dev/zero... no
decision on anonymous shared memory allocation method... 4.4BSD-style
mmap() via MAP_ANON
decision
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
So questions about the above; is it worrysome that we have --prefix in
there twice. And secondly that some still are ${prefix} i.e. not
substituted ? And finally - anything obviously wrong ?
Dirk, I build APR/HTTPD on a daily basis with 10.1.5 and
Dirk, I build APR/HTTPD on a daily basis with 10.1.5 and never saw the
problem you mentioned. I bet you're using the (screwed up) version of
AutoConf/AutoMake coming with the developer tools... I had to patch that one
as well...
Neither did I - until the day before yesterday and today ;-(
Guys, everyone here admits we are lousy at inventing names...
all suggestions for better names of these macros are welcome!
At 01:49 PM 7/11/2002, William A. Rowe, Jr. wrote:
Actually, here is my current math, with optimized forms for specific
situations we encounter often (aprox. limits are given
On 11 Jul 2002 [EMAIL PROTECTED] wrote:
+ -1: aaron [veto for reusing the apr_time_t identifier for a new
use.
+I'm ok with apr_timeval_t.]
If we're avoiding apr_time_t because of confusion with the POSIX time_t,
it makes no sense whatsoever to use
On Thu, Jul 11, 2002 at 01:37:14PM -0700, Brian Pane wrote:
Let's take a typical scenario:
- Acme software releases mod_acme 2.0 to work with Apache 2.0
- They distribute a binary version of this module to work specifically
with 2.0.39 (the only version out that isn't susceptible to the
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
mismatched binary compatibility, but it does make it obvious to the
app
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
mismatched binary compatibility, but it does make it obvious to
48 matches
Mail list logo
