ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
darithorn has joined #zig
wink_ has joined #zig
<wink_> @andrewrk, a while ago you said you had to "use the same compiler to build llvm, clang, and zig" ( IIRC, another time this came up you had a link with some additional information.
<wink_> If my recolection is correct, do you still have that link?
darithorn has quit [Remote host closed the connection]
kristate has quit [Remote host closed the connection]
diltsman has joined #zig
fsateler has joined #zig
fsateler_ has quit [Ping timeout: 252 seconds]
allan0 has quit [Ping timeout: 245 seconds]
<diltsman> What file is builtin.Arch in?
<andrewrk> wink_, I don't remember, sorry
<andrewrk> diltsman, `zig builtin` shows you the contents of @import("builtin")
<daurnimator> huh... a see some sort of magic `__zig_test_fn_slice` in there
<andrewrk> yeah that's a bit magic. has to do with how `zig test` is implemented.
<daurnimator> andrewrk: wow; that musl merge is huge!
<daurnimator> andrewrk: so I don't quite understand: why are we bundling musl?
wilsonk has quit [Read error: Connection reset by peer]
<daurnimator> it does seem weird to me that my zig package now contains all the .c files for musl....
wilsonk has joined #zig
<daurnimator> would it make more sense to include precompiled libc.a files for each target?
kristate has joined #zig
jjido has joined #zig
jjido has quit [Client Quit]
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jjido has joined #zig
Zaab1t has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Zaab1t has quit [Quit: bye bye friends]
dewf has joined #zig
kristate has quit [Remote host closed the connection]
allan0 has joined #zig
<gamester> andrewrk: I found an issue :)
develonepi3 has quit [Remote host closed the connection]
knebulae has joined #zig
<andrewrk> gamester, what's the issue?
<gamester> andrewrk: isn't there supposed to be a compile error when trying to pass an i32 to a function that takes a [*c]i32 ?
<gamester> the function ends up interpreting the integer as a pointer
halosghost has joined #zig
<andrewrk> [*c] pointers are dangerous
<andrewrk> if should be an error if it would be an error in C
<andrewrk> I just checked, in C it's allowed, but you get a warning
<andrewrk> I think we can maybe tighten up the rules a bit
<gamester> ah, I was under the mistaken impression that c pointers were introduced only to solve the issue of pointer-to-one vs pointer-to-many and perhaps null vs not-null
<gamester> in auto translated code
<andrewrk> gamester, their purpose is to have the same semantics as C pointers. I'm opening an issue for your example, just a sec
<andrewrk> daurnimator, see my comment here:
<gamester> andrewrk: for me, gcc also complains by default: "incompatible integer to pointer conversion passing 'int' to parameter of type 'int *'; take the address with & [-Wint-conversion]"
<gamester> (it's a warning)
<andrewrk> gamester, right, so I think we can have an error for that. Thanks for the test case, and apologies for getting a little defensive at first :)
<gamester> np
Zaab1t has joined #zig
<gamester> It's interesting how default warnings change the C spec without changing it :)
nbjoerg has left #zig [#zig]
<gamester> it seems to be a solution for modernizing such an old language without breaking anything
dewf has quit [Read error: Connection reset by peer]
<andrewrk> yeah
<wink_> andrewrk: Txs for trying to remember, let me ask more directly; why is zig broken when NOT using "the same compiler to build llvm, clang, and zig"?
<andrewrk> clang and gcc have incompatible C++ ABIs across some combination of versions
<wink_> txs!
man213 has joined #zig
man213 has quit [Quit: Page closed]
man213 has joined #zig
kristate has joined #zig
kristate has quit [Read error: Connection reset by peer]
kristate_ has joined #zig
<man213> Hi guys. Newbie and grateful zig user here. Today I downloaded compiler master build (2019-03-12) and noticed that my program produces different results depending on build option: i.e. --release-safe and debug builds produce correct results, but --release-small and --release-safe produce incorrect result. I wonder if it is a known issue? Is there any simpler way to test this behaviour than my program (mine is a raytracer). I'm a windows
<andrewrk> hi man213
Akuli has joined #zig
<andrewrk> is your code open source?
<Akuli> how am i supposed to run zig test under valgrind? in older zig versions, i could do 'valgrind zig-cache/test', but now it's something like 'valgrind zig-cache/o/oiasjfoaijsfioajsfio/test'
<andrewrk> man213, I don't think there are any known bugs with diverging debug/release behavior. it could potentially be undetected undefined behavior:
<andrewrk> if it turns out to be a problem with zig's codegen though, that's a high priority bug
<andrewrk> Akuli, if your test fails it prints the path. or you can use `--output-dir zig-cache` to get the old behavior
<andrewrk> but note that there was a bug with this that I just pushed a fix to master branch for
<Akuli> ok let me update my zig
<Akuli> ummm... how do i do that with zig build?
<Akuli> lx
<andrewrk> foo.setOutputDir()
<Akuli> oops
<Akuli> i think i'll add a valgrinding thing to my build.zig
<andrewrk> if you use setOutputDir to zig build then you can use getOutputPath() and friends
<andrewrk> s/to/in/
gamester has quit [Quit: Leaving]
<man213> andrewrk, yes, you can get it here:
<andrewrk> man213, what's std.winapi? do you have a patched zig standard library?
<man213> andrewrk, damn, not really. I just placed slightly modified winapi bindings into zig's folder. Forgot to move it to my project's dir. Gonna fix it
develonepi3 has joined #zig
<man213> andrewrk, fixed. Now everything should be fine
<andrewrk> man213, is this a regression from a previous version of zig? was there a version where release-fast / release-small had expected behavior?
<man213> andrewrk, I'm not sure. Just noticed it today. I upgrade the compiler from time to time (and upgraded it today) with master build and often do release-fast and release-small builds to check executable size before committing. Yesterday everything was ok.
<man213> andrewrk, is there any previous master builds for me to check it or it is replaced completely by a newer master build?
<andrewrk> man213, here are all the windows builds from this month:
<andrewrk> I deleted everything before Mar 1
<andrewrk> man213, if we had it would help a lot, because then we could do binary search on your application
<andrewrk> oh - in your case @setRuntimeSafety should do the trick. you could try a release-fast build, with @setRuntimeSafety(true) in some places to see where it fixes it
<andrewrk> I'm not suggesting this as a workaround, but to help discover the nature of the problem
<man213> andrewrk, Just rolled back two commits earlier and release-fast build produces exactly the same result as the debug build. Hmm... Ok, I'll play with @setRuntimeSafety and do some more research. Thank you, Andrew.
<andrewrk> man213, two commits earlier - what version is that?
<andrewrk> in your own code or two versions of zig?
<man213> andrewrk, two commits earlier - I meant my code, not zig
<andrewrk> ah ok- in that case it's probably undetected undefined behavior. if you figure out what it is, I'm interested to know, because as far as zig is concerned we either need to (1) add runtime checks to detect that, or (2) document it as something zig cannot detect:
<andrewrk> (for (1) I mean runtime checks for Debug/ReleaseSafe builds)
<man213> andrewrk, ok, I'll play with @setRuntimeSafety and other stuff in case if the issue is my fault and let You know.
<andrewrk> sounds good, happy hacking
<man213> andrewrk, btw, is inaccessible for me.
<andrewrk> what happens when you try to access it?
<man213> andrewrk, Chrome says that this site can't be reached. Ping says that "ping: Name or service not known"
<andrewrk> maybe you are experiencing DNS issues?
diltsman has quit [Ping timeout: 256 seconds]
<man213> andrewrk, nevermind. Opened the link from the other machine. Maybe it's an issue with my VPN
kristate_ has quit [Remote host closed the connection]
<man213> andrewrk, How @setRuntimeSafety should be used? Do I need to place it in the beginning of my function's body or something? (couldn't figure out it from the docs)
<andrewrk> man213, I'll improve the docs and then see if that answers your question :)
jjido has joined #zig
mikdusan has quit [Remote host closed the connection]
<man213> andrewrk, ok :)
<andrewrk> man213, I found a bug - @setRuntimeSafety is not correctly overriding the build mode. pushing a fix shortly.
<man213> andrewrk, fine, otherwise I was about to spray @setRuntimeSafety _everywhere_ :D
mikdusan has joined #zig
<andrewrk> man213, it's probably going to take all day for this fix to make it through the CI
<andrewrk> there's already a bit of a queue
<man213> andrewrk, may be it's the good time for me to do a build myself
darithorn has joined #zig
<andrewrk> daurnimator, the latest zig source tarball is still less than 5 MiB
<andrewrk> consider that llvm-7.0.1.src.tar.xz + cfe-7.0.1.src.tar.xz is 39 MiB. That gives a rough estimate of how big zig-1.0.0-bootstrap.tar.xz will be, and the new musl source code is a tiny fraction of it
kristate has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kristate has quit [Ping timeout: 272 seconds]
man213 has quit [Quit: Page closed]
man213 has joined #zig
<andrewrk> there's a new example in the docs now too
<Akuli> how do i write a zig build step that runs a command?
<Akuli> i tried all kinds of things and got created some poo that compiles, but segfaults the build system
<andrewrk> Akuli, a system command or an executable built with the build system?
<Akuli> an executable built with the build system, under valgrind
<Akuli> i.e. a system command
Zaab1t has quit [Quit: bye bye friends]
<andrewrk> const cmd = b.addSystemCommand([][]const u8{"valgrind"}); cmd.addArtifactArg(exe); const valgrind = b.step("valgrind", "Run the thing in valgrind"); valgrind.dependOn(&cmd.step);
<Akuli> you make that look so easy :DD
<andrewrk> yeah the main problem is lack of documentation
<Akuli> woot
<Akuli> that worked on the first try
<andrewrk> 😎
wootehfoot has joined #zig
<man213> andrewrk, roger that
<Akuli> ok so i have a very difficult to debug bug
<Akuli> it doesn't happen with 'zig test'
<Akuli> if i add a line that is seemingly unrelated to other stuff i have, i get a bunch of valgrind errors from lines before the line i added
<andrewrk> generally if you get any valgrind errors, the first one is the one to look at
<Akuli> i know
<andrewrk> this is in debug mode?
<Akuli> i think so, whatever is the default
<andrewrk> yes that's debug
<Akuli> ok i managed to get something reproducing i think
<Akuli> let me create an issue
<andrewrk> that new `error: dependency on library c must be explicitly specified in the build command` is nice
<Akuli> yes, but that's not the error i'm getting
<Akuli> :D
<andrewrk> weird, if I don't link libc then I don't get the valgrind errors
<Akuli> it seems to only happen with c_allocator
<Akuli> if i replace it with DirectAllocator.init() and link with libc anyway, it will work
<andrewrk> I'm getting the valgrind errors with --library c but the allocator line deleted
<Akuli> :DDDD
<Akuli> same
<Akuli> but it works with DirectAllocator and --library c!
<Akuli> adding the DirectAllocator fixes it
<andrewrk> what do you mean adding it?
<Akuli> replace the allocator line with that
<andrewrk> so not even using it
<Akuli> yes
<Akuli> lets guess: something is calculating stack sizes or indexes or whatever incorrectly, and adding a large enough object on the stack happens to "fix" it so that valgrind doesn't notice that anything is wrong
<andrewrk> this is either a bug in zig or a bug in valgrind
<Akuli> i still don't know what --library c has to do with this
<Akuli> it fixes it every time, somehow
<andrewrk> it's the opposite for me. --library c makes the valgrind errors show up
<Akuli> umm yes
<Akuli> more like, deleting it fixes the stuff
<andrewrk> Akuli, do you know about --disable-valgrind?
<Akuli> no
<andrewrk> that turns off the thing where zig teaches valgrind what `foo = undefined;` means
<Akuli> errors seem to be coming anyway
<andrewrk> right. so that points to a bug in valgrind rather than zig
<Akuli> i first noticed this when a random number generator generated the same random numbers every time
<Akuli> when not running under valgrind
<Akuli> then i valgrinded it and it was reading uninitialized memory
<Akuli> maybe i was doing something else wrong then
<andrewrk> your example in #2061 looks fine
<andrewrk> uh oh
<andrewrk> I know what this is :(
<andrewrk> this is one of the 2 documented design flaws of zig
<andrewrk> which is planned to be fixed somehow
<andrewrk> related to no-copy semantics changes coming soon
<Akuli> so which member variable is the problem? is it Lel.rnd?
<Akuli> or does the compiler think that default_prng isn't needed anymore after something happens?
Avila has joined #zig
<man213> andrewrk, zig builds from sources in two minutes on my machine, wow (I do not take llvm build time into account, huh)
Avila has quit [Quit: Leaving]
<andrewrk> man213, if you build the (work in progress) self hosted compiler along with that, it adds about 10 more seconds to the build ;)
<andrewrk> Akuli, did you see the diff? the problem is copying the Random interface field
<andrewrk> I think this will be fixed with a way to annotate fields as "nocopy"
<Akuli> i thought that it's just a pointer so it doesn't matter?
Flaminator has joined #zig
<andrewrk> #591 explains it
<andrewrk> it's not a pointer
<Akuli> so the problem is on the line where i get the .random into a local variable?
<Akuli> would this fix? const rnd = &default_prng.random;
<Akuli> with & in the front
<andrewrk> yes, did you see the diff ?
<Akuli> umm lol nevermind
<Akuli> i didn't notice that you edited the comment
<andrewrk> ah, apologies. should have made a new comment
<Akuli> thanks for all this! :D
<Akuli> this would have taken me a looooong time to notice what's wrong
<andrewrk> it's planned for a compile error to catch this in the future. hopefully in the 0.5.0 release
<Akuli> but now that i see this i can see why it could be wrong
<Akuli> in c++ (ewww), this would implicitly invoke the copy constructor
<andrewrk> right
<emekankurumeh[m]> wouldn't this be solved by a different interface pattern?
<emekankurumeh[m]> on a side note would that nocopy annotations be similar to pin/unpin in rust?
<andrewrk> emekankurumeh[m], see this issue is also blocking on no-copy semantics
Ichorio has joined #zig
Akuli has quit [Quit: Leaving]
<man213> andrewrk, I've managed to break debug build too, yay!
<man213> andrewrk, The trouble hides somewhere in std.rand
<man213> Or I'm doing something incorrect with it
<man213> Need to research further but I'm 90% sure that it has nothing to do with runtime safety checks
<andrewrk> man213, I believe it's exactly the same issue that Akuli just ran into above
<man213> andrewrk, yeah, that is it
<andrewrk> have a look at and also the IRC logs are relevant
<andrewrk> sorry about the design flaw; know that I definitely consider it really important and I have high confidence it will be fixed in 0.5.0
jjido has joined #zig
halosghost has quit [Quit: WeeChat 2.4]
Ichorio has quit [Ping timeout: 244 seconds]
darithorn has quit [Remote host closed the connection]
return0e_ has quit [Ping timeout: 252 seconds]
return0e has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
develonepi3 has quit [Quit: Leaving]
man213 has quit [Ping timeout: 256 seconds]
torque has quit [Remote host closed the connection]
torque has joined #zig
diltsman has joined #zig
<diltsman> How would I replace exe.setTarget(builtin.Arch.armv7m, builtin.Os.freestanding, builtin.Environ.eabi); when building with HEAD?
<daurnimator> andrewrk: heh. I was the one that pointed you to midipix I think
<daurnimator> oh he's not in the channel any more :(
<andrewrk> diltsman, exe.setTarget(builtin.Arch {.arm = builtin.Arch.Arm64.v7m}, builtin.Os.freestanding, builtin.Abi.eabi)
<andrewrk> this will make that a lot more convenient:
<andrewrk> daurnimator, I must have missed it before
<daurnimator> andrewrk: re: #591. I had the same idea as was about to type it up but found it there already....
<andrewrk> yeah that's a good proposal
<daurnimator> I was going to call it `nocopy` instead of `fixed` :P
<Flaminator> IMO `fixed` and `nocopy` mean 2 different things.
<andrewrk> Flaminator, explain?
<daurnimator> Flaminator: which one means "this member is not allowed to be copied"
<Flaminator> That would be nocopy daurnimator. For me fixed would mean it's stuck and you can't move it around but you can make a copy of it, while nocopy means you can move it around you just can't make an extra copy of it.
<daurnimator> Flaminator: what does 'move it around' mean?
<daurnimator> in a computer; moving *is* copying...
<Flaminator> Bad analogy incoming: imagine a room, there is a box on the floor and a pilar that is stuck to the floor and the ceiling. You can move the box around from one position in the room to another while the pilar is fixed in that same position and can't be moved around.
<daurnimator> Flaminator: I'm not sure what is the box/room/pillar in this analogy
<Flaminator> The room is for example 200 bytes of memory and the box and the pillar are a byte each located in those 200 byes.
<daurnimator> Flaminator: struct layout is static in zig: members don't move around the struct.
<daurnimator> (it's undefined *where* they are; but they don't move once a location is picked)
<andrewrk> if you copy bytes, then treat the newly copied bytes (which are in a different location) as a valid object, then according to the perspective of that object, it has moved
<andrewrk> if you put me in a cloning chamber, and then when the clone of me walks out of the other cloning chamber, he's going to think he teleported
<Flaminator> I don't really know what the nocopy/fixed thing is for though, was only saying that the words have a different meaning too me.
<diltsman> It appears that build results are now in zig-cache/o/<CRAZY STUFFS!>/
commander has quit [Remote host closed the connection]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andrewrk> diltsman, is it working ok for you? you can override it
<diltsman> New behavior. Just was unexpected.
<andrewrk> if you try your `zig build` commands a few times in a row you should see that everything is cached
<diltsman> Right.
<andrewrk> and try making a change in any file - .zig, .h, or use a different version of zig, anything! - and only what needs to get rebuilt will