amk has quit [Read error: Connection reset by peer]
amk has joined #zig
Anzh has quit [Ping timeout: 268 seconds]
Anzh has joined #zig
Anzh has quit [Read error: Connection reset by peer]
Anzh has joined #zig
Anzh has quit [Ping timeout: 252 seconds]
bsrd has joined #zig
SLWW_ has joined #zig
SLWW has quit [Ping timeout: 246 seconds]
waleee-cl has joined #zig
cole-h has joined #zig
fritchie has joined #zig
pretty_dumm_guy has joined #zig
klltkr has quit [Read error: Connection reset by peer]
klltkr has joined #zig
Bernstein has quit [Remote host closed the connection]
pretty_dumm_guy has quit [Quit: WeeChat 3.2-dev]
tlam has quit [Read error: Connection reset by peer]
zenkuro has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
leeward has joined #zig
TheLemonMan has joined #zig
plumm has joined #zig
<andrewrk>
daurnimator, yeah a bunch of us still use it regularly
<rbino>
what is the recommended naming convention for tagged union fields? the documentation seems to imply it's snake_case but searching for union(enum) in ziglang/zig it seems that TitleCase is more used
<andrewrk>
rbino, snake_case, same as enums. it changed semi-recently so you are seeing the older style
<andrewrk>
the reasoning is that it is somewhat common of a refactor to change an enum to a union
<rbino>
thanks andrewrk, I imagined it was a changed convention but I didn't know which of the two was the more recent one
tefter has joined #zig
tefter has quit [Remote host closed the connection]
Akuli has joined #zig
<TheLemonMan>
andrewrk, speaking of the naming scheme shall we write proper names (eg. RISCV, PowerPC -> PPC) in upper case?
<TheLemonMan>
capitalizing only the first letter makes them look bad IMO
<andrewrk>
well you know my stance but if you wanna break the rule I won't stop you
<plumm>
what is your stance
<plumm>
also, HTTP vs Http?
<TheLemonMan>
isPpc is objectively uglier than isPPC heh
<andrewrk>
the algorithm for creating a TitleCase and camelCase is well defined now: start with lower_snake_case then convert the _ into uppercasing the next letter
<andrewrk>
TheLemonMan, I don't disagree with you there but I like the consistency the algorithm provides. I've found in practice there are examples where it becomes subjective how to do it but the algorithm does pick a side
<andrewrk>
I also think you get used to what you see more often
<TheLemonMan>
I'll just follow the algorithm then, names are not so important :)
<TheLemonMan>
the original question wrt whether the isXXX should be split into isXXX32/isXXX64 remains, right now we have a mixture of the two
<ifreund>
while were on the topic of naming conventions, tigerbeetle has gone with snake_case for function names and I find it a lot more readable than camelCase for longer function names
<andrewrk>
TheLemonMan, how about this: do what's convenient for the patch, without introducing unnecessary methods "just in case someone wants them"
<g-w1>
that astgen big int commit was informative
<g-w1>
the zir format is pretty flexible
<andrewrk>
yeah I had to make room in the ZIR enum tho heh
<andrewrk>
we're currently at exactly 256 ZIR instruction tags
<andrewrk>
computers are fun
<TheLemonMan>
andrewrk, that's ok, in that case you can merge that PR as-is
<andrewrk>
sounds good!
<g-w1>
it seems like you can just make a tag with a payload of another tag to get around it?
<g-w1>
this is what you did before right?
<andrewrk>
nice, new test coverage!
<andrewrk>
I think we can bump ppc32 to Tier 2
<TheLemonMan>
woop woop
<g-w1>
will zig use llvm 12.0.1 when it comes out?
<andrewrk>
are you asking about the CI?
<g-w1>
yes
<andrewrk>
yes
<g-w1>
hopefully the patch makes it in!
<andrewrk>
I think we should wait for llvm 12.0.1 to release zig 0.8.0
<ifreund>
do we have an idea when llvm 12.0.1 will release?
<andrewrk>
no
<andrewrk>
the website says TBD
ur5us__ has joined #zig
<ikskuh>
yay, no more source updates for me /o\
<ikskuh>
:D
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
ur5us__ has quit [Ping timeout: 276 seconds]
<andrewrk>
what do you mean?
<ikskuh>
using arch linux and i'm too lazy to build llvm12 myself
<ikskuh>
so i have to wait until zig 0.8 is published :D
teratorn_ has joined #zig
teratorn has quit [Ping timeout: 265 seconds]
leon-p has quit [Quit: leaving]
teratorn_ is now known as teratorn
sord937 has quit [Quit: sord937]
SLWW_ has quit [Read error: Connection reset by peer]
<v0idifyy>
i think we agree that \0 not being allowed is good lol
<v0idifyy>
*breaks everything that uses posix
lumo_e has joined #zig
<lumo_e>
hi, I'm trying to build zig from source; apparently the build process gets killed for OOM when building zig1.o
wootehfoot has joined #zig
<lumo_e>
I have about 8GB of ram and 2 of swap which get completely used up
<lumo_e>
is this supposed to be normal?
<g-w1>
yes
<g-w1>
the new compiler is being worked on now that will hopefully fix this
<lumo_e>
a ballpark estimate of the memory I would need to build it?
<g-w1>
it usually takes me ~8
zenkuro has quit [Ping timeout: 265 seconds]
<xackus_>
you can try -DZIG_OMIT_STAGE2, this will probably reduce maxrss
<xackus_>
if you don't need stage2
<lumo_e>
I actually wanted to mess with the stage 2 zig but it seems it is not my lucky day
<lumo_e>
maybe I can increase my swap space a little, that should work
<lumo_e>
is there an issue tracking this? Or is this not an issue?
<g-w1>
it is an issue!
<andrewrk>
lumo_e, yeah sorry bout that, we're using a lot of memory as a crutch for now, but the main project efforts are focused on the new lower-memory-using backend
<ifreund>
vastly lower I might add
<andrewrk>
this problem will be permanently eradicated soon, but until then this is what we have to deal with
<lumo_e>
no need to be sorry, it's fun to have an OOM in a while
<andrewrk>
lol
<andrewrk>
yeah... I learned a lot about compiler development in the last 5 years :)
<lumo_e>
so this would be resolved by fixing the stage 1 compiler or by regenerating the stage 1 from the stage 2? (...supposing this is correct, I have been trying to catch up on the self hosting strategy)
<lumo_e>
out of curiosity, what is in current stage1 that uses up so much memory?
<andrewrk>
the way values are handled, they contain references to both stages of IR that generated them, and the compiler has no tracking to know when it is safe to free a Value, so it must keep all that stuff in memory for the whole duration of the compilation
<andrewrk>
we also don't have a compilation unit per file like most compilers; when you build self-hosted you are building 100% of the code every time, into 1 object file
<xackus_>
-DCMAKE_EXE_LINKER_FLAGS_INIT='-fno-lto' may help, I don't know by how much
<andrewrk>
you can easily oom just by doing @setEvalBranchQuota(999999); and then loop at comptime from 1 to 9999999
<andrewrk>
xackus_, that won't help at all, there is no LTO happening
<xackus_>
ah, it's not turned on? when I was linking against debug llvm it seemed to help
<g-w1>
its not the linking, its the compiling
<andrewrk>
xackus_, interesting. I have no idea why that would be the case
<xackus_>
ah, yes it's not the bottleneck in this case anyway
pretty_dumm_guy has joined #zig
lumo_e has quit [Quit: lumo_e]
pretty_dumm_guy has quit [Quit: WeeChat 3.2-dev]
klltkr has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
enrico_ has joined #zig
<enrico_>
back
enrico_ is now known as lumo_e
<lumo_e>
barely made it by increasing my swapfile to 4G and leaving only the terminal open
<lumo_e>
yay
<mikdusan>
ikskuh: I rolled these on archlinux; let me know if you want any tarballs and I'll upload to gdrive: https://zigbin.io/606658
lumo_e has quit [Quit: lumo_e]
lumo_e has joined #zig
lumo_e has quit [Client Quit]
<mikdusan>
andrewrk: xackus_ is referring to selecting linker; with gcc-10.x it defaults to gold-linker and LTO plugin, even if not passing LTO'able objects. Using `-fno-lto` uses the bfd linker, which in llvm debug build lowers memory needs during linking by about 25%
<andrewrk>
ah interesting
<mikdusan>
it's not much but a gig here, a gig there
<andrewrk>
mikdusan, congrats on diagnosing the drone ci failure. thank you so much for that. wow.
<mikdusan>
face-slap to see it was a llvm-bug already filed and blocker for 12.0.1 ! thanks
<andrewrk>
omg were they aware of it when tagging the 12.0.0 release?
<mikdusan>
oh speaking of which should we just disable drone aarch64 `zig build test` for now?
<andrewrk>
yeah I guess... disabling all of aarch64-linux for llvm yoloing a major release... feels terrible
<andrewrk>
but yeah
<mikdusan>
unless... do we have an option to say "skip debug builds" ?
<andrewrk>
yeah
<andrewrk>
well you'll need a tiny edit to build.zig but look for "skip_release" and there's already some relevant code there
<mikdusan>
hmm... I might as well add something beside `-Dskip-release` . call it `-Dskip-debug` ?