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/
mq32 has joined #zig
<fengb> How should I represent ternary with vectors?
waleee-cl has quit [Quit: Connection closed for inactivity]
cshenton has joined #zig
<daurnimator> fengb: like are you asking about `all` vs `some`?
<daurnimator> fengb: or do you mean you want to do a ternary on all members and get a vector result
jokoon has quit [Quit: jokoon]
<fengb> The latter. I want an array of op(a) ? a : b
<fengb> Er... vector
<cshenton> If it's a vector of primitives you could always use a mask and sum the results.
<cshenton> Which I think is how vector math libraries usually implement ternary if under the hood.
<fengb> I was trying to avoid figuring out the hard part myself >_>
<cshenton> Give me a moment I'll see what I can find.
<fengb> Bit math doesn't come to me naturally so I'd have to spend hours drawing diagrams. Was hoping for some shortcut
<fengb> Thanks
lunamn_ has joined #zig
lunamn has quit [Ping timeout: 258 seconds]
<cshenton> fengb: This is non generic but should convey the general idea https://gist.github.com/cshenton/10f3ce16c2646878885ec7f6b91e7175
<cshenton> Apologies for any hard edges, only started using the language yesterday :)
<fengb> Ah cool, thanks!
<fengb> Well... I only started using vectors ~5 minutes ago so we're all learning :)
<cshenton> No problem, I'm a fan of how zig's exposing vector types, but at the moment it involves a lot of explicit casting.
<cshenton> Going to see if I can make a generic version of this.
<fengb> Scientes had some major changes on his fork: https://github.com/ziglang/zig/pull/2945
<fengb> I think he also wanted to see inferred return types because of the explicit casting
<scientes> fengb, inferred return types was wanted, but what for is not there
<scientes> cshenton, there are much more serious problems than the type system
<cshenton> I'm not a huge fan of inferred return types, you can always be explicit at compile time if you want generic return types.
<scientes> such as vector index accesses being done wrong, despite me pointing out that the way it is being done is incorrect
<scientes> and knowing the correct way, which is how gcc does it
<cshenton> In my experience (using julia) they are error prone because they create accidental union types all over the place.
<scientes> this mistake means that it is possible I will completely abandon my work
<cshenton> How so?
<cshenton> I know it used to be the case in C that you had to cast to array before doing index access.
<scientes> cshenton, that isn't true
<scientes> not on any clang or gcc
<scientes> the only thing that held me back from coding it the right way was not understanding an unrelated piece of code: copy elision.
adamkowalski has quit [Quit: Lost terminal]
dimenus has quit [Remote host closed the connection]
<cshenton> I thought pre 4.6 that you had to use a union type for element access, such as on this stackoverflow post from 2009 https://stackoverflow.com/questions/1771945/c-how-to-access-elements-of-vector-using-gcc-sse-vector-extension
<cshenton> (in gcc)
<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 joined #zig
ur5us_ has quit [Ping timeout: 248 seconds]
lunamn_ has quit [Ping timeout: 268 seconds]
lunamn has joined #zig
<cshenton> Trying to recreate some of the generic apis I'm used to in scientific computing, zig is pretty nice for this kind of stuff https://gist.github.com/cshenton/e7ff7632ca51afa0a46846ba672bcb49
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:
lunamn has quit [Ping timeout: 258 seconds]
lunamn has joined #zig
ur5us_ has joined #zig
darithorn has joined #zig
mattmurr has joined #zig
dddddd has quit [Remote host closed the connection]
cshenton has joined #zig
benjif has quit [Read error: Connection reset by peer]
<cshenton> Can anyone link a `zig.build` file that builds a c library from source, then links it with some zig code into a static executable?
benjif has joined #zig
<cshenton> Doing game stuff and I develop on multiple OS' so I want things to be pretty system independent, vendored dependencies etc.
cshenton has quit [Remote host closed the connection]
ur5us_ has quit [Ping timeout: 245 seconds]
darithorn has quit [Quit: Leaving]
return0e has joined #zig
jokoon has joined #zig
daex has quit [Ping timeout: 250 seconds]
daex has joined #zig
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
lunamn has quit [Quit: Lost terminal]
<pixelherodev> Has lazy analysis changed recently?
<pixelherodev> Just updated the compiler and suddenly it noticed that a function that isn't being used was invalid :P
<pixelherodev> I'm not using @typeInfo at all
FireFox317 has joined #zig
<FireFox317> pixelherodev: Regarding the comment on my PR on ClashOS, did you see this change by daurnimator? https://github.com/ziglang/zig/commit/c0cb6767451441fcc9cd3dc4fee3b4794c8b0646
<pixelherodev> Vaguely a while back
<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?
marmotini_ has joined #zig
Pistahh has joined #zig
Yardanico has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
waleee-cl has joined #zig
iq has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
dimenus has joined #zig
Yardanico has joined #zig
benjif_ has joined #zig
benjif has quit [Ping timeout: 265 seconds]
leeward has joined #zig
<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]
casaca has joined #zig
dimenus has joined #zig