ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
mahmudov has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
return0e has quit [Remote host closed the connection]
return0e has joined #zig
<GitHub183>
[zig] mdsteele opened pull request #1309: Add "Comments" section to language reference (master...docs-comments) https://git.io/fNVmN
aesl has joined #zig
<GitHub42>
zig/master 0db33e9 Matthew D. Steele: Add "Comments" section to language reference (#1309)...
<GitHub194>
[zig] andrewrk closed pull request #1309: Add "Comments" section to language reference (master...docs-comments) https://git.io/fNVmN
<aesl>
how close is Zig to being production ready?
<andrewrk>
aesl, 2 years
<aesl>
cool, I'm fine with that
<aesl>
how much do you think the syntax will change from now to then?
dbandstra has joined #zig
<andrewrk>
return type syntax. coroutine syntax. required parens for some binary operations. function calling convention. aggregate type definition and literal syntax. alignment and other unusual properties of pointer type syntax
<andrewrk>
there are a few more
<andrewrk>
probably a few more instances of wide sweeping breaking syntax changes
<andrewrk>
once self-hosted compiler is nearing completion I plan to try to do all the syntax stuff as soon as possible
<Bas_>
Yeah I read their docs, pretty much useless.
<Bas_>
Since it's not directly zig related I don't want to pollute the chat here, but if you have any experience, let me know. ^^
<bheads_>
have you tried adding timing around the api calls? Normally I find I am using and api incorrectly or there is a better api call
<Bas_>
Yeah, sometimes it's slow sometimes it's fast. Though the actual transfer speed is always similar. 500MB/s While Linux does nearly 5GB/s on the same machine (VM in the windows box actually).
<Bas_>
So either winsock is shit, or I'm doing something wrong. Currently I'm thinking winsock is shit ^^
<andrewrk>
linux is native while windows is in a VM?
<moshe>
not after running your command, that was the original output from my test file
<moshe>
it the says ?.c:1:1: note: 'JavaVM' depends on itself TODO: remember C source location to display here
<andrewrk>
if you are interested in troubleshooting, you can run the above command, save the stdout into foo.zig and then post a link to a paste of it
<andrewrk>
the next step toward solving this is coming up with a small C code example that causes this problem
<moshe>
will do.
<andrewrk>
alternatively if you want to just get on with your day, you can look at the translate-c output, manually patch up the generated zig code, and then use that in your project rather than a @cImport
<andrewrk>
(that said we do want to solve this eventually)
<moshe>
I ran the translate-c command.. the generated zig file has 1960 lines
<andrewrk>
right, so that's why we want to narrow it down to a small test case
<andrewrk>
by searching for JavaVM, and then looking for JavaVM in the C code
<moshe>
I think I do understand the problem: *JavaVM is an opaque typedef that hides an internal struct full of pointers to functions, some of which take a *JavaVM as argument
<moshe>
so there's a circularity there
<andrewrk>
zig needs to generate valid code from that though
<andrewrk>
so it's definitely a bug
<moshe>
Yeah, I agree.
wilsonk has quit [Read error: No route to host]
wilsonk has joined #zig
<moshe>
I'll try to create a smaller c file that triggers the problem.
<andrewrk>
that would be much appreciated
<winksaville>
andrewrk: I added all of the tests that I'd created to test {p} to your code that added {*} they all passed except one where I was testing a Slice.
<winksaville>
First off there was a typo/bug in my original test and the test fails on my {p} code too, so the test was bad.
mahmudov has quit [Ping timeout: 264 seconds]
<andrewrk>
you'll need to pass `slice.ptr` to get the slice pointer to print
<winksaville>
how do I do that?
<winksaville>
what's the syntax
<andrewrk>
append the characters ".ptr" to a slice
<winksaville>
andrewrk: That wasn't obvious is the ".ptr" available on arrays or any other thing, searching the docs only has it for slices?
<andrewrk>
correct, the ptr field is only available on slices, as the documentation says
<winksaville>
k
<winksaville>
One other observation, there are 5 "Paths" where "fn formatType" prints the address using code like "return format(context, Errors, output, "{}@{x}", @typeName(T.Child), @ptrToInt(value))"
<winksaville>
I had added formatAddress for those and some "wink_log" printing the PathN.
<andrewrk>
there are not 5 paths in my implementation
<andrewrk>
there is only 1
<winksaville>
You mean the Pointer path in format state machine?
<andrewrk>
yes
<winksaville>
well, yes and no
<winksaville>
What I'm saying is the code that used to print the pointers with the format "{}@{x}" is there but no longer used.
<winksaville>
Should those paths be changed to @compileError?
<ofelas>
why for a struct with fn port(self: *const Self) u16,... fn otherfn(self: *Self, port: u16)... gives redefinition of port?
Bas_ has quit [Ping timeout: 252 seconds]
jjido has joined #zig
<andrewrk>
ofelas, because in the definition of otherfn, `port` can refer to both the parameter, and the port function
<andrewrk>
winksaville, they're still used. sometimes a pointer is printed even if it's not explicit
<ofelas>
hmm, okay
<winksaville>
I added all the tests from my PR which attempts to add test coverage of those paths, but none of them were executed in any of the existing tests or the ones I added.
companion_cube has left #zig ["WeeChat 1.0.1"]
<andrewrk>
what problem are you trying to solve?
<winksaville>
I just wanted to validate my tests worked with the new code and I was guessing those paths were now not being excersied and that seems the case.
<winksaville>
Unexcersied code paths aren't the best idea, so it seems there should be tests for those paths or change them to @compileError, IMHO :)
<winksaville>
I've already incorporated the additonaly tests I'd previously created, I can create a PR if you'd like. I can include the @compileError's if want them.
<MajorLag1>
andrewrk: until reading #1306 I wasn't aware that realloc was not supposed to be able to error if new_len < old_len. Like was mentioned by someone else in the thread, my own pool allocator moves you to a smaller block size pool if you cross below a limit, which can cause an allocation from the OS, which can fail. In my case the behavior can be changed, but the restriction does seem problematic.
<andrewrk>
MajorLag1, noted. we need to resolve that use case, with the use case that I posted in the issue, because currently they're in conflict
<andrewrk>
winksaville, I'm not focused on 100% std lib test coverage just yet. the API is still in flux. feel free to make a pull request
<winksaville>
k
<MajorLag1>
Well, we could have 2 reallocs. Something like realloc (which can fail any time) and resize (which will fail if the memory has to be moved). On the one hand this makes intent more explicit, on the other hand it complicates implementation, and on the gripping hand it doesn't really solve the problem as described by that post so much as it just forces the caller to deal with it.
<andrewrk>
right. there are 2 fundamental questions here, related to each other: (1) should the caller be responsible for tracking the byte count of allocations, and (2) should there be a way for the caller to shrink the byte count of an allocation in an infallible way
<andrewrk>
I think if the caller is responsible for tracking byte count, then it should be able to shrink the byte count without the possibility of failure
<andrewrk>
if the caller doesn't have to track byte count, it's no big deal to allow realloc to fail
noonien has quit [Quit: Connection closed for inactivity]
<moshe>
andrewk: I managed to reproduce that compiler bug with a small test case.
<andrewrk>
wonderful
<moshe>
I made a github gist with the inputs, sould I post the link here?
<MajorLag1>
If slices were Go-style and carried around a capacity too, then it wouldn't be an issue. Just spitballing, maybe allocators should return a `struct { data: []var, capacity: usize };`.
<andrewrk>
the zig equivalent of that is std.ArrayList