<v0idify>
(i'm setting up a development environment
pretty_dumm_guy has quit [Quit: WeeChat 3.2-dev]
<v0idify>
damn, llvm compilation speeds
<g-w1>
yep its pretty bad. you shouldn't have to compile the compiler every time tho. just update --override-lib-dir to $ZIG_REPO/lib
<v0idify>
yes but this is my first time :)
<g-w1>
you can just use the master compiler, and override the lib dir. ofc its always fun to build from source :P
<v0idify>
how?
<g-w1>
--override-lib-dir ?
<v0idify>
oh god, thanks
<g-w1>
the compiler should be master tho so std.builtin matches up
<v0idify>
sorry, probably should be on CONTRIBUTING.md
<g-w1>
ive actually never used it, since i mostly work on the compiler, but it *should* work
<v0idify>
andrewrk, (don't have github) the things that don't need a context simply use void right? also it's not entirely clear to me what the example use-case is for
ur5us has quit [Ping timeout: 258 seconds]
ur5us has joined #zig
brzg has joined #zig
earnestly has quit [Ping timeout: 240 seconds]
barakkl1993 has joined #zig
barakkl1993 has quit [Ping timeout: 252 seconds]
xackus_ has joined #zig
xackus has quit [Ping timeout: 268 seconds]
teratorn_ has joined #zig
teratorn has quit [Ping timeout: 252 seconds]
brzg has quit [Quit: leaving]
jicksaw has quit [Quit: ZNC is kill]
osa1 has quit [Ping timeout: 240 seconds]
jicksaw has joined #zig
xackus_ has quit [Quit: Leaving]
xackus has joined #zig
<xackus>
I got zig0 to build with llvm main, but now it crashes in ZigLLVMTargetMachineEmitToFile
aerona has quit [Quit: Leaving]
<mikdusan>
xackus: what's the context?
<xackus>
mikdusan: I am trying out a new clang api for macro expansion: clang::MacroExpansionContext
<mikdusan>
which llvm tag/branch ?
<xackus>
main
<mikdusan>
using something based on zig llvm12 branch?
<xackus>
yes
<mikdusan>
linux/x86_64 ?
<xackus>
yep
<xackus>
it segfaults in the destructor of StandardInstrumentations
<mikdusan>
hmmm zig0 is limited in options but I wonder if you can get it to emit llvm ir
<xackus>
I should probably get some sleep before tackling this further
<mikdusan>
here's about the most basic thing for zig0 to do. try this, you may have to adjust zig0 path, and where ./lib is coming from:
<companion_cube>
There's a 2 part cppcon video on atomics
<companion_cube>
The basic principle is just variables that you can change atomically even between threads
<v0idify>
but that's for compiler devs, i want to understand it for using it in my program
<companion_cube>
With some specific operations
<companion_cube>
Ah well, don't, unless you're writing new concurrency primitives :). Although an atomic bool can be useful to signal stuff between threads
<ifreund>
v0idify: I think understanding what the different orderings allow the compiler to do and not do is the same as unterstanding how to use it in your program
<v0idify>
okay, i
<v0idify>
okay, i'll check it out then. i hate ANSI enter
<ifreund>
you may also want to read the relevant part of the C11 or C++11 standard linked there
<v0idify>
i'm trying to use an atomic bool for signaling when my loop that accepts connections stops working, but i realize that i probably should use select {} for this, because if i do while (running) { conn = accept(); } then i will have to do one more connection to turn off the server anyway
<M_F>
Oh, and there is another thing that I didn't understand : when using `packed struct`s, it appears that the first fields that are declared end up in the least significant bits of the representation, but the doc says that "fields remain in the order declared", am I interpreting it wrongly ?
<M_F>
(i.e. do we normally order bits from least significant to most significant ? I know this would make mathematical sense, but it's a bit surprising to me haha)
<fengb>
It's architecture dependent. By convention, little endian orders by LSB first
<M_F>
Ok, thanks
<M_F>
"Non-ABI-aligned fields are packed into the smallest possible ABI-aligned integers in accordance with the target endianness." (from the doc) Is it what this means ?
<M_F>
Otherwise I'd propose to state this behavior more clearly in the docs (unless it is actually obvious and not worth mentioning; I'm not familiar enough with systems progamming to judge that)
<M_F>
What bothers me is that endianness is about the order of _bytes_, not _bits_...
<fengb>
Bit endian is a thing too
<M_F>
Yes, of course
<Raito_Bezarius>
would that be possible to declare the struct in C with packing and gets it back in Zig?
<fengb>
Yes if you can guarantee the C field layout
<Raito_Bezarius>
Alright
gazler has joined #zig
dyeplexer has joined #zig
allan0 has joined #zig
allan0 has quit [Read error: Connection reset by peer]
allan0 has joined #zig
RadekCh has quit [Quit: Connection closed]
TheLemonMan has joined #zig
waleee-cl has joined #zig
frmdstryr has quit [Ping timeout: 252 seconds]
remby has joined #zig
mattmurr___[m] has joined #zig
xackus has joined #zig
Major_Biscuit has quit [Quit: WeeChat 3.0.1]
remby has quit [Ping timeout: 240 seconds]
lemur_ has joined #zig
lemur has quit [Ping timeout: 265 seconds]
nvmd has joined #zig
remby has joined #zig
remby has quit [Quit: Leaving]
cow-orker has quit [Ping timeout: 246 seconds]
cole-h has joined #zig
aerona has joined #zig
dyeplexer has quit [Read error: Connection reset by peer]
<mikdusan>
llvm-12.0.0 tagged
<TheLemonMan>
let's party ?
Snetry has quit [Read error: Connection reset by peer]
<mikdusan>
:)
lemur_ has quit [Quit: Konversation terminated!]
Snetry has joined #zig
<mikdusan>
fyi - it is 12.0.0-rc5 retagged
<TheLemonMan>
I can't stand the stage1 compiler anymore, the OOM keeps triggering even though there are 12GB of free ram
Akuli has joined #zig
<mikdusan>
hmm odd. I can get away with 10G vm...
jumpnbrownweasel has joined #zig
<TheLemonMan>
that's way too much RAM anyway
<mikdusan>
oh maybe -DCMAKE_BUILD_TYPE=Debug saves a bit?
<TheLemonMan>
I'm always building the compiler in debug mode
<TheLemonMan>
I noticed this kind of failure after the switch to the new pass manager, I'm not 100% sure that's the culprit tho
<mikdusan>
peculiar. on archlinux, llvm12 branch, time -v gives on fresh build, all caches destroyed, llvm12:
<mikdusan>
Maximum resident set size (kbytes): 8128420
<mikdusan>
and visually top was showing some 7.5g for zig1.o
osa1 has joined #zig
earnestly has quit [Ping timeout: 240 seconds]
<mikdusan>
but this is in vm. no desktop
pretty_dumm_guy has quit [Quit: WeeChat 3.2-dev]
<pingiun>
is there a way to loop a certain amount of times like for i in 0..5 in rust or for(i = 0; i < 5; i++) in C?
<Nypsie>
Good old while loop
<pingiun>
ah sad
<Nypsie>
var i: usize = 0; while(i<5) : (i+=1){}
<pingiun>
oh interesting, i didn't see that syntax yet
<pingiun>
i see it's in the documentation, but i just missed it before. thanks!
blackpawn has quit [Ping timeout: 240 seconds]
<Nypsie>
You're welcome :)
earnestly has joined #zig
jumpnbrownweasel has quit [Quit: Connection closed]
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<andrewrk>
oh snap it's llvm release day today :-o
xackus has quit [Ping timeout: 240 seconds]
<g-w1>
does anyone know the proposal to make functions only callable at comptime?
<mikdusan>
andrewrk: on bumping master to llvm12, CI pipepline for macos-arm64 will be straightfwd. I can also do macos-x86_64 bump but not with formal zig-bootstrap (never got that to work).
cole-h has joined #zig
<andrewrk>
mikdusan, it'll take me the better part of the day to get all the CI tarballs ready, planning to merge into master this evening
<mikdusan>
👍
fritchie has joined #zig
teratorn_ has joined #zig
teratorn has quit [Ping timeout: 240 seconds]
paulsmith21 has joined #zig
<andrewrk>
wtf there are still 13 release blockers open
<andrewrk>
it's also missing the latest release/12.x commit that fixes our aarch64 issue...?
<mikdusan>
yes
v0idify has quit [Ping timeout: 240 seconds]
<mikdusan>
tom sent an email to the report saying it won't make 12.0.0
<andrewrk>
the hell is the point of release candidates when they dont fix them before the release
<mikdusan>
I _might_ suggest we delay until 12.0.1, but then... who knows how many blockers will make that tag.
v0idify has joined #zig
v0idify has quit [Ping timeout: 240 seconds]
v0idify has joined #zig
v0idify has quit [Remote host closed the connection]
v0idify has joined #zig
xackus has joined #zig
<paulsmith21>
hi, there - i am able to trigger what appears to be an infinite loop in the Semantic Analysis step. i have this boiled-down version of my code that's causing it -- basically, it's a tree structure, implementing the type-specific interface for formatting per std.fmt.format comment, with some self-recursion. i suspect it is the self-recursion that's
<mikdusan>
g-w1: but yours doesn't include animated gif :P
<g-w1>
:(
<paulsmith21>
interesting - it also works if you comment out the call to std.fmt.format in the .leaf arm, so it's not just (only?) the recursive call to Node.format
<g-w1>
i feel like there is some weird recursion that is not caught by the compiler
<mikdusan>
seems to be doing a lot of zig`generic_fn_type_id_eql(a=0x00000001671731c0, b=0x00000001874815a0) at analyze.cpp:5770:5
ur5us has joined #zig
<xackus>
mikdusan maybe the segfault from yesterday has something to do with the new pass manager
<paulsmith21>
i should mention, this is on a checkout of 0.7.1.
<g-w1>
its the same for me on master
<g-w1>
feel free to file an issue on the compiler
<paulsmith21>
will do. thanks!
paulgrmn_ has quit [Ping timeout: 252 seconds]
<mikdusan>
xackus: with `basic.zig` and zig0 command line from my gist, you got IR, but then it still segfaults?
<andrewrk>
mikdusan, I'm making the call here that master branch zig is going to depend on release/12.x (not the tag). so the CI tarballs will include the extra commit
<mikdusan>
aaaaah . ctrl-c ctrl-c ctrl-c :)
<andrewrk>
sorry
<andrewrk>
which one(s) are you doing?
<andrewrk>
I'm about to kick off aarch64-macos, x86_64-linux, and x86_64-windows
<mikdusan>
i was just redoing my plethora of macos deps. arm64, x86_64 11.0, 10.15 and 10.9 and linux. but these aren't zig-bootstrap anyways
<andrewrk>
ok cool
LewisGaul has quit [Quit: Connection closed]
<mikdusan>
andrewrk: clarification. 12.x is a branch, not a tag. is zig master going to peg at fa0971b87fb2c9d14d1bba2551e61f02f18f329b ?
<andrewrk>
yes pegging tarballs at that commit
<mikdusan>
👍
<mikdusan>
xackus: can you provide llvm main commit you are building against?
<xackus>
64c24f493e5f4637ee193f10f469cdd2695b4ba6
<xackus>
guess I need a debug build for this
<mikdusan>
xackus: I'll try to reproduce segfault on macos; won't have results for a few hours
Yardanico has quit [Remote host closed the connection]
cbix has quit [Ping timeout: 250 seconds]
Yardanico has joined #zig
pingiun has joined #zig
paulsmith21 has quit [Quit: Connection closed]
fireglow has quit [Quit: Gnothi seauton; Veritas vos liberabit]
<pingiun>
i just made my first thing in Zig! I was implementing the sha2 algorithms in Rust and found that i needed some code duplication because const generics and such aren't that advanced yet. I knew that Zig allows for all the compile time trickery that I needed so I wanted to see how easy it would be. Here's what I came up with: https://gist.github.com/pingiun/7e6a1e067f997f296bed9bf0ff9900f8
cole-h has quit [Ping timeout: 246 seconds]
<pingiun>
I would love to know if there are any things that can be more idiomatic in Zig, because this is just what I came up with while porting from rust
teratorn__ has joined #zig
cbix has joined #zig
teratorn_ has quit [Ping timeout: 252 seconds]
<g-w1>
looks pretty nice!
<g-w1>
did you find it easier to write than the rust?
fireglow has joined #zig
cole-h has joined #zig
<pingiun>
not really, but that's mainly because i was already more familiar with rust and I tried to make it more difficult for myself by implementing the two algorithm versions at once
<pingiun>
also in this case you don't really get a lot of annoyance from the borrow checker, because you're working with a lot of static buffers
<pingiun>
but one thing that stood out to me was +% which is really nice syntax
<pingiun>
in Rust this is 123.wrapping_add(321) which is kinda ugly
<pingiun>
and it was somewhat harder to find the right functions (such as math.rotr) to use because searching in the stdlib doesn't work very well yet
<pingiun>
but it was really fun!
<g-w1>
cool!
ur5us has quit [Ping timeout: 258 seconds]
<pingiun>
oh right I wanted to ask, are struct fields private? is it possible to make them public/private?
<g-w1>
no, it is not
<v0idify>
how can I wait for all async functions to finish running when ran with runDetached?
<g-w1>
pingiun: all struct fields are public
<pingiun>
g-w1: is there a convention of adding a _ prefix to fields you shouldn't touch?
<g-w1>
no, there is not
<v0idify>
not really
<ifreund>
pingiun: I recommend doc comments on fields that *really* shouldn't be touched stating as much
<pingiun>
ifreund: makes sense
<andrewrk>
v0idify, if you want to wait for them then you need to allocate the frame, use async, and then when you want to wait, use await
<andrewrk>
runDetached is a red herring
teratorn__ has quit [Read error: Connection reset by peer]
xackus has quit [Read error: Connection reset by peer]
teratorn_ has joined #zig
xackus_ has joined #zig
<v0idify>
:|
<v0idify>
makes sense though
<v0idify>
i don't get some things runDetached do though
<v0idify>
the beginOneEvent and yield stuff don't make sense to me,
cow-orker has joined #zig
<andrewrk>
mikdusan, I'm thinking of using -mcpu=x86_64_v2 for our CI builds of zig. thoughts?
<andrewrk>
I think even v2 is supported by pretty old hardware
<mikdusan>
it looks very old. So far I've found nothing to say it would be a problem
<andrewrk>
nice. doin it
<g-w1>
so this will give the ci better speeds and also the downloaded tarballs?
<andrewrk>
potentially. depends on how much these CPU features end up getting utilized and how much they matter to perf
LewisGaul has quit [Ping timeout: 240 seconds]
<g-w1>
yep, makes sense
<mikdusan>
I have a datapoint for mac side of things. old macpro (10.6 days) is penryn. that's between x86_64 v1 and v2 and that's a 13 year old system
<g-w1>
i mean, it wont affect llvm speed
<mikdusan>
g-w1: with zig-bootstrap it does because it rebuilds llvm with `zig cc` :)
<g-w1>
ci uses zig-bootstrap?
<mikdusan>
for linux yes
<g-w1>
oh nice
<mikdusan>
maybe more than linux, I haven't examined the date of dep tarballs used by ci for freebsd or win
<andrewrk>
we use zig-bootstrap for all the CI now I believe
<mikdusan>
minus macos aarch64
<g-w1>
turns out compiling llvm from nixos only took like 40 minutes
<andrewrk>
alright. llvm12 branch merged into master and pushed. now it's a race to fix the broken CI
<andrewrk>
mikdusan, can you do the honors for aarch64-macos please? :)
<andrewrk>
I'm working on zig-bootstrap builds for everything that can be cross compiled