ChanServ changed the topic of #zig to: zig programming language | https://ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
mahmudov has quit [Remote host closed the connection]
<daurnimator> andrewrk: it gets a bit tricky for 64 bit time; e.g. we need to redefine our `struct timespec`.... and then we change/edit `extern "c"` definitions to match
<andrewrk> what `extern "c"` definitions are you referring to?
<daurnimator> andrewrk: e.g. `pub extern "c" fn nanosleep(rqtp: *const timespec, rmtp: ?*timespec) c_int;` in std/c.zig
mht has quit [Ping timeout: 252 seconds]
mht has joined #zig
_Vi has quit [Ping timeout: 256 seconds]
ur5us has quit [Remote host closed the connection]
ur5us has joined #zig
frmdstryr has joined #zig
frmdstryr has quit [Quit: Konversation terminated!]
joey152 has quit [Remote host closed the connection]
waleee-cl has quit [Quit: Connection closed for inactivity]
<daurnimator> andrewrk: any particular comment in #265?
<pixelherodev> How do I migrate from `setTheTarget(.{.Cross=.{}})`?
<daurnimator> andrewrk: did you see my comment on #4612 ?
<pixelherodev> Wanted to get back to work on ZigIRRat but build is broken and that hurt motivation :(
<daurnimator> pixelherodev: `setTarget(.{})`
<pixelherodev> Doesn't work - targeting `i386-freestanding`
<pixelherodev> This is for generating test IR to run the AST on
<pixelherodev> s/AST/AST generator
<daurnimator> pixelherodev: "doesn't work"?
<pixelherodev> `setTarget(.{})` <- did you mean that I should move what was in the .Cross struct into there?
<daurnimator> pixelherodev: yep.
<pixelherodev> `./build.zig:22:9: error: no member named 'arch' in struct 'std.zig.cross_target.CrossTarget'` (.arch = .i386)
<daurnimator> pixelherodev: .arch was moved inside of .cpu
* pixelherodev sighs
<pixelherodev> Well, might as well do this now
<pixelherodev> Thanks
<daurnimator> oh. .cpu was flattened?
<andrewrk> this might actually help you because you can now set a default target
<andrewrk> const target = b.standardTargetOptions(.{}); foo.setTarget(target);
<andrewrk> or you can just hard code a CrossTarget
<andrewrk> daurnimator, you might be mixing up std.Target and std.zig.CrossTarget
<pixelherodev> Right but I don't *want* a standard target for the builder; I'm targeting *three different targets* :P
<pixelherodev> Generating native binary for test library frontend, i386 test binary, and ... well, it's technically still marked as i386 but the third is a custom ISA I'm testing
<pixelherodev> It's 32-bit so i386 maps "close enough"
<pixelherodev> Zig 0.6 will be mid-April, right? I'm thinking I'll stick to 0.6 (and maybe backport bugfixes from trunk on a local branch) when it's released :P
<andrewrk> so you probably want to use that whitelist feature then
<pixelherodev> The what?
<pixelherodev> CPU features whitelist?
<andrewrk> never mind. what was `setTheTarget(.{.Cross=.{}})` even doing? that doesn't look valid to me. there were no default values for those fields
<andrewrk> yes that was still std.Target. now there is a new struct, std.zig.CrossTarget
<pixelherodev> andrewrk, I had actual values in there but didn't consider them relevant to the question
<andrewrk> if you give the actual example I can give you the actual code to update it to
<pixelherodev> Basically just i386-freestanding
<pixelherodev> {.arch = .i386, .os = .freestanding, .abi = .none, .cpu_features = (zag.Target.Arch.i386).getBaselineCpuFeatures()`
<andrewrk> setTarget(.{.cpu_arch = .i386, .os_tag = .freestanding, .abi = .none})
<andrewrk> the cpu features thing is not needed anymore
<pixelherodev> Yay!
<pixelherodev> Thanks!
<pixelherodev> ... and now I run into a compiler regression :(
<pixelherodev> I'll bisect later
<pixelherodev> `Assertion failed at ../src/buffer.hpp:37 in buf_ptr. This is a bug in the Zig compiler`
<pixelherodev> The frontend builds, it's only that i386-freestanding LLVM IR that fails...
<andrewrk> that assertion looks like it might have a straightforward fix
<andrewrk> I'll be happy to look into this before the release. that goes for anyone btw, if you have a regression and your project isn't building
<pixelherodev> Going to try trunk again
<pixelherodev> It's possible I broke it when bisecting a different issue :P
ur5us has quit [Ping timeout: 240 seconds]
<pixelherodev> Yep, now I have an entirely *different* error!
* pixelherodev goes away for a bit to fix these. I'll be back.
<pixelherodev> ... nope that's still there too
<pixelherodev> Just had a pleasant surprise with streams :)
<pixelherodev> (inStream() now gives what was previously inStream().stream?! YAY!)
<pixelherodev> I'll look into the bug myself real quick
<daurnimator> andrewrk: we broke every zig hello-world with the change in signature of file.write.
<pixelherodev> What happened?
<pixelherodev> I've clearly missed a *lot*
<daurnimator> pixelherodev: write() on posix systems can return with a partial write -> file.write now returns number of bytes written instead of void
<andrewrk> daurnimator, correct
<andrewrk> hello world from 0.5.0 -> master already had 1 breaking change. so think of it like buy 1 get 1 free
<daurnimator> not great for all the misc blog posts out there :(
<Nilium> Is std.Target only defined in specific cases? Kind of confused at why it's missing from std.zig in the Homebrew package but present in the 0.5.0 docs.
<andrewrk> Nilium, std.zig never had Target
<daurnimator> huh?
<daurnimator> even today in builtin we spit out `/// Deprecated: use `std.Target.cpu.arch`
<Nilium> I mean, it might not be part of the source, hence why I'm asking
<Nilium> I couldn't figure out how to use it in build.zig, since it doesn't seem to exist in std
<Nilium> So maybe the homebrew package is borked...
<Nilium> Yeah - that's a different one than I'm referring to.
<Nilium> The one I'm referring to is what daurnimator mentioned.
<daurnimator> Nilium: do you have the 0.5.0 package? or master? (or old master?)
<Nilium> 0.5.0
<Nilium> Hang on, let me grab the other laptop
<andrewrk> Nilium, 0.5.0 doesn't have std.Target
<andrewrk> where do you see it in the docs?
<Nilium> I'm trying to find the link I followed to get the stdlib docs.
<Nilium> Yeah, looks like it's the master docs, so that explains it
<Nilium> OK, so probably just.. always use master.
<Nilium> Seems like it's hard to follow things otherwise.
<andrewrk> 0.6.0 will be a nice release to stick to, at least for a few months
<Nilium> I mean, this is normal for pre-1.0 languages, so nothing wrong with it.
<andrewrk> I'm really not worried about breaking hello world, or anything else, pre-1.0. there is nothing more important than getting the language and std lib correct before stabilizing
<Nilium> I agree.
<pixelherodev> andrewrk, found the bug - it only occurs with `--no-emit-bin`
<pixelherodev> src/main.cpp:1306 calls `buf_ptr(&g->bin_file_output_path)`, which is of course empty because there *is* no such path
<pixelherodev> Wait no... that's where the crash is happening, but I don't follow the logic looking back
<pixelherodev> Ah wait never mind - the call I thought ruined that logic chain only occurs on Windows
<daurnimator> I generally have found that I can stick on a zig release for ~2.5 months before it gets too out of sync with master
<Nilium> Yeah. It’s not a problem with anything other than me having mismatched information.
tgschultz has quit [Ping timeout: 256 seconds]
tgschultz has joined #zig
frett27 has joined #zig
dddddd has quit [Ping timeout: 258 seconds]
slurpie has joined #zig
_Vi has joined #zig
return0e has joined #zig
return0e has quit [Remote host closed the connection]
tdc has joined #zig
frett27 has quit [Ping timeout: 258 seconds]
knebulae has quit [Read error: Connection reset by peer]
daex has quit [Ping timeout: 255 seconds]
daex has joined #zig
daex has quit [Ping timeout: 258 seconds]
daex has joined #zig
_Vi has quit [Ping timeout: 240 seconds]
knebulae has joined #zig
marmotini_ has joined #zig
marmotini_ has quit [Ping timeout: 256 seconds]
marijnfs has joined #zig
slurpie has quit [Ping timeout: 265 seconds]
daex has quit [Ping timeout: 265 seconds]
daex has joined #zig
marmotini_ has joined #zig
bryanhonof has joined #zig
msaud has joined #zig
msaud has left #zig [#zig]
_Vi has joined #zig
waleee-cl has joined #zig
dddddd has joined #zig
dingenskirchen has quit [Ping timeout: 240 seconds]
frmdstryr has joined #zig
slurpie has joined #zig
marmotini_ has quit [Remote host closed the connection]
bryanhonof has quit [Remote host closed the connection]
FireFox317 has joined #zig
slurpie has quit [Ping timeout: 256 seconds]
FireFox317 has quit [Remote host closed the connection]
dingenskirchen has joined #zig
wootehfoot has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
dingenskirchen has quit [Read error: Connection reset by peer]
dingenskirchen1 has joined #zig
dingenskirchen1 is now known as dingenskirchen
jessermeyer has joined #zig
jessermeyer has quit [Remote host closed the connection]
jessermeyer has joined #zig
<fengb> Whoa no feedback, just merge? >_>
<andrewrk> what kind of feedback were you expecting?
<fengb> "Hey you suck"
<fengb> I don't know. I just dont expect my first round to be okay :P
<andrewrk> I did sneak a "fixup" commit in there if you didn't see it
<fengb> How will I learn if you fix stuff for me? >_>
<andrewrk> I don't really see it that way. sometimes it's harder for contributors to make certain kinds of changes, e.g. breaking changes, and it has nothing to do with learning/skill and more to do with the structure of decision making
<fengb> Ah I see
<fengb> Basically all my questions were answered heh. Okay thanks
<andrewrk> thanks for the patch :)
<fengb> Thanks for letting me experiment like this :)
TheLemonMan has joined #zig
mattmurr has quit [Quit: ZNC 1.7.5 - https://znc.in]
mahmudov has joined #zig
<jessermeyer> I need to explicitly pass 'self' parameters when using std functions, right? e.g fn openFile(self: Dir, sub_path: []const u8, flags: OpenFlags)... I can't just do std.fs.Dir.openFile("/path/to/file.txt");
<andrewrk> you could do std.fs.cwd().openFile("/path/to/file.txt")
<andrewrk> but if you have an absolute directory then you can use std.fs.openFileAbsolute
<jessermeyer> Yeeeaah was just about to suggest that to myself, after looking up examples in the standard library.
<jessermeyer> Right.
<TheLemonMan> ooh, Travis offers a ppc64le CI for open-source projects
<euantor> I believe sr.ht is going to offer ppc64le at some point too - there was talk in the channel about them having a system from Raptor CS that was going to become a build slave eventually
marmotini_ has joined #zig
marmotini_ has quit [Ping timeout: 260 seconds]
<TheLemonMan> Raptor systems are quite cool as they are pricey
FireFox317 has joined #zig
<pixelherodev> Is it possible to send patches to the Zig mailing list on SourceHut instead of opening GitHub PRs? I'm moving as far away from GitHub as I can given their, uh, "brilliant" decision to make the notifications API worse
<pixelherodev> s/API/UI
<andrewrk> yes you can send patches however you like
SimonN has quit [Remote host closed the connection]
<andrewrk> but as usual, the easier you make the patch to merge, the more likely it gets merged sooner
<pixelherodev> Right, that's reasonable
frmdstryr has quit [Remote host closed the connection]
<TheLemonMan> uh? what's up with the GH notifications?
<pixelherodev> They're torturing the UI
<TheLemonMan> *shrug* I only use emails to keep track of GH notifications, I had never seen the old UI
<andrewrk> same
<pixelherodev> There are too many Zig notifications alone to go through them by email for me
<TheLemonMan> andrewrk, golang solves the "lightweight-loop" problem by double-locking a mutex, that's really smart
_Vi has quit [Ping timeout: 240 seconds]
<andrewrk> thanks, despite seeming simple that took me a good 15 minutes of chin-scratching to come up with
<andrewrk> #4731 is a really nice improvement. it's going to be quite handy when debugging multi threaded event loops
<TheLemonMan> but the stdlib mutex don't have a blocking acquire :(
<TheLemonMan> yeah I wrote that as I was playing around with the event loop on FreeBSD
<andrewrk> why do you think it doesn't?
<TheLemonMan> eh because I'm dumb and was reading the single_threaded implementation of Mutex
<andrewrk> yeah the single-threaded use case is why to check if the atomicrmw is 0 above, rather than simply double-acquire
<andrewrk> pixelherodev, I really don't understand that criticism, can't he just resize his browser window to be smaller
<andrewrk> just checked... it works fine
<pixelherodev> Not if you're using a tiled window manager (which I do as well)
<pixelherodev> I had the same problem
<pixelherodev> (for the brief minutes where I tested it)
Akuli has joined #zig
<TheLemonMan> andrewrk, I've pushed a slightly different approach
<pixelherodev> And I think the "it blends notifications from multiple repos together" part was more of a concern anyways
<TheLemonMan> no global mutex, I create one in the loop scope and deadlock there
<TheLemonMan> in single-thread mode that path is never taken as the panicked goes back to 0
<pixelherodev> `The title of the notification no longer stands out, as it’s the same size as the name of the repo that was affected. They’re no longer grouped by repo, either, so I have to read both every time to get the full context.`
<pixelherodev> ^
<TheLemonMan> you can probably write your own notification display with a few lines of code
<andrewrk> TheLemonMan, this is definitely an improvement over status quo and I'd be happy to merge as is, but do you think it might make sense to make deadlocking a mutex Illegal Behavior? this way if we ever wanted to improve debug mode mutexes we could add some (optional?) debugging features to them
<andrewrk> we already do this for --single-threaded
<andrewrk> this adds a dependency on defining the behavior of double-locking a mutex with the same thread to be a deadlock, rather than Don't Do This, And Tools Will Help You Debug It If You Do
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
<TheLemonMan> *shrug* I have no idea if people rely on this kind of tricks in the wild
<andrewrk> the beauty of the approach I outlined is that it doesn't depend on same-thread deadlocking - it only relies on "normal" mutex behavior of thread(s) waiting on other(s)
<TheLemonMan> the idle loop could be replaced with an evel simpler `while (true) sleep(a_lot);` if we don't want to stray into the IB realm
<pixelherodev> To clarify my message from this morning: `src/main.cpp:1306 calls `buf_ptr(&g->bin_file_output_path)`, which is of course empty because there *is* no such path` <- that *is* the bug]
<pixelherodev> My thought that it was *wrong* is what I corrected as itself incorrect
<andrewrk> TheLemonMan, but this is a default panic handler and sleep() has a more difficult OS dependency than Mutex
<TheLemonMan> same-thread deadlocking means we also have to store the thread id somewhere... that may bloat the parking-lot mutex
<andrewrk> as an example, --single-threaded Mutex has no OS dependency, but sleep() still would
<TheLemonMan> hm, gotcha
<TheLemonMan> we also have some kind of OS (or better, ABI) dependency since `threadlocal` is used
<TheLemonMan> I don't really expect bare-metal/OS-less people to use the default handler
<pixelherodev> What does `--single-threaded` actually *do*?
<pixelherodev> Ah, it's in the docs :) Thanks!
<andrewrk> TheLemonMan, based on my understanding, OS's that have multi-threading generally support thread local variables, and ones that don't we make --single-threaded the default (and therefore thread local variables become simply globals)
<andrewrk> oh, I see the flaw in my approach
<andrewrk> the first one to increment panicking is not necessarily the correct one to call abort()
<TheLemonMan> yeah, `panicking` is a rough count of how many waiting threads there are
<TheLemonMan> I spent a lot of time tracking down a bug in a previous implementation because I was sure @atomicRmw returned the new value
<andrewrk> ok I think your latest iteration is good to merge
<andrewrk> I think my approach was fine, but it does possibly result in the same thread locking the same mutex and expecting a deadlock. so it's not better than the simpler approach you have
<TheLemonMan> hmm, what if we just use a `ResetEvent` ?
<andrewrk> that sounds right
<TheLemonMan> thank you kprotty
<andrewrk> indeed
<TheLemonMan> enforcing the mutex lock/unlock thread to be the same is an interesting idea tho
<andrewrk> yeah. I think the language and std lib should help debug multi-threaded software
<andrewrk> we don't have the nice multi-threaded guarantees like rust, so the least we can do is provide helpful debugging tools
slurpie has joined #zig
hsh has joined #zig
<FireFox317> how do i get llvm10? can i just clone llvm-project and checkout `release/10.x`?
<FireFox317> or is there an easier way?
<andrewrk> FireFox317, release/10.x branch is your best bet right now since it's not released yet
<FireFox317> andrewrk, thanks!
<pixelherodev> Testing a fix for that issue I was having
<FireFox317> its not possible to build llvm with cmake anymore :(
<andrewrk> it worked for me
<FireFox317> nvm
<FireFox317> wrong dir lol
<andrewrk> oh nice, they just cut rc4
frett27 has joined #zig
<andrewrk> like, minutes ago
<FireFox317> rc4 is probably gonna be the one thats gonna be released right?
<andrewrk> likely
<andrewrk> i'm merging master into llvm10 for you
<FireFox317> ah cool, im working on some riscv stuff and i hope llvm10 is gonna solve some things that arent working now
<TheLemonMan> riscv stuff? spill the beans!
jessermeyer has quit [Remote host closed the connection]
<FireFox317> risc-v operating system, starting simple with something like xv6, but finally i want it to work on my own fpga :)
jessermeyer has joined #zig
<TheLemonMan> cool! syntesized CPUs are awesome
<pixelherodev> Okay, fixed the problem with building for i386, but now my build.zig is crashing ``/usr/local/lib/zig/std/build.zig:2157:63` "attempted to use null value" :(
<BaroqueLarouche> do I need to compile LLVM 10 right now if you merge the llvm10 into master ?
<TheLemonMan> master into llvm10
<TheLemonMan> not the other way around
<BaroqueLarouche> oh
<BaroqueLarouche> read too fast
<andrewrk> llvm10 branch has master merged in, I just did it
<andrewrk> we merge llvm10 into master as soon as llvm 10 is officially released
<andrewrk> at that point building llvm/clang/lld from source could be the easiest way to obtain a source build, but you can also expect ziglang.org/downloads to work
<andrewrk> and that is because I manually go and build llvm from source for all the ci machines
<TheLemonMan> oh I was about to ask if you compiled llvm9 on freebsd yourself
<TheLemonMan> NetBSD wins, it compiled just fine with llvm/clang installed from ports
<andrewrk> thanks pixelherodev
<pixelherodev> Yeah no problem
<pixelherodev> Thought it would be an easy fix like that
<pixelherodev> Now to figure out the next failure :(
<andrewrk> TheLemonMan, yeah I just pay a couple bucks for a high performance server for 2 hours
<andrewrk> just to upload that tarball for the CI
<andrewrk> pixelherodev, it's related to the other change... the build system is expecting the compiler to print the path to the build artifact
<pixelherodev> But - that doesn't make sense anymore
<pixelherodev> Given that there can be (deliberately) multiple artifacts
<pixelherodev> e.g. binary, LLVM IR, and assembly
<andrewrk> yeah it should just print the output dir not a specific build artifact
<pixelherodev> Ah
<andrewrk> that's all the build system wants anyway
<pixelherodev> Will take a bit for me to find where that happens
<pixelherodev> Ahh, I get it. It's the same change I just made
<pixelherodev> Wait
<pixelherodev> Why is there a different path for the different output types?
<pixelherodev> Shouldn't they all be output to the same folder?
<pixelherodev> Think I got it
<pixelherodev> Well, not an understanding of that
<pixelherodev> But a fix
<pixelherodev> for the build.zig failure
<pixelherodev> Got it working, but it's working around the fact there are multiple paths instead of consolidating them, which it really should IMO
mattmurr has joined #zig
jessermeyer has quit [Remote host closed the connection]
return0e has joined #zig
return0__ has quit [Ping timeout: 268 seconds]
<FireFox317> hmm andrewrk, i'm getting build errors when building zig with llvm10. has to do with lld, i guess its because now its using my system lld?
<FireFox317> fixed :)
<FireFox317> Niceeee, llvm10 fixed the issue yeahh
daex has quit [Ping timeout: 240 seconds]
daex has joined #zig
_Vi has joined #zig
ur5us has joined #zig
frett27 has quit [Ping timeout: 258 seconds]
jjido has joined #zig
Akuli has quit [Quit: Leaving]
mahmudov has quit [Remote host closed the connection]
mahmudov has joined #zig
tdc has quit [Ping timeout: 265 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
urluck has quit [Ping timeout: 246 seconds]
SimonNa has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
marijnfs has quit [Ping timeout: 240 seconds]
ur5us has quit [Quit: Leaving]
ur5us has joined #zig
<nrdmn> since mid november (47f06be36 / "string literals are now null terminated") my uefi/freetype programs don't work any more
jjido has joined #zig
FireFox317 has quit [Ping timeout: 258 seconds]
urluck has joined #zig
<andrewrk> nrdmn, any clues?
<nrdmn> andrewrk: nope, not yet
<andrewrk> it's pretty difficult to observe any side effects from those changes
ky0ko has quit [Ping timeout: 268 seconds]