ChanServ changed the topic of #zig to: zig programming language | https://ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
powerofzero has joined #zig
ur5us_ has joined #zig
zags has quit [Ping timeout: 260 seconds]
ifreund has quit [Ping timeout: 265 seconds]
ifreund has joined #zig
<mikdusan> andrewrk: not certain of zig-bootstrap status for master/llvm11 and macos. I'll give that a whirl
<mikdusan> but the wall I'm hitting is indeed with zig-bootstrap master, which is at llvm12
<andrewrk> mikdusan, note that the macos CI does something slightly different than directly using zig-bootstrap. it's kind of doing its own bootstrap process, only using the tarball for zig cc and zig c++
<mikdusan> in azure logs for macos: -- Found llvm:
<mikdusan> /Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMXRay.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMWindowsManifest.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMSymbolize.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMDebugInfoPDB.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gn
<mikdusan> u-0.6.0+1c9ef63a/lib/libLLVMOrcJIT.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMOrcError.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMJITLink.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMObjectYAML.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMMCA.a;/Users/runner/zig+llvm+
<mikdusan> lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMLTO.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMPasses.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMCoroutines.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMObjCARCOpts.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMExten
<mikdusan> sions.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMLineEditor.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMLibDriver.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMInterpreter.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMFuzzMutate.a;/Users/runner/zig+llvm+lld+clang-x86_64-
<mikdusan> macos-gnu-0.6.0+1c9ef63a/lib/libLLVMMCJIT.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMExecutionEngine.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMRuntimeDyld.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMDWARFLinker.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMDlltoolDri
<mikdusan> ver.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMOption.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMDebugInfoGSYM.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMCoverage.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMXCoreDisassembler.a;/Users/runner/zig+llvm+lld+clang-x86_6
<mikdusan> 4-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMXCoreCodeGen.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMXCoreDesc.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMXCoreInfo.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMX86Disassembler.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMX86Co
<mikdusan> deGen.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMX86AsmParser.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMX86Desc.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMX86Info.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMWebAssemblyDisassembler.a;/Users/runner/zig+llvm+lld+clan
<mikdusan> g-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMWebAssemblyCodeGen.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMWebAssemblyDesc.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMWebAssemblyAsmParser.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMWebAssemblyInfo.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0
<mikdusan> .6.0+1c9ef63a/lib/libLLVMSystemZDisassembler.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMSystemZCodeGen.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMSystemZAsmParser.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMSystemZDesc.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMSys
<mikdusan> temZInfo.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMSparcDisassembler.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMSparcCodeGen.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMSparcAsmParser.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMSparcDesc.a;/Users/runner/zig+llvm+ll
<mikdusan> d+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMSparcInfo.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMRISCVDisassembler.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMRISCVCodeGen.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMRISCVAsmParser.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef
<mikdusan> 63a/lib/libLLVMRISCVDesc.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMRISCVUtils.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMRISCVInfo.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMPowerPCDisassembler.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMPowerPCCodeGen.a;/Users/ru
<mikdusan> nner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMPowerPCAsmParser.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMPowerPCDesc.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMPowerPCInfo.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMNVPTXCodeGen.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-g
<mikdusan> nu-0.6.0+1c9ef63a/lib/libLLVMNVPTXDesc.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMNVPTXInfo.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMMSP430Disassembler.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMMSP430CodeGen.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMMSP430AsmP
<mikdusan> arser.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMMSP430Desc.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMMSP430Info.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMMipsDisassembler.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMMipsCodeGen.a;/Users/runner/zig+llvm+lld+clang-
<mikdusan> x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMMipsAsmParser.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMMipsDesc.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMMipsInfo.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMLanaiDisassembler.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLV
<mikdusan> MLanaiCodeGen.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMLanaiAsmParser.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMLanaiDesc.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMLanaiInfo.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMHexagonDisassembler.a;/Users/runner/zig+llv
<mikdusan> m+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMHexagonCodeGen.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMHexagonAsmParser.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMHexagonDesc.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMHexagonInfo.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1
<mikdusan> c9ef63a/lib/libLLVMBPFDisassembler.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMBPFCodeGen.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMBPFAsmParser.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMBPFDesc.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMBPFInfo.a;/Users/runner/z
<mikdusan> ig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMAVRDisassembler.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMAVRCodeGen.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMAVRAsmParser.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMAVRDesc.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9
<mikdusan> ef63a/lib/libLLVMAVRInfo.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMARMDisassembler.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMARMCodeGen.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMARMAsmParser.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMARMDesc.a;/Users/runner/zig
<mikdusan> +llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMARMUtils.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMARMInfo.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMAMDGPUDisassembler.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMAMDGPUCodeGen.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9
<mikdusan> ef63a/lib/libLLVMMIRParser.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMipo.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMInstrumentation.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMVectorize.a;/Users/runner/zig+llvm+lld+clang-x86_64-macos-gnu-0.6.0+1c9ef63a/lib/libLLVMLinker.a;/Users/runner/zig+llvm+lld
mikdusan has quit [Quit: WeeChat 3.0.1]
mikdusan has joined #zig
<mikdusan> so I had to disconnec to stop my irc client from feeding a bad paste.
<mikdusan> sorry y'all
<mikdusan> my understanding is macos ci uses zig-bootstrap also for llvm libs
<andrewrk> mikdusan, I recommend https://clbin.com/
<mikdusan> heh no i was just pasting what I thought was a 1 liner to show llvm is used from tarball. copy from azure web interface of logs was the issue.
<andrewrk> ahh
<andrewrk> the macos ci script *only* uses the tarball for zig cc and zig c++
<andrewrk> wait no I'm wrong, sorry
<andrewrk> yes so to update it for llvm12 we need to put llvm 12 libs in it
<andrewrk> so you tried that, and ran into an issue?
<mikdusan> yes. i did minimal changes to cmake command line to get it building on big sur.
<mikdusan> everything is nice. get the usual hosted llvm (via xcode/clang)
<mikdusan> then get zig with llvm and sytem compiler fine
<mikdusan> but rebuild llvm with `zig c++` is the stop.
<mikdusan> end up in 2 situations: 1 is some reduced size executables that are not functional.
<mikdusan> or 2. using ZIG_SYSTEM_LINKER_HACK=1 it stops because system ld is not so dumb and gives an error.
<mikdusan> i am fairly certain it's because... when we do "-target x86_64-macos" our cross-compile logic kicks in. and all the use of SDK search paths is gone, and -lSystem is no longer present. cmake detection probes make bad decisions because of this. etc.
gazler has joined #zig
<mikdusan> (all this within the caveat: I am on Big Sur).
<andrewrk> hmm with llvm11 we do not use the system linker hack right? so let's try to keep it that way
<mikdusan> correct: we don't use the hack anywhere in zig-bootstrap
gazler_ has quit [Ping timeout: 260 seconds]
<oats> andrewrk, congrats on your run, that's a hell of an achievemnt! makes me want to take back up running...
<andrewrk> thanks
<mikdusan> andrewrk: ok I think it's worth while I try zig-bootstrap on an older macos. I have a 10.13 clunker. this let's me avoid 11.0 (big sur) factor.
ifreund has quit [Ping timeout: 260 seconds]
<andrewrk> I think the llvm 12 release is going to be rough for zig unfortunately
brzg has joined #zig
<andrewrk> they already moved one of our bug tickets to 12.0.1
<mikdusan> and odd that... it was a statement like "because there is no fix" . wth
<g-w1> all the more incentive to get the self-hosted backend working :)
<mikdusan> doit!
brzg has quit [Quit: leaving]
craigo has joined #zig
blackpawn has quit [Ping timeout: 264 seconds]
sebonirc has quit [Quit: sebonirc]
<g-w1> is there a way to get the minimum int type that a comptime_int can fit into?
<ugla> log2-of-the-value number of bits?
<g-w1> nice :) thanks
<mikdusan> math.Log2Int() ?
<mikdusan> oh that needs a type
<mikdusan> math.IntFittingRange
notzmv has quit [Ping timeout: 265 seconds]
xackus_ has joined #zig
xackus has quit [Ping timeout: 245 seconds]
LanceThePants has joined #zig
craigo_ has joined #zig
lunamn6 has joined #zig
hspak4 has joined #zig
st4ll11 has joined #zig
osa1_ has joined #zig
Wolf481pl has joined #zig
idxu_ has joined #zig
Techcable_ has joined #zig
tomku|two has joined #zig
doublej472 has joined #zig
Snetry- has joined #zig
^_ has joined #zig
kragacles_ has joined #zig
Ekho has quit [Disconnected by services]
powerofzero has quit [*.net *.split]
Techcable has quit [*.net *.split]
mjanssen has quit [*.net *.split]
Wolf480pl has quit [*.net *.split]
Snetry has quit [*.net *.split]
kragacles has quit [*.net *.split]
lunamn has quit [*.net *.split]
tomku has quit [*.net *.split]
so has quit [*.net *.split]
V has quit [*.net *.split]
voldial has quit [*.net *.split]
craigo has quit [*.net *.split]
dongcarl has quit [*.net *.split]
hspak has quit [*.net *.split]
sawzall has quit [*.net *.split]
osa1 has quit [*.net *.split]
SimonNa has quit [*.net *.split]
st4ll1 has quit [*.net *.split]
Tharro has quit [*.net *.split]
idxu has quit [*.net *.split]
bkleiner has quit [*.net *.split]
doublej41 has quit [*.net *.split]
kragacles_ is now known as kragacles
lunamn6 is now known as lunamn
hspak4 is now known as hspak
idxu_ is now known as idxu
SimonNa has joined #zig
Tharro has joined #zig
Ekho has joined #zig
so has joined #zig
<g-w1> oh I actually need it to be able to detect 0x0000000000000000 as having 8 bytes. is this possible?
<daurnimator> g-w1: no
<daurnimator> g-w1: you have to tell zig how many bytes an integer should take
<daurnimator> s/bytes/bits/
<g-w1> makes sense
<g-w1> now I need another @as
ur5us_ has quit [Ping timeout: 264 seconds]
gpanders has quit [Remote host closed the connection]
gpanders has joined #zig
earnestly has quit [Ping timeout: 264 seconds]
craigo__ has joined #zig
craigo_ has quit [Ping timeout: 260 seconds]
ksynwa has joined #zig
<ksynwa> I am a noob so I had a couple of questions. 1) What exactly is systems programming? Feel free to be brief about this. 2) Is Zig mostly a systems programming language?
<andrewrk> ksynwa, people mean different things when they say it, but in general it means that the Application Program Interfaces you are interacting with are Operating System APIs, or sometimes even that you are writing Operating System code yourself
<mipri> the wikipedia entry on it isn't bad, for wikipedia. There's a target platform and all of it's available for use, as opposed constraining yourself to a VM.
<andrewrk> Zig is a general-purpose programming language, which means it can be used for any kind of programming, including systems programming, but also anything else
<ksynwa> Nice. Okay. Thanks.
<ksynwa> Much appreciated.
<andrewrk> in fact, one of zig's strengths is that the restrictions it puts on zig programmers means that zig code can be used in many places - more places than most other programming languages
<ksynwa> Yeah I was reading its comparison with rust and seems like a nice compromise. Thanks for taking the time to explain.
<mipri> consider swapping two files. In almost any language, Perl, Python, bash, you'd do this with two rename() calls (downside: the one file is momentarily not present where it should be, and this could be spotted and cause a fault), or with a copy and two renames (downside: unnecessary I/O and disk usage).
<daurnimator> ksynwa: "true" (I say that in danger of a no-true-scotsman argument) systems programming often has requirements such as "no runtime"/"no garbage collection"/"no arbitrary heap allocation" many languages are hence no suitable for systems programming
notzmv has joined #zig
<mipri> Linux actually has a renameat() syscall that you can use to swap two files in one operation, without either downside, but because it's new and not everywhere, you generally can't use it. In a systems programming language it's what I'd expect to use.
<andrewrk> mipri, we have a nice way to model that - you can do a comptime check for the target OS version range
<andrewrk> if the minimum OS version range is >= the version that introduced it, you can unconditionally rely on it
<andrewrk> oops, I meant to say, "if the target OS version range minimum is >="
<daurnimator> andrewrk: did we ever get the graceful fallback for comptime-known vs runtime-known working on that?
<andrewrk> for renameat? I don't remember
<daurnimator> andrewrk: I meant for the version check helper
<andrewrk> I vaguely remember seeing a clean version check helper
<andrewrk> if the target OS version range maximum is < the version that introduced renameat then you can unconditionally do the code that does not use it
<andrewrk> and finally if the target OS version range spans the version that introduced it, you can do the version check at runtime, and choose which code path is appropriate
<andrewrk> and this can be expressed quite simply and cleanly with zig
<daurnimator> i.e. some feature was introduced in 3.15. scenario A: you compile for 4.0-5.10: we know at comptime that it will be available and have no fallback. scenario B: you compile for 3.14-5.10: you need to branch at runtime and include both versions in the code.
<andrewrk> don't forget scenario C
notzmv has quit [Ping timeout: 245 seconds]
knebulae has quit [Read error: Connection reset by peer]
<daurnimator> or D
<andrewrk> what's D?
<andrewrk> C is you compile for 4.0-3.14
<andrewrk> oops I mean 3.0-3.14
<daurnimator> D is that the feature got backported to the 3.14 kernel and we should have just tried it and only fallback on ENOSYS
<andrewrk> that would be the same code as scenario B
<andrewrk> unless scenario B wants to avoid the ENOSYS entirely?
<daurnimator> I thought in scenario B its a switch on e.g. whatever is returned by `uname`
<andrewrk> I see, yes I can see where that would be desirable too in some cases
<mipri> nice, std.os.sendfile has an example of glibc version checking
<daurnimator> looks like our helper just returns `null`. so the choice of "try anyway" vs "use uname" is up to the caller: https://github.com/ziglang/zig/blob/d3565ed6b48c9c66128f181e7b90b5348504cb3f/lib/std/builtin.zig#L478
halbeno has quit [Quit: Leaving.]
halbeno has joined #zig
nvmd has quit [Ping timeout: 245 seconds]
atkh has quit [Quit: Ping timeout (120 seconds)]
sord937 has joined #zig
nvmd has joined #zig
dyeplexer has joined #zig
protheory8-new-m has joined #zig
<protheory8-new-m> Hi, will Zig compiler support Reference Types, Module Linking, Interface Types, Threads and Atomics proposals once they will get merged into the WebAssembly specification?
<protheory8-new-m> Or does it depend on LLVM?
craigo__ has quit [Ping timeout: 246 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
<andrewrk> yes, zig will support these. there is a self-hosted backend in progress that is independent of LLVM
<andrewrk> it may take some time however. I don't have an estimate on when such features will be available
tnorth_ has joined #zig
tnorth_ is now known as tnorth
craigo__ has joined #zig
tomku|two has quit [Ping timeout: 256 seconds]
tomku has joined #zig
ifreund has joined #zig
proteusguy has quit [Ping timeout: 272 seconds]
proteusguy has joined #zig
ur5us_ has joined #zig
bitmapper has quit [Quit: Connection closed for inactivity]
<protheory8-new-m> So Zig is going to be one of the best languages for WebAssembly? It doesn't have a GC.
<ksynwa> Do you prefer to use zls (languager server) from the github releases or build it from master?
<protheory8-new-m> * So is Zig going to be one of the best languages for WebAssembly? It doesn't have a GC.
<daurnimator> ksynwa: generally I build from master. But I believe there is currently an incompatibility
<ikskuh> protheory8-new-m: no, not "going to be". just *is*
<daurnimator> protheory8-new-m: we hope so?
<protheory8-new-m> <ikskuh "protheory8-new: no, not "going t"> I don't see any libs for doing that, so I wouldn't say that
<protheory8-new-m> * I don't see a lot of libs tbh, so I wouldn't say that
<ikskuh> protheory8-new-m: I've seen people doing immediate html rendering in zig already
<ikskuh> i'm using it for myself
<ikskuh> most zig libraries that don't talk to native are just wasm compatible
<protheory8-new-m> Maybe someone will make a JavaScript to WebAssembly compiler and it will automatically become the best language for Wasm lol
<protheory8-new-m> <ikskuh "protheory8-new: I've seen people"> where
<ikskuh> here and there *grin* let me look into my github stars
<ikskuh> this is by me, using a compiler written in zig in wasm
<ikskuh> which was pretty much zero-effort
<protheory8-new-m> > compiler written in Zig in Wasm
<protheory8-new-m> What do you mean?
<ikskuh> i've written a compiler in zig
<ikskuh> (lola is my programming language)
<ikskuh> and i've made the wasm playground afterwards, took me one or two hours
<ikskuh> https://ashet.computer/livedemo.htm another demo by me, running a 16 bit computer emulation
<protheory8-new-m> But where is html rendering?
<ikskuh> yeah, i'm searching
<ikskuh> not sure if it still builds, but it's a nice demo with DOM modification and webgl combined
<protheory8-new-m> Or maybe we can have Java bytecode embedded into Wasm file as data, hard code Java VM to execute that bytecode and then compile it into WebAssembly
<protheory8-new-m> So we get Java VM compiled to WebAssembly, which executes hard coded into Wasm file Java bytecode
<ikskuh> protheory8-new-m: you won't see much good wasm dom rendering libraries though, until wasm-in-the-browser gets a well defined API for it
<protheory8-new-m> Truly write once run anywhere
<protheory8-new-m> <ikskuh "protheory8-new: you won't see mu"> But it already exists, you interact with DOM through JS
<ikskuh> yeah, but everyone does differently
<ikskuh> which means there is no portability for wasm apps
m4r35n357 has quit [Ping timeout: 264 seconds]
m4r35n357 has joined #zig
zups has joined #zig
TheLemonMan has joined #zig
wilsonk_ has quit [Ping timeout: 245 seconds]
earnestly has joined #zig
<protheory8-new-m> <ikskuh "yeah, but everyone does differen"> What do you mean?
cole-h has quit [Ping timeout: 260 seconds]
<shachaf> protheory8-new-m: You should probably not use Matrix features like replying to messages and editing messages on IRC. They translate very badly.
leah2 has quit [Remote host closed the connection]
<protheory8-new-m> Yeah, I figured
leah2 has joined #zig
ur5us_ has quit [Ping timeout: 264 seconds]
xackus_ has quit [Read error: Connection reset by peer]
xackus__ has joined #zig
<ikskuh> protheory8-new-m: everyone uses a different API to access DOM from WASM
tane has joined #zig
<tane> howdy
<TheLemonMan> hiya
<ikskuh> heya
<daurnimator> hoya?
<TheLemonMan> don't let the chain die
<daurnimator> TheLemonMan: I hear you can fix all the LLVM issues now? :)
<TheLemonMan> I wish we didn't discover all those regressions a week before the release is cut heh
<daurnimator> Not as if we develop against LLVM master..... I'd be surprised if we're not the only project even trying their release candidates
<TheLemonMan> rust moved to 12 a few days ago
<TheLemonMan> but they vendor their llvm copy so any interesting patch can be cherry-picked
isolier has quit [Quit: Ping timeout (120 seconds)]
isolier has joined #zig
nycex has joined #zig
nycex- has quit [Quit: Quit]
knebulae has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
notzmv has joined #zig
zups has quit []
^_ is now known as V
osa1_ is now known as osa1
<skuzzymiglet> are there any Qt bindings for Zig you know of?
<skuzzymiglet> or C for that matter :)
<ikskuh> nope, i don't think so?
<ifreund> skuzzymiglet: I saw this but haven't looked closely: https://github.com/kassane/qml_zig
<skuzzymiglet> looks alright
<skuzzymiglet> not sure why it's QML bindings not Qt
<skuzzymiglet> not sure of the difference
<ikskuh> Qt is a huge framework with thousands of classes
<ikskuh> binding it to C is nearly impossible due to a huge load of inheritance and polymorphism
<skuzzymiglet> I'm just thinking of messing with some webviews and qtwebengine is the most modern
<ikskuh> ah
<ikskuh> you could use a combined zig/qt build thing though
<ikskuh> make a library with qt that just exports the api surface you need :)
<skuzzymiglet> in C++?
<ifreund> yeah, but export a C API
<ifreund> and you can build/link C++ doing that with zig code no problem using the zig toolchain :)
<skuzzymiglet> thanks, I'll try that when I find some time :)
<ikskuh> yeah, i'd do it in C++
<ikskuh> qt is not made for other languages than C++ :D
<skuzzymiglet> indeed
<skuzzymiglet> it takes lots of work to bind and the end result sucks in every language
<ikskuh> yeah
<ikskuh> same will be true for an idiomatic zig UI though
<ikskuh> (or any UI basically)
ubert1 has joined #zig
osa1_ has joined #zig
osa1 has quit [Ping timeout: 264 seconds]
TheLemonMan has joined #zig
osa1_ is now known as osa1
teratorn has quit [Ping timeout: 240 seconds]
<Raito_Bezarius> I'm trying to reinterpret a @embedFile array into a packed structure, but for some reason, the resulting structure data looks wrong
<Raito_Bezarius> This looks like this: https://clbin.com/cmjw2
<TheLemonMan> nested packed structures are often wrong
<Raito_Bezarius> the header looks good though
<Raito_Bezarius> the data is wrong
<Raito_Bezarius> so you suggest I should inline it?
<TheLemonMan> yeah
<Raito_Bezarius> Alright, thanks for the pointer!
<ifreund> Raito_Bezarius: I don't think you're hitting any packed struct bug there, what you're trying to do is invalid though
<ifreund> you can only @ptrCast() for the header, you need to set the data pointer manually
<Raito_Bezarius> ifreund: Could you explain me what is invalid? I'm having some difficulties to grasp yet what @ptrCast does exactly
<Raito_Bezarius> ha
<Raito_Bezarius> hm
<Raito_Bezarius> why ?
<ifreund> @ptrCast() allows you to tell the compiler to reinterpert memory as some other type
<ifreund> which is fine for the header of u32s
<ifreund> it is not fine to reinterpert the first bytes of data as a memory address where the data is stored though
<ifreund> it won't be the right address
<Raito_Bezarius> Right, I see now
<Raito_Bezarius> Okay, I see why this is wrong
<TheLemonMan> that ptrToInt + intToPtr combo looks pretty wild
<DarkUranium> skuzzymiglet, why not GTK?
<DarkUranium> Or, for simple UI, libui
<Raito_Bezarius> TheLemonMan: is there something more idiomatic?
<Raito_Bezarius> I really do use ptrToInt + intToPtr more than often that I would in an attempt to mimic C
<TheLemonMan> @ptrCast(*u32, dest + line) ?
<Raito_Bezarius> Aha
<Raito_Bezarius> Thanks
<TheLemonMan> wait, why is dest *[*]u8 ?
<Raito_Bezarius> pointer on an array of pixels?
<Raito_Bezarius> like char** dest?
<Raito_Bezarius> I could only use char* dest I guess
<Raito_Bezarius> can I discard a const during casts?
<TheLemonMan> not if you still want your kneecaps
<Raito_Bezarius> alright, I want them
<TheLemonMan> if you _really_ need that use ptrToInt and intToPtr
<Raito_Bezarius> but like if I do inline the packed struct, @embedFile give me a *const [*]u8
<TheLemonMan> but that's bad, really bad
<Raito_Bezarius> and then if I reinterpret the header in the inlined struct
<Raito_Bezarius> I still need to set the data ptr
<Raito_Bezarius> but when ptrCasting, I still get the const qualifier
<Raito_Bezarius> so I cannot mutate the data ptr (?)
<ifreund> the data you get from @embedFile() is const
<ifreund> you can may a copy if you want o mutate it
<Raito_Bezarius> That makes sense
<TheLemonMan> I'm not following because I'm shit at multitasking, but embedded data cannot be mutated
<ifreund> var mutable_data = @embedFile("foo").*;
<TheLemonMan> but why are you mutating the font data in first place?
<Raito_Bezarius> I don't want to mutate
<ifreund> ^^^
<Raito_Bezarius> https://clbin.com/gy1yl
<Raito_Bezarius> as per ifreund remark, I cannot reinterpret the data
<Raito_Bezarius> so I can just set font.data to be buffer + font.headerSize
<Raito_Bezarius> or am I doing something stupid?
<TheLemonMan> data = buffer + @sizeOf(Header)
<TheLemonMan> that's it
<TheLemonMan> right now you're stomping over the first 4/8 bytes of font data to set-up your pointer
<Raito_Bezarius> hm right
<TheLemonMan> I guess you're trying to emulate a tail field with `char []` type
<TheLemonMan> in C
<Raito_Bezarius> correct
<TheLemonMan> yeah that's not the correct translation
<Raito_Bezarius> I don't want to make you spend more time on noob question, do you have any pointers on where to look to learn about it in Zig land?
<TheLemonMan> I think you can do something like `fn data(self: *Font) [*]u8 { return @ptrCast(u8, self) + @sizeOf(Header); }`
<ifreund> @ptrCast([*]u8, ...
<TheLemonMan> or simply pass a pointer for your data and one for the header
<TheLemonMan> ifreund, told you I'm shit at multitasking heh
<Raito_Bezarius> yeah but I understood the intent :p
<TheLemonMan> ifreund, I've updated #8178, we may need more than two sets of stubs :(
<TheLemonMan> or give everything the middle finger and merge all the symbols into a single one
<ifreund> hrm, that's no fun
<Raito_Bezarius> nice, I think I got it, thank you ifreund & TheLemonMan !
nvmd has quit [Quit: Later nerds.]
<TheLemonMan> Raito_Bezarius, nice, if you have any more problems please ask away
<TheLemonMan> we're a friendly bunch
<Raito_Bezarius> That's really awesome, thank you for your help :)
<ifreund> TheLemonMan: maybe we should just be building musl's libc.so from source for the target when dynamically linking instead of using stubs. We already can build libc.a
<TheLemonMan> that's an idea, we could also try passing --allow-shlib-undefined and forget about it
<TheLemonMan> after all we need the stub thing for glibc only because of the symbol versioning story
<TheLemonMan> but musl doesn't give a damn
<ifreund> hmm, though doesn't that mean people won't get errors if they use something that's actually not defined by libc?
<ifreund> sounds like a kinda crappy user experience
<TheLemonMan> that's the only downside
<TheLemonMan> well right now it's erroring because people are using symbols that do exist :P they even out
nvmd has joined #zig
<ifreund> :D
<ifreund> TheLemonMan: by the way, do you have an idea of a good way to fix this? https://github.com/ziglang/zig/issues/8144
<TheLemonMan> you can't do much :\ the system .so files are linked against a newer symbol
<ifreund> should zig default to using the system libc then?
<TheLemonMan> if you're not cross-compiling that's ok
<TheLemonMan> today I learned about go's &^ operator and now I want it in Zig too
<ifreund> isn't that just a & ~b ?
<ifreund> or do I not fully understand what that operator does?
<TheLemonMan> yeah
<TheLemonMan> I think it's useful when b is a comptime_int constant
<TheLemonMan> you can avoid the casting madness before applying the not
xenon has joined #zig
Wolf481pl is now known as Wolf480pl
Flaminator has quit [Remote host closed the connection]
Flaminator has joined #zig
notzmv has quit [Ping timeout: 276 seconds]
notzmv has joined #zig
craigo__ has quit [Quit: Leaving]
craigo has joined #zig
dongcarl has joined #zig
notzmv has quit [Ping timeout: 272 seconds]
tnorth has quit [Ping timeout: 240 seconds]
ksynwa has quit [Quit: oh no they're here]
ksynwa has joined #zig
txdv has joined #zig
<txdv> Are there any plans for a http library?
<ifreund> http library: https://github.com/truemedian/hzzp
<ifreund> there will at least a client library in the std eventaully though for the package manager
<txdv> Any ETA on when the package manager is going to drop?
Techcable_ is now known as Techcable
<TheLemonMan> tomorrow
<ifreund> after the stage2 compiler compiles itself
<marler8997> Fellow language connoisseurs, I want to get people's opinion on whether my stitch scripting language should add special syntax for variable assignment "foo = bar" of if I should use a builtin like "@set foo bar". Feel free to share your thoughts with me on the #stitch channel
<TheLemonMan> it depends on whether you want people to use it or not
<marler8997> TheLemonMan, definite yes to that
<TheLemonMan> then I'd ditch the second option
<marler8997> follow up question, how would you want to differentiate between setting a script variable vs an environment variable?
<TheLemonMan> with a leading $ for env vars
<TheLemonMan> unless you want $igil$
<marler8997> script variables use leading $
<marler8997> env.FOO = bar?
<marler8997> access with $env.FOO
<TheLemonMan> a bit verbose but works (do env variables allow spaces in their names?)
<marler8997> TheLemonMan, good question
<marler8997> do OS's let you do that?
<ifreund> indeed
<ifreund> man environ
<marler8997> doesn't look like it: 'FOO BAR=what' env
Akuli has joined #zig
<ifreund> well, it's well specificed, but you can certainly put FOO=foo bar in your environ
<marler8997> well, that's just BASH
<ifreund> *not well specified
<marler8997> right, but in the varname
<ifreund> it's just and array of null terminated strings
<ifreund> musl's getenv() seems to allow it
<marler8997> looks like it works
<marler8997> this python program: import os;import subprocess;os.environ["foo bar"] = "hey";subprocess.call(["env"])
<marler8997> I'm also fine with using a builtin commands for managing environment variables: @setenv "foo bar" "hey" (@env "foo bar")
<ifreund> we sould maybe move this to #stitch
<marler8997> yeah, would love to get people's feedback, let me know on #stitch
dingenskirchen has quit [Ping timeout: 260 seconds]
dyeplexer has quit [Remote host closed the connection]
leibniz[m] has joined #zig
dingenskirchen has joined #zig
txdv has quit [Quit: Connection closed]
bitmapper has joined #zig
notzmv has joined #zig
mmohammadi9812 has joined #zig
txdv has joined #zig
craigo has quit [Ping timeout: 245 seconds]
waleee-cl has joined #zig
xenon has quit [Quit: Konversation terminated!]
ifreund has quit [Quit: WeeChat 3.0.1]
ifreund has joined #zig
sord937 has quit [Quit: sord937]
wilsonk has joined #zig
<andrewrk> ifreund, I haven't had a chance to look into 8144 yet but based on the error you pasted it looks like the stubs incorrectly link against 2.33 instead of 2.32 as they were supposed to
<TheLemonMan> it's the system library that's linked against a newer version
<andrewrk> oh I see
<TheLemonMan> ah, the MIPS issue mentioned on reddit is tracked in #8183 and #8178
txdv has quit [Ping timeout: 240 seconds]
<ifreund> andrewrk: one way to solve this would be a way to force usage of the system libc. This is probably the right default when linking system libraries tbh
<andrewrk> yeah I can see that
<ifreund> you can already do this by passing the output of `zig libc` to the --libc option but it's not very convinient in build.zig yet
<andrewrk> I think if zig was in charge of building everything, it would be desirable to leave things as status quo
<ifreund> indeed
<andrewrk> but if we're trying to mix with system libraries, then it makes sense to link against system libc
<ifreund> the status quo is necessary for zig's cross compilation capabilities, which are only possible if not linking system libraries
<andrewrk> we have this problem even more severely with building c++ code
<andrewrk> zig can build c++ code but shit hits the fan quickly if you try to link against c++ code from other compilers
<andrewrk> and there's nothing we can do about that
<ifreund> sounds about right :/
<ifreund> maybe zig could invoke the system C++ compiler though
<ifreund> (if linking system C++ libraries)
<andrewrk> ugh
<andrewrk> we were so close to eliminating an entire scope of problems
<ifreund> just gotta get everyone to vendor their C code and stop linking system libs
<ifreund> distros will hate us
<andrewrk> wow that actually sounds great to me
<andrewrk> I hadn't even considered that
<andrewrk> but yeah I can already feel the heat from distro maintainers rage
<bbuccianti> andrewrk: I just wanted to say that I'm seeing your vimeo videos about game development with SDL2 and it's such a nice experience! thanks a lot for those!
zags has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<earnestly> andrewrk: Do you think they have legitimate concerns?
cole-h has joined #zig
ur5us_ has joined #zig
<vent> mus
carldd has joined #zig
mmohammadi9812 has quit [Remote host closed the connection]
mmohammadi9812 has joined #zig
SimonN has joined #zig
SimonNa has quit [Ping timeout: 260 seconds]
<carldd> Hi, does Zig have VLA (Variable Length Arrays) or something similar to the C99 function `alloca`?
<mikdusan> andrewrk: maybe we should think about an abi-designator in the triple that _means_ use the system abi
Snetry- has quit [Quit: left Freenode]
Snetry has joined #zig
Akuli has quit [Quit: Leaving]
mmohammadi9812 has quit [Ping timeout: 276 seconds]
mmohammadi9812 has joined #zig
earnestly has quit [Ping timeout: 260 seconds]
sebonirc has joined #zig
earnestly has joined #zig
tane has quit [Quit: Leaving]
<ikskuh> carldd: no, that feature is considered unsafe and is not supported in zig.
<ikskuh> use a "big enough" array if you know the uppper bound
<ikskuh> or do a heap allocation if you don't
<carldd> ikskuh: Ok, thanks. I'll have to do something like that
<andrewrk> earnestly, yes they do
<earnestly> I don't think they're going to survive against developers; in many ecosystems that role as guardian between potentially malicious developers and users is already abandoned
* earnestly .oO(I wonder what "so hell" will be called in the future)
<zags> Is there a nice way to dynamically add indentation in string formatting? I can do N prints of spaces, but lemme know if I'm missing a formatting trick or a repeat-this-char thingie. Note that the amount of indentation comes from a variable.
<ikskuh> isn't there a indenting writer somewhere?
sebonirc has quit [Quit: sebonirc]
zags has quit [Ping timeout: 276 seconds]