ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<GitHub162>
zig/master bf21747 Andrew Kelley: translate-c: fix typedef duplicate definition of variable...
<andrewrk>
bb010g, ^ sqlite .h file issue fixed
<bb010g>
andrewrk: Cool! I'll test it out in a bit.
<bb010g>
andrewrk: Ok, looking at the output a bit more, I'm not quite sure whether to comment this on the current issue or make a new one—if you look at <sqlite3.h>, you'll see that sqlite3_bind_blob is a normal function, but in <sqlite3ext.h>, after the import of "sqlite3.h", it's redefined via a preprocessor macro to sqlite3_api->bind_blob.
<bb010g>
The output of `zig translate-c /usr/include/sqlite3ext.h` has only the line `pub extern fn sqlite3_bind_blob(…) c_int;`, not a constant pointing at sqlite3_api.
<bb010g>
I'll work out a MWE.
<andrewrk>
translation of macros is fundamentally limited
<andrewrk>
but let's see if this is an example where we can do something sane
<andrewrk>
zig has a custom C parser for handling macros
<achambe>
Hmm, might be good to add a manual escape hatch somehow to override odd cases
<bb010g>
typedef struct { int (*foo)(); } api_routines;
<bb010g>
extern const api_routines *api;
<bb010g>
#define api_foo api->foo
<bb010g>
Stick those lines in a header file, translate it, and you don't have api_foo
<achambe>
actually, making a wrapper header is a good enough escape hatch, ignore what i said before
<achambe>
bb010g: building anything in particular with sqlite?
<bb010g>
Working on making an extension for it.
<bb010g>
I'd like to be able to do the whole thing in Zig, as opposed to having to also write some C. (The current setup still involves autogenerating some C, but you'd be able to write an extension without manually touching C.)
<andrewrk>
achambe, generally, lazy analysis is the escape hatch
<andrewrk>
in this recent case it did not protect against duplicate variable declaration, but that makes sense
<achambe>
a way to stress test some of zig would be to tell sqlite to use that allocator
<andrewrk>
bb010g, would you mind opening an issue for this? I think this is a macro that we can translate
<achambe>
bb010g: oh thats cool - I think hybrid C/zig programs would be interesting. I'm looking at making a backup tool and I use sqlite for the metadata
<bb010g>
Ok. Think I'll probably just manually touch up the translation of the current headers in the meantime, and if I do raw modules correctly, I could have a wrapper sit on top and be parameterized by what raw bindings you're using.
<bb010g>
(Are there plans for first-class namespaces at some point, or are you keeping those for just files and @import?)
<MajorLag>
empty structs are pretty much the same as a namespace. In fact, I generate "namespaces" with them in several things.
vec_ has joined #zig
<andrewrk>
^ agreed. I'm considering even removing the "namspace" type and having files implicitly be empty structs
<andrewrk>
or... maybe even actual structs. And you can put fields in them
<andrewrk>
then a file is equivalent to an anonymous struct
<achambe>
interesting
<MajorLag>
`const int = @import("interpolation.zig").ForType(f64);` generates an `interpolation` namespace with everything working on f64 internally. It does this by taking type T and returning an empty struct that has everything in it defined in T. `pub fn ForType(comptime T: type) type
<MajorLag>
return struct
<MajorLag>
<MajorLag>
if(T != f32 and T != f64) @compileError("interpolation only supports float types.");
<MajorLag>
in fact, there are actually functions within that empty struct that themselves return empty structs based on the input type
<MajorLag>
under some circumstances, you can get crazy with code reuse using comptime in zig
<bb010g>
Oh, wow, got a core dump while figuring out the proper output for that issue
<andrewrk>
tiehuis, on what OS did you run into trouble with BufferedAtomicFile?
JinShil has joined #zig
<bb010g>
andrewrk: I think part of this issue is that there's no current way in Zig to express a ccc function pointer. This example Zig doesn't actually put a bar decl in the generated header:
<andrewrk>
`extern` in the fn proto means C calling convention
<bb010g>
Oh, export, I'm dumb
<bb010g>
Got that right 5 lines up
<bb010g>
`export fn bar(foo: extern fn() c_int) c_int { … }` core dumps with "TOTO implement get_c_type for more types", which is what I think these structs would need
<bb010g>
<sqlite3ext.h> follows the form `export const api_routines = extern struct { pub foo: extern fn() c_int, };`
<andrewrk>
this will run only the translate-c tests
<andrewrk>
then you can add your test case and watch it fgail
<andrewrk>
then edit src/translate-c.cpp to fix it
darithorn has joined #zig
steveno_ has quit [Quit: Leaving]
<andrewrk>
bb010g, oops, I forgot to mention the file name - you can add your test case to the top of test/translate_c.zig
davr0s has joined #zig
bheads has joined #zig
bheads_ has quit [Ping timeout: 264 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
bheads has quit [Client Quit]
davr0s has joined #zig
daemol has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
daemol has quit [Read error: Connection reset by peer]
daemol has joined #zig
daemol has quit [Quit: daemol]
darithorn has quit [Quit: Leaving]
jfo has joined #zig
<koomi>
hey, I'm doing @cInclude("linux/kvm.h") and a bunch of defines are missing
<koomi>
--verbose-cimport isn't really helping in figuring out why
<koomi>
any tips how to debug this further?
davr0s has joined #zig
<andrewrk>
hi koomi - macros are inherently problematic to translate since zig must use heuristics to determine how they are intended to be used
<andrewrk>
however, maybe you have found a case that we could add a reasonable translation for
<andrewrk>
my suggestion would be to find an example of the #define that zig is unable to translate and open a GitHub isuse and then let's look at it and see if we can come up with translation rules
noonien has quit [Quit: Connection closed for inactivity]
<koomi>
andrewrk: do non-trivial macros work at all?
<koomi>
e.g.:
<koomi>
#define FOO 1
<koomi>
#define BAR FOO<<1
<koomi>
if I try to include that BAR isn't defined
<andrewrk>
we don't have any binary operator parsing in macros yet
<koomi>
I see
<koomi>
I thought you used clang for header parsing and everything would magically just work
<koomi>
too bad
jjido has joined #zig
jfo has quit [Ping timeout: 276 seconds]
atk has joined #zig
zolk3ri has joined #zig
<achambe>
koomi: it does use clang - but macros are a complication
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
jfo has joined #zig
jfo has quit [Remote host closed the connection]
<andrewrk>
koomi, imagine trying to translate this macro: #define IF if (
<andrewrk>
IF x) { return; }
<andrewrk>
(for C programmers to save typing '(')
<andrewrk>
that concept just doesn't translate into zig, quite intentionally
return0e_ has quit [Read error: Connection timed out]
return0e_ has joined #zig
<MajorLag>
Just spitballing, but what if it translated whatever macros it could in one pass, then ran the preprocessor over whatever is left and translated the results? Sure, zig couldn't use those untranslated macros, but there's probably good reason for that and at least any code in the C files should still work.
qazo has joined #zig
<andrewrk>
MajorLag, clang already does this for us
<andrewrk>
what we're talking about is just looking at a bare macro with no context, and trying to turn that into a zig declaration that has the same meaning
<koomi>
yeah, considering macros can contain any arbitrary stuff it's obviously a problem
<koomi>
I was thinking only about simplish constants
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jjido has joined #zig
<andrewrk>
certainly we can add more macro support than currently exists
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]