ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<wink_>
andrewrk: I tried to use gobolt to see what the code looked like when returning a ?i32, but it gave an error "[zig trunk #1] error: return type '?i32' not allowed in function with calling convention 'ccc'
<wink_>
because it was doing an "export", seems reasonable
<andrewrk>
wink_, you'll have to call your function that returns ?i32 from an exported function that only uses the C ABI
<wink_>
But if I change to a "pub" then it doesn't generate assembly.
<andrewrk>
this is working as designed
<wink_>
ok, I think I've got it, let me see
<wink_>
worked, I created "export fn xx() void { _ = square(2); } and that worked, I wonder if the default app should use that technique?
so has joined #zig
porky11 has quit [Ping timeout: 240 seconds]
<andrewrk>
there's no way that created a non-empty function
<andrewrk>
unless you made square export
<andrewrk>
wink_, what are you trying to accomplish?
<wink_>
Its in debug mode by default, so square was created
<wink_>
Funny you'd ask: the reason I looking at godbolt was I was curious how ?TypeId.Int worked. With a pointer I've assumed null == 0 and its a test for zero, but was curious how it worked with TypeId.Int.
<andrewrk>
you're curious what the debug assembly is?
<andrewrk>
probably better off looking at llvm ir than x86
mnoronha has quit [Ping timeout: 250 seconds]
<wink_>
I was curious what the ABI was, the assembly is hard, but it looks like in release-fast the stack has a "null" flag and the data is returned in the register, is that correct?
<wink_>
(I'm guessing not ABI doc's yet and I suspect it'll change before 1.0)
<wink_>
s/not/no/
<andrewrk>
there's no ABI for optional types other than optional pointers
<andrewrk>
that's why you get that compile error above
<wink_>
yea, no C ABI but there is some convention for zig or maybe I'm not asking the question properly.
<andrewrk>
there is purposefully no specified convention
<andrewrk>
so that zig/llvm can choose however it wants to represent based on any number of factors
mnoronha has joined #zig
<wink_>
hmm, it be nice if there was some convention so that eventually some shim could be used to interface to/from zig without being restricted to C but no worries now.
<andrewrk>
I'm not convinced that we need that
<andrewrk>
what problems would it solve?
<andrewrk>
(I know there are answers to this, but I have alternate solutions to the problems)
<scientes>
andrewrk, i agree that we should stick to C ABI
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<wink_>
I'm not suggesting doing away or changing the C ABI just a way to use Zig Types via other applications in other apps. Just a thought.
<scientes>
that means extending the C ABI
<scientes>
like if you do optional types you have to make the first argument a bit field on true/false for first optional argument, second optional argument, et cetera
<scientes>
but designing calling conventions is really difficult and highly dependent on the hardware architecture
<scientes>
so i think we should stick to the C ABI, even if it means limiting the types that can be passed
<wink_>
sg
<scientes>
you can always pass a pointer to the zig type
<scientes>
right?
<andrewrk>
scientes, right. you would probably create an @OpaqueType() and then ptr cast that to/from your zig type in the C API layer
<andrewrk>
we could probably have zig do the opaque type thing automatically
<wink_>
Yea, but you don't you need to know the layout of a `var x: ?usize;`
<andrewrk>
no, because the layout is contained within the zig code which is all internally consistent
<andrewrk>
sorry, read that as, "But don't you need to know...?"
<wink_>
confused, if you pass an @OpaqueType() which is a `var pX: *?size` the layout in memory has to be defined so it can be accessed properly in the C code, right?
<andrewrk>
the C code sees a pointer to forward decl
<andrewrk>
this is a common pattern in C
<wink_>
but isn't a `var x: ?usize` have a "tag" field associated with it so you know if it's null or not?
<wink_>
s/isn't/doesn't/
<scientes>
it does, i see it in lldb all the time
<wink_>
so if you want to pass a pointer to x to a C program it needs to know the memory layout of the two fields, correct?
<scientes>
so i guess i was wrong in saying that you could "just pass a pointer"
<scientes>
yes, and it would be good if this was not defined in zig
<andrewrk>
if you want the C code to know the memory layout then you have to use the C ABI
<andrewrk>
wink_, if you use the opaque type strategy then you would have to use an accessor function
<wink_>
ok
<andrewrk>
another strategy you could have is have the extern struct be a field in your zig struct, and pass a pointer to that
<andrewrk>
and use @fieldParentPtr to get the zig struct from the C struct pointer
<andrewrk>
that works if you want to have some "public" fields exported in the library API, but also have private state
<andrewrk>
that matches the most common API pattern for C libraries
<wink_>
I guess I was just thinking if Zig became very popular, they might want to access Zig native API's and data. But hey, that's a good problem to have :)
<wink_>
gtg, later
<andrewrk>
I have solutions to this problem for well-defined values of "they"
<scientes>
wink_, making that possible locks down the flexibility of the zig language, and it essentially means creating a second language (an ABI)
<scientes>
look how the C++ ABI changes all the time, it is gross
<andrewrk>
for example when packages become a thing, we will cache debug builds of packages in this way
_whitelogger has joined #zig
mnoronha has joined #zig
jjman has joined #zig
mnoronha has quit [Ping timeout: 250 seconds]
darithorn has quit [Quit: Konversation terminated!]
mnoronha has joined #zig
qazo has quit [Read error: Connection reset by peer]
qazo has joined #zig
mnoronha has quit [Ping timeout: 252 seconds]
qazo has quit [Read error: Connection reset by peer]
qazo has joined #zig
qazo has quit [Read error: Connection reset by peer]
very-mediocre has quit [Ping timeout: 256 seconds]
redj has joined #zig
return0e has quit [Ping timeout: 252 seconds]
Hejsil has quit [Ping timeout: 256 seconds]
return0e has joined #zig
return0e has quit []
porky11 has joined #zig
chemist69 has joined #zig
<andrewrk>
Hejsil, hmm yep that's a bug
<andrewrk>
unfortunately that might be an llvm bug which means it's harder to fix
<unique_id>
andrew, once I have a website, maybe for 0.4 or 0.5 I can add my game under "Active external projects using Zig". I think that would help Zig.
<andrewrk>
sounds great
mnoronha has joined #zig
<unique_id>
Is it a known issue (is it an issue?) that some libraries can't be found unless also linking c? So with "--library lz4" lz4 isn't found, but with "--library lz4 --library c" lz4 is found.
<andrewrk>
unique_id, what's the error message when it can't be found?
<unique_id>
andrewrk, "lld: error: unable to find library -llz4"
<andrewrk>
huh. that's strange
<andrewrk>
I would have expected linker errors with the libc symbols
return0e has joined #zig
chemist69 has quit [Quit: WeeChat 1.9.1]
noonien has joined #zig
qazo has quit [Ping timeout: 240 seconds]
darithorn has joined #zig
qazo has joined #zig
mnoronha has quit [Ping timeout: 252 seconds]
qazo has quit [Ping timeout: 252 seconds]
mnoronha has joined #zig
qazo has joined #zig
qazo has quit [Ping timeout: 260 seconds]
keveman has joined #zig
<unique_id>
I am having to add --library-path /usr/lib (or /usr/local/lib) for it to find my libraries that I've put in there. Was that intended?
wink_ has joined #zig
<unique_id>
I don't know how it's been finding other libraries that I've been using
<unique_id>
It seems that all the dependencies I've been using have been in places like /usr/lib/x86_64-linux-gnu
<andrewrk>
ah that's probably why the above lz4 thing happened
porky11 has quit [Ping timeout: 250 seconds]
<andrewrk>
I'll think about how library paths should work. my first thought is that it should be the job of the build system to find libraries and know about default paths and things like that
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<wink_>
andrewrk, scientes: A use case for "knowing" the layout. I've created an Actor system (https://github.com/winksaville/zig-actor-model) in Zig. One of the things it should beable to do is send a Message to Actors written in other languages. To do that efficiently I'd like to use something more performant and `packed struct`. To do this I need to be
<wink_>
able to easily control the layout or know what the layout Zig uses. The scenario where this is important is when the Actors are on the same computer using queues to pass messages. Thoughts?
<andrewrk>
best bet is probably to use the C ABI for this use case
<wink_>
By that you mean `packed struct`, correct?
<andrewrk>
although I wouldn't discount the null hypothesis of an explicit serialization and deserialization layer without benchmarking it
<andrewrk>
no, by that I mean `extern struct`, although `packed struct` would also work in this use case
<andrewrk>
I would tackle this problem by defining a message format that makes sense independent of programming languages, and then write a serialization/deserialization layer to handle it
<wink_>
agreed that's what I'll do when there is a "network" involved, but when the Actors are on the same computer sert/desert should not be required. When we have an `extern struct` where can I find the alignment/layout rules?
<andrewrk>
it's the C ABI
<wink_>
k, txs!
Ichorio has joined #zig
keveman has quit [Ping timeout: 256 seconds]
<unique_id>
In what directories does build.zig's .linkSystemLibrary look?
<andrewrk>
you can use .addLibPath to add directories
<wink_>
Searching around the it seems section [6.7.2.1](https://port70.net/~nsz/c/c11/n1570.html#6.7.2.1) of the C standard seem most pertinent. Is it Zig or LLVM which decides the alignment of struct fields as the standard only says "Each non-bit-field member of a structure or union object is aligned in an implementation- defined manner appropriate to its
<wink_>
type."
<andrewrk>
the c standard does not define a C ABI
<andrewrk>
the C ABI is defined by a tuple of (operating system, architecture, C compiler environment)
<andrewrk>
which corresponds to the --target-os --target-arch --target-environ flags of zig
<unique_id>
andrewrk: Ok, then I don't understand why "--library Foo" does not find libFoo.so in /usr/lib or /usr/local/lib, but gcc's -lFoo does.
<unique_id>
I have to add --library-path /usr/lib
<unique_id>
ok I'll try .addLibPath
Jenz has joined #zig
<Jenz>
AFAIK, there's no docs for the `use` keyword?
<andrewrk>
I filed this in response to your question
<wink_>
andrewrk: So, for example, with os=OsLinux arch=ZIGLLVM_x86_64 and environ=ZIGLLVM_GNUABI64 is it Zig or LLVM that is determining the the alignment of struct fields.
<andrewrk>
in the current implementation, the c++ code uses LLVM API to find out alignment. but the information could be determined without llvm
keveman has joined #zig
<Jenz>
Excellent, thanks andrewrk
Jenz has quit [Quit: Lost terminal]
Jenz has joined #zig
Jenz has quit [Quit: Lost terminal]
keveman has quit [Ping timeout: 256 seconds]
porky11 has joined #zig
Jenz has joined #zig
renatorabelo has joined #zig
<Jenz>
I feel there should be a bit more pretty way to ignore return value than `_ = someFoo();`
<unique_id>
(I like it)
<andrewrk>
Jenz, "pretty" was never one of zig's goals
<andrewrk>
the minor cognitive dissonance you feel when ignoring a return value is entirely intentional
<Jenz>
Ok, no can do about that I guess, this kind of thing is one I've started getting used to...