<g-w1>
andrewrk: are you doing lazy stuff for structs, or will all the lazy stuff come later at the same time?
<andrewrk>
I'm about to tackle it
<g-w1>
ok nice! that progress looks really sweet
osa1_ has quit [Ping timeout: 268 seconds]
aerona has quit [Quit: Leaving]
artem1 has quit [Ping timeout: 250 seconds]
earnestly has quit [Ping timeout: 240 seconds]
artem1 has joined #zig
artem1 has quit [Ping timeout: 246 seconds]
<mikdusan>
one nasty side effect of linux OOM killer is building software, the unfinished file is not removed, and subsequent make/ninja skips it because timestamp is adequately newer than deps. real PITA with building llvm debug and gcc-10.2 (lto memory pig during linking)
gpanders has quit [Ping timeout: 268 seconds]
<andrewrk>
oof
<mikdusan>
oom !
cole-h has joined #zig
dyeplexer has joined #zig
bitmapper has quit [Quit: Connection closed for inactivity]
artem1 has joined #zig
<marler8997>
does anyone want to be my impartial judge and tell me if I'm taking crazy pills on an issue with win32metadata?
<koakuma>
Or alternatively, is there anything I can help with to make self.buf aligned?
<koakuma>
I also see a TODO in the struct definition so I believe the core team is aware about this, so, is there any plans on when it will be implemented?
<ifreund>
koakuma: add dirent64 definitions for the relevant architectures missing them and use the align() specifier in the comment there
<ifreund>
as for when it will be implemented, the answer is before 1.0 or whenever someone interested implemented in it feels motivated, which ever comes first
maetbag has joined #zig
osa1 has joined #zig
earnestly has joined #zig
notzmv has quit [Read error: Connection reset by peer]
<koakuma>
ifreund: I see that the dirent64 structure is shared across all arches:
<koakuma>
So I only need to uncomment the TODOs, or is there anything else I should do?
<ifreund>
is there a use-case for different parts of a large program having different max supported versions for a given interface?
wootehfoot has joined #zig
mmohammadi9812 has quit [Remote host closed the connection]
cole-h has joined #zig
yyp has quit [Quit: now it's safe to turn off your computer]
yyp has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
klltkr has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<cepheus>
random bikeshedding question about API design: i'm wrapping a C library that can return failure in very exceptional cases that are usually not really reasonable (or at least worth the effort) to gracefully handle, but i don't want to entirely discount that possibility. would it make more sense to use the name 'x' for the infallible version and 'tryX' for the fallible, or 'x' for the fallible and 'mustX' for the infallible?
<cepheus>
(in this case the infallible would just panic in the cases where the fallible version would return an error, but i'm not also sure that's necessarily desirable)
<ifreund>
if there's *any* way to handle the error, your function should return an error and not panic, always leave that decision up to the user of your library
<cepheus>
alternative suggestions also welcome of course
Snaffu has joined #zig
<cepheus>
I'm not forgoing one for the other in this case
<ifreund>
my point is that I wouldn't have two separate function definitions
<ifreund>
just make the user do `foo() catch @panic("")`
pmwhite has joined #zig
<cepheus>
neither would i were it not for the sake that this is both a narrow intersection of very commonly used operation, very difficult to recover correctly, and ideally usable with defer/errdefer without hassle
cole-h has quit [Ping timeout: 265 seconds]
lunamn has quit [Ping timeout: 240 seconds]
ave_ has quit [Ping timeout: 245 seconds]
<pmwhite>
Is there a reason that std.os.linux.open returns a usize instead of an i32. I would expect the result to be usable as the parameter to std.os.linux.close.
<ifreund>
pmwhite: std.os.linux is made up of direct wrappers for the syscalls, you need to call std.os.linux.getErrno() to check if open() returned an error and then cast to the i32 you want
<ifreund>
note that std.os.open() does this for you and is usually what you want to use
<pmwhite>
ah, that makes sense. I guess I should be using std.os.close as well.
<pmwhite>
looks like there is no std.os.ioctl, which is not a surprise, since it's not a cross-platform thing (I think).
linuxgemini has quit [Quit: Ping timeout (120 seconds)]
lunamn has quit [Quit: Ping timeout (120 seconds)]
ave_ has quit [Quit: Ping timeout (120 seconds)]
pmwhite has quit [Ping timeout: 268 seconds]
m4r35n357 has quit [Ping timeout: 240 seconds]
m4r35n357 has joined #zig
dyeplexer has joined #zig
<g-w1>
andrewrk: ah, i figured out why I thought there was some cpuinfo bug the other day. is this a bug or a feature: https://clbin.com/XZxfV
<g-w1>
this is preventing me from switching to the zig build system for my project
<g-w1>
zig recognizes the mcpu but llvm doesn't like the asm even tho gcc does
Snaffu has quit [Remote host closed the connection]
Snaffu has joined #zig
Snaffu has quit [Client Quit]
<g-w1>
lemme strace it to see if its even passing the right things to clang
lunamn has joined #zig
linuxgemini has joined #zig
lunamn has quit [Client Quit]
linuxgemini has quit [Client Quit]
Akuli has joined #zig
<andrewrk>
g-w1, arm1176jzf_s has sub-arch v6kz which should imply armv5t and armv6k. if you use --verbose-llvm-cpu-featuers it should have +armv6kz which should do the trick
dyeplexer has quit [Remote host closed the connection]
artem1 has joined #zig
rbino has joined #zig
maetbag has quit [Quit: maetbag]
artem1 has quit [Ping timeout: 250 seconds]
artem1 has joined #zig
<rbino>
hi everybody! I'm trying out Zig and so far I like it very much, now I'm trying to do a thing with comptime: is it possible to populate a global const array using comptime? if so, how would I do it? (links to existing code which does so would be perfect)
<rbino>
ok nevermind: I literally switched back to the Zig documentation where I had the "Arrays" section opened and my eyes ended up on "// use compile-time code to initialize an array"
<g-w1>
i have a code snippet: this parses some data from an embedded file and generates an array https://clbin.com/jjDXP
<rbino>
the array in the example is a var but I assume it works for const arrays to
<rbino>
g-w1, thanks, this also helps
<rbino>
g-w1, if I understand correctly @setEvalBranchQuota(N) is needed to make the compiler able to do N loops at comptime without erroring, right? I assume the default is a low number
<g-w1>
default is 100
<g-w1>
i just chose large number because i knew it would never overflow
<braket>
"Zig has no RAII so it's a non-starter language for me" is among the top 5 sentences that makes my blood boil lmao
<earnestly>
Why would you let that happen to yourself
<g-w1>
someone brought this up on discord and i want to see what people think. lets say package1 defines an error.Foo and package2 also defines that error.Foo. if those errors get merged into the same set, how will you be able to differentiate between them?
sm2n has quit [Ping timeout: 240 seconds]
<earnestly>
Would they be namespaced by package name?
<g-w1>
idk, zig right now doesn't do that
<g-w1>
but i imagine it could become a problem and we dont want the user to have to namespace it
<earnestly>
It may be inevitble that user intervention is necessary
<earnestly>
able*
<g-w1>
this should be solved in the language
<earnestly>
Hm, not sure how it would be possible without restoring to guesswork/heuristics in attempting to automatically do it
<g-w1>
why not just have error.packagename.Foo?
<earnestly>
Oh I thought you ruled out namespacing
sm2n has joined #zig
<g-w1>
the compiler does that, not the user
<g-w1>
in c the user does it
<ifreund>
g-w1: if we do that, I want a way to return error.std.OutOfMemory
<ifreund>
(from outside the std)
<g-w1>
im thinking that the name should be only required if its ambigious
<ifreund>
when would it not be ambigious?
<g-w1>
and why not just return that?
<g-w1>
if there is only one instance of the error in the compilation
<g-w1>
s/instance/package with/
<earnestly>
Ada might be instructive, perhaps. The packaging system is quite involved, but can't remember much (may be explicit)
<g-w1>
im not sure how to solve this, just thought it would be good to bring up as i can see it causing wtf bugs
<ifreund>
g-w1: I'd open an issue to discuss this properly. Maybe there already is one
<g-w1>
i dont think so, i think funcod was trying to bring this up, but couldn't properly phrase it (maybe)
<g-w1>
ill open one when I find time
<ifreund>
maybe, I couldn't really understand what they were getting at or what it had to do with the original message I sent