Re: mod_brotli in 2.4.x is missing a few Makefile changes

On Apr 30, 2017 12:27 PM, "Jan Ehrhardt" wrote: Gregg Smith in gmane.comp.apache.devel (Sun, 30 Apr 2017 08:54:34 -0700): >On 4/30/2017 5:36 AM, Jan Ehrhardt wrote: > >> The problem with CMake is that it does not build all things, that AL and >> AH put in their distributions.

Re: 1.6.0 release candidates

On Apr 29, 2017 7:24 AM, "Nick Kew" <n...@apache.org> wrote: On Fri, 2017-04-28 at 11:35 -0500, William A Rowe Jr wrote: > ./configure --enable-timedlocks > > Right off the bat we find new rpm hokum in our configure; Where does the rpm_share come from? Isn't t

Re: 1.6.0 release candidates

On Wed, Apr 26, 2017 at 4:07 AM, Nick Kew wrote: > > A minimalist approach is Good. But when you say minimalist, do you > mean minimalist efforts as in "this should work out-of-the-box" > or minimalist efforts as in a README.platform? Are we likely > looking at more code

Re: Request for additional installbuilddir exports

On Apr 27, 2017 13:00, "Jacob Champion" <champio...@gmail.com> wrote: On 04/26/2017 11:58 AM, William A Rowe Jr wrote: > On Wed, Apr 26, 2017 at 12:28 PM, Jacob Champion <champio...@gmail.com> > wrote: > >> Over at httpd I'm trying to engineer >> a

Re: Request for additional installbuilddir exports

On Wed, Apr 26, 2017 at 12:28 PM, Jacob Champion wrote: > > Sorry for the post-1.6 timing on this. Because of the withdrawal of 1.6.0 I think there is no problem making changes in the API with 1.6.1. If we had released it... but even still... > Over at httpd I'm trying to

Re: 1.6.0 release candidates

On Thu, Apr 20, 2017 at 12:36 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > Couple issues tunneling into my AIX/HPUX boxes. ppc64 RHEL 5 linux looks good, > at least, passes all tests, sysv sem timed locks discovered. Hopefully > able to test in the next day or few. With

Re: 1.6.0 release candidates

Couple issues tunneling into my AIX/HPUX boxes. ppc64 RHEL 5 linux looks good, at least, passes all tests, sysv sem timed locks discovered. Hopefully able to test in the next day or few. On Wed, Apr 19, 2017 at 1:43 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > With patches now

Re: 1.6.0 release candidates

With patches now accounted for I can pre-test and report back today on AIX, HPUX and propose a fix to silence the win32 32 -> 16 bit warnings (after division is done.) But my inclination is to defer this new feature to a later 1.7+2.0 release. Shipping a feature that devs would expect to need

Re: 1.6.0 release candidates

On Mon, Apr 17, 2017 at 11:06 AM, Nick Kew wrote: > On Mon, 2017-04-17 at 14:01 +0200, Rainer Jung wrote: > > Thanks for the comments. > >> my test results: most important is failure to compile on Solaris 8 and a >> hang during make test on Solaris 10, as well as your key seeming

Re: Et resurrexit tertia die.

On Mon, Apr 10, 2017 at 8:35 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > There is a fix for the appearance of offline resources on Windows as > symlinks, only junctions and symlinks to first and files should have > appeared as symlinks Before I wrap up for the we

Re: Et resurrexit tertia die.

If you svn checkout with crlf lineends rather than native, and zip -X (no need for Unix attribs) you have that package generated on a Unix box. On Apr 13, 2017 3:08 AM, "Nick Kew" wrote: > On Mon, 2017-04-10 at 10:40 +0100, Nick Kew wrote: > > I think we've done most of 1.6.0,

Re: svn commit: r1790911 - in /apr/apr-util/branches/1.6.x: aprutil.dep aprutil.mak libaprutil.mak

On Tue, Apr 11, 2017 at 5:42 PM, Gregg Smith <g...@gknw.net> wrote: > On 4/11/2017 3:11 PM, William A Rowe Jr wrote: >> >> On Mon, Apr 10, 2017 at 10:46 PM, <gsm...@apache.org> wrote: >>> >>> Author: gsmith >>> Date: Tue Apr 11 03:

Re: svn commit: r1790911 - in /apr/apr-util/branches/1.6.x: aprutil.dep aprutil.mak libaprutil.mak

On Mon, Apr 10, 2017 at 10:46 PM, wrote: > Author: gsmith > Date: Tue Apr 11 03:46:02 2017 > New Revision: 1790911 > > URL: http://svn.apache.org/viewvc?rev=1790911=rev > Log: > remove dbd_freetds from .mak/dep I don't use it, but know it compiled at one time. What's the

Re: svn commit: r1790490 - in /apr/apr/branches/1.6.x: ./ include/ include/arch/unix/ locks/beos/ locks/netware/ locks/os2/ locks/unix/ locks/win32/ test/

On Apr 10, 2017 04:04, "Nick Kew" wrote: On Fri, 2017-04-07 at 16:31 +0200, Yann Ylavic wrote: > > Or are apr_{thread,proc,global}_mutex_timedlock() new to APR 1.6 and are not part of 1.5.x and before? > > Yes that's the case (new to 1.6, not in 1.5), so no possible > regression

Re: Et resurrexit tertia die.

Agreed across the board. 1 has fixes and concensus, 2-4 can be fixed in 2.0. There is a fix for the appearance of offline resources on Windows as symlinks, only junctions and symlinks to first and files should have appeared as symlinks, I will address that state by Tues Eve. Will be checking the

Re: svn commit: r1790296 - /apr/apr/trunk/locks/unix/proc_mutex.c

On Fri, Apr 7, 2017 at 11:07 AM, Yann Ylavic wrote: > On Fri, Apr 7, 2017 at 4:33 PM, Jim Jagielski wrote: >> >>> On Apr 7, 2017, at 9:53 AM, Branko Čibej wrote: >>> >>> On 07.04.2017 14:38, Jim Jagielski wrote: You are assuming

Re: svn commit: r1790296 - /apr/apr/trunk/locks/unix/proc_mutex.c

On Apr 6, 2017 3:34 PM, "Jim Jagielski" wrote: > On Apr 6, 2017, at 4:25 PM, Jacob Champion wrote: > > > A zero or negative timeout should attempt to instantaneously acquire, and return TIMEUP immediately if that's not possible. Treating negative

Re: svn commit: r1790296 - /apr/apr/trunk/locks/unix/proc_mutex.c

On Apr 5, 2017 1:42 PM, "William A Rowe Jr" <wr...@rowe-clan.net> wrote: How is now an int? Nevermind, reading too quickly. Sorry.

Re: svn commit: r1790296 - /apr/apr/trunk/locks/unix/proc_mutex.c

How is now an int? Wouldn't that be an apr_time_t (much too big to fit in an int on an LP64 arch.) On Apr 5, 2017 12:25 PM, "Yann Ylavic" wrote: > On Wed, Apr 5, 2017 at 7:14 PM, Jim Jagielski wrote: > > Your log is: > > > >Follow up to r1667900:

Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x: locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c

On Wed, Apr 5, 2017 at 9:17 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Wed, Apr 5, 2017 at 8:57 AM, Nick Kew <n...@apache.org> wrote: >> On Wed, 2017-04-05 at 08:11 -0500, William A Rowe Jr wrote: >> >>> > Maybe we should reconsider the who

Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x: locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c

On Wed, Apr 5, 2017 at 8:57 AM, Nick Kew <n...@apache.org> wrote: > On Wed, 2017-04-05 at 08:11 -0500, William A Rowe Jr wrote: > >> > Maybe we should reconsider the whole idea of timedlocks?? >> >> Without throwing them out wholesale, in the intere

Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x: locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c

On Wed, Apr 5, 2017 at 8:22 AM, Jim Jagielski wrote: > As noted in a previous thread regarding the values of timeouts > related to the 3 major timedwait() canon implementations, I'm not > exactly sure how well thought out and tested these are. Putting > them in 1.6 means that

Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x: locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c

On Wed, Apr 5, 2017 at 6:46 AM, Jim Jagielski wrote: > >> On Apr 5, 2017, at 6:39 AM, Yann Ylavic wrote: >> >> >> Agreed, there seems to be few (if any) alternatives, though, but: >> avoid using apr_proc/global_mutex_timedlock() on OSX is recommended. >>

Re: Default Linux mutex method

On Mon, Apr 3, 2017 at 5:00 PM, Yann Ylavic <ylavic@gmail.com> wrote: > On Mon, Apr 3, 2017 at 9:24 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > >> Given that we didn't elect PROC_PTHREAD mutexes as an alternate >> _USE_ schema, I don't have a

Re: Default Linux mutex method

On Mon, Apr 3, 2017 at 2:06 PM, Jim Jagielski wrote: > Considering the sad affair w/ pthread on OSX, I would > recommend we stay w/ using sems. For darwin (and other BSD? or do they still fcntl?), agreed 100%. Linux seems to be in a completely different state of affairs.

Re: Default Linux mutex method

On Mon, Apr 3, 2017 at 5:05 AM, Yann Ylavic wrote: > > Yes I got this, my point is that there are no duplicates here, one and > only one per: > - pthread mutex => PTHREAD_SERIALIZE (kind of implicit since all > unixes use pthreads, but not to be confused with >

Re: Default Linux mutex method

On Apr 1, 2017 4:07 AM, "Yann Ylavic" <ylavic@gmail.com> wrote: On Fri, Mar 31, 2017 at 4:21 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > So almost two decades later, this is still odd. > > apr.h:#define APR_USE_SHMEM_MMAP_TMP 0 > apr.h:#define AP

Re: Default Linux mutex method

On Fri, Mar 31, 2017 at 10:22 AM, Jim Jagielski wrote: > Reading the configure.in file, it looks like we are due > for some updates for the 21st century: > > # See which lock mechanism we'll select by default on this system. > # The last APR_DECIDE to execute sets the default. >

Re: apr_file_copy with APR_FILE_SOURCE_PERMS not copying permissions if destination already exists

On Fri, Mar 31, 2017 at 10:04 AM, Nick Kew <n...@apache.org> wrote: > >> On 30 Mar 2017, at 15:59, William A Rowe Jr <wr...@rowe-clan.net> wrote: >> >> I'd suggest we treat it as a bug, change the behavior accordingly in 1.6.0, >> and @bug the API to ind

Default Linux mutex method

So almost two decades later, this is still odd. apr.h:#define APR_USE_SHMEM_MMAP_TMP 0 apr.h:#define APR_USE_SHMEM_MMAP_SHM 0 apr.h:#define APR_USE_SHMEM_MMAP_ZERO0 apr.h:#define APR_USE_SHMEM_SHMGET_ANON 0 apr.h:#define APR_USE_SHMEM_SHMGET 1 apr.h:#define

Re: apr_file_copy with APR_FILE_SOURCE_PERMS not copying permissions if destination already exists

On Thu, Mar 30, 2017 at 11:30 AM, Nick Kew <n...@apache.org> wrote: > On Thu, 2017-03-30 at 09:59 -0500, William A Rowe Jr wrote: > >> > Is this the expected behaviour? should documentation warn that if the >> > destination already exists, then permi

Re: apr_file_copy with APR_FILE_SOURCE_PERMS not copying permissions if destination already exists

On Thu, Mar 30, 2017 at 8:55 AM, Fernando Vicente wrote: > > apr_file_copy does not copies permissions from source if the destination > already exists, even when the flag APR_FILE_SOURCE_PERMS is set. > I made a quick test by creating 3 files with the following permissions: >

Re: 1.6 release timetable

On Thu, Mar 23, 2017 at 1:01 PM, Nick Kew wrote: > On Thu, 2017-03-23 at 10:13 -0700, Gregg Smith wrote: > >> My retro build changes and Jan's revised patch have been commited. >> Windows should be good to go. > > Brilliant, thanks both. +1 > I'll take the activity on this

Re: LARGEFILE test broken?

I really don't understand what we meant to accomplish on Unix, it was before I was proficient on that platform. AIUI it meant apr_off_t was large enough to hold my file pointer, which was how it was implemented on Win32. We explicitly used a 64 bit type to ensure files were addressable. As I've

Re: Where do ./build/rules.mk come from in apr-util?

The origin of that file is the apr-1.5.2... this is how you or your distributor had built the underlying apr library, and the flags must (mostly) match. In your case, you may be safe to simply change that to "CPPFLAGS=" if all other settings are correct. Note this is a debugging build with no

Re: expat upgrade patch to 2.2.0

On Mon, Feb 13, 2017 at 11:25 AM, Nick Kew wrote: > On Mon, 2017-02-13 at 08:35 -0800, Luke Perkins wrote: >> Stefen, >> >> I submitted a patch request to the APR README regarding the TARBALL vs. SVN >> versions of the source file a couple of weeks ago. I have not heard back >>

Re: [PATCH] deadlocking condition with APR_HAS_THREADS

If you don't re-join your threads to the parent thread, I can't say I believe that this represents a bug. But that's just my 2c from the original architecture. On Feb 8, 2017 4:30 PM, "Stefan" wrote: > On 2/2/2017 14:45, Branko Čibej wrote: > > On 02.02.2017 13:30, Stefan

Re: apr-util error code

On Thu, Jan 19, 2017 at 11:40 AM, Branko Čibej <br...@apache.org> wrote: > On 19.01.2017 18:30, Dirk-Willem van Gulik wrote: >> On 19 Jan 2017, at 17:46, William A Rowe Jr <wr...@rowe-clan.net> wrote: >> >>> In 2.0 I'd like to see include/apu_error.h simply a

Re: apr-util error code

In 2.0 I'd like to see include/apu_error.h simply a stub to #include and track it all in one place. Will try to hold onto that though for my next round tuit. It makes the back porting of new apu_errno.h constants a bit trickier but hardly impossible. ITMT, your proposal looks fine Dirk. On

Re: Right magic to test the crypto modules

I think an LD_LIBRARY_PATH dance might be simplest? We try both the path/ and the path/apr-#/ locations. On Wed, Jan 18, 2017 at 4:14 PM, Dirk-Willem van Gulik wrote: > What is the right/proper way to test the crypto modules (as they are not > copied into apr/.lib during a

Re: URL fetch functionality

On Tue, Jan 17, 2017 at 12:11 AM, Ivan Zhakov <i...@visualsvn.com> wrote: > On 17 January 2017 at 03:25, William A Rowe Jr <wr...@rowe-clan.net> wrote: >> On Jan 16, 2017 06:08, "Dirk-Willem van Gulik" <di...@webweaving.org> wrote: >>> >>> I’

Re: URL fetch functionality

It was called serf. It never entered ASF proper, but it is still out there (not sure if Justin moved it from Google code or not.) On Jan 16, 2017 06:08, "Dirk-Willem van Gulik" wrote: > I’ve got a few modules that I am trying to merge that all do a bit of > simple HTTP get

Re: thread-saftey memory pools

The reason is that each thread can obtain its own distinct and therefore safe allocator. The model is such that when the thread for finishes a unit of work, it returns the memory to the thread's allocator for the next unit of work. The alternative is the malloc/free model which you are used to,

Re: testpoll

On Wed, Jan 11, 2017 at 2:51 PM, Jim Jagielski wrote: > It looks like it is taking time for the message to > arrive and that is what is causing the APR_EINTR. After > all, it is behaving exacting like a wait for no data. > The apr_sleep() "ensures" time. But isn't -1 'infinite'

Re: testpoll

this is a general unix implementation bug or specific to OSX behavior. On Wed, Jan 11, 2017 at 7:22 AM, Jim Jagielski <j...@jagunet.com> wrote: > > On my system, poll works. > > > On Jan 10, 2017, at 3:15 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > > &g

Re: Supported Windows versions for APR 2.0 (was Re: [PATCH] Optimizeapr_file_info_get(APR_FINFO_SIZE) on Windows)

On Thu, Dec 29, 2016 at 9:34 AM, Branko Čibej <br...@apache.org> wrote: > On 26.12.2016 19:16, William A Rowe Jr wrote: >> Unfortunately Windows doesn't in any sensible way... AFAIK and please >> correct me if I'm wrong, there is still no strateful/resumable stream >

Re: 1.6 apr/apr-util scope/timetable?

On Sat, Dec 24, 2016 at 1:23 AM, Ivan Zhakov wrote: > > Regarding my current problem: I'm getting the following when I attempt > to build expat: > [[[ > runtestspp.obj : error LNK2019: unresolved external symbol > _align_limit_to_full_utf8_characters referenced in function

Re: Supported Windows versions for APR 2.0 (was Re: [PATCH] Optimizeapr_file_info_get(APR_FINFO_SIZE) on Windows)

API. And of course with FnA() it was always fun speculating if that call used OEM CP or locale CP. :) On Dec 24, 2016 02:52, "Branko Čibej" <br...@apache.org> wrote: > On 22.12.2016 18:21, William A Rowe Jr wrote: > > What I'd like us to consider is to rip out

Re: Supported Windows versions for APR 2.0 (was Re: [PATCH] Optimizeapr_file_info_get(APR_FINFO_SIZE) on Windows)

d see if we can address any concerns. --- Original message --- > *Subject:* Supported Windows versions for APR 2.0 (was Re: [PATCH] > Optimizeapr_file_info_get(APR_FINFO_SIZE) on Windows) > *From:* Ivan Zhakov <i...@visualsvn.com> > *To:* William A Rowe Jr <wr...@rowe-clan.net

Re: 1.6 apr/apr-util scope/timetable?

On Dec 20, 2016 22:50, "William A Rowe Jr" <wr...@rowe-clan.net> wrote: Ensure we build well with distributing expat. *without* (sorry - please excuse tablet keyboard.)

Re: 1.6 apr/apr-util scope/timetable?

On Nov 30, 2016 23:23, "William A Rowe Jr" <wr...@rowe-clan.net> wrote: Is there anything holding up the jumps to 1.6, or 2.0? I'd personally like to see an API harmonising memcache to redis, but that can't possibly be a showstopper to any incremental release. What other a

Re: [PATCH] Optimize apr_file_info_get(APR_FINFO_SIZE) on Windows

On Sun, Dec 18, 2016 at 11:30 AM, Ivan Zhakov <i...@visualsvn.com> wrote: > On 17 December 2016 at 21:47, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > > As 1.6 is unreleased, whatever goes in trunk that does -not- break > backwards > > binary

Re: [PATCH] Optimize apr_file_info_get(APR_FINFO_SIZE) on Windows

the proposal is under debate/discussion. On Dec 17, 2016 10:23 AM, "Ivan Zhakov" <i...@visualsvn.com> wrote: > On 17 December 2016 at 10:56, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > On Sat, Dec 17, 2016 at 1:43 AM, Ivan Zhakov <i...@visualsvn.co

Re: [PATCH] Optimize apr_file_info_get(APR_FINFO_SIZE) on Windows

On Sat, Dec 17, 2016 at 1:43 AM, Ivan Zhakov wrote: > On 24 August 2016 at 20:34, Ivan Zhakov wrote: > > I was monitoring Subversion server I/O on Windows and noticed that > > apr_file_info_get(APR_FINFO_SIZE) involves two syscalls > >

Re: 1.6 apr/apr-util scope/timetable?

On Sat, Dec 17, 2016 at 1:34 AM, Ivan Zhakov <i...@visualsvn.com> wrote: > On 3 December 2016 at 18:40, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > On Sat, Dec 3, 2016 at 6:00 AM, Ivan Zhakov <i...@visualsvn.com> wrote: > >> 1. Currently apr 1.6.x d

Re: configure.in: cross-compile

On Tue, Dec 13, 2016 at 9:30 PM, Dengke Du wrote: > Hi all > > When apr used in cross-compile, it pass 8 bytes to ac_cv_sizeof_off_t by > the following: > > APR_CHECK_SIZEOF_EXTENDED([#include ], off_t, 8) > > at the line 1789 in configure.in > > But when the target

Re: svn commit: r1772803 - in /apr/apr/trunk: CHANGEScrypto/crypt_blowfish.c

On Mon, Dec 5, 2016 at 4:38 PM, wrote: > Doesn’t this simple patch break all existing hashes for the existing type? > > No, only those exceeding an absurd number of iterations. 31 iterations takes over a day of CPU at 3Ghz. Perhaps this breakage is safe for 2.0, but perhaps

Re: 1.6 apr/apr-util scope/timetable?

pair at the moment but there's > time. > > [3]https://www.apachehaus.net/misc/wamps.txt > > > > On 03.12.2016 16:40, William A Rowe Jr wrote: > >> I'm wondering, where do we go on trunk with 2.0 on Windows, >>> now that we can emit solution/project files from CMake, or just >>> straightforward .mak files? It insisting on a local install of CMake >>> all that much of a hassle for the Windows build machine? >>> >> >

Re: 1.6 apr/apr-util scope/timetable?

On Sat, Dec 3, 2016 at 6:00 AM, Ivan Zhakov wrote: > > 1. Currently apr 1.6.x doesn't build on Windows using makefiles: > [[[ > link.exe @C:\Users\ivan\AppData\Local\Temp\nm2BCE.tmp >Creating library .\x64\Release\libapr-1.lib and object > .\x64\Release\libapr-1.exp >

Re: Random AH01842 errors in mod_session_crypto

On Fri, Dec 2, 2016 at 4:28 PM, Yann Ylavic wrote: > On Fri, Dec 2, 2016 at 10:06 PM, Yann Ylavic wrote: > > On Wed, Oct 5, 2016 at 12:23 PM, Yann Ylavic > wrote: > >> > >> Patch attached, WDYT? > > > > Ping, probably is worth

Re: Random AH01842 errors in mod_session_crypto

On Fri, Dec 2, 2016 at 3:06 PM, Yann Ylavic wrote: > On Wed, Oct 5, 2016 at 12:23 PM, Yann Ylavic wrote: > > > > Patch attached, WDYT? > > Ping, probably is worth considering for 1.6 (even 1.5) ? > Provided you don't *break* the API contract with

Re: 1.6 apr/apr-util scope/timetable?

On Wed, Nov 30, 2016 at 11:23 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > Even as httpd is operating under paralysis by analysis, we are long past a > year since the last releases. > > Is there anything holding up the jumps to 1.6, or 2.0? > > I'd perso

Re: 1.6 apr/apr-util scope/timetable?

On Thu, Dec 1, 2016 at 2:09 AM, Nick Kew <n...@apache.org> wrote: > > > On 1 Dec 2016, at 04:23, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > > > Even as httpd is operating under paralysis by analysis, we are long past > a year since the last releases.

1.6 apr/apr-util scope/timetable?

Even as httpd is operating under paralysis by analysis, we are long past a year since the last releases. Is there anything holding up the jumps to 1.6, or 2.0? I'd personally like to see an API harmonising memcache to redis, but that can't possibly be a showstopper to any incremental release.

Re: debug patch (was FOSSA)

Better to limit the individual %s args to ensure the entire string fits in the allocated 1024 char buffer than switch to snprintf, IMO. These are fn name constants, etc that can't conceivably overflow in the first place. On Nov 16, 2016 19:24, "Dirk-Willem van Gulik" wrote:

Re: Redis and mod_cache/mod_socache

On Wed, Nov 2, 2016 at 1:11 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > But we've succeeded in keeping all of these components and their > library dependencies out of the process map for all apr-consuming > apps which don't invoke these API's... > >

Re: Redis and mod_cache/mod_socache

On Mon, Oct 31, 2016 at 10:49 AM, Graham Leggett wrote: > On 31 Oct 2016, at 5:05 PM, Jim Jagielski wrote: > > > Moving to APR: > > > > Query: Think it would be worth my time to work on a Redis > > implementation for APR-util? I am working on a minimal Redis

Re: expat upgrade to 2.1.0

On Sun, Nov 1, 2015 at 12:59 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Sun, Nov 1, 2015 at 12:16 PM, Graham Leggett <minf...@sharp.fm> wrote: > >> On 31 Oct 2015, at 7:48 PM, Michael Felt <mamf...@gmail.com> wrote: >> >> > I would l

Re: Talking json

That's what mod_bmx emits. Aaron Bannert built it with an extensible key:value bean schema. It implemented mod_status data and extended it for virtual host data collection. AL 2.0, have a look, he is still on this channel mostly lurking if you have questions :) If you need to parse json,

Re: [PATCH] Add support for IP_FREEBIND sockopt (PR58725)

Sources written for 1.5.3 would no longer be source compatible with 1.5.2, so this is a change for 1.6.0. I've seen no objection to apr_cstr (another we cannot backport to 1.5.x), so I'll backport that this morning and get us a little closer to being ready to tag and release 1.6.0. Bill On Thu,

Re: [PATCH] Add support for IP_FREEBIND sockopt (PR58725)

>From http://apr.apache.org/versioning.html... "Versions are denoted using a standard triplet of integers: *MAJOR.MINOR.PATCH*. The basic intent is that *MAJOR* versions are incompatible, large-scale upgrades of the API. *MINOR* versions retain source and binary compatibility with older minor

Win32 APR cannot have threads disabled (was Re: log4cxx-0.10.0 and crash on exit)

On Tue, Mar 1, 2016 at 11:33 AM, Sean Dynan wrote: > > I thought APR defaults to multithreaded on Windowsa all the apr.h* files > > You are absolutely right. apr.h is auto-generated by the build process > so, naturally, Visual Studio totally ignores it during file searches >

Re: Mailing list semantics

I tally 9 +1 to change to default reply-all semantics, and one +/-0 ENOCARE vote. No votes against. Jeff, would you care to execute the decision with a jira ticket for apmail, or would you like me to execute? Cheers, Bill On Wed, Jan 27, 2016 at 10:08 PM, William A Rowe Jr <wr...@r

Is 1.4.x deprecated? (Was: svn commit: r1728973 - in /apr/apr-util/branches/1.4.x: ./ CHANGES)

On Sun, Feb 7, 2016 at 8:47 AM, wrote: > > Backport of r1728971 from 1.5.x. > > Modified: > apr/apr-util/branches/1.4.x/ (props changed) > apr/apr-util/branches/1.4.x/CHANGES > Is 1.4.x maintained? The release of 1.5.x introduced an ABI-compatible replacement of

Re: Mailing list semantics

On Wed, Jan 27, 2016 at 10:08 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > [] Keep reply-to-poster default reply semantics > [X] Change to reply-to-list default reply semantics > Easy choice, but I lived with the old solution under the now abandoned Thunderbird -

Mailing list semantics

I know we are facing an org-wide change of MLA's, but in the meantime... It's been debated a number of times in the past (far, long distant past) but @apr lists operate disjointly with other projects, httpd for certain, unknown how subversion is currently configured. At least three significant

Re: apr_token_* conclusions

On Wed, Jan 27, 2016 at 10:11 PM, Branko Čibej wrote: > > > > Stating that equivalent-case are treated as equal states that the > > code points "A"-"Z" are all treated as equal, and "a"-"z" are all > > treated as equal (and "A" and "a" would be treated as unique > > of one

Re: apr_token_* conclusions

On Wed, Jan 27, 2016 at 6:29 AM, Jim Jagielski wrote: > > > On Jan 27, 2016, at 4:44 AM, Branko Čibej wrote: > > > > > > Hmph, it's concise, not confusing. Subversion's APIs expect all strings > > to be encoded in UTF-8, so the docstring can't just say > >

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Thu, Jan 21, 2016 at 4:18 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > This is as far as I got on my last iteration, electing what appear > to be 'normal string' handling functions that are part of svn. > > Based on apr's short-name preference, I had yet to redecorate

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

har from *sep* as a token separator. Separators at the beginning of *str* will be skipped. Returns a pointer to the beginning of the first token in **str* or NULL if no token is left. Modifies *str* such that the next call will return the next token. NoteThe content of **str* may be modified by thi

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Tue, Jan 26, 2016 at 5:16 PM, Jim Jagielski <j...@jagunet.com> wrote: > > > On Jan 26, 2016, at 4:39 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > > > On Tue, Jan 26, 2016 at 3:12 PM, Jim Jagielski <j...@jagunet.com> wrote: > > I'm

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

No time to respond until pressing $dayjob stuff is finished this evening, but I have the entire day tomorrow to devote to bringing the proposed change to trunk/ and proposing for backport to branches/1.6/ On Thu, Jan 21, 2016 at 10:47 AM, Jim Jagielski wrote: > Any updates on

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Thu, Jan 21, 2016 at 4:18 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > Based on apr's short-name preference, I had yet to redecorate > these functions as apr_cstr_* functions, but that I will get to > tomorrow. If you see something that doesn't fall into t

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

that doesn't fall into the normal string / general purpose criteria, feel free to holler before the first commit... Bill On Thu, Jan 21, 2016 at 4:07 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > No time to respond until pressing $dayjob stuff is finished this evening, > but I have th

Re: binary protocol/sasl with apr_memcache

On Fri, Jan 8, 2016 at 9:35 AM, Jeffrey Crowell wrote: > Hi, > > I'm looking to use aprutil to interface with sasl + memcached so that the > memcached can live in a "hostile network". > > I don't see any support for the binary protocol, which is required for > sasl. >

EBCDIC bug(s?) in our apr-util//crypto/crypt_blowfish.c implementation

This doesn't look good. Does an EBCDIC architecture fan want to whip up the fix? static char *BF_crypt(const char *key, const char *setting, char *output, int size, BF_word min) { ... static const unsigned char flags_by_subtype[26] = {2, 0, 0, 0, 0, 0, 0, 0,

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

> > On Nov 26, 2015 08:39, "William A Rowe Jr" <wr...@rowe-clan.net> wrote: > >> Sounds right... Actually a fusion between svn_cstring_* and several >> existing ap_ and apr_ functions would be useful. >> >> SVN folk, any objection to A

Re: [PATCH] Prevent huge pool allocations for small requests.

On Mon, Dec 21, 2015 at 5:42 PM, Stefan Fuhrmann wrote: > > The problem is that those huge nodes are kept under > index 0, so the limiter code of r1594729 will not kick > in if the apr_allocator_t.free array is empty because > max_index is 0 in that case. > > Also, it would

Re: [PATCH] APR hash documentation

Same question again, is this an apr or svn behavior change? On Mon, Dec 21, 2015 at 4:45 PM, Stefan Fuhrmann wrote: > On 11.12.2015 11:32, Bert Huijben wrote: > >> >> >> -Original Message- >>> From: Stefan Fuhrmann [mailto:stef...@apache.org] >>> Sent: donderdag 10

Re: apr_hash_overlay returns hash with duplicate keys

Which public API, APR's or svn's? On Dec 10, 2015 11:24 AM, "Ivan Zhakov" wrote: > On 10 December 2015 at 20:20, Julian Foad wrote: > > Ivan Zhakov wrote: > >> On 10 December 2015 at 19:14, Julian Foad > wrote: > >>> APR devs,

Re: why apr_arch_utf8.h does not use extern "C" to export symbols for C++ user

Yes, because include/arch/ and include/private were always intended to be private details and those headers are not going to be installed by default when you 'make install'. Since then it seems there are a lot of consumers of these sorts of headers, I believe tcnative needs a few of these. If we

Re: apr_token_* conclusions

The only question in my mind, after thinking about this all day, is how do we (plural) de-escalate this immature behaviour between senior ASF members? If there was a time to fall on your own katana James, that most recent post was it. Let's cut the s* and just code some cool stuff? If you are

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

That describes the 'token' use case, right? While MMX operands let the clib devs play with 16-byte/dword/word units, we are principally looking at very short strings. As soon as you do a 16 byte compare w/delimiting the null byte, your optimization is lost. I think we are of one mind on this,

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

Better if I address this Q to svn folks at the APR project :) On Nov 26, 2015 08:39, "William A Rowe Jr" <wr...@rowe-clan.net> wrote: > Sounds right... Actually a fusion between svn_cstring_* and several > existing ap_ and apr_ functions would be useful. > > SV

Re: apr_token_* conclusions

On Nov 26, 2015 11:03 AM, "Branko Čibej" <br...@apache.org> wrote: > > On 26.11.2015 15:44, William A Rowe Jr wrote: > > Better if I address this Q to svn folks at the APR project :) > > On Nov 26, 2015 08:39, "William A Rowe Jr" <wr...@rowe-cla

Re: apr_token_* conclusions

On Thu, Nov 26, 2015 at 7:49 PM, Branko Čibej <br...@apache.org> wrote: > On 26.11.2015 22:55, William A Rowe Jr wrote: > > On Nov 26, 2015 11:03 AM, "Branko Čibej" <br...@apache.org> wrote: > >> On 26.11.2015 15:44, William A Rowe Jr wrote: >

Fwd: apr_token_* conclusions (was: Better casecmpstr[n]?)

Some further analysis... -- Forwarded message -- From: William A Rowe Jr <wr...@rowe-clan.net> Date: Wed, Nov 25, 2015 at 9:44 PM Subject: Re: apr_token_* conclusions (was: Better casecmpstr[n]?) To: httpd <d...@httpd.apache.org> On Wed, Nov 25, 2015 at 6:45 PM, Wi

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Wed, Nov 25, 2015 at 9:44 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > LANG="ku_TR.iso88599"; >64 = @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ > ^ @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`ABCDEFGHİJKLMNOPQRSTUVWXYZ{|}~ > v

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Nov 25, 2015 12:00, "Mikhail T." <mi+t...@aldan.algebra.com> wrote: > > On 25.11.2015 12:42, William A Rowe Jr wrote: >> >> If the script switches setlocale to turkish, for example, our forced-lowercase content-type conversion >> will cause "IMAGE

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Wed, Nov 25, 2015 at 2:06 PM, Jacob Champion wrote: > My two cents: I agree that another "name mangled" abbreviation is not > particularly helpful, but I also agree with Jim's concern: "apr_token" made > me immediately wonder what made this exclusive to HTTP tokens. >

<    1   2   3   4   5   6   7   8   9   10   >