On Mon, Mar 15, 2004 at 10:11:09AM -0800, [EMAIL PROTECTED] wrote:
> 1) This patch isn't complete. At the very least we need a patch to the
> header
> that includes doxygen comments that document this new API. Preferably, a new
> patch would also include a patch to testpoll to test this feature
The attached patch ensure that APR_FROM_OS_ERROR(e) return
a consistent value for NetWare.
The current macro prevents AB to run on NetWare because
we are failing a test in apr_socket_connect():
sockets.c (line 356)
if (connect(sock->socketdes, (const str
Quoting Aaron Bannert <[EMAIL PROTECTED]>:
>
> On Mar 15, 2004, at 11:30 AM, [EMAIL PROTECTED] wrote:
> > Yeah, but rather than add a showstopper, I am just going to fix this
> > today. It
> > is on my list of things to fix ASAP.
>
> Part of me wishes we didn't have the lock mechanism in the
>
Thom May <[EMAIL PROTECTED]> writes:
> > As for timing, I would suggest making APR 1.0 official first, then
> > switching over to Subversion shortly after. But, let's please get APR 1.0
> > out the door first. It's overdue enough. =) -- justin
+1 on moving to Subversion given a consensus amo
On Mar 15, 2004, at 11:30 AM, [EMAIL PROTECTED] wrote:
Yeah, but rather than add a showstopper, I am just going to fix this
today. It
is on my list of things to fix ASAP.
Part of me wishes we didn't have the lock mechanism in the
main apr_*_mutex_create() functions, so that they could just be
ful
Quoting "William A. Rowe, Jr." <[EMAIL PROTECTED]>:
> At 12:56 PM 3/15/2004, [EMAIL PROTECTED] wrote:
> >Quoting "William A. Rowe, Jr." <[EMAIL PROTECTED]>:
> >
> >>
> >> >rbb 2004/03/15 10:33:30
> >> >
> >> > 1.1 apr/test/globalmutexchild.c
> >> >...
> >> > int main(
At 12:56 PM 3/15/2004, [EMAIL PROTECTED] wrote:
>Quoting "William A. Rowe, Jr." <[EMAIL PROTECTED]>:
>
>>
>> >rbb 2004/03/15 10:33:30
>> >
>> > 1.1 apr/test/globalmutexchild.c
>> >...
>> > int main(int argc, const char * const argv[])
>> > {
>> > apr_pool_t *p;
>
On Mar 15, 2004, at 11:15 AM, Aaron Bannert wrote:
On Mar 15, 2004, at 10:56 AM, [EMAIL PROTECTED] wrote:
Nope. Take a look at the thread that is complaining about the API for
global_mutex and proc_mutex. Without that global_mutex_create call,
the program
segfaults on any Unix machine. This is
On Mar 15, 2004, at 10:56 AM, [EMAIL PROTECTED] wrote:
Nope. Take a look at the thread that is complaining about the API for
global_mutex and proc_mutex. Without that global_mutex_create call,
the program
segfaults on any Unix machine. This is a bug in the _child_init API,
because it
should ac
Quoting "William A. Rowe, Jr." <[EMAIL PROTECTED]>:
>
> >rbb 2004/03/15 10:33:30
> >
> > 1.1 apr/test/globalmutexchild.c
> >...
> > int main(int argc, const char * const argv[])
> > {
> > apr_pool_t *p;
> > int i = 0;
> > apr_global_mutex_t *global_loc
Quoting [EMAIL PROTECTED]:
> Quoting Aaron Bannert <[EMAIL PROTECTED]>:
>
> > On Mon, Mar 15, 2004 at 09:13:34AM -0800, [EMAIL PROTECTED] wrote:
> > > I am trying to port the testgloballock code to the unified framework,
> and
> > I
> > > can't make the child process work. It seems that
> > apr_
>rbb 2004/03/15 10:33:30
>
> 1.1 apr/test/globalmutexchild.c
>...
> int main(int argc, const char * const argv[])
> {
> apr_pool_t *p;
> int i = 0;
> apr_global_mutex_t *global_lock;
>
> apr_initialize();
> atexit(apr_terminate);
>
>
Quoting Aaron Bannert <[EMAIL PROTECTED]>:
> On Mon, Mar 15, 2004 at 09:13:34AM -0800, [EMAIL PROTECTED] wrote:
> > I am trying to port the testgloballock code to the unified framework, and
> I
> > can't make the child process work. It seems that
> apr_global_lock_child_init
> > only works if the
At 02:15 AM 3/14/2004, Robert Norris wrote:
>Attached is a patch that adds a function apr_pollset_update(). This
>updates the list of requested events for the descriptor in the
>underlying implementation for a descriptor that is already in a pollset.
>...
>The optimisation that I'd like to do is to
On Mon, Mar 15, 2004 at 09:13:34AM -0800, [EMAIL PROTECTED] wrote:
> I am trying to port the testgloballock code to the unified framework, and I
> can't make the child process work. It seems that apr_global_lock_child_init
> only works if the child process was created using apr_fork. This means t
A couple of comments:
1) This patch isn't complete. At the very least we need a patch to the header
that includes doxygen comments that document this new API. Preferably, a new
patch would also include a patch to testpoll to test this feature. It should
also include a stub function in all non-
I am trying to port the testgloballock code to the unified framework, and I
can't make the child process work. It seems that apr_global_lock_child_init
only works if the child process was created using apr_fork. This means that the
global_lock API can't be used on non-Unix platforms. This same
On Mon, 15 Mar 2004, Geoffrey Young wrote:
> if you could take a look at this
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25550
Noted, thanks!
> Let me know if you have specific things you want to see in 0.9.5 (that are
> doable in say a day's time... nothing more than that).
if you could take a look at this
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25550
it would be great. there's no diff-generated patch but the change is s
Robert Norris wrote:
Robert,
Thanks for resending... No promises but I'll try to review this this week.
Please, someone beat me to it.
Bill
[ I'm resending this, because I didn't get any responses to it the first
time. ]
Attached is a patch that adds a function apr_pollset_update(). This
updates t
Quoting Nick Kew <[EMAIL PROTECTED]>:
> >
> > Personally, I dislike using a random number to simulate a failure rate.
>
> OK so far. Perhaps the fact that my degree was maths and my first job
> was in stochastic simulation makes me happier than some with them:-)
>
> > The
> > purpose of the
>
> Personally, I dislike using a random number to simulate a failure rate.
OK so far. Perhaps the fact that my degree was maths and my first job
was in stochastic simulation makes me happier than some with them:-)
> The
> purpose of the test suite isn't to emulate the real world where you
Quoting Nick Kew <[EMAIL PROTECTED]>:
> On Mon, 15 Mar 2004, Aaron Bannert wrote:
>
> > I ended up just committing Nick's patch to testreslist.c. I'm not
>
> That's a good question. I wasn't at all sure my use of the random
> number generation (to simulate a failure rate) would meet APR
> porta
Quoting Aaron Bannert <[EMAIL PROTECTED]>:
> On Wed, Mar 10, 2004 at 06:06:16PM -0800, [EMAIL PROTECTED] wrote:
> > APR-util needs a full test suite. I will try to put together the
> framework
> > from
> > the APR repository ASAP. probably sometime tomorrow. While I am at it I
> will
> > start
related trivia for Solaris users: the folks at www.blastwave.org were kind
enough to add ssl support to their subversion package this weekend...
previously it was not useful for accessing the test repository
On Mon, 15 Mar 2004, Aaron Bannert wrote:
> I ended up just committing Nick's patch to testreslist.c. I'm not
That's a good question. I wasn't at all sure my use of the random
number generation (to simulate a failure rate) would meet APR
portability criteria. In the absence of an apr_random mod
On Thu, Mar 11, 2004 at 11:34:27PM +, Joe Orton wrote:
> On Thu, Mar 11, 2004 at 02:18:04PM -0800, Aaron Bannert wrote:
> > Are the showstoppers that are listed in the STATUS file the only
> > ones we have? (for APR, APR-UTIL, etc...)
>
[...]
> - fixing condition variables on Win32
There is a
On Wed, Mar 10, 2004 at 06:06:16PM -0800, [EMAIL PROTECTED] wrote:
> APR-util needs a full test suite. I will try to put together the framework
> from
> the APR repository ASAP. probably sometime tomorrow. While I am at it I will
> start the test suite at the same time. I will be focusing on th
On Mon, Mar 15, 2004 at 03:37:42AM +, Nick Kew wrote:
> It's 3 in the morning again, but I've written an updated patch,
> This time I've adapted the testsuite to watch it in action and
> successfully run it (Linux 2.4.x). As ever, more eyes better:-)
Tested and committed. Thanks for the patch
I know it's got a few more patches I need to get in before it's ready to
go, but just so that I could go ahead and at least get started on this
(using some extended definition of "tomorrow" which technically ended
about 24 hrs ago, sigh)... I've tagged apr, apr-util, and apr-iconv as
JCW_0_9_5_PRE
On Sun, 14 Mar 2004, Jeff Trawick wrote:
> see comments in PR 26050 about discrepancy in prototypes that seems to show an
> underlying issue; apps don't see apr_res_t, so some rework and testing is
> needed
It's a fair cop guv. The resource is detached when it's issued, so
invalidate mustn't ta
On Sun, 14 Mar 2004 [EMAIL PROTECTED] wrote:
> This needs to get resolved. I believe the fix is to simply add the correct
> checks to APR_STATUS_IS_TIMEUP, but I also would like to know if we really
> need
> to keep APR_STATUS_IS_ETIMEDOUT at all. Can we mark it deprecated?
+1 as far as I'm co
I have spent the last half hour or so trying to make the socket timeout tests
pass on Windows. I couldn't make it happen, so I finally started reading
through the code. It turns out that we have a number of error codes that mean
that a timeout has expired.
On any platform that uses wait_for_io_
Committed.
Ryan
Quoting Garrett Rooney <[EMAIL PROTECTED]>:
>
> On Mar 14, 2004, at 9:15 PM, [EMAIL PROTECTED] wrote:
>
> >
> > applied and committed.
> >
> > Thanks, and keep 'em coming.
>
> Sure thing. Here's two more in testsock.c ;-)
>
> -garrett
>
> Index: test/testsock.c
> =
On Mar 14, 2004, at 9:15 PM, [EMAIL PROTECTED] wrote:
applied and committed.
Thanks, and keep 'em coming.
Sure thing. Here's two more in testsock.c ;-)
-garrett
Index: test/testsock.c
===
RCS file: /home/cvspublic/apr/test/testsock.c,
applied and committed.
Thanks, and keep 'em coming.
Ryan
Quoting Garrett Rooney <[EMAIL PROTECTED]>:
> The new sockchild.c file has a few warnings on OS X.
>
> /bin/sh /Users/rooneg/Hacking/apr/libtool --silent --mode=compile gcc
> -g -O2 -DHAVE_CONFIG_H -DDARWIN -DSIGPROCMASK_SETS_THREAD_
I'll apply this later tonight. Ever since writing this test, I have been trying
to make it work on Windows.
Ryan
Quoting Garrett Rooney <[EMAIL PROTECTED]>:
> The new sockchild.c file has a few warnings on OS X.
>
> /bin/sh /Users/rooneg/Hacking/apr/libtool --silent --mode=compile gcc
> -g -
The new sockchild.c file has a few warnings on OS X.
/bin/sh /Users/rooneg/Hacking/apr/libtool --silent --mode=compile gcc
-g -O2 -DHAVE_CONFIG_H -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK
-no-cpp-precomp -I../include -o sockchild.lo -c sockchild.c && touch
sockchild.lo
sockchild.c: In functio
38 matches
Mail list logo
