<g-w1>
andrewrk: turns out the bug was that Module.zig was starting at 0 for errors and my "fix" in C.zig was just a stopgap solution for that :)
<g-w1>
off-by-one errors are the worst
xackus__ has quit [Ping timeout: 246 seconds]
sundbp has quit [Ping timeout: 240 seconds]
earnestly has quit [Ping timeout: 240 seconds]
<g-w1>
doing a fix now with a bunch of other stuff too
drsensor has joined #zig
paulgrmn has joined #zig
paulgrmn has quit [Ping timeout: 240 seconds]
<g-w1>
andrewrk: ok i just found a bug, but im not sure how to solve it, so basically when we do an incremental update and add an error with `error.A` then remove that error, and do an update, the error still stays in the Module. this is a problem because @errorToInt wont fail because the error exists in the Module even though it is not ever declared. what do you think is the best path of action here?
<g-w1>
should we track what errors belong to a decl and delete those when the decl is deleted?
<g-w1>
this is an unfortunate error :) (took me a very long time to debug as it was not triggering in the test harness, but was triggering on the cli). I will make my pr as it is done, but mention this in the pr
gazler_ has joined #zig
proteus-guy has quit [Remote host closed the connection]
forgot-password has quit [Ping timeout: 245 seconds]
<andrewrk>
s-ol, lol, glad you figured it out
<andrewrk>
mikdusan, yes, for `zig cc` with `-`, we'll need to either disable the cache system entirely, or write it to a temp file, perhaps named after the hash of the contents
<andrewrk>
would have to examine the existing code to figure out which path is more straightforward
ur5us_ has joined #zig
<andrewrk>
note that we do have a tmp directory within zig-cache/ already which can be utilized
<andrewrk>
ifreund, what are you using for the common parameters in (former) astgen.zig? was thinking we might want to avoid the unnecessary virtual call scope.getGenZir()
<andrewrk>
but we still do need to pass scopes too, for variable lookup, continue, and break
<andrewrk>
maybe GenZir would have a *Astgen field, Astgen would have a *Module field, and the functions would all start with: `gz: *Scope.GenZir, scope: *Scope` ?
drsensor has quit [Quit: Connection closed for inactivity]
hsh has quit [Quit: Connection closed for inactivity]
paulgrmn has joined #zig
paulgrmn has quit [Ping timeout: 268 seconds]
<g-w1>
andrewrk: what was wrong with the node_offset_builtin_call_arg0? I think it is accurate
<andrewrk>
g-w1, looks like it's doing exactly the same thing as the node_offset tag, right?
<g-w1>
+ 1 :P
<g-w1>
return token_starts[tok_index + 1];
<andrewrk>
won't that point to the ( ?
<g-w1>
no
<g-w1>
i thought it would, but it doesn't
<g-w1>
(unless my editor is messed up)
<andrewrk>
I think it should navigate via the AST to the node that is the first arg of the builtin call
<andrewrk>
rather than via tokens
<g-w1>
hmm, why? is there any case where it would be different?
<g-w1>
or just for consistency which I totally get
<andrewrk>
well you're going to need to do that for arg1 anyway, so it would be easier to maintain those side by side
<andrewrk>
it's also easier to reason about
<g-w1>
ok cool ill do that
<andrewrk>
also main_tokens is not the same as firstToken
<andrewrk>
if it was @foo(a + b); main_tokens will make it point at the + (or maybe when we improve things further it would underline the whole binary expr) but tok + 1 would make it point at the `a`
<g-w1>
ahh i see
ur5us_ has quit [Ping timeout: 258 seconds]
<andrewrk>
I didn't even realize that at first, it's just one of those things that doing it the "right way" avoids hidden footguns :)
<g-w1>
oh nice the ci is passing again
<andrewrk>
g-w1, regarding the O(N) @intToError, you can add an ArrayListUnmanaged to Module that tracks index->name
<andrewrk>
it and global_error_set can share the string memory
<g-w1>
you think this one case is enough to warrant that?
<g-w1>
@errorToInt at comptime
<andrewrk>
yeah because O(N) is a potentially high cost, and there is only 1 Module, so those extra bytes of that index are real cheap
<g-w1>
ok, makes sense
<andrewrk>
on the other hand, if we had to implement @intToError without changing the language, it would mean adding a hash set to every Decl (set of referenced error names) and a reference count to every error value
<andrewrk>
this would be a high cost because there are many Decl and many error values
<g-w1>
yeah, that would be bad
<g-w1>
hmm im confused about the way I should impl node_offset_builtin_call_arg0. this works const node = decl.relativeToNodeIndex(node_off) - 1;, but this doesn't const node = decl.relativeToNodeIndex(node_off) + 1;
<g-w1>
how can the - 1 work? is there some inverse logic?
<andrewrk>
look at node_offset_for_cond for example
<andrewrk>
the node is already correct - it is the node index of the builtin call. you need to use the AST tree data to navigate to parameter 0
<andrewrk>
so you probably need to grab that logic from the switch in render.zig
<g-w1>
hm ok
<andrewrk>
this is the "lazy" part being resolved
<andrewrk>
the key thing here is that this thing where we poke around in the nodes/tokens arrays didn't have to happen in semantic analysis for stuff that didn't have any compile errors
<g-w1>
oic, changing the node was just blindly fumbling
<g-w1>
the one downside of this dod change is that it reduces understandabality
<andrewrk>
yes, some things became more complex
<andrewrk>
although I think this particular change is less related to dod and more related to making source locations survive incremental updates
<andrewrk>
remember that we had some incorrect test cases before
<g-w1>
yes, this makes it much more accurate which is good
<g-w1>
hmm, i didn't need a switch, const first_arg = node_datas[node].lhs; worked, am I doing something wrong?
<andrewrk>
the interpretation of lhs and rhs are defined by the node tag
<andrewrk>
check out lines 610-622 of render.zig
leon-p has joined #zig
forgot_password has quit [Ping timeout: 250 seconds]
<g-w1>
ok andrewrk i think I did it correct this time :)
<g-w1>
sorry for the hastle
<andrewrk>
np, thanks for the patch!
bbuccianti2 has left #zig ["Leaving"]
bitmapper has quit [Quit: Connection closed for inactivity]
<spacelove>
I'll check back in the morning, but the question I'm trying to resolve is: is there a way to build the graph (datastructure) in that program during compilation, instead of each time the program is run? It takes several minutes to build the graph, but only moments to run the search (that searches on the graph)
<spacelove>
Maybe there's a more idiomatic way to do this, I'm not sure.
xackus__ has quit [Remote host closed the connection]
xackus__ has joined #zig
<cepheus>
out of interest, zig is able to coerce `s orelse null` into [*c]u8 where `@TypeOf(s) == ?[:0]u8`, but not just s by itself?
<cepheus>
s/zig is/why is zig/
<cepheus>
(this is 0.7.1, things may be different on master, haven't checked)
xackus has joined #zig
spacelove has quit [Ping timeout: 240 seconds]
xackus__ has quit [Ping timeout: 268 seconds]
qbit has joined #zig
spacelove has joined #zig
<spacelove>
Does the zig stdlib have a way of writing variables to file? I can see how this might work: var f = try fs.Dir.writeFile(fs.cwd(),"file.dat", "test"); but what about if I want to write non-string data?
<spacelove>
I am trying to pre-compute that graph, so basically I'm trying to write a hashmap to file
<spacelove>
buildGraph returns a graph, and if I want to know if there's a way to avoid rebuilding the graph every time I run the program. I thought comptime was the answer but it doesn't seem to work yet
<spacelove>
So I thought I could write it to file, then include it, then somehow compile like that.
<g-w1>
you cannot write a hashmap to a file, since zig does not know what to do with it
<g-w1>
i reccomend iterating over the hashmap and then writing the key and value to the file
<spacelove>
Oy vey
<spacelove>
Is there a simpler way to accomplish this. Like something a programmer would be like, "oh you don't write to file to precompute, you do X"
<g-w1>
im not sure
<g-w1>
in the future comptime stuff would be cached
<spacelove>
Alrighty
<spacelove>
The problem is that the values are themselves arrays of strings
<spacelove>
Seems like a nightmare
<spacelove>
Maybe there's a way to write like the pure binary data to file
<g-w1>
sounds like you want serialization
<g-w1>
not sure there is a way to do that with a hashmap since it contains pointers and stuff
<spacelove>
Mamma mia
<ifreund>
you can serailize it into a simple list of keys/values and the deserialize back into a hashmap
<spacelove>
I can try that. Are there docs on serialization?
<g-w1>
spacelove: stuff can be precomputed at comptime as long as you dont mind extra compilation time.
<spacelove>
I don't. That's what I want to do
<g-w1>
ok makes sense
<spacelove>
But it seems like there's no way to precompute a hashmap at compile time
<g-w1>
what is the type of your hash map?
<spacelove>
StringHashMap. It's in the zigbin.io file.
<g-w1>
if its string tosomething use ComptimeStringMap
<g-w1>
it does not support dynamically adding stuff, so I reccomend putting stuff in a comptime array, and then transrefing it to that when you are done
<spacelove>
"Like ComptimeStringHashMap but optimized for small sets of disparate string keys." if I have 70k words... will it still work?
<spacelove>
That was my concern.
<spacelove>
Thanks for that talk btw.
<g-w1>
i think compitmestringmap would still have better performance than dynamically loading stuff from a file at runtime
<spacelove>
Yea I mean, my use case is, I only need to build this graph once, then the program can run forever
<spacelove>
So if ComptimeStringMap can do that that seems ideal
<g-w1>
well you can only build it once at compitme
qbit has quit [Quit: leaving]
qbit has joined #zig
cole-h has joined #zig
yyp has joined #zig
<ifreund>
spacelove: ComptimeStringMap will likely be very inefficent with 70k keys
<ifreund>
especially if many of those keys are the same length as others
<ifreund>
you're probably better off either embedding your 70k strings in your binary and building a normal hashmap at runtime or using the implemention from https://github.com/ziglang/zig/pull/5359
<vent>
Probably not a zig question, but I'm printing to stdout with terminal escape sequences to add color. Only, my terminal is not interpreting the escape sequences. I can verify the sequences are correct, as if I echo each line with `-e`, the colors all come out correct.
<vent>
To clarify, when I run the program, the escape sequences just get printed to the terminal like this: http://ix.io/2UnL
<g-w1>
how do you write the escape codes in your zig program?
<Nypsie>
You must write your escape sequences using '\x1b['
<vent>
g-w1: The codes are just written to the char buffer like any other string. That buffer is then printed to stdout.
<vent>
Ah, yeah I see what you mean. I was escaping the backwards slash in my escape character
<vent>
Yep, got it by changing the escape char from "\\033[" to "\x1b[". Thanks!
jokoon has joined #zig
<Nypsie>
You're welcome! :)
yyp has quit [Quit: now it's safe to turn off your computer]
cole-h has quit [Ping timeout: 240 seconds]
Akuli has joined #zig
jokoon2 has joined #zig
jokoon has quit [Ping timeout: 246 seconds]
dongcarl has quit [Ping timeout: 265 seconds]
neptunepink has quit [Ping timeout: 276 seconds]
fputs has joined #zig
osa1 has quit [Read error: Connection reset by peer]
yyp has joined #zig
neptunepink has joined #zig
slevin11 has joined #zig
slevin11 has quit [Quit: Connection closed]
hsh_ has quit [Quit: Connection closed for inactivity]
jokoon2 has quit [Quit: Leaving]
osa1 has joined #zig
spacelove has quit [Quit: Connection closed]
dyeplexer has quit [Remote host closed the connection]
artmb has joined #zig
<artmb>
Hi all. I am trying to play with std lib code.But I am getting "import of file outside package path: '../std.zig' " when I ma trying to run a test: zig test lib/std/fmt/parse_float.zig
<g-w1>
use --main-pkg-path .
<artmb>
thanks. what is exactly a package path?
bitmapper has joined #zig
<g-w1>
it is where things can import stuff from
<artmb>
without setting this flag: `--main-pkg-path` zig will fallback to a basedir of source file ( lib/std/fmt/ in my case)?
<g-w1>
i think so
<ifreund>
yep
artem1 has joined #zig
artmb has quit [Quit: Connection closed]
<artem1>
exit
<artem1>
rxit
<artem1>
exit
artem1 has quit [Client Quit]
artmb has joined #zig
<artmb>
J
artmb has quit [Quit: WeeChat 3.0.1]
xackus_ has joined #zig
xackus has quit [Ping timeout: 252 seconds]
Nilium has quit [Quit: <kristin> Cower is like... I dunno. sometimes he seems senile and other times he seems like a middle schooler.]
Nilium has joined #zig
<ifreund>
andrewrk: currently working on switching the first paramter of the various astgen functions to be a *GenZir insted of a *Module, should be done pretty soon if you want to avoid conflicts
<andrewrk>
thanks for the heads up! I'm doing error sets, not worried about conflicts
<ifreund>
yeah, conflicts shoudn't be too bad :D
<ifreund>
renaming the file is already done
<ifreund>
part of me really wants to just make the gpa global for the self hosted compiler, but part of me feels like that would be un-ziggish
<ifreund>
justification is that there's no situation in which we want two gpas
<ifreund>
and then we don't have to take the (addmittedly light) memory/perf hit of passing it around
<ifreund>
I already made my gpa global in river :D
<andrewrk>
I'm fine with making gpa global
<andrewrk>
only reason I can think of to not do it would be if we were trying to debug some tricky thing, it could be useful to pass a different allocator to a different component
<andrewrk>
maybe let's not do it quite yet
<ifreund>
yeah, it definitely doesn't need to happen on this branch
<andrewrk>
btw I'm guessing you knew this but most of those perf ideas in BRANCH_TODO I was planning on filing an issue for and not blocking the branch on them
<ifreund>
makes sense
<g-w1>
andrewrk: fyi i think i fixed the remaining issues in the pr. also error sets 👀. are you doing lazy stuff for them?
<andrewrk>
I'm making them implemented similar to functions
<g-w1>
are they Decl s?
<andrewrk>
g-w1, do you mind rebasing after ifreund's commits?
<g-w1>
ill rebase
<g-w1>
that was ez lol
<g-w1>
pushed
<ifreund>
got one more coming soon, though it hopefully won't be too bad either
<ifreund>
sorry for the conflicts
<g-w1>
hmm, i think the caching system might be messed up. every time i do `./build-zirm-rel/zig build test-stage2 -Denable-qemu` it rebuilds the test suite even if i change no source files
<g-w1>
this only happened after the rebase
<ifreund>
g-w1: I think you need to do a cmake rebuild due to the file rename
<g-w1>
ahh, cmake is the worst
dimenus has quit [Quit: WeeChat 3.1]
<g-w1>
ifreund: typo in translate-c.zig return @import("Astgen.zig").simple_types.has(name);
<ifreund>
urgh, I thought I did full rebuild
<andrewrk>
probably didn't -Denable-llvm which disables translate-c
<ifreund>
ah, yeah that'd be it
ur5us_ has joined #zig
<ifreund>
g-w1: pushed a fix, thanks
yyp has quit [Quit: now it's safe to turn off your computer]
g-w1_ has joined #zig
g-w1_ is now known as g_w1
g-w1 has quit [Ping timeout: 252 seconds]
cow-orker has joined #zig
<ifreund>
and pushed the astgen parameters change, sorry for any conflicts. This time I did build with -Denable-llvm though :)
<g_w1>
the rebase was pretty smooth this time
<ifreund>
that was quick indeed :)
<ifreund>
man the result location stuff is so clean in stage2
<ifreund>
(reading the comments on g_w1's PR
jokoon has joined #zig
<ifreund>
anyhow I'm off for the night so don't worry about me causing any more conflicts
g_w1 is now known as g-w1
<g-w1>
ah all i have to do is toUnsignedInt
paulgrmn has joined #zig
<g-w1>
the .{ .ty = u16_type } makes sure that it is an int, that *is* very clean