ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
<marler8997> or sometimes an older compiler, sometimes older compilers aren't smart enough to detect valid things. A common one is detecting whether variables are uninitialized
<marler8997> one of the reasons why Zig not having warnings will be nice
<g-w1> yeah, anything I should do?
<g-w1> I recently started using lorri and it started
DarkUranium has joined #zig
<marler8997> try a different compiler?
<marler8997> clang maybe?
<g-w1> clang is also broken ;)
<g-w1> ill try to fix it
<g-w1> clang says cannot find stdio.h, so something broke
<daurnimator> ifreund not historically
<daurnimator> ifreund: e.g. I think unix 8th edition uses write() returning 0 to indicate that read() would return 0
<g-w1> i guess I will nuke lorri
<g-w1> oof it wasn't lorri
Swahili has quit [Remote host closed the connection]
<g-w1> its probably my nix shell, can someone take a look at this?
adamkowalski has joined #zig
<adamkowalski> is there a way to predict what the name of the executable will be for a unit test?
<adamkowalski> if I type zig test tests/foo.zig
<adamkowalski> and then want to run the debugger on it for example
<g-w1> if it fails it will show the path
<g-w1> so you can put in an unreachable or panic
<adamkowalski> sure but suppose you want to preemptively know. I want to hook it up to my editor (emacs)
<adamkowalski> I have a test at point implemented, but I can't implement debug at point
<adamkowalski> I have to run the failing test, wait for the error, grab the path, modify the config, launch lldb
<g-w1> use -femit-bin but beware, it expects a few args to be passed to each test
<adamkowalski> and what if you want to debug a passing test? it seems strange adding unreachable to the end
<g-w1> zig test -femit-bin=output
<adamkowalski> ah so output would be the path you want to use?
<g-w1> yes, but then you need to do ./output `zig-exe-path` so that it can do some stuff in the test runner
<adamkowalski> perfect i'll try that!
<g-w1> and that will run all the tests in the file
<adamkowalski> but I can still use --test-filter right?
<g-w1> lemme try
<adamkowalski> sorry yeah i'm trying too, will report back
<g-w1> i dont think so
<g-w1> also that zig test -femit-bin runs the tests so im not sure if its the best. I think it may just be an untended side effect of how the compiler works, not how its intended
<adamkowalski> actually it seems to be working perfect for me
<g-w1> wow! im getting into emacs so if you could share the config that would be great!
<adamkowalski> yeah that actually works great, because when I do test at point, it will generate the output
<adamkowalski> then when I want to debug the output file will be in the right path and I just pass in the zig exe
<adamkowalski> give me a couple minutes to implement and then I'll push to github
<g-w1> ok
<adamkowalski> My workflow does rely on a specific project structure to work though haha
<adamkowalski> So you might need to modify it a bit
<g-w1> ok
<adamkowalski> essentially I have a src folder and a tests folder
nycex has quit [Remote host closed the connection]
<adamkowalski> If your project is named foo I expect you have a src/foo.zig file
nycex has joined #zig
<adamkowalski> that file is the entry point for your library and when you run the tests I add a --pkg-begin foo src/foo.zig tests/my_test_file.zig
<adamkowalski> so if you don't utilize that you might want to change things to work for you
<g-w1> ok, well i think it would help to see another ziguanas emacs configs anyways
<adamkowalski> you my friend are a genious! I got it hooked up
<adamkowalski> now test at point and debug at point work
<g-w1> ah the culprit was i didn't have hardeningDisable=["all"]; in my shell.nix. andrewrk: I remember you gave this to me, why is this required?
earnestly has quit [Ping timeout: 256 seconds]
brzg has joined #zig
<adamkowalski> my zig mode config starts at 230
<adamkowalski> I add a config to emacs lsp mode to utilize zig lsp
<adamkowalski> then you can see the zig test suite, file, nearest, last, and visit functions which do as they are named
<g-w1> ok, thanks
<adamkowalski> and then at the very end I have the dap config (debug stuff)
<adamkowalski> let me know if I can help1
<adamkowalski> I also have neovim configs in there which do similar things (run nearest test) / (debug using some config) so whatever floats your boat
<andrewrk> g-w1, because otherwise nixos adds -O2 and some other stuff which ruins debuggability when you are developing
<g-w1> ok, well it also added a bunch of compilation warnings that broke the build, I will make a wiki page to help a future person from debugging this :)
<g-w1> thanks
<adamkowalski> andrewrk: do you have any information you can point me to about how you implemented type checking?
<adamkowalski> it seems like it creates a chicken/egg problem with compile time code evaluation
<adamkowalski> you can have functions which return types, but in order to figure out the function to call you need to know the type of the variable right?
<g-w1> adamkowalski, see zir_sema.zig it takes zir from zir.zig and runs comptime on it *producing* typed zir (ir.zig)
<g-w1> comptime is the thing that does the typechecking
<adamkowalski> yeah I figured there would be some untyped ir that gets produced first
<adamkowalski> then do you have a bytecode interpret or how do you evaluate the untyped ir during compile time?
<adamkowalski> and how do you type check the things during comptime execution haha
<g-w1> you eval the untyped ir
<adamkowalski> how though haha
<adamkowalski> you don't know the types? so which instructions do you generate?
<g-w1> search for mod.coerce in this file
<adamkowalski> awesome thanks, i'll start studying that
<g-w1> and review coerce in Module.zig to see how the type checking works
<adamkowalski> wow that codebase is really clean, it makes it a joy to read haha. The c++ std library is a nightmare with all their naming schemes
gazler_ has joined #zig
squeek502 has quit [Remote host closed the connection]
adamkowalski has quit [Quit: Lost terminal]
gazler has quit [Ping timeout: 272 seconds]
midgard_ has joined #zig
midgard has quit [Ping timeout: 240 seconds]
cole-h has quit [Quit: Goodbye]
cole-h has joined #zig
<g-w1> adamkowalski thanks! your config made lsp work for me
Xavi92 has joined #zig
bitmapper has quit [Quit: Connection closed for inactivity]
eax has joined #zig
knebulae has quit [Read error: Connection reset by peer]
knebulae has joined #zig
bitmapper has joined #zig
<Xavi92> After a few months without updating zig, I have noticed a format specifier is now required e.g.: `{s}` or `{d}`. What's the rationale behind this change? From first sight, this looks like a step backwards, since `{}` should be enough since zig's comptime is clever enough to guess the type underneath
<Xavi92> It looks a lot like the (insecure) format specifiers on C `%s` and `%d`, respectively
<daurnimator> Xavi92: it was due to a mission to removed the special cases for u8 inside of `std.fmt`. I agree that it seems a step backwards
<Xavi92> daurnimator: thanks for the quick reply. Which special cases?
<daurnimator> Xavi92: previously there was a "if slice: if u8, print as string else print as comma separated list of values"
<Xavi92> Hrm, I'm surprised the language got affected by an apparent quirk on its implementation, though
<daurnimator> Xavi92: essentially a side effect of zig having no "string" type and instead relying on slice-of-u8
<andrewrk> Xavi92, the insecurity of C printf specifiers is when using a user-provided format string. this is not a concern in zig because the format string is always comptime-known
<andrewrk> the problem with {} was that you could introduce bugs on accident because you expected a string but provided a non-string
<andrewrk> and this would only manifest at runtime in the form of a bug
<daurnimator> andrewrk: I thought it was more the inverse: people had a comptime function that e.g. printed arrays, and then when passed a u8 it would suddenly start doing something different
<Xavi92> andrewrk: that seems a valid reason. So I guess the compiler performs comptime checks even if `{s}` is passed to the format specifier and a non-string parameter is passed
<andrewrk> yes; the {s} makes sure that you pass something that makes sense to print as a string
<Xavi92> What about `{*}`, BTW?
<andrewrk> that means print it as a pointer address
<andrewrk> T@0xdeadbeef
<Xavi92> I understand. Thanks again!
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
Techcable has quit [Remote host closed the connection]
<v0idify> is there date stuff in std? like iterating through months
<brzg> you can look through std/time.zig but i dont think so
<v0idify> yeah no, there's basically nothing there
<v0idify> ooh boy dates sure are fun
hnOsmium0001 has joined #zig
Xavi92 has quit [Quit: - Chat comfortably. Anywhere.]
eax has quit [Ping timeout: 268 seconds]
xackus has joined #zig
xackus_ has quit [Ping timeout: 272 seconds]
brzg has quit [Quit: leaving]
_whitelogger has joined #zig
geemili has joined #zig
klltkr has quit [Ping timeout: 240 seconds]
craigo_ has quit [Ping timeout: 264 seconds]
Techcable has joined #zig
Techcable has quit [Ping timeout: 260 seconds]
Techcable has joined #zig
_whitelogger has joined #zig
semarie has quit [Ping timeout: 240 seconds]
Techcable has quit [Remote host closed the connection]
semarie has joined #zig
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #zig
komu has joined #zig
komu has quit [Quit: Connection closed]
em1n has joined #zig
cole-h has quit [Ping timeout: 240 seconds]
em1n has quit [Ping timeout: 260 seconds]
bitmapper has quit [Quit: Connection closed for inactivity]
dyeplexer has joined #zig
ur5us has joined #zig
ur5us has quit [Ping timeout: 264 seconds]
earnestly has joined #zig
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
lqd has quit [Quit: Connection closed for inactivity]
craigo_ has joined #zig
jaens[m] has joined #zig
jokoon has joined #zig
eax has joined #zig
tnorth_ has joined #zig
<tnorth_> Hey there. Trying to have a struct including a pointer to its own type, but I get `struct Foo depends on itself`. The code is: fn Test(comptime T: type) type { return struct { children : ?*[2]@This(); }; }
<tnorth_> If I write children: ?*[]@This(); it compiles, but according to the docs, this is for runtime known number of items. I want to have an array of pointer to such a structure, and I know that number at comptime. Reading the docs, I had the impression that *[2] bar is a pointer to 2 items of type bar. Here, the compiler shouldn't need to know more, or am I missing something?
klltkr has joined #zig
<ifreund> no that should work, sounds like a compiler bug to me
<ifreund> though *[2]@This() is a pointer to array not array of pointers
<ifreund> you might want [2]?*@This()
<tnorth_> hmm ok thanks, I'll try with the latest build and file a bug if it still doesn't work
<tnorth_> btw, is it possible to have a pointer to different (known) types of data? probably not, right?
<ifreund> you mean one pointer type which could point to multiple different things? you need @ptrCast() for that
geemili has quit [Ping timeout: 240 seconds]
<ifreund> or you could just store a usize and use @ptrToInt()/@intToPtr()
geemili has joined #zig
<tnorth_> ok!
<tnorth_> thanks
<tnorth_> (that's what I meant)
eax has quit [Ping timeout: 268 seconds]
Swahili has joined #zig
<Swahili> Trying the hash map, checked the example ( )
<Swahili> Where: var map = AutoHashMap(u32, u32).init(std.testing.allocator)
<Swahili> what is the type of map?
<Swahili> similarly, while trying the stringhashmap, used @typeof, which gives me std.hash_map.HashMap([]const u8,[]const u8,std.hash_map.hashString,std.hash_map.eqlString,80)
<Swahili> is this the right way of doing this?!
<Swahili> if there's a more generic way of writing the type that's not that long
<ikskuh> the type is AutoHashMap(u32, u32)
<g-w1> AutoHashMap(u32,u32)
<ikskuh> const MyHashMap = AutoHashMap(u32, u32);
<ikskuh> MyHashMap.init(allocator);
<Swahili> For StringHashMap too?
<Swahili> std.StringHashMap([]const u8)
<ifreund> yes, it works the same way
<Swahili> Interesting, that worked
<ifreund> comptime functions are memoized which makes this work
<Swahili> Thanks for the help!
<ifreund> i.e. every invocation of std.ArrayList(u8) will return the same type
<Swahili> It'll take a few months, but learning slowly thanks to you people.
<Swahili> Looking at the source code ( ), we have: pub fn StringHashMap(comptime V: type) type
<Swahili> is this a generic? saying that because of the syntax"type"
<g-w1> yes
<Swahili> just noticed :T interesting
eax has joined #zig
eax has quit [Remote host closed the connection]
eax has joined #zig
<tnorth_> is it possible to define an int size using a comptime variable ? ie instead of var foo: u8; comptime ss: u8 = 8 ; var foo : u ss ?
<tnorth_> (the latter doesn't work)
<daurnimator> tnorth_: `std.meta.Int(false, ss)` ?
<tnorth_> daurnimator: I didn't know about that one, thanks!
<tnorth_> s/meta.Int/meta.IntType/ I guess
<dutchie> `pub const IntType = @compileError("replaced by std.meta.Int");` ?
<dutchie> you'll also want to write .signed or .unsigned instead of true/false
<g-w1> probably on different version
bipbopbee has joined #zig
* daurnimator has spent a few hours playing with netlink.... its really hard to come up with a robust netlink API without allocations
<daurnimator> Maybe I'll have to write it with allocations and tell people to use FixedBufferAllocator :/
Xavi92 has joined #zig
<Xavi92> Hi, this might fit better on #vscode, but for some reason I can't toggle breakpoints on .zig files in codium. Is there anyone else having this issue?
<Xavi92> Thanks anyway!
<ifreund> /buffer 14
<ed_t> at what optimization levels are for (xxx) |*y| y.* = z; statements replaced with memset? eg. does this only happen with ReleaseFast?
<ifreund> probably relase safe as well
<Swahili> Let's say that I have const Suit = enum { clubs, spades }, could I access the enum from the string literal "spades"? Of course not right?
<ifreund> Swahili: you can cause zig is awesome
<ifreund> std.meta.stringToEnum
<Swahili> wow! lol that's awesome!
<Swahili> I'll check that :D
<Swahili> Yeh it works! Thank you!
<ifreund> no problem!
<daurnimator> hmm... there's no way to make a method allow both `*Self` and `*const Self` is there
<daurnimator> in that the const-ness propagates to e.g. the return type
<ifreund> should be, pretty sure stuff in std.mem does that
<daurnimator> :( seems like I need to duplicate my function: `fn foo(self: *Self) *foo { return; } fn foo_const(self: *const Self) *const foo { return; }`
<ifreund> daurnimator: you can use @typeInfo() and @Type() build the return type
<ifreund> though then you need to take anytype... yeah I guess that's the issue
<daurnimator> ifreund: I can't though: if I don't use `*Self` in the signature then you don't get the automatic "take a reference when calling methods" behaviour
tane has joined #zig
<daurnimator> if I had `fn foo(self: anytype) if(self==*Self) *foo else *const foo {` then you can't do ``
<ifreund> this use case confuses me though, if *const works why not just use that?
<daurnimator> ifreund: sometimes you just want to read the result; sometimes you need to modify it
<ifreund> sound like that should definitely be two separate functions :P
<daurnimator> not really
<daurnimator> let me paste the actual code I'm now using
<ed_t> ifreund looks like it is NOT happing with ReleaseSafe, if I am reading the valgrind, MachineCode output correctly. Interestingly it looks like the preceed allocate does call a memset to set the allocation to undefined. Is there a way to tell the allocator what value to set the allocation to?
<daurnimator> ed_t: zig emits special annotations for valgrind :)
<ifreund> ed_t: no you can't tell the allocator what to set the memory to. Note that that memset for undefined is a no-op in release fast/small
<ed_t> ifreund its also 4x faster that the loop zig uses later to set the allocation to 0
<v0idify> daurnimator, i get what you're trying to do and i think it should be possible but from an API perspective i would just leave it as is
<daurnimator> v0idify: I'm about to do it again.... with a heftier function body
<daurnimator> lots of duplicated code :(
<ifreund> daurnimator: does anytype as the first arg not allow syntax?
<daurnimator> ifreund: when it does you get a `Self` rather than a `*Self` or a `*const Self`: in this case the pointer value matters
<ifreund> ah I see
<daurnimator> though actually its worse
<daurnimator> *always* gives a Self
<daurnimator> ==> you never get the mutable version
<daurnimator> what I want is if `foo` is mutable, foo.header() returns a mutable pointer; otherwise, foo.header() returns a const pointer
<ifreund> yeah I totally get your use-case now
<ed_t> according valgrind even release fast is not using memset for the loop (as you explained the memset for undefine is optimized out)
<ifreund> daurnimator: wait, why can't you take Self by value? you're not returning a pointer to the struct (at least not in the header() example)
<ifreund> unles data.ptr points into the struct...
<daurnimator> ifreund: even if foo is mutable I still get the Self by value
<daurnimator> oh wait... hmmmm
<ifreund> the question is whether is mutable or not
<daurnimator> okay I think I have a better workaround
<v0idify> how do i turn numbers into strings
<ifreund> v0idify: std.fmt.bufPrint() or allocPrint()
<v0idify> hmm i'm `print`ing tho
<v0idify> wrong question, just need to check format docs
<v0idify> oh but i need to pad zeroes to id
<v0idify> it*
<v0idify> it's a date
<ifreund> v0idify: see the doc comment of std.fmt.format()
<v0idify> yup that's what i'm doing, holy this function is powerful
bitmapper has joined #zig
<v0idify> am i not supposed to call .close on fs.cwd()?
<ifreund> v0idify: no
<v0idify> yeah just read the doc comment (it doesn't show up in generated docs), why?
<ifreund> the generated docs are very incomplete, I recommend ignoring them and just reading the source
<v0idify> is there an inverse format? like parsing
<daurnimator> v0idify: not really. there's a parseInt though
<daurnimator> parsing needs lookahead; which means it doesn't have a straightforward inverse to serialisation
<v0idify> okay
<v0idify> memory leak reports from GPA are not giving a full stacktrac
<v0idify> this is a confusing error
<v0idify> error: type '?*std.hash_map.Entry' does not support field access
<v0idify> for ( |kv| {
<ikskuh> for requires .len to be existent
<ikskuh> you want to use "while" here
<v0idify> oh wow
<v0idify> somehow i read the test cases on hash_map.zig multiple times without realizing that
_whitelogger has joined #zig
klltkr has quit [Quit: Leaving]
cole-h has joined #zig
karchnu has joined #zig
Snaffu has joined #zig
Akuli has joined #zig
dyeplexer has quit [Remote host closed the connection]
<Swahili> Is it possible to create an array literal dynamically? std.ArrayList is the way to go?
<Swahili> (not knowing the array length)
<g-w1> arraylist
<ifreund> array length must be comptime known, you can create them dynamically at comptime but not at runtime
<Swahili> probably best to re-read
<ikskuh> Swahili: what do you want to achieve?
<ikskuh> array literals dynamically doesn't make much sense, as "literal" is a syntactical concept
<ikskuh> do you mean array (constant size), slice(fixed, but dynamic size) or resizable data structure?
<Swahili> ikskuh: sure :) just testing really
yrashk has quit [Read error: Connection reset by peer]
yrashk has joined #zig
cren has joined #zig
dch has quit [Ping timeout: 264 seconds]
dch has joined #zig
dch has quit [Client Quit]
dch has joined #zig
tnorth_ has quit [Ping timeout: 240 seconds]
<marler8997> the C printf security issues don't apply to Zig because it does type verification at runtime (i.e. using {s} for an integer will be a compile error)
<marler8997> that was for Xavi92
<marler8997> *type verification at comptime
<cren> hi! do Zig strings give me a direct view onto the bytes? I want to make sure I'm manipulating the raw bytes and not characters
mikdusan2 has quit [Quit: WeeChat 3.0.1]
<Xavi92> marler8997: thanks for your reply :)
<ifreund> cren: if you're talking about string literals, they are of type *const [N:0]u8 where N is the length
<ifreund> so yes, you are manipulating the raw bytes
<cren> oh wait Zig doesn't have a `String` type does it? It's just character arrays...
* cren slaps himself around the head a bit
<cren> oh, no it does.
<ifreund> zig has no language level string type
<ifreund> string literals are byte arrays as I said
<ifreund> usually slices of bytes are used to pass strings around
<cren> yeah I've just now realised I was double-wrong
jokoon has quit [Ping timeout: 272 seconds]
<cren> I was referring to a `String` type which did not exist in a function that was never used, so the compiler wasn't catching it
Thale has joined #zig
<Thale> hello
<Thale> anyone here who fancies answering  some basic questions about slices vs. arrays vs. pointers again? I am still struggling to get it right more often than not
<Thale> suppose I have a buffer []u8, which holds my data
<Thale> and I want to now copy the first 4 bytes to a usize, the next 4 to a f32 etc.
<Thale> var value: usize = std.mem.bytesAsValue(usize, buffer[0..7]);
<Thale> This is what I tried, but the types are not correct like that, because bytes as Value expects an array
<ifreund> var value = std.mem.bytesToValue(usize, buffer[0..@sizeOf(usize)]);
<Thale> oh should have been 8 I guess
<Thale> not 7
<ifreund> yes, also bytesAsValue returns a pointer
<Thale> but still same as before
<ifreund> bytesToValue returns a value
<Thale> ah ok
<Thale> stil lgetting expected *[8]u8, passed []u8
<ifreund> can I see the exact code producing that error?
<ifreund> because what I sent should work
<Thale> D:\Software\Programmieren\zig-windows-x86_64-0.8.0-dev.1118+8661a13b7\zig-windows-x86_64-0.8.0-dev.1118+8661a13b7\lib\zig\std\mem.zig:2069:9: error: expected *[8]u8, passed []u8
<Thale>         @compileError(std.fmt.bufPrint(&buf, "expected *[{}]u8, passed " ++ @typeName(B), .{size}) catch unreachable);
<Thale>         ^
<Thale> D:\Software\Programmieren\zig-windows-x86_64-0.8.0-dev.1118+8661a13b7\zig-windows-x86_64-0.8.0-dev.1118+8661a13b7\lib\zig\std\mem.zig:2077:77: note: called from here
<Thale> pub fn bytesAsValue(comptime T: type, bytes: anytype) BytesAsValueReturnType(T, @TypeOf(bytes)) {
<Thale>                                                                             ^
<Thale> D:\Software\Programmieren\zig-windows-x86_64-0.8.0-dev.1118+8661a13b7\zig-windows-x86_64-0.8.0-dev.1118+8661a13b7\lib\zig\std\mem.zig:2077:77: note: called from here
<Thale> pub fn bytesAsValue(comptime T: type, bytes: anytype) BytesAsValueReturnType(T, @TypeOf(bytes)) {
<Thale>                                                                             ^
<Thale> .\src\mesh.zig:429:71: note: called from here
<Thale>                         var parent_index: usize = std.mem.bytesToValue(usize, nodes_buffer[byte..@sizeOf(usize)]);
<Thale> is there a better way to paste code here?
<ifreund> use a pastebin, this is IRC
<ifreund> I see the problem though, you're using a runtime known index
<Thale> yes
<ifreund> you need nodes_buffer[byte..][0..@sizeOf(usize)]
<ifreund> slicing only gives you a pointer to array if both indicies are comptime known currently
<Swahili> Thale: use something like
<ifreund> though IMO it should only require the length to be comptime known
<Thale> ahh, that makes sense
<Thale> cool, that works, yes, the byte is just supposed to be an offset
<Thale> thanks!
<ifreund> no problem!
<ifreund> (aside, I was being dumb. we slice with start/end indexes in zig so both must be known to know the length)
<v0idify> how do i easily sort dates :#
<Thale> well if i did byte..byte+8, you know that the length is 8 independent of byte I guess?
<Thale> but yeah I see what's the issue now
<v0idify> nvm i don't need it yet
<g-w1> I think a lot of things would be easier if the self-hosted compiler imported "std.zig" instead of "std". this would help with zls completions because it has the right version of std and makes it slightly easier to build zig
<g-w1> is there anything not making that happen?
<ifreund> g-w1: well for one, that wouldn't be possible with the current directory structure
<g-w1> could you override the "std"?
<ifreund> @import("std.zig") outside of the std itself also feels super icky to me
<g-w1> well then @import("std") but overriding std; <- would that be better
<ifreund> I don't see the point
<ifreund> you should only be using the the compiler built from the same commit you are working off of to develop stage2
<g-w1> zls sees import std as the std system location
<g-w1> its not that big of a problem
<cren> how should I check two strings for equality in the sense "all the same characters in the same order"?
<g-w1> std.mem.eql(u8, str1, str2)
<earnestly> encoding
<g-w1> utf8?
<earnestly> Who knows, are both even encoded the same?
<earnestly> Do zero-width spaces count?
<v0idify> float value 1.100000 cannot be coerced to type 'i64'
<ifreund> @floatToInt()
<v0idify> oh my god of course
<v0idify> for some reason my brain said "oh i64, totally a float"
<ifreund> heh
<v0idify> what is wrong with me @intToFloat(i64, num)
<ifreund> must be opposite day where you're living :P
Nypsie has joined #zig
<Swahili> Is there a good read on error handling in Zig? The docs got me started but, I'm not sure if I'm doing it correctly. But this might be due to my application flow and my own decisions over when to use catch for default, etc.
<v0idify> is there a way to get something from an array without failing when it's out of bounds?
<ifreund> v0idify: const result = if (i < foo.len) foo[i] else default;
ur5us has joined #zig
<ifreund> Swahili: just do what makes sense, there are no hard and fast rules to follow. Zig is a very pragmatic language
<Swahili> ifreund: ok ;)
ur5us_ has joined #zig
ur5us has quit [Ping timeout: 264 seconds]
jzelinskie has quit [Ping timeout: 260 seconds]
eddyb[legacy] has quit [Ping timeout: 265 seconds]
hnOsmium0001 has joined #zig
jzelinskie has joined #zig
eddyb[legacy] has joined #zig
Swahili has quit [Remote host closed the connection]
<andrewrk> you'll know if you hit a hard and fast rule: the compiler will spit an error at you :)
ifreund has quit [Ping timeout: 256 seconds]
ifreund has joined #zig
squeek502 has joined #zig
emptee has joined #zig
mikdusan has joined #zig
Akuli has quit [Quit: Leaving]
swills has quit [Ping timeout: 240 seconds]
Thale has quit [Quit: Connection closed]
swills has joined #zig
notzmv has joined #zig
notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
nikita` has left #zig [#zig]
swills has quit [Ping timeout: 240 seconds]
craigo_ has quit [Ping timeout: 272 seconds]
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
<andrewrk> alright! #7920 is down to only the remaining zig fmt failing cases
<andrewrk> ifreund, I'm about to take on a new task, do you have anything W.I.P. for me to avoid?
<ifreund> andrewrk: not right now, let me know what you start on though
<ifreund> was distracted by river today :)
tane has quit [Quit: Leaving]
<andrewrk> sounds like a worthwhile distraction! I'll start on the "recovery" test cases
<andrewrk> I think we are very close to merge ready
<andrewrk> and then R.I.P. ZLS
swills has joined #zig
<g-w1> what does recovery mean?
<andrewrk> the use case is an IDE wants to still have an AST even when there are parse errors because the programmer is in the middle of editing
<andrewrk> so it means emitting parse errors but still completing parsing and recovering the meaning of the tokens after the error
<g-w1> oh, makes sense, that is a very good feature
<noam> andrewrk: awesome work! :)
Xavi92 has quit [Quit: - Chat comfortably. Anywhere.]
ur5us_ has quit [Ping timeout: 264 seconds]
emptee has quit [Quit: Konversation terminated!]
<andrewrk> 48 failing zig fmt test cases left
<earnestly> daurnimator: ~cks too that blog as an opportunity to claim that what this package maintainer is really saying is, "you should do more work for us and limit the features (and reliability) of your software"
<earnestly> Which is about what I suppose ought to be expected from developers who think they should bundle libraries
<daurnimator> "~cks"?
<earnestly> I find it rather tasteless given how much I've seen maintainers contribute patches and fixes upstream to support new versions
<earnestly> But if anything it provides, maybe, a median insight into how these people think