<daurnimator>
andrewrk: I think my question needs a bit of design consideration: how can both fields and methods exist in the same namespace? ==> should we error on conflicts? or alternatively: do we need a different method call syntax to field access syntax
<andrewrk>
I do agree it's worth having some design discussion about that
<scientes>
@hasField is coded, but pending a decision on the issues that it brought up
<tgschultz>
I like the idea of eliminating `var` as a parameter un-type, since it's overloaded already. That said, I agree with andrew that it is closely related to runtime-interfaces. That's a tricky problem. My idea was a new container that performed type-erasure compiled in runtime circumstances, but even that still has issues. Like, if you stored a an interface in your struct it would become type-erased behind your back and mysteriously
<tgschultz>
lose all error set information.
<andrewrk>
that's another thing I want to solve with this is error sets, and maybe even const/non-const is related?
<andrewrk>
or at least have a plan for all of these things at the same time
shritesh has joined #zig
<tgschultz>
ErrorSets are tricky in this. If we could assign each unique error set encountered at compile time a unique id that could also be stored, then we could keep that in an interface, but if we're going to do that why not also assign each type a unique id and embed that as well? If I'm thinking about this correctly, that could be a hidden field in debug/safe... wait, that sounds familiar.
<tgschultz>
also it seems like errorset inference could be dependency looped under that circumstance
<tgschultz>
but yeah, if we could do that, then we could solve runtime interfaces at least within the same compilation unit. Doesn't seem solveable beyond that anyway.
<tgschultz>
Unless you wann go full COM dispatch... which I really don't recommend.
hio has quit [Quit: Connection closed for inactivity]
<tgschultz>
ah yes, it sounds like #1119, that's why its familiar
<daurnimator>
hryx: ah yes! thanks. I couldn't find it
shodan45 has quit [Quit: No Ping reply in 180 seconds.]
<shritesh>
Should I update the instructions for building Zig on Windows to use VS 2019? The 2017 link requires you to sign in with MS and the instructions don't work with 2019.
<andrewrk>
shritesh, yes please
<daurnimator>
andrewrk: so I'm feeling a little overwhelmed by the allocator work... do you have criteria for an MVP?
<daurnimator>
I also did it with headers... looking around: all the modern malloc replacements use a process-wide radix tree
<daurnimator>
wondering if I should redo it
<daurnimator>
(though my radix tree would be allocator-specific)
<shritesh>
andrewrk, done. I have also modified the instructions to only install the Build Tools rather than the full blown Visual Studio Community edition
<andrewrk>
thanks!
<shritesh>
Does the link to llvm/clang 7.0 still need to be there?
<andrewrk>
no
<shritesh>
removed
<emekankurumeh[m]>
for interfaces I'm a fan of #1214
<tgschultz>
#1214 doesn't solve error sets. Aside from some sugar it actually appears to me to be identical to status-quo interfaces, actually, which we know don't optimize well.
<tgschultz>
ok, I've hit the part of rewriting the allocator interface where nothing is testable until I rewrite half of debug too. Time for bed I think.
<emekankurumeh[m]>
after the coroutine rewrite, you won't be able to abstract over async functions return types, right?
<hryx>
I've never implemented LSP but won't it be blocked on the async/coroutine overhaul anyway?
<daurnimator>
maybe? but the underlying functions can probably be written?
<hryx>
the main thing the parser rewring brings is making parsing changes hella more contributor friendly -- perhaps the LSP implementation will benefit from that
shritesh has quit [Read error: Connection reset by peer]
gamester has joined #zig
<gamester>
parser rewrite? Writing the second stage parser?
<hryx>
in case anyone else wants to run `valgrind --tool=callgrind bin/zig fmt (find ../std -type f -name "*.zig")`
<hryx>
fun fact 2: std has 310 zig source files
<hryx>
which won't be a problem once zig fmt can operate recursively on a directory ^_^
<andrewrk>
hryx, I thought it already did that
<hryx>
andrewrk: derp. you are right. I misread the usage and (ashamedly) didn't even try to pass a dir argument
<andrewrk>
no worries, when everything is constantly changing it's hard to be on top of what does what :)
<andrewrk>
nice perf stats!
<hryx>
thanks! playing around with kcachegrind tonight in case it reveals any more useful information about the change
<andrewrk>
the other thing to fiddle with is possibly using ArrayList instead of SegmentedList, but I think that's a separate issue
<andrewrk>
even LinkedList might actually perform well because the parser uses an arena and so the items would likely be adjacent? idk it's worth playing with in that separate issue
<andrewrk>
I think it's safe to say that the easier maintenance of the recursive version comes with fundamentally better performance characteristics. win-win, no brainer
<hryx>
that was a pleasant bonus
<hryx>
re: SegmentedList, it looks like SegmentedList.addOne() takes roughly 26% of calls/time in both branches
<andrewrk>
really loving this detailed writeup. I was sad to see the snake, cow, and whale go
<hryx>
I was sad to let them go. thanks for noticing
<andrewrk>
hryx, if you want to rebase feel free. I don't see it as necessary
<daurnimator>
andrewrk: ah, heh
<daurnimator>
andrewrk: any response on how this might unblock LSP (615)
<andrewrk>
I think hryx is correct re: contributor friendly and the main blocker is async/coroutine overhaul
<andrewrk>
LSP and doc generation are both really important but I don't fancy maintaining a non-self-hosted implementation
<hryx>
andrewrk: regarding rebase or not, let me run through the commit messages real quick to make sure there isn't anything vulgar etc. in there. If all clear, let's go with the simpler merge commit approach as you mentioned
<hryx>
I tend to add some flare to my commit messages, which isn't always appropes
<daurnimator>
andrewrk: can't it be self-hosted though in at least the same style as translate-c2
jevinskie has joined #zig
<andrewrk>
daurnimator, that's worth thinking about but the problem is that unlike translate-c the interface between the c++ code and the zig code would be much larger, and not the same interface between stage1 and stage2. the stages will have entirely different ways of representing compilation & analysis
<andrewrk>
the beauty of code sharing with translate-c is how it's exactly the same interface regardless of whether it's stage1 or stage2
<andrewrk>
that applies to the caching system too - that can move to self-hosted
shodan45 has joined #zig
scientes has quit [Ping timeout: 244 seconds]
marmotini_ has joined #zig
<lunamn>
I was thinking for a bit while using translate-c and thought if it takes care of removing declarations that aren't used in the original c code, mostly because the output got confusing when I wanted to find the original functions, so, does it?
<lunamn>
andrewrk, sadly, no, does it help that I'm linking against libc? it gets confusing when the declarations from it's headers leak into the output, when they aren't used in either the original or output code (I can be wrong about the output zig code using them, though)
<andrewrk>
I don't understand your question
<andrewrk>
what behavior are you seeing, what are you expecting?
<lunamn>
suppose I have some original C code that includes stdio.h to open/read/write a file, and I run translate-c over it
<lunamn>
what I see is that all of stdio.h gets imported into the output, including things that are unrelated to the functions I used. if I, for example, used fwrite(), I also got the declarations for getw() after running translate-c, that look disconnected from what I originally used
ltriant has quit [Quit: leaving]
<andrewrk>
ah ok I'm following along - and then the question is whether the extra stuff ends up bloating your program, yes?
<andrewrk>
zig has lazy top level declaration analysis - if something isn't referenced then it isn't even semantically analyzed
<lunamn>
well I wouldn't say bloating the program itself when I'm compiling the output zig code, but rather readability of that output
<andrewrk>
I'm going to bed, good night. feel free to open an issue explaining your question and any proposals for different behavior you have
<lunamn>
that's fine, thank you!
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined #zig
hio has joined #zig
Ichorio has joined #zig
Ichorio has quit [Ping timeout: 246 seconds]
allan0 has joined #zig
return0e has joined #zig
return0e has quit [Remote host closed the connection]
return0e has joined #zig
JinShil has joined #zig
avoidr has joined #zig
JinShil has quit [Quit: Leaving]
avoidr has quit [Quit: leaving]
rivten has joined #zig
marmotini_ has quit [Remote host closed the connection]
scientes has joined #zig
rivten has quit [Quit: Page closed]
Zaab1t has joined #zig
Zaab1t has quit [Client Quit]
gamester has quit [Remote host closed the connection]
alot has joined #zig
bheads______ has left #zig [#zig]
gamester has joined #zig
gamester has quit [Remote host closed the connection]
<gamester>
andrewrk: yeah I knew about that code, I was just doing a sanity check by copying a lib from /usr/lib64 to /usr/lib, and instead then it's found
<gamester>
indeed*
gamester has quit [Read error: Connection reset by peer]
gamester has joined #zig
avoidr has joined #zig
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
wootehfoot has joined #zig
meheleventyone has joined #zig
r1b has joined #zig
very-mediocre has joined #zig
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined #zig
<tgschultz>
uh, compiler asserts are so annoying to debug
<andrewrk>
tgschultz, have you figured out the trick of printing the source file / line / column?
<tgschultz>
nope, please enlighten me?
<andrewrk>
now that I think of it, it would be pretty easy to have an assert that did that automatically
<andrewrk>
anyway, if using a debugger, go up the stack until you find a AstNode* or a IrInstruction*
<andrewrk>
instruction->source_node gets you to AstNode*
<tgschultz>
it's almost always a comptime access of an undeclared identifier, but working out where and how can get a bit troublesome.
<andrewrk>
(gdb) p source_node.owner.data.structure.root_struct.path[0]
<andrewrk>
(gdb) p source_node.line + 1
<andrewrk>
let me look into that assert thing real quick.
<tgschultz>
ok, that's good to know, but now I have to go work out how to use gdb
<donpdonp>
im trying to convert a *struct to an array of bytes (to send over a pipe). whats the right way to do the conversion?
<tgschultz>
that assumes you won't be modifying the bytes
<tgschultz>
if you need them mutable and have to make a copy: var bytes = std.mem.toBytes(my_struct_ptr);
<gamester>
*const [size]u8 works
<donpdonp>
gamester: woah. okay. const can show up in so many places o^O
<donpdonp>
tgschultz: that looks clean/zig-ish. thx
<donpdonp>
python adherents are pythonistas. rust adherents are rustaceans. what are zig adherants?
<tgschultz>
assertion appears to occur in std.event tests. Probably has to do with async<>. I was really hoping that keeping the struct fields it was expecting would be enough.
* donpdonp
asks the tough questions
<tgschultz>
programmers
<donpdonp>
ha
Zaab1t has joined #zig
<tgschultz>
I'll bet async<> is also insisting on the allocator being a pointer
Zaab1t has quit [Remote host closed the connection]
<andrewrk>
tgschultz, is the stack trace printing working? which assert is it tripping?
<tgschultz>
all I get is "Assertion failed. This is a bug in the Zig compiler.", I'm running linux with a master from at most a few days ago
<tgschultz>
alright. if you need more info I can push the current state of the branch and you could pull that. i've only touched std so far.
<tgschultz>
or if its a few quick gdb commands I can enter those, it's still running for now
<andrewrk>
I'm not actually fixing the bug, just doing a meta thing
<TheLemonMan>
intCast or the shift itself failed
<donpdonp>
given struct {id: u16, payload: union{a: u16, b:u16}}. how do I create an instance of that anonymous union? im trying MyStruct{.id = 4, .payload = {.a = 1}} but it doesnt like it
<andrewrk>
tgschultz, pull master and try your assertion failure again
<andrewrk>
it should print `when analyzing file:line:column: assertion failed`
<andrewrk>
I didn't convert all the asserts yet, but that should help. I'm not sure why it's aborting rather than printing a stack trace for you
<tgschultz>
andrewrk: ok, one sec. donpdonp: `MyStruct{.id = 4, .payload=@typeOf(@field(MyStruc, "payload")){ .a = 1, }};`
<tgschultz>
andrewrk, by "pull master" do you mean pull the source and compile it or is it built already?
<tgschultz>
I assume the former
<andrewrk>
pull source and compile it, yeah
<tgschultz>
alright, that'll be a bit then. I'll let you know.
<andrewrk>
that's just a mitigation. obviously the actual bug needs to get fixed
<tgschultz>
well if it works that'll help a lot actually.
<TheLemonMan>
if you manage to recover the panic() message I can try to fix it
gamester has quit [Quit: Leaving]
<tgschultz>
andrewrk: seems to have worked: when analyzing /root/git_stdlib-interface_reform_2/std/event/channel.zig:340:24: assertion failed
<andrewrk>
hope that helps. I only converted a few asserts for now
<tgschultz>
it appears to confirm my suspicion, changing `async<allocator>` to `async<&allocator>`, even though Allocator is safe to copy in the new paradigm, seems to mollify it.
<tgschultz>
If just changing all async lines to have a & or * in them is all that is required I'll call it acceptable for our purposes, but if not, or if I get ambitious, from what I recall of the cpp code last time it wouldn't be too difficult to fix.
<tgschultz>
thanks for throwing that together for me
<andrewrk>
np, sorry for the bugz
Zaab1t has joined #zig
SimonNa has quit [Remote host closed the connection]
Zaab1t has quit [Client Quit]
<tgschultz>
ha, ok. so now that I've satsfied async<> by giving it a pointer, it fails (in normal zig errors) becasue it does too much type checking and can't deal with the type erasure.
SimonNa has joined #zig
<tgschultz>
my clever plan to deal with async in the new iteration is thusly foiled. looks like I'll have to touch cpp after all.
<andrewrk>
you might be wasting your time if you're doing anything with async before #2377
qazo has joined #zig
<tgschultz>
just doing enough to get tests to pass without a horrific usrland workaround.
<tgschultz>
so basically: make ir_analyze_async_call expect a struct instead of a pointer, and disable typechecking for the first parameter.
n_1-c_k has joined #zig
very-mediocre has quit [Quit: Page closed]
<donpdonp>
im rolling my own 'channels', so it'll be interesting to see what zig does
<tgschultz>
donpdonp: oh my bad. you want the struct instance, not the struct type, because payload is a field. @field(Command(undefined), "payload") should work
<donpdonp>
oh that makes sense. zig should prob give a type error there
<tgschultz>
see #1439
<tgschultz>
specifically the last few comments
* donpdonp
hmms
<donpdonp>
ok. here's a memory mgmt question. fn makeCircle() *Circle { return &Circle{.radius = 3}; } <- is that automatically doomed to fail, because the Circle{} allocated memory, then returns the address and deallocated it at the end of the function, making any use of the pointer invalid?
<andrewrk>
yes
<andrewrk>
I think that might even be a compile error right now
<donpdonp>
hmm. if memory is allocated, which allocator does it use? (or is it part of the call frame?)
* donpdonp
hopes thats a sane question :)
<emekankurumeh[m]>
it's part of the stack frame
<tgschultz>
memory is never allocated behind your back in zig (future debug/saftey features aside). The Circle instance is in the function's stack frame and will technically be invalid once it returns. However, in many cases that memory won't be overwritten right away making it *appear* to work right up until it doesn't.
<tgschultz>
I mean, the error was legit, I'm just not sure the description was
<andrewrk>
I'm gonna do some translate-c live coding on the stream today, starting in 5 minutes: https://www.twitch.tv/andrewrok/
alot has quit [Quit: WeeChat 2.4]
<donpdonp>
is there a way to take the least significant u8 from a u64, and put it into a u8 variable?
<donpdonp>
oh i think @intCast is it. yea zig!
SimonNa has quit [Remote host closed the connection]
<TheLemonMan>
@truncate(u8, value&0xff)
wootehfoot has quit [Read error: Connection reset by peer]
* donpdonp
nods
<donpdonp>
what about turning [8]u8 back into a u64?
<TheLemonMan>
it depends, here you have to throw endianness into the mix
<TheLemonMan>
mem has all you may ask for
* donpdonp
nods and goes to look at mem (send and receive are on the same box, so endianness is the same)
<tgschultz>
mem.bytesAsValue or mem.readInt aught to be what you're looking for
<tgschultz>
and actually if you're sending things over a wire you may want to look at io.Serializer/Deserialzer
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<tgschultz>
so someone more familiar with the compiler code, what's the non-ptr equivelent of ir_analyze_container_field_ptr? like if I want to analyze a field in a struct where the struct was not a pointer?
Ichorio has quit [Ping timeout: 255 seconds]
<donpdonp>
well i should have looked at that earlier :)
<donpdonp>
i think this is my last hurdle: const buf: []u8 = readPipe(); std.mem.bytesAsValue(u64, buf) => error: expected *[N]u8 , passed []u8
<donpdonp>
i know that array[1..5] will make a slice, but i dont know how to go from slice to array. (i checked at runtime and buf.len == 8)
n_1-c_k has quit [Read error: Connection reset by peer]
n_1-c_k has joined #zig
<donpdonp>
well, made it a step further. const b8: *[8]u8 = @ptrCast(*[8]u8, buf.ptr); const a64 = std.mem.bytesAsValue(usize, b8);
<donpdonp>
last bit fails on var command: *Command = @intToPtr(*Command, a64); => expected type 'usize', found '*align(1) usize'
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
squeek502 has joined #zig
jjido has joined #zig
hio has quit [Quit: Connection closed for inactivity]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]