This has been merged with the abts SVN repo.
Ryan
On 21 Jun 2004 [EMAIL PROTECTED] wrote:
> dreid 2004/06/21 08:18:00
>
> Modified:test abts.c
> Log:
> Allow abts_str_equal() to handle NULL values being passed in without
> segfaulting. This should probably be applied into
It could work, you are correct. I wasn't trying to fix that problem, I
was trying to get _any_ mutexes to work with proc_create. If we have
other bugs that some mutexes do work and others don't, then thats fine,
but those are other bugs that can easily be worked out whenever. The API
is what I
On Tue, 15 Jun 2004, Joe Orton wrote:
> On Mon, Jun 14, 2004 at 08:02:41AM -0400, [EMAIL PROTECTED] wrote:
> > On Mon, 14 Jun 2004, Justin Erenkrantz wrote:
> > > How will fcntl() work with this? flock() isn't on a bunch of platforms,
> > > so
> > > fcntl() is probably the more portable soluti
On Mon, 14 Jun 2004, Brad Nicholes wrote:
>Is there a reason why the apr_procattr APIs were implemented as
>
> apr_procattr_xxx_set (apr_procattr_t*, value)
>
> rather than
>
> apr_procattr_set (apr_procattr_t*, APR_xxx_ATTR, value, ...)
>
> It seems like the second approach would make it ea
On Mon, 14 Jun 2004, Justin Erenkrantz wrote:
> --On Saturday, June 12, 2004 9:45 PM -0400 [EMAIL PROTECTED] wrote:
>
> > OK, here is the proc mutex re-org. This is ugly, but it passes all of the
> > tests, using both fork and proc_create. The only problem with this patch,
> > is that it doesn
++1 to re-naming this way. You guys know not to let me name things.
After I get some more feedback, I'll make this change (and possibly
others) and commit.
Ryan
On Sun, 13 Jun 2004, William A. Rowe, Jr. wrote:
> At 08:45 PM 6/12/2004, [EMAIL PROTECTED] wrote:
>
> >OK, here is the proc mutex re
OK, here is the proc mutex re-org. This is ugly, but it passes all of the
tests, using both fork and proc_create. The only problem with this patch,
is that it doesn't do the configure magic to actually setup FORK_DEFAULT
and PROC_CREATE_DEFAULT. To test this, I just set APR_USE_FLOCK_SERIALIZE
I have the code compiling, but not working yet. Once I have all the tests
passing on my box (hopefully tomorrow now), I will be posting a patch,
because we will need some changes to the configure system to make this
work, and I'm not really sure how to best make those changes.
Ryan
On Tue, 8 Jun 2004 [EMAIL PROTECTED] wrote:
> On Mon, 7 Jun 2004, William A. Rowe, Jr. wrote:
>
> > At 07:42 AM 6/4/2004, Joe Orton wrote:
> > >On Fri, Jun 04, 2004 at 02:31:48AM -0700, Justin Erenkrantz wrote:
> > >> I took a look at the locking problem, and I think it can be fixed
> > >> rathe
On Mon, 7 Jun 2004, William A. Rowe, Jr. wrote:
> At 07:42 AM 6/4/2004, Joe Orton wrote:
> >On Fri, Jun 04, 2004 at 02:31:48AM -0700, Justin Erenkrantz wrote:
> >> I took a look at the locking problem, and I think it can be fixed
> >> rather trivially. This is a minor problem in that it only aff
On 7 Jun 2004 [EMAIL PROTECTED] wrote:
>mod_test.la: mod_test.slo $(LOCAL_LIBS)
> +<<< Makefile.in
> + $(LIBTOOL) --mode=link $(COMPILE) -rpath $(srcdir) -avoid-version
> -module mod_test.lo $(LT_LDFLAGS) $(ALL_LDFLAGS) -o $@
> +===
> $(LIBTOOL) $(LTFLAGS) --mode=link $(
On Mon, 7 Jun 2004, David Reid wrote:
> > rbb 2004/06/05 12:20:12
> >
> > Modified:test abts.c
> > Log:
> > Add back the -l option to the apr test suite. This allows the test
> suite
> > to list all available tests.
>
> Tha
lowly with it, so somebody else could easily beat me to it.
Ryan
On 5 Jun 2004 [EMAIL PROTECTED] wrote:
> rbb 2004/06/05 15:19:42
>
> Modified:test Makefile.in testuuid.c
> Added: test abts.c abts.h abts_tests.h testutil.c testutil.h
> Removed: tes
On 4 Jun 2004 [EMAIL PROTECTED] wrote:
> jerenkrantz2004/06/04 01:44:15
>
> Modified:test abts.c globalmutexchild.c testglobalmutex.c
> Log:
> Various test suite improvements to actually test the global mutex code with
> all
> of the available methods.
>
> abts.c: Properly
On Sat, 5 Jun 2004, Damir Dezeljin wrote:
> Hi.
>
>
> > What platform are you on?
> Windows :'(
>
>
> > (although I know we have solved this somehow
> > for pipes, because we must poll in mod_cgi.)
> This is a great news. I need to poll on a pipe from child process. I will
> try to checkout a re
On Fri, 4 Jun 2004, Joe Orton wrote:
> On Fri, Jun 04, 2004 at 02:31:48AM -0700, Justin Erenkrantz wrote:
> > I took a look at the locking problem, and I think it can be fixed
> > rather trivially. This is a minor problem in that it only affects the
> > case where the child doesn't share memory
What platform are you on? Polling on file descriptors isn't available on
all platforms, because not all of the underlying platforms support it. I
believe that Windows, for example, can't do it, at least not with the
functions that we are using. (although I know we have solved this somehow
for p
Changing to the new framework for apr-util is trivial, because there is
just one test file that is actually using it. What is more annoying is
re-writing all of the existing test files to use the framework, which I
just don't have the time for right now. I'll try to get to updating the
test fram
On Fri, 4 Jun 2004, Stas Bekman wrote:
> Jeff Trawick wrote:
>
> There is one more problem. Not the whole API is tested and many APIs are
> tested only partially. IMHO, you want to run coverage tests first and only
> after passing a sensible coverage threshold, should 1.0 be released.
This goal
On Fri, 4 Jun 2004, Justin Erenkrantz wrote:
> --On Friday, June 4, 2004 9:58 AM -0400 [EMAIL PROTECTED] wrote:
>
> > You don't need apr_*_mutex_join, that is what apr_*_mutex_child_init is
> > supposed to do, but it can't, because the API doesn't work. The simple
> > fact that you needed to in
On Fri, 4 Jun 2004, Amit Athavale wrote:
> Quoting Ryans solution
>
> >
> >
> >
> >I've been working on this, and I don't see a solution. I have the parameter
> >added to child_init, and the structures get allocated. But, that doesn't
> >solve
> >the problem, because many lock types just can'
You don't need apr_*_mutex_join, that is what apr_*_mutex_child_init is
supposed to do, but it can't, because the API doesn't work. The simple
fact that you needed to insert a new method to do exactly what an existing
method does proves that the API is currently broken.
Now, the reason that this
On Thu, 3 Jun 2004, Greg Stein wrote:
> On Thu, Jun 03, 2004 at 01:35:06PM -0400, [EMAIL PROTECTED] wrote:
> > On Thu, 3 Jun 2004, Justin Erenkrantz wrote:
> >...
> > > Can we fix it in 2.0? Sure. No reason that a 1.0 release prevents that.
> > > And, we might be able to fix it in 1.1, but it de
On Thu, 3 Jun 2004, Justin Erenkrantz wrote:
> --On Thursday, June 3, 2004 9:53 AM -0400 [EMAIL PROTECTED] wrote:
>
> > Dude, the API _can't_ work. This isn't a matter of being able to slap a
> > fix on it. The locking API isn't portable, and until it is changed in
> > some way, can't be made
Here is a pointer to the e-mail:
http://marc.theaimsgroup.com/?l=apr-dev&m=107940423312808&w=2
Ryan
On Thu, 3 Jun 2004, Amit Athavale wrote:
> >
> >
> >>>The damned locking API can't work portably as things stand today. It
> >>>wasn't designed to be portable, and it was never tested in a port
On Thu, 3 Jun 2004, Justin Erenkrantz wrote:
> --On Thursday, June 3, 2004 7:17 AM -0400 [EMAIL PROTECTED] wrote:
>
> > The damned locking API can't work portably as things stand today. It
> > wasn't designed to be portable, and it was never tested in a portable
> > manner. I posted a possible
On Thu, 3 Jun 2004, Jeff Trawick wrote:
> Who is going to do anything about these showstoppers and when? If no action,
> I
> don't see why they should be considered showstoppers.
They are showstoppers because they break the library. If they aren't
breaking the library, then they probably aren
On 2 Jun 2004 [EMAIL PROTECTED] wrote:
> jorton 2004/06/02 01:27:43
>
> Modified:test testsock.c
> Log:
> * test/testsock.c (setup_socket): Return NULL if bind fails, fixing
> test suite hang if port 8021 is in use; all callers updated. (come
> back longjmp, all is forgive
On Tue, 1 Jun 2004, [UTF-8] Branko Čibej wrote:
> Klaus Keppler wrote:
>
> > Hello Ryan,
> >
> >>> b. In apr_thread_cond[_timed]_wait cond->mutex and mutex are reset
> >>> multiple times, why?
> >>
> >
> >> I don't know. I'll need to dig into this.
> >
> >
> > Recently I wrote a multithreaded
I wrote this code initially a long time ago, and since then some others
primarily Will Rowe have tried to improve it. However, for the most part
the code you are talking about is my original code.
On Tue, 1 Jun 2004, malc wrote:
> Hello,
>
> I have a couple of question regarding win32 condition
I am generally avoiding the branching, because I haven't found a good
explanation of when we back-port and when we don't. So, if somebody else
cares, they can merge.
Ryan
On Thu, 27 May 2004, Stas Bekman wrote:
> [EMAIL PROTECTED] wrote:
> > This doc update has been committed.
>
> Thanks Ryan.
This doc update has been committed.
Ryan
On Thu, 27 May 2004, Stas Bekman wrote:
> [EMAIL PROTECTED] wrote:
> >
> > On Wed, 26 May 2004, William A. Rowe, Jr. wrote:
> >
> >
> >>At 09:05 PM 5/26/2004, Stas Bekman wrote:
> >>
> >>
> >>>I've posted the following wording:
> >>>
> >>>/**
> >>>* Vali
On Thu, 27 May 2004, Stas Bekman wrote:
> [EMAIL PROTECTED] wrote:
> > On Thu, 27 May 2004, Geoffrey Young wrote:
> >
> >
> >>>This should move to the httpd list
> >>
> >>um, ok, but it's not necessarily a .htpasswd specific issue. anyone trying
> >>to use apr_password_validate on win32 could p
One more item for that copious free time that doesn't exist. :-)
This'll get bumped up my stack of things to do asap.
Ryan
On Thu, 27 May 2004, Stas Bekman wrote:
> I hate to act as a broken phone, but Steve Hay reports that sha1 validation
> fails on win32. Quoting Steve:
>
> --
On Thu, 27 May 2004, Geoffrey Young wrote:
>
> > This should move to the httpd list
>
> um, ok, but it's not necessarily a .htpasswd specific issue. anyone trying
> to use apr_password_validate on win32 could potentially run into this.
>
> the snag, as I see it, is that the fallback position on s
On Thu, 27 May 2004, Geoffrey Young wrote:
>
> > I beg your pardon, gentlemen. Would you be so kind to decide first
> > between yourself whether this is a bug or not? According to Ryan it's
> > not a bug, according to your comment above, Bill, it is.
>
> I think there is a bug lurking around, at l
On Wed, 26 May 2004, William A. Rowe, Jr. wrote:
> At 09:05 PM 5/26/2004, Stas Bekman wrote:
>
> >I've posted the following wording:
> >
> >/**
> > * Validate hashes created by APR-supported algorithms: md5 and base64.
> > * hashes created by crypt are supported only on platforms that provide
>
On Wed, 26 May 2004, Stas Bekman wrote:
> [EMAIL PROTECTED] wrote:
> > Also it will show you how to generate the data for yourself.
>
> Unfortunately at the moment I have no time to figure it out. Though it worries
> me that I couldn't get non-apr md5/sha1 generators' output pass
> password_val
On Wed, 26 May 2004, Stas Bekman wrote:
> So I'm trying to drop crypt and trying to write tests for the md5 and sha1
> parts of the apr_password_validate. I fail to come up with any test input that
> will pass the test. I try various md5 and sha1 functions, and none of them
> matches. Is it suppo
On Wed, 26 May 2004, Stas Bekman wrote:
> [EMAIL PROTECTED] wrote:
> > Portable doesn't mean what most people think in means in APR. It means
> > the code _should_ work on all platforms. It doesn't mean that the data
> > will be processed identically on all platforms hwoever. In this case, you
Portable doesn't mean what most people think in means in APR. It means
the code _should_ work on all platforms. It doesn't mean that the data
will be processed identically on all platforms hwoever. In this case, you
are asking windows to validate a password that it can't encrypt. That
isn't go
On Wed, 26 May 2004, Graham Leggett wrote:
> Amit Athavale wrote:
>
> > Normally EEXIST is returned when CREATE and EXCL flags are combined.
> > So I guess you are trying to create segment which is already there.
> > check with ipcs
> > whether you have orphan segments ('cause of some reasons)
>
Linux supports both anonymous and named shared memory. By default though,
Linux is using SHMGET in APR, which is named, but not backed by a file.
You will get APR_EEXIST if the semaphore already exists, this can be
checked by running ipcs.
I hit this problem with the test suite at one point, and
This is a deficiency in our error reporting for apr_shm_foo. Basically,
we always use the same error codes, regardless of the shm mechanism used.
In all likelyhood, your problem is that your system is using shmget under
the covers. In that case, we don't use the filename that you pass in.
So, ru
On 25 May 2004 [EMAIL PROTECTED] wrote:
> bnicholes2004/05/25 15:29:33
>
> Modified:test testpoll.c
> Log:
> A timeout value of 0 causes select() on NetWare to return immediately with
> a timeout error. So give NetWare a little time.
This isn't the right fix. Select should
On 24 May 2004 [EMAIL PROTECTED] wrote:
> jorton 2004/05/24 05:45:29
>
> Modified:test abts.c
> Log:
> * test/abts.c (abts_add_suite): Strip .c extension from subsuite name.
Yeah, I was too lazy to do that. :-)
Ryan
On Sun, 23 May 2004, Joe Orton wrote:
> On Sat, May 15, 2004 at 07:51:50PM -, Ryan Bloom wrote:
> > rbb 2004/05/15 12:51:50
> >
> > Modified:test testshm.c
> > Log:
> > If we can't create the shared memory segment, don't try t
I think I see what you mean by cleaning up -q output. It have already
committed a fix to the svn repo for ABTS. I am porting to APR's version
right now.
Ryan
On Sun, 23 May 2004 [EMAIL PROTECTED] wrote:
>
>
> On Sun, 23 May 2004, Joe Orton wrote:
>
> > On Sun, May 23, 2004 at 02:43:03PM -0400
On Sun, 23 May 2004, Joe Orton wrote:
> On Sun, May 23, 2004 at 02:43:03PM -0400, [EMAIL PROTECTED] wrote:
> > Ok, \r isn't going to work either. The problem seems to be when the
> > output is captured to a file, which is what I image emacs is doing. I'm
> > going to keep hunting for a solutio
Ok, \r isn't going to work either. The problem seems to be when the
output is captured to a file, which is what I image emacs is doing. I'm
going to keep hunting for a solution for this, but I am not convinced that
I will actually find one that is both portable and works for arbitrary
output str
Hmm. Ok, so \b is really correct, and I would consider this a
configuration problem more than anything else. \b is supposed to print a
backspace character, I believe that your emacs is getting confused,
because ctrl-H in emacs is the default help command. So, \b just doesn't
look like
I'll try to fix it tonight.
Ryan
On Thu, 20 May 2004, Ed Holyat wrote:
>
>
> the new test suite uses a \b in it's output. In my bash shell/emacs
> environment, this produces some ugly output.
>
> testatomic.c: |^H/^H-^H|^H\^H-^H|...etc
>
> using the octal value \008 produces the desired effect
On Sun, 16 May 2004, Cliff Woolley wrote:
> On Sun, 16 May 2004, Stas Bekman wrote:
>
> > What I'm after is having APR API specify which apr functions have errno set,
> > so one can rely on that and not do guessing which can change in the future.
>
> My gut reaction is that if we actually /need/ e
Another bug from subversion.
Ryan
-- Forwarded message --
Date: Sun, 09 May 2004 19:59:05 +0200
From: C.A.T.Magic <[EMAIL PROTECTED]>
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Cc: Josh Pieper <[EMAIL PROTECTED]>
Subject: Re: [bug] FSFS errors when doing simultaneous commits - w
There is a bug in the Mac OS X readdir implementation that is breaking
subversion in some situations. I don't have easy access to a box that I
can use to re-create and fix this bug. But, this is definately something
APR should work-around.
Ryan
-- Forwarded message --
Date: Sun
On Tue, 4 May 2004, [UTF-8] Branko Čibej wrote:
> [EMAIL PROTECTED] wrote:
>
> >On Sat, 1 May 2004, makl wrote:
> >
> >
> >> Currently I do the copy from apr.hw to apr.h at install time, since I
> >>
> >>havn't found a good way to do that at configure time without making
> >>config.status useles
__FILE__ is already added to the suite, so the output always includes the
actual file name. As for __LINE__, it is something that I have considered
adding to the log_message function, but I am not convinced of it's
usefulness once we have the ability to print out custom messages. In
CuTest, it i
The new test framework is essentially done. There are some features I
would still like to add. However, the suite has feature parity with the
CuTest framework that we are currently using. The suite was written from
scratch, but it has many of the same advantages of the CuTest framework
(ie smal
On Sat, 1 May 2004, makl wrote:
> [EMAIL PROTECTED] wrote:
>
> >>Index: Makefile.in
> >>===
> >>RCS file: /home/cvspublic/apr/Makefile.in,v
> >>retrieving revision 1.97
> >>diff -u -3 -r1.97 Makefile.in
> >>--- Makefile.in 10 Ma
Please post patches in-line, it makes it much easier to reply to them with
comments.
> Index: Makefile.in
> ===
> RCS file: /home/cvspublic/apr/Makefile.in,v
> retrieving revision 1.97
> diff -u -3 -r1.97 Makefile.in
> --- Makefile.
No, neither should be exposed, but Unix (as a general rule, some
variants have solved this, most haven't) doesn't let us have that fine
grain-ed resolution, so the unix one is exposed.
Ryan
On Thu, 29 Apr 2004, Brad Nicholes wrote:
>If we add APR_DECLARE() to the prototype, it will cause th
So, CuTest was bothering me because it does some stupid things, like longjmp'ing
out of the test functions. I have begun writing a new framework from the ground
up. This should be a much cleaner API and it gives much better output IMNSHO.
The suite isn't complete yet, and some major features ar
I'll add some tests to the test program tonight to catch stuff like this.
Ryan
Quoting Joe Orton <[EMAIL PROTECTED]>:
> This broke apr_hash_{merge,overlay}; I've checked in a minimal fix to
> stop httpd segfaulting everywhere, but presumable it needs a doc string
> update as below, unless behav
Quoting André Malo <[EMAIL PROTECTED]>:
> * [EMAIL PROTECTED] wrote:
>
> > Quoting André Malo <[EMAIL PROTECTED]>:
> >
> > > * André Malo <[EMAIL PROTECTED]> wrote:
> > >
> > > > APR_DECLARE(apr_hash_t *) apr_hash_make_custom(apr_pool_t *pool,
> > > >
Quoting André Malo <[EMAIL PROTECTED]>:
> * André Malo <[EMAIL PROTECTED]> wrote:
>
> > APR_DECLARE(apr_hash_t *) apr_hash_make_custom(apr_pool_t *pool,
> > apr_hashfunc_t hash_func)
>
> Additionally hash_func should be a pointer (also in declarat
I fixed this. I thought I had re-compiled after my changes, but I must have
just been in the test directory when I did it.
Ryan
Quoting André Malo <[EMAIL PROTECTED]>:
> * [EMAIL PROTECTED] wrote:
>
> > +APR_DECLARE(apr_hash_t *) apr_hash_make_custom(apr_pool_t *pool,
> > +
Committed. Thank you for creating a new test for this as well. :-D
Ryan
Quoting Ami Ganguli <[EMAIL PROTECTED]>:
> --- Ami Ganguli <[EMAIL PROTECTED]> wrote:
> >Small problem... the APR_HASH_KEY_STRING case
> > requires that we find the key length.
>
> Here's a new patch.
>
> - Added
I've done a (very) quick review, and the concept looks right. One small change
that I will make when I commit the code. ->hash_func should always have a
value, if the hash_table isn't creted with apr_hash_make_custom(), then
apr_hash_make() should set it to a default hash function, which is the
How are you computing your pre-computed hash values? Did you copy the hashing
algorithm from APR's find_entry?
My biggest concern with this function is that the caller's hash function must
agree with APR's hash function or the hash table won't work. What will happen
if APR changes the hash al
< David meant to send this to the list, but hit the wrong button. His message
is reproduced in it's entirity along with my response. >
Quoting David Reid <[EMAIL PROTECTED]>:
> > The biggest problem with releasing HEAD as 1.0, is that the TIMESUP status
> codes
> > don't work everywhere, and lo
Quoting Sander Striker <[EMAIL PROTECTED]>:
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, April 07, 2004 5:40 PM
>
> > Quoting Ian Holsman <[EMAIL PROTECTED]>:
> >
> > > Bojan Smojver wrote:
> > > > I'm not sure if I asked about this before, but the API docs publishe
Quoting Ian Holsman <[EMAIL PROTECTED]>:
> Bojan Smojver wrote:
> > I'm not sure if I asked about this before, but the API docs published on
> the APR
> > site are quite old and they don't have a lot of stuff that new docs have.
> Any
> > chance someone can unleash Doxygen over the files again to
The biggest problem with releasing HEAD as 1.0, is that the TIMESUP status codes
don't work everywhere, and locks aren't portable. Both of these changes will
break source compatibility and need to be fixed before 1.0.
Ryan
Quoting Justin Erenkrantz <[EMAIL PROTECTED]>:
> --On Friday, April 2,
This patch is seg faulting the test suite. I'll look into it, but this may be a
problem with the reference concept and apr_pollset_add. The problem is that you
can create the apr_pollfd_t on the stack, which means that the ref field may not
be initialized. This is what is causing the segfault,
This is on my list of things to look at. I have done a very quick cursory scan
of the patch, but I haven't really looked at it yet. The problem is I just
started a new job, and I am still trying to work out when I have time to code
outside of work.
I'll try to look at this tonight or this weeke
(This e-mail will use apr_size_t throughout. The same applies to apr_off_t and
apr_ssize_t, and possibly other types).
I was going to stay out of this, but I decided not to. apr_off_t and apr_size_t
and any other types like them are incorrectly defined in APR today. The problem
is that they ar
Quoting "Marc M. Adkins" <[EMAIL PROTECTED]>:
> I was working with APR on Windows a half-year ago and used apr_dso_load() a
> fair amount. I could have sworn that the load functionality followed the
> PATH environment variable setting when loading modules. I could easily be
> wrong about that
These are different scenarios, unless sslswamp is sending a signal to the Apache
server for some reason. In the attached e-mail, somebody is trying to run pool
cleanup code from within a signal handler. But running code within a signal
handler is always dangerous, and it generally shouldn't be d
g to have less time to work on this very
soon, so I won't be changing the test suite as often. If you want to set it up
though, go for it and I'll stop checking them in.
Ryan
>
>
> On 17/03/2004, at 10:33 AM, <[EMAIL PROTECTED]> wrote:
>
> > rbb
would really like to make more
progress on the test suite.
Ryan
Quoting [EMAIL PROTECTED]:
> rbb 2004/03/15 18:23:33
>
> Modified:.STATUS
> Log:
> Add a note about the problems with the locking API. This is a
> showstopper,
> because it keep peopl
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
>
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
> >> >
>
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[])
> > {
> > a
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_
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
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
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
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
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
> =
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 -
Quoting [EMAIL PROTECTED]:
> rbb 2004/03/13 13:50:28
>
> Modified:docs/coverage apr_atomic.c.gcov apr_cpystrn.c.gcov
> apr_pools.c.gcov apr_random.c.gcov
> apr_strings.c.gcov index.h
+1
Ryan
Quoting Sander Striker <[EMAIL PROTECTED]>:
> Hi,
>
> I hereby would like to propose that we move APR to the Subversion
> repository at http://svn.apache.org/repos/asf/. Subversion had a
> 1.0 release februari 23rd. Binaries are available for various
> platforms. Given that it is bu
Quoting [EMAIL PROTECTED]:
> rbb 2004/03/10 18:42:34
>
> Modified:test .cvsignore Makefile.in testuuid.c
> Added: test CuTest.c CuTest.h test_aprutil.h testall.c
> Log:
> Add the test framework from APR to APR-util, and port testuuid to the
Quoting Nick Kew <[EMAIL PROTECTED]>:
> On Wed, 10 Mar 2004, Aaron Bannert wrote:
>
> > We'll
> > also want to add some test code while we're at it.
>
> You mean to reslist in particular, or apr_util in general?
> If the former, would it help for me to revisit it?
>
APR-util needs a ful
Quoting [EMAIL PROTECTED]:
> Quoting Joe Orton <[EMAIL PROTECTED]>:
>
> > On Wed, Mar 10, 2004 at 12:19:25PM -0800, [EMAIL PROTECTED] wrote:
> > > Also, this data looks slightly better than it is. While some of the
> files
> > are
> > > in the green block, that doesn't mean that they are fully t
Quoting Joe Orton <[EMAIL PROTECTED]>:
> On Wed, Mar 10, 2004 at 12:19:25PM -0800, [EMAIL PROTECTED] wrote:
> > Also, this data looks slightly better than it is. While some of the files
> are
> > in the green block, that doesn't mean that they are fully tested. Often we
> test
> > a single error
1 - 100 of 806 matches
Mail list logo
