<daurnimator>
I think `zig-cache` is a good name for it
<FireFox317>
andrewrk, to repro the memory leak: change `want_debug_deadlock` in Cache.zig to true, run `zig build test-stage -Denable-llvm`. It will then show the memory leak of `all_cache_digest_set`.
<FireFox317>
Thanks for merging my PR that fast btw :)
<FireFox317>
I tried to solve that leak by making `all_cache_digest_set` pub and calling `deinit` on it, but that caused the segfault
SimonNa has quit [Quit: Leaving]
SimonNa has joined #zig
marijnfs has quit [Quit: WeeChat 2.8]
DrDeano has quit [Ping timeout: 245 seconds]
ur5us_ has quit [Ping timeout: 264 seconds]
ur5us_ has joined #zig
mikdusan has quit [Quit: WeeChat 2.5]
<andrewrk>
g-w1, re: branch quota - why do we need to the Shared struct stuff?
<andrewrk>
*why do we need to change
<andrewrk>
I think it was already set up correctly
<andrewrk>
FireFox317, ok let me poke at it
fputs has joined #zig
<g-w1>
because the inlining shared only works in comptime function calls
<g-w1>
we want @setBranchEvalQuota to work outside of comptime function calls. there was a discussion on discord about this in #zig-help recently.
<g-w1>
they were correctly in *a* shared struct, but it was nothing outside of a inlining context when inlining == null. Am I seeing something wrong?
<g-w1>
right now it makes no difference, because the only way to have branch_count overflow go over branch_quota is through inline calls, but in the future, a comptime while could to it too, and that could be outside of a comptime/inline function
<andrewrk>
I see, thanks!
notzmv has quit [Remote host closed the connection]
SebastianKeller has quit [Remote host closed the connection]
<andrewrk>
g-w1, sent you a review
<g-w1>
thanks
notzmv has joined #zig
<andrewrk>
welp, windows CI is no longer able to build zig1.obj without running out of OOM. rip
<fengb>
Did andrewrk just OOM?
<g-w1>
andrewrk: in your review you say "
<g-w1>
This is indeed where branch_count should be initialized to 0.
<g-w1>
what if this is in the middle of a comptime while that has backwards branches?
<g-w1>
sorry for the extra lines, my clipboard put them in when copying
benjif has quit [Quit: Leaving]
<andrewrk>
g-w1, look at the comment directly above that
<andrewrk>
.shared = if (b.inlining) |inlining| inlining.shared else &shared_inlining,
<g-w1>
I see, consider this example (at comptime ofc) `b=false;while (true) { if (b) comptime foo(); b = random_bool(); }` in the while there could already be a brancheval before it is called
<g-w1>
and for the 1001 test, should we just set it? or also make something overflow to it?
<g-w1>
hmm, still if we put the branch_count in the Inlining.Shared, then it can't be used outside an inline function? or am I missing something :)
notzmv has joined #zig
<andrewrk>
FireFox317, did the Cache deadlock detection code detect the deadlock when you ran into it?
<andrewrk>
or did you actually hit a deadlock and have to figure it out
<andrewrk>
oh I bet you hit it because it was 2 different processes
<andrewrk>
god damn it I'm just going to delete the detection code since it can't even help in these cases
<andrewrk>
g-w1, inline function calls and comptime function calls are the same thing. however I think you're right that this will need to be adjusted to support inline while
<andrewrk>
I think we should only make the change once we can actually add a test case to exercise the necessity of the change
<andrewrk>
because afaik we don't have inline while working yet
<g-w1>
How can the change be not nesessary? it would make the implimentation of analyzeInstSetEvalBranchQuota more complicated because we have to check if inlining != null and then do something temporary if inlining == null when trying to set branch eval quota. I am trying to get away from a local maximum.
<andrewrk>
I'm saying that branch_quota should not be inside Shared but branch_count should
<andrewrk>
since there are 2 shared things, let's name them better
<andrewrk>
FireFox317, this fixes the memory leak for me, no segfault: https://clbin.com/ZYSHA
<g-w1>
that looks good, but imo branch_count should not be in Block.Inlining.Shared, but in Block.Shared, or just a *u32, and since there are 2 of them, I just put them together.
<andrewrk>
we only want to start counting branches when you do inline while, inline for, inline call, or comptime call
<g-w1>
exactly. but an inline while/for wont trigger a Block.Inlining to be created, therefore how can you count branches if the it is in the Block.Inlining?
<andrewrk>
idk, I don't think we have to figure that out in order to add the first version of @setEvalBranchQuota
<andrewrk>
I don't think it will be difficult to adjust the structs if we need to
ur5us has joined #zig
<g-w1>
what should happen if you use it out of an inline function? that is why I added those things, to help our future selves and remove thinking about what it should do
ur5us_ has quit [Ping timeout: 258 seconds]
<andrewrk>
it wouldn't help our future selves because we only use it in an inline function currently, and our future selves will happily move the field into the outer struct, knowing it was only ever read (until now) for inline functions
<g-w1>
ah, I see
<andrewrk>
*it would help*
<g-w1>
thanks for going through this with me :)
<andrewrk>
np, thanks for the patch, and also this is partly subjective so thanks for listening to my input
<andrewrk>
if we have the field outside the branch, our future selves will have to inspect the code more carefully to understand how the field is used
<andrewrk>
oops, I meant outside the Inlining.Shared struct
layneson has quit [Quit: WeeChat 2.9]
FireFox317 has quit [Ping timeout: 260 seconds]
blueberrypie has joined #zig
<g-w1>
running into this when trying to make that minimal test case :9:12: error: TODO implement set stack variable with large stack offset
<g-w1>
can you zoom in on one of those towers to show all the functions called?
<andrewrk>
yep
<andrewrk>
did you get tracy working for you?
<g-w1>
I had some trouble with one of the libs, but what ill do is just use the source from the version with the same binary on nixos
<g-w1>
ill try it soon
<g-w1>
oh we also need to know what to do when you do zig run with -ofmt=c
<g-w1>
maybe just sub-call zig run on the c file?
<andrewrk>
g-w1, I think your test case will fail
<g-w1>
why?
ur5us has quit [Ping timeout: 264 seconds]
<andrewrk>
I think y == 1
<g-w1>
thats what I thought, but it passes on my machine?
<andrewrk>
when you say it passes you mean you are running `zig build test-stage2 -Denable-llvm` ?
<andrewrk>
-Denable-llvm is required for `zig run` to support .c files
<g-w1>
yes, it also passes with y - 1
<g-w1>
so probably a bug in the cbe
leon-p has quit [Quit: leaving]
<g-w1>
it actually deadlocks with -Denable-llvm?
<g-w1>
but just doing `-Denable-qemu` runs the cbe test
<g-w1>
ill update it to y - 1 just so that in the future it will work
<andrewrk>
g-w1, in your "this is fast" code example it uses a comptime parameter which is not supported by stage2 yet so that's just a runtime call and it looks like the detection of a runtime call in a comptime block didn't trigger an error
<g-w1>
the @compileLog worked
<andrewrk>
wait, never mind, because it's in a comptime scope, so the parameter doesn't matter
<andrewrk>
with stage1?
<g-w1>
does it not work for you?
<andrewrk>
error: no entry point found
<g-w1>
with stage1 yeah
<g-w1>
stage1 is faster than stage2
<g-w1>
*in this example
<andrewrk>
that's the correct answer too
<andrewrk>
I wonder what's taking up all the memory
<g-w1>
we may just need some hot paths. i gtg now, but later in the week ill do some profiling if I can get tracy to work
<g-w1>
the hot paths to shorten those "towers"
<andrewrk>
stage1 faster than python3 for this example too...
<andrewrk>
wtf
<g-w1>
zig comptime would be a very nice interpreted language if we added io to it
<g-w1>
ooooooooohhhhhhhhhhhhhh
<g-w1>
its the memoized fn calls!!!!!!!
<g-w1>
i was thinking abt how u usually speed up fib and then figured out by dynamic programming :P
<kbd>
Also I'm not sure what I'm supposed to make the return type of `buildFuncMap`.
waleee-cl has quit [Quit: Connection closed for inactivity]
mikdusan has joined #zig
<mikdusan>
kbd: change return type from `type` to `std.StringArrayHashMap(*const @TypeOf(hello))` ; using the former forces fn to be comptime. you don't want that here.
<kbd>
that all makes so much sense, ty. I didn't understand the error message.
<kbd>
Specifying types is the hardest part of Zig for me so far. Hence just making a function and taking its type instead of figuring out how to specify the function type inline.
<mikdusan>
a neat lang enhancement would be to allow function (the parameters) and return type to INSERT the function body for global name resolution. so in body it would be nice to `fn (...) T { const T = ....; var T ....; };` but that would have shadowing issues. maybe a builtin to anchor that scope: `fn buildFuncMap() #body.T { const T = std.StringArrayHashMap(...); };` and nope this still wouldn't solve shadowing
<mikdusan>
issues.
<mikdusan>
related, return type inference is not a feature of the language (which is what I think your code was originally trying to do). https://github.com/ziglang/zig/issues/447
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #zig
<kbd>
Here's how I got there actually... Originally I had `std.StringArrayHashMap` as the return type, not realizing that the full type is `std.StringArrayHashMap(*const @TypeOf(hello))`. Then I followed error messages and maybe something in the stdlib to get there. And I didn't understand how comptime works, now I get that the `std.StringArrayHashMap(*const @TypeOf(hello))` is comptime and the `.init(A)` is runtime, after reading the source of
<kbd>
StringArrayHashMap.
<kbd>
I didn't expect type inference and was sure "type" was wrong, but it compiled if `var funcmap = buildFuncMap();` was commented out, so it was legal... but again I didn't understand comptime. Makes sense now, thanks again :)
<mikdusan>
>but it compiled if ... was commened out <-- just to be clear, that's because zig is lazy and won't resolve / compile buildFuncMap until something needs it
cole-h has quit [Quit: Goodbye]
<kbd>
I was just typing out that that was behavior I still didn't understand :)
<kbd>
I didn't understand why the compiler didn't figure out until it was "called"... at compile time... that passing the allocator was a runtime thing.
<mikdusan>
heh this is valid zig source... as long as you don't use `whatever` --> `const whatever = @import("import me. I dare you");`
<kbd>
so that I don't have to `@TypeOf(hello)`, what's the right way to specify hello's type inline?
<daurnimator>
kbd: for a function with an inferred error set there isn't a better way
<kbd>
oh, that explains the error I'm getting lol
<mikdusan>
if it was not inferred... then `HashMap(*const fn() void)` would let you avoid builtin @typeOf()
<kbd>
cause `fn hof(myfunc: *const fn () !void) !void { try @call(.{}, myfunc, .{}); }` gives "inferring error set of return type valid only for function definitions" and I didn't understand that at all.
<kbd>
ty daurnimator
<kbd>
and mikdusan
x1212 has joined #zig
sord937 has joined #zig
Patrice_ has quit [Ping timeout: 264 seconds]
midgard has quit [Ping timeout: 260 seconds]
Biolunar has quit [Ping timeout: 260 seconds]
Biolunar has joined #zig
midgard has joined #zig
FireFox317 has joined #zig
<FireFox317>
andrewrk, yep indeed the detection code did not detect it. I've been pretty good at figuring out why it deadlocks now :P
<FireFox317>
I see you just removed the code
sord937 has quit [Ping timeout: 240 seconds]
sord937 has joined #zig
<FireFox317>
g-w1, the deadlock is probably caused by your current zig compiler not being master (you also have to recompile that with make/ninja)
gazler has joined #zig
BaroqueLarouche has quit [Quit: Idle for 30+ days]
ur5us has joined #zig
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
sord937 has quit [Remote host closed the connection]
gazler has quit [Remote host closed the connection]
gazler has joined #zig
sord937 has joined #zig
hch has quit [Ping timeout: 256 seconds]
hch has joined #zig
ur5us has quit [Ping timeout: 258 seconds]
Sarwaz has joined #zig
nullheroes has joined #zig
<Sarwaz>
Hello!
<Sarwaz>
I am used to C preprocessor where I usually have a DEBUG define that I use to wrap code that I only want to be compiled in debug mode, for example if I want to perform certain assertions or output logs. What would be the equivalent way of achieving these things in Zig?
<ikskuh>
you can just make a bool const for that
<ikskuh>
or switch on std.builtin.mode
<ikskuh>
if(std.builtin.mode == .Debug) { … }
<ikskuh>
the … is only compiled in when you do a Debug build
<dutchie>
yeah, ifs whose condition is known at comptime are guaranteed to not have the "other" branch compiled
Patrice_ has joined #zig
<Sarwaz>
ok, and is Zig compiler smart enough to remove a function call if my function does not do anything in debug mode?
<Sarwaz>
I mean, imagine a function that starts with if(std.builtin.mode == .Debug) and do nothing otherwise
<Sarwaz>
will there be any overhead for calling the function and evaluating the if statement or will it be completely removed in non-debug builds?