ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
ShrewdSpirit has joined #zig
<ShrewdSpirit> Hello. So tonight I found zig from languages and it tingled my curiosity to dig for it. I'm sure it'll be my new beloved language after Go!
<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
<daurnimator> zachcarter: a webview is not really what I'm interested in
porky11 has quit [Ping timeout: 250 seconds]
<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
reductum has joined #zig
<zachcarter> daurnimator: I understand it's not comparable to Qt - but there aren't many options available for cross platform GUI
<zachcarter> if you don't want to use Electron / Chromium / CEF / Webview
<zachcarter> I'm not sure what realistic options are outside of GTK / Qt
<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
<daurnimator> zachcarter: IUP
<daurnimator> libui has lost it's progress :(
<zachcarter> daurnimator: thank you for sharing - I was aware of libui but not IUP
<daurnimator> wxwidgets lives on of course
<zachcarter> yeah - but C++ :/
<zachcarter> and I'm not a huge fan overall
<daurnimator> IUP is frustrating
<daurnimator> but often easier to use than GTK
<zachcarter> you might enjoy this article daurnimator:
<daurnimator> zachcarter: I prefer to use the native widgets where possible. Doing otherwise tends to destroy accessibility
<zachcarter> agreed
steveno has joined #zig
<knebulae> andrewrk, sorry for the long delay, but info regarding the subsystem can be found here: (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."
<daurnimator> knebulae: what was the subsystem question?
* daurnimator has some amount of knowledge around that from early midipix days....
<knebulae> daurnimator: "Are there any suggestions for guidance on producing a UEFI application executable, linked with msvc .lib files (EDK-II)?"
<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."
steveno has quit [Quit: Leaving]
Ichorio has quit [Ping timeout: 240 seconds]
IntoxicatedHippo has joined #zig
francis36012 has quit [Ping timeout: 244 seconds]
nodist has joined #zig
nodist has quit [Quit: Leaving]
reductum has quit [Quit: WeeChat 2.3]
emekoi has quit [Ping timeout: 250 seconds]
ShrewdSpirit has quit [Ping timeout: 246 seconds]
Thalheim has joined #zig
ShrewdSpirit has joined #zig
<ShrewdSpirit> Which editor do you guys use for zig?
<lorenzzzo> lol i just realized that i dont use syntax highlighting
<knebulae> ShrewdSpirit: Using VSCode with Marc Tiehuis' excellent Zig plugin.
<ShrewdSpirit> knebulae: Perfect! Thanks
<ShrewdSpirit> Also does zig support avr (more precisely arduino)?
<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.
<ShrewdSpirit> Cool
steveno has joined #zig
jjido has joined #zig
<knebulae> anyone have any good examples or docs on the Builder object?
zachcarter has quit [Ping timeout: 240 seconds]
mouldysammich has joined #zig
<euantor> > maybe the *BSDs
<euantor> FreeBSD support is a work in progress, but there's no current support for other BSD variants as far as I'm aware
<andrewrk> knebulae, ok, looks like we need to add more CLI flags and pass them to the linker to expose this subsystem option
<andrewrk> ShrewdSpirit, AVR isn't supported yet
<andrewrk> have a look at this table:
<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"
halosghost has joined #zig
<ShrewdSpirit> andrewrk: Oh I see. Thanks
unique_id has joined #zig
<unique_id> cross compiling to windows and running through wine because I'm too lazy to boot up windows. The future is here!
<andrewrk> :)
<unique_id> (to test windows version)
<andrewrk> wine is an incredible project
<unique_id> yeah
<andrewrk> sometimes I read wine source code to clarify MSDN documentation
<andrewrk> then test on actual windows, and, sure enough, they got it right
<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
<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.
<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
<andrewrk> but I think your comments apply to the stage1 compiler as well
<knebulae> I found relevant code in both source dirs
<andrewrk> let's start with "what should the UI be from the user's perspective" and then work from there
<andrewrk> so it's either add `-mefi_application` and `-mefi_driver` or introduce `--windows-subsystem [arg]` and remove the current -m options
<andrewrk> oh I see your point about the windows target now
<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
<andrewrk> this is not true for an UEFI application, so the OS is not windows
<andrewrk> I think that's a pretty clear case
<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
<knebulae> So, OsUefi as an ostype and -mefi_driver, -mefi_application to differentiate?
<knebulae> As long as changing the configuration struct to account for the additional two flags will not have adverse side effects elsewhere.
<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
<knebulae> Damn, I haven't even had my cornflakes yet.
<andrewrk> haha
<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
<knebulae> gotcha
<andrewrk> is that correct that only 1 subsystem can be selected at a time?
<knebulae> yes
oky has joined #zig
unique_id has quit [Quit: Konversation terminated!]
IntoxicatedHippo has quit [Quit: Leaving]
Ichorio has joined #zig
MajorLag has left #zig [#zig]
MajorLag has joined #zig
oconnor0 has joined #zig
<oconnor0> What is the status on network programming?
<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
<MajorLag> oconnor0: IIRC it mostly doesn't exist yet. There's a big async change coming and I think we're waiting on that.
<MajorLag> You can call native APIs, but there's not stdlib implementation.
<oconnor0> MajorLag: thanks. do you know the ETA of the async change?
Zaab1t has joined #zig
<andrewrk> oconnor0, it's (1) copy elision (2) async change (3) then networking should be nice
<andrewrk> hoping to have 1-3 done by next release (0.4.0)
<andrewrk> estimated release date: march 15 2019. it's dependent on llvm 8's release date
<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 :)
<oconnor0> andrewk, awesome, thanks.
<mgxm> is anyone working on freebsd support to libc?
<andrewrk> mgxm, are you talking about or are you talking about zig's standard library interface to make freebsd syscalls?
<mgxm> about the syscalls
<andrewrk> I'm not aware of any efforts of this currently
<andrewrk> if you're going to try to do it, you could follow the patterns for macosx in the standard library
<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
<mgxm> so, should I replace all the functions that use syscall to use the c interface?
<MajorLag> FreeBSD doesn't officially have a stable ABI, right? So probably.
Hejsil has joined #zig
xentec has quit [Quit: memento mori]
<MajorLag> Fiar enough, I was only even trying it to workaround the false ''depends on itself'
xentec has joined #zig
jjido has quit [Ping timeout: 240 seconds]
<andrewrk> mgxm, yes
<andrewrk> someone from the freebsd team stopped by and clarified that point
steveno has quit [Ping timeout: 250 seconds]
steveno has joined #zig
meheleventyone has joined #zig
<ShrewdSpirit> Is zig fully self hosted now?
<andrewrk> ShrewdSpirit, no, some big changes are needed first
<ShrewdSpirit> Since the compilation stages confused me
<j`ey> stage1 is C++
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<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?
<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
<andrewrk> the LLVM/target triple code is simple, I don't foresee that being a problem
<knebulae> Ok. Fair enough.
<andrewrk> as an example, in zig you should be able to do this: if (builtin.os == {; }
<andrewrk> e.g. it's a valid assumption that if the target OS is windows, you can call the RtlGenRandom DLL function
<andrewrk> however this is not true for the UEFI target
<andrewrk> does that make sense?
<knebulae> Understood
<knebulae> Absolutely. Stupid question -- where are the builtins defined?
<andrewrk> they are generated by the compiler. you can see them with `zig builtin`
Hejsil has quit [Ping timeout: 256 seconds]
steveno_ has joined #zig
steveno has quit [Ping timeout: 268 seconds]
meheleventyone has joined #zig
meheleventyone has quit [Client Quit]
<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.
oats has joined #zig
daurnimator has quit [Ping timeout: 252 seconds]
Zaab1t has quit [Quit: bye bye friends]
daurnimator has joined #zig
steveno_ has quit [Ping timeout: 246 seconds]
steveno_ has joined #zig
steveno_ has quit [Ping timeout: 260 seconds]
<andrewrk> oh boy, I think I may have solved copy elision for @sliceToBytes. that was a tricky one
<andrewrk> the parameter expression writes directly to the return value
<andrewrk> or, "refers directly" rather than "writes"
halosghost has quit [Quit: WeeChat 2.3]
steveno_ has joined #zig
shodan45 has joined #zig
zachcarter has joined #zig
steveno_ has quit [Remote host closed the connection]
<daurnimator> "a running windows operating system that you can interact with" <-- could you define this?
<daurnimator> andrewrk: would "a running nt kernel" be a suitable definition?
<daurnimator> or do you really mean "win32 is available"
<andrewrk> I would define it as all of the public API of kernel32.dll being available, and correct, to interface with
<daurnimator> andrewrk: oh... so somewhere in between nt and win32? that's sorta awkward >.<
<andrewrk> was that a trick question? sounds like there's something you're implying
<daurnimator> andrewrk: most windows applications as microsoft make them is a stack of: nt kernel | NTDLL.DLL | kernel32.dll | user32.dll
<daurnimator> you can create programs that use any number of pieces starting from the left
<andrewrk> right. so far zig std lib for windows depends on the first 3
<andrewrk> and I don't think you can depend on any of those for UEFI applications
<daurnimator> it's *very* hard to avoid bringing in user32.dll
<daurnimator> (though not impossible)
<andrewrk> we've avoided it so far. what do you think the standard library will need it for?
<andrewrk> I'm not necessarily against it, I just haven't seen a need for it yet, and the null hypothesis is fewer dependencies
<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
<andrewrk> that's fine - I imagine that applications and libraries which want to do that will have a quite reasonable dependency on user32.dll
<daurnimator> this is notable because as soon as user32.dll gets loaded into your process on windows, you can no longer fork
<andrewrk> what dll call is that?
<andrewrk> I don't think we use that in the standard library
<daurnimator> andrewrk: this is also related to subsystems. usually things that use ntdll.dll directly and not kernel32.dll are called "native subsystem"
<andrewrk> I'd like to read more about this
<daurnimator> native subsystem windows programs are much more interesting from a unix POB
<daurnimator> *POV
<daurnimator> also for windows early boot you can *only* run native subsystem programs
<andrewrk> my understanding was that kernel32 is the lowest abstraction level windows offers
<daurnimator> it's the lowest one they document well :P
<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
<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
<daurnimator> andrewrk: yes UEFI should be a different target
<andrewrk> well, one of my laptops :)
<daurnimator> andrewrk: however our definition of "windows" doesn't exactly make sense. I think you need to split it into "nt" and "win32"
<andrewrk> ahh, this is the crux of your point
<daurnimator> where win32 is 98% a superset of nt.
<andrewrk> I think there could be a good case to make for this, and I would like to officially consider it
<andrewrk> on the issue tracker
<daurnimator> it also has a different side.... wine emulates win32 well, but less-so nt.
<daurnimator> whereas reactos emulates nt
<andrewrk> oh, interesting. I thought those were mostly the same codebase
<daurnimator> reactos is a reimplementation of the nt kernel
<daurnimator> (and low level dlls)
<daurnimator> wine is more rewriting kernel32.dll calls to be linux syscalls along with managing lots of misc state.
<daurnimator> though wine implements *some* ntdll functionality. as there are parts of windows where developers regularly drop down a level
<daurnimator> andrewrk: will create an issue now I guess
<andrewrk> daurnimator, thanks, I appreciate it
<andrewrk> it's good to have someone around who is intimate with windows
<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?
<andrewrk> it sounds like there are some good answers to this, which would be useful in the issue