<daurnimator>
the downside (which you already figured out I think) is that you can only have a single robust mutex handler per *process*
<daurnimator>
and usually libc takes it
<scientes>
daurnimator, no, per thread
<scientes>
you are wrong
<daurnimator>
ah yes
<daurnimator>
but yes; prefer eventfd over futexes where possible.
<daurnimator>
it does wonders for the more-common-than-anyone-thinks use case of "wait on mutex or stdin or socket"
<wrl>
i did tests some time ago to see if eventfd was any slower than non-composable signalling primitives (basically, futex and anything on top of it)
<wrl>
but i tested in the blocking case
<wrl>
i'm sure in the case where the futex is elided completely they're faster
<wrl>
but in the blocking case eventfd is no faster or slower than anything else
<wrl>
pipes are the slowest
<wrl>
everything else is pretty much... couple hundred nanoseconds for wakeup
<wrl>
i mean honestly i wasn't even interested in seeing if there was a winner
<wrl>
eventfd being composable is a huge advantage over the futex-based primitives
<wrl>
so i just wanted to see if it were any slower as a result
<wrl>
as it turns out, no
<daurnimator>
wrl: as much as I prefer eventfd; they both have things the other doesn't
<daurnimator>
wrl: e.g. futexes can do priority inheritence to avoid priority inversion
<daurnimator>
my preference is eventfd by default; futexes where you need specific functionality that is unavailable otherwise
<wrl>
ah, good point yeah
<wrl>
daurnimator: i like structuring things in a loose actor pattern, where actors listen on both a mailbox from other actors and also whatever else they need to (sockets, inotify, window system events, etc)
nore has quit [Ping timeout: 252 seconds]
nore has joined #zig
knebulae has quit [Quit: Leaving]
slipyx has joined #zig
marmotini_ has joined #zig
THFKA4 has quit [Quit: WeeChat 2.3]
scientes has quit [Ping timeout: 246 seconds]
xtreak has joined #zig
xtreak has quit [Remote host closed the connection]
xtreak has joined #zig
marmotini_ has quit [Ping timeout: 245 seconds]
marmotini has joined #zig
Hejsil has joined #zig
<Hejsil>
andrewrk, so if all string literals will be `*const [N]null u8`, then I'd assume that all `var a = "abc"` should be turned into `var a = "abc".*` correct?
jjido_ has joined #zig
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 250 seconds]
jjido_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 268 seconds]
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 246 seconds]
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 245 seconds]
xtreak has quit [Remote host closed the connection]
marmotini has quit [Ping timeout: 245 seconds]
marmotini_ has joined #zig
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 250 seconds]
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 255 seconds]
xtreak has joined #zig
neceve has joined #zig
marmotini_ has quit [Ping timeout: 244 seconds]
marmotini_ has joined #zig
marmotini_ has quit [Ping timeout: 246 seconds]
marmotini has joined #zig
forgot-password has joined #zig
<forgot-password>
Hey guys, I just updated to the latest zig build, but when trying to build a recent project I now get an error about std.build.Builder.addCommand. Has the API changed?
shritesh has quit []
<Hejsil>
forgot-password, seems there was two changes. addCommand was replaced with addSystemCommand, and LibExeObjStep got a `run` function
<forgot-password>
Hejsil: Thanks, it seems like addSystemCommand now only takes 2 arguments instead of 4
<forgot-password>
Got it, I just generated a new project via init-exe and did some copying ;)
<forgot-password>
Thank you
marmotini has quit [Ping timeout: 255 seconds]
marmotini has joined #zig
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 268 seconds]
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 250 seconds]
xtreak has quit [Read error: Connection reset by peer]
xtreak has joined #zig
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 250 seconds]
forgot-password has quit [Quit: leaving]
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 272 seconds]
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 246 seconds]
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 250 seconds]
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 250 seconds]
jjido has quit [Quit: Connection closed for inactivity]
marmotini_ has quit [Ping timeout: 245 seconds]
marmotini_ has joined #zig
xtreak has quit [Remote host closed the connection]
xtreak has joined #zig
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 250 seconds]
scientes has joined #zig
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 245 seconds]
xtreak_ has joined #zig
marmotini has joined #zig
xtreak has quit [Ping timeout: 250 seconds]
marmotini_ has quit [Ping timeout: 250 seconds]
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 250 seconds]
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 255 seconds]
xtreak_ has quit [Remote host closed the connection]
marmotini has quit [Ping timeout: 244 seconds]
marmotini_ has joined #zig
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 244 seconds]
marmotini has quit [Remote host closed the connection]
marmotini_ has joined #zig
xtreak has joined #zig
scientes has quit [Remote host closed the connection]
scientes has joined #zig
marmotini_ has quit [Ping timeout: 255 seconds]
marmotini_ has joined #zig
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 272 seconds]
marmotini_ has joined #zig
hg has joined #zig
marmotini has quit [Ping timeout: 272 seconds]
xtreak has quit []
allochi has joined #zig
Hejsil has quit [Quit: Page closed]
fengb_ has joined #zig
fengb has joined #zig
fengb has quit [Client Quit]
dirkson has quit [Quit: Cheers!]
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 244 seconds]
nullheroes has quit [Quit: WeeChat 2.3]
allochi has quit [Quit: Page closed]
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 246 seconds]
wilsonk has quit [Ping timeout: 245 seconds]
marmotini has joined #zig
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
marmotini has quit [Remote host closed the connection]
MajorLag has joined #zig
neceve has quit [Read error: Connection reset by peer]
tgschultz has quit [Ping timeout: 250 seconds]
MajorLag is now known as tgschultz
oats is now known as butt
butt is now known as oats
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 246 seconds]
wilsonk has joined #zig
develonepi3 has quit [Quit: Leaving]
fsateler_ has quit [Ping timeout: 246 seconds]
Ichorio has joined #zig
<andrewrk>
yes Hejsil
wilsonk has quit [Ping timeout: 250 seconds]
wilsonk has joined #zig
wilsonk has quit [Ping timeout: 245 seconds]
dd10 has joined #zig
return0e_ has joined #zig
return0e has quit [Ping timeout: 250 seconds]
dd10 has quit [Quit: Page closed]
dd10 has joined #zig
return0e has joined #zig
return0e_ has quit [Ping timeout: 246 seconds]
marmotini has quit [Remote host closed the connection]
<mikdusan>
is std.LinkedList good for FIFO, or is another more suitable?
<mikdusan>
*is there another more suitable?
<andrewrk>
mikdusan, it's fine as far as time complexity goes, but depending on your particular use case there may be a more optimized data structure that the std lib doesn't have yet
<andrewrk>
it's certainly not a mistake to start with std.LinkedList. easy to swap out the component later
<mikdusan>
yup i’ll use it. just making sure i’m not missing any (better) existing std options
develonepi3 has joined #zig
Hejsil has joined #zig
<Hejsil>
A linked list + A good allocator goes a long way in terms of speed. In the advent of code I did a LinkedList + FixedBufferAllocator solution which was only 4x slower than the ring buffer solution liampwll made
<andrewrk>
Hejsil, in answer to your string literal question above - yep. Or if you wanted to change strings later you'd have to give it a type, like this: var s: []const u8 = "hi"; s = "bye";
<andrewrk>
but dereferencing it would allow you to use it to initialize an array, as you pointed out
<Hejsil>
Right, was just making sure we intended to break this code :)
<Hejsil>
'break' as in breaking change
<andrewrk>
yep. we still have a lot of breakage to go before stabilizing
<andrewrk>
I'm working on a major bug fix - decoupling LLVM types / LLVM debug info types from Zig types in stage1
<scientes>
what is ConstValSpecialUndef ?
<andrewrk>
scientes, `undefined`
<andrewrk>
that's how `undefined` is represented in ConstExprValue
wootehfoot has joined #zig
<scientes>
i'm confused how implicit_cast managed to convert a u16 to a u8
<andrewrk>
I didn't really understand struct layout and alignment when I started zig but now I understand it quite well
<Hejsil>
Aah. I see
<andrewrk>
right now packed structs always have alignment of 1, for every field
<andrewrk>
which makes it only useful for bitfields really
<andrewrk>
but if you have the power to align fields manually then it becomes a powerful tool that can be used to lay things out in memory with great precision
<Hejsil>
Sounds like something that also relates to Zig reordering fields of normal structs
<andrewrk>
(which obviously you only need sometimes; normal structs should be OK for most things)
<andrewrk>
yes, that will be more straightforward after this change too
<andrewrk>
we also don't waste time creating llvm types and debug types that are only used at comptime
<andrewrk>
it's taking me a few days though. with the upcoming release this comes at the cost of some other bug fixes
<fengb_>
[Benjamin Feng, fengb] Wow, looks great. I've been dabbling with writing an emulator and having the language help align the memory correctly would be amazing
fengb has joined #zig
<andrewrk>
scientes, it will probably merge conflict in ir.cpp but in easy-to-resolve ways
<emekankurumeh[m]>
i think in this situation a FixedBufferAllocator, wrapped in a ArenaAllocator would be better
<mikdusan>
point is value needs mutable storage
<allochi>
if the array literals are constant, why when I assign a variable an array literal and use the address of the variable, I can mutate the array.
<allochi>
?
<allochi>
I will paste the snippet, give me a minute.
<emekankurumeh[m]>
i just realized godbolt only compiles the code, it doesn't run it
<allochi>
you see if I assign the array literal to a variable and then use the variable address, I'm able to mutate the array, so it's not constant.
<allochi>
sorry, this is not making sense, the array literal is basically just a memory block inside the code, and is can be accessed and modified.
<mikdusan>
i think you’re right. i’m wrong. but the difference in your code is: 1 does it with a tmp that vanishes. the other does it with storage that’s around longer.
<mikdusan>
line 28. `var a` is alive during use in line 33. while line 14 []i32{24,2} does not live past line 15. yet you use that memory in loop at line 17.
<allochi>
I'm not sure it vanishes, again that array is in the stack, and I try to modify it while I'm still in the same stack.
<allochi>
are you sure? is so what would be the workaround without using the heap?
<allochi>
actually, this is not correct, I'm sorry
<allochi>
it doesn't vanish
<allochi>
the simple proof of that if I comment the line that mutate the array `atest.value[0] = 0;`
<allochi>
the for loop is able to read the first element of every array and prints it out.
<allochi>
if it vanish, then I should get segfault.
<mikdusan>
in your original that’s what i got. a bad access.