ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
_dev_zero has quit [Remote host closed the connection]
_dev_zero has joined #zig
_dev_zero has quit [Remote host closed the connection]
_dev_zero has joined #zig
Maxxii has joined #zig
cenomla has quit [Quit: cenomla]
dimenus has joined #zig
_dev_zero has quit [Remote host closed the connection]
<GitHub158>
zig/master 4f8c26d Andrew Kelley: fix enum sizes too large...
<dimenus>
andrewrk: do you have a minute to talk about #538?
<andrewrk>
yes
<dimenus>
i'm a little confused by what you mean with the msvc compiler driver
<dimenus>
msvc doesn't expose an interface to use c1.dll / etc
<andrewrk>
dimenus, right, so one of the features of zig is the build system. build.zig and such. and one of the use cases we want to support, is using zig instead of e.g. cmake to build cross platform projects
<andrewrk>
even if that project is written in C, and not zig
<dimenus>
ok, that sounds good. do you plan on utilizing msvc to compile this code then
<dimenus>
rather than llvm?
<dimenus>
in this particular test
<dimenus>
(still not getting a stack trace in llvm6)
<dimenus>
looks like its hitting the panic in debug.zig
<andrewrk>
yes, zig build's addCLibrary/addCExecutable is supposed to use msvc on windows
<ltr_>
hey andrewrk i have noticed that you like sound, hehe is there a good read on the subject of generating sounds+formats+filters+synths+code, i dont know the jargon so i dont know what to look for
<andrewrk>
I don't know of a good introductory reading, but maybe a DSP course on coursera
<ltr_>
how for example impulse tracker , i love that piece of software, ill like to know how it works
<ltr_>
after lunch ill file the issue
<ltr_>
ill look into that course
<andrewrk>
it's really difficult. I have tried to take it multiple times and have not gotten past lesson 2-3ish
<andrewrk>
I think I need more discipline
<ltr_>
i just want to play with samples generate synths notes with code
<GitHub62>
zig/master 52521d5 Jeff Fowler: fix typo on darwin lseek (#602)
<dimenus>
andrewrk: for 538, the existing compiler code doesn't produce a valid import lib with exports for MSVC to digest
<dimenus>
if you can see the difference if you objdump an import lib created with mingw-clang vs zig
<dimenus>
or if you're using msvc, dumpbin
<andrewrk>
dimenus, I think there is some misunderstanding because #538 has to do with using msvc's binaries - cl.exe and link.exe - and not using LLVM/clang/LLD
<andrewrk>
538 has nothing to do with zig creating import libs
<dimenus>
we invoke lld-link to create the dll first and then cl to compile the full executable
<dimenus>
no?
<andrewrk>
no, for 538, we only use zig to run build.zig, and we just act as the build system for msvc tools
<andrewrk>
llvm/clang/lld don't enter into the picture, except to run build.zig
<dimenus>
passing --verbose-link to that build emits an LLD call though
<ltr_>
thats the output of the parsec on #include <uv.h>
<andrewrk>
ltr_, yeah, and you can see how it incorrectly generates `pub const uv_connect_t = struct_uv_connect_s;` twice
<jfo>
andrewrk: that leads me to some more ish, let me see if I can unravel it I'll brb ty
<andrewrk>
ltr_, it's a bug in parsec.cpp
<ltr_>
i can look into it
<andrewrk>
great
<ltr_>
i really want to deploy a microservice in production here in zig lol
<jfo>
andrewrk: oh wait! got it.
<jfo>
pr coming
<andrewrk>
ltr_, sounds like we need concurrency and networking :)
<andrewrk>
ltr_, oh, or libuv like you're doing :)
<jfo>
++ concurrency and networking :)
<andrewrk>
jfo, I'm going to be working on those things very soon
<jfo>
i i know just throwing in my ++ !
<jfo>
:)
<ltr_>
exactly
<ltr_>
here in my job they are spending a lot of money in AWS cos of bloated crap like spring boot to do simple selects and transform em to json, 150mb just to start the vm.
<ltr_>
it is just too painful to watch
<andrewrk>
ltr_, if you get something working and your company likes it, see if they want to do a sponsorship with a banner on ziglang.org
<GitHub192>
[zig] jfo opened pull request #605: Fix Stat include in darwin land (master...pr) https://git.io/vFgOl
<jfo>
looks like the only discrepency is `st_birthtimespec: struct_timespec`
<andrewrk>
jfo, rdev: u64 is wrong
<andrewrk>
let me double check it on my mac
<jfo>
:+1:
<jfo>
bbiab dinner time.
<andrewrk>
jfo, I have the same output as you. so I translated the struct incorrectly. so we can use the values for the struct that you obtained just now
<andrewrk>
ltr_, it seems to matter whether you use -> or . correctly
<andrewrk>
ltr_, oh, did you compile clang in debug mode?
<ltr_>
i think not
<andrewrk>
you'll probably have to do that if you want to use gdb usefully
<ltr_>
Cannot resolve function decl_name to any overloaded instance
<ltr_>
ok it passes twice for some reason on typedefs
<dimenus>
andrewrk: so I've broken 538 (the dll creation part) into a minimally reproducible example
<dimenus>
and if i do build-lib on mathtest.zig it produces no exported symbols
<dimenus>
I found the LLVM function to specify the DLLStorageClass but when I add it, it's now exporting a lot of other symbols as well that I wouldn't expect to exist
<dimenus>
ex, w/ clang if i have a math.c file with just add(int x, int y) in it, it produces a dll with one function
<dimenus>
where as zig adds mempy, memset, floor, fmod and a lot of others
<andrewrk>
this is expected
<dimenus>
should i just file a new issue?
<andrewrk>
what's going on is that clang is expecting to link with libc, which provides all these functions
<andrewrk>
llvm generates calls to these functions
<dimenus>
shouldn't we assume if we're creating a dll that we shouldn't explicitly export other symbols that we're not using
<andrewrk>
dimenus, when we build a zig executable or library that does not depend on libc, first we build 2 things: compiler-rt.o and builtin.o. then we produce yourliborexe.o and link them all together
<andrewrk>
we always must have compiler-rt.o and builtin.o. unless we link with libc, which has all the symbols.
<dimenus>
but now the calling application can't link with libc
<dimenus>
because we've duplicately defined symbols
<andrewrk>
it can, the symbols are private to the library
<dimenus>
hmm, then I need to find another flag
jfo has joined #zig
<andrewrk>
I know it is possible. worst case scenario, we have to submit a patch to llvm to rename the symbol dependencies it generates, to add a namespace to them. But that should not be necessary
<dimenus>
is there a flag on a given function decl if it's 'export' in zig?
<andrewrk>
yes, it's the `export` keyword
<dimenus>
sorry, not the zig keyword
<dimenus>
context has an 'export_visib_mod' enum attached to it
<dimenus>
if i knew that a given function was export, I can fix this example
<andrewrk>
oh, FnTableEntry::linkage
<andrewrk>
anything other than GlobalLinkageIdInternal means that the symbol is exported in the .o file
<dimenus>
i used that originally, which was what caused the duplicately defined symbol issue
<dimenus>
running another test now
<andrewrk>
ideally we would end up with a .dll that did not expose stuff from builtin.o and compiler-rt.o
<dimenus>
yep, just exposing add in this case
<ltr_>
this is weird, the debugger stops at parsec.cpp:2580 if strcmp((*typename)->list.items, "uv_connect_t") == 0 but if i continue to line 2610, but never reach 2611
<andrewrk>
ltr_, in my experience, it's not helpful to use gdb unless everything is compiled in debug mode
<ltr_>
damn
<ltr_>
its weird cos the second time it reaches that line
<dimenus>
clang only generates IR for the add function where as we output almost 2400 lines
<andrewrk>
which one do you think is not necessary?
<dimenus>
in this situation, everything except add
<andrewrk>
I can explain everything
<andrewrk>
the implementation of add, when llvm codegens, emits function calls to builtin.o and compiler-rt.o. so we must have these. Notice that they are separate compile units they can be cached.
<andrewrk>
we also generate code for panic. if we never call panic, all this code gets deleted when you do --release-fast or --release-safe
<andrewrk>
or if the user provides their own panic implementation
<andrewrk>
at the end of the day, when compiled with --release-fast, our DLL will be as slim as clang's
<andrewrk>
and clang's depends on libc, otherwise they would have the same problem as us
cenomla has joined #zig
<jfo>
andrewrk: oh yeah of course. 1 sec
<andrewrk>
dimenus, if you use `zig build-obj` you can see it only generate code for the add fn
<andrewrk>
then the only thing is the panic implementation, and you can make it generate less code by adding one like this: `pub fn panic(msg: []const u8) -> noreturn { while (true) {} }`
<dimenus>
sorry, I'm not getting that behavior
<dimenus>
if i call build-obj mathtest.zig --emit llvm-ir
<dimenus>
i get 144k worth of IR
<andrewrk>
I haven't tried --emit llvm-ir yet. tiehuis added that. try this