On Saturday, 8 October 2016 at 13:06:42 UTC, Manu wrote:
> Oh no, you too? >_<

Yeah, I've been going on a readability bender lately, especially in public facing code.

My thinking there is that statements in code that don't immediately give context are essentially a cipher. Because that's exactly what you need to do to understand the code - look something up to see what it means. Named parameters and variable names that provide the context avoid that to a large degree.

I'm especially trying to make Binderoo readable as there's so many programmers that are scared by metaprogramming. My GDCE talk spent a lot of time attempting to make it all understandable. Making the code descriptive seals the deal. If I can make my code more descriptive, and it compiles out just the same but makes the compiler do a bit more work... Make the compiler do more work and optimise the compiler.

I'm far more lax on not-publicly-facing code (so basically API implementations and supporting code that isn't part of a public interface). Anything I expect someone other than myself to interact with gets the readability treatment. Which, as you know, is important because readable code generally isn't efficient code - as is evidenced by the vectorisation/buffer processing thread going on in here.

It's also interesting how many programmers get vehemently defensive when you call out non-descriptive programming practices as programming for your own convenience and no one else. I have this argument with using i/j/k/foo/bar/etc in loops as well.

> 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...

Been slowly making my way through it. Seems solid enough, but I haven't looked through it all thoroughly yet.

On 2016-10-10 12:39, Ethan Watson wrote:

> I'm especially trying to make Binderoo readable as there's so many
> programmers that are scared by metaprogramming.

Isn't std.typecons.Flag metaprogramming ;)

-- 
/Jacob Carlborg

On Monday, 10 October 2016 at 12:10:56 UTC, Jacob Carlborg wrote:
> Isn't std.typecons.Flag metaprogramming ;)

Hahaha, oh wow. If ever there was a case for mixins.

On Monday, 10 October 2016 at 08:44:49 UTC, Manu wrote:
> On 10 October 2016 at 17:29, Andrea Fontana via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On Thursday, 6 October 2016 at 14:53:52 UTC, Manu wrote:
>>>
>>> I've done another pass incorporating prior feedback, mostly focusing on documentation.
>>>
>>>
>>> http://dtest.thecybershadow.net/artifact/website-b6e2e44dd40dd7c70eb45829c02060b99ae3937b-57272ccdf902fa3f0c050d522129f2be/web/library-prerelease/std/experimental/color.html
>>>
>>> Can interested parties please give it another once-over and add
>>> further comments?
>>> How can I get this to a point where people would like to see it in phobos?
>>>
>>> Repo: https://github.com/TurkeyMan/color
>>> PR: https://github.com/dlang/phobos/pull/2845
>>
>>
>> Nice work!
>>
>> colorFromString should be colorFromRGBString :)
>
> Nar. It parses any form of colour-in-a-string.

From doc:
colorFromString	Create a color from a string. May be a hex color in the standard forms: (#/$)rgb/argb/rrggbb/aarrggbb May also be the name of any color from the Colors enum.

It seems it reads just rgb. (+ enum)

I think that:
colorFromString("red");
colorFromString!"rgb"("#3212ff");
colorFromString!"bgra"("#ff1232dd");

makes more sense.

Andrea

On 10 October 2016 at 23:00, Andrea Fontana via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 10 October 2016 at 08:44:49 UTC, Manu wrote:
>
> From doc:
> colorFromString Create a color from a string. May be a hex color in the
> standard forms: (#/$)rgb/argb/rrggbb/aarrggbb May also be the name of any
> color from the Colors enum.
>
> It seems it reads just rgb. (+ enum)
>
> I think that:
> colorFromString("red");
> colorFromString!"rgb"("#3212ff");
> colorFromString!"bgra"("#ff1232dd");
>
> makes more sense.
>
> Andrea

Why? I see no value in that function being a template... It's not like you can confuse "#FF0080" and "LightGoldenrodYellow". As far as I know, there's no possible ambiguity in colour strings, so why make them separate functions?

On Monday, 10 October 2016 at 13:25:07 UTC, Manu wrote:
> On 10 October 2016 at 23:00, Andrea Fontana via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On Monday, 10 October 2016 at 08:44:49 UTC, Manu wrote:
>>
>> From doc:
>> colorFromString Create a color from a string. May be a hex color in the
>> standard forms: (#/$)rgb/argb/rrggbb/aarrggbb May also be the name of any
>> color from the Colors enum.
>>
>> It seems it reads just rgb. (+ enum)
>>
>> I think that:
>> colorFromString("red");
>> colorFromString!"rgb"("#3212ff");
>> colorFromString!"bgra"("#ff1232dd");
>>
>> makes more sense.
>>
>> Andrea
>
> Why? I see no value in that function being a template... It's not like you can confuse "#FF0080" and "LightGoldenrodYellow". As far as I know, there's no possible ambiguity in colour strings, so why make them separate functions?

But it would be useful to create rgb, bgr, argb, bgra, or other color space using a string.

If a third party library or source gives me code in rgba, I have to preprocess it to convert as argb and then pass it to your library.

Anyway, I don't know if a code with letters a-f can be composed. In that case an ambiguity exists.

On 10 October 2016 at 23:41, Andrea Fontana via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 10 October 2016 at 13:25:07 UTC, Manu wrote:
>>
>> On 10 October 2016 at 23:00, Andrea Fontana via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> On Monday, 10 October 2016 at 08:44:49 UTC, Manu wrote:
>>>
>>> From doc:
>>> colorFromString Create a color from a string. May be a hex color in the
>>> standard forms: (#/$)rgb/argb/rrggbb/aarrggbb May also be the name of any
>>> color from the Colors enum.
>>>
>>> It seems it reads just rgb. (+ enum)
>>>
>>> I think that:
>>> colorFromString("red");
>>> colorFromString!"rgb"("#3212ff");
>>> colorFromString!"bgra"("#ff1232dd");
>>>
>>> makes more sense.
>>>
>>> Andrea
>>
>>
>> Why? I see no value in that function being a template... It's not like you can confuse "#FF0080" and "LightGoldenrodYellow". As far as I know, there's no possible ambiguity in colour strings, so why make them separate functions?
>
>
> But it would be useful to create rgb, bgr, argb, bgra, or other color space using a string.

Give the preferred format as template arg?

> If a third party library or source gives me code in rgba, I have to preprocess it to convert as argb and then pass it to your library.

Sorry, what are we talking about? My lib supports basically every format or arrangement I've ever encountered... you can work with practically any data format you can think of.

> Anyway, I don't know if a code with letters a-f can be composed. In that case an ambiguity exists.

It must also be exactly 3,4,6,8 letters long, and begin with the letter '#' or '$' ;)


I'm not sure why it matters what format the colour you have is...
Strings are in the form #RRGGBB, or #AARRGGBB. That is all.
It's the standard I've seen used everywhere ever, including the web,
which is a pretty good precedent :P
If you support swizzled forms of strings, then ambiguity exists.
Better not to allow it.

If you want a BGR from a string, use: colorFromString!BGR8("#FF0000");
If you want Lab: colorFromString!(Lab!float)("#FF0000");

On Sunday, 9 October 2016 at 13:28:05 UTC, Manu wrote:
> On 9 October 2016 at 15:34, Ilya Yaroshenko via Digitalmars-d <digitalmars-d@puremagic.com> 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?
>
> Even operations that don't require shuffling, eg:
>   RGBA8[] a, b;
>   zip(a, b).map!(e => e[0] + e[1]).copy(output);
>
> Which I've suggested before (and Walter liked the idea), could be
> sugared up by making use of the languages largely under-used array
> operation syntax:
>   output[] = a[] + b[]; // ie, types have overloaded addition
> operators, so this array expression would be lowered to the pipeline
> expression above. This would be super-useful for HEAPS of things!
>
> Even these still need to be done in batches since colour adds are saturating operations, and there are SIMD instructions for saturating arithmetic, so we basically always have to do colour work in SIMD, which means batching, and that basically ruins any chance for natural, readable, expressions in your code. I want to find a way that we can express these operations naturally, without having to always manually handle the batching.
>
> If we can get there, then I will say D is a good language for stream-data processing.

What about forwarding the array ops to a foreach of the static array?
Like as above but instead of:

ElementType!(R)[N] batch;

have:

static struct Batch
{
    ElementType!(R)[N] elements;
    auto get() { return elements[];}

    Batch opBinary(string op)(Batch rhs) if(hasOperator!(ElementType!(R),op))
    {
        Batch b;
        foreach(i; iota(N)) mixin("b.elements[i] = elememts[i]" ~op~"rhs.elements[i]");
        return b;
    }
    //repeat for opUnary,opOpAssign...
}
Batch batch;

I'll make another forum thread for this.

On Tuesday, 11 October 2016 at 00:10:04 UTC, Nicholas Wilson wrote:
> What about forwarding the array ops to a foreach of the static array?
> Like as above but instead of:
>
> ElementType!(R)[N] batch;
>
> have:
>
> static struct Batch
> {
>     ElementType!(R)[N] elements;
>     auto get() { return elements[];}
>
>     Batch opBinary(string op)(Batch rhs) if(hasOperator!(ElementType!(R),op))
>     {
>         Batch b;
>         foreach(i; iota(N)) mixin("b.elements[i] = elememts[i]" ~op~"rhs.elements[i]");
>         return b;
>     }
>     //repeat for opUnary,opOpAssign...
> }
> Batch batch;
>
> I'll make another forum thread for this.

whoops missed an
alias get this;

On Monday, 10 October 2016 at 23:26:53 UTC, Manu wrote:
> I'm not sure why it matters what format the colour you have is...
> Strings are in the form #RRGGBB, or #AARRGGBB. That is all.
> It's the standard I've seen used everywhere ever, including the web,
> which is a pretty good precedent :P

If the web is a good precedent (CSS4 specs):
"The first 6 digits are interpreted identically to the 6-digit notation. The last pair of digits, interpreted as a hexadecimal number, specifies the alpha channel of the color, where 00 represents a fully transparent color and ff represent a fully opaque color."

https://drafts.csswg.org/css-color/#hex-notation

CSS3 doesn't support hex string with alpha but they suggest you to use rgba() function. I think argb() doesn't exists instead.
https://www.w3.org/TR/2011/REC-css3-color-20110607/#rgba-color

Chrome 52 supports it:
https://googlechrome.github.io/samples/css-alpha-channel/

Android instead:
https://developer.android.com/reference/android/graphics/Color.html#parseColor(java.lang.String)
"Parse the color string, and return the corresponding color-int. If the string cannot be parsed, throws an IllegalArgumentException exception. Supported formats are: #RRGGBB #AARRGGBB [...]"

Please notice that on PNG file format rgba is quite common (also on bmp with semi-official apha support)
PNG: http://www.libpng.org/pub/png/book/chapter08.html