ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
return0e has joined #zig
return0e has quit [Ping timeout: 252 seconds]
return0e has joined #zig
return0e has quit [Remote host closed the connection]
return0e has joined #zig
andrewrk has quit [*.net *.split]
return0e has quit [Remote host closed the connection]
Guest54253 has joined #zig
return0e has joined #zig
return0e has quit [Ping timeout: 260 seconds]
beetcoin has quit [Ping timeout: 272 seconds]
beetcoin has joined #zig
beetcoin has quit [Ping timeout: 245 seconds]
beetcoin has joined #zig
beetcoin has quit [Ping timeout: 260 seconds]
beetcoin has joined #zig
mnoronha has joined #zig
noonien has quit [Quit: Connection closed for inactivity]
qazo has joined #zig
qazo has quit [Ping timeout: 240 seconds]
qazo has joined #zig
Guest54253 is now known as andrewrk
qazo has quit [Ping timeout: 252 seconds]
nornagon has joined #zig
<nornagon>
i'm trying to build zig from source on macOS, and I'm getting an error when installing llvm@7 with brew
<nornagon>
Error: No available formula with the name "llvm@7"
<nornagon>
is there a tap I'm missing, perhaps?
<nornagon>
aha, fixed it with `brew upgrade --devel llvm`
<andrewrk>
nornagon, oh interesting! did that have to build it from source?
<nornagon>
yep, brew is currently building llvm locally
<nornagon>
shall i PR an update to README.md?
<nornagon>
(it might make sense to use a git submodule and always build llvm from source, that way you can isolate the zig build from whatever llvm might be on the system)
<andrewrk>
nornagon, what happened is that, just today, we upgraded from depending on llvm 6 to the llvm 7 that just released
<nornagon>
ah, so the llvm@7 instructions will work fine in a couple of days
<andrewrk>
yes
<nornagon>
so much for an easy first PR then :P
<andrewrk>
nornagon, apologies, you joined in a tricky window
<nornagon>
it's no problem, i upgrade electron's chromium dependency for my day job
<nornagon>
i eat C++ compiler errors for breakfast
<nornagon>
also hi! i just watched your recurse center talk from a little while back :)
<nornagon>
interested in experimenting with zig, no real goals yet
<andrewrk>
nornagon, nice to meet you. I look forward to seeing the code that you write
<andrewrk>
feel free to ask for code review or paste a link to show a demo
mnoronha has quit [Ping timeout: 252 seconds]
return0e has joined #zig
reductum has joined #zig
return0e has quit [Remote host closed the connection]
return0e has joined #zig
reductum has quit [Quit: WeeChat 2.2]
qazo has joined #zig
qazo has quit [Ping timeout: 252 seconds]
reductum has joined #zig
darithorn has quit [Quit: WeeChat 2.2]
qazo has joined #zig
very-mediocre has joined #zig
reductum has quit [Quit: WeeChat 2.2]
kristate has joined #zig
kristate was banned on #zig by ChanServ [*!*@221x242x19x3.ap221.ftth.ucom.ne.jp]
kristate was kicked from #zig by ChanServ [Banned: I would like you to take a break from Zig for a week, and then come back when you're ready to interact in an ho]
very-mediocre has quit [Ping timeout: 256 seconds]
tankf33der has joined #zig
unique_id has quit [Remote host closed the connection]
kristate has joined #zig
kristate was kicked from #zig by ChanServ [Banned: I would like you to take a break from Zig for a week, and then come back when you're ready to interact in an ho]
porky11 has joined #zig
kristate has joined #zig
kristate was banned on #zig by ChanServ [*!*@2400:2200:e2:32c8:6cce:77e1:1fbe:cb12]
kristate was kicked from #zig by ChanServ [Banned: I would like you to take a break from Zig for a week, and then come back when you're ready to interact in an ho]
kristate_ has joined #zig
kristate_ was kicked from #zig by ChanServ [Banned: I would like you to take a break from Zig for a week, and then come back when you're ready to interact in an ho]
kristate has joined #zig
kristate was kicked from #zig by ChanServ [Banned: I would like you to take a break from Zig for a week, and then come back when you're ready to interact in an ho]
j`ey has quit [Remote host closed the connection]
noonien has joined #zig
kristate_ has joined #zig
kristate_ was kicked from #zig by ChanServ [Banned: I would like you to take a break from Zig for a week, and then come back when you're ready to interact in an ho]
unique_id has joined #zig
<unique_id>
std.os.File's read marks EINVAL as unreachable, which I guess is because EINVAL is a logic error that you're just supposed to fix. However, it might be something that needs to be handled when O_DIRECT is used. From postgresql channel: https://pastebin.com/raw/MtkhzNw4
mnoronha has joined #zig
kristate has joined #zig
kristate was kicked from #zig by ChanServ [Banned: I would like you to take a break from Zig for a week, and then come back when you're ready to interact in an ho]
<unique_id>
Don't worry though, I'm only using O_DIRECT for my website's key value store. Not the game ! This API is way too awful for shipping software with it.
<unique_id>
(the linux API)
<scientes>
unique_id, O_DIRECT is a linux-specific API, so you should use std.os.linux.read() directly
<scientes>
unique_id, and there is no way to open a file with O_DIRECT using the generic interfaces anyways
<unique_id>
file.openHandle(fd)
<unique_id>
File*
very-mediocre has joined #zig
<scientes>
yeah, but you are using a raw std.os.linux.open() call
<scientes>
(or something in C)
<unique_id>
doesn't matter, openHandle + read is broken on linux
tankf33der has left #zig [#zig]
<scientes>
yeah i was thinking about it, and maybe we should add an "unreachable" value
<unique_id>
what? Currently it's switch(...) EINVAL => unreachable, which is the problemo
<scientes>
that way only the value is undefined, instead of the whole program
<scientes>
like you could get EFAULT if you do a ptrcast, there is all sorts of undefined behavior in program, I don't think zig should be expected to fill every one of them.
<scientes>
but it could handle the situation more gracefully
<scientes>
that's my personal opinion
<unique_id>
EINVAL can be returned from read, no way around that. A program could make sure the file is a certain size before it reads to avoid the EINVAL, but that's a race condition.
<scientes>
so, if the file isn't opened with O_DIRECT then read will just return a short read. Oh, what about when at the very end of the file.....
<unique_id>
but no, I can understand not wanting to dirty a cross platform interface with something linux+O_DIRECT specific.
<scientes>
anyways I have to go to work.
<unique_id>
but, then it probably shouldn't have openHandle(fd) if it's not going to handle the errors
<andrewrk>
what's this about read returning EINVAL? do we have an incorrect `unreachable`?
<andrewrk>
here's what I see in `man 2 read`: fd is attached to an object which is unsuitable for reading; or the file was opened with the O_DIRECT flag, and either the address specified in buf, the value specified in count, or the file offset is not suitably aligned.
<andrewrk>
or: fd was created via a call to timerfd_create(2) and the wrong size buffer was given to read(); see timerfd_create(2) for further information.
<andrewrk>
my logic is that proper programs will prevent the possibility of these things from happening at compile time, and so the std lib asserts if it gets this error code
<andrewrk>
a better way to phrase it is that it asserts it will not get this error code
<andrewrk>
my reasoning is that e.g. error.Invalid does not make sense in this case. the programmer should be able to guarantee they are using the read api correctly, and in exchange the error set has one less possibility in it
<unique_id>
andrewrk: It's not possible to prevent EINVAL at compile time when using O_DIRECT because EINVAL being returned depends on the file being read. https://pastebin.com/raw/MtkhzNw4
<unique_id>
It was a big surprise to me
<andrewrk>
oh, well if the API is bad, that's different
<andrewrk>
unique_id, so when you get EINVAL in this case, you don't actually end up reading the bytes right?
<andrewrk>
can't you detect that the count value is not suitably aligned before you call read?
<andrewrk>
also #musl is a great place for questions like this
<andrewrk>
by all means ask them here, but I often go to #musl for questions like these because they're knowledgable and friendly
<unique_id>
andrewrk: The count value can be perfect, you'll still get an EINVAL if the file size is wrong.
<andrewrk>
and then what do you do if you get EINVAL?
<unique_id>
The program would abort or something, having detected that its file has been messed with
<andrewrk>
I see
<unique_id>
Maybe the program could lock the file or something to make sure it controls the size of the file, and then it can use read correctly without getting EINVAL
<andrewrk>
I guess the bottom line is, are you willing or not willing to accept undefined behavior if something messes with the file behind your programs back
<MajorLag>
unique_id, andrewrk: `const buffer: [1]u8 = []u8{8}; const sliceA: []u8 = &buffer;` is this really valid? It reads to me as 'assign sliceA as a pointer to the slice called buffer', which is to say not the data buffer points to, but the slice data structure?
<andrewrk>
and if not willing (perfectly reasonable) then my recommendation for now would be to side-step some of the cross platform abstractions in std (even std.os.posixRead), calling std.os.linux.read directly and dealing with the errno codes yourself
<andrewrk>
I think for most stuff though we want the unreachable on EINVAL
<andrewrk>
if we were going to handle O_DIRECT, we'd probably have something like std.os.posixReadDirect and it would simply handle the error codes differently
<andrewrk>
certainly openHandle should be documented that the fd cannot be O_DIRECT
<andrewrk>
MajorLag, without running it through the compiler, it looks like it should be error: mutable slice to constant data
<andrewrk>
how it works is that the `const` on buffer applies directly to the bytes of the array, since it's not a pointer, it's actual data right there. so those bytes are constant
<MajorLag>
oh wait, I'm just not reading it correctly. buffer is an array, not a slice.
<andrewrk>
yeah. I think it is a little too subtle syntactically array vs slice
<andrewrk>
semantically I think it works fine
<andrewrk>
but array vs slice are a lot different but they look very similar
<MajorLag>
but *[N]T => []T is implicit? I wasn't aware of that, but it makes sense.
<andrewrk>
yeah, that came with pointer reform
<MajorLag>
someone proposed an alternative array syntax I think, but nobody was really thrilled about it. It shouldn't be a problem as long as I pay better attention.
<unique_id>
andrewrk: This was the right channel, I was reporting an issue not asking for help.
<andrewrk>
unique_id, my apologies, I just woke up, everything makes sense now.
<MajorLag>
I wonder if 1565 has the same cause as 1076?
<andrewrk>
MajorLag, I'm in the middle of fixing #1076. it's not as bad as I thought. it's just a problem with string literal caching
<andrewrk>
so I think they're different, since 1565 has no string literals
<unique_id>
andrewrk: I don't know if you get notified on these, but I added a comment to my most recent bug report. It's interesting :)
<andrewrk>
don't worry, I get an email notification for every comment in the entire ziglang org
<andrewrk>
yeah this is really strange. I'm going to look at this as soon as I finish up 1076
unique_id has left #zig ["Konversation terminated!"]
<andrewrk>
just had a bug in c++ because I accidentally named a local variable the same as a parameter
<andrewrk>
I got used to that not happening because of zig coding
qazo has quit [Ping timeout: 252 seconds]
<andrewrk>
1076 is fixed
mnoronha has quit [Ping timeout: 252 seconds]
return0e has quit [Remote host closed the connection]
mnoronha has joined #zig
mnoronha has quit [Ping timeout: 240 seconds]
qazo has joined #zig
darithorn has joined #zig
darithorn has quit [Read error: Connection reset by peer]
<andrewrk>
I'm pretty sure everything I'll talk about and demo is already in the docs, so if you don't watch it you won't miss much
<wink_>
I'm trying to build the lastest zig with llvm 7.0.0 and I'm getting a compile error from translate_c.cpp:18 where it includes <clang/Frontend/ASTUnit.h>
<wink_>
The error is: SmallVector.h:313:11 error: "void* memcpy(void*, const void*, size_t)" writing to an object type "struct std::pair<void*, long unsigned int>" with no trivial copy-assignment; ...
<wink_>
I'm on Arch Linux and I compiled llvm 7.0.0 from sources using gcc. Should I use clang?
noonien has quit [Quit: Connection closed for inactivity]
cgag has joined #zig
cgag has quit [Client Quit]
mnoronha has quit [Ping timeout: 252 seconds]
unique_id has joined #zig
darithorn has joined #zig
<unique_id>
wink_: I believe that you also have to compile clang before you compile zig. That's what I did.
<unique_id>
I mean, from that I got the newest clang headers which you need
<unique_id>
compile everything with the same compiler
<wink_>
unique_id: I did but obviously did something wrong :)
darithorn has quit [Quit: WeeChat 2.2]
jfo has quit [Ping timeout: 272 seconds]
<wink_>
So I recompiled with clang and it compiled, but now I've got a linker error:
<wink_>
home/wink/prgs/ziglang/zig/build/../deps/lld/ELF/InputFiles.cpp:138: undefined reference to `llvm::DWARFContext::getLineTableForUnit(llvm::DWARFUnit*, std::function<void (llvm::Error)>)'
cgag has joined #zig
<cgag>
getting a billion undefined reference errors while building llvm 7 during "Linking CXX shared library ../../lib/libLTO.so", anyone dealt with this or anything similar while building llvm?
mnoronha has joined #zig
Ichorio has quit [Ping timeout: 252 seconds]
return0e has quit [Remote host closed the connection]
cgag has quit [Quit: WeeChat 2.2]
mnoronha has quit [Ping timeout: 252 seconds]
cgag has joined #zig
<andrewrk>
if you're on linux and having trouble building from source you can use the binary static builds while waiting for your distro to catch up
<cgag>
missed any previous messages but once i switched to using ninja nad building in release mode it worked, definitely ran out of ram linking when not building in release mode, don't know if ninja was a factor at all
mnoronha has joined #zig
<andrewrk>
I 100% recommend building clang and llvm in release mode
<andrewrk>
zig is unusable for general use if llvm/clang are in debug mode
porky11 has quit [Quit: Leaving]
cgag has quit [Read error: Connection reset by peer]