<ifreund>
luckily the zig build system makes compiling C code to work around that issue easy enough
racoon has quit [Remote host closed the connection]
racoon has joined #zig
racoon has joined #zig
racoon has quit [Changing host]
hspak has quit [Quit: Ping timeout (120 seconds)]
<andrewrk>
honestly one of the biggest value adds of zig is that it's simple enough that when you inevitably have to do some hacky workaround for your specific use case, the resulting complexity is still tolerable
hspak has joined #zig
<ifreund>
yeah, that's pretty much what's allowed me to get so far with river
<ifreund>
I seriously doubt I would be farther along in any other language aside from probably C
<ifreund>
but the zig code is safer and is about to get safer still with zig-wayland/zig-wlroots
<dominikh>
oh, question about your wayland scanner + zig build integration: are you just spitting files into the file system, or can you feed source code directly into zig?
<ifreund>
I'm just spitting files into the file system for now, I'd love to integrate this with zig's caching system though when that hopefully becomes feasible some day
<dominikh>
well, lemme know when you have lists and I'll try migrating over to your bindings :)
<ifreund>
cool, I actually just started poking at lists
ur5us has joined #zig
omglasers2 has quit [Read error: Connection reset by peer]
<ifreund>
also, I know the scanner code is super ugly, I wrote it very quickly without much thought about design.
<dominikh>
as long as it works I won't look at it
<ifreund>
heh
<ifreund>
I mean it's likely you'll try to do something I haven't tried yet, but I'm not aware of any major issues left
<dominikh>
I would assume that we use largely the same protocols
<ifreund>
well, I haven't finished porting river to zig-wlroots/zig-wayland yet so only what tinywl.zig uses is really tested
<dominikh>
ah.
<dominikh>
I mean, I did write a wayland scanner once, so as long as the code isn't _too_ terrible to look at…
<ifreund>
It's mostly ugly cause I was trying to avoid allocations when I really shouldn't have cared very much
<dominikh>
in the scanner itself, or the generated code?
<g-w1>
is async implimented only in zig, or also in llvm?
<g-w1>
i mean, is it implimented in the compiler, or llvm
<ifreund>
it would also greatly benefit from that PR adding named format specifiers for std.format
<ifreund>
in the scanner itself
<ifreund>
the generated code doesn't do any allocations directly, though libwayland does of course
<dominikh>
ah. yeah, not sure allocations are a big problem when parsing small XML files, in a build step
<dominikh>
I'm all for speed and stacks, but still :P
<ifreund>
no, they really aren't and I use arenas anyways
<ifreund>
I should really clean it up at some point but it works and my TODO list is a mile long
<dominikh>
mine is about 70 years long at this point…
<dominikh>
unrelated, Zig's allocators are really great. makes it trivial to add Tracy memory profiling to an allocator via a simple wrapper
<dominikh>
(too bad most allocations will happen inside C land for us)
<ifreund>
yeah, I love the zig std handling of allocators. Arenas feel so nice to use
k69 has joined #zig
<ifreund>
true that :/
<ifreund>
maybe I'll rewrite wlroots in zig some day when I'm really really bored
<k69>
i might have the dumbest question
<ifreund>
probably not though, I don't have the graphics chops
<dominikh>
ifreund: theoretically you should be able to replace it bit by bit
<k69>
variables cannot be shadowed right?
<k69>
i'm trying to recursively acces a struct field
<ifreund>
dominikh: indeed, the big downside would be that I'd lose out on or have to port any new work
<dominikh>
ifreund: yeah, that's the downside. but you already have to keep atop new releases because of your bindings, anyway. no backwards ABI compatibility in wlroots
<g-w1>
k69: yes variables cannot be shadowed
<ifreund>
unless I can convince emersion to port the official implementation to zig after zig is stable :P (seems unlikely)
<dominikh>
(and a million unstable interfaces, anyway)
<ifreund>
dominikh: yeah, but updating the bindings for releases is pretty easy. wlroots doesn't break all that much anymore
<ifreund>
just git log -p include/wlr
<dominikh>
ifreund: well, you could probably replace a fair bit of wlroots by implementing the right interfaces, if you manage to punch through the coupling
<ifreund>
g-w1: async is implemented only in zig afaik
<dominikh>
not sure wlroots needs many graphics chops, either. the actual rendering is pretty simple, and the whole DRM+KMS+GBM stack is just annoying, not that difficult
<k69>
g-w1 thanks
k69 has quit [Remote host closed the connection]
<ifreund>
dominikh: could be, I just haven't touched any of that code before
<dominikh>
time flies. soon, it'll be 10 years in the future and you'll slowly have replaced all the bits of wlroots
<ifreund>
also renderer_v6 is only just getting implemented now and that's an example of something that I probably would have trouble coming up with on my own
<dominikh>
haven't looked at that yet
<ifreund>
not to mention the xwayland stuff which I really don't care about the details of but is good to have
<dominikh>
how much worse than writing an X11 WM can it be :P
<ifreund>
no idea, and I don't want to learn how to write an X11 wm :P
<dominikh>
you're in luck, I've written one :P
<ifreund>
there's a reason I started writing wayland code instead of X11 code
<ifreund>
how was it?
<dominikh>
pleasant enough. but I didn't use the C libs; someone wrote a pure Go implementation of the X protocol
<ifreund>
neat
<dominikh>
main reason I want to move to Wayland is that it lets me draw windows wherever and redirect input. in X11, you can't really do that. the coordinates of clients are known to the X11 server
<dominikh>
so if you don't draw in the right place, input is busted
<ifreund>
right, X gives the clients way more information/power than wayland does
a92 has joined #zig
<ifreund>
I mostly started writing wayland code because the protocol seemed simpler/easier to understand to me than whatever was going on with X
<earnestly>
ifreund: (Yes, snake_case is fine. That's the normal style for everything in Ada)
<dominikh>
well, it's much easier to get an X11 window manager going, since you have much fewer responsibilities
<ifreund>
not too happy with some stuff like the semi-mandatory CSDs, but in general it's been quite nice
<dominikh>
Let's be fair, only GTK3 stuff has mandatory CSDs at this point. and I don't mind them too much, as long as you can get rid of the drop shadows
<earnestly>
Sidechannel boogaloo; who owns this memory? Who cares! Wayland is the future
<ifreund>
dominikh: very true, though I like the fact that wlroots + my compositor have an order of magnitude fewer LOC than the xorg server
<dominikh>
that is true
<earnestly>
aka libuaf
<ifreund>
I sent gtk a PR implementing xdg-decoration but it's been sitting there without review for months
<ifreund>
I should probably follow up or something but I really hate hacking on that codebase
<dominikh>
it's a political issue at this point
<ifreund>
they already support the super outdated kde server-decoration protocol
<ifreund>
which I don't really feel like implementing in river
<dominikh>
though, it's a bit of a difficult situation. they put actual functionality in the CSD; where does that go without CSD?
<ifreund>
like what? the close and minimize buttons?
<dominikh>
as I understand it, that whole top bar is the CSD
<ifreund>
yeah I think you're right
<dominikh>
they call em header bars
<dominikh>
but here's a fun thought: nobody is saying that your compositor has to render the whole surface… you could cut off the CSD ;)
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ifreund>
true that
<dominikh>
anyway, drop shadows in the default theme aside, I don't really find header bars that offensive. bunch of actually useful buttons; it just happens to also do resizing and moving. requests that you can deny
<ifreund>
Yeah my main annoyance is with the shadows, though telling the clients they are tiled on all sides usually gets rid of them
<dominikh>
nice
cole-h has quit [Ping timeout: 260 seconds]
ur5us has quit [Quit: Leaving]
radgeRayden has quit [Ping timeout: 272 seconds]
radgeRayden has joined #zig
ur5us has joined #zig
kotrcka has joined #zig
a92 has quit [Quit: My presence will now cease]
hlolli has joined #zig
hlolli_ has quit [Ping timeout: 256 seconds]
hlolli_ has joined #zig
hlolli has quit [Ping timeout: 272 seconds]
earnestly has quit [Ping timeout: 265 seconds]
xackus_ has joined #zig
xackus has quit [Ping timeout: 240 seconds]
a_chou has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
kotrcka has quit [Quit: Konversation terminated!]
CodeSpelunker has quit [Quit: CodeSpelunker]
kristoff_it has quit [Ping timeout: 272 seconds]
frmdstryr has quit [Ping timeout: 256 seconds]
][_R_][ has joined #zig
[RMS] has quit [Ping timeout: 264 seconds]
a_chou has quit [Quit: a_chou]
a_chou has joined #zig
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
hlolli__ has joined #zig
hlolli_ has quit [Remote host closed the connection]
lucid_0x80 has joined #zig
halbeno has quit [Quit: Leaving.]
halbeno has joined #zig
jjsullivan1 has quit [Remote host closed the connection]
jjsullivan1 has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
xackus_ has quit [Ping timeout: 272 seconds]
a_chou has quit [Quit: a_chou]
jj__ has joined #zig
jjsullivan1 has quit [Read error: Connection reset by peer]
lucid_0x80 has quit [Quit: Leaving]
supercoven has joined #zig
aerona has quit [Quit: Leaving]
marnix has quit [Ping timeout: 240 seconds]
marnix has joined #zig
hlolli__ has quit [Ping timeout: 256 seconds]
hlolli__ has joined #zig
marnix has quit [Ping timeout: 260 seconds]
marnix has joined #zig
cole-h has joined #zig
sord937 has joined #zig
mokafolio has quit [Ping timeout: 264 seconds]
omglasers2 has joined #zig
Ashpool has quit [Remote host closed the connection]
mokafolio has joined #zig
sawzall has quit [Read error: Connection reset by peer]
marnix has quit [Ping timeout: 272 seconds]
marnix has joined #zig
jjido has joined #zig
hlolli__ has quit [Ping timeout: 272 seconds]
ur5us has joined #zig
st4ll1 has quit [Quit: WeeChat 2.9]
earnestly has joined #zig
hlolli__ has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #zig
mq32 has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
lltt has quit [Ping timeout: 240 seconds]
hlolli__ has quit [Ping timeout: 272 seconds]
kristoff_it has joined #zig
wilsonk_ has joined #zig
Guest9767 has quit [Ping timeout: 260 seconds]
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
waleee-cl has joined #zig
frmdstryr has joined #zig
cren has joined #zig
jjido has joined #zig
m4r35n357 has joined #zig
m4r35n357 has quit [Client Quit]
sawzall has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
supercoven has quit [Read error: Connection reset by peer]
m4r35n357 has joined #zig
<ifreund>
dominikh: finished my version of a type safe wl_list binding ttps://github.com/ifreund/zig-wayland/commit/ba49b2b6f984b788aea5e752bfeb64e3381472e7
<ifreund>
now I just need to update zig-wlroots to use it
donniewest has joined #zig
lucid_0x80 has joined #zig
<ifreund>
hrm, it doesn't play nice with lists of wl_client or wl_resource yet
<ifreund>
should be able to fix that though
Akuli has joined #zig
skuzzymiglet has joined #zig
<dominikh>
ifreund: I'm trying to grok the prepend and append functions and the use of fieldParentPtr there.
<ifreund>
yeah that's super ugly code, you'll be happy to know that I'm rewriting it currently and it's looking a lot cleaner
<dominikh>
well I still haven't figured out how it works :D
<ifreund>
what's happening is I'm using the fact that extern struct { foo: extern struct { ... } } has the same abi as the innner struct
<ifreund>
a pointer cast would work just as well there tbh
<ifreund>
I guess @fieldParentPtr() felt a little safer or something
<dominikh>
ah, so it's really just a @ptrCast
<ifreund>
in this case yes
<dominikh>
yeah I understand fieldParentPtr in the general case
<dominikh>
I was just perplexed by this instance
<ifreund>
probably I should have just used a pointer cast, in retrospect fieldParentPtr is pretty confusing there
<ifreund>
but neither should be needed in v2
tdeo has quit [Remote host closed the connection]
<dominikh>
well, looking forward to v2 then
<dominikh>
what was the issue with wl_client and wl_resource, anyway?
<ifreund>
well they are opaque types so you have to use wl_resource_get_link()/wl_resource_from_link() etc
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
<ifreund>
well, yeah legacy BS aside though it should be
<dominikh>
true. but it's legacy BS you can depend on
<ifreund>
regardless, what I've got is looking pretty clean
<ifreund>
just need to update the listener impl now and test
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<earnestly>
ifreund: Are you familiar with arcan and the work around it?
donniewest has quit [Read error: Connection reset by peer]
donniewest has joined #zig
<ifreund>
earnestly: I've certianly heard of it and have read some of the wiki pages, not terribly familiar though
<ifreund>
dominikh: just pushed v2, would appreciate your thoughts
layneson has joined #zig
m4r35n357 has quit [Quit: Ex-Chat]
skuzzymiglet has quit [Ping timeout: 240 seconds]
cren has quit [Quit: cren]
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
decentpenguin has quit [Ping timeout: 260 seconds]
<dominikh>
ifreund: I like it
<dominikh>
looks a lot cleaner than what I had
CodeSpelunker has joined #zig
jjido has joined #zig
<ifreund>
as you saw, it took me a fairly crappy iteration to get there :D
<ifreund>
thanks for the inspiration, without seeing yours I probably would have just settled for the non-type-safe version for a while longer
<dominikh>
:)
<dominikh>
you going to port zig-wlroots to the new list?
<g-w1>
do you use river as your daily driver?
<ifreund>
yep, porting zig-wlroots right now
<ifreund>
g-w1: been daily driving it for months at this point :)
<g-w1>
nice!
decentpenguin has joined #zig
lltt has joined #zig
<g-w1>
shouldn't the self-hosted compiler use the standard library in the zig repo instead of the system standard library? I had some issues with this
radgeRayden has quit [Ping timeout: 240 seconds]
<ifreund>
it'll use the standard library of whatever zig you use to compile it
<ifreund>
you probably want to use zig compiled from master of course
<g-w1>
I just use master, but if the repo also has the standard library, wouldn't it make more sense to compile the self hosted compiler using the repo? I had a more recent master stdlib than my working branch of the compiler, so I had to git pull, but if it used the repo's stdlib, it wouldn't happen
<g-w1>
or is it just good practice to git pull always?
<ifreund>
you want to use a compiler compiled from whatever git commit you are working off of
<g-w1>
ok
<ifreund>
and generally you should rebase onto master right before opening a PR to make sure everything still works
<g-w1>
ok
<dominikh>
also because linear history is love, though the Zig project doesn't seem to care about that :P
lucid_0x80 has quit [Quit: Leaving]
skuzzymiglet has joined #zig
<ifreund>
It doesn't not care either, it just isn't absolutely strict
<ifreund>
and merge commits do make sense sometimes when branches are long-lived
<dominikh>
sure, though I still prefer if the merge commit doesn't lead to tangled history. i.e., no merges in the merged branch, and the branch rebased on top of master. you can still force a merge commit, but the history is basically linear still
<ugla>
You can do `git config [--global] branch.autosetuprebase always` if you want new branches to rebase by default
<dominikh>
ooh I had no idea git pull behavior could be configured in the first place. I always git fetched and git rebased by hand…
<ifreund>
i have mine set to ff-only for pull
<dominikh>
I have a git puff aliased to that
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
marnix has quit [Ping timeout: 260 seconds]
<ifreund>
dominikh: zig-wlroots updated for the new wl_list bindings, now back to rewriting river for me :)
<dominikh>
ifreund: great. I'll port my code and see what blows up
<ifreund>
I'll be curious to hear how it goes
<dominikh>
can't go too poorly, it's not much more complex than tinywl at this stage
marnix has joined #zig
<ifreund>
well tinywl.zig has been working for a while so you probably won't have major issues
<ifreund>
there are of course some parts of wlroots that I haven't bound yet, but everything river currently uses is done
<dominikh>
it's fine, I'll send patches if anything is missing
<ifreund>
cool
marnix has quit [Ping timeout: 260 seconds]
skuzzymiglet has quit [Quit: WeeChat 3.0]
marnix has joined #zig
hlolli__ has joined #zig
ur5us has joined #zig
<dominikh>
ifreund: wrt zig-wlroots, would you agree to change some functions that return optionals to return errors instead? stuff like *_create
<ifreund>
dominikh: sure if the errors are unambigous
<ifreund>
I think most of the _create functions should just return error.OutOfMemory
<dominikh>
not sure it's always that unambiguous, but IMO a generic error.Failure (or whatever) is better than using optionals for operations that can fail? especially because user code would just end up with a lot of orelse return...
<dominikh>
stuff like wlr_backend_autocreate. it can probably fail for reasons other than a failed allocation, but it's still very much an error if it returns null
<ifreund>
yeah errors certianly make more sense semantically for these and it would be nice to be able to use try
<dominikh>
I can send a patch for the ones I run into? or would you prefer doing it all in one big swoop?
<ifreund>
feel free to send a patch for as much or as little as you like. I think we do want to make all of them errors eventually though
<dominikh>
well, someone has to look at all of the API. some optional pointers are correct the way they are
<ifreund>
yeah, e.g. the surfaceAt() functions should definitely stay optional
<ifreund>
I think those are the minority though
<dominikh>
sure. still takes a human to figure out the exceptions
<ifreund>
yup
<dominikh>
what I'm trying to say is that it's probably easier to turn things into errors bit by bit, than it is to do a simple search and replace :P
<ifreund>
I see your point
<ifreund>
might start with tinywl and move on to whatever you need
<dominikh>
yeah. expect a PR soonish
<ifreund>
and I think many can be a simple error.OutOfMemory, e.g. wlr_layer_shell_create() can only fail due to allocation or wl_global_create failing
<dominikh>
aye
<ifreund>
and the later only happens due to allocation failure or invalid parameters, but wlroots passses vaild params
<dominikh>
go figure, zig-wlroots will be a lot more type-safe than wlroots
<ifreund>
oh yeah
<dominikh>
I wish wlroots was more const correct in its arguments, though.
<ifreund>
that's the whole point of it really ;D
<ifreund>
I'm sure emersion would be happy to merge patches constifying things
<ifreund>
that's probably the most minor issue I've had though, null pointers and type safety of listeners have been the most annoying
<dominikh>
yeah, but not much they can do about that
<dominikh>
well, aside from the lack of documentation. I had to look at the implementation a lot to figure out the arguments to events
<ifreund>
I should really send a patch addding docs for all the wl_signal arguments I've looked up and encoded in the type system of zig-wlroots
<ifreund>
but ya know, the TODO list never gets any shorter
<dominikh>
yeah…
<dominikh>
heck, I still need to send a patch to the wayland docs, has some mistake in it
<ifreund>
hrm, I could really use a better name for the namespace of scanned wlr protocol functions. Already using wlr for wlroots so wlr_proto is the best I've come up with but it's kinda long
<ifreund>
wlrp is short but unclear
<ifreund>
hardest problem in computer science
<dominikh>
what kind of functions are those?
<ifreund>
all the functions generated from scanning the xml of the wlr protocols
<ifreund>
though they should eventually all get moved to proper namespaces in wayland-protocols
<ifreund>
(ext, wp, xdg, etc.)
<dominikh>
ah. this mostly affects clients, not servers, right? since on the server side, users will interact with the wlroots bindings instead
<ifreund>
yeah but you still need to use e.g. the Layer enum for layer shell code which is scanned from the xml
<dominikh>
oh, I see.
<dominikh>
sorry, I don't have a good name then
skuzzymiglet has joined #zig
<ifreund>
I guess I'll just deal with typing out wlr_proto until we get the relevant protocols upstreamed :D
Akuli has quit [Quit: Leaving]
<dominikh>
also… have we hijacked the channel with off-topic, or is this common?
<ifreund>
I guess it might be a little excessive at this point, feel free to join me in #river
skuzzymiglet has quit [Read error: Connection reset by peer]
skuzzymiglet has joined #zig
sord937 has quit [Quit: sord937]
marnix has quit [Ping timeout: 256 seconds]
ur5us has quit [Remote host closed the connection]
ur5us has joined #zig
msingle has joined #zig
marnix has joined #zig
marnix has quit [Ping timeout: 256 seconds]
riba has joined #zig
xentec_ is now known as xentec
skuzzymiglet has quit [Read error: Connection reset by peer]
skuzzymiglet has joined #zig
jjido has joined #zig
skuzzymiglet has quit [Ping timeout: 240 seconds]
_whitelogger has joined #zig
skuzzymiglet has joined #zig
donniewest has quit [Quit: WeeChat 3.0]
skuzzymiglet has quit [Ping timeout: 256 seconds]
Wallbraker281 has quit [Quit: Ping timeout (120 seconds)]
jaredmm has quit [Quit: Bouncin']
jaredmm_ has joined #zig
Wallbraker281 has joined #zig
idxu has quit [Ping timeout: 240 seconds]
idxu_ has joined #zig
idxu_ is now known as idxu
tane has quit [Quit: Leaving]
riba has quit [Ping timeout: 260 seconds]
<g-w1>
i just had to invalidate the cache, and then it worked. probably a bug in the caching system.