<hlolli>
probably a general question on strings, when creating a stream+reader combo for the following "💯hello" string, I notice that I can't represent that 100 in u8 range, but if I call readInt, I get astronomical values for all the characters. How would I go about reading these values individually as integer?
<hlolli>
correction, I get the high numbers if I call it like this reader.readInt(u32, std.builtin.endian), for u8 I get correct values but not on the first char.
st4ll1 has quit [Ping timeout: 265 seconds]
<companion_cube>
💯 is multiple bytes in utf8
<companion_cube>
you can't look at individual bytes and expect to get a meaningful result
<fengb>
Are you trying to extract numbers from a string? That’d be std.fmt.parseInt
ur5us_ has joined #zig
<fengb>
Oh wait, I thought that emoji was for funsies
<hlolli>
I'm trying to create a simple parser by scanning trough strings, I'm looking for something that would work like java's java.io.StringReader.
<fengb>
You’ll need to do proper UTF8 parsing if you’re working with Unicode
<companion_cube>
you need to iterate at least on codepoints, if not better
<hlolli>
hmm ok ahh nice
squeek502_ has joined #zig
squeek502 has quit [Ping timeout: 240 seconds]
<companion_cube>
not sure what java would do there, it's utf16 iirc and emojis might be outside the scope of single char utf16?
<hlolli>
thanks that probably saved me bunch of time. companion_cube: maybe, coming from js/pyhon/java, strings are something that I've never spilled a gray hair over thus far :P (except wasm->js bindings, still easy)
<companion_cube>
you never had a decoding error in python? lucky you 🙃
<hlolli>
I had that in nginx recently, python was involved indirectly. But I'm more refering to aliging string bytes to array/memory, I know it's doing all that under the hood.
<companion_cube>
python3 makes a difference between string and bytes
<companion_cube>
zig doesn't
<companion_cube>
(but provides some basic functions to manipulate utf16/utf8-encoded strings from the underlying []u8)
<hlolli>
so it's like c, which what I expected of zig, the joke here is on me for not learning low level languages properly after so many years of software development.
omglasers2 has quit [Read error: Connection reset by peer]
<daurnimator>
hlolli: generally you don't need to care about codepoints
st4ll1 has joined #zig
<ugla>
it's not easy to make a simple API for unicode. even python3 can be surprising, depending on what you actually want. the len() of a single emoji can be, say, 6.
<daurnimator>
or even 22
<ugla>
swift does a nice job, and just gives you different views of the data, but then you have to know what all those options are and which one you want
<hlolli>
>>> len('💯')
<hlolli>
1 # got 1 here
<ugla>
I don't think there's an easier way out
<ugla>
hlolli: try 🧛🏼♀️️ or something (if that survives this matrix to irc bridge)
<daurnimator>
likewise you can't just trim unicode codepoints off; take them out of context; or elipsize them without using the correct non-trivial algorithm
<hlolli>
ugla: icelandic?
<hlolli>
>>> len('🧛')
<hlolli>
1
<daurnimator>
hlolli: that's a different emoji
<hlolli>
true, wtf
<daurnimator>
hlolli: likewise, ﷽
<daurnimator>
that's a single character that's 22 codepoints wide IIRC
<hlolli>
python says it's 1 :P but yeh, I've read about these wide strings recently in the book "C in nutshell", I guess all the possible chars aren't still occupied, but I know very little about the millions of symbols:)
<daurnimator>
hlolli: your general philosophy should be; don't care. handle strings opaquely
<hlolli>
ugla: I wish I could screen shot what I see in my terminal, I get the sign for women, the black dracula and a box. And indeed, it's 6.
<daurnimator>
hlolli: that'll probably be due to your font
<hlolli>
Very off topic, still interesting. I guess I'll not be the last one to fall into this pitfall. Keeping the Utf8View function in close proximity in beginner tutorials would make sense.
<ugla>
hlolli: yeah, that's how emoji are composed. the box is a "zero width joined" probably. vampire + zwj + female symbol turns into a vampire woman. then you can add skin tone modifiers too, further increasing the len
<ugla>
s/joined/joiner/
<daurnimator>
hlolli: why do you want/need Utf8View?
<hlolli>
also "very off topic" not percise choise of words. I never got deep into irc culture, I see many of my colleagues itching for "threads PLZ" on slack in such a topic :)
<hlolli>
I want to iterate over string character by character. Rewriting some esoteric parsers to learn the language.
<hlolli>
Zig there's to say
<daurnimator>
hlolli: why do you want to iterate over it character by character?
<daurnimator>
(for a parser you likely want to do it char by char)
<hlolli>
the original parser which I'm copying after is doing it that way
<daurnimator>
as in, iterate over it in u8
<hlolli>
that could be but as long as I'm able to create switch statements with signle quote string literals '💯', I'd be good, I don't think I need such atomic view of the bytes. It looks like the iterator built into the utf8 view will cover all characters.
<justin_smith>
hlolli: if you want to operate on unicode, there are unicode libraries (eg. libunistring), I can't tell you which is best though
<daurnimator>
libunistring is good; its where I'd go if I ever need to e.g. line-wrap a unicode string
<hlolli>
not sure that's something I need to achieve, if I can type icelandic characters like ÆÖÐÚÁ and german äë, I'd be happy enough
<hlolli>
maybe dressing dracula in green jacket as female, I'll have a look around :D
<pfg_>
std.mem.startsWith(u8, the_text, "💯") will work too with just a byte iterator, but switch is much easier to use
hlolli has quit [Ping timeout: 272 seconds]
a92 has joined #zig
squeek502_ has quit [Remote host closed the connection]
pfg__ has joined #zig
Jeanne-Kamikaze has joined #zig
pfg_ has quit [Ping timeout: 240 seconds]
CodeSpelunker has quit [Read error: Connection reset by peer]
<yZ5vlALg86lP>
i'm running into this line in my code: https://github.com/ziglang/zig/blob/master/lib/std/net.zig#L1701 - accept() getting a WouldBlock error, since i did not set std.io.is_async, but what i did was to do a setsockopt for SO_(SND|RCV)TIMEO which sets a timeout on the socket...
<yZ5vlALg86lP>
i don't really want to set the socket to nonblocking. i just want to regularly return if there is no incoming connection, but i'm ok to have a few seconds timeouts on that...
<yZ5vlALg86lP>
i think of lifting that code and modifying it to my needs. but i suspect others might also run into this, shall i open an issue for this?
ur5us has joined #zig
ur5us_ has quit [Ping timeout: 264 seconds]
a92 has quit [Quit: My presence will now cease]
ur5us_ has joined #zig
ur5us has quit [Ping timeout: 272 seconds]
lucid_0x80 has joined #zig
a_chou has joined #zig
earnestly has quit [Ping timeout: 246 seconds]
a_chou has quit [Quit: a_chou]
gonz_ has quit [Ping timeout: 272 seconds]
gonz_ has joined #zig
<andrewrk>
yZ5vlALg86lP, yes please do
<daurnimator>
yZ5vlALg86lP: SO_*TIMEO aren't generally very useful: they don't work well with any polling schemes
<andrewrk>
daurnimator, re: #7136 you're not wrong, but like, man, I would rather work on other stuff
<andrewrk>
you mind if I close the issue but PRs welcome to add to the list?
<daurnimator>
andrewrk: `find . -name .zig`. just put them all in there.
<andrewrk>
that's fine by me
<daurnimator>
false positives are fine; you just don't want false negatives.
<andrewrk>
fair enough
ur5us_ has quit [Ping timeout: 260 seconds]
<daurnimator>
alternatively, maybe zig could gain a `-MD`-like flag that emits a list of files touched during a build?
waleee-cl has quit [Ping timeout: 272 seconds]
waleee-cl has joined #zig
kristoff_it has quit [Ping timeout: 256 seconds]
jzelinskie has quit [Ping timeout: 272 seconds]
marnix has joined #zig
jzelinskie has joined #zig
jzelinskie has quit [Ping timeout: 272 seconds]
jzelinskie has joined #zig
ur5us has joined #zig
factormystic has quit [Ping timeout: 240 seconds]
Jeanne-Kamikaze has quit [Ping timeout: 256 seconds]
supercoven has joined #zig
supercoven has quit [Max SendQ exceeded]
supercoven has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
xackus has joined #zig
xackus has quit [Client Quit]
<andrewrk>
that wouldn't solve the conditional compilation issue that you just brought up
lucid_0x80 has quit [Ping timeout: 240 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
lltt has quit [Ping timeout: 256 seconds]
<pixelherodev>
daurnimator: `find . -name .zig` returns empty list for me - `s/\.zig/\*&/`
<pixelherodev>
:P
lucid_0x80 has joined #zig
decentpenguin has quit [Quit: ZNC crashed or something]
decentpenguin has joined #zig
dongcarl has quit [Quit: Ping timeout (120 seconds)]
dongcarl has joined #zig
sord937 has joined #zig
utzig has quit [Ping timeout: 272 seconds]
utzig has joined #zig
ur5us has joined #zig
omglasers2 has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
ur5us has quit [Ping timeout: 265 seconds]
lucid_0x80 has quit [Ping timeout: 256 seconds]
cole-h has quit [Ping timeout: 264 seconds]
shachaf has quit [Remote host closed the connection]
shachaf has joined #zig
halbeno has quit [Remote host closed the connection]
halbeno has joined #zig
jjido has joined #zig
sord937 has quit [Remote host closed the connection]
sord937 has joined #zig
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
hlolli has joined #zig
riba has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
riba has quit [Ping timeout: 246 seconds]
neceve has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lltt has joined #zig
earnestly has joined #zig
ky0ko has quit [Remote host closed the connection]
bens has quit [Ping timeout: 256 seconds]
bens has joined #zig
ky0ko has joined #zig
<ask6155>
Does zig differenciate between system(kernel) dependant and independant libraries?
<ikskuh>
can you elaborate?
<ikskuh>
i've heard those terms first time today
<ask6155>
I mean If use the standard library, is there differenciation between functions which make syscalls and ones which don't? Or do all functions make syscalls? Can I use the standard library on bare metal?
<ikskuh>
you can use most of the non-i/o stuff of std on bare metal
<ikskuh>
not working is stuff like timers, fs, network
<ask6155>
Yeah but how do I which of the functions can be used? There should be some kind of 'tag' saying this function requires a system in order to function
<ask6155>
*How do i know
<ikskuh>
just use them
<ikskuh>
and if it won't compile, it won't work :D
<ikskuh>
it's a mix of experience and knowledge
<ask6155>
Isn't it better to keep them seperate?
<ikskuh>
if you know that stuff does I/O
<ikskuh>
you can' use it on freestanding
<ikskuh>
but pure algorithms and data structures don't require I/O
<ask6155>
Hmm
<ask6155>
If I make a zig library, how should I distribute it? Just like a c library?
<ifreund>
if you're exporting a C ABI then sure, otherwise just distribute the source
<ask6155>
Yeah but I make a library, put it on github, someone makes a zig program with it by using my source, what if I update my lib? Doesn't he have to download my source again, link to it and check if his program still works?
<ikskuh>
exactly
<ask6155>
Is that... Good?
<ask6155>
I mean... i have to do it for every library I use.
<ask6155>
Also every program that uses the lib has a copy of it in it.
<ikskuh>
yeah, for zig, you reference libs by source
<ikskuh>
no as a binary
<ikskuh>
the same goes for any other system as well ;)
<ifreund>
the best option currently is git submodules imo
<dutchie>
yeah i was about to say most people seem to use submodules atm
<novaskell>
yes since the user may tweak it to their use case, compile with different flags, etc etc. With a binary you can only really link against it and only for what you compiled it for
<dutchie>
i believe the plan is for there to be a better package management story once the self-hosted compiler is done?
<ifreund>
eventually we will need an official manifest format for packages so that the zig build system/package manager can handle versioning
<ifreund>
dutchie: indeed, self hosted is the main blocker for an official package manager
<ask6155>
What about distros? Will there be no dependencies anymore?
<ifreund>
andrew wants the compiler to be fast before people start compiling massive dependency trees
<ifreund>
ask6155: imo zig should make it easy for distros to put zig libs in e.g. /usr/include/zig/
<ifreund>
these would be compile time only dependencies though of course
<ask6155>
I meant if say ubuntu wants to add a zig program to their repo. A binary package.
<ask6155>
They have to get the program's source, source of every dependency, and compile all of it. So basically static linking. They would have to do it for every program. Even if they have the same dependencies, right?
<ikskuh>
ask6155: yes, correctly
<ikskuh>
and it's good this way
<ask6155>
Remind me why people hate static linking?
<ikskuh>
dunno
<ikskuh>
i love it
<ikskuh>
makes stuff painless
<dutchie>
updates are harder, bigger binary size i think are the main complaints
<dutchie>
i didn't say i agreed with the complaints, only that those are what people normally complain about ;)
<ikskuh>
zig is not *able* to do binary libraries anyways :D
<ifreund>
sure it can, but C ABI only
<ikskuh>
:D
<ikskuh>
well, i consider those C libraries :D
<ikskuh>
the most complaints about "building from source" i hear is that it sucks
<ikskuh>
in general
<ikskuh>
as it's hard, diverse, underdocumented
<ifreund>
the main issues are caused by tooling and crappy build systems
<ikskuh>
yep
<ikskuh>
zig can change that :)
<ask6155>
No the people who use the software don't have to 'build from source' the people who manage the packages have to
<ikskuh>
also people who want to develop stuff
<ikskuh>
joining a zig project is awesome
<ikskuh>
you need zig
<ikskuh>
and usually that's it
<ask6155>
I heard stuff about Go too. How archlinux guys hate it. Is zig similar to that in that sense?
<ikskuh>
dunno
<ikskuh>
and i really don't care
<ikskuh>
i am in favour of including all deps as source
<ikskuh>
as it allows me independency
<ikskuh>
it also allows building stuff everywhere
<ikskuh>
if you depend on system libs, you depend on that system
<ikskuh>
and you might even require it
<ask6155>
What about including c libraries as source too?
<ikskuh>
ye.s
<ikskuh>
*yes.
<ask6155>
The main arguement I hear is that if you link something like openssl and they find a bug in it then they can't just fix it. They have to wait for everyone to fix it.
<ask6155>
*everyone to update their software
<ikskuh>
yes
<ikskuh>
that's true
<ikskuh>
but if you have the openssl source in your source tree
<ikskuh>
you can build that software in 20 years
<ikskuh>
again
<ikskuh>
and fix bugs
<ikskuh>
which might not be true anymore if you depend on externs
<ask6155>
Hmm maybe I should do this
<ikskuh>
it's a problem ignored by a lot of people
<ikskuh>
create *maintainable* software means that you need to be able to build it even in case of an apocalypse without internet
<ikskuh>
only your last USB drive with your stuff on it
<daurnimator>
good luck trying to build an old openssl; it relies on the specific glibc details of those times
<ask6155>
Maybe the static linking problem stems from C and the unlinkable glibc
<daurnimator>
glibc developers encourage dynamic linking so that you can use old applications on new systems
<ikskuh>
daurnimator: i would just not use openssl for several reasons :D
<karchnu>
I still don't quite understand why static linking isn't mainstream nowadays.
<ask6155>
daurnimator: how does that work?
<daurnimator>
static linking tends to be preffered by application developers; dynamic linking by library and system developers
<daurnimator>
karchnu: because then you can't fix a bug in e.g. libc without recompiling programs
<karchnu>
Recompiling a program should not be a problem.
<daurnimator>
open source isn't a given: a huge proportion of software is closed source
<daurnimator>
libc needs a fix? better hope the application developer is willing to pull in the update and rebuild for you.... hopefully they still are in business; if you're lucky they might only charge you a small fee for it...
<karchnu>
daurnimator: sure, but still. You don't find a fully statically compiled OS very often.
<karchnu>
Even in OSS.
<daurnimator>
karchnu: freertos is all statically compiled IIRC
<ifreund>
there's oasis too
<karchnu>
Yep, there are some, but it is really, REALLY underground.
<daurnimator>
karchnu: but note that most OSes don't have a stable ABI apart from dynamically linking libc. linux is the exceptional one for having stable syscalls
<ifreund>
I think the best o both worlds would be statically linking most things and only dynamically linking things like libc and mesa
<daurnimator>
why not e.g. your ssl library?
<ifreund>
yeah that too of course
<daurnimator>
why not your unicode tables?
<ifreund>
I guess your point is that it's hard to draw the line?
<daurnimator>
I think everything with a different lifecycle should be a point of dynamic linking
<karchnu>
daurnimator: having a stable ABI is great for static linking. OS with other kernels should recompile their applications once per release, not a big deal. They already do it.
<karchnu>
And I prefer a program with a behavior that won't change because of a library update.
<daurnimator>
karchnu: so, freebsd has a new release..... users have to wait for e.g. spotify corporation to recompile before they upgrade?
<karchnu>
I think that we are used to dynamic linking to the point that most people would find it heresy not to do so.
<karchnu>
daurnimator: I don't see the connection.
<daurnimator>
karchnu: without dynamic linking or a stable syscall ABI how would closed source applications work with new OS releases?
<ask6155>
I'm still confused... How to manage libraries? Wait for the package manager? Will there be an abi?
<daurnimator>
For now you need to manage libraries manually. within the next year we should have a package manager
<daurnimator>
There may not be an ABI for zig types for a long time; so you'll need to use the C ABI in the mean-time
<karchnu>
daurnimator: you don't have to forbid dynamically compiled libraries to offer statically compiled applications.
<ikskuh>
daurnimator: i don't see an option for zig types to have an ABI in the first place
<ask6155>
Should I then ship my libraries as an .so?
<ikskuh>
if you create C libraries: yes
<ikskuh>
if you create zig libraries: no
<ikskuh>
also: always ship the source
<daurnimator>
if you create zig libraries: you can; but for open source work the convention is to just ship source.
<daurnimator>
we don't yet have a good pattern for zig "headers"
<daurnimator>
ask6155: please don't needlessly take discussions to PM
<ask6155>
Well I didnt know if it would work since I use a transport :D
<ask6155>
Sorry
<ask6155>
You're saying to ship the source. But any program which uses it will have to keep it up to date. But the guys to archlinux said they will never take a program like that... Or something
<daurnimator>
ask6155: you ship your application/library source; and mention your dependencies in the README (as well as potentially using git submodules; and in future whatever package management zig settles on)
<ifreund>
well, they already do for rust programs at least :P
<ifreund>
I think zig can do better than rust/go here though
<daurnimator>
ask6155: packaging for archlinux; they would not use e.g. your vendored dependencies. They will package your dependencies as their own packages.
<ask6155>
Yeah but how would that work?
<daurnimator>
what do you mean
<ask6155>
When I get a library dependency on archlinux, it is actually just a dynamic library
<daurnimator>
ask6155: usually yes; but header-only libraries exist
<daurnimator>
for now (without a stable ABI); zig dependencies would be treated like header-only libraries
<ask6155>
What is a header-only library?
<ifreund>
a library where the full source is in the header
<daurnimator>
surprisingly there is a wikipedia article for it
<ifreund>
heh
<ask6155>
Yeah but wha.... i'm confused
<ask6155>
I used to think in context of C/C++ there is a program and a library, package maintainers compile the program and link to a dynlib. They ship this program as a package. Then the compile a dynlib and ship it as a package. On the user side he installs 2 packages and the programs does dlopen() and bada bing bada boom, everything works!
<dominikh>
"and [...] everything works!", that is adorable :P
<ask6155>
Well that's the theory
<ask6155>
How would this happen in the context of Zig?
<ask6155>
Assuming both the program and library are written in Zig?
<dominikh>
everything gets thrown into a single compilation unit, and in the ideal case gets compiled into a static binary
<ask6155>
I hope that is how things go.
<ask6155>
Now I have to go otherwise the phone will die. Bye! o/
<g-w1>
thanks, do you happen to know the zir instruction that does this?
<g-w1>
interesting, it seems like ir.cpp:12048 just manually expands the error set
hnOsmium0001 has joined #zig
tane has joined #zig
sawzall has quit [Read error: Connection reset by peer]
sawzall has joined #zig
TheLemonMan has joined #zig
nvmd has joined #zig
gscacco has quit [Ping timeout: 246 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lltt has joined #zig
marnix has quit [Ping timeout: 240 seconds]
jjido has joined #zig
marnix has joined #zig
aerona has joined #zig
hlolli_ has joined #zig
hlolli has quit [Remote host closed the connection]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Ashpool has joined #zig
jjido has joined #zig
lucid_0x80 has quit [Ping timeout: 240 seconds]
<andrewrk>
daurnimator, I'm happy we got the cmake issue sorted out thanks to johnLate
<TheLemonMan>
isn't cmake itself the real problem?
<andrewrk>
yes, I see cmake as a sub-par solution to the problem of having a cross-platform build script
ur5us has joined #zig
<andrewrk>
maybe we could make an argument for bootstrapping the compiler only being supported on unixy systems and then we could ditch cmake, and to build zig on windows you would have to download a previous zig binary
skuzzymiglet has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<g-w1>
if the first check in an and fails, will the second be evaluated? if (x and b.y(z)) // will b.y be evaluated?
<earnestly>
iow, is and short-circuiting
<andrewrk>
g-w1, no. `and` and `or` are control flow
<g-w1>
thanks
sord937 has quit [Ping timeout: 240 seconds]
ur5us has quit [Ping timeout: 264 seconds]
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
sord937 has joined #zig
jjido has joined #zig
sord937 has quit [Remote host closed the connection]
sord937 has joined #zig
solaire has joined #zig
solaire has quit [Client Quit]
sawzall has quit [Read error: Connection reset by peer]
sawzall has joined #zig
<dominikh>
http://sprunge.us/219y4z I find it interesting that the first form allows the shadowing while the latter doesn't. primarily I'm wondering what makes the first form work.
<dutchie>
is there a way to do @intToEnum without the risk of UB if the int isn't a valid enum value?
<ifreund>
dominikh: probably a bug in stage 1 :/
<ifreund>
dutchie: use a non-exhaustive enum
<dutchie>
it's an enum from a C header
<dominikh>
ifreund: so it shouldn't work?
<ifreund>
dutchie: there's probably an std.meta functions that lets you do the cast while handling failure
<ifreund>
dominikh: afaik no, but we don't have a spec yet so I'm not 100%
<dominikh>
assuming it shouldn't work, I have a follow-up question on namespacing and style. I obviously ran into this because I _wanted_ to name those functions the same thing. am I over-using namespaces? should I just go for Tablet and TabletPad instead of Tablet.Pad?
<dominikh>
interesting, thanks
<ifreund>
that'd be what I'd do here
<ifreund>
I usually only nest struct decls like that when the nested struct is used as one of the fields of the parent and nowhere else
skuzzymiglet has quit [Ping timeout: 246 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<dominikh>
hm yeah, that might make more sense than what I've been doing. this is me trying to map wlroots APIs to zig
<dominikh>
(and yeah, I'm aware of your efforts on the same)
<ifreund>
you've seen zig-wlroots?
<ifreund>
why do the same work in parallel if I may ask?
<dominikh>
Aye. but I wanted to experiment with this myself, see if I came up with something different. also in part because my own wayland bindings are ever so slightly different
<ifreund>
wasn't aware of your wayland bindings, you have your own scanner impl and everything?
<dominikh>
it's mostly a learning experience and experimentation
<ifreund>
cool
<ifreund>
I'm doing this solely because I want to use the bindings in river
<dominikh>
nah, no scanner etc yet. your work is more ahead in that regard. but I have a type-safe wl_list ;)
<ifreund>
oh? with ABI compatability?
<dominikh>
if I didn't mess up, yeah
<dutchie>
ifreund: ah i'll have a look, thanks
<dominikh>
hold on
<ifreund>
I didn't see a clear way to do that but I have type safe wl_signal and listener at least
<dutchie>
aha yeah, std.meta.intToEnum is exactly what i want
<ifreund>
dominikh: that looks reasonable, but don't forget that wlroots may set prev/next to NULL
<ifreund>
which would be UB with that impl
<dominikh>
ifreund: that's fair, but arguably it's as UB as accessing the undefined value. you shouldn't be doing anything that reads those fields if wlroots had reason to null them out
<dominikh>
it's not a case of "these might be NULL and I should be handling that" if I am not mistaken
<ifreund>
setting them to null is also useful in some cases
<dominikh>
can you provide an example?
<ifreund>
say you want to check if an element is part of a list or not
<ifreund>
the case where prev == next == self is ambigious, is it a list with one element or a floating element
<dominikh>
it's an empty list, actually
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
<ifreund>
yeah, though that doesn't really make sense when done to a member of the list not the head
<dominikh>
the way that wl_list is used, anyway. since the list itself is defined by the list head, a sentinel value, and you can't really cut lists in half
<dominikh>
(which is why I have the ListElement alias, to make it clear which fields are lists vs links)
<ifreund>
memberes are set to null/null on removal by libwayland
<dominikh>
that is true
<dominikh>
but since you don't treat members as lists, you don't read those fields when they're null
<ifreund>
I might go as far as to remove iteration/init from ListElement
<dominikh>
i.e. you start traversal from the head sentinel, not from a member
<dominikh>
yeah, that would be more correct
<dominikh>
you'll also notice that my remove function sets next and prev to self. which is… eh. a good workaround for not having null
<ifreund>
I'd be more inclined to use undefined there
dimenus has joined #zig
<ifreund>
really though these are bindings to a C API and I think it's important to maintain the same semantics when possible, I wonder if wlroots checks for prev/next == NULL anywhere
<dominikh>
hm. with the way it is now, calling remove more than once on an element is defined and works
<ifreund>
but enough on that, what's cool about your compositor?
<dominikh>
so far nothing, as it's not usable yet :) the first version will be a simple port of my clone of cwm, but after that it'll act as a playground for UI experiments. I'm overall unhappy with modern GUIs and window management and want to build something smarter… also it's a floating WM, which apparently is a novelty among wayland compositors :P
<ifreund>
heh, hikari and wayfire are both floating-first
<ifreund>
I think there's a fairly far along openbox clone as well
<ifreund>
you might like hikari, it also started off as a cwm clone iirc
CodeSpelunker has joined #zig
<dominikh>
yeah, it's on my list of projects to "take inspiration" from. at the end of the day, I'm mostly writing it for myself, so it'll probably end up as an amalgamation of features.
<ifreund>
nice, I'll be interested to see where you end up in terms of features
<ifreund>
and if you ever feel like using my wayland/wlroots/xkbcommon/pixman bindings let me know if you run into any shortcomings or issues :D
<dominikh>
btw, what's your approach to writing the wlroots bindings? mine's translate-c + a whole ton of manual cleanup
<ifreund>
I mostly just ran translate c on a file then copy and pasted some parts of the output + kakoune magic
<ifreund>
it was a lot more monotonous to write than zig-wayland was
<dominikh>
oh yeah, zig-wayland does still use libwayland, right? you're just replacing the scanner?
<ifreund>
zig-wlroots should have everything I need to port river now though, I'm on to slowly rewriting all of river's code to use it and fixing minor error I find in the bindings along the way
<ifreund>
yeah it's just a scanner + bindings for libwayland
<dominikh>
tbf, the main reason I have my own wlroots bindings is because it's a lot faster to work on those than it is to send patches
<ifreund>
I'm pretty fast at merging trivial stuff usually
<ifreund>
and bindings stuff is generally trivial
<dominikh>
circling back to wl_list, optional pointers do work with the C ABI, so it should be fairly easy to change the wrapper to support NULLs
<ifreund>
yeah, I want to make the one I have in zig-wayland typesafe now having seen yours and split the Head/Element implementations
<dominikh>
at that point I can probably switch to zig-wayland; I haven't done anything else with my bindings yet, other than wl_list and stealing your type-safe signal and listener
<dominikh>
I've been pondering type-safe resource, but that's not really as important, seeing how we use wlroots for most things
<ifreund>
I used opaque pointers for the server side as well as the client side
<ifreund>
I don't have the proper ones everywhere in my wlroots bindings yet though, there's still a lot of wl.Resource where it should be wl.Seat or whatever
<dominikh>
ah
<ifreund>
idk why libwayland didn't do this, it's much easier to keep track of what is what
<dominikh>
fun fact: I made the mistake of writing a pure Go implementation of a wayland client and server, before realizing that wl_drm pretty much forces one to use libwayland (for now, anyway) and that wlroots is quite handy… so I started learning Zig…
<ifreund>
yeah, zig is pretty much the best option for wayland if you don't want to do C IMO :)
<dominikh>
it looks that way, yeah
<ifreund>
writing a wayland implementation from scratch sounds kinda fun though, but I've been too busy working on river for that
<dominikh>
the protocol isn't all that complex tbh
<earnestly>
(Ada is nice here, case doesn't matter, lol)
ikskuh has quit [Quit: Winke winke!]
LanceThePants has joined #zig
sawzall has quit [Ping timeout: 272 seconds]
marnix has quit [Ping timeout: 246 seconds]
donniewest has quit [Quit: WeeChat 3.0]
sawzall has joined #zig
LanceThePants has quit [Ping timeout: 256 seconds]
CodeSpelunker has quit [Quit: CodeSpelunker]
CodeSpelunker has joined #zig
marnix has joined #zig
<ifreund>
dominikh: yeah, that's a namespace
<ifreund>
(structs without fields are namespaces)
<dominikh>
yeah, I wasn't aware namespaces are lowercase
marnix has quit [Ping timeout: 260 seconds]
<ifreund_>
snake_case to be specific, see e.g. std.fs or std.meta or std.os
<ifreund_>
earnestly: case doesn’t matter in zig either, it’s just a coding style thing
<g-w1>
rust gives a compiler warning, is this planned for zig too?
<ifreund_>
rust really does that? I hope zig never does
<ifreund_>
zig doesn’t have warnings only errors so far and I believe the plan is to keep it that way
<g-w1>
so no unused variable warnings, or an error for that instead?
<ifreund_>
I believe an error for that is the plan, but it’s tricky
<dominikh>
the plan is to make it an error. of course complicated by lazy evaluation right now
<dominikh>
c.f. the multibuild proposal to fix _that_
<dominikh>
what I find unfortunate is that these errors make it harder to work on code and test it as it is being written. for example, you can't just "comment out" code by using an unconditional early return, because then zig complains about unreachable code… which is great for finished code, not so great during debugging
<earnestly>
ifreund_: No, case doesn't matter. You can type your code in all caps if you wanted
marnix has joined #zig
<earnestly>
Iow, it's case insensitive
<dominikh>
so a variable named foo can be addressed as FOO?
<earnestly>
Yes
<ifreund_>
ew?
<earnestly>
And not only that, but Δ can be written as δ
<earnestly>
ifreund_: It has to work on systems which had no lowercase
<dominikh>
oh right, Ada. for some reason I was thinking of Rust
<dominikh>
would've been shocked if a modern language was case insensitive
<earnestly>
It works beautifully, but you can't use case to signify meaning like Go/plan9 C does with types being capitalised
<earnestly>
It's a shame more aren't insensitive, I think SQL is like that still. Oh well
<earnestly>
You never end up with nasty things like FooHttpTcp or FooHTTPTCP
<earnestly>
(But you can pick whichever poison you want)
marnix has quit [Ping timeout: 240 seconds]
<ifreund_>
well you can’t throw snake_case into the mix unless it ignores underscores as well (does it?)
<justin_smith>
in clojure there's a "camel-snake-kebab" library to translate cases of identifiers at runtime
dimenus has quit [Ping timeout: 264 seconds]
<justin_smith>
so your env can have SHOUTING_SNAKE_CASE, normal vars kebab-case, db snake_case, etc. and you can translate between them
<justin_smith>
this comes up because it's common to use hash-maps for everything
tane has quit [Quit: Leaving]
<daurnimator>
kebab-case is weird
<justin_smith>
it's normal in lisp, where there's no infix -
<daurnimator>
it's normal in HCL (hashicorp config language) where there *is* infix -
<andrewrk>
dominikh, ifreund: decls can shadow decls. locals cannot shadow anything. ambiguous decl references are not allowed
<justin_smith>
daurnimator: ok that's demented
<dominikh>
andrewrk: what's considered an ambiguous decl reference?