On Sunday, 26 August 2018 at 23:39:32 UTC, Manu wrote:
> We could really use robust tools to produce a matching C++ .h file
> from the extern symbols in a D module, and likewise a .di file from a
> C/C++ header.
> This category of tooling has many existing instances, it's
> overwhelming. As far as I can tell, they're all experimental, or
> broken, or designed only to target a specific application (DMD), etc.
> I think it would be an advantage if there were *one* tool, that works,
> in both directions, which is advertised, recommended, and maintained
> by the core group.
> I've evaluated them all before at various points in time, but the
> landscape keeps shifting. Someone, please give me a prominent
> hyperlink to the solution that *works*, and instructions. I don't have
> energy to re-do comprehensive evaluations on this front, I'm spent.
> Agree on one, make it the official one, and then track bugs against it
> in bugzilla?

I know this isn't quite what you asked for but you should get in contact with Iain to generalise https://github.com/dlang/dmd/pull/8591/files
As for the other direction, I'd suggest talking to Atila to get app working for your use cases.

This is about as official as its going to get.

On Sunday, 26 August 2018 at 22:54:18 UTC, Walter Bright wrote:
> On 8/26/2018 1:55 PM, Walter Bright wrote:
>> I will tiresomely ask again, do you have a list of each and every aspect of the poor integration?
>
> I know you don't like filing bug reports. I'll make it easy for you.
>
> Every time someone you work with says:
>
> "I can't use D because ..."
> "I'm abandoning D because ..."
> "D sux because ..."
>
> Just append a note of it to a text file. It doesn't matter what the reason is, any information is valuable, including:
>
> "... because Walter killed and ate my dog"
> "... because my apartment contract stipulates no pets, no smokers, no D programming"
> "... because I can't take D jokes anymore"
> "... because Walter won't stop droning on with his boring Boeing anecdotes"
>
> Now and then, just email me the file.

It's 2.30 AM here, and you've made me smile :-P

/P

On Sun, 26 Aug 2018 at 17:20, Nicholas Wilson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Sunday, 26 August 2018 at 23:39:32 UTC, Manu wrote:
> > We could really use robust tools to produce a matching C++ .h
> > file
> > from the extern symbols in a D module, and likewise a .di file
> > from a
> > C/C++ header.
> > This category of tooling has many existing instances, it's
> > overwhelming. As far as I can tell, they're all experimental, or
> > broken, or designed only to target a specific application
> > (DMD), etc.
> > I think it would be an advantage if there were *one* tool, that
> > works,
> > in both directions, which is advertised, recommended, and
> > maintained
> > by the core group.
> > I've evaluated them all before at various points in time, but
> > the
> > landscape keeps shifting. Someone, please give me a prominent
> > hyperlink to the solution that *works*, and instructions. I
> > don't have
> > energy to re-do comprehensive evaluations on this front, I'm
> > spent.
> > Agree on one, make it the official one, and then track bugs
> > against it
> > in bugzilla?
>
> I know this isn't quite what you asked for but you should get in
> contact with Iain to generalise
> https://github.com/dlang/dmd/pull/8591/files
> As for the other direction, I'd suggest talking to Atila to get
> app working for your use cases.
>
> This is about as official as its going to get.

Yeah, i've been following both those efforts.
I don't have any free time to motivate this stuff on my own right now.
I'm just listing all the things (because Walter asked me to).

Incidentally, what's the state of DCompute stuff lately? Did the
front-end ever get a polish pass?
That's actually another really high-value ticket that I could use to
gain a lot of leverage, if it's at a place where you'd want to show it
to developers...
Mostly, just a good set of step-by-step docs would make all the difference.

On Sunday, 26 August 2018 at 23:39:32 UTC, Manu wrote:
> You should try using VisualD to debug DMD some time. You'll quickly
> discover edge cases trying to evaluate all the relevant state while
> stepping around. C++ RTTI is a problem (can't identify derived type in
> debugger), globals are a problem, TLS is a problem.
> The minor edge cases emerge frequently enough that they convey a sense
> of immaturity. I'll start taking note everything I encounter a minor
> debugging issue.


It's not just VisualD, the debug info DMD produces just doesn't include things like global variables for some reason. I use VS Code to debug, I get around it by using -gc (which is now deprecated) and adding the variable to the watch list with the full name. It's a pain in the ass though.

On Sun, 26 Aug 2018 at 15:55, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 8/26/2018 1:55 PM, Walter Bright wrote:
> > I will tiresomely ask again, do you have a list of each and every aspect of the poor integration?
>
> I know you don't like filing bug reports. I'll make it easy for you.

I file shit-loads of bug reports! >_<

> Every time someone you work with says:
>
> "I can't use D because ..."

That's not what we're up against.
We need to be focused on the question "It's okay to consider trying
something other than C++ because [boxes that we care about are all
ticked]".
We're not determining why we can't use D, we need to establish why we
can *consider trying* D.

> "I'm abandoning D because ..."

I've talked about this quite a bit already.
One of my colleagues spent a few weeks trying it out in his home game
engine; he abandoned it because effort required to interact with C++
was much greater than he imagined upon first inspection of the binding
features available.
His key criticisms were:
  - Expects tool to output compatible .h/.di files from complementary file.
  - Complained he felt colour-blind in the editor.
  - Bugs (mostly with extern(C++)) reduced his confidence it was
production ready. (I attempted to address the list of issues he
encountered a few weeks back, but some remain)

He likes the language, and would support it if he was satisfied
tooling was where it needs to be.
Tooling maturity was his biggest concern.

By contrast, another colleague tried writing a small game in his own
time. His feedback was that it felt 'fine', but he didn't encounter
anything that made it "simpler than C++", and claimed readability
improvements were tenuous.
He wouldn't show us his code. I'm sure he wrote basically what he
would have written in C++, and that's not how to get advantages out of
D... but his experience is still relevant. It demonstrates that C++
programmers won't be convinced without clear demonstration of superior
expressive opportunity.


What I know is, it all starts with a direct comparison to C++, and THAT starts with extern(C++)... which still kinda sucks right now. I've been working on it.

On Sun, 26 Aug 2018 at 17:40, tide via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Sunday, 26 August 2018 at 23:39:32 UTC, Manu wrote:
> > You should try using VisualD to debug DMD some time. You'll
> > quickly
> > discover edge cases trying to evaluate all the relevant state
> > while
> > stepping around. C++ RTTI is a problem (can't identify derived
> > type in
> > debugger), globals are a problem, TLS is a problem.
> > The minor edge cases emerge frequently enough that they convey
> > a sense
> > of immaturity. I'll start taking note everything I encounter a
> > minor
> > debugging issue.
>
>
> It's not just VisualD, the debug info DMD produces just doesn't include things like global variables for some reason. I use VS Code to debug, I get around it by using -gc (which is now deprecated) and adding the variable to the watch list with the full name. It's a pain in the ass though.

Right. That's not even remotely acceptable.

On Monday, 27 August 2018 at 00:26:35 UTC, Manu wrote:
> Yeah, i've been following both those efforts.
> I don't have any free time to motivate this stuff on my own right now.
> I'm just listing all the things (because Walter asked me to).
>

Fair enough. I suppose you'd need namespaces working first anyway to get  much out of those tools.

> Incidentally, what's the state of DCompute stuff lately? Did the
> front-end ever get a polish pass?
> That's actually another really high-value ticket that I could use to
> gain a lot of leverage, if it's at a place where you'd want to show it
> to developers...
> Mostly, just a good set of step-by-step docs would make all the difference.

Mostly I've been stupidly busy with uni but I'm now FREEEEEEE!

I'm going to wait for the LLVM 7 release (very soon) and then get things going again: testing, atomics, docs, API contracts etc. I'll post to Announce when I've done all that. I'm still waiting for the Khronos folks to get back to me to get the SPIRV backend into upstream LLVM.

You're mostly interested in CUDA, right? That should be much easier to get shipshape.

On Sun, 26 Aug 2018 at 17:50, Nicholas Wilson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Monday, 27 August 2018 at 00:26:35 UTC, Manu wrote:
> > Yeah, i've been following both those efforts.
> > I don't have any free time to motivate this stuff on my own
> > right now.
> > I'm just listing all the things (because Walter asked me to).
> >
>
> Fair enough. I suppose you'd need namespaces working first anyway to get  much out of those tools.
>
> > Incidentally, what's the state of DCompute stuff lately? Did the
> > front-end ever get a polish pass?
> > That's actually another really high-value ticket that I could
> > use to
> > gain a lot of leverage, if it's at a place where you'd want to
> > show it
> > to developers...
> > Mostly, just a good set of step-by-step docs would make all the
> > difference.
>
> Mostly I've been stupidly busy with uni but I'm now FREEEEEEE!
>
> I'm going to wait for the LLVM 7 release (very soon) and then get things going again: testing, atomics, docs, API contracts etc. I'll post to Announce when I've done all that. I'm still waiting for the Khronos folks to get back to me to get the SPIRV backend into upstream LLVM.
>
> You're mostly interested in CUDA, right? That should be much easier to get shipshape.

Actually, I'm really mostly interested in DX12 shader output right
now... I think there are tools that can convert LLVM to DX shaders? I
haven't looked into it yet, but it's on my backlog.
Next would be SPIRV for Vulkan.

On Sunday, August 26, 2018 5:39:32 PM MDT Manu via Digitalmars-d wrote:
>   ARC? What ever happened to the opAddRef/opDecRef proposal? Was it
> rejected? Is it canned, or is it just back on the bench? (GC is
> absolutely off the table for my project, I have no influence on this)

I don't know what Walter's current plans are for what any built-in ref-counting solution would look like, but it's my understanding that whatever he was working on was put on hold, because he needed something like DIP 1000 in order to make it work with @safe - which is what then triggered his working on DIP 1000 like he has been. So, presumably, at some point after DIP 1000 is complete and ready, he'll work on the ref-counting stuff again. So, while we may very well get it, I expect that it will be a while.

- Jonathan M Davis

On Sun, 26 Aug 2018 at 18:08, Manu <turkeyman@gmail.com> wrote:
>
> On Sun, 26 Aug 2018 at 17:50, Nicholas Wilson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >
> > On Monday, 27 August 2018 at 00:26:35 UTC, Manu wrote:
> > > Yeah, i've been following both those efforts.
> > > I don't have any free time to motivate this stuff on my own
> > > right now.
> > > I'm just listing all the things (because Walter asked me to).
> > >
> >
> > Fair enough. I suppose you'd need namespaces working first anyway to get  much out of those tools.
> >
> > > Incidentally, what's the state of DCompute stuff lately? Did the
> > > front-end ever get a polish pass?
> > > That's actually another really high-value ticket that I could
> > > use to
> > > gain a lot of leverage, if it's at a place where you'd want to
> > > show it
> > > to developers...
> > > Mostly, just a good set of step-by-step docs would make all the
> > > difference.
> >
> > Mostly I've been stupidly busy with uni but I'm now FREEEEEEE!
> >
> > I'm going to wait for the LLVM 7 release (very soon) and then get things going again: testing, atomics, docs, API contracts etc. I'll post to Announce when I've done all that. I'm still waiting for the Khronos folks to get back to me to get the SPIRV backend into upstream LLVM.
> >
> > You're mostly interested in CUDA, right? That should be much easier to get shipshape.
>
> Actually, I'm really mostly interested in DX12 shader output right
> now... I think there are tools that can convert LLVM to DX shaders? I
> haven't looked into it yet, but it's on my backlog.
> Next would be SPIRV for Vulkan.

This looks promising: https://blogs.msdn.microsoft.com/directx/2017/01/23/new-directx-shader-compiler-based-on-clangllvm-now-available-as-open-source/