<scientes>
/// Tries to print a stack trace to stderr, unbuffered, and ignores any error returned.
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
tridactyla has quit [Remote host closed the connection]
tridactyla has joined #zig
bgiannan has joined #zig
walac has quit [Ping timeout: 252 seconds]
walac has joined #zig
<tralamazza>
emekankurumeh[m]: do you remember the error exactly?
Summertime has quit [Quit: Sunsetting.]
Summertime has joined #zig
<daurnimator>
scientes: it's not great for nested definitions
porky11 has joined #zig
ltriant has quit [Quit: leaving]
<marler8997_>
looking through some zig code, I just realized that D's input range interface (empty/front/popFront) can be emulated in zig with one function (next)
<marler8997_>
Input Ranges in D: for (; !range.empty; range.popFront) { auto value = range.front; // code }
<marler8997_>
And Zig's solution: while (range.next()) |value| { // code }
<ki9a>
do you guys use official llvm or a fork?
<mikdusan>
official. currently 8.0.0
<daurnimator>
ki9a: since LLVM 8, official.
<ki9a>
ah. Nevermind then. I just did macabi support for my own copy, they won't accept that till it's officially released by apple later this year ofc but if you use official then there's little point in offering.
<ki9a>
(that's uikit on mac)
<marler8997_>
what's macabi?
<ki9a>
as announced at wwdc, you can now run uikit apps (think ios code) on osx.
<ki9a>
but it requires a special set of flags in the object files.
<marler8997_>
interesting, I know very little when it comes to apple's development tools/environment
<ki9a>
It feels like a hack to be honest.
<marler8997_>
sounds similar to adding support to be able to run android apps on linux or something
<ki9a>
yep
<marler8997_>
cool
<marler8997_>
weird, but cool :)
<ki9a>
would have made a lot more sense to properly port uikit
<gonz_>
andrewrk: No, nothing in particular yet. I have my eye on a few interop use cases for the BEAM (Erlang VM) and things like that at the moment, as well as just exercises in replicating coreutils, etc. just for fun.
kristoff_it has quit [Remote host closed the connection]
marijnfs_ has quit [Quit: WeeChat 2.4]
tdl7rt has joined #zig
tgschultz has quit [Read error: Connection reset by peer]
tgschultz has joined #zig
hio has joined #zig
tdl7rt has quit [Quit: Page closed]
<scientes>
ki9a, i believe there is still a single (very small) patch in lld
<scientes>
this copy elision stuff is super exciting!
FireFox317 has quit [Quit: Page closed]
halosghost has joined #zig
halosghost is now known as alot
<ki9a>
scientes: ah.
<scientes>
it is OSX specific
<emekankurumeh[m]>
did we still need those patches or was that because of the wrong flags being passed to lld?
<scientes>
emekankurumeh[m], it was because lld's Mach-O support is unmaintained
<scientes>
it is a hack that up-stream doesn't want
<emekankurumeh[m]>
FireFox317, tralamazza: it was a while ago (pre 0.4.0) and I was trying build a rom for a Gameboy Advance
<emekankurumeh[m]>
I've heard that but another linker error we had a workaround for was due to the wrong flags being passed to lld so I wasn't sure if it was the same error
<scientes>
I don't understand why zig uses the softfloat library? Can't we just call the llvm intrinsics, and then have that generate calls to the softfloat library if necessary?
<scientes>
that way comptime can be way faster
<scientes>
or rather, use the features of C.
<scientes>
oh i see, we already do that
<scientes>
softfloat is just to guarantee f128 on crappy platforms
<andrewrk>
scientes, it's for comptime f128 code
<andrewrk>
stage2 doesn't need it
<scientes>
also if I use __builtins, I guess I put in some compat so it also works with MSVC?
<andrewrk>
it could probably be dropped as a dependency once we're self hosted if self-hosted compiler doesn't do comptime f128 math
<andrewrk>
anyway the dependency is only holding perf back in stage1, the real solution is to make progress on self-hosted
<scientes>
yeah its not a big deal
<andrewrk>
stage1 perf is garbage, stage2 is going to be much much better
<andrewrk>
the assumptions and language have changed so much, the codebase is optimized for being "hackable"
<andrewrk>
self-hosted gets to be relatively stable, without too many assumptions changing out from underneath
<andrewrk>
the zig ir for self hosted will be completely different
<scientes>
yeah some of it is kinda messy
<andrewrk>
I had to introduce the concept of "suspending" and "resuming" IR analysis for result location branch. the abstractions are getting even more stressed
<andrewrk>
but with knowledge of what had to be done in stage1, stage2 can be much simpler
<scientes>
but its single threaded?
<andrewrk>
yeah still single threaded
<andrewrk>
stage2 is planned to be multithreaded
<scientes>
anyways, i'll look at the code some time
<scientes>
and that is going to stress LLVM, which really isn't ready for multi-threaded
<andrewrk>
it does in theory support it, and I have a proof of concept of it working
<andrewrk>
but I wouldn't be surprised if we triggered a few LLVM bugs
<scientes>
exactly
<scientes>
the model isn't bad though, limiting optimizations by scope
<andrewrk>
oh yeah, that's just for debug builds btw. release builds will probably still be single threaded (or at least bottlenecked by LLVM)
<scientes>
LLVM's optimizations passes declar the scope they need, so in theory they can operate just on BBs or Functions, and be multi-threaded
<scientes>
but no-one has actually used that
<andrewrk>
I wasn't planning on activating that code path
<andrewrk>
stage2 produces N object files in parallel and then links them together
<andrewrk>
zig doesn't have a stable ABI, but the compiler is obviously free to choose a temporary one for debug builds
<andrewrk>
that's the beauty of it
<scientes>
yes
<andrewrk>
and we can add padding to structs, etc, to minimize the need to rebuild stuff
<andrewrk>
it'll be a fun problem to solve. hopefully not too many bugs
<scientes>
i'm sure there will be lots, but its such exciting work that they will be bearable :)
<andrewrk>
fair :)
SamTebbs33 has quit [Quit: leaving]
wootehfoot has joined #zig
<daurnimator>
andrewrk: how goes copy ellision?
avoidr has joined #zig
Ichorio has joined #zig
<gonz_>
Are the compilation plus tests on Windows supposed to take 1+ hour?
<Sahnvour>
gonz_: could be, what tests are you running, and are you getting output ?
<gonz_>
The default ones suggested on the build instructions page
<daurnimator>
gonz_: I think we also advise -Dskip-release
<daurnimator>
which should speed things up significantly
<daurnimator>
gonz_: from CONTRIBUTING.md: One of the most helpful ones is `-Dskip-release`. Adding this option to the command in step 2 above will take the time down from around 2 hours to about 6 minutes
<andrewrk>
daurnimator: I was close to full behavior tests passing but then ran into a dead end with how inferred comptime worked for struct and array initializations inside inlined loops
<andrewrk>
So I had to solve some stuff a different way and now I'm back to 0 behavior tests passing. I think I'm close to getting back though
<scientes>
andrewrk, oh that needs to change anyways
<scientes>
it should use insertelement/insertvalue
<scientes>
and extractelement/extractvalue
<scientes>
well only for arrays
<scientes>
*only for vectors
<scientes>
you also need it to avoid a copy when reading from a directly passed argument
<scientes>
but i thnk the optimizer can handle that one
<scientes>
but you can't get a pointer to a vector
<daurnimator>
so misc operation I might need: what I'm going to call "bit expansion" => it would double up bits to get something twice as wide. e.g. 1011 => 11001111.
<daurnimator>
searching around, it looks like intel haswell+ added the PDEP instruction that makes such a thing efficient
<daurnimator>
but I'm left thinking about what to do on other architectures and older processors
<scientes>
daurnimator, that probably belongs as an LLVM intrinsic first
<scientes>
but yeah I've done a number of interesting bit hacks too
<scientes>
countPopulationUpto, ProjectBits, and NthBitOfMask
vexu has quit [Quit: WeeChat 2.5]
<daurnimator>
mikdusan: thanks. as I should have expected; it's on the famous bit twiddling page
<daurnimator>
Is there any variation of this that belongs in the standard library?
<daurnimator>
I assume that LLVM *won't* optimize it to a PDEP operation: should I just use inline assembly? I think we don't have dispatch to supported instructions in zig yet....
<daurnimator>
(i.e. ifunc support)
<scientes>
daurnimator, that is why you add a llvm intrinsic....
<daurnimator>
scientes: huh? wouldn't it be more about adding an llvm optimization pass?
<daurnimator>
but also, that doesn't help with the IFUNC side of things..... I don't really want to have "universal" vs "haswell+" binaries
<scientes>
no, you just add an intrinsic, and then add lowering for the intrinsic
<scientes>
and you then use ifunc
<scientes>
but you can even use the slick target_arch() ifunc frontend
<scientes>
although i think that is currently gcc-only
<daurnimator>
I don't know what that is.... but gcc-only doesn't sound helpful for zig.
<scientes>
llvm has ifunc support
<scientes>
its just a shortcut so you can compile the same function multiple times for multiple arches
<scientes>
and emit a ifunc stub
<scientes>
but isn't ifunc only for shared-libraries?
<scientes>
we also have to implement it ourselves (we already do that for vdso)
<andrewrk>
I'm looking forward to working on anything else
<andrewrk>
all of the elegance of this approach was lost with b025193de5b951734e5108e4762e5dc40359431b, it's all spaghetti now
<andrewrk>
working on zig stage1 compiler is like turning a treehouse into a skyscraper while living in it
<scientes>
heh
<mikdusan>
this quote is wikipedia article material :)
<scientes>
a self-hosted compiler would we woorse
<marijnfs_>
lol
<scientes>
you haven't pushed that one
<scientes>
ohyes you did
<andrewrk>
I actually ended up using a lot of the code from the abandoned copy-elision-2 branch
<scientes>
you probably should work on something else, and then try version 4 in a week
<andrewrk>
nah this is the final version
<andrewrk>
tests passing first, then can decide whether to spend time paying off technical debt
<andrewrk>
I do believe improvements can be made incrementally once *something* passes all the tests
alot has quit [Quit: WeeChat 2.5]
ross_k has joined #zig
<andrewrk>
woo ok at least the test case that I had to add the spaghetti for now is passing
<andrewrk>
you have to admit this is pretty optimal code generation: https://clbin.com/DIlr9
wootehfoot has quit [Read error: Connection reset by peer]
<andrewrk>
so if you were to step through that code with a debugger it would walk you through the inlined loop, showing you all the values, even though they're all comptime known
<scientes>
ahh yes
<andrewrk>
but the function body is empty; the debugger would just be putting on a show for you
<scientes>
that is cool
<scientes>
that is really useful however
<andrewrk>
I haven't tested it. I hope llvm/gdb are good enough that this works
<scientes>
you don't want to remove critical constants from the debug
<scientes>
i don't think it will work
<andrewrk>
I don't think there's any reason it shouldn't
<andrewrk>
testing no
<andrewrk>
*now
<andrewrk>
yeah gdb didn't know about any local variables. I think that's an issue with llvm's debug info generation, or gdb, or both
<andrewrk>
I'll bring it up on the mailing list at some point
<scientes>
gdb can't stop on anything but an instruction i believe
<andrewrk>
it should at least show a local variable though
<andrewrk>
let me try something else
<andrewrk>
damn, when I use `asm volatile ("nop");` it says `result = <optimized out>`. I think this is an llvm issue
<scientes>
as long as you are doing it right others can come around and fix it
<andrewrk>
DWARF is capable of putting constants in the debug info itself and using that for local variables which have a known value. this is what LLVM should be doing
<scientes>
the point is to have a basis that they have to make work
<andrewrk>
yeah
klltkr has joined #zig
athaudia has joined #zig
<andrewrk>
ok great all the tricky inline loop comptime tests pass now
<ross_k>
hey, having trouble building the tetris demo on zig 0.4.0 win64. `zig build play` just hangs there.
<ross_k>
was working fine on 0.3.0 - any way I can see what it's stuck on?
<scientes>
ross_k, use gdb/lldb
<andrewrk>
oh I didn't know it was working on 0.3.0
<scientes>
and hit ctrl-c
<andrewrk>
ross_k, if you look at `zig build --help` there are some options there, such as --verbose
<ross_k>
okay, I'll try that
<andrewrk>
I haven't put a lot of effort in getting tetris example working on windows - I figured I'd do it with the package manager once that's available
<andrewrk>
and that will be a lot more resilient to different systems, everything should kinda just work the same on every platform
<ross_k>
that makes sense, though I'll see if I can get it working
<ross_k>
would really like to use zig for a game project
<andrewrk>
yeah it's a good use case. package manager will help that a lot
<andrewrk>
because it's going to be able to package up C (and maybe c++) libraries in addition to zig
<andrewrk>
without any separate installation steps or requirements
<andrewrk>
so that people can actually have dependencies and feel confident that they're going to work everywhere
<andrewrk>
the javascript folks have been able to do this for years
<andrewrk>
people make fun of them, but I have no clue why, they've actually solved code reuse and actually share a lot of code with each other
<andrewrk>
seems like an obvious win to me
<Tetralux>
I'm reminded of the lpad incident. :^)
<daurnimator>
andrewrk: except that in the JS world, you're much better off if you don't do code reuse
<andrewrk>
was it really even that bad though? a bunch of people's CI servers gave an error and they had to point their dependency URL somewhere else temporarily
<daurnimator>
andrewrk: e.g. in fengari, I've had issues with *every single dependency* we originally selected. And we've had to reimplement every one.
<AlexMax>
Does Zig have a way to include binary files and make them accessible via an identifier as part of its build process?
<daurnimator>
AlexMax: what do you mean by "binary" here?
<AlexMax>
andrewrk: Perfect
<AlexMax>
I had a hard time coming up with the right words for what I was looking for
<tgschultz>
I'm personally not convinced that most code-reuse solutions don't cause more problems than they solve.
<andrewrk>
daurnimator, I don't buy that reasoning. there are plenty of incredibly useful dependencies. ffmpeg. llvm. crypto functions. image encoding/decoding. networking abstractions. data structures
<andrewrk>
in c/c++ dependencies are problematic when you depend on the system, and that's a big reason developers shy away from them
<daurnimator>
tgschultz: ehhh, I've found its significantly different on a per language basis
<daurnimator>
I tend to find that C libraries are high quality and I want to use them. Whereas e.g. JS libraries are low quality and you sort of can't
<andrewrk>
zig depends on softfloat (but vendors the code)
<daurnimator>
Maybe its a barrier to entry thing...
porky11 has quit [Quit: Leaving]
<daurnimator>
your average ruby, python and lua libraries tend to be pretty low quality too
<andrewrk>
one day I hope zig is so popular that there exist low quality libraries :)
<daurnimator>
And popular != high quality
<scientes>
andrewrk, good one
<andrewrk>
hopefully with zig code though it should be pretty easy to determine a general sense of quality by quickly skimming over the code
<andrewrk>
you see a bunch of `.?` and `catch unreachable` everywhere and back away slowly
<andrewrk>
I also foresee third party services for package discovery and curating
<ross_k>
imo a decent package manager that works seamlessly across platforms would be great, but satisfying dependencies manually should be an option too
<andrewrk>
yes there will still be a concept of "system dependencies"
<scientes>
and code coverage tools, et cetera
<daurnimator>
yeah the biggest thing I'd like to see in a language package manager is an actual usable integration with the system package manager
<ross_k>
like with nodeJS, it's common to keep hold of the node_modules folder in case the module's host goes down ie. npm
<andrewrk>
daurnimator, I think you're going to be disappointed. I'm focusing on reproducibility and determinism across platforms by default rather than integration
<daurnimator>
andrewrk: then I probably won't use the zig package manager then....
<andrewrk>
but I do consider that to be a valid use case - a dependency that is necessarily a system dependency
<andrewrk>
especially because that's what package maintainers will want to do
<andrewrk>
but it's not what the upstream developers want
<daurnimator>
If we want to make zig able to replace C, then zig libraries need to be packagable into normal distro packages
<andrewrk>
certainly
<andrewrk>
definitely planning on working with you & others on that
<andrewrk>
it's not the default though
Ichorio has quit [Ping timeout: 252 seconds]
<scientes>
yes, that is pherephery work someone else should do
tracernz has quit [Ping timeout: 252 seconds]
ross_k has quit [Quit: Page closed]
tracernz has joined #zig
avoidr has quit [Quit: leaving]
marijnfs_ has quit [Quit: WeeChat 2.3]
<scientes>
how does compiler_rt get linked in?
<scientes>
cause llvm also implicitely links against libm
hio has quit [Quit: Connection closed for inactivity]
<scientes>
we link against libc on windows, right?
<scientes>
and osx
<daurnimator>
scientes: no. windows doesn't have a libc to link to
<scientes>
then how do we make syscalls?
<scientes>
i'm just wondering if we have libm
<daurnimator>
syscalls on windows are done from ntdll; or kernel32.dll
ltriant has joined #zig
<scientes>
cause i just realized we have to ship a libm