ChanServ changed the topic of #zig to: zig programming language | https://ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
viashimo has joined #zig
joaoh82 has quit [Ping timeout: 240 seconds]
jjsullivan has quit [Remote host closed the connection]
<viashimo> hi, I'm using trying to modify a field in a packed struct and get "error: cannot reassign to constant". I don't understand what the structure's field is constant
<viashimo> here's the example code: https://paste.debian.net/1175661/
<ifreund> viashimo: hi, your function takes self by value instead of pointer and function parameters are always constant
<ifreund> you can do `self: *Vec3` if you want to mutate it
<viashimo> oh I see. that makes sense.
<viashimo> ifreund: thanks!
<ifreund> no problem!
<andrewrk> g-w1, can you help me repro #6939 ? I can't get it to happen for me
mattnite has quit [Ping timeout: 245 seconds]
<g-w1> andrewrk: huh, I cant either, I guess it got fixed. closing rn
<g-w1> 4 issues left. yay!
<andrewrk> so close :)
<andrewrk> I also have a surprise for windows users today...
oats is now known as ot
ot is now known as oa
<andrewrk> just need to test it first
mattnite has joined #zig
<jaredmm> Microsoft gives me enough surprises. I don't need anymore. :(
mattnite has quit [Quit: leaving]
jjsullivan has joined #zig
<karchnu> why I'm hyped even though I didn't even use windows?
<andrewrk> damn, ok, it needs a bit more thought. I have a self-contained .zip file that windows users can use to build zig from source, no MSVC installation required
<andrewrk> only problem is cmake doesn't know what to do on Windows besides generate msvc projects
<andrewrk> ok clearly this would be best solved with zig build :) that way not even cmake is required
<karchnu> impressive
<andrewrk> there is one big reason this is not just masturbatory: it allows release build of llvm,clang,lld + debug build of zig
<andrewrk> until now windows users have been stuck with all or nothing
<fengb> You sound so defensive :3
<mshb> I never had any doubt that "scratch your own itch" was a euphemism :D
<andrewrk> llvm's dependency on c++ is a big problem for bootstrapping
<andrewrk> we get runtime crashes when using `zig c++` mixed with system-installed LLVM :(
<andrewrk> why you gotta make a compiler backend depend on the c++ ABI?
<andrewrk> I mean I'm not even complaining about the dependency on libstdc++, I'm just talking about the library ABI boundary
lucid_0x80 has joined #zig
<meowray> zig's LLD-as-a-library is a problem for us .. https://reviews.llvm.org/D85278
llimllib has joined #zig
joaoh82 has joined #zig
<daurnimator> meowray: 'us'?
joaoh82 has quit [Ping timeout: 256 seconds]
<meowray> daurnimator: i maintain LLD and know that it is not suitable for such a use case
<daurnimator> meowray: then why was e.g. https://reviews.llvm.org/D70378 a thing?
<meowray> daurnimator: a distribution maintainer wants to save disk space because of zig's use case
<meowray> daurnimator: i have mentioned in an early review that LLD-as-a-library is not going to be reliable
<meowray> even after D70378 there are still issues, for example, ResetAllOptionOccurrences will reset all the llvm global cl::opt
<meowray> if you use any such variable after calling lld, it may go wrong
<meowray> for example, if there is a fatal error or error() is called 20 times, the process will exit
<meowray> if the user is a non-llvm application and can guarantee there is no fatal() or error() call, D70378 may be fine
hlolli_ has joined #zig
Ekho has quit [Ping timeout: 244 seconds]
<andrewrk> meowray, zig will change to invoke itself as a child process in order to call LLD
hlolli__ has quit [Ping timeout: 272 seconds]
cole-h has joined #zig
<andrewrk> what does D85278 have to do with zig using LLD as a library?
<andrewrk> D85278 looks like an attempt to fix system lld packages causing issues such as https://github.com/ziglang/zig/issues/7209
<andrewrk> although I'm not sure why it is so problematic (or such an unexpected use case) to be able to use a library as a library
<andrewrk> dynamic linking LLD will add even more latency if we have to go through process creation
Ekho has joined #zig
<andrewrk> look at all this nonsense that would happen every time we need to invoke LLD: https://clbin.com/hnbko
casaca has quit [Remote host closed the connection]
<meowray> have you actually measured the time cost if zig starts a new process (lld)?
hcnelson has quit [*.net *.split]
ziguana[m] has quit [*.net *.split]
betawaffle has quit [*.net *.split]
tcsc has quit [*.net *.split]
dch has quit [*.net *.split]
strmpnk has quit [*.net *.split]
nikki93 has quit [*.net *.split]
larme has quit [*.net *.split]
nikki93 has joined #zig
dch has joined #zig
strmpnk has joined #zig
ziguana[m] has joined #zig
tcsc has joined #zig
betawaffle has joined #zig
hcnelson has joined #zig
larme has joined #zig
casaca has joined #zig
betawaffle has quit [Ping timeout: 244 seconds]
betawaffle has joined #zig
joaoh82 has joined #zig
<pjz> how can I iterate over a structs fields at runtime and compare the field names to a string?
<andrewrk> without warming the file system it is 3.17 ms on my fast laptop
<andrewrk> pjz, you would use comptime reflection to populate a value that is then available at runtime
<pjz> my non-working code is at https://github.com/pjz/aoc-2020-zig/blob/main/src/day04.zig#L43 if anyone can help me out; if this is the wrong place to ask for ziglang help, please point me in the right direction
<pjz> andrewrk: so I can't do a runtime iteration using the comptime iterator?
<pjz> I'm trying like for (std.meta.fields(MyStruct)) |field| { if (somevalue == field.name) { ...
<fengb> You can do `inline for`
<pjz> ahh.. that seems to work
<pjz> now... can you explain what that's doing?
<pjz> it means like 'inline this compile-time result into this runtime code' ?
<andrewrk> it inlines the for loop, so the element iterator becomes comptime known
<andrewrk> meowray, what can we do on zig's end to make your life easier?
<pjz> why is array[2..] okay, but not array[..2] ?
<pjz> also, negative indexing for slices would be nice
<pjz> but I'm sure there's an issue open for it
<pjz> and yeah, not top priority
<andrewrk> 0 is just one character
<andrewrk> no need to complicate the language
mattnite has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
mattnite has quit [Quit: Lost terminal]
mattnite has joined #zig
mattnite has quit [Quit: Lost terminal]
mattnite has joined #zig
mattnite has quit [Quit: Lost terminal]
mattnite has joined #zig
<andrewrk> hmm what is one expected to link to find FOLDERID_LocalAppData and FOLDERID_Profile?
<andrewrk> I think these are guids. pretty silly they didn't just make the definition `static const`...
<andrewrk> ahh, -luuid
<pjz> how do I declare a constant array of 3-char strings? I tried const foo = [_][]u8 { "foo", "bar" }; but no go
<pjz> dangit, my bad - somehow I ended up looking at an ancient version (0.1.1?) of those, probably by following an old link in the wiki or something. Sorry.
<andrewrk> no problem
stripedpajamas has joined #zig
a_chou has joined #zig
powerofzero has quit [Ping timeout: 240 seconds]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
earnestly has quit [Ping timeout: 264 seconds]
dumenci has joined #zig
lucid_0x80 has quit [Ping timeout: 246 seconds]
dumenci has quit [Remote host closed the connection]
a_chou has quit [Remote host closed the connection]
<pjz> why when I do " my_u32 |= (if (foo[0] == 'a') 64 else 0);" do I get "cannot store runtime value in type 'comptime_int'" ? I'm storing into my_u32
<pjz> writing it as "if (foo[0] == 'a') myu32 |= 64;" works fine
lucid_0x80 has joined #zig
lucid_0x80 is now known as dumenci
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #zig
osa1 has quit [Quit: osa1]
osa1 has joined #zig
<daurnimator> pjz: welcome to one of the oldest open bugs: https://github.com/ziglang/zig/issues/137
joaoh82 has quit [Ping timeout: 264 seconds]
mattnite has quit [Remote host closed the connection]
cole-h has quit [Ping timeout: 264 seconds]
xackus__ has joined #zig
<pjz> hmm
<pjz> okay, well, at least there's a workaround
<pjz> any hints for making a bitfield? I'm trying to use a PackedIntArray of i1 but " integer value 1 cannot be coerced to type 'i1'"
<pjz> aaand that looks like it's probably the same bug in a different form. Nice.
<pjz> ah, needs to be u1 not i1. thought thinking on it, i1 shold maybe be an invalid type?
tetsuo-cpp has joined #zig
llimllib has quit [Quit: Connection closed for inactivity]
stripedpajamas has quit [Read error: Connection reset by peer]
joaoh82 has joined #zig
<daurnimator> pjz: i1 holds either 0 or -1
tetsuo-cpp has quit [Ping timeout: 272 seconds]
tetsuo-cpp has joined #zig
joaoh82 has quit [Ping timeout: 265 seconds]
marnix has quit [Ping timeout: 240 seconds]
marnix has joined #zig
lonjil has joined #zig
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
mattnite has joined #zig
mattnite has quit [Quit: Lost terminal]
earnestly has joined #zig
joaoh82 has joined #zig
joaoh82 has quit [Ping timeout: 256 seconds]
tetsuo-cpp has quit [Ping timeout: 260 seconds]
waleee-cl has joined #zig
_whitelogger has joined #zig
lucid_0x80 has joined #zig
dumenci has quit [Ping timeout: 272 seconds]
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
joaoh82 has joined #zig
joaoh82 has quit [Ping timeout: 240 seconds]
hlolli_ has quit [Read error: Connection reset by peer]
midgard has quit [Ping timeout: 272 seconds]
travv0 has quit [Ping timeout: 272 seconds]
yZ5vlALg86lP has quit [Ping timeout: 272 seconds]
hlolli has joined #zig
travv0 has joined #zig
midgard has joined #zig
mmx870 has quit [Quit: The Lounge - https://thelounge.chat]
mmx870 has joined #zig
DerWanderer has joined #zig
DerWanderer has left #zig ["Leaving"]
joaoh82 has joined #zig
joaoh82 has quit [Remote host closed the connection]
joaoh82 has joined #zig
joaoh82 has quit [Read error: Connection reset by peer]
protheory8-new-m has joined #zig
<protheory8-new-m> Where is async function frame allocated?
<protheory8-new-m> > @frame provides access to the async function frame pointer.
<protheory8-new-m> Does it point to frame that is allocated on heap?
<protheory8-new-m> Does it point to frame that is allocated on heap?
<protheory8-new-m> * > @frame provides access to the async function frame pointer.
<novaskell> You're given it when you perform `async foo();` as the return value so you can decide where to put it
pafmaf[m] has joined #zig
<protheory8-new-m> Thanks, also there is someone asking:
<protheory8-new-m> > How are pointers to local variables made safe across yield points?
<companion_cube> So i1 contains only 0 and -1? Lol
<protheory8-new-m> <novaskell "You're given it when you perform"> Actually, doesn't return a pointer to async frame too?
<novaskell> before is executed only once while I've copied the continuation which allows running it twice
<novaskell> s/running/resuming/
<protheory8-new-m> Yeah, I know that, so frame is on stack by default?
<novaskell> yes
<novaskell> until you place it somewhere else
* novaskell isn't sure how result location semantics play into this or if it even does
<ifreund> well you can place it directly into heap memory
<ifreund> it's not on the stack by default, it's wherever you choose to place it
<protheory8-new-m> So last question: `var stuff = async funcName();`, is `stuff` instance of `@Frame(funcName)` or `*@Frame(funcName)`?
<ifreund> the former
<ifreund> there is no implicit heap allocation in zig
<protheory8-new-m> ok
<protheory8-new-m> thanks
<protheory8-new-m> does resume also return anything?
<protheory8-new-m> * does resume also return something?
<novaskell> neat
<ifreund> no resume doesn't return anything
<protheory8-new-m> thanks
wootehfoot has joined #zig
<karchnu> How can I format the output with "{}" as I can do with printf in C? Like, allowing 20 characters for a value?
<karchnu> That's really basic, but I didn't find out. ^^'
<ifreund> karchnu: see the doc comment of std.fmt.format()
<karchnu> ifreund: ok, thanks!
wootehfoot has quit [Quit: Leaving]
<karchnu> It would be awesome to add a few examples from time to time in the documentations. I'm starting to use Zig, and for now I use tests to grasp the different concepts.
radgeRayden has joined #zig
<ifreund> agree that docs could use a lot of work, but there are other higher priority tasks currently
<ifreund> I'm sure they will recieve much more attention as zig approaches 1.0
<karchnu> ifreund: I agree, not a priority. :)
<karchnu> I made a lexer in a single day just using the one from the compiler, so I guess it is not really hard to start being productive in Zig, even without docs.
<karchnu> (without prior zig development)
<ifreund> if you're familiar with C you can be productive in zig within days
wootehfoot has joined #zig
<ifreund> I had written less than 50 lines of zig before I started work on river :D
<fengb> Other than syntax and some advanced features, Zig is kinda boring (in a good way)
<fengb> Makes it really easy to learn
<karchnu> fengb: that's exactly why I like it. :D
<fengb> :D
<karchnu> the focus isn't on adding features, but make it work in every cases, even on WASM or on windows, having a great build system, being able to work with low level GPU features and API, kernel stuff… a real C substitute, not just yet-another-language
<karchnu> I was hyped by the project, not really by the language.
<ifreund> yeah, though the language also happens to solve all the problems I have with C and does in a way that doesn't create a million new ones
<karchnu> yep, now I enjoy the language as well, with nice features that don't make the compilation slow, or the binary to explose in size, with a way better way to handle errors, a better type system…
<protheory8-new-m> Doesn't moving async function frame might cause undefined behavior when reading local pointer variable in the async function if async function was suspended at least once?
<jaredmm> Speaking of C: when I have a cimport function that's returning "[*c]const struct_t" and I want to be able to access a field, what's the most sensible way to do that in Zig? If it was "[*c]struct_t", const s: *struct_t works, but I don't know what the analogue is for the const variant.
cole-h has joined #zig
<fengb> *const struct_t
<protheory8-new-m> > Doesn't moving async function frame might cause undefined behavior when reading local pointer variable in the async function if async function was suspended at least once?
<protheory8-new-m> It seems like that's exactly what happens, should this be mentioned in the docs?
<jaredmm> I would've told you that I already did that, but apparently I did not.
<ifreund> jaredmm: you can also dereference the [*c] pointer directly with foo.*.field_name
<jaredmm> Yeah, that's what I was trying to avoid.
<ifreund> heh, carry on then :D
commander has joined #zig
Akuli has joined #zig
lucid_0x80 has quit [Remote host closed the connection]
lucid_0x80 has joined #zig
cole-h has quit [Ping timeout: 260 seconds]
layneson has joined #zig
layneson has quit [Ping timeout: 256 seconds]
layneson has joined #zig
marnix has quit [Ping timeout: 264 seconds]
mattnite has joined #zig
marnix has joined #zig
plakband has joined #zig
lucid_0x80 has quit [Remote host closed the connection]
lucid_0x80 has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
demizer has quit [Quit: WeeChat 2.9]
<companion_cube> oh god, I just ragequit the handmade seattle podcast :/
<ifreund> why? I only listened to the one section andrew was on but I found it quite nice
<companion_cube> gingerbill started spounting nonsense on go vs rust
<companion_cube> like, you can dislike rust, but saying 1) it's even remotely as complicated as C++ 2) it's full of "unproven ideas" is just pure BS
<companion_cube> jesus
<companion_cube> makes my blood boil
<ifreund> I agree with 1 but not 2, rust is complicated by its very nature but it has much less accidental complexity than C++ so far
<companion_cube> I think C++ is at least an order of magnitude more complex than rust
<ifreund> they are continuing to add features to it though...
<companion_cube> not really
<companion_cube> they're just generalizing existing features to make them cleaner
heidezomp has joined #zig
<companion_cube> it's just "make const expressions work on more stuff" typically
<companion_cube> https://en.cppreference.com/w/cpp/utility/variant/get <-- nothing in rust is even remotely as ugly as, say, this
<companion_cube> anyway
<companion_cube> and the BS about new ideas, what a pile of crap
<ifreund> not yet :P though in all seriousness I sincerly hope that rust never gets that bad
<companion_cube> rust is mostly a mix of C and ML, both are from the 1970s
<companion_cube> well
<companion_cube> what have they added recently, really??
<ifreund> wrt the "unproven ideas" comment, rust *is* the first language to make this whole borrow checker thing a core thing
<companion_cube> c++20 adds so many new things, rust has only had `async` as a new big thing since 2015
<companion_cube> sure
<companion_cube> and go is the first to use CSP
<companion_cube> (badly, too)
<companion_cube> (well ok. since 2015 I think the 2 new features are: async, and (this month!!) const generics start being stabilized.)
<companion_cube> (compare with c++17 and c++20.)
<companion_cube> anyway, given his past streams and stuff I think gingerbill has a particular pb with rust. oh well.
<ifreund> I feel like this isn't really the right channel for this :/
<companion_cube> yeah I know
<companion_cube> sorry
kristoff_it has joined #zig
<kristoff_it> Zig SHOWTIME starts now https://twitch.tv/kristoff_it
<companion_cube> kristoff_it: what's the program?
<companion_cube> thanks! is it not on the website?
<ifreund> there's a link to there from zig.show
<ifreund> through the newsletter button
<companion_cube> ah. intuitively that'd be for subscribing.
jpe90 has joined #zig
oa is now known as oats
lucid_0x80 has quit [Ping timeout: 240 seconds]
Barabas has joined #zig
<Barabas> Hello
<Barabas> I have three projects. Two are libraries and one is an executable. The executable uses library A and B. Library B also uses library A. When building my exe, although I do `addPackagePath` for both libraries when it gets to the code to import library A from a file in library B it says it can't find it.
<ifreund> Barabas: hey, you'll need to add A to B's dependencies
<ifreund> example here ^
<Barabas> ifreund I do this in my build.zig of the executable, right?
<ifreund> Barabas: yes that's right
<Barabas> cool, thanks
Pistahh has quit [Remote host closed the connection]
plakband has quit [Quit: WeeChat 2.9]
Pistahh has joined #zig
Pistahh has quit [Client Quit]
a_chou has joined #zig
a_chou has quit [Remote host closed the connection]
a_chou has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
riba has joined #zig
layneson has quit [Ping timeout: 256 seconds]
a_chou has quit [Quit: a_chou]
aterius has quit [Ping timeout: 244 seconds]
siraben has quit [Ping timeout: 244 seconds]
josias has quit [Ping timeout: 246 seconds]
Snektron has quit [Ping timeout: 246 seconds]
ugla has quit [Ping timeout: 246 seconds]
ifreund_ has quit [Ping timeout: 246 seconds]
hcnelson has quit [Ping timeout: 244 seconds]
mattmurr___[m] has quit [Ping timeout: 240 seconds]
novaskell has quit [Ping timeout: 246 seconds]
Nypsie[m] has quit [Ping timeout: 244 seconds]
protheory8-new-m has quit [Ping timeout: 244 seconds]
pafmaf[m] has quit [Ping timeout: 244 seconds]
alexnask[m] has quit [Ping timeout: 260 seconds]
lroy64[m] has quit [Ping timeout: 268 seconds]
googlebot[m] has quit [Ping timeout: 260 seconds]
ky0ko1 has quit [Ping timeout: 260 seconds]
bfredl has quit [Ping timeout: 264 seconds]
sergeeeek[m] has quit [Ping timeout: 246 seconds]
BaroqueLarouche has quit [Ping timeout: 240 seconds]
fengb has quit [Ping timeout: 268 seconds]
ziguana[m] has quit [Ping timeout: 244 seconds]
return0e[m] has quit [Ping timeout: 246 seconds]
hnOsmium0001 has joined #zig
hcnelson has joined #zig
Snektron has joined #zig
pafmaf[m] has joined #zig
ugla has joined #zig
ifreund_ has joined #zig
asie has joined #zig
<asie> hello
siraben has joined #zig
aterius has joined #zig
ky0ko1 has joined #zig
BaroqueLarouche has joined #zig
fengb has joined #zig
<ifreund> o7
Nypsie[m] has joined #zig
alexnask[m] has joined #zig
protheory8-new-m has joined #zig
return0e[m] has joined #zig
marnix has quit [Ping timeout: 256 seconds]
marnix has joined #zig
Bekwnn has joined #zig
<Bekwnn> Hi, I think my strategy of "do other things and hope compiler updates help fix the problem" paid off. I just got a bit more info about why my project is having a build failure. I'm wondering if the -L library path here looks suspect since it's not an absolute path? https://i.imgur.com/h17Nlwd.png
<Bekwnn> this build.zig and project was all working on 0.6.0+xxxxxx versions, but started running into issues after I jumped to 0.7.0 and I'm thinking maybe there were changes to std.build
wootehfoot has quit [Quit: Leaving]
wootehfoot has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
riba has quit [Ping timeout: 240 seconds]
Akuli has quit [Quit: Leaving]
riba has joined #zig
jpe90 has quit [Quit: WeeChat 2.9]
riba has quit [Ping timeout: 244 seconds]
<g-w1> could someone point me to where in ir.cpp compitme function calls are implimented? I am thinking of how to impliment them in stage2, but want to know how it works in stage1 as a reference.
mattnite has quit [Quit: Lost terminal]
xackus__ has quit [Ping timeout: 240 seconds]
bfredl has joined #zig
a92 has joined #zig
marnix has quit [Ping timeout: 272 seconds]
marnix has joined #zig
marnix has quit [Ping timeout: 240 seconds]