ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
darithorn has quit [Quit: Konversation terminated!]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
renatorabelo has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
renatorabelo has quit [Read error: Connection reset by peer]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
renatorabelo has joined #zig
<renatorabelo> c/lear
renatorabelo has quit [Ping timeout: 252 seconds]
very-mediocre has joined #zig
wilsonk has quit [Read error: No route to host]
wilsonk has joined #zig
davr0s has joined #zig
<very-mediocre> this is awesome:
davr0s has quit [Read error: Connection reset by peer]
accessays has joined #zig
accessays has quit [Quit: Leaving]
porky11 has joined #zig
davr0s has joined #zig
wink_ has quit [Quit: - A hand crafted IRC client]
wink_ has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
return0e has quit []
davr0s has joined #zig
return0e has joined #zig
<scientes> very-mediocre, it could be better
<andrewrk> 0.3.0 is released
<scientes> WooT! congrats
<andrewrk> I posted the release notes to hacker news. I hope we get to front page :)
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
<very-mediocre> congrats
<very-mediocre> scientes: everything can always be better :)
Ichorio has joined #zig
SimonNa has joined #zig
halosghost has joined #zig
<halosghost> andrewrk: hi
unique_id has joined #zig
<halosghost> andrewrk: you exposed arbitrarily-sized, fixed-width integers in 0.3
<halosghost> andrewrk: I love you
<halosghost> andrewrk: carry on :)
<andrewrk> halosghost, and if you put them in a packed struct, you get a bit field
<halosghost> andrewrk: I love you
<halosghost> you are loved
<halosghost> I cannot describe how much I've wanted that in a programming language for so long
<halosghost> oh man, 0.3's release notes are getting me really excited again
renatorabelo has joined #zig
<halosghost> I should really start getting back into it
<halosghost> has anyone started on a posit implementation yet?
* halosghost goes to look at the issue tracker
<halosghost> looks like not
<halosghost> well then, might be a fun thing to try my hand at
<halosghost> andrewrk: seriously though; you (and the rest of the zig contributors) have done some amazing work
<halosghost> Zig is my best hope at the moment of eventually getting to leave C behind
<andrewrk> what's posit?
<halosghost> andrewrk: posits are a fractional numeric type proposal to replace floating-point arithmetic
<andrewrk> oh interesting, this is the first I've heard of that
<halosghost> really?
<halosghost> oh man
<halosghost> I have some technical talks for you then :)
<halosghost> one sec
<halosghost> I'll start with the most recent (and therefore, most salient one):
<halosghost> this one is a demo of an 8-bit posit implementation in Julia beating a 32-bit float on quality and performance for audio-encoding (along with a lot of the technical details of posit implementations):
<halosghost> and here's the website that tracks the community of crazy evangelicals of posits and the work being done on them:
<halosghost> andrewrk: they descend from unums (which have been around longer, so you may have heard of)
<andrewrk> halosghost, thanks, I'll check this stuff out
<halosghost> finally, a C software implementation of posits to which a bunch of other bindings exist:
<halosghost> andrewrk: any time!
<halosghost> if I can manage to get a few more of my personal projects done, I'd love to start contributing to Zig; and I'm fascinated by posits; so that might be a place I go to start :)
<halosghost> fair warning about SoftPosit: it's All Rights Reserved
<halosghost> so, yeah
<halosghost> oh, no wait; looks like a lot of the files are 3-clause BSD; it just doesn't have a repo-wide license
<andrewrk> btw halosghost you don't have to wait for AUR - the static linux binaries on are 100% static
<andrewrk> I challenge you to find a linux distro on which they don't work out of the box
<halosghost> haha
<halosghost> I don't doubt you (at this point, I think you've earned some benefit of the doubt)
<andrewrk> :)
<halosghost> honestly, I'd be tempted to do that anyway because of the cool self-hosting stuff :)
<halosghost> but, we'll see
<halosghost> I have other things I sadly need to do first
<halosghost> I think I will go ahead and start idling in here more though
<halosghost> I really annot describe how excited I am about where Zig is headed
<halosghost> (which you may have noticed from my post on :P
<MajorLag> zig static worked on a 2.6 kernel last I tired. It's about as universal as things get in linux. Only way I can think of it being more universal is to somehow make it a fat binary with builtin QEMU user-mode emulation so it runs on arbitrary architectures.
<halosghost> including a UEFI header so it can run on absolute bare-metal? :P
<MajorLag> hmm... a simple benchmark I had for some of my code lost 4ns/loop in zig 0.3 release-fast compared to zig 0.2.
<halosghost> lost meaning it's slower or faster?
<andrewrk> MajorLag, that almost certainly has to do with the difference between LLVM 6 and 7
<MajorLag> it's slower, and yeah since LLVM is the one doing the optimization I'm pretty sure it is to blame.
<halosghost> well, that's too bad ):
<andrewrk> there's still stuff zig could be doing to help llvm optimize more
<andrewrk> I'm hoping that exploring pointer aliasing (the disallowing of it by default with safety checks, etc) will yield some good results
<andrewrk> especially if we can ditch Type Based Alias Analysis, and just make it something like You Can Only Alias If You Tell The Compiler About It Based Analysis
<halosghost> afaiu, certainly a more liberal use of restrict pointers helps with performance easily
<MajorLag> Interesting, release-small is actually a bit faster
<halosghost> MajorLag: if I had a nickel for everytime I've seen -Os binaries outperform -O2 binaries, I'd have lots of money
<andrewrk> --release-fast is equivalent to -O3
<andrewrk> this proposal is to address that:
unique_id has quit [Ping timeout: 240 seconds]
<andrewrk> idea being that you choose an overall optimize for - perhaps --release-small, but then at package level, scope level, you can override what to optimize for
<halosghost> mm, that sounds fun
<andrewrk> maybe you want a debug build but your blake2b implementation should just go ahead and be --release-fast
unique_id has joined #zig
<MajorLag> I'm not using any pointers in this code, at least not on purpose. It's possible that passing the struct "by-value" is actually being passed as a pointer, but @sizeOf it is only 4 so I doubt it.
<halosghost> andrewrk: does zig do anything / have anything analogous to intN_fast_t and intN_least_t?
<andrewrk> MajorLag, right now zig does not optimize by passing small structs by value. even a struct with 1 field is passed by reference. however llvm could decide to make it by value
<andrewrk> zig also doesn't re-order struct fields yet. there's a lot we haven't tried to do yet
<MajorLag> ok, but that'd be true of zig 0.2 as well. And since the 0.2 master I'm testing with is only slightly out of date of 0.3 it has to be LLVMs doing.
<andrewrk> halosghost, I investigated intN_fast_t and intN_least_t early on and came up with the conclusion that they're at best worthless, at worst actually accomplish the opposite of intended
<halosghost> haha
<andrewrk> just use the number of bits that you need; zig is allowed to use a larger type if it's faster
<halosghost> any write-up of that? I'd be interested in knowing your thoughts
<halosghost> ahh
<halosghost> fair enough
<andrewrk> even in structs. because zig does not guarantee the size of structs
<halosghost> I suppose with {i,u}N now being a thing, it's certainly less of a useful idea
<MajorLag> and if you need exactly that size, i.e. for structs, that's what `packed` is for.
<halosghost> right
<MajorLag> well, anyway, nothing to do but soldier on. The code in question should be faster anyway.
<andrewrk> the blessing and the curse of llvm is that it's a bit of a black box
unique_id has quit [Remote host closed the connection]
hooo has joined #zig
DutchGh0st has joined #zig
<DutchGh0st> YAAS! :D
<DutchGh0st> good job \o/
halosghost has quit [Ping timeout: 244 seconds]
halosghost has joined #zig
<halosghost> andrewrk: you said that {i,u}Ns get gracefully compiled to bitfields in packed structs; does that include both sub-power-of-two sized ints and super-sized ones?
<halosghost> andrewrk: e.g., does an i129 compile down to something like `struct { int64_t upper, lower, top: 1 }`, and an i7 to `struct { int8_t i: 7 }`?
<halosghost> actually, scrap that
<halosghost> let me ask the real question
<halosghost> mmm
<halosghost> nah, I just need to think about this more before I interrogate you :)
mnoronha has joined #zig
<andrewrk> halosghost, yes
<halosghost> awesome
<andrewrk> yes, that includes both sub-power-of-two sized ints and super-sized ones, (not that you need to think more)
<halosghost> right
<halosghost> well, I'm still on the fence about whether or not it will help me, but it's cool to know :)
* halosghost is trying to figure out a space-efficent implementation of Rationals
hooo has quit [Quit: Page closed]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<MajorLag> andrewrk, I'm considering making a pull request that would alter std in a breaking way. What's the easiest way to run every test in std?
<andrewrk> MajorLag, zig test std/index.zig
<andrewrk> if you just did make install from the build folder: ./zig test ../std/index.zig
<MajorLag> \std\io.zig:619:13: error: unable to find 'io_test.zig'
<andrewrk> yeah - zig doesn't ship with the std lib tests
<andrewrk> you'll have to use the std/ from source
<MajorLag> really? there are tests in std
<andrewrk> yeah but if there's a file that is just tests we don't ship it
<andrewrk> mostly because of a couple compiler_rt tests that are multiple MiBs
<MajorLag> well for the first pass I don't really need that thurogh a test.
<andrewrk> you can also run the zig test suite with -Dskip-release which takes about 5 minutes
<andrewrk> that will run the std lib tests on all targets, even non-native ones
<MajorLag> ok. Also, what's the status of meta.zig? I thought there was a branch for it, but can't find it anywhere.
<MajorLag> nevermind, I just did
davr0s has joined #zig
<andrewrk> I think it is quite bit-rotted at this point
<DutchGh0st> alexnask iss not around anymore ?
mnoronha has quit [Ping timeout: 260 seconds]
jjido has joined #zig
<MajorLag> I can probably fix that as it is tangentially related. How do you feel about including it in std even without replacing the builtins for now?
<halosghost> andrewrk: so, another question on {u,i}N: a u1 can either hold the values 0 or 1; am I correct in thinking that an i1 can only hold the values 0 or -1?
<andrewrk> MajorLag, I would consider that progress
<andrewrk> halosghost, correct
<halosghost> fun
<halosghost> I love how that implies the possibility of a negative bool
<halosghost> e.g., the difference between “oui” and “si” in French
tbodt has joined #zig
<tbodt> is there documentation for the stdlib somewhere?
<tbodt> or is that in the "we'll get to it someday" list
<DutchGh0st> is there a 'comptime if' or 'inline if' thingy?
<andrewrk> tbodt, that's something that is high priority, but I'm insisting on solving it with auto-generated html documentation from the self-hosted compiler
<andrewrk> so it's a big milestone to get there
<halosghost> DutchGh0st: there are comptime expressions
<DutchGh0st> yeah but hold on,
<andrewrk> DutchGh0st, all if and switch expressions are implicitly comptime if the condition/target expression is comptime known
<halosghost> andrewrk: ooh, that's fun
* halosghost didn't know that
<andrewrk> if you want to force an if or switch to be comptime you can do so simply by putting `comptime` before the condition/target expression, and you'll get a compile error if it couldn't be done
<tbodt> why is the compiler being made self-hosting? I read somewhere that it solves actual problems but didn't see what those problems were
<DutchGh0st> while I just created an unsigned integer type, and passed that to 'is_signed()'
<andrewrk> tbodt, here is some info
<andrewrk> the goal is to build the compiler for all targets
<andrewrk> there's also just the features of zig that I want to use, e.g. async/await with a thread pool. C++ doesn't have that
<halosghost> andrewrk: if all the arguments of a function are comptime, that function is purely comptime as well, even if user-defined; yeah?
<andrewrk> halosghost, it won't necessarily be executed at compile-time
<halosghost> mmmm
<halosghost> I suppose it would depend on what's in the function body for if it's even possible to be at comptime
<andrewrk> if it has any parameters or return value types that require comptime, that will force it. e.g. if a parameter has type `type`
<halosghost> mm
<andrewrk> the way you can think about it is, you shouldn't have to care whether something happens at comptime or not. so don't worry about it. if you need something to be at comptime, then you can force it to be so
<halosghost> right
<halosghost> I'm trying to figure out how my idea for a space-efficient Rational implementation might work now that {u,i}N are a thing
<andrewrk> for now you will have to use `if (comptime is_signed(N))`
<DutchGh0st> Ohh
<DutchGh0st> hehehe
<DutchGh0st> there isn't a @isSigned() compiler defined function, is there?
<DutchGh0st> nor a @bitCount()
<halosghost> there's @typeInfo now
<andrewrk> DutchGh0st, int types have a `is_signed` field
<andrewrk> u32.is_signed
<DutchGh0st> yeahh that's what I used for is_signed() and bitcount() :)
<DutchGh0st> Im doing it the good way then I suppose
<andrewrk> yeah. that might get removed since @typeInfo gives you identical info
<DutchGh0st> I like how you get to write your own helper functions for stuff like that, and get to exactly write what you want it to do
<halosghost> @typeInfo(T).Int.is_signed and @typeInfo(T).Int.bits iirc
<halosghost> (not entirely sure)
<DutchGh0st> yeup
<DutchGh0st> and btw, how would you use inline while to unroll a loop, 4 times
<DutchGh0st> but for each of those 4 unrolls, you want to keep track of a variable, and at the end, sum up all the 4 values,
<DutchGh0st> how'd you do that?
<DutchGh0st> so like, loop over [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12], by 4 at a time, then do something like 'var r1 = val1 + 1; var r2 = val2 + 1; var r3 = val3 + 1; var r4 = val4 + 1; result += r1 + r2 + r3 + r4'
<andrewrk> DutchGh0st, sounds like you want
<DutchGh0st> see, I'd like to create d1, d2, d3 and d4, and then say 'result = result +% d1 +% d2 +% d3 +%d4;
<DutchGh0st> instead of 'create d1, add d1 to result', 4 times, I'd like to do this: 'create d1, d2, d3, d4, add d1, d2, d3, and d4 to result'
Hejsil has joined #zig
unique_id has joined #zig
<Hejsil> DutchGh0st, use an array? var d: [N]u8 = undefined; {Do inline while loop}; result = d[0] + d[1] + d[2] + d[3];
<DutchGh0st> I guess
<DutchGh0st> but where do I create the array then?
<Hejsil> Before your loop
<DutchGh0st> the inline loop is an inner loop
<DutchGh0st> so do I create the array outside of all the loops?
<DutchGh0st> or does it not matter
<Hejsil> Doesn't matter
<DutchGh0st> performance wise also not?
<Hejsil> Ye
<DutchGh0st> Im surprised :O
<Hejsil> {var i: usize = 1;} {var j: usize = 2;}. i and j will "probably" share the same stackspace
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Hejsil> Btw, working on a userland "@reify". This is gonna be a fun experiment
<DutchGh0st> what does reify do?
<Hejsil> Creates an `type` from a `TypeInfo` struct
<Hejsil> The reverse of `@typeInfo`
<Hejsil> We can't create TypeId.Enum, .Fn and .ArgTuple, but with some hacks, I think you can generate .Struct and .Union + the rest
<andrewrk> Hejsil, whaaat, how is that possible?
<DutchGh0st> oh so you can like write write a metafunction that defines the typeinfo?
<Hejsil> struct { data: [Size]u8, fn get(comptime field: []const u8) FieldType(field) { <get field from data field> } }
<DutchGh0st> and then boom, create a struct out of it
<andrewrk> aha
<Hejsil> You get the idea
<DutchGh0st> :D
<andrewrk> that's actually not unreasonable. I wouldn't be mad if I had to read that implementation
<Hejsil> Lol
<Hejsil> Is that a case of not having @reify?
<Hejsil> I don't even know what will come from this
<andrewrk> haha
<andrewrk> happy release day Hejsil :)
<andrewrk> thanks for all your contributions
<Hejsil> Wuuuh! 0.3
<andrewrk> and tiehuis too. I know you read the logs
<Hejsil> I've been a little inactive on the code side lately as all my project became blocked by bugs.
<Hejsil> But the bug squash weeks have fixed most of those
<andrewrk> great, let me know if there are some more I can prioritize
<andrewrk> because unless bugs are blocking people I want to get back to breaking things!
<Hejsil> Make sense
<Hejsil> I think I had some problems with the randomize, where some tests fail in any buildmodes but Debug
<Hejsil> I'll look into that at some point
<andrewrk> damn. those are the hardest to debug
<DutchGh0st> o.O
<DutchGh0st> what was the cause?
<DutchGh0st> oh nm
<Hejsil> Idk yet. I guess I could try running the tests again to refresh my memory (maybe it's fix, who knows)
<andrewrk> it's all different stuff. but the main problem is that the symptoms of bugs that affect non-debug builds are often divorced from the causes
<DutchGh0st> does slice have a 'starts_with' function? I know you can write slice[0] == '...', but thats...ugly
<andrewrk> DutchGh0st, std.mem.startsWith(T, big_slice, small_slice)
<Hejsil> I'd assume that, if debug, doesn't runtime assert, then all the release modes really should work too
<Hejsil> Ofc, if you hack hard enough, you could do some stuff
<Hejsil> But for sane code
<andrewrk> Hejsil, that's mostly true. (and we want it to be true as much as possible)
<andrewrk> but there's just some stuff we can't have safety for
<Hejsil> I know
<andrewrk> one big thing that will help that is runtime safety for use of undefined value
<andrewrk> we can't always have it, but there are lots of cases where we can
<DutchGh0st> can small_slice also be just a value rather than a slice?
<andrewrk> DutchGh0st, slice.len != 0 and slice[0] == value
<andrewrk> you are of course welcome to create a helper function for that
<Hejsil> Also, the build system assumes that `args[0]` is always a path to a zig executable, which is annoying
<Hejsil> when build the self-hosted-compiler that is
<andrewrk> hm I thought we passed it as args[1]
<Hejsil> Or, i don't actually know it gets the exe
<Hejsil> But, if I have zig in my path, i can't use it to build zig stage2
<andrewrk> hmmm. I'm not sure if I quite understand what you're trying to do. but, stage2 is not independent from stage1. it links against zig_llvm.a and I think another .a file from stage1
<Hejsil> Yeah, i know
<andrewrk> but anyway the build process for stage2 assumes that you just built stage1
<Hejsil> I can't do <make stage 1> <add stage 1 exe to path> <use the stage 1 exe from the path to build stage 2>
<andrewrk> hm. I thought you could
<Hejsil> Sec, i'll check again
<andrewrk> I just did it
<Hejsil> Or, actually, to add more details
<Hejsil> I have a .bin in my home folder that is in my path
<Hejsil> and i symlinked stage1/bin/zig -> zig1
<Hejsil> And then:
<Hejsil> zig1 build --prefix $(pwd)/build/stage2 install attempt to unwrap error: FileNotFound
<Hejsil> From zig repo root
<andrewrk> let me try
<andrewrk> Hejsil, hm interesting. I think this is simply some code in the tests that is calling std.os.real without taking into account PATH
<andrewrk> test/tests.zig:112
<andrewrk> does libc realpath use PATH?
<andrewrk> nope, looks like it does not
<andrewrk> Hejsil, ok my suggestion is that std/special/build_runner.zig:43, before it initializes Builder, should resolve zig_exe with PATH and potentially call std.os.real
<andrewrk> that will fix it
<andrewrk> or potentially even in src/main.cpp:397, where, you are right, it is using arg0 for zig exe
<andrewrk> ok even better, instead of using arg0 it should use os_self_exe_path
<Hejsil> Also, `error{} == error{}` is `false`. Intended?
DutchGh0st has quit [Quit: - A hand crafted IRC client]
<Hejsil> If it follows the rules of enums, then this makes sense
<Hejsil> But errorsets work like sets (duh), so maybe that should actually evaluate to true
<andrewrk> mmm I think error{} == error{} should probably be true. that asks the question if error{A,B} should equal error{A} || error{B}
<andrewrk> the only complicating factor is that we plan to have doc comments get inherited. should they matter?
<Hejsil> Idk
<Hejsil> I only really need error{a,b} == error{a,b} to be true, because that makes some test code easier
<Hejsil> :)
<andrewrk> that seems like a reasonable thing to expect
<Hejsil> Aka, Reify code
<andrewrk> after this change, `zig build` works in the root dir, with `zig` as a symlink
<Hejsil> Nice
very-mediocre has quit [Ping timeout: 256 seconds]
Ichorio has quit [Ping timeout: 245 seconds]
halosghost has quit [Quit: WeeChat 2.2]
<Hejsil> Well, Reify is on hold, lol
porky11 has quit [Quit: Leaving]
<Hejsil> Hmm, seems like i don't have the "randomizer tests pass in debug but not in release" problem on linux
<Hejsil> But then again, I did only see this problem on windows
hoppetosse has joined #zig
<hoppetosse> Congratulations on 0.3.0!
<andrewrk> thanks hoppetosse
<hoppetosse> I had forgotten how much had changed since 0.2.0, it's great XD
<hoppetosse> I was also very impressed with dbandstra's oxid project, some cool comptime stuff happening
<andrewrk> oh yeah. I need to update my system so that I can play it
<andrewrk> on the weekend I started a pure zig X client
<andrewrk> I think it's doable
<andrewrk> loading opengl/vulkan at runtime is another problem
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
<hoppetosse> I was playing with X11 and XCB earlier in the summer
<hoppetosse> I also basically translated glad.h and I'm loading opengl dynamically
<hoppetosse> It might be in tick/examples already
Hejsil has quit [Ping timeout: 256 seconds]
renatorabelo has quit [Remote host closed the connection]