ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
eax has quit [Quit: eax]
cole-h_ has quit [Ping timeout: 265 seconds]
<Snektron> ed_t: You should probably separate parsing of the pipeline definition and running the pipeline. Integrating async into parsing seems like overengineering to me
brzg has joined #zig
layneson has joined #zig
blackpawn has quit [Ping timeout: 256 seconds]
blackpawn has joined #zig
brzg has quit [Quit: leaving]
<vent> Is there a way to define an ad-hock slice over 3 seperate variables? I have 3 strings that I want to pass into std.mem.concat().
sundbp has quit [Ping timeout: 265 seconds]
<mipri> slices are fat pointers, not iterators, so you couldn't do that unless the three separate variables happened to refer to contiguous memory in the order you wanted
<vent> What about something like this? [_][]const u8{page_dirpath, page_basename, page_extension}
<vent> If the pointers to each []u8 are contiguous then it should okay to index right?
layneson has quit [Quit: WeeChat 3.1]
notzmv has joined #zig
<vent> Perhaps if I just declare it as an array first, then pass that in.
LobbyLobster has joined #zig
<oats> does this not work? concat(alloc, u8, &[_][]const u8{a, b, c})
<mipri> ? that's what I'm doing in the second use there
<g-w1_> if the slices are contiginus, will var slice = .{.ptr = a.ptr, .len = a.len + b.len + c.len }; work or am i confused?
<mipri> ah, std.mem.concat just wants a slice of slices; no need for any of that talk about contiguous memory
<oats> indeed
<oats> std.mem.concat is smort
<mipri> I can't get that .{.ptr = ...} stuff to work though
<g-w1_> `var slice: []const u8 = undefined; slice.ptr = xxx; slice.len = xxx;`
<mipri> ah nice. I finally got it but still had a useless initial value
aconbere has joined #zig
<vent> mipri: Nice one, thanks for the code snippet. My code looked very similar already, but the type I was passing in was wrong. I was passing in []u8 when I should have been passing in u8.
osa1 has joined #zig
earnestly has quit [Ping timeout: 246 seconds]
osa1_ has quit [Ping timeout: 264 seconds]
aconbere has quit [Ping timeout: 265 seconds]
aconbere has joined #zig
powerofzero has quit [Ping timeout: 276 seconds]
aconbere has quit [Ping timeout: 264 seconds]
aconbere has joined #zig
tomku has quit [Ping timeout: 246 seconds]
tomku has joined #zig
v0idify has joined #zig
<v0idify> what's a good way to have a Backend struct that can hold different things depending on the platform?
<v0idify> essentially like an interface
<v0idify> but without function pointers lol
<tdeo> how much do you expect to share between the backends?
<v0idify> basically nothing
<v0idify> actually, it depends
<tdeo> if they're not sharing much code, then you can have each struct separately and do `const Backend = if (cond) BackendA else BackendB;`
<v0idify> opengl backends that share rendering functions but not initalizations that are os dependant
<v0idify> but there might be other kinds of backends
dimenus|home has quit [Ping timeout: 265 seconds]
<v0idify> oh maybe just make a single function that takes a union(enum) :/
LobbyLobster has quit [Quit: Leaving]
<v0idify> is there a way to make a union(enum) and only allocate the memory required for the kind chosen?
<v0idify> without having an extra pointer ofc
<v0idify> it's for using on a SinglyLinkedList
<daurnimator> v0idify: sounds like you want a SinglyLinkedList(void) and use `@fieldParentPtr`
Rum has joined #zig
<v0idify> daurnimator, huh it seems like it but it confuses me? how do i know what type it is from void
<v0idify> and what is field_name
<daurnimator> v0idify: you don't: put the `SinglyLinkedList(void).Node` *in* your structure. instead of your structure in the node type
<v0idify> oh that's crazy
<v0idify> hmm i'd rather not though, it wouldn't make much sense for the data structure i'm doing, is there any other way?
<v0idify> i mean, how can i figure out the type from a Node then
<v0idify> use case: linked list of draw operations (think fill rectangle with color, draw text, etc)
<tdeo> you can have a "base" struct with just an enum of which variant it is, and put that base struct in each of the variants
<tdeo> then you can have a linked list of that
<v0idify> and then call fieldParentPtr on that right?
<v0idify> but the Node would need to be a pointer to the struct
<v0idify> s/struct/enum
<tdeo> then you can have a linked list of that
<tdeo> oops
<v0idify> tdeo, yeah, it's saving a Node inside the command. i'll use that for now, thanks
<tdeo> hm, i don't understand. are you thinking of something better than this?
<v0idify> no :p
<v0idify> i'm just saying that i'd rather not have node inside the Command in the case i don't want it on a list, but it'll do for now
ur5us has quit [Ping timeout: 244 seconds]
<tdeo> ah i see, i don't think you can do that with SinglyLinkedList easily but you can probably do it with more code
<v0idify> surely
<v0idify> when type safety + manual memory management bites you in the ass
<v0idify> C allows this easily with just the second part, Go allows this easily with just the first
<v0idify> o/ thanks so much
<tdeo> np
terinjokes has joined #zig
<aconbere> If I have an ArrayList with strings in it ArrayList([]const u8)
<aconbere> What is the type of .items? And how do I check the equality of it?
<aconbere> I'm tryin `testing.expectEqualSlices([]u8, l.items, [_][]u8{ "val1", "val2" });`
<aconbere> but the typing is all wrong haha
<aconbere> (imagine me adding many different consts to places in case that's it)
<aconbere> this is the error I get `./src/mime.zig:62:51: error: expected type '[]u8', found '*const [4:0]u8'
<aconbere> Which I read to say that the big difference is that [_][]u8{ "val1", "val2" } has pointers to the array?
<daurnimator> aconbere: you probably want `[]const u8` as the first argument.
<daurnimator> and then you'll need `&` before the `[_]`
<aconbere> interstingly that changed nothing :-D
<daurnimator> aconbere: you'll also need a `const` so you get: `&[_][]const u8{ "val1", "val2" }`
<aconbere> phew that did it
<aconbere> I had previously put in the consts because... that makes sense to me
<aconbere> but the dereference surprised me
<daurnimator> dereference?
<aconbere> "&"
<aconbere> maybe that's backwards :-|
<daurnimator> that's getting a reference; not a dereference
<aconbere> backwards
<daurnimator> Might be easier for your brain to think of `&` as the "address-of" operator
<aconbere> Thanks :)
<daurnimator> aconbere: `[_][]const u8{ "val1", "val2" }` is an *array* of strings: in memory its two `[]const u8` in a row. with the `&` its a pointer-to-two `[]const u8`s
<daurnimator> aconbere: and then "pointer to some number of `[]const u8`" can coerce to "slice of `[]const u8`", which is what your `expectEqualSlices` wants
<aconbere> actually super helpful
<aconbere> Your explanation makes perfect sense, and it seems obvious in retro spect that this was about the type of the array containing the strings
<aconbere> feel like the error kinda sent me down the wrong route though :-/
<aconbere> '[]u8', found '*const [4:0]u8'
<aconbere> Why do you think the compiler was pointing to the inner strings as the issue?
<aconbere> (sorry super interested in the response but I don't have a bouncer and I have to head to bed, I'll follow up tomorrow, thanks again)
cole-h_ has joined #zig
jumpnbrownweasel has quit [Quit: Connection closed]
aconbere has quit [Ping timeout: 265 seconds]
cole-h_ is now known as cole-h
jumpnbrownweasel has joined #zig
Rum has quit [Read error: Connection reset by peer]
waleee-cl has quit [Quit: Connection closed for inactivity]
sord937 has joined #zig
ed_t has quit [Ping timeout: 246 seconds]
ed_t has joined #zig
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #zig
GreaseMonkey has quit [Remote host closed the connection]
GreaseMonkey has joined #zig
cole-h has quit [Ping timeout: 264 seconds]
riba has joined #zig
yyp has joined #zig
sundbp has joined #zig
ur5us has joined #zig
riba has quit [Ping timeout: 260 seconds]
yyp has quit [Quit: now it's safe to turn off your computer]
yyp has joined #zig
earnestly has joined #zig
yyp has quit [Quit: now it's safe to turn off your computer]
sundbp has quit [*.net *.split]
notzmv has quit [*.net *.split]
sundbp has joined #zig
ur5us has quit [Ping timeout: 264 seconds]
qazo has joined #zig
TheLemonMan has joined #zig
Raito_Bezarius has quit [Ping timeout: 264 seconds]
Raito_Bezarius has joined #zig
notzmv has joined #zig
Rum has joined #zig
Rum has quit [Quit: Leaving]
TheLemonMan has quit [Ping timeout: 260 seconds]
sord937 has quit [Quit: sord937]
TheLemonMan has joined #zig
gazler has joined #zig
<TheLemonMan> sundbp, don't give up! you were this close to the end!
<ikskuh> I started a second attempt on the user map:
<ikskuh> This time, 100% self hosted and no restrictions on the number of markers!
<ikskuh> Contribution via Github PRs
<TheLemonMan> OSM looks pretty nice
<Nypsie> \o/
<ikskuh> TheLemonMan: yeah! and only a little bit of glue JS to Leaflet and Zig code to build the data :)
qazo has quit [Quit: ...]
nore has quit [Ping timeout: 245 seconds]
nore has joined #zig
fireglow has quit [Quit: Gnothi seauton; Veritas vos liberabit]
fireglow has joined #zig
v0idify has quit [Remote host closed the connection]
v0idify has joined #zig
aconbere has joined #zig
gpanders has joined #zig
dyeplexer has joined #zig
cole-h has joined #zig
nvmd has joined #zig
teknico has joined #zig
teknico has quit [Client Quit]
notzmv has quit [Ping timeout: 264 seconds]
marler8997 has joined #zig
v0idify has quit [Remote host closed the connection]
v0idify has joined #zig
yyp has joined #zig
notzmv has joined #zig
yyp has quit [Quit: now it's safe to turn off your computer]
notzmv has quit [Ping timeout: 246 seconds]
yyp has joined #zig
delaney has joined #zig
delaney has quit [Client Quit]
<v0idify> so the only way to make "interfaces" is with function pointers/
<v0idify> ?
<ikskuh> yes, for runtime interfaces
<ikskuh> comptime interfaces can be done with generics (anytype9
<v0idify> thinking about how it would work memory-wise makes it make sense but i have thought about it with languages that hide those details for too long :)
<ikskuh> this is a userland implementation made by me as a concept
Akuli has joined #zig
dyeplexer has quit [Remote host closed the connection]
<txdv> ikskuh: did you just implement interfaces with the languages itself?
<ikskuh> yep
<ikskuh> welcome to zig! where we implement language features at comptime
<yyp> ^
* g-w1_ thinks of lisp
g-w1_ is now known as g-w1
<ikskuh> lisp at comptime? why not :D
<yyp> lisp interpreter at comptime :p
<ikskuh> well, i made a small comptime forth that can do peer type resolution :D
<g-w1> i was thinking of how lisp also advertizes stuff like classes implemented in macros
<yyp> In Zig we just s/macros/comptime and do the same thing
<ikskuh> *rofl*
jmiven has quit [Quit: reboot]
<companion_cube> lisp has comptime, it just doesn't really have types
jmiven has joined #zig
<yyp> Lisp doesn't have types?
<ifreund> janet even has a comptime keyword
<ifreund> or macro, sorry
<yyp> janet?
<companion_cube> yyp: well, not static types anyway
<companion_cube> lisp macros are just comptime stuff
<companion_cube> but they work on `AST -> AST`, rather than partial evaluation
<yyp> ifreund: thanks!
<ifreund> companion_cube: I'm no expert on lisps, but janet at least does let you evaluate things at compile time
<yyp> AST -> AST feels like what Rust macros allow
<companion_cube> ifreund: all of them always did, yes
<ifreund> rust doesn't have quoting
<companion_cube> that's what macros are about
<yyp> What quoting?
<companion_cube> ifreund: rust procedural macros take the AST, so why would they need quoting
<yyp> ^
<ifreund> which means you need to learn a separate macro language, unlike with lisp
<companion_cube> sure, it's a lot more work to write these, yes
<txdv> wait, is zig the next lisp?
<companion_cube> if that means zig gets the lisp curse, hopefully not
<ifreund> zig's not a lisp, but some of its features correlate loosly to some nice things about lisps
<txdv> if you allow people to do something in the language, they will do it
<companion_cube> I think D's comptime is a lot closer to zig's
<yyp> ifreund: yep, having to learn another language for macros is quite annoying
<txdv> its a law, if it is expressible, they will do it
notzmv has joined #zig
<ifreund> companion_cube: probably, but D looks way too kitchen sink for me to invest any more time looking at it
sawzall has quit [Read error: Connection reset by peer]
<yyp> Checked some D examples, it has exceptions, not interested
<ifreund> and GC
<yyp> even worse
<ifreund> and I think a borrow checker too now?
<ifreund> and C++ ABI compat of some kind
<companion_cube> it was designed as a C++ replacement, so yeah, it's big
<yyp> C++ replacement doesn't need to have exceptions and GC
sawzall has joined #zig
<yyp> ¯\_(ツ)_/¯
<companion_cube> it's from the late 90s/early 00s, exceptions were the least of evils
<ifreund> zig is a fantastic C++ replacement because it makes different design descisions instead of repeating the same mistakes
<companion_cube> the GC is because it helps with memory safety
<ifreund> Rust is also quite a good C++ replacement in some cases
<companion_cube> ifreund: I'm not sure zig is a good C++ replacement
<companion_cube> if C++ programmers can dismiss it with "there's no RAII"
<companion_cube> the same way Go was suppoesd to be a C++ replacement and was laughed out of the room
<companion_cube> (with reason, tbh)
<yyp> Go was supposed to be a C replacement
<ifreund> not seriously, it has a GC
<companion_cube> oh actually at the beginning they thought it'd attract the C++ crowd
<companion_cube> you have talks where they say that
<yyp> Blame Plan9 guys then
<companion_cube> showing they didn't get what people use C++ for
<aconbere> I just see Go as the C author's mulligan
<aconbere> do overs!
<aconbere> Like regardless of who they thought it would attact and what languages they thought it might replace. It just feels like ... they wrote it.
<ifreund> companion_cube: compared to Go, Zig is a far better C++ replacement, having super powerful/flexible generics that can replace all that template metaprogramming as well as no runtime or GC overhead
<ifreund> infact, I'm going to predict that C++ gets types as first class values in constexpr scopes sometime in the next 20 years
<companion_cube> ifreund: I'd say it's halfway there
<ifreund> indeed, though not 100%
<companion_cube> no RAII will rebuke most C++ programmers
<ifreund> oh you're talking about the first thing I said
notzmv has quit [Ping timeout: 276 seconds]
<yyp> RAII seems like a bad idea anyway
<companion_cube> seems like a good idea to me, it's even one of the few things rust salvaged from C++
<TheLemonMan> lol
<aconbere> Today seems to be the day in which I conqure Readers / Generics
<aconbere> Wish me luck
Akuli has quit [*.net *.split]
<txdv> isn't defer the equivalent of raii?
<companion_cube> no
<companion_cube> defer doesn't compose with generics in the same way
<txdv> can you give me an example why not
<ifreund> no, and thank god it isn't
<companion_cube> let's say you have, in rust, a Vec<Foo> where Foo contains stuff with destructors (like a hashmap, a socket, etc.)
<ifreund> raii needs move semantics and a whole bunch of other complexity
<companion_cube> `Vec.clear the_vec` will automatically clear resources
sawzall has quit [Read error: Connection reset by peer]
<companion_cube> defer is more explicit but only for scope allocated resources
<companion_cube> ifreund: yeah, and RAII typically needs some sort of specialization for the (fast) case where there's no destructors
<companion_cube> it can be done by hand of course, but the "clear a vector of Copy types" needs some kind of optimization to recognize it has nothing to do
sawzall has joined #zig
<yyp> Maybe RAII is not actually that bad and I misunderstood what it does, but still I think that Zig does better since everything is explicit instead of hiding a free() with ~Object
<yyp> Just that acronym is confusing
<companion_cube> yyp: imho the value of RAII is that it composes well. Doing stuff manually means you need to pass `free` as parameters in many cases
<earnestly> TheLemonMan: Have you rewritten lemonbar in zig yet? :p
<companion_cube> (or do something else, but anyway)
<earnestly> raii(composes(well)));
<TheLemonMan> earnestly, it's pretty far in the todo list heh
<yyp> companion_cube: no, at least not with Zig since allocated objects store an allocator within themselves and then you can just defer thing.deinit(); or something
<earnestly> It's the first thing I remember you making
<TheLemonMan> my very first linux program!
<TheLemonMan> everything went downhill from there on
<yyp> Now I want to make Wayland version of lemonbar..
Akuli has joined #zig
<TheLemonMan> oh, I also contributed to companion_cube ocaml-containers
<TheLemonMan> damn, the GH repo list is a trip down memory lane
notzmv has joined #zig
<txdv> companion_cube: can you show off the composition of raii in an example in your favorite language?
waleee-cl has joined #zig
<companion_cube> yyp: yeah if you allocate everything in allocator it's a different story
<companion_cube> it does indeed require move semantics to work cleanly
<companion_cube> you can also have interesting examples with Arc<T>, locks, etc. (refcounting is an area where it's also super useful)
daeluk has joined #zig
<txdv> How would you implement this in zig (without the raii aspect)?
<companion_cube> nested std.ArrayList I guess, but you need to defer either the destruction of v2, or to clear v's elements before destroying it
<companion_cube> of course you can also shove everything into a local allocator :p
<ifreund> do you mean a local arena?
<ifreund> that's not great with the way growable arrays allocate
<ifreund> to do this in Zig, I'd use ArrayListUnmanaged for the nested elements
<ifreund> the deinit is just 2 lines: for (foo.items) |child_list| child.list.deinit(); foo.deinit();
<mikdusan> andrewrk: can you eyeball #8265. I'd like to get this in, then adopt the same approach for llvm12 branch macos-arm64, and shift llvm12 macos-x86_64 to build x86_64 host using a xcode-based bootstrap tarball
<txdv> I think that zig wants to tell you that there is a lot more going on, that there is something allocating memory
<mikdusan> this way we're ready for llvm12. and if/when zig-bootstrap can build artifact, then we can switch. but I'd like a working thing now
<companion_cube> txdv: yes, zig is more explicit, we all agree
<txdv> { let v2 = vec![1,2,3]; v.push(v2) } // this is just v2 = [1,2,3,4]// and since nobody uses this is optimized away
<mikdusan> also what happens if llvm12 continuous integration succeeds? I don't see any logic to prevent tarball posting if branch != master
<txdv> Most of the languages just overdo it with the "I will do this without you knowing it", zig tries to show it in the language what is happening
<mikdusan> ^^ scratch my last comment. I see condition now in pipelines.yml
<companion_cube> txdv: I mean, in rust, you know it; but it's automatic like stack allocation or other things
drakonis has quit [Quit: ZNC 1.8.2 -]
<txdv> can you show me an exampe in rust where rust invokes an external library(written and c) and then uses raii to cleanup?
<txdv> This where where zig shines
drakonis has joined #zig
<TheLemonMan> just wrap the C object in a new type and implement the drop trait for that
<TheLemonMan> you can't forget a drop but you can forget a defer
<yyp> Since zig has translate-c, maybe it would have something like translate-h which takes a header file and generates externs for it
<g-w1> thats what translate-c does
<yyp> It tries to translate actual C code
<g-w1> headers are actual c code; thats exactly how cimport works
<yyp> And sometimes throws @compileError("unable to translate function") for non-trivial functions
<yyp> I want to know the types that C function takes and translate-c fails on my function of interest
<yyp> s/types/types of parameters
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<companion_cube> txdv: looking for an old blog post -_-
<companion_cube> C bindings are clearly not as easy in rust, but you can still wrap stuff easily
<companion_cube> like TheLemonMan said
<yyp> are they?
<yyp> ah, nevermind, translate-c works with header files too
<andrewrk> yyp, that's the main use case :)
<ifreund> nice rust bindings for libwayland have proved very hard, and rust bindings for wlroots have been abandoned after over a year of work
<ifreund> it's not always easy
<yyp> Now another problem, C function accepts [*c][*c]u8, how can I convert a normal array like [_][]u8{ "hello" } to that?
<ifreund> yyp: does C want one or both of those pointers to be null terminated?
<yyp> I guess only the second one, but [*c][*c]const u8 is what translate-c gives
<ifreund> indeed, translate-c is only aware of what is encoded in C's type system which is not much
<ifreund> you need to read the documentation of the C library or the code to know what it expects for sure
<yyp> This is what I found in the header file: const char *names[1]
<ifreund> &[_][*:0]const u8{"hello"} should work
<yyp> sentinel-terminated pointers possible with C calling convention? [*c:0] didn't work
<yyp> Are *
<g-w1> yes they are
<yyp> What's the syntax then?
<yyp> Or maybe it doesn't change, nevermind
<yyp> ifreund: &[_][*:0]const u8{"stuff"} didn't work, expected type '[*c][*:0]const u8', found '*const [1][*:0]const u8'
<ifreund> ah yeah, it has to be mutable
<yyp> If you remove the &, Zig couldn't find array type
<ifreund> so make a var foo = [_][*:0]const u8{"hello"}; and pass a pointer to that
<yyp> It finally compiled! Thank you, ifreund!
<ifreund> yyp: all pointers types have the same ABI and may be arguments of callconv(.C) functions
<ifreund> [*c] should never be used outside of *autogenerated* Zig code
<yyp> Wait, when all pointer types have the same ABI is there a reason for [*c] to exist?
<yyp> Even in autogenerated code
ur5us has joined #zig
leon-p has quit [Quit: leaving]
<aconbere> `index 0 incorrect. expected { 118, 97, 108, 49 }, found { 118, 97, 108, 49 }`
<aconbere> :thinking:
<aconbere> so those two look the same to me :)
<ifreund> yyp: yes, because translate-c will never be smart enough to map c pointers to zig's more finely grained pointer types
<yyp> aconbere: wait that's illegal
nvmd has quit [Quit: Later nerds.]
<yyp> Maybe that's something weird with the arrays themselves
<ifreund> aconbere: would need to see code to spot the bug :P
v0idify has quit [Remote host closed the connection]
v0idify has joined #zig
sundbp has quit [Ping timeout: 264 seconds]
<aconbere> okay... I'm embarassed to post this but here it goes
<aconbere> ifreund: ^
TheLemonMan has joined #zig
<TheLemonMan> aconbere, you are comparing the slices .ptr and .len contents
<TheLemonMan> in other words expectEqualSlices is shallow
yyp has quit [Quit: now it's safe to turn off your computer]
bitmapper has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<aconbere> hmm once again I feel myself bumping up against my understanding of zig's type system and memory :-/
<aconbere> If I just pop out of my arraylist testing.expectEqual(l.pop(), "val1");
<aconbere> I get expected slice ptr u8@7f09512ef00c, found u8@204a92
<aconbere> oh, I should be using expectEqualSlice
<aconbere> since these are also slices :P
<aconbere> All i have left now is a memory leak hahaha
<aconbere> I /think/ what's happening is I'm dupe'ing a slice to act as a key to a hashmap
<aconbere> and that it's not getting free'd
<aconbere> mpf
<aconbere> okay I have to stop staring at this lol
<ifreund> aconbere: I'm here now, are you still on the same issue/is that code link still current?
<aconbere> ifreund: let me push up the latest changes
<aconbere> cool
<aconbere> from the latest commit if you run `zig test src/mime.zig`
<aconbere> you'll see a bunch of memory leaks :)
<aconbere> and I'm pretty confident about why
<aconbere> In this section my intent is to grab some data out of my buffer, and use them as keys and values in a hash map
<aconbere> If I naivly pass the slice to the hashmap the underlying bytes change that's no good
<aconbere> so I reached for dupe
<aconbere> now I'm responsible for free'ing that allocated memory as I understand it
<aconbere> but when I try to free it in deinit I get segfaults
<aconbere> (so if I wrote there it segfaults)
<aconbere> Per usual, I assume my understanding of zig is just... too limited
<ifreund> aconbere: you are allocating a new key even when the key already exists in the hash map
<ifreund> I'd recommend using getOrPut here and only allocating the key if an existing entry is not found
<aconbere> ahhhhhh
<aconbere> interesting!
<ifreund> example here actually:
<ifreund> and fwiw your understanding of Zig seems to be fine at this point, it's just maunal memory management you need to get used to :P
Akuli has quit [Quit: Leaving]
<ifreund> by the way, have you seen ?
<aconbere> Wild, I was wondering why some of the functions on HashMap existed and it makes more sense now
<aconbere> :)
<aconbere> But those things wont help me learn how to write simple parsers in zig
<ifreund> getOrPut() is also more efficient as you only hash the key once
<ifreund> aconbere: oh I'm not saying you shouldn't write your own, just giving examples of how others have solved similar issues :D
<aconbere> ah! I hadn't yet
<aconbere> "All 3 tests passed."
<aconbere> cool, that was a good lesson, thanks
<ifreund> no problem!
notzmv has quit [Ping timeout: 244 seconds]
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
<aconbere> I totally had my rust hat on writing that
<aconbere> This was a new way of thinking about it that I had to adjust to
notzmv has joined #zig
<aconbere> Which concisely I guess was me expecting the compiler to deal with cleaning up my unneeded allocation for me or wisely copy
<aconbere> fun
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
ur5us has quit [Ping timeout: 264 seconds]
mokafolio has quit [Quit: Bye Bye!]
jsb has quit [Quit: .]
jsb has joined #zig
daeluk has left #zig [#zig]
mokafolio has joined #zig
ur5us has joined #zig
mokafolio has quit [Client Quit]