coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [coreutils] what belongs in the next coreutils release?


From: Pádraig Brady
Subject: Re: [coreutils] what belongs in the next coreutils release?
Date: Fri, 01 Oct 2010 02:05:06 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3

On 27/09/10 14:26, Pádraig Brady wrote:
> On 27/09/10 14:07, Jim Meyering wrote:
>> Pádraig Brady wrote:
>>> On 26/09/10 20:29, Jim Meyering wrote:
>>>> It's been 5 months since coreutils-8.5, and the list of NEWS
>>>> entries is long enough that I think we'd do well to make a release.
>>>> I've included those entries below.
>>>>
>>>> Other than the imminent fix for tr's assert-on-invalid-inputs bug,
>>>> is there anything people would like to see included?
>>>
>>> I'd also like to test out mutexes vs spinlocks in multicore sort.
>>>
>>> I'd also like to test if it's appropriate to limit the
>>> default max number of processors used in multicore sort
>>> to something like 8.
>>
>> Waiting a week or two would be fine.
>> Does that sound reasonable?
>>
>>> I was hoping to get multibyte support for join in
>>> (which is pretty much complete now), but given
>>> the requirement that `sort` order matches up with
>>> that of `join`, we'll have to do both in unison I think.
>>
>> I'd prefer to defer those changes, too.
>>
>>> There is also the split --number enhancement which
>>> is mostly done except for some docs and refactoring,
>>> but we might push that out till next time, time depending.
>>
>> Either way would be fine with me.
>> It's a new feature, so even if the code is immature,
>> it won't cause much harm.
> 
> tr this evening
> multi-core sort testing probably wednesday evening
> join multibyte tweaks friday
> sort multibyte alignment with join (not sure)
> split --number another couple of days.
> 
> I'll have more info in a few days.

OK there should be nothing holding the release as far as I'm concerned.

tr fixes done.

I did multicore sort testing and I'm happier it's OK.
I'm still a bit worried we're being a bit aggressive
by using spinlocks and threads = num CPUs, but
it's not too bad and we can performance tweak later if needed.

join multibyte is done, but needs to match sort,
and I'm not comfortable rushing multibyte sort
changes in. Will do for next release.

split --number required more extensive changes
which I may get around to this weekend,
but no need to hold up the release for it.

cheers,
Pádraig.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]