wootehfoot has quit [Read error: Connection reset by peer]
techtirade has quit [Ping timeout: 264 seconds]
marijnfs has joined #zig
techtirade has joined #zig
a92 has joined #zig
techtirade has quit [Ping timeout: 260 seconds]
Snetry has quit [Ping timeout: 240 seconds]
Snetry has joined #zig
alexpana has quit [Quit: WeeChat 1.9.1]
techtirade has joined #zig
bitmapper has quit []
bitmapper has joined #zig
leon-p has quit [Quit: leaving]
Snetry has quit [Ping timeout: 265 seconds]
Snetry has joined #zig
Snetry has quit [Ping timeout: 256 seconds]
Snetry has joined #zig
marijnfs has quit [Ping timeout: 272 seconds]
cole-h has quit [Ping timeout: 246 seconds]
Snetry has quit [Ping timeout: 240 seconds]
philtor has quit [Ping timeout: 264 seconds]
Snetry has joined #zig
ur5us has joined #zig
ur5us has quit [Ping timeout: 264 seconds]
hnOsmium0001 has joined #zig
ur5us has joined #zig
marijnfs has joined #zig
osa1_ has joined #zig
osa1 has quit [Ping timeout: 246 seconds]
marijnfs has quit [Ping timeout: 258 seconds]
a92 has quit [Quit: My presence will now cease]
ur5us has quit [Ping timeout: 264 seconds]
a_chou has joined #zig
Snetry has quit [Ping timeout: 264 seconds]
_whitelogger has joined #zig
Snetry has joined #zig
xackus_ has joined #zig
xackus has quit [Ping timeout: 264 seconds]
<cCCCCcccccCCc>
Hi, tonight's zig master release has an issue for me. I've got several projects in zig and when I try to compile them now with a fresh, empty cache on an x86-64 Linux system it wedges at 'Compile C Objects [1312/1327] aio.c...' and never successfully completes. I can confirm if I downgrade to the 0.7.1 release it will complete successfully.
<cCCCCcccccCCc>
I forget the exact tag, but the release prior to tonight's worked fine as well.
<andrewrk>
cCCCCcccccCCc, I'm aware of the issue but haven't solved it or reverted it yet. it's my top priority item right now
<cCCCCcccccCCc>
No worries, I just figured I should say in case no one had. Thanks for the hard work!
<andrewrk>
instead of reverting or working around it, I decided to improve the tooling for troubleshooting such issues. now we've got a new -fsanitize-thread feature landing soon
<g-w1>
andrewrk: i should tell you that the latest tarball doesn't really deadlock on my server (did 1st time, but then after that not, my guess is because the cache is hot or something), but still does on my personal 8-core machine
<andrewrk>
g-w1, I'm eager for you to try after #7520 is merged
<marler8997>
Hey, I'm working on windows path issues, it looks like Windows has some functions that are exported from ".exe" files (not always dll files). How do you think the Zig compiler should handle that?
spiderstew_ has quit [Ping timeout: 272 seconds]
spiderstew has joined #zig
a_chou has quit [Quit: a_chou]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
Snetry has quit [Ping timeout: 246 seconds]
karrick has quit [Ping timeout: 260 seconds]
l1x has quit [Ping timeout: 260 seconds]
Snetry has joined #zig
r0bby has quit [Ping timeout: 260 seconds]
cren has quit [Ping timeout: 260 seconds]
cren has joined #zig
l1x has joined #zig
r0bby has joined #zig
karrick has joined #zig
Snetry has quit [Ping timeout: 265 seconds]
Snetry has joined #zig
techtirade has joined #zig
Snetry has quit [Ping timeout: 240 seconds]
Snetry has joined #zig
osa1_ is now known as osa1
Snetry has quit [Ping timeout: 272 seconds]
Snetry has joined #zig
_whitelogger has joined #zig
fengh has joined #zig
Snetry has quit [Ping timeout: 246 seconds]
selby has joined #zig
Snetry has joined #zig
Snetry has quit [Ping timeout: 260 seconds]
Snetry has joined #zig
sord937 has joined #zig
<rowbee>
can i define the type of a tuple? or should i define a struct instead?
<rowbee>
the documentation only contains 1 reference to tuples and it's in "for"
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
Snetry has quit [Ping timeout: 260 seconds]
Snetry has joined #zig
Snetry has quit [Ping timeout: 272 seconds]
Snetry has joined #zig
rzezeski has quit [Ping timeout: 260 seconds]
kushalp has quit [Read error: Connection reset by peer]
tracernz has quit [Ping timeout: 272 seconds]
kwilczynski has quit [Read error: Connection reset by peer]
r0bby has quit [Read error: Connection reset by peer]
procnto has quit [Read error: Connection reset by peer]
karrick has quit [Read error: Connection reset by peer]
rzezeski has joined #zig
kwilczynski has joined #zig
tracernz has joined #zig
r0bby has joined #zig
karrick has joined #zig
procnto has joined #zig
kushalp has joined #zig
leon-p has joined #zig
Snetry has quit [Ping timeout: 240 seconds]
cole-h has joined #zig
Snetry has joined #zig
<rowbee>
what does "array access of non-array type 'Point'" mean? i'm just trying to initialize a struct
<rowbee>
line in question: const ret: Point = .{ x, y };
<rowbee>
type is const Point = struct { x: i64, y: i64 };
<rowbee>
is there a less verbose way than Point{.x = x, .y = y};?
xackus_ has quit [Ping timeout: 246 seconds]
Snetry has quit [Ping timeout: 272 seconds]
fengh has quit [Ping timeout: 256 seconds]
Snetry has joined #zig
leon-p has quit [Quit: Lost terminal]
Sekhat has joined #zig
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
procnto has quit [Ping timeout: 268 seconds]
tracernz has quit [Ping timeout: 260 seconds]
karrick has quit [Read error: Connection reset by peer]
r0bby has quit [Read error: Connection reset by peer]
kushalp has quit [Read error: Connection reset by peer]
kwilczynski has quit [Read error: Connection reset by peer]
rzezeski has quit [Ping timeout: 256 seconds]
kwilczynski has joined #zig
tracernz has joined #zig
kushalp has joined #zig
r0bby has joined #zig
procnto has joined #zig
rzezeski has joined #zig
selby has quit [Quit: My MacBook has gone to sleep.]
karrick has joined #zig
selby has joined #zig
tracernz has quit [Ping timeout: 256 seconds]
cole-h has quit [Ping timeout: 264 seconds]
tracernz has joined #zig
_whitelogger has joined #zig
<ifreund>
you can alternative do const p: point = .{ .x = x, .y = y};
<ifreund>
s/point/Point/
<ifreund>
but yea zig requires the field names. In general zig favors reading code over writing code
selby has quit [Quit: My MacBook has gone to sleep.]
Snetry has joined #zig
leon-p has joined #zig
<rowbee>
saw the video. :(
selby has joined #zig
selby has quit [Client Quit]
Snetry has quit [Ping timeout: 264 seconds]
Snetry has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
notzmv has quit [Read error: Connection reset by peer]
save-lisp-or-die has joined #zig
notzmv has joined #zig
notzmv has quit [Remote host closed the connection]
xackus_ has joined #zig
xackus_ has quit [Ping timeout: 264 seconds]
fengh has joined #zig
marijnfs has joined #zig
marijnfs has quit [Ping timeout: 260 seconds]
sawzall has quit [Read error: Connection reset by peer]
sawzall has joined #zig
sord937 has quit [Quit: sord937]
tgschultz has joined #zig
marnix has quit [Ping timeout: 256 seconds]
marnix has joined #zig
a_chou has joined #zig
knebulae has quit [Read error: Connection reset by peer]
knebulae has joined #zig
midgard_ has joined #zig
midgard has quit [Ping timeout: 272 seconds]
Sekhat has quit [Remote host closed the connection]
GregVardy54 has joined #zig
cole-h has joined #zig
<dominikh>
is there a way to do something like this? http://sprunge.us/6fqWRU – syntactically this doesn't work because !void gets parsed as a unary boolean expression. but I'm not sure it's even semantically possible?
a_chou has quit [Quit: a_chou]
<tgschultz>
it looks like you're trying to return the type of an error union, but using the inferred syntax and there's no errors to infer. Something like `return error{EndOfStream,BrokenHandle}!void;`should work.
<tgschultz>
or `error!void` for the all-encompasing error union.
<tgschultz>
I'm not really sure what you're trying to accomplish since you could just use `fn foo() !void` directly.
<tgschultz>
Depending on what you're trying to do, there are ways to use @typeInfo to build an errorset.
<dominikh>
Ideally, I'd want the error set inferred from the function that used ReturnType() as its return value. the real use is a function that does or doesn't return errors, depending on the type of one of the generic parameters
<tgschultz>
so the real sig should be along the lines of `fn foo(something: anytype) ReturnType(@typeOf(something))`and then ReturnType can use whatever logic to determine the if it should error, and construct the errorset (possibly using @typeInfo)
<tgschultz>
the hiccup would be if `anytype` is itself a generic function, then @typeInfo will be full of useless
<tgschultz>
er, `something`
<dominikh>
sure, but you'd still want the error set inferred from the function body, not whatever 'something' is. it's not strictly _necessary_, but neither are inferred error sets in the first place. 'something', in this case, is either a pointer or not a pointer. and if it's not a pointer, we need to do work that may fail.
<dominikh>
I can of course figure out the error set myself, but having it inferred would be handy
xackus_ has joined #zig
hnOsmium0001 has joined #zig
marnix has quit [Ping timeout: 264 seconds]
<tgschultz>
in that case yes, I think you are correct that it is not expressible.
ur5us has joined #zig
marnix has joined #zig
<tgschultz>
interesing: if the compiler infers an empty errorset you still have to use try to call the function, which makes sense, however the scope that calls that function doesn't have to return an error union despite using try: https://zig.godbolt.org/z/PPjcnh
<tgschultz>
As I recall, I long ago reported the opposite of this issue, that you couldn't use try with an inferred empty error set.
blueberrypie has quit [Quit: Ping timeout (120 seconds)]
blueberrypie has joined #zig
GregVardy54 has quit [Remote host closed the connection]
ur5us has quit [Ping timeout: 260 seconds]
leeward has quit [Remote host closed the connection]
tgschultz has quit [Quit: Going offline, see ya! (www.adiirc.com)]
selby has joined #zig
selby has quit [Quit: My MacBook has gone to sleep.]
selby has joined #zig
<scientes>
I think you should have to use try
<scientes>
there is still an error set there
<scientes>
you have to unwrap it
nyaayaya has quit [Quit: byeee~]
<scientes>
if you want to cast it away you hvae to use unreachable
cren has quit [Quit: cren]
<g-w1>
is there support for piping to `zig fmt` and getting output on stdout?
kushalp has quit [Ping timeout: 268 seconds]
kwilczynski has quit [Ping timeout: 272 seconds]
tracernz has quit [Ping timeout: 258 seconds]
procnto has quit [Ping timeout: 260 seconds]
r0bby has quit [Ping timeout: 268 seconds]
rzezeski has quit [Ping timeout: 264 seconds]
<andrewrk>
g-w1, check `zig fmt -h`
<g-w1>
thanks
karrick has quit [Ping timeout: 260 seconds]
procnto has joined #zig
karrick has joined #zig
rzezeski has joined #zig
tracernz has joined #zig
r0bby has joined #zig
kushalp has joined #zig
kwilczynski has joined #zig
karrick has quit [Read error: Connection reset by peer]
karrick has joined #zig
kushalp has quit [Ping timeout: 260 seconds]
procnto has quit [Ping timeout: 260 seconds]
midgard_ is now known as midgard
kushalp has joined #zig
procnto has joined #zig
marnix has quit [Ping timeout: 240 seconds]
marnix has joined #zig
marnix has quit [Ping timeout: 246 seconds]
leon-p has quit [Quit: leaving]
osa1 has quit [Ping timeout: 246 seconds]
<g-w1>
I am doing a big merge and got this, https://paste.rs/1qy, what should I do? temporarly remove that part in build.zig?
<andrewrk>
you should be able to look at the conflicts and figure out what changed in each side, and make sure the final result incorporates both changes
<andrewrk>
are you familiar with the git workflow for conflict resolution?
<g-w1>
yes, I was just trying to test my changed before commiting, but I have decided to commit now, and then do commit --patch if it doesn't work. it was doing diff HEAD so it was GIANT
<andrewrk>
I'm sorry for not getting to your PRs earlier
<andrewrk>
it's hard to balance doing my own work and helping others get their PRs landed
<g-w1>
thats fine, vexu helped me
<andrewrk>
TSAN just landed FYI
<g-w1>
nice! ill try it soon
<andrewrk>
this also fixes a deadlock with the caching system
<andrewrk>
I suspect it may solve your use case, although drone ci is still hitting another one
<andrewrk>
cCCCCcccccCCc, there's a good chance 9f33984119ee698a9b344ad0df7b498b334e0f6e (just landed in master branch) solves the deadlock you hit. there's still another one happening that is next in line to be diagnosed and fixed=
osa1 has joined #zig
<andrewrk>
the good news is I'm pretty sure this isn't weird multi-threading issues, I think it's a legit bug in the caching system logic. so it's something any language would have faced, it's not zig being harder to debug than e.g. rust