Remember calling a NIF is not cheap, you want to minimize the number of calls and do as much work during a single call as is possible. That sounds like it’s doubling the cost?
that’s probably true, i bet it will kill the performance of JSON, but I can see other uses for this!
I’m not really sure. Why not just wait on the first NIF to return? Having two calls is not really a way on the beam for start and get without wrapping into a process, which is the pattern someone would try to do anyway.
Ill be giving a short ~15-20 minute talk on Zigler on the “rolling Zig community meetup” zig.show, if you’d like to learn about how Zigler works under the hood, I’ll do a shallow dive into the zig portion of the “secret sauce” of Zigler: https://zig.show/ on sunday morning (US time); sunday afternoon (europe time), sunday night (asia time). This will also be eventually published to youtube.
Updated to 0.7.1
Zig version is now bumped to 0.7.1
Now supports threaded, yielding, and dirty nifs. Consult the documentation guides on how to use these different long-running nif methods:
Regression: nerves is (temporarily) not supported until the arm32 architecture becomes tier 1. If you would like to use zig with nerves, consider using v0.3.2.
Updated to 0.8.1
Zig version is bumped to 0.8.1
https://hexdocs.pm/zigler/Zig.html
Major highlights:
- Supports cancellation of threaded and yielding nifs by killing the owning process.
- When compiled with debug symbols, zig “error return traces” are merged with elixir exception stacktraces.
- Supports idiomatic "std.testing.*’ zig stdlib functions for running zig tests
Version 0.9.1 is released!
Zig version updated to 0.9.1:
Major highlights: Support for c and c++ compilation using the sources
option:
https://hexdocs.pm/zigler/Zig.html#module-compiling-c-c-files
Zigler version 0.10.1 is released, with a redone API, fully updated documentation and guides.
Big highlight is “easy_c” which lets you mount a c library (or supplied c code) and allows you to integrate C libraries as nifs in an intuitive fashion without having to write error-prone glue code by hand.
Is there a way to write the zig code in a .zig file so I can get all the goodness of an editor w/LSP, syntax highlighting, etc… for my zig code?
Very quick search in the docs tell me you can - Zig — zigler v0.10.3.
It seems that with that method, you write your code in a .zig file, but then still have to wrap every function you wish to expose to Elixir in that external .zig file within the Elixir module?
I was looking for a method that didn’t require that duplication of effort. Or did I misunderstand how it works?
It was an oversight that I didn’t build it in 0.10. this feature will come in 0.11
actually in the meantime, you can probably (haven’t tried it, kinda guessing) get the result you want by doing:
~Z"""
pub usingnamespace @import("file-to-import.zig");
"""
Just a FYI, when I tried the pub usingnamespace
trick, I get:
** (KeyError) key :pub not found
(zig_parser 0.1.9) lib/zig.parser.ex:272: Zig.Parser.put_opt/3
(zig_parser 0.1.9) lib/zig.parser/top_level_decl.ex:5: Zig.Parser.TopLevelDecl.post_traverse/5
(zig_parser 0.1.9) Zig.Parser."TopLevelDecl__22"/6
(zig_parser 0.1.9) Zig.Parser."ContainerDeclarations__4"/6
(zig_parser 0.1.9) Zig.Parser."ContainerMembers__0"/6
(zig_parser 0.1.9) Zig.Parser."Root__4"/6
(zig_parser 0.1.9) Zig.Parser.parser__1/6
(zig_parser 0.1.9) Zig.Parser.parser/2
(zig_parser 0.1.9) lib/zig.parser.ex:179: Zig.Parser.parse/1
(zigler 0.10.3) lib/zig/compiler.ex:85: Zig.Compiler.compile/4
(zigler 0.10.3) expanding macro: Zig.Compiler.__before_compile__/1
It’s OK if the feature is coming in 0.11. Thanks for giving it a shot!