<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 std.io.writer
<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?
<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>
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.
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? https://clbin.com/vBmHu 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
<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
<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