ChanServ changed the topic of #zig to: zig programming language | https://ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
ur5us has quit [Remote host closed the connection]
ur5us has joined #zig
ur5us has quit [Remote host closed the connection]
ur5us has joined #zig
benjif has quit [Quit: Leaving]
ur5us_ has joined #zig
ur5us has quit [Ping timeout: 264 seconds]
cole-h has quit [Quit: Goodbye]
cole-h has joined #zig
greeb has joined #zig
benjif has joined #zig
<ugla> Otherwise I will try to make one.
<ugla> Wayland coordinates are in 24.8 fixed-point format, so I have some functions to deal with that specific format, but would be nice to have a lib for any Qm.f format
xackus has joined #zig
<pixelherodev> Fixed(x,y) might be a useful generic
jsb has quit [Ping timeout: 260 seconds]
jsb has joined #zig
cararemixed has quit []
cole-h has quit [Ping timeout: 264 seconds]
ur5us has joined #zig
ur5us_ has quit [Ping timeout: 264 seconds]
hspak has quit [Ping timeout: 240 seconds]
sebonirc has quit [Quit: sebonirc]
bitmapper has quit [Quit: Connection closed for inactivity]
benjif has quit [Quit: Leaving]
xackus_ has joined #zig
xackus has quit [Ping timeout: 256 seconds]
kbd_ has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
a_chou has joined #zig
a_chou has quit [Quit: a_chou]
ur5us has quit [Ping timeout: 256 seconds]
xackus_ has quit [Ping timeout: 240 seconds]
kbd has joined #zig
jacobsandlund has joined #zig
jacobsandlund has quit [Quit: Ping timeout (120 seconds)]
jacobsandlund has joined #zig
jacobsandlund has quit [Client Quit]
jacobsandlund has joined #zig
jacobsandlund has quit [Client Quit]
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
drp has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #zig
ehaas has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cole-h has joined #zig
lucid_0x80 has joined #zig
lucid_0x80 is now known as suskun_
tnorth_ has joined #zig
suskun_ has quit [Ping timeout: 240 seconds]
lucid_0x80 has joined #zig
leon-p has quit [Quit: leaving]
marijnfs has quit [Ping timeout: 272 seconds]
marijnfs has joined #zig
marijnfs has quit [Client Quit]
gazler has joined #zig
gazler__ has quit [Read error: Connection reset by peer]
nycex has quit [Ping timeout: 240 seconds]
<mikdusan> do we have any allocators that work in both comptime and runtime?
<mikdusan> #868 would help me too. :(
<daurnimator> When is a pointer taken at comptime valid until?
<mikdusan> forever?
<daurnimator> which is to ask: is returning a pointer to a stack array at comptime safe?
<mikdusan> yup
<daurnimator> okay...
<mikdusan> i did it that way for an unsigned integer to string func. used log to figure the digits, then have `var buf: [N]u8 = undefined; .... return &buf;`
<daurnimator> and what if your callee doesn't call you with `comptime foo()`?
<mikdusan> but in order to make the same fn work at runtime... i need to branch
<mikdusan> then it fails
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
<mikdusan> with zig error 'N' is not const evaluable or whatever
<daurnimator> I think for the code I was writing, it would that mean they hit undefined behaviour if they don't use `comptime`
larme has quit [Quit: WeeChat 2.3]
cow-orker has joined #zig
larme has joined #zig
<mikdusan> ah yes... calcLimbLen is probably able to give a comptime result?
<mikdusan> in my case the array size flipped to be runtime dependent and error'd nicely
<daurnimator> `calcLimbLen` works at both comptime and runtime
<daurnimator> and its only dependant on the type of the argument; not the value
<mikdusan> yup so [N]Limb is comptime known in both comptime and runtime initSet
cole-h has quit [Ping timeout: 246 seconds]
<daurnimator> mikdusan: heh.... but I assume we don't *want* that?
<daurnimator> and how do we make cases like my above paste *not* a footgun?
<mikdusan> daurnimator: I like the idea of fn being able to work at both comptime/runtime. but differences like returning stack working in comptime... yuck
* mikdusan votes for compiler if stack mem returned, in both comptime/runtime contexts. (we'll of course need an allocator solve before that)
<daurnimator> mikdusan: the other side of the problem is: without a comptime allocator, returning a pointer to stack is the *only* way to do it :/
<mikdusan> aye aye
<mikdusan> so this is also weird to me. I can do (4 + 4) and compiler with comptime solve it.
<mikdusan> but I have a fn that now works both comp/runtime and print( my_dual_personality_function() ) doesn't get run at comptime unless I prefix it with comptime keyword
<mikdusan> i wonder if there's a way to mark a fn as comptime-savvy
<mikdusan> and this rings a bell. I bet andrew already has an issue for exactly that
mikdusan has quit [Ping timeout: 246 seconds]
mikdusan has joined #zig
ltr has joined #zig
ltr has quit [Quit: leaving]
<tnorth_> hi there. Is there any facility provided by Zig to measure the execution time of a function / piece of code? Or should one just use std.time ?
<mikdusan> not that I recall. maybe look at lib/std/hash/benchmark.zig/benchmarkHash as a quick example
<tnorth_> mikdusan: Ok thanks, I see it uses std.Timer(). I guess using std.time.milliTimestamp() should also work?
<ifreund> indeed, though std.Timer() is likely a lot nicer to use
<ifreund> also it gives nanosecond precision not millisecond iirc
<mikdusan> i think Timer can beat milliseconds and is monotonic; that is it won't be effected by your system's micro-time adjustments that happen... throughout the day
<ifreund> right, yeah you definetly don't want the Timestamp() functions as they arent monotonic
<tnorth_> ok, thanks. Timer() works perfectly
<Nypsie[m]> ifreund: Thanks for the review ;)
more_spaghetti has joined #zig
<ifreund> Nypsie[m]: no problem! it's code review day for me as I've got a large and very cool river PR nearing completion as well :)
<Nypsie[m]> Ooooh nice! Cool to see more and more people contributing to other Zig projects as well :)
bitmapper has joined #zig
<Nypsie[m]> I got a nice proposal/refactor worked out in a seperate branch that I can't wait to show to you all in the next meeting
gazler has quit [Remote host closed the connection]
<ifreund> Nypsie[m]: Nice! i think there's some missing logic in the locals PR though, you don't ensure that the local indexes assigned to alloc instructions are of the correct type
gazler has joined #zig
<ifreund> and don't forget that you can just generate suboptimal code if it's easier to get working
<ifreund> i.e. don't take advantage of the compression the spec allows in the binary format for the locals vec
<Nypsie[m]> ifreund: Ah you're right! I made the assumption that once we reached the codegen stage. We can already assume its of the correct type due to the semantic analysis phase ensuring that.
<Nypsie[m]> s/.We/, we
<Nypsie[m]> But I suppose we have to ensure that the value types match that of the local index
<ifreund> exactly
nvmd has quit [Quit: Later nerds.]
<Nypsie[m]> ifreund: Aren't we supposed to do this check at genLoad, rather than genAlloc? At genLoad we retrieve the index and must ensure that the type of load equals that of the index. Because at genAlloc we only have the type of the variable itself, and nothing else to compare it with.
ltr has joined #zig
<Nypsie[m]> Aaaah wait nvm I see what you mean now. I'll fix this later tonight after work.
donniewest has joined #zig
leon-p has joined #zig
ltr has quit [Ping timeout: 264 seconds]
fputs has quit [Quit: WeeChat 3.0]
fputs has joined #zig
Akuli has joined #zig
waddlesplash has joined #zig
kbd has joined #zig
<tnorth_> what is the reason for never implicitly casting (C-like), for instance int to float?
<ifreund> tnorth_: because that leads to subtle bugs and hard to read code
<daurnimator> tnorth_: I imagine because in C its far too easy to do it accidentally
<daurnimator> tnorth_: in zig any loss of precision or range must be accompanied with a cast that you intended it to happen
<waddlesplash> daurnimator: hello, I replied to your question on GitHub; and feel free to ping me there or here now or in the future with Haiku questions :)
<waddlesplash> and the same goes for anyone else interested in Haiku, of course
<waddlesplash> interest in Haiku outside of the community itself is not very common, so whatever I can do to grease wheels is always a pleasure
<daurnimator> waddlesplash: re: libbe. as its a layer higher than libc, I think we'd hope to avoid it in the zig standard library.
<waddlesplash> Haiku's definition of "libc" is pretty hazy in the first place
<waddlesplash> "libroot.so" has all the libc bits in it, but it has a bunch of Haiku-specific APIs, too
<daurnimator> that we understand
<daurnimator> most (all?) oses are sort of the same with that pattern
<waddlesplash> hmm, actually, are you sure find_directory is in libbe?
<waddlesplash> I don't think it is
<waddlesplash> that documentation may be wrong
<daurnimator> the breadcrumb of your linked docs indicated libbe; that's all I have to go on
<waddlesplash> yeah, it is actually part of libroot.so
<daurnimator> waddlesplash: and thanks for joining in :) welcome to our community!
<waddlesplash> :)
waleee-cl has joined #zig
<daurnimator> waddlesplash: zig considers cross-compilation a first class use-case. my first thought of how zig can help haiku is by allowing people to compile not only zig, but C for haiku from anywhere.
<waddlesplash> you are going to find that tricky for 2 reasons:
<waddlesplash> 1. most Haiku applications are C++, which is somewhat more complicated to cross-compile (but not a lot)
<waddlesplash> 2. Haiku applications rely heavily on extended attributes, which many OSes do not support, or support badly at the filesystem level
<waddlesplash> obviously we support cross-compiling Haiku itself from Linux, etc., but we have some evil tricks in the build system to get around a lack of xattr support
<daurnimator> waddlesplash: once the current basic support is done; and a few more... one item to get an early start on might be to help us get libc/libroot headers under a permissive enough license that we can distribute them with zig itself.
<waddlesplash> Haiku is already MIT-licensed
<waddlesplash> so you are covered :D
tnorth_ has quit [Ping timeout: 240 seconds]
<waddlesplash> filed ticket about erroneous documentation: https://dev.haiku-os.org/ticket/16749
<waddlesplash> I don't know of any other OS/filesystem that supports xattr types; and besides that, most have extremely restrictive size limits for individual or total attributes
<waddlesplash> or just disable them entirely and require you to edit fstab to enable them in the first place
<waddlesplash> under Linux, if you want to use fully native xattrs during a Haiku cross build, you have to use XFS or maybe BTRFS
<waddlesplash> ext4 tops out at 32-64k of xattrs or something like that
nvmd has joined #zig
more_spaghetti has quit [Remote host closed the connection]
<oats> how can I, in the default executable build.zig, set the default target to "native-native-gnu"?
<oats> I've tried combing through std.build but I still don't get it :P
<ifreund> oats: see the standardTargetOptions() function
<ifreund> you can set a default target with the "args" parameter
<ifreund> and don't forget to call setTarget() on your LibExeObjSteps of course
<oats> would this work? StandardTargetOptionsArgs{.defaut_target = .{.abi = .gnu}}
gpanders has quit [Quit: ZNC - https://znc.in]
<ifreund> oats: yes, I believe so
gpanders has joined #zig
<oats> hey that seems to work
<oats> thanks y'all
<dutchie> i tend to have more success reading the std library code than the docs at the moment
hnOsmium0001 has joined #zig
Ziemas has joined #zig
nycex has joined #zig
sord937 has joined #zig
<marler8997> waddlesplash out of curiosity, what sorts of things does Haiku do with the extra xattrs it supports?
<waddlesplash> lots
<waddlesplash> as that documentation page shows, contacts are stored on Haiku in empty files with xattrs
<waddlesplash> similarly, email is stored as one-file-per-message, with to/from/subject/... in xattrs, and then you can search for email using the standard filesystem search dialog
<waddlesplash> you can give any file a custom icon by setting the "icon" attribute
<waddlesplash> file mimetypes are stored in an attribute (i.e. instead of having to sniff every time)
<marler8997> interesting, which filesystem type supports xattrs like that?
<marler8997> or does haiku use it's own filesystem format?
<waddlesplash> some filesystems also expose various on-the-fly metadata that way, e.g. our packagefs exposes a "SYS:PACKAGE" attribute which tells you what package a file comes from
<waddlesplash> marler8997: the Be File System, which comes from BeOS, yes
<marler8997> ah
<waddlesplash> Linux et al. can at least read befs
<waddlesplash> but I think Haiku's driver is the only one with write support
<marler8997> I'd be interested in seeing what Haiku has to offer, I see there's videos on the website, any you would recommend I look at?
<waddlesplash> marler8997: there are then also attribute "indexes", so you can run "query" to search for e.g. "media/* files with MEDIA:duration >= ..."
<waddlesplash> (i.e. at the filesystem level)
<marler8997> ah...now there's a reason for why they are xattrs
<marler8997> instead of just somewhere inside the file
<waddlesplash> well you can add the attributes to any file
<waddlesplash> no need to worry about formats
<waddlesplash> if you want a video, this is a pretty quick introduction: https://www.youtube.com/watch?v=0ua1o0BuYUo
<waddlesplash> the FAQ and then User Guide are better overviews and then documentation of the "why" and the "what"
<marler8997> yeah, I was wondering why you would put email fields in xattrs instead of just inside the email file itself...with the filesystem query feature, now I see why you would put them in xattrs
hidayat has joined #zig
<hidayat> Hi, just started coding in zig, could not find any information on how to compare struct with each other.
<hidayat> Is it to use memcmp from C, if it is, are all Structs padded with zeros?
<ifreund> hidayat: using memcmp on non packed/extern struct would be a bug
<ifreund> std.meta.eql() will do a comparison field by field
<hidayat> cool, thanks
<hidayat> Is there some way of padding a struct with zeros without using memset. Thinking of the use case where you
<hidayat> wanna create a hash from the bytes in a struct. For example to hash all states in a Vulkan pipeline?
<hidayat> Or do you need to pack the struct to be able to do that?
<ifreund> hidayat: you can use a struct with a well-defined memory layout like a packed/extern struct
<ifreund> or you can hash all of the fields individually
<ifreund> zig makes no guarentees about the padding/layout of "plain" structs
<hidayat> thanks:)
<ifreund> no problem, have fun!
<hidayat> thanks, it's been really fun so far:)
<hidayat> just tested std.meta.eql, its soo good, this something that has been missing in C and C++ for a long time
<mikdusan> and look at the source code for it. I don't know if it's possible in c++20 but imagine doing the same thing with templates
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
jacobsandlund has joined #zig
<hidayat> :)
xackus_ has joined #zig
jacobsandlund has quit [Quit: Ping timeout (120 seconds)]
kbd has joined #zig
kbd has quit [Client Quit]
jacobsandlund has joined #zig
kbd has joined #zig
jacobsandlund has quit [Quit: Ping timeout (120 seconds)]
<Nypsie[m]> ifreund: Finally managed to ensure the index's valtype and the local match. Unfortunately I had to dumb it down a little (requires allocation and no compression). But it was the best I could come up with, with the current structure that is.
lucid_0x80 has quit [Ping timeout: 264 seconds]
jacobsandlund has joined #zig
sord937 has quit [Ping timeout: 240 seconds]
sord937 has joined #zig
l1x has joined #zig
Akuli has quit [Ping timeout: 256 seconds]
Akuli has joined #zig
cole-h has joined #zig
hidayat has quit [Quit: Connection closed]
jacobsandlund has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
kbd has joined #zig
kbd has quit [Client Quit]
gazler has quit [Quit: Leaving]
factormystic has quit [Read error: Connection reset by peer]
factormystic has joined #zig
midgard has quit [Read error: Connection reset by peer]
midgard has joined #zig
ur5us has joined #zig
kbd has joined #zig
ur5us_ has joined #zig
ur5us has quit [Ping timeout: 264 seconds]
Akuli_ has joined #zig
Akuli has quit [Disconnected by services]
Akuli_ is now known as Akuli
<rowbee> how does gdb syntax highlight zig code?
<rowbee> it not only highlights C keywords but also stuff like @ptrToInt
<rowbee> which isn't valid C
<rowbee> and stuff like pub fn which obviously isn't C
wootehfoot has joined #zig
<andrewrk> I didn't know it did that, that's neat
<andrewrk> maybe it uses an open source syntax highlighting library such as pygments
wootehfoot has quit [Read error: Connection reset by peer]
sord937 has quit [Remote host closed the connection]
sebonirc has joined #zig
<rowbee> wait it's not intentional
<rowbee> that's so weird
<rowbee> https://www.gnu.org/software/src-highlite/ gdb uses this, apparently
Akuli has quit [Disconnected by services]
l1x has quit [Quit: Connection closed for inactivity]
lunamn has quit [Read error: Connection reset by peer]
ave_ has quit [Remote host closed the connection]
linuxgemini has quit [Remote host closed the connection]
benjif has joined #zig
<andrewrk> I briefly checked the source, it does not mention zig explicitly
TheLemonMan has joined #zig
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
jacobsandlund has joined #zig
<rowbee> really odd
<rowbee> time to gdb gdb
<rowbee> looks like rust.lang contains almost all the keywords i see (pub, fn, usize, etc.)
<rowbee> so it's possible src-highlite detect zig as rust
<fengb> Same hack we do on Discord :P
<rowbee> lol
jacobsandlund has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
<greeb> /quit/win 2
<greeb> oops!
<greeb> long annoying day, sorry -_-
mokafolio has quit [Quit: Bye Bye!]
benjif has quit [Quit: Leaving]
mokafolio has joined #zig
mokafolio has quit [Client Quit]
ur5us_ has quit [Remote host closed the connection]
ur5us_ has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
mokafolio has joined #zig
mokafolio has quit [Client Quit]
ave_ has joined #zig
lunamn has joined #zig
linuxgemini has joined #zig
kameliya has joined #zig
mokafolio has joined #zig
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
mokafolio has quit [Client Quit]
mokafolio has joined #zig