4 ms·

The last time I looked at the Nim documentation, one had to manually declare C and C++ functions. I don't see how that's different from pretty much any other la

The last time I looked at the Nim documentation, one had to manually declare C and C++ functions. I don't see how that's different from pretty much any other language that can call C (i.e. pretty much all of them). Then there's preprocessor macros. I don't know how Zig does it, I'd have to look. I expand on why dpp is the way it is in my DConf 2019 talk: https://www.youtube.com/watch?v=79COPHF3TnE&t=8s https://www.youtube.com/watch?v=79COPHF3TnE&t=8s

nimmer 7y ago
Nim has an automated generator for C/C++ wrappers or translating from C. Also there are very easy ways to create Python modules in Nim: https://robert-mcdermott.gitlab.io/posts/speeding-up-python-with-nim/ https://robert-mcdermott.gitlab.io/posts/speeding-up-python-... https://github.com/yglukhov/nimpy https://github.com/yglukhov/nimpy
- atilaneves 7y ago
  Thanks for the links. That's nice, but not the same - users have to intend to write a Python extension in Nim. With autowrap, you can call unmodified D code (and as shown in the blog, C code as well with dpp). That means code that was never meant for consumption from another language can be made available.
  - nimmer 7y ago
    You don't need to modify the code, just add a wrapper. Nothing prevents generating a wrapper automatically but 99% of the time that is not very useful. The large majority of Python extension contain Python-specific code to access or return Python objects or act in a pythonic way.
    - atilaneves 7y ago
      > You don't need to modify the code, just add a wrapper. Still not the same. > Nothing prevents generating a wrapper automatically but 99% of the time that is not very useful. The large majority of Python extension contain Python-specific code to access or return Python objects or act in a pythonic way. Except, and I cannot stress this enough, at work we're using this to succesfully call into D production code without any Python-specific anything. It just works. The article wasn't even about that, it's about making it work just as seamlessly for C.
mratsim 7y ago
It's easy to call preprocessor macros from Nim, no difference from wrapping C: Example on wrapping a simple benchmark macro: - https://github.com/mratsim/weave/blob/052ae40a/experiments/e04_channel_based_work_stealing/primitives/coz.h#L79 https://github.com/mratsim/weave/blob/052ae40a/experiments/e... - https://github.com/mratsim/weave/blob/052ae40a/experiments/e04_channel_based_work_stealing/primitives/coz.nim#L21 https://github.com/mratsim/weave/blob/052ae40a/experiments/e...
- atilaneves 7y ago
  While nice, one still has to manually declare a Nim proc and tell it whence it came from. That's not the same.
  - nimmer 7y ago
    ...or let automated tools like c2nim do the job.
    - atilaneves 7y ago
      So just like the article describes.
steveklabnik 7y ago
Zig basically includes clang inside of it: https://twitter.com/andy_kelley/status/1099485306783440896 https://twitter.com/andy_kelley/status/1099485306783440896

nimmer 7y ago

Nim has an automated generator for C/C++ wrappers or translating from C. Also there are very easy ways to create Python modules in Nim: https://robert-mcdermott.gitlab.io/posts/speeding-up-python-with-nim/ https://robert-mcdermott.gitlab.io/posts/speeding-up-python-... https://github.com/yglukhov/nimpy https://github.com/yglukhov/nimpy

atilaneves 7y ago
Thanks for the links. That's nice, but not the same - users have to intend to write a Python extension in Nim. With autowrap, you can call unmodified D code (and as shown in the blog, C code as well with dpp). That means code that was never meant for consumption from another language can be made available.
- nimmer 7y ago
  You don't need to modify the code, just add a wrapper. Nothing prevents generating a wrapper automatically but 99% of the time that is not very useful. The large majority of Python extension contain Python-specific code to access or return Python objects or act in a pythonic way.
  - atilaneves 7y ago
    > You don't need to modify the code, just add a wrapper. Still not the same. > Nothing prevents generating a wrapper automatically but 99% of the time that is not very useful. The large majority of Python extension contain Python-specific code to access or return Python objects or act in a pythonic way. Except, and I cannot stress this enough, at work we're using this to succesfully call into D production code without any Python-specific anything. It just works. The article wasn't even about that, it's about making it work just as seamlessly for C.

mratsim 7y ago

It's easy to call preprocessor macros from Nim, no difference from wrapping C: Example on wrapping a simple benchmark macro: - https://github.com/mratsim/weave/blob/052ae40a/experiments/e04_channel_based_work_stealing/primitives/coz.h#L79 https://github.com/mratsim/weave/blob/052ae40a/experiments/e... - https://github.com/mratsim/weave/blob/052ae40a/experiments/e04_channel_based_work_stealing/primitives/coz.nim#L21 https://github.com/mratsim/weave/blob/052ae40a/experiments/e...

atilaneves 7y ago
While nice, one still has to manually declare a Nim proc and tell it whence it came from. That's not the same.
- nimmer 7y ago
  ...or let automated tools like c2nim do the job.
  - atilaneves 7y ago
    So just like the article describes.

steveklabnik 7y ago

Zig basically includes clang inside of it: https://twitter.com/andy_kelley/status/1099485306783440896 https://twitter.com/andy_kelley/status/1099485306783440896