<daurnimator>
I wonder if they meant to check the type of pa_volume_t instead of the type of c_uint
schme245 has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
<daurnimator>
Dominic[m]: reading the code, whenever it hits a left paren it assumes the destination type is a pointer.. I'd file an issue
dingenskirchen has joined #zig
schme245 has quit [Remote host closed the connection]
<Dominic[m]>
daurnimator: Thanks, I appreciate your help. Do you mind if I link you the issue once it's open so you can comment if I've missed anything?
<daurnimator>
Dominic[m]: sure
<daurnimator>
Dominic[m]: I'll see it get created in any case
marmotini_ has quit [Remote host closed the connection]
<daurnimator>
Dominic[m]: I have a provisional fix for you; just waiting for you to file an issue so I can post the patch ;)
<dch>
this reads to me like I'm able to modify const S. I can infer that it allows me to modify the inner var of the struct, but why should this be allowed, and for S to maintain its const-ness?
<daurnimator>
dch: note that `S` is a struct; not an *instance* of a struct.
<dch>
daurnimator: #facepalm moment thanks!
<dch>
so it would be pretty standard for struct definitions to be const, then
<daurnimator>
dch: yeah.... though its not the struct that might change, but the type entirely
doublex has quit [Ping timeout: 265 seconds]
<daurnimator>
e.g. `var T: type = undefined; inline while (some_condition) { T = struct { inner: T }; } return T;`
return0e has quit [Remote host closed the connection]
<dch>
daurnimator: when would it be useful to have a variable type then? I'm not used to that in functional world. type inference would be very unhappy
return0e has joined #zig
<daurnimator>
dch: see my example just there: you might be building up a part from pieces.
<daurnimator>
andrewrk: around? I'm encountering an issue where zig translate-c just exits the process with code 1
<dch>
daurnimator: neat I can see how that's useful, but I'm not yet familiar enough with zig format to read that reliably. inline if supplied type can be fitted into 8 or less bytes.
<daurnimator>
dch: huh?
shakesoda has joined #zig
doublex has joined #zig
<Snektron>
daurnimator, why does LinearFifo implement 3 different types of allocator
<Snektron>
Should that be handled by allocators instead
<Snektron>
I mean that it seems out of place that the LinearBuffer handles allocation, as all functionality can be obtained by building around an allocator instead
<Snektron>
.Static is the same as .Dynamic with a FixedBufferAllocator
<Snektron>
Not quite maybe, but that feels like the proper direction to me
<daurnimator>
Snektron: but then if you want .Static you'd have to wrap it in some higher level struct that had a buffer next to it
<Snektron>
Thats the price of abstraction i guess
<Snektron>
I would almost argue to make allocators a comptime parameter (similar to how c++ handles them)
<Snektron>
Best of both worlds plus possibly better optimization opportunities
<Snektron>
Old functionality can be remained by passing *std.mem.Allocator as the allocator type
<Snektron>
(That would be similar to c++'s polymorphic memory thingy's)
<daurnimator>
Snektron: but with the current code you don't have to pay the price of abstraction; or the overhead of the allocator interface for non-dynamic fifos
<Snektron>
Instead you have a type which feels like it implements two things at once
riba has joined #zig
<daurnimator>
usage is the same aside from init?
dddddd has joined #zig
marmotini_ has joined #zig
riba has quit [Ping timeout: 258 seconds]
marmotini_ has quit [Ping timeout: 260 seconds]
wootehfoot has joined #zig
_whitelogger has joined #zig
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
<daurnimator>
Dominic[m]: ?
doublex has quit [Remote host closed the connection]
doublex has joined #zig
mahmudov has quit [Remote host closed the connection]
mahmudov has joined #zig
<Dominic[m]>
daurnimator: Sorry, I've been cooking/cleaning :) Just sat down to do this
mahmudov has quit [Remote host closed the connection]
mahmudov has joined #zig
schme245 has joined #zig
<Dominic[m]>
Is there a naming scheme/strategy used for optional pointers? The docs use the optional_ prefix, but I'm not sure if that's conventional or just for explanation purposes.
doublex has quit [Ping timeout: 260 seconds]
schme245 has quit [Remote host closed the connection]
schme245 has joined #zig
doublex has joined #zig
mahmudov has quit [Remote host closed the connection]
mahmudov has joined #zig
doublex has quit [Ping timeout: 240 seconds]
doublex has joined #zig
doublex has quit [Ping timeout: 268 seconds]
dingenskirchen has quit [Remote host closed the connection]
schme245 has quit [Remote host closed the connection]
dingenskirchen has joined #zig
schme245 has joined #zig
marmotini_ has joined #zig
doublex has joined #zig
marmotini_ has quit [Ping timeout: 260 seconds]
mgxm has quit [Ping timeout: 245 seconds]
mgxm has joined #zig
riba has joined #zig
<Snektron>
I usually do opt
MarquisdeFalbala has joined #zig
Akuli has joined #zig
riba has quit [Ping timeout: 260 seconds]
MarquisdeFalbala has quit [Ping timeout: 252 seconds]
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]