<fengb>
Yeah I agreed with him until halfway through
a_chou has quit [Remote host closed the connection]
xackus_ has quit [Ping timeout: 256 seconds]
eddyb[legacy] has quit [Read error: Connection reset by peer]
JimRM has quit [Read error: Connection reset by peer]
eddyb[legacy] has joined #zig
JimRM has joined #zig
rxF has joined #zig
fengb has quit [*.net *.split]
rom1504 has quit [*.net *.split]
cow-orker has quit [*.net *.split]
torque has quit [*.net *.split]
rxF is now known as torque
rom1504 has joined #zig
earnestly has quit [Ping timeout: 240 seconds]
<andrewrk>
I have to say I'm not a fan of all these weird log levels
<andrewrk>
I think debug, info, warn, error, and fatal make sense
<andrewrk>
I'll make a proposal
<pixelherodev>
Why *are* there so many??
<torque>
I remember someone linking a list of "standard" log levels that other logging libraries use in here
<andrewrk>
it corresponds to some legacy system thing
<andrewrk>
`man syslog`
<torque>
right
_whitelogger has joined #zig
_whitelogger has joined #zig
<andrewrk>
I'm in the final stretch for #6250
<andrewrk>
"andrewrk wants to merge 120 commits into master" @_@
waleee-cl has quit [Quit: Connection closed for inactivity]
<pixelherodev>
Nice
<pixelherodev>
I guess my vacation is almost over :P
ur5us has joined #zig
ur5us has quit [Ping timeout: 240 seconds]
joey152 has quit [Ping timeout: 246 seconds]
ky0ko_ has quit [Remote host closed the connection]
_whitelogger has joined #zig
dead10cc has joined #zig
nikita` has joined #zig
mmohammadi9812 has joined #zig
mmohammadi98129 has joined #zig
mmohammadi9812 has quit [Ping timeout: 256 seconds]
mmohammadi98129 is now known as mmohammadi9812
dead10cc has left #zig [#zig]
ky0ko_ has joined #zig
mmohammadi9812 has quit [Ping timeout: 258 seconds]
marnix has quit [Ping timeout: 258 seconds]
radgeRayden has quit [Ping timeout: 246 seconds]
marnix has joined #zig
dch has quit [Read error: Connection reset by peer]
dch has joined #zig
cole-h has quit [Quit: Goodbye]
marnix has quit [Ping timeout: 264 seconds]
ur5us has joined #zig
earnestly has joined #zig
frett27_ has quit [Ping timeout: 256 seconds]
cow-orker has joined #zig
fengb has joined #zig
ur5us has quit [Ping timeout: 240 seconds]
ur5us has joined #zig
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
ur5us has quit [Ping timeout: 244 seconds]
marnix has joined #zig
cxzuk has joined #zig
<cxzuk>
Hi all, wondering if someone can point me in the right direction. Id like to know if theres something equivalent to templated functions in zig?
<cxzuk>
Yes that looks likely, I think Zig doesn't support function overloading? Id like to make a DSL that takes either a function pointer, a struct, or an enum as its generic component. Is that doable?
<cxzuk>
Thats great, thank you! have a good sunday
_Vi has joined #zig
wjlroe has quit [Read error: Connection reset by peer]
waleee-cl has joined #zig
guan has quit [Read error: Connection reset by peer]
wjlroe has joined #zig
guan has joined #zig
procnto has quit [Read error: Connection reset by peer]
procnto has joined #zig
tracernz has quit [Ping timeout: 272 seconds]
tracernz has joined #zig
omglasers2 has joined #zig
cxzuk has quit [Remote host closed the connection]
xackus_ has joined #zig
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
sealmove has joined #zig
<sealmove>
Hi, I am new to Zig. I downloaded v0.6.0 binary and see that the compiler is 147.5 MB! What's going on? Does it ship with the whole LLVM statically compiled in it?
<ifreund>
yes
<sealmove>
I have LLVM 10 installed on my system. Which .tar file should I use to leverage my existing LLVM installation? zig-0.6.0.tar.xz? zig-bootstrap-0.6.0.tar.xz? or some other?
<ifreund>
all the tar files from the website are statically linked for portability
<ifreund>
if you want a dynamically linked zig you need to get it from your distro's repos or compile yourself
<sealmove>
oh ok thanks
<ifreund>
no problem, have fun playing with zig!
nycex has joined #zig
<sealmove>
thanks :)
klltkr has joined #zig
klltkr has quit [Client Quit]
wootehfoot has joined #zig
klltkr has joined #zig
marnix has quit [Ping timeout: 240 seconds]
omglasers2 has quit [Read error: Connection reset by peer]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
sealmove has quit [Read error: Connection reset by peer]
radgeRayden has joined #zig
radgeRayden has quit [Remote host closed the connection]
a_chou has joined #zig
wootehfoot has joined #zig
<justin_smith>
andrewrk: that binding if suggestion the other day hurt my brain a bit, but it works, here's the most "puzzling" part of my simplifying test (which passes) http://ix.io/2yW5
<justin_smith>
in both branches box.prize is equal to null (in thousands of goes both branches are hit, and both asserts succeed)
<justin_smith>
I needed some carefully placed randomized sleeps to ensure that the race branch is always hit though (but even with the race cmpxchgWeak does its job, of course, keeping the final tally for prizes_claimed correct)
<justin_smith>
if that |_| was |foo| I could assert foo was null as well, but there's really no point in testing the failure branch
<justin_smith>
anyway, your suggestion works and clearly I have some things to learn about binding inside if
a_chou has quit [Ping timeout: 246 seconds]
<ifreund>
if (foo) |f| { // if the "outermost" optional is non-null, unwrap and set f to the contained value
<ifreund>
nested optionals are a pain to work with though, but are luckily not too common
<ifreund>
the "contained value" of f could be null if foo is e.g. a ??u32
a_chou has joined #zig
<pixelherodev>
Hmm.. would a std.meta.noneNull function, which checks a N-level optional recursively and returns the innermost value or null, be useful?
<pixelherodev>
e.g. with ???a you could do `if (std.meta.noneNull(a)) |b| {} else {}`
<ifreund>
I really don't think we sould encourage using nested optionals
<ifreund>
I've never seen a valid use case for ???T, and ??T is already rare enough
* pixelherodev
nods
<pixelherodev>
Hmm... what valid use cases are there for ??T
<pixelherodev>
?
<justin_smith>
ifreund: I wouldn't be using a nested optional, but cmpxchgWeak is optional (null on success, old value on failure), and I need to use it on an optional value
<justin_smith>
pixelherodev: see above
<justin_smith>
if it was up to me cmpxchg{Strong|Weak} would return true/false instead of being an optional
<ifreund>
justin_smith: yes, this is one of the valid use cases where ??T comes up
<ifreund>
and what, use an out argument for the old value?
<ifreund>
i think the current state is fine
<justin_smith>
ifreund: it's already stale by the time you do anything useful with it, just read the thing again
<justin_smith>
perhaps there's subtle techniques where race conditions are avoided if you only have the one transaction rather than a write followed by read?
<justin_smith>
if I'm in a retry loop, reading the pointer again instead of using the failure value is more likely to succeed
<justin_smith>
does it slow things down in the global impact?
<justin_smith>
or maybe that assumption is wrong...
layneson has joined #zig
<justin_smith>
ifreund: my understanding is that on the hardware level, the cmpxchg means that the "old value" is propagated fully to your thread, and your next read is guaranteed to be at least that up to date (the thing being prevented here is chache being out of sync between CPUs)
<justin_smith>
so the very fact you did cmpxchg is enough to get the result you want, you don't need to return the value
<justin_smith>
I welcome correction if that's a misunderstanding
<ifreund>
well, the value could be modified before you get the chance to read it after the cmpxchg
cole-h has joined #zig
<ifreund>
I don't have a use-case in mind, but there's no way to prevent that race if the old value is not returned by the atomic opreation
<justin_smith>
ifreund: but the value could also change after the cmpxchg in all the same cases
<justin_smith>
*would - in all cases where your read after the cmpxchg is invalid, the return value of the cmpxchg was invalid at the same point of execution
<justin_smith>
ifreund: returning the old value doesn't prevent any race though, it's the cmpxchg which asserts the old value which does the race prevention
<justin_smith>
what it *might* arguably do is reduce your retry count, but I'm skeptical
<ifreund>
like I said, I don't have a use-case in mind but the fact that you are losing information that cannot otherwise be obtained without racing
<ifreund>
i agree that this information probably isn't useful though, so maybe it doesn't matter
layneson has quit [Ping timeout: 260 seconds]
<justin_smith>
ifreund: you are losing no information, the cmpxchg on the hardware level already guarantees that the value is synchronized at that point in time, my test pasted above would fail if this weren't true
<justin_smith>
normal usage of the value from memory provides the same information that the cmpxchg does
<justin_smith>
(after that synchronization point occurs- that sync is what cmpxchg offers, not information)
<justin_smith>
that said, it's a minor issue, it just requires counterintuitive unboxing of an optional, and a zig user should understand optionals (I'm closer to that now...)
<justin_smith>
oh, that was sloppy - cmpxchg does provide the important informatin of success / fail, my minor gripe is that that could simply be a boolean
<ifreund>
what stops you from getting pre-empted directly after the cmpxchg and before the normal read by a thread that modifies the value?
<justin_smith>
ifreund: what stops that thread from changing the value after you've already cached the return of "old value" - it's exactly the same situation, you deal with it the same way
<justin_smith>
if anything having one less operation makes the existing race (if any) harder to see in testing
<ifreund>
no, because you don't know what the old value was
<ifreund>
it may not matter what it was, but this is information you are losing
<justin_smith>
ifreund: you read it on failure from the object, it's been synchronized to your thread
<justin_smith>
you get the same result the cmpxchg as currently written provides
<justin_smith>
my test shows that
<ifreund>
I don't think thats guarenteed
<ifreund>
in practice it may happen 99% or even 100% of the time, but I'm pretty sure there is no guarenteed atomicity there
<justin_smith>
it doesn't need atomicity - all I'm saying is your use of the memory location itself is at least as up to date as the return value of the cmpxchg was, relying on anything other than that means you already have a bug
<ifreund>
I agree that it's "at least" as up to date, but it could have been overwritten since the cmpxchg
<justin_smith>
the usage of that primitive means that you have a single known synchronization point, returning true/false vs. optional doesn't change the fact that this is your last sync point
<justin_smith>
ifreund: and that failure case applies equally to the return value of cmpxchg itself
<justin_smith>
any failure of reading the var is also a failure of using that value
<justin_smith>
both are suspect, but known correct as of a specific known op, that's enough
<justin_smith>
(though one is allowed to be slightly fresher.. maybe there's a way that could cause a but)
<justin_smith>
*bug
<ifreund>
that's what I'm saying, splitting the read out of the cmpxchg makes the whole thing non-atomic
<ifreund>
yes the value return may have been changed since the cmpxchng, but it *is* the value you compared with
<ifreund>
if you read after then you can't know if that's the value you compared with or if it's fresher
<ifreund>
I don't know if this actually matters in practice, but I think you are losing some information if cmpxchg doesn't return the old value
<justin_smith>
ifreund: oh, OK - that's what I lost, the case where knowing the older value that's no longer fresh would be potentially useful
<justin_smith>
thanks
nullheroes has quit [Quit: WeeChat 2.9]
<ifreund>
yeah like I said I can't think of any use case for this information, but it is information that would be lost :P
a_chou has quit [Ping timeout: 240 seconds]
_Vi has quit [Ping timeout: 240 seconds]
a_chou has joined #zig
earnestly has quit [Ping timeout: 240 seconds]
Akuli has joined #zig
a_chou has quit [Ping timeout: 240 seconds]
earnestly has joined #zig
st4ll1 has joined #zig
joey152 has joined #zig
_Vi has joined #zig
klltkr has quit [Ping timeout: 256 seconds]
wootehfoot has quit [Ping timeout: 265 seconds]
gert_ has joined #zig
flokli has quit [Ping timeout: 244 seconds]
flokli has joined #zig
_whitelogger has joined #zig
omglasers2 has joined #zig
wootehfoot has joined #zig
ur5us has joined #zig
marnix has quit [Ping timeout: 240 seconds]
pangey has quit [Ping timeout: 256 seconds]
pangey has joined #zig
leeward has quit [Remote host closed the connection]
a_chou has joined #zig
a_chou has quit [Remote host closed the connection]
_whitelogger has joined #zig
Akuli has quit [Quit: Leaving]
wootehfoot has quit [Read error: Connection reset by peer]