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/
cren has quit [Quit: cren]
<daurnimator> andrewrk: how do we make sure the functions in compiler-rt don't get optimized into function calls into compiler-rt?
g_w1 has joined #zig
<andrewrk> there is a backend-specific answer to that question
<andrewrk> for llvm it's nobuiltin. for our own backend we can take whatever strategy we want
<daurnimator> andrewrk: further context, considering #7265, on some targets I imagine e.g. sincos would be a call to hardware for sin and cos. while on others sin and cos might be a call to sincos which is backed by a hardware instruction itself.
<daurnimator> or is that assumption just totally incorrect?
<daurnimator> andrewrk: so we can build the entire compiler-rt object with nobuiltin? or do we need our own function attribute `nobuiltin(true)`?
<g-w1> iirc, at least on x86_64, the libc versions of trig functions are actually faster than the hardware ones for some reason
<andrewrk> tbh I don't think we need to do anything until the problem actually manifests. I'm not worried about being able to solve it if it starts happening
<andrewrk> currently we have a flag in the compiler implementation that is set to true when we are building compiler-rt symbols
st4ll1 has quit [Remote host closed the connection]
st4ll1 has joined #zig
<daurnimator> I'm sort of afraid of it coming up only on certain optimization levels with certain cpu feature sets.
<andrewrk> fengb, what's the wasm equivalent command of `readelf -s` but for a wasm object?
<daurnimator> there's a wasm-objdump
<ifreund> wasm2wat can also be useful
<andrewrk> daurnimator, if you copy the memcpy source code from zig's compiler-rt into a separate file and rename the function and run optimizations, it will optimize into a call to memcpy. but within compiler-rt the function's body is preserved
<andrewrk> looks like llvm pays attention to the symbol name
<andrewrk> try renaming "mystery" to "memcpy" https://godbolt.org/z/zbM9x3
<daurnimator> thats far too magical for my liking >.<
<andrewrk> side note, I wonder why this isn't just jmp memcpy
<daurnimator> looks like its trying to avoid calling with length 0?
<andrewrk> memcpy allows passing 0 tho
<daurnimator> *shrug* maybe there have been historically broken implementations?
<andrewrk> heh, the equivalent C code actually does not get optimized into memcpy: https://godbolt.org/z/hdd6js
<daurnimator> andrewrk: I'm struggling to get a zig version that optimizes to `__memcpy4`
a92 has joined #zig
xackus__ has joined #zig
earnestly has quit [Ping timeout: 240 seconds]
xackus_ has quit [Read error: Connection reset by peer]
<andrewrk> huh. LLD lets you pass a shared object as a positional argument for x86_64 but not for aarch64
a92 has quit [Quit: My presence will now cease]
<ky0ko> is there some trick to getting zig to use frameworks with C headers on macOS? linkSystemLibrary/linkFramework in my build.zig seem to be doing nothing to get it to find the C headers
<ky0ko> i'm just trying to get something to work with SDL2
ur5us has quit [Ping timeout: 260 seconds]
<andrewrk> you gotta add the framework directory manually
<andrewrk> (as a workaround for now. that's not the intended user experience)
xackus has joined #zig
xackus__ has quit [Ping timeout: 260 seconds]
<ky0ko> what do you mean by this? `exe.addFrameworkDir("/Library/Frameworks");` sort of deal?
<andrewrk> yes
<andrewrk> maybe also the include path
<ky0ko> i am doing so, include path as well, to no effect
<ky0ko> with --verbose i can confirm that the compiler is being passed the -I option with the correct path
<ky0ko> the file exists
<ky0ko> but Zig claims not to find it
<ky0ko> scratch that, it probably helps to spell words correctly
ur5us has joined #zig
<andrewrk> ky0ko, oh, your issue is one of the ones in the 0.7.1 milestone: https://github.com/ziglang/zig/issues/6996
<andrewrk> it's a recent regression
<andrewrk> the 0.7.1 milestone issues are my top priority this week
<ky0ko1> no, that appears to be different than what i am experiencing
<ky0ko1> actually currently i have it finding the framework, i just have an unexplained crash happening
<andrewrk> ah
<ky0ko> i also had some issues getting the arm version working (i have an arm mac) but for now i'm just using the x86_64 version
<ky0ko> i assume that's just not ready yet
<andrewrk> kubkon has some work-in-progress code that makes everything Just Work on aarch64-macos but it's not in master branch yet
<ky0ko> okay. i'll just stick to the x86_64 binaries for now and move to that when it's ready
ur5us has quit [Ping timeout: 256 seconds]
a_chou has joined #zig
a_chou has quit [Remote host closed the connection]
waleee-cl has quit [Quit: Connection closed for inactivity]
xackus_ has joined #zig
xackus has quit [Ping timeout: 260 seconds]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
sord937 has joined #zig
sord937 has quit [Remote host closed the connection]
sord937 has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
halbeno has quit [Quit: Leaving.]
lucid_0x80 has joined #zig
halbeno has joined #zig
ur5us has joined #zig
jukan_ has joined #zig
ur5us has quit [Ping timeout: 240 seconds]
jukan_ has quit [Ping timeout: 272 seconds]
jukan has joined #zig
dddddd has quit [Ping timeout: 246 seconds]
ur5us has joined #zig
mshb has joined #zig
jukan has quit [Ping timeout: 265 seconds]
cole-h has quit [Ping timeout: 256 seconds]
gpanders has quit [Ping timeout: 260 seconds]
gpanders has joined #zig
cole-h has joined #zig
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
cole-h has quit [Ping timeout: 256 seconds]
ur5us has quit [Ping timeout: 264 seconds]
earnestly has joined #zig
<ikskuh> something broke with asnyc code: https://github.com/MasterQ32/zig-network/runs/1478112195
<ikskuh> can someone check out what this means?
<ikskuh> /opt/hostedtoolcache/zig/zig-linux-x86_64-0.7.0+51d7c14ce/x64/lib/zig/std/debug.zig:1752:1: error: function with calling convention 'C' cannot be async
<ikskuh> handleSegfaultLinux crashes
<ikskuh> is this known?
<ifreund> ikskuh: ah, that's due to lemonboy's recent fix for a deadlock there
<ifreund> needs a nosuspend I think
<ikskuh> ah, so we need a fix for the fix :D
jmiven has quit [Quit: reboot]
jmiven has joined #zig
hlolli_ has joined #zig
lucid_0x80 is now known as suskub
suskub is now known as suskun
cren has joined #zig
gpanders has quit [Ping timeout: 264 seconds]
gpanders has joined #zig
gpanders has quit [Ping timeout: 256 seconds]
gpanders has joined #zig
jukan has joined #zig
wootehfoot has joined #zig
jukan has quit [Ping timeout: 256 seconds]
sord937 has quit [Ping timeout: 240 seconds]
sord937 has joined #zig
marnix has quit [Ping timeout: 240 seconds]
marnix has joined #zig
sord937 has quit [Remote host closed the connection]
sord937 has joined #zig
ifreund1 has joined #zig
ifreund2 has joined #zig
ifreund has quit [Disconnected by services]
ifreund2 is now known as ifreund
ifreund1 has quit [Disconnected by services]
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
dddddd has joined #zig
Miaourt has quit [Quit: Ping timeout (120 seconds)]
Miaourt has joined #zig
dumenci has joined #zig
suskun has quit [Ping timeout: 240 seconds]
<cren> if I make an allocation like this: `const memory = try allocator.alloc(u8, 20);`, have I just done something totally pointless? I can read the allocated memory but it consists of random(ish) values, and I can't write it
<novaskell> You should be able to write as you get slice of `[]u8` back as the slice bound is immutable but the memory it points to isn't
<novaskell> cren: https://0x0.st/i7jB.zig
<cren> ah yes of course slices are pointers. I cannot seem to get that one into my head
<cren> hmmm interestingly I can assign a single character to an element in that array but I can't assign a string of length 1
<ikskuh> > wine client error:10c: read: Invalid Address
<ikskuh> \o/ my code kills wine!
<g-w1> cren: to assign a string, you want to use mem.copy
<cren> I was just making the mistake of using double quotes for characters because I come from Python where characters are just strings of length 1
waleee-cl has joined #zig
<cren> using `allocator.create()`, what is returned is a pointer to a single entity. (object?) If I dereference the pointer and declare a const variable to store the result, I then can't mutate the value, right? Unless I dereference again and create a var
<ifreund> if you dereference the pointer returned by create and store the result you are making a copy
<ifreund> you probably just want to store the pointer
jukan has joined #zig
jukan has quit [Client Quit]
hnOsmium0001 has joined #zig
marnix has quit [Ping timeout: 260 seconds]
_whitelogger has joined #zig
xackus_ has quit [Ping timeout: 264 seconds]
marnix has joined #zig
dumenci has quit [Ping timeout: 260 seconds]
lucid_0x80 has joined #zig
FireFox317 has joined #zig
<ikskuh> C:\\windows\\system32\\pkg-config.COM
<ikskuh> what is that?
<ikskuh> i think i made zig explode :D
<FireFox317> andrewrk, any opinions on #7271? Should i go for LemonBoys suggestion?
<FireFox317> Defintely a bug that should be solved before 0.7.1 tho
Akuli has joined #zig
<andrewrk> FireFox317, I don't understand LemonBoy's comment - your change looks correct to me
<FireFox317> andrewrk, Well we are just changing the --name paramater, which means we change the output name of the binary. This in theory does not have to rebuild the complete binary, just to change the name
<andrewrk> ok I think I understand the comment but I still prefer your change
<FireFox317> Sure :thumbsup:
<andrewrk> hmm I think I originally planned @import("builtin") to expose that name but looks like that never happened
<andrewrk> anyway I'd like to merge this
<andrewrk> sorry for breaking the CI yesterday :-/
<andrewrk> incoming fix
Snetry has quit [Quit: left Freenode]
<FireFox317> andrewrk, i dont see why the issue/pr have something to do with @import("builtin"). Am I missing something?
<FireFox317> Lets say @import("builtin") reflects the name, then it still should be cached right, or is everything in @import("builtin") cached thus no need to add it to the code?
<andrewrk> if the name was accessible as a comptime value, it would affect the generated zig code
<andrewrk> my comment was a response to lemonboy
<FireFox317> ah okay, and thus cause a rebuild.
<FireFox317> I see
Snetry has joined #zig
<andrewrk> let me think about it a little bit more real quick
<andrewrk> FireFox317, ok my argument for keeping your patch as-is: that name is common to all zig source and all C source files because it affects the output path
<FireFox317> I thought LemonBoy was suggesting that the name of the .o file in the cache directory should reflect the name of the zig source file, and not be affected by the --name parameter i think.
<FireFox317> Or something like that
<FireFox317> andrewrk, yep true.
<andrewrk> I think the logic to name the .o file in the cache directory is correct as is
<andrewrk> --name changes very rarely. it's ok to have it in the root cache hash
<FireFox317> :thumbsup:
<andrewrk> ok, CI should be green now
lucid_0x80 has quit [Quit: Leaving]
mguaypaq has joined #zig
cole-h has joined #zig
mguaypaq has quit [Quit: leaving]
jjsullivan1 has joined #zig
LanceThePants has quit [Read error: Connection reset by peer]
LanceThePants has joined #zig
jmiven has quit [Quit: bye]
jmiven has joined #zig
GrooveStomp has quit [Ping timeout: 240 seconds]
decentpenguin has quit [Read error: Connection reset by peer]
FireFox317 has quit [Ping timeout: 256 seconds]
FireFox317 has joined #zig
LanceThePants has quit [Read error: Connection reset by peer]
LanceThePants has joined #zig
FireFox317 has quit [Quit: Leaving]
decentpenguin has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
cren has quit [Quit: cren]
sord937 has quit [Quit: sord937]
LanceThePants has quit [Read error: Connection reset by peer]
LanceThePants has joined #zig
LanceThePants has quit [Read error: Connection reset by peer]
LanceThePants has joined #zig
<mla> whats a good way to benchmark zig maybe wholesale on a fn-by-fn basis? anything like a sampling profiler like rbspy in zig?
<justin_smith> mla: with a debug build, I'd expect any standard C profiler to give meaningful results
CodeSpelunker has joined #zig
<justin_smith> you will probably need to enable libc linkage as well (which shouldn't be a problem for most apps)
radgeRayden has quit [Ping timeout: 272 seconds]
<justin_smith> a popular choice for linux is gprof
<mla> justin_smith: thanks for the tip, ill give gprof a whirl
GrooveStomp has joined #zig
<mla> hmm i need a gmon.out file , wonder if i can have zig generate that
<g-w1> i know the self-hosted compiler uses tracy, so you could have a look at src/tracy.zig to see how to setup
CodeSpelunker has quit [Quit: CodeSpelunker]
<mla> i guess for tracy route the whole thing is const tracy = trace(@src()); defer tracy.end(); within the top of each fn
<andrewrk> zig uses standard debug info as well, so the answer to your question is the same as "what's a good way to benchmark C/C++"
<andrewrk> I believe the perf function is a sampling profiler
<andrewrk> s/function/program/
<companion_cube> there could be python-like decorators? :p
<mla> thanks, yeah i think im back to gprof, just need to get the right flag to get gmon.out
wootehfoot has quit [Quit: Leaving]
<mla> oh neat valgrind is working for me good, first time ever profiling at this level but callgrind seems to be working for my usecase
<justin_smith> mla: gmon.out is a file gprof creates while the program is running (if you've linked gprof)
<justin_smith> mla: cool - yeah valgrind is a standard option too
marnix has quit [Ping timeout: 256 seconds]
riba has joined #zig
<andrewrk> alexnask[m], are you around?
Akuli has quit [Quit: Leaving]
<ikskuh> andrewrk: how stable are f16/half in zig? :D
<andrewrk> completely
<ikskuh> wonderful
<ikskuh> let's do openglfoo with that
<andrewrk> there are a bunch of targets where we have f16 tests disabled because of LLVM bugs - but they are bugs
<karchnu> ikskuh: why do you need f16? For computation speed?
ncon has quit [Ping timeout: 260 seconds]
ncon has joined #zig
<justin_smith> there are gpus that use f16 natively
<andrewrk> with @setFloatMode(.Strict) zig would have to emulate f16 without target support, but with @setFloatMode(.Optimized) zig would be allowed to use f32 or f64 machine instructions for f16 operations if it decided it was faster
<ikskuh> <karchnu> ikskuh: why do you need f16? For computation speed?
<ikskuh> less space
<ikskuh> texture coordinates for UI rendering
<ikskuh> i can make my struct 8 or 16 byte large
<andrewrk> ah I see for in-memory representation
<andrewrk> yeah just be mindful of your float mode when using f16 in computations
<andrewrk> I'm guessing for your use case you will actually upcast it to f32 or f64 for computations
<andrewrk> then downcast to f16 for storage
<ikskuh> i will never upcast it anyways
<ikskuh> only downcast precomputed texture coordinates to pass them to the GPU :)
<andrewrk> I see. Yes I think that should work quite well
<ikskuh> let's put zig to the test then :)
<ikskuh> maybe i can show-off something later
riba has quit [Ping timeout: 256 seconds]
g-w1 has quit [Quit: WeeChat 3.1-dev]
g-w1 has joined #zig
<andrewrk> only 18 issues left in the 0.7.1 milestone...
<ikskuh> \o/