ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
brzg has joined #zig
remby has joined #zig
xackus_ has quit [Ping timeout: 246 seconds]
gazler__ has joined #zig
gazler_ has quit [Read error: Connection reset by peer]
remby has quit [Ping timeout: 246 seconds]
brzg has quit [Quit: leaving]
remby has joined #zig
remby has left #zig [#zig]
zag has quit [Quit: leaving]
nvmd has joined #zig
<andrewrk> ifreund, good night and thank you very much!
Swahili has quit [Remote host closed the connection]
GreaseMonkey has joined #zig
dyeplexer has joined #zig
mikdusan has joined #zig
xd1le has joined #zig
dominikh has quit [Ping timeout: 260 seconds]
via has quit [Quit: whoops]
xd1le has quit [Read error: Connection reset by peer]
via has joined #zig
leon-p has quit [Quit: leaving]
earnestly has quit [Ping timeout: 246 seconds]
terinjokes has quit [Quit: ZNC 1.8.1 -]
terinjokes has joined #zig
leon-p has joined #zig
mikdusan has quit [Quit: WeeChat 2.5]
GrooveStomp has quit [Ping timeout: 240 seconds]
GrooveStomp has joined #zig
_fritchie has quit [Remote host closed the connection]
_fritchie has joined #zig
mikdusan has joined #zig
leon-p has quit [Quit: leaving]
cole-h has quit [Ping timeout: 256 seconds]
frett27 has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
craigo has quit [Ping timeout: 264 seconds]
wootehfoot has joined #zig
tines9 has quit [Ping timeout: 272 seconds]
earnestly has joined #zig
gpanders_ has quit [Quit: ZNC -]
gpanders has joined #zig
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
tefter has joined #zig
<ifreund> andrewrk: no problem! I'm looking at SliceOpen and Slice next :)
wootehfoot has quit [Ping timeout: 256 seconds]
jokoon has joined #zig
Swahili has joined #zig
zags has joined #zig
<ifreund> slices done, probably look at catch in hour or two
Kiori has joined #zig
tefter has quit [Ping timeout: 265 seconds]
<Kiori> Hi all, has anyone used zig to compile C apps?
<ifreund> sure
<ifreund> just do CC="zig cc"
<Swahili> Learning; trying to figure out how to convert string to int and vice-versa; so found fmt and digitToChar; and tried> const chr = std.fmt.digitToChar(65, false); const result = [_]u8{ chr }; print("Result is {s}\n", .{result}); and get thread 441451 panic: reached unreachable code
<Swahili> what should I learn to figure this out?
<Kiori> I'm trying to figure out how to compile sdl with zig as a c comp. Does zig behave like llvm?
<ifreund> Swahili: for string to int, see std.fmt.parseInt()
<ifreund> for the other way, std.fmt.bufPrint() or std.fmt.allocPrint()
<ifreund> Kiori: indeed, zig relies on libclang to compile C code
<Swahili> ifreund: thanks for looking! yeh, I saw a github comment showing std.fmt.bufPrint(buf, "{}", .{int}); but I think I should really go through the basics to figure this things out myself, as my bg is as3, php, then javascript...did some swift in the past :~))
<Swahili> I had a quick look on comptime yesterday, but I haven't yet reached that point yet :)
<Kiori> @ifreund is there any special setup i should know about before trying to link any lib, or should it just work? thanks for the reply btw.
<ifreund> Kiori: the intention is that it is a drop-in replacement. Barring any bugs you shouldn't need to do anything special
<ifreund> just give it a try and see if it works
<Kiori> ok, i'm figuring it out atm. I'll come back if I hit any walls.
<Kiori> thanks again
<zags> I wonder if it would be possible a Zig optimizer to encode the length of a slice in the upper pointer bits when it can prove the slice doesn't escape.
<zags> And it can prove the length fits in the bits. Highly arch dependent of course.
<Gliptic> that would add masking to every operation
<Gliptic> not obviously an improvement
<zags> even intel cpu's are getting support for that
<zags> should help with cache pressure
<zags> Linear Address Masking Support
<zags> arm already has it
<Piraty> fails with: error: Unknown Clang option: '-target=i386-linux-musl'
<Piraty> i'm doing sth wrong: `make CC="zig cc -target=i386-linux-musl" <...>`
<ifreund> zags: stuff like that is part of the reason slices don't have a well-defined memory layout :)
<ifreund> Piraty: it's --target
<Piraty> ouch
<ifreund> no worries, it just took me a solid 3 reads of the --help
<Piraty> i shuuld step away from the computer on this beautiful sunday
* Piraty uninstalls distro's x86_32 musl crosscompiler -- who needs that if zig has everything :p
xackus_ has joined #zig
<ifreund> :)
<ifreund> note that with musl you even get to choose between static and dynamic linking when cross compiling now :)
<ifreund> before 0.7.1 zig could only do static
<v0idify> no way to compile Linux with zig no? :#
<v0idify> who wants to dynamic link anyway
<ifreund> I do so that my wayland compositor can build on musl systems, good luck staticaly linking mesa
<v0idify> oh :(
<v0idify> ifreund, did the talk get recorded anywhere? I haven't watched it. are you dogfooding river (using it yourself)?
<ifreund> I've been daily driving it for about 6 months
<ifreund> I think recordings of all the fosdem talks should become available soon
<v0idify> okay cool, thanks
<ifreund> andrewrk: done with catch/return, moving on to for loops
<zags> ifreund: good point :)
midgard has quit [Read error: Connection reset by peer]
midgard has joined #zig
squeek502_ has quit [Ping timeout: 264 seconds]
<Swahili> When> fmt.bufPrint(&buf, "{}", .{user_input}), what is "{}"? Tried> const foobar: []const u8 = ""; fmt.bufPrint(&buf, foobar, .{user_input})
<ifreund> "{}" is a format string
<ifreund> e.g. fmt.bufPrint(&buf, "x is: {}, y is {}\n", .{x, y});
<ifreund> the output will be written into the buffer you pass and a slice of the written output returned
<ifreund> if you don't want to supply a buffer manually, use fmt.allocPrint()
<ifreund> and if you want to learn the rules for format strings, read the doc comment of std.fmt.format()
<Swahili> ifreund: thanks for looking! Ah ok, so I can look it up here
<Swahili> sorry, didn't know
<ifreund> no, that library is totally unrealted
<Swahili> I'll try allocPrint just after :)
<Swahili> oh its unrelated
<ifreund> note that's for master though, you might be using 0.7.1
<Swahili> latest 0.8.0 :) Thanks, I'll read
<Swahili> So, in the future, we'd find the documentation for fmt in the main web docs and figure this out without having to check the source code. Right?
mikdusan has quit [Quit: WeeChat 2.5]
<Swahili> I think yesterday it was mentioned that is a good practice to check the source code
<ifreund> Indeed, autogenerated std docs are not yet ready for usage
<ifreund> this is certainly something that will be done sometime before 1.0 though
<Swahili> It'll look great I'm sure :)
<Swahili> I had a look on ( ),since this is documented; I guess that this same tool that'll be used for "autogenerating std docs" can be used for the rest of us? : )
<ifreund> indeed, that would be the idea
wootehfoot has joined #zig
<Swahili> Amazing!
mikdusan has joined #zig
leon-p has joined #zig
zags_ has joined #zig
zags has quit [Ping timeout: 246 seconds]
zags_ has quit [Ping timeout: 264 seconds]
squeek502 has joined #zig
zags has joined #zig
cole-h has joined #zig
gpanders has quit [Quit: ZNC -]
gpanders has joined #zig
gpanders has quit [Client Quit]
gpanders has joined #zig
<v0idify> how can I debug Segmentation fault at address 0x0 / ???:?:?: 0x0 in ??? (???)
<mikdusan> what gave the fault, zig.exe or foo.exe?
<v0idify> ? foo.exe
<v0idify> as in, the compiled binary
<mikdusan> yes
<mikdusan> so is that built as release or debug?
<v0idify> debug
<mikdusan> platform
<v0idify> it just seems like callMain was calling to 0x0 but that's not true :p
<v0idify> x86_64 linux glibc
<v0idify> i'm doing a bunch of C stuff
<mikdusan> did you try gdb?
<v0idify> what should i try with it?
<mikdusan> the executable that faulted
<mikdusan> just run it, let it fault. ask gdb for backtrace. it might show something the builtin segfault handler of zig runtime can't handle.
<v0idify> nope
<v0idify> I found the offending line, i'll investigate
<v0idify> backstrace be like 0x0000000000000000 in ?? ()
<v0idify> it's weird that it doesn't tell me what function is doing it
<mikdusan> where memory gets corrupted is key. if it happens to trounce something in the critical path for backtrace, then this suckage happens
<Gliptic> your C stuff isn't calling some function pointers that could be 0?
<v0idify> Gliptic, i don't think so. the call is just: xcb_connect(null, &num); (where num is a c_int)
<v0idify> the null isn't a function and it works fine in normal C
<ifreund> if you paste the code somewhere it might be easier to help
<v0idify> yeah one sec, sorry
waleee-cl has joined #zig
<Kiori> Hi there, I'm trying to compile sdl with zig cc, it tries to find sdl2.lib files in the libs folder, but sdl only boundles sdl2.a files.
<Kiori> Anyone know anything about it, or how to deal with this kind of issue?
<Kiori> This seems to be a reported problem, as per here:
<ifreund> v0idify: pretty sure you should be initializing screen_number to 0
<ifreund> the comment on the xcb function says that it uses it
<v0idify> ifreund, still segfaults, and it works on C without it
<ifreund> v0idify: can I see the working C code?
<ifreund> your code doesn't segfault for me...
<v0idify> D:
<mikdusan> solved! :P
<Gliptic> just have to shit ifreund's computer
<v0idify> i just realized: the working c code segfaults with the zig compiler!
<Gliptic> eh, *ship
<ifreund> how are you building?
<ifreund> I used zig build-exe xcb.zig -lc -lxcb
<ifreund> v0idify: that could be UBSan kicking in
<mikdusan> does ubsan segfault or some other sig?
<ifreund> zig enables it by default when compiling C code
<v0idify> zig run $(pkg-config --libs --cflags xcb) <file>
<ifreund> UBsan should show ug as SIGILL iirc :/
<v0idify> well that's painfully obvious now
<v0idify> i'm lacking -lc
<ifreund> lol
<ifreund> I'm surprised that compiled though
<ifreund> guess the xcb header doesn't depend on any libc headers
<v0idify> kinda hate that the symptoms were so weird, would rather have had a compilation error
<v0idify> then why did it fail?
<v0idify> oh it uses libc but the headers are not included in their's
<v0idify> so blame xcb?
<v0idify> i gtg, thanks for the help and sorry for being dumb
<ifreund> no worries!
<mikdusan> what was the compiler logic here. id needs a -lc and didn't complain about it? I forget why...
<mikdusan> s/id/it/
<mikdusan> v0idify: is your xcb library(s) built with zig or already present on system?
<mikdusan> n/m. you use pkg-config. so comes from system.
cole-h has quit [Ping timeout: 240 seconds]
Akuli has joined #zig
a_chou has joined #zig
craigo has joined #zig
Kiori has quit [Remote host closed the connection]
riba has joined #zig
jokoon has quit [Quit: Leaving]
jjido has quit [Quit: Connection closed for inactivity]
<v0idify> what's the danger for reading from a variable on another thread if we don't care about partial writes?
<Gliptic> usually that's not the only thing you're doing
<v0idify> ?
<v0idify> the zig async model confuses me a bit. :# i'm thinking in goroutines but that clearly doesn't translate well because there's no channel
jukan has joined #zig
<Gliptic> I mean, do you have two threads, one thread reading a value that the other thread writes to, is that all you have?
<v0idify> fair enough. scratch my message from before, i'm just thinking on how to design this
<Gliptic> the danger is that you can read a new or old value, and it might not match up chronologically with other reads or writes
<marler8997> made a good amount of progress on win32metadata binding gen, take a look at what it's generating so far:
<ifreund> hrm, continue in inline for is borked right?
<ifreund> is there a workaround?
<mikdusan> in stage1?
<ifreund> yeah in stage1
<mikdusan> yeah you don't really change that flow control. the loop is just unrolled that many times. place conditionals around your thing.
<ifreund> oh it's actually a continue for a non-inline while loop in the body of an inline for
dyeplexer has quit [Remote host closed the connection]
<ifreund> uugh, can't even break to a block from the inline for
<ifreund> guess this loop will just be inefficient
<mikdusan> do you mean break to inline_for scope, or to parent of inline_for ? the former seems to work for me.
hnOsmium0001 has joined #zig
<ifreund> break from inside an inline for to a parent scode
<ifreund> s/scode/scope/
<mikdusan> doesn't sound like anything is borked tbh
<ifreund> the compiler crashes with a stacktrace in codegen for the break in question
<ifreund> it only crashes if there is more than one flag_def though and the inline for actually iterates
a_chou has quit [Remote host closed the connection]
<mikdusan> have a reduction. you convinced me it's borked :P
<ifreund> :)
<mikdusan> also it only borks when `continue :outer` is inside the if{}. put it into inline_for scope and no crash
<ifreund> interesting
<mikdusan> I suppose a workaround is add runtime bool as first shortcutting expr of the unrolled if() . bleh.
<ifreund> mikdusan: this is what I did, probably not 100% optimal but it's not a hot path
<mikdusan> oh yeah you just did correct what I was trying to suggest. lol
<mikdusan> btw I also tried converting inline_for to inline_while and bug still persists
<ifreund> that usually only helps when the values of the container being iterated are runtime known but the length is comptime known
<mikdusan> sure just checking on the chance
<ifreund> fair enough, you never know with stage1 :D
marijnfs has joined #zig
<marijnfs> what happened to @TagType
<ifreund> marijnfs: std.meta.TagType() i'd guess
<marijnfs> thanks!
<mikdusan> marijnfs: nice. Is the meta info rich enough to apply a integer literal style? like FILE_ATTRIBUTE_INTEGRITY_STREAM = 32768 looks much better in our existing windows bits.zig as 0x8000
<ifreund> I think you mean to tag marler8997 :P
<mikdusan> whupsee. marler8997 ^^ 2 lines above was meant for you.
<marler8997> @TagType?
<mikdusan> I mean hey I did the first 3 chars and tab-completed :|
<marler8997> oh the integer stuff
<marler8997> the metadata just contains the raw values, we'd have to apply our own rules/tricks to do that
<mikdusan> any way to heuristic that it's flags? flags usually want to be hexed
<marler8997> good question, not that I'm seeing in the metadata
<marler8997> we could go through all the values of an enum and if they are all powers of 2 them assume they are flags and print them in hex
<marler8997> ilspy prints them as hex, should find out what ilspy is doing
<mikdusan> ah ok. was hoping for something we could key off from meta. not very important but if you see a straightfwd way...
<marler8997> looks like ILspy might print all powers of 2 >= 16 as hex
<marler8997> right now I'm trying to deal with the UnicodeAlias part, I'm getting a dependency loop
<ifreund> hopefully it's not #131
<marler8997> nah
<marler8997> current solution is to check if the root modules defines UNICODE=true/false...then set the aliases accordingly
<marler8997> I shouldn't be getting a dependency loop from it
<ifreund> andrewrk: bounced of for/if statements for now, partially due to an issue I found with lastToken() on blocks. Poking at error set decls now
<ifreund> s/of/off/
zags has quit [Ping timeout: 272 seconds]
<andrewrk> roger that
<andrewrk> I'm still on asm
<ifreund> cool, have fun :)
<andrewrk> I think we have enough implemented to run a small zig fmt benchmark and see how this pays off, if at all, for zig fmt
<andrewrk> noting however that the main speedup is intended for the main pipeline, not this one
<ifreund> I don't think it's ready for any real code yet tbh, but some artficially selected code sure :D
<ifreund> RE the issue with blocks, if the last statement ends in a semicolon lastToken() is off by one
<ifreund> I guess we need to add BlockTwoSemicolon and BlockSemiColon?
<andrewrk> yep guess so
<andrewrk> it's kind of annoying, but, in terms of what the hardware is doing I think it's pretty ideal
<v0idify> how does zig plan to address the chicken and the egg problem: what minimal compiler can we start off that's humanly auditable, or will it always depend on an initial C++ compiler? i'm thinking in the line of this:
Swahili has quit []
<ifreund> that may realistically never happen though, the current plan is to depend only on C not C++ for the bootstrap compilier by 1.0
<v0idify> "the evil plan to replace C" I love it
<v0idify> but I agree, starting off from a C compiler is not that bad
zags has joined #zig
<v0idify> is there a good explanation of the two stages? does stage 1 not depend on LLVM? I'm confused
<ikskuh> stage0: 100% c++
<ikskuh> stage1: part zig, part c++
<ikskuh> stage2: 100% zig
<ikskuh> stage3: stage2 compiled with stage2
<v0idify> that makes sense
<v0idify> stage0 uses LLVM right now but it's supposed to not do that in the future right?
<ifreund> stage2 has non-llvm backends in progress
<ikskuh> v0idify: the idea is that stage2 will output stage2 as C code
<v0idify> oh, so it also skips steps!
<pixelherodev> I'm also working on an alternate compiler in C99 that's completely self-contained ~~and wipes the rootfs if it detects that it is linked againsts LLVM~~
<pixelherodev> Not much to see there just yet, as I spent a month or so just focusing on design, but I'm hoping to pick up the pace this week :)
<zags> :)
<ifreund> andrewrk: error set decls and the slice/slice sentinel split are up, going to take a look at splitting out BlockSemicolon and BlockTwoSemicolon now
<v0idify> pixelherodev, awesome!
<motiejus> hi folks. I am trying to compile `Yelp/dumb-init` with `zig cc`, and am getting: `zig: error: argument unused during compilation: '-s' [-Werror,-Wunused-command-line-argument]`
<motiejus> if I remove `-s`, it works; but both clang and gcc happily accept that option
<motiejus> `0.8.0-dev.1039+bea791b63`
<motiejus> is it just missing a flag? If yes, I can go ahead and submit a patch; but perhaps I am misunderstanding something here
<andrewrk> ifreund, nice!
<andrewrk> motiejus, what does -s do? I don't see it documented here:
<motiejus> from gcc(1): ` -s Remove all symbol table and relocation information from the executable.`
<andrewrk> oh snap there is a way to pass strip to the compiler
<motiejus> looks like it's undocumented in clang
<ifreund> does it actuall have an effest in clang or does clang just ignore it?
<motiejus> I wasn't able to find it there, but clang will accept it
<andrewrk> one sec
<v0idify> is there an introduction to std.atomic... things? what is an AtomicOrder?
<andrewrk> not well documented yet, but for now you can use this:
frett27 has quit [Ping timeout: 264 seconds]
<motiejus> andrewrk: thanks, compiling
<andrewrk> it was documented, I just didn't see it at first
<v0idify> andrewrk, wow i understand nothing on that website
<v0idify> my question was more on the line of: "I have no clue what atomic I/O is"
<v0idify> I think I'll just use a Mutex for now though
<andrewrk> I have never heard of atomic I/O
<andrewrk> if this atomics docs don't make sense to you, then yes I suggest to stick to the higher level concurrency primitives
<v0idify> sorry I don't know what's the name for this.. thing
Akuli has quit [Quit: Leaving]
<motiejus> andrewrk: I compiled it and retried, same result: ; I used the 'mkdir build ; cd build; cmake ..; make' ; do I need to wipe caches?
<motiejus> (doing that)
<andrewrk> you don't need to because the cache notices the zig version
<motiejus> well, I thought so. But it still fails
<motiejus> just clone `` and `CC="zig cc" make`
<g-w1> yep, im getting that too with the latest version
ur5us has joined #zig
<g-w1> oh wait, zig cc is broken now :(. `zig cc test.c` results in a bunch unused argument -s for me where test.c is int main() {return 0;}
<mikdusan> sounds like -s should only be spec'd for link
<andrewrk> I see the problem
<andrewrk> ok fixed in latest commit, sorry about that
<andrewrk> motiejus, I tested dumb-init, it builds cleanly now
<andrewrk> thanks for the report
<ifreund> fixed Tree.lastToken() for blocks :)
<andrewrk> wonderful
<andrewrk> and I see Vexu did some work on introducing an intermediary AST for translate-c which is going to make that part of the task straightforward
<andrewrk> finally, astgen should be a piece of cake since we can call those same ast "full" functions
<ifreund> yeah, though someone called the namespace for those "Full" instead of "full"... basically unusuable :P
<ifreund> I think the API they provide is even nicer to use than what the old code had :)
<andrewrk> oh right, oops, I violated the style guide=
<zags> I have a function taking function ptr, argument is callback: anytype - I then try to query it's RETURN type through @typeInfo(@TypeOf(callback)).Fn.return_type.? ... unfortunately, I get `error: unable to unwrap null` Ideas?
<ifreund> We want to snake_case the token and node tag enums too right?
<ifreund> probably push off all the style bikeshed untill everything works right before merge
<zags> oh wait, I can introspect anytype can I?
<zags> can't"
<ifreund> zags: you can introspect the concrete type that actually gets passed to the function
<zags> So basically I need a way to pass any two-arg function to a generic function and introspect the return type, hmm
<zags> ifreund: how?
<ifreund> @TypeOf(arg_name)?
<zags> @typeInfo(@TypeOf(callback)).Fn.return_type.?
<zags> that's why I have
<zags> but... error: unable to unwrap null
<zags> s/why/what
<ifreund> does null mean void or something? not sure
<zags> i never pass functions returning void though
<ifreund> notice that you aren't getting an error saying it's not a function
<zags> yep
riba has quit [Ping timeout: 246 seconds]
craigo has quit [Quit: Leaving]
ur5us has quit [Ping timeout: 258 seconds]
jeyr has joined #zig
jeyr has quit [Client Quit]
<andrewrk> ifreund, yeah I'll do a style pass right at the very very end before merging
<ifreund> cool :)
<ifreund> I'm looking at break now by the way
<andrewrk> got it
wootehfoot has quit [Quit: Leaving]
<andrewrk> we'll want to do a pass to look for TODO comments too I think
<ifreund> indeed, I've left a few myself
<ifreund> though I don't think the many still-commented test cases will pass without most or all of them being resolved
<andrewrk> got it
cole-h has joined #zig
notzmv has quit [Remote host closed the connection]
<andrewrk> man, we could have saved a lot of time by doing it this way from the beginning, heh
<andrewrk> but all in all this is only going to eat a couple weeks, peanuts in the lifetime of the project
<andrewrk> one of the nice things about zig is that we don't have a deadline for 1.0 and we also don't have a big debut. we can slowly start to stabilize more and more, and support more and more use cases. declaring 1.0 will feel like nothing is actually changing
Kiori has joined #zig
notzmv has joined #zig
<ifreund> I mean, 1.0 will be pretty exciting nonetheless :D
<ifreund> but yeah, we have the rare oppurtunity to iterate as much as we want and dodge those pesky local maxima
notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
<zags> is that supposed to work?
<zags> @typeInfo(@TypeOf(func)).Fn.return_type.?
<zags> this one gets confused if `func` has anytype arguments, but a concrete return type
<ifreund> andrewrk: break done, which will be my last commit for today :)
marijnfs has quit [Quit: WeeChat 2.8]
<ifreund> zags: I think what happens there is that the type of functions with anytype parameters is not resovled fully until they are called
<andrewrk> ifreund, wonderful, thank you so much!
reductum has joined #zig