schme245 has quit [Remote host closed the connection]
<fengb>
Have fun!
wootehfoot has quit [Read error: Connection reset by peer]
schme245 has joined #zig
schme245 has quit [Ping timeout: 240 seconds]
<daurnimator>
:( `warning: struct demoted to opaque type - has bitfield` leads to `error: opaque types have unknown size and therefore cannot be directly embedded in structs`
dingenskirchen has quit [Remote host closed the connection]
lunamn_ has joined #zig
dingenskirchen has joined #zig
lunamn has quit [Ping timeout: 258 seconds]
lunamn_ has quit [Ping timeout: 268 seconds]
lunamn has joined #zig
frmdstryr has quit [Ping timeout: 260 seconds]
dddddd has quit [Remote host closed the connection]
<daurnimator>
bgiannan: it brings the knowledge that an array is null-terminated into the type system
<daurnimator>
which means it can e.g. save you from passing a non-null terminated pointer to the `open` syscall
<daurnimator>
bgiannan: in zig code itself you should almost always be using slices (where length is known). null-terminated strings mainly show up in C apis
<daurnimator>
bgiannan: one place that you would use them is e.g. your `SDL_LoadBMP` wrapper function.
<bgiannan>
ok so i don't get why std.mem.toSlice returns a null terminated pointer then? shouldn't we just make the slice null terminated when passing it to something that needs it?
<daurnimator>
bgiannan: mem.toSlice returns a null terminated *slice*
<daurnimator>
not just a null terminated many-pointer
<bgiannan>
right
<bgiannan>
the question remains
<daurnimator>
that means it has known length, but *also* there is a null at the end
<bgiannan>
i get what it is i just don't get why we need it there
<daurnimator>
it means we can e.g. call open() on it without dupe-ing the string
<Dominic[m]>
I have a c string, how can I print/compare it?
<daurnimator>
Dominic[m]: std.cstr.cmp?
<Dominic[m]>
Well, I have a *c_void which I've cast to a *[]u8, and `warn()` just prints it as a pointer.
schme245 has joined #zig
<bgiannan>
daurnimator, so we imply that most use of std.mem.toSlice() is to make calls that require null terminated slices ?
<daurnimator>
Dominic[m]: you probably wanted to cast it to a `[*]u8` and then use `mem.toSlice` on it
<bgiannan>
daurnimator, Buffer.toSlice() now returns a null-terminated slice so I have to either propagate that everywhere or make a utility function that only returns a regular slice
<daurnimator>
bgiannan: mem.toSlice is for converting a null terminated many-pointer to a slice. that its a null terminated slice is a bonus
<daurnimator>
bgiannan: null terminated slices should coerce to non-terminated slices
<bgiannan>
they should?
<bgiannan>
if they do i'm fine with it
<bgiannan>
if have this use case: `var my_slice = if (something) a_buffer.toSlice() else a_slice;`
<bgiannan>
-> expected type '[:0]const u8', found '[]const u8'
<bgiannan>
i should give my_slice an explicit type i guess
<daurnimator>
bgiannan: in that case its alerting you of a danger: you passed a possibly non-null terminated thing to something that expects a null terminated thing
wootehfoot has joined #zig
<Dominic[m]>
daurnimator: I had to do `[*:0]u8` as the cast fwiw :)
<Dominic[m]>
Bit of a monster: `toSlice(u8, @intToPtr([*:0]u8, @ptrToInt(user_data)))`
<daurnimator>
Dominic[m]: ah yep. exactly the thing bgiannan is probably hitting right now :)
<daurnimator>
Dominic[m]: uhhhh why are you ptrtoint and back again?
<daurnimator>
that's "super bad"
<Dominic[m]>
daurnimator: I'll take an alternative, but I think I have to because my input is a `*c_void`
<daurnimator>
Dominic[m]: use @ptrCast
<Dominic[m]>
I think I did, and it didn't like my going from a singular to plural. That may not apply now there's a sentinel, will try.
<Dominic[m]>
Yeah, that works :) Thanks daurnimator! I had problems with `@ptrCast(*[]u8, user_data)`: ` error: cast increases pointer alignment`
<Dominic[m]>
I don't think I've properly understood what `*[]` means. Does it actually mean pointer to an empty array or something?
<daurnimator>
Dominic[m]: `*[]u8` is a pointer *to* a slice
<Dominic[m]>
ah, I see I've misread the docs on pointers now. Thank you :)
<daurnimator>
Dominic[m]: a pointer to a slice requires an alignment of your pointer width (probably 8); while your *c_void would have alignment 1
<Dominic[m]>
daurnimator: Ah, I see. Thank you for explaining that, it's very helpful.
return0e_ has joined #zig
<daurnimator>
bgiannan: shouldn't need to make it explicit on `my_slice` I think? what type is `a_slice`?
<bgiannan>
daurnimator, the actual use case was: `a_buffer.append(if (something) another_buffer.toSlice() else a_slice)`
<daurnimator>
bgiannan: and what was the issue/error?
<bgiannan>
`expected type '[:0]const u8', found '[]const u8'`
<daurnimator>
bgiannan: thats odd... what does the compiler note point at?
<daurnimator>
is this a weird peer type resolution thing?
<Dominic[m]>
Well, here is the result of my playing with zig https://github.com/SevereOverfl0w/pulse-volume :) There's another ptrToInt(intToPtr) in there if anyone has a better idea for that case.
<bgiannan>
Dominic[m], i'd say @ptrCast should fit all of those
<daurnimator>
Dominic[m]: should ptrcast to `[*:0]const u8`
<daurnimator>
bgiannan: I don't think it will? if `pa_context_get_sink_info_list` is declared to take a *c_void you won't be able to pass a const pointer into it?
<daurnimator>
Dominic[m]: that said, you could pass a pointer to a pointer in instead :)
<daurnimator>
(assuming that the callback doesn't outlive the function... which is looks like to me?) `pulse.pa_context_get_sink_info_list(c, get_sink_info_callback, &default_sink_name)`
<Dominic[m]>
daurnimator: Do you mean on line 17?
<daurnimator>
Dominic[m]: 35
<Dominic[m]>
that I should ptrCast to const u8, that is.
<Dominic[m]>
`@ptrCast([*:0]const u8, default_sink_name)` gives me `cast discards const qualifier`
<daurnimator>
really?
<Dominic[m]>
Yeah
<Dominic[m]>
`default_sink_name: [*c]const u8,` this is the line in the struct that cimport generated.
<daurnimator>
Dominic[m]: that doesn't sound right...
<daurnimator>
I just meant adding the `const` on 17
<Dominic[m]>
Oh :) Okay!
<Dominic[m]>
Going to have a play with passing a pointer to the string too, sounds like an interesting idea.
wootehfoot has quit [Read error: Connection reset by peer]
<daurnimator>
Dominic[m]: can `sink.*.name` be just `sink.name`?
<Dominic[m]>
daurnimator: `error: type '[*c]const .cimport:1:15.struct_pa_sink_info' does not support field access`
<daurnimator>
hmm okay.
<daurnimator>
Dominic[m]: I think you can declare your callback as taking a ?*const pulse.struct_pa_sink_info instead
<Dominic[m]>
daurnimator: I can indeed. And then I can use sink.name! Thanks. Does zig figure out that it needs to do some conversion?
<daurnimator>
Dominic[m]: [*c] is for auto-converted C files where we can't tell if its a pointer-to-many or a pointer-to-one.
<Dominic[m]>
Ah! That's useful to know.
<Dominic[m]>
daurnimator: I'm beat. I don't know how to make the `get_sink_info_callback` code get the default sink when it's passed as a pointer (via `&default_sink`). I've tried making the pointer cast a `*(...)` to say it's a pointer to that, but with no luck. I'm sure it's something obvious :)
<daurnimator>
Dominic[m]: paste your latest and I'll throw some ideas at it
<daurnimator>
Dominic[m]: FYI I'm on top of PR #3973 right now. So there's a few related changes for that too
<daurnimator>
Dominic[m]: and how do I use the program?
<Dominic[m]>
daurnimator: If you're on linux you can build with pulseaudio-devel installed, and just run `./pulse-vol` and it should print out the volume.
<daurnimator>
Dominic[m]: it doesn't print anything... just sits there
<daurnimator>
strace says its in a `ppoll`
<Dominic[m]>
Oh, the version you have won't do anything. The version on GitHub works. Apologies, I sent you my "this is what I was trying" version. You'll need to uncomment line 35, and comment line 36.
mahmudov has joined #zig
schme245 has quit [Remote host closed the connection]
<Dominic[m]>
The intention is to have this code replace a mixed shell out between pactl and alsactl for use with lemonbar.
<daurnimator>
Dominic[m]: nope still hangs....
<Dominic[m]>
Hmm. All I can think is that pulseaudio isn't running on your machine?
<daurnimator>
I'm listening to spotify right now :P
<Dominic[m]>
Just to make sure, this is the line you have? `const o = pulse.pa_context_get_sink_info_list(c, get_sink_info_callback, @intToPtr(*c_void, @ptrToInt(default_sink_name)));`
<daurnimator>
`const o = pulse.pa_context_get_sink_info_list(c, get_sink_info_callback, &default_sink_name);`
<daurnimator>
No I changed it to: `var default_sink_name = mem.toSliceConst(u8, server_info.default_sink_name);`
<Dominic[m]>
I would assume that it's failing the default sink name comparison, I debugged that by having `warn` print out the default sink name.
<daurnimator>
Dominic[m]: I see the issue: `get_sink_info_callback` isn't called imediately, so the stack-allocated default_sink_name is invalid
<daurnimator>
so you were right: the ptrtoInt/IntToPtr dance is required
<Dominic[m]>
Ah I see. Yeah. There's some kind of async dance going on.
<daurnimator>
makes me think those _unref calls are incorrect
<Dominic[m]>
I took those directly from the pactl source, so I've assumed they're right. But it's something I want to look further into. They don't look right.
<Dominic[m]>
I first want to see if I can get pulse's async to work with zig's async. Might clean the code up a bit.
<daurnimator>
that's likely to be a lot of work
<Dominic[m]>
Why's that?
<daurnimator>
maybe not; you'll see I guess
<daurnimator>
but zig's async mainloop is quite immature
<daurnimator>
Dominic[m]: after it prints my volume should it quit?
<Dominic[m]>
daurnimator: try adjusting your volume or changing the default device.
<daurnimator>
Dominic[m]: ah cool; so it prints on change. makes sense :)
<Dominic[m]>
daurnimator: That's great, thanks! I really appreciate you taking the time to do that.
<daurnimator>
Dominic[m]: I also noticed that the pulseaudio API abuses enums for flags :(
<daurnimator>
Dominic[m]: e.g. trying to print the `sink` structure makes zig panic because the enum field isn't a valid enum
<Dominic[m]>
daurnimator: yeah, that gave me some trouble when I was trying to bit cast the flags. Although I didn't know that it was partially because I was just missing an intToEnum around the whole thing at the start.
<Dominic[m]>
This is the first language I've played with in a long while, I quite enjoy making beginner mistakes like this :)
<daurnimator>
Dominic[m]: zig is good at making flaws in C apis apparent
<Dominic[m]>
Yeah.
<Dominic[m]>
daurnimator: Are enum literals the reason that `.PA_CONTEXT_READY` works in the comparison?
<daurnimator>
Dominic[m]: yes
<daurnimator>
Dominic[m]: in #3973 some C gets translated better by the @cImport
dddddd has joined #zig
teatec has joined #zig
<Dominic[m]>
daurnimator: Do you use `zig fmt`? I ask because your code formatting looks better to me as the lines are long, but zig fmt puts it back for me, and zig fmt is run automatically on write in vim.
<daurnimator>
Dominic[m]: yes
<daurnimator>
Dominic[m]: add a trailing comma to get zig fmt to multi-line it
<daurnimator>
`myfunc(1,2,3,)` ==> will put one arg per line
<Dominic[m]>
ah! that's the missing special symbol.
mahmudov has quit [Ping timeout: 258 seconds]
frmdstryr has joined #zig
mahmudov has joined #zig
mahmudov has quit [Read error: Connection reset by peer]
mahmudov has joined #zig
waleee-cl has joined #zig
<daurnimator>
uh, how can I add a usize and an isize? I know that the isize is no more negative than the usize is large
<daurnimator>
I guess `x %+ @bitCast(usize, y)`.... that's how it works at the cpu level
<mq32>
daurnimator: you can safely use bitCast then as zig guarantees two's complement
<Dominic[m]>
daurnimator: Did you build your version of that diff? I'm not able to get the bitwise-or to compile, I'm getting `invalid operands to binary expression: '.cimport:7:15.enum_pa_subscription_mask' and '.cimport:7:15.enum_pa_subscription_mask'` I'm guessing that's different on #3973 too?
<daurnimator>
Dominic[m]: yep
lunamn_ has quit [Ping timeout: 240 seconds]
lunamn has joined #zig
return0e_ has quit [Remote host closed the connection]
return0e_ has joined #zig
mahmudov has quit [Ping timeout: 258 seconds]
return0e_ has quit []
marmotini_ has joined #zig
<Snektron>
Those casts with arithmetic are kinda annoying tbh
marmotini_ has quit [Remote host closed the connection]
mahmudov has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
schme245 has joined #zig
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
frmdstryr has quit [Quit: Konversation terminated!]
WendigoJaeger has joined #zig
<schme245>
what's the easiest way to open a file in the same directory as a source file?
<schme245>
I'm looking at the docs but I can't find a way to get a Dir other than `cwd()`?
mahmudov has quit [Read error: No route to host]
mahmudov has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
WendigoJaeger has quit [Quit: Connection closed for inactivity]
lunamn_ has joined #zig
lunamn has quit [Ping timeout: 265 seconds]
kirke67 has quit [Ping timeout: 260 seconds]
ky0ko has joined #zig
darithorn has joined #zig
frmdstryr has joined #zig
WendigoJaeger has joined #zig
ur5us has joined #zig
mahmudov has quit [Read error: Connection reset by peer]
mahmudov has joined #zig
<wilsonk>
schme245: check out lib/std/fs.zig:695 for openFile. That func works with relative paths. (createFile is a few lines further down, if needed). Hopefully that is what you are looking for
<schme245>
wilsonk:
<schme245>
wilsonk: hmm... openFile takes a Dir argument, how do I create a Dir for the current path in the first place?
frmdstryr has quit [Ping timeout: 268 seconds]
<jicksaw>
std.fs.cwd() gives current working Dir
<jicksaw>
oh just saw your previous msg
<jicksaw>
wouldn't fs.makeDir("path") work?
<wilsonk>
you could just do 'const file = try std.fs.cwd().openFIle(file_name, .{});' I think
<schme245>
wilsonk: cwd depends on which dir you are running the code in which is not what I'm after in this case
<schme245>
BaroqueLarouche: thanks, will check it out!
<wilsonk>
oh, I see...the same file as the source file. Just use openFIleAbsolute like BaroqueLarouche says then, I suppose (feed it the directory of the source file)