[Issue 6715] Using a custom pow function for ^^

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=6715

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P2  |P4

--

Re: bigint and pow

[rassoc via Digitalmars-d-learn]

On 10/2/22 09:24, Fausto via Digitalmars-d-learn wrote:

Thanks a lot. I am to used to C and, more important, I didn't think to look for 
also another operator for the power function :)



Oh, and I forgot to mention that this is doing what you probably asked for 
originally:

```d
import std;
import cmath = core.stdc.math;
void main()
{
// both print 1e+72
writeln(pow(10.0, 72));
writeln(cmath.pow(10, 72));
}
```

But it's just floating-point scientific notation, not true BigInts.

Another math difference from C is that D has well-defined wrapping math for 
signed ints.

Re: bigint and pow

[rassoc via Digitalmars-d-learn]

On 10/2/22 09:24, Fausto via Digitalmars-d-learn wrote:

Thanks a lot. I am to used to C and, more important, I didn't think to look for 
also another operator for the power function :)



D does have pow and many other useful math functions [1], it's just not defined 
for BitInts. Oh, and speaking of C, you also have access to all the usual C 
math [1] functions with just an import:

```d
import std.stdio : writeln;
void main()
{
import std.math : pow;
writeln(pow(10, 3)); // pow from D

import core.stdc.math : pow;

writeln(pow(10, 3)); // pow from C

// can also make it more explicit to show where it is coming from:

import cmath = core.stdc.math;
writeln(cmath.pow(10, 3));
}
```

Have fun with D!

[1] https://dlang.org/library/std/math.html
[2] https://dlang.org/library/core/stdc/math.html

Re: bigint and pow

[Fausto via Digitalmars-d-learn]

On Sunday, 2 October 2022 at 02:02:37 UTC, rassoc wrote:

On 10/2/22 00:04, Fausto via Digitalmars-d-learn wrote:

Hello,

I am trying to use pow with an integer argument, but I cannot 
have a bigint result, for example, ```pow(10,72)```.
Do I have to write my pow function or is there a native 
solution?


thanks,
Fausto



In contrast to certain scripting languages, there's no implicit 
promotion, you have to opt in for BigInt [1] usage in D:


```d
import std;
void main()
{
// all print the same
writeln(BigInt(10) ^^ 72);
writeln(10.BigInt ^^ 72);
writeln("10".BigInt ^^ 72);
}
```

[1] https://dlang.org/phobos/std_bigint.html#.BigInt


Thanks a lot. I am to used to C and, more important, I didn't 
think to look for also another operator for the power function :)

Re: bigint and pow

[rassoc via Digitalmars-d-learn]

On 10/2/22 00:04, Fausto via Digitalmars-d-learn wrote:

Hello,

I am trying to use pow with an integer argument, but I cannot have a bigint 
result, for example, ```pow(10,72)```.
Do I have to write my pow function or is there a native solution?

thanks,
Fausto



In contrast to certain scripting languages, there's no implicit promotion, you 
have to opt in for BigInt [1] usage in D:

```d
import std;
void main()
{
// all print the same
writeln(BigInt(10) ^^ 72);
writeln(10.BigInt ^^ 72);
writeln("10".BigInt ^^ 72);
}
```

[1] https://dlang.org/phobos/std_bigint.html#.BigInt

bigint and pow

[Fausto via Digitalmars-d-learn]

Hello,

I am trying to use pow with an integer argument, but I cannot 
have a bigint result, for example, ```pow(10,72)```.

Do I have to write my pow function or is there a native solution?

thanks,
Fausto

[Issue 16200] Faster pow implementation for integral exponents

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16200

Dlang Bot  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Dlang Bot  ---
dlang/phobos pull request #7823 "Fix Issue 16200 - Faster pow implementation
for integral exponents" was merged into master:

- 1c5ab751434f9c7f2c8be786129cbdd4ad19e98d by berni44:
  Fix Issue 16200 - Faster pow implementation for integral exponents

https://github.com/dlang/phobos/pull/7823

--

[Issue 16200] Faster pow implementation for integral exponents

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16200

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #4 from Dlang Bot  ---
@berni44 created dlang/phobos pull request #7823 "Fix Issue 16200 - Faster pow
implementation for integral exponents" fixing this issue:

- Fix Issue 16200 - Faster pow implementation for integral exponents

https://github.com/dlang/phobos/pull/7823

--

[Issue 21606] pow(NaN,0) gives 1 not NaN

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21606

Berni44  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Berni44  ---
I just found out, that this is a weird exception of the rule, that all
calculations including NaNs should be NaN...

--

[Issue 21606] pow(NaN,0) gives 1 not NaN

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21606

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #2 from Dlang Bot  ---
@berni44 created dlang/phobos pull request #7819 "Fix Issue 21606 - pow(NaN,0)
gives 1 not NaN" fixing this issue:

- Fix Issue 21606 - pow(NaN,0) gives 1 not NaN

https://github.com/dlang/phobos/pull/7819

--

[Issue 21601] std.math : pow(float/double, -2) produces sometimes wrong result

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21601

Dlang Bot  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Dlang Bot  ---
dlang/phobos pull request #7783 "Fix Issue 21601 - std.math : pow(float/double,
-2) produces sometimes wrong result" was merged into master:

- bab6c2b2114c067fac127b9291c2f7fd98d3ae53 by berni44:
  Fix Issue 21601 - std.math : pow(float/double, -2) produces sometimes
  wrong result

https://github.com/dlang/phobos/pull/7783

--

[Issue 21606] pow(NaN,0) gives 1 not NaN

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21606

--- Comment #1 from Berni44  ---
I've created a fix already, but have to wait for PR #7783 to be merged.

--

[Issue 21606] New: pow(NaN,0) gives 1 not NaN

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21606

  Issue ID: 21606
   Summary: pow(NaN,0) gives 1 not NaN
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@bernis-buecher.de

unittest
{
assert(isNaN(pow(float.nan,0)));
assert(isNaN(pow(double.nan,0)));
assert(isNaN(pow(real.nan,0)));
}

--

[Issue 16200] Faster pow implementation for integral exponents

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16200

--- Comment #3 from Berni44  ---
Created attachment 1815
  --> https://issues.dlang.org/attachment.cgi?id=1815=edit
Some analysis on speed differences between the three algorithms in charge

I added now an attachment with a speed analysis of the three algorithms
(stepanovs is not identical to the one given above). Main result: None of the
three algorithms is clearly better than the others. (But there are nice
diagrams and an other idea on how to improve the speed of the pow function.)

--

[Issue 16200] Faster pow implementation for integral exponents

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16200

Berni44  changed:

   What|Removed |Added

 CC||bugzi...@bernis-buecher.de

--- Comment #2 from Berni44  ---
Results on my computer:

dmd:
0 1 sec, 331 ms, 327 μs, and 6 hnsecs
1 2 secs, 940 ms, 293 μs, and 9 hnsecs
2 7 secs, 428 ms, 953 μs, and 5 hnsecs

ldc:
0 330 ms, 3 μs, and 2 hnsecs
1 117 ms, 824 μs, and 1 hnsec
2 1 sec, 324 ms, 530 μs, and 6 hnsecs

IMHO the program compares apples with oranges, that is doubles with reals.
Replacing double with real I get:

dmd:
0 2 secs, 335 ms, 325 μs, and 8 hnsecs
1 2 secs, 942 ms, 572 μs, and 9 hnsecs
2 7 secs, 421 ms, 349 μs, and 3 hnsecs

ldc:
0 530 ms, 947 μs, and 1 hnsec
1 117 ms, 768 μs, and 1 hnsec
2 1 sec, 324 ms, 124 μs, and 9 hnsecs

Not so clear, that the new algorithm is superior...

(I did a lot of more speed checking with these algorithms - I will write the
results down and post a link here, once I'm done.)

See also https://github.com/dlang/phobos/pull/7783 for results on checking
correctness.

--

[Issue 21601] std.math : pow(float/double, -2) produces sometimes wrong result

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21601

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #2 from Dlang Bot  ---
@berni44 created dlang/phobos pull request #7783 "Fix Issue 21601 - std.math :
pow(float/double, -2) produces sometimes wrong result" fixing this issue:

- Fix Issue 21601 - std.math : pow(float/double, -2) produces sometimes
  wrong result

https://github.com/dlang/phobos/pull/7783

--

[Issue 21601] std.math : pow(float/double, -2) produces sometimes wrong result

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21601

--- Comment #1 from Berni44  ---
Ups, should be "> 0.0" in the second test.

--

[Issue 21601] New: std.math : pow(float/double, -2) produces sometimes wrong result

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21601

  Issue ID: 21601
   Summary: std.math : pow(float/double, -2) produces sometimes
wrong result
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@bernis-buecher.de

Both unittests fail:

import std.math : pow;

unittest
{
assert(pow(-513645318757045764096.0f,-2) > 0.0);
assert(pow(-1.6299717435255677e+154,-2) < 0.0);
}

--

[Issue 5628] std.math unittest disabled - roundoff error in pow() on SSE2

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=5628

Dlang Bot  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Dlang Bot  ---
dlang/phobos pull request #7321 "Fix Issue 5628 - std.math unittest disabled -
roundoff error in pow()" was merged into master:

- 7b9c47452152217dccc83ad8a35945ee472dda1a by Bernhard Seckinger:
  Fix Issue 5628 - std.math unittest disabled - roundoff error in pow() on SSE2

https://github.com/dlang/phobos/pull/7321

--

[Issue 5628] std.math unittest disabled - roundoff error in pow() on SSE2

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=5628

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #7 from Dlang Bot  ---
@berni44 created dlang/phobos pull request #7321 "Fix Issue 5628 - std.math
unittest disabled - roundoff error in pow()" fixing this issue:

- Fix Issue 5628 - std.math unittest disabled - roundoff error in pow() on SSE2

https://github.com/dlang/phobos/pull/7321

--

Re: Why pow() won't go beyond 2^31?

[Murilo via Digitalmars-d-learn]

Hi guys, thank you for helping me out here, there is this 
facebook group for the D language, here we can help and teach 
each other. It is called Programming in D. Please join. 
https://www.facebook.com/groups/662119670846705/?ref=bookmarks

Re: Why pow() won't go beyond 2^31?

[Daniel Kozak via Digitalmars-d-learn]

On Thu, Nov 29, 2018 at 8:10 AM Murilo via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:

> I am using the function pow() from std.math but if I try pow(2,
> 32) it returns 0, it doesn't compute beyond the maximum value of
> an int(2^31) and I am working with long. What should I do?
>

if you look at doc: https://dlang.org/phobos/std_math.html#.pow.2

you will see that return type is infered from pow arguments, so if both
arguments are int for example the return value would be int too
https://run.dlang.io/is/FMVJhY

so if you want to have long as output one of your args should be (u)long or
you can enforce that by
pow!long(2,32);

https://run.dlang.io/is/WlDfsE

Re: Why pow() won't go beyond 2^31?

[Alex via Digitalmars-d-learn]

On Thursday, 29 November 2018 at 07:07:06 UTC, Murilo wrote:
I am using the function pow() from std.math but if I try pow(2, 
32) it returns 0, it doesn't compute beyond the maximum value 
of an int(2^31) and I am working with long. What should I do?


what exactly is your input?

´´´
import std.stdio;
import std.experimental.all;

void main()
{
long u = 2;
assert(pow(u,32) == 4294967296);
assert(pow(2UL,32) == 4294967296);
}
´´´

Why pow() won't go beyond 2^31?

[Murilo via Digitalmars-d-learn]

I am using the function pow() from std.math but if I try pow(2, 
32) it returns 0, it doesn't compute beyond the maximum value of 
an int(2^31) and I am working with long. What should I do?

Re: CTFE ^^ (pow)

[Joakim via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[Guillaume Piolat via Digitalmars-d]

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!

Re: CTFE ^^ (pow)

[Jonathan M Davis via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[Walter Bright via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[Guillaume Piolat via Digitalmars-d]

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.

Re: CTFE ^^ (pow)

[Manu via Digitalmars-d]

On 24 March 2018 at 18:10, Walter Bright via Digitalmars-d
 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.

Re: CTFE ^^ (pow)

[Walter Bright via Digitalmars-d]

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.

Re: CTFE ^^ (pow)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[Jacob Carlborg via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[Jacob Carlborg via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[Jacob Carlborg via Digitalmars-d]

On 2018-03-23 13:34, bauss wrote:


What do you mean?

https://gcc.gnu.org/bugzilla/buglist.cgi?component=c%2B%2B=gcc=--- 


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

https://gcc.gnu.org/bugzilla/buglist.cgi?component=c%2B%2B=0=bug_status%2Cpriority%2Cassigned_to%2Cbug_id=gcc_format=advanced

--
/Jacob Carlborg

Re: CTFE ^^ (pow)

[Manu via Digitalmars-d]

On 24 March 2018 at 01:42, Walter Bright via Digitalmars-d
 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.

Re: CTFE ^^ (pow)

[H. S. Teoh via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[Walter Bright via Digitalmars-d]

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.

Re: CTFE ^^ (pow)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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 
(and just converted it to C# the other day as part of a big Flash -> 
Unity3D conversion) and it works quick-and-easy even there (of course, 
the Haxe/C#-generating tool is written in D, the tool was just easier to 
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.

Re: CTFE ^^ (pow)

[Jonathan M Davis via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[Nick Sabalausky via Digitalmars-d]

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.

Re: CTFE ^^ (pow)

[Jonathan M Davis via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[Nick Sabalausky via Digitalmars-d]

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!

Re: CTFE ^^ (pow)

[Nick Sabalausky via Digitalmars-d]

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.

Re: CTFE ^^ (pow)

[Manu via Digitalmars-d]

On 23 March 2018 at 12:16, Walter Bright via Digitalmars-d
 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 ;)

Re: CTFE ^^ (pow)

[Seb via Digitalmars-d]

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/tneyowfjewrlrtnqs...@forum.dlang.org

Re: CTFE ^^ (pow)

[Timon Gehr via Digitalmars-d]

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.

Re: CTFE ^^ (pow)

[Seb via Digitalmars-d]

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

 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.

Re: CTFE ^^ (pow)

[Jonathan M Davis via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[Manu via Digitalmars-d]

On 23 March 2018 at 12:25, Jonathan M Davis via Digitalmars-d
 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
>>
>>  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.

Re: CTFE ^^ (pow)

[Jonathan M Davis via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[jmh530 via Digitalmars-d]

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.

Re: CTFE ^^ (pow)

[Walter Bright via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[Manu via Digitalmars-d]

On 23 March 2018 at 12:02, Walter Bright via Digitalmars-d
 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 ;)

Re: CTFE ^^ (pow)

[Walter Bright via Digitalmars-d]

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 :-)

Re: CTFE ^^ (pow)

[Manu via Digitalmars-d]

On 23 March 2018 at 11:24, Walter Bright via Digitalmars-d
 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

Re: CTFE ^^ (pow)

[Walter Bright via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[Manu via Digitalmars-d]

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.

Re: CTFE ^^ (pow)

[Manu via Digitalmars-d]

On 23 March 2018 at 02:37, Norm via Digitalmars-d
 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...

Re: CTFE ^^ (pow)

[Manu via Digitalmars-d]

On 23 March 2018 at 01:36, Nick Sabalausky (Abscissa) via
Digitalmars-d  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.

Re: CTFE ^^ (pow)

[Timon Gehr via Digitalmars-d]

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.

Re: CTFE ^^ (pow)

[bauss via Digitalmars-d]

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=gcc=---

Re: CTFE ^^ (pow)

[Jacob Carlborg via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[Walter Bright via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[RazvanN via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[Norm via Digitalmars-d]

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

[Issue 16474] CTFE pow

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16474

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution|--- |DUPLICATE

--- Comment #13 from Walter Bright  ---


*** This issue has been marked as a duplicate of issue 5227 ***

--

Re: CTFE ^^ (pow)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[Jordan Wilson via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[Walter Bright via Digitalmars-d]

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.

Re: CTFE ^^ (pow)

[Norm via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[Walter Bright via Digitalmars-d]

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?

Re: CTFE ^^ (pow)

[Norm via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[bachmeier via Digitalmars-d]

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.

Re: CTFE ^^ (pow)

[Manu via Digitalmars-d]

On 22 March 2018 at 18:25, Nick Sabalausky (Abscissa) 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.

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.

Re: CTFE ^^ (pow)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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.

Re: CTFE ^^ (pow)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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!

Re: CTFE ^^ (pow)

[Jonathan M Davis via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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.

Re: pow

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 21 March 2018 at 16:29:26 UTC, aerto wrote:

thanks, a last question in a diffrent function i use


use

BigInt i = 
"105312291668557186697918027683670432318895095400549111254310977536";


and it should work. Note the quotation marks - it reads it as a 
string because a long number literal is limited o 64 bit 
representations.

Re: pow

[aerto via Digitalmars-d]

On Wednesday, 21 March 2018 at 16:00:56 UTC, Adam D. Ruppe wrote:

On Wednesday, 21 March 2018 at 15:56:00 UTC, aerto wrote:
why pow(256, 27) gives 0, instead of 
105312291668557186697918027683670432318895095400549111254310977536L


that result is simply too big to fit in the result. Try using a 
bigint instead:


import std.bigint, std.stdio;

void main() {
BigInt i = 256;
i ^^= 27;
writeln(i);
}


thanks, a last question in a diffrent function i use 
writeln(105312291668557186697918027683670432318895095400549111254310977536L); and i get Error: integer overflow any solution >?

Re: pow

[H. S. Teoh via Digitalmars-d]

On Wed, Mar 21, 2018 at 03:56:00PM +, aerto via Digitalmars-d wrote:
> why pow(256, 27) gives 0, instead of
> 105312291668557186697918027683670432318895095400549111254310977536L

Because 256, being an int type, can only hold a 32-bit result, the
maximum of which is 2^31 (or 2^32 if you use uint). But 256^27 = 2^216,
far bigger than a 32-bit int can hold.

As Adam said, you probably want to use BigInt instead:

import std.bigint;
auto result = pow(BigInt(256), 27);


T

-- 
Food and laptops don't mix.

Re: pow

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 21 March 2018 at 15:56:00 UTC, aerto wrote:
why pow(256, 27) gives 0, instead of 
105312291668557186697918027683670432318895095400549111254310977536L


that result is simply too big to fit in the result. Try using a 
bigint instead:


import std.bigint, std.stdio;

void main() {
BigInt i = 256;
i ^^= 27;
writeln(i);
}

pow

[aerto via Digitalmars-d]

why pow(256, 27) gives 0, instead of 
105312291668557186697918027683670432318895095400549111254310977536L

Re: CTFE ^^ (pow)

[Manu via Digitalmars-d]

On 19 March 2018 at 13:00, Jacob Carlborg via Digitalmars-d
 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/ojxxjixcxnztmssky...@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

Re: CTFE ^^ (pow)

[Jacob Carlborg via Digitalmars-d]

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/ojxxjixcxnztmssky...@forum.dlang.org


--
/Jacob Carlborg

Re: CTFE ^^ (pow)

[Paolo Invernizzi via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[Manu via Digitalmars-d]

On 18 March 2018 at 21:34, bachmeier via Digitalmars-d
 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.

Re: CTFE ^^ (pow)

[Norm via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[bachmeier via Digitalmars-d]

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.

Re: CTFE ^^ (pow)

[rikki cattermole via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[nkm1 via Digitalmars-d]

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 ;)

Re: CTFE ^^ (pow)

[Jonathan M Davis via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[rikki cattermole via Digitalmars-d]

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.

Re: CTFE ^^ (pow)

[Danni Coy via Digitalmars-d]

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 ;)

Re: CTFE ^^ (pow)

[Norm via Digitalmars-d]

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

Re: CTFE ^^ (pow)

[rikki cattermole via Digitalmars-d]

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.

Re: CTFE ^^ (pow)

[Norm via Digitalmars-d]

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