ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
<andrewrk> Flaminator, there are a well defined set of types that the language depends on; these will be part of the spec
<andrewrk> it is already the case that core language features are kept separate from the standard library
<andrewrk> this thing that you desire is already in effect
<andrewrk> yxprogramming, I think your best bet is to treat it like a normal library - put the libc.a file on the command line for example
<yxprogramming> Yeah, I've tried that and it seems to work, the problem is that I also need to use some c libraries, and the it won't let me do that unless I use `exe.linkLibC()`. Is there a way around this?
<plumm> Why is std.mem.zeroes a code smell?
<andrewrk> yxprogramming, what problem are you running into if you do not use exe.linkLibC() ?
squeek502_ has quit [Remote host closed the connection]
eax has joined #zig
klltkr has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
klltkr has joined #zig
klltkr has quit [Client Quit]
<plumm> is there any way to get cImport to treat enums as not just c_ints? i have a use case where it's a c_long instead
klltkr has joined #zig
klltkr has quit [Client Quit]
<yxprogramming> andrewrk: The error is `LibCInstallationNotAvailable`
<andrewrk> yxprogramming, check `zig libc --help`
<andrewrk> you should be able to create a libc.txt file and then use `--libc libc.txt` to use it
<andrewrk> but I'm also wondering why it is trying to find a libc installation
<andrewrk> this error looks like it is only possible to get if you are linking libc, are you sure you are not accidentally trying to link libc?
earnestly has quit [Ping timeout: 240 seconds]
<yxprogramming> andrewrk: I am trying to link libc intentionally, the C library I am using requires it. The issue may be that I am using both `exe.addObjectFile("libc.a")` and `exe.linkLibC()`, but I am unable to include the header files without the latter
<g-w1> what is the error if you use the c library with out exe.linkLibC()
<andrewrk> yxprogramming, yes those two strategies are incompatible with each other
<andrewrk> have you tried using -I or -isystem flags for the headers?
<g-w1> yxprogramming: you also need headers for your libc
<yxprogramming> so the build finishes without errors now, what I did to solve it was move the libc headers into my project directory and added the include directory to my build.zig file, and it stopped complaining about the libc linking. I guess it was just having trouble finding the headers from my system. Thanks for the help!
<g-w1> makes sense, nice that you got it working
osa1_ has joined #zig
osa1 has quit [Ping timeout: 268 seconds]
<noam> Recursive imports (foo -> bar, bar -> foo) don't allow access to non-pub members of foo via, right?
<noam> Or, in a file foo.zig, with a non-pub member bar, @import("foo.zig").bar() is illegal, right?
xackus has joined #zig
xackus__ has joined #zig
xackus_ has quit [Ping timeout: 268 seconds]
xackus has quit [Ping timeout: 246 seconds]
yxprogramming has quit [Quit: leaving]
eax has quit [Quit: leaving]
<andrewrk> mm that's a good question
<andrewrk> I think it's going to be not true. so that @This() and @import("current_file.zig") would give you the same thing
<andrewrk> direct answer: "no"
eax has joined #zig
isolier has quit [Ping timeout: 268 seconds]
isolier has joined #zig
skuzzymiglet has quit [Remote host closed the connection]
isolier has quit [Ping timeout: 252 seconds]
eax has quit [Quit: leaving]
<plumm> anyone have any recs on chairs?
bitmapper has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
ur5us__ has quit [Ping timeout: 258 seconds]
a_chou has joined #zig
a_chou has quit [Remote host closed the connection]
retropikzel has joined #zig
sord937 has joined #zig
cole-h has quit [Ping timeout: 252 seconds]
nathanael has joined #zig
nathanael has left #zig [#zig]
ur5us__ has joined #zig
johannes_ has joined #zig
daex has quit [Ping timeout: 252 seconds]
daex has joined #zig
ur5us__ has quit [Ping timeout: 250 seconds]
amk has joined #zig
daex has quit [Ping timeout: 240 seconds]
bitmapper has quit [Quit: Connection closed for inactivity]
linear_cannon has joined #zig
daex has joined #zig
xackus has joined #zig
jjido has joined #zig
xackus__ has quit [Ping timeout: 265 seconds]
earnestly has joined #zig
deb303 has quit [Ping timeout: 240 seconds]
xackus has quit [Ping timeout: 240 seconds]
ur5us__ has joined #zig
xackus has joined #zig
ur5us__ has quit [Ping timeout: 250 seconds]
osa1_ is now known as osa1
ur5us__ has joined #zig
waffle_ethics has quit [Remote host closed the connection]
waffle_ethics has joined #zig
leon-p has joined #zig
Seich has quit [Ping timeout: 252 seconds]
Seich has joined #zig
retropikzel has quit [Ping timeout: 250 seconds]
leon-p has quit [Quit: leaving]
dyeplexer has joined #zig
wilsonk has quit [Read error: Connection reset by peer]
daex has quit [Ping timeout: 268 seconds]
daex has joined #zig
<xackus> mikdusan I followed the LLVM upgrade procedure but zig0 still segfaults :(
ur5us__ has quit [Ping timeout: 245 seconds]
<mikdusan> which lvm13 commit are you building against, so I can sync with you
<mikdusan> ooh interesting. I pulled your latest branch, built against whatever I had for llvm13 and now get a zig.exe (ie. zig0 produced something).
<mikdusan> and using an llvm13 assert build:
<mikdusan> Assertion failed: (STI.hasFeature(X86::Mode16Bit)), function emitPrefixImpl, file /opt/src/llvm/13.xackus/llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp, line 689.
<mikdusan> to build basic.zig ^^
<mikdusan> looks like something is off here. Model16bit ?
<mikdusan> s/Model/Mode/
<xackus> the commit is 64c24f493e5f4637ee193f10f469cdd2695b4ba6
<mikdusan> awesome. I already have that one built
klltkr has joined #zig
<mikdusan> ok so I have a zig0 and a zig produced, and zig0 against basic.zig no longer segfaults. Is that your case too?
<mikdusan> __but__ using zig instead of zig0, examining .ll and target triple looks bogus:
<mikdusan> target triple = "i386-unknown-macos-gnu"
<mikdusan> smells like an inconsistency between .cpp and .zig enums
<plumm> are error traces still borked?
<xackus> hmm I think I somehow broke my llvm build
<xackus> I hope this time, with lto disabled, my debug build will complete
<mikdusan> lib/std/target.zig, Arch is not updated. it needs m68k ?
<xackus> hmm, I updated all the zig_clang stuff
<xackus> this needs to be synced too?
<mikdusan> yes, it doesn't appear to be explicitly mentioned in upgrade procedure
<mikdusan> i think toElfMachine should have a .m68k => ._68K mapping too
<mikdusan> toCoffMachine map to .Unknown sounds reasonable
<xackus> looks like I also missed target.cpp::arch_list, though that one is mentioned in a comment
<mikdusan> which linux are you on?
<xackus> ubuntu
<xackus> I will wait until the build completes, I don't want the C++ language server to cause OOM
<xackus> or I guess I can use a dumb editor
<mikdusan> tbh you probably don't need llvm+debug (which implicitly has +asserts); a nice llvm+release+assert gave me the nice assert above.
<xackus> I'm too far into the build for it to be worth to restart
<xackus> but thanks for the idea
<mikdusan> is m68k a 16-bit ptr ?
<xackus> Wikipedia says 24/32 bit address bus
dyeplexer has quit [Ping timeout: 268 seconds]
frmdstryr has joined #zig
<mikdusan> xackus: added a diff at end of gist:
leon-p has joined #zig
bitmapper has joined #zig
<xackus> mikdusan I don't see a diff
waleee-cl has joined #zig
<mikdusan> hmm maybe I forgot to hit the comment button. should be there now.
<mikdusan> afk
<xackus> thanks!
xackus_ has joined #zig
xackus has quit [Ping timeout: 252 seconds]
xackus_ has quit [Client Quit]
xackus has joined #zig
hidayat has joined #zig
johannes_ has quit [Quit: leaving]
WilhelmVonWeiner has joined #zig
dyeplexer has joined #zig
hidayat has quit [Quit: Connection closed]
pretty_dumm_guy has joined #zig
ifreund has quit [Quit: WeeChat 3.1]
ifreund has joined #zig
frmdstryr has quit [Ping timeout: 252 seconds]
Techcable has quit [Quit: ZNC -]
Techcable has joined #zig
<andrewrk> anyone willing to figure out how to set up a reverse shell and attach gdb to the stalling drone CI test?
lemur has joined #zig
klltkr has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
TheLemonMan has joined #zig
Akuli has joined #zig
retropikzel has joined #zig
skuzzymiglet has joined #zig
cole-h has joined #zig
retropikzel has quit [Ping timeout: 276 seconds]
lemur has quit [Quit: Konversation terminated!]
plumm has quit [Quit: Textual IRC Client:]
leon-p has quit [Quit: leaving]
leon-p has joined #zig
dyeplexer has quit [Remote host closed the connection]
pretty_dumm_guy has quit [Quit: WeeChat 3.2-dev]
plumm has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<noam> > "AstGen" which stands for Abstract Syntax Tree Generation. This is the part where we input an AST and output Zig Intermediate Representation code
<noam> That seems... weirdly named.
<plumm> what is weird abouit it
<noam> "AST gen takes in an AST and gens IR"
<noam> "ASTGen" sounds like it generates an *AST*
<plumm> I guess it's more of an artifact than anything. I presume that step was there before zir
pretty_dumm_guy has joined #zig
<andrewrk> noam, did you have a concrete counter proposal?
<noam> For the name?
<andrewrk> yes
mikdusan has quit [Quit: WeeChat 3.0.1]
<noam> ... IRGen?
<noam> IR Generation, the process that generates IR?>
<andrewrk> there are 2 kinds of IR
<g-w1> zirgen?
<andrewrk> that works
<andrewrk> I think one mistake I made in stage1 was not coming up with clear, distinct names for these concepts
<g-w1> did you see sobeston's comment about an air conditioner being an optimiser for zig 🤣
<g-w1> i laughed so hard
<andrewrk> yes 💯
<andrewrk> yeah I decided we're going to rename ir.zig to air.zig Analyzed Intermediate Representation
<g-w1> makes a lot more sense
<ikskuh> i love "air conditioner"
<ifreund> are we going to have both ZirGen and GenZir?
<ifreund> that sounds bad
<ikskuh> Ast2Zir, Zir2Air, Air2Machine
<andrewrk> MC = Machine Code
<g-w1> why is naming things so hard?
<andrewrk> why wouldn't it be? that's all math is
<andrewrk> ifreund, Scope.GenZir should probably be Scope.ZirBlock
<andrewrk> Block => AirBlock
<ifreund> andrewrk: yeah that seems right to me
<andrewrk> it's starting to come together
<andrewrk> it's not always obvious at first what concepts will be in play
<andrewrk> what do we even do in stage1?
<ifreund> we analyze.cpp ir.cpp and codegen.cpp
<andrewrk> ah we only have ScopeBlock in stage1 because we don't have an SSAT, we use basic blocks and phi nodes
<g-w1> except ir.cpp is also astgen
<g-w1> which kind of makes sense
<g-w1> but a lot of things in ir.cpp should go in analysis.zig imo
<g-w1> s/zig/cpp :P
<andrewrk> ah wasn't sure if you were suggesting to self-host more
<andrewrk> there's unfortunately a performance reason (both compilation and runtime) for ir.cpp to be large
<g-w1> what, im very curious
<andrewrk> putting functions in different files in C and C++ means the optimizer cannot inline them, which is the core optimization trick that enables all other ones
<g-w1> oof, thats pretty bad
<andrewrk> and then also C++ especially, but also C to some degree, is slower at compile multiple files than if you just put all the logic in fewer files
<ifreund> yup, that's a large reason why C++ compile times are absolute shit
<g-w1> yes, that makes sense
<andrewrk> #include means redoing a lot of work, *especially* with templates
<andrewrk> the compiler has to do all the work for every file, and then the linker has to notice there is redundant work and delete it
<ifreund> you have to put so much in the headers so it can be inlined, which then gets compiled repeatedly for every object that includes it
<andrewrk> so next time you have to wait a long time for LLVM to build, you can thank the C++ gods for designing a language that introduces pointless redundant overhead to every single file!
<ifreund> well, #include originated in C
<g-w1> will the zig llvm backend have compilation units? or is that not a concern since it is for debug builds?
<andrewrk> ifreund, yeah but c'mon they've had plenty of time to solve this problem
<companion_cube> and they did… in 2020
<g-w1> ~~c++ modules~~
<andrewrk> g-w1, not sure what you're asking
<g-w1> will zig still give llvm a big hunk of ir to do? or will it be split up?
<andrewrk> ah I see. currently the spec will say splitting of a compilation job into compilation units is implementation-defined, not something the language has control over
<g-w1> i remember that llvm does not like big hunks of ir and this is one of the reasons that compilation is slow today
<andrewrk> I think you should be more specific than "does not like" because it certainly generates optimal code
<g-w1> *takes a long time
<ifreund> which is fine for release builds
<g-w1> yeah, that is why I was asking
<g-w1> for targets where zig will not have a backend, it might be useful
<andrewrk> yeah it might. the spec will leave room for the implementation to choose to do that
<g-w1> do you plan to finish all backends before 1.0?
<andrewrk> no
<g-w1> ok
<andrewrk> will just make sure the support table is clear and prominently featured
<andrewrk> before 1.0 I plan to finish a representative set of backends to make sure we didn't miss something in the language design
<andrewrk> but we need to be able to add and remove backends over a long period of time without breaking the language
<g-w1> so some TODOs will be allowed in the code?
<andrewrk> no, they have to all be issues:
<andrewrk> no TODO comments allowed in code at 1.0
<g-w1> ohh
<g-w1> but issues will be allowed?
<andrewrk> yes, in accordance with the support table
<g-w1> ok, thanks for the clarification
<andrewrk> np
leon-p has quit [Quit: leaving]
sord937 has quit [Quit: sord937]
lemur has joined #zig
<g-w1> andrewrk: does this look correct for `try`?
<g-w1> i think i mismatched the code /payload
lqd has quit [Read error: Connection reset by peer]
tcsc has quit [Ping timeout: 250 seconds]
tav has quit [Ping timeout: 250 seconds]
euantorano has quit [Ping timeout: 245 seconds]
meinside has quit [Ping timeout: 260 seconds]
tcsc has joined #zig
lqd has joined #zig
euantorano has joined #zig
<g-w1> i think *this* is correct
tav has joined #zig
meinside has joined #zig
<g-w1> when i put up a pr, i have some questions that are TODOs
<marler8997> andrewrk, did everything work out with the llvm 12 release?
<andrewrk> marler8997, no, this was a particularly YOLO release from upstream and we are still dealing with the consequences
<marler8997> feck
<andrewrk> biggest issue is the flaky failures on drone ci
<marler8997> ugh, flaky ci failures are the worst
<ifreund> finally got annoyed enough by github thinking zig was primarily written in C to figure out what was wrong and fix it :D
<andrewrk> thanks
<marler8997> what was the fix?
<marler8997> that does produce some much better optics
Akuli has quit [Quit: Leaving]
<g-w1> ok i made a pr for `try` astgen
lemur has quit [Quit: Konversation terminated!]
tlam has quit [Read error: Connection reset by peer]
Piraty has quit [Quit: ---]
ur5us__ has joined #zig
tlam has joined #zig
mikdusan has joined #zig
<andrewrk> g-w1, you ok with a handoff?
<g-w1> yep
pretty_dumm_guy has quit [Quit: WeeChat 3.2-dev]
<andrewrk> g-w1, this might be a fun one for you: TODO implement int literals that don't fit in a u64
<andrewrk> hmm, looking at it looks like there may be some kind of parse error there
<andrewrk> pretty sure 0b0000_0000 should fit in a u64 :)
Bernstein has quit [Remote host closed the connection]
<g-w1> yeah, interesting
<g-w1> for bigints i would just use Zir.Inst.Const
<g-w1> ?
<andrewrk> that does not exist anymore
<andrewrk> no pointers allowed
teratorn_ has joined #zig
<g-w1> ooh, store the limbs in extra data :D
<g-w1> who needs structs when you have extra_data
<andrewrk> lol that's the spirit
dingenskirchen has quit [Quit: ZNC 1.8.1 -]
<andrewrk> only problem you gotta solve is the limbs are usize and extra_data are u32s
teratorn has quit [Ping timeout: 240 seconds]
<g-w1> i was thinking bitcast
<andrewrk> you can take some inspiration from float literals
<g-w1> ok
<g-w1> are you going to add a zir inst for try since its so popular?
<andrewrk> all the zir instructions that try needs are already available
<g-w1> i meant to reduce memory/disk
<g-w1> or does it not make sense to?
<andrewrk> The ZIR code has to have expressions turned into instructions
<g-w1> yes, i meant to add a zir instruction for try, but nevermind
<g-w1> it doesn't make that much sense :P
<andrewrk> try makes sense at the instruction level but not at the IR level :)
xackus has quit [Ping timeout: 252 seconds]
dingenskirchen has joined #zig
moodman has joined #zig
Stephanie is now known as Stephie
marijnfs has joined #zig
<marijnfs> how do i overwrite the print method for a struct?
<g-w1> define a format function on it
<g-w1> you can find a good example in src/codegen/spu-mk2.zig
<marijnfs> g-w1: ah nice, i think i got it
<marijnfs> can i do this for a 'native' type?
<marijnfs> I have an ID: [N]u8
<g-w1> no
<marijnfs> :(
<noam> andrewrk: is anon function calling an accepted part of 1717? similarly, is `var a: fn()void = undefined; a = foo; a = bar;` valid?
<andrewrk> marijnfs, there is a pattern you can follow
<andrewrk> check out std.zig.fmtId and usage sites
<andrewrk> noam, yes it is valid
<noam> gotcha, okay
<noam> Wanted to double check before thinking about the implementation :P
<marijnfs> andrewrk: what does that do? I would have to wrap by struct in fmtId?
dingenskirchen has quit [Ping timeout: 240 seconds]
<andrewrk> usage looks like: print("foo: {}", .{ fmtId(xyz) })
dingenskirchen has joined #zig
<marijnfs> i see
<marijnfs> how do i convert a []u8 to [*c]const u8
<ifreund> foo.ptr
<ifreund> though be careful, C might expect the pointer to be null terminated
<marijnfs> that works
<marijnfs> i see]
<marijnfs> does [:0] automatically convert?
<ifreund> convert to what?
<marijnfs> yes it does, nice
<noam> Uhhh, it doesn't automatically insert a terminator
<noam> If the original string isn't already zero terminated, that'll result in Bad Things
<marijnfs> [:0]u8 converts to [*c]const u8 without ptr
<marijnfs> so that makes sense yeah
<noam> ... ah, I thought you meant the slicing operation (foo[:0]), not changing the type of foo
<marijnfs> isn't that python:P
<andrewrk> marijnfs, c pointers are dangerous, the only reason you should be using them is if using @cImport
<ifreund> tbh I'm a little surprised that [:0]const u8 coerces to [*:0]const u8
<andrewrk> I think it checks out. when would that be problematic?
<ifreund> I don't have any concrete example, it just seems inconsistend with e.g. []const u8 and [*]const u8
<ifreund> why does having a sentinel make a slice coerce to a pointer?
<andrewrk> []const u8 to [*]const u8 is lossy
<ifreund> ok, but so is [:0]const u8 to [*:0]const u8
<ifreund> the 0 could come early
<andrewrk> I don't have a good answer to that but I also feel that there is an argument to be made here that I can't think of. would be up for discussing this on the issue tracker over time
<andrewrk> if there is a demonstrable footgun here that would be a solid argument for removing the type coercion from the language
<marijnfs> andrewrk: yes i'm working with c code indeed
<marijnfs> i definitely favour automatic coercion
marijnfs has quit [Ping timeout: 245 seconds]