00:05 <daurnimator> andrewrk: hey just watching your video (via HN)

00:05 <daurnimator> andrewrk: should mention Lua as a lang that you can suprisingly write "perfect code"

00:09 <daurnimator> andrewrk: also I didn't get my reply in scrollback overnight :)

01:27 <hryx> daurnimator: I must agree about the Lua comment :>

01:30 <hryx> I'd love some feedback from people here on a proposal. I don't want to put this up on GitHub if it's a dupe, or captured better somewhere else. Or if it contains lies/errors.

01:30 <hryx> https://gist.github.com/hryx/c0644a096974be253c81ecd0cd61a877

01:31 <hryx> Lemme know what you think!

01:31 <hryx> (title is "RFC: Make function definitions expressions")

02:06 <shachaf> Hmm, I started writing about what I want in an error-handling system a little while ago and came up with something pretty close to what Zig has: http://slbkbs.org/tmp/5-error-handling.txt

02:07 <shachaf> Actually it looks like Zig has a lot of language features I've been wanting and trying to figure out, like named-break-with-value

02:08 <shachaf> How does the |x| { ... } syntax work? Is it a standalone thing in some way or syntactically a part of for/catch/etc.?

02:14 <hryx> shachaf: That syntax is specific to constructs which a) "unwrap" a value which can be null/error, or b) provide reference during iteration, switch, etc.

02:14 <hryx> far as I know it means nothing on its own

02:16 <shachaf> OK, that's what I figured.

02:19 <hryx> Also shachaf, that's quite a thoughtful braindump on error handling. how do you like Zig's so far?

02:21 <shachaf> I've been wondering about a general meaning for "block argument that can early-exit" that can be worked out at compile-time and isn't macros or something complicated like delimited continuations. But I think having these things be user-defined might be counter to the Zig philosophy.

02:22 <shachaf> I haven't actually used Zig yet, though I heard of it before. I'll have to look at it a bit more, though, it looks like it has some form of a bunch of things I've wanted.

02:49 <hryx> Also shachaf, that's quite a thoughtful braindump on error handling. how do you like Zig's so far?

02:49 <hryx> oops, sorry. Accidentally hit up ._.

02:53 <jfondren> glibc's getrusage() headers are awful: https://gist.github.com/jrfondren/1d98e9dcc056184f1317a1ac47e59673

02:53 <jfondren> all that and it's just an array of ints, really.

03:02 <hryx> jfondren: can you explain the @"" in that link? Are those some kind of anonymous struct members or something?

03:02 <shachaf> A lot of things in glibc seem pretty bad. Some functions are just way worse than the system calls they're wrapping.

03:03 <shachaf> It looks like Zig binaries on Linux aren't dynamically linked at all? How do they handle things like DNS?

03:05 <jfondren> the @"" doesn't compile. So I thought about submitting that as a bug. But the other file there is produced by gcc itself, and it's also completely useless.

03:08 <jfondren> zig produces dynamically-linked binaries with --library c

03:15 <jfondren> DNS: https://gist.github.com/jrfondren/b049085f8c74482b96097f7db16a18eb

03:19 <jfondren> speaking of |x| { error handling }, I just rewrote that gist to use those. that's quite a bit nicer.

03:24 <shachaf> OK, so if you want to use system libraries you have to link libc presumably.

03:24 <shachaf> I guess DNS is less of an issue than things like OpenGL.

03:28 <jfondren> if you want to use system libraries you have to link with them, sure. But there's a lot of functionality in syscalls that zig can invoke directly, and the functionality in the system libraries can be reimplemented without the libraries. For DNS, there's already stuff like FireDNS, libdns, etc., that you might prefer to gethostbyname

03:30 <jfondren> I'd say, --library is an option. (literally.)

03:32 <shachaf> Yes, the system DNS library isn't great anyway, and I guess parsing resolv.conf yourself is the best you can do.

03:34 <shachaf> But if you want e.g. libGL there's not much you can do (?).

03:34 <MajorLag> hryx, overall I think it's a solid proposal. The idea has been brought up a few times but hasn't really been anyone's priority. Personally, I'm in favor of it because it is more consistent with the rest of the language and it means I can stop wrapping comptime-generated functions in structs. Honestly not sure which syntax for `extern` makes more sense.

03:45 <hryx> Thank you MajorLag. If it's a worthwhile consideration I'll post it. I've been looking for some way to contribute to zig with my limited experience -- this is something I'd be down to tackle, though I have no idea how much work is involved yet.

03:47 <hryx> jfondren: Hope you don't mind, I made a revision using `orelse` to reduce the indentation. also removed stdio.h https://gist.github.com/hryx/108570362b9ce9897f54f6e2ee542bb6

03:51 <shachaf> On closures: I recently found out that D supports closures relative to a stack frame, which are only valid inside the scope they're defined in.

03:51 <hryx> shachaf: have you looked at the Tetris proof of concept? (By Andrew, author of zig) It links against GLFW and libpng: https://github.com/andrewrk/tetris

03:53 <shachaf> I'm not sure whether it's a good idea in general but it would work for some of the examples in #1048 with no extra copying.

03:53 <shachaf> Nope, haven't looked.

03:54 <daurnimator> shachaf: I assume by asking about dns you're really asking about nss libs your system may expect?

03:55 <shachaf> daurnimator: Yes.

03:56 <shachaf> Recently I was trying to figure out what the real ABI that you need to/can assume when writing static Linux binaries is.

03:56 <daurnimator> shachaf: I assume the best answer would be the same as it is in musl: the nss shared library mode is a terrible idea: use of the nscd socket is the least-bad way to get it

03:56 <shachaf> The answer is something like, the Linux system call ABI, which is nice, and then a bunch of things like parsing reasonably stable formats like /etc/resolv.conf and /etc/passwd yourself.

03:57 <daurnimator> shachaf: also lots of /proc and /sys....

03:57 <daurnimator> shachaf: and then you have what the system dynamic linker expects/understands

03:57 <shachaf> Right. But at least that's in ther ketnel and it's pretty well-specified.

03:58 <shachaf> And then when you get to things that you just have to dynamically link, like OpenGL, it more or less pulls in the system libc anyway.

03:58 <daurnimator> shachaf: and then you have some other interesting things like set_robust_list, which should only ever be called *once* in a thread. usually glibc is the thing to do it, but if you don't have glibc..... ?

03:59 <shachaf> Well, if you're writing your own runtime presumably you're taking care of that.

04:00 <daurnimator> shachaf: but what about when you then link against something else that expects glibc's management functions for it

04:00 <daurnimator> you end up having to emulate misc glibc apis...

04:00 <shachaf> Right.

04:01 <shachaf> If it's statically linked then at least you know what the surface you have to emulate is.

04:01 <daurnimator> shachaf: if what is statically linked?

04:01 <daurnimator> shachaf: what if you're using zig to create a shared library though

04:01 <shachaf> The something thing you link against.

04:04 <shachaf> It's all just a mess.

04:59 <oats> howdy, I'm getting familiar with some zig by following along with the x86 kernel live-coding video, which I'm finding very fun and informative

05:00 <oats> I've just stumbled across some type thing that I don't understand, what's the difference between a *T pointer and this strange [*]T pointer?

05:06 <MajorLag> *T is a pointer to a single T, [*]T is a pointer to an unknown number of T

05:06 <MajorLag> For instnace, *u8 is a pointer to a single byte. [*]u8 is a pointer to an unknown number of bytes, most likely a null terminated C-string.

05:08 <oats> ah, gotcha

05:08 <oats> Thanks :)

05:10 <oats> Does that mean that stuff like pointer arithmetic isn't available for *T ?

05:11 <MajorLag> Right.

08:46 <raoof> hi and thanks andrew and everybody else for making a cool language. I have a question, I have png file and I wanted to read the file and parse it at compile time, is it possible?

10:06 <hryx> raoof, take a look at @embedFile() - https://ziglang.org/documentation/master/#embedFile

10:06 <daurnimator> hryx: they left

10:11 <hryx> too true

10:13 <daurnimator> hryx: though I think their question is still useful to me

10:13 <daurnimator> ==> Can you e.g. call libpng at compile time?

10:16 <hryx> ooh, that's a good question, I don't know if you can call extern/C functions at compile time

11:17 <raoof> hryx, thanks I'm using @embedFile I meant calling libpng to avoid decoding png at runtime

11:21 <m4r35n357> Can zig parse command line arguments? I couldn't find anything in the documentation section. (I am probably here prematurely, but I have a short c program that I would be interested in converting if that is feasible)

11:23 <m4r35n357> BTW I am motivated to try zig as a replacement for c, with native 128 bit floats. And yes, my problem domain does benefit from the extra precision!

14:45 <MajorLag> You cannot call library functions at compile time. I did write a pure zig png library, but a) it's really sloppy and needs a lot of rework I haven't done yet, and b) it requires an allocator, which currently doesn't work at comptime either. What I've done in one of my demos is have an extra build step to pre-process assets into the memory layout I want, then dump that to a file that is @embedFile'd into the main pr

15:24 <raoof> MajorLag, thanks good to know

18:23 <oats> what's the reason for the change in struct syntax?

18:23 <oats> struct.{ ... }

18:30 <hryx> oats: That was done to resolve a syntactic ambiguity having to do with function return types. There's an issue for it somewhere. But it's probably going to be reverted soon after the problem is solved a different way

18:31 <hryx> ah, here https://github.com/ziglang/zig/issues/760

18:39 <oats> hryx: does this mean that single-expression functions don't need braces?

18:40 <oats> oh wait, never mind

18:40 <oats> I misread the issue

18:40 <oats> I see why this is a problem

18:57 <oats> fwiw, I like Hejsil's solution the best so far

19:03 <hryx> totally, I think that's the one that's gonna happen

19:03 <hryx> here's the work on it https://github.com/ziglang/zig/pull/1685

19:13 <oats> awesome

19:13 <oats> another question, how does one separate code into multiple files?

19:13 <oats> I can't find any documentation on how that works

19:25 <hryx> oats: You always need one root file (e.g. "main.zig") which is the target of `zig build-exe`. That file can include other files with @import("other/file.zig"). Any files in your source tree which don't end up getting imported like this aren't compiled -- this means tests in those files won't get run either

19:26 <oats> hryx: makes sense, thanks :)

19:27 <hryx> I was originally confused by the fact that you have to have exactly one root file (instead of `build [file1] [file2] ...`), but I like it now :>

19:32 <oats> I love compilers that are build systems

19:32 <oats> I've about made enough makefiles

20:29 <oats> what's the difference between a struct field and a plain variable declared in a struct?

20:46 <oats> also, what's zig's polymorphism story? is there one yet?

21:34 <benjikun> does the `@import("std").build.Builder;` stuff work at compile-time

21:34 <MajorLag> oats, a struct field is an instance variable, a variable declared in a struct is just namespaced to that struct type. Zig has polymorphic functions using comptime parameters or the 'var' keyword. For the latter, see "printValue" under Case Study: printf in Zig (https://ziglang.org/documentation/master/#Case-Study-printf-in-Zig).

23:35 <shachaf> hryx: I get a syntax error building build.zig for that tetris repository -- has the syntax changed or something?

23:42 <shachaf> Oh, it works with 0.3.0 but not 0.3.0+ef5d7ce4