Re: apr_token_* conclusions

[William A Rowe Jr]

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 on that page,
quit apologizing.  If you are out to score some cool public posts, it might
be time to hang up that hat.  And it isn't specific to Jim, anyone who
complains that APR moves too slow wasn't hanging around here 12 yrs ago,
the moment it is time for a release, there will be the momentum for release.

Grow up everyone, this isn't httpd.  Let's code.
On Nov 30, 2015 06:15, "Jim Jagielski"  wrote:

>
> > 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 functions. We actually have a number of other, heh,
> >>> improvements on APR that we could "donate"; we just never really got
> >>> around to producing the necessary patches.
> >> Yeah, svn is in the same situation as httpd. There are
> >> some functions would "ideally" would exist in APR,
> >> but APR doesn't move "fast enough" to allow that to
> >> happen, so both projects start collecting APR-like
> >> kruft after awhile...
> >>
> >> It certainly would be nice if there was someway to address
> >> that...
> >
> > Uh, what I wrote is in no way intended to be a criticism of APR. Maybe
> > if people who think APR isn't moving fast enough spent their time
> > writing code here instead of writing mails about it, this "problem"
> > would just vanish. At least, that's my understanding of how open source
> > is supposed to work -- right, Jim? ;)
>
> Gosh! You are right! Gee whiz, I haven't had any substantial code added
> to APR since 1.5.1. Thanks for reminding me! I really feel completely
> and utterly unworthy to comment on or criticize APR in any meaningful
> way and I offer my heartfelt apologies to everyone on this thread
> for wasting their time on a thread which started off as a suggestion
> for a new function to be added to httpd but, I noted:
>
> I propose a ap_strncasecmp/ap_strcasecmp which we should use.
> Ideally, it would be in apr but no need to wait for that
> to happen :)
>
> which, at least how I read it, implies code to be added to APR
> in the ideal case. But that is besides the point, as Brane so
> correctly says! Instead of writing emails about code to be
> added, we should instead be writing the code itself, which,
> of course, will be accepted in as-is with no discussion whatsoever,
> since, heck, that's kind of what's going on here, but as Brane
> reminds us all, such a thing is a problem that will magically
> disappear the more we write code!
>
> I propose that no message be allowed on the dev@apr list unless
> a 15-line patch or code contribution is attached. This will
> solve the nasty problem! In fact, maybe we should just shut down
> dev@apr since it encourages such unconstructive behavior as "writing
> emails" when we instead should be head's down cranking out code
> that may, or may not (usually not) be added and used before the
> end of the decade.

FOSDEM 2016 - take action by 4th of December 2015

[Roman Shaposhnik]

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):
   https://fosdem.org/2016/schedule/#devrooms

This year, for the first time, we are running a dedicated
Big Data and HPC Developer Room and given how much of that
open source development is done at ASF it would be great
to have folks submit talks to:
   https://hpc-bigdata-fosdem16.github.io

While the CFPs for different Developer Rooms follow slightly 
different schedules, but if you submit by the end of this week 
you should be fine.

Finally if you don't want to fish for CFP submission URL,
here it is:
   https://fosdem.org/submit

If you have any questions -- please email me *directly* and
hope to see as many of you as possible in two months! 

Thanks,
Roman.

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

[William A Rowe Jr]

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, sniping aside.  I started with an svn
cp today from asf subversion, and chose to focus on only the svn_cstring_
(excluding svn_string and svn_stringbuf ops), but there is room if we give
the nod and should treat them as 3 seperate groupings.  First commit
inbound in the morning with lots of room for optimization.

Re: apr_token_* conclusions

[Branko Čibej]

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 optimization is lost.
>
> I think we are of one mind on this, sniping aside.  I started with an
> svn cp today from asf subversion, and chose to focus on only the
> svn_cstring_ (excluding svn_string and svn_stringbuf ops), but there
> is room if we give the nod and should treat them as 3 seperate
> groupings.  First commit inbound in the morning with lots of room for
> optimization.
>

Ack. I think svn_string, and certainly svn_stringbuf, are out of scope
for APR.

-- Brane

Re: apr_token_* conclusions

[Jim Jagielski]

> 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 functions. We actually have a number of other, heh,
>>> improvements on APR that we could "donate"; we just never really got
>>> around to producing the necessary patches.
>> Yeah, svn is in the same situation as httpd. There are
>> some functions would "ideally" would exist in APR,
>> but APR doesn't move "fast enough" to allow that to
>> happen, so both projects start collecting APR-like
>> kruft after awhile...
>> 
>> It certainly would be nice if there was someway to address
>> that...
> 
> Uh, what I wrote is in no way intended to be a criticism of APR. Maybe
> if people who think APR isn't moving fast enough spent their time
> writing code here instead of writing mails about it, this "problem"
> would just vanish. At least, that's my understanding of how open source
> is supposed to work -- right, Jim? ;)

Gosh! You are right! Gee whiz, I haven't had any substantial code added
to APR since 1.5.1. Thanks for reminding me! I really feel completely
and utterly unworthy to comment on or criticize APR in any meaningful
way and I offer my heartfelt apologies to everyone on this thread
for wasting their time on a thread which started off as a suggestion
for a new function to be added to httpd but, I noted:

I propose a ap_strncasecmp/ap_strcasecmp which we should use.
Ideally, it would be in apr but no need to wait for that
to happen :)

which, at least how I read it, implies code to be added to APR
in the ideal case. But that is besides the point, as Brane so
correctly says! Instead of writing emails about code to be
added, we should instead be writing the code itself, which,
of course, will be accepted in as-is with no discussion whatsoever,
since, heck, that's kind of what's going on here, but as Brane
reminds us all, such a thing is a problem that will magically
disappear the more we write code!

I propose that no message be allowed on the dev@apr list unless
a 15-line patch or code contribution is attached. This will
solve the nasty problem! In fact, maybe we should just shut down
dev@apr since it encourages such unconstructive behavior as "writing
emails" when we instead should be head's down cranking out code
that may, or may not (usually not) be added and used before the
end of the decade.