<cshenton>
I'm still curious how you think the vector element access in zig is wrong. I'm going to be doing tonnes of SIMD stuff in userspace so it would be good to know of any hard edges.
cshenton has quit [Remote host closed the connection]
nephele has quit [Ping timeout: 248 seconds]
nephele has joined #zig
muffindrake has quit [Ping timeout: 246 seconds]
muffindrake has joined #zig
darithorn has quit [Read error: Connection reset by peer]
cshenton has quit [Remote host closed the connection]
leeward has quit [Disconnected by services]
lunamn has quit [Ping timeout: 240 seconds]
leeward has joined #zig
<leeward>
Does anyone have examples of std.Mutex being used?
lunamn has joined #zig
<leeward>
Reading the code, it looks like it's safe to deinit after taking the lock, but I'd like someone else to agree that that's the intent before I go using it.
plumm has quit [Quit: Lost terminal]
_whitelogger has joined #zig
lunamn has quit [Ping timeout: 240 seconds]
lunamn has joined #zig
_whitelogger has joined #zig
leeward has quit [Quit: *Poof*]
ikan-keli_ has quit [Ping timeout: 268 seconds]
lunamn has quit [Ping timeout: 265 seconds]
lunamn has joined #zig
lunamn has quit [Ping timeout: 265 seconds]
lunamn has joined #zig
<mikdusan>
leeward: yup just acquire and defer release and for the rest of block scope you are good:
<pixelherodev>
That's the one that introduced the assert?
<pixelherodev>
There's only two asserts shown there
<pixelherodev>
One removed, one added, and AFAICT they're the same
marmotini_ has joined #zig
<FireFox317>
Nope, that commit is just some refactoring changing how to call the dwarf debug info methods. The assert was added a long time ago. Are you hitting that same assert?
<pixelherodev>
Not sure at the moment
<pixelherodev>
I haven't checked in at least a montj
<pixelherodev>
month*
<pixelherodev>
Only changes I've made since October were bug fixes / improvements needed for the game I was making
<pixelherodev>
I noticed stack tracing was broken after doing some testing upon merging those changes into my main kernel source tree and removing the overridden standard library and swapping to the custom OS layer
<pixelherodev>
though I vaguely remember it breaking a while before that
<pixelherodev>
On a different note, a suggestion for 0.6: `zig fmt` should automatically update e.g. calls to std.fmt to use tuples
<pixelherodev>
Would make transition a lot smoother
Pistahh has quit [Remote host closed the connection]
<FireFox317>
Hmm okay, so it just doesn't work? Do you get a already panicking panic?
<pixelherodev>
Yeah
<pixelherodev>
Another unrelated question: did ArrayList.iterator go byebye?
<pixelherodev>
Updating my code in hope that a critical compiler bug has already been fixed :P
<pixelherodev>
Never mind, tests show a better method anyways :)
<FireFox317>
Yes, ArrayList.iterator is gone -> for(list.toSliceConst()) |element|
<pixelherodev>
Hmm... "/usr/local/lib/zig/std/fmt.zig:97:13: error: type 'usize' does not support field access"
<pixelherodev>
Ah
<pixelherodev>
Yeah, the error message isn't clear but it's definitely my code :P
<pixelherodev>
Dangit! All this and the compiler error is still not fixed :(
<pixelherodev>
Whelp
<pixelherodev>
Guess that means I really should open an issue for it
<FireFox317>
What is it about?
<pixelherodev>
Weird comptime crash
<pixelherodev>
I'm using an inline while loop to automatically populate a settings structure
<pixelherodev>
If the structure member is a bool, then e.g. `--hello` sets it true
<pixelherodev>
If it's an optional slice of u8s, it reads the next arg and uses that
<pixelherodev>
It works if there's only one `?[]const u8` in the structure
<pixelherodev>
To make things even more fun, changes in the LLVM IR output by the updated compiler require tweaks to the backend :P
<pixelherodev>
Nothing major though, which is good - just needed to support false/true constants
<FireFox317>
Hmm okay, yeah that is annoying
<pixelherodev>
Which one? :)
<FireFox317>
comptime crashes xd
<pixelherodev>
;)
<pixelherodev>
Huh - so apparently, my compiler build is slightly out of date despite having literally just `git pull && make`d.
<pixelherodev>
and installed ofc
<pixelherodev>
"Fortunately," after fixing that and updating, the error is still here :(
return0e has quit [Remote host closed the connection]
marmotini_ has quit [Remote host closed the connection]
return0e has joined #zig
return0e has quit [Remote host closed the connection]
return0e has joined #zig
FireFox317 has quit [Remote host closed the connection]
qazo has quit [Quit: ...]
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
protty has joined #zig
<protty>
would it be a good trade-off to allocate about 3 words per socket, abstract it out and support parallel reading/writing or keep the current exclusive access and avoid the allocation?
<leeward>
mikdusan: I'm talking about freeing the mutex's memory, not just taking and releasing it. For example, pthreads mutexes say this: "It shall be safe to destroy an initialized mutex that is unlocked. Attempting to destroy a locked mutex results in undefined behavior."
<leeward>
Which is slightly inconvenient, since I'd like to use the mutex itself to guarantee that nobody's holding it when I go to free it.
<leeward>
It doesn't look like Zig uses futex, though, so...maybe it's safe?
marmotini_ has quit [Remote host closed the connection]
<protty>
leeward: std.Mutex doesnt allocate any memory, on linux it uses a per thread futex through std.ResetEvent. Its `deinit` is effectively a no-op https://github.com/ziglang/zig/blob/master/lib/std/mutex.zig#L62 so you dont technically have to call it but thats probably not correct
dddddd has joined #zig
<protty>
e.g. if you free it while holding it and you dont call `Held.release()`, then all the other threads trying to acquire/waiting on the mutex would either deadlock or access invalid memory which may be UB
<leeward>
protty: Mmm, so I probably ought to do what I do in pthreads: grab it to make sure nobody else is holding it, release it, then free it and ensure that nothing else tries to acquire it during my shutdown procedure.
<protty>
that is not correct either as when you release it, your thread could be preempted, another thread could then acquire it, get preempted, let yours run and then you try and free a mutex that another thread is now holding. It wouldnt be atomic. A possible solution would be to either make sure that deinit cant be called by multiple threads or use a
<protty>
mutex to synchronize your mutex ... in which case the design should have a second glance
marmotini_ has joined #zig
<protty>
actually, nevermind. I can see some cases where using a mutex to access a mutex would be valid
marmotini_ has quit [Ping timeout: 248 seconds]
lygaret has joined #zig
return0e_ has quit [Ping timeout: 250 seconds]
return0e_ has joined #zig
return0e has quit [Ping timeout: 258 seconds]
<leeward>
protty: The acquire-before-free thing should never wait. It'd probably be preferable to just peek it and make sure it's unlocked, but there's no mechanism for that with Zig mutexes at the moment.
<leeward>
Wrapping it in a mutex when we're tearing things down just bumps the problem up a level. Now we have to destroy the outer mutex somehow.
<leeward>
The problem is that I'm making a library, and I don't have complete control over the overall thread situation. Documentation only gets you so far.
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
<protty>
Could you clarify on "should never wait"? As for peeking, there should now be `std.Mutex.tryAcquire(): ?Held` which should work both inside and outside the critical section. But if the goal is "peek, then free" then that needs to be done atomically as pointed out earlier
<protty>
Mostly opinion, but in general code should be written sequentially instead of guarding against possibility of parallel. The latter can lead to slower single threaded performance & design complication.
<dimenus>
can the results of an if expression be directly assigned to a variable?
<fengb>
Yes, `const foo = if (bar) 1 else 2;`
<dimenus>
hmm, maybe because my if expressions were nested
marmotini_ has joined #zig
<fengb>
Yeah I noticed nested expressions have some problems
lygaret has quit [Ping timeout: 265 seconds]
lygaret has joined #zig
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
<dimenus>
hmm optional types don't support struct init syntax
lunamn has joined #zig
darithorn has joined #zig
schme245 has joined #zig
<schme245>
is the roadmap posted in the 0.5 release notes still somewhat accurate?
jokoon has left #zig [#zig]
schme245 has quit [Remote host closed the connection]
schme245 has joined #zig
FSX has quit [*.net *.split]
bkleiner has quit [*.net *.split]
tbodt has quit [*.net *.split]
FSX has joined #zig
bkleiner has joined #zig
protty has quit [Ping timeout: 260 seconds]
schme245 has quit []
diginet has quit [*.net *.split]
terinjokes has quit [*.net *.split]
wtw has quit [*.net *.split]
Nazral has quit [*.net *.split]
nore has quit [*.net *.split]
niftynei has quit [*.net *.split]
wtw has joined #zig
niftynei has joined #zig
diginet has joined #zig
nore has joined #zig
terinjokes has joined #zig
casaca has joined #zig
D3zmodos has quit [*.net *.split]
dtz has quit [*.net *.split]
<leeward>
protty (in case you look at the IRC logs): I meant that by design the mutex should never be held when it's about to be deinit'd. The peek-then-free approach is just so I can have slightly better error messages in the event that my library is misused.
ur5us_ has joined #zig
clktmr has joined #zig
clktmr has left #zig [#zig]
iq has quit [Quit: Leaving]
<dimenus>
got bitten by [*c] just now, it will take basically any value
<dimenus>
i accidentally fat figured slice.len as the value instead of slice.ptr
<dimenus>
and no complaints from the compiler
ur5us_ has quit [Remote host closed the connection]
<dimenus>
i guess that makes sense though, i should remember to sanitize my cimport's for types like that
ur5us_ has joined #zig
wootehfoot has joined #zig
dom96 has quit [Ping timeout: 268 seconds]
casaca has quit [Quit: leaving]
dom96 has joined #zig
dimenus has quit [Ping timeout: 268 seconds]
marmotini_ has quit [Remote host closed the connection]