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/
msingle has quit [Ping timeout: 256 seconds]
nvmd has quit [Quit: Later nerds.]
xackus__ has joined #zig
ur5us_ has quit [Ping timeout: 264 seconds]
earnestly has quit [Ping timeout: 246 seconds]
Jeanne-Kamikaze has joined #zig
ur5us_ has joined #zig
Ashpool_ has quit [Quit: Leaving]
KIMI has joined #zig
<KIMI> hi, is someone have example for "reader interface" i don't understand how to use to read a file line by line
<ifreund> KIMI: sounds like you might want Reader.readUntilDelimiterAlloc() or similar using '\n' as the delimiter
<KIMI> i cann it directly?
<KIMI> call
<KIMI> i don't understand there is no Reader.readUntilDelimitedAlloc
<KIMI> it is hard to read a file
<KIMI> xD
<ifreund> look in std/io/reader.zig where the Reader interface is defined
<ifreund> line #125
<KIMI> but i don't understand it is inside a function inside struct
<KIMI> is there an example of code to use it?
<ifreund> if you're asking how to get a Reader from a File, just use my_file.reader()
<KIMI> i need read file line by line
<KIMI> what is my_file?
<KIMI> i need code example to understand how to do it
<ifreund> whatever file you want to read?
<KIMI> what is type of my_file in your example?
<ifreund> std.fs.File
<KIMI> can you show me full example i am lost xD
<ifreund> const f = try std.fs.cwd().openFile("foo.txt", .{}); const line = try f.reader().readUntilDelimiterAlloc(allocator, '\n', 1024);
<KIMI> thanks
<KIMI> how to get next line?
<ifreund> call readUntilDelimiterAlloc() again, you probably want to use a while loop
<KIMI> why it can't find file in parent folder?
<ifreund> cwd() gives you the current working directory when you run the program, that's where it looks
<KIMI> how to read in a parent folder?
<KIMI> this is hard :(
<andrewrk> it's a legitimately hard problem and the API is not yet stable. the functions that exist were only added in order to unblock a different project. the API hasn't seen any intentional effort spent on it yet
<ifreund> KIMI: you can pass a relative path, i.e. "../foo.txt"
<KIMI> that is what i write ../data/font.fnt but i get: Unable to dump stack trace: FileNotFound
cole-h has quit [Ping timeout: 240 seconds]
<g-w1> iirc it (".." in file path) doesn't work on windows
<KIMI> yes i am on windows
<KIMI> what should i do?
<g-w1> you could do openFileAbsolute if you know the absolute path
<KIMI> but if i move exe it wont work anymore
<KIMI> if path change
a93 has joined #zig
<KIMI> i can use fopen?
<KIMI> i found C example
<KIMI> i will keep on C i think for the moment i need to learn it properly
<g-w1> I think std.fs.realpath gives you the absolute path, im not on windows so I can't really test it. sry. fopen will probably work.
<KIMI> but i don't like headers :(
<andrewrk> marler8997, I eliminated one thing as a possible cause of failure
<andrewrk> https://clbin.com/brmaX working binary is at the top, crashing binary is next. you can see the working binary has a version number on the dlopen function. but in the failing stack trace, it does go into the correct version after all
<andrewrk> this plus the fact that musl-based void linux is having a crash (somewhere else) seemingly due to lack of running start code, leads me to believe that is the next place to look
<KIMI> why i cant use string on fopen? i get an error msg error: expected type '[*:0]const u8', found '[]const u8'
<KIMI> i can't open a file since yesterday xD
<ziguana[m]> andrewrk: in case you haven't seen it https://fasterthanli.me/articles/so-you-want-to-live-reload-rust. looks mildly related to whatever the hell you're trying to do here (link vulkan drives from a static binary?)
<ziguana[m]> the TLS part was surprising to me in particular, didn't know that it needs special constructors and destructors
<KIMI> i will stick with C i think sorry :(
<andrewrk> KIMI, try again closer to 1.0 :)
<KIMI> when is it released?
<andrewrk> years into the future
<KIMI> i will try again later someone on telegram told me to try zig for easier C, but i'm not very good even in C
kristoff_it has joined #zig
msingle has joined #zig
<andrewrk> marler8997, sorry to keep pinging you, I'm using you as a rubber duck and to give little progress updates
<andrewrk> next thing I discovered: the crash is in glibc main thread initialization code. it's doing pd->tid = INTERNAL_SYSCALL_CALL (set_tid_address, &pd->tid);
<andrewrk> but the address it is using comes from THREAD_SELF and it ends up being 0x2d1 which is an invalid pointer. So something is wrong with THREAD_SELF
KIMI has quit [Remote host closed the connection]
<andrewrk> for x86_64 it's this: https://clbin.com/HDlhk
<andrewrk> which makes sense since this is the crash: https://clbin.com/MFKEz
<andrewrk> ok so the fs register is not set up properly
<andrewrk> hmm I bet LemonBoy would know the answer here
<andrewrk> zig sets the fs register in start code, but it looks like glibc did not like the value we set it to
xentec has quit [Ping timeout: 240 seconds]
radgeRayden has joined #zig
<andrewrk> I see the problem. here are the last few syscalls the glibc dynamic loader does before entering zig's _start code, followed by the 1st syscall that zig's _start code does: https://clbin.com/9z8ok
<andrewrk> basically zig's start code is clobbering the fs register value from glibc's start code
<andrewrk> since we didn't actually link with libc, zig thought we were in charge of the start code
<andrewrk> s/the start code/initializing TLS/
CommunistWolf has quit [Quit: No Ping reply in 180 seconds.]
CommunistWolf has joined #zig
<andrewrk> yooo I got a window
<ziguana[m]> git push when
<andrewrk> it's with this patch to zig, which I can't just push, I need to think about how to make this work for normal use cases too: https://clbin.com/P0DND
<ziguana[m]> cool! is there an issue where I can catch up with what this is for?
<andrewrk> no but here's the repo: https://github.com/andrewrk/zig-window
<andrewrk> I'm planning to do a nice blog post on this soon
<ziguana[m]> sweet, thanks
<andrewrk> what distro do you use?
<g-w1> are there any other types of errors besides @compileLog that don't stop analysis?
<ziguana[m]> the glorious nixos
<andrewrk> you wanna try my binary?
<ziguana[m]> yeah, let me get to a pc
<g-w1> could I try it? I use arch.
<ziguana[m]> ok, got a nix-shell or something?
<g-w1> I also have nix though
<ziguana[m]> man, nvm i'm on llvm10 still for zig, sorry
<andrewrk> ziguana[m], that's the thing, you don't need anything, you can run it without installing anything
<ziguana[m]> i'm kind of scared about this project tbh, aren't you going to end up reimplementing a good portion of dynamic linking? that'd be a can of worms and a half...
<ziguana[m]> oh right, static binary
<andrewrk> run that in a terminal so you can ctrl+c it and tell me what it does instead of opening a window like it is supposed to
<ziguana[m]> it just werkz holy hell
<andrewrk> :-O
<g-w1> is it supposed to work on any linux?
<andrewrk> that's the goal but there are some TODOs
<andrewrk> I'm about to try a musl-based linux
<g-w1> yeah i get illegal instruction
<ziguana[m]> you on x86-64, right?
<g-w1> yes
msingle has quit [Ping timeout: 240 seconds]
<andrewrk> g-w1, I need to get master branch patched up so that this doesn't depend on my local dirty tree, and then if you're interested to join the effort, you could try building from that zig-window repo and you could help figure out what patches might be needed to make it additionally work on your system
hlolli_ has joined #zig
<ziguana[m]> looking forward to that blog post, i'm really curious about what exactly you did
<ziguana[m]> looks like manually dlopen'ing x11 libs and doing the vulkan loading too
<andrewrk> I am curious about where that illegal instruction is. My best guess is UBSAN found a bug in Vulkan-Loader
<g-w1> I am interested! This seems like a very good learning oppurtunity for me to learn about lower level stuff. I am using a 2013 cpu so maybe ur cpu just has more instructions
<andrewrk> oh!
<andrewrk> hang on yeah that's a native build - let me change to baseline
<andrewrk> :D
<ziguana[m]> too much mtune?
<andrewrk> when you compile for the native CPU, zig takes advantage of the native CPU features. you have to intentionally cross compile to do something different
hlolli__ has quit [Ping timeout: 272 seconds]
<andrewrk> all I'm doing differently now is adding `-target x86_64-linux` to the build, which will then select the "baseline" CPU features
<andrewrk> g-w1, ^
<g-w1> IT WORKED
<ziguana[m]> haha this one dies for me, but only some of the time
<andrewrk> whaaat
<ziguana[m]> actually getting killed by the sanitizer, "memory leak detected"
<g-w1> when i resize the window this happens: https://share.olind.xyz/f.php?h=30ALFSux&p=1
<ziguana[m]> error: VulkanOutOfDate..wh..what'
<ziguana[m]> yep, that's what i see
<andrewrk> I'm sure the "hello world triangle" code I wrote has a bug in it
<andrewrk> I see the same thing
<andrewrk> that's not really the point of this demo though :)
<ziguana[m]> don't worry, we're still impressed
<andrewrk> ok so we have arch and nixos in the bag
<andrewrk> who's next?
<andrewrk> :D
<g-w1> lemme try debian rn
<andrewrk> damn, I gotta go in a minute, I promised to help with chores at 6pm and it's 6:38 now
<andrewrk> I'm getting a segfault inside musl on void linux
<waleee-cl> works fine on clearlinux (I assume the triangle in static-window4 is unmoving?)
<andrewrk> yep it's unmoving. wow nice! that's quite a few linuxes already!
<andrewrk> no musl based linuxes yet tho
<g-w1> ill leave you with this cryptic error on debian: https://paste.rs/tTv
a93 has quit [Quit: leaving]
<andrewrk> I know how to solve that
<andrewrk> we need to detect what the proper soname for libdl.so is. right now it is hard coded to libdl.so.2
<andrewrk> ok so basically the patch to zig we need is to be able to disable the call to initStaticTLS() in start.zig. or we need to have it runtime detect that it does not need to run that code
<ziguana[m]> does the static TLS collide with something?
hlolli_ has quit [Ping timeout: 272 seconds]
<ziguana[m]> or is it just that register?
<ziguana[m]> ok, i can wait for the blog post
msingle has joined #zig
<Snektron> wowie, ziguana has come to life
<waleee-cl> a friend running slackware were 'meh' about testing the demo binary
raggi has joined #zig
<andrewrk> yeah that's fair
<andrewrk> I mean the source is available if they don't trust it
<Snektron> andrewrk: your binary disconnects my monitor
<andrewrk> o.O
<Snektron> Its not your fault, i noticed this on my own example as well, so at least i know it didn't do anything wrong especially
<Snektron> or we made the same mistake, which is entirely possible
<Snektron> I thought the issue was already fixed since it didn't trigger on my own example
<Snektron> basically my monitor turns black and then tells me there is no signal
msingle has quit [Ping timeout: 246 seconds]
<Snektron> not really sure what to do about it...
<Snektron> Now it works fine (glibc void)
<andrewrk> what was it before?
<Snektron> Same OS, i just rebooted
<Snektron> I suspect some other application interacts with it somehow, or maybe my driver is somehow unstable
<Snektron> im not sure how to trigger it
<waleee-cl> soneone else running musl void also got a segfault
<andrewrk> I'm able to repro that
<andrewrk> will debug it soon
<andrewrk> gotta go, see ya
radgeRayden has quit [Ping timeout: 272 seconds]
xackus__ has quit [Read error: Connection reset by peer]
xackus has joined #zig
xackus_ has joined #zig
xackus has quit [Read error: Connection reset by peer]
xackus__ has joined #zig
xackus_ has quit [Ping timeout: 240 seconds]
frmdstryr has quit [Ping timeout: 240 seconds]
xackus has joined #zig
xackus__ has quit [Ping timeout: 256 seconds]
layneson has quit [Ping timeout: 246 seconds]
<marler8997> so if I understand correctly, we need some way to know whether or not we were loaded by ld, so we can know whether or not to initialize tls?
KIMI has joined #zig
<KIMI> hi, i want to try again, how to convert [*]const u8 in to [*:0]const u8?
<KIMI> i got [*]const u8 by doing path.ptr (path is a []const u8)
<KIMI> i can't give up this easy i need finish it lol
<g-w1> try std.cstr
<KIMI> how to use it?
<KIMI> how it is with llocator
<KIMI> oh
<g-w1> std.cstr.addNullByte
<KIMI> one question why it is different than on C? on C i can just "the path" without 0 at the end
<KIMI> is on C automatic?
<KIMI> wit haddNullByte it work thanks
<KIMI> it is possible to not have to use allocator and make it transparent like in C?
<KIMI> i am trying this example https://stackoverflow.com/a/3501681
<KIMI> it work fine too if i put the path directly like in the example
<KIMI> i have my code on a function like thjis fn load(a: *Allocator, path: []const u8) !FontData
<KIMI> i think my message is a confusing because i don't explain all, i call load(allocator, "the path") <= how to make it so this is directly passed into fopen(path) like i would do with fopen("the path")
<KIMI> i ask this because i don't think i should allocate just to add a 0
<KIMI> ok i read api of fopen require null terminated string since there is no size parameter, that is why it ask [:0], so i need make my function too that require [:0] anyways
<KIMI> [:0] is what i needed all from the start xD
<KIMI> fn load(a: *Allocator, path: [:0]const u8) !FontData
<KIMI> now another problem, there is no getline in c.zig
<marler8997> if you share the zig code you have now, should be easy to help
<marler8997> missing definition for fontdata
<marler8997> how about just send all your code?
<KIMI> why?
<KIMI> i just want read file xD
<KIMI> line by line
<marler8997> because the code you sent me is missing code I need to compile it
<marler8997> also, not sure why you are using fopen
<KIMI> just create text file and call code to load fopen
<KIMI> because with reader i can't load file in parent folder on windows
<KIMI> apparently
<marler8997> do you just need zig code that reads a file line by line?
<KIMI> yes
<KIMI> the file is in parent folder
<KIMI> i am here with fopen because reader dosn't work on windows for parent folder with"../"
<KIMI> i forgot who told me that, but it is in this chat
<KIMI> i get file not found when i tried
<marler8997> ok give me a minute
<KIMI> ok thanks for trying to help me
<KIMI> thanks
<KIMI> reader is what i tried
<KIMI> it doesn't work on windows with path "../" for file in parent folder
<KIMI> i will try ur code
<KIMI> yes same error: Unable to dump stack trace: FileNotFound
<marler8997> that means the file you are trying to open and read doesn't exist
<marler8997> FileNotFound
<KIMI> the file exist
<KIMI> it works with fopen
<KIMI> it find the file
<marler8997> you must have path or cwd incorrect
<marler8997> how are you running it?
<KIMI> like the other person said on this chat on windows it doesn't work with path "../"
<KIMI> that is why i said i will use C
<marler8997> let me try that
<KIMI> with fopen and getline
<marler8997> "../test.txt" works for now
<marler8997> *works for me
<marler8997> what OS are you on?
<KIMI> i run the test zig test font.zig
<KIMI> windows
<marler8997> oh..that's why
<KIMI> yes xD
<KIMI> so what should i do?
<marler8997> to workaround, you could get the absolute pathname, and strip off the last directory
<KIMI> but it is allocating
<marler8997> what is allocating?
<KIMI> i tried that too, i need allocate to get absolute path
<KIMI> or it was for the addbyte i forgot
<marler8997> to get absolute path, you can either allocate, or use MAX_PATH with a global/stack buffer
sord937 has joined #zig
<KIMI> can you show me how to do this to get the file in parent directory
<marler8997> yeah, writing a function for you
<KIMI> thanks you
<pixelherodev> KIMI: the null byte isn't automatic in Zig; it's only needed when interacting with C code. The default "string" type in Zig uses a length tracker instead of a null byte
kristoff_it has quit [Ping timeout: 264 seconds]
<KIMI> thanks marler8997
<KIMI> i could have never figured that code by myself
<marler8997> you'll get there eventually if you keep at it
<pixelherodev> ^
<KIMI> what i put as depth?
<pixelherodev> (Positive) experience is the key determiner for code quality
<marler8997> that's the number of ".." you want
<pixelherodev> Of course, if most of the code you've worked with is bad, you'll learn to write bad code :(
<marler8997> so long as you are vigilant with self evaluation and keep yourself to high quality standards you will get better
<pixelherodev> Yeah, though knowing what quality is can be difficult if you haven't seen it :)
Jeanne-Kamikaze has quit [Quit: Leaving]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
ur5us_ has quit [Ping timeout: 264 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
lucid_0x80 has joined #zig
supercoven has joined #zig
marnix has quit [Ping timeout: 246 seconds]
marnix has joined #zig
xackus has quit [Quit: Leaving]
xackus has joined #zig
a_chou has joined #zig
a_chou has quit [Client Quit]
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #zig
marnix has quit [Ping timeout: 256 seconds]
marnix has joined #zig
cole-h has joined #zig
osa1_ has joined #zig
KIMI has quit [Remote host closed the connection]
ur5us_ has joined #zig
<andrewrk> marler8997, the tls initialization problem is solved in the most recent commit I pushed to zig master branch (assuming it passes CI)
<marler8997> checking
<andrewrk> "All checks have failed" => oh.
<andrewrk> ugh that's just the stack traces test needing line numbers of start.zig to be in the test cases
<marler8997> good
<andrewrk> yeah. major progress today!!
<marler8997> how far are you getting now?
<andrewrk> did you try the binary? https://andrewkelley.me/temp/static-window4
<andrewrk> check the bottom of the readme of zig-window
<marler8997> oh headless still getting Vulan Extension not present error, trying on virtualbox
KIMI has joined #zig
<KIMI> about the code someone gave me why fn load(allocator: *std.mem.Allocator, reader: anytype) !void reader is anytype
<andrewrk> I think we are already getting the correct output for headless
<KIMI> why is it anytype and not Reader?
<marler8997> VulkanInitializationFailed :(
<marler8997> got to "opening window"
<andrewrk> KIMI, because of https://github.com/ziglang/zig/issues/764
<KIMI> thanks i will look
osa1_ has quit [Quit: osa1_]
LanceThePants has joined #zig
earnestly has joined #zig
gpanders has quit [Ping timeout: 240 seconds]
sawzall has quit [Ping timeout: 240 seconds]
ur5us_ has quit [Ping timeout: 264 seconds]
<andrewrk> marler8997, hmm I think it will be interesting to see what failed. perhaps something to do with X11?
gpanders has joined #zig
lucid_0x80 is now known as suskun
nyaayaya has quit [Remote host closed the connection]
nyaayaya has joined #zig
nyaayaya has quit [Remote host closed the connection]
nyaayaya has joined #zig
cole-h has quit [Quit: Goodbye]
mitchk has joined #zig
hlolli_ has joined #zig
mattmurr___[m] has joined #zig
<mitchk> HI All, I'm having some trouble. Building on a brand new fedora 33 install. I've installed clang-devel,llvm-devel,lld-devel all 11.x. When I run "cmake .." I get an error "Could NOT find clang (missing: CLANG_LIBRARIES) " Is there a env variable I should set to define that?
<mitchk> Build the zig project that is.
<dutchie> andrewrk: i also see VulkanInitializationFailed
<dutchie> i'm on wayland, but xwayland should be working
mitchk has quit [Remote host closed the connection]
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
KIMI has quit [Remote host closed the connection]
mitchk has joined #zig
mitchk has quit [Remote host closed the connection]
gpanders has quit [Ping timeout: 246 seconds]
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
gpanders has joined #zig
Core3159 has joined #zig
Core3159 has quit [Read error: Connection reset by peer]
radgeRayden has joined #zig
kristoff_it has joined #zig
frmdstryr has joined #zig
<g-w1> mitchk: I think you are experiencing this: https://old.reddit.com/r/Zig/comments/hn0q1j/build_for_fedora_32/
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
<g-w1> regarding my bug on debian where it couldn't find the .so file for static-window, /lib64 is just ld-linux-x86-64.so.2 (only thing in it) so anything it ties to load from there (libdl.so.2) just doesn't exist. libdl is here for me on debian /usr/lib/x86_64-linux-gnu/libdl.so.2
marnix has quit [Ping timeout: 272 seconds]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
supercoven has quit [Ping timeout: 240 seconds]
marnix has joined #zig
filpAM has joined #zig
shynoob has joined #zig
<shynoob> hey I am new here..
<shynoob> any pointers to where to get started
msingle has joined #zig
osa1 has quit [Ping timeout: 256 seconds]
osa1 has joined #zig
hlolli__ has joined #zig
zugzwang_ has joined #zig
hlolli_ has quit [Remote host closed the connection]
zugzwang_ has quit [Remote host closed the connection]
zugzwang_ has joined #zig
msingle has quit [Ping timeout: 256 seconds]
shynoob has quit [Ping timeout: 240 seconds]
zugzwang__ has joined #zig
zugzwang__ has quit [Client Quit]
shynoob has joined #zig
zugzwang_ has quit [Ping timeout: 260 seconds]
<shynoob> when will zig be production ready?
<shynoob> sorry I mean when will zig 1.0 be released?
swills has quit [Quit: swills]
swills has joined #zig
supercoven has joined #zig
supercoven has quit [Max SendQ exceeded]
supercoven has joined #zig
supercoven has quit [Max SendQ exceeded]
<karchnu> shynoob: I guess we will have to wait until the self-hosted compiler will be ready, and when API will be stable and generic for all architectures.
<karchnu> This could be years from now.
supercoven has joined #zig
supercoven has quit [Max SendQ exceeded]
swills has quit [Client Quit]
supercoven has joined #zig
supercoven has quit [Max SendQ exceeded]
supercoven has joined #zig
supercoven has quit [Max SendQ exceeded]
<shynoob> uh oh
<karchnu> Maybe this will be sooner than that, self-hosted compiler wasn't really a thing a few months ago and now it is still experimental but in the 0.7.0 release.
<karchnu> I bet that the zig language and most of the standard library will be (kinda) stable in less than a year.
Akuli has joined #zig
donniewest has joined #zig
<wilsonk> quit
<fengb> Don't quit us :o
radgeRayden has quit [Read error: Connection reset by peer]
<shynoob> lol
waleee-cl has joined #zig
xackus has quit [Read error: Connection reset by peer]
xackus has joined #zig
<marler8997> andrewrk, I ran with "xtrace" which said Authentication Rejected: None of the authentication protocols specified are supported and host-based authentication failed
<mq32> karchnu, shynoob: i guess that zig can be "production ready" in roughly 2 years from now on for the major platforms (x86_64, arm64, linux,windows, mac)
dumenci has joined #zig
suskun has quit [Ping timeout: 256 seconds]
chowder has joined #zig
<marler8997> andrewrk, scratch my last response (was running with xtrace from glibc). actual X11 xtrace doesn't show much, I see setup/CreateWindows and a couple InternAtom comands
chowder has quit [Quit: Leaving]
TheLemonMan has joined #zig
mq32 is now known as ikskuh
filpAM has quit [Remote host closed the connection]
Guest59 has joined #zig
nrdmn0 has quit [Quit: Ping timeout (120 seconds)]
nrdmn0 has joined #zig
shynoob has quit [Quit: Leaving]
msingle has joined #zig
hnOsmium0001 has joined #zig
Akuli has quit [Remote host closed the connection]
Akuli has joined #zig
Ashpool has joined #zig
m4r35n357 has quit [Quit: Ex-Chat]
<andrewrk> marler8997, hmm, does this example work? https://github.com/SaschaWillems/Vulkan#Basics this is where I cribbed the code from
<andrewrk> 01 - Triangle
<marler8997> trying...
Ashpool has quit [Quit: Leaving]
cole-h has joined #zig
hlolli__ has quit [Ping timeout: 246 seconds]
<marler8997> it also fails...which is good I guess :)
<marler8997> vkEnumeratePhysicaDevices fails
<marler8997> could be virtualbox doesn't have a GPU
<marler8997> I have an ubuntu machine with a monitor attached I can try as well
<marler8997> oh...looks like the ubuntu loader doesn't support the "--preload" parameter
<g-w1> same thing on debian that happened to me
<andrewrk> same thing on WSL
<marler8997> I think LD_PRELOAD is more widely supported
<fengb> Hasn’t 1.0 been “2 years from now” for about 5 years now? :P
<andrewrk> for at least 2 years yeah haha
<marler8997> probably better to use LD_PRELOAD, then if we want, we can remove the values we added on the second invocation
sord937 has quit [Quit: sord937]
<TheLemonMan> andrewrk, yo, have you seen my comment on the TLS changes?
<andrewrk> not yet! looking for it now
<g-w1> I am a little confused. Wasn't the project to compile it into a static binary? Why is there a dynamic linker being used? Is it being used to make the static bianry and then run it?
<andrewrk> TheLemonMan, ah. yeah I didn't really think this through very well
skuzzymiglet has joined #zig
<TheLemonMan> ABI compatibility is a huuuge problem
<andrewrk> want to brainstorm how to get further on the graphics window problem? we made more progress yesterday, and have a binary that runs on a few different distros: https://andrewkelley.me/temp/static-window4
<andrewrk> it's almost as if we would need builtin.link_libc to be a runtime value
<TheLemonMan> doesn't run here (debian/x86_64)
<ifreund> g-w1: linking mesa statically isn't really viable
<andrewrk> oh yeah I think debian is blocking on the dyld not supporting --preload, so we need to switch to using LD_PRELOAD
<g-w1> ah, because it is so close to the hardware?
<andrewrk> code base is here: https://github.com/andrewrk/zig-window
<andrewrk> g-w1, if I recall correctly, not because of any sensible reason, just because of accidental complexity in the way it is set up
<ifreund> yeah, that's my understanding as well
<g-w1> ok
Jeanne-Kamikaze has joined #zig
<marler8997> I should have a PR for LD_PRELOAD soon
<andrewrk> TheLemonMan, we *could* have official support for this use case, and have something like std.builtin.runtime_link_libc (comptime value - if true a different, runtime value would tell whether this was the static or dynamic execution). in this case thread.zig would use this mechanism to take the pthread path
<andrewrk> it would add more complexity to the std lib
<andrewrk> but this is a pretty obviously valuable use case
<TheLemonMan> more is an understatement, we're already drowning in complexity
<andrewrk> valid concern
<andrewrk> what do you think, should we give up on this?
msingle has quit [Ping timeout: 240 seconds]
<TheLemonMan> the idea is cool, trying to use a single executable as dynamic and static at the same time is the biggest problem
<TheLemonMan> maybe if you stick to statically linked glibc/musl and try to run it with a matching dynamic loader... dunno
<TheLemonMan> on a related note, do you remember why `resizeFn` has a `buf_align` parameter?
<TheLemonMan> bfredl, ping
<andrewrk> TheLemonMan, the idea is that the client is responsible for tracking all the allocation metadata, including pointer, length, and requested alignment
<TheLemonMan> but `buf_align` can be simply obtained by the slice ptr, and it'd be even correct if the user down-aligned the slice
<TheLemonMan> eg. a []align(16) u32 can be safely thrown around as a []align(4) u32, trying to free the latter will call `resizeFn` with `buf_align` of 4 instead of 16
<marler8997> I think the point of buf_align isn't to know the alignment of the pointer, but to be used in something like an alignment lookup table
<marler8997> there are cases where an allocator could use it, however, I might argue that the use cases would be rare, and in the cases where it is useful, the allocator could manage that information itself
<andrewrk> I'm not strongly in favor of defending the idea. As far as I'm concerned, client tracking of length and alignment, and the thing where you can get more bytes than requested are all experimental
<andrewrk> IMO if we can't show some real data on perf improvements or debugging experience being better, we should simplify the interface and remove those things
<marler8997> this decision is what my generic allocator design addresses, it doesn't specify who owns allocation metadata, it can be managed by the caller or the allocator
<TheLemonMan> the C allocator may make use of that info and choose between plain malloc and posix_memalign
<TheLemonMan> I hesitated because of this possible problem, picking the wrong function here means a runtime crash so it's pretty critical
<ifreund> hrm, can't figure out how to work around or isolate this stage1 compiler crash I've found :/
<andrewrk> ifreund, are you able to get a gdb stack trace?
<andrewrk> marler8997, yeah we should test the perf of your generic allocator with one that does its own tracking and see if we can use that to justify the interface
<ifreund> andrewrk: yeah poked around with gdb a bit already, one sec
<marler8997> andrewrk, yeah that's a good idea
<TheLemonMan> andrewrk, annnd, what do you think of the proposal in #6870 ?
<TheLemonMan> marler8997, what's this generic allocator thing?
<ifreund> andrewrk: https://0x0.st/iRtQ.txt
<ifreund> by using @compileLog and print in gdb I've tracked it down to this code: https://github.com/ifreund/zig-wayland/blob/7848a30142af9b3dead9373fd87d237240458c4a/src/common_core.zig#L70
<ifreund> but I haven't managed to create a minimal reproducer or figure out a way to sidestep the crash
<TheLemonMan> marler8997, looks nice but a bit too convoluted for my taste
<marler8997> The idea would be to implement all the allocators in the generic interface, but keep the runtime allocator interface
<ifreund> and Obj is this when it crashes: https://0x0.st/iRte.txt
<TheLemonMan> two nested `inline for`, you're really pushing your luck here
<andrewrk> TheLemonMan, I'm in favor of breaking {} and forcing people to be in the habit of using {s} to force string interpretation. I already think in status quo, {} is a footgun
<ifreund> yeah, though it's been working alright till now :/
<TheLemonMan> andrewrk, awesome!
<andrewrk> was that the only open question?
<TheLemonMan> yeah, unless you don't like the brackets I've used :P
<andrewrk> for representing slices?
<TheLemonMan> yeah, both slices and arrays now print as `{ x, xx, xxx, ... }`
<andrewrk> I'm fine with that
<TheLemonMan> ifreund, try `up 5` and `p source_node->src()`
<TheLemonMan> finding and replacing all the stray `{}` is gonna take a while
<ikskuh> andrewrk: i agree on forcing {s} for strings :)
<ikskuh> annoying, but we still have writeAll :)
<ikskuh> well, "annoying"
<ikskuh> :D
<ikskuh> typing one character more
<ifreund> TheLemonMan: that points me to line 71 of the code I linked
<ikskuh> let vs const again! :D
<fengb> 5076
<ifreund> (I had to go up a little more than 5)
<TheLemonMan> awesome, what's the result of `p val->data` in the `ir_resolve_const_type` frame?
<TheLemonMan> I'm afraid it's tripping up that assertion because of the `destroy: void` field
<ifreund> oops, wrong ping entirely :/
<TheLemonMan> hmm, the data payload is completely zeroed... what's `p val->special` ?
<ifreund> ConstValSpecialStatic
<TheLemonMan> and `p val->type->special` ?
<ifreund> "there is no memeber named special"
<TheLemonMan> arr, `p val->type->id`
<ifreund> ZigTypeIdMetaType
osa1 has quit [Quit: osa1]
osa1 has joined #zig
<TheLemonMan> can I reproduce the crash by pulling the zig-wayland repo?
<ifreund> no, you'll need my WIP branch of river
<andrewrk> TheLemonMan, we *could* make {} a compile error and you'd have to put some character in there to mean "figure it out based on the type"
<ifreund> Give me a second and I'll push my current local changes
<andrewrk> similar to how you have to put `: anytype` in a parameter instead of leaving it blank
dumenci has quit [Ping timeout: 260 seconds]
<ikskuh> "{?}"
<andrewrk> yeah something like that
<TheLemonMan> that's an interesting idea, people may not want to type that extra character tho
<andrewrk> I agree. however right now we do have a footgun that C printf doesn't have. in printf you get a compile error if you do %s and put a non-string. in zig you get incorrect output at runtime
<ikskuh> ↑
<TheLemonMan> #1358 reserved "{?}" for the debug output format, makes sense
<ikskuh> which is kinda a "just give me *something*"
<ifreund> TheLemonMan: you should be able to reproduce on this branch with a zig build after initing the submodules: https://github.com/ifreund/river/tree/zig-wlroots
<TheLemonMan> ikskuh, let's make it print a random string!
<ikskuh> haha :D
<andrewrk> tangentially related, it would be nice if there were an easy way to do a path separator in a format string without " ++ foo ++ "
<ikskuh> "these numbers are here for debugging"
<ikskuh> "{/}"
<ikskuh> :D
<andrewrk> that seems reasonable
seatodawn has joined #zig
<marler8997> LD_PRELOAD PR here: https://github.com/andrewrk/zig-window/pull/7
bkleiner has joined #zig
<TheLemonMan> ifreund, gimme a few minutes, gotta compile wlroots
<seatodawn> hello, this is gonna be HELLA dumb, but how would I go about opening a file in zig?
<ifreund> TheLemonMan: thanks for giving it a look :)
<ifreund> seatodawn: std.fs.cwd().openFile()
<ikskuh> seatodawn: std.fs.cwd().openFile("path", .{});
<seatodawn> god IM DUMB
<seatodawn> i was just reading the documentation and couldnt figure it out for the life of me, THANK YOUUU
<ifreund> no problem, and I don't think that means you're dumb. The documentation isn't too great yet
<seatodawn> be back later boyos, probably with a different name 😁
<ifreund> o7
<seatodawn> ahh i guess, still :^(
<seatodawn> hope u guys dont mind me being a bby noob and asking questions
seatodawn has quit [Quit: Quit]
<TheLemonMan> ifreund, works fine here? I've just built the river.o object (couldn't link it because of some missing libs)
<ifreund> TheLemonMan: huh? are you on the master branch or the zig-wlroots branch?
<TheLemonMan> on the wrong one, of course
<andrewrk> we have 1 report of ubuntu working with this
<marler8997> dang, vulkan extension not present, my ubuntu probably too old
<g-w1> same for me on debian https://paste.rs/KvS
<andrewrk> ok there is one more thing to try, can you find the location of where your vulkan .so files are?
<andrewrk> for me it is /run/opengl-driver/lib/ and I hard coded that but maybe we need to detect a different path for that
<andrewrk> e.g. /run/opengl-driver/lib/libvulkan_intel.so
<andrewrk> ok yeah let me double check if we look in /usr/lib/x86_64-linux-gnu/
<marler8997> locate vulkan gives me 888 entries...lol
<marler8997> looks like I don't have vulkan installed
<andrewrk> look for libvulkan.so, or libvulkan_intel.so, or libvulkan_radeon.so
<marler8997> none of it, all my '.so's are from my yocto repositories, none installed nativealy on the system
<ifreund> heh, your static window thing crashed river :D
<ifreund> I should probably look into that, my xwayland stuff is pretty sloppy as I don't care much about it
<marler8997> ifreund, how did it connect? does river have an XServer?
<ifreund> yeah, it has decent suppport for X programs through Xwayland
<andrewrk> ifreund, heh yeah well we will also add wayland support too :D
<ifreund> it can be buggy though depending on how weird the clients are though
<marler8997> cool, I was able to use Xwayland to get doom over X to run on our printers that use wayland
Ashpool has joined #zig
<andrewrk> g-w1, actually, look for something like this: https://clbin.com/mLgtC
<andrewrk> maybe something in "share" ?
<g-w1> hmm. maybe I dont have https://paste.rs/ruU
<g-w1> ok, ill try that
<andrewrk> if you figure out something that works we can add runtime logic to detect it
segmentationfaul has joined #zig
<segmentationfaul> wait
segmentationfaul has quit [Client Quit]
segfaults has joined #zig
<segfaults> there we go
<TheLemonMan> ifreund, the problem is in deps/zig-wayland/generated/zriver_status_v1_server.zig, the Request type is generated multiple times with different bodies
<TheLemonMan> removing the extra definitions fixes the crash
<ifreund> TheLemonMan: they are generated in different namespaces though, shouldn't that be fine?
<TheLemonMan> yeah, but that's the quickest workaround I thought of :)
<ifreund> interesting
<TheLemonMan> ok, the problem are the zero-sized enums
<ifreund> the ones with just destroy: void?
<TheLemonMan> yeah
<ifreund> well it makes sense why nobodies hit this yet, it's not something that would come up in non-generated code
<g-w1> I now got to VulkanInitalizationFailed by just installing more vulkan packages from apt. (I think a mesa package did the trick)
Xavi92 has joined #zig
ur5us_ has joined #zig
LanceThePants has quit [Read error: Connection reset by peer]
LanceThePants has joined #zig
frett27 has joined #zig
<TheLemonMan> I really hate when writing a small test case takes more time than fixing the problem :(
Xavi92 has left #zig ["https://quassel-irc.org - Chat comfortably. Anywhere."]
<ifreund> heh, I'm curious what you came up with. My attempts at a small test case didn't reproduce the crash
<g-w1> Oh, I think my gpu driver is just bad (debian foss stuff). Im like 80% sure it's not zig-window's fault
skuzzymiglet has quit [Read error: Connection reset by peer]
<ifreund> static-window6 works using something other than river on void/glibc by the way
jeko has joined #zig
jeko has quit [Quit: Leaving]
<segfaults> is there an argc equivalent in zig?
<segfaults> i could only find argv
<marler8997> argv.len?
<segfaults> i-
<segfaults> t-thank u
<segfaults> im not used to zig, my 21 yo boomer ass stuck in C mentality
<marler8997> if you're a boomer what does that make my 32 yo ass?
<segfaults> a relic of days past, bless us with your knowledge
<marler8997> lol
<segfaults> lmaooo im sry <3
skuzzymiglet has joined #zig
ur5us_ has quit [Ping timeout: 264 seconds]
<andrewrk> TheLemonMan, in my experience that's most of the time
<TheLemonMan> ifreund, a patch is up, let me know if it solves your problem
<TheLemonMan> if you manage to write a small test case I'd really appreciate it
<TheLemonMan> andrewrk, this time the test case is something like 3-4 projects heh
<andrewrk> we need a zig equivalent of creduce :)
<marler8997> dlang had one that I think was pretty generic? dustmite
<g-w1> does it just work by reducing stuff until the compiler doesn't crash smartly?
<andrewrk> g-w1, yes
marnix has quit [Ping timeout: 256 seconds]
<pixelherodev> Does creduce not work on Zig?
<pixelherodev> I thought it was just generic enough and Zig *just* close enough for it to work
<pixelherodev> csmith-for-zig would be neat too
<pixelherodev> Have a server spent a constant 1% of CPU finding compiler bugs for instance :P
<pixelherodev> heck, csmith + import-c might be able to work
<ikskuh> is it a known problem that windows crosscompilation doesn't work?
<marler8997> pixelherdev, I was not aware of csmith...looks cool
<ikskuh> for release builds it is
<marler8997> cross compiling on windows to something else, or to windows?
<segfaults> im trying to use std.os.argv[0..] but it says slice of undefined, am i doing something wrong or is this not allowed?
<segfaults> im trying to print it right now, to test
<g-w1> is the error at runtime or compile time?
<segfaults> compile time
<segfaults> because if i use std.os.argv[1] it does work
<g-w1> this is because argv is set to undefined in std/os.zig at compile time and then populated at runtime. it is probably a bug in zig.
<segfaults> gotcha, thank you
<ikskuh> marler8997: linux → windows, x86_64-windows, Release***
<ikskuh> marler8997: lld-link: error: could not open 'libcmt.lib': No such file or directory
<ikskuh> that's the error i get for all release modes
<TheLemonMan> ikskuh, try with x86_64-windows-gnu
<TheLemonMan> libcmt.lib is part of MSVC sdk iirc
<ikskuh> ah!
<ikskuh> well, that's one weird error :D
<ikskuh> but right, i link libc in release modes as _sincos is missing in release without libc :D
skuzzymiglet has quit [Read error: Connection reset by peer]
cren has quit [Quit: cren]
cren has joined #zig
<TheLemonMan> open a ticket for that, it shouldn't be hard to add
<ikskuh> yeah, i'll do
<ikskuh> but thanks to you, i now have this: https://mq32.de/public/f2cb237cecaf8b5ea3fe4c9980190248dd38fe75.png
<g-w1> is the thing that happened earlier with std.os.argv[0..] not working because it was undefined a bug?
frett27_ has joined #zig
<ifreund> TheLemonMan: that fixed it, thanks so much
<ifreund> I will try and get a test case worked out
kristoff_it has quit [Ping timeout: 256 seconds]
Akuli has quit [Quit: Leaving]
frett27 has quit [Ping timeout: 240 seconds]
<andrewrk> Congrats to alexnask[m] who is now a part time paid contractor for ZSF! 🎉
<pixelherodev> Congrats alexnask[m] !
<pixelherodev> andrewrk: unrelated, I think emit-h PR is ready :)
<andrewrk> nice
<pixelherodev> It was mostly tetsuo, I just provided the test harness
<karchnu> Congrats alexnask[m]!!
LanceThePants has quit [Read error: Connection reset by peer]
<ikskuh> oh, alex is now paid to solve my problems? NICE
<pixelherodev> That's totally true! :D
<ikskuh> <3
<alexnask[m]> Thanks ppl!
fivemoreminix has joined #zig
fivemoreminix has quit [Client Quit]
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<wilsonk> congrats Alex
skuzzymiglet has joined #zig
KIMI has joined #zig
<KIMI> hi, i make some progress today but i find some issues
<KIMI> it never print the 1st character
<ikskuh> andrewrk, alexnask[m]: is there platform-independent file mapping tool in std?
<KIMI> |< erning first=86 second=44 amount=-1
<KIMI> it should print:
<KIMI> >| kerning first=86 second=44 amount=-1 |<
<andrewrk> ikskuh, I don't think so
<pixelherodev> ikskuh: going to ping Alex with every question now? :P
<KIMI> i think is because on windows new line is different
<KIMI> yes that is that, i switched to LF and now it is printing right line
<KIMI> i fix my own bug, i make progress indeed xD
<KIMI> how to make it so it accept both LF and CRLF? with delimiter?
<ifreund> const foo: void = undefined;
<ifreund> is this the same as const foo: void = {}; ?
GrooveStomp has joined #zig
<ikskuh> pixelherodev: sure thing! :D
<ikskuh> <andrewrk> ikskuh, I don't think so
<ikskuh> ah dang
<ikskuh> i remember something std.fs.MapOfFile
<ikskuh> time to implement that!
skuzzymiglet has quit [Ping timeout: 260 seconds]
<andrewrk> ifreund, ha funny you should ask that, our Specs Meeting last week answered exactly that question
<ifreund> guess I should pull up the minutes :D
<andrewrk> I think SpexGuy typed up the respective github issues too
<ifreund> cool, that makes my code easier to write
donniewest has quit [Quit: WeeChat 3.0]
<ifreund> gotta say, taking steps towards a proper spec makes me excited
<ikskuh> yeah, me too
ur5us_ has joined #zig
reductum has joined #zig
cren has quit [Quit: cren]
Guest59 has quit [Quit: Connection closed]
xackus has quit [Ping timeout: 256 seconds]
<andrewrk> I think the LemonBoy PR I just merged is going to make some people happy
<marler8997> KIMI, after you read the line and check it isn't null, you can strip the "\r" character off the end
<marler8997> stripRight or trimRight probably
<andrewrk> ifreund, is #7205 a candidate for 0.7.1?
<pixelherodev> Specs meeting?
<pixelherodev> Neat
<karchnu> I just saw the last loris's video on async/await, thanks so much for that.
<pixelherodev> I think given the removal of the stage1 emit-h, re-adding it in for 0.7.1 with the CBE makes sense
<pixelherodev> But I contributed to it so I'm probably biased, and I'd generally say that the minor releases should have as few changes as possible
<andrewrk> it's a bug fix release, so it should have only bug fix releases
<andrewrk> *only bug fixes
<pixelherodev> andrewrk: "emit-h stopped working in 0.7.0 after working fine in 0.6.0" ;)
<pixelherodev> I kid
<andrewrk> it was part of stage1 though. adding it to stage2 won't actually restore the same functionality