www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - CTFE ^^ (pow)

reply Manu <turkeyman gmail.com> writes:
What is so hard about implementing a pow intrinsic that CTFE can use?
It's ridiculous that we can't CTFE any non-linear function...
It's one of those blocker bugs that's been there almost 10 years.
Mar 17 2018
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Manu wrote:


 What is so hard about implementing a pow intrinsic that CTFE can use?
 It's ridiculous that we can't CTFE any non-linear function...
 It's one of those blocker bugs that's been there almost 10 years.


nobody bothered. it is all done by intercepting calls in CTFE engine (using 
FQN mangled names), nothing very special. i once did it in my fork (but 
then mangling scheme was changed, and i never fixed the patch, lol).
Mar 17 2018
parent reply Rubn <where is.this> writes:
On Sunday, 18 March 2018 at 04:37:32 UTC, ketmar wrote:

 Manu wrote:


 What is so hard about implementing a pow intrinsic that CTFE 
 can use?
 It's ridiculous that we can't CTFE any non-linear function...
 It's one of those blocker bugs that's been there almost 10 
 years.


 nobody bothered. it is all done by intercepting calls in CTFE 
 engine (using FQN mangled names), nothing very special. i once 
 did it in my fork (but then mangling scheme was changed, and i 
 never fixed the patch, lol).


There was a PR a while ago IIRC, it's probably one of those 
sitting at the back of the queue from 4 years ago or something.
Mar 18 2018
parent Manu <turkeyman gmail.com> writes:
On 18 March 2018 at 06:57, Rubn via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 There was a PR a while ago IIRC, it's probably one of those sitting at the
 back of the queue from 4 years ago or something.


Unacceptable if true.
Mar 18 2018
prev sibling next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Sunday, 18 March 2018 at 04:25:48 UTC, Manu wrote:

 What is so hard about implementing a pow intrinsic that CTFE 
 can use?
 It's ridiculous that we can't CTFE any non-linear function...
 It's one of those blocker bugs that's been there almost 10 
 years.


Not all that much. Can you give me an example that does't work 
yet that you want to use?
Mar 18 2018
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
Nicholas Wilson wrote:


 On Sunday, 18 March 2018 at 04:25:48 UTC, Manu wrote:

 What is so hard about implementing a pow intrinsic that CTFE can use?
 It's ridiculous that we can't CTFE any non-linear function...
 It's one of those blocker bugs that's been there almost 10 years.


 Not all that much. Can you give me an example that does't work yet that 
 you want to use?


building gamma tables in CTFE. and LUT tables for XYZ color space.
Mar 18 2018
prev sibling next sibling parent Guillaume Piolat <notthat email.com> writes:
On Sunday, 18 March 2018 at 07:47:24 UTC, Nicholas Wilson wrote:

 On Sunday, 18 March 2018 at 04:25:48 UTC, Manu wrote:

 What is so hard about implementing a pow intrinsic that CTFE 
 can use?
 It's ridiculous that we can't CTFE any non-linear function...
 It's one of those blocker bugs that's been there almost 10 
 years.


 Not all that much. Can you give me an example that does't work 
 yet that you want to use?


Hello, I also needed this recently! I was surprised to see that 
^^ isn't CTFE but just a pow call.


------------- main.d -----------

T convertDecibelToLinearGain(T)(T dB) pure nothrow  nogc
{
     static immutable T ln10_20 = cast(T)LN10 / 20;
     return exp(dB * ln10_20);
}

void main()
{
     enum foo = convertDecibelToLinearGain!float(-24);
}
Mar 18 2018
prev sibling parent Manu <turkeyman gmail.com> writes:
On 18 March 2018 at 00:47, Nicholas Wilson via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Sunday, 18 March 2018 at 04:25:48 UTC, Manu wrote:

 What is so hard about implementing a pow intrinsic that CTFE can use?
 It's ridiculous that we can't CTFE any non-linear function...
 It's one of those blocker bugs that's been there almost 10 years.



 Not all that much. Can you give me an example that does't work yet that you
 want to use?


x^^y :)
Mar 18 2018
prev sibling next sibling parent reply Johan Engelen <j j.nl> writes:
On Sunday, 18 March 2018 at 04:25:48 UTC, Manu wrote:

 What is so hard about implementing a pow intrinsic that CTFE 
 can use?
 It's ridiculous that we can't CTFE any non-linear function...
 It's one of those blocker bugs that's been there almost 10 
 years.


It's been available in LDC since 1.6.0.
https://godbolt.org/g/Yx7PyK

- Johan

(PS. The aggressive style of your message would not motivate me 
to improve things for you.)
Mar 18 2018
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 18 March 2018 at 02:19, Johan Engelen via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Sunday, 18 March 2018 at 04:25:48 UTC, Manu wrote:

 What is so hard about implementing a pow intrinsic that CTFE can use?
 It's ridiculous that we can't CTFE any non-linear function...
 It's one of those blocker bugs that's been there almost 10 years.



 It's been available in LDC since 1.6.0.
 https://godbolt.org/g/Yx7PyK

 - Johan

 (PS. The aggressive style of your message would not motivate me to improve
 things for you.)


It's not aggression, it's a decade of compounded frustration.
I consider myself extremely patient with D, but how far am I supposed
to extend patience before I admit that I'm wasting my precious time
investing in something that's never going to 'get there'?
I still want to love D, but I'm drifting away and using it less and
less these days, and the main reason is that something so trivial as
this, which has been a recorded bug for almost a decade and comes up
often, still never moves. I'm always waiting... and so I find other
things to do with my time.

After being too busy to work on my side projects for a while, I
finally had a small block of time. I jumped in, did a few things, then
hit the same brick wall that I hit 3 years ago. My momentum comes to
an instant halt, and I feel like I'm just less likely to return to the
project again in the future wrt competing for priorities.
Ideally, if I make my blockers known (this one is so simple!!), and
try and re-awaken them semi-regularly... I'd like to think getting
back to something 3 years later, I'm able to move forward. But it's
still most of the same blockers I identified within my first 2-3 days
of using D ~9 years ago; I still can't ARC, I still can't pass an
rvalue by ref, and I still can't x^^y in ctfe.
This one has gotta be by far the simplest thing I've ever complained about!

Anyway, I've pretty much run out of energy to advocate a thing that
still doesn't even solve my own needs (let along the needs of my
companies), based on the assumption that it's fast moving, and
deficiencies will be resolved 'soon enough' after it's made known that
they are a blocker.
I'm sorry, 'soon enough' is not soon enough... I've run out of
patience, and I'm becoming increasingly frustrated and toxic.

I was gonna spend today coding, but I think I'll go outside instead.
Mar 18 2018
parent reply Jacob Carlborg <doob me.com> writes:
On 2018-03-19 01:00, Manu wrote:


 It's not aggression, it's a decade of compounded frustration.


Perhaps you can give this a try: 
https://forum.dlang.org/thread/ojxxjixcxnztmsskyuud forum.dlang.org

-- 
/Jacob Carlborg
Mar 19 2018
parent Manu <turkeyman gmail.com> writes:
On 19 March 2018 at 13:00, Jacob Carlborg via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 2018-03-19 01:00, Manu wrote:


 It's not aggression, it's a decade of compounded frustration.



 Perhaps you can give this a try:
 https://forum.dlang.org/thread/ojxxjixcxnztmsskyuud forum.dlang.org


Haha. Yeah, mine was the very first response, linking to this exact issue!
Just one of the many ways I've tried to resurrect interest in this issue :P
Mar 19 2018
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On 18 March 2018 at 17:00, Manu <turkeyman gmail.com> wrote:

 On 18 March 2018 at 02:19, Johan Engelen via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Sunday, 18 March 2018 at 04:25:48 UTC, Manu wrote:

 What is so hard about implementing a pow intrinsic that CTFE can use?
 It's ridiculous that we can't CTFE any non-linear function...
 It's one of those blocker bugs that's been there almost 10 years.



 It's been available in LDC since 1.6.0.
 https://godbolt.org/g/Yx7PyK

 - Johan

 (PS. The aggressive style of your message would not motivate me to improve
 things for you.)


 It's not aggression, it's a decade of compounded frustration.
 I consider myself extremely patient with D, but how far am I supposed
 to extend patience before I admit that I'm wasting my precious time
 investing in something that's never going to 'get there'?
 I still want to love D, but I'm drifting away and using it less and
 less these days, and the main reason is that something so trivial as
 this, which has been a recorded bug for almost a decade and comes up
 often, still never moves. I'm always waiting... and so I find other
 things to do with my time.

 After being too busy to work on my side projects for a while, I
 finally had a small block of time. I jumped in, did a few things, then
 hit the same brick wall that I hit 3 years ago. My momentum comes to
 an instant halt, and I feel like I'm just less likely to return to the
 project again in the future wrt competing for priorities.
 Ideally, if I make my blockers known (this one is so simple!!), and
 try and re-awaken them semi-regularly... I'd like to think getting
 back to something 3 years later, I'm able to move forward. But it's
 still most of the same blockers I identified within my first 2-3 days
 of using D ~9 years ago; I still can't ARC, I still can't pass an
 rvalue by ref, and I still can't x^^y in ctfe.
 This one has gotta be by far the simplest thing I've ever complained about!

 Anyway, I've pretty much run out of energy to advocate a thing that
 still doesn't even solve my own needs (let along the needs of my
 companies), based on the assumption that it's fast moving, and
 deficiencies will be resolved 'soon enough' after it's made known that
 they are a blocker.
 I'm sorry, 'soon enough' is not soon enough... I've run out of
 patience, and I'm becoming increasingly frustrated and toxic.

 I was gonna spend today coding, but I think I'll go outside instead.


I want to just justify my apparent over-reaction... I think I'm not
the only one that feels this way fairly often.
Something that seems trivial only invokes over-reaction of this nature
when there is sufficient emotional energy behind it.
In my case, that is represented by investing a decade of my life into
something based on the promise (**wishful thinking?) that it'll get to
the point where I want it to be as a tool to do my work... but then
slowly awakening myself to the reality that that's actually unlikely
to happen, and the longer it takes, the less likely that eventual
reality becomes.
Perhaps it's breaking a delusion I imposed on myself years ago, but it
still produces a feeling of being robbed of time and energy.

Anyway, I suspect I'm not the only one that reaches this point and
tends to feel this way. I've seen a lot of good people come and go
after they 'burn out' in some way. Patience is finite.
There's no action item here... just wanted to share a reflection, and
perhaps there's some takeaway for the community with respect to
priorities?
Mar 18 2018
parent reply Joakim <dlang joakim.fea.st> writes:
On Monday, 19 March 2018 at 00:08:58 UTC, Manu wrote:

 On 18 March 2018 at 17:00, Manu <turkeyman gmail.com> wrote:

 [...]


 I want to just justify my apparent over-reaction... I think I'm 
 not
 the only one that feels this way fairly often.
 Something that seems trivial only invokes over-reaction of this 
 nature
 when there is sufficient emotional energy behind it.
 In my case, that is represented by investing a decade of my 
 life into
 something based on the promise (**wishful thinking?) that it'll 
 get to
 the point where I want it to be as a tool to do my work... but 
 then
 slowly awakening myself to the reality that that's actually 
 unlikely
 to happen, and the longer it takes, the less likely that 
 eventual
 reality becomes.
 Perhaps it's breaking a delusion I imposed on myself years ago, 
 but it
 still produces a feeling of being robbed of time and energy.

 Anyway, I suspect I'm not the only one that reaches this point 
 and
 tends to feel this way. I've seen a lot of good people come and 
 go
 after they 'burn out' in some way. Patience is finite.
 There's no action item here... just wanted to share a 
 reflection, and
 perhaps there's some takeaway for the community with respect to
 priorities?


Perhaps the community simply has different priorities than you? 
For example, my Android port has never gotten much use either, 
which is fine as I primarily did that work for myself.

Nevertheless, you have to think of D as like working in a 
startup: if you see something that you think needs doing, you 
have to drive it yourself or it will never get done. Pretty much 
the same for most any OSS project too.
Mar 18 2018
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, March 19, 2018 00:28:15 Joakim via Digitalmars-d wrote:

 On Monday, 19 March 2018 at 00:08:58 UTC, Manu wrote:

 On 18 March 2018 at 17:00, Manu <turkeyman gmail.com> wrote:

 [...]


 I want to just justify my apparent over-reaction... I think I'm
 not
 the only one that feels this way fairly often.
 Something that seems trivial only invokes over-reaction of this
 nature
 when there is sufficient emotional energy behind it.
 In my case, that is represented by investing a decade of my
 life into
 something based on the promise (**wishful thinking?) that it'll
 get to
 the point where I want it to be as a tool to do my work... but
 then
 slowly awakening myself to the reality that that's actually
 unlikely
 to happen, and the longer it takes, the less likely that
 eventual
 reality becomes.
 Perhaps it's breaking a delusion I imposed on myself years ago,
 but it
 still produces a feeling of being robbed of time and energy.

 Anyway, I suspect I'm not the only one that reaches this point
 and
 tends to feel this way. I've seen a lot of good people come and
 go
 after they 'burn out' in some way. Patience is finite.
 There's no action item here... just wanted to share a
 reflection, and
 perhaps there's some takeaway for the community with respect to
 priorities?


 Perhaps the community simply has different priorities than you?
 For example, my Android port has never gotten much use either,
 which is fine as I primarily did that work for myself.

 Nevertheless, you have to think of D as like working in a
 startup: if you see something that you think needs doing, you
 have to drive it yourself or it will never get done. Pretty much
 the same for most any OSS project too.


I definitely agree with this. If the folks fixing stuff don't have the same
priorities as you, then there's a high risk that what you want to be fixed
won't get fixed, and that's often how things go with open source projects.
But at the same time, if you come to D, see all kinds of great things about
it, and think that it's going to be fantastic but keep running into things
that cause you problems when you try to use D, and then those pain points
don't get fixed even after years of dealing with the language, that's going
to be very frustrating - even more so if you've invested a lot of time and
energy into it.

On some level, the only solution is to buckle down and fix your pain points
yourself, but that can also be quite frustrating.

- Jonathan M Davis
Mar 18 2018
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On 18 March 2018 at 17:28, Joakim via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Perhaps the community simply has different priorities than you? For example,
 my Android port has never gotten much use either, which is fine as I
 primarily did that work for myself.

 Nevertheless, you have to think of D as like working in a startup: if you
 see something that you think needs doing, you have to drive it yourself or
 it will never get done. Pretty much the same for most any OSS project too.


This is such an easy and readily-deploy-able response here.
What you say is true, and I totally understand this... but at the same
time, that's not actually the relationship I want to have with my
tool. A startup probably shouldn't still be a startup 10 years later.

In your case, doing the android work was obviously an interest you had
on the side, and you gain something from the work itself.
I have a small amount of that, but that's not where I'm at, and it
never has been. I want to use D to do my job, because I'm fed up with
C++. I want to engage in D the way I think D should **EXPECT** it's
users to engage in D; as an end-user, who uses the tool to get their
jobs done.
If D is a large-ish scale hobby project among a bunch of people with
mutual interests, then that should be more clearly communicated, but I
don't think that's the intent, and I feel perfectly fine interacting
with D in the way D is intended to be interacted with.

Incidentally, this particular work I'm doing is on a multimedia
library intended for the community... so I really am truly trying to
contribute something of value!! But like most of my projects, I tend
to get blocked at some point, and then it goes on hold indefinitely.
Mar 18 2018
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
For those not in the know, Manu is special.

He is in essence a use case for D himself.

We really should be trying to make him happy in terms of blockers.
It's just good business sense.

Shame we can't throw money at him, he would have great ROI value.
Mar 18 2018
parent reply Manu <turkeyman gmail.com> writes:
On 18 March 2018 at 18:11, rikki cattermole via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 For those not in the know, Manu is special.

 He is in essence a use case for D himself.

 We really should be trying to make him happy in terms of blockers.
 It's just good business sense.

 Shame we can't throw money at him, he would have great ROI value.


Haha!
I tried to mitigate coming across that way, and express myself in
terms of patience and frustration, which I think is probably something
a lot of people here can relate to.

Sure, there's no reason for anyone to care about my opinion, but I
have truly spent years investing in D, and strategies and attempts to
integrate it into my work *professionally*. Doing company
demonstrations, training colleagues, attempting small projects as
proof of concept, etc.
That's all I care about. I have hobby projects like everyone, but what
I *really* care about, is getting to the point where I can write D
code professionally in my field of work.
I also think I work in one of the prime fields where D has so much to
offer... but we also have an unusually high bar-to-entry.
Mar 18 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 19/03/2018 2:21 PM, Manu wrote:

 On 18 March 2018 at 18:11, rikki cattermole via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 For those not in the know, Manu is special.

 He is in essence a use case for D himself.

 We really should be trying to make him happy in terms of blockers.
 It's just good business sense.

 Shame we can't throw money at him, he would have great ROI value.


 
 Haha!
 I tried to mitigate coming across that way, and express myself in
 terms of patience and frustration, which I think is probably something
 a lot of people here can relate to.
 
 Sure, there's no reason for anyone to care about my opinion, but I
 have truly spent years investing in D, and strategies and attempts to
 integrate it into my work *professionally*. Doing company
 demonstrations, training colleagues, attempting small projects as
 proof of concept, etc.
 That's all I care about. I have hobby projects like everyone, but what
 I *really* care about, is getting to the point where I can write D
 code professionally in my field of work.
 I also think I work in one of the prime fields where D has so much to
 offer... but we also have an unusually high bar-to-entry.


Your entire reply is reason to care about your opinion :)

I'm not alone in thinking that you're a very valuable community member.
Perhaps you can have a chat with a member of DLF about getting a list of 
issues for you figured out?
Mar 18 2018
parent reply Manu <turkeyman gmail.com> writes:
On 18 March 2018 at 18:29, rikki cattermole via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 19/03/2018 2:21 PM, Manu wrote:

 On 18 March 2018 at 18:11, rikki cattermole via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 For those not in the know, Manu is special.

 He is in essence a use case for D himself.

 We really should be trying to make him happy in terms of blockers.
 It's just good business sense.

 Shame we can't throw money at him, he would have great ROI value.



 Haha!
 I tried to mitigate coming across that way, and express myself in
 terms of patience and frustration, which I think is probably something
 a lot of people here can relate to.

 Sure, there's no reason for anyone to care about my opinion, but I
 have truly spent years investing in D, and strategies and attempts to
 integrate it into my work *professionally*. Doing company
 demonstrations, training colleagues, attempting small projects as
 proof of concept, etc.
 That's all I care about. I have hobby projects like everyone, but what
 I *really* care about, is getting to the point where I can write D
 code professionally in my field of work.
 I also think I work in one of the prime fields where D has so much to
 offer... but we also have an unusually high bar-to-entry.



 Your entire reply is reason to care about your opinion :)

 I'm not alone in thinking that you're a very valuable community member.


I'm not though... I'm a noisy whingey one that never actually gives
anything back!
I'm just a stubborn mule that's constantly trying to fight my way
through my next hurdle.

I think maybe my lessons are of some value, and I've been a forcing
function for a few important developments.
If I were to start over again today, I might have different
experience, thanks to a relative increase in ecosystem maturity
compared to when I started.


 Perhaps you can have a chat with a member of DLF about getting a list of
 issues for you figured out?


I've influenced more than I feel is reasonable with respect to my
results. I've mostly failed, and not through lack of trying. There are
lots of people here now who are having way more success than I have.
I might do that if I could maneuver my workplace into a position where
they were to consider a serious investigation again.

I still want x^^y to work though! :P
Mar 18 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 19/03/2018 2:38 PM, Manu wrote:

 On 18 March 2018 at 18:29, rikki cattermole via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 19/03/2018 2:21 PM, Manu wrote:

 On 18 March 2018 at 18:11, rikki cattermole via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 For those not in the know, Manu is special.

 He is in essence a use case for D himself.

 We really should be trying to make him happy in terms of blockers.
 It's just good business sense.

 Shame we can't throw money at him, he would have great ROI value.



 Haha!
 I tried to mitigate coming across that way, and express myself in
 terms of patience and frustration, which I think is probably something
 a lot of people here can relate to.

 Sure, there's no reason for anyone to care about my opinion, but I
 have truly spent years investing in D, and strategies and attempts to
 integrate it into my work *professionally*. Doing company
 demonstrations, training colleagues, attempting small projects as
 proof of concept, etc.
 That's all I care about. I have hobby projects like everyone, but what
 I *really* care about, is getting to the point where I can write D
 code professionally in my field of work.
 I also think I work in one of the prime fields where D has so much to
 offer... but we also have an unusually high bar-to-entry.



 Your entire reply is reason to care about your opinion :)

 I'm not alone in thinking that you're a very valuable community member.


 
 I'm not though... I'm a noisy whingey one that never actually gives
 anything back!
 I'm just a stubborn mule that's constantly trying to fight my way
 through my next hurdle.
 
 I think maybe my lessons are of some value, and I've been a forcing
 function for a few important developments.
 If I were to start over again today, I might have different
 experience, thanks to a relative increase in ecosystem maturity
 compared to when I started.
 

 Perhaps you can have a chat with a member of DLF about getting a list of
 issues for you figured out?


 
 I've influenced more than I feel is reasonable with respect to my
 results. I've mostly failed, and not through lack of trying. There are
 lots of people here now who are having way more success than I have.
 I might do that if I could maneuver my workplace into a position where
 they were to consider a serious investigation again.


Your result, is a better D experience for everyone involved.
There has been no failure that I can see on the communities end.

You failed to create a successful commercial products using D, wait hang 
on Quantum Break!

Just because 99 times out of 100 you've failed doesn't mean 1 won't be 
successful given more hard work.
Mar 18 2018
parent Manu <turkeyman gmail.com> writes:
On 18 March 2018 at 18:50, rikki cattermole via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 19/03/2018 2:38 PM, Manu wrote:

 On 18 March 2018 at 18:29, rikki cattermole via Digitalmars-d

 <digitalmars-d puremagic.com> wrote:

 On 19/03/2018 2:21 PM, Manu wrote:

 On 18 March 2018 at 18:11, rikki cattermole via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 For those not in the know, Manu is special.

 He is in essence a use case for D himself.

 We really should be trying to make him happy in terms of blockers.
 It's just good business sense.

 Shame we can't throw money at him, he would have great ROI value.




 Haha!
 I tried to mitigate coming across that way, and express myself in
 terms of patience and frustration, which I think is probably something
 a lot of people here can relate to.

 Sure, there's no reason for anyone to care about my opinion, but I
 have truly spent years investing in D, and strategies and attempts to
 integrate it into my work *professionally*. Doing company
 demonstrations, training colleagues, attempting small projects as
 proof of concept, etc.
 That's all I care about. I have hobby projects like everyone, but what
 I *really* care about, is getting to the point where I can write D
 code professionally in my field of work.
 I also think I work in one of the prime fields where D has so much to
 offer... but we also have an unusually high bar-to-entry.




 Your entire reply is reason to care about your opinion :)

 I'm not alone in thinking that you're a very valuable community member.



 I'm not though... I'm a noisy whingey one that never actually gives
 anything back!
 I'm just a stubborn mule that's constantly trying to fight my way
 through my next hurdle.

 I think maybe my lessons are of some value, and I've been a forcing
 function for a few important developments.
 If I were to start over again today, I might have different
 experience, thanks to a relative increase in ecosystem maturity
 compared to when I started.


 Perhaps you can have a chat with a member of DLF about getting a list of
 issues for you figured out?



 I've influenced more than I feel is reasonable with respect to my
 results. I've mostly failed, and not through lack of trying. There are
 lots of people here now who are having way more success than I have.
 I might do that if I could maneuver my workplace into a position where
 they were to consider a serious investigation again.



 Your result, is a better D experience for everyone involved.
 There has been no failure that I can see on the communities end.

 You failed to create a successful commercial products using D, wait hang on
 Quantum Break!

 Just because 99 times out of 100 you've failed doesn't mean 1 won't be
 successful given more hard work.


I'm much more comfortable with confrontational emails :P

I'm not doing much work anymore though...
I'm drifting for entirely preventable reasons. I guess I just wanted
to share that here somehow. In altogether too many words! ;)
Mar 18 2018
prev sibling next sibling parent reply Norm <norm.rowtree gmail.com> writes:
On Monday, 19 March 2018 at 00:59:45 UTC, Manu wrote:

 On 18 March 2018 at 17:28, Joakim via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:

 Perhaps the community simply has different priorities than 
 you? For example, my Android port has never gotten much use 
 either, which is fine as I primarily did that work for myself.

 Nevertheless, you have to think of D as like working in a 
 startup: if you see something that you think needs doing, you 
 have to drive it yourself or it will never get done. Pretty 
 much the same for most any OSS project too.


 This is such an easy and readily-deploy-able response here.
 What you say is true, and I totally understand this... but at 
 the same
 time, that's not actually the relationship I want to have with 
 my
 tool. A startup probably shouldn't still be a startup 10 years 
 later.

 In your case, doing the android work was obviously an interest 
 you had
 on the side, and you gain something from the work itself.
 I have a small amount of that, but that's not where I'm at, and 
 it
 never has been. I want to use D to do my job, because I'm fed 
 up with
 C++. I want to engage in D the way I think D should **EXPECT** 
 it's
 users to engage in D; as an end-user, who uses the tool to get 
 their
 jobs done.
 If D is a large-ish scale hobby project among a bunch of people 
 with
 mutual interests, then that should be more clearly 
 communicated, but I
 don't think that's the intent, and I feel perfectly fine 
 interacting
 with D in the way D is intended to be interacted with.

 Incidentally, this particular work I'm doing is on a multimedia 
 library intended for the community... so I really am truly 
 trying to contribute something of value!! But like most of my 
 projects, I tend to get blocked at some point, and then it goes 
 on hold indefinitely.


+1024 bytes

I think D is a terrific language worthy of all the praise it gets 
and it is way way more stable than it was 3yrs ago. But the 
attitude of submit a PR if you want it fixed works very much 
against D. Like it or not these forums are a front page on the D 
marketing campaign.

My workplace has stopped using D after a 6 month trial, which 
finished in Jan 2018. Several developers did post here during 
that period when blocked by a bug or incomplete feature, only to 
be told if they want it fixed they can always submit a PR.

Inevitably when told this they simply dropped D and went back to 
C++ and Python. And they made a point to bring this experience up 
at the final go/no-go meeting.

The majority of developers, including those voting for D, had 
these common opinions (much to my disappointment)

a) We're not in the business of developing and maintaining D, but 
it seems that is what we would need to do as a company. We are 
better off with C++ and Python.

b) D feels like C++ did back in the mid 90's. A time when we 
avoided templates and often the STL because compiler 
implementations were too buggy. We are better off with C++ and 
Python.


I keep pushing D here but now it is a bit of a joke when I bring 
it up. I've become "the D guy" and it isn't discussed seriously 
any more by other developers, except a select few.

Cheers,
Norm
Mar 18 2018
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 19/03/2018 3:56 PM, Norm wrote:

 On Monday, 19 March 2018 at 00:59:45 UTC, Manu wrote:

 On 18 March 2018 at 17:28, Joakim via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:

 Perhaps the community simply has different priorities than you? For 
 example, my Android port has never gotten much use either, which is 
 fine as I primarily did that work for myself.

 Nevertheless, you have to think of D as like working in a startup: if 
 you see something that you think needs doing, you have to drive it 
 yourself or it will never get done. Pretty much the same for most any 
 OSS project too.


 This is such an easy and readily-deploy-able response here.
 What you say is true, and I totally understand this... but at the same
 time, that's not actually the relationship I want to have with my
 tool. A startup probably shouldn't still be a startup 10 years later.

 In your case, doing the android work was obviously an interest you had
 on the side, and you gain something from the work itself.
 I have a small amount of that, but that's not where I'm at, and it
 never has been. I want to use D to do my job, because I'm fed up with
 C++. I want to engage in D the way I think D should **EXPECT** it's
 users to engage in D; as an end-user, who uses the tool to get their
 jobs done.
 If D is a large-ish scale hobby project among a bunch of people with
 mutual interests, then that should be more clearly communicated, but I
 don't think that's the intent, and I feel perfectly fine interacting
 with D in the way D is intended to be interacted with.

 Incidentally, this particular work I'm doing is on a multimedia 
 library intended for the community... so I really am truly trying to 
 contribute something of value!! But like most of my projects, I tend 
 to get blocked at some point, and then it goes on hold indefinitely.


 
 +1024 bytes
 
 I think D is a terrific language worthy of all the praise it gets and it 
 is way way more stable than it was 3yrs ago. But the attitude of submit 
 a PR if you want it fixed works very much against D. Like it or not 
 these forums are a front page on the D marketing campaign.
 
 My workplace has stopped using D after a 6 month trial, which finished 
 in Jan 2018. Several developers did post here during that period when 
 blocked by a bug or incomplete feature, only to be told if they want it 
 fixed they can always submit a PR.


Did they at any point tell us that it was a blocker for your company who 
was trialing D?

Because I do not remember once in that time period of any one saying this.

Walter has gone out of his way in the past to help companies, even 
flying to them on his own dime.

If you want to be treated special, we need to have a reason for you to 
be treated special, otherwise you're just like everybody else 
complaining without giving back.
Mar 18 2018
parent reply Norm <norm.rowtree gmail.com> writes:
On Monday, 19 March 2018 at 03:14:51 UTC, rikki cattermole wrote:

 Did they at any point tell us that it was a blocker for your 
 company who was trialing D?

 Because I do not remember once in that time period of any one 
 saying this.

 Walter has gone out of his way in the past to help companies, 
 even flying to them on his own dime.

 If you want to be treated special, we need to have a reason for 
 you to be treated special, otherwise you're just like everybody 
 else complaining without giving back.


We don't want to be treated special. We don't want to give back. 
This is the *entire* point.

D claims to be "Industry Proven and Ready" but we have to submit 
PRs or get special treatment from Walter to use it effectively? 
Sorry, but this is why many feel that D is still just a hobby 
project.

We are an organisation trying to get work done. D was a potential 
replacement of our existing C++/Python tool chain. Unfortunately 
it *requires* us to give back, which as I stated is not our 
business. Our business is the development of medical devices and 
supporting application software, not compiler or language 
development.

IMO most of D is close enough, but I am a convert and geek. Most 
of my fellow developers are not.

Cheers,
Norm
Mar 18 2018
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 19/03/2018 4:43 PM, Norm wrote:

 On Monday, 19 March 2018 at 03:14:51 UTC, rikki cattermole wrote:

 Did they at any point tell us that it was a blocker for your company 
 who was trialing D?

 Because I do not remember once in that time period of any one saying 
 this.

 Walter has gone out of his way in the past to help companies, even 
 flying to them on his own dime.

 If you want to be treated special, we need to have a reason for you to 
 be treated special, otherwise you're just like everybody else 
 complaining without giving back.


 
 We don't want to be treated special. We don't want to give back. This is 
 the *entire* point.
 
 D claims to be "Industry Proven and Ready" but we have to submit PRs or 
 get special treatment from Walter to use it effectively? Sorry, but this 
 is why many feel that D is still just a hobby project.
 
 We are an organisation trying to get work done. D was a potential 
 replacement of our existing C++/Python tool chain. Unfortunately it 
 *requires* us to give back, which as I stated is not our business. Our 
 business is the development of medical devices and supporting 
 application software, not compiler or language development.


You just said the magic word, medical.

D was never an appropriate fit here.

dmd's backend has been for thirty years (or so) been up to recently 
licensed so that you may not use it for this purpose. Nothing has 
changed here.
Mar 18 2018
next sibling parent reply Norm <norm.rowtree gmail.com> writes:
On Monday, 19 March 2018 at 03:53:07 UTC, rikki cattermole wrote:

 On 19/03/2018 4:43 PM, Norm wrote:

 On Monday, 19 March 2018 at 03:14:51 UTC, rikki cattermole 
 wrote:

 Did they at any point tell us that it was a blocker for your 
 company who was trialing D?

 Because I do not remember once in that time period of any one 
 saying this.

 Walter has gone out of his way in the past to help companies, 
 even flying to them on his own dime.

 If you want to be treated special, we need to have a reason 
 for you to be treated special, otherwise you're just like 
 everybody else complaining without giving back.


 
 We don't want to be treated special. We don't want to give 
 back. This is the *entire* point.
 
 D claims to be "Industry Proven and Ready" but we have to 
 submit PRs or get special treatment from Walter to use it 
 effectively? Sorry, but this is why many feel that D is still 
 just a hobby project.
 
 We are an organisation trying to get work done. D was a 
 potential replacement of our existing C++/Python tool chain. 
 Unfortunately it *requires* us to give back, which as I stated 
 is not our business. Our business is the development of 
 medical devices and supporting application software, not 
 compiler or language development.


 You just said the magic word, medical.

 D was never an appropriate fit here.

 dmd's backend has been for thirty years (or so) been up to 
 recently licensed so that you may not use it for this purpose. 
 Nothing has changed here.


I have no idea what you're talking about now.

What has the backend license got to do with medical?

D would be a great fit for medical with its  safe, pure and GC.

Supporting application software is standard desktop development. 
Some of these applications are for production and testing and the 
rest are normal end-user Windows desktop?

We also develop mobile applications but we didn't consider D for 
that role.

Cheers,
Norm
Mar 18 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 19/03/2018 5:05 PM, Norm wrote:

 On Monday, 19 March 2018 at 03:53:07 UTC, rikki cattermole wrote:

 On 19/03/2018 4:43 PM, Norm wrote:

 On Monday, 19 March 2018 at 03:14:51 UTC, rikki cattermole wrote:

 Did they at any point tell us that it was a blocker for your company 
 who was trialing D?

 Because I do not remember once in that time period of any one saying 
 this.

 Walter has gone out of his way in the past to help companies, even 
 flying to them on his own dime.

 If you want to be treated special, we need to have a reason for you 
 to be treated special, otherwise you're just like everybody else 
 complaining without giving back.


 We don't want to be treated special. We don't want to give back. This 
 is the *entire* point.

 D claims to be "Industry Proven and Ready" but we have to submit PRs 
 or get special treatment from Walter to use it effectively? Sorry, 
 but this is why many feel that D is still just a hobby project.

 We are an organisation trying to get work done. D was a potential 
 replacement of our existing C++/Python tool chain. Unfortunately it 
 *requires* us to give back, which as I stated is not our business. 
 Our business is the development of medical devices and supporting 
 application software, not compiler or language development.


 You just said the magic word, medical.

 D was never an appropriate fit here.

 dmd's backend has been for thirty years (or so) been up to recently 
 licensed so that you may not use it for this purpose. Nothing has 
 changed here.


 
 I have no idea what you're talking about now.
 
 What has the backend license got to do with medical?


The code generation capabilities of dmd has not been certified for 
medical usage.

In essence, if it generated bad code, kills somebody, your the one at 
fault, even if the source is fine. You would end up begging to settle 
out of court.

It is my understanding that medical software manufacturers pay for their 
compilers already certified. So that suggests to me that you're not 
exactly life threatening but I would still caution you away from D even 
if that bit is just my own opinion.
Mar 18 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, March 19, 2018 17:15:26 rikki cattermole via Digitalmars-d wrote:

 On 19/03/2018 5:05 PM, Norm wrote:

 On Monday, 19 March 2018 at 03:53:07 UTC, rikki cattermole wrote:

 You just said the magic word, medical.

 D was never an appropriate fit here.

 dmd's backend has been for thirty years (or so) been up to recently
 licensed so that you may not use it for this purpose. Nothing has
 changed here.


 I have no idea what you're talking about now.

 What has the backend license got to do with medical?


 The code generation capabilities of dmd has not been certified for
 medical usage.

 In essence, if it generated bad code, kills somebody, your the one at
 fault, even if the source is fine. You would end up begging to settle
 out of court.

 It is my understanding that medical software manufacturers pay for their
 compilers already certified. So that suggests to me that you're not
 exactly life threatening but I would still caution you away from D even
 if that bit is just my own opinion.


It may be there are compilers certified for that sort of thing (I'm
certainly no expert on the subject), but AFAIK, basically every compiler
ever says that it's not certified or guaranteed for anything, because the
compiler writers don't want to get sued if something goes wrong regardless
of what you're using it for.

- Jonathan M Davis
Mar 18 2018
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 19/03/2018 5:23 PM, Jonathan M Davis wrote:

 On Monday, March 19, 2018 17:15:26 rikki cattermole via Digitalmars-d wrote:

 On 19/03/2018 5:05 PM, Norm wrote:

 On Monday, 19 March 2018 at 03:53:07 UTC, rikki cattermole wrote:

 You just said the magic word, medical.

 D was never an appropriate fit here.

 dmd's backend has been for thirty years (or so) been up to recently
 licensed so that you may not use it for this purpose. Nothing has
 changed here.


 I have no idea what you're talking about now.

 What has the backend license got to do with medical?


 The code generation capabilities of dmd has not been certified for
 medical usage.

 In essence, if it generated bad code, kills somebody, your the one at
 fault, even if the source is fine. You would end up begging to settle
 out of court.

 It is my understanding that medical software manufacturers pay for their
 compilers already certified. So that suggests to me that you're not
 exactly life threatening but I would still caution you away from D even
 if that bit is just my own opinion.


 
 It may be there are compilers certified for that sort of thing (I'm
 certainly no expert on the subject), but AFAIK, basically every compiler
 ever says that it's not certified or guaranteed for anything, because the
 compiler writers don't want to get sued if something goes wrong regardless
 of what you're using it for.
 
 - Jonathan M Davis
 


Here is clang's[0], nothing about medical. Just you can't sue us when it 
goes wrong.

Compare against[1], clearly its a big deal safety wise. This is why I 
will say specifically even for D that I love, do not use it here.

[0] http://releases.llvm.org/2.8/LICENSE.TXT
[1] 
https://developer.arm.com/products/software-development-tools/compilers/arm-compiler/safety
Mar 18 2018
prev sibling parent reply Norm <norm.rowtree gmail.com> writes:
On Monday, 19 March 2018 at 04:15:26 UTC, rikki cattermole wrote:

 On 19/03/2018 5:05 PM, Norm wrote:

 On Monday, 19 March 2018 at 03:53:07 UTC, rikki cattermole 
 wrote:

 On 19/03/2018 4:43 PM, Norm wrote:

 On Monday, 19 March 2018 at 03:14:51 UTC, rikki cattermole 
 wrote:

 Did they at any point tell us that it was a blocker for 
 your company who was trialing D?

 Because I do not remember once in that time period of any 
 one saying this.

 Walter has gone out of his way in the past to help 
 companies, even flying to them on his own dime.

 If you want to be treated special, we need to have a reason 
 for you to be treated special, otherwise you're just like 
 everybody else complaining without giving back.


 We don't want to be treated special. We don't want to give 
 back. This is the *entire* point.

 D claims to be "Industry Proven and Ready" but we have to 
 submit PRs or get special treatment from Walter to use it 
 effectively? Sorry, but this is why many feel that D is 
 still just a hobby project.

 We are an organisation trying to get work done. D was a 
 potential replacement of our existing C++/Python tool chain. 
 Unfortunately it *requires* us to give back, which as I 
 stated is not our business. Our business is the development 
 of medical devices and supporting application software, not 
 compiler or language development.


 You just said the magic word, medical.

 D was never an appropriate fit here.

 dmd's backend has been for thirty years (or so) been up to 
 recently licensed so that you may not use it for this 
 purpose. Nothing has changed here.


 
 I have no idea what you're talking about now.
 
 What has the backend license got to do with medical?


 The code generation capabilities of dmd has not been certified 
 for medical usage.

 In essence, if it generated bad code, kills somebody, your the 
 one at fault, even if the source is fine. You would end up 
 begging to settle out of court.

 It is my understanding that medical software manufacturers pay 
 for their compilers already certified. So that suggests to me 
 that you're not exactly life threatening but I would still 
 caution you away from D even if that bit is just my own opinion.


No, compilers do not need to be certified for class B or class C 
software. These are the two highest safety classes for medical 
SW. Beyond class C SW is not allowed, e.g. safety critical 
interlocks such as the big red button to shut off a radiation 
dose or stop a robotic system.

Compilers are are treated as SOUP (Software of Unknown 
Provenance), i.e. a black box. Risk analysis leads to risk 
control measures that in turn ensure people don't die and this is 
done at the system and component level, not the codegen level. 
Verification is performed to ensure the system implements the 
requirements correctly, and subsequently the risk control 
measures. Not all requirements are risk control measures, but all 
requirements must be verified as correct.

Cheers,
Norm
Mar 18 2018
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Monday, 19 March 2018 at 05:27:20 UTC, Norm wrote:

 On Monday, 19 March 2018 at 04:15:26 UTC, rikki cattermole 
 wrote:

 On 19/03/2018 5:05 PM, Norm wrote:

 On Monday, 19 March 2018 at 03:53:07 UTC, rikki cattermole 
 wrote:

 On 19/03/2018 4:43 PM, Norm wrote:

 [...]


 You just said the magic word, medical.

 D was never an appropriate fit here.

 dmd's backend has been for thirty years (or so) been up to 
 recently licensed so that you may not use it for this 
 purpose. Nothing has changed here.


 
 I have no idea what you're talking about now.
 
 What has the backend license got to do with medical?


 The code generation capabilities of dmd has not been certified 
 for medical usage.

 In essence, if it generated bad code, kills somebody, your the 
 one at fault, even if the source is fine. You would end up 
 begging to settle out of court.

 It is my understanding that medical software manufacturers pay 
 for their compilers already certified. So that suggests to me 
 that you're not exactly life threatening but I would still 
 caution you away from D even if that bit is just my own 
 opinion.


 No, compilers do not need to be certified for class B or class 
 C software. These are the two highest safety classes for 
 medical SW. Beyond class C SW is not allowed, e.g. safety 
 critical interlocks such as the big red button to shut off a 
 radiation dose or stop a robotic system.

 Compilers are are treated as SOUP (Software of Unknown 
 Provenance), i.e. a black box. Risk analysis leads to risk 
 control measures that in turn ensure people don't die and this 
 is done at the system and component level, not the codegen 
 level. Verification is performed to ensure the system 
 implements the requirements correctly, and subsequently the 
 risk control measures. Not all requirements are risk control 
 measures, but all requirements must be verified as correct.

 Cheers,
 Norm


I was the CTO and partner of a company using D in medical devices 
since more than ten years ago... as Norm wrote, medical software 
is a strange beast...

Anyway, as someone else wrote, when I leaved the company, two 
years ago, the new CTO and my former colleague, decided not to 
invest anymore in D. After ten years of use.

Said that, I'm pretty happy about what's happening in D Land in 
the last 3/4 months, but clearly there's a lot to be done.

/Paolo
Mar 19 2018
prev sibling parent Danni Coy <danni.coy gmail.com> writes:
The volunteer line is fine for big picture stuff that is going to require a
lot of work and planing to get right. Using that for smaller feature
requests is going to give the impression that D is lacking in the technical
expertise to get anything done, It's often a sign that an open source
project is dying. I don't think anybody wants that.

On the other hand take a little time to try and get your point accross
without being unnecessarily confrontational. Not because you aren't right
but because it takes less time than rehashing these conversations and I
know for a fact that some of you have way more productive things to do with
your time than this ;)
Mar 18 2018
prev sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 03/18/2018 11:43 PM, Norm wrote:

 
 We don't want to be treated special. We don't want to give back. This is 
 the *entire* point.
 


An attitude like that and there's any wonder it didn't work out? Sheesh.

This is the thing about OSS: The business willing to give back (and 
there are many such businesses) are the ones that reap benefits. The 
companies that wilfully cling to zero-sum bullshit are on their own, by 
their own choice, and open themselves to allowing their competitors to 
take the advantage for themselves. That is the way of the world, that is 
the way of reality.

D can't be held responsible for self-defeating zero-sum, "us vs them" 
mentalities. Sheesh.
Mar 22 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, March 22, 2018 21:25:11 Nick Sabalausky  via Digitalmars-d 
wrote:

 On 03/18/2018 11:43 PM, Norm wrote:

 We don't want to be treated special. We don't want to give back. This is
 the *entire* point.


 An attitude like that and there's any wonder it didn't work out? Sheesh.

 This is the thing about OSS: The business willing to give back (and
 there are many such businesses) are the ones that reap benefits. The
 companies that wilfully cling to zero-sum bullshit are on their own, by
 their own choice, and open themselves to allowing their competitors to
 take the advantage for themselves. That is the way of the world, that is
 the way of reality.

 D can't be held responsible for self-defeating zero-sum, "us vs them"
 mentalities. Sheesh.


While I do think that there's a lot to be said for companies who are willing
to use open source and give back to the community in the process, there are
plenty of people (and not just companies) who just want a tool to get things
done. And I don't think that there's anything wrong with that. Yes, everyone
is better off when companies are willing to give back, but that doesn't work
for everyone, and honestly, there are some places where I've worked where I
wouldn't want them trying to give back, because they wouldn't be giving back
anything of value and/or it would be of poor quality. But regardless of the
quality of code involved, your average company is not going to do much in
terms of contributing to open source, even if ultimately, we're all better
off if folks in general contribute back from time to time.

And I think that it's quite safe to say that regardless of what folks are
giving back or not giving back, we'd all be better off if D were in a place
that the average user could use it without running into serious problems,
and we wouldn't have companies saying that they couldn't use D because of
bugs or whatnot. I think that we're in a _much_ better place with regards to
that than we once were and that the situation continues to improve, but
clearly, some of the issues that we still have are showstoppers for some
folks. We're never going to please everyone, but we do want D to be solid
and not _require_ that the average D user give back even if we'd very much
like for folks to give back where they can.

- Jonathan M Davis
Mar 22 2018
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 03/22/2018 09:44 PM, Jonathan M Davis wrote:

 On Thursday, March 22, 2018 21:25:11 Nick Sabalausky  via Digitalmars-d
 wrote:

 On 03/18/2018 11:43 PM, Norm wrote:

 We don't want to be treated special. We don't want to give back. This is
 the *entire* point.


 An attitude like that and there's any wonder it didn't work out? Sheesh.

 This is the thing about OSS: The business willing to give back (and
 there are many such businesses) are the ones that reap benefits. The
 companies that wilfully cling to zero-sum bullshit are on their own, by
 their own choice, and open themselves to allowing their competitors to
 take the advantage for themselves. That is the way of the world, that is
 the way of reality.

 D can't be held responsible for self-defeating zero-sum, "us vs them"
 mentalities. Sheesh.


 
 While I do think that there's a lot to be said for companies who are willing
 to use open source and give back to the community in the process, there are
 plenty of people (and not just companies) who just want a tool to get things
 done. And I don't think that there's anything wrong with that. 


I agree. The problem is with saying "I want X, and I'm not willing to 
offer anything for it." And then wondering why it doesn't work out.
Mar 22 2018
parent reply Jordan Wilson <wilsonjord gmail.com> writes:
On Friday, 23 March 2018 at 01:49:30 UTC, Nick Sabalausky 
(Abscissa) wrote:

 On 03/22/2018 09:44 PM, Jonathan M Davis wrote:

 On Thursday, March 22, 2018 21:25:11 Nick Sabalausky  via 
 Digitalmars-d
 wrote:

 On 03/18/2018 11:43 PM, Norm wrote:

 We don't want to be treated special. We don't want to give 
 back. This is
 the *entire* point.


 An attitude like that and there's any wonder it didn't work 
 out? Sheesh.

 This is the thing about OSS: The business willing to give 
 back (and
 there are many such businesses) are the ones that reap 
 benefits. The
 companies that wilfully cling to zero-sum bullshit are on 
 their own, by
 their own choice, and open themselves to allowing their 
 competitors to
 take the advantage for themselves. That is the way of the 
 world, that is
 the way of reality.

 D can't be held responsible for self-defeating zero-sum, "us 
 vs them"
 mentalities. Sheesh.


 
 While I do think that there's a lot to be said for companies 
 who are willing
 to use open source and give back to the community in the 
 process, there are
 plenty of people (and not just companies) who just want a tool 
 to get things
 done. And I don't think that there's anything wrong with that.


 I agree. The problem is with saying "I want X, and I'm not 
 willing to offer anything for it." And then wondering why it 
 doesn't work out.


I suppose it's about finding that balance between growing the D 
user base, and trying to get said user base to give back.

Say I was offered a car with no windscreen...I have 3 responses:
1. Cool! I'll put in a windscreen myself, as this car has a great 
engine.
2. Thanks. This car does a great job getting from a to b, pity 
about all these bugs flying in my face though. Wish I knew more 
about windscreens.
3. No thank you, I'll just stick with the train. Nice spinner 
rims, btw.

Regarding D, I fall into (2), but sometimes I wonder if catching 
the train would be easier...
Mar 23 2018
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 03/23/2018 03:35 AM, Jordan Wilson wrote:

 
 I suppose it's about finding that balance between growing the D user 
 base, and trying to get said user base to give back.
 
 Say I was offered a car with no windscreen...I have 3 responses:
 1. Cool! I'll put in a windscreen myself, as this car has a great engine.
 2. Thanks. This car does a great job getting from a to b, pity about all 
 these bugs flying in my face though. Wish I knew more about windscreens.
 3. No thank you, I'll just stick with the train. Nice spinner rims, btw.
 
 Regarding D, I fall into (2), but sometimes I wonder if catching the 
 train would be easier...


I used to be (2) with D, but that was something like ten years ago. At 
this point, it's more like a brand new sedan, well-built, reasonably 
priced, great mileage, a few minor things I've tweaked or done 
differently if I had a magic wand, but otherwise a car that leaves me 
wondering "Why are people whining about the lack of spinner support and 
iPhone whiz-bangery? Big effing deal."

That's NOT a comment on Manu's OP here, of course. Something like "Why 
is x^^y *still* not CTFE-able???" is the kind of thing I completely 
sympathize with. Can't imagine that sort of thing being a blocker 
though, especially if I were still doing a lot of work in C or C++.
Mar 23 2018
parent reply Manu <turkeyman gmail.com> writes:
On 23 March 2018 at 01:36, Nick Sabalausky (Abscissa) via
Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On 03/23/2018 03:35 AM, Jordan Wilson wrote:

 I suppose it's about finding that balance between growing the D user base,
 and trying to get said user base to give back.

 Say I was offered a car with no windscreen...I have 3 responses:
 1. Cool! I'll put in a windscreen myself, as this car has a great engine.
 2. Thanks. This car does a great job getting from a to b, pity about all
 these bugs flying in my face though. Wish I knew more about windscreens.
 3. No thank you, I'll just stick with the train. Nice spinner rims, btw.

 Regarding D, I fall into (2), but sometimes I wonder if catching the train
 would be easier...



 I used to be (2) with D, but that was something like ten years ago. At this
 point, it's more like a brand new sedan, well-built, reasonably priced,
 great mileage, a few minor things I've tweaked or done differently if I had
 a magic wand, but otherwise a car that leaves me wondering "Why are people
 whining about the lack of spinner support and iPhone whiz-bangery? Big
 effing deal."

 That's NOT a comment on Manu's OP here, of course. Something like "Why is
 x^^y *still* not CTFE-able???" is the kind of thing I completely sympathize
 with. Can't imagine that sort of thing being a blocker though, especially if
 I were still doing a lot of work in C or C++.


Like, in this particular project, being able to generate all tables at
compile time is the thing that distinguishes the D code from the C++
code; it's the *whole point*... If I have to continue to generate
tables offline and paste big tables of data in the source code (and
then re-generate them manually when I change something); then
situation is identical to C++, therefore, stick with C++.\

This is the practical reality with a lot of my outstanding issues with
D; we've covered an awful lot of ground in 10 years, but basic
outstanding issues like not being able to pass an rvalue as ref makes
the D code longer and uglier than the C++ code it's meant to replace.
There's no argument that can be made that advocates leaving C++
(established, entrenched) for an emerging language like D, when the
case-study is longer+uglier in D.

My experience today is; D can generate machinery that C++ can't even
dream of, which is awesome, but that usually represents a tiny
fraction of your code, usually packed up in a tight little box. For
the majority of 'just code that you write', D's biggest contributors
are ranges+slices, but in my experience (migrating C++ to D), that
stuff doesn't emerge until a couple of iterations after migration.
The initial migration focuses on translation, and when super-simple
code gets longer and uglier, that's not a good look, and tends to stop
people dead in their tracks.
And it's basically inexcusable. The most common frequent code that you
write shouldn't be longer/uglier in D. We need to be able to
demonstrate that the common case gets better (or at least stays the
same) just as much as the obscure and contrived case.
Mar 23 2018
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/23/2018 11:09 AM, Manu wrote:

 [...]


You make some good points. The CTFE one is kinda inexcusable on our part, 
because it was trivial to implement (just more or less add some table entries 
and some glue copying existing examples), and there were posts after posts here 
and on bugzilla talking about it and nobody doing anything about it.

Rvalue references are not trivial and can have major unintended consequences. 
They're a rather ugly feature in C++, with weirdities. I doubt D will ever have 
them.

Regarding ARC, we've tried on that front numerous times. Still we don't have a 
good RC solution, but it isn't for lack of trying.

But at some level, D cannot replace C++ on a line-by-line basis. There's always 
going to be something different. If not in the core language, in the way the 
standard library works. If you're heavily using templates and stuff in C++, 
you're likely going to have to rethink how the code works to get it in D (or
any 
other language).

For example, in my efforts translating C to D, the clumsy part is the 
metaprogramming in the C preprocessor. There's nothing there D cannot do, but
it 
has to be redesigned. The result is much better, but translating by rote is 
simply impossible.

Also, just try translating some of the code in Phobos to C++. It was tried to
do 
ranges for C++, and the result was terrifying. (It worked, but that's about all 
that could be said for it.)
Mar 23 2018
parent Manu <turkeyman gmail.com> writes:
On 23 March 2018 at 12:16, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 3/23/2018 11:09 AM, Manu wrote:

 [...]



 You make some good points. The CTFE one is kinda inexcusable on our part,
 because it was trivial to implement (just more or less add some table
 entries and some glue copying existing examples), and there were posts after
 posts here and on bugzilla talking about it and nobody doing anything about
 it.

 Rvalue references are not trivial and can have major unintended
 consequences. They're a rather ugly feature in C++, with weirdities. I doubt
 D will ever have them.


... totally started a new thread (sorry!)
;)



 Regarding ARC, we've tried on that front numerous times. Still we don't have
 a good RC solution, but it isn't for lack of trying.


I understand, and I don't feel like I've been hammering this one into
the dirt unfairly. Work appears to be ongoing, and I'm watching with
interest.
It has been a very long time coming though. I feel like it's a
breakthrough that we're all pretty much in agreement that it should
exist! That was a long fight on its own ;)


 [...]


Oops, new thread ;)
Mar 23 2018
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 23 March 2018 at 18:09:01 UTC, Manu wrote:

 [snip]

 Like, in this particular project, being able to generate all 
 tables at compile time is the thing that distinguishes the D 
 code from the C++ code; it's the *whole point*... If I have to 
 continue to generate tables offline and paste big tables of 
 data in the source code (and then re-generate them manually 
 when I change something); then situation is identical to C++, 
 therefore, stick with C++.\


You can use import expressions, but then you have to parse the 
string at compile-time to turn it into something useful, I 
suppose.
Mar 23 2018
prev sibling next sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 03/23/2018 02:09 PM, Manu wrote:

 If I have to continue to generate
 tables offline and paste big tables of data in the source code (and
 then re-generate them manually when I change something); then
 situation is identical to C++, therefore, stick with C++.\
 


WAT?

When in the world would anyone ever need to do any of that? And I mean 
*regardless* of language? What kind of build system are you even using, 
punch cards and sneakernet?

Just run your custom generator tool from your buildscript (it's a 
trivial one-liner), and have it generate a full-fledged .d file ready 
for import (or a data file which is then string-imported by your main 
program).

It's quick and trivial, I've been doing it for a project written in Haxe 

Unity3D conversion) and it works quick-and-easy even there (of course, 

write that way).

DMD itself used to do that too when it was still C-based. Nobody ever 
needed to manually re-regenerate it (it was automatically invoked when 
necessary by the makefile), and *certainly* nobody ever needed to go 
copy-pasting any generated data.
Mar 23 2018
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/23/2018 11:09 AM, Manu wrote:

 Like, in this particular project, being able to generate all tables at
 compile time is the thing that distinguishes the D code from the C++
 code; it's the *whole point*... If I have to continue to generate
 tables offline and paste big tables of data in the source code (and
 then re-generate them manually when I change something); then
 situation is identical to C++, therefore, stick with C++.\


This file:

   https://github.com/dlang/dmd/blob/master/src/dmd/backend/optabgen.c

computes tables, and writes several tables out to several .c files, which are 
then #include'd into the main build. It all happens automagically using the 
makefile:

   https://github.com/dlang/dmd/blob/master/src/win32.mak#L420

I've been using this technique continually since the early 1980's :-)

Some IDEs have problems with it, because they cannot support layered builds
like 
this, but good old make does it just fine.

I can't recall ever seeing anyone else use this technique (other than Nick!), 
but it works and isn't that bad.

The dmd front end used to do this as well, but that has since been replaced
with 
CTFE since it was converted to D.
Mar 24 2018
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 24, 2018 at 01:42:56AM -0700, Walter Bright via Digitalmars-d wrote:
[...]

 This file:
 
   https://github.com/dlang/dmd/blob/master/src/dmd/backend/optabgen.c
 
 computes tables, and writes several tables out to several .c files,
 which are then #include'd into the main build. It all happens
 automagically using the makefile:
 
   https://github.com/dlang/dmd/blob/master/src/win32.mak#L420
 
 I've been using this technique continually since the early 1980's :-)
 
 Some IDEs have problems with it, because they cannot support layered
 builds like this, but good old make does it just fine.


Thus proving that IDEs suck. ;-)



 I can't recall ever seeing anyone else use this technique (other than
 Nick!), but it works and isn't that bad.


It's not all that uncommon.  I've worked with projects (and still do)
where code is generated by a tool at build time, and then #include'd by
other source code.  Any project that uses lex/yacc (or their clones
flex/bison) does this. One of my own recent projects involved a clever
(IMO) trick of using the C preprocessor on a C header file (truetype, to
be precise) to generate D code that then gets compiled by a D compiler,
by suitably (re)defining certain macros.

Being able to do all this in CTFE instead is nice, but hardly a
*necessity*.  And to be frank, the slowness of CTFE hampers serious use
cases like generating parsers (it's definitely doable, as proven by
Pegged, but it does come with an unattractive increase in compilation
time (when will we see newCTFE materialize... *hint hint* :-P)).


T

-- 
Life begins when you can spend your spare time programming instead of watching
television. -- Cal Keegan
Mar 24 2018
parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 03/24/2018 09:53 AM, H. S. Teoh wrote:

 On Sat, Mar 24, 2018 at 01:42:56AM -0700, Walter Bright via Digitalmars-d
wrote:
 [...]

 I can't recall ever seeing anyone else use this technique (other than
 Nick!), but it works and isn't that bad.


 
 It's not all that uncommon.  I've worked with projects (and still do)
 where code is generated by a tool at build time, and then #include'd by
 other source code.  Any project that uses lex/yacc (or their clones
 flex/bison) does this. One of my own recent projects involved a clever
 (IMO) trick of using the C preprocessor on a C header file (truetype, to
 be precise) to generate D code that then gets compiled by a D compiler,
 by suitably (re)defining certain macros.
 


And the excellent, classic book "The Pragmatic Programmer" promoted it 
as a technique worth having in one's toolbelt (That book, along with 
"Writing Solid Code", left a big lasting impact on me.)

IIRC, in the earlier days of Gameboy Advance homebrew (back when I still 
had time for that sort of thing!) it was also the first common technique 
for including images/audio in a ROM image. (Until other tools were 
developed to handle the task better.)
Mar 24 2018
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On 24 March 2018 at 01:42, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 3/23/2018 11:09 AM, Manu wrote:

 Like, in this particular project, being able to generate all tables at
 compile time is the thing that distinguishes the D code from the C++
 code; it's the *whole point*... If I have to continue to generate
 tables offline and paste big tables of data in the source code (and
 then re-generate them manually when I change something); then
 situation is identical to C++, therefore, stick with C++.\



 This file:

   https://github.com/dlang/dmd/blob/master/src/dmd/backend/optabgen.c

 computes tables, and writes several tables out to several .c files, which
 are then #include'd into the main build. It all happens automagically using
 the makefile:

   https://github.com/dlang/dmd/blob/master/src/win32.mak#L420

 I've been using this technique continually since the early 1980's :-)

 Some IDEs have problems with it, because they cannot support layered builds
 like this, but good old make does it just fine.

 I can't recall ever seeing anyone else use this technique (other than
 Nick!), but it works and isn't that bad.

 The dmd front end used to do this as well, but that has since been replaced
 with CTFE since it was converted to D.


I understand table generation, that is the standard approach. It's
made awkward by the fact that build systems are hard, and numerous,
and a user of a lib with such build requirement inherits that baggage
into their project.
I'm not sure why I seem to have to defend the idea that it's a *great
thing* that D (in theory; according to the advertising brochure) does
away with these requirements.
It just occurred to me too that it's not even that simple. The
instantiation sites (which are in user code) dictate what tables need
to be emit. It's not feasible to generate all possible tables...
there's a combinatorial explosion of possible inputs. I instantiate
only what tables the user needs on demand. It's impossible to
pre-generate 'all' tables; there's no such quantity.
Mar 24 2018
next sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 03/24/2018 12:37 PM, Manu wrote:

 
 I understand table generation, that is the standard approach. It's


Huh? Then I guess I don't understand why you implied that the 
alternative to CTFE was manually regenerating and copy-pasting tables:


 On 3/23/2018 11:09 AM, Manu wrote:

 Like, in this particular project, being able to generate all tables at
 compile time is the thing that distinguishes the D code from the C++
 code; it's the *whole point*... If I have to continue to generate
 tables offline and paste big tables of data in the source code (and
 then re-generate them manually when I change something);








 I'm not sure why I seem to have to defend the idea that it's a *great
 thing* that D (in theory; according to the advertising brochure) does
 away with these requirements.


No need to defend it, we're all sold on it already. To clarify: I wasn't 
saying "no need for CTFE", I was saying: "If you *have* to work around 
an unfortunate CTFE limitation, like the missing x^^y, then it's not 
hard to do so *without* all that manual work you suggested".



 made awkward by the fact that build systems are hard,


The decent ones aren't. (And if you happen to be stuck with MSBuild, 
well, then my sincere condolences. I periodically use Unity3D and I wish 
soooo much it wasn't tied to MSBuild...or CLR for that matter, but I 
digress...frequently ;))

Frankly, if a buildsystem makes doing XYZ (ex: "executing a CLI command 
upon build") harder than it would be in a shellscript, then the given 
buildsystem sucks and you may as well replace it with a plain old script.



 and a user of a lib with such build requirement inherits that baggage
 into their project.


Meh, its about half an ounce of baggage for the user. (But again, yes, 
CTFE is still better...at least when it doesn't slow down their build 
too much). And its zero-baggage if the generated files aren't dependent 
on the user's code, though I see now (below) that's not the case for 
your project.



 It just occurred to me too that it's not even that simple. The
 instantiation sites (which are in user code) dictate what tables need
 to be emit. It's not feasible to generate all possible tables...
 there's a combinatorial explosion of possible inputs. I instantiate
 only what tables the user needs on demand. It's impossible to
 pre-generate 'all' tables; there's no such quantity.


I guess that does complicate it somewhat (and again, to be clear, being 
able to just do CTFE would obviously be far better than this) but FWIW, 
that still might not be difficult to overcome, depending on the exact 
nature of the problem: Whatever inputs are necessary for table 
generation, let the user specify them as cmdline args to your generator 
tool. Again, not ideal, but a perfectly feasible workaround in a pinch, 
and doesn't require abandoning all the *other* benefits of D.
Mar 24 2018
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/24/2018 9:37 AM, Manu wrote:

 I'm not sure why I seem to have to defend the idea that it's a *great
 thing* that D (in theory; according to the advertising brochure) does
 away with these requirements.


It is indeed a great idea. I'm just making the case that it isn't a blocker to 
not have it. It's inconvenient.

It's like you can code anything in C, even OOP. It's just inconvenient,
tedious, 
and error-prone to.
Mar 24 2018
parent Manu <turkeyman gmail.com> writes:
On 24 March 2018 at 18:10, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 3/24/2018 9:37 AM, Manu wrote:

 I'm not sure why I seem to have to defend the idea that it's a *great
 thing* that D (in theory; according to the advertising brochure) does
 away with these requirements.



 It is indeed a great idea. I'm just making the case that it isn't a blocker
 to not have it. It's inconvenient.

 It's like you can code anything in C, even OOP. It's just inconvenient,
 tedious, and error-prone to.


Instantiations of the tables are parametric. It would be impossible to
pre-generate tables for all possible instantiations.
I have no idea how the pre-gen tool would discover instantiations in
user code to know which tables to generate.
I guess the user would need to supply instantiation parameters to the
tool as well in advance to inform it which tables intend to be used...
I'm not even remotely interested in that experience. It's a blocker,
because I won't write that code. That's just a shitty experience.
Mar 24 2018
prev sibling parent reply Guillaume Piolat <notthat email.com> writes:
On Saturday, 24 March 2018 at 16:37:06 UTC, Manu wrote:

 I'm not sure why I seem to have to defend the idea that it's a 
 *great
 thing* that D (in theory; according to the advertising 
 brochure) does
 away with these requirements.


Manu is not the only one who has to write such programs because 
of ^^ (log, exp, cosh, sinh, tanh... need pow to be CTFE to be 
CTFE themselves).
It's a lot more unconvenient, and plain different semantics 
(can't parameterize the table based on a compile-time value) when 
compared to having working CTFE.
Mar 26 2018
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/26/2018 9:26 AM, Guillaume Piolat wrote:

 On Saturday, 24 March 2018 at 16:37:06 UTC, Manu wrote:

 I'm not sure why I seem to have to defend the idea that it's a *great
 thing* that D (in theory; according to the advertising brochure) does
 away with these requirements.


 
 Manu is not the only one who has to write such programs because of ^^ (log,
exp, 
 cosh, sinh, tanh... need pow to be CTFE to be CTFE themselves).
 It's a lot more unconvenient, and plain different semantics (can't
parameterize 
 the table based on a compile-time value) when compared to having working CTFE.


It is a great idea, and some ought to pull it:
https://github.com/dlang/dmd/pull/8071
Mar 26 2018
prev sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, March 26, 2018 16:26:38 Guillaume Piolat via Digitalmars-d wrote:

 On Saturday, 24 March 2018 at 16:37:06 UTC, Manu wrote:

 I'm not sure why I seem to have to defend the idea that it's a
 *great
 thing* that D (in theory; according to the advertising
 brochure) does
 away with these requirements.


 Manu is not the only one who has to write such programs because
 of ^^ (log, exp, cosh, sinh, tanh... need pow to be CTFE to be
 CTFE themselves).
 It's a lot more unconvenient, and plain different semantics
 (can't parameterize the table based on a compile-time value) when
 compared to having working CTFE.


I think that that we all agree that having these functions work with CTFE
would be great. The disagreement is mostly on how much of an inconvenience
it is or how big a deal that inconvenience is.

Ultimately, it's just a question of someone taking the time to do the work,
not whether the work is desirable. And fortunately, it looks like at least
some of those functions have had recent work done towards making them work
in CTFE (e.g. the PR that Walter linked to in another post).

- Jonathan M Davis
Mar 26 2018
parent Guillaume Piolat <notthat email.com> writes:
On Tuesday, 27 March 2018 at 02:23:50 UTC, Jonathan M Davis wrote:

 I think that that we all agree that having these functions work 
 with CTFE would be great. The disagreement is mostly on how 
 much of an inconvenience it is or how big a deal that 
 inconvenience is.

 Ultimately, it's just a question of someone taking the time to 
 do the work, not whether the work is desirable. And 
 fortunately, it looks like at least some of those functions 
 have had recent work done towards making them work in CTFE 
 (e.g. the PR that Walter linked to in another post).

 - Jonathan M Davis


That's great news!
Mar 27 2018
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On 22 March 2018 at 18:25, Nick Sabalausky (Abscissa) via
Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On 03/18/2018 11:43 PM, Norm wrote:

 We don't want to be treated special. We don't want to give back. This is
 the *entire* point.


 An attitude like that and there's any wonder it didn't work out? Sheesh.

 This is the thing about OSS: The business willing to give back (and there
 are many such businesses) are the ones that reap benefits. The companies
 that wilfully cling to zero-sum bullshit are on their own, by their own
 choice, and open themselves to allowing their competitors to take the
 advantage for themselves. That is the way of the world, that is the way of
 reality.

 D can't be held responsible for self-defeating zero-sum, "us vs them"
 mentalities. Sheesh.


Small companies are often at a resource-shortage as it is... they
probably wouldn't be looking for potential productivity increase
opportunities (like using D instead of C) if that wasn't the case.
Mar 22 2018
parent bachmeier <no spam.net> writes:
On Friday, 23 March 2018 at 02:42:12 UTC, Manu wrote:


 Small companies are often at a resource-shortage as it is... 
 they probably wouldn't be looking for potential productivity 
 increase opportunities (like using D instead of C) if that 
 wasn't the case.


IMO we need to be honest with them so they don't waste time on D 
that they don't have if it can't meet their needs. There's a 
non-zero chance that you'll run into problems, and they need to 
know that they might have to do some things themselves, and move 
on if that's not something they can do.
Mar 22 2018
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On 18 March 2018 at 19:56, Norm via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Monday, 19 March 2018 at 00:59:45 UTC, Manu wrote:

 On 18 March 2018 at 17:28, Joakim via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 Perhaps the community simply has different priorities than you? For
 example, my Android port has never gotten much use either, which is fine as
 I primarily did that work for myself.

 Nevertheless, you have to think of D as like working in a startup: if you
 see something that you think needs doing, you have to drive it yourself or
 it will never get done. Pretty much the same for most any OSS project too.



 This is such an easy and readily-deploy-able response here.
 What you say is true, and I totally understand this... but at the same
 time, that's not actually the relationship I want to have with my
 tool. A startup probably shouldn't still be a startup 10 years later.

 In your case, doing the android work was obviously an interest you had
 on the side, and you gain something from the work itself.
 I have a small amount of that, but that's not where I'm at, and it
 never has been. I want to use D to do my job, because I'm fed up with
 C++. I want to engage in D the way I think D should **EXPECT** it's
 users to engage in D; as an end-user, who uses the tool to get their
 jobs done.
 If D is a large-ish scale hobby project among a bunch of people with
 mutual interests, then that should be more clearly communicated, but I
 don't think that's the intent, and I feel perfectly fine interacting
 with D in the way D is intended to be interacted with.

 Incidentally, this particular work I'm doing is on a multimedia library
 intended for the community... so I really am truly trying to contribute
 something of value!! But like most of my projects, I tend to get blocked at
 some point, and then it goes on hold indefinitely.



 +1024 bytes

 I think D is a terrific language worthy of all the praise it gets and it is
 way way more stable than it was 3yrs ago. But the attitude of submit a PR if
 you want it fixed works very much against D. Like it or not these forums are
 a front page on the D marketing campaign.

 My workplace has stopped using D after a 6 month trial, which finished in
 Jan 2018. Several developers did post here during that period when blocked
 by a bug or incomplete feature, only to be told if they want it fixed they
 can always submit a PR.

 Inevitably when told this they simply dropped D and went back to C++ and
 Python. And they made a point to bring this experience up at the final
 go/no-go meeting.

 The majority of developers, including those voting for D, had these common
 opinions (much to my disappointment)

 a) We're not in the business of developing and maintaining D, but it seems
 that is what we would need to do as a company. We are better off with C++
 and Python.

 b) D feels like C++ did back in the mid 90's. A time when we avoided
 templates and often the STL because compiler implementations were too buggy.
 We are better off with C++ and Python.


 I keep pushing D here but now it is a bit of a joke when I bring it up. I've
 become "the D guy" and it isn't discussed seriously any more by other
 developers, except a select few.


I know these feels so well.
People take their one experience, and that's the truth on the matter.
The sad part is, it's actually a massive missed opportunity! If these
colleagues posted here, and instead were greeted by recognition of
their issue, and provided a satisfactory work-around, or even a prompt
fix, they would have taken a COMPLETELY different message away from
their interaction; it would be "this D comunity is so awesome, I can
have confidence that our issues will be handled in a personalised
way!", and there's very strong value in that for a business...
Mar 18 2018
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 03/18/2018 11:28 PM, Manu wrote:

 
 I know these feels so well.
 People take their one experience, and that's the truth on the matter.
 The sad part is, it's actually a massive missed opportunity! If these
 colleagues posted here, and instead were greeted by recognition of
 their issue, and provided a satisfactory work-around, or even a prompt
 fix, they would have taken a COMPLETELY different message away from
 their interaction; it would be "this D comunity is so awesome, I can
 have confidence that our issues will be handled in a personalised
 way!", and there's very strong value in that for a business...
 


Well *of course* they would love any group that does custom work for 
them for free! ;)

But I think, therein lies one of the big shortcomings we have in 
promoting D:

Around here, we complain and whine and...erm...b***h (don't need another 
of Walter's secret PC-enforment emails) about "this is a volunteer 
project, we're not getting paid for this, blah blah blah"...

*AND YET*: We don't have NO crystal clear, obvious way for people to 
actually say "I need this, SO HERE, TAKE MY MONEY IN EXCHANGE FOR IT!!!" 
(Sure, we know that Walter's been open to stuff like that, but do 
prospective D users know that?)

That's what we need. Solves everyone's problems. Improves D. Gets us 
around the "not backed by a company" problems. Brings businesses into D 
instead of turning them away at the gates. I mean, shoot: *We* want 
users, we want money, we want to get paid to work on/with D. *They* have 
money and want things done. Let's get together, right?!! Everybody happy!
Mar 22 2018
next sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 03/22/2018 09:43 PM, Nick Sabalausky (Abscissa) wrote:

 On 03/18/2018 11:28 PM, Manu wrote:

 I know these feels so well.
 People take their one experience, and that's the truth on the matter.
 The sad part is, it's actually a massive missed opportunity! If these
 colleagues posted here, and instead were greeted by recognition of
 their issue, and provided a satisfactory work-around, or even a prompt
 fix, they would have taken a COMPLETELY different message away from
 their interaction; it would be "this D comunity is so awesome, I can
 have confidence that our issues will be handled in a personalised
 way!", and there's very strong value in that for a business...


 
 Well *of course* they would love any group that does custom work for 
 them for free! ;)
 
 But I think, therein lies one of the big shortcomings we have in 
 promoting D:
 
 Around here, we complain and whine and...erm...b***h (don't need another 
 of Walter's secret PC-enforment emails) about "this is a volunteer 
 project, we're not getting paid for this, blah blah blah"...
 
 *AND YET*: We don't have NO crystal clear, obvious way for people to 
 actually say "I need this, SO HERE, TAKE MY MONEY IN EXCHANGE FOR IT!!!" 
 (Sure, we know that Walter's been open to stuff like that, but do 
 prospective D users know that?)
 
 That's what we need. Solves everyone's problems. Improves D. Gets us 
 around the "not backed by a company" problems. Brings businesses into D 
 instead of turning them away at the gates. I mean, shoot: *We* want 
 users, we want money, we want to get paid to work on/with D. *They* have 
 money and want things done. Let's get together, right?!! Everybody happy!


Shoot, *just* noticed now this new opencollective stuff *does* offer that!

That needs to go straight up on the dlang front page, stat!!!
Mar 22 2018
prev sibling parent Norm <norm.rowtree gmail.com> writes:
On Friday, 23 March 2018 at 01:43:49 UTC, Nick Sabalausky 
(Abscissa) wrote:

 On 03/18/2018 11:28 PM, Manu wrote:

 
 I know these feels so well.
 People take their one experience, and that's the truth on the 
 matter.
 The sad part is, it's actually a massive missed opportunity! 
 If these
 colleagues posted here, and instead were greeted by 
 recognition of
 their issue, and provided a satisfactory work-around, or even 
 a prompt
 fix, they would have taken a COMPLETELY different message away 
 from
 their interaction; it would be "this D comunity is so awesome, 
 I can
 have confidence that our issues will be handled in a 
 personalised
 way!", and there's very strong value in that for a business...
 


 Well *of course* they would love any group that does custom 
 work for them for free! ;)


[snip]

All that was expected of D in the tests that I supervised was 
zero blocking bugs and documented features to be complete and 
working as advertised. We did not expect special treatment or new 
features to be implemented on whim without giving back in time or 
cash.

While personally I agree with your sentiments regarding OSS, my 
experience has been that most companies will only donate cash or 
time when a tool has already proven itself to be a useful.

Cheers,
Norm
Mar 22 2018
prev sibling next sibling parent nkm1 <t4nk074 openmailbox.org> writes:
On Monday, 19 March 2018 at 02:56:32 UTC, Norm wrote:

 +1024 bytes

 I think D is a terrific language worthy of all the praise it 
 gets and it is way way more stable than it was 3yrs ago. But 
 the attitude of submit a PR if you want it fixed works very 
 much against D. Like it or not these forums are a front page on 
 the D marketing campaign.


But do you know that? Maybe without that attitude fewer PRs would 
have been submitted. Perhaps that attitude works, just doesn't 
work well enough for your purposes. But maybe without that 
attitude D would've been even less suitable for you?


 a) We're not in the business of developing and maintaining D, 
 but it seems that is what we would need to do as a company. We 
 are better off with C++ and Python.

 b) D feels like C++ did back in the mid 90's. A time when we 
 avoided templates and often the STL because compiler 
 implementations were too buggy. We are better off with C++ and 
 Python.


So you rejected D because of compiler bugs, missing tools, etc., 
not because of nasty attitude of some people on the forums? Fair 
enough, and it's entirely possible that DMD (or whatever) is not 
good enough for you, but what makes you think that improving the 
attitude would do anything to fix bugs? Only PRs can do that.

Anyway, as far as I can tell, when people answer to complainers 
"send a PR or GTFO", they're just telling it like it is. Ignoring 
the reality won't make it stop being the objective state of 
affairs.


 D claims to be "Industry Proven and Ready" but we have to 
 submit PRs
 or get special treatment from Walter to use it effectively? 
 Sorry, but
 this is why many feel that D is still just a hobby project.


D doesn't "claim" anything, it's just a programming language. 
Some people claim some things, it's your job to determine how 
true their propaganda is.
Also, what is wrong or unworthy about hobby projects? Pretty sure 
my hobby (which is not hacking on DMD) is a lot more important 
(to me) than your medical company ;)
Mar 18 2018
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/18/2018 7:56 PM, Norm wrote:

 My workplace has stopped using D after a 6 month trial, which finished in Jan 
 2018. Several developers did post here during that period when blocked by a
bug 
 or incomplete feature, only to be told if they want it fixed they can always 
 submit a PR.


What are the bugzilla issues on those?
Mar 22 2018
parent reply Norm <norm.rowtree gmail.com> writes:
On Friday, 23 March 2018 at 03:28:05 UTC, Walter Bright wrote:

 On 3/18/2018 7:56 PM, Norm wrote:

 My workplace has stopped using D after a 6 month trial, which 
 finished in Jan 2018. Several developers did post here during 
 that period when blocked by a bug or incomplete feature, only 
 to be told if they want it fixed they can always submit a PR.


 What are the bugzilla issues on those?


This is just a few cut-paste from the collated list. Some were 
reported but found later to be duplicates, many were existing 
bugs, so no new bugzilla was created in those cases.

https://issues.dlang.org/show_bug.cgi?id=18055
https://issues.dlang.org/show_bug.cgi?id=17942
https://issues.dlang.org/show_bug.cgi?id=16317
https://issues.dlang.org/show_bug.cgi?id=16189
https://issues.dlang.org/show_bug.cgi?id=17949
https://issues.dlang.org/show_bug.cgi?id=15511
https://issues.dlang.org/show_bug.cgi?id=16107

We had no problem with installation or IDE support like many 
forum posts seem to talk about. Untar DMD tarball just worked 
when bin put on the path for Win, Mac and Linux. This easy 
installation to $HOME/somewhere was a bonus most developers liked 
and many thought even nicer than installing Python.

I feel like I've been bashing D here but that wasn't my intention 
at all. I am a D convert, broken beyond repair. All our 
developers liked D as a language. The biggest win I think was the 
ability to write code that cleanly brought together C, C++ and 
Python.

Cheers,
Norm
Mar 22 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/22/2018 9:15 PM, Norm wrote:

 On Friday, 23 March 2018 at 03:28:05 UTC, Walter Bright wrote:

 What are the bugzilla issues on those?


 
 This is just a few cut-paste from the collated list. Some were reported but 
 found later to be duplicates, many were existing bugs, so no new bugzilla was 
 created in those cases.
 
 https://issues.dlang.org/show_bug.cgi?id=18055
 https://issues.dlang.org/show_bug.cgi?id=17942
 https://issues.dlang.org/show_bug.cgi?id=16317
 https://issues.dlang.org/show_bug.cgi?id=16189
 https://issues.dlang.org/show_bug.cgi?id=17949
 https://issues.dlang.org/show_bug.cgi?id=15511
 https://issues.dlang.org/show_bug.cgi?id=16107


Thank you. I have tagged them with the "Industry" keyword, which is for issues 
raised by people using D in industrial situations. The last one (16107) is 
marked as resolved and appears to have been fixed.
Mar 22 2018
parent reply Norm <norm.rowtree gmail.com> writes:
On Friday, 23 March 2018 at 05:24:48 UTC, Walter Bright wrote:

 On 3/22/2018 9:15 PM, Norm wrote:

 On Friday, 23 March 2018 at 03:28:05 UTC, Walter Bright wrote:

 What are the bugzilla issues on those?


 
 This is just a few cut-paste from the collated list. Some were 
 reported but found later to be duplicates, many were existing 
 bugs, so no new bugzilla was created in those cases.
 
 https://issues.dlang.org/show_bug.cgi?id=18055
 https://issues.dlang.org/show_bug.cgi?id=17942
 https://issues.dlang.org/show_bug.cgi?id=16317
 https://issues.dlang.org/show_bug.cgi?id=16189
 https://issues.dlang.org/show_bug.cgi?id=17949
 https://issues.dlang.org/show_bug.cgi?id=15511
 https://issues.dlang.org/show_bug.cgi?id=16107


 Thank you. I have tagged them with the "Industry" keyword, 
 which is for issues raised by people using D in industrial 
 situations. The last one (16107) is marked as resolved and 
 appears to have been fixed.


Thanks, sorry that was my mistake (posting in a hurry). It was 
this bug:

https://issues.dlang.org/show_bug.cgi?id=16108
(hardly what I would call a blocker, but I didn't make the list)

Looking at bugzilla I see this is also now fixed but we were on 
2.074 at the time. Sorry I don't have more specific details, it 
was hard enough just to get some devs to create bugzilla accounts 
let alone find existing tickets or raise new tickets.

As I was trying to point out before but unfortunately came across 
as just a negative git; many developers agreed that D is a 
fantastic language, but they have zero interest in developing or 
even raising tickets when D doesn't just work. I think the main 
reason for this is because they expect a C++/Python like 
experience where your rarely hit a compiler/interpreter bug.

This seems to be the majority of developers I talk to, so it is a 
hard sell, but on the bright side I'm starting to see more and 
more internal tools here written in D :)

Cheers,
Norm
Mar 23 2018
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On Friday, 23 March 2018 at 09:37:26 UTC, Norm wrote:


 I think the main reason for this is because they expect a 
 C++/Python like experience where your rarely hit a 
 compiler/interpreter bug.


What happens if they found a bug in C++ or Python?

--
/Jacob Carlborg
Mar 23 2018
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 23.03.2018 13:06, Jacob Carlborg wrote:

 On Friday, 23 March 2018 at 09:37:26 UTC, Norm wrote:
 

 I think the main reason for this is because they expect a C++/Python 
 like experience where your rarely hit a compiler/interpreter bug.


 
 What happens if they found a bug in C++ or Python?
 
 -- 
 /Jacob Carlborg


The process is very similar to when they hit it in DMD:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51664

This is an anecdote, of course, but for perspective: this bug was known 
for ~7 years before I posted the duplicate and it took another 5 years 
from my report until it was fixed.

Note that the first answer I got was "I don't think [this report] is 
valid". I guess it is easier to not blame the compiler if you are not 
sure whether you understand the language definition correctly.
Mar 23 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/23/2018 8:15 AM, Timon Gehr wrote:

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51664


The money shot: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51664#c3
Mar 23 2018
parent reply Manu <turkeyman gmail.com> writes:
On 23 March 2018 at 11:24, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 3/23/2018 8:15 AM, Timon Gehr wrote:

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51664



 The money shot: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51664#c3


Thing is, C++ has nothing to prove; it's already accepted as de-facto
standard. People have decades of familiarity and comfort with C++'s
edges. As I've said before, on first look at D, they need to see a
sparkling promised land; not a new set of edges they need to learn and
be aware of. People aren't interested in trading one edgy language for
another.
Trust me, these impressions are __super important__, and offering of
work-around's are unlikely to be considered satisfactory responses,
likewise pointing at things that suck about C++; it's not a defence,
they already know all too well!
When I do demo's, I tend to carefully guide the process such that we
avoid hitting a stream of edges I know about. People are already
sceptical and desperately looking for a reason to dismiss the whole
thing entirely. Most people seem to hate learning new stuff ;)
Key is to make a convincing sell consistently, and we're getting
dangerously close to that point I reckon.

Here's another one of these apparently trivial cases which is highly
likely to emerge for a new user (ie, has, in my experience, and I have
to 'explain' the situation, which is anti-merit):
https://github.com/dlang/dmd/pull/8031
Mar 23 2018
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 23.03.2018 20:02, Manu wrote:

 Here's another one of these apparently trivial cases which is highly
 likely to emerge for a new user (ie, has, in my experience, and I have
 to 'explain' the situation, which is anti-merit):
 https://github.com/dlang/dmd/pull/8031


The language grammar has a nontrivial amount of unintuitive cases like 
this one, I guess due to historical reasons. We ought to just merge the 
type and expression grammar and let the compiler figure out whether an 
AST node is a type or an expression within semantic. I might write a DIP 
for this after pushing the tuple DIP.
Mar 23 2018
prev sibling next sibling parent reply bauss <jj_1337 live.dk> writes:
On Friday, 23 March 2018 at 09:37:26 UTC, Norm wrote:

 I think the main reason for this is because they expect a 
 C++/Python like experience where your rarely hit a 
 compiler/interpreter bug.

 Cheers,
 Norm


What do you mean?

https://gcc.gnu.org/bugzilla/buglist.cgi?component=c%2B%2B&product=gcc&resolution=---
Mar 23 2018
parent Jacob Carlborg <doob me.com> writes:
On 2018-03-23 13:34, bauss wrote:


 What do you mean?
 
 https://gcc.gnu.org/bugzilla/buglist.cgi?component=c%2B%2B&produc
=gcc&resolution=--- 


That's only limited to 500, here's a list of 10 000:

https://gcc.gnu.org/bugzilla/buglist.cgi?component=c%2B%2B&limit=0&order=bug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=gcc&query_format=advanced

-- 
/Jacob Carlborg
Mar 24 2018
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On 23 March 2018 at 02:37, Norm via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Looking at bugzilla I see this is also now fixed but we were on 2.074 at the
 time. Sorry I don't have more specific details, it was hard enough just to
 get some devs to create bugzilla accounts let alone find existing tickets or
 raise new tickets.


I can echo this experience. I think only two colleagues (out of quite
a lot) of mine have ever created a bugzilla account.
Most of them get to the point where they see a website that looks like
it's from the 90's and it wants you to create
yet-another-internet-account™, they just close the page.
Nobody wants more internet accounts.

This happened to me again on Tuesday this week...
Mar 23 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/23/2018 11:14 AM, Manu wrote:

 I can echo this experience. I think only two colleagues (out of quite
 a lot) of mine have ever created a bugzilla account.
 Most of them get to the point where they see a website that looks like
 it's from the 90's and it wants you to create
 yet-another-internet-account™, they just close the page.
 Nobody wants more internet accounts.


I have no idea how they can use git, since that has a user interface from the 
1970's :-) github itself may look modern, but it's a rube goldberg construction 
that is hardly user discoverable.



 This happened to me again on Tuesday this week...


All bugzilla requires is a name and a password. It does not do any
verification. 
Heck, just type in xxx yyy and it'll work. This trivial bit of effort makes it 
effective in preventing troll posts :-)
Mar 23 2018
next sibling parent Manu <turkeyman gmail.com> writes:
On 23 March 2018 at 12:02, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 3/23/2018 11:14 AM, Manu wrote:

 I can echo this experience. I think only two colleagues (out of quite
 a lot) of mine have ever created a bugzilla account.
 Most of them get to the point where they see a website that looks like
 it's from the 90's and it wants you to create
 yet-another-internet-account™, they just close the page.
 Nobody wants more internet accounts.


 I have no idea how they can use git, since that has a user interface from
 the 1970's :-) github itself may look modern, but it's a rube goldberg
 construction that is hardly user discoverable.


Oh, I've put a LOT of effort into trying to sell git (very
successfully) too!! ;)
Fortunately, git has loads of good clients now. Particularly on Windows.



 This happened to me again on Tuesday this week...


 All bugzilla requires is a name and a password. It does not do any
 verification. Heck, just type in xxx yyy and it'll work. This trivial bit of
 effort makes it effective in preventing troll posts :-)


Well, my colleague isn't a troll. A genuinely interested party, but
he's not gonna go out of his way for it. I can't control the natural
reaction that most people have to being confronted with a registration
page.
I'd suggest openauth, and people using their github accounts; I think
that's what people expect. I mean, most people just expect the bug
tracker to BE on github ;)
Mar 23 2018
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, March 23, 2018 12:13:58 Manu via Digitalmars-d wrote:

 On 23 March 2018 at 12:02, Walter Bright via Digitalmars-d

 <digitalmars-d puremagic.com> wrote:

 On 3/23/2018 11:14 AM, Manu wrote:

 This happened to me again on Tuesday this week...


 All bugzilla requires is a name and a password. It does not do any
 verification. Heck, just type in xxx yyy and it'll work. This trivial
 bit of effort makes it effective in preventing troll posts :-)


 Well, my colleague isn't a troll. A genuinely interested party, but
 he's not gonna go out of his way for it. I can't control the natural
 reaction that most people have to being confronted with a registration
 page.
 I'd suggest openauth, and people using their github accounts; I think
 that's what people expect. I mean, most people just expect the bug
 tracker to BE on github ;)


Really? I've dealt with relatively few projects that use github as a bug
tracker, and it's been my experience that most anything that's really
serious has its own bugtracker (usually some form of bugzilla) - though most
such projects predate github by a long shot. I'd think that signing up for a
bugtracker would be par for the course and that if anything, the fact that a
project was using github issues instead of its own bugtracker would imply
that it was small, which doesn't necessarily give a good impression -
especially for a compiler.

And with how simplistic github issues are in comparison to bugzilla, I don't
know why you'd want to use it other than the fact that you don't have to go
to the effort of setting up your own bugzilla. I'd certainly hate to see us
switch to github issues just because a few folks weren't willing to sign up
for a bugzilla account, though for whatever reason, some folks keep pushing
for us to switch over.

- Jonathan M Davis
Mar 23 2018
parent Jacob Carlborg <doob me.com> writes:
On 2018-03-23 20:25, Jonathan M Davis wrote:


 Really? I've dealt with relatively few projects that use github as a bug
 tracker, and it's been my experience that most anything that's really
 serious has its own bugtracker (usually some form of bugzilla) - though most
 such projects predate github by a long shot. I'd think that signing up for a
 bugtracker would be par for the course and that if anything, the fact that a
 project was using github issues instead of its own bugtracker would imply
 that it was small, which doesn't necessarily give a good impression -
 especially for a compiler.


I think it's related to the culture of the language. Have a look at Ruby 
on Rails [1] for example. Basically the biggest Ruby project there is, 
it's using GitHub for issue tracking.

[1] https://github.com/rails/rails/issues

-- 
/Jacob Carlborg
Mar 24 2018
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On 23 March 2018 at 12:25, Jonathan M Davis via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Friday, March 23, 2018 12:13:58 Manu via Digitalmars-d wrote:

 On 23 March 2018 at 12:02, Walter Bright via Digitalmars-d

 <digitalmars-d puremagic.com> wrote:

 On 3/23/2018 11:14 AM, Manu wrote:

 This happened to me again on Tuesday this week...


 All bugzilla requires is a name and a password. It does not do any
 verification. Heck, just type in xxx yyy and it'll work. This trivial
 bit of effort makes it effective in preventing troll posts :-)


 Well, my colleague isn't a troll. A genuinely interested party, but
 he's not gonna go out of his way for it. I can't control the natural
 reaction that most people have to being confronted with a registration
 page.
 I'd suggest openauth, and people using their github accounts; I think
 that's what people expect. I mean, most people just expect the bug
 tracker to BE on github ;)


 Really? I've dealt with relatively few projects that use github as a bug
 tracker, and it's been my experience that most anything that's really
 serious has its own bugtracker (usually some form of bugzilla) - though most
 such projects predate github by a long shot. I'd think that signing up for a
 bugtracker would be par for the course and that if anything, the fact that a
 project was using github issues instead of its own bugtracker would imply
 that it was small, which doesn't necessarily give a good impression -
 especially for a compiler.

 And with how simplistic github issues are in comparison to bugzilla, I don't
 know why you'd want to use it other than the fact that you don't have to go
 to the effort of setting up your own bugzilla. I'd certainly hate to see us
 switch to github issues just because a few folks weren't willing to sign up
 for a bugzilla account, though for whatever reason, some folks keep pushing
 for us to switch over.


I'm not suggesting switch to github. I've never suggested that. I
understand it's inferior.
I'm suggesting supporting openauth.
Mar 23 2018
next sibling parent Seb <seb wilzba.ch> writes:
On Friday, 23 March 2018 at 20:38:38 UTC, Manu wrote:

 On 23 March 2018 at 12:25, Jonathan M Davis via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:

 On Friday, March 23, 2018 12:13:58 Manu via Digitalmars-d 
 wrote:

 On 23 March 2018 at 12:02, Walter Bright via Digitalmars-d

 <digitalmars-d puremagic.com> wrote:

 On 3/23/2018 11:14 AM, Manu wrote:

 This happened to me again on Tuesday this week...


 All bugzilla requires is a name and a password. It does not 
 do any verification. Heck, just type in xxx yyy and it'll 
 work. This trivial bit of effort makes it effective in 
 preventing troll posts :-)


 Well, my colleague isn't a troll. A genuinely interested 
 party, but
 he's not gonna go out of his way for it. I can't control the 
 natural
 reaction that most people have to being confronted with a 
 registration
 page.
 I'd suggest openauth, and people using their github accounts; 
 I think
 that's what people expect. I mean, most people just expect 
 the bug
 tracker to BE on github ;)


 Really? I've dealt with relatively few projects that use 
 github as a bug tracker, and it's been my experience that most 
 anything that's really serious has its own bugtracker (usually 
 some form of bugzilla) - though most such projects predate 
 github by a long shot. I'd think that signing up for a 
 bugtracker would be par for the course and that if anything, 
 the fact that a project was using github issues instead of its 
 own bugtracker would imply that it was small, which doesn't 
 necessarily give a good impression - especially for a compiler.

 And with how simplistic github issues are in comparison to 
 bugzilla, I don't know why you'd want to use it other than the 
 fact that you don't have to go to the effort of setting up 
 your own bugzilla. I'd certainly hate to see us switch to 
 github issues just because a few folks weren't willing to sign 
 up for a bugzilla account, though for whatever reason, some 
 folks keep pushing for us to switch over.


 I'm not suggesting switch to github. I've never suggested that. 
 I
 understand it's inferior.
 I'm suggesting supporting openauth.


Hold your breath - Vladimir is silently working on getting 
Mozilla's Bugzilla fork mainstream again.
Actually it's not so silent - the Mozilla people call his work 
"near-heroic efforts":

https://dylan.hardison.net/2018/03/18/bugzilla-harmony-news

Some pointers:

https://github.com/CyberShadow/bmo
http://dbugs.k3.1azy.net

And yes it will support OAuth 2.0 - but just GitHub Auth for the 
time being because that's the most important one. The full list 
is here:

https://github.com/CyberShadow/bugzilla-meta/blob/master/notes.org

You can join e.g. #dlang_org on Slack for more discussions about 
this.
Mar 23 2018
prev sibling parent reply Nick Sabalausky <a a.a> writes:
On Friday, 23 March 2018 at 20:38:38 UTC, Manu wrote:

 I'm not suggesting switch to github. I've never suggested that. 
 I
 understand it's inferior.
 I'm suggesting supporting openauth.


OAuth is a phisher's paradise.

But that aside, it's never made any sense to me for projects to 
self-impose a policy of "If you've found a bug, and you're 
non-registered, we don't want to hear about it."

I would think any self-respecting project would WANT to lower the 
barrier to being notified of problems, not put roadblocks in the 
way: That's what outsourced call centers are for!
Mar 23 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, March 23, 2018 23:37:18 Nick Sabalausky via Digitalmars-d wrote:

 I would think any self-respecting project would WANT to lower the
 barrier to being notified of problems, not put roadblocks in the
 way: That's what outsourced call centers are for!


Part of the problem with that is the sheer number of spammers out there.
Signing up is a pretty minimal barrier to entry, and it's mostly prevented
spam from showing up in bugzilla. And if someone isn't willing to take a few
minutes to sign up for a bugzilla account, that implies that they don't care
very much.

Yes, we want the barrier to entry to be minimal, but that doesn't mean that
it makes sense to make it zero.

- Jonathan M Davis
Mar 23 2018
parent reply Nick Sabalausky <a a.a> writes:
On Saturday, 24 March 2018 at 00:08:17 UTC, Jonathan M Davis 
wrote:

 On Friday, March 23, 2018 23:37:18 Nick Sabalausky via 
 Digitalmars-d wrote:

 I would think any self-respecting project would WANT to lower 
 the barrier to being notified of problems, not put roadblocks 
 in the way: That's what outsourced call centers are for!


 Part of the problem with that is the sheer number of spammers 
 out there. Signing up is a pretty minimal barrier to entry, and 
 it's mostly prevented spam from showing up in bugzilla. And if 
 someone isn't willing to take a few minutes to sign up for a 
 bugzilla account, that implies that they don't care very much.

 Yes, we want the barrier to entry to be minimal, but that 
 doesn't mean that it makes sense to make it zero.


Yea, but there are less obtrusive ways of preventing spam posts. 
Like the modern crop of captchas.
Mar 23 2018
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, March 24, 2018 00:39:03 Nick Sabalausky via Digitalmars-d 
wrote:

 On Saturday, 24 March 2018 at 00:08:17 UTC, Jonathan M Davis

 wrote:

 On Friday, March 23, 2018 23:37:18 Nick Sabalausky via

 Digitalmars-d wrote:

 I would think any self-respecting project would WANT to lower
 the barrier to being notified of problems, not put roadblocks
 in the way: That's what outsourced call centers are for!


 Part of the problem with that is the sheer number of spammers
 out there. Signing up is a pretty minimal barrier to entry, and
 it's mostly prevented spam from showing up in bugzilla. And if
 someone isn't willing to take a few minutes to sign up for a
 bugzilla account, that implies that they don't care very much.

 Yes, we want the barrier to entry to be minimal, but that
 doesn't mean that it makes sense to make it zero.


 Yea, but there are less obtrusive ways of preventing spam posts.
 Like the modern crop of captchas.


I really, really, really hope that we never see captchas on bugzilla. I'd
sign up for an account any day of the week to avoid having to deal with
captchas. IMHO, captchas are one of the most annoying inventions known to
man. And I really don't understand why it's a big deal to have to have to
sign up to report a bug. You need to give your e-mail address anyway if you
want to receive any updates on the bug. IMHO, it makes perfect sense that
signing up for an account would be involved with that.

- Jonathan M Davis
Mar 23 2018
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2018-03-24 00:37, Nick Sabalausky wrote:


 OAuth is a phisher's paradise.
 
 But that aside, it's never made any sense to me for projects to 
 self-impose a policy of "If you've found a bug, and you're 
 non-registered, we don't want to hear about it."
 
 I would think any self-respecting project would WANT to lower the 
 barrier to being notified of problems, not put roadblocks in the way: 
 That's what outsourced call centers are for!


And even worse, projects that use a bot to automatically close issues 
that are too old and haven't seen any activity. Just because it's old 
and the maintainers didn't want to work on the bug doesn't mean the bug 
is gone.

-- 
/Jacob Carlborg
Mar 24 2018
prev sibling parent Joakim <dlang joakim.fea.st> writes:
Been meaning to respond to this for some time now, finally got 
around to it. :)

On Monday, 19 March 2018 at 00:59:45 UTC, Manu wrote:

 On 18 March 2018 at 17:28, Joakim via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:

 Perhaps the community simply has different priorities than 
 you? For example, my Android port has never gotten much use 
 either, which is fine as I primarily did that work for myself.

 Nevertheless, you have to think of D as like working in a 
 startup: if you see something that you think needs doing, you 
 have to drive it yourself or it will never get done. Pretty 
 much the same for most any OSS project too.


 This is such an easy and readily-deploy-able response here.
 What you say is true, and I totally understand this... but at 
 the same
 time, that's not actually the relationship I want to have with 
 my
 tool. A startup probably shouldn't still be a startup 10 years 
 later.


Then maybe D is the wrong tool for you?  Almost any tool that I 
know of, you either have to pay a ton of money or be willing to 
invest a ton of your development time to maintain yourself.  D is 
in the latter camp for anything serious, which is why Weka 
contracts with the ldc devs and Sociomantic wrote their own 
garbage collector and Ocean  nogc libraries.

There are a few exceptions to this rule, ie clang mostly 
open-sourced by Apple and available for free, but almost no tools 
work that way. You seem to expect D to work like clang without 
having an Apple behind it, only the largest company on the 
planet! :)


 In your case, doing the android work was obviously an interest 
 you had
 on the side, and you gain something from the work itself.
 I have a small amount of that, but that's not where I'm at, and 
 it
 never has been. I want to use D to do my job, because I'm fed 
 up with
 C++. I want to engage in D the way I think D should **EXPECT** 
 it's
 users to engage in D; as an end-user, who uses the tool to get 
 their
 jobs done.


Great, you can all pay Walter $100-500 like you do for all your 
other tools and then you can get your paying job done. Oh, you 
never paid Walter anything? Well, then the expectations are 
different.


 If D is a large-ish scale hobby project among a bunch of people 
 with
 mutual interests, then that should be more clearly 
 communicated, but I
 don't think that's the intent, and I feel perfectly fine 
 interacting
 with D in the way D is intended to be interacted with.


It has elements of that, but it's growing into something more, 
particularly with the fundraising efforts recently.  Whether they 
will succeed, nobody can predict.


 Incidentally, this particular work I'm doing is on a multimedia 
 library intended for the community... so I really am truly 
 trying to contribute something of value!! But like most of my 
 projects, I tend to get blocked at some point, and then it goes 
 on hold indefinitely.


I know, I'm not saying your ultimate goal is selfish in this 
case.  However, if you want to use it in your job, that's a 
different matter.

On Monday, 19 March 2018 at 01:15:28 UTC, Manu wrote:

 On 18 March 2018 at 17:55, Jonathan M Davis via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:

 I definitely agree with this. If the folks fixing stuff don't 
 have the same priorities as you, then there's a high risk that 
 what you want to be fixed won't get fixed, and that's often 
 how things go with open source projects.


 And here it comes again!
 I understand the reality, and echo-ing statement sounds so good 
 to the
 community... but it's a terrible opinion to propagate if the 
 goal is
 for D to be successful.
 You're effectively saying "D is a hobby/toy, therefore you 
 can't bank
 on it with confidence". If I weren't a deluded zealot, there's 
 NO WAY
 I'd let my business invest in this technology when the crowd 
 endlessly
 repeats this sentiment.


Then don't, but that's the reality of where D's at. There's a 
wide spectrum between hobby/toy and production tool that 
conservative businesses pay thousands of dollars for, so they can 
make sure it's super-stable and supported.  D is somewhere in 
between, closer to the former than the latter.  That means it's 
more suited for startups like Sociomantic or Weka and not for 
old-school conglomerates like HP.  If you want the stability of 
the latter while paying nothing, it's your expectations that are 
wrong.


 So, while it IS a practical reality, there needs to be very 
 strong
 motivation from the community (and organisation) to combat that
 practical reality.
 I would strongly suggest; never say a sentence like this again. 
 It's
 the wrong attitude, and it gives an undesirable impression to 
 users.
 (assuming the goal is for D to be successful, and not a fun 
 hobby for
 the devs)


It is the _truth_, so it should be repeatedly said.


 But at the same time, if you come to D, see all kinds of great 
 things about it, and think that it's going to be fantastic but 
 keep running into things that cause you problems when you try 
 to use D, and then those pain points don't get fixed even 
 after years of dealing with the language, that's going to be 
 very frustrating - even more so if you've invested a lot of 
 time and energy into it.

 On some level, the only solution is to buckle down and fix 
 your pain points yourself, but that can also be quite 
 frustrating.


 Or hire staff who are paid to work on 'boring' issues. I would 
 make regular donations if I could be satisfied that my decade 
 old issues would be addressed. I wonder how many others would 
 too?


There has been a bountysource for many years, linked from the 
front page of the wiki: did you ever pick an issue and put a 
bounty on it?  If not, you have not done what you'd said you'd do.

I don't mean to put all the blame back on you, the community has 
failed so far to tie some business model to the OSS development 
process, something without which no OSS project has ever gone 
anywhere. Whether it's the consulting model that the linux kernel 
started off with, or the ad-based model of Firefox/Chrome, or the 
hybrid model of Android, every major OSS project you've ever used 
in production had a business model powering it behind the scenes.

D has so far failed to have one, which is partially why it's 
still a "startup." The recent Opencollective effort is one 
possible way to change that. I have suggested another paid model 
in this forum before, which is the most successful software 
licensing model today.

For you to ever get D in production, outside of startups, one of 
these business models will need to be used by the D team.
Apr 01 2018
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On 18 March 2018 at 17:55, Jonathan M Davis via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Monday, March 19, 2018 00:28:15 Joakim via Digitalmars-d wrote:

 On Monday, 19 March 2018 at 00:08:58 UTC, Manu wrote:

 On 18 March 2018 at 17:00, Manu <turkeyman gmail.com> wrote:

 [...]


 I want to just justify my apparent over-reaction... I think I'm
 not
 the only one that feels this way fairly often.
 Something that seems trivial only invokes over-reaction of this
 nature
 when there is sufficient emotional energy behind it.
 In my case, that is represented by investing a decade of my
 life into
 something based on the promise (**wishful thinking?) that it'll
 get to
 the point where I want it to be as a tool to do my work... but
 then
 slowly awakening myself to the reality that that's actually
 unlikely
 to happen, and the longer it takes, the less likely that
 eventual
 reality becomes.
 Perhaps it's breaking a delusion I imposed on myself years ago,
 but it
 still produces a feeling of being robbed of time and energy.

 Anyway, I suspect I'm not the only one that reaches this point
 and
 tends to feel this way. I've seen a lot of good people come and
 go
 after they 'burn out' in some way. Patience is finite.
 There's no action item here... just wanted to share a
 reflection, and
 perhaps there's some takeaway for the community with respect to
 priorities?


 Perhaps the community simply has different priorities than you?
 For example, my Android port has never gotten much use either,
 which is fine as I primarily did that work for myself.

 Nevertheless, you have to think of D as like working in a
 startup: if you see something that you think needs doing, you
 have to drive it yourself or it will never get done. Pretty much
 the same for most any OSS project too.


 I definitely agree with this. If the folks fixing stuff don't have the same
 priorities as you, then there's a high risk that what you want to be fixed
 won't get fixed, and that's often how things go with open source projects.


And here it comes again!
I understand the reality, and echo-ing statement sounds so good to the
community... but it's a terrible opinion to propagate if the goal is
for D to be successful.
You're effectively saying "D is a hobby/toy, therefore you can't bank
on it with confidence". If I weren't a deluded zealot, there's NO WAY
I'd let my business invest in this technology when the crowd endlessly
repeats this sentiment.

So, while it IS a practical reality, there needs to be very strong
motivation from the community (and organisation) to combat that
practical reality.
I would strongly suggest; never say a sentence like this again. It's
the wrong attitude, and it gives an undesirable impression to users.
(assuming the goal is for D to be successful, and not a fun hobby for
the devs)


 But at the same time, if you come to D, see all kinds of great things about
 it, and think that it's going to be fantastic but keep running into things
 that cause you problems when you try to use D, and then those pain points
 don't get fixed even after years of dealing with the language, that's going
 to be very frustrating - even more so if you've invested a lot of time and
 energy into it.

 On some level, the only solution is to buckle down and fix your pain points
 yourself, but that can also be quite frustrating.


Or hire staff who are paid to work on 'boring' issues. I would make
regular donations if I could be satisfied that my decade old issues
would be addressed. I wonder how many others would too?
Mar 18 2018
parent reply bachmeier <no spam.net> writes:
On Monday, 19 March 2018 at 01:15:28 UTC, Manu wrote:


 Or hire staff who are paid to work on 'boring' issues. I would 
 make regular donations if I could be satisfied that my decade 
 old issues would be addressed. I wonder how many others would 
 too?


That's actually possible now for corporate sponsors, though it 
takes a fair chunk of change, but you get 3 bug fixes a month: 
https://opencollective.com/dlang#budget

My understanding is that more options will be made available 
later.
Mar 18 2018
parent Manu <turkeyman gmail.com> writes:
On 18 March 2018 at 21:34, bachmeier via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Monday, 19 March 2018 at 01:15:28 UTC, Manu wrote:


 Or hire staff who are paid to work on 'boring' issues. I would make
 regular donations if I could be satisfied that my decade old issues would be
 addressed. I wonder how many others would too?



 That's actually possible now for corporate sponsors, though it takes a fair
 chunk of change, but you get 3 bug fixes a month:
 https://opencollective.com/dlang#budget

 My understanding is that more options will be made available later.


I dun supported.
Mar 18 2018
prev sibling parent Manu <turkeyman gmail.com> writes:
On 18 March 2018 at 18:15, Manu <turkeyman gmail.com> wrote:

 On 18 March 2018 at 17:55, Jonathan M Davis via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Monday, March 19, 2018 00:28:15 Joakim via Digitalmars-d wrote:

 On Monday, 19 March 2018 at 00:08:58 UTC, Manu wrote:

 On 18 March 2018 at 17:00, Manu <turkeyman gmail.com> wrote:

 [...]


 I want to just justify my apparent over-reaction... I think I'm
 not
 the only one that feels this way fairly often.
 Something that seems trivial only invokes over-reaction of this
 nature
 when there is sufficient emotional energy behind it.
 In my case, that is represented by investing a decade of my
 life into
 something based on the promise (**wishful thinking?) that it'll
 get to
 the point where I want it to be as a tool to do my work... but
 then
 slowly awakening myself to the reality that that's actually
 unlikely
 to happen, and the longer it takes, the less likely that
 eventual
 reality becomes.
 Perhaps it's breaking a delusion I imposed on myself years ago,
 but it
 still produces a feeling of being robbed of time and energy.

 Anyway, I suspect I'm not the only one that reaches this point
 and
 tends to feel this way. I've seen a lot of good people come and
 go
 after they 'burn out' in some way. Patience is finite.
 There's no action item here... just wanted to share a
 reflection, and
 perhaps there's some takeaway for the community with respect to
 priorities?


 Perhaps the community simply has different priorities than you?
 For example, my Android port has never gotten much use either,
 which is fine as I primarily did that work for myself.

 Nevertheless, you have to think of D as like working in a
 startup: if you see something that you think needs doing, you
 have to drive it yourself or it will never get done. Pretty much
 the same for most any OSS project too.


 I definitely agree with this. If the folks fixing stuff don't have the same
 priorities as you, then there's a high risk that what you want to be fixed
 won't get fixed, and that's often how things go with open source projects.


 And here it comes again!
 I understand the reality, and echo-ing statement sounds so good to the
 community... but it's a terrible opinion to propagate if the goal is
 for D to be successful.
 You're effectively saying "D is a hobby/toy, therefore you can't bank
 on it with confidence". If I weren't a deluded zealot, there's NO WAY
 I'd let my business invest in this technology when the crowd endlessly
 repeats this sentiment.

 So, while it IS a practical reality, there needs to be very strong
 motivation from the community (and organisation) to combat that
 practical reality.
 I would strongly suggest; never say a sentence like this again. It's
 the wrong attitude, and it gives an undesirable impression to users.
 (assuming the goal is for D to be successful, and not a fun hobby for
 the devs)


 But at the same time, if you come to D, see all kinds of great things about
 it, and think that it's going to be fantastic but keep running into things
 that cause you problems when you try to use D, and then those pain points
 don't get fixed even after years of dealing with the language, that's going
 to be very frustrating - even more so if you've invested a lot of time and
 energy into it.

 On some level, the only solution is to buckle down and fix your pain points
 yourself, but that can also be quite frustrating.


 Or hire staff who are paid to work on 'boring' issues. I would make
 regular donations if I could be satisfied that my decade old issues
 would be addressed. I wonder how many others would too?


For what it's worth, I think I sound like nothing is moving ever, and
that's not actually the reality today at all. I so feel like momentum
has increased substantially recently on a number of fronts, but I'm
mostly a passive observer standing a bit off to the side somewhere.
I am constantly impressed and excited about all the work that's being
done here... I read the announcements, and think "yeah, I super can't
wait to get amongst that good stuff!! ...if only my project would be
un-blocked from the thing that blocked it 5 years ago".
In some way, I'm still waiting for the opportunity to do all the good
stuff with D that D can do (including Android ports!), but I'm usually
blocked by mostly boring trivia, and a couple of big things (ie, ARC).
Mar 18 2018
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, March 18, 2018 18:15:28 Manu via Digitalmars-d wrote:

 On 18 March 2018 at 17:55, Jonathan M Davis via Digitalmars-d

 I definitely agree with this. If the folks fixing stuff don't have the
 same priorities as you, then there's a high risk that what you want to
 be fixed won't get fixed, and that's often how things go with open
 source projects.


 And here it comes again!
 I understand the reality, and echo-ing statement sounds so good to the
 community... but it's a terrible opinion to propagate if the goal is
 for D to be successful.
 You're effectively saying "D is a hobby/toy, therefore you can't bank
 on it with confidence". If I weren't a deluded zealot, there's NO WAY
 I'd let my business invest in this technology when the crowd endlessly
 repeats this sentiment.

 So, while it IS a practical reality, there needs to be very strong
 motivation from the community (and organisation) to combat that
 practical reality.
 I would strongly suggest; never say a sentence like this again. It's
 the wrong attitude, and it gives an undesirable impression to users.
 (assuming the goal is for D to be successful, and not a fun hobby for
 the devs)


Well, it's the reality of things are. And D can be used just fine in a
production environment. It's just that you have to be willing to deal with
the warts that come with the wonderful stuff. Anyone who isn't isn't going
to be very happy. The number of warts have definitely gone down over time,
but that doesn't mean that they're all gone, and depending on your
priorities, it may be that they're far too often not going away in the
places that you care about most. Either way, I'm not about to lie about the
state of things. The fact that we're dealing almost exclusively with
volunteers has a definite impact on what gets done and how it gets done.
We're not the first language to start out that way, and others ended up
being _very_ successful in the long run (e.g. it's my understanding, that
python started entirely as open source with no company backing and took
quite a few years to grow to the point that it had a significant user base).
We've made a lot of progress, but we also have quite a lot of work to do.


 But at the same time, if you come to D, see all kinds of great things
 about it, and think that it's going to be fantastic but keep running
 into things that cause you problems when you try to use D, and then
 those pain points don't get fixed even after years of dealing with the
 language, that's going to be very frustrating - even more so if you've
 invested a lot of time and energy into it.

 On some level, the only solution is to buckle down and fix your pain
 points yourself, but that can also be quite frustrating.


 Or hire staff who are paid to work on 'boring' issues. I would make
 regular donations if I could be satisfied that my decade old issues
 would be addressed. I wonder how many others would too?


With how things seem to be going with the D Foundation, it seems
increasingly likely that something like this will happen. It wasn't all that
long ago that there was trouble having enough money to pay for the travel
expenses of folks going to dconf, let alone hire staff to work on stuff. As
I understand it, some money has already been paid for specific projects
(e.g. the new CTFE engine), but AFAIK, there isn't currently anyone being
paid just to fix bugs. That may come though, especially if folks are willing
to donate money specifically towards that end.

- Jonathan M Davis
Mar 18 2018
prev sibling next sibling parent RazvanN <razvan.nitu1305 gmail.com> writes:
On Sunday, 18 March 2018 at 04:25:48 UTC, Manu wrote:

 What is so hard about implementing a pow intrinsic that CTFE 
 can use?
 It's ridiculous that we can't CTFE any non-linear function...
 It's one of those blocker bugs that's been there almost 10 
 years.


Well, there is this PR : https://github.com/dlang/dmd/pull/8071
Mar 23 2018
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/17/2018 9:25 PM, Manu wrote:

 What is so hard about implementing a pow intrinsic that CTFE can use?


https://github.com/dlang/dmd/pull/8071



 It's one of those blocker bugs that's been there almost 10 years.


It's one that seems to engender lots of comments, but no action.

(BTW, there's a way to do it without the CTFE fix. One can use the approach
I've 
always used in the past for C, which is write a separate program to generate
the 
tables. This was used in the DMD build, and was gradually replaced with CTFE.
It 
still exists in the backend, which is still in C++.)
Mar 23 2018
parent reply Manu <turkeyman gmail.com> writes:
On 23 March 2018 at 03:16, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 3/17/2018 9:25 PM, Manu wrote:

 What is so hard about implementing a pow intrinsic that CTFE can use?



 https://github.com/dlang/dmd/pull/8071


Best PR this year!


 It's one of those blocker bugs that's been there almost 10 years.



 It's one that seems to engender lots of comments, but no action.

 (BTW, there's a way to do it without the CTFE fix. One can use the approach
 I've always used in the past for C, which is write a separate program to
 generate the tables. This was used in the DMD build, and was gradually
 replaced with CTFE. It still exists in the backend, which is still in C++.)


Right, but then there's no reason to use D. When D undermine's its own
proposed usefulness, it loses against C++ every time, no competition.

In my experience, migration to D involves a series of case-studies,
typically demonstrating points of weakness for C++ (ie, tables of data
pasted in code), and how D seductively improves the situation. This is
exactly one of those cases, except you're confronted with a very
rude-awakening, and it's a powerful turn-off rather than a turn on.
Mar 23 2018
parent Nick Sabalausky <a a.a> writes:
On Friday, 23 March 2018 at 18:22:06 UTC, Manu wrote:

 On 23 March 2018 at 03:16, Walter Bright via Digitalmars-d

 (BTW, there's a way to do it without the CTFE fix. One can use 
 the approach I've always used in the past for C, which is 
 write a separate program to generate the tables. This was used 
 in the DMD build, and was gradually replaced with CTFE. It 
 still exists in the backend, which is still in C++.)


 Right, but then there's no reason to use D.


Of course there is. It's called "all the other million things D 
does better than C++ besides CTFE pow".


 When D undermine's its own proposed usefulness, it loses 
 against C++ every time, no competition.


Not when it's isolated examples instead of the language as a 
whole. It's not D's fault programmers are terrible at basic 
cost/benefit analysis.
Mar 23 2018
prev sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, March 23, 2018 13:38:38 Manu via Digitalmars-d wrote:

 On 23 March 2018 at 12:25, Jonathan M Davis via Digitalmars-d

 <digitalmars-d puremagic.com> wrote:

 On Friday, March 23, 2018 12:13:58 Manu via Digitalmars-d wrote:

 On 23 March 2018 at 12:02, Walter Bright via Digitalmars-d

 <digitalmars-d puremagic.com> wrote:

 On 3/23/2018 11:14 AM, Manu wrote:

 This happened to me again on Tuesday this week...


 All bugzilla requires is a name and a password. It does not do any
 verification. Heck, just type in xxx yyy and it'll work. This trivial
 bit of effort makes it effective in preventing troll posts :-)


 Well, my colleague isn't a troll. A genuinely interested party, but
 he's not gonna go out of his way for it. I can't control the natural
 reaction that most people have to being confronted with a registration
 page.
 I'd suggest openauth, and people using their github accounts; I think
 that's what people expect. I mean, most people just expect the bug
 tracker to BE on github ;)


 Really? I've dealt with relatively few projects that use github as a bug
 tracker, and it's been my experience that most anything that's really
 serious has its own bugtracker (usually some form of bugzilla) - though
 most such projects predate github by a long shot. I'd think that
 signing up for a bugtracker would be par for the course and that if
 anything, the fact that a project was using github issues instead of
 its own bugtracker would imply that it was small, which doesn't
 necessarily give a good impression - especially for a compiler.

 And with how simplistic github issues are in comparison to bugzilla, I
 don't know why you'd want to use it other than the fact that you don't
 have to go to the effort of setting up your own bugzilla. I'd certainly
 hate to see us switch to github issues just because a few folks weren't
 willing to sign up for a bugzilla account, though for whatever reason,
 some folks keep pushing for us to switch over.


 I'm not suggesting switch to github. I've never suggested that. I
 understand it's inferior.
 I'm suggesting supporting openauth.


You mentioned that you thought that most people expected the bug tracker to
be be on github, which is why I said what I did. And whether you think that
it should be on github or not, there are others who like to bring it up from
time to time.

I have no idea what it would take to support openauth or what the pros and
cons of that would be. Personally, I _prefer_ to have separate logins for
things so that the risk of spam and whatnot is segregated and so that there
is less of a connection between sites that I use, but I also usually use a
different e-mail address for every site that I deal with so that I can more
easily filter my e-mail and know where e-mail addresses leak, and that's not
a typical thing for folks to do. I also use a password manager so that
having more passwords to worry about is not an issue, and while many folks
do that, many do not. But with what little I know of the situation with
openauth, I'm not aware of a reason why it would be a problem to enable it
in addition to normal logins - assuming that bugzilla makes it
straightforward anyway. I have no idea whether any version of bugzilla
supports it or not.

- Jonathan M Davis
Mar 23 2018
parent Seb <seb wilzba.ch> writes:
On Friday, 23 March 2018 at 20:48:07 UTC, Jonathan M Davis wrote:

 I have no idea whether any version of bugzilla supports it or 
 not.

 - Jonathan M Davis


Mozilla's fork of Bugzilla (BMO) does - see 
https://forum.dlang.org/post/tneyowfjewrlrtnqsuvd forum.dlang.org
Mar 23 2018