On Wed, 17 Aug 2005, Joe Orton wrote:
> On Tue, Aug 16, 2005 at 01:49:55AM -0500, William Rowe wrote:
> > At 09:24 PM 8/15/2005, Garrett Rooney wrote:
> > >So back in Dec 2003 Sander Striker suggested [1] adding Subversion's
> > >macros for manipulating apr arrays (APR_ARRAY_IDX, which automates
On Mon, 25 Jul 2005, Wilson, Brian A wrote:
> I'm trying to track down an error when closing a program using apr. In
> the jxta-c shell it calls apr_terminate upon exit but it ends up in an
> infinite while loop in apr_allocator_destroy. I've traced it down to a
> point where the while loop is b
On Thu, 21 Jul 2005, Nick Kew wrote:
> On Wed, 20 Jul 2005, Henry Jen wrote:
>
> > I need to have recursive(NESTED) mutex support in our project.
> >
> > Currently apr is relying on pthread lib to provide
> > pthread_mutexattr_settype to provide recursive support, unfortunately,
> > that does not s
On Wed, 20 Jul 2005, Paul Querna wrote:
> > -1 for Win32, the condvars deadlock is a serious bug. I knew this is not
> > news, but as the patch had been available for quite a while, is it
> > possible to get it fixed?
>
> No.
>
> I will not commit such a platform specific patch. Anyone who actual
On Tue, 12 Jul 2005, Dan Johnson wrote:
> The problem is that I need to compile using MinGW under Cygwin, and
> MinGW doesn't provide any of the shared memory header files (shm.h,
> sys/mmap.h, sys/mman.h, etc.) so the test fails.
> A quick Google shows that a few other people have had this probl
On Thu, 26 May 2005, Daniel Rall wrote:
> * apr/include/apr_thread_proc.h
> (apr_thread_data_set): Corrected spelling of the word "thread".
Got it, thanks!
On Tue, 12 Apr 2005, Paul Querna wrote:
> > I believe APR 0.9.x is under CTR.
I was also under the impression that all branches of APR were CTR.
However, I agree that discussion on API changes would be good, even in a
CTR system. That has always been the basic idea with CTR -- you can
commit wi
On Thu, 31 Mar 2005, Sander Striker wrote:
> Ryan Bloom wrote:
> > I really don't think we should take a function like apr_pcalloc and
> > convert it to a macro. The only reason to go to a macro is for
> > performance reasons. First, the performance boost should be
> > relatively minimal, and fo
On Tue, 22 Mar 2005, Marco Spinetti wrote:
> I'd like to know the download and upload speed of clients with my server.
> Can use some apr functions toknow these statistics?
I assume you're talking about Apache 2.0.x. If so, then it's the httpd
that you'll need to query for statistics like this,
On Fri, 18 Mar 2005, Ryan Bloom wrote:
> disabling sendfile solved it immediately. Seems to me that until our
> sendfile support is better, we should err on the side of always
> sending the data correctly instead of absolutely as fast as possible.
>
> I would much rather have APR default to not u
On Thu, 17 Mar 2005, William A. Rowe, Jr. wrote:
> If you two (and anyone else with an explicit vote on the apr-iconv
> 1.0.2 tarball) vote in the next hour it would clarify things quite
> a bit.
My original vote was intended to be +1 for release. Apparently such a
vote at this point is of littl
On Thu, 17 Mar 2005, Jim Jagielski wrote:
> Anyway, anyone who has ever been an RM has done something
> to tick people off, it comes with the job ;)
amen to that...
On Thu, 17 Mar 2005, Paul Querna wrote:
> When I counted the votes, I interpreted all of the +1s to be for the
> entire group (apr, apr-util, apr-iconv). I am sorry if I misinterpreted
> any of the votes. This was not my intention.
This is, I think, the real question, and one I was asking mysel
On Thu, 17 Mar 2005, Justin Erenkrantz wrote:
> > he rolled it, I get 1 vote. Not 3. This is an absolute violation
> > of our charter and operating guidelines.
> >
> > With that, the counter is at four hours, and I will pull
> > down this apr-iconv tarball unless the vote concludes
> > in favor
> @@ -46,6 +46,13 @@
> apr_bucket_alloc_t *list = data;
>
> apr_allocator_free(list->allocator, list->blocks);
> +
> +#if APR_POOL_DEBUG
> +if (list->pool && list->allocator != apr_pool_allocator_get(list->pool))
> {
> +apr_allocator_destroy(list->allocator);
> +}
> +#en
On Sun, 27 Feb 2005, Luca Renzi wrote:
> I'm a student and I need to use apr_lib for a little
> project.
>
> The question is:
> I don't understand what are data and key parameter for
> the function
> apr_socket_data_set.
>
> Could somebody explain?
Several APR data types include a userdata member
On Fri, 18 Feb 2005, Damir Dezeljin wrote:
> I'm developing an application using APR on AS/400 (OS400) platform. As I
> know only apr (no apr-utils) was ported to OS400 by IBM to run Apache2. Do
> anyone know if there is any issue on compiling apr-utils on OS400?
apr-util is supposed to all be co
On Sun, 30 Jan 2005, Nick Kew wrote:
> If anyone with APR karma would like to take responsibility for committing
> it, please contact me within 24 hours to discuss logistics.
This was me dropping the ball, and the problem is being corrected...
On Thu, 20 Jan 2005, Ben Hyde wrote:
> The mnemonic b is widely used for both buckets and brigades.
Sometimes "e" means bucket. :)
> Buckets and brigades both have a field named "list", but one is a
> doubly linked list and the other is one of the many flavors of heap.
heh
I don't think anybo
On Thu, 20 Jan 2005, Ben Hyde wrote:
> Should not the second argument to apr_brigade_create be named
> "bucket_alloc", rather than "list".
It was supposed to mean "freelist". It got its name before we came up
with a name for the bucket allocator (cleverly named bucket_alloc).
In other words, su
On Mon, 27 Dec 2004, Mihai Limbasan wrote:
> In reply to my earlier question - went ahead and did it.
>
> What this patch does is fix all conditionals that depend implicitely
> on APR_SUCCESS being zero to perform an explicit test against its
> *macro definition* and not against the numeric litera
On Mon, 27 Dec 2004, Garrett Rooney wrote:
> Ok, I think we may be talking about two different cases...
>
> There's the "check if a call returned an error, and if so return that to
> your caller" case, which personally I think is easist to read as:
>
> if (rv)
>return rv;
No, that's just me m
On Mon, 27 Dec 2004, Garrett Rooney wrote:
> > This seems to defeat the point of having an APR_SUCCESS in the first
> > place. It's also (at least in my eyes) slightly less intuitive than
> > explicit testing.
>
> Part of the definition of apr_status_t is the fact that APR_SUCCESS is
> defined to
On Wed, 15 Dec 2004, Brad Nicholes wrote:
> release of APR 1.0. Since then there has been a lot of activity in
> TRUNK as compared to almost no activity in the 1.0.x branch.
After the 1.0.x branch was created at ApacheCon, Justin and Thom
backported everything that they thought could be backport
On Thu, 9 Dec 2004, Nick Kew wrote:
> If it is accepted as a startingpoint for an apr-util module, I'll
> donate it to ASF and license it all under ASF terms.
> If not, all rights reserved.
Concept definitely seems appealing...
On Thu, 9 Dec 2004, Nick Kew wrote:
> > Why does the close function take a void arg? Can't we just pass it an
> > apr_dbt_t *?
>
> To pass to apr_pool_cleanup funcs without a cast :-)
Don't do this. This is exactly the sort of thing that got us into trouble
with apr_brigade_cleanup(). In parti
On Tue, 7 Dec 2004, Stas Bekman wrote:
> As explained in the other reply, it's not this code that causes the crash,
> but (maybe) the wrapper that calls it. The wrapper is autogenerated based
> on the prototype. I have no details of the crash, I hate talking on behalf
> of someone, when I don't kn
On Tue, 7 Dec 2004, Stas Bekman wrote:
> Well, I see why it was made like this. this is because of the cleanup
> wrapper:
Originally apr_brigade_cleanup() itself was the pool cleanup callback and
thus the void* argument type was necessary. Later on it was causing
badness on Win32 due (I think) t
On Wed, 1 Dec 2004, David Barrett wrote:
> A couple questions about the XML parser built into apr_util:
>
> 1) Does it support anything other than pure ASCII files?
> 2) Is there any way to parse UTF-8 files?
> 3) Does it use the Xerces XML back end?
My understanding is that it's just a wrapper a
On Tue, 30 Nov 2004, Jeff Trawick wrote:
> > * @param pwbuf Buffer to store the password
> > * @param bufsize The length of the password buffer.
> > + * @remark If the password entered must be truncated to fit in
> > + * the provided buffer, APR_ENAMETOOLONG will be returned.
> > */
> > APR
On Thu, 25 Nov 2004, Joe Orton wrote:
> Or if it does, -1 veto on either bumping the APR major version or
> creating a branch or making toast with jam before Allan submits a patch
> for review on [EMAIL PROTECTED]
Okay, well, that means that for progress to be made, some form of patch
needs to ge
On Wed, 24 Nov 2004, [ISO-8859-15] André Malo wrote:
> As you might have noticed, I'm currently cleaning up the properties that are
> left over from cvs and cvs2svn. In particular:
>
> - removing cvs2svn:cvs-rev
> - adjusting svn:executable (leaving only the real executables)
> - adjusting svn:key
On Wed, 24 Nov 2004, Justin Erenkrantz wrote:
> To be clear, I'm perfectly happy with merging to trunk in Allen's changes
> *once* completed and reviewed and moving trunk to 2.x if need be - but I
Nevertheless, the question at hand is what action to take RIGHT NOW.
"Let's just wait for..." with
On Wed, 24 Nov 2004, Justin Erenkrantz wrote:
> Oh, please don't. We have *no* idea what the changes are or whether we'll
> even ultimately accept them. Please branch Allen's changes off in a
> sandbox (cp trunk branches/64-bit-changes) - let him get a workable version
> that we can then review,
On Wed, 24 Nov 2004, Garrett Rooney wrote:
> I guess I'm just arguing for a single branch that's the target of the
> current development, as opposed to one 64 bit dev branch and one trunk
> which holds other changes, thus requiring us to either invest constant
> effort in merging changes from the
On Wed, 24 Nov 2004, William A. Rowe, Jr. wrote:
> Allan - your last patches were to try to -wedge- the current
> API into httpd. Can you share the patch just to fix APR?
> Then we can start to comprehend scope. NO CASTS - just the
> correct declarations in the first place.
Since this is obviou
On Wed, 24 Nov 2004, Allan Edwards wrote:
> First order of business now that we are on SVN is to focus on
> the APR changes that are needed. It's not clear to me though,
> now that we have an APR 1.0 branch, is the trunk open for
> API-breaking changes or do we need a separate branch for that work
On Mon, 22 Nov 2004, Julian Foad wrote:
> Joe Orton wrote:
> > On Mon, Nov 22, 2004 at 08:14:26PM -, Paul Querna wrote:
> >>+memcpy( (void*)uuid_data, (const void *)&g, sizeof( uuid_t ) );
> >
> > Please watch the code style, Paul!
>
> Not sure exactly what Joe is referring to, but note th
On Mon, 22 Nov 2004, William A. Rowe, Jr. wrote:
> Yes - I understand that this means 1.x will never be used by
> httpd. Version numbers are cheap. The APR project should
> become used to this, if they are active, and httpd moves at
> it's normal pace, it would be easy to go through APR 2.x, 3.x
On Sat, 20 Nov 2004, Justin Erenkrantz wrote:
> > Opinions on my '?'s above?
>
> Looks good. -- justin
Likewise +1 to all.
--Cliff
On Fri, 19 Nov 2004, Garrett Rooney wrote:
> In an attempt to see what happened in the last day or so while my email
> was accidentally being routed to /dev/null (never mess with your email
> settings right before getting on a plane, it's just asking for trouble)
> I checked out the eyebrowse arch
On Fri, 19 Nov 2004, Garrett Rooney wrote:
> We're using SVN now, might as well say so in README.dev ;-)
Got it, thanks.
We've taken the plunge. The APR CVS repositories are now converted and
closed.
svn co https://svn.apache.org/repos/asf/apr/apr/trunk/ apr
svn co https://svn.apache.org/repos/asf/apr/apr-util/trunk/ apr-util
svn co https://svn.apache.org/repos/asf/apr/apr-iconv/trunk/ apr-iconv
svn co https://svn
On Fri, 5 Nov 2004, Marco Spinetti wrote:
> Can someone explain me the difference between apr and glib?
> I see the glib doc
> (http://developer.gnome.org/doc/API/2.0/glib/index.html) and it seems
> very complete: it has a lot of similar apr functions.
Well, as you say, there is a lot of overlap
On Wed, 20 Oct 2004, Brian King wrote:
> I'm just wondering if this is the right list to get support for Win32
> building issues.
Um, well, if you mean "support for building APR on Win32" or "support for
building apps with APR on Win32", then the answer is yes. If you just
need general help with
to
cancel the class altogether.
Hope to see you there,
Cliff
T03: Apache Portable Runtime 1.0 Tutorial
Day: Sat
Time: 09h00
Session chair: None assigned
Duration: 180 minutes
Style: Tutorial
Level: Experienced
Audience: Developer
Categories:
Speaker: Cliff Woolley
Speaker: Sander Striker
As any sys
On Wed, 6 Oct 2004, Jean-Jacques Clar wrote:
> Why providing something that it is going to fail every single
> time?
That was my original thought. I wouldn't mind seeing both the caller as
well as the !HAS_WRITEV cases fixed (or "fixed" if you prefer) for this
reason.
--Cliff
On Tue, 5 Oct 2004, Joe Orton wrote:
> Right, the bug is in how the function is used. It's the same as calling
> apr_file_write() and presuming it won't return short. The fix is to
> call apr_file_write_full(), in that case. In this case, there is no
> apr_file_writev_full(), so that should be
On Mon, 4 Oct 2004, Jean-Jacques Clar wrote:
> >> +if ((rv = apr_file_write(thefile, vec[i].iov_base, nbytes))
>
> I thought that the nbytes on the call for apr_file_write() is the
> number of bytes to write.
Oh crap, I'm sorry, I totally missed that. *blush*
+1 to the patch as-is.
--C
On Mon, 4 Oct 2004, Jean-Jacques Clar wrote:
> If HAS_WRITEV is not defined the current code
> will just push the first vector to the target.
Oooh, that sucks. Good catch.
> The function should write all the vectors or none.
> I propose the following patch, comments will be
+1, with the follo
On Thu, 23 Sep 2004, Mladen Turk wrote:
> I found myself couple of times replying to the original sender
> by default, while my intention was to reply to the list.
> The solution is either to 'reply to all' (why would anyone
> wish to receive two messages about the same subject?) or doing
> that b
On Mon, 20 Sep 2004 [EMAIL PROTECTED] wrote:
> ake 2004/09/20 12:20:12
>
> Modified:atomic/win32 apr_atomic.c
> Log:
> WIN64: avoid unresolved external error with 64 bit build
>{
> +#if (defined(_M_IA64) || defined(_M_AMD64))
> +return InterlockedExchangeAdd(mem, val
Um, it sure would be helpful if the three functions:
API_DECLARE(apr_status_t) apr_iconv_open(const char *, const char *,
apr_pool_t *, apr_iconv_t *);
API_DECLARE(apr_status_t) apr_iconv(apr_iconv_t, const char **,
apr_
Apache Portable Runtime 1.0.0 Released
The Apache Software Foundation and the Apache Portable Runtime
Project are proud to announce the General Availability of
version 1.0.0 of the Apache Portable Runtime, APR.
APR is available for download from:
http://apr.ap
On Mon, 30 Aug 2004, Gisle Vanem wrote:
> Did you read and understand my 1st message? Stuff like
> static APR_INLINE void copy_array_hdr_core (in apr_tables.c)
>
> wouldn't compile. I.e. becoming "static extern __inline ..".
Crap, I mised that detail. Anyway I find it difficult to believe that
t
On Mon, 30 Aug 2004, Gisle Vanem wrote:
> Okay, I worked on the original problem and found a viable fix; Leave the
> APR_INLINE in apr.hw as-is:
>
> #define APR_INLINE __inline
>
> But in headers like arch\win32\apr_arch_atime.h, with inline code do at
> top:
>
> #ifdef __GNUC__
> #undef APR_INLI
On Mon, 30 Aug 2004, Bill Stoddard wrote:
> The apr_thread_cond code in Windows is pretty crufty stuff. I'm going
> to try to find some time to do a rewrite. If I'm not done by the time
> your ready to roll 1.01, then commit Klaus' patch.
Thanks, Bill!
--Cliff
On Sat, 28 Aug 2004, Klaus Keppler wrote:
> Hmm - I posted the bug in march to apr-dev - and was told to open
> a bugzilla ticket. OK - I did so - but nothing happened.
Oy. :( Well, let's just say that having patches fall through the cracks
is probably the single biggest problem that we've been
On Sat, 28 Aug 2004, Klaus Keppler wrote:
> As I already mentioned many many many weeks ago, the implementation
> of condition variables under WIN32 has at least one nasty bug which
> may lead to a deadlock
> (see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27654)
Unfortunately, given our
Normally Bill Rowe will come along behind and build a .zip of the
distribution that was checked out using a Win32 version of CVS so that
*all* of the files have DOS line endings. The .tar.gz and .tar.Z
distributions always have unix line endings.
--Cliff
On Sat, 28 Aug 2004, Klaus Keppler wro
The normal way to have done this would have been to use
#undef APR_IS_DEV_VERSION
instead of removing the #define entirely. David, I didn't see this as a
problem when I built the RC on windows, but you might consider fixing it
prior to the final roll.
--Cliff
On Sat, 28 Aug 2004, Klaus Kep
On Sat, 28 Aug 2004, Gisle Vanem wrote:
> > Has anybody attempted building APR using MingW? The win32 portion
> > of the headers seems rather MSVC centric. I don't know if it's supposed
> > to works since I found no reference to MingW on apache.org or in the docs.
Our win32 support is indeed MSVC
On Fri, 27 Aug 2004, Mladen Turk wrote:
> c) If thread_exit was never called before thread_join
> do not set the retval but rather return APR_INCOMPLETE.
That's really what the unix impl does? APR_INCOMPLETE was supposed to
mean that partial results were returned but just not quite everythin
will all
be good.
--Cliff
On Thu, 26 Aug 2004, Cliff Woolley wrote:
>
> Has anybody gotten apr-util to compile with apr-iconv?
>
> I get the following on win32 when building apr-util with apr and apr-iconv
> all present:
>
> apr-util\xlate\xlate.c(181): error C2198: &
Has anybody gotten apr-util to compile with apr-iconv?
I get the following on win32 when building apr-util with apr and apr-iconv
all present:
apr-util\xlate\xlate.c(181): error C2198: 'apr_iconv_close' : too few
arguments for call through pointer-to-function
apr-util\xlate\xlate.c(182): error
On Sat, 21 Aug 2004, Anthony Wells wrote:
> Currently, I am attempting to port an older Apache 1.3 module to Apache 2.0
> using the APR. Unfortunately, the documentation for APR is rather sparse
The documentation, such as it is, is all in the header files. Some parts
are definitely more verbose
On Tue, 3 Aug 2004, Andrew Stribblehill wrote:
> I'm trying to improve httpd's mod_userdir so that it knows it
> shouldn't serve ~fool when user 'fool' has an administratively
> prohibited shell, so:
>
> UserDir DisableShell /bin/badlad
>
> To this end, I need a function to query the user's shell.
On Mon, 2 Aug 2004, William A. Rowe, Jr. wrote:
> Least action is fork 1.1, cvs rm the offensive files, and change about
> 10 lines of the makefiles and rip out the ldap detection. Pretty trivial.
> Deprecating means we support this junk till 2.0 releases.
+1. If the API is really that broken,
On Sun, 4 Jul 2004, David Reid wrote:
> So, all being well I'll have enough net access to roll RC3 Mon/Tues. If not
> I'll do it on Thursday.
Sounds good to me... thanks David!
--JustCliff
On Tue, 15 Jun 2004, Joe Orton wrote:
> apr_brigade_create() does that already.
Oh, duh, of course it does. As many times as I've looked at that line,
you'd think I'd have it memorized by now. :)
On Tue, 15 Jun 2004, Joe Orton wrote:
> 2) allocate brigade structures using the bucket allocator
If you're going to do this, then surely you need to call
apr_pool_cleanup_register() somewhere?
===
RCS file: /home/cvs/apr-util/buck
On Wed, 26 May 2004, Stas Bekman wrote:
> I thought that P in APR stands for Portable, but I guess it is not quite
> true.
Theory and practice are more similar in theory than in practice. :)
--Cliff
On Sun, 23 May 2004, Noah Misch wrote:
> Perhaps a ``configure'' option for bucket debugging is in order? For that
> matter, why not make it the default; most folks who build their own APU do so
> for a development project, so intuitive failure modes will trump efficiency in
> early use. I can r
On Sat, 22 May 2004, Stas Bekman wrote:
> > that brigade will be corrupted by this operation).
>
> Do you suggest that the sample program that I posted doesn't hang in that
> macro, but after it?
That should be correct, yes. You'll end up creating a loop in the
brigade, and walking through the b
On Fri, 21 May 2004, Stas Bekman wrote:
> I understand all that, but I guess I fail to pass the point across. It is not
> a problem that I encounter in my code. On the contrary I'm writing tests that
> exercise, both valid and invalid ways the API can be called. API that hangs
> when called in inv
On Fri, 21 May 2004, Stas Bekman wrote:
> Joe Orton wrote:
> > On Thu, May 20, 2004 at 03:54:58PM -0700, Stas Bekman wrote:
> >
> >>fb = apr_bucket_flush_create(ba);
> >>db = apr_bucket_transient_create("aaa", 3, ba);
> >>APR_BRIGADE_INSERT_HEAD(bb, db);
> >>APR_BUC
On Thu, 20 May 2004, Stas Bekman wrote:
> #0 0x4037db83 in mallopt () from /lib/tls/libc.so.6
> #1 0x4037b8ba in free () from /lib/tls/libc.so.6
A segfault in free() more or less always means heap corruption has
previously occurred. You might try enabling bucket debugging at compile
time -- th
On Mon, 17 May 2004, Stas Bekman wrote:
> You mean, you dare to leave, without finding a proxy first? :)
I'll be here for the member's meeting. I'm not leaving until Wednesday.
I just have a lot to do between now and then. :)
On Mon, 17 May 2004, Joe Orton wrote:
> I'd hoped some friendly buckets guru would step in here :) I guess if
> it's correct to solve this at bucket-level, the solution is to make
> socket_bucket_read() check whether the socket is non-blocking on each
> call, and temporarily set the timeout to -1
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/ errno to be set to glean
useful information about what
On Fri, 14 May 2004, Stas Bekman wrote:
> So, who changed that in 2.0.49? It worked just fine pre-2.0.48. The guilty
> party please stand up and explain. This change causes a serious breakage in
> the protocol handlers and filters on those affected platforms. I suppose apr
> doesn't have tests for
On Tue, 20 Apr 2004, Mathihalli, Madhusudan wrote:
> Since I didn't get any negative feedback, can I take that it's okay to
> commit the change ?
Lazy consensus would seem to apply -- so, yes. :)
On Mon, 19 Apr 2004, Mathihalli, Madhusudan wrote:
> Since a lot of the async signals are blocked by default, I thought
> it'll be good to provide a apr_(un)block_signal() api for those who want
> to block/unblock only select signals. Here's a patch to do that.
Is this portable? (Admitting
On Wed, 24 Mar 2004, Marc M. Adkins wrote:
> PS Is there a mail archive for this list?
Well I can at least answer this half. ;) Yes, there are several.
Here are a few web-based ones:
http://marc.theaimsgroup.com/?l=apr-dev&r=1&w=2
http://nagoya.apache.org/eyebrowse/SummarizeList?listId=183
-
On Wed, 17 Mar 2004, Sander Striker wrote:
> > 1.20.2.3 +1 -1 apr-util/misc/apr_rmm.c
> > 1.3.2.2 +10 -2 apr-util/test/testrmm.c
> >
> > Sander and company - if the final tags of apr 0.9.5 / httpd 2.0.49 can
> > pick this up - it would be lovely. Well validated.
I'll make sure they
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!
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 [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
On Sun, 14 Mar 2004, Cliff Woolley wrote:
> I'll put my heads together with the PMC and see what we can come up
> with.
Umm... just reread that... "my heads"... *crosses all (four? eight? ;)
eyes*... okay... I need a vacation ;)
On Sun, 14 Mar 2004, Guenter Knauf wrote:
> For what is it good for that I'm familiar with CVS, have it on my
> machine, and am able to contribute patches, if I'm not able to commit
> them, and my posts get mostly ignored (as with many other posts too)
> because either the commiters have no time f
On Fri, 12 Mar 2004, Craig Rodrigues wrote:
> What's the status of apr 0.9.5? I'm getting many
> requests to update apr in the FreeBSD ports system.
T&R tomorrow.
I'll try to attend to any outstanding patches before I roll the RC.
--Cliff
I wanted to do this before I left for NY, but alas, time ran out. I'll
get back Wednesday night, so I'll do it then. If you want to get
something in before the T&R, here's your chance. :) I'll also resurrect
the 1_0_BRANCH at that time, and then -dev will be 1.1-dev, hoping to get
1.0 out SOON
On Sun, 29 Feb 2004 [EMAIL PROTECTED] wrote:
> I've been lurking for the last few days, and this list is too quiet. :-) I'd
> like to stir up trouble again, so I am officially asking to have my commit
> access re-instated. I am in the middle of creating a new project that uses
> APR,
> and I w
On Tue, 24 Feb 2004, David Reid wrote:
> +1 Can we make this a priority for the PMC Chair to persue with the
> board?
I would, but the board (or rather Greg) is already on it. :)
> Given that SVN is now 1.0 we should really get our asses in gear and get 1.0
> out the door. Given the strong opin
On Tue, 24 Feb 2004, Sander Striker wrote:
> This would make the use of any OS header files a derived work of the OS,
> I can't imagine you think this is the case.
Not a good example; there's a specific exemption for that case IIRC.
--Cliff
On Mon, 23 Feb 2004, Justin Erenkrantz wrote:
> Well, if we believe the AL v2.0 is GPL-compatible, then this is a moot point,
> I believe.
"GPL-compatible" means that Apache-licensed code can be added to a GPL
product and that that product can still be distributed under the GPL, not
the other way
On Mon, 23 Feb 2004, Scott Lamb wrote:
> significant difference between them. In transferring either big or
> small files with httpd-2.0 HEAD and ab over loopback on Darwin
> (keepalive on). Which I'd think would be the ideal situation for seeing
> an improvement...
Neither ab nor loopback make f
On Mon, 12 Jan 2004, Craig Rodrigues wrote:
> Has anyone made a move at releasing apr-0.9.5?
> I have a lot of FreeBSD users asking me for an apr-0.9.5
> release so that it can be added to the FreeBSD ports
> tree.
Arhhh.. yet another thing on my list of things to do yesterday. :-/
I'll atte
On Sun, 11 Jan 2004, Charles Bonello wrote:
> I am a student studying business studies at school and I would like some
> information about APR. Would you please forward some information.
Have you seen our website at http://apr.apache.org/ ? What additional
information would you like to know?
--
On Thu, 8 Jan 2004, Donald Doane wrote:
> The following comment is from apr_lib.h:
>
> * apr_vformatter does not call out to any other code, it is entirely
> * self-contained. This allows the callers to do things which are
> * otherwise "unsafe". For example, apr_psprintf uses the "scratch"
>
1 - 100 of 729 matches
Mail list logo
