www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Thanks from a python programmer

reply Chris Piker <chris hoopjump.com> writes:
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.
Mar 04 2021
next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
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.
Mar 04 2021
next sibling parent reply Chris Piker <chris hoopjump.com> writes:
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,
Mar 04 2021
parent reply deadalnix <deadalnix gmail.com> writes:
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.
Mar 04 2021
parent reply Chris Piker <chris hoopjump.com> writes:
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.
Mar 04 2021
parent deadalnix <deadalnix gmail.com> writes:
On Thursday, 4 March 2021 at 23:38:48 UTC, Chris Piker wrote:

 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.


It is!

Very useful to find simple code sample that reproduce a bug from 
a large project. You usually end up having to do some manual 
cleaning after the fact, but it can do 98% of the job.

Feel free to ask question if you run into problems using it, many 
here can help.
Mar 05 2021
prev sibling parent Chris Piker <chris hoopjump.com> writes:
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.


 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.


Hi Iain

To get back to you on the stack corruption issue, I noticed some 
bugs in a dependency library I wrote in C.  I was using my old C 
library in new ways now that I have D bindings and ended up 
flushing some bugs out of the woodwork.  When I fixed the bugs, 
the stack corruption issue under GDC disappeared.  Not sure why 
they didn't appear in the DMD binaries, but who knows, vagaries 
of stack layout I guess.

Thanks for the quick reply to my initial message, sorry about the 
false alarm.

Also, appreciate your work on GDC!  I wish GDC was included in 
the package list for CentOS 8 (our production servers) but that's 
true of many packages that I end up building from source on 
CentOS.

Take Care,
Mar 11 2021
prev sibling next sibling parent reply Curious George <curiousgeorge 12curiousgeorge12.email> writes:
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.
Mar 04 2021
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
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.
Mar 04 2021
prev sibling next sibling parent Chris Piker <chris hoopjump.com> writes:
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,
Mar 04 2021
prev sibling next sibling parent reply James Lu <jamtlu gmail.com> writes:
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.
Mar 04 2021
parent reply mipri <mipri minimaltype.com> writes:
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.
Mar 04 2021
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 5 March 2021 at 06:11:33 UTC, mipri wrote:

 On Friday, 5 March 2021 at 02:13:44 UTC, James Lu wrote:

 [...]


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

 [...]


Have you checked out dpp?
https://code.dlang.org/packages/dpp

https://wiki.dlang.org/Bindings#Binding_generators
Mar 05 2021
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Friday, 5 March 2021 at 06:11:33 UTC, mipri wrote:


 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.


*shrug* I work with C libraries all the time, and while dstep and 
dpp might not handle everything, the parts they don't are minor.


 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.


As far as calling C functions? Of course, but those languages are 
also as capable as Zig if all you want to do is call functions.

If you're talking about C interoperability more generally, you 
have a strange definition of capable. You can create a D shared 
library that can be called as if it's a shared C library. You can 
go further and restrict yourself to betterC mode and then you're 
basically writing modernized C code that without further 
modification can be dumped in the middle of an existing C 
project. I don't think, say, Ruby can do that even though it has 
an FFI. Then there's the big issue of passing data back and 
forth. That's a language design issue and D makes it easy.
Mar 05 2021
parent reply mipri <mipri minimaltype.com> writes:
On Friday, 5 March 2021 at 12:21:19 UTC, bachmeier wrote:

 On Friday, 5 March 2021 at 06:11:33 UTC, mipri wrote:


 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.


 *shrug* I work with C libraries all the time, and while dstep 
 and dpp might not handle everything, the parts they don't are 
 minor.


 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.


 As far as calling C functions? Of course, but those languages 
 are also as capable as Zig if all you want to do is call 
 functions.

 If you're talking about C interoperability more generally, you 
 have a strange definition of capable. You can create a D shared 
 library that can be called as if it's a shared C library. You 
 can go further and restrict yourself to betterC mode and then 
 you're basically writing modernized C code that without further 
 modification can be dumped in the middle of an existing C 
 project. I don't think, say, Ruby can do that even though it 
 has an FFI.


You can absolutely do that with Ruby. You write a library that
loads Ruby as a library, then have it run your Ruby code, then
export C ABI functions that call into Ruby. It involves writing
(or generating) a bunch of C, which is the same on-the-wing
experience I referenced above with getting Python to call C
libraries. Start with
https://stackoverflow.com/questions/2801346/embedding-ruby-calling-a-function-from-c

You can do it. The existence of someone who can say "*shrug* I
work with C libraries all the time, and while rstep and rpp
might not handle everything, the parts they don't are minor."
is therefore not impossible. Would that mean that Ruby's a
first-class language for writing shared objects? If someone
claimed "Ruby has first-class C integration" would you not be
able to imagine any more-luxurious seats that a language might
have a ticket for?


 Then there's the big issue of passing data back and forth. 
 That's a language design issue and D makes it easy.


Why, what big issue? You *can* pass data back and forth. You
*can* even only write in a dialect of Ruby that would have a
great deal of sympathy with C and not require as much data
conversion, cheaply converting between char*s and
UncheckedByteArrays like the 'Native' JVM dialects.

You can do it, so it's first class, so it can hardly be
improved, and I certainly can't think of any languages that do
it better.


It's really tiresome to make a point this simple and then still
have to explain it. Of course I have a "strange definition of
capable" for you when I'm describing features you don't miss
because you're satisfied with less features. Airlines generally
make passengers walk past first-class to get to their cheaper
seating, so you at least don't hear conversations like

   A: I wish general seating had more comfortable seats.

   B (defensively): what do you mean? I fly all the time and the
     seat padding is as good as it gets. They'll even bring
     little packets of peanuts to you mid-flight! You can't get
     *that* kind of service elsewhere.
Mar 05 2021
parent reply bachmeier <no spam.net> writes:
On Friday, 5 March 2021 at 16:15:12 UTC, mipri wrote:


 You can absolutely do that with Ruby. You write a library that
 loads Ruby as a library, then have it run your Ruby code, then
 export C ABI functions that call into Ruby. It involves writing
 (or generating) a bunch of C, which is the same on-the-wing
 experience I referenced above with getting Python to call C
 libraries. Start with
 https://stackoverflow.com/questions/2801346/embedding-ruby-calling-a-function-from-c


You're not interested in having a serious conversation (or maybe 
you don't use D and don't understand how any of this works).
Mar 05 2021
parent reply mipri <mipri minimaltype.com> writes:
On Friday, 5 March 2021 at 17:44:13 UTC, bachmeier wrote:

 You're not interested in having a serious conversation (or 
 maybe you don't use D and don't understand how any of this 
 works).


This is the conversation:

   Curious George: [Nim] can compile directly to C, and thus
    utilize such libraries and code easier than D can.

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

   mipri: [These examples from Nim] are first class C
    integration. What D has is very fine, but it's general seating.
    [Python] was such a chore that http://swig.org/ happened to
    pull the Python programmers off the wing

   bachmeier: [defensive shrugging]

   mipri: It's really tiresome to make a point this simple and
     then still have to explain it.

   bachmeier: [angry mind-reading]

There's a communication failure: Curious George likes Nim's C
integration, and James Lu doesn't see how it's any better than
D's. That's fine: Curious George didn't say much to begin with.
It may even be the case that precisely where Curious George
actually likes Nim, D *really* is as good, and he's just
relaying a general understanding of transpiling benefits. But
because there's a communication failure, I stepped in to help:
here are some specific things that transpiling lets Nim do,
that might make someone prefer it for C integration.  My goal
wasn't "make everyone use Nim" or "establish that D has
terrible FFI"; it was "allow people like James Lu to read
statements like Curious George's and understand what might be
meant by them, instead of thinking them as merely in error."

Now, thanks to you, there is another communication failure. As
usual I wasted some time trying to overcome it by strengthening
and modulating the signal. But there's nothing I can say that
can make you read, or make you think about what you're reading.
If someone shuts off their radio, it doesn't matter how clear
the radio comms are.
Mar 05 2021
parent James Lu <jamtlu gmail.com> writes:
On Friday, 5 March 2021 at 18:22:31 UTC, mipri wrote:

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

   mipri: [These examples from Nim] are first class C
    integration. What D has is very fine, but it's general 
 seating.
    [Python] was such a chore that http://swig.org/ happened to
    pull the Python programmers off the wing


from ctypes import *
sox = cdll.LoadLibrary("libc.so.6")
sox.sox_init()

No headers required.
Mar 07 2021
prev sibling parent reply Preetpal <preetpal.sohal gmail.com> writes:
On Friday, 5 March 2021 at 06:11:33 UTC, mipri wrote:

 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.


I am very skeptical about the usefulness of transpiling in the 
manner you describe. Can you show some examples of this being 
used? How is it any different than just generating a header file 
in an intermediate build step (like how CMAKE can configure a 
version header file or you could even write a C program to write 
a header definition file)? Isn't this worse than just re-defining 
the constant, since now you lose compile time knowledge of what 
the constant should be?
Mar 06 2021
parent mipri <mipri minimaltype.com> writes:
On Sunday, 7 March 2021 at 04:15:12 UTC, Preetpal wrote:

 Isn't this worse than just re-defining the constant, since now 
 you lose compile time knowledge of what the constant should be?


There are two compilers, and the C one still has knowledge of
it, but yes it can't be a const in this case as Nim doesn't
know it's a constant, and that's arguably a downside of doing
things that way. Another downside is you need to care about
another compiler's availability, version, toolchain, etc. Being
skeptical is fine; the Nim community also does not really
embrace transpilation as a feature, and on older systems I've
had an easier time getting D set up than Nim.


 How is it any different than just generating a header file in
 an intermediate build step


Not having to do that is a difference.
Mar 06 2021
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
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.


I'm going to be honest, I haven't checked Nim in like 4 years or 
so, so things may have changed quite a bit since then, but last I 
checked the claim made by it supporters were gross exaggeration, 
if not outright lies in some cases.

I don't think the aggressive over promotion of anything, 
anywhere, was ever helpful to anyone except people running pump 
and dump schemes, so I've always wondered what the Nimzoïds are 
trying to achieve here.

This is very annoying and give a very impression of the language 
and its community, especially when one tries it and see that the 
picture that is being sold is miles away from the reality of the 
field.
Mar 05 2021
prev sibling parent Curious George <curiousgeorge 12curiousgeorge12.email> writes:
On Thursday, 4 March 2021 at 20:14:32 UTC, Curious George wrote:

 [...]


I'd like to apologize for my initial post as it wasn't 
sufficiently substantiated and thus resulted in an argument. 
Further, I am quite thankful to mipri for not only elaborating on 
my point, but expressing impressive meditative acumen. In the 
future, I hope to avoid this and actually defend my positions 
myself.

P.S. I'm mainly a D programming, but I've been looking into nim 
as of late, and I got a tad excited as one can see. As such, 
please think poorly of me for that post, but not nim's community.
Mar 06 2021
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On Thursday, 4 March 2021 at 09:57:01 UTC, Chris Piker wrote:


 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.


Please file an issue on GitHub [1], otherwise it will be 
difficult for to fix if I don't know about it. Try to include a 
reduced test case.


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


That's great to hear.

[1] https://github.com/jacob-carlborg/dstep/issues

--
/Jacob Carlborg
Mar 05 2021
prev sibling parent reply James Blachly <james.blachly gmail.com> writes:
On 3/4/21 4:57 AM, Chris Piker wrote:
...

 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.


...

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


Chris, thanks for the note. We found the same: Our computational biology 
group are all python alumni, and the three of us on the software side 
have all switched to D. The transition from python was pretty seamless, 
cognitively, and I would say our overall productivity has gone UP.

Still have to use pandas for some dataframe type work, but otherwise, 
all code is written in D.
Mar 09 2021
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 10 March 2021 at 03:06:40 UTC, James Blachly wrote:

 On 3/4/21 4:57 AM, Chris Piker wrote:
 ...

 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.


 ...

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


 Chris, thanks for the note. We found the same: Our 
 computational biology group are all python alumni, and the 
 three of us on the software side have all switched to D. The 
 transition from python was pretty seamless, cognitively, and I 
 would say our overall productivity has gone UP.

 Still have to use pandas for some dataframe type work, but 
 otherwise, all code is written in D.


Yeah, if more people just knew about D.

Me and another user converted some python code and got execution 
time down from hours (stopped the execution after x hours) to 
under 1 minute (I think it was about 20 seconds on my system 
iirc).

It was a very pleasing experience.
Mar 10 2021
next sibling parent reply Chris Piker <chris hoopjump.com> writes:
On Wednesday, 10 March 2021 at 12:03:05 UTC, Imperatorn wrote:

 On Wednesday, 10 March 2021 at 03:06:40 UTC, James Blachly

 Yeah, if more people just knew about D.


Without a big corporate backer adoption is slow, but I hope the D 
community just keeps plugging along anyway.


 Me and another user converted some python code and got 
 execution time down from hours (stopped the execution after x 
 hours) to under 1 minute (I think it was about 20 seconds on my 
 system iirc).

 It was a very pleasing experience.


Similar story here.  I provide a streaming service for a few 
space particles and fields research groups.  Some of the radio 
spectrum generators were taking more than 35 minutes to provide a 
day's worth of data, thus causing client programs to time out.  
It was frustrating because the FFTs ran in fortran code after 
all, so python wasn't even doing most of the work.

After converting the streamer programs to D, CPU utilization is 
less than 30% of a single core (even on debug builds on DMD) 
while maxing out the RAID-5 array.  Response time is now less 
than 18 seconds, which is still long but it's now a hardware 
limitation, not a software problem.

To me D feels like an upgrade, but not a radical break.  Both D 
and python have modules.  Associative arrays swap in for 
dictionaries.  Range operations feel like list comprehensions, 
and I'm sure there are more similarities I've yet to encounter.

The learning curve is a bit steep at times, though Ali's book has 
been very helpful in that regard and the gdc+gdb+ddd stack has 
provided a reasonable debugging experience so far.

Happy Programming,
Mar 11 2021
parent welkam <wwwelkam gmail.com> writes:
On Friday, 12 March 2021 at 07:50:52 UTC, Chris Piker wrote:

 On Wednesday, 10 March 2021 at 12:03:05 UTC, Imperatorn wrote:
 it's now a hardware limitation, not a software problem


I havent seen the data but most measurement data is in narrow 
range so delta compression could save a lot of space. Just an 
idea.
Mar 12 2021
prev sibling parent Siemargl <inqnone gmail.com> writes:
On Wednesday, 10 March 2021 at 12:03:05 UTC, Imperatorn wrote:


 Yeah, if more people just knew about D.

 Me and another user converted some python code and got 
 execution time down from hours (stopped the execution after x 
 hours) to under 1 minute (I think it was about 20 seconds on my 
 system iirc).

 It was a very pleasing experience.


It would be great to write a short article on the transition from 
Python to D, or even a details manual
Mar 12 2021