hio has quit [Quit: Connection closed for inactivity]
Flaminator has joined #zig
tgschultz has joined #zig
fengb has joined #zig
utzig has quit [Ping timeout: 252 seconds]
IntoxicatedHippo has joined #zig
lunamn has quit [Quit: leaving]
fengb has quit [Ping timeout: 260 seconds]
fengb has joined #zig
<fengb>
Is there a pattern for doing serializable bitflags?
bheads62 has quit [Ping timeout: 260 seconds]
<daurnimator>
fengb: isn't that just 'packed struct { a:u1, b:u2 ....... }
<fengb>
Yeah but I wanted to document the shifts
<fengb>
Probably not a big deal. I'll run with this and see how far I get
<hryx>
andrewrk: QQ, in translate-c-2, what approach do you recommend for generating an integer literal token? in the C++ version it converts the clang::APSInt to a bigint for the AST node, but the Zig AST node doesn't store the big.Int, just a token
<hryx>
essentially, should I convert the clang big int to zig and render that, or should I just copy the string from the original C source?
<hryx>
hope the question makes sense
ltriant has quit [Ping timeout: 245 seconds]
<hryx>
(tiehuis: this is why I asked about the big int stuff the other day)
<andrewrk>
hryx: good question. No need to use big ints anymore, the clang apsint can get rendered to text
lunamn has joined #zig
<andrewrk>
I think they already have functions for that
<hryx>
cool. from clang docs it looks like doing so with native Clang functions requires using C++ allocators, and I assumed that should be avoided in stage2 translate-c
<hryx>
I might have been mistaken
<andrewrk>
There's another option
<andrewrk>
If zig supports all the same integer literal syntax, the source span can be copied directly
<hryx>
that's what I was thinking might be good to start with for now
<hryx>
I'll do that and leave a comment to re-evaluate when translate-c gets more love
<andrewrk>
It would be more robust to have clang parse and serialize though. For example octals are different
<hryx>
ah I see
<andrewrk>
It's still ok though, one thing at a time
<daurnimator>
yeah i was about to say... i hope we don't have same octal syntax
<andrewrk>
Let's try to get your branch in a mergable state
<andrewrk>
And then keep chipping away at the problem
<hryx>
oh wtf, a c++ octal is just a number prefixed with "0"? lame
<hryx>
sounds good andrewrk
<hryx>
(sorry, was just commenting about the octal syntax coz I didn't know about that differencen before)
<andrewrk>
Going through bigint is fine if that's the easiest way to serialize
<daurnimator>
hryx: back in the day octal was useful
<hryx>
Also apologies for the super slow progress lately, last couple weeks have been super insane again
<daurnimator>
e.g. look at ascii through an octal lens. it'll make more sense
<daurnimator>
same with x86 machine code... makes a shit load more sense in octal
<hryx>
I see, that makes sense. I was more confused that hex uses "0x", so I'd expect octal to be "0o" or something
<andrewrk>
No worries hryx it's appreciated that you're contributing at all
<andrewrk>
Octal is 0o in zig but not C
<andrewrk>
Oh you know why it needs to go through apsint and not source hryx
<andrewrk>
Macros
<andrewrk>
There can never be any direct source copying because of the preprocessor
<andrewrk>
fengb: yeah there's a big fat hack in struct field alignment. I have a plan to fix it
<andrewrk>
Look for the "lazy values" issue
<andrewrk>
I'm gonna focus on stability (bug fixes) for the next couple weeks
<andrewrk>
But like, the hard bugs that need under the hood changes
<hryx>
andrewrk: I just got the translate-c PR to a point where I feel ok "cauterizing" it and not making any more changes. I'll open it for review -- it's not perfect but probably ok considering translate-c-2 is super WIP
<hryx>
don't hold back though, I'm definitely open to clean up any loose ends before merging
<hryx>
also, it's a lot of commits again. no conflicts, but want it squashed?
curtisf has quit [Ping timeout: 260 seconds]
<fengb>
andrewrk: when using packed structs, I accidentally left a nested struct 7 bits wide, and encountered the "Assertion failed. This is a bug in the Zig compiler." Is that the same problem?
<andrewrk>
hryx: no, a merge commit is good
<andrewrk>
And thanks! I'll have a look tomorrow
<hryx>
dope dope!
<andrewrk>
fengb: I'm not sure. If you can't find an existing issue after a quick search feel free to file that one
<fengb>
Sounds good thanks
<andrewrk>
hryx: apologies if we already talked about this but I can't remember, so did the test case at the top of the translate c tests regress?
<andrewrk>
Oh is that the one for the issue you opened?
<hryx>
exactly -- the add_2 tests now don't work because of that new issue
<hryx>
rather, they now fail because we're observing import mode in stage2
<hryx>
and that issue is to remove the import mode, at which point we can uncomment those tests
<andrewrk>
I see, ok, but we can at least add different tests for stage1 and stage2
<andrewrk>
Even if 2 is divergent from 1 it can still have coverage
<hryx>
ah yeah, I was gonna ask about that. In that case I'll add a few tests for the new stage2 stuff
<hryx>
cool, will have those done tonight so ye can review tomorrow
<andrewrk>
Perfect
<andrewrk>
I mean if we get to the point where all the 2 stuff is covered and it's good, we can just delete translate_c.cpp and the tests
fengb has quit [Ping timeout: 260 seconds]
<hryx>
true. that will be a nice diff >:)
<andrewrk>
Yeah and the really important thing is that all efforts (even now with your efforts) are for the real, final compiler
<andrewrk>
Not just stage1
<andrewrk>
That's the main motivation for this change
<andrewrk>
We can fully invest in the stage2 translate-c
brakmic has joined #zig
<hryx>
yesss. Well I hope this change can help others get started on that investment a little
brakmic_ has joined #zig
brakmic has quit [Ping timeout: 248 seconds]
darithorn has quit [Quit: Leaving]
squiddlebit has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
brakmic_ has quit [Read error: Connection reset by peer]
IntoxicatedHippo has quit [Quit: Leaving]
brakmic has joined #zig
brakmic has quit [Read error: Connection reset by peer]
brakmic_ has joined #zig
curtisf has joined #zig
<curtisf>
finally tracked down the miscompilation to a short-ish 25 line snippet :D but it's now very late. I wanted to say thank you all to working on Zig! I'm looking forward to watching it gain traction!
Hejsil has joined #zig
<marler8997_>
is there a way to pass a "const type" to a function? i.e. "const usize"?
curtisf has quit [Ping timeout: 260 seconds]
daurnimator[m] has quit [Read error: Connection reset by peer]
mattisme has quit [Read error: Connection reset by peer]
BitPuffin has quit [Write error: Connection reset by peer]
geemili has quit [Remote host closed the connection]
M948e5[m] has quit [Write error: Connection reset by peer]
emekankurumeh[m] has quit [Write error: Connection reset by peer]
BitPuffin has joined #zig
ltriant has quit [Ping timeout: 248 seconds]
<marler8997_>
why doesn't the Array TypeInfo have an "is_const" field?
mattisme has joined #zig
<Hejsil>
marler8997_ Only memory locations can be 'const'. This means declarations and pointers.
<marler8997_>
ok thanks for confiming
<marler8997_>
whoa....running ./bin/zig test ../std/meta.zig seems to be completely locking up my linux box
<marler8997_>
I just rebooted, ran it again and now it's completely hung again
<thm>
maybe try limiting the amount of memory it can take?
marmotini_ has joined #zig
avoidr has joined #zig
<thm>
is there a way to parallelize builds? build-exe seems to use only one thread/process
marler8997 has quit [Remote host closed the connection]
wilsonk has joined #zig
ajhager has quit [Remote host closed the connection]
hio has joined #zig
Flaminator has joined #zig
fsateler has quit [Ping timeout: 245 seconds]
fsateler has joined #zig
avoidr has quit [Quit: leaving]
laaron- has joined #zig
laaron has quit [Ping timeout: 260 seconds]
<tgschultz>
marler8997_ it may be an infinite import loop. I've encountered something similar before. The solution at the time was to cd into std and run the test from there.
marijnfs has joined #zig
M948e5[m] has joined #zig
<thm>
are there html docs for the std library?
marmotini_ has quit [Ping timeout: 245 seconds]
<thm>
okay, this is a faq ;)
squiddlebit has quit [Quit: WeeChat 1.9.1]
ajhager has joined #zig
halosghost has joined #zig
fengb has joined #zig
<fengb>
No docs for std yet, but the code is pretty readable
Akuli has joined #zig
mmx87 has quit [Quit: Ping timeout (120 seconds)]
mmx87 has joined #zig
<samtebbs>
Perhaps we should add a notice to the README saying that docs for std are coming as a lot of people have probably spent time looking for them.
<Tetralux>
Seems good to me.
darithorn has joined #zig
<fengb>
RTF~M~ C? :P
<darithorn>
is it normal for zig to require all of its llvm dependencies when all i want is to build docs?
<darithorn>
docgen.zig doesn't look like it uses anything special and I already have a prebuilt zig compiler binary
<darithorn>
(i know the docs aren't much there but i was curious what state they were in)
<scientes>
I'm starting to think we should have implicit up-casting of vectors
<scientes>
and shouldinstead introduce @sext() and @zext()
<scientes>
not because it is unsafe on vectors, but because it creates an inconsistancy with arrays
<fengb>
Are there plans to implicitly downcast bit operations? "const foo: u2 = bar & 0b11;"
<scientes>
fengb, no
<companion_cube>
why do people write `_ = try foo();` instead of `try foo();`?
<scientes>
maybe to limit warnings, but never actually cast
<fengb>
Zig throws an error if you don't use the return value
<companion_cube>
even if it's void?
<fengb>
It's also self documenting that the function has a return value
<scientes>
so there might be a compiler "internal range" to supress errors, but the type would never change
<companion_cube>
ah ok.
<fengb>
Oh void? That doesn't make sense
<companion_cube>
no, I'm just wondering
<companion_cube>
it makes sense if it fails when the value is silently discarded.
<fengb>
scientes: not auto downcast but rather smart enough to be context aware
<companion_cube>
(I'm taking a look at docgen)
<scientes>
_ = should be an error if it returns void
<scientes>
fengb, yes, but probably only in stage2
brakmic_ has quit [Ping timeout: 245 seconds]
<scientes>
lots of work on errors just isn't worth it now
<fengb>
Ah okay
brakmic_ has joined #zig
<fengb>
Is there a documented roadmap of features per version?
<andrewrk>
marler8997_, hmm, it might be time to reel in memory usage of stage1
<Tetralux>
I just find myself I could type a bunch without thinking "aaaand gotta tell it that I'm still typing"
<Tetralux>
Aside from that I haven't really missed them yet.
marler8997 has joined #zig
<tgschultz>
Alright, I'll bite, why would it be useful to have doc comments in the TypeInfo?
<darithorn>
i can't speak for lunamn but i'm just rooting for the ability to generate documentation easily. To me, TypeInfo seems like a good place to put that access
<lunamn>
yeah, that's the idea
<darithorn>
though, since Zig already enforces a certain code style, it'd make sense to have documentation generation built into the compiler, which would enforce a certain doc style
<tgschultz>
I don't see why that's necessary, and it opens up comments being relavant to comptime code. As in, the behavior of code could change depending on the comments.
<darithorn>
that's true but i think no matter what you do there's potential for abuse
<darithorn>
if the docs were exported as a json file, the programmer could almost just as easily use that to change runtime behavior
<tgschultz>
sure, but since this functionality is only really useful for exactly one thing, it doesn't seem like a good tradeoff at all
mawaldne has quit [Ping timeout: 260 seconds]
<darithorn>
yeah, i can agree that there's very little reason to put in the extra effort to expose that information to the user at compile time
<darithorn>
is there any work being done in putting doc gen into the compiler?
<hryx>
darithorn: see issue #21 - I plan to do work on it after current task
<darithorn>
okay, that's great. with my school i hardly have any time to work on the generation part but i'd absolutely love to work on going through and documenting everything once it's ready
<darithorn>
or once the documentation style is finalized
vexu has joined #zig
dimenus_ has joined #zig
avoidr has joined #zig
marmotini_ has quit [Read error: No route to host]
<Sahnvour>
debugging this is tedious, but what you can do for a start is: in coff.zig, fn loadSections, output the name of each section it loads in the while loop
<Sahnvour>
(and reinstall zig with after doing the change so that it builds with it)
<Sahnvour>
it should but you have an illegal read before it can reach this part :)
tgschultz has quit [Ping timeout: 248 seconds]
MajorLag is now known as tgschultz
marijnfs_ has quit [Ping timeout: 252 seconds]
dimenus_ has quit [Ping timeout: 248 seconds]
<Sahnvour>
also you can try to open your build.exe with PEView (http://wjradburn.com/software/) and make sure it sees a .rdata section
fengb has quit [Ping timeout: 260 seconds]
<cameris>
hryx: `fn escapeChar` returns a slice to an array that is declared inside that function, hence on the stack. I'm not sure, but is that supposed to work?
<emekankurumeh[m]>
that smells like a bug
<hryx>
dang
Flaminator has quit [Disconnected by services]
<hryx>
thanks cameris, I'll look into that
<hryx>
in fact I can already tell you're totally right. Doesn't matter how much I work with slices, my brain still says "array"
vexu has quit [Quit: WeeChat 2.5]
<hryx>
:>
<mikdusan3>
that looks like a bug. but i don't think that's causing your specific issue
<emekankurumeh[m]>
Sahnvour: i think the header is being loaded incorrectly because zig thinks that there are 0 instead of 7 sections
<cameris>
mikdusan3: the len is not the problem I think, thats part of the slice. But the call of escapeChar in `fn writeEscapeString`.
<cameris>
well maybe, not really sure. At least it seems odd to me.
<mikdusan3>
yes i only did a workaround for one call point of escapeChar
<Sahnvour>
emekankurumeh[m]: interesting, can PEView load it correctly ?
<cameris>
hryx: in #2749 your doing the same in the first example with `fn f(c: u8) []const u8`
<emekankurumeh[m]>
nvm i was misunderstanding the logic
<emekankurumeh[m]>
nvm again i was correct
<hryx>
thank you mikdusan3 and cameris! I'll fix that when I get home
<emekankurumeh[m]>
Sahnvour: in coff.loadSections the length of Coff.sections is checked before it is ever initialized to something meaningful
<Sahnvour>
emekankurumeh[m]: yeah that looks like something wrong, I don't remember why it's written like this
<emekankurumeh[m]>
i'll make a patch for that
<Sahnvour>
sections is supposed to be initialized with undefined, so filled with 0xAA right ? Then I don't understand how it can work, because sections.len would always be different from 0
<mikdusan3>
hryx: here's a fix for cstr/zstr stuff. turns out "cstr" was a misnomer. function returns non-null-terminated bytes. and all you have to do is make it a slice instead of calling Context fn str()
<Sahnvour>
emekankurumeh[m]: does that fix your sigsev ?
<mikdusan3>
duh. why don't i just add it to PR :)
<emekankurumeh[m]>
yes
<emekankurumeh[m]>
though with some error traces i get integer overflows
<hryx>
thanks mikdusan3, hott stuff
<Sahnvour>
I think there's still a bug: `Coff` has no init func, so there's no way to know if `sections` is initialized or not
<Sahnvour>
it should either get an init(), or `openSelfDebugInfoWindows` should initialize `sections` itself
<mikdusan3>
C null-terminated strings are a billion dollar mistake. maybe more.
<wrl>
slices are clearly the better abstraction
<hryx>
also I think the issue of returning a stack-allocated slice remains. in which case I can just make the destination slice a parameter instead of return value
<hryx>
whoa wait, will copy elision make that unnecessary?
<hryx>
:brain_explode:
<mikdusan3>
hryx: it's not an issue of returning a *slice*. that's done and copy elision takes care of the *slice*.
<mikdusan3>
the issue is the memory slice points to is technically gone.
<mikdusan3>
ie: creating an array... and slice it. the storage for 1,2,3,4 is tmp. --> `return [_]u8{1,2,3,4,5}[0..];`
<hryx>
sorry, that is indeed what I meant to say -- I appreciate the more correct language :>
<Sahnvour>
emekankurumeh[m]: what environment are you in ?
<emekankurumeh[m]>
windows 7 64bit x86_64-windows-gnu
<Sahnvour>
what does the -gnu part implies ? because I'm able to run your snippet and it displays the error trace correctly, on W10
<emekankurumeh[m]>
the abi
<emekankurumeh[m]>
i don't think it should matter because i'm not linking to libc
<emekankurumeh[m]>
i think zig is going a level too deep when showing error traces. it shows the error trace fine but after that the error trace is finished i get the overflow error.
<Sahnvour>
possibly it's trying to display the windows function calling the program
<Sahnvour>
but I remember seeing these in stack traces, so that shouldn't cause overflow
<Sahnvour>
looking at your previous gist, the next frame is kernel32.dll!BaseThreadInitThunk which was located at a lower address in memory
<Sahnvour>
in that case, it would make sense the subtraction goes wrong
<Sahnvour>
because your base address is something like 0x13FB...
avoidr has quit [Quit: leaving]
<companion_cube>
should generic things like ArrayList take a comptime function to deinit elements that are removed?
<cameris>
Im totally confused right now, in https://ziglang.org/documentation/0.4.0/#Peer-Type-Resolution `fn boolToStr(b: bool) []const u8` isn't that the same problem that hryx is faceing? What is the lifetime of the strings that are returned?
<Tetralux>
String literals are in the static segment and therefore not on the stack, therefore global, there's always around.
<Tetralux>
Well - not really "global" per se - but you get my point.
<Tetralux>
They're around for the lifetime of the program.
<hryx>
yes, for string _literals_ that exactly right
<hryx>
(the bug I asked about had a different problem, just to be clear)
<Tetralux>
.. But not: var a: [64]u8 etc.
<Tetralux>
Because that's on the stack.
<Tetralux>
And therefore you should not return it.