ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
atk has quit [Quit: Well this is unexpected.]
atk has joined #zig
<scientes>
how do i pass around a reference to stdout that i can call .print on?
<scientes>
I end up just using posixWrite cause I don't know how to use fmt
<scientes>
also, you have to use write to print '{' or '}'
<scientes>
oh wait, i can use {}, "{"
<tiehuis>
you can escape them by repeating
<tiehuis>
e.g. print("{{}}") will print "{}"
<scientes>
oh ok
<scientes>
i've got something like gperf brewing, but it has to generate code cause comptime doesn't cut it for complicated algorithms (like you can't std.sort.sort)
kristate has quit [Remote host closed the connection]
kristate has joined #zig
kristate has quit [Remote host closed the connection]
kristate has joined #zig
porky11 has joined #zig
return0e has quit [Ping timeout: 272 seconds]
return0e has joined #zig
hoppetosse has quit [Ping timeout: 240 seconds]
kristate has quit [Ping timeout: 240 seconds]
<andrewrk>
j`ey, ah right nice find
<andrewrk>
it would be interesting to see how much this speeds it up
<j`ey>
andrewrk: and it will be fun to see if there are other 'plans'
kristate has joined #zig
<andrewrk>
agreed
<kristate>
andrewrk: morning
<andrewrk>
morning
noonien has joined #zig
<MajorLag>
`error: expected enum or union, found 'u32'` `builtin.TypeId.Enum => return @sizeOf(@TagType(T)),`. Now I have to hunt down where something needs a `comptime` in front of it it keep the compiler from being stupid.
<MajorLag>
How the hell can `switch(@typeId(T))` inside a comptime block ever fail this assert? `builtin.TypeId.Enum => debug.assert(@typeId(T) == builtin.TypeId.Enum),`
<andrewrk>
hm I don't understand the code examples
<andrewrk>
oh I see
<andrewrk>
if that assert is failing it seems like a compiler bug to me
<MajorLag>
I fear the circumstances under which it occurs may be too complicated to replicate in a minimal way. If so, I'll package up the related sources causing the problem for you.
<MajorLag>
This just seems a lot like bugs we'd recently determined weren't actually bugs.
<MajorLag>
but since this is happening in a comptime block and no amount of liberally sprinkling "comptime" around seems to be fixing it...
<andrewrk>
I'm disturbed that zig has caused you to have to debug by sprinkling comptime around
allan0 has quit [Ping timeout: 252 seconds]
<MajorLag>
it's because it isn't always clear what will be considered runtime and what won't.
<MajorLag>
I would think that any use of @typeId() or @typeOf() would be a comtime value, but experience has taught me otherwise.
<andrewrk>
I don't think it's possible for the results of those to not be comptime
<andrewrk>
they panic if zig tries to codegen them
<kristate>
andrewrk: andrew, are you serious about u0?
<kristate>
I get 0-bit structs; I am not against 0-bit types
<andrewrk>
the null hypothesis is that they're fine, so the burden of proof is on removing them
<kristate>
but integers are another thing
<MajorLag>
maybe they are comptime values, but when you pass a different type into the function they are in it seems like sometimes they still have the same value they had the last time you called the function..
<andrewrk>
there's still an issue open for that right?
<MajorLag>
I thought we'd determined they were all acting correctly?
<MajorLag>
and it was just my reasoning that was wrong
<kristate>
andrewrk: then why are they not implemented in llvm or in any other place if they are so great?
<andrewrk>
MajorLag, hm I think we need to come up with a good example to discuss. or is this the same as that one issue I closed and we discussed briefly?
<andrewrk>
kristate, I think you can make a better argument than an appeal what llvm is doing or what an unspecified other projects are doing
<andrewrk>
llvm doesn't have the concept of 0 bit types at all, so of course there is no i0
<andrewrk>
0 bit types is a slightly higher level abstraction than what LLVM provides
<andrewrk>
kristate, are you not convinced by the math example?
<kristate>
smallest unit is a bit, which represents 0 or 1
<kristate>
there is no such thing as half a bit
<andrewrk>
but there is such a thing as the absence of a bit
<j`ey>
u0.5
<kristate>
there is no spoon
<kristate>
since we are riding on top of llvm, integers should be sacred and map 1:1 with LLVMIntType
<kristate>
0-bit integers can be represented as void
<MajorLag>
andrewrk, I don't know. I can't find a flaw with my reasoning here, but that doesn't mean there isn't one.
<andrewrk>
kristate, 0 bit types are not represented at all in llvm. operations on 0 bit types are no-ops
<andrewrk>
we don't code gen no-ops
<kristate>
andrewrk: right, u0 doesn't make sense :-) there is nothing that you can do with it. its
<kristate>
it's like your tail bone
<andrewrk>
MajorLag, I need to do a better job communicating how it's supposed to work in some of these cases. I'm certainly interested in specific use cases where the way that it works causes you friction
<kristate>
the definition of an integer in computer science is a range of mathematical integers. zero-to-zero is not a range
<andrewrk>
the range of u8 is [0, 256). the range of u0 is [0, 1)
<kristate>
u1 is [0,1]
<MajorLag>
but as andrewrk points out in the issue, just because it is a nop doesn't mean it is useless.
<kristate>
u0 is not a range
<andrewrk>
u1 is [0, 2)
<andrewrk>
the 2nd number is always pow(2, bit_count)
<MajorLag>
andrewrk, I'll see if I can put together something that can be more easily looked at, but if not I'll send you the code that's currently causing me trouble.
<andrewrk>
MajorLag, either one of those would be welcome
<MajorLag>
I don't believe so, I'm only looking at types in the problematic code. No other comptime data is involved.
<MajorLag>
well, comptime ints
<andrewrk>
ok
<MajorLag>
Ah, ok. Forget about this. It was my fault all along. Turns out I'd commented out another switch statement that had the line `builtin.typeId.Int,` before it. So the compiler was quite correctly branching where I told it to with `u32`.
Ichorio has joined #zig
Ichorio has quit [Client Quit]
<andrewrk>
is your comment on #906 still a thing though?
<andrewrk>
MajorLag, I don't blame you though - since we're before 1.0.0 there's always that little distrust of the compiler in the back of your head. sorry about that
<MajorLag>
Yes, but I really should stop reactively blaming the compiler just because it's comptime and I ran into a ton of comptime bugs in the past.
Ichorio has joined #zig
<MajorLag>
The comment on #906 is an example of the compiler working as expected given the description of the behavior. It is merely an example of the confusion that behavior can cause.
<MajorLag>
when was that stdcallcc bug introduced btw? I've been waiting to get all my older projects up to date until 0.3.0, but that thread lead me to check if my game engine still worked and it is broken now. I'm not sure if that's because I added stdcallcc to the win32 package functions since I last tested or if that used to work.
<andrewrk>
MajorLag, I don't know if you noticed but it is already fixed in master
<andrewrk>
with a test case to prevent it from breaking again
<MajorLag>
I haven't been keeping up with master because it CI was failing for so long. I'm out of the habit.
<andrewrk>
my bad
<andrewrk>
it's fixed now
<andrewrk>
lots of bugs fixed recently too
<MajorLag>
Sorry to have wasted your time with these non-issues today. I should refrain from reporting problems on monday morning I think.
<andrewrk>
haha, no worries
<andrewrk>
in general your bug reports have been immeasurably helpful
<andrewrk>
I know it's annoying to pause your dev process and file a bug report
<kristate>
wow dude
porky11 has quit [Read error: No route to host]
porky11 has joined #zig
<kristate>
andrewrk: I am not angry over here, more shocked than anything else. Would you like to give an explanation on why you rejected the issue instead of replying to me?
<andrewrk>
let's talk in private. #zig is for technical discussion about zig
<kristate>
andrewrk: isn't it a technical question?
<kristate>
I am asking technically about u0 -- I have no personal beef with you
<andrewrk>
if you want the discussion on #1530 to continue, you need to make more convincing arguments. your bob and jill example does not explain your thought process adequately, and you did not follow through enough on my response to that example
<andrewrk>
you also have not addressed my point about how many states u0 has
<kristate>
andrewrk: does that merit completely closing and rejecting the issue?
<andrewrk>
kristate, I need you to focus on having a positive attitude and an open mind
<andrewrk>
will you do that?
<kristate>
andrewrk: Definitely positive, Andrew? I have been supporting you financially and the project with my time and resources. I have been flying all over Japan telling everyone about the wonders of zig
<kristate>
but I want zig to succeed more than anything
<andrewrk>
I know you do, and I appreciate what you have been doing
<andrewrk>
but you still have to follow the proposal process
<kristate>
andrewrk: I have been, but if you close the issue there is no process :-)
<andrewrk>
ok, so let's try to get back on topic here. the less meta discussion, the better
<kristate>
andrewrk: yes, I am pretty busy and I really care about zig
<andrewrk>
kristate, let me lead the discussion a little bit. how many states does u1 have?
<kristate>
2 states, 0 or 1
<andrewrk>
right. and how about u0?
<kristate>
1 state in theory
<andrewrk>
according to your quote: information theory states that information that can be stored in a system is proportional to the logarithm of N possible states of that system, denoted logb(N) where b is the base.
<andrewrk>
so for u0: N == 1, and logb(1) == 0
<andrewrk>
however you thought it was logb(0), right?
<andrewrk>
because you said > logb(N) is only defined for N>0. Thus, the logb(0) is undefined.
<kristate>
andrewrk: right, but computers can only register in bits, or 2 states. there is no way to operate on a u0
<andrewrk>
I would still like to hear that acknowledgment
<kristate>
andrewrk: sorry if you felt I was ignoring you. I felt pretty bad when you rejected and closed the issue, too.
<kristate>
andrewrk: that said, I really think that having u0 will lead to problems down the road, especially when used within structs.
<kristate>
they are not required and should be removed.
<kristate>
andrewrk: likewise, winksaville made a good point that upcasting from u0 to u1 is not possible
<andrewrk>
that's a bug. all the bugs come from the same simple thing, that we need to have u0 be a comptime-known value of zero
<kristate>
andrewrk: seems more like a hack at what end?
<kristate>
andrewrk: what am I not getting?
wink_ has joined #zig
<kristate>
hey wink_
<andrewrk>
kristate, here's what it comes down to. it's not my job to convince you that u0 should be allowed. if you want it changed, it's your job to convince me that it shouldn't. You have not convinced me. If you would like to continue trying to convince me, please comment on the issue, and you're going to need to prepare a strong case. I have an open mind, but you need to invest more time in your arguments
<kristate>
andrewrk: isn't that backwards? we have to convince programmers all over the world to use zig. I want to know your reasons so that I can debate with you
<kristate>
I also want to know your reasons so that if they are good, I can share them with others and spread the love
<wink_>
kristate: q for me?
<kristate>
wink_: what's your take on u0 -- trying to be objective about it and understand what is so great about having it
<wink_>
It seems natural to me as long as it has well defined and unsurprising semantics. At the moment the most surprising semantic is the address of a u0 is null and yet the compiler appears to allow me to deference it.
<kristate>
wink_: yes, this is because it is backed by a void llvm type
<kristate>
I am for u0 being labeled as what it is, void
<wink_>
Can you create a &void ?
<kristate>
andrewrk ?
<wink_>
var v:void = {}; assert(&v == null); // works
<wink_>
var pV = &v; assert(pV.* == {}); // works
<j`ey>
are you sure the derefence is actually emitted?
<j`ey>
it might just replace the load with a void value
<wink_>
I'm not sure of anything, but I'm guessing the compiler is seeing it all as comptime calculations and optimizing it away, but just guessing.
<j`ey>
'When you store a u0, you know that there is only one possible value. So it takes up 0 bits of storage. It's brilliant, you don't actually store anything. When you load it, same thing. You know that there is only one value. So when you load it, you just know that the value is 0 and don't actually do any loading.'
<kristate>
Yeah, this goes against one of the zen of zig: "Small, simple language. Focus on debugging your application rather than debugging your knowledge of your programming language."
<kristate>
wink_ not being sure of anything is bad mojo
<andrewrk>
wink_, there seems to be an unrelated bug with comparison against null: test "aoeu" { var x: i32 = 1; @compileLog(&x == null); }
<andrewrk>
that should be a compile error
<j`ey>
why?
<andrewrk>
only optional pointers can be null. null comparison for this type does not make sense
<andrewrk>
oh I know what's going on here
<andrewrk>
hmm never mind. yeah this appears to be a bug
<wink_>
hmmm so I shouldn't be able to do this: `var x: i32 = 1; assert(&x != null);`
<andrewrk>
right
<andrewrk>
unless you casted &x to ?*i32 first
<wink_>
That seems overly strict, I like the current behavior :)
<andrewrk>
do you have a use case for it?
<j`ey>
I think it makes sense, no point checking for null if it cant ever be!
<andrewrk>
right, it's probably an indication that the programmer made a mistake somewhere
<wink_>
But what is the value of pZero: `var zero: u0; var pZero = &v;`
<andrewrk>
it's a compile-time-only value, just like a pointer to an empty struct, a pointer to a void value, or a pointer to an enum with only 1 item
<kristate>
wink_: did you mean to type `var zero: u0; var pZero = &zero;` ?
<wink_>
yea, sorry
<andrewrk>
there will never be any machine instructions to deal with zero or pZero
<kristate>
so what is the use case for u0 ?
<j`ey>
wink_: can you print pZero?
<wink_>
andrewrk: so `assert(pZero == null)` is ok and I don't have to cast it?
<andrewrk>
wink_, you can only test optional types for null. in your example pZero is not an optional type
<andrewrk>
(well you can right now as you demonstrated, but it's a bug)
<wink_>
And if I do cast it what will be the value of pZero, null I assume?
<wink_>
And should I be able to deference it?
Thalheim has joined #zig
<andrewrk>
the type ?*u0 in memory is represented as a bool which is whether or not it's null. you implicitly casted a T to a ?T so of course it will not be null
<andrewrk>
dereferencing a *u0 always happens at compile-time and the value is always 0
<andrewrk>
this is exactly the same as an enum with 1 tag
<kristate>
yes, enum with one tag makes sense, since it's used inside of the binary and not serialized
<kristate>
but, what is the use case for u0 ?
<andrewrk>
I think you need to come up with a more complete example about how serialization is a problem. serialization works fine with 0 bit types
<kristate>
andrewrk: so it is safe to assume that there is no use case for u0 ?
<kristate>
Hejsil commented that he does not know of the use case
<wink_>
Is `var zero: u0 = 0; var pZero = &zero;` correct code?
<andrewrk>
wink_, yes that will work fine once I fix the bug
<wink_>
It works for me now and I then can do `assert(pZero.* == 0);`
<andrewrk>
kristate, what did you think about the use case that I pointed out in the issue?
<kristate>
andrewrk: have a link?
<andrewrk>
wink_, `pZero.* == 0` should always be comptime-known, but the bug is that it is not
<j`ey>
wink_: can you print the value of pZero?
<andrewrk>
I'm going to close IRC for a bit so I can stop talking about this and just actually fix it. back in a bit
<wink_>
No and I can't print zero either `warn("zero={}\n", zero);` gives "error: compiler bug: var args can't handle void. https://github.com/ziglang/zig/issues/557"
<j`ey>
what error do you get for pZero?
<kristate>
wink_: yeah, I filed a bug for that -- it's because it's backed by a llvm void type
<wink_>
Ok, I'm going to lunch will see what up afterwards.
<kristate>
wink_: thanks
<rom1504>
it's interesting to have a simple way to represent base 1
<kristate>
rom1504: don't get me wrong, I think that the idea is interesting. it's just that having an integer type that is not storable is dangerous
<rom1504>
I don't know enough about zig to have an opinion on that
<rom1504>
however "it's not like you can use u0 for any sort of calculation" is wrong, you can compute anything in base 1
<j`ey>
I guess you could have a list of u0s
<rom1504>
I can imagine it could be useful for some theoritical stuff
<rom1504>
yeah exactly
<j`ey>
but you dont need u0 for that, an empty enum would be fine
<MajorLag>
I can't see how it could possibly be dangerous. You mention serialization in the thread, but we know what we're reading and writing when we serialize, either because it's a known structure or because the format identifies its structure. Either way I have difficult seeing how a 0-bit type makes that more dangerous than it already is.
<rom1504>
j`ey: yeah sure
unique_id has quit [Remote host closed the connection]
porky11 has quit [Quit: Leaving]
Ichorio has quit [Ping timeout: 240 seconds]
unique_id has joined #zig
unique_id has quit [Ping timeout: 240 seconds]
<kristate>
andrewrk: my u0 patch also included code for guarding against llvm's upper bound of (1<<24)-1 bits. I would appreciate if you could review it and merge it https://github.com/ziglang/zig/pull/1541
<andrewrk>
thanks kristate - I'll have a look
davr0s has joined #zig
<j`ey>
andrewrk: is the stream still 1700 estw?
<j`ey>
-w
<andrewrk>
j`ey, yes, Thursdays at 17:00 EST
<wink_>
andrewrk: I see a commit for dereference *u0 are you done with u0 changes, I want to run the tests I have when you are?
<andrewrk>
wink_, wait for 2 more commits
<wink_>
sg
<andrewrk>
ah I see what's happening with the null == thing. it's kind of amusing
<andrewrk>
we explicitly omit comparing *T and null in the equality code. but then we resolve both sides of a == b with peer type resolution, which sees a null and a T, and concludes that the peer types should resolve to ?T. so it casts your *T to ?*T and then does == null, and of course it's not
<j`ey>
I wouldnt think *T would implicitly cast to ?*T
<andrewrk>
T implicitly casts to ?T
<andrewrk>
it definitely makes sense. it's how you call C APIs since all C APIs have ? in their pointer types
<j`ey>
oh wait, it's the other way around that doesnt make sense
<andrewrk>
yeah there is no implicit cast the other way around
<andrewrk>
wink_, after looking at it, I'm kind of on the fence about the behavior of the pointer comparing thing
<andrewrk>
going to add the error though
<andrewrk>
alright wink_, go nuts
<wink_>
k
<kristate>
that that the language is getting stronger
<kristate>
looking forward to wink_'s tests
<kristate>
*glad that the language is getting stronger
<wink_>
So `assert(&zero == null);` now give a compiler "error: comparison against null can only be done with optionals", which is expected
<wink_>
But `assert(@ptrCast(?*u0, &zero) == null);` crashes compiler is there some other way to cast &zero?
<andrewrk>
it should say error: cannot pointer cast *u0 because it has no actual address
<andrewrk>
this will cause the same crash for *void
<wink_>
Here is the error:
<wink_>
error: comparison against null can only be done with optionals
<wink_>
assert(pZero == null);
<wink_>
And then the "^" points at first "=" in "=="
<andrewrk>
can you give me a full test case for the compiler crash?
<wink_>
k
<andrewrk>
nvm I got it
<wink_>
k
<wink_>
Should &zero == null with the proper pointer cast?
<andrewrk>
no you can only get null by assigning null
<andrewrk>
and you can only assign null to an optional
<andrewrk>
that pointer cast should be a compile error. you can't cast a zero bit pointer to a non-zero-bit pointer