ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<MajorLag>
I usually call `zig build-exe` directly, unless the build is more complicated for some reason, then I just use a cmd script for now.
<andrewrk>
and you run that from cmd.exe?
<MajorLag>
yeah
<andrewrk>
cool. just making sure that you'll see the new stack traces
<MajorLag>
I'm looking forward to doing a lot less debug.warn debugging.
<MajorLag>
Sad news, it looks like my inline copy eliding trick doesn't always work under release-fast optimizations. Most of the time it does, but I've run into a case where it doesn't.
<andrewrk>
there's a really important language design issue to address this that I've been putting off for a long time
<scientes>
the clang code that set that attribute is ~1000 lines long
<scientes>
so i'm sifting through it
<kristate>
yeah, I read the mailing list item earlier -- where is the code?
<scientes>
ir_render_call in src/codegen.cpp, and ZigLLVMBuildCall in src/zig-llvm.cpp
<scientes>
but it is complicated as we are no using llvm::CallSite, but llvm::CallInst directly
<scientes>
nor are we using llvm::Argument
<scientes>
the code in clang that does the same thing is in lib/CodeGen/CGCall.cpp, but it is quite long
<andrewrk>
scientes, if we have to do we can use the c++ api and wrap it. that's what zig_llvm.h / zig_llvm.cpp is for
<kristate>
let me read-up on lib/CodeGen/CGCall.cpp
jjido has quit [Ping timeout: 272 seconds]
<kristate>
andrewrk: morning
<andrewrk>
I'm stepping through some llvm code in a debugger, and it seems that nearly every line I thought was doing something simple is actually an overloaded operator D:
<andrewrk>
morning
<scientes>
kristate, CodeGenFunction::EmitCall and CodeGenModule::ConstructAttributeList
<scientes>
andrewrk, its just going to be quite intrusive to change ZigLLVMBuildCall, but it will give us access to sret, byval, inreg, returned, and inalloca
<kristate>
inalloca...
<andrewrk>
scientes, sounds worth it
<andrewrk>
are you just trying to add sret at the callsite though? I think we have code that demonstrates doing something like that already
<scientes>
it can't add argument attributes, only call attributes (like async)
<scientes>
maybe...
<andrewrk>
hmm maybe not, yeah
<ltr_>
hello everyone
<andrewrk>
why wouldn't it automatically add matching attributes as the definition?
<andrewrk>
hi ltr_
<ltr_>
andrewrk: just in case, do you have a clean *.nix file to work with llvm clang libc++ 6?
<ltr_>
or at least libstdcxx (>c++11) , my clang refuse to find the std include files
<ltr_>
=/
<scientes>
<andrewrk> why wouldn't it automatically add matching attributes as the definition?
<andrewrk>
ltr_, hmm my nix file for building llvm does not have any libc++ workaround in it
<ltr_>
oh
<andrewrk>
ltr_, oh I have a similar problem to that sometimes
davr0s has joined #zig
<andrewrk>
I haven't figured out why it happens, but I use the default compiler (gcc) to build zig
<andrewrk>
and llvm
<andrewrk>
scientes, when I originally wrote this code, I assumed that LLVMBuildCall would choose matching attributes as the function definition. so looks like that bad assumption is the cause of the bug
<scientes>
yes
<kristate>
hmmmm
<scientes>
what I don't understand in the clang code is how it is handled when differn't argument have difffern't attributes, it looks like there is only one AttributeList
<scientes>
(even though this doesn't apply to sret)
kristate has quit [Remote host closed the connection]
<MajorLag>
here's another issue with typeInfo: enum value is represented as a usize, but enum(u128) is valid.
<andrewrk>
yep. gotta fix that
<MajorLag>
is there a maximum int size? I recall LLVM crashing on some things I tried.
<andrewrk>
using ints for loading, storing, and bit manipulation I think works for any size
<andrewrk>
math operations such as addition and multiplication, llvm will crash because it only knows how to do lib calls for compiler-rt functions. but I'm going to propose a patch to llvm that will let it generate lib calls for arbitrary sized integers
<andrewrk>
it would be a non-standard thing
<andrewrk>
(but arguably should be a standard)
<andrewrk>
128 should be safe in status quo land
<andrewrk>
for all operations
<andrewrk>
according to zig, all integer sizes are valid for all operations, and it's a bug that we can't handle operations for really big ints
<andrewrk>
if we have to fork llvm, then we fork llvm.
kristate has quit [Remote host closed the connection]
kristate has joined #zig
<scientes>
good night
kristate has quit [Ping timeout: 250 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
mnoronha has joined #zig
mnoronha has quit [Ping timeout: 246 seconds]
<unique_id>
Back to Zig baby. Yeahhhhh switching languages is WHAT I DO! You might think I'm mentally unstable, I assure you I am not.
<andrewrk>
lol unique_id welcome back
<unique_id>
Thank you, thank you :)
<scientes>
hi
<andrewrk>
unique_id, i'm sorry that zig is not further along in maturity, that would probably make it easier to stay
<andrewrk>
on the plus side we're about to get windows stack traces
<andrewrk>
are you on windows?
<unique_id>
No, but I'm glad nontheless :)
<scientes>
also alot of stuff is working on arm64
<scientes>
linux/arm64
<andrewrk>
nice! I'm excited to look at your patches soon
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
kristate has joined #zig
kristate has quit [Ping timeout: 260 seconds]
wink_ has joined #zig
<c15ade4>
unique_id: the search for the perfect language is a long and difficult one
<c15ade4>
the more you try, the more you things you find to hate about each
<c15ade4>
and each feature with a productivity gain, is a lost again by either language immaturity, or because you are not a newbie again
<c15ade4>
are**
<c15ade4>
enjoy :P
<scientes>
* Favor reading code over writing code.
<c15ade4>
I don't see why you couldn't have both - terse mode for writing, easy mode for reading :P
<unique_id>
well looking at the Zig code that I've written, I'm definitely liking it a lot. I see that I had started working on a template engine for my website, something I remember now but I had forgotten about. Switching languages too often is super confusing.
<unique_id>
my workspace is an absolute mess
<scientes>
unique_id, i just got a 3rd monitor
<unique_id>
I meant my workspace folder though :)
<unique_id>
scientes: what size?
<scientes>
they area all cheap, 1920x1080, the others are 1680x1050 and 1440x900
<unique_id>
I had a 4K monitor. I noticed no difference other than the smaller font before scaling. However, once I moved from 4K to 1080p it was nightmarish for a while. You really notice the pixels!
<scientes>
i heard that 4k support was bad, so i got a 4k tv instead
<unique_id>
But it's a fairly large 1080p monitor, so the effect wouldn't be as noticable on a smaller one
<unique_id>
yeah, 4k on Linux at least was not fun for a long time
<unique_id>
My 4K monitor would once every few months emit an extremely loud sound that sounded like some kind of siren. Apperantly it's something the manufacturer uses to test the monitor? I don't know. But it was surpsingly frightening every time it happened.
noonien has quit [Quit: Connection closed for inactivity]
<unique_id>
C++ code would be better if deep copies (copy constructor) was an explicit op like in Rust. I don't really care that I can't see if a destructor is run or not because that's not actionable info, what is actionable is knowing whether or not you are doing stupid copies!
<unique_id>
So defer or RAII with explicit .clone() and destructive moves are both good. Both have their strengths and weaknesses, with defer definitely winning over in the simplicity department IMO. RAII no matter how good will make you fight with it in edge cases. Defer is better for games, OS dev, etc. RAII competes better in less serious applications IMO. Just a random thought.
<andrewrk>
unique_id, I think I generally agree with you