At 04:50 PM 12/16/2004, Brad Nicholes wrote:
I must still be missing something because this just seems really
unorganized and confusing. If the above is true, then when 1.x finally
does branch and TRUNK becomes 2.x, we will have a 1.0.x branch, 1.1.x
branch ... 1.xxx.x at the same level as a
Mladen, just an FYI... this would leave a couple key issues;
1. This is not an MSVCRT based build, there is a new set of
clib dll files corresponding to the new compilers, which
are not nearly as widely distributed as MSVCRT.dll
2. Some C headers and libs are not in the free compiler
At 12:43 PM 12/27/2004, Mihai Limbasan wrote:
Forgot to attach the patch. Thanks, Garret :)
Minor patch that fixes a few warnings coming up with the (APR default)
warning level 3 when building on VC++ 2003, IA32.
Patch is against the current HEAD (rev 123376).
The file_io/unix/fullrw.c is
At 06:25 AM 1/5/2005, [EMAIL PROTECTED] wrote:
Author: minfrin
Date: Wed Jan 5 04:25:33 2005
New Revision: 124196
URL: http://svn.apache.org/viewcvs?view=revrev=124196
Log:
The Microsoft version of the ldap_start_tls_s() function has 5 parameters
instead of openldap's 3.
+/*
+ * On Windows,
At 11:05 AM 1/5/2005, Jim Jagielski wrote:
Graham Leggett wrote:
I don't see any hassles about requiring that httpd depend on a certain
minimum APR (it does already - httpd v2.1 depends minimally on APR v1.0)
- the only issue is that there has been no official release of apr v1.1
yet for
Can I have a second set of eyes for a reality check before
I backport this compile-time cleanup?
Bill
At 01:01 PM 1/5/2005, [EMAIL PROTECTED] wrote:
Author: wrowe
Date: Wed Jan 5 11:01:20 2005
New Revision: 124243
URL: http://svn.apache.org/viewcvs?view=revrev=124243
Log:
Clean up 4
Ewww... IIUC - apr_ldap_initialize(ldaps://foo/) was supposed to
handle the ssl 'crap' for us. If we are just exposing OpenLDAP and
Novell LDAP, -1 for this change, and I'd like to propose we deprecate
the whole shooting match for ldap.
Consider apr_dbm. We don't expect or require users to
At 01:44 PM 1/6/2005, Graham Leggett wrote:
Brad Nicholes wrote:
How are client certificates specified within the Novell toolkit?
With the API's ldapssl_set_client_cert() and
ldapssl_set_client_private_key()
Can you do this after ldap_init()?
My thinking is to teach apr_ldap_set_option(ld,
At 04:11 PM 1/6/2005, Graham Leggett wrote:
William A. Rowe, Jr. wrote:
Wouldn't it be *much* more economical to do something similar
to apr_procattr_t, where we set up all the choices beforehand,
and can reuse the apr_ldapopt_t over and over on each ldap
connection for options which do
At 10:47 AM 1/7/2005, Jeff Walter wrote:
I took a gander at the APR SHM stuff, the only thing happening after the
file is closed is:
apr_pool_cleanup_register(new_m-pool, new_m, shm_cleanup_owner,
apr_pool_cleanup_null);
*m = new_m;
return APR_SUCCESS;
If all it is doing is registering a
Silly Question - doesn't this proposal fit better
in the commons project than Tomcat?
For that matter, I'm rolling the dice that the apr
project itself would entertain the possibilities of
supporting jni / xs / c++ wrappers.
The reason I suggest this is that we have .pkg and .rpm
folks
At 12:03 PM 1/11/2005, Mladen Turk wrote:
William A. Rowe, Jr. wrote:
Silly Question - doesn't this proposal fit better
in the commons project than Tomcat?
Perhaps, but the guys that are interested in
both c and Java live inside J-T-C :).
Actually, the converse is true - tomcat-dev is modestly
that before backporting.
If I hear no negative feedback, I'll commit Sunday with comment
to 1.0 / 0.9 so they both compile cleanly and such warnings
don't alarm end users.
Bill
At 12:19 PM 1/11/2005, Julian Foad wrote:
William A. Rowe, Jr. wrote:
Can I have a second set of eyes for a reality check before
I
I'm posting to determine who in the apr project would
be interested in a defining a common oo approach to apr
and hosting those efforts in this sphere within apr?
E.g.;
* an [EMAIL PROTECTED] list, discussing and coming
to a common approach for exposing apr as an object
model.
* a
Are you thinking of @bug in the doxygen? That's where I left
all the 0.9 anomalies until 1.0 was ready.
Bill
At 05:57 AM 1/17/2005, Joe Orton wrote:
On Mon, Jan 17, 2005 at 11:40:33AM +, Julian Foad wrote:
/**
* Get the number of key/value pairs in the hash table.
* @param ht The hash
I understand
svn cp .../trunk .../tags/1.1.0
are you planning to drop any new API interfaces from that rev?
Until we commit new API interfaces, doesn't it make as much
sense to leave svn trunk at 1.1 rev? If we decide to further
fix 1.1.x, we can commit those changes to svn trunk.
If we
At 12:19 PM 1/19/2005, Paul Querna wrote:
William A. Rowe, Jr. wrote:
svn cp .../trunk .../branches/1.1
Or if we decided not to use trunk, we can also
svn cp .../tags/1.1.0 .../branches/1.1
^^ that was my plan. (branches/1.1.x/)
The only question you hadn't answered, do we need trunk = 1.2
At 12:33 PM 1/19/2005, Ryan Bloom wrote:
One of my biggest mistakes when initially designing APR was that I
forced each platform to have completely distinct implementations for
simple functions if the structures were distinct. This has led to a
great amount of duplicate code in the library, and
At 06:34 AM 1/27/2005, Max Bowsher wrote:
Ping?
Any responses to the below?
if test -z $places; then
-places=std /usr/local/BerkeleyDB.4.1 /boot/home/config
+places=std /usr/local /usr/local/BerkeleyDB.4.1 /boot/home/config
You cannot change the order... you can append new locations.
At 06:57 AM 1/27/2005, Mads Toftum wrote:
On Thu, Jan 27, 2005 at 02:51:51PM +0200, Graham Leggett wrote:
Following the link on http://apr.apache.org to the announcement for APR
v1.1.0, leads to the announcement for v1.0.1. Is this a website problem or
is my browser being odd?
Unless
At 10:32 AM 1/27/2005, Paul Querna wrote:
I counted +1 from:
~ Brad Nicholes
~ Mladen Turk
~ Graham Leggett
Counting the final RC sounds sane, no need for a second
vote then. Nevermind :)
Bill
At 05:20 PM 1/27/2005, Reid Spencer wrote:
This is a bit of a silly request, but could we get the APR commits list
to use the prefix apr commits instead of svn commits in the subject
line? I'm on the mailing list for both Subversion and APR and I get
confused every time APR sends me an svn commit
And footnote - after Justin's and others' efforts, we actually
incorporated a number of WinCE patches.
You can likely start with the win32 apr (libapr) win32 .dsp
project files, and migrate to that platform.
Bill
At 05:28 PM 1/27/2005, Justin Erenkrantz wrote:
--On Thursday, January 27, 2005
At 07:17 PM 2/4/2005, [EMAIL PROTECTED] wrote:
windows build.
running win32ver.awk when APR_IS_DEV_VERSION is not defined (unmodifed from
apr-1.1.0.tar.gz) causes an illegal libapr.rc to be created. The
PRODUCTVERSION line ends in a comma, rather than a build number.
Agreed this is (was) a
Do you find declarations in stdio.h for fseeko64/ftello64?
Looks like an __off64_t to me on RHAS3.
Bill
At 04:48 PM 2/7/2005, Graham Leggett wrote:
Hi all,
While trying to compile PHP v4.3.2 (RPM as provided by RHEL3) against APR v1.1
and httpd v2.1.3 (trunk) with apr-config changed to
At 04:54 PM 2/7/2005, you wrote:
--On Monday, February 7, 2005 10:44 PM + [EMAIL PROTECTED] wrote:
Author: wrowe
Date: Mon Feb 7 14:44:09 2005
New Revision: 151766
URL: http://svn.apache.org/viewcvs?view=revrev=151766
Log:
In order to remove the win32ver.awk generation of .rc files for
At 05:20 PM 2/7/2005, Justin Erenkrantz wrote:
autoconf uses apr_version.h to determine what version of APR we are using at
build-time.
IIUC, autoconf is doing some complex grep extraction of the
tokens, no?
IIUC, changing to a c-preprocessor only flavor will buy us
the ability to actually run
At 05:30 PM 2/7/2005, Justin Erenkrantz wrote:
+1. This approach is infinitely better than adding new files. -- justin
If the APR_VERSION_ONLY works to exclude the C code (as
opposed to the C preprocessor code) as I've now committed...
I'd apply exactly the same fix on libapr-util and
At 02:31 AM 3/2/2005, Maxim wrote:
Has anyone use APR library (http://apr.apache.org) with your application for
Win32 with MinGW?
First, I tried compiling APR library with MinGW but got the same error about
shared memory allocation support:
./configure:Error: decision on anonymous shared
At 03:19 PM 3/4/2005, Minto van der Sluis wrote:
The reason I ask is because I intend to add apr, apr-util and apr-iconv as
packages to the T2 build environmant (www.t2-project.org). However there is
already a iconv (I think gnu) installed. Unfortunately I am not allowed to
overwrite the
Justin Erenkrantz wrote:
--On Monday, March 7, 2005 10:47 PM -0600 William A. Rowe, Jr. [EMAIL
PROTECTED] wrote:
I'd committed a patch to fix the version resource tag, it seems
we were broken when trying to build non-dev flavors of the .dll's.
I would go for 1.1.1 as I don't believe we're
Only busted for 'releases'.
Because httpd kept picking up -dev tags, this was never noted.
At 12:44 AM 3/11/2005, Justin Erenkrantz wrote:
--On Thursday, March 10, 2005 5:55 PM -0600 William A. Rowe, Jr. [EMAIL
PROTECTED] wrote:
Backporting to 1.1 ASAP, then! A related question, 1.1(.1
Any time you have two different builds, things will go wrong.
In theory, you either build loadable modules or not. If not,
one would think we would disrepect APR_ICONV_PATH. Seems
not to be the case.
I'm unhappy with the number of parallel build flavors in apr
util/iconv, and will look at this
[Proposed solution enclosed]
At 10:07 AM 3/15/2005, Curt Arnold wrote:
iconv modules compiled using apr-0.9.x are not compatible with
applications build with apr-1.x.
As defined. There is no apr 0.x apr 1.x apr 2.x compatibility.
Within apr n.x all apr n.y versions are backward compatible.
At 04:23 PM 3/16/2005, William A. Rowe, Jr. wrote:
2. deposit apr-iconv 0.9 files into the iconv/ subdirectory
in parallel to libaprutil.dll / libapriconv.dll
3. deposit apr-iconv 1.x files into an apriconv.1 subdirectory
in parallel to libaprutil-1.dll / libapriconv-1.dll
4. for both
At 05:08 PM 3/16/2005, Paul Querna wrote:
William A. Rowe, Jr. wrote:
-1 for apr-util / apr-iconv.
Curt has identified a very significant issue; I will comment
to that thread. Since the 'fix' should be fairly trivial,
I think we should next release a version that deals with
iconv/*.so's.
I do
At 10:07 AM 3/15/2005, Curt Arnold wrote:
iconv modules compiled using apr-0.9.x are not compatible with
applications build with apr-1.x. The crash is likely occurring when a
passed in apr_pool_t from the 1.x implementation used by the caller is
passed to the uninitialized apr-0.9.x
It occurs to me the issues can be localized to apr-iconv.
As long as the prerequisite is the as-yet-unreleased apr 1.1.1
with the answer to the tangle codepage file search issue, then
I believe the apr and apr-util tarballs themselves will be fine.
Cracking on getting an appropriate patch
At 06:19 PM 3/16/2005, Justin Erenkrantz wrote:
--On Wednesday, March 16, 2005 6:05 PM -0600 William A. Rowe, Jr. [EMAIL
PROTECTED] wrote:
In answer to the bigger Q - I would discourage anyone from
adopting apr 1.0 and hope few have. apr 1.0 wasn't ready for
prime time, to coexist on machines
At 06:43 PM 3/16/2005, Justin Erenkrantz wrote:
--On Wednesday, March 16, 2005 6:38 PM -0600 William A. Rowe, Jr. [EMAIL
PROTECTED] wrote:
Cracking on getting an appropriate patch together for apr-iconv
trunk, after some brief comments we will move ahead w/ tagging
an apr-iconv 1.1.1.
You
At 06:57 PM 3/16/2005, Justin Erenkrantz wrote:
--On Wednesday, March 16, 2005 6:43 PM -0600 William A. Rowe, Jr. [EMAIL
PROTECTED] wrote:
0.9 and 1.1 yes.
0.9 and 1.0?
Yes. -- justin
Which version did we disambiguate apr-config from apr-config-1?
For that matter, how do we disambiguate
At 08:16 PM 3/16/2005, Sander Striker wrote:
[EMAIL PROTECTED] wrote:
Author: wrowe
Date: Wed Mar 16 18:07:51 2005
New Revision: 157852
URL: http://svn.apache.org/viewcvs?view=revrev=157852
[...]
Modified: apr/apr-iconv/trunk/lib/iconv_module.c
URL:
At 08:29 PM 3/16/2005, Paul Querna wrote:
For that matter, how do we disambiguate include/ from include/?
Most modern libraries have an include/foopkg/*.h structure.
1.0.0
Not when, how?
At 09:57 PM 3/16/2005, Justin Erenkrantz wrote:
On Thu, Mar 17, 2005 at 03:16:44AM +0100, Sander Striker wrote:
API_STRINGIFY? When did we grow that? Is this materially different than
APR_STRINGIFY?
I know, I know. OtherBill's patches required us to remove any dependencies
upon APR_*
Thank you Sander!!!
Although yes, I would wish that viewcvs would do so, I understand how
differently deltas are stacked in svn vs cvs. Obviously, for a given
given pair of mechanisms, each of the functions will perform differently
in terms of speed/bandwidth/storage to one another. I'll spend
I didn't see a vote called for this release. I saw a vote
amended and an extra tarball thrown out there.
I have done a search against pmc@ and [EMAIL PROTECTED] Justin 'amended'
his +1 to include 1.0.2. Nobody else did so (some explicitly
did not vote on this item).
I'm explicitly voting -1
At 01:54 PM 3/17/2005, Justin Erenkrantz wrote:
--On Thursday, March 17, 2005 1:25 PM -0600 William A. Rowe, Jr. [EMAIL
PROTECTED] wrote:
I have done a search against pmc@ and [EMAIL PROTECTED] Justin 'amended'
his +1 to include 1.0.2. Nobody else did so (some explicitly
did not vote
At 02:29 PM 3/17/2005, Justin Erenkrantz wrote:
--On Thursday, March 17, 2005 2:14 PM -0600 William A. Rowe, Jr. [EMAIL
PROTECTED] wrote:
What was insufficiently explicit about
William A. Rowe, Jr. wrote:
-1 for apr-util / apr-iconv.
which Paul replied to?
I still don't see any message from
At 03:03 PM 3/17/2005, Paul Querna wrote:
Jim Jagielski wrote:
Cliff Woolley wrote:
I still think this is an over-reaction as no one operated in bad faith
here. I maintain that any effort would be better placed at fixing the
problems and rolling a new apr-iconv 1.1.0 that fixes whatever problem
At 03:30 PM 3/17/2005, Jim Jagielski wrote:
-0 for keeping, +0 for removing.
Folks there is no vote for removing/not removing.
We have a simple system. Vote for the release or not.
I was being considerate of the RM by allowing 6 hours before
the tally is re-counted, it should have been taken
At 03:12 PM 3/17/2005, Cliff Woolley wrote:
This is, I think, the real question, and one I was asking myself. Did we
at some point decide to release the APR libraries *not* as a group? Why
do we have different revisions of all three going out? Why did apr-iconv
not go to 1.1.x when apr-* did?
While the original tarball was prematurely released, I'm
reminded (thank you :) that it's at least +3 votes, and
1 more +1 than -1 to bless a release. I deliberately waited
to retract the tarball so everyone's votes were correctly
re-tallied.
So far, Sander votes +1. OtherBill votes -1.
Paul
At 03:03 PM 3/17/2005, Paul Querna wrote:
I didn't feel I did it in a rush. I don't feel it was an excessively fast
release cycle.
Just one hopefully productive comment, committing the actual
announce about 24 hours before the release:
* gives translators time to convert to other languages
On the surface, Curt's solution would break our compatibility rules.
But I think we can deviate in this instance;
the modules in iconv/*.so are compiled by the apr-iconv project
itself. If we change both apr-iconv and its modules to now
disambiguate the 0.9 and 1.0 modules, and we expect
At 11:15 AM 3/17/2005 the APR project inadvertantly announced
that APR-Iconv 1.0.2 was released.
This release of APR-Iconv 1.0.2 has since been retracted.
These files have been removed from the downloads page of
www.apache.org. APR-Iconv 1.0.1 remains the current, stable
release. We
At 11:03 AM 3/18/2005, Jim Jagielski wrote:
Seems to me, having apr_socket_sendfile universally available and
having APR deal with whether sendfile exists or how to
implement or emulate it makes the most sense...
The corollary is that if apr_socket_sendfile doesn't do what
the user expects, they
At 10:09 PM 3/29/2005, Curt Arnold wrote:
I'm unclear on the proposed resolution. Does it include a mechanism to
distinguish apriconv-1 encoding modules from apriconv-0 modules either by
changing the module signature or name?
I believe we should do that, too. But it seems that some want
us
At 12:36 AM 3/30/2005, Curt Arnold wrote:
On Mar 29, 2005, at 11:13 PM, William A. Rowe, Jr. wrote:
At 10:09 PM 3/29/2005, Curt Arnold wrote:
I'm unclear on the proposed resolution. Does it include a mechanism to
distinguish apriconv-1 encoding modules from apriconv-0 modules either
DYLD_LIBRARY_PATH or
LD_LIBRARY_PATH on OSX?
Bill
At 09:49 AM 3/30/2005, SteveKing wrote:
Branko Čibej wrote:
William A. Rowe, Jr. wrote:
At 12:36 AM 3/30/2005, Curt Arnold wrote:
However, it would be good if we could get some comment from a Subversion
developer.
Agreed, and Branko's watching
At 10:17 AM 3/30/2005, Mladen Turk wrote:
William A. Rowe, Jr. wrote:
I've developed libxlate library about a year ago, so perhaps
it deserves a second look. It can be integrated within apr-iconv,
because it follows the iconv api.
Since this is my code, I'm willing to donate it to ASF if
accepted
At 01:02 PM 3/30/2005, Curt Arnold wrote:
If apr-iconv is an implementation detail of apr_xlate, then I don't see the
significance of deprecating it. Either it (or a replacement) is needed to
support apr_xlate on platforms that don't provide an iconv or apr_xlate needs
to be deprecated or
At 03:50 PM 3/30/2005, Curt Arnold wrote:
Well, subversion does use apr_xlate. But this was actually reported
by our log4cxx devs, who tripped over the subversion copy when they
thought they were using their own build.
I made the initial report when attempting to use apr_xlate in log4cxx.
Yup
Colm, grep doesn't help here.
Most of the references you cited are EBCDIC platform-specific
uses of apr_xlate.
Bill
At 04:18 PM 3/30/2005, Colm MacCarthaigh wrote:
On Wed, Mar 30, 2005 at 03:50:46PM -0600, Curt Arnold wrote:
I don't think interpretation 1 could be supported since Subversion
At 06:11 PM 3/30/2005, Curt Arnold wrote:
What are the licensing or technical issues of using the X-licensed ICU4C
(http://ibm.com/software/globalization/icu) to implement apr_xlate on
platforms that don't have a native iconv?
It's been 2 years since I examined the option. IIRC it's
c++ code,
At 12:23 AM 3/31/2005, Mladen Turk wrote:
William A. Rowe, Jr. wrote:
FWIW - who else in this community wants to participate if such
an ASL/BSD licensed iconv project grew up around the most current
code for iconv?
Well, I'm interested if the final product will not depend on a
hundred or so
At 12:28 PM 3/31/2005, Curt Arnold wrote:
On Mar 31, 2005, at 5:27 AM, Mladen Turk wrote:
I'm sure we can think of something, but if you say that we
can not use native WIN32, then we could at least offer the
option to use gnu-iconv for win32 builds as well, or any other
iconv-api library.
How
At 03:06 PM 4/6/2005, Curt Arnold wrote:
The issues that I ran into:
1. apr_iconv dereferences inbytes_left without checking for NULL
From the doc comments from apr_xlate_conv_buffer:
If the final call is made as suggested, apr_iconv will case a null pointer
exception. GNU iconv does not.
At 01:38 PM 4/12/2005, [EMAIL PROTECTED] wrote:
Author: pquerna
Date: Tue Apr 12 11:38:21 2005
New Revision: 161087
URL: http://svn.apache.org/viewcvs?view=revrev=161087
Log:
Backport apr_reslist_timeout_set and apr_reslist_invalidate.
These functions have been in 1.x for a long time. I am
At 05:34 PM 4/13/2005, Justin Erenkrantz wrote:
--On Tuesday, April 12, 2005 4:28 PM -0400 Cliff Woolley [EMAIL PROTECTED]
wrote:
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
Feel free to research; the issue is the underlying calls to
[WSA]WaitForEventOrTimeout ... Windows can't poll more than
64 handles + timeout event.
Bill
At 01:38 AM 4/16/2005, Mladen Turk wrote:
Hi,
Can we set the FD_SETSIZE to a higher number then 64
on Windows platform?
Here is what docs say:
At 10:56 AM 4/18/2005, Mladen Turk wrote:
Paul Querna wrote:
Hmm. I am not really happy with this loop. I don't think this will be
very fast with thousands of Sockets. I am far from an expert on Win32,
but why can't 'WSAWaitForMultipleEvents' be used, instead of iterating
every socket?
It has
At 01:10 PM 4/18/2005, Mladen Turk wrote:
William A. Rowe, Jr. wrote:
I do have a productive suggestion though that we kicked around once or
twice. Spin up helper threads (we can even keep a cache of them) to
handle each group of 64 events, and have them pop an event to the
parent thread once
IIUC - there are -very- few cases where you need a massive
array of poll/select objects, because in most cases it's not
practical with a threaded architecture.
Cases in point; the httpd listen pool, the jni listen pool.
Any other good examples?
I'm thinking we need to start from square one on an
At 12:04 AM 4/19/2005, James Mansion wrote:
Isn't poll on files more a theoretical benefit than actual,
since they always signal as ready?
Surely you must be thinking of disk files, not pipes.
Bill
This makes alot of sense. But we are talking about the need for
large scale parallelism, not discrete events. Once a given unit
of I/O work can be performed on a given socket or pipe, it's going
to be time to farm it out to a worker.
Somewhere in this scheme we need to consider dispatching.
I'd like to modify the Win32 build projects (of mod_jk, and
httpd 1.3/2.0/2.1-dev, along with apr);
The /O2 optimization option is extremely agressive, unfortunately
it produces less than ideal crash traceback information. That
is due to the (implicit) /Oy flag, which omits respecible stack
At 08:46 AM 5/11/2005, Branko Čibej wrote:
All in all - comments?
How about moving away from MSVC 6 to (say) VC.Net 2003, while we're at it?
It's time, to say the least.
Not for 1.3 or 2.0 httpd - you lose some measure of binary
compatibility. We can jump through hoops to continue to use
the
At 04:35 PM 5/11/2005, Branko Čibej wrote:
William A. Rowe, Jr. wrote:
If the open source community tends to push back on Microsoft's
newest compilers, it's simply because their forced treadmill is
the anathema of inclusiveness.
That's what's happening right now with Subversion. The Python 2.4
At 08:29 PM 5/11/2005, Randy Kobes wrote:
That sounds great, but one consideration from the point of
view of Perl (eg, mod_perl) is that the dominant Win32 Perl
binary, from ActiveState, uses VC 6 to compile, and they
don't have any plans soon of changing that. But that might
change by the next
IIUC, if you look, there are groups of status results under
a single case. This is especially true on OS/X and Win32.
But even on unix; consider
/** operation would block */
#if !defined(EWOULDBLOCK) || !defined(EAGAIN)
#define APR_STATUS_IS_EAGAIN(s) ((s) == APR_EAGAIN)
#elif
At 09:20 PM 5/11/2005, Wesley W. Garland wrote:
If I had my fantasy implementation, though, codes like EAGAIN and
EWOULDBLOCK would be merged into one result... but that would
require... well, all factors considered, a time travel machine and way
to encourage cooperation between the USL and BSD
Because nobody added it? (It would be apr_brigade_save).
I'm actually more concerned with adding an apr_brigade_consume;
it's used in the ssl stack already. The fact is that some folks
reading a brigade will simply consume the buckets contained
within, and it's sub-optimal to leave them lying
[I'm answering specifically to apr@ - so that there isn't so much
noise on so many lists :)]
At 12:19 PM 5/12/2005, you wrote:
On the specify compiler version used in builds, I think APR should
compile and pass tests on VC6, 7, 7.1 and 8. I've submitted patches
that also get it compiling
At 12:19 PM 5/12/2005, Curt Arnold wrote:
On the build specification, the VS IDE project files are helpful for
debugging but they are awkward to set up and don't run unit tests,
assemble distributions, etc. To use APR within log4cxx, I've created
Ant scripts to build APR and log4cxx which
At 01:05 PM 5/12/2005, Garrett Rooney wrote:
A while back I had posted the beginnings of a patch to gen_make.py that used
ezt.py to templatize the existing win32 build system, making it automatically
generated. This could easily be extended to generate other types of build
files, if someone
Issue #1; How to manipulate nelts in apr_table_entry?
We can preserve the existing behavior of nelts, defining it as
a simple int. A few casts are required out of the result of some
pointer arithmetic.
The alternative is to use apr_size_t to define nelts, however
that will percolate many
At 09:01 AM 5/17/2005, Joe Orton wrote:
On Mon, May 16, 2005 at 01:39:20PM -0500, William Rowe wrote:
Issue #1; How to manipulate nelts in apr_table_entry?
We can preserve the existing behavior of nelts, defining it as
a simple int. A few casts are required out of the result of some
At 11:24 AM 5/18/2005, Andrew Binstock wrote:
Quick note re:
It's embodied by the patch below - the delta of two pointer
offsets result in a size_t (by definition). On LP64/P64, the
sizeof(int) sizeof(size_t).
That's not the definition of size_t. The delta of
two pointers you're referring
At 09:35 AM 5/18/2005, Joe Orton wrote:
On Wed, May 18, 2005 at 02:41:48AM -0500, William Rowe wrote:
At 09:01 AM 5/17/2005, Joe Orton wrote:
On Mon, May 16, 2005 at 01:39:20PM -0500, William Rowe wrote:
Issue #1; How to manipulate nelts in apr_table_entry?
We can preserve the existing
At 04:17 PM 5/19/2005, Paul Querna wrote:
Mladen Turk wrote:
Hi,
Until multicast support for WIN32 gets enabled, can we
add it to the build, so that at least APR_ENOTIMPL is returned.
Any objections?
I thought the code was all there to do it -- and I do not have the bits
to do the DSP
At 01:22 PM 6/7/2005, Justin Erenkrantz wrote:
--On Tuesday, June 7, 2005 6:16 PM + [EMAIL PROTECTED] wrote:
Sandbox of apr/trunk/ for fips integration. Here may lurk fips issues
(MD5 etc)
Added:
httpd/httpd/branches/fips-dev/srclib/apr/
- copied from r188836, apr/apr/trunk/
I
It seems this type should be changed for 2.0 - may I deprecate
apr_dso_handle_sym_t in favor of apr_dso_sym_t?
Bill
Please, take a quick look and consider this patch.
It fixes BSD in particular, where we pick up bin/libtoolize15 but
grab (or entirely fail to grab) share/aclocal/libtool.m4, as it's
installed as share/aclocal/libtool15.m4.
I missed the other side of this patch, which is to prefer the order
of
Nicholas;
don't use libapr - that refers to 0.9.x and you will undoubtedly
create headaches. Retain libapr-1 if that's the version you mean
to build against.
Use apr-config-1 to query apr for the paths to the library, compile
time variables, etc.
And it appears you might be missing -lc,
At 09:24 AM 6/13/2005, jean-frederic clere wrote:
William A. Rowe, Jr. wrote:
+ ltfindcmd=`sed -n \/=[^\\\`]/p;/libtool_m4=/{s/.*=/echo /p;q;}\ \
+$libtoolize`
+ ltfile=${LIBTOOL_M4-`eval $ltfindcmd`}
+ # Expecting the code above to be very portable, but just in case
At 03:47 PM 6/17/2005, Brian W. Fitzpatrick wrote:
Patch attached.
APR devs, what say ye?
if (!path[0]) {
would be much faster.
Otherwise +1 :)
Bill
At 07:36 AM 6/23/2005, Scott Greig wrote:
Has anyone successfully built apr for win64?
Compiled on win32 targeting win64. If you look to apr's svn
trunk, you will find most every sizeof(void*) sizeof(long)
problem has been squashed.
Please feel free to report any issues you encounter!
Bill
Mladen;
I'd prefer you don't commit this, *yet*. I agree the build
system needs refactoring. But also believe that more cruft in
the tree will only confuse users. And your specific solution
does not lend itself to being maintained, particularly by the
unix hackers in the room :-/
John,
unless you are building only for Win9x (ewww) apr_off_t is
most definitely not an int. It needs to resolve to APR_INT64
or perhaps with gcc, as a long long. Since your patch carries
on the use of the win32 api (and not faux-posix), it most
definitely can use the whole 64 bit file
At 12:27 PM 6/28/2005, Mladen Turk wrote:
William A. Rowe, Jr. wrote:
Question; do we want to adopt (finish adopting) svn's build
system coded in python?
Are you guys saying that I would need a python to even
consider to build a APR from the cvs/svn?
This is true *today* for everyone except
901 - 1000 of 3066 matches
Mail list logo
