ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
cgag has joined #zig
<wink_> andrewrk: do you generally use gcc or clang as your build compiler when build llvm?
<andrewrk> wink_, whatever is the default compiler on the system
<wink_> So generally clang on osX and gcc on linux?
<wink_> (I'm on Arch Linux and have both installed but gcc is the default)
cgag has quit [Quit: WeeChat 2.2]
mnoronha has quit [Ping timeout: 260 seconds]
mnoronha has joined #zig
<wilsonk> I built LLVM-7 on Linux (Ubuntu 16.04) with GCC-5.4 and Clang-7 (after bulding clang-7 with GCC-5.4 obviously). Each built without incident for me...just so people know. The final resulting clang-7 buillds llvm/clang/compiler-rt/lld about %14 faster than GCC-5.4! That is pretty significant, I thought. So it takes 6 mins 13 seconds on average to build llvm/clang/compiler-rt/lld now.
cgag has joined #zig
reductum has joined #zig
mnoronha has quit [Ping timeout: 260 seconds]
reductum has quit [Quit: WeeChat 2.2]
<cgag> vimquit
<cgag> hmm, wonder how "vim" got there.
cgag has quit [Quit: WeeChat 2.2]
cgag has joined #zig
cgag has quit [Remote host closed the connection]
cgag has joined #zig
cgag has quit [Remote host closed the connection]
cgag has joined #zig
return0xe has quit [Ping timeout: 240 seconds]
cgag has quit [Client Quit]
return0e has joined #zig
<nornagon> are there any examples of integrating zig's build system with an external build system? I'd like to vendor skia as part of a project, and skia is built with gn. it'd be neat if i could wrap skia's build and have it automatically built as part of the zig build
cgag has joined #zig
cgag has quit [Remote host closed the connection]
kristate has joined #zig
kristate was kicked from #zig by ChanServ [Banned: I would like you to take a break from Zig for a week, and then come back when you're ready to interact in an ho]
<andrewrk> nornagon, you could have the external build system call `zig build-exe ...` or `zig build-lib ...` directly, or if you use the zig build system you coudl use the Command step. Here's an example:
<andrewrk> instead of exe.getOutputPath() you would use the skia build system command
<nornagon> oh hm, i hadn't considered driving zig through an external build system
<nornagon> that makes sense
<andrewrk> if you already have a build system, that probably makes the most sense
<andrewrk> `zig build` can help you avoid yet another dependency if you don't already
<nornagon> is there a way you can specify c include paths with `zig build-exe`?
<andrewrk> yes
<andrewrk> -isystem or -dirafter
<andrewrk> I think we can add -I like C compilers but I haven't yet
<andrewrk> I'm headed to bed. if you have any more questions feel free to leave them for me here and I'll answer in the morning. you can check the logs at your leisure
cgag has joined #zig
very-mediocre has joined #zig
<very-mediocre> Controversial but important thing to consider: andrewrk, be wary of adding a "Code of conduct" to your project
<very-mediocre> once the marxist mob moves in and ousts you, the drama begins
<very-mediocre> and so it starts.
<very-mediocre> Contrary to what they claim, their CoC does not have a monopoly on egalitarian behavior
<very-mediocre> so imho be wary of the pressure to accept it.
<very-mediocre> Just my 2 cents after watching several projects get taken over by the dispensers of false moral outrage.
<very-mediocre> You can be egalitarian, inclusive, whatever, without paying the "protection money" (social credit is the currency they manipulate).
<very-mediocre> The model is akin to buying indulgences, just add this piece of paper and you're suddenly a paragon of virtue. The convenience is part of the scam.
<nornagon> good username
<nornagon> trying to build a glfw example on macOS, and i'm getting this error from lld:
<nornagon> Assertion failed: (dylib.file), function exports, file /Users/nornagon/Source/Reference/zig/deps/lld/lib/ReaderWriter/MachO/File.h, line 365.
<nornagon> I added some logging to File.h, and it looks like the framework that triggers it is CoreGraphics
<nornagon> ah, maybe it's failing to find one of the other frameworks that CoreGraphics refers to
<nornagon> i'll take another look tomorrow
Jenz has joined #zig
<Jenz> Hey, is there no docs for the stdlib?
<Jenz> And I think zig looks very promising :)
<very-mediocre> afaik no docs yet for it and it's still in flux
<very-mediocre> but zig code is pretty clean so it's not very hard to grasp the std code by reading it:
<unique_id> yeah you get used to the stdlib pretty quickly. And you can always search a file for "pub fn" to see all the functions that you can use :)
<unique_id> very-mediocre: About the CoC thing, I agree with you but most people don't see what you see, they're not observant enough. It's best to discuss this in private.
very-mediocre has quit [Ping timeout: 256 seconds]
DutchGh0st has joined #zig
<DutchGh0st> mh, @compileError's should always error with the message, right?
<DutchGh0st> I can see this being debatable for correctness, but it does not give any compile error on windows at least:
very-mediocre has joined #zig
<very-mediocre> unique_id: part of the scam is you're not allowed to call it out. I have said nothing objectionable about anyone, I have not defined classes of people that are better or worse than others. If anything that's their MO.
<very-mediocre> plot twist: I'm not even white.
<very-mediocre> I'm sure it's best to discuss in private lest accusations of racism/whateverism are made, but it's plainly untrue.
<very-mediocre> In the end it's not my project, but I just needed to say this because I do care about it and it's such a shame how politically motivated groups are taking over communities.
<very-mediocre> Anything I write here is intended to provide a data point for andrewrk's perusal, nothing more.
<DutchGh0st> maybe this is a little bit worse:
Jenz has quit [Ping timeout: 256 seconds]
<very-mediocre> I'm unclear about some aspects of how comptime works. In this code:
<very-mediocre> usage, is it necessary to call `comptime range()` or would `range()` suffice for it to run at comptime?
<very-mediocre> e.g. line 25
<DutchGh0st> oh my
<DutchGh0st> if else clauses in the return type to figure out the length of the array, thats cool
<very-mediocre> I was reflexively reaching for the nonexistent ternary operator for those :)
<DutchGh0st> ternary, meh
<DutchGh0st> but I guess the range function is written in such a way that you *can* call it at runtime, but also *can* call it at comptime
<very-mediocre> All the params are comptime though
<very-mediocre> I guess I'm wondering if zig is currently smart enough to know that
<DutchGh0st> then you can't call it with non-comptime variables
<DutchGh0st> try making just a variable, and pass it to the range function, won't work
<very-mediocre> Yes, but if everything about it is comptime-known, then certainly it should always be run at comptime, no?
<very-mediocre> Yes, I'm aware that it's static-only for now, it was an experiment
<DutchGh0st> mhh, comptime param's dont mean the function is comptime
<very-mediocre> that's true, but it's "comptime-pure"
<very-mediocre> so to speak
<very-mediocre> It doesn't touch anything not-comptime
<DutchGh0st> probably still need to write 'comptime range(....)' in order to fully have it comptime evaluated
<very-mediocre> What if I write `inline while`
<very-mediocre> on line 15
<DutchGh0st> mhhh
<very-mediocre> This simple code exposed a lot of flaws in my understanding
<DutchGh0st> if you write inline while, what I think is that line 16 gets unrolled
<very-mediocre> Yes, that makes it static/comptime
<DutchGh0st> e.g, this simple function here: , creates just a bunch of if statements
<very-mediocre> at that point, if I were to call `range()` instead of `comptime range()` what difference would remain?
<DutchGh0st> basically a lookup of 'is the variable less than 10? return 1, less than 100? return 2, less than 1000? return 3 etc etc'
<DutchGh0st> that the input still has to be comptime
<very-mediocre> hmm
<very-mediocre> And another thing I'm exploring here, is whether one can write it in such a way as to benefit from comptime when everything is comptime-known
<DutchGh0st> but why not make everything runtime?
<very-mediocre> but also allow it to run dynamically
<very-mediocre> >but why not make everything runtime? -- because it's a learning project :)
<very-mediocre> also generating huge ranges at runtime can be very slow
<DutchGh0st> wait but you'r making an array also an returning that...
<DutchGh0st> lazy evaluation helps on that point,
<very-mediocre> lazy evaluation amortizes the processor load
<DutchGh0st> comptime lazy evaluation is a thing
<very-mediocre> really?
<very-mediocre> Isn't it equivalent to what this code is doing?
<DutchGh0st> make a struct, that has like a start, a stepsize and a end,
<very-mediocre> Ultimately it's either a precomputed array (comptime) or runtime evaluated.
<DutchGh0st> make something like a 'next' function that returns an optional integer (the type would be ?usize, or ?u32, or whatever you like there),
Jenz has joined #zig
<very-mediocre> I wouldn't call that "comptime lazy evaluation"
<DutchGh0st> you could also make a 'size' function that returns how many elements you expect to come,
<Jenz> Thanks for answer previously very-mediocre
<very-mediocre> np :]
<DutchGh0st> and then call "comptime r = comptime range(...);" "comptime buff: [r.size()] u32 = undefined;", "for(buff) |*elem| { elem.* = catch unreachable }"
<very-mediocre> oh, I see what you mean
<very-mediocre> a non-comptime function, that you later call at comptime
<DutchGh0st> or you could just make a `while( |item| { // do stuff }' inside a comptime block then
<very-mediocre> Sure
<very-mediocre> Your response was very helpful to me actually
<very-mediocre> I've been away from zig a couple of months and I hadn't grasped comptime back then
<very-mediocre> now you've helped me realize that non comptime stuff can be run at comptime
<very-mediocre> (trying to get back into zig)
mixi has joined #zig
<very-mediocre> DutchGh0st: it's coming back to me now, the reason I wrote it as a comptime function is the return type has to be comptime-known
<very-mediocre> otherwise memory would have to be allocated
<Jenz> I love the build system
<Jenz> Though I don't get much of is, as there's no doc haha
<DutchGh0st> thats why I suggested using a lazy sequence
<DutchGh0st> like this:
<very-mediocre> jenz: there are docs, just not stdlib docs:
<Jenz> yeah I know, I was reffering to the build system docs :)
<DutchGh0st> whichs works both at run and compiletime
<very-mediocre> DutchGh0st: that's awesome
<DutchGh0st> and if you wanted to, you could making it more flexible!
<DutchGh0st> if you want your range to be a range of u32, you could do that, hold on
<very-mediocre> yes I can see how to do that :)
<Jenz> Any contributors here?
<Jenz> (To zig)
<very-mediocre> DutchGh0st: hm I think the use case in your pastebin differs from what I had in mind, I was aiming for the Python-esque "looping at runtime through a range"
davr0s has joined #zig
<very-mediocre> where the range itself is static, however
<DutchGh0st> comptime var r = comptime range.init(10, 100, 1000);
<DutchGh0st> then you can just call a runtime .next() I think?
<DutchGh0st> hold on!
<very-mediocre> yes but then .next() generates the values at runtime, which amortizes the cost (so it's not that slow
<very-mediocre> but it's still not as fast as precomputing the entire rangw
<Jenz> No contributors here?
<very-mediocre> jenz: andrewrk is the project owner/maintainer
<DutchGh0st> what do you mean by precomputing?
<very-mediocre> he's probably asleep (US timezone)
<DutchGh0st> create a list?
<very-mediocre> DutchGh0st: I mean the entire array of numbers in the range is static, not generated at runtime
<Jenz> I see, thanks I'll remember that
<very-mediocre> jenz: some other contributors chat here too
<Jenz> Hm, but none seems to be interested atm
<Jenz> (if here)
<very-mediocre> consider time zones :) andrewrk is very active overall
<DutchGh0st> okey, you can very-mediocre
<Jenz> I don't doubt it
<very-mediocre> DutchGh0st: I'm not sure that's equivalent to my `range` function
<DutchGh0st> if Im correct that just expands to "sum += 10; sum += 20; sum += 30" at compiletime, but those statements get runned at runtime
<very-mediocre> the outcome is the same but I think the codegen here might be more verbose
<very-mediocre> Your approach gives us a fully unrolled loop
<very-mediocre> anyway both approaches seem to have pros/cons
<very-mediocre> I was aiming for a breezy, low mental load way of looping through any range that comes to mind, and having the compiler treat the range like an inline defined array
<DutchGh0st> but then you still need to loop over the array
<very-mediocre> Yes, that's fine with me
<DutchGh0st> 2 secs
<very-mediocre> That's the desired use case in fact
qazo has quit [Quit: 345345]
<very-mediocre> yep that works
<very-mediocre> but usability is lower than my approach
<very-mediocre> but mine only works for comptime known ranges.
<DutchGh0st> the last loop is runtime, the loop that fills the array is comptime
<very-mediocre> yes, I understand
<very-mediocre> I'm modeling my approach after other languages that provide ranges natively
<DutchGh0st> you could have a function that takes a range, and returns the buffer
<very-mediocre> DutchGh0st: that's what my function is :)
<DutchGh0st> so you dont have to write the filling loop anymore
<very-mediocre> that's literally what this is in the first place:
<very-mediocre> fun convo btw :)
<very-mediocre> first I thought "my approach sucks" after seeing your solution
<very-mediocre> then I realized there are pros and cons
<DutchGh0st> I guess, but this is about what I know of comptime hahaha
<DutchGh0st> it's difficult to get somethimes, but yeah, its fun to play with!
<DutchGh0st> anyway, gotta go now! goodluck with figuring out what you think solves your problem! :D
<DutchGh0st> byee!
<very-mediocre> bye
<very-mediocre> I don't have a real problem yet, this is just an experiment I wrote a couple months ago for learning comptime, revisited to day as it's my day off :)
DutchGh0st has quit [Quit: - A hand crafted IRC client]
unique_id has quit [Remote host closed the connection]
<very-mediocre> jenz: hang around, I'm sure you will get responses from people involved in zig
<very-mediocre> they are very helpful
<Jenz> Thanks, I will
<very-mediocre> What questions do you have? I might be able to answer some
<Jenz> I didn't have any, I just wanted to tell them thanks, and that they they've done a good job :)
<very-mediocre> DutchGh0st: in case you read chatlogs, look at this:
<very-mediocre> That's what I was aiming for with my `range` implementation
<very-mediocre> jenz: andrewrk often reads the chatlogs
<very-mediocre> zig is indeed awesome :)
<Jenz> Though just now I came across something, what does this syntax do?: `[][]const u8{exe.getOutputPath()}`
<very-mediocre> { } is an array initializer
<Jenz> Then, does this getOutputPath return a two-dimensional array?
<very-mediocre> example: const my_array: []u8 = "A"; is the same as the inline array ([]u8 {'A'})
<very-mediocre> I think so yes.
<Jenz> Ah ok, thanks then it makes sense
<Jenz> `exe` is of whatever type `Builder#addExecutable` returns
<very-mediocre> yes
<very-mediocre> you can see it returns a pointer to a LibExeObjStep
<very-mediocre> and that's defined here:
<Jenz> Yeah, thanks, I'll be back, gtg, class
<very-mediocre> bye.
Jenz has left #zig [#zig]
Hejsil has joined #zig
<Hejsil> very-mediocre, for ranges that go from 0-n, this can be used:
<Hejsil> Not a general purpose range, but it has the nice property of briefness with no runtime storage
<very-mediocre> nice
<very-mediocre> here you're benefiting from `i`
<very-mediocre> I actually don't get the appeal of ranges like:
<very-mediocre> but people seem to really love them, and a lot of languages advertise having ranges like this...
<Hejsil> I very rarely need these kinds of ranges. I only use my "to" function in some test code
<very-mediocre> I suspect they might be popular around data science circles
<very-mediocre> those people tend to use Python, Julia, etc
<very-mediocre> after all this discussion I find my solution not-so-bad after all
<Hejsil> Here is a range :) var i: usize = offset; while (i < end) : (i += step) { }
<very-mediocre> :)
<very-mediocre> This has been a good thought experiment
<very-mediocre> It's got me thinking about a discussion I had with andrewrk a couple of months ago
<very-mediocre> about zig trying to run things at comptime if everything about them is comptime-known
<very-mediocre> then I could change the signature from: pub fn range(comptime inclusive: bool, comptime a: comptime_int, comptime b: comptime_int, comptime step: comptime_int)
<very-mediocre> to use a more generic int (not sure which yet)
<very-mediocre> (perhaps with generics)
<very-mediocre> and it'd work statically and dynamically
noonien has joined #zig
<very-mediocre> Another thing that'd be cool is if `comptime_int` would auto-cast to a runtime int value
<Hejsil> Not sure I understand this one. Doesn't it already do this?
<very-mediocre> Yes and no
<Hejsil> (casting to any i/ux that is)
<very-mediocre> it does infer it for literals I believe
<very-mediocre> let me review this, I forgot what the exact case was where it didn't happen
return0xe has joined #zig
return0e has quit [Ping timeout: 252 seconds]
<very-mediocre> iirc I encountered something like this as well when writing range.zig
<very-mediocre> trying to remember, it's been 2 months S:
DutchGh0st has joined #zig
<Hejsil> Aaah, right
<very-mediocre> iirc (could be way off) the original range function I wrote returned comptime_int
<very-mediocre> and I think that caused errors
<DutchGh0st> very-mediocre: , reading about the ranges in kotlin,
<DutchGh0st> but are they lazily generated? or does it generate a whole array behind the scenes?
<very-mediocre> No idea how it's implemented
<Hejsil> It probably just generates the appropriate loop
<Hejsil> So lazy, i guess
<very-mediocre> lazy but still without the overhead of a stream like .next()
<very-mediocre> (is my best guess)
<Hejsil> Hmmm... Actually, it probalby generates some datastructure that has a next()
<Hejsil> Because they work without loops
<DutchGh0st> I broke the compiler
<DutchGh0st> yay
<very-mediocre> they aren't iterators though afaik
<DutchGh0st> unreachable: C:\projects\zig-d3l86\src\analyze.cpp:is_container:3912
<Hejsil> ^ I've hit is one as well, but was lazy, and didn't wonna try to make a small example
<DutchGh0st> Ill try
<Hejsil> Probably some comptime stuff
<DutchGh0st> I think I know where to look
<DutchGh0st> yeah
<DutchGh0st> just like concatting a comptime undefined with a defined array segfaults
<DutchGh0st> sure, it's probably UB without comptime, still a segfault should not happen o.O
<DutchGh0st> reduces to couple of lines
<DutchGh0st> but I dont get it, why am I able to dereference a @This() ?
<DutchGh0st> its not a ptr
<DutchGh0st> is it>?
<Hejsil> In Zig IR any identifier is a ptr deref, as far as I know
<Hejsil> And sometimes (through bugs) it slips into userland code
<Hejsil> This is probably related to that
<DutchGh0st> small enough? ^^
<DutchGh0st> what is your github, Hejsil?
<Hejsil> Small enough for an issue, yes :)
<Hejsil> Can you guess? :)
<Hejsil> I think this is a bug related to pass by value
<Hejsil> Idk if @This() is required
<Hejsil> Is it?
<DutchGh0st> I dont know
<DutchGh0st> hold on
<DutchGh0st> yea
<DutchGh0st> it is
<Hejsil> Well, idk then
<Hejsil> Probalby some @This() + pass by value interaction
<very-mediocre> what happens if you do `const Self = @This();` in the struct body
<very-mediocre> then use :Self in the signature?
<DutchGh0st> probably wont make a difference
<DutchGh0st> Self would be an alias to @This
<very-mediocre> I'm asking because @This() is context sensitive
<very-mediocre> maybe calling it in a function param is tripping it :)
<DutchGh0st> *@This() <-- ptr to self, *const @This <-- const ptr to self
<DutchGh0st> @This <-- is self
<DutchGh0st> that's how I see it at least?
<very-mediocre> I agree
<very-mediocre> just saying the way it's evaluated is based on context
<very-mediocre> it's definitely a bug
<DutchGh0st> Just like in Rust, `*const @This` would be &self, `*@This()` would be &mut self, and @This would be `self`
<DutchGh0st> actually Hejsil, the function that takes @This() does not have to be compiletime at all
<DutchGh0st> but if the struct is compiletime, you create a const / comptime var , and then at runtime call the function, it still gives that message
<very-mediocre> DutchGh0st: your example doesn't compile for me
<very-mediocre> on the latest master binary
<very-mediocre> `error: attempt to dereference non-pointer type 'S' const crash = self.*.n;`
<DutchGh0st> I just found out yeah
<DutchGh0st> well, in that case its not an issue anymore :)
<DutchGh0st> how do I turn on sigsegv on windows btw?
<DutchGh0st> or something that tells me a programm failed to execute, because currently when something crashes...the programm just hangs for a second, and then stops executing without any message
<DutchGh0st> is this a known issue?
<DutchGh0st> unreachable: /deps/zig/src/analyze.cpp:const_values_equal_ptr:5506
<DutchGh0st> Aborted (core dumped)
very-mediocre has quit [Ping timeout: 256 seconds]
return0e has joined #zig
very-mediocre has joined #zig
mnoronha has joined #zig
very-mediocre has quit [Ping timeout: 256 seconds]
kristate has joined #zig
kristate was kicked from #zig by ChanServ [Banned: I would like you to take a break from Zig for a week, and then come back when you're ready to interact in an ho]
kristate has joined #zig
kristate was kicked from #zig by ChanServ [Banned: I would like you to take a break from Zig for a week, and then come back when you're ready to interact in an ho]
DutchGh0st has quit [Quit: - A hand crafted IRC client]
Avinash has joined #zig
Avinash has quit [Client Quit]
qazo has joined #zig
Avinash has joined #zig
qazo has quit [Ping timeout: 252 seconds]
Hejsil has quit [Quit: Page closed]
Ichorio has joined #zig
Avinash has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
very-mediocre has joined #zig
Avinash has joined #zig
mnoronha has quit [Ping timeout: 250 seconds]
mnoronha has joined #zig
Avinash has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
wilsonk has quit [Read error: Connection reset by peer]
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
qazo has joined #zig
Avinash has joined #zig
Avinash has left #zig [#zig]
wilsonk has joined #zig
<andrewrk> nice, we're at full green CI, 2 days after LLVM 7 release. not bad
<DutchGh0st> good job :D
mnoronha has quit [Ping timeout: 252 seconds]
darithorn has joined #zig
Ichorio has quit [Ping timeout: 245 seconds]
mnoronha has joined #zig
DutchGh0st has joined #zig
darithorn has quit [Quit: WeeChat 2.2]
crimson_penguin has joined #zig
<crimson_penguin> o/
<andrewrk> hi crimson_penguin
kristate has joined #zig
kristate was kicked from #zig by ChanServ [Banned: I would like you to take a break from Zig for a week, and then come back when you're ready to interact in an ho]
<crimson_penguin> hey!
<crimson_penguin> I wasn't on Freenode for a while, because they forced SASL, and I was too lazy to set it up with my ZNC server, but then I spent 5 minutes and did it
<andrewrk> welcome
unique_id has joined #zig
very-mediocre has quit [Ping timeout: 256 seconds]
<MajorLag> there's no existing way to expand varargs right? Like, lets say I have a wrapper type, I can't have its init() take `args:...` and pass that to the init() of the type it wraps?
<DutchGh0st> if that was the case you could make decorator functions as well :)
Jenz has joined #zig
<Jenz> \o
<andrewrk> hi Jenz
* Jenz :D
<andrewrk> MajorLag, I believe var args auto explodes when you pass it to another function
<andrewrk> so you can do that
<Jenz> Thanks so much for zig, I think you've done a fantastic job andrewrk
<andrewrk> that being said I've been putting off bugs surrounding var args since I plan to remove the feature and add tuples instead
<andrewrk> thanks Jenz. what are you working on?
<Jenz> Eh, nothing atm
<Jenz> Im a bit unexperienced in about everything
<Jenz> And trying to make sense of the build system
<andrewrk> of zig build? yeah it's undocumented and at the proof-of-concept stage. rough place to start
<Jenz> I really like it, nice place to start IMO, rough seems to work, given enough work
<Jenz> At least for most cases
<MajorLag> my test suggests that isn't true andrewrk. `error: expected type '*Allocator', found '(args)'`. Not a big deal, I can crack this nut a different way.
<andrewrk> MajorLag, ah my mistake.
<MajorLag> In fact, that wasn't a great way to solve it anyway.
davr0s has quit [Quit: Textual IRC Client:]
DutchGh0st has quit [Quit: - A hand crafted IRC client]
noonien has quit [Quit: Connection closed for inactivity]
davr0s has joined #zig
DutchGh0st has joined #zig
Jenz has quit [Quit: Lost terminal]
DutchGh0st has quit [Quit: - A hand crafted IRC client]
porky11 has joined #zig
Jenz has joined #zig
<Jenz> Anyone knows where I can find precompiled LLVM 7? On x86_64-pc-linux-gnu, Arch if that's relevant
<Jenz> ("Arch" as in the distro, not architecture)
redj has quit [Ping timeout: 252 seconds]
<andrewrk> Jenz, why not use the static zig build from ?
<Jenz> Ah, I guess that's a much better idea indeed, thanks!
<andrewrk> it's updated on successful master branch builds, so you can go back and get newer ones when you want to update
<Jenz> Alright, sounds good
Jenz has quit [Quit: leaving]
Jenz has joined #zig
Jenz has quit [Quit: leaving]
mnoronha has quit [Ping timeout: 240 seconds]
davr0s has quit [Quit: Textual IRC Client:]
porky11 has quit [Remote host closed the connection]
return0xe has quit [Remote host closed the connection]
return0xe has joined #zig
wilsonk has quit [Ping timeout: 252 seconds]