ChanServ changed the topic of #zig to: zig programming language | https://ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
dewf has joined #zig
kristate has joined #zig
<andrewrk> results at the end of the stream: https://i.imgur.com/KufxrKm.png
mikdusan has joined #zig
<mikdusan> re: gpda stream; maybe note mprotect'd allocator state is dubious in a multithreaded process?
<andrewrk> tgschultz, I think the closest thing to that zig supports (after llvm8 branch merge) is wasm
<andrewrk> mikdusan, good point, yes the next thing on the roadmap is to decide if it's going to be thread safe or not
Avila has quit [Quit: Leaving]
<MajorLag> andrewrk, zig supporting it today wouldn't be a requirement.
<MajorLag> that debug allocator is going to be sweet
dewf has quit [Quit: Leaving]
kristate has quit [Ping timeout: 250 seconds]
scientes has quit [Ping timeout: 268 seconds]
darithorn has joined #zig
darithorn has quit [Remote host closed the connection]
Zaab1t has joined #zig
kristate has joined #zig
kristate has quit [Remote host closed the connection]
Zaab1t has quit [Quit: bye bye friends]
fsateler has joined #zig
fsateler_ has quit [Ping timeout: 246 seconds]
mikdusan has quit [Ping timeout: 256 seconds]
THFKA4 has quit [Ping timeout: 264 seconds]
_whitelogger has joined #zig
adrusi has quit [Quit: ZNC 1.7.2 - https://znc.in]
allan0 has joined #zig
adrusi has joined #zig
marmotini_ has joined #zig
kristate has joined #zig
noonien has joined #zig
marmotini_ has quit [Remote host closed the connection]
Akuli has joined #zig
halosghost has joined #zig
<andrewrk> damn, the is_packed=true test of std.io.Serializer/Deserializer is tripping an assertion in a debug build of llvm 8.0.0rc3
<andrewrk> reported upstream. I hope they just fix it and call it a day
<tgschultz> how does that work? Wouldn't that have been compiled out by then? By which I mean the packed/not packed versions of the function would have been separated out?
<andrewrk> llvm does have the concept of a packed struct - it means no alignment padding
<andrewrk> if you're curious: https://bugs.llvm.org/show_bug.cgi?id=40919
<tgschultz> Oh ok, if I read this correctly, it doesn't have to do with the test per-se, but with type bitwidth information in general.
<andrewrk> it has to do with an optimization that LLVM is doing in release-safe mode, it had an invalid assumption
<andrewrk> it's either zig emitting an invalid LLVM IR file, and the llvm bug is that the verifier didn't catch the problem, or it's a legitimate bug in one of llvm's optimization passes that made an incorrect assumption about integer widths
<andrewrk> damn, it's an issue in llvm 7 too. so we just have been tripping this assertion for some time now and didn't know it because we usually use release builds of llvm
<andrewrk> I'm going to open an issue and disable the failing tests and comment a link to the issue
kristate has quit [Remote host closed the connection]
darithorn has joined #zig
Ichorio has joined #zig
<daurnimator> andrewrk: I caught up on your stream. One thing I kept noticing was that you had workarounds due to `align` being unavailable for the usize and isize used with e.g. mprotect
<daurnimator> andrewrk: possible ideas: 1. add a 'pointer to unknown' type that allows pointer attributes. other pointers can implicitly cast to the unknown pointer type with matching align/etc. 2. allow `align` to be used on non-pointer types
<andrewrk> I'm not sure what you're referring to
<daurnimator> andrewrk: e.g. the mprotect address argument.
<andrewrk> pointer to opaque is pointer to unknown
<andrewrk> oh that's a good point, the addr argument can be *align(page_size) @OpaqueType()
<andrewrk> the length still has to be checked the same way though
<daurnimator> yep. but the address doesn't :)
<andrewrk> no language changes needed, just an API change
<daurnimator> okay. I didn't think you could use an opaque type there, as a user wouldn't be able to pass an arbitrary pointer?
<andrewrk> ah right you would need a reference to the type for the first arg of @ptrCast or @intToPtr
<andrewrk> `[*]align(page_size) u8` is probably fine
<andrewrk> the second argument could be an aligned end pointer rather than a length
<andrewrk> it shouldn't make a difference in optimized builds; a function that small is probably getting inlined, and then the addition/subtraction would cancel out
<andrewrk> nope that's a bad idea. consider the last page of memory
<daurnimator> andrewrk: `2` above would also work for length. e.g. if you could have `fn foo(bar: align(page_size) usize)` which would essentially add an assert that the last X bits are 0?
<daurnimator> if that was more general it could also lead to interesting memory optimizations: `struct {a:align(4096) u64, b:u12}` // this struct can fit in 8 bytes!
<andrewrk> I haven't ruled out yet an enum type that supports ranges
<andrewrk> example: enum(u8) { SpecialCaseA = 0, SpecialCaseB = 255, Normal = 1...254 }
Avila has joined #zig
fsateler has quit [Read error: Connection reset by peer]
fsateler has joined #zig
dewf has joined #zig
Ichorio has quit [Read error: Connection reset by peer]
Ichorio has joined #zig
<Akuli> if there isn't an idiomatic way to do this in zig yet, maybe consider that too: https://github.com/Akuli/curses-klondike/blob/master/src/klon.h#L19-L32
Ichorio_ has joined #zig
<Akuli> i could have done: enum KlonCardPlace { STOCK, DISCARD, FOUNDATION0, ..., FOUNDATION3, TABLEAU0, ..., TABLEAU6 }; but how do i access the enum value for the n'th tableau or foundation easily then
<andrewrk> Akuli, yep this is the use case for the thing above
<andrewrk> the _NUM macros would be @enumToInt
<andrewrk> KLON_FOUNDATION and KLON_TABLEAU would be @intToEnum
<Akuli> how would i put foundation enums, tableau enums, STOCK and DISCARD all in the same enum though?
<andrewrk> and then val == KlonCardPlace.FOUNDATION would do a range check
Ichorio has quit [Ping timeout: 258 seconds]
<Akuli> hmm
<andrewrk> with the syntax above
<Akuli> i'm not sure if that's a bit too magical for ==, but anyway :D
<andrewrk> example: enum(u8) { SpecialCaseA = 0, SpecialCaseB = 255, Normal = 1...254 }
<andrewrk> we have a precedent for it with switch cases on ranges
very-mediocre has quit [Ping timeout: 256 seconds]
<emekankurumeh[m]> but would we get general purpose ranges then?
darithorn has quit [Remote host closed the connection]
<tgschultz> andrewrk, what would be the result of @intToEnum(Normal) in your example?
<tgschultz> sorry, @enumToInt
<andrewrk> tgschultz, @enumToInt is a no-op at runtime. enums are backed by an integer
<andrewrk> you would need union initialization syntax to initialize the value: value = Enum { .Normal = 10 }
<andrewrk> @enumToInt(value) == 10
<andrewrk> union initialization syntax would have to get smarter for this to work with tagged unions with this kind of enum
<andrewrk> not smarter but there would need to be syntax for the case where the tag value had to be specified and a union payload as well
<tgschultz> that... seems weird to me. I would have guessed @enumToIn(MyEnum.Normal) would map to 1 as the lowest possible value.
<andrewrk> the idea is that you have an integer, and you're "mapping out" what all the different ranges are
<tgschultz> but I guess that would potentially cause comparison problems.
<andrewrk> this would be, for example, how you model that thing where MAX_UINT is a special value
<tgschultz> seems like this overlaps a bit with specifying the tag encoding of a union.
<andrewrk> I think it still works
<andrewrk> but now an entire range of values maps to a particular union payload
<andrewrk> if I propose this I'll be sure to proof of concept some really good use cases
<andrewrk> main idea is to remove the excuse that C programmers (including myself) have for using special values of integers
<andrewrk> or rather, make the type system aware of it, so that the perf/memory benefits still happen, but the compiler is aware
<tgschultz> there's a lot of use cases to cover if that's the goal. bitflags for instance, things like MAKEINTRESOURCE that encode a pointer, etc.
tgschultz has quit [Quit: Page closed]
MajorLag is now known as tgschultz
halosghost has quit [Quit: WeeChat 2.4]
Ichorio_ has quit [Quit: Leaving]
Akuli has quit [Quit: Leaving]
dewf has quit [Quit: Leaving]
_whitelogger has quit [*.net *.split]
pqflx3[m] has quit [*.net *.split]
l1x has quit [*.net *.split]
_whitelogger has joined #zig
<andrewrk> alright postponed some issues, back on track
mgxm has quit [Ping timeout: 264 seconds]
mgxm has joined #zig