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)
<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
<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
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>
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? >_>
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
<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?
<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]