On Tue, 2010-03-09 at 15:45 -0600, Hyrum K. Wright wrote:
> We also have a couple of hash- and array-based iteration functions
> which might be handy. I can post those if there is interest.
Yep, let's raid the SVN treasure chest :-)
--
Bojan
On Mar 9, 2010, at 2:42 PM, Bojan Smojver wrote:
> On Tue, 2010-03-09 at 12:48 -0500, Jeff Trawick wrote:
>> IMO these functions are a natural addition; any concerns from the
>> crowd?
>
> Didn't SVN folks also have some hash sorting functions we could "borrow"
> as well? May as well get those,
On 3/9/2010 3:37 PM, Hyrum K. Wright wrote:
>
> I'm also planning a followup which const-ifies the apr_hash_index_t params to
> these functions, as well as apr_hash_this(). Thoughts?
Note const'ness will only be alterable with apr 2.0 forwards.
I'm eyeballs to alligators here, so I won't have
On Mar 9, 2010, at 2:00 PM, William A. Rowe Jr. wrote:
> On 3/9/2010 11:48 AM, Jeff Trawick wrote:
>> On Tue, Mar 9, 2010 at 11:19 AM, Hyrum K. Wright
>> wrote:
>>> In using the apr_hash datastructure in Subversion, we've found that we
>>> often only want the key or value from a hash. Furthermo
On Tue, 2010-03-09 at 12:48 -0500, Jeff Trawick wrote:
> IMO these functions are a natural addition; any concerns from the
> crowd?
Didn't SVN folks also have some hash sorting functions we could "borrow"
as well? May as well get those, while we're at it :-)
--
Bojan
On 3/9/2010 11:48 AM, Jeff Trawick wrote:
> On Tue, Mar 9, 2010 at 11:19 AM, Hyrum K. Wright
> wrote:
>> In using the apr_hash datastructure in Subversion, we've found that we
>> often only want the key or value from a hash. Furthermore, casting
>> the various return parameters has proven cumbers
On Tue, Mar 9, 2010 at 11:19 AM, Hyrum K. Wright
wrote:
> In using the apr_hash datastructure in Subversion, we've found that we
> often only want the key or value from a hash. Furthermore, casting
> the various return parameters has proven cumbersome. To solve this
> problem, we've introduced t
In using the apr_hash datastructure in Subversion, we've found that we
often only want the key or value from a hash. Furthermore, casting
the various return parameters has proven cumbersome. To solve this
problem, we've introduced three helper functions to return the key,
key length, and value fr
On 09 Mar 2010, at 4:53 PM, William A. Rowe Jr. wrote:
In theory, when people try apr v1.5 for the first time, we're likely
to find out. I suspect it may be worth assuming support is present,
and then if it turns out that a platform that is still used doesn't
support it, we can then reintroduce
On 09 Mar 2010, at 1:46 PM, Jeff Trawick wrote:
Hmmm - in that case it may make sense to drop the ifdef entirely,
and if a
unix platform is found to not support O_BLOCK, we can then make a
call then
as what to do. The ifdef could in theory be solving a problem we
don't have.
I mis-worded
On 03/09/2010 03:42 PM, jfcl...@apache.org wrote:
Author: jfclere
Date: Tue Mar 9 14:42:23 2010
New Revision: 920897
URL: http://svn.apache.org/viewvc?rev=920897&view=rev
Log:
typos? Otherwise it won't compile.
Since APR 2 won't support Win95, IMO the entire
WIN_OS_IS_ANSI and UNICODE_FS sho
On 08 Mar 2010, at 10:53 PM, Jeff Trawick wrote:
Hmmm, the existing code follows this pattern, as below, and if we
decide to
change the pattern then we need to change this behaviour throughout
the rest
of the code, and probably the rest of APR too.
For APR_FOPEN_NONBLOCK, if the caller ask
On Tue, Mar 9, 2010 at 6:43 AM, Graham Leggett wrote:
> On 08 Mar 2010, at 10:53 PM, Jeff Trawick wrote:
>
>>> Hmmm, the existing code follows this pattern, as below, and if we decide
>>> to
>>> change the pattern then we need to change this behaviour throughout the
>>> rest
>>> of the code, and p
On 3/9/2010 5:52 AM, Graham Leggett wrote:
> On 09 Mar 2010, at 1:46 PM, Jeff Trawick wrote:
>
>>> Hmmm - in that case it may make sense to drop the ifdef entirely,
>>> and if a
>>> unix platform is found to not support O_BLOCK, we can then make a
>>> call then
>>> as what to do. The ifdef could in
On 08 Mar 2010, at 11:26 PM, Joe Orton wrote:
APR_FOPEN_LARGEFILE is intended to be (and is documented as)
"advisory"
rather than mandatory.
Exposing a NONBLOCK flag without attaching *any* semantics to it
w.r.t.
subsequent read/write calls seems completely wrong. If you want
platform-spe
15 matches
Mail list logo
