Hi All

Just wanted to say thanks to the D community for the tools I've been using this week to write new utility apps around my old C libraries.  For years I've used python as the front end for a stream processor I maintain for work (the das2C library on github).  I haven't written much D code over the last two years, but python's performance was again growing tiresome, so I've come back to D for new application level code.  Others on these forums have mentioned that a good place to expand D's user base is the current crop of python programmers.  At least for folks like me who also maintain C libraries for performance, that sounds like a great focus area.

The only downsides I've experienced with my current round of D programming is that:

A) One of my programs compiles/runs fine under dmd, but the exact same code exhibits stack corruption under GDC-10.  (that was an interesting debugging session)  I haven't tried it under LDC yet.

B) Current github,master dstep output has an amusing bug where it writes some of the header definitions right into the middle of the "extern (C)" line at the top.

C) Also dexed has a confusing interface so I've started kicking a token monthly donation to it's development.  Maybe others will join in as well.

These were all minor issues, dstep especially saved me a TON of time.

Take care and I hope you keep up the good work, especially in the area of Linux IDE development.

On Thursday, 4 March 2021 at 09:57:01 UTC, Chris Piker wrote:
> The only downsides I've experienced with my current round of D programming is that:
>
> A) One of my programs compiles/runs fine under dmd, but the exact same code exhibits stack corruption under GDC-10.  (that was an interesting debugging session)  I haven't tried it under LDC yet.
>

Hi Chris,

Thanks for sharing your experience.

Would it be possible to raise a bug report with either a reduced test or steps to reproduce?

https://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc&component=d&version=10.0

Regards,
Iain.

On Thursday, 4 March 2021 at 10:20:15 UTC, Iain Buclaw wrote:
> On Thursday, 4 March 2021 at 09:57:01 UTC, Chris Piker wrote:
>> The only downsides I've experienced with my current round of D programming is that:
>>
>> A) One of my programs compiles/runs fine under dmd, but the exact same code exhibits stack corruption under GDC-10.  (that was an interesting debugging session)  I haven't tried it under LDC yet.
>>
> Would it be possible to raise a bug report with either a reduced test or steps to reproduce?
>
> https://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc&component=d&version=10.0

Sure.  I can't get to it till this weekend but I'll see if I can create a cut-down test case.  The overall program + library set is a bit extensive.

Maybe I'm just doing something I'm not supposed to and just getting luck with dmd memory layout.  I'm pretty inexperience with D so anything's possible, it might not be a bug in GDC at all.

Cheers,

On Thursday, 4 March 2021 at 10:31:12 UTC, Chris Piker wrote:
> Sure.  I can't get to it till this weekend but I'll see if I can create a cut-down test case.  The overall program + library set is a bit extensive.
>
> Maybe I'm just doing something I'm not supposed to and just getting luck with dmd memory layout.  I'm pretty inexperience with D so anything's possible, it might not be a bug in GDC at all.
>
> Cheers,

Dustmite can help you reduce to a simple test case.

On Thursday, 4 March 2021 at 09:57:01 UTC, Chris Piker wrote:
> Hi All
>
> Just wanted to say thanks to the D community for the tools I've been using this week to write new utility apps around my old C libraries.  For years I've used python as the front end for a stream processor I maintain for work (the das2C library on github).  I haven't written much D code over the last two years, but python's performance was again growing tiresome, so I've come back to D for new application level code.  Others on these forums have mentioned that a good place to expand D's user base is the current crop of python programmers.  At least for folks like me who also maintain C libraries for performance, that sounds like a great focus area.
>
> [...]

I know this might be construed as rude to say this on D's NG, but have you checked out nim? It has python-like syntax, can compile directly to C, and thus utilize such libraries and code easier than D can. It's also a growing language.

On Thursday, 4 March 2021 at 20:14:32 UTC, Curious George wrote:
> On Thursday, 4 March 2021 at 09:57:01 UTC, Chris Piker wrote:
>> Hi All
>>
>> Just wanted to say thanks to the D community for the tools I've been using this week to write new utility apps around my old C libraries.  For years I've used python as the front end for a stream processor I maintain for work (the das2C library on github).  I haven't written much D code over the last two years, but python's performance was again growing tiresome, so I've come back to D for new application level code.  Others on these forums have mentioned that a good place to expand D's user base is the current crop of python programmers.  At least for folks like me who also maintain C libraries for performance, that sounds like a great focus area.
>>
>> [...]
>
> I know this might be construed as rude to say this on D's NG, but have you checked out nim? It has python-like syntax, can compile directly to C, and thus utilize such libraries and code easier than D can. It's also a growing language.

As someone who has been writing Nim for a while, I wouldn't really say that statement is entirely true. The syntax is more familiar and that's probably a big plus, but the experience isn't really better than D imo.

On Thursday, 4 March 2021 at 20:14:32 UTC, Curious George wrote:
> On Thursday, 4 March 2021 at 09:57:01 UTC, Chris Piker wrote:
> 
> I know this might be construed as rude to say this on D's NG, but have you checked out nim? It has python-like syntax, can compile directly to C, and thus utilize such libraries and code easier than D can. It's also a growing language.

Thanks for the suggestion, I may check out nim someday.  I've already invested time in understanding D to some degree and now have a few production programs written in D, so I think I'll just stick with it unless I hit a show stopper.  I'm currently maintaining software written in java, C, D, matlab, IDL, python (probably some more I'm forgetting) and still have to take up julia at some point in the near future.

So right now I'm just not up for tackling another language, but good luck to nim.  Anything that stops wasting vast amounts of hardware, electricity, and my user's time, gets my vote :)

Cheers,

On Thursday, 4 March 2021 at 10:54:24 UTC, deadalnix wrote:
> On Thursday, 4 March 2021 at 10:31:12 UTC, Chris Piker wrote:
>
> Dustmite can help you reduce to a simple test case.

So this link popped-up in a Google search for "dlang dustmite"...

https://dlang.org/blog/2020/04/13/dustmite-the-general-purpose-data-reduction-tool/

Whoa, now *that* looks handy.  Thanks a lot!  I'll take a crack at using dustmite later in the week.

On Thursday, 4 March 2021 at 20:14:32 UTC, Curious George wrote:
>
> I know this might be construed as rude to say this on D's NG, but have you checked out nim? It has python-like syntax, can compile directly to C, and thus utilize such libraries and code easier than D can. It's also a growing language.

Python has first-class C integration, and D has first-class extern(C) support.

On Friday, 5 March 2021 at 02:13:44 UTC, James Lu wrote:
> On Thursday, 4 March 2021 at 20:14:32 UTC, Curious George wrote:
>>
>> I know this might be construed as rude to say this on D's NG, but have you checked out nim? It has python-like syntax, can compile directly to C, and thus utilize such libraries and code easier than D can. It's also a growing language.
>
> Python has first-class C integration, and D has first-class extern(C) support.

Here's a complete Nim program that prints the max amount of
file descriptors that a select() set can have:

  let FD_SETSIZE {.importc: "FD_SETSIZE", header: "<sys/select.h>".}: cint
  echo FD_SETSIZE

Here's a version that exports a function that returns that
value:

  let FD_SETSIZE* {.importc: "FD_SETSIZE", header: "<sys/select.h>".}: cint
  proc setsize*: cint {.exportc.} = FD_SETSIZE

With this assembly:

  setsize:
   endbr64
   mov    eax,0x400
   ret
   nop    WORD PTR [rax+rax*1+0x0]

So FD_SETSIZE is 1024 on godbolt.org. There's no 1024 in the
Nim, and Nim is not parsing the C headers or anything; it's
just deferring the value to C.

This is a nice thing you get from a transpiler... which nobody
using Nim really exploits, preferring to put a bunch of Nim
const definitions with what the C headers have. Anyway, here's
some more very uncommon Nim:

  proc `*`(a: float, b: int64): float =
     {.emit: [result, " = ", a, " * ", b, ";"].}

That's a * operator that literally just returns whatever a*b
does with those types in C.

That's first class C integration. Here's business class from
Zig:

  const c = @cImport({
      @cDefine("_NO_CRT_STDIO_INLINE", "1");
      @cInclude("stdio.h");
  });
  pub fn main() void {
      _ = c.printf("hello\n");
  }

This sets a C #define and then includes everything from stdio.h
as a struct with #defines as variables, C functions as Zig
functions, C #define *macros* also as Zig functions, etc. This
time the magic is not from C codegen and deferring the work to
a C compiler, but from Zig's compiler properly digesting C's
header files.

What D has is very fine, but it's general seating. Any language
with an FFI at all should be about as capable as D's FFI.

The last time I did C FFI with Python it was such a chore that
http://swig.org/ happened to pull the Python programmers off
the wings and actually into the airplane. I guess it's gotten
much better.