00:07 <ShrewdSpirit> Hello. So tonight I found zig from godbolt.org languages and it tingled my curiosity to dig for it. I'm sure it'll be my new beloved language after Go!

00:08 <ShrewdSpirit> I'm going to try clashos on my rpi and see how it works since I always wanted to make a custom OS for it

00:19 <daurnimator> zachcarter: a webview is not really what I'm interested in

00:30 <ShrewdSpirit> Do you guys have any idea why I get "/usr/bin/ld: cannot find -lclangFrontend" and other clang libraries error? I have full llvm toolchain setup

01:42 <zachcarter> daurnimator: I understand it's not comparable to Qt - but there aren't many options available for cross platform GUI

01:42 <zachcarter> if you don't want to use Electron / Chromium / CEF / Webview

01:42 <zachcarter> I'm not sure what realistic options are outside of GTK / Qt

01:44 <zachcarter> ShrewdSpirit: the linker needs to be able to find them - you need to ensure they're in a path the linker is searching in

01:49 <daurnimator> zachcarter: IUP

01:49 <daurnimator> libui has lost it's progress :(

01:50 <zachcarter> daurnimator: thank you for sharing - I was aware of libui but not IUP

01:51 <daurnimator> wxwidgets lives on of course

01:53 <zachcarter> yeah - but C++ :/

01:54 <zachcarter> and I'm not a huge fan overall

01:54 <daurnimator> IUP is frustrating

01:54 <daurnimator> but often easier to use than GTK

01:55 <zachcarter> you might enjoy this article daurnimator: http://blog.johnnovak.net/2016/05/29/cross-platform-gui-trainwreck-2016-edition/

02:05 <daurnimator> zachcarter: I prefer to use the native widgets where possible. Doing otherwise tends to destroy accessibility

02:06 <zachcarter> agreed

02:20 <knebulae> andrewrk, sorry for the long delay, but info regarding the subsystem can be found here: https://docs.microsoft.com/en-us/cpp/build/reference/subsystem-specify-subsystem?view=vs-2017 (these are of type EFI_APPLICATION). GCC also has a UEFI toolkit that produces these types of binaries (WinPE-64 using the ms_abi calling convention). The entry point is UefiMain (so as long as this is visible as a C function, everything should "just work."

02:23 <daurnimator> knebulae: what was the subsystem question?

02:25 <knebulae> daurnimator: "Are there any suggestions for guidance on producing a UEFI application executable, linked with msvc .lib files (EDK-II)?"

02:25 <knebulae> daurnimator: "By way of background, these executables are just Win64-PE files with a different subsystem linked against the UEFI libraries rather than MSVCRT."

12:14 <ShrewdSpirit> Which editor do you guys use for zig?

12:15 <lorenzzzo> lol i just realized that i dont use syntax highlighting

12:16 <knebulae> ShrewdSpirit: Using VSCode with Marc Tiehuis' excellent Zig plugin.

12:17 <ShrewdSpirit> knebulae: Perfect! Thanks

12:18 <ShrewdSpirit> Also does zig support avr (more precisely arduino)?

12:20 <knebulae> ShrewdSpirit: Yes, zig supports all targets llvm supports (although the stdlib only has implementations for Linux (maybe the *BSDs)/MacOS/Windows). "zig targets" will list the supported target triples.

12:20 <ShrewdSpirit> Cool

13:19 <knebulae> anyone have any good examples or docs on the Builder object?

14:04 <euantor> > maybe the *BSDs

14:05 <euantor> FreeBSD support is a work in progress, but there's no current support for other BSD variants as far as I'm aware

14:11 <euantor> https://github.com/ziglang/zig/tree/freebsd2

14:26 <andrewrk> knebulae, ok, looks like we need to add more CLI flags and pass them to the linker to expose this subsystem option

14:27 <andrewrk> ShrewdSpirit, AVR isn't supported yet

14:28 <andrewrk> have a look at this table: https://github.com/ziglang/zig/#supported-targets

14:28 <andrewrk> I should remove some of the ones from `zig targets` because although llvm advertises a backend for more targets than these, when you go to actually use them you get the error message "unable to create target based on: avr-unknown-unknown-unknown"

14:42 <ShrewdSpirit> andrewrk: Oh I see. Thanks

14:44 <unique_id> cross compiling to windows and running through wine because I'm too lazy to boot up windows. The future is here!

14:44 <andrewrk> :)

14:44 <unique_id> (to test windows version)

14:44 <andrewrk> wine is an incredible project

14:45 <unique_id> yeah

14:45 <andrewrk> sometimes I read wine source code to clarify MSDN documentation

14:45 <andrewrk> then test on actual windows, and, sure enough, they got it right

14:49 <knebulae> andrewrk: I was looking at the Zig source, and am a bit torn on the least painful way to implement these linker flags. UEFI shares almost everything in common with the OsWindows target (and the MSVC linker layout), but it also has two modes of its own, EFI_APPLICATION and EFI_DRIVER, which have different entrypoints. So the question is whether to implement an OsUefi type with its own suboptions, largely duplicating (and/or piggybacking where possible) on

14:49 <knebulae> the OsWindows target code, or implementing the two UEFI subsystems as say a -m option (thus expanding the compilation struct size, and at first glance I have no idea the side-effects here) as an additional Windows subsystem.

14:50 <andrewrk> knebulae, ah, you must be looking at the self-hosted code. I wouldn't worry about that quite yet. you're about 2 minor versions ahead of that being the thing we ship

14:50 <andrewrk> but I think your comments apply to the stage1 compiler as well

14:51 <knebulae> I found relevant code in both source dirs

14:51 <andrewrk> let's start with "what should the UI be from the user's perspective" and then work from there

14:53 <andrewrk> so it's either add `-mefi_application` and `-mefi_driver` or introduce `--windows-subsystem [arg]` and remove the current -m options

14:54 <andrewrk> oh I see your point about the windows target now

14:54 <andrewrk> ok, so here's what the windows target means: it means you are building an executable where the assumption is that you have a running windows operating system that you can interact with

14:54 <andrewrk> this is not true for an UEFI application, so the OS is not windows

14:54 <andrewrk> I think that's a pretty clear case

14:55 <andrewrk> we already have a non 1:1 mapping with Zig OS to LLVM OS so it won't be hard to add uefi as another os type

14:58 <knebulae> So, OsUefi as an ostype and -mefi_driver, -mefi_application to differentiate?

14:59 <knebulae> As long as changing the configuration struct to account for the additional two flags will not have adverse side effects elsewhere.

15:00 <andrewrk> knebulae, that sounds good to me. for bonus points you can change all the subsystem flags to be an enum instead of bools, and have the cli parsing code emit an error when more than one is specified

15:01 <knebulae> Damn, I haven't even had my cornflakes yet.

15:01 <andrewrk> haha

15:01 <andrewrk> that CodeGen struct is created once per compilation (1 per invocation of zig binary) so the fields may as well be global variables as far as memory use is concerned

15:05 <knebulae> gotcha

15:06 <andrewrk> is that correct that only 1 subsystem can be selected at a time?

15:07 <knebulae> yes

16:56 <oconnor0> What is the status on network programming?

16:58 <MajorLag> andrewrk: `fn interface(self: *Impl) Interface.Implement(@typeOf(self)) {` => 'error: use of undeclared identifier 'self''. That's a new one to me. If I use the type without the @typeOf I get a false 'depends on itself' error, related to #1832? using `self: var` and @typeOf(self) makes it function as expected. I guess the way parameters and return types can reference a previous parameter only works if that paramete

16:59 <MajorLag> oconnor0: IIRC it mostly doesn't exist yet. There's a big async change coming and I think we're waiting on that.

16:59 <MajorLag> You can call native APIs, but there's not stdlib implementation.

17:01 <oconnor0> MajorLag: thanks. do you know the ETA of the async change?

17:06 <andrewrk> oconnor0, it's (1) copy elision (2) async change (3) then networking should be nice

17:06 <andrewrk> hoping to have 1-3 done by next release (0.4.0)

17:06 <andrewrk> estimated release date: march 15 2019. it's dependent on llvm 8's release date

17:07 <andrewrk> oh, llvm just published that 8 comes out on Feb 27, but they'll probably be 1 week late, and then zig releases 1 week after that. so I stand by my estimate :)

17:14 <oconnor0> andrewk, awesome, thanks.

17:19 <mgxm> is anyone working on freebsd support to libc?

17:20 <andrewrk> mgxm, are you talking about https://github.com/tiehuis/zligc? or are you talking about zig's standard library interface to make freebsd syscalls?

17:20 <mgxm> about the syscalls

17:21 <andrewrk> I'm not aware of any efforts of this currently

17:21 <andrewrk> if you're going to try to do it, you could follow the patterns for macosx in the standard library

17:22 <andrewrk> most of the libc functions should be in std/c/index.zig which apply to any OS. however there may be some freebsd specific things, and you can look at the example set by std/c/darwin.zig

17:27 <mgxm> so, should I replace all the functions that use syscall to use the c interface?

17:30 <MajorLag> FreeBSD doesn't officially have a stable ABI, right? So probably.

17:31 <Hejsil> MajorLag, https://github.com/ziglang/zig/issues/1209#issuecomment-403218763

17:33 <MajorLag> Fiar enough, I was only even trying it to workaround the false ''depends on itself'

17:36 <andrewrk> mgxm, yes

17:37 <andrewrk> someone from the freebsd team stopped by and clarified that point

18:49 <ShrewdSpirit> Is zig fully self hosted now?

18:49 <andrewrk> ShrewdSpirit, no, some big changes are needed first

18:49 <ShrewdSpirit> Since the compilation stages confused me

18:53 <j`ey> stage1 is C++

19:13 <knebulae> andrewrk: a wrinkle, now that I've done my homework. LLVM treats the target triple for UEFI subsystems as x86_64-pc-win32-coff. Given the current state of the code, I'm inclined to think that rather than creating a new os type for UEFI, extending Windows would be the best bet, and it would prevent having to mess with any of the code that interfaces with LLVM and deals with target triples. Thoughts?

19:14 <andrewrk> knebulae, I understand that to LLVM the target triple is windows - this has to do with calling conventions and mangling and such. but the windows target to Zig means much more, and I'm still confident that UEFI in zig should be represented as a different operating system

19:15 <andrewrk> the LLVM/target triple code is simple, I don't foresee that being a problem

19:15 <knebulae> Ok. Fair enough.

19:15 <andrewrk> as an example, in zig you should be able to do this: if (builtin.os == builtin.Os.windows) { std.os.windows.RtlGenRandom(...); }

19:16 <andrewrk> e.g. it's a valid assumption that if the target OS is windows, you can call the RtlGenRandom DLL function

19:16 <andrewrk> however this is not true for the UEFI target

19:16 <andrewrk> does that make sense?

19:16 <knebulae> Understood

19:17 <knebulae> Absolutely. Stupid question -- where are the builtins defined?

19:17 <andrewrk> they are generated by the compiler. you can see them with `zig builtin`

19:18 <andrewrk> https://github.com/ziglang/zig/blob/f75262b79f0656ebfac7fb5bd2d6d8e8cce01258/src/codegen.cpp#L6807

20:01 <MajorLag> Hejsil, after playing around with a few other ways it could be done, I haven't come up with a better approach to interfaces than yours. Seems you've thought it through pretty well.

22:13 <andrewrk> oh boy, I think I may have solved copy elision for @sliceToBytes. that was a tricky one

22:13 <andrewrk> the parameter expression writes directly to the return value

22:14 <andrewrk> or, "refers directly" rather than "writes"

23:32 <daurnimator> "a running windows operating system that you can interact with" <-- could you define this?

23:33 <daurnimator> andrewrk: would "a running nt kernel" be a suitable definition?

23:33 <daurnimator> or do you really mean "win32 is available"

23:34 <andrewrk> I would define it as all of the public API of kernel32.dll being available, and correct, to interface with

23:35 <daurnimator> andrewrk: oh... so somewhere in between nt and win32? that's sorta awkward >.<

23:35 <andrewrk> was that a trick question? sounds like there's something you're implying

23:36 <daurnimator> andrewrk: most windows applications as microsoft make them is a stack of: nt kernel | NTDLL.DLL | kernel32.dll | user32.dll

23:37 <daurnimator> you can create programs that use any number of pieces starting from the left

23:38 <andrewrk> right. so far zig std lib for windows depends on the first 3

23:38 <andrewrk> and I don't think you can depend on any of those for UEFI applications

23:38 <daurnimator> it's *very* hard to avoid bringing in user32.dll

23:38 <daurnimator> (though not impossible)

23:39 <andrewrk> we've avoided it so far. what do you think the standard library will need it for?

23:39 <andrewrk> I'm not necessarily against it, I just haven't seen a need for it yet, and the null hypothesis is fewer dependencies

23:39 <daurnimator> andrewrk: on windows if you do certain things, (like create a graphics handle? I can't remember...) then user32.dll gets loaded in and there's nothing you can do to stop it

23:40 <andrewrk> that's fine - I imagine that applications and libraries which want to do that will have a quite reasonable dependency on user32.dll

23:41 <daurnimator> this is notable because as soon as user32.dll gets loaded into your process on windows, you can no longer fork

23:41 <andrewrk> what dll call is that?

23:41 <andrewrk> I don't think we use that in the standard library

23:42 <daurnimator> andrewrk: this is also related to subsystems. usually things that use ntdll.dll directly and not kernel32.dll are called "native subsystem"

23:42 <andrewrk> I'd like to read more about this

23:42 <daurnimator> native subsystem windows programs are much more interesting from a unix POB

23:42 <daurnimator> *POV

23:42 <daurnimator> also for windows early boot you can *only* run native subsystem programs

23:42 <andrewrk> my understanding was that kernel32 is the lowest abstraction level windows offers

23:43 <daurnimator> it's the lowest one they document well :P

23:43 <daurnimator> anything lower and the official line is "hear-be-dragons". but for various reasons they can never change it without breaking ABI for *EVERY WINDOWS PROGRAM EVER*. so it's not going anywhere

23:43 <andrewrk> I still think a UEFI executable makes sense to be a separate target OS from windows though. for example my laptop uses UEFI but boots linux

23:44 <daurnimator> andrewrk: yes UEFI should be a different target

23:44 <andrewrk> well, one of my laptops :)

23:44 <daurnimator> andrewrk: however our definition of "windows" doesn't exactly make sense. I think you need to split it into "nt" and "win32"

23:44 <andrewrk> ahh, this is the crux of your point

23:44 <daurnimator> where win32 is 98% a superset of nt.

23:45 <andrewrk> I think there could be a good case to make for this, and I would like to officially consider it

23:45 <andrewrk> on the issue tracker

23:47 <daurnimator> it also has a different side.... wine emulates win32 well, but less-so nt.

23:47 <daurnimator> whereas reactos emulates nt

23:47 <andrewrk> oh, interesting. I thought those were mostly the same codebase

23:48 <daurnimator> reactos is a reimplementation of the nt kernel

23:48 <daurnimator> (and low level dlls)

23:49 <daurnimator> wine is more rewriting kernel32.dll calls to be linux syscalls along with managing lots of misc state.

23:49 <daurnimator> though wine implements *some* ntdll functionality. as there are parts of windows where developers regularly drop down a level

23:57 <daurnimator> andrewrk: will create an issue now I guess

23:58 <andrewrk> daurnimator, thanks, I appreciate it

23:58 <andrewrk> it's good to have someone around who is intimate with windows

23:59 <andrewrk> if you write up the issue, it will help to understand some example use cases where someone would care whether they were targeting one, or the other. in other words, why should we make the user have to care about the difference?

23:59 <andrewrk> it sounds like there are some good answers to this, which would be useful in the issue