<andrewrk>
wrl, I'll have you using zig build for your C project before you know it
<telemach>
so, regarding embedding — most libs i looked into wants to own event loop and/or assume single instance (i.e. glfw)
<telemach>
but wrl could explain much better, he hit and overcome most of those problems
<telemach>
i'm just starting my path on that minefield
<andrewrk>
event loops can be joined if the API does it right. I made sure the libsoundio event loop was compatible with external event loops
<wrl>
andrewrk: pretty well invested in waf for the time being but eyeing zig for some other tasks ;)
<wrl>
yeah so just to sum things up with audio plugins and UI embedding – when the host application calls into the plugin and says "open your editor window", it passes in a parent window into which the plugin should open its window
<wrl>
HWND on win, xcb_window_t on lin, NSView * on mac
<wrl>
on linux, you can then spin up a thread and just run an event loop as normal from there
<wrl>
on win/mac, the host application already owns the event loop, so the plugin window has to hook into it for redraws, generally with a timer event
<wrl>
there's like... one or two low-level GL libs that support that kind of thing. the general purpose libs (SDL2, GLFW, etc) are wholly unsuitable
<hryx>
oops, just realized I left an issue draft open last night :O
<hryx>
*unsubmitted
<andrewrk>
the key to joining multiple event loops is 3 things: (1) an API to flush/poll the event queue that doesn't block on empty queue, (2) a function pointer callback that signals the event queue has become non-empty, which can be called from any thread, and (3) an API to signal to wake up a blocking call to the event loop run function
<andrewrk>
in theory there is a more efficient way to do it, but this is correct and generally good enough
<andrewrk>
I mean obviously the more efficient way to do it is to only have 1 event loop
<wrl>
right
<wrl>
the tricky bit with the UI loops is that you also need to wake it up at regular intervals to redraw
<andrewrk>
yeah. with ui loops I prefer to poll the other event loops every frame
<wrl>
same as i'm doing
<scientes>
why not use two differn't threads?
neceve has quit [Remote host closed the connection]
kristate has joined #zig
<emekankurumeh[m]>
are we going to bump the open issues to 0.5.0?
<emekankurumeh[m]>
or release a version 0.4.1 or something like that?
<andrewrk>
emekankurumeh[m], I'm probably going to spend most of tomorrow working on release notes and issues
<andrewrk>
and then yes when I cut the release I'll organize the milestones
<andrewrk>
everybody ready for a fun media day?
<shritesh>
Excited!!!
<hryx>
ready (°_°)7
<l1x>
=^.^=
allana has joined #zig
scientes has quit [Remote host closed the connection]
scientes has joined #zig
kristate has quit [Remote host closed the connection]
kristate has joined #zig
_whitelogger has joined #zig
marmotini_ has joined #zig
scientes has quit [Remote host closed the connection]
fsateler_ has joined #zig
fsateler has quit [Ping timeout: 246 seconds]
scientes has joined #zig
kristate has quit [Ping timeout: 268 seconds]
Kingsquee has joined #zig
hio has quit [Quit: Connection closed for inactivity]
kristate has joined #zig
bheads__ has joined #zig
allana has quit [Remote host closed the connection]
bheads___ has quit [Ping timeout: 244 seconds]
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 268 seconds]
marmotini has quit [Read error: Connection reset by peer]
<daurnimator>
wrl: the problem on windows is that they hid the main GDI EVENT handle from win xp sp2
<wrl>
on linux everything is great. tight redraws, low CPU usage, etc
<daurnimator>
wrl: the problem on OSX is that they don't expose the internal CFRunLoop mach port set
<wrl>
ugh, yep
<daurnimator>
dragonflybsd has the best story
<daurnimator>
I wish everyone copied them...
<wrl>
there's some other approaches I'm planning on looking into – notably, CVDisplayLink on Mac and some... other type of timer thread on windows
<wrl>
but I'm not there yet
<wrl>
daurnimator: how's it look over there? i'm familiar with the whole token concept but not intimately
<scientes>
daurnimator, i thought the BSDs just used the linux graphics layer these days, because of DRM
<daurnimator>
wrl: to summarize it: on dragonfly bsd, all the internals are built on *top* of kqueue: select(), poll(), many ioctls.... all on top of kqueue. means you can use kqueue for everything perfectly
Zaab1t has joined #zig
<wrl>
daurnimator: love it, yeah
<wrl>
honestly i feel like windows has the worst story here
<daurnimator>
wrl: vs on other bsds, they still have all the select/poll/other machinery in parellel to kqueue. sometimes kqueue built on top of an internal poll() call
<daurnimator>
wrl: windows actually has it really really good at the NT layer. it's win32 that has the bad story
<wrl>
sure, there's the generalised IOCP or overlapped operations, WaitForMultipleEvents and all, but you can't get window events the same way
<wrl>
there's MsgWaitForMultipleEvents but
<daurnimator>
wrl: right. and window events are all in win32 :)
<wrl>
MsgWaitForMultipleObjects, my bad
<wrl>
yeah
<daurnimator>
wrl: window events are all driven off an internal/hidden EVENT handle.
<daurnimator>
wrl: in win2000 you could just get the internal EVENT handle and use it; sidestepping all the mess and do an event loop the right way
<wrl>
daurnimator: aha, so internally everything *is* built on the same concepts, but it's just not exposed
<wrl>
how could you do that on win2k? i'm not planning on doing it, ofc, but i'm interested in reading about it
<daurnimator>
wrl: uh, some offset from the segment register there was a pointer to a struct with the EVENT handle in it
<wrl>
aha so it was undocumented
<wrl>
makes sense
<wrl>
i bet you could still pull the same trick but you'd have to hardcode the offset
<daurnimator>
you always had to hardcode the offset
<scientes>
uggggh this all sounds horrible
<wrl>
well i mean
<daurnimator>
but then in winxp service pack they marked that structure as readable only by the kernel
<wrl>
aha
<wrl>
welp
Hejsil has joined #zig
<wrl>
scientes: linux got this right honestly
<daurnimator>
scientes: no...not really
<scientes>
what specifically, epoll?
<daurnimator>
uh *wrl
<daurnimator>
epoll is a mess. but at least it is usable
<daurnimator>
but X and wayland both messed up graphics event handling
<scientes>
what is wrong with wayland?
<wrl>
scientes: window system handle being waitable like any other handle
<wrl>
rather than it being hidden somewhere
<daurnimator>
we *almost* got the right abstraction again with GBM; but then nvidia destroyed progress with EGLStreams
<wrl>
daurnimator: is the GBM/EGLStream fight still going on?
<daurnimator>
wrl: yep. last I checked everyone except nvidia uses GBM. nvidia are doing their own thing; and linux graphics suffers for it
<wrl>
fucking nvidia, man
<daurnimator>
IIRC in GBM you just get to poll a file descriptor to get events. usable with epoll/etc. with EGLStreams you get this weird callback from the graphics driver using a shared memory futex-but-with-ioctl mess
<wrl>
christ
hio has joined #zig
<scientes>
yuck
<scientes>
maybe i should get into graphics
<daurnimator>
scientes: http://arcan-fe.com/ <-- new display protocol. by far the best design IMO. I hope it can replace X and wayland soon....
<wrl>
daurnimator: i've seen arcan here and there
<wrl>
what's the benefit over wayland in particular?
<wrl>
... wait why does it handle audoi
<wrl>
audio
<daurnimator>
wrl: have a read of the blog there. so much good technical information
<scientes>
yeah i gotta get my zig robust cross-process locks working
kristate has quit [Remote host closed the connection]
<scientes>
cause there are plenty of use cases, and glibc is buggy
kristate has joined #zig
<wrl>
scientes: use eventfd
<scientes>
so that 32-bit clients can use a 64-bit server
<scientes>
through shared-memory locks
<daurnimator>
wrl: because the hardest part of display servers is synchronisation and permissions..... and the same with audio servers. and you might notice that sometimes video and audio need to be synced together. why have two different mechanisms for the same thing. <-- logic as far as I recall.
<wrl>
i very much do not like that arcan also handles audio
<scientes>
wrl, why would you be forced to use it?
<scientes>
and it is reasonable if you ever want to stream with IP
<daurnimator>
not to mention that when you're e.g. targeting HDMI, video and audio are on the same cable...
<wrl>
scientes: because ALSA isn't great and when an application (such as an audio server) opens the audio device, that process "owns" the audio device
<scientes>
and its solid pthread all the way through
<wrl>
so i *would* have to use it
<scientes>
while pulseaudio has a mutex abstraction
<scientes>
wrl, not if you have hardware mixing, like a SoundBlaster :)
<daurnimator>
wrl: arcan can output to e.g. openal instead of grabbing the alsa device
<scientes>
but thats why you need pulseaudio or audioflinger
<wrl>
scientes: any more recent cards you can name with hardware mixing? ;)
<scientes>
I just had a Sound Blaster when everyone was complaining about pulseaudio. I switched back to ALSO and never had a problem :)
<daurnimator>
wrl: anyway, have a read of the arcan blog. also join #arcan if you want. beware that you'll learn of horrors in your systems that you never knew were there.
Hejsil has quit [Ping timeout: 256 seconds]
<scientes>
daurnimator, how close are they to declaring the protocol stable?
<daurnimator>
scientes: not at all. the next major milestone IMO is the wayland<>arcan bridge so that you can run wayland understanding applications under arcan.
<scientes>
ok, cause I could make 32-bit clients on 64-bit systems first-class, but it requires more work in zig
<scientes>
pthreads doesn't support that
kristate has quit [Ping timeout: 252 seconds]
<wrl>
scientes: just because of the size of the structures differing?
* daurnimator
feels like we're getting too offtopic
<scientes>
basically, there is an offset in there that is send to the kernel, and it varies between 32-bit and 64-bit
<daurnimator>
i.e. it's an undocumented function meant only for CoreFoundation
<wrl>
you get it from looking at symbol names?
<daurnimator>
got that from reading the gnu fork/reimplementation of core foundation
<wrl>
got it
<wrl>
daurnimator: curious to read anything you've got on the win32 EVENT thing also
<daurnimator>
wrl: found the member name: "hEventQueueClient"
kristate has joined #zig
<daurnimator>
wrl: googling that should lead you down a weird and wonderful rabbithole
<daurnimator>
which ends in disappointment
<wrl>
daurnimator: aha, if it's in THREADINFO that makes sense why child/parent windows can't be on separate threads
Ichorio has joined #zig
scientes has quit [Read error: Connection reset by peer]
scientes has joined #zig
forgot-password has joined #zig
scientes has quit [Read error: Connection reset by peer]
scientes has joined #zig
<daurnimator>
wrl: how deep down the rabbit hole did you get?
noonien has joined #zig
<wrl>
daurnimator: haven't delved too far in
<andrewrk>
shritesh, would it be better if the file extension of wasm objects was .wasm?
<shritesh>
Definitely
<daurnimator>
andrewrk: how are things looking for the release?
<andrewrk>
daurnimator, just a couple more hours of release notes. I'm going to punt on all the remaining bugs
<andrewrk>
apologies for the business buzzword. I mean I'm going to move them to the 0.5.0 milestone
<shritesh>
WASM APIs in the browser expect the mimetype to be Type=application/wasm and the easiest way for webservers to enforce that is with the extension
<daurnimator>
what was the business buzzword?
<andrewrk>
punt, an american football metaphor
<daurnimator>
'milestone' is more business buzzword than anything else you said :P
<daurnimator>
andrewrk: punt doesn't come from american football ;)
<andrewrk>
shritesh, did you have any luck using them with node?
<wilsonk>
Does cross compiling to any other os/abi/libc combo work for anybody else when you try a combo besides the main (x86 or arm)/linux/(gnu or musl) combos? Ie. things like 'zig build-exe --c-source t.c -target sparcv9-linux-gnu --library c' don't work for me. Or is documenting the failing combos part of #2058
<shritesh>
I have not. I can try. I'll even see how it works with WASI
<andrewrk>
wilsonk, there are a lot of little problems, usually not too much effort to solve. I only really solved x86_64 and aarch64 as a proof of concept
<wilsonk>
ah, ok. I was under the impression that most were solved...my bad
<andrewrk>
well, they are in theory. I guess the percent that work without testing is lower than I expected
<scientes>
yeah I was suprised how easy it was to port to aarch64
<scientes>
(that was me)
<andrewrk>
shritesh, hmm I keep getting `SyntaxError: Invalid or unexpected token" from node v8.15.0
<wilsonk>
a few of them also don't really match up between the triple and the 'available' target triples listed for libc. Things like aarch64-linux-gnu needing to actually be aarch64v8-linux-gnu (and v8_5a doesn't work, etc). Just mentioning. Scientes did you happen to keep any notes on porting aarch64? Might be some overlap with other targets
<andrewrk>
wilsonk, yeah, the sub-arch situation can be a bit clunky in that regard
<scientes>
wilsonk, yeah i ran into that too
<scientes>
the sub-arch thing
<andrewrk>
if you look at `zig targets` look at the tree structure of sub-architectures, that should at least explain the situation
<scientes>
wilsonk, it was pretty easy, just copy from musl when you are missig stuff
<scientes>
(except syscalls that is, get those from linux direct)
<andrewrk>
wilsonk, I'm definitely interested in increasing the quality and testing of these
<wilsonk>
hmm, maybe I will try to make up something comprehensive on which targets are at least recognized, and then error out.
<andrewrk>
this is sort of also why we have the "tier system" and note that only x86_64 linux, windows, macos are tier 1
<wilsonk>
andrewrk: right
<daurnimator>
andrewrk: would you have time to fix some last minute packaging bugs before release? (I don't know if there are any; I can start trying to package now)
<andrewrk>
I'd recommend focusing on the target that is personally interesting to you
<andrewrk>
daurnimator, yes
<andrewrk>
my goal is to tag the release within 1.5 hours
<scientes>
well aarch64 could be tier one...if someone paid me...I just couldn't pay for a testing VPS out of pocket
<shritesh>
andrewrk: I tried out an add(u32, u32) u32 function in NodeJS and it worked
<andrewrk>
what version of node?
<andrewrk>
and did you use build-obj build-lib or build-exe?
<shritesh>
11.6
<shritesh>
build-exe
<scientes>
is that emscripten?
<andrewrk>
scientes, zig supports webassembly now
<scientes>
oh, i didn't know v8 supported web assembly
<daurnimator>
andrewrk: okay. I'm checking things now. is Tiehuis in here?
<wilsonk>
scientes: can't you just run a qemu vm on your local machine and test aarch?
<scientes>
wilsonk, I test it on native aarch64
forgot-password has quit [Quit: leaving]
<scientes>
wilsonk, i am talking about automated tests
<wilsonk>
oh, I see
<scientes>
it can't be tier1 without automated tests
<wilsonk>
right, I see that now looking at the requirements
<andrewrk>
yeah everyone who doesn't run on aarch64 has to know when they break something
<andrewrk>
shritesh, hmm, I'm still getting `SyntaxError: Invalid or unexpected token` with `x = require('./test.wasm')` in the node 11.6.0 repl
<andrewrk>
there's a link to the upstream bug there
<daurnimator>
thanks.
<andrewrk>
np. I've done some debian packaging, I'm familiar with this process of patches having to be justified
<daurnimator>
given that it's an upstream bug for non-native target, I'd prefer to say its just on lld upstream to fix it
<andrewrk>
that's your discretion as a package manager. as an upstream author I want users to be able to rely on the same experience no matter what system they're on, which is why Zig maintains a fork of LLD
<andrewrk>
(there have been other patches but so far all others have been accepted upstream)
<daurnimator>
arch philosophy is pretty much to hound the upstream until they merge it. and only carry a patch if the upstream refuses.
<daurnimator>
and then: we'd carry the patch in our lld package; not vendor lld into the zig package
<andrewrk>
LLD has refused on this patch (for good reasons; it's a bit of a hack)
<andrewrk>
users will always be able to use the ziglang.org/download version of zig if they want the patch on arch
<andrewrk>
are you going to make softfloat an external dependency too?
<noonien>
hello folks!
Sahnvour has joined #zig
<noonien>
how's ARM support?
<scientes>
noonien, i did the aarch64 port
marmotini_ has quit [Remote host closed the connection]
<noonien>
ah, i'm interested in armv7
<scientes>
noonien, freestanding or linux?
<daurnimator>
andrewrk: why are the softfloat sources vendored in?
<noonien>
last time i tried, it appeared to have some support, just not user-facing
<noonien>
linux ATM
<scientes>
noonien, there is no linux armv7 support
<scientes>
but it isn't difficult to do
<scientes>
I would do it if I had some motivation
<noonien>
i see :(
<andrewrk>
daurnimator, the zig source tree is optimized for the developer experience of building from source
<andrewrk>
look at all the github issues that have not been filed because people didn't have softfloat installed, or it wasn't found by the build config, etc
<daurnimator>
andrewrk: sure. and now I'm trying to figure out what changes are required for the packager experience :P
<noonien>
AFAIR zig had a llvm backend, which should suport armv7, i'm guessing there's no init function, right?
<scientes>
noonien, yes, thats why it is so easy
<andrewrk>
yeah. it should just be LLD and softfloat. you might get some pushback from musl, glibc, and linux headers being distributed with zig, but that's not really negotiable. zig ships with a custom cross compilation toolkit
<andrewrk>
that should be a warning not an error, and it should be silenced
<andrewrk>
zig_clang_cc1as_main.cpp is a vendored file
<daurnimator>
andrewrk: trying to figure out the flow: looks like you set -Werror ?
<andrewrk>
what compiler/version is that?
<andrewrk>
are you not making a release build? I'm pretty sure -Werror is only set in Debug builds
<daurnimator>
andrewrk: if you want cmake to use CPPFLAGS and other env vars (which we require for packaging), you *have* to not provide a release type.
<andrewrk>
it only sets the release type if one isn't provided
<daurnimator>
which result in a build type of "None"
<daurnimator>
essentially, specifying no build type means "use env vars". specifying "Release" means "please append -O3 and -DNDEBUG"
<daurnimator>
(+ lots of other flags)
<andrewrk>
use -DCMAKE_BUILD_TYPE=None then
<daurnimator>
well yeah I can do that.... but seems silly when that's the default already for cmake
<noonien>
+
<andrewrk>
the zig source tree is optimized for the developer experience of building from source
<andrewrk>
building from source has to be solved by N people; packaging has to be solved by 1 person
wootehfoot has joined #zig
<scientes>
-Werror with unused variables is kind of annoying in debug mode
<scientes>
cause sometimes you are just testing stuff
<scientes>
daurnimator, use ninja -GNinja
<scientes>
why are there files in src-self-hosted that get installed to std?
<scientes>
why arn't those files just in std?
<scientes>
arm.zig main.zig and errmsg.zig
<andrewrk>
scientes, that's how stage1 zig fmt works
<andrewrk>
that will get deleted when we have a feature complete stage2
<scientes>
it just annoys me cause i like symlinking std
<andrewrk>
use --override-std-dir
<scientes>
no, i symlink, then run ninja install
<andrewrk>
I don't think that's a reasonable use case to support
<scientes>
but yeah that would do it
<scientes>
and --override wouldn't work unless i install
<scientes>
and I really want to be able to run the files that are in git
<scientes>
it simplifies my work-flow
<daurnimator>
grrr. my whole laptop locked up and I had to hard reboot
<scientes>
daurnimator, mine does that too :/
<daurnimator>
happended during compilation of translate_c.cpp
<mikdusan>
file an bug/issue :)
<daurnimator>
I think I just ran out of ram or something
<andrewrk>
overcommit is to blame
<scientes>
daurnimator, it usually is overheating with laptops
<mikdusan>
daurnimator: curious, which compiler is building your .cpp ?
<daurnimator>
mikdusan: gcc 9 I think
<mikdusan>
daurnimator: that might explain it. i recently did a llvm-8.0.0 build in a linux-vm. the first stage bootstrapped with gcc. and killed my vm hard. then i installed clang-7 and it ran much much leaner with 4 jobs. gcc failed with 2 jobs. same vm.
<mikdusan>
tldr- if you have resource constraints, building big llvm’ish things with gcc is more needy than clang
<scientes>
mikdusan, only because gcc optimizes it more
<daurnimator>
I gtg to dinner
<scientes>
mikdusan, are you using debug fission?
<andrewrk>
you have to build zig with the same system compiler used to build the clang/llvm packages
<mikdusan>
in the ghostbusters metaphor, if ghostbusters are developers, their plasma guns are compilers, what is the marshmallow man?
<scientes>
undefined behavior
<andrewrk>
A+
<mikdusan>
i think scientes wins
Zaab1t has quit [Ping timeout: 245 seconds]
kristate has quit [Ping timeout: 252 seconds]
<shritesh>
andrewrk: I went down the WASM rabbit hole and it looks like Zig is really well suited for WASM. Being explicit about allocators, strings and @OpaqueType makes interfacing really easy even without the vast tooling that C and Rust have.
<andrewrk>
cool!
<andrewrk>
we need someone to do a wasm project with zig to help explore the use case. I'm sure there are lots of rough edges right now
<shritesh>
I wrote a BF WASM interpreter in Rust like two days after the support landed and any of the tooling existed: https://shr.ite.sh/brainfuck-rust-wasm.html I might do the same with Zig lol
<andrewrk>
took me a second to understand BF means "Basic Functionality" and not "Brain Fuck"
<andrewrk>
oh, nvm
<shritesh>
Not it does mean Brainfuck
<shritesh>
No*
<andrewrk>
got it, so it's not a wasm interpreter in rust, it's a brainfuck interpreter in wasm (from rust source)
<shritesh>
Especially with WASI and every CDN providing a WASM runtime at the edge, zig may be able do something here.
<shritesh>
Maybe someone can even write an OS with Zig that only runs WASI binaries.
<andrewrk>
there are some cool things you can do if all userspace is jitted. for example you can stay forever in privileged mode, relying on no sandbox escapes
<andrewrk>
something like that. I've never tried it
develonepi3 has joined #zig
<scientes>
how do i resolve ConstValSpecialStatic ?
<scientes>
oh i C
Zaab1t has joined #zig
jzelinskie has quit [Read error: Connection reset by peer]
jzelinskie has joined #zig
Zaab1t has quit [Quit: bye bye friends]
fsateler_ has quit [Ping timeout: 245 seconds]
fsateler has joined #zig
<daurnimator>
back
<daurnimator>
and grrr.. turns out my irc box ran out of disk space comiling
<daurnimator>
*compiling
<daurnimator>
and for some reason I can't get into the real build boxes (ssh permission failing)
<daurnimator>
and my wine turned to vinegar.
<daurnimator>
the last hour or so was not kind to me
<Sahnvour>
that wine fermented pretty quickly
<daurnimator>
Sahnvour: I opened a 38 year old bottle :P
<Sahnvour>
milord!
hg has quit [Quit: WeeChat 2.4]
halosghost has joined #zig
fsateler_ has joined #zig
fsateler has quit [Ping timeout: 245 seconds]
<andrewrk>
I tagged the release. Still need the ~2 hours of CI time to finish the release notes
<halosghost>
ooh, a new release?
<shritesh>
I'm prepping a PR for homebrew with the new release. Or does someone else do that?
<andrewrk>
you are more than welcome to do that
<andrewrk>
I think you are the first one to it this release cycle
<tgschultz>
I should use this release as an oportunity to update all my code and ease back in to doing useful things with zig again. I've been really busy with other things lately.
<scientes>
i'm excited that my breaking code will be able to be reviewed
<scientes>
(if i can get the tests passing that is)
gamester has joined #zig
bheads___ has joined #zig
bheads__ has quit [Ping timeout: 250 seconds]
bheads____ has joined #zig
shawn_ has joined #zig
bheads___ has quit [Ping timeout: 246 seconds]
scientes has quit [Ping timeout: 245 seconds]
<emekankurumeh[m]>
is the native target decided at compile time is it decided at runtime?
<shawn_>
compile time
shawn_ is now known as scientes
<scientes>
but you are not clear on what you are asking
<scientes>
or what you want to do
wootehfoot has quit [Quit: teh pillowz]
<emekankurumeh[m]>
I was wondering if for example download a msvc zig executable from the website and have it chose the right target when linking libc on mingw automatically
<emekankurumeh[m]>
but setting the target works just fine too
halosghost has quit [Quit: WeeChat 2.4]
Ichorio has quit [Ping timeout: 268 seconds]
shawn_ has joined #zig
scientes has quit [Ping timeout: 252 seconds]
Sahnvour has quit [Quit: Leaving]
shawn_ is now known as scientes
<andrewrk>
30 minutes, and I will have these notes done
<scientes>
sweet
<scientes>
something is returning g->builtin_types.entry_invalid; but i can't put a watchpoiint on that
<scientes>
ugggh
<scientes>
i need to learn gdb/lldb better
<gamester>
It looks like I'm going to miss the release celebration, my flu is forcing my will. Congratz Andrew on 0.4 and congratz on having so many awesome people now participating in Zig. 0.4 is a great release and future releases will be even better! Here's hoping that the growth of the community can eventually reduce the load off of you, financally and workwise. Good night!