<SamTebbs33>
Note I tried to make the Directory struct packed, which it needs to be, but I can't do that since "error: array of 'src.kernel.arch.x86.paging.DirectoryEntry' not allowed in packed struct due to padding bits
<gamester>
SamTebbs33: The compiler says the size of DirectoryEntry is 5 bytes
<SamTebbs33>
Weird, if you sum up all the fields it comes to 32 bits
<SamTebbs33>
To quote the docs: "bool fields use exactly 1 bit" and "Zig supports arbitrary width Integers and although normally, integers with fewer than 8 bits will still use 1 byte of memory, in packed structs, they use exactly their bit width"
<gamester>
yeah this is weird
<SamTebbs33>
Possible packed struct bug here? I can do more investigation if need be
<daurnimator>
SamTebbs33: can you iterate over struct members and print their offsets?
<SamTebbs33>
Sure, I haven't done any reflection in Zig before but will check the docs
<daurnimator>
SamTebbs33: something like this: for (@typeInfo(DirectoryEntry).Struct.fields) |field| { std.debug.warn("field={}, byteoffset={} bitoffset={}\n", field.name, @byteOffsetOf(DirectoryEntry, field.name), @bitOffsetOf(DirectoryEntry, field.name)); }
<gamester>
daurnimator: that appears to need to be an inline for, but I'm then hitting a "compiler bug" (a missing cast)
<SamTebbs33>
gamester, yeah it does, it should be zeroes, then ones up until page_phys_addr then it should be 2
<SamTebbs33>
I guess
<daurnimator>
gamester: yeah... looks like a bug I think
<SamTebbs33>
gamester, duarnimator: I'll make an issue! Do you think it needs a more generic example or is this good enough?
<daurnimator>
SamTebbs33: always try and get it down to a minimal test case if you can.
<gamester>
This is already fairly minimal as long as only DirectoryEntry is included and no excess surrounding code, but one could certainly try to 'simplify' the struct while still hitting the bug(s)
<SamTebbs33>
gamester, duarnimatorm, yeah I'll add some comments and refactor the fields names to make it more clear
<daurnimator>
SamTebbs33: use tab completion for IRC names :P
<gamester>
SamTebbs33: I'd include the @sizeOf issue as well. While the byte offsets seem too low, the total size seems too high.
<SamTebbs33>
daurnimator: haha thanks :D
<SamTebbs33>
gamester: Yeah I will, the mismatch is too weird
<gamester>
SamTebbs33: I think it's only the last field that's at the wrong byte offset
<gamester>
the 'ignored' field is at bit offset 8, so definitely byte offset 1
<gamester>
SamTebbs33: oh nevermind I misread what you said. I thought you had said it should at all zeroes up until page_phys_addr, I was trying to correct that :D
<daurnimator>
gamester: I thought bitOffsets were *within* a byte; i.e. the issue is that the bitoffset wasn't reset to 0 at the byte boundary
<gamester>
daurnimator: "Returns the bit offset of a field relative to its containing struct"
<daurnimator>
gamester: huh. right. I misunderstood the field :P
<SamTebbs33>
Do you guys have any idea what could be causing this?
halosghost has joined #zig
<SamTebbs33>
I guess I should figure out if this is a @bitOffset, @byteOffset and @sizeOf issue or if it's wrongly laid out in memory too.
<SamTebbs33>
I hazard a guess at saying it's wrongly laid out in memory due to my troubles debugging my kernel :p
<daurnimator>
SamTebbs33: sorry I'm not familiar with that part of the codebase
<gamester>
Yeah I have no clue, but nice find! As useful as packed structs are, not many people have been using them so far. I'll be needing them at some point so it's nice that they are getting some use :D
SimonNa has quit [Remote host closed the connection]
<SamTebbs33>
gamester: thanks :) I think this is the third bug I've found in the past week and a half :D Tbh that was one of the main reasons why I've wanted to use Zig: to find bugs
<daurnimator>
SamTebbs33: heh. you're lucky. I tend to find one every 20 mins or so :P
return0e has quit []
return0e has joined #zig
<SamTebbs33>
daurnimator: haha I might have encountered a few more but just not noticed them yet :p
<SamTebbs33>
I'm surprised that this use case (of packed structs) isn't tested for
<mikdusan1>
add some :)
<SamTebbs33>
Hmm ignore that, it seems that it is tested in stage1/behavior/sizeof_and_typeof.zig, not with bools though AFAIS
<SamTebbs33>
mikdusan1: Oh definitely, I reckon it should come with a patch that fixes the bug and I have no idea how to do that yet :D
fengb has joined #zig
<fengb>
I'm curious: does this work if you change bool to u1?
<SamTebbs33>
Nothing changes if I change bool to u1 :/
<SamTebbs33>
fengb: ^
<fengb>
Okay, I was hoping it's a bug in bool heh
gamester has quit [Remote host closed the connection]
<SamTebbs33>
fengb: Yeah me too
<SamTebbs33>
Hopefully andrew will have some insight when he gets time to look at it
<mikdusan1>
if you want to look at the code for those builtins - ir.cpp - ir_analyze_instruction_byte_offset_of()
<SamTebbs33>
mikdusan1: Sweet, thanks :) I'll take a look
<SamTebbs33>
What's the best way of doing debug logging in the zig source?
<mikdusan1>
i just use fprintf(stderr,...)
<mikdusan1>
friendly reminder; after changing src/ and installing, you'll need to use `--cache off` when testing .zig; eg. `zig run --cache off foo.zig`
<SamTebbs33>
mikdusan1: I'm assuming that doesn't apply to doing `zig build-exe foo.zig && ./foo`?
<mikdusan1>
correct
<SamTebbs33>
mikdusan1: cheers
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 258 seconds]
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 258 seconds]
porky11 has joined #zig
<andrewrk>
mikdusan1, incorrect - the cache system is not broken, it knows when things change
<mikdusan1>
i see your point, but in the world of logging and doing a repeat `zig run` the cache prevents seeing analysis log statements
<andrewrk>
if you insert a new log statement, the change will be picked up
<mikdusan1>
and if i want to see the log statements on re-run when NOTHING has changed?
Akuli has joined #zig
<andrewrk>
the log statements are in the compiler?
<mikdusan1>
yes
<andrewrk>
I see
<mikdusan1>
btw welcome back. how was your marathon?
<andrewrk>
mikdusan1, sorry for putting you on the spot. I just want to make sure that rumors don't spread of the cache system being broken
<andrewrk>
(unless they're true, in which case need to be fixed pronto. I don't want people superstitiously wiping the cache dir)
<andrewrk>
it was a well run event. those last 6 miles are brutal
<mikdusan1>
yes i wasn't clear that it was NOT a bug. only that we needed to circumvent the cache system. i agree, need to be clear if it might read as a "bug" where there is none
<SamTebbs33>
"well run"
<SamTebbs33>
andrewrk: Good to know it went well :)
avoidr has joined #zig
<donpdonp>
i can zig test src/one.zig. whats the usual way to run though all the files?
allan0 has quit [Ping timeout: 244 seconds]
allan0 has joined #zig
marmotini has joined #zig
SamTebbs33 has quit [Quit: leaving]
marmotini_ has quit [Ping timeout: 248 seconds]
porky12 has joined #zig
porky11 has quit [Read error: No route to host]
<tgschultz>
andrewrk: are we aware of an issue with windows traces being wrong again? Specifically it seems to only happen on the very first line and may just be a single character?
<tgschultz>
though in my current case that doesn't make sense, because it asserted an inactive union field access on assigning to a u32.
wilsonk|3 has joined #zig
wilsonk has quit [Ping timeout: 252 seconds]
marmotini has quit [Remote host closed the connection]
very-mediocre has joined #zig
Ichorio has joined #zig
Zaab1t has joined #zig
Zaab1t has quit [Client Quit]
SamTebbs33 has joined #zig
<tgschultz>
huh, so it's as if it was using cached data or something. merely adding a space fixed the trace
<tgschultz>
and removing it again, it still works.
Ichorio has quit [Read error: Connection reset by peer]
Ichorio has joined #zig
Akuli has quit [Quit: Leaving]
SamTebbs33 has quit [Quit: Lost terminal]
mrkishi has joined #zig
<emekankurumeh[m]>
does zig use the parser written in zig or the original one written in c++?
heitzmann has quit [Quit: WeeChat 2.4]
heitzmann has joined #zig
very-mediocre has quit [Ping timeout: 256 seconds]
porky12 has quit [Ping timeout: 248 seconds]
<andrewrk>
emekankurumeh[m], compilation uses the c++ one. zig fmt uses the self-hosted one
<fengb>
I like a lot of what he wrote, but really disagree on error handling
<emekankurumeh[m]>
andrewrk: any thoughts?
<fengb>
After working with Go a bunch, if you don't add proper error handling into the language, people will invent adhoc patterns that emulate them poorly
<andrewrk>
emekankurumeh[m], I read this and I don't think there's anything for zig project to learn from this post
<fengb>
I'd be curious to see how Odin develops
<andrewrk>
his biggest issue is errors, and his suggestion is "You make your mess; you clean it." I don't even know how that's supposed to work. You told me to append an item to a list and there's not enough memory to do it, what am I supposed to do?
<andrewrk>
an error is when the requested operation could not be completed
<andrewrk>
that's not a mess - that's a possible outcome of attempting something fallible
<fengb>
Fallible isn't perfect. Therefore we shouldn't support it :troll:
<mikdusan1>
strangely enough it's not easy to find examples of error handling in odin. especially memory failures.
<andrewrk>
fengb, you may be trolling but my definition of "perfect" is explicitly: "correct behavior and output for every possible input"
<andrewrk>
handling errors correctly is part of creating perfect software
<fengb>
Sorry, I'm more countering a rather common design philosophy that ignores the real world
<andrewrk>
my use of "perfect" doesn't mean some unicorn rainbow shitting idealistic future - it means the design allows for all the bugs to be fixed
avoidr has quit [Quit: leaving]
<andrewrk>
some designs actually prevent this. for example if you use python, go, or any scripting language really, you actually cannot handle out of memory. you will never be able to control the behavior when memory is exhausted
<andrewrk>
this is a language limitation; not a fundamental limitation of reality
gamester has joined #zig
<andrewrk>
fengb, just taking your prompt as an excuse to rant :)
<fengb>
Sure, I just didn't mean offense, even if I sorta hijacked "perfect"
<gamester>
I don't understand why gingerbill doesn't mention/credit Jai, when he's been copying Jai's syntax and asking JBlow about syntax issues with Jai's design. Also one of Odin's goals is "joy of programming" but then says "error handling should not be fun" when talking about Zig..
<fengb>
One thing I love about Zig is how it naturally cascades down to embedded systems, webassembly, etc without feeling like a trudge to replace the userland.
<merlyndmg>
Jai isn't released software yet
<merlyndmg>
that's one reason not to include it
<andrewrk>
fengb, yep! I tried to make this point in the intro of the talk linked on that blog post - even if you manage to make perfect software, if you don't do it in a widely reusable way, then someone else is going to write their own not-perfect software for their environment instead of using yours
<merlyndmg>
(and one reason I'm slowly digging into zig now)
halosghost has quit [Quit: WeeChat 2.4]
<fengb>
I'm really enjoying this renaissance of C replacements though. Feels long overdue to finally have something that's not a C++ replacement
<andrewrk>
Jon is a smart guy but he has a very specialized perspective, and not opening up his development process to the open source world as I've done with Zig is keeping his perspective limited
<merlyndmg>
There might be value to keeping his perspective narrow and more focused for a while, making his retail game in it, then opening it up for wider criticism
<merlyndmg>
but I think zig is good to be doing a different approach
<fengb>
I think it's really pigeonholed into game dev
porky12 has quit [Ping timeout: 252 seconds]
<merlyndmg>
that's the intention, yeah
<merlyndmg>
from what I understand
Ichorio has quit [Ping timeout: 252 seconds]
<fengb>
Jon is really smart, but nobody has the best idea on everything. I believe having real world usecases taxing the language will improve it much more than an ivory tower approach
<fengb>
andrewrk: I really like your wizard hat in that talk :P
gamester has quit [Quit: Leaving]
<andrewrk>
I had a wizard hat?
<emekankurumeh[m]>
there are some features in odin that i would like to see in zig though
<emekankurumeh[m]>
namely distinct values, and bit sets
<fengb>
Your miming of ivory tower design
<andrewrk>
ahh right
<fengb>
Although your version of a wizard sounds really derpy
porky12 has joined #zig
<emekankurumeh[m]>
zig fmt seems to be broken, whenever i try to run it i get a segfault in ___chkstk_ms
utzig has joined #zig
mikdusan1 has quit [Read error: Connection reset by peer]
<andrewrk>
emekankurumeh[m], one of the zig test suite tests runs zig fmt on build.zig
mikdusan has joined #zig
porky12 has quit [Quit: Leaving]
I_Right_I has joined #zig
<I_Right_I>
Hi all, I am checking out zig for the first time and I was wondering if there is any documentation for the standard library?
gamester has joined #zig
gamester has quit [Client Quit]
<scientes>
not yet
<scientes>
basically it is waiting for the documentation generator to be written