ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
hasen_judy has quit []
zedias has joined #zig
<zedias> help
<zedias> HELP
zedias has quit [Ping timeout: 260 seconds]
hoppetosse has quit [Ping timeout: 248 seconds]
puppp has quit [Ping timeout: 248 seconds]
cenomla has joined #zig
<andrewrk> zedias, how can I help you
<GitHub96> [zig] andrewrk pushed 1 new commit to master: https://git.io/vFs8g
<GitHub96> zig/master abff1b6 Andrew Kelley: windows: use the same libc search within a compilation unit
cenomla has quit [Quit: cenomla]
puppp has joined #zig
pupppp has joined #zig
puppp has quit [Ping timeout: 248 seconds]
arBmind has joined #zig
<pupppp> errors in zig are like one program-wide enum?
pupppp has quit [Read error: Connection reset by peer]
pupppp has joined #zig
hoppetosse has joined #zig
dimenus has quit [Read error: Connection reset by peer]
<ltr_> wasm runs on a "stack machine"? in the browser?
dimenus has joined #zig
<pupppp> what's wasm?
<pupppp> ltr_,
<andrewrk> pupppp, yes
<pupppp> there was a site called wasm back in the day, now this word has a different meaning
<pupppp> I want to throw a wall of text about exceptions on github issues, wanna read?
<andrewrk> yes
<andrewrk> definitely
<ltr_> yes webassembly
<ltr_> and it runs in a stack machine
<dimenus> andrewrk: how did you get the idea for zig?
pupppp has quit [Read error: Connection reset by peer]
pupppp has joined #zig
hoppetosse has quit [Ping timeout: 248 seconds]
hoppetosse has joined #zig
arBmind has quit [Quit: Leaving.]
<andrewrk> dimenus, when I coded C, zig is the language I wish it was instead
<andrewrk> zig is just incremental improvements on C
<dimenus> i've been watching jblow off and on since he started his language
<dimenus> so i was just curious
<andrewrk> I watched some of his videos
<andrewrk> I'm impressed with the performance
<andrewrk> I want to try to match his performance with the self-hosted rewrite
<andrewrk> but we also have planned to support mega large codebases while jblow has said that a codebase > 80,000 ish lines is not really a use case he cares about
<dimenus> I don't think that last statement is true
<dimenus> Maybe you're missing an extra 0
<dimenus> but I think the witness is about half a million lines
<dimenus> yeah it was over a quarter of a million back in 2015: https://twitter.com/jonathan_blow/status/558341435297001473?lang=en
<andrewrk> hmm yeah maybe I'm off by a factor of 10
<dimenus> so if i wanted to dig into performance, is it worth even working off the C++ only codebase?
<dimenus> actually, i should start with profiling......
hoppetosse has quit [Ping timeout: 240 seconds]
<andrewrk> dimenus, one thing we have is --enable-timing-info
<dimenus> neat
<andrewrk> I was planning on getting concurrency working soon, so we could use that in the self hosted rewrite
<andrewrk> but yeah, I think I'm going to focus on performance in the self hosted codebase and not the C++ codebase
<dimenus> andrewrk: btw, I was trying to understand your commit you made last night. What do you mean the "same libc path" per compilation unit?
<dimenus> vs what I had previously
<andrewrk> if find_libc_include_path is called, and then find_libc_lib_path is called, they should use the same value for the ZigWindowsSDK
<andrewrk> e.g. how you had it originally, except the state is saved in CodeGen instead of os.cpp
<dimenus> ah that makes sense
pupppp has quit [Read error: Connection reset by peer]
pupppp has joined #zig
<pupppp> Why you still work on windows sdk integration, to use libraries from zig?
<pupppp> I hope to actually replace visual studio. You should have enough to do that.
<andrewrk> pupppp, the best thing I want to achieve is to replace every c library with a zig library. then we don't need the windows SDK
<andrewrk> but to help zig be practical and to get people to use it, people need to be able to use existing code
<pupppp> I use mingw, I don't even know what windows sdk is. I have most of the headers necessary.
<andrewrk> it's not relevant to your use case since you're not using --library c
<dimenus> you can't replace everything at once
<dimenus> and if you want adoption you need to have 'minimal friction'
<andrewrk> agreed
<dimenus> if you make someone's workflow vastly more complicated or reduce the number of things they can use to 0 unless they use your language
<dimenus> nobody is going to use your language for anything other than toy programs
<andrewrk> exactly
<dimenus> also, i like the idea of being able to translate pieces of code when I want to
<pupppp> How different is microsoft libc from mingw libc?
<pupppp> are they compatible? Can I use dll compiled with microsoft compiler from exe compiled with mingw compiler?
<pupppp> is libc a dinamic or static library?
<dimenus> mingw libc is a hack
<pupppp> ?
<dimenus> an old hack that microsoft is against
<dimenus> wish I had the article handy......
<pupppp> I don't understand what libc is even necessary for.
<pupppp> From what I've seen, it's possible to do most of the things without it.
<dimenus> most things like what?
<dimenus> or are you referring to just within zig?
<dimenus> andrewrk has already done a lot of work to free zig from having to use libc
<pupppp> I still can call winapi functions, and other library functions. This means, gui, graphics, image processing.
<dimenus> if you want to know what libc does, do a dumpbin in an MSVC development cmd on one of the libc libs :)
<pupppp> I guess libc is for printing text in console, something else
<pupppp> ...
<dimenus> libc does a lot of setup, like if you have a basic GUI application that starts your code in 'WinMain'
<dimenus> libc calls your code
<pupppp> I guess libc also takes care of thread local storage and stack checks
<pupppp> I really dislike when compilers hide code from me, makes me paranoid.
<dimenus> as I said above though, I don't think any of us is saying we'd prefer to use libc
<dimenus> but if you use other code in the meantime that links libc, you need to be able to link it
<dimenus> which up until the code I submitted yesterday was pretty brittle as it used a set hardcoded path
<pupppp> I learned that libjpeg uses setjmp/longjmp for error managing, which made me doubt that I'll be able to port it to zig properly.
<pupppp> back to exceptions
hoppetosse has joined #zig
pupppp has quit [Ping timeout: 240 seconds]
pupppp has joined #zig
<andrewrk> pupppp, to port it to zig, you would not use setjmp/longjmp
<andrewrk> setjmp/longjmp are bad practice and should be avoided in zig
<pupppp> I suspect that setjmp might be actually faster than passing error codes through many layers of functions. I'm not sure how to check it.
<pupppp> Actually yes, setjmp is as heavy as an actual exception, os will do a lot of things behind the scenes. Maybe I could do goto instead.
<andrewrk> I'm also planning on weighting branches against errors: https://github.com/zig-lang/zig/issues/84
<pupppp> Branch prediction is an interesting feature. Needs a lot of testing though.
<pupppp> I annoyed people about it previously here https://board.flatassembler.net/topic.php?p=199168#199168
<pupppp> Tried to figure out if just rearranging code by hand will be enough. Still haven't figured out.
<pupppp> Okay, I'll forget about exceptions, I'll go for goto instead. Goto and giant functions.
<pupppp> Need to write the actual code now.
<pupppp> EASTL is a cool library, it could be a good reference.
<andrewrk> pupppp, if you just use zig normally and functions whenever you want, and then use --release-fast, LLVM turns your code into giant functions with goto
<andrewrk> you might be doing unnecessary work
<pupppp> ok, I'll try
<dimenus> andrewrk: what are your thoughts on having multiple backends?
<dimenus> (another idea borrowed from jblow)
<dimenus> i know we have a lot more important things to do first
<dimenus> just curious
<andrewrk> I think it could make sense if we could get something out of it
<andrewrk> jblow's main reason for doing it is speed
<andrewrk> I want to explore an advanced caching strategy before resorting to writing a custom backend
<andrewrk> also, jai doesn't have debug symbols
<andrewrk> if we had our own backend, we could distribute zig as a 100% static binary that does not depend on libc. that's pretty neat
<andrewrk> but it wouldn't have all the advanced optimizations LLVM offers
<dimenus> i'm on jblow's end as far as iteration speed goes
<dimenus> but that does sound interesting
<andrewrk> I think we can compete with jai's speed. that's one of the things I want to prove in 0.2.0
<dimenus> his demo game is ~ 50k lines i think and compiles in about half a second on x64
<andrewrk> if you look at --enable-timing-info, 10% of time is spent generating compiler-rt.o and builtin.o. these objects are (almost) always exactly the same. we can eliminate that 10%
<dimenus> probably slower on llvm
<dimenus> i haven't had a chance yet, lots more busy work to do today
<dimenus> earlier this week i had a lot more conference calls
<dimenus> i did compile llvm master in the background though
<dimenus> :D
<andrewrk> nice
<andrewrk> I made progress on the assertion
<andrewrk> I'll file an issue so you can follow along
<dimenus> the test assertion w/ master?
<dimenus> nice
<andrewrk> yes
<dimenus> very nice
<dimenus> do we submit the IR to LLVM as txt or in that binary format?
<dimenus> i'm just learning about all of this
<andrewrk> we create an in memory structure using the LLVM API
<andrewrk> which can be rendered in that text format
<andrewrk> with LLVMDumpModule
hoppetosse has quit [Ping timeout: 240 seconds]
_dev_zero has quit [Remote host closed the connection]
_dev_zero has joined #zig
hoppetosse has joined #zig
dimenus has quit [Quit: Leaving]
<dtzWill> why do you need your own backend to ship 100% static binaries? O:)
arBmind has joined #zig
cenomla has joined #zig
<andrewrk> to ship a static binary of zig that does not depend on libc?
<andrewrk> because LLVM depends on (among other things) libc
<andrewrk> zig already supports shipping 100% static binaries of zig programs
<andrewrk> I was referring to the self hosted compiler
<dtzWill> oh, right, okay. So statically linked libc wouldn't help, you mean avoiding libc specifically altogether?
* dtzWill builds LLVM and LLVM-based tools into fully-static executables regularly
<dtzWill> (musl, and I go .... a roundabout way to it that's an important part of my research O:))
<dtzWill> (among other things working to free the world from shared/static SNAFU)
<andrewrk> dtzWill, yes
<dtzWill> anyway I'm sure you're plenty aware of those sorts of issues given how magically zig handles them (well, in my limited experience it does, but even taht is an impressive claim...)
<andrewrk> dtzWill, you might find this issue interesting: https://github.com/zig-lang/zig/issues/514
<dtzWill> yes! *subscribes*, *reads*
<dtzWill> wow, yes
<dtzWill> I wish I had more time ATM so I could work on that and how what our ideas could be mutually beneficial. Bah.. Well for now just know this is good stuff and I think you're really on to something ^_^
<andrewrk> if you ever get time, let me know. I could use a hand
<dtzWill> sure thing o7
pupppp has quit [Ping timeout: 240 seconds]
hoppetosse has quit [Remote host closed the connection]
dimenus has joined #zig