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/
qazo has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
mooch has joined #zig
mahmudov has quit [Remote host closed the connection]
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
<mooch> hey, when i'm using zig build run,
<mooch> how do i pass arguments to my program?
<mikdusan> currently something like this: `if (b.args) |args| run_cmd.addArgs(args);`
<mikdusan> and from command line `zig build run -- one two three`
<mooch> okay, thank you
mooch has quit [Read error: Connection reset by peer]
BaroqueLarouche has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
forgot-password has quit [Ping timeout: 268 seconds]
epmills has joined #zig
epmills_ has joined #zig
epmills has quit [Ping timeout: 265 seconds]
forgot-password has joined #zig
euandreh has quit [Ping timeout: 272 seconds]
forgot-password has quit [Ping timeout: 272 seconds]
<pixelherodev> andrewrk, thanks for that freestanding debug info fix!
ky0ko_ has quit [Remote host closed the connection]
<daurnimator> andrewrk: yes. that's why I'm using generic_rv32
forgot-password has joined #zig
<andrewrk> "generic" is overloaded here
epmills_ has quit [Remote host closed the connection]
rageoholic has joined #zig
<rageoholic> Hi. I'm getting an error where I can't include vcruntime.h or other compiler specific include files
<rageoholic> How can I fix this
<daurnimator> rageoholic: are you linking libc ?
<rageoholic> Yup
<daurnimator> What is your host and what is your target?
<rageoholic> Windows for both
<rageoholic> x64
forgot-p1ssword has joined #zig
<daurnimator> `zig libc` ?
<rageoholic> What about it?
<daurnimator> what is the output?
<rageoholic> sys_include_dir=C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\lib\x64\..\..\include
forgot-password has quit [Ping timeout: 260 seconds]
<daurnimator> and is that correct?
<rageoholic> Yup
<rageoholic> I even reinstalled zig and rebooted my machine. I don't wanna purge VS too
<mikdusan> check and compare the possible locations for cached versions of that information. `zig-cache/native_libc.txt` and `%LOCALAPPDATA%/zig/stage1/native_libc.txt`
<mikdusan> you can safely delete them.
<rageoholic> OK we're good
<rageoholic> Thank you
<mikdusan> let me guess, you upgraded the compiler recently
<rageoholic> Yeah VS updated
<rageoholic> Cannot wait till I can just do audio and video in zig standalone. Even if I have to write my own platform layers to do it
<rageoholic> You know what
<rageoholic> Fuck it
<rageoholic> I'm going to do it
<rageoholic> After this project I'm going to make a Zig only SDL-like
forgot-p1ssword has quit [Ping timeout: 268 seconds]
<rageoholic> Sorta like Sokol
<pixelherodev> Zokol?
<pixelherodev> :P
qazo has quit [Read error: Connection reset by peer]
<shakesoda> rageoholic: many pains await you, best of luck
<daurnimator> rageoholic: indeed. this will hurt alot. enjoy :)
<daurnimator> rageoholic: ps, check out arcan
rageoholic has quit [Remote host closed the connection]
<fengb> `raw: 16[u8]` I think it's time for me to give up for the night
<pixelherodev> :P
<pixelherodev> Not all of us have that luxury
<pixelherodev> Major deadline tomorrow, and the *freaking communications layer is broken*
<pixelherodev> So I'm hacking together a debugging interface over an external UART <-> converter I found in my spare parts drawer :panic:
<shakesoda> pixelherodev: D:
<pixelherodev> Don't worry, I see how it would be amusing if it wasn't happening to *me*
<shakesoda> much as i find doing uart stuff actually kind of fun, not with an impending deadline
<pixelherodev> I'm literally just hacking together a fake printf that uses vsprintf + dump_to_xuart
<pixelherodev> Then rewriting the currently commented-out printfs to go through a #defined print function that either goes to printf (on PC) or hacked_together_mess (ESP8266)
<daurnimator> https://lwn.net/Articles/808595/ <== made me think about how we handle signalling NaN in zig
mooch has joined #zig
adamkowalski has joined #zig
<pixelherodev> That's interesting
<pixelherodev> How does the handling work now?
<pixelherodev> On a different note, in seeking to fix this communications error, I accidentally fixed an entirely different bug that was butchering the performance of the "simulated" MCU I was using for testing :)
<adamkowalski> How do you check if two enums have the same active tag?
<adamkowalski> without nested switch statements*
<pixelherodev> Wait, do you mean unions?
<adamkowalski> yeah union(enum)
<pixelherodev> Pretty sure you can retrieve the tag
<pixelherodev> Though I don't remember how
<adamkowalski> I want to compare two of them for equality, so I want to say their tags must match, or return false. If their tags match check their data members
<pixelherodev> Yeah, @as(enum_type, u1) == @as(enum_type, u2)
<pixelherodev> Where u1 and u2 are both tagged unions which have enum_type as the tag type
<adamkowalski> actually I think std.meta.eql does the job in this case
<pixelherodev> That works too, probably
<adamkowalski> how would @as(enum_type, u1) work? that would only work if it's not a union(enum) just a regular enum right?
<adamkowalski> I feel like you need to extract the tag out of the union(enum) first then compare as an int
<pixelherodev> No
<pixelherodev> `@as(tag_type, union_tagged)` gives the tag
<adamkowalski> ah perfect so I could do @as(@TagType(T), u)?
<adamkowalski> thanks!
<pixelherodev> Yeah
<pixelherodev> Well
<pixelherodev> Yeah
<pixelherodev> Or even @as(@TagType(@TypeOf(u)), u)
<pixelherodev> That works even in a comptime function where `u` is of type var and all you know is that `u` is a tagged union,
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
<pixelherodev> Oh my god it's communicating! ... occasionally. About 70% of packets fail to transmit properly, but 30% functional is better than 0% functional!
<adamkowalski> awesome! what are you building?
<pixelherodev> A medical device thingy - can't say too much though, because the whole reason I have to stay up and get it done tonight is that there's a potential investor
<adamkowalski> that sounds exciting. good luck
<pixelherodev> I can definitely go into details of how it *works* though, which is the cool part anyways
<pixelherodev> The client frontend is in Zig, which is nice :)
<pixelherodev> but the protocol library and the MCU parts are in C, because I wasn't about to rely on LLVM-xtensa
<adamkowalski> I'm not sure if you all are using any machine learning, but I had a big breakthrough in my library (compute graph). I finally implemented reverse mode automatic differentiation so you can take derivatives of scalars/vectors/matrices/nd tensors automatically!
<adamkowalski> watch out python/tensorflow, neural networks in pure zig are around the corner
<pixelherodev> Nooooo
<pixelherodev> ... not because I use python / tensorflow
<pixelherodev> I'm just opposed to neural networks on principle
<adamkowalski> haha, yeah but this library has nothing to do with neural networks. It's linear algebra + automatic differentiation
<adamkowalski> you can build neural networks on anything else you want on top of them
<pixelherodev> You say machine learning I hear computer program that wastes insane amounts of processing power on an RNG
<adamkowalski> I recommend using models which are explainable, but you learn the parameters using gradient descent
<adamkowalski> thats what we do in my industry since we have to be able to legally explain why our models make the decisions they made
<adamkowalski> for example solving the initial conditions of a differntial equation using backprop. but the actual model is easy to understand and explain to domain experts
<pixelherodev> I don't think NNs should be used in any way other than to research a problem space
<pixelherodev> Anything that can be solved with NNs *can* be solved classically, even if its more work
<pixelherodev> and solving it properly means a better understanding of the problem
<adamkowalski> I'm not sure I agree, I think people who apply them blindly without understanding how they work are the issue
<pixelherodev> I had this debate recently elsewhere, give me a sec to grab a screenshot of what I argued there instead of rehashing the whole thing again - I'd rather you responsed to points I've already made than go over them again
<adamkowalski> if you understand the math behind it, they are fairly straightforward and can be applied to many different tasks very effictively and honestly share a lot in common with "classical methods"
<adamkowalski> for example computer vision is "classically" solved with hand engineered kernels that you use for your convolutions, but learning the kernels using data is fine
<pixelherodev> But it also is a massive waste of resources
<pixelherodev> "programmer time is more expensive than CPU time" is just a fancier way of saying "we're wasting tons of CPU time"
<adamkowalski> thats an implementation detail, people who say that are lazy
<pixelherodev> It's really really not
<adamkowalski> at work we have very few data points so we need to be able to extract all the juice possible out of just a few (10 points) data points
<pixelherodev> It's fundamentally more expensive to use NNs than classical programming
<adamkowalski> we use bayes rule + differentiable programming (optimaztion using gradient descent) to be able to leverage prior knowledge but allow the data to overwhelm them if they are vastly different
<pixelherodev> If the NN can figure it out, so can engineers
<pixelherodev> My fundamental argument is that relying on NNs isn't really scientific - instead of researching the problem and devising the solution, we set up a computer to guess-and-check and use that data to calibrate what is effectively an RNG
<daurnimator> hey now.... engineers can be RNG too
<adamkowalski> anyway, different strokes for different folks I guess. I'm interested in solving problems that require using the right tool for the job. Some things are learned from data, others are done using heurisitic and large sets of rules implemented by the programmers. Either way it's very rigirous engineering and I would be foolish to ignore a solution just it's implemented one way or another
<pixelherodev> Reasonable
<pixelherodev> As I've said a thousand times, every argument about tech - programming languages, NNs, whatever - ultimately comes down to totally subjective values
<pixelherodev> ... ugh. This communications layer is failing for the stupidest reason possible
<pixelherodev> The protocol code tries to wait until enough bytes are available to continue - which is approximately 11 for a standard packet.
<pixelherodev> The external UART feeds info on demand
<pixelherodev> So the buffer is never full until I actually try reading
<pixelherodev> It'd be amusing if not for the fact that it's requiring serious code restructuring
adamkowalski has quit [Remote host closed the connection]
<mq32> pixelherodev, thanks for showing me that i'm not a lone guy not liking NNs for everything :D
<pixelherodev> Huh. GDB is actually working. That's unexpected.
<mq32> \o/
<pixelherodev> Over serial to the MCU
<daurnimator> pixelherodev: ooooo I'm doing the same thing right now :D
<pixelherodev> `value has been optimized out` *exhaustion*
<pixelherodev> On the bright side, I was right that optimizations would make this just as efficient as a C++ abstraction?
metaleap has joined #zig
_Vi has joined #zig
<pixelherodev> daurnimator, does yours also involve a situation where GDB actually functions... but isn't usable anyways due to timing issues?
<daurnimator> almost!
<pixelherodev> Since the code I'm debugging is extremely timing-heavy - all work is done in *ms*, and a reply is expected in that time - it times out while I debug
<daurnimator> I'm having issues where something goes wrong after ~20ms of running and then stops responding to gdb
<pixelherodev> Ah, even more fun :)
<pixelherodev> Huh. This is... weird.
<pixelherodev> If I run GDB and then hit continue... *everything works*.
<pixelherodev> Communication over the XUART is 100% reliable, despite the fact that GDB doesn't touch it.
<pixelherodev> Okay so... like 90% reliable. Still much better
<pixelherodev> ... and also there's a memory leak, which explains a lot.
<pixelherodev> Still, I'm mildly surprised the OOM catching behavior functioned
<pixelherodev> Good news is, I know what I need to do; bad news is, this is *not* going to be fun. `valgrind` galore.
metaleap has quit [Quit: Leaving]
mq32 has quit [Ping timeout: 265 seconds]
<pixelherodev> Or, maybe, I shouldn't be surprised that it *incorrectly* reported OOM, and there are *zero* memory leaks
<pixelherodev> *none*.
<pixelherodev> Correction: none in *my* code. There's a surprising number in e.g. the intel graphics driver :P
<pixelherodev> The only memory bug was actually caused by non null-terminated strings getting printed and thus strlen()ed
<shakesoda> pixelherodev: heh, yeah, running valgrind on systems with intel graphics consistently is quite annoying
mq32 has joined #zig
_Vi has quit [Ping timeout: 248 seconds]
<pixelherodev> On the bright side, got 100% reliability! By cheating.
<pixelherodev> One thing I noticed is that for whatever reason, it seems to need "warm up time" - the first few commands tend to fail, then it gets a tad more reliable
<pixelherodev> If each command is attempted ~5 times, it will almost *always* work
<pixelherodev> Can definitely still improve this, still got a few hours, but this is probably sufficient
<daurnimator> How does zig find the default panic function?
<pixelherodev> A `grep -r panic` should find that pretty quickly
<daurnimator> ah... in std/builtin.zig... and it looks for std.os.panic
<pixelherodev> builtin.zig has `pub const panic: PanicFn = if (@hasDecl(root, "panic")) root.panic else default_panic;`
<pixelherodev> Yeah
<pixelherodev> default_panic is defined in builtin.zig as well
<shakesoda> pixelherodev: long as it works through the imminent deadline i guess, heh
<pixelherodev> shakesoda, precisely.
<pixelherodev> Ended up actually using the XUART as the main data channel, mostly because it makes emergency prints much much easier to add
<pixelherodev> Also, it means that the exposed USB connection *cannot* be used to upload code in any fashion
<pixelherodev> The other nice thing is that the typical command packet is ~24 bytes, so even at 9600 baud trying five times is pretty damn fast
<pixelherodev> (that includes some padding + checksum)
<daurnimator> std.os.panic is not part of "BYO os" is it? :(
<pixelherodev> It is
<pixelherodev> daurnimator, but that's *optional*
<pixelherodev> If it doesn't exist, then the rest of default_panic in builtin.zig is used
<pixelherodev> Alternately, you can override default_panic *entirely* by having a pub fn panic in your root source file
dddddd has quit [Ping timeout: 260 seconds]
<daurnimator> pixelherodev: right... I'm trying to sort of make an "SDK"
<daurnimator> and I'm providing a panic function
<pixelherodev> Needs to be included by the root source file
<daurnimator> but it seems like my user has to do `pub fn panic(message: []const u8, stack_trace: ?*builtin.StackTrace) noreturn { return mysdk.panic(message, stack_trace); }`
<pixelherodev> Not necessarily
<daurnimator> ?
<pixelherodev> Could easily do `using SDK.panic`
<pixelherodev> Well, `pub using SDK.panic`
<daurnimator> ooooo. good idea
<pixelherodev> Or `pub usingnamespace SDK`
<pixelherodev> You could also have the SDK show up at the OS level
<pixelherodev> e.g. `pub os = @import("SDK")` in the RSF
<pixelherodev> Then, override what you want, and use `pub using` from e.g. libc for the rest
<daurnimator> ah right; it's `root.os` isn't it. not `std.os`
<daurnimator> that gives me at least a little flexibility
<daurnimator> o.o has anyone had an issue before where it seems like a `linksection` is getting ignored
<pixelherodev> Don't think so?
<daurnimator> figured it out I think
euandreh has joined #zig
euandreh has quit [Remote host closed the connection]
return0e has joined #zig
<pixelherodev> lesson learned: calling a function in GDB over serial doesn't end well.
_whitelogger has joined #zig
rappet_ has quit [Ping timeout: 248 seconds]
rappet has joined #zig
_Vi has joined #zig
<pixelherodev> Then I was having troubles because I was using relative paths and the FS on the Flash memory doesn't like that
<pixelherodev> Good news is, everything works now*!
<pixelherodev> *given a sufficiently high retry value
_whitelogger has joined #zig
strmpnk has quit []
dddddd has joined #zig
<betawaffle> are the fields on `type` values deprecated?
<alva> Is there a way to turn a comptime []const u8 into an identifier, or something along those lines? Trying to port G_DEFINE_TYPE from GLib.
<daurnimator> alva: are you looking for @field ?
<daurnimator> Where does @breakpoint() turn into a call to abort() ?
<daurnimator> ==> if I try and use @breakpoint() on riscv I get a linker error: lld: error: undefined symbol: abort
<alva> daurnimator: No, I'd like to create a new identifier from the slice. Or programmatically create a type, on which I can set the name.
<daurnimator> alva: and then do what with the name?
<daurnimator> alva: types don't have to have names in zig
<alva> daurnimator: Given the name "big_chungus", I want to create some functions like "big_chungus_get_type() { ... generated code ... }", and I'm wondering if that can be done with comptime programming, or if I need a code generation step in my build process.
<daurnimator> alva: you can't create function names at comptime
<alva> daurnimator: I see. Thanks!
TheLemonMan has joined #zig
<TheLemonMan> daurnimator, https://reviews.llvm.org/D69390
TheLemonMan has quit [Client Quit]
<daurnimator> ah, so I should use `asm ("ebreak")` instead for now?
waleee-cl has joined #zig
<betawaffle> is it possible to define methods on `[*]T`? for example, by defining `fn example(self: [*]T)`?
<daurnimator> betawaffle: no
<daurnimator> andrewrk: is there a download link that always points at latest master build?
<Snektron> daurnimator, you could extract it from the json downloads page
<daurnimator> Snektron: or whatever makes the json download page could also put up a redirect to the most recent :)
<daurnimator> context: in a CI job I want to just put: `curl -L https://ziglang.org/builds/zig-linux-x86_64-master.tar.xz | tar -xzvf -` and get a usable zig
<betawaffle> what's the right way to link to Hypervisor.framework in build.zig?
<daurnimator> .linkFramework("Hypervisor")
<betawaffle> i've got that, but it says it's still not finding the header file i'm trying to cInclude
BaroqueLarouche has joined #zig
naltun has joined #zig
return0e has quit [Remote host closed the connection]
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
BaroqueLarouche has joined #zig
naltun has quit [Ping timeout: 260 seconds]
return0e has joined #zig
<fengb> "function returns address of local variable"
<fengb> Was this added recently?
<fengb> Huh, apparently it was part of the IR split
<fengb> Free wins 🎉
bheads_ has joined #zig
bheads has quit [Ping timeout: 246 seconds]
bheads_ is now known as bheads
marmotini_ has joined #zig
<andrewrk> great, only 63 conflicts in ir.cpp rebasing #4152
<fengb> Is there a way to detect if the current execution is at comptime?
<fengb> Ah okay
<daurnimator> Reminder to all: put up GSoC ideas on the wiki! https://github.com/ziglang/zig/wiki/GSoC-Ideas-2020
<Snektron> I was wondering if there is any roadmap for simd intrinsics
<Snektron> apart from @reduce i couldn't find anything
<andrewrk> there are a lot of issues marked "contributor friendly" that could go on this wiki page daurnimator
<fengb> scientes had a branch with a lot but it ran concurrent with a bunch of internal refactorings
<andrewrk> Snektron, there's a big ol checklist here: https://github.com/ziglang/zig/issues/903#issuecomment-459508820
<daurnimator> andrewrk: they need to be tuned a bit.... and mentors should volunteer
<daurnimator> I'm about to write up a mail to the mailing list with more details
<Snektron> ah thanks andrewrk
<Snektron> nothing urgent btw, just wondering
<fengb> Would it be useful to have a GSoC project just to pull some of these commits in? https://github.com/ziglang/zig/pull/2945
<andrewrk> fengb, no, most of these commits don't really do things the right way
<andrewrk> I found it to be more productive and less buggy to ignore that pull request
<andrewrk> they also build upon each other in problematic ways, so if you fix the first commit in the branch, the rest of the commits break
Akuli has joined #zig
naltun has joined #zig
return0e has quit [Remote host closed the connection]
return0e has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen1 has joined #zig
dingenskirchen1 is now known as dingenskirchen
return0e has quit [Ping timeout: 272 seconds]
mooch has quit [Ping timeout: 260 seconds]
<daurnimator> andrewrk: might need your help over here: https://sourceware.org/bugzilla/show_bug.cgi?id=25470
<andrewrk> 0 bit types are not emitted in debug info. if they are, it's a bug in izg
<andrewrk> if they're willing to support 0 bit integers that would be wonderful. both signed and unsigned 0 bit integers have the value 0
<daurnimator> Want me to quote you on that? or do you want to make a comment yourself?
<andrewrk> I'll comment
mahmudov has joined #zig
<daurnimator> 👍
* daurnimator heads to bed
<andrewrk> good night!
<daurnimator> great success with the FOMU today :) https://github.com/im-tomu/fomu-workshop/pull/140
<andrewrk> what progress did you make?
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen1 has joined #zig
dingenskirchen1 is now known as dingenskirchen
return0e has joined #zig
naltun has quit [Ping timeout: 260 seconds]
metaleap has joined #zig
return0e has quit [Remote host closed the connection]
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen1 has joined #zig
dingenskirchen1 is now known as dingenskirchen
return0e has joined #zig
return0e has quit [Remote host closed the connection]
return0e has joined #zig
<metaleap> i'm implementing a (pre-existing) jsonrpc protocol (classic req/resp aka call/ret pattern) where a request always produces either result-value or error-code-with-msg. my callbackfn-types are almost about to look like this:
<metaleap> handlerFoo: fn(cur_call_scoped: *Allocator, params: FooParams) anyerror!union{result: ?FooResult, err: struct{code,msg}}
<metaleap> this sorta return type (regardless of whatever domain-specific thing `Foo` is per such exposed API method) begins to creep me out here
<metaleap> do i gather correctly that zigs native global-`error`-set is an enum not a union ie. funcs can return `error.SomeName`s but not `error.WithContextData{.....}`s
<metaleap> (and also catch the former not the latter)ß
<metaleap> i probably ditch the anyerror! union part and require handlers to catch locally and translate such catches back to the userland union's `err` tag to return..
<mikdusan> correct, no custom payload with zig errors -- they cannot themselves be a "union(enum){...}"
<metaleap> thx for confirming, thought i'd probe the channel in case sth like this was planned / in the works / undocumented-hidden
<fengb> There's a proposal to allow additional data
<mikdusan> iirc the big question for that usually come down to "who would manage the extra memory required?" :)
<metaleap> good point, cant see a way that wouldnt be dirty hacky and fraught
<fengb> Trying to find the issue... I remember a nice idea to extend the inferred error to allow unions, and it can auto downcast to an errorset
<metaleap> (tho .. could allow only fixed-size payloads and gather similarly to the global error set to be reserved in the DATA section but would yield only distressingly cumbersome realworld usages i'm sure =)
<mikdusan> I would shudder if the sizeOf(err) is globally changed from some machine int size, to the _largest_ union of all possible union(enum) errors
<metaleap> oh no scratch that above, stupid & silly
<metaleap> also there's unknown nr of errors floating around in theory
<metaleap> so no point
<fengb> Number of errors is comptime known
<metaleap> not the instances.
<metaleap> people dont always immediately exit on them..
<metaleap> you can pass them around etc
<metaleap> ah dont mind me, mind mushed from day job
<metaleap> .net cripples the synapses
<fengb> Is there a way to show watched issues in Github? >_>
<fengb> It exists but at the account level, not repo level
marmotini_ has quit [Remote host closed the connection]
<fengb> I think the standard pattern is to initialize a container in the "root" function: https://github.com/ziglang/zig/blob/master/lib/std/zig/parse.zig#L39
_Vi has quit [Ping timeout: 272 seconds]
decentpenguin has joined #zig
wootehfoot has joined #zig
return0e has quit [Remote host closed the connection]
wootehfoot has quit [Read error: Connection reset by peer]
_whitelogger has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
strmpnk has joined #zig
<Snektron> fengb https://github.com/issues
<Snektron> maybe that doesnt work for watched
dingenskirchen has quit [Read error: Connection reset by peer]
dingenskirchen has joined #zig
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
BaroqueLarouche has joined #zig
_Vi has joined #zig
Yardanico has quit [Ping timeout: 258 seconds]
Yardanico has joined #zig
decentpenguin has quit [Ping timeout: 240 seconds]
naltun has joined #zig
ur5us has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
naltun has quit [Ping timeout: 260 seconds]
ave_ has joined #zig
Snetry has joined #zig
Snetry has quit [Remote host closed the connection]
Snetry has joined #zig
Snetry has quit [Client Quit]
Snetry has joined #zig
<andrewrk> zig as a drop-in c compiler can be done in zig instead of c++
<mikdusan> if that is done, stage1 doesn't need to embed clang anymore? (by clang I mean not the LLVM backend)
<andrewrk> never mind, I got mixed up. a prerequsite for the drop-in replacement of a c compiler is https://github.com/ziglang/zig/issues/2041, which *can* be done in zig instead of c++
<andrewrk> but then doing #3089 (which depends on that other one) will want to parse the command line in main.cpp and set up the stage1 CodeGen properties accordingly
ur5us has quit [Ping timeout: 245 seconds]
<andrewrk> however... it's a fairly manageable project size to implement c compilation in self-hosted. this involves implementing the cache system, command line parsing, building the libcs, etc
<andrewrk> once all that is done, then stage1 could simply forward the args to a single libcall
<andrewrk> and... this would get us to parallel builds of c objects much sooner than self-hosted for zig code will be available
<andrewrk> in fact we could then delete all the libc building stuff for stage1, I believe
Snetry has quit [Quit: left Freenode]
<andrewrk> in fact, all 2,702 lines of link.cpp from stage1 could be moved to self-hosted
<andrewrk> because stage1 only needs to create libuserland.a
<andrewrk> the cache hash stuff can also move to self-hosted. cach_hash.hpp is a reasonably small set of functions
<mikdusan> yeah we don't need cache once self-hosted is up
<mikdusan> (in stage1)
<andrewrk> maybe even now though, it could move to libuserland
<mikdusan> grep'd src-self-hosted... it does some @cImport stuff
<andrewrk> there's no dependency on that for these things though
<mikdusan> awesome
Snetry has joined #zig
<andrewrk> for example src-self-hosted/{translate_c.zig,print_targets.zig,stage1.zig,c_tokenizer.zig,clang.zig,dep_tokenizer.zig} these are all hot
<andrewrk> "hot", meaning get compiled into libuserland.a which is linked into zig.exe which we ship on ziglang.org/download
<andrewrk> there's a lot of low hanging fruit for self-hosting right now
nyberg has joined #zig
<andrewrk> pixelherodev, ^ this would speed up that uncached musl libc build of yours by a factor equal to number of CPU cores you have
novaskell has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
ur5us has joined #zig
<mikdusan> what is target abi "macabi" ?
<metaleap> WELP! i dont do threading and yet my `try std.io.getStdOut().outStream().stream.write("whatev")` calls runtime-fail at:
<metaleap> EBADF => unreachable, // Always a race condition.
<metaleap> lib/zig/std/os.zig:499:22: 0x24bd68 in std.os.write
<mq32> a race condition does not mean it's a multithreaded problem
<mq32> it just means that you are using a resource that was not created yet (in that case: you use an invalid FD)
novaskell has left #zig ["User left"]
<metaleap> OOOH i should have taken the addr of the ....stream , now no such issue
<andrewrk> mikdusan, llvm comment says "Mac Catalyst variant of Apple's iOS deployment target"
* mikdusan reads up
Akuli has quit [Quit: Leaving]
<mikdusan> oh it's for cross iOS/macOS apps. even with a single-company at helm, the Catalyst apps look like mud compared to specialized for each of iOS and macOS
metaleap has quit [Quit: Leaving]
jessermeyer has joined #zig
<jessermeyer> var WAIT_FAILED2 = 0xFFFFFFFF; gives me error: variable of type 'comptime_int' must be const or comptime
<jessermeyer> Why can't I set that as a var?
<jessermeyer> I want it as a var because I want to change it later.
<andrewrk> if you want to change it at runtime, then zig has to know how much memory to allocate for it at runtime
<jessermeyer> Looks like if I tell Zig it's a u32 it'll go along with it.
<jessermeyer> Makes sense!
<jessermeyer> Think I found a bug with this, or at least unexpected behavior.
<jessermeyer> var r1: u32 = 164; var WAIT_FAILED2: u32 = 0xFFFFFFFF; var r3 = r1 == WAIT_FAILED2;
<jessermeyer> Is false.
<jessermeyer> But...
<jessermeyer> var r1:u32 = 222; const WAIT_FAILED2 = 0xFFFFFFFF; var r3 = r1 == WAIT_FAILED2; is true
<jessermeyer> Sorry, I don't know a sane way of copying code into IRC.
<jessermeyer> Sorry, Don't know why I chose different numbers for r1, don't think it matters.
<jessermeyer> The real bug is that while (MsgWaitForMultipleObjects(1, &window_handle, 1, 1, QS_ALLPOSTMESSAGE) != WAIT_FAILED) returns false but it should not.
<jessermeyer> MsgWaitForMultipleObjects does not return WAIT_FAILED, by inspection.
<Snektron> (you could use a paste service)
<jessermeyer> (That's probably smart)
<mikdusan> `r1 == WAIT_FAILED2` is false
<jessermeyer> But the compiler cannot make up its mind, based on the type WAIT_FAILED2 has.
Snetry has quit [Ping timeout: 268 seconds]
<jessermeyer> I agree it should evaluate to false.
<mikdusan> make a small reproduction. I cannot reproduce "true" result from what is shown. oh, also why `!= WAIT_FAILED` instead of WAIT_FAILED2 ?
<jessermeyer> Ruh Row
<jessermeyer> I'm getting var returned = MsgWaitForMultipleObjects(1, &window_handle, 1, 1, QS_ALLPOSTMESSAGE); var WAIT_FAILED1:u32 = 0xFFFFFFFF; var eval = returned == WAIT_FAILED1; var eval2 = returned != WAIT_FAILED1;
<jessermeyer> that both eval2 and eval are false.
<jessermeyer> WAIT_FAILED in the real code is comparing against a comptime_int
<jessermeyer> but I agree my examples are not consistent between each other.
<mikdusan> andrewrk: what is the ideal goal for build.zig to use for target-triple when completely not specified?
<mikdusan> ideal as in future with self-hosted, etc.
<mikdusan> bad wording. I guess what is the ideal default?
<mikdusan> jessermeyer: which platform?
<jessermeyer> win10
<mikdusan> oh win . so I don't know that debugger. but making hello world with top 3 lines easily verifies `r3` to be false
<jessermeyer> I know.
<jessermeyer> But that doesn't mean the bug doesn't exist!
<mikdusan> so this is not a console app?
<jessermeyer> Well I'm not technically specifying subsystem: windows
<jessermeyer> zig build-exe -ldxgi -ld3d12 -ldxguid -ld3dcompiler bug1.zig -L "C:\Program Files (x86)\Windows Kits\10\Lib\10.0.18362.0\um\x64"
<jessermeyer> I built both programs the same way
<jessermeyer> only difference is the root source file
<jessermeyer> let me see if winmain() triggers it
<mikdusan> can you try something like... `if (r3) @breakpoint();`
<mikdusan> (to let zig do the eval)
<jessermeyer> Sorry I'm not following exactly... What will that tell us?
<mikdusan> if debugger breaks at that line, it means that zig's generated code caused it. I'm trying to rule out a debugger issue
ur5us has quit [Ping timeout: 246 seconds]
<jessermeyer> Ah
<mikdusan> I suppose @panic("waaat") would work just as well
<andrewrk> mikdusan, std.Target.Native
<andrewrk> mikdusan, btw, I finally solved https://github.com/ziglang/zig/pull/4152#issuecomment-573971743 in that branch
FireFox317 has joined #zig
<FireFox317> Aren't you forgetting to link libc?
<jessermeyer> Smart.
<andrewrk> the good news is that the solution wasn't a hack, it improved a bunch of edge cases to make sense
<jessermeyer> The debugger is falsely reporting that value!!
FireFox317 has quit [Remote host closed the connection]
<jessermeyer> I'll submit a bug report. Thanks for your superior debugging skills.
<jessermeyer> VS's debugger doesn't seem to suffer from this issue.
<mikdusan> side note: @brekapoint on macos/lldb doesn't break for me on the correct line in main(). haven't used it that much to narrow down production more.
<mikdusan> jessermeyer: which debugger had buggy value?
<jessermeyer> RemedyBG
<mikdusan> thanks
<jessermeyer> Uh oh.
<jessermeyer> It's a heisenberg bug.
<jessermeyer> It's suddenly reporting the correct value now.
<Snektron> concurrent modification
<Snektron> oof
<Snektron> shouldn't have tried to refAllDecls before generating all symbols
<mikdusan> jessermeyer: smells like ub.
<jessermeyer> Yeah, the debugger is really built around debugging C code, which it does just fine.
<mikdusan> but being that breakpoint was on a line at the right spot, i don't see any ub chance there
<mikdusan> jessermeyer: is it possible some line numbering changed from the binary and source, and png debug session was from out-of-sync bin/sources ?
<mikdusan> (png paste
<jessermeyer> Yeah I'm sorting to think something like that is going on.
<jessermeyer> starting~
<mikdusan> so if the bin/source was out of sync during debugging, I could believe some ub
ltriant has joined #zig
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
frmdstryr has joined #zig
jessermeyer has quit [Remote host closed the connection]
<andrewrk> finally, the fixes to result location stuff are making sense rather than being total hacks
<andrewrk> thanks for the help mikdusan
<mikdusan> heh i built `zig` by mistake and it linked :)
<mikdusan> it's always nice zig0 -> zig starts to work
<andrewrk> yeah always a relief
<andrewrk> especially with translate-c covering a lot of syntax
traviss has quit [Ping timeout: 260 seconds]
Snetry has joined #zig
mahmudov has quit [Remote host closed the connection]