On Friday, 7 October 2016 at 01:42:08 UTC, Manu wrote:
> On 7 October 2016 at 03:03, Ilya Yaroshenko via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On Thursday, 6 October 2016 at 14:53:52 UTC, Manu wrote:
>>> [...]
>>
>>
>> Could you please make `colorFromString` nothrow @nogc? Or make `nothrow @nogc` analog. -- Ilya
>
> I think throwing is the precedented action in that failure case...
> what would you suggest?
> I could have an overload that returns an error or something...?
>
> I wonder how the work towards throwing RC things is going?

No idea. The reason to do not throw Exceptions is to be able to use Phobos in betterC mode without DRuntime at all.

On Friday, 7 October 2016 at 01:57:06 UTC, Manu wrote:
> Regarding 'Linear.No'... yeah... I dunno. I've had this argument before.
> I really hate that pattern. If it's required, I'll do it

At least as far as readability goes, explicit parameterisation lets you understand the invocation at a glance rather than already knowing the actual name of the parameter or having to go elsewhere in code to see the prototype. For a library, I'd favor readability.

On 7 October 2016 at 18:09, Ethan Watson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Friday, 7 October 2016 at 01:57:06 UTC, Manu wrote:
>>
>> Regarding 'Linear.No'... yeah... I dunno. I've had this argument before. I really hate that pattern. If it's required, I'll do it
>
>
> At least as far as readability goes, explicit parameterisation lets you understand the invocation at a glance rather than already knowing the actual name of the parameter or having to go elsewhere in code to see the prototype. For a library, I'd favor readability.

Oh no, you too? >_<
Incidentally, have you had a geez over the core API? An efficient API
will emerge when we work out how to work batched operations into
ranges...

On Saturday, 8 October 2016 at 13:06:42 UTC, Manu wrote:
> On 7 October 2016 at 18:09, Ethan Watson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On Friday, 7 October 2016 at 01:57:06 UTC, Manu wrote:
>>>
>>> Regarding 'Linear.No'... yeah... I dunno. I've had this argument before. I really hate that pattern. If it's required, I'll do it
>>
>>
>> At least as far as readability goes, explicit parameterisation lets you understand the invocation at a glance rather than already knowing the actual name of the parameter or having to go elsewhere in code to see the prototype. For a library, I'd favor readability.
>
> Oh no, you too? >_<
> Incidentally, have you had a geez over the core API? An efficient API
> will emerge when we work out how to work batched operations into
> ranges...

I like true/false here :-)

On 8 October 2016 at 23:28, Ilya Yaroshenko via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Saturday, 8 October 2016 at 13:06:42 UTC, Manu wrote:
>>
>> On 7 October 2016 at 18:09, Ethan Watson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> On Friday, 7 October 2016 at 01:57:06 UTC, Manu wrote:
>>>>
>>>>
>>>> Regarding 'Linear.No'... yeah... I dunno. I've had this argument before. I really hate that pattern. If it's required, I'll do it
>>>
>>>
>>>
>>> At least as far as readability goes, explicit parameterisation lets you understand the invocation at a glance rather than already knowing the actual name of the parameter or having to go elsewhere in code to see the prototype. For a library, I'd favor readability.
>>
>>
>> Oh no, you too? >_<
>> Incidentally, have you had a geez over the core API? An efficient API
>> will emerge when we work out how to work batched operations into
>> ranges...
>
>
> I like true/false here :-)

I like this guy ;)

On Saturday, 8 October 2016 at 13:06:42 UTC, Manu wrote:
> Oh no, you too? >_<
> Incidentally, have you had a geez over the core API? An efficient API
> will emerge when we work out how to work batched operations into
> ranges...

How far would `r.inBatchesOf!(N)` go in terms of compiler optimisations (e.g. vectorisation) if N is a power of 2?

auto inBatchesOf(size_t N,R)(R r) if(N!=0 &&isInputRange!R &&  hasLength!R)
{
    struct InBatchesOfN
    {
        R r;
        ElementType!(R)[N] batch;
        this(R _r)
        {
             assert(_r.length % N ==0);// could have overloads where undefined elements == ElementType!(R).init
             r = _r;
             foreach( i; 0..N)
             {
                  batch[i] = r.front;
                  r.popFront;
             }
        }

        bool empty() { return r.empty; }
        auto front { return batch; }
        void popFront()
        {
             foreach( i; 0..N)
             {
                  batch[i] = r.front;
                  r.popFront;
             }
        }
    }

    return InBatchesOfN(r);
}

On 9 October 2016 at 14:03, Nicholas Wilson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Saturday, 8 October 2016 at 13:06:42 UTC, Manu wrote:
>>
>> Oh no, you too? >_<
>> Incidentally, have you had a geez over the core API? An efficient API
>> will emerge when we work out how to work batched operations into
>> ranges...
>
>
> How far would `r.inBatchesOf!(N)` go in terms of compiler optimisations
> (e.g. vectorisation) if N is a power of 2?
>
> auto inBatchesOf(size_t N,R)(R r) if(N!=0 &&isInputRange!R &&  hasLength!R)
> {
>     struct InBatchesOfN
>     {
>         R r;
>         ElementType!(R)[N] batch;
>         this(R _r)
>         {
>              assert(_r.length % N ==0);// could have overloads where
> undefined elements == ElementType!(R).init
>              r = _r;
>              foreach( i; 0..N)
>              {
>                   batch[i] = r.front;
>                   r.popFront;
>              }
>         }
>
>         bool empty() { return r.empty; }
>         auto front { return batch; }
>         void popFront()
>         {
>              foreach( i; 0..N)
>              {
>                   batch[i] = r.front;
>                   r.popFront;
>              }
>         }
>     }
>
>     return InBatchesOfN(r);
> }

Well the trouble is the lambda that you might give to 'map' won't work anymore. Operators don't work on batches, you need to use a completely different API, and I think that's unfortunate.

On Sunday, 9 October 2016 at 05:21:32 UTC, Manu wrote:
> On 9 October 2016 at 14:03, Nicholas Wilson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> [...]
>
> Well the trouble is the lambda that you might give to 'map' won't work anymore. Operators don't work on batches, you need to use a completely different API, and I think that's unfortunate.

Could you please give an example what type of operation should be vectorized?

On Sunday, 9 October 2016 at 05:21:32 UTC, Manu wrote:
> On 9 October 2016 at 14:03, Nicholas Wilson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> How far would `r.inBatchesOf!(N)` go in terms of compiler optimisations
>> (e.g. vectorisation) if N is a power of 2?
>>
>> auto inBatchesOf(size_t N,R)(R r) if(N!=0 &&isInputRange!R &&  hasLength!R)
>> {
>>     struct InBatchesOfN
>>     {
>>         R r;
>>         ElementType!(R)[N] batch;
>>         this(R _r)
>>         {
>>              assert(_r.length % N ==0);// could have overloads where
>> undefined elements == ElementType!(R).init
>>              r = _r;
>>              foreach( i; 0..N)
>>              {
>>                   batch[i] = r.front;
>>                   r.popFront;
>>              }
>>         }
>>
>>         bool empty() { return r.empty; }
>>         auto front { return batch; }
>>         void popFront()
>>         {
>>              foreach( i; 0..N)
>>              {
>>                   batch[i] = r.front;
>>                   r.popFront;
>>              }
>>         }
>>     }
>>
>>     return InBatchesOfN(r);
>> }
>
> Well the trouble is the lambda that you might give to 'map' won't work anymore. Operators don't work on batches, you need to use a completely different API, and I think that's unfortunate.

How?  All you need is an extra `each` e.g. r.inBatchesOf!(8).each!(a =>a[].map!(convertColor!RGBA8))

perhaps define a helper function for it that does each + the explicit slice + map, but it certainly doesn't scream completely different API to me.

On Sunday, 9 October 2016 at 05:34:06 UTC, Ilya Yaroshenko wrote:
> On Sunday, 9 October 2016 at 05:21:32 UTC, Manu wrote:
>> On 9 October 2016 at 14:03, Nicholas Wilson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>> [...]
>>
>> Well the trouble is the lambda that you might give to 'map' won't work anymore. Operators don't work on batches, you need to use a completely different API, and I think that's unfortunate.
>
> Could you please give an example what type of operation should be vectorized?

anything that is able to be. Given that ElementType!InBatchesOfN are a static array
of ElementType!(R), the compiler can* (assuming no branching and anything else that impedes vectorisation) combine most expressions into equivalent vector instruction.
This approach might not work so well for colours as is but should work if we "transpose" the colour i.e. rgbargbargbargba -> rrrrggggbbbbaaaa and then transpose it back.

*I know this is the sufficiently intelligent compiler argument