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

FOSDEM 2016 - take action by 4th of December 2015

As most of you probably know FOSDEM 2016 (the biggest, 100% free open source developer conference) is right around the corner: https://fosdem.org/2016/ We hope to have an ASF booth and we would love to see as many ASF projects as possible present at various tracks (AKA Developer rooms):

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

On 01.12.2015 05:31, William A Rowe Jr wrote: > > 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

Re: apr_token_* conclusions

> On Nov 27, 2015, at 2:15 PM, Branko Čibej wrote: > > On 27.11.2015 15:59, Jim Jagielski wrote: >>> On Nov 26, 2015, at 8:49 PM, Branko Čibej wrote: >>> >>> In any case — I don't think anyone over at dev@s.a.o would object to APR >>> including those