ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<daurnimator>
has anyone looked into compiling zig to eBPF?
<daurnimator>
I saw it in the support table
<daurnimator>
so not sure how used it is
<daurnimator>
And theres a related question: is it possible to get compiled output from a zig program itself?
<daurnimator>
e.g. Could you implement: const bpf = @compile("bpf", somefunction);
<knebulae>
andrewrk: any thoughts or comments here: https://nebulae.online/klib.zig.txt ? I won't make this a regular thing. Just curious about comptime, and how much easier this could be (I suspect a 1 liner).
<andrewrk>
knebulae, std.mem.len(u8, ptr) or std.cstr.len(ptr)
<daurnimator>
knebulae: why do you have a []T vs a [*]T anyway?
<daurnimator>
(at comptime, why would you not know the length?)
<andrewrk>
I had to force zig to look at the bytes at runtime, however, due to missing comptime features, but I did make some progress on that in 218a4d4b30f32
<andrewrk>
invoking the compiler automatically to create artifacts is an interesting idea, which I would be open to considering in a proposal
<andrewrk>
knebulae, thanks for making the PR!
<knebulae>
Dude, this shouldn't be such a PITA. Lol.
<knebulae>
My git workflow zen is poor. Very poor.
<daurnimator>
andrewrk: oh you're responding to my bpf question above. I meant my import question from a couple of days ago
<daurnimator>
made an issue for the invoke-other-target though. (#1856)
<andrewrk>
daurnimator, I'm sorry for missing your question on IRC. can you make an issue for that too?
<daurnimator>
andrewrk: it's not well formed enough in my head to be an issue yet I think
<andrewrk>
can you repeat the question?
<daurnimator>
andrewrk: the idea is that when you @import() a file, *only* e.g. extern things are returns in an anonymous struct.
<daurnimator>
and that extern does *not* automatically propogate
<andrewrk>
extern? the C calling convention?
<andrewrk>
isn't that what pub does?
<daurnimator>
uh yeah pub
<daurnimator>
maybe I misunderstand things.... at the moment zig code ends up full of `_ = @import("foo")` which gets exports of the foo module into your program
<andrewrk>
can you describe the use case you're trying to improve?
<daurnimator>
2018-12-20 00:15:52 andrewrk the current workaround is: comptime { _ = @import("X.zig"); }
<andrewrk>
I understand that is relevant, but it's a useful exercise for both of us if you describe the use case explicitly
<daurnimator>
2018-12-20 00:15:04 unique_id Let's say that I'm creating a library. I point build.zig to src/index.zig. index.zig has "pub const X = @import("X.zig")". Inside X.zig there's an exported function (pub export fn foo() void {}). However, because the symbol X inside index.zig is never used, then X.zig is never visited, and foo never makes it into the library.
Ichorio has quit [Ping timeout: 244 seconds]
<daurnimator>
I'm thinking of some sort of syntax like `pub @import("X.zig").*` which re-exports all the fields of the import
<daurnimator>
I have an assumption here that any `pub` functions in the entry point end up as symbols in the build artifact.
<daurnimator>
^ any and only
IntoxicatedHippo has joined #zig
_whitelogger has joined #zig
unique_id has joined #zig
<unique_id>
daurnimator: "which re-exports all the fields of the import " - as in 'pub use @import("file.zig")' ?
steveno_ has quit [Remote host closed the connection]
IntoxicatedHippo has quit [Ping timeout: 240 seconds]
<knebulae>
and for andrewrk, the compiler throws an error with []u16, because it is expecting []c_ushort. They should be interchangeable.
<knebulae>
this specifically is driving me up a wall, I just don't understand semantically what it wants: error: expected type '?[*]const c_ushort', found '*[]const c_ushort'
<knebulae>
btw my footgun loaded c-in-zig code worked :/
unique_id has joined #zig
<unique_id>
knebulae: "?[*]const c_ushort" is a maybe null pointer to an unknown number of c shorts. "*[]const c_ushort" is a pointer to a slice, which is basically a struct that stores a pointer and a length
<unique_id>
Very, very different types
<mgxm>
andrewrk: All tests passed
<unique_id>
knebulae: If ?[*]const c_ushort came from automatic translation of a C header, then it was picked to be conservative, maybe it should instead be "*const c_ushort". or "?*const c_ushort". This use case of using imported c headers will be improved in the future as I understand it.
<unique_id>
Right now you'll have to do casting
<unique_id>
Or use zig translate-c and fix the header yourself
_whitelogger has joined #zig
a_chou has joined #zig
a_chou has quit [Client Quit]
a_chou has joined #zig
unique_id has quit [Ping timeout: 240 seconds]
<knebulae>
unique_id: thank you very much, and it was the concept of slices that I wasn't taking into account (although I am not unfamiliar with the concept), coupled with the, as you said, conservative c header translation.
Ichorio has joined #zig
a_chou has quit [Quit: a_chou]
return0e_ has quit [Remote host closed the connection]
<andrewrk>
knebulae, your PR overall looks good. there are some minor tweaks I'd like to make. Would you prefer feedback that you implement yourself, or for me to just fix it up real quick in a branch before merging? I'm happy to do either
tridactyla has quit [Excess Flood]
wilsonk has quit [Read error: Connection reset by peer]
<knebulae>
I'd just say let you fix it up. Then I can see kind of what you envision. Then my next PR will be better. And sorry for making the PR muddy. I actually had git problems and had to hand copy my changes over that resulted in a few mistakes. I have my workflow down now.
<andrewrk>
great! thanks for taking the time to submit a patch
<andrewrk>
knebulae, I did some reading of gnu efilib - I think there are some extern things that are the actual interface with the UEFI system
<andrewrk>
I think the gnu efi lib and the edk-II are both calling the same extern functions and using the same extern variables under the hood
<andrewrk>
anyway I think this is a good start, and i'm going to merge your patch
<andrewrk>
there is a lot of potential here for the zig standard library to provide the EFI lib, eliminating a dependency on the gnu one or the intel one
<andrewrk>
it's really not that much code
<knebulae>
andrewrk: agreed
<knebulae>
andrewrk: the only thing that would have been a show stopper at the end of the day would have been the insistence on including libc with imported c code.
<andrewrk>
copy elision update: starting to pass behavioral tests. 379 lines of behavior tests are now passing, 8145 lines to go
<andrewrk>
(probably more are passing but I'm traversing linearally and fixing issues as they come up)
wilsonk has joined #zig
return0e has quit [Read error: Connection reset by peer]