<Snektron>
its used in a few places throughout the std library
<Snektron>
eh
<Snektron>
matrix glitched
<fengb>
Deja vu? 🙃
<ifreund>
so, translate C should know how to do that I guess
<ifreund>
unrelated, but is there currently a way to run an external program from within zig? something like `execl` in c
<ifreund>
(can't use execl since the ABI is not yet supported)
<ifreund>
ah looks like ChildProcess may be what I'm after
marijnfs has joined #zig
tane has quit [Quit: Leaving]
return0e_ has quit []
marijnfs1 has quit [Ping timeout: 250 seconds]
jjido has joined #zig
marijnfs has quit [Quit: Lost terminal]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mikdusan>
ifreund: do you want to exec or spawn?
<ifreund>
i want to fork() and execl() in c
<ifreund>
so spawn?
<mikdusan>
yes you want spawn
<mikdusan>
are you looking to capture output?
<mikdusan>
*stdout
<ifreund>
no, don't really care
* daurnimator
waves
<mikdusan>
oh wait I haven't looked at ChildProcess.exec* functions. they may not be "exec" in the posix-sense.
lqd_ is now known as lqd
<daurnimator>
ifreund: avoid fork()+exec() if you can: use posix_spawn...
<daurnimator>
(in C that is)
<daurnimator>
but also probably good advice for zig's ChildProcess module
<mikdusan>
not a fan of exec2 impl. try spawn and you probably want to .Inherit stdout/stderr unless desire is to hide output
<daurnimator>
(at least when libc is linked)
<mikdusan>
daurnimator: are you a heavy archlinux user?
<ifreund>
daurnimator: yes I'm aware that posix_spawn() is the way to go in more modern c, was looking for something convienent in the zig std though
<daurnimator>
mikdusan: yes
<mikdusan>
gotta say... installed archlinux for sole purpose of building/debug zig... and it's really painless to keep archlinux updated.
<daurnimator>
ifreund: yeah ChildProcess..... it does need a nonclemanture cleanup though
<daurnimator>
mikdusan: gonna be a full time convert? :)
<shakesoda>
mikdusan: just let it not be updated for a while, and things become increasingly hellish
<mikdusan>
heh if macOS restricts command-line binaries any more, I might have to bail
<daurnimator>
shakesoda: as long as you update once every 4 years or so you'll be fine
<fengb>
I’ve only had like 2 breaking changes since running Arch. And 1 of them was telegraphed well in advance (systemd)
<shakesoda>
pacman has hosed a system or two of mine and i've sworn it off for keeps
<fengb>
Eh, just don’t try a partial upgrade and things generally work. I’ve had years of out of date
<mq32>
fengb: Yeah, arch is surprisingly stable for what people tell about instability
<ifreund>
yeah arch has been super stable for me
<daurnimator>
I've got one arch system originally installed in 2008 and it still just keeps coming along
<fengb>
The other time was smbd changed its systemd names and I wasn’t aware. That was a bit annoying since things mostly worked
<mq32>
i had two breaking experiences with arch. One wasn't the fault of arch, it was just the package maintainer was like "hey, let's break everything from 2.0 to 3.0 and don't provide config migration"
<mq32>
the other one was my stupidity of having a power loss on updating the kernel + modules
<mq32>
the power loss happened between "deploy new kernel" and "deploy new modules"
<ifreund>
fun
<mq32>
it was an adventure fixing this :D
<mikdusan>
I am getting tired of short power outages these days. May actually invest in a 5-minute UPS.
<ifreund>
no fallback kernel?
<mq32>
not at this time :D
return0e has joined #zig
<fengb>
Has anyone used VoidLinux?
hazeycode has joined #zig
<Nilium>
fengb: I use it.
daex has quit [Ping timeout: 264 seconds]
<hazeycode>
if (std.cstr.cmp(layerName, &layerProperties.layerName) == 0)
<hazeycode>
produces error: expected type '[*:0]const u8', found '*const [256]u8'
<hazeycode>
im so confused about strings, can anyone help me?
<daurnimator>
hazeycode: they changed just a couple of days ago. various bits will need to catch up
<fengb>
Zig doesn’t think one of them is 0 terminated
<daurnimator>
hazeycode: what is the type of `layerProperties.layerName`?
<hazeycode>
apparently the type is *const [256]u8
<hazeycode>
it's from a c header
daex has joined #zig
<daurnimator>
hazeycode: zig has no way to know that its null-terminated: if the library is documented to do so then you could cast it.
<fengb>
Why not [*:0]const u8? Might be early terminated
<daurnimator>
fengb: yeah I was thinking that... depends if its zero extended or just the one null terminator
<hazeycode>
it probably will be early terminated
<hazeycode>
but *:0 produces error: cast increases pointer alignment
<fengb>
wat, u8 alignment should be 1
<daurnimator>
hazeycode: shouldn't... did you write: `@ptrCast([*:0]const u8, &layerProperties.layerName)`?
<hazeycode>
daurnimator: I did not, that works just fine :)
<hazeycode>
my bad
<hazeycode>
really loving zig, except for all the different pointer types. I get the point, and maybe I'll get used to it but it's quite a faff
<fengb>
It’s a pain working with C because it just doesn’t care
<daurnimator>
hazeycode: zig's priority isn't intended to be easy to write: its supposed to be easy to debug and read.
<shakesoda>
fengb: but that's the best thing in c
<shakesoda>
it just doesn't give a crap
<hazeycode>
yeah I'm down with the principles of zig, just the c interop is quite painful for me at times
<daurnimator>
hazeycode: you might notice how the @ptrCast is "loud" it explains that this is something that is just documented behaviour of the library and might not necssarily be true
<daurnimator>
that should jump out at a reviewer and suggest they go verify that it *is* null terminated
<fengb>
Buffer overrun is quite common in C :P
<daurnimator>
if not true: you probably have a buffer over-read bug (which can be a cause of information leakage like heartbleed)
<hazeycode>
yeah it's a cool feature for sure! I'm just having teething pains :)
<shakesoda>
you get used to the pointer stuff reasonably quickly once you start building things instead of just doing interop
<shakesoda>
it's never as bad as when you're trying to interface with some crazy translated c stuff, heh
<hazeycode>
although I have to say, I went back to C from Rust for stuff I typically do, because C doesn't care and I can get stuff done haha
<fengb>
Well Rust cares too much >_>
<hazeycode>
In fact I've gone back to C from everything else. I think Zig might be the one :D
<shakesoda>
yeah rust is *ridiculously* obsessive, and frustrating
<shakesoda>
also, it inherited too many of c++'s ways to hide what is actually happening.
<hazeycode>
and its compile times !!!!
<hazeycode>
:D
<shakesoda>
heh, that too
<shakesoda>
I do think it's reasonably designed and better for the world than c++ is, but it's just really frustrating
<fengb>
I like Zig because it’s just the right kind of anal >_>
<hazeycode>
:eyes:
<shakesoda>
zig has the right balance, a lot more aligned with the things I care about
<andrewrk>
it will be really good after we can merge anal dumps
<shakesoda>
oh
<mikdusan>
btw when we do stage2 cli driver, let's consider "-###" option
<fengb>
When I have some friction, it’s usually because I’m doing something no type system could represent or it’s actually ambiguous
<andrewrk>
mikdusan, "Print (but do not run) the commands to run for this compilation" ?
<mikdusan>
aye
<mikdusan>
i get that zig doesn't spawn much but I still like dry-runs
<mikdusan>
and what in the hell. first "anal dumps" and no "dry runs". I mean what am I discussing here.
<mikdusan>
*now
<andrewrk>
hmm. you can kinda get that with --verbose-cc --verbose-link -fno-emit-bin
<hazeycode>
brb, need more toilet paper
hazeycode has quit [Ping timeout: 240 seconds]
UgiDesu has quit [Read error: Connection reset by peer]
waleee-cl has quit [Quit: Connection closed for inactivity]
adamkowalski has joined #zig
adamkowalski has quit [Client Quit]
return0xe has joined #zig
return0e has quit [Ping timeout: 264 seconds]
rappet has quit [Ping timeout: 272 seconds]
rappet has joined #zig
return0xe has quit [Remote host closed the connection]
<pixelherodev>
Sorry about bumping the issue count above 1000 :P
<shakesoda>
ah, yes: attempt to bufPrint -> break the compiler
<shakesoda>
how dare i have the audacity to try to format...
* shakesoda
checks
<shakesoda>
a u32
<mikdusan>
lies!
<shakesoda>
the actual issue was something to do with re-slicing the buffer into a null terminated thing, i just wrote it a different way and it's fine
<pixelherodev>
I have a failure analyzing inferred error sets... :P
<andrewrk>
i have it working
<andrewrk>
zig cc as a drop in c compiler
<daurnimator>
andrewrk: oooo, nice!
<daurnimator>
with all args as described in the json thing?
<andrewrk>
yes. good night
<daurnimator>
night!
dddddd has quit [Ping timeout: 250 seconds]
<shakesoda>
andrewrk: sweet
<mikdusan>
pixelherodev: where's the reduction for #4770
doublej41 has joined #zig
doublej472 has quit [Ping timeout: 260 seconds]
<shakesoda>
hmm, symlink to zig binary can't find zig lib dir anymore
<shakesoda>
had to put a symlink to that folder next to the other link (gross!)
<mikdusan>
platform?
<shakesoda>
linux
<mikdusan>
where is zig root dir, and where is the binary symlink?
<shakesoda>
~/opt/zig-whatever-revision-folder/zig is symlinked at ~/.local/bin/zig (which is in my $PATH)
<daurnimator>
shakesoda: I have a similar setup. no issues.
<shakesoda>
on latest revision?
<daurnimator>
yep
<shakesoda>
on the build I grabbed on monday it worked here, too
<shakesoda>
latest doesn't want to play ball
<shakesoda>
the workaround is easy, but it's kinda bizarre
* mikdusan
has ~/.local/bin/zig -> /home/mike/opt/zig-master/bin/zig
<mikdusan>
works
<mikdusan>
0.5.0+153c6cf92
<mikdusan>
I also have the other "style" working: ~/.local/bin/zig -> /home/mike/opt/zig-linux-x86_64-0.5.0+153c6cf92/zig
<shakesoda>
i wonder what's going on with my system then, it's nothing weird or different
<shakesoda>
need to reboot for a kernel update anyway, maybe it'll go away like magic
<shakesoda>
I found the problem
<mikdusan>
/proc ?
<shakesoda>
on this particular attempt, when I symlinked it I forgot the -s flag
<shakesoda>
not... quite a symlink.
<shakesoda>
haven't screwed that one up in years, must be too late for me :D
<mikdusan>
yeah we can't cheaply find all hard links to the same inode
daex has quit [Ping timeout: 264 seconds]
daex has joined #zig
frett27 has joined #zig
frett27_ has joined #zig
frett27 has quit [Ping timeout: 250 seconds]
frett27_ has quit [Read error: Connection reset by peer]
frett27_ has joined #zig
Kingsquee has quit [Quit: Konversation terminated!]
daex has quit [Ping timeout: 246 seconds]
jjido has joined #zig
daex has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
TheLemonMan has joined #zig
<TheLemonMan>
pixelherodev, how the hell did you get a stack trace without any line infos?
<Snektron>
<fengb "Has anyone used VoidLinux?"> I run it on my rpi
jjido has joined #zig
frett27 has joined #zig
frett27_ has quit [Ping timeout: 250 seconds]
marijnfs has joined #zig
_whitelogger has joined #zig
daex has quit [Ping timeout: 246 seconds]
<marijnfs>
how do you get the the type a pointer points to with meta/traits?
<TheLemonMan>
marijnfs, meta.Child
<marijnfs>
TheLemonMan: thanks
<marijnfs>
i wanna add some serialization for [] types. The deserialization would need an allocator i guess, but would be really convenient
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 250 seconds]
_Vi has joined #zig
<frett27>
hi, i wish to convert a pointer of arbitrary time to []u8, how can i do that ?
<TheLemonMan>
it's again a view over the original `bytes` slice
<TheLemonMan>
slices don't own any memory
<frett27>
ok, make sense
dddddd has joined #zig
return0e has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 264 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
return0xe has joined #zig
frett27_ has joined #zig
frett27 has quit [Ping timeout: 250 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 264 seconds]
waleee-cl has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 256 seconds]
Barabas has joined #zig
<Barabas>
Hello
<Barabas>
I had some update for visual studio and I updated my zig to some newer version. I don't know which one caused the issues, but I'm getting linker errors about libcmtd.lib, libvcruntimed.lib, legacy_stdio_definitions.lib, OLDNAMES.lib
<Barabas>
Hmm....
mahmudov has joined #zig
<Barabas>
I swear I saw something about not including system paths anymore or something, but I can't find it
<Barabas>
Ok, the zig version I was on before also doesn't seem to work anymore... I guess it's the visual studio upgrade. I bet they changed directories so nobody can find the stuff they need. (as usual)
Barabas has quit [Remote host closed the connection]
<andrewrk>
Barabas, you need to addLibPath to give the directory, and linkSystemLibrary if it is a DLL; otherwise give the absolute path to addObject
<pixelherodev>
That's slightly out of date but the error occurs on there too so it's good enough
<Barabas>
ok
<andrewrk>
oh I see you do this in the bottom snippet
<Barabas>
Yes, it just has more dependencies somehow which it tires to find as .a files?
<Barabas>
I'm really not sure what's going on at this level :P
slowtyper has quit [Quit: WeeChat 2.7.1]
<TheLemonMan>
frett27_, check out std.meta.trait
<TheLemonMan>
pixelherodev, I'll check it out asap
<frett27_>
TheLemonMan, thanks
<andrewrk>
Barabas, hmmm. I'm not sure what's pulling in those .a files. can you add --verbose-link to your `zig build` command?
<andrewrk>
I suspect that LLD got too smart for its britches and thinks it should do some kind of mingw thing
<pixelherodev>
TheLemonMan, huge thanks
<pixelherodev>
If you get it working, I'd love to know how you went about debugging it
<pixelherodev>
(Like I mentioned, I can't get it reduced)
<pixelherodev>
And I have no idea what's wrong with my stack traces :(
slowtyper has joined #zig
<Barabas>
not sure if I should paste it here so I put it in the issue
<andrewrk>
Barabas, ah, ok it looks like -lldmingw is the culprit, let me try to think why that would get put there
<Barabas>
it does mention mingw
<andrewrk>
I wonder if this is a regression after updating to mingw-w64 7.0.0
<andrewrk>
Barabas, thanks for the report. I'm going to try to reproduce this issue and solve it
<TheLemonMan>
pixelherodev, does the test-stack-traces pass for you?
<Barabas>
Thanks for looking into it :)
<Barabas>
I also would like to know why it suddenly doesn't find the standard msvc libraries anymore
<Barabas>
Oh... it does work if I run it from the `x64 Native Tools Command Prompt for VS 2019`
<Barabas>
(Without specifying gnu)
_Vi has quit [Ping timeout: 260 seconds]
mahmudov has quit [Ping timeout: 264 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Barabas>
My bad for not trying that earlier. I did kinda try it, but with powershell which doesn't really work :P
dddddd_ has joined #zig
dddddd has quit [Ping timeout: 246 seconds]
dddddd_ is now known as dddddd
<mikdusan>
so why do zig executables export 40,000+ "weak def" symbols (on macos,linux,freebsd) ?
<TheLemonMan>
that's compiler_rt
<TheLemonMan>
oh 40,000... that's a lot
<TheLemonMan>
do they have names?
<mikdusan>
big numbers come from llvm::*, lld::*
<mikdusan>
having them _during_ link (ie. .so/.dylib) I get that... but these are executables.
<TheLemonMan>
oh you mean in the compiler executable
<mikdusan>
on macos I passed a special linker flag to export nothing in the executable, and it saved 3.5 MB for Debug binary. the exectuable worked fine running some test-compiler-errors. there was no observable "performance" advantage.
<mikdusan>
yes I mean to say "zig.exe" itself.
<frett27_>
TheLemonMan, tested traits, but i went with something wrong,
<pixelherodev>
What are the problems that this solves?
<andrewrk>
frett27_, I think the "isSlice" trait is no longer useful for this purpose. I suggest to not use it, or use a different one that indicates a better concept of a "memory span"
forgot-password has joined #zig
<forgot-password>
With wasm, is it possible to import WebAssembly.Memory via `extern`?
<fengb>
It should be. The WASI implementation shows how you can import
<frett27_>
andrewrk, makes sense
<pixelherodev>
fengb, thanks
<forgot-password>
fengb: What do you mean exactly? In std/os/wasi.zig I can't find anything
<pixelherodev>
This has definitely been said before, but why does isWasm get compiled into runtime code?
<pixelherodev>
s/said/asked
<fengb>
Oh I thought there’s a extern variable definition in there
<TheLemonMan>
because the compiler doesn't know it's not useful in the final binary
<TheLemonMan>
and it's used in start.zig
<pixelherodev>
Ah. ... okay but why (is it used in start.zig)?
<TheLemonMan>
because we want to know if we're targeting Wasm
<TheLemonMan>
it's used to export the correct _start symbol there
<forgot-password>
When I do `extern "js" var js_memory: []u8` (What should the type be anyways?) I get a compile error telling me that the variable is not defined when I try to use it
<pixelherodev>
Ah, so Zig doesn't yet know not to export functions that can be used both at comptime and runtime if they're only used at comptime?
<TheLemonMan>
yeah, if you don't want that in your binaries take advantage of the linker GC capabilities
<TheLemonMan>
and pass -ffunction-sections
<forgot-password>
Aha, so when I change the type to `extern "js" var js_memory: u8` the compiler at least seems to notice my declaration and doesn't just ignore it
<fengb>
Type should be `[*]u8` because slices aren’t ABI compatible
<fengb>
But it’s trying to link in the variable with the linker hmm
<forgot-password>
I'm sorry that's what I meant. The error is still the same, though
<forgot-password>
Yeah, lld is complaining about that, you're right
<pixelherodev>
TheLemonMan, this is for my backend - that is, I *am* the linker :P
<pixelherodev>
I'm going to have to implement that myself later
Akuli has joined #zig
<fengb>
Hmm I can't seem to convince it to import it. Can you open an issue?
<TheLemonMan>
pixelherodev, I have a patch for your problem!
<TheLemonMan>
open src/AST.zig line 219 and change `union` to `union(enum)`
<pixelherodev>
... huh. Interesting. Thanks!
<fengb>
Importing functions just works for wasm though
<pixelherodev>
... which union is this?
<TheLemonMan>
Call
<pixelherodev>
I've made changes since so the line is different
<pixelherodev>
Thanks!
<TheLemonMan>
np, I'll write a patch to catch this problem
<pixelherodev>
... doesn't work :(
<pixelherodev>
Going to push current
<fengb>
Potentially crappy workaround: can you use JS to copy the data into the wasm memory?
<TheLemonMan>
uh weird, it runs fine here
<pixelherodev>
I pushed the current status
<TheLemonMan>
but halts with `AST generation failed!`
<pixelherodev>
TheLemonMan, it's probably because I've reorganized that union locally
<pixelherodev>
Yeah I'm not surprised by that
<pixelherodev>
The IR generated from the test is different in other build modes
<pixelherodev>
And the AST generator isn't fully implemented yet
<pixelherodev>
I've been using the partially finished generator to implement parts of the backend, which can then be used to better test the AST generator when I finish implementing it and vice versa
<pixelherodev>
Once the backend's done I plan on implementing unit tests so I can detect if e.g. an AST generator change breaks the backend's register allocation
<TheLemonMan>
hmm, you have some more similar problems, let me push a PR for the compiler so that you can easily spot them all at once
<TheLemonMan>
what strategy are you using for the register allocation?
<pixelherodev>
Well, first I need to explain the calling convention a bit
<pixelherodev>
Basically, it (for compatibility with a different language) uses two separate stacks
<pixelherodev>
The hardware stack is used for function calls
<pixelherodev>
And a stack with its pointer as r5 is used for arguments
<pixelherodev>
Register allocation basically works by assigning registers to all allocations and load results before translating any opcodes
<pixelherodev>
When an instruction needs to access an allocation, it notifies the allocator and passes it the stream
<pixelherodev>
it can then e.g. move allocations from registers to the stack to make room, and then moves the requested allocation into registers and returns a handle, which the instruction emitter uses to identify the register the value is placed in
<pixelherodev>
I'm currently using caller-saving of registers to make it easier to implement
<pixelherodev>
When calling a function, all used registers are pushed to the r5 stack
<pixelherodev>
Currently, args are loaded into registers, though I might swap this around (the calling convention is honestly half-assed right now)
<forgot-password>
fengb: I just wanted to create a FixedBufferAllocator with an explicit buffer passed from JavaScript. std.heap.page_allocator does the job fine as well :)
<pixelherodev>
Then any future instructions move the allocations back into registers so they can continue being used
<forgot-password>
The reason being that I wanted to access the memory from JavaScript, but with std.heap.page_allocator you never know when that memory is "grown away" from you
return0e_ has joined #zig
<fengb>
Ah right
<fengb>
Just allocate 1GB so it’ll never go away 🙃
<pixelherodev>
What's the root of the issue? Should I not be using untagged enums?
<pixelherodev>
s/enum/union
<pixelherodev>
I've got it building locally now by switching all untagged unions to `union(enum)`
return0e has quit [Ping timeout: 250 seconds]
<fengb>
But yeah it seems like this is a limitation in the implementation or docs
<forgot-password>
I guess you are right, web pages allocating a gig of memory shouldn't surprise anyone today, haha
<pixelherodev>
Uh no
<pixelherodev>
That surprises me a *lot*
<pixelherodev>
(I only ever use the internet with JS disabled, among other restrictions, so)
<fengb>
Sites don’t usually use that much. Browsers like to eat memory for breakfast though
<TheLemonMan>
pixelherodev, untagged enums have no concept of active field, checking those against an enum literal makes no sense
<pixelherodev>
... they... ohhh.
<pixelherodev>
Thanks a ton
<pixelherodev>
Weird that it worked in debug mode though
<TheLemonMan>
except that in non-release mode the compiler silently adds a hidden field to track the active slot
<pixelherodev>
oh. That would do it.
<pixelherodev>
Huge thanks :D
<TheLemonMan>
np
<pixelherodev>
Almost got runtime down to single-digit milliseconds
<pixelherodev>
Average of 12ms now
<pixelherodev>
But >92% of that is just the lexer, so I can probably get it down to 2-3 ms just by switching to LLVM bitcode instead of human-readable IR
<pixelherodev>
Alternately, could shave off multiple milliseconds by reordering the lexer comparisons so the most-used tokens are checked before the least-used instead of checking them all in a single unordered go
<andrewrk>
it should be a compile error to check an untagged union against an enum tag=
<TheLemonMan>
yeah, I have a PR ready
<forgot-password>
pixelherodev: Well, I do web development for work and some apps (whatever you wann call them) are absolutely horrific. Mostly due to low budget though
<pixelherodev>
"apps" <- that's exactly why I run with JS disabled
<forgot-password>
Yeah, I totally get that
<fengb>
Doesn’t have to be about budget. Slack is my goto app to make fun of
<pixelherodev>
Well, half of the reason
<TheLemonMan>
andrewrk, #4764 is ready
<pixelherodev>
The other half is that I disabled the specex/meltdown mitigations on my computer to increase performance, and the cost is that running JS has now gone from "potentially safe" to "not even close"
<forgot-password>
Obviously, without JS the memory usage is probably not an issue
<andrewrk>
TheLemonMan, thanks I'll take a peek
<pixelherodev>
Hah, got it! Average run time is now 8 milliseconds, but it varies between 5 and 11
<fengb>
When are you merging it into Zig proper? :P
<pixelherodev>
If that *ever* happens, it would take *months* minimum just to finish the implementation, clean up bugs, and implement an x86/x64 backend
<pixelherodev>
Then likely a few more days/weeks to get it up to Zig upstream standards
<pixelherodev>
Hah! Even better! Now it varies between 5 and 8 (though it's almost always eight now)
<pixelherodev>
Does zag buffer stdout?
<TheLemonMan>
no, unless you wrap stdout/stderr in a bufferedOutStream
<pixelherodev>
That's what I thought
<pixelherodev>
(Explains why removing debug prints shaved off half the runtime :P)
<andrewrk>
dom96, I wonder if nim would benefit from shipping with zig rather than msvc/gcc/clang (I'm not sure exactly what C compiler components nim currently distributes)
<andrewrk>
it might, for example, decrease the tarball size of nim, or make cross compiling work
<andrewrk>
I promise you I am not trolling
<fengb>
So this means zig will be able to build zig huh? Self-host complete 🙃
<pixelherodev>
Hold on, does the 45MB tarball include the LLVM backend?
<pixelherodev>
'cause that post strongly implies the answer is yes
<mikdusan>
#3089 what is plan for drop-in usage and -MD/-MV/-MF are used?
<pixelherodev>
45MB tarball includes LLVM 9?
<dom96>
andrewrk, somebody suggested this already heh, might make sense actually but not sure Araq can bring himself to allow that :P
<dom96>
What is this cross compile magic that clang/gcc cannot ship though? Why can't they ship it?
<andrewrk>
mikdusan, the plan is if any of those args are supplied, the cache system is disabled
<andrewrk>
mikdusan, I'll push this branch and open a PR so that it can become contributor friendly to those interested
<andrewrk>
pixelherodev, it includes the zig executable, which exposes the clang executable as well. it does not include llvm .h files or .a files however
<pixelherodev>
So it'd still need an LLVM download? What does that bring the *total* size to?
<pixelherodev>
i.e. if you have a single tarball you can download onto, say, a fresh Windows 10 install, or a GCC-based distro, how big would it be?
<andrewrk>
dom96, it's actually quite a lot of additional work on top of clang. zig ships with a subset of musl libc source files, a subset of glibc source files, a subset of mingw-w64 source files. there are some patches applied, and some header file preprocessing. and finally the build systems each are ignored; instead zig compiler knows how to build them from source, and it integrates tightly with the way target settings work
<andrewrk>
for musl and glibc, it involves building the projects N times (1 for each target) and then running some post-processing tools to create the files that zig actually ships with. zig is actually capable of targeting all 42 glibc versions
<pixelherodev>
Is it possible to tell Zig to emit LLVM BC instead of IR?
<andrewrk>
not currently but would consider a proposal to expose that capability
<pixelherodev>
In that case, is it possible to tell Zig to pipe the IR into another process instead of - no, from when I was implementing the build system changes, I didn't see that...
<pixelherodev>
Would a proposal to allow piping the output of a build system invocation into another process be considered?
<andrewrk>
dom96, oh, and also zig maintains an implementation of a multi-target compiler-rt which is a non-trivial amount of work (as TheLemonMan can tell you)
<andrewrk>
if Araq changed his mind I would be happy to cooperate
<pixelherodev>
Hm, Zig is generating invalid inline asm
<pixelherodev>
As a test, I ran `opt` on the test IR file
<dom96>
andrewrk, since choosenim is already something we recommend to most people installing Nim it would probably make sense to integrate it there, and since I own that project I can easily implement that. The only problem is time :)
<andrewrk>
is choosenim responsible for getting a C compiler installed and configured?
<andrewrk>
TheLemonMan, regarding 4764 - I want to play with the unused variable thing. I'm a bit confused how that works
<TheLemonMan>
I've just cargo-culted that from `catch`, it basically catches the case where the body is `unreachable`
<andrewrk>
ohh it's actually checking the AST node type, not the actual type
<andrewrk>
right, ok
<andrewrk>
nice work
mahmudov has joined #zig
<andrewrk>
TheLemonMan doing the lord's work, tryna get that issue count below 1,000
<TheLemonMan>
hah I'm trying hard to reach that sweet 999
<TheLemonMan>
there are a few stale issues that can be closed tho
adamkowalski has joined #zig
Bekwnn has joined #zig
Barabas has quit [Ping timeout: 240 seconds]
<dom96>
andrewrk, only on Windows
<andrewrk>
oh very interesting, so on posix, nim integrates with the system c compiler?
<dom96>
yep
<dom96>
you can also use vcc on windows if you have it AFAIK
mahmudov has quit [Ping timeout: 264 seconds]
<Bekwnn>
Anyone here using zig on win10? "zig build > compile_output.txt" seemingly doesn't co-operate on win7. The resulting .txt is empty and everything spews out to console.
<andrewrk>
`zig build` prints to stderr
<Bekwnn>
ah thanks, looks like adding 2>&1 to the end did the trick
forgot-password has quit [Ping timeout: 264 seconds]
<Bekwnn>
I kinda tried poking around build.zig in the std, but how exactly does addCSourceFile() work? Seems like dark magic to me
<Bekwnn>
currently dealing with undefined function in some source files but not others
mahmudov has joined #zig
rappet has quit [Quit: No Ping reply in 210 seconds.]
<ifreund>
as I understand it `addCSourceFile()` is what you use if you need zig to compile c code for you
rappet has joined #zig
<ifreund>
for example, you could use that to compile a test.c and include a corresponding test.h in your zig code with @cImport()
<adamkowalski>
andrewrk: i loved the stream yesterday. I think being able to use the zig compiler as a drop in replacement for clang is gonna help adoption tremendously
<Bekwnn>
right I mean I figured it probably assumes a header with the same name in the same directory as the C file you're including, but in this case it's seemingly grabbing the declaration in the @cInclude(.h) fine and not throwing any errors, but later on it's throwing an error about the function not being defined. Even though it's seemingly not
<Bekwnn>
complaining about the source file with said definition being included
<adamkowalski>
I'm gonna try to use that as an excuse to use that for our next greenfield project we are starting in a couple weeks
<Bekwnn>
>Even though it's seemingly not complaining about the source file with said definition being included
<adamkowalski>
then i'll try and convince them to write new modules in zig instead of c++, and move from cmake to the zig build system
<Bekwnn>
as addCSourceFile() in the build.zig, I mean
<adamkowalski>
then i'll try to deprecate the c++ and I snuck zig in right under their nose
<adamkowalski>
just don't tell anyone i'm going to `export CC="zig cc"` and `export CXX="zig cc"`
<shakesoda>
adamkowalski: devious
<shakesoda>
adamkowalski: i like the way you think
<adamkowalski>
haha yeah we will see how it goes
<ifreund>
Bekwnn: header doesn't have to have the same name, that was just an example.
<ifreund>
it sounds like you have a linking error, are you sure the c function declaration matches the definition?
<ifreund>
not 100% sure but the order of things in your build.zig might be important, try putting the addCSourceFile() earlier if possible
<Bekwnn>
It's a bit of a frankenstein mish-mash. I'm attempting to use cimgui, which works, but attempting to use the imgui_impl_opengl3/sdl2 files is stumbling on the function definitions. Those parts are c++, but another user on here got it working.
<pltrz>
got an error building a project with a recent zig: "/usr/lib/zig/std/build.zig:1682:28: error: container 'std.io' has no member called 'BufferOutStream'"
<pltrz>
looking at build.zig, seems like there is BufferedOutStream, but not BufferOutStream
strmpnk has quit [Quit: Updating details, brb]
strmpnk has joined #zig
<andrewrk>
pltrz, `your_buffer.outStream()`
<andrewrk>
the API got simpler
adamkowalski has quit [Quit: Lost terminal]
forgot-password has joined #zig
<pltrz>
cool, it's actually for https://github.com/dbandstra/oxid - I will see if I can put my noob skills to work and maybe fix it for that guy
<Bekwnn>
ahh, actually maybe I shouldn't have been ignoring these #pragma pack warnings...
<Bekwnn>
might be an x86 vs. x64 thing..
<andrewrk>
fengb, so, you were joking about bootstrapping earlier, but using `zig cc` to build zig actually has a clear benefit: producing builds of zig for any target. once you have `zig cc` available (and we improve it to support c++ code as well) then one could use it to build llvm/clang/lld for a different target, and finally the zig compiler itself for a different target
<andrewrk>
mipsel tarballs on the download page, here we come
<fengb>
wasm too? :P
decentpenguin has quit [Quit: decentpenguin]
<mq32>
> and we improve it to support c++ code as well
* mq32
is excited
<mq32>
would be cool if we could ship libc++ with zig as well
<mq32>
this would make zig the single-best c++ crossdev environment available
<jwh>
as long as its configurable :P
<andrewrk>
mq32, I just looked into it, it's doable. only 15k lines for libc++, and 6k lines for libc++abi
<andrewrk>
it would add an estimated 108 KB to the tarball size, 629 KB to the installation size
<mq32>
it looks like it contains the headers already
<mq32>
ah :)
<mq32>
but yeah, building a c++ standard lib with the same convencience as with libc with zig would be totally awesome
<andrewrk>
and then that's where we stop. everything from there can be done with packages
<mq32>
yep
<mq32>
because every package can be built from source then
<mikdusan>
zig-cc: is the logic that as soon as .passthrough is seen, regardless of what args are processed thus far, punt to clang driver?
<andrewrk>
mikdusan, yes
student069 has joined #zig
<andrewrk>
mikdusan, if you look at the top of tools/update_clang_options.zig you can see a list of known options and which ones are "passthrough". it's only --help currently
<andrewrk>
maybe that could be named better
<andrewrk>
options that do not match anything are passed through
<mikdusan>
we need to punt when "-E" and (if cc1 is to be understood) "-cc1 -Eonly"
<Bekwnn>
sanity check: If I'm able to find a symbol in the .obj file in zig-cache/o, that means that symbol is defined?
<andrewrk>
"punt" would be a name improvement
<Bekwnn>
or is it possible to have just declarations in /o
<Bekwnn>
they're usable example bindings for a few popular setups that are "usable as-is" or modifiable to suit your purposes
<mikdusan>
andrewrk: is update_clang_options.zig/known_options order important? I'll just append to it for now.
mahmudov has quit [Ping timeout: 250 seconds]
<Bekwnn>
eh, might be an issue with c++ vs. C style struct args
<jaredmm>
This is unlikely to be related in any way, but I had issues linking some libraries awhile back on Windows (only Windows) and I couldn't link them when I went with C code either.
<jaredmm>
I never figured it out because I'm a quitter.
mahmudov has joined #zig
<andrewrk>
mikdusan, no
<jaredmm>
Symbols were all defined, same as you saw, linker commands all looked right.
<andrewrk>
I'm going to do another stream in a few minutes
<andrewrk>
same topic
<shakesoda>
Bekwnn: i wonder what's going on with your setup
<shakesoda>
it looks nearly exactly like mine, which works fine on windows and linux
<Bekwnn>
shakesoda: are you sure you didn't take any steps to modify the impl_X.h files?
<shakesoda>
oh, yeah, I extern c'd them
<shakesoda>
totally forgot
<Bekwnn>
and one of the functions has a default arg that causes complaints... I changed that but only tried to extern "c" them via defining IMGUI_IMPL_API
<shakesoda>
i've got a boatload of little changes to my imgui/cimgui files, so i just didn't remember
<shakesoda>
interestingly, the comment about the SDL2 IME handling is either incorrect or missing some kind of detail
<Bekwnn>
I had to do a pretty crazy find and replace on glew.h due to 1085... as far as I'm aware I'm the only person who's gotten that one working
<shakesoda>
solution, avoid glew ;)
<shakesoda>
I fixed the SDL2 IME support myself years ago, unless this runs into some weird case
<Bekwnn>
eh it works perfectly fine now. It just used a ton of function-style macros which didn't actually do anything unless you added defines yourself
<Bekwnn>
so I recorded a search, find, delete macro in vim and did "400 @r" a few times
<shakesoda>
glew is really annoying in a lot of respects, i usually end up with epoxy, glad or just getting the pointers myself
<shakesoda>
although at least it's not as busted with core profile as it once was
<shakesoda>
BaroqueLarouche: nice, i haven't done any audio stuff in zig yet, although i'm going to port my openal (sdl2+mojoal) stuff somewhat soon
<shakesoda>
far less fancy than wwise is
<BaroqueLarouche>
I work for Audiokinetic, this is a demo for a internal dev talk (which can be on any technical subject)
<Bekwnn>
I mostly wanted a new graphics tinkering framework, but also I've been doing optimization stuff at work and have wanted to experiment with a pure data-oriented ECS and profile it a bit
<Bekwnn>
Wound up doing Zig because rust fails to fix the two things I want to get away from in C++ most: compile times (soon™) and complexity
<shakesoda>
that's what I started doing, although at this point I also want to just move the fast bits of my engine/tools to zig
Cogitri has left #zig ["User left"]
<Bekwnn>
I'm mainly a gameplay programmer and I don't think I'm in the right domain of our code base to just modify 'bits' of it
<Bekwnn>
in general our engine is a little bit more monolithic because as a studio we're genre specialists
<Bekwnn>
in terms of not having as much of a gameplay code vs. engine code separation
<shakesoda>
eh, strong separation increases the complexity a vast amount
<pixelherodev>
Hold on, ImGui in Zig?!
return0e_ has quit [Remote host closed the connection]
<BaroqueLarouche>
using the C binding
<BaroqueLarouche>
and building the C++ parts in a static library
<Bekwnn>
>and building the C++ parts in a static library
<Bekwnn>
unless I'm misunderstanding, I don't think shakesoda or I did that
<Bekwnn>
or rather there's no external build step. From a fresh project I should be able to just grab git submodules, copy some modified headers as a one-time step, and then zig build
<Bekwnn>
more or less the same, but with a few warning suppressions and a define
<companion_cube>
Bekwnn: what kind of games do you work on?
<Bekwnn>
AoE 4
<BaroqueLarouche>
neat
<Bekwnn>
or rather the studio does RTS, I'm really just mainly on that project though
<Bekwnn>
so when you think about how much gameplay logic potentially carries over to other RTS projects, yeah there's a slightly weaker separation of engine and game compared to say UE4. Cuz something like having units garrison a structure makes sense as "engine code"
<Bekwnn>
the engine itself is separated into a few parts though, so there is some cleanliness to be had
<Bekwnn>
It's been a really fun project to work on so far
<pixelherodev>
AoE?
<companion_cube>
age of empires
marijnfs_ has joined #zig
<pixelherodev>
Ah
slurpie has joined #zig
marijnfs has quit [Ping timeout: 246 seconds]
<Bekwnn>
with imgui done I guess I get to pick between input handling, object rendering, adding to the math lib, or fleshing out imgui usage more
<Bekwnn>
I'm tempted to reward myself with the math lib one since it's nice, simple, and fun...
<mikdusan>
andrewrk: #4774, my cherry-pick may have been premature. I'm thinking we shouldn't just punt for eg. `-E`; let's say a cross-target is specified then we should use zig logic to setup inc/lib/framework search paths ?
<Bekwnn>
given that it's mostly for personal organization, does it make more sense to have things like "backlog p1" "backlog p2" etc as labels or milestones? (Given I'm already using milestones to set personal goals for v0.1, v0.2, etc
daex has quit [Ping timeout: 250 seconds]
daex has joined #zig
<Bekwnn>
eh, milestone probably makes the most sense since if I move something that's backlogged into a milestone I'd want it to not be a backlog item anymore
Akuli has quit [Quit: Leaving]
daex has quit [Ping timeout: 264 seconds]
daex has joined #zig
<pixelherodev>
Got the IR backend *working*
<pixelherodev>
Need to tweak the calling convention so that its Puts call uses the right ABI
<pixelherodev>
But other than that, it *works*
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
<pixelherodev>
Still only takes ~7 ms in release-fast mode, which means 99% of runtime occurs in the Zig->IR translation - which isn't me going after the compiler, but being glad I don't need to worry about optimizing for a good while :D
return0e has quit [Remote host closed the connection]
frett27_ has quit [Ping timeout: 250 seconds]
ky0ko has joined #zig
daex has quit [Ping timeout: 264 seconds]
daex has joined #zig
<ifreund>
sweet, I finally got all my issues sorted out. My hello world wayland compositor in zig works!
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 256 seconds]
<pmwhite>
What kind of compositor are you aiming for? Tiling?
Bekwnn has quit [Ping timeout: 240 seconds]
<ifreund>
i want dwm
<ifreund>
sway is awesome, but I never liked how i3 does windows