ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<andrewrk>
kristate, I should be getting through your PRs soon! thanks for the patience
porky11 has quit [Ping timeout: 240 seconds]
<kristate>
andrewrk: after CE backport, a number of crypto related tests at work have triggered test asserts
<andrewrk>
hmm that's good to know
<andrewrk>
any test cases you can make public?
<kristate>
andrewrk: yeah, trying to get to the bottom of it
<kristate>
I am glad that you found the timeval stuff, too
<andrewrk>
yeah that's been a long standing issue
<kristate>
in our branch, we have const time_t
<kristate>
and on darwin time_t maps to c_long
<andrewrk>
got it
schme245 has quit [Remote host closed the connection]
reductum has quit [Quit: WeeChat 2.3]
<kristate>
andrewrk: X catch unreachable seems to trigger linker errors on macos
<kristate>
that is, it generates malformed mach-o
<andrewrk>
hmm, that expression is covered in behavior tests
<kristate>
andrewrk: yeah, it's weird because it only pops-up ever so often
<andrewrk>
if you have an .o file that reliably causes the error can you try linking with the system linker, to see if it's a problem with linking?
<kristate>
andrewrk: good idea, I will check with verbose-link
<diltsman>
Does anyone know if one of the assembly compiler_rt functions has been ported over? I would like to look over an example before I try porting some of the ARM routines.
<andrewrk>
diltsman, I believe there is some inline assembly in std/special/compiler_rt/index.zig
<diltsman>
So, __eabi_memcpy4 and __eabi_memcpy8 just call memcpy. Suggestions on what to do instead? I suspect some assembly.
<andrewrk>
I think you should be able to port the compiler_rt source from LLVM directly
<andrewrk>
any reason not to?
<diltsman>
The src is "b memcpy"
<diltsman>
Slightly more compliecated than that, but basically that.
<andrewrk>
sounds like we should port that assembly directly
<andrewrk>
I'll be back in a bit
<diltsman>
Doesn't that just call the C function memcpy? We don't want a dependency on libc, right?
<andrewrk>
LLVM code generation always has a memcpy dependency
<andrewrk>
that's why we provide it in std/special/builtin.zig
<andrewrk>
zig automatically builds it when you do build-exe or build-lib
<diltsman>
Ah! Didn't realize that. That simplifies things greatly.
<diltsman>
Should I make an arm directory in std/special/compiler_rt to match the directory layout of compiler_rt?
<strmpnk>
andrewrk: I caught the stream for a short while earlier but had to leave a bit early. re streaming topics: It'd be interesting to hear some discussion about various things you're leaving out of Zig and why.
<strmpnk>
I'm sure common ones come up like affine types (Rust comparisons in general), Jai comparisons too perhaps. But also various aspects of generics, macros, etc that you think compile time execution takes care of instead.
<strmpnk>
(and if some of this is covered in many streams that I've missed, I'd be happy to see some pointers at videos+time ranges or articles. Perhaps we could all work on creating a topical index into the streamed content.)
<kristate>
andrewrk: still online?
<daurnimator>
andrewrk: catching up on the stream now. I think the package manager issue needs to be split as it won't be all done in the current milestone.
<daurnimator>
and agreed that waiting on networking stuff before the coroutine rewrite is done is a bad idea. even blocking networking should probably wait for it.
<daurnimator>
s/waiting/working/
<daurnimator>
heh. *hooray* my proposal is called out as "really cool"
<kristate>
daurnimator: got a link?
<daurnimator>
kristate: to?
<kristate>
daurnimator: your proposal
<kristate>
I am generally against committing any blocking networking -- the stopgap should be an event runtime, but I am generally against that too
<emekankurumeh[m]>
will we get tls in 0.4.0 or will that come in 0.5.0?
<daurnimator>
emekankurumeh[m]: tls being thread local storage?
<kristate>
andrewrk: so, what is the zig best practice for zeroing a variable on stack when defined? []u8{0} ** len ?
<emekankurumeh[m]>
daurnimator: yeah
<kristate>
I like that undefined sets memory to 0xAA on debug mode
<diltsman>
andrewrk: Will I need to do anything anywhere else to get it to pick up the files in compiler_rt/arm?
<andrewrk>
kristate, ah yes, I wonder if those are your crypto failures. It was actually a bug that debug mode *wasn't* setting undefined bytes to 0xaa
<emekankurumeh[m]>
diltsman: make sure to add them to the CMake file
<andrewrk>
emekankurumeh[m], I think we can have Thread Local Storage in 0.4.0. it's a small enough change
<kristate>
andrewrk: yes, I am glad that was fixed
<andrewrk>
kristate, for initializing aggregate data structures, the official recommendation is to explicitly initialize all fields
<andrewrk>
for arrays, `[]T{x} ** len` as you mentioned is recommended
<andrewrk>
of course you can always drop down to a @memset if you need to do something other than what is officially recommended (perhaps when using a C API)
<kristate>
yeah, currently secure_zero does something like that -- but I think it is rather aggressive
<emekankurumeh[m]>
would there be any penalty in making all globals threa local by default?
Flaminator has quit [Ping timeout: 244 seconds]
<andrewrk>
yes
<andrewrk>
first of all it's semantically incorrect
<emekankurumeh[m]>
could be useful for running `zig fmt` after a merge or push
marmotini_ has joined #zig
schme245 has joined #zig
schme245 has quit [Remote host closed the connection]
very-mediocre has joined #zig
allan0 has quit [Ping timeout: 268 seconds]
schme245 has joined #zig
allan0 has joined #zig
redj has quit [Read error: Connection reset by peer]
schme245 has quit [Remote host closed the connection]
schme245 has joined #zig
schme245 has quit [Read error: Connection reset by peer]
schme245 has joined #zig
schme245 has quit [Ping timeout: 246 seconds]
allan0 has quit [Ping timeout: 244 seconds]
allan0 has joined #zig
schme245 has joined #zig
<schme245>
is there a function in the std lib for printing the contents of an array/slice, not the type@address?
<MajorLag>
schme245: []u8 should print as a string automatically, but any other type you need to do something like: `for(slice) |e| debug.warn("{},", e);`
<MajorLag>
unless someone added a fmt switch for it... which may have happened.
<schme245>
ok. that is simple enough to write, but do you think something like this would be considered as a format string?
<schme245>
so you could write `warn("{a}", arrayOrSlice)` to get the same effect with some nice brackets to boot?
<MajorLag>
yeah, that'd be a relatively straight forward addition to std.fmt, but it doesn't look like anyone has done it yet. Probably because we're planning on redoing std.fmt: https://github.com/ziglang/zig/issues/1358
<schme245>
cool, I'll shot a PR for it tonight and we'll see what happens
jevinski_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
allan0 has quit [Ping timeout: 250 seconds]
allan0 has joined #zig
allan0 has quit [Ping timeout: 250 seconds]
allan0 has joined #zig
Flaminator has joined #zig
steveno_ has joined #zig
radgeRayden has joined #zig
MajorLag has quit [Ping timeout: 252 seconds]
marmotini_ has quit [Ping timeout: 240 seconds]
MajorLag has joined #zig
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
steveno_ has quit [Ping timeout: 240 seconds]
MajorLag has quit [Ping timeout: 250 seconds]
halosghost has joined #zig
MajorLag has joined #zig
steveno_ has joined #zig
noonien has joined #zig
Avila has joined #zig
Ichorio has joined #zig
darithorn has joined #zig
redj has joined #zig
MajorLag has quit [Ping timeout: 268 seconds]
steveno_ has quit [Ping timeout: 268 seconds]
Zaab1t has joined #zig
MajorLag has joined #zig
schme245 has quit [Remote host closed the connection]
schme245 has joined #zig
schme245 has quit [Ping timeout: 240 seconds]
tobbez has quit [Quit: Lost terminal]
schme245 has joined #zig
tobbez has joined #zig
steveno_ has joined #zig
schme245 has quit [Remote host closed the connection]
schme245 has joined #zig
schme245 has quit [Ping timeout: 245 seconds]
<andrewrk>
hmm I need to define what happens when you try to @bitCast(u4, u8(x))
<halosghost>
andrewrk: you mean whether it becomes the high nybble or the low nybble?
<halosghost>
or do you mean something else?
<andrewrk>
well right now it causes undefined behavior in LLVM IR codegen, so that's a problem
<halosghost>
haha
<halosghost>
yes, that's not good :)
<andrewrk>
didn't mean to make them evenly divisible. also a problem is: @bitCast(u7, u8(x))
<andrewrk>
I think I will make it a compile error for now
<halosghost>
the compile error being @bitCast'ing a thing to a wider target type?
<halosghost>
or a smaller target type? (it's been a sec since I looked at @bitCast)
<andrewrk>
to a smaller one
<andrewrk>
it already gives an error if the @sizeOf's don't match. but @sizeOf(u7) == 1, so the analysis didn't catch it
<andrewrk>
@sizeOf is "store size" - how many bytes you need to store the type. but for @bitCast to work the bit size has to match
<andrewrk>
maybe we need @bitSizeOf
<andrewrk>
since we have @byteOffsetOf and @bitOffsetOf
<MajorLag>
we also should make a clearer distinction between "store size" and "aligned size", but we've already talked about that regarding arrays.
<andrewrk>
yeah, I don't think that is resolved yet
<MajorLag>
in #1851 kristate added an @alignedSizeOf
<andrewrk>
ah right. I'll have a look at that one next
<andrewrk>
MajorLag, in Deserializer.deserializeInt, what's supposed to happen regarding endianness when T == u7?
<andrewrk>
do we want the logical big end, logical small end, or does it depend on builtin.endian?
steveno__ has joined #zig
steveno_ has quit [Ping timeout: 268 seconds]
<MajorLag>
I believe it would always take the 7 least significant bits in byte-packed mode. I'll have to look at the code quick to refresh my memory.
<andrewrk>
ok cool, I'm pushing a small fix to master branch in a sec
<MajorLag>
I'm surprised we can get away with not marking `endian: builtin.Endian` as comptime though.
<MajorLag>
in the Serializer/Deserializer generators.
<andrewrk>
yeah. I must have made it implicitly comptime, but there should probably be an error for that
<andrewrk>
I bet if you call the function with a runtime value (and parameter not marked comptime) it crashes
wilsonk has quit [Read error: No route to host]
<andrewrk>
nope, no crash. it implicitly marks parameters comptime when the return type is a comptime type
<MajorLag>
ah, that makes sense. we didn't always do that though did we? probably how I got into the habbit.
<andrewrk>
that's something we can decide: * embrace implicit comptime parameters and make it an error to redundantly specify, or * embrace explicitly labeling comptime and make it an error if you forget to do it
<MajorLag>
I'm not even sure which way I lean on that.
<andrewrk>
me either, which is why it lets you do either way for now
Ichorio_ has joined #zig
Ichorio has quit [Ping timeout: 244 seconds]
steveno__ has quit [Remote host closed the connection]
wilsonk has joined #zig
steveno has joined #zig
steveno has quit [Client Quit]
very-mediocre has quit [Ping timeout: 256 seconds]