ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
kbd has joined #zig
<kbd> Help, I think I'm stuck in a loop between "error: comptime control flow inside runtime block" (on 'continue') and "error: unable to evaluate constant expression" on the 'for'.
<kbd> will post gist
squeek502 has quit [Remote host closed the connection]
<kbd> this is the thing from the other day where I had to change tuples to structs because the former was comptime. So I'd expect the for loop to not be 'inline'
<g-w1> use inline for
<g-w1> i think it should work
<kbd> inline for gives the first of the errors on the 'continue'
<kbd> "comptime control flow inside runtime block"
<g-w1> ah you want const format
<g-w1> but continues inside inline for doesn't work hmm
<kbd> ah. Hmm, changed "var format" to "const format", "for" to "inline for", and I'm still getting " error: comptime control flow inside runtime block" on the (second) continue
<g-w1> is there some way you can not use continue?
<kbd> yeah, apply more structured programming. Will try.
<g-w1> this is definently a bug in stage1, idk how easy to fix
<kbd> yep that gets passed it using flags.
<g-w1> flags?
<kbd> I'll post the updated code one sec
<g-w1> k
<kbd> oh it's still buggy anyway, lemme get the code to actually work. My point about flags was that any 'continue' can be turned into a flag (like "skip"), where the rest of the block is guarded by an "if skip".
<g-w1> ah yep, makes sense
<kbd> maybe that's not true in general, not sure. But in my case where the continue is at the tail of each branch I think it holds.
<kbd> sorry, "if ( ! skip)"
<kbd> what's the easiest way to format an integer into a string? The function I was looking at has five parameters.
<kbd> like should I bufPrint it into a string that I know is long enough?
<g-w1> std.fmt.formatInt
<g-w1> or just bufPrint
<kbd> ok I didn't understand what to use for the 'writer' on formatInt, lemme look at the stdlib again.
<g-w1> just use bufPrint if you know the length
<kbd> 32 bit number is max 10 digits if I counted correctly. But ok, no simpler version of formatInt that I missed, thanks. Cause I look at the writer in the stdlib to try to figure out what it is and it's "anytype" 🤦‍♂️
<g-w1> it is something that impliments
<g-w1> generics in zig are kind of hard to reason about because anytype
<g-w1> *not generics per-se but traits
<mipri> it's static but it's still duck typing, yeah? documentation will help, and maybe some tooling to show you what the anytype looks like according to callers.
<g-w1> i think it can be accomplished with some language features to make traits like this
<g-w1> imo its best to implement something in the language, you shouldn't need docs to tell you something as basic as what to pass to a function
<mipri> this is already a hard requirement for something like a format string.
<g-w1> yeah, but i feel like there is a way to do some sort of trait thing at comptime that can better tell you the type in the signature of the function
<mipri> although I was thinking of the var arguments that go with it, first.
<daurnimator> kbd: indeed `continue` is broken inside of comptime loops
<daurnimator> we've had to work around that in the standard library in a few places
<daurnimator> also watch out for using `break` or `switch` inside of comptime loops
ifreund has quit [Ping timeout: 240 seconds]
<daurnimator> or even `return` inside of a comptime loop... which includes `try`
<kbd> So the loop should automatically turn into a runtime loop if it uses runtime features, but it doesn't?
<g-w1> is this a language flaw, or a impl flaw?
<daurnimator> g-w1: impl.
<g-w1> ok
squeek502 has joined #zig
LewisGaul has quit [Quit: Connection closed]
<kbd> dang that was the main thing I was looking forward to (the async/await) in my Zig implementation.
brzg has joined #zig
<daurnimator> kbd: I'm not sure what code you're trying with?
<kbd> sure lemme produce a test case
<kbd> figured maybe y'all would respond with the github issue I ran into
<kbd> I quickly stripped down my main code into that, but that reproduces.
<kbd> that complies and runs without the 'pub const io_mode = .evented'
pyrmont has left #zig [#zig]
<kbd> bbiab
<daurnimator> kbd: trying to compile that I get "child_process.zig:474:17: error: missing std lib enhancement: ChildProcess implementation has no way to collect the environment variables to forward to the child process"
<g-w1> i get the broken llvm module on latest zig
<mikdusan> heh I was looking at which procs use compressed memory and a bunch of `llvm-tblgen` came up. From yesterday when I *tried* to run tools/update_cpu_features.zig against llvm-11 sources (just to see what would happen). result was "Panicked during a panic. Aborting." but... I didn't see
<mikdusan> that it left a dozen zombie processes
qazo has joined #zig
brzg has quit [Quit: leaving]
qazo_ has joined #zig
qazo is now known as Guest91210
qazo_ is now known as qazo
xentec has quit [Quit: memento mori]
xentec has joined #zig
<andrewrk> mikdusan, huh I wonder what caused those processes to become zombies
<andrewrk> in theory if the parent is killed the children should be killed too right?
<andrewrk> hmm I searched for "abort child processes" and did not get the results I expected
<andrewrk> mikdusan, the script works on master branch if you comment out csky and handle the fact that some TuneFeatures are empty (handle the optional instead of .?)
earnestly has quit [Ping timeout: 265 seconds]
<daurnimator> andrewrk: no, if parent are killed then children get reparented to PID 1
<andrewrk> that is not a desirable default
<daurnimator> tell the designers back in the 80s
<daurnimator> uh, 70s
<andrewrk> I'd rather just set a flag to change things, is there one?
<daurnimator> its platform dependant
<daurnimator> but hey, it's one of those times I actually changed posix :)
<daurnimator> andrewrk: oh, and it also depends on all the programs you *call* using the same non-default behaviour. so essentially unenforceable without cgroups/pid namespaces
<daurnimator> which are even more platform dependant that process groups
<daurnimator> s/that/than/
<andrewrk> I don't really care about posix, we can always put comptime logic to switch on the target
<andrewrk> the behavior was observed on linux
<daurnimator> e.g. back in 2017 I asked netbsd and they said they wouldn't implement the options unless posix mandated it.
<kbd> is there any trick for using iterators to pass them to things like std.mem.join or sort? Trying to join the values of BufSet. Get the iterator, add them to an ArrayList, and take the .items?
<kbd> (to pass to .join)
cole-h has quit [Quit: Goodbye]
cole-h has joined #zig
sord937 has joined #zig
knebulae has quit [Read error: Connection reset by peer]
bens has joined #zig
<mikdusan> andrewrk: trivial PR for llvm12: #8105
waleee-cl has quit [Quit: Connection closed for inactivity]
<mikdusan> thanks for "update to LLVM 12 sret callsite requirements" commit!
<andrewrk> np
<andrewrk> thx for the usage fix
xackus_ has joined #zig
ky0ko has quit [Remote host closed the connection]
hidayat has joined #zig
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
craigo has quit [Ping timeout: 240 seconds]
leon-p has joined #zig
<semarie> andrewrk: how often is updated zig-bootstrap ?
<andrewrk> hi semarie! it's updated when llvm releases and when zig releases
<andrewrk> I'd be happy to do an update right now for llvm12rc2 and zig llvm12 branch
<andrewrk> for 0.7.1 you can check out the git tag of the repo
cole-h has quit [Ping timeout: 260 seconds]
<andrewrk> semarie, done. master branch of zig-bootstrap is updated to latest zig llvm12 branch, and llvm 12 rc2
<andrewrk> there are a number of issues with llvm 12 that are not resolved yet
<mikdusan> andrewrk: you mentioned a thing you do with every zig llvm update, 24 hours, what does that process entail?
<mikdusan> is it `zig build test` w/ llvm debug binaries or something more?
<andrewrk> yes it's that
<andrewrk> takes a long time to complete
<mikdusan> just checking, are you aware that release can be built with same asserts enabled?
TheLemonMan has joined #zig
<TheLemonMan> yo
<mikdusan> hi lemon
<TheLemonMan> re: the debug info problem, did you manage to reproduce it with LLVM12?
<mikdusan> getting close. I've got it down to 10 megabyte .ll
<mikdusan> and now am setting up an llvm `opt` that uses -O1 passes and will add 1 by 1 each -O2 pass difference until it poops
<TheLemonMan> you can use llvm-reduce to perform the reduction for you
<TheLemonMan> I usually perform a binary search, run opt with every pass and then remove half of them
<mikdusan> ok so I have a 10 meg .ll which has been optimized and can reproduce every time these 2 things:
<mikdusan> llc against .ll crashes. and opt --strip other.ll, llc never crashes.
<mikdusan> I'll give reduce a shot right now
<mikdusan> ugh not getting how to use this thing
<TheLemonMan> yeah, there are little to no docs, check out this video
<mikdusan> thanks
<TheLemonMan> 2:02 shows how it works
craigo has joined #zig
<mikdusan> go go gadget
<mikdusan> down to 1.2M reduced.ll so looks like progress
<TheLemonMan> now that's what I call weight loss
<mikdusan> github doesn't like .xz for shame.
cole-h has joined #zig
<mikdusan> TheLemonMan: updated #6408
<TheLemonMan> submitted a patch for the miscompilation
<mikdusan> llvm-reduce managed to get it down to 200 KB . pretty impressive
<mikdusan> 90% of that is debug meta
<TheLemonMan> we should split #6480 into two tickets, the miscompilation is unrelated to the debug assertion problem
<mikdusan> I agree
<mikdusan> I'll do that
<mikdusan> this title ok? `llvm12: -OReleaseFast miscompilation of lib.std.fs.path.extension()`
<TheLemonMan> yeah
<TheLemonMan> the debug problem is linked to the tokens_copy being defined twice
<TheLemonMan> same file, same line, different scope
<TheLemonMan> as expected it's because of the `inline for`
<TheLemonMan> fs.path.extension should use lastIndexOfScalar instead of lastIndexOf, that'd make it slightly faster than it already is
earnestly has joined #zig
ifreund has joined #zig
<mikdusan> heh crossed my wires on those two issues. fixed now.
<mikdusan> so debug issue is basically comment #8 here:
<mikdusan> well maybe not alloca-related. i haven't checked details enough.
<TheLemonMan> check out the unoptimized .ll file, do you see the same declaration for `tokens_copy` (from json.zig) ?
<mikdusan> grep tokens_copy a2.ll | grep dec
<mikdusan> call void @llvm.dbg.declare(metadata %TokenStream* %tokens_copy, metadata !9959, metadata !DIExpression()), !dbg !9973
<mikdusan> call void @llvm.dbg.declare(metadata %TokenStream* %tokens_copy22, metadata !9959, metadata !DIExpression()), !dbg !9973
<mikdusan> call void @llvm.dbg.declare(metadata %TokenStream* %tokens_copy25, metadata !9959, metadata !DIExpression()), !dbg !9973
<TheLemonMan> can you upload the reduced unoptimized .ll file too? I'll check if some optimization pass is mishandling the debug infos
<mikdusan> yup
<mikdusan> it manifested somewhere between opt --O1 and --O2
<TheLemonMan> you can try to pinpoint the offending passes with llvm's bugpoint
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
hidayat has quit [Quit: Connection closed]
recombinant has joined #zig
recombinant has quit [Client Quit]
<ikskuh> TheLemonMan: answering here to prevent spam:
<ikskuh> even then LLVM is not doing what i'm asking for:
<ikskuh> it's not setting rbx, but bl
<ikskuh> which has very different semantics
midgard has quit [Ping timeout: 264 seconds]
<TheLemonMan> the type itself decides what part of the register is updated, this behaviour is the same in C asm expressions (IIRC)
midgard has joined #zig
<ikskuh> hm
<ikskuh> then i consider this a footgun and should yield an error instead of silently emitting broken code
<TheLemonMan> I guess this is only a problem on architectures with "register views" (x86 and aarch64)
<ikskuh> yeah, but it's still a problem
<ikskuh> asm volatile("":: [_] "{rbx}" (@as(u1, 1)):);
<ikskuh> this is looking like it's setting rbx, but it's actually not setting rbx
<ikskuh> thus: footgun/bug imho
<TheLemonMan> yeah, that's definitely something the compiler should catch
cole-h has quit [Read error: Connection reset by peer]
knebulae has joined #zig
cole-h has joined #zig
<mikdusan> am I using `llc` wrong? if I can do this:
<mikdusan> `opt -O3 -S unoptimized.ll > optimized.ll; llc optimized.ll [SEGFAULT]`
<mikdusan> but this:
<mikdusan> `llc -O3 unoptimized.ll` does not segfault
<TheLemonMan> try adding -filetype asm
<mikdusan> no diff
<TheLemonMan> hmm, check if the optimization pipelines are the same (pass -debug-pass=Arguments to check them)
<mikdusan> ah. they're quite different
<mikdusan> trigger for the debug-info assert:
<mikdusan> opt -inline -sroa -S _unoptimized.ll > _custom.ll
<mikdusan> llc _custom.ll
supercoven has joined #zig
kbd has joined #zig
bitgestalt has joined #zig
bitgestalt has quit [Quit: Leaving]
qazo has quit [Quit: ...]
Guest91210 has quit [Quit: ...]
dyeplexer has joined #zig
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
hidayat has joined #zig
kragacles has quit [Quit: ZNC 1.8.2 -]
kragacles has joined #zig
nvmd has joined #zig
hnOsmium0001 has joined #zig
kbd has joined #zig
ky0ko has joined #zig
mokafolio has quit [Quit: Bye Bye!]
jmiven_ is now known as jmiven
hidayat has quit [Quit: Connection closed]
mokafolio has joined #zig
waleee-cl has joined #zig
Akuli has joined #zig
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
xackus_ has quit [Read error: Connection reset by peer]
xackus__ has joined #zig
craigo has quit [Ping timeout: 260 seconds]
viashimo has quit [Disconnected by services]
dyeplexer has quit [Remote host closed the connection]
ky0ko has quit [Remote host closed the connection]
hidayat has joined #zig
leroycep has quit [Ping timeout: 264 seconds]
ovf has quit [Ping timeout: 260 seconds]
ovf has joined #zig
<andrewrk> howdy TheLemonMan, thanks for the help recently troubleshooting our llvm 12 woes
<TheLemonMan> hiya, gotta get everything lined up and ready for the release
<TheLemonMan> if you have some spare cycles for #8007 I'll rebase it
* ifreund takes a look at the infinite loop in the parser TheLemonMan discovered
<g-w1> its not in the parser, its in fmt
<ifreund> you sure? gdb lead me to believe otherwise
<g-w1> it just throws a parse error for me
* g-w1 realizes that is the stage1 parser
<andrewrk> TheLemonMan, even C printf gets x/X. how come we don't get it in zig?
<andrewrk> oh I see, you made it not ambiguous, so it only works for integers
<andrewrk> ok, I'm game to merge it
<TheLemonMan> x/X on slices of u8 prints the usual { 0x.., 0x.., ... }, you can get the "condensed" hex format with the supplied formatters
<TheLemonMan> cool, I'll rebase it asap
<TheLemonMan> g-w1, the error is in the stage2 parser used by zig fmt
<g-w1> yep, I realized that :/
<ifreund> found it :)
<TheLemonMan> the tok_i -= 1 part is fishy
<TheLemonMan> and there are many occurrences of that
<andrewrk> TheLemonMan, it's part of the new strategy, the parser does less work and later you have to poke around the token_tags array to find information about the AST
<TheLemonMan> yeah, but the loop is now doing nextToken() -> tok_i -= 1
<TheLemonMan> it gets stuck in the loop for the time being
<ifreund> yeah I think it's wrong in this case, removing it doesn't cause any tests to fail
<ifreund> I'll try and add a test case for the desired recoverability in this situation
<TheLemonMan> look out for some other nextToken/tok_i-=1 pairs, I noticed at least two or three of them
<marler8997> g-w1, hey have you tried looking at that opensslstatic issue? I don't want to deploy binaries until we figure out why it isn't working on your machine
<g-w1> not yet, zigup works, just not google
<g-w1> ill debug more later
<g-w1> is anyone familiar with how the cbe allocates memory? im getting a weird leak in only one place here.
<g-w1> try bw.writeAll("typedef struct { "); try dg.renderType(bw, child_type); try bw.writeAll(" payload; uint16_t error; } "); this is weird, im only getting a leak on the third write
<ifreund> did you try valgrind yet?
<g-w1> no, i thought the gpa was enough; is it not?
<ifreund> I don't know, personally I'd give valgrind a try. It has saved me countless hours of debugging
<g-w1> also when I run it on the cli its doesn't leak, only in the test harness. something is fishy
<andrewrk> valgrind has a lot to offer zig programs because it will catch branch on undefined value, and zig has valgrind integration to mark `undefined` stuff
<g-w1> it did catch something :)
<andrewrk> gpa provides leak checking and a certain kind of memory safety but it will not catch branch on undefined
<g-w1> hmm is zig not catching something?
<g-w1> i used valgrind -s, never used b4
<g-w1> this is w/o -s
ifreund1 has joined #zig
<g-w1> seems like something is undefined
<andrewrk> g-w1, that's not catching anything, you'd be better to run without valgrind in this case to get the stack trace that zig is failing to print there
<g-w1> here that is, very confusing
<g-w1> ig ill try to figure out how the writer allocates
<g-w1> it seems like its just the gpa
ifreund has quit [Ping timeout: 264 seconds]
<ifreund1> g-w1: did you push your code yet?
ifreund1 is now known as ifreund
<g-w1> its probably something stupid :)
<ifreund> g-w1: I think the issue is your ` typedefs.clearRetainingCapacity();` call
<ifreund> you don't free the owned rendered slices stored in the map
<ifreund> (this is in updateDecl()
<g-w1> ah, thanks
freshmaker666 is now known as greeb
<g-w1> ah, it was probably the case since the test harness uses the same module? its always fun debugging code you didn't write but suspecting you wrote the bug
<ifreund> gotta get more paranoid :P
greeb has left #zig ["WeeChat 2.9"]
<ifreund> TheLemonMan: did a quick pass over std/zig/parse.zig but didn't find any other `p.tok_i -= 1; p.nextToken();` loops :)
<TheLemonMan> yay, no more infinite loops
<andrewrk> brilliant
<andrewrk> and thanks to FireFox317 we got zig-bootstrap up to speed with llvm12 branch
hidayat has quit [Quit: Connection closed]
LewisGaul has joined #zig
sord937 has quit [Quit: sord937]
craigo has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
LewisGaul has quit [Ping timeout: 240 seconds]
ed_t has joined #zig
<ed_t> think I have a compiler bug, which occurs in both 0.71 and 0.80git (from friday).
<ed_t> I've posted info in zig-help on the 'zig programming language' discord
<ed_t> the while loop at line 65 exits even though the previous print shows as false, which should mean it suspends
leon-p has quit [Quit: leaving]
Akuli has quit [Quit: Leaving]
xackus__ has quit [Ping timeout: 245 seconds]
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
kbd has joined #zig
<ed_t> opened: issue #8119
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
ed__ has joined #zig
ed_t has quit [Ping timeout: 240 seconds]
ed__ is now known as ed_t