/cc @jgeralnik|
---|---
> On second thought - not sure how well this could possibly work. When
> compiling my stand alone utility I pass in: --passL:"-lpcap" so that my
> binary will like against pcap, but if I want this code to run in compile time
> I need to either link the compiler
Slightly off topic, but as part of a recent job recruitment process I wrote my
own libpcap-like packet processor and in benchmarking it I noticed it was about
6x faster than the actual libpcap which uses a bunch of expensive callbacks via
function pointers internally. It's also pretty easy in
On second thought - not sure how well this could possibly work. When compiling
my stand alone utility I pass in: `--passL:"-lpcap"` so that my binary will
like against pcap, but if I want this code to run in compile time I need to
either link the compiler to libpcap or dynamically load the
I'm not a frequent nim user, but this is a feature I have been looking forwards
to since my first nim project in 2016.
My usecase - I would like to compile bpf filters at compile time to attach to
sockets, and I don't want to rely on libpcap being installed on target systems.
My code looks
@timothee
I sent you build instructions for libffi on gitter, but here they are just for
posterity:
> I followed the instructions here:
When I started out with nimterop, I was forced to leverage gorgeEx and create a
separate binary toast due to this exact limitation. Nimterop uses tree-sitter
which is a C/C++ parsing library for a variety of programming languages so it
wasn't possible to load it during compile time.
Initially,
is a rather
complicated file format, implementing my Nim based parser (even if only for
attributes) wasn't really in the cards.
There's certainly solutions to this without requiring compile time FFI of
course.
@timothee Thank you again for the detailed example. I see you're getting around
the struct issue by passing back a pointer. It gets kind of messy, but I
suppose I can deal with it :)
> if you'd like to help, please tell me how I can download / build libffi on
> windows... I'm not a windows
sh is
> caused because of a memory corruption caused by importing a library 3-layers
> deep which uses the compile time FFI.
That may be true. A compiler flag to have it turned on with some docs saying
"this feature is very powerful and may cause issues if used too extensively"
> One thing to keep in mind is that having FFI in the VM allows it to also work
> in the secret interpreter.
That's a great point, but we can have a separate binary/tool for that like
`nimrepl`.
corruption caused by importing a library 3-layers
deep which uses the compile time FFI.
But seriously, I think even staticExec+staticRead is more than enough. At some
point, you have to rely on a build/make tool that can do more than your
language do internally.
My biggest reason for wanting FFI at compile-time is to be able to use
libraries that are wrappers around C libraries. For example for my Arduino
stuff I wrote a macro that reads an image file and converts that to an array of
bytes that is directly inserted into your code (this is how sprites
One thing to keep in mind is that having FFI in the VM allows it to also work
in the secret interpreter. This ensures that one can try out more things
interactively, such as anything that needs `times` for instance.
Reasons why I remain skeptical:
Unclear QA
How to ensure quality of this feature? Say I run an SDL2 game at compile-time,
it crashes, now what? How do I debug that? Can I close these bug reports as
"won't fix"?
Use Cases
What are the use cases? What is it you need to do at compile-time
for C/C++ structs, the binary layout is different from the PNode binary layout
of a compile time object instance, so you can't just deref a ptr Foo returned
by a importc proc (that wouldn't make sense); and thankfully the compiler
prevents it.
However you can access individual fields via
> libffi bindings only support win32, not win64; maybe a solution is to use a
> dll for win64 instead of embedding the sources, see
> [https://github.com/Araq/libffi/blob/master/libffi.nim#L14](https://github.com/Araq/libffi/blob/master/libffi.nim#L14)
Interesting. It looks like it _should_
> What in particular needs work on Windows 64bit?
libffi bindings only support win32, not win64; maybe a solution is to use a dll
for win64 instead of embedding the sources, see
> all posix platforms we have in CI are supported (linux (32 and 64), osx,
> freebsd); win32 is supported; the only thing that needs work is win64, help
> welcome for that
That's awesome to hear! What in particular needs work on Windows 64bit?
I started playing around with it and noticed
I've been using it extensively ever since the feature was introduced, it's a
very useful feature and works well. Feel free to upvote
[https://github.com/nim-lang/Nim/pull/13091](https://github.com/nim-lang/Nim/pull/13091)
which re-enables testing this feature in CI, to prevent future
That would be awesome! We could say hello to F# type providers.
`staticRead` and `staticExec` are good workarounds though.
Compile time FFI has been a wish of mine for some time now. I noticed that it's
mostly developed, but has been disabled:
[https://github.com/nim-lang/Nim/commit/c5dbb0379fc431a01220224097f00323df6c9ced](https://github.com/nim-lang/Nim/commit/c5dbb0379fc431a01220224097f00323df6c9ced
21 matches
Mail list logo
