ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<bheads>
I live in EST time, its just 5pm is when I leave work and am stuck in traffic
diltsman has quit [Ping timeout: 256 seconds]
dimenus has joined #zig
dimenus has quit [Quit: Leaving]
porky12 has joined #zig
darithorn has joined #zig
<MajorLag>
Does anyone know, are arrays handled the same way as structs re: #733?
<MajorLag>
Also, what's the appropriate way of submitting PRs that are dependant on other PRs?
tdc has quit [Ping timeout: 252 seconds]
Ichorio has joined #zig
tdc has joined #zig
allochi has joined #zig
allochi has quit [Client Quit]
Hejsil has joined #zig
<Hejsil>
#733 is the same for arrays
<Hejsil>
MajorLag
<MajorLag>
Hejsil, re: generic meta.eql, should it follow pointers? Is an [N]*u8 `eql` to another [N]*u8 if the values are the same, or only if the pointers are?
<Hejsil>
I'd say no. We want the "safe" subset. If the user wants to follow pointers, they should have another solution that takes into account cycles
<Hejsil>
So just == on ptrs, and .len == .len and .ptr == .ptr on slices
<Hejsil>
Also, meta.lessThan would also be useful :)
<Hejsil>
Also, for the PR depend on PRs. Idk how to do this, but If the first PR is done, and I know enough to review it, I could merge it
<MajorLag>
ok, so is `*T == *const T` if they point to the same place?
<MajorLag>
I would think so, but they are technically different types.
<Hejsil>
Would that ever happen?
<Hejsil>
Don't we pass fn eql(a: var, b: @typeOf(a)) bool ?
<Hejsil>
So we should always compare types, that are the same
<MajorLag>
It came up in a test with slices, which is why I asked. eql could be eql(a: var, b: var) with additional asserts, or even eql(a: var, b: var<EqlType(a)>) some day.
<Hejsil>
Why is eql(a: var, b: @typeOf(a)) bool not good enough?
<MajorLag>
It could be, it depends on your definition of `eql`. Since we're going with pointers not being eql even if their values are, then it probably is good enough.
<Hejsil>
I think, 99% of the time, the user wants to compare two types, that are the same :)
<Hejsil>
And if they don't, they should probably make their own, and have a comment explain why, two different types can be compared for equallity
<MajorLag>
edge cases matter
<Hejsil>
Exactly, and that is why they should roll their own
<MajorLag>
anyway, I agree that eql shouldn't be deep equlaity.
<Hejsil>
Actually, I'd say 100%, a generic eql, should only compare types that are the same
tdc has quit [Ping timeout: 252 seconds]
tridactyla has joined #zig
tdc has joined #zig
<MajorLag>
Hejsil, I didn't worry about following formatting standards as I figured a run through std.fmt would fix that.
<Hejsil>
Right. Then just do that, and we're done!
<MajorLag>
zig fmt is part of the compiler now? Or do I have to compile stage2 still?
<Hejsil>
You still need stage2. I can run fmt after merge, if that is better
<MajorLag>
It'd be easier for me. the dev environment I use when working with git will probably OOM trying to compile stage2
<MajorLag>
Hmm.... I think a lot of my utility code will become a lot simpler if I just assume copy elision will work soon.
porky12 has quit [Quit: Leaving]
<Hejsil>
MajorLag, did you see my latest comments on the meta.zig PR
<MajorLag>
I hadn't before I wrote that comment. I don't think returning a `*align(1) T` would make the function very useful. Then again, having this alignment limitation at all make it seem kinda pointless. For ints, mem.readInt() would probably be better, and for other types I have, and plan to make a PR for, arbitrary type reading/writing from streams that would work. Alignment would not be relevant.
<Hejsil>
MajorLag, in my randomizer, I use aliasing ptrs into byte arrays, so that reading/writing roms is trivial. Just read bytes, alias into bytes, modify alias', write bytes back
<Hejsil>
No need for serialization on write
<Hejsil>
So, i'd find it useful
<MajorLag>
No need for serialization unless the endianess is different than native
<Hejsil>
I have lu16 wrappers
<Hejsil>
lux wrappers*
<MajorLag>
doesn't that kinda defeat the purpose?
<Hejsil>
It's still more trival to alias a byte buffer, than deserialize
<Hejsil>
and serialize
<Hejsil>
The stdlib is gonna get cleaned up at some point. Having it in allows us to think about something like this when we do the cleanup
<MajorLag>
deserializtion is pretty trivial. It just isn't as efficient if the endianess matches.
<Hejsil>
Anyways, you can decided. I have my own implementation I use, so I wont miss them in std if you don't think it's worth it
<Hejsil>
but stream.write(mem.toBytes(packed_boy)) is the best serialization :)
<MajorLag>
`file_stream_writer.write(&value);` is my way. struct doesn't even need to be packed.
<Hejsil>
I like to have them packed, to document layout
<Hejsil>
In a way, it's declarative deserialization. I just declare my layout, and now it just works
<MajorLag>
layout is documented by order & size of fields as far as I'm concerned. compiler added padding is invisible in the code and ignored by the arbitrary type writer.
<Hejsil>
What about a:u4, b: u4?
<MajorLag>
if it is an actual bitfield it has to be packed for now, but I have plans to fix that because endianess is an issue there too.
<MajorLag>
for now I'd probably just take it as a u8
<Hejsil>
True. I think I have a few packed sturcts, where I don't take care of endianess proporly for sub 8 bit types
<Hejsil>
structs* properly*
<MajorLag>
bitfield endianess is pretty hairy, which is why I've left it largely unsolved. It also hasn't come up that often.
<MajorLag>
I probably still have too much java developer in my because my inclanation is to turn that into a struct.{u16} with fns to do the masking and shifting to retrieve the values.