> Oh, apxs doesn't know about this file. Yuck. I think that apache-1.3
As I've mentioned maybe a dozen times over the past six months, apxs does
not work in 2.0. It needs to be taught how to use config_vars.mk or,
at the very least, all of its current symbols need to be replaced with
those used
"Roy T. Fielding" <[EMAIL PROTECTED]> writes:
> > > All variables are an approximation -- cosmic rays can change the value as
> > > well, with only a slightly smaller probability than mid-increment time
> > > slices in a non-test system.
> >
> > hmmm... I've seen many fixes needed for several ins
"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
> > maybe the description of APR_INCOMPLETE should be made more vague
> > (slightly less useful to somebody trying to see what it means) to
> > cover different uses?
> >
> > but programmers are one thing, and they can grep the source code if
> >
Roy T. Fielding at [EMAIL PROTECTED] wrote:
>> Oh, apxs doesn't know about this file. Yuck. I think that apache-1.3
>
> As I've mentioned maybe a dozen times over the past six months, apxs does
> not work in 2.0. It needs to be taught how to use config_vars.mk or,
> at the very least, all of i
On Mon, Aug 06, 2001 at 03:49:53PM -, [EMAIL PROTECTED] wrote:
> bnicholes01/08/06 08:49:53
>
> apr/locks/NetWare - New directory
Shouldn't it be netware? -- justin
Hi
During my testing the subversion (http://subversion.tigris.org) on the
Win32 platform, I ran into some problems with the apr_dir_open/apr_dir_read
functions as implemented on Win32.
The following is tested on a WinNT 4.0 sp6, using MSVC6 sp3.
As for which version of APR I'm using, I can't rea
apr/locks/NetWare has been renamed to apr/locks/netware
apr/threadproc/NetWare has been renamed to apr/threadproc/netware
Sorry, these got by me during the check in
Brad
>>> Justin Erenkrantz <[EMAIL PROTECTED]> Monday, August 06, 2001 9:52:27 AM >>>
On Mon, Aug 06, 2001 at 03:49:53PM -, [EM
I assume that this is just a typo. However, I have no way to test it.
But it seems it wasn't tested as well as you might hope before it was
committed.
Greg
---
Index: srclib/apr/include//apr_portable.h
Greg Ames <[EMAIL PROTECTED]> writes:
> I assume that this is just a typo. However, I have no way to test it.
> But it seems it wasn't tested as well as you might hope before it was
> committed.
I'd assume that too. Let me see what happens if the typo is fixed.
It may be that a header file wou
On 6 Aug 2001 [EMAIL PROTECTED] wrote:
> +#ifdef NETWARE
> +uint64_t sec;
> +uint64_t usec;
> +
> +NXGetTime(NX_SINCE_1970, NX_SECONDS, &sec);
> +NXGetTime(NX_SINCE_1970, NX_USECONDS, &usec);
> +*uuid_time = (sec * 1000) + (usec * 10) +
> +0x01B21DD2
There shouldn't be a reason to call connect again in the chunk
below since apr_wait_io_or_timeout should return success if we can
use the socket or error if we've timeout.
barbee.
Index: sockets.c
===
RCS file: /home/cvspublic/apr/ne
[EMAIL PROTECTED] writes:
> There shouldn't be a reason to call connect again in the chunk
> below since apr_wait_io_or_timeout should return success if we can
> use the socket or error if we've timeout.
The purpose of the connect call is to find out whether or we have a
connection. It is much b
The problem is that the second connect() call is failing with an
EALREADYCONNECTED.
The correct way to detect an error from connect, according to Single Unix, is
to do a poll
or select. If select/poll return with an error or they timeout, the connect
failed. If they return
successfully, then
Ryan Bloom <[EMAIL PROTECTED]> writes:
> The problem is that the second connect() call is failing with an
> EALREADYCONNECTED.
> The correct way to detect an error from connect, according to Single Unix, is
> to do a poll
> or select. If select/poll return with an error or they timeout, the con
Sorry for the confusion. I actually did mean to check it in with the
EnterDebugger() call there. I still have not had a chance to fully verify this
routine mainly because I haven't ported the test for it yet. So as a note to
myself, (which will cause the NetWare debugger to display so tha
I watched it fail on a FreeBSD machine.
For an example of code that uses a non-blocking accept:
http://www.cs.odu.edu/~cs779/stevens2nd/lib/connect_nonb.c
Ryan
On Monday 06 August 2001 14:48, Jeff Trawick wrote:
> Ryan Bloom <[EMAIL PROTECTED]> writes:
> > The problem is that the second conn
apr_connect() is returning EISCONN instead of APR_SUCCESS
on a FreeBSD 4.2 machine.
barbee.
On 06 Aug 2001 17:48:21 -0400 Jeff Trawick <[EMAIL PROTECTED]>
allegedly said:
> Ryan Bloom <[EMAIL PROTECTED]> writes:
>
> > The problem is that the second connect() call is failing with
an EALREADYCONNE
On Mon, 6 Aug 2001, Brad Nicholes wrote:
>Sorry for the confusion. I actually did mean to check it in with
> the EnterDebugger() call there. I still have not had a chance to
> fully verify this routine mainly because I haven't ported the test for
> it yet. So as a note to myself, (which wil
18 matches
Mail list logo