<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 bar.foo, 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?
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
<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