btbytes has quit [Read error: Connection reset by peer]
hio has joined #zig
return0e_ has joined #zig
return0e has quit [Ping timeout: 255 seconds]
return0e_ has quit [Read error: Connection reset by peer]
return0e has joined #zig
shawn_ has joined #zig
shawn_ has quit [Read error: Connection reset by peer]
scientes has joined #zig
Zaab1t has joined #zig
Zaab1t has quit [Client Quit]
scientes has quit [Ping timeout: 268 seconds]
gonzus has joined #zig
scientes has joined #zig
<mikdusan>
is there any .zig code in zig repository that calls c/cpp API from stage1 compiler code? looking for example of how to compile/link against .cpp for because I’d like to use zig’s test harness.
allochi has joined #zig
allochi has quit [Client Quit]
<scientes>
andrewrk, is there some limitation of the bigint.cpp code I should know about, because my new @fshl/@fshr code is breaking on comptime ints u64 and larger
gonzus has quit [Quit: Leaving.]
gonzus has joined #zig
gonzus has quit [Quit: Leaving.]
gonzus has joined #zig
<mikdusan>
ah never mind my earlier question about .cpp test harness. i worked around it.
<tgschultz>
enum literals are a great convenience. Mysterious bools in function calls should become much more rare.
<andrewrk>
Sahnvour, I haven't seen this before, reading now
<andrewrk>
oh actually I have seen this
<Sahnvour>
right
<Sahnvour>
I can't remember if I already asked this, but is top-notch performance a goal of stage1 ? (I guess not)
<andrewrk>
no it's not
<andrewrk>
it is for stage2 though
<andrewrk>
I wonder if we will see the rise of a new compiler backend project which is optimized for debugging and fast compilation speed
<scientes>
so for is guaranteed to iterate forward?
<andrewrk>
yes. I suppose that should go into the lang ref
<Sahnvour>
that would be awesome ... I wonder how much work Jai's debug backend represents
<andrewrk>
I'm sure jon's implementation is tightly coupled with the rest of the project, and that he has no interest in collaborating. he's not very friendly to the open source software movement
<Sahnvour>
my point is, something tailored to a specific project arguably is less work than a general framework like LLVM and since he apparently did it, that may be a radical move paying off
<andrewrk>
yeah. it makes sense for him since he's mostly only targeting x86_64 windows
<andrewrk>
zig is a much more ambitious project
<Sahnvour>
indeed
<andrewrk>
it's so tempting to bypass llvm... we could do so much to speed up compilation
<andrewrk>
but then all the sudden zig has to be an assembler too
<scientes>
and an optimizer
<andrewrk>
well, even if we used llvm only for optimization
<andrewrk>
*only for release builds, I mean
<Sahnvour>
a (optional) fast debug backend, even limited to x64, would still be hugely beneficial imo
<andrewrk>
yeah you're not wrong
<andrewrk>
that comes at a cost of complexity for stage2 though
gonzus has quit [Quit: Leaving.]
<andrewrk>
I think there are fundamentally different ways that the code would be structured, if we only had an LLVM backend, vs if we had an LLVM backend and a custom backend for some targets
<andrewrk>
maybe the differences can be reconciled
<andrewrk>
maybe having a custom x64 backend from the start would help prevent us from designing ourselves into a corner with stage2
<Sahnvour>
making custom backend an afterthought would probably be problematic when implementing it, but I would understand that it isn't a main goal for 1.0 OTOH
wootehfoot has joined #zig
<andrewrk>
inline assembly is one of the main problems with a custom backend
<andrewrk>
on windows it's not an issue because dynamic libraries are the interface to the kernel
<Sahnvour>
why is that a problem ?
<andrewrk>
well maybe not a problem, but a huge project
<andrewrk>
as scientes pointed out, there is a lot of maintenance work associated with an assembler because instruction sets get updated on a regular basis
<bheads>
one option is to include another backend with the stage2 compiler, to avoid the llvm dependency
<bheads>
it doesnt solve the debugging performance per say
<andrewrk>
I don't see how that is an option or what the benefit would be
<bheads>
"I think there are fundamentally different ways that the code would be structured, if we only had an LLVM backend, vs if we had an LLVM backend and a custom backend for some targets"
<bheads>
They did this in D, the frontend was rewritten to support multiple backends, thus it enabled D to have 3 different compilers that were compatible
<andrewrk>
my AWS CloudFront charges for the month of March was $22. about 250 GB downloaded from ziglang.org
<andrewrk>
up from $15 in february, $8 in january. this is growing fast
<bheads>
tats awesome
<scientes>
andrewrk, use scaleway
<scientes>
bandwidth is free
<scientes>
well, it doesn't scale as well
<scientes>
for 8eu/mo you get 200mb/s however it has to cross the atlantic to get to the us
<andrewrk>
ziglang.org is a static site. I don't need a VPS
<scientes>
static sites are the way to go. I just wanted to say that "cloud" is actually very expensive
<scientes>
the mark up are insane
<mikdusan>
250 GB including everything (binary downloads of zig builds) ?
<scientes>
mikdusan, not including github
<andrewrk>
mikdusan, yes
<andrewrk>
I think cloudflare might actually do what I want for free
<scientes>
cloud flare is also always at the cutting edge regarding features
<scientes>
like they support Encrypted SNI
<scientes>
which allow you to hide that you are using zig :)
<mikdusan>
mkvtoolnix uses fosshub for millions of downloads if you wanted to sep packages from website.