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

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.

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.

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.

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

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.

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

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.

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?

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.