<ikskuh>
andrewrk: you're taking a "pointer-pointer" there, so you receive a pointer to an array instead of letting the array decay into the correct pointer type
<andrewrk>
I don't think it's a pointer pointer
<leah2>
but removing the & fixes it ;)
<leah2>
and that makes "it a pointer fewer"
<ikskuh>
andrewrk: yeah, that's why i quoted it :D
<ikskuh>
you get a pointer to an array though
<ikskuh>
instead of a pointer to the first element
<andrewrk>
but I want a pointer to an array
<andrewrk>
and puts also wants a pointer to an array
<ikskuh>
puts wants a pointer to a char :D
<andrewrk>
is there a way to fix it by changing the definition of puts?
<fengb>
Pointer to array would be a double pointer
<pjz>
ifreund: you said "the std.mem.Allocator interface doesn't work at comptime" ... but I don't see that I'm trying to make it do so. It's not marked comptime.
cole-h has quit [Ping timeout: 260 seconds]
a92 has joined #zig
notzmv has joined #zig
SimonNa has quit [Remote host closed the connection]
notzmv has quit [Ping timeout: 240 seconds]
notzmv has joined #zig
<pixelherodev>
andrewrk: I missed something; why does CBE need to use #includes instead of fnsigs for extern "c" fns?
<andrewrk>
I added the new type of test that lets you run the C code that you emitted, and got hello world working. your cbe code doesn't handle update() correctly tho
<pixelherodev>
Nice!
<pixelherodev>
Less nic!
<pixelherodev>
Hey wait... you said CBE was supposed to be separate from incremental compilation, so updates shouldn't occur?
<pixelherodev>
(so was never tested)
wilsonk has quit [Ping timeout: 256 seconds]
ur5us has quit [Ping timeout: 260 seconds]
neptunepink has quit [Ping timeout: 260 seconds]
ur5us has joined #zig
spiderstew_ has joined #zig
neptunepink has joined #zig
spiderstew has quit [Ping timeout: 268 seconds]
neptunepink has quit [Ping timeout: 272 seconds]
neptunepink has joined #zig
neptunepink has quit [Ping timeout: 240 seconds]
neptunepink has joined #zig
neptunepink has quit [Ping timeout: 246 seconds]
neptunepink has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
<pixelherodev>
andrewrk: wait, so do we want to go back on the earlier decision then? We want CBE to be incremental now? :(
<andrewrk>
my stance has always been the same on this, all the backends support the same API. the extent to which they take advantage of it is flexible
ur5us has quit [Ping timeout: 264 seconds]
<pixelherodev>
we explicitly decided that CBE would not support incremental compilation, since there was no use case for it - which is why update was marked unreachable
<pixelherodev>
we could just have it @panic instead of unreachableing, to make it explicit that it's not supported? ("C backend does not support incremental compilation!" for instance)
<andrewrk>
the frontend, which supports incremental compilation, gets to have the same API for every backend
<pixelherodev>
Wait, hold on - which function is update? We use updateDecl, don't we?
* pixelherodev
pops open source
<andrewrk>
I think you are overestimating the changes required to conform to the API
<pixelherodev>
Yeah no, I see
<pixelherodev>
Compilation.update, right?
<pixelherodev>
Okay, I was thinking in terms of the pre-Compilation API
<pixelherodev>
I'll tackle that issue within the next ten hours or so, depending on when I end up sleeping
<pixelherodev>
Thanks for the clarification :)
<andrewrk>
I think if CBE wants to be maximally simple, you would just ignore updateDecl(), ignore deleteDecl(), and do everything inside flush()
<andrewrk>
right now it's doing deleteDecl() => unreachable
<pixelherodev>
Right...
<pixelherodev>
Okay, so is the idea to change Compilation.update to invoke CBE differently, so we don't updateDecl, or to support incremental?
<andrewrk>
no changes to Compilation.zig, it's already calling the backend API correctly
<pixelherodev>
Gotcha,
<pixelherodev>
Ahh okay, I see
<pixelherodev>
... need to pull a new static Zig :P
<pixelherodev>
my stage1 build is too out of date to build stage2 lol
<pixelherodev>
Okay, good to go :)
<pixelherodev>
Sheesh this is not going to be pleasant... codegen now takes long enough to be visible! :(
<pixelherodev>
Whelp, on the bridge side, this just inspired me to redo swathes of the zyg design :P
<pixelherodev>
Uh... master fails on test-stage2 after wiping the cache...
<pixelherodev>
This'll be fun. Global cache, maybe?
<pixelherodev>
With the latest static zig installed, I'm unable to build an unmodified stage2 from master after nuking all caches :( I get an index out of bounds finding the zig path in the test runner? Weird...
<pixelherodev>
There breaking changes since the last nightly?
* pixelherodev
sighs
<pixelherodev>
7ca9f3bc7ba1a413ea7f8b88dfafba3d0f842f6e breaks test running for me, but looking at the code, I don't see *why*
<andrewrk>
you always need to rebuild zig after pulling master
<pixelherodev>
Ohhhh, I see what happened, yeah
<pixelherodev>
andrewrk: do you happen to have a static build you can upload somewhere? :P Library is fine, but my stage1 binary doesn't pass its own path to the test runner
<pixelherodev>
Otherwise, I'm going to just have to wait for the next nightly :P
<pixelherodev>
or, more likely, send an untested PR :P
<pixelherodev>
andrewrk: is it fine to just call `codegenDecl` for everything in the decl_table on flush() ?
<pixelherodev>
Or should it be starting with exports and then dependencies?
decentpenguin has quit [Quit: ZNC crashed or something]
a_chou has quit [Remote host closed the connection]
koakuma has quit [Quit: Leaving.]
wootehfoot has joined #zig
leon-p has joined #zig
podge has quit [Remote host closed the connection]
cole-h has joined #zig
<andrewrk>
it's not linking that takes 95% of the time, it's building zig1.o
<andrewrk>
25 mins sounds like a release build on oldish hardware. do you perhaps intend to be doing a debug build?
SimonNa has joined #zig
<ikskuh>
andrewrk: wow, why does it take *that* long?
<ifreund>
stage1 is slow and llvm is slow
<andrewrk>
ikskuh, slap on a -ftime-report and you'll have a detailed answer
jjido has joined #zig
<ikskuh>
i wonder if i built wrong all the time, i'm using cmake :D
<g-w1>
if you have ~8 gb of ram and no swapping it will probably take a while.
ehaas has joined #zig
ehaas has quit [Client Quit]
ehaas has joined #zig
dumenci has quit [Ping timeout: 256 seconds]
frett27 has joined #zig
bitmapper has quit [Quit: Connection closed for inactivity]
kbd has joined #zig
<kbd>
Hi there. Just started learning Zig a few days ago. As a first exercise, I'm rewriting my shell prompt in Zig so that it's portable to non-posix shells in case I want to use Nu or Xonsh etc. Been poring over the stdlib for a while trying to find where "atoi" is and I haven't been able to find how to convert a string to an int so I figured I'd just
<kbd>
hop on IRC and ask.
wilsonk_ has quit [Ping timeout: 240 seconds]
<ifreund>
kbd: std.fmt.parseInt()
nycex has quit [Quit: Quit]
nycex has joined #zig
<kbd>
ty ifreund!
<kbd>
didn't expect that to be in 'fmt'
<ifreund>
it does feel a little weird for it to be there but I don't know of anywhere else it would make more sense
<pixelherodev>
andrewrk: is it fine to just call `codegenDecl` for everything in the decl_table on flush(), or should I start at exports and recursively check dependencies? With most backends, the usage of updateDecl allows for not thinking about it, since they're added to a work queue; we don't have that, which means all of the logic of "what needs to be done" needs to be replaced with "for decl in all_decls". I'm
<pixelherodev>
just not certain what `all_decls` is in this case...
<andrewrk>
it's fine to iterate the decl_table on flush()
<pixelherodev>
I wasn't sure, thanks for clarifying!
<pixelherodev>
Might be good to catch up on the changes in internals since I last looked; Compilation.update should not have caught me by surprise! :(
<FireFox317>
andrewrk, ah nice!
<ifreund>
pixelherodev: comptime function calls is listed as the agenda
<pixelherodev>
Ah, neat!
* pixelherodev
spies
wootehfoot has quit [Quit: Leaving]
GrooveStomp has quit [Read error: Connection reset by peer]
strmpnk has quit []
cararemixed has joined #zig
tane has quit [Quit: Leaving]
<pixelherodev>
andrewrk: question for some point after the screen (hence here and not irc.twitch): why does sema operate on IR and not AST? Is it faster? Easier?
<ifreund>
pixelherodev: afaik it is because IR is typed
<g-w1>
no, sema turns zir into typed ir. my guess is less code in zir_sema.zig and a little more in astgen (for example, catch and orelse are simmilar, if for and while simmilar)
<pixelherodev>
hmm
<FireFox317>
isnt that for comptime?
<FireFox317>
pixelherodev, see top comment in zir_sema.zig
<pixelherodev>
FireFox317: yes, but *why* is there untyped IR?
<pixelherodev>
I'm confused why sema doesn't operate on the AST, and astgen doesn't just produce typed IR