ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
fsateler has quit [Read error: Connection reset by peer]
fsateler has joined #zig
<diltsman>
Any idea why adding a function that has "unreachable;" in the body would cause the compiler to generate a .data.relo.ro section?
benaiah` has joined #zig
benaiah has quit [Read error: Connection reset by peer]
benaiah` is now known as benaiah
Zaab1t has joined #zig
Zaab1t has quit [Quit: bye bye friends]
Hejsil has joined #zig
<Hejsil>
MajorLag, thanks for the suggestion, but I don't think a binary format is worth it for what I'm trying to do.
davr0s has joined #zig
<c15ade4>
zero copy json for the win
MajorLag has quit [Ping timeout: 268 seconds]
MajorLag has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
wilsonk has quit [Read error: No route to host]
oconnor0 has quit [Ping timeout: 252 seconds]
oconnor0 has joined #zig
mht has joined #zig
Zaab1t has joined #zig
Zaab1t has quit [Quit: bye bye friends]
Zaab1t has joined #zig
<MajorLag>
Hejsil: *shrug*, serializing to and from text seems like a lot more work to me than a binary representation. Maybe that's because I've already written a serializer/deserializer for working with data formats. Having a program that converts text to the format, and from the format to text solves any human readable and UNIX utility interaction needs. Of course, I'm also one of those people who think PowerShell did the
<MajorLag>
r by removing the "(ASCII) text is the universal interface" part, so I guess if you're trying to be really UNIX-y then you'd want to go with text anyway.
<Hejsil>
Well, if there is a better solution, I'm all in. As i see it, text seems like the best interface for most of the data I wonna send around these processes. I also don't think the binary format will win me much, as I want different games to have the ability to output different fields, if they exists in those games.
<Hejsil>
So, for gen1 games, they're not gonna output sp_defense, as it doesn't exists
<Hejsil>
And the text format will make the format very accessible for people who wonna write a pass in Python or something
<Hejsil>
And in a way, the games themself are already binary formats and few people wonna write tools for these games because of this.
<Hejsil>
Finally done with all that. Time to work on other projects for a bit!
<andrewrk>
enjoy :)
bheesham has quit [Quit: WeeChat 1.4]
<Hejsil>
andrewrk, Hmmm, but the stage 1 compiler doesn't understand doc comments
<andrewrk>
you mean the parser?
<Hejsil>
Well, yea
<Hejsil>
They have to be in the tree for everyhting to work
<Hejsil>
But I guess that is just part of what is needed to get this done
<andrewrk>
if we switched to a token index based thing, rather than token pointer, we could just look backwards from nodes for doc comment tokens
<Hejsil>
Idk. I know most of std by now, so I can wait :)
<Hejsil>
But prototyping is important
<andrewrk>
yeah, I just feel bad telling everyone, "sorry no docs, I have to do a ton of work before that will be available"
<Hejsil>
Also, on the topic of parsing. How is "server compiler" gonna work with the current Ast points to Tokens points to Src? Wont we be waisting memory by holding onto the source code?
<Hejsil>
Or maybe this question is a little premature, as Idk what will use most memory in stage 2
<andrewrk>
currently stage2 does reference counting for all values
<andrewrk>
and yes, hangs onto full source / tokens for any code that has not changed
<andrewrk>
I think it will be ok to start this way and then change it later
<Hejsil>
Seems fair
<Hejsil>
How is copy-elision comming along?
<Hejsil>
Still a lot of changes left=
<Hejsil>
?*
<andrewrk>
yes - it seems that every semantic construct is a different puzzle to solve
<andrewrk>
anyway, zig IR is getting more complicated. but zig language is mostly the same, with some extra, helpful guarantees about how memcpy won't happen
<andrewrk>
the only unsolved problem right now is peer type resolution. unless I think of some clever thing, it's going to be a kind of "left-to-right" type resolution
<Hejsil>
Hmm. I read somewhere that this would find var a: u8 = if (something) 1 else 2;
<Hejsil>
find/fix*
<andrewrk>
yes it would, because it essentially does u8(1) and then u8(2)
<andrewrk>
it also would allow: var a = if (something) u8(1) else 2;
<andrewrk>
but not: var a = if (something) 1 else u8(2);
<Hejsil>
Makes sense since the code has to know about the location and its type
<Hejsil>
Ooh
<Hejsil>
Hmm.
scriptnull has joined #zig
<Hejsil>
So a gets the type of u8(1), and then 2 is casted to the location type
<andrewrk>
also: var a = if (something) u16(1) else u8(2); // ok
<andrewrk>
but: var a = if (something) u8(1) else u16(2); // error: expected u8, found u16
<andrewrk>
not ideal.
<andrewrk>
but if you put the cast on the outside, both things get casted to the outside thing
<Hejsil>
And we cant resolve the two expressions in relation to eachother before the result?
<andrewrk>
but LLD is: * not planned to support incremental linking * not designed to be used as a library * not written in zig ;)
<ltr_>
i know the linker of llvm for apple, i fixed a bug long time ago (zig 0.0.1?)
<andrewrk>
yes, and sadly that was the last improvement to the apple linker code that anyone has made :(
<ltr_>
hahah yeah
<andrewrk>
this is a good use case for using zig's async I/O - once the coroutine rewrite is complete. but a blocking implementation should be easy to migrate over
<wootehfoot>
lld doesn't support incremental linking? I thought it at least supported it with -Wl,--thinlto-cache-dir=/path/to/cache s of LLVM 5.0, or are you talking about something else?
<andrewrk>
I don't think thin LTO is the same thing as incremental linking
<ltr_>
ok ill research the linker thing, i have to update my zig knowledge first and setup my zig's env. anyways i think something like quake is doable
<wootehfoot>
no it's not, it's a particular use case when incremental liking works
<ltr_>
maybe with an semiautomated tool
<andrewrk>
ltr_, quake would be an impressive demo
<andrewrk>
you could work on translate-c and try to get it good enough to port quake
<ltr_>
ill start with the linker
<ltr_>
using go/llvm linkers for reference
<andrewrk>
wootehfoot, hmm, it looks like thinlto with a cache directory does some kind of incremental linking that I was not aware of
<andrewrk>
thanks - I'll investigate this
<wootehfoot>
andrewrk, thank you too, your recurse presentation was really inspiring by the way :)
<andrewrk>
wootehfoot, I think the main drawback of this is that it requires all objects and libraries to have been compiled with thin LTO
<andrewrk>
whereas a generic linker that supports incremental linking could support, for example, .a files built with gcc
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<oats>
andrewrk: will there be a coding live stream today? what time are they at?
<wootehfoot>
andrewrk, gcc's LTO gimple trees aren't any more amazing either. They're versioned so re-using a lib's gimple tree from an older GCC is a nono. Then there's the -fno-fat-lto-objects which has become default, and thus requires gcc-ld, gcc-ar.. etc. for the toolchain to be fully aware of the linking phase. In GCC >=6 'ld -r' enables incremental linking with LTO.
<andrewrk>
oats, yes, 17:00 EST. the topic today will be implementing a floating point number parser
<wootehfoot>
Then, for the fans of deterministic builds with LTO, it required setting the LTO seed to zero, with breaks incremental linking altogether, everything is a tradeoff :)
<wootehfoot>
requires*
<andrewrk>
wootehfoot, zig's stance on this tradeoff is: debug builds are not deterministic; release builds are
<andrewrk>
release builds also are not incremental
Ichorio_ has quit [Read error: Connection reset by peer]
Ichorio_ has joined #zig
Ichorio has quit [Ping timeout: 246 seconds]
Ichorio_ has quit [Client Quit]
steveno has quit [Remote host closed the connection]
oconnor0 has quit [Ping timeout: 240 seconds]
oconnor0 has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
<oats>
does a "deterministic" build mean that, given the same source code and the same compiler version, the output binaries/libraries would be the exact each build?