Re: color lib
On Friday, 7 October 2016 at 01:42:08 UTC, Manu wrote: On 7 October 2016 at 03:03, Ilya Yaroshenko via Digitalmars-d 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.
Re: Some nice new DMD slicing optimizations
On 07/10/2016 7:07 PM, Walter Bright wrote:
https://github.com/dlang/dmd/pull/6176
I'm happy to report that DMD has (finally!) gotten some significant new
optimizations! Specifically, 'slicing' a two register wide aggregate
into two register-sized variables, enabling much better enregistering.
Given the code:
void foo(int[] a, int[] b, int[] c) {
foreach (i; 0 .. a.length)
a[i] = b[i] + c[i];
}
the inner loop formerly compiled to:
LA: mov EAX,018h[ESP]
mov EDX,010h[ESP]
mov ECX,[EBX*4][EAX]
add ECX,[EBX*4][EDX]
mov ESI,020h[ESP]
mov [EBX*4][ESI],ECX
inc EBX
cmp EBX,01Ch[ESP]
jb LA
and now:
L1A:mov ECX,[EBX*4][EDI]
add ECX,[EBX*4][ESI]
mov 0[EBX*4][EBP],ECX
inc EBX
cmp EBX,EDX
jb L1A
I've been wanting to do this for years, and finally got around to it. (I
also thought of a simpler way to implement it, which helped a lot.)
Further work will be in widening what this applies to.
If there is bound checking shouldn't there be a check to guarantee b and
c and >= a.length?
Otherwise, awesome!
Re: Some nice new DMD slicing optimizations
On Friday, 7 October 2016 at 06:07:47 UTC, Walter Bright wrote: https://github.com/dlang/dmd/pull/6176 I'm happy to report that DMD has (finally!) gotten some significant new optimizations! Specifically, 'slicing' a two register wide aggregate into two register-sized variables, enabling much better enregistering. [...] Awesome!
Some nice new DMD slicing optimizations
https://github.com/dlang/dmd/pull/6176
I'm happy to report that DMD has (finally!) gotten some significant new
optimizations! Specifically, 'slicing' a two register wide aggregate into two
register-sized variables, enabling much better enregistering.
Given the code:
void foo(int[] a, int[] b, int[] c) {
foreach (i; 0 .. a.length)
a[i] = b[i] + c[i];
}
the inner loop formerly compiled to:
LA: mov EAX,018h[ESP]
mov EDX,010h[ESP]
mov ECX,[EBX*4][EAX]
add ECX,[EBX*4][EDX]
mov ESI,020h[ESP]
mov [EBX*4][ESI],ECX
inc EBX
cmp EBX,01Ch[ESP]
jb LA
and now:
L1A:mov ECX,[EBX*4][EDI]
add ECX,[EBX*4][ESI]
mov 0[EBX*4][EBP],ECX
inc EBX
cmp EBX,EDX
jb L1A
I've been wanting to do this for years, and finally got around to it. (I also
thought of a simpler way to implement it, which helped a lot.)
Further work will be in widening what this applies to.
Re: color lib
On 7 October 2016 at 12:55, Manu wrote:
> On 7 October 2016 at 12:38, Manu wrote:
>> On 7 October 2016 at 12:25, Chris Wright via Digitalmars-d
>> wrote:
>>> On Fri, 07 Oct 2016 11:42:08 +1000, Manu via Digitalmars-d wrote:
I think throwing is the precedented action in that failure case...
what would you suggest?
>>>
>>> In C# 1.0, the standard pattern was to throw on errors. Later, they
>>> revised their preferred mechanism and started offering methods like:
>>>
>>> static bool TryParse(string str, out DateTime dt) {...}
>>
>> Indeed, but what should WE do?
>
> I've rolled with:
> bool colorFromString(Color = RGB8)(scope const(char)[] str, out
> Color color) pure nothrow @safe @nogc
More updates and doco tweaks pushed.
Re: color lib
On 7 October 2016 at 12:38, Manu wrote:
> On 7 October 2016 at 12:25, Chris Wright via Digitalmars-d
> wrote:
>> On Fri, 07 Oct 2016 11:42:08 +1000, Manu via Digitalmars-d wrote:
>>> I think throwing is the precedented action in that failure case...
>>> what would you suggest?
>>
>> In C# 1.0, the standard pattern was to throw on errors. Later, they
>> revised their preferred mechanism and started offering methods like:
>>
>> static bool TryParse(string str, out DateTime dt) {...}
>
> Indeed, but what should WE do?
I've rolled with:
bool colorFromString(Color = RGB8)(scope const(char)[] str, out
Color color) pure nothrow @safe @nogc
Re: color lib
On 7 October 2016 at 12:25, Chris Wright via Digitalmars-d
wrote:
> On Fri, 07 Oct 2016 11:42:08 +1000, Manu via Digitalmars-d wrote:
>> I think throwing is the precedented action in that failure case...
>> what would you suggest?
>
> In C# 1.0, the standard pattern was to throw on errors. Later, they
> revised their preferred mechanism and started offering methods like:
>
> static bool TryParse(string str, out DateTime dt) {...}
Indeed, but what should WE do?
Re: color lib
On 7 October 2016 at 11:42, Manu wrote: > On 7 October 2016 at 03:03, Ilya Yaroshenko via Digitalmars-d > 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 >> >> >> 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...? Problem with overloading is that the function type only differs by return type... is there a phobos convention for function naming where a parallel nothrow @nogc version is also supplied?
Re: color lib
On Fri, 07 Oct 2016 11:42:08 +1000, Manu via Digitalmars-d wrote:
> I think throwing is the precedented action in that failure case...
> what would you suggest?
In C# 1.0, the standard pattern was to throw on errors. Later, they
revised their preferred mechanism and started offering methods like:
static bool TryParse(string str, out DateTime dt) {...}
Re: inout delegate
On 7 October 2016 at 05:58, Jinx via Digitalmars-d
wrote:
> On Thursday, 6 October 2016 at 15:00:56 UTC, Manu wrote:
>>
>> On 6 October 2016 at 00:29, Manu wrote:
>>>
>>> On 4 October 2016 at 11:15, Manu wrote:
[...]
>>>
>>>
>>> I'm really struggling with this issue.. multiple times a day.
>>> I can't find a reasonable workaround. casting, or trying to re-synth
>>> the delegate type from the function signature doesn't seem to be
>>> reasonable. I lose all the attributes, and storage class on parameters
>>> are an endless nuisance that should never have existed. Cloning the
>>> function signature verbatim, but with inout resolved seems to be
>>> really hard and probably buggy.
>>> I really just need this bug fixed... is it a particularly tricky fix?
>>
>>
>> Goodnight. I'm really hoping I wake up tomorrow and someone has some
>> comment on this issue...
>> I'm a post about it every day. I'm completely blocked while this
>> regression stands ;)
>
>
> Why not make a template function that does the necessary conversion? Going
> from the delegate to a void* then back again with the appropriate attributes
> applied by a cast?
storage class and attributes are so hard to work with. It's a serious
pain to do what you suggest.
Since this is a bug (and a very recent regression no less), I just
want it fixed so I can get on with it. Writing massively complex
workarounds for it is just not worth the energy. Seriously, I'm sure I
could spend a whole day on it trying to cover all cases!
Perhaps you'd like to give it a go ;)
Something like:
template delegateTypeForInoutMethod(T, string method)
{
alias delegateTypeForInoutMethod = [write lots of stuff here];
}
struct S
{
inout(int)[] f(ref const(int) arg) inout pure nothrow { return [ arg ]; }
}
static assert(delegateTypeForInoutMethod!(const(S), "f") ==
const(int)[] delegate(ref const(int)) pure nothrow, "You failed!");
Re: color lib
On 7 October 2016 at 04:48, Random D user via Digitalmars-d
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.
>
>
> Just a quick minor comment on:
> A8 RGB!("a",ubyte,false,0) 8 bit alpha-only color type.
> -->
> Reads like, "False what ???". Also "What is 0 ???".
> -->
> How about RGB!("a", ubyte, Linear.No, Colorspace.sRGB) or something like
> that,
> since there's going to be a list of these in the docs.
>
> What does colorspace 0 mean actually? (AdobeRGB??? i.e. first from
> colorspace enum according the docs).
It's kind of upsetting that the docs don't show the default arg as the
enum it is...
The struct is defined:
struct RGB(string components_, ComponentType_, bool linear_ = false,
RGBColorSpace colorSpace_ = RGBColorSpace.sRGB)
I don't know why the docs translate that to be '0'? Why not just omit
the default args from the docs as they are in the code:
alias A8 = RGB!("a", ubyte);
??
It also seems the docs have rearranged the order of the enum... seriously?
Why wouldn't that retain the order the programmer specified?
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, otherwise
I'm really not enthusiastic about it personally.
It just seems like pointless bloat in symbol names to me, is if they
weren't already bloated enough.
Re: std.math API rework
On 10/6/16 12:53 PM, Ilya Yaroshenko wrote: Effective work with std.experimental.ndslice and and mir.ndslice.array requires half of std.math be an exactly aliases to LLVM intrinsics (for LDC). Why? To enable vectorization for mir.ndslice.algorithm I created internal math module [1] in Mir. But this is weird, because third side packages like DCV [2] requires to use the module too. Also, some optimisation for std.complex and future std.exprimental.color would be very ugly without proposed change. I'd love to understand this point better. In particular, how do you reconcile it with kinke's assertion that some of these intrinsics simply format to C routines? Our high-level view is that doing efficient work should not require one to fork the standard library. On the other hand, the traditional place for compiler-specific code is in the core runtime, not the standard library. (There is a tiny bit of stdlib code that depends on dmd to be fair.) So I'd like to be reasonably confident the right rocks are put in the right places. Have you considered (per Iain) migrating these symbols to core.math and then forward those in stdlib to them? Thanks, Andrei
Re: color lib
On 7 October 2016 at 03:03, Ilya Yaroshenko via Digitalmars-d 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 > > > 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?
Re: std.math API rework
On Thursday, 6 October 2016 at 20:55:55 UTC, Ilya Yaroshenko wrote: So, I don't see a reason why this change break something, hehe No, Iain is right. These LLVM intrinsics are most often simple forwarders to the C runtime functions; I was rather negatively surprised to find out a while ago.
Re: std.math API rework
On 6 October 2016 at 22:55, Ilya Yaroshenko via Digitalmars-d
wrote:
> On Thursday, 6 October 2016 at 20:45:24 UTC, Iain Buclaw wrote:
>>
>> On 6 October 2016 at 22:31, Ilya Yaroshenko via Digitalmars-d
>> wrote:
>>>
>>> On Thursday, 6 October 2016 at 20:07:19 UTC, Iain Buclaw wrote:
On 6 October 2016 at 18:53, Ilya Yaroshenko via Digitalmars-d
wrote:
>
>
> [...]
If you can prove that llvm intrinsics are pure (gcc math intrinsics are
not) and that llvm intrinsics pass the unittest (gcc math intrinsics aren't
guaranteed to due to the vagary of libm implementations and quirky cpu
support that trades correctness for efficiency).
[...]
>>>
>>>
>>>
>>> LLVM math functions are pure :P http://llvm.org/docs/LangRef.html
>>>
>>
>> I picked a random example.
>>
>> http://llvm.org/docs/LangRef.html#llvm-sin-intrinsic
>>
>> """
>>
>> Semantics:
>>
>> This function returns the sine of the specified operand, returning the
>> same values as the libm sin functions would, and handles error conditions in
>> the same way.
>>
>> """
>>
>> This would have me believe that they are infact not pure. ;-)
>>
>> But, I've never looked under the hood of LLVM, so I can only believe those
>> who have. In any case, IMO, you should focus on getting this into
>> core.math. That's where compiler intrinsics should go. The intrinsics of
>> std.math are historical baggage and are probably due a deprecation - that
>> is, in the sense that their symbols be converted into aliases.
>>
>> Iain.
>
>
> Current code is (please look in LDC's fork):
>
> version(LDC)
> {
> real cos(real x) @safe pure nothrow @nogc { return llvm_cos(x); }
> ///ditto
> double cos(double x) @safe pure nothrow @nogc { return llvm_cos(x); }
> ///ditto
> float cos(float x) @safe pure nothrow @nogc { return llvm_cos(x); }
> }
> else
> {
>
> real cos(real x) @safe pure nothrow @nogc { pragma(inline, true); return
> core.math.cos(x); }
> //FIXME
> ///ditto
> double cos(double x) @safe pure nothrow @nogc { return cos(cast(real)x); }
> //FIXME
> ///ditto
> float cos(float x) @safe pure nothrow @nogc { return cos(cast(real)x); }
>
> }
>
> So, I don't see a reason why this change break something, hehe
Well, sure, I could mark all gcc intrinsics as pure so you can use
__builtin_print() or malloc() in pure code. Doesn't mean the compiler
is honest in allowing it. ;-)
Get this in core.math, there's no place for compiler-specific code in phobos.
Iain.
Re: std.math API rework
On Thursday, 6 October 2016 at 20:45:24 UTC, Iain Buclaw wrote:
On 6 October 2016 at 22:31, Ilya Yaroshenko via Digitalmars-d
wrote:
On Thursday, 6 October 2016 at 20:07:19 UTC, Iain Buclaw wrote:
On 6 October 2016 at 18:53, Ilya Yaroshenko via Digitalmars-d
wrote:
[...]
If you can prove that llvm intrinsics are pure (gcc math
intrinsics are not) and that llvm intrinsics pass the
unittest (gcc math intrinsics aren't guaranteed to due to the
vagary of libm implementations and quirky cpu support that
trades correctness for efficiency).
[...]
LLVM math functions are pure :P
http://llvm.org/docs/LangRef.html
I picked a random example.
http://llvm.org/docs/LangRef.html#llvm-sin-intrinsic
"""
Semantics:
This function returns the sine of the specified operand,
returning the same values as the libm sin functions would, and
handles error conditions in the same way.
"""
This would have me believe that they are infact not pure. ;-)
But, I've never looked under the hood of LLVM, so I can only
believe those who have. In any case, IMO, you should focus on
getting this into core.math. That's where compiler intrinsics
should go. The intrinsics of std.math are historical baggage
and are probably due a deprecation - that is, in the sense that
their symbols be converted into aliases.
Iain.
Current code is (please look in LDC's fork):
version(LDC)
{
real cos(real x) @safe pure nothrow @nogc { return
llvm_cos(x); }
///ditto
double cos(double x) @safe pure nothrow @nogc { return
llvm_cos(x); }
///ditto
float cos(float x) @safe pure nothrow @nogc { return
llvm_cos(x); }
}
else
{
real cos(real x) @safe pure nothrow @nogc { pragma(inline, true);
return core.math.cos(x); }
//FIXME
///ditto
double cos(double x) @safe pure nothrow @nogc { return
cos(cast(real)x); }
//FIXME
///ditto
float cos(float x) @safe pure nothrow @nogc { return
cos(cast(real)x); }
}
So, I don't see a reason why this change break something, hehe
Re: std.math API rework
On 6 October 2016 at 22:31, Ilya Yaroshenko via Digitalmars-d wrote: > On Thursday, 6 October 2016 at 20:07:19 UTC, Iain Buclaw wrote: >> >> On 6 October 2016 at 18:53, Ilya Yaroshenko via Digitalmars-d >> wrote: >>> >>> [...] >> >> >> If you can prove that llvm intrinsics are pure (gcc math intrinsics are >> not) and that llvm intrinsics pass the unittest (gcc math intrinsics aren't >> guaranteed to due to the vagary of libm implementations and quirky cpu >> support that trades correctness for efficiency). >> >> [...] > > > LLVM math functions are pure :P http://llvm.org/docs/LangRef.html > I picked a random example. http://llvm.org/docs/LangRef.html#llvm-sin-intrinsic """ Semantics: This function returns the sine of the specified operand, returning the same values as the libm sin functions would, and handles error conditions in the same way. """ This would have me believe that they are infact not pure. ;-) But, I've never looked under the hood of LLVM, so I can only believe those who have. In any case, IMO, you should focus on getting this into core.math. That's where compiler intrinsics should go. The intrinsics of std.math are historical baggage and are probably due a deprecation - that is, in the sense that their symbols be converted into aliases. Iain.
6767015388093641922
I is
Re: std.math API rework
On Thursday, 6 October 2016 at 20:07:19 UTC, Iain Buclaw wrote: On 6 October 2016 at 18:53, Ilya Yaroshenko via Digitalmars-d wrote: [...] If you can prove that llvm intrinsics are pure (gcc math intrinsics are not) and that llvm intrinsics pass the unittest (gcc math intrinsics aren't guaranteed to due to the vagary of libm implementations and quirky cpu support that trades correctness for efficiency). [...] LLVM math functions are pure :P http://llvm.org/docs/LangRef.html I can do a Phobos fork. But I hope I can fix it.
Walmond send pictures down up down [your code here]
Send pictures
Re: std.math API rework
On 6 October 2016 at 18:53, Ilya Yaroshenko via Digitalmars-d wrote: > Effective work with std.experimental.ndslice and and mir.ndslice.array > requires half of std.math be an exactly aliases to LLVM intrinsics (for > LDC). > > To enable vectorization for mir.ndslice.algorithm I created internal math > module [1] in Mir. But this is weird, because third side packages like DCV > [2] requires to use the module too. Also, some optimisation for std.complex > and future std.exprimental.color would be very ugly without proposed change. > > Proposed change is very simple: > Each math function listed in [1] should be a template for DMD/GDC and an > alias for LDC in std.math. > > If some one has strong arguments against it, please let me know now. > > [1] https://github.com/libmir/mir/blob/master/source/mir/internal/math.d > [2] https://github.com/ljubobratovicrelja/dcv > > Best regards, > Ilya If you can prove that llvm intrinsics are pure (gcc math intrinsics are not) and that llvm intrinsics pass the unittest (gcc math intrinsics aren't guaranteed to due to the vagary of libm implementations and quirky cpu support that trades correctness for efficiency). I have a reasonable belief to say that the answer is no on both parts. Even if some llvm intrinsics lower to native instructions on x86, most other platforms will just forward it to an impure, mixed bag of long double support libm. :-) If you need it specialized, do it yourself. Phobos seems more of a place for generalized application support, from what I gather, and how I approach it. Iain.
Re: inout delegate
On Thursday, 6 October 2016 at 15:00:56 UTC, Manu wrote: On 6 October 2016 at 00:29, Manu wrote: On 4 October 2016 at 11:15, Manu wrote: [...] I'm really struggling with this issue.. multiple times a day. I can't find a reasonable workaround. casting, or trying to re-synth the delegate type from the function signature doesn't seem to be reasonable. I lose all the attributes, and storage class on parameters are an endless nuisance that should never have existed. Cloning the function signature verbatim, but with inout resolved seems to be really hard and probably buggy. I really just need this bug fixed... is it a particularly tricky fix? Goodnight. I'm really hoping I wake up tomorrow and someone has some comment on this issue... I'm a post about it every day. I'm completely blocked while this regression stands ;) Why not make a template function that does the necessary conversion? Going from the delegate to a void* then back again with the appropriate attributes applied by a cast?
Re: color lib
On Thursday, 6 October 2016 at 14:53:52 UTC, Manu wrote:
I've done another pass incorporating prior feedback, mostly
focusing on documentation.
Just a quick minor comment on:
A8 RGB!("a",ubyte,false,0) 8 bit alpha-only color type.
-->
Reads like, "False what ???". Also "What is 0 ???".
-->
How about RGB!("a", ubyte, Linear.No, Colorspace.sRGB) or
something like that,
since there's going to be a list of these in the docs.
What does colorspace 0 mean actually? (AdobeRGB??? i.e. first
from colorspace enum according the docs).
Re: color lib
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 Could you please make `colorFromString` nothrow @nogc? Or make `nothrow @nogc` analog. -- Ilya
Re: std.math API rework
On Thursday, 6 October 2016 at 16:53:54 UTC, Ilya Yaroshenko wrote: Effective work with std.experimental.ndslice and and mir.ndslice.array requires half of std.math be an exactly EDIT: mir.ndslice.algorithm
std.math API rework
Effective work with std.experimental.ndslice and and mir.ndslice.array requires half of std.math be an exactly aliases to LLVM intrinsics (for LDC). To enable vectorization for mir.ndslice.algorithm I created internal math module [1] in Mir. But this is weird, because third side packages like DCV [2] requires to use the module too. Also, some optimisation for std.complex and future std.exprimental.color would be very ugly without proposed change. Proposed change is very simple: Each math function listed in [1] should be a template for DMD/GDC and an alias for LDC in std.math. If some one has strong arguments against it, please let me know now. [1] https://github.com/libmir/mir/blob/master/source/mir/internal/math.d [2] https://github.com/ljubobratovicrelja/dcv Best regards, Ilya
Re: inout delegate
On 6 October 2016 at 00:29, Manu wrote: > On 4 October 2016 at 11:15, Manu wrote: >> On 4 October 2016 at 10:50, Timon Gehr via Digitalmars-d >> wrote: >>> On 03.10.2016 05:06, Manu via Digitalmars-d wrote: Okay, well my current project is blocked on this. I can't progress. https://issues.dlang.org/show_bug.cgi?id=16572 >>> >>> >>> Probably you can work around the issue using unsafe type casts. >> >> Mmm, I'll see how much work it is to detect the case to do such a cast... > > I'm really struggling with this issue.. multiple times a day. > I can't find a reasonable workaround. casting, or trying to re-synth > the delegate type from the function signature doesn't seem to be > reasonable. I lose all the attributes, and storage class on parameters > are an endless nuisance that should never have existed. Cloning the > function signature verbatim, but with inout resolved seems to be > really hard and probably buggy. > I really just need this bug fixed... is it a particularly tricky fix? Goodnight. I'm really hoping I wake up tomorrow and someone has some comment on this issue... I'm a post about it every day. I'm completely blocked while this regression stands ;)
color lib
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
First Blood
So, Alexandru (our first n00b) has made his first contribution, see https://github.com/dlang/dlang.org/pull/1493. Yay! In order to continue his onboarding process, I'll look for a few bugs of varying degrees of difficulty that should offer him good exposure to various areas of our toolset. If you have some specific issues in mind that would be appropriate, please reply here or write me/him email. Thanks, Andrei
Re: Examples Wanted: Usages of "body" as a Symbol Name
On Wednesday, 5 October 2016 at 02:11:14 UTC, Meta wrote: - Video games, such as referring to the player character's body Many years ago I did a D port of the C-Dogs game from C to D and it was quite annoying to have to rename all the body variables to body_. It has happened in other contexts a few more times since.
Re: Examples Wanted: Usages of "body" as a Symbol Name
On Thursday, 6 October 2016 at 06:38:06 UTC, Jonathan M Davis wrote: Yeah, the fact that the body keyword is not required normally but is when you have in/out contracts is annoying, completely aside from what the keyword used is. I don't care much about losing the name body to a keyword, but I definitely don't like that you have to use a keyword for a function body when you have in/out contracts. It doesn't seem like it should be necessary, and it's inconsistent with the normal case. - Jonathan M Davis I agree 100%.
