<pmwhite>
i'm wanting to write a regular expression library; what are people's preferred RE dialect? I'm thinking POSIX Extended Regular Expressions is good because it is a standard.
<mikdusan>
I was on the fence about what that was morphing into
dddddd has quit [Remote host closed the connection]
<mikdusan>
if cmake is not case-sensitive then maybe we need to fix our CMakeLists.txt file; it has several conditionals based on "Debug" and "Release" - should we just define a lower-cased var for CMAKE_BUILD_TYPE and use that in our conditionals?
<andrewrk>
sorry that was a typo. it *is* case sensitive, hence the initial motivation for the original patch
<daurnimator>
mikdusan: I thought the point was the cmake *is* case sensitive
<andrewrk>
I typo'd in the commit msg
<daurnimator>
release != Release. both could be valid
<mikdusan>
ok I'm back on the same page :)
<daurnimator>
andrewrk: good to know @typeId is deprecated. I was going to propose its removal as soon as #4435 was merged.
<andrewrk>
I checked the gentoo package and it does not appear to have done that, so false alarm there
<andrewrk>
it's a bit scary to advertise "really good at cross compiling" and then package maintainers delete that feature :(
<daurnimator>
andrewrk: in gentoo the idea was that its up to the sysadmin on how they want to compile LLVM
<daurnimator>
they'd probably see it as taking away choice from the users
<andrewrk>
right, this is the classic negotiation between upstream and downstream
<daurnimator>
"I'm never going to compile for PPC; why would I want that code sitting around on my system"
<andrewrk>
this is a (perverse) incentive to self-hosted without llvm. package maintainers would be less likely to mangle the codebase
<daurnimator>
gentoo emphasises end-user choice where you customize your build to be only the minimum set of functionality you need
<daurnimator>
this works because in gentoo the end user compiles everything themselves.
<andrewrk>
yes and this motivation is reasonable. yet in practice, upstream ends up getting issue reports from actual users being surprised that the software errors on their system instead of just working
<daurnimator>
should we print a warning? --> if target is unavailable then print an error "it seems as though your LLVM was compiled without support for $TARGET; you'll need to work with whomever compiled your LLVM"
<daurnimator>
right; but hard errors will get patched out
<daurnimator>
leave a soft error somewhere else
<andrewrk>
nah the hard error is exactly right. it communicates clearly that upstream considers these features necessary for the software to be functional
<andrewrk>
if downstream wants to patch it out, they have that right
<daurnimator>
but as you say: downstream will patch it out; but users will come to us: we should leave a soft warning behind.
<andrewrk>
are we aware of any such patching?
<andrewrk>
this might be one of those problems that only exists because we are thinking about it
<daurnimator>
not yet I think
<pixelherodev>
Personally, I think that allowing builds with limited target support is fine
<pixelherodev>
If someone is compiling themselves to use the binary themselves, they probably know what they're doing
<pixelherodev>
Maybe have an option to replace the configuration assertion with a runtime compiler error?
<andrewrk>
the situation is that person A is compiling it for N other people who are not aware of these changes
<andrewrk>
there's no option. according to zig if your llvm is missing targets, zig refuses to build
<andrewrk>
this is intentional. to build zig without all the targets enabled is to fork zig
<pixelherodev>
I'm saying that as a Gentoo user, I'd have preferred being able to build Zig without needing to let my computer run overnight rebuilding LLVM + Clang
<pixelherodev>
As person A compiling for zero other people :)
<andrewrk>
well you are free to fork zig and disable some targets
<fengb>
Ziglite
<mikdusan>
any quick summaries on what src/zig_clang.cpp/ZigClangLoadFromCommandLine() does ?
<andrewrk>
mikdusan, it's the entry point to libclang's semantic analysis API. it relies on a lot of C++-isms, so it was easier to sort of invent a more C-friendly function and put a few chunks of code in there
<andrewrk>
the main function there is clang::ASTUnit::LoadFromCommandLine. the rest of the code is mainly extracting error messages
<mikdusan>
i threw a userland print stacktrace before stage1 reports the error. but it only has 1 line
<andrewrk>
next step is to figure out why null is getting returned without any errors set
<andrewrk>
that "Early failures in LoadFromCommandLine may return with ErrUnit unset." looks suspicious
<tdeo>
trying to use socket control messages in pure zig, anyone mind quickly helping me translate the __CMSG_LEN/CMSG_ALIGN calculation to zig? in the repo at lib/libc/musl/include/sys/socket.h line 299
<andrewrk>
mikdusan, maybe we can access the errors only with `diags` and without unit->stored_diag_begin?
<andrewrk>
then we can delete that early `return nullptr`
<andrewrk>
tdeo, you can use `zig translate-c` to do this :)
<andrewrk>
make a file called foo.c with contents "#include <sys/socket.h>"
<tdeo>
i can, i want to eventually make a PR for this and translate-c generated code would be a bit long/weird
<tdeo>
relies on overflow and wondering if there's a more idiomatic way in zig
<andrewrk>
yes you will have to isolate the structs/bits you are interested in and clean it up
<mikdusan>
andrewrk: I'm just brainstorming here; I seem to recall sourcehut doing sometihg with CPU-ID but admit not paying close attention. if they do some odd cpu reporting, I'm wondering if there is a path ZigClangLoadFromCommandLine takes that causes error
<tdeo>
but yeah, a literal translation is enough to get started with actually
ur5us has quit [Ping timeout: 240 seconds]
<andrewrk>
mikdusan, I think libclang has errors for us and we are not using the API to find them correctly
<andrewrk>
oh! we are passing -march=native. so basically if you try to compile any C program with -march=native on sr.ht it will fail
<mikdusan>
i changed it to -march-skylake and got positive results
<mikdusan>
=skylake
<mikdusan>
and taking out -march entirely i get results so what is clang doing that we can do :)
<daurnimator>
leeward: oh? what do you need?
<fengb>
1717 doesn't specify where an anon function goes so I was assuming it wasn't decided yet. Section on "Where does the anonymous function's code get put?"
<mikdusan>
afk for a bit
ur5us has quit [Ping timeout: 240 seconds]
<fengb>
`typedef uintptr_t (*fn_usize)(*void);`
<fengb>
... why is the identifier in the middle of this statement?
<wilsonk>
if I am trying to access an external C enum member that is a struct and I am getting the error 'expected type [*].structtype found *.structtype' then how to I get the '[]' part? All I am doing in zig is trying to take the address of the c enum.struct ala. '&enum.struct'
<wilsonk>
ok, I coerced it using two coercion steps ala. 'single item pointers can be cast to len-1 single item arrays' in the docs but it is pretty verbose and a little ugly. I have to use it in a couple other spots as well. Is there an easier way, by chance?
alexnask has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen1 has joined #zig
dingenskirchen1 is now known as dingenskirchen
_Vi has joined #zig
dddddd has joined #zig
waleee-cl has joined #zig
zfoo_ has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
marmotini_ has joined #zig
mgxm has quit [Read error: Connection reset by peer]
mgxm has joined #zig
mahmudov has quit [Ping timeout: 260 seconds]
mahmudov has joined #zig
decentpenguin has joined #zig
Xatenev has joined #zig
<Xatenev>
hello
<Xatenev>
when was the first version of zig released? thank you
<Xatenev>
I can'T find it.
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen1 has joined #zig
<Xatenev>
ah, found it on the download page, 2017-10-17 :)
dingenskirchen1 is now known as dingenskirchen
FireFox317 has joined #zig
metaleap has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
LER0ever has quit [Remote host closed the connection]
Xatenev has left #zig [#zig]
<fengb>
I'm so glad circular imports work just fine. Enjoy the little things :P
<shakesoda>
fengb: wonderful
dddddd has quit [Ping timeout: 260 seconds]
daex has joined #zig
<mikdusan>
looks like Cirrus CI 2xCPU and 4GB FreeBSD VM fails with large test too. also it has a 2-hour hardlimit
<andrewrk>
mikdusan, I think we can get them to change the API
<mikdusan>
I don't have the big picture of their stuff, but clang driver is somehow emitting those diags. I'm wondering if they're using a better diags mechanism that we might consider switching to
<andrewrk>
that's a good question
<mikdusan>
my head just spins reading their source... I have a hard time grok'ing CamelCase for members :(
<mikdusan>
that and C++'s allergy to using (should be forced) `this->`
<andrewrk>
the only one left is std.zig due to OOM as we thought
<mikdusan>
thumbs up for test-standalone
<andrewrk>
at least the tarballs will now have docs in them :)
<mikdusan>
yeah on my local FreeBSD VM 4GB doesn't do it. i _think_ 5GB might squeeze by but I use 6GB now.
waleee-cl has joined #zig
Aruseus has joined #zig
decentpenguin has quit [Ping timeout: 260 seconds]
decentpenguin has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
<alexnask>
Hi, quick question, are all C pointers allow_zero? (I would expect so, just want to make 100% sure)
<mq32>
hey alexnask
<mq32>
no, c-pointers are usually optional instead of allowzero
<mq32>
allowzero means that "0x00" is a __valid__ address, not like in C where it's the __invalid__ address
<alexnask>
True, I hadn't considered that.
<alexnask>
I'm working on #4401 right now, allow_zero is passed from the pointer type to the slice type by default and it seems C pointers always end up in allowzero slices (which is wrong)
<alexnask>
Which I've fixed in my branch, just wondering what I can assert about the C pointer type
marmotini_ has quit [Read error: Connection reset by peer]
lunamn has quit [Ping timeout: 240 seconds]
<fengb>
I think there was some talk splitting the implicit optional out from `[*c]`
return0e_ has quit [Remote host closed the connection]
<alexnask>
Wouldn't it be equivalent to [*] at that point?
<fengb>
No, it's still `*` or `[*]`, but we can translate them to `?[*c]`, which is slightly better
<mq32>
you can index a [*]ptr by using ptr.* and ptr[0]
return0e_ has joined #zig
<fengb>
Force the Zig code to double check optionality, which is a common problem in C APIs
<andrewrk>
AlexMax, [*c] pointers are allowzero
<fengb>
Wrong alex 🙃
<andrewrk>
oh wow I didn't even notice
<andrewrk>
alexnask ^
<andrewrk>
it's not planned or even proposed to change this. I'm pretty sure status quo is correct
<alexnask>
Hi :)
<andrewrk>
welcome back!
<alexnask>
Thanks :p Getting acquainted to the C++ compiler again :D
<andrewrk>
much has changed
<andrewrk>
some highlights: translate-c is self-hosted now
return0e_ has quit [Ping timeout: 246 seconds]
<andrewrk>
(still using the libclang API tho)
<andrewrk>
var args is gone
<andrewrk>
but we have tuples
<alexnask>
I took a look at some of the past PRs and commits, mostly metaprogramming ones, also the new async functions etc
<alexnask>
tuples == anonymous lsit literals right? Or did I miss a huge feature? :P
<andrewrk>
ooh, a mail just popped up: [llvm-dev] Moving the AVR backend out of experimental
<andrewrk>
so far I've perfectly guessed every llvm backend that would get promoted next. 3 cycles ago zig was enabling wasm, riscv, and avr for the downloads page build
<andrewrk>
fengb, *shrug* if it solves a problem for you and it makes your code easier to maintain
<fengb>
Haha okay. Just wondering if anyone has trouble following it
<fengb>
Me in 3 months is generally less clever
<andrewrk>
wow that's pretty annoying that you have to use a double for 64 bit ints
<alexnask>
lol
<fengb>
I found that out yesterday :(
<fengb>
Wasm is more advanced than JS >_>
<andrewrk>
idk how you invent an ISA from scratch that runs on a VM and don't give it 64 bit ints
<fengb>
Wasm works with i64 just fine
<andrewrk>
oh I see
<andrewrk>
ABI in this case means "javascript can do stuff with it"
<fengb>
Javascript couldn't represent it at the time. It can now but the JS spec hasn't caught up yet
<fengb>
Yeah, I should clarify it
<fengb>
I'm really afraid of using float bits. It feels so dirty
<metaleap>
the zig binary distribution includes "full src" for std or so i thought. some seem to be excluded though @import-referenced elsewhere, such as zig/parser_test.zig
<shakesoda>
why was typeof renamed anyways
<shakesoda>
i'm not sure why some of the @ stuff has initial caps and the rest not
<mikdusan>
capitalized naming convention for types
<mikdusan>
if it returns a type, capitalize it
<metaleap>
the zig binary distribution includes "full src" for std or so i thought. some seem to be excluded though @import-referenced elsewhere, such as zig/parser_test.zig --- by design? by accident? side-effect of some automated-process+lazy-resolving?
mokafolio has joined #zig
<shakesoda>
mikdusan: that makes sense
<andrewrk>
metaleap, some of the tests are very large. for example lib/std/special/compiler_rt/udivmodti4_test.zig which is 9.8 MiB
<andrewrk>
ability to run the std lib test suite is not considered something that is supported with an "installation tarball"
<andrewrk>
testing std is only needed as part of the development process, which makes sense that you would need the full source tree
<andrewrk>
as of a few days ago, the behavioral tests pass with --test-evented-io
<alexnask>
Yeah I looked into that one quite a bit (including event loop code etc), I have to really try wrap my head around it atm though
<fengb>
The low level is pretty complex. But I really like the high level api
<andrewrk>
if I get this commit done today that I'm working on (self-hosting `zig libc`) then this will be a really nice demo of code that works in both evented mode and blocking mode, yet expresses concurrency
return0e_ has joined #zig
return0e_ has quit [Client Quit]
<andrewrk>
huh. I think we need to be able to "select" on multiple `anyframe` values
Akuli has joined #zig
<betawaffle>
:o yeah, that'd be great
<betawaffle>
or you know... just let us query them directly?
<betawaffle>
i don't want to see zig make the same mistakes Go did
zfoo_ has quit [Ping timeout: 265 seconds]
<andrewrk>
don't worry I don't think anyone intends to write kubernetes in zig
<betawaffle>
lol
<betawaffle>
kubernetes was translated from java
<gchristensen>
so a translation to zig might be the next step?
<betawaffle>
:D howdy gchristensen
<gchristensen>
hey hey
* gchristensen
's just been creeping
<betawaffle>
i'm just waiting for nix to be rewritten in zig, rather than rust
<gchristensen>
not likely, unfortunately
<betawaffle>
yeah, i know
<gchristensen>
though if Zig has a good C++ FFI story ... =)
<betawaffle>
does rust?
<gchristensen>
no
<betawaffle>
it definitely has a good C ffi story
<andrewrk>
afaik the only one is D does. maybe nim since it compiles to C
<fengb>
I don’t think C++ has a good interface to other C++ 🙃
<gchristensen>
pretty much
<alexnask>
C++ FFI requires a full C++ compiler
<alexnask>
:P
<andrewrk>
dom96 can probably weigh in on this
<gchristensen>
I can provide a compiler .... :)
<alexnask>
:D
Aruseus has quit [Quit: Leaving]
<andrewrk>
it is true that zig is able to compile C++, which means your project can have .cpp/.h files to provide a C API on top of a C++ API, and build them with zig alone
<alexnask>
D's C++ is pretty amazing you can even use std::string
<alexnask>
ffi*
forbjok has quit [Ping timeout: 240 seconds]
frmdstryr has quit [Remote host closed the connection]
<alexnask>
--verbose-ir seems to always crash on master right now
Xatenev has joined #zig
<andrewrk>
it doesn't really work with large inputs
<mq32>
fengb: that's a site that greatly shows how bad exceptions mess up control flow
<metaleap>
fengb: lol the "exception" one
<fengb>
I actually disagree in practice. Exception flows are generally pretty great
<andrewrk>
this is the kind of thing I'm talking about when I say that async/await is just a function call
<fengb>
Zig errors flow like exceptions, except you know every site that can happen
<andrewrk>
this is a neat article
<fengb>
But it keeps mentioning jai :(
<andrewrk>
I think the real stinker here is `finally`
<andrewrk>
I've never seen `finally` in a codebase and thought, "that is an appropriate way to model this behavior"
* shakesoda
has always had a rather passionate hatred for exceptions
<companion_cube>
wait, isn't finally just the equivalent of defer??
<mq32>
companion_cube: it is
<mq32>
but in java, you can return from a finally
<mq32>
and override the original return value
<fengb>
Yeah that's messed up
<fengb>
Although I do wish I could error from a defer in Zig :P
<andrewrk>
I think that suspend/resume is basically coroutines
<metaleap>
in case anyone was just wondering: if you `std.zig.parse()` all 374 `$ZIGPATH/lib/zig/std` .zig files (~5MB) at once (keeping the ast.Tree.source field also allocated/non-freed for the lifetime of the Tree as you must), you allocate in total 45MB.
<andrewrk>
in zig
<shakesoda>
fengb: that sounds like it'd make everything crazy
<companion_cube>
mq32: hu, funny.
<andrewrk>
so basically zig has coroutines. it's suspend/resume. and they're intended to be used to create a higher level abstraction of "async functions"
<fengb>
What, then we can introduce errdeferdefer
<fengb>
Or is it defererrdefer
<fengb>
andrewrk: but you won't let me make my generators :pout:
<shakesoda>
coroutines <3
<shakesoda>
i always miss coroutines when i'm writing things that aren't lua
<alexnask>
Cant you just write into some value and suspend to make a generator?
<andrewrk>
fengb, yeah, but it's not a "no", it's just a, "I'm focusing on other design priorities at the moment"
<andrewrk>
alexnask, the problem is the question, "who is in charge of calling resume?"
<metaleap>
Xatenev: you're passing a slice that doesnt point to some known buffer location
<fengb>
alexnask: yeah that's what I did. I'm mostly joking because I ran into major design problems with the current implementation
<andrewrk>
with generators, it is supposed to be the caller. however with zig's coroutines (suspend/resume), it is coordinated by the implementation of the callee
<Xatenev>
metaleap: o i see.
<metaleap>
Xatenev: in other words, your ppm_header points to some random location in memory, and segfault is because you can't write to there
<andrewrk>
anyway, if we have generators they should work with async functions. so that will require a language change to support generators
<alexnask>
Hmm, I guess I really haven't thought it through, I thought it would be sufficient to keep the frame around and resume after each suspend writes the next value
<Xatenev>
metaleap: is the example on the docs outdated or am I missing something?
<metaleap>
well you can see there the slice points to a pre-allocated 100-len array
<fengb>
Use a real array: `var ppm_header: [100]u8 = undefined;`
<Xatenev>
metaleap: yeah, I tried earlier with [100] but direcetly passed the array to bufPrint
<alexnask>
and then ppm_header[0..] in bufPrint
<Xatenev>
yep it works now
<fengb>
Slices in Zig are backed by arrays. By creating an undefined one, you're pointing at random memory (actually it's 0xaaaaa in debug)
<Xatenev>
fengb: yeah its similar to go in that respect I guess
<Xatenev>
atleast it looks that way :)
<fengb>
Go is different because the GC can give you arbitrary memory
<alexnask>
Slices are basically references into contiguous memory (arrays)
<fengb>
In Zig, slices have to be backed by real arrays or given to you explicitly by an allocator
<metaleap>
actually go slices are almost the same under the hood but declaring one, it'll default to "nil" meaning len=0 ptr=0
<metaleap>
but yeah when you append() them or items to them, the hidden array allocations happen then.
<metaleap>
Xatenev: if you're coming from go and looking to append() to "slices", your friend will be std.ArrayList(T)
<alexnask>
string_view is the best slice type /s
<Xatenev>
metaleap: thanks :)
<alexnask>
I'm out for now, good evening everyone
<metaleap>
odd: when i std.zig.parse() ~5MB of zig files, every time I run that the number of bytes allocated varies, between 40MB - 45MB.
<metaleap>
my counting allocator following the std.testing.FailingAllocator alloc/free-bytes-counting logic exactly. are arenas random like that? thought they'd always grab 4KB pages so total allocations should be consistent per run
<andrewrk>
see ya alexnask
<metaleap>
there shouldnt be that much entropy in ever-the-same-process. the files in question dont change between runs, neither does my logic
<andrewrk>
metaleap, maybe strace will have a clue
<metaleap>
hm, lets see if `strace zig build run` will follow down the process tree
<metaleap>
i mean zig build test
<metaleap>
ah i can run it on the test binary thats in zig-cache
<andrewrk>
you can do `zig build --verbose` and then copy-paste the cmd line
<metaleap>
noice, thats one to remember
<metaleap>
well that full syscalls-for-374-file-reads strace output is .. for another day :D
<Xatenev>
the docs here are broken: fs.file.File (Struct) should be fs.File (no idea if its relevant or known) just thought i mention it :p
<metaleap>
std/fs.zig exports File (that becomes std.fs.File) which it got from std/fs/file.zig
ur5us has joined #zig
ur5us has quit [Quit: Leaving]
<metaleap>
funny, my earlier discrepancy in allocations from one run "identical" to the next: i shut down my technically-forever-running/long-running multi-threaded machinery too early / slept too short (this from a `test` mind you).
<metaleap>
now it's always the same
alexnask has joined #zig
<metaleap>
clocking in at a whopping 83MB everytime for keeping around & alive in memory all `ast.Tree`s of exactly 430 .zig files of 5MB
<andrewrk>
kinda makes sense - rendered source code is actually quite an efficient way to store an AST. to parse it is to "unpack" it
Xatenev has quit [Quit: Leaving.]
<andrewrk>
however I foresee the align(0) proposal to be useful here
<metaleap>
well i certainly *did* expect a higher number than those stored :D
<metaleap>
right now its ok for me to be 16MB RAM per 1MB of .zig src-bytes. but when adoption and code-bases everywhere blow up over the years, at some point some unlikely LSP users will balk. nevermind the future tho.
<metaleap>
right now all i know is that more stuff in ram means ready access to more precomputed / not needing to be re-calcd-all-the-time goodies. waiting to be explored
<alexnask>
I remember back in the day there was no comptime allocator, was that added at some point?
<alexnask>
I had a pretty good implementation of interfaces (I think it's along the same lines with Hejsil's with options to customize the storage of the object in the interface obj), should be able to adapt it to comptime too.
<alexnask>
I'll go through the other proposals/PRs and try to come up with some good API
<andrewrk>
ok, if you do that I will come up with my list of use cases that I want to solve with that language feature, and we can discuss from there
<andrewrk>
it's stuff like, "an allocator implementation should be able to have comptime alignment access"
<andrewrk>
"the rules about const and error set coercing should apply to interfaces"
<andrewrk>
stuff like that
<alexnask>
Sure thing
_Vi has joined #zig
<andrewrk>
I'm pretty happy with how this std.fs.Dir API is coming along. it's turning out to be simpler to use that than mess with paths, and it's the better way to do things anyway
<andrewrk>
for example if you want to check if a directory has some file paths - you could accept an allocator and mess with paths, and have a race condition. Or you could just open the directory, defer dir.close() and use dir.access(), and not have any race conditions
<Sahnvour>
about comptime allocator, I wonder if it can be emulated by comptime u8 arrays and type coercion for now
<alexnask>
Yeah you could probably do something like that
<alexnask>
The whole point is to write a single version of the code for both comptime and runtime though
<Sahnvour>
just an idea I wanted to try for fun :)
<alexnask>
The compiler never frees afaik
<alexnask>
So you should be able to initialize a buffer and leak it from a comptime function (?)
<alexnask>
You cant cast memory to arbitrary types though
<fengb>
There's a few compiler errors with how the allocator interface is working atm
<fengb>
Hmm... do we need vectors of bools? Is there something old school bit operators can't work?
<wilsonk>
is there a way to automatically coerce a single item pointer to a len-1 single-item array with a comptime func or anything? Or do we just have to manually write it out over three lines of code every time? Example in the coercion portion of the docs https://ziglang.org/documentation/master/#Type-Coercion-Arrays-and-Pointers
<andrewrk>
fengb, bool and i1 are the same thing and they can be bitcasted
<andrewrk>
wilsonk, you could write a function to do it. maybe it should be in std.mem
<alexnask>
This is a version that just takes the pointer
<alexnask>
as a parameter
<fengb>
Showoff
<alexnask>
:P
<fengb>
And also it compiles properly too
<alexnask>
Godbolt is bae
<wilsonk>
alexnask: nice, that one worked for me...not to say fengb's wouldn't work for someone that knew the difference, but I just plugged each function into my code and the second one worked out of the box. Thanks
<fengb>
Mine wasn't even compiling lol -_-
<wilsonk>
It is also possible that this is unnecessary and I am just interacting with C in a poor way
<wilsonk>
heh, yes that was my problem also ;)
<alexnask>
I dont really see why you would need a lot of *[1]T pointers
<andrewrk>
ah. yeah with C such a function is useful
<wilsonk>
^^
<andrewrk>
but wait - *T casts to [*c]T
ur5us has joined #zig
<fengb>
It happens a few times in std
<andrewrk>
I'm going to grab some food and then planning to stream at 6pm EST (in 1 hour)
<alexnask>
windows build takes so long on the CI server :D
<fengb>
Whoo
<andrewrk>
gonna do more easy high level game dev stuff, I'm tired of debugging hard problems in front of an audience xD
<fengb>
Isn't Zig your ultimate yak shave?
<andrewrk>
it's pretty far down the yak stack
<andrewrk>
I have a lot of different projects I want to do, but they all need a programming language to do them in :)
daex has quit [Ping timeout: 240 seconds]
Akuli has quit [Quit: Leaving]
daex has joined #zig
<fengb>
But it's 2020. You should totally implement it in JS
ur5us has quit [Ping timeout: 240 seconds]
<alexnask>
simulate a universe in TypeScript
<alexnask>
(+ Electron)
<fengb>
Actually that ship is no longer cool. You should totally implement it in Rust / wasm
<alexnask>
TypeScript and Rust are both pretty neat tbh :P
<companion_cube>
fengb: that sounds far too efficient