ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
ryan_ has quit [Quit: Leaving]
dimenus has joined #zig
dimenus has quit [Ping timeout: 268 seconds]
cenomla has quit [Quit: cenomla]
dimenus has joined #zig
cenomla has joined #zig
cenomla has quit [Remote host closed the connection]
<dimenus>
andrewrk: are you planning on merging the recent commits of master into llvm6?
<andrewrk>
dimenus, if you want to, go for it
<dimenus>
i was just curious how you usually do it, as I'm still new to git
<andrewrk>
ah
<dimenus>
git fetch & manually resolve?>
<andrewrk>
here's how I would do it:
<andrewrk>
1. make sure `git status` is clean
<andrewrk>
2. git checkout llvm6
<andrewrk>
3. git fetch --all --prune --tags
<andrewrk>
4. git merge origin/llvm6
<andrewrk>
5. git merge origin/master
<andrewrk>
6. git push origin llvm6
<andrewrk>
I can push this right now if you want
<dimenus>
thanks for the tip, sure up to you
<dimenus>
i was just curious. going to work on mingw support in llvm6
<andrewrk>
pushed
<andrewrk>
cool
ryan_ has joined #zig
dimenus has quit [Ping timeout: 240 seconds]
tiehuis has joined #zig
arBmind has joined #zig
arBmind has quit [Quit: Leaving.]
arBmind has joined #zig
arBmind has quit [Client Quit]
dimenus has joined #zig
ryan_ has quit [Ping timeout: 240 seconds]
tiehuis has quit [Quit: WeeChat 1.9.1]
<dimenus>
andrewrk: did you write any of the code for the embedded_* projects or is that pulled from the llvm tree?
arBmind has joined #zig
<andrewrk>
dimenus, softfloat is not related to llvm; it's used without any patches
<andrewrk>
embedded_lld is lld 5.0.0, plus some patches
<andrewrk>
you can see the patches like this: git log -p -- deps/lld
<andrewrk>
I've gotten most of them accepted upstream, so for llvm 6 we could go back to using actual LLD
<andrewrk>
except for one
<andrewrk>
which is zig commit 1a1414fc42c7beb25b6de4134d99884ea6544b57
<andrewrk>
because it's a workaround of an LLD bug that it still not fixed, it does not solve the root cause
<dimenus>
ah ok, yeah the llvm6 branch of zig no longer builds against llvm6 master
<andrewrk>
if we were able to figure out the root cause in LLD and get the fix merged upstream, we could delete embedded_lld
<andrewrk>
dimenus, oh, in the llvm6 branch, I was using -DZIG_FORCE_EXTERNAL_LLD=on
<dimenus>
ah ok
<dimenus>
duly noted
<andrewrk>
and then I applied 1a1414fc42c7beb25b6de4134d99884ea6544b57 to the LLD I built against
<andrewrk>
it's kind of a unresolved problem. I'm hoping to get it ifxed in actual LLD before 6 is released
<dimenus>
according to the mailing list, the MachO lld is not really actively developed
<ltr_>
it seems that the lld code was made by completelly different people of the rest of the linkers
<dimenus>
the mac lld code you mean?
<ltr_>
yes
btlg has quit [Ping timeout: 240 seconds]
<andrewrk>
yes, unless the LLVM project suddenly starts caring about LLD for Mach-O, it will fall on zig project to maintain and improve the Mach-O linker
<andrewrk>
and I'm thinking, if we go that route, I'll work on self hosting the compiler so we can write it in userland. No reason to have to stick with c++ if we're the ones maintaining it
<dimenus>
i have no familiarity with mach-o, hopefully we'll get someone who uses it on a daily basis
<ltr_>
eventually zig should have their own linkers
<andrewrk>
ltr_, why's that?
<ltr_>
i know the internals of mach-o, but i do not own a mac now :D
<ltr_>
that why i understood about self hosted compiler + linker, a'la go
<ltr_>
that's what*
<dimenus>
does anyone know how to make cmake look in a different spot for llvm/clang?
<andrewrk>
dimenus, cmake/Findllvm.cmake and cmake/Findclang.cmake
<andrewrk>
you can add a hardcoded search path
<andrewrk>
dimenus, another thing that is useful is the CMAKE_PREFIX_PATH
<andrewrk>
that changes the root directory that cmake looks for libraries. that's what I usually do when messing around with different llvm builds
<dimenus>
yeah i defined cmake_path_prefix but it still found system llvm
<dimenus>
oops, prefix path I meant
<andrewrk>
you have to do it from an empty dir, you can't change it once you do it once, because cmake doesn't work perfectly
<ltr_>
andrewrk: everything that can be computed at compile time, is going be resolved at compile time? or one have to explicity state that you want a chunk of code to be comptime
<andrewrk>
you might have to write some functions that return types, to call in the function prototype
tankfeeder has left #zig [#zig]
<ltr_>
first im going to try to do it in someway then ill try to do it elegantly
<andrewrk>
don't forget to still validate the input parameters
<ltr_>
i guess im going to do it in the parser at compile time, i mean im going to generate an specific parser at compile time just for that string, so if it fails its going to try another pattern in the chain
<dimenus>
andrewrk: what do you use to debug c/c++ on linux?
<dimenus>
or do you just use raw gdb :)
<ltr_>
have you seen the herb sutter presentation that he gave at cppcon2017?
<ltr_>
if i want to print to stdout ill need to write to FD = 0?
<ltr_>
pub fn getStdOut() -> %File
<ltr_>
just saw that
<ltr_>
oh now i get the new api
<ltr_>
thanks
<andrewrk>
yes and then you can use file.write. Or you can create a FileOutStream and use the OutStream API (which has nice things like formatted print). And if you want to take it a step further you can put that out_stream in a BufferedOutStream and use the same API but now it's buffered
<ltr_>
thats a lot of changes in the documentation
<ltr_>
jeje
<ltr_>
hehe*
<andrewrk>
ltr_, yeah, I'm working on that now - making the documentation be tested
<andrewrk>
so we can't accidentally break it with compiler changes