ChanServ changed the topic of #zig to: zig programming language | https://ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<merlyndmg> oh I figured it out. if I make it a comptime variable and do a manual `if` on it then it works
<merlyndmg> *parameter not variable
<merlyndmg> that said, would it be silly for something like transCreateNodeBoolInfixOp to do an assert that you only passed it a booland or boolor operator? The original CPP code made such an assert. Does the function get auto-duplicated if you use compile time values, as long as they're not type variables and thus actually have to have different
<merlyndmg> implementations?
<pixelherodev> "if I make it a comptime variable and do a manual `if` on it then it works" ... definitely not going to steal that idea :)
<pixelherodev> Also, regarding that LLVM backend thingy: I slowed down the VM and now it looks even cooler
danielvu has quit [Quit: WeeChat 2.5]
<data-man> merlyndmg, try 'comptime assert(...)'
nullheroes has joined #zig
<andrewrk> frmdstryr, I'm definitely interested in working on the perf of stream server with regards to async and stuff, but there's a bunch of work to get to that point. I wonder if in the meantime you would be interested in looking into the perf of self-hosted parser
<andrewrk> that's a very straightforward, blocking operation
<andrewrk> even when we have threads, the task of parsing won't be split into threads
<andrewrk> (perhaps 2 threads separately parse 2 files, but not 2 threads on 1 file)
<andrewrk> and I'm sure that we're not at top speed for self-hosting parser, I think there is probably a lot of room for improvement
<andrewrk> how the arena allocator works for one, as well as which list data structure to use (I doubt the current use of SegmentedList is the best choice)
<andrewrk> and then maybe even some of the parsing code, idk
<mq32> andrewrk: do you really want to tell me that zig can now again compile for AVR __after__ i coded my weekend project in C?! :D
<mq32> *grin* next project it is, then... :)
frmdstryr has quit [Quit: Konversation terminated!]
protty has joined #zig
<daurnimator> andrewrk: at this point... do you think streams as mixins will be accepted? I don't want to build too much more on top
<andrewrk> the part where the namespaces conflict is a no-go
<protty> andrewrk: hey, am here from the PR if youd prefer faster feedback
<daurnimator> FWIW I actually consider the namespace conflict a good thing. I can't imagine wanting to do: myobject.something.read() *and* having myobject.someotherthing.read() and having 2 different results...
nephele has quit [Ping timeout: 252 seconds]
nephele has joined #zig
<pixelherodev> Seconded
lunamn has quit [Ping timeout: 276 seconds]
lunamn has joined #zig
* daurnimator looks around at how other languages handle this.... https://stackoverflow.com/a/37195530
<mq32> daurnimator: C# has a quite nice feature for "different implementation of a method with the same signature from two different interfaces"
<mq32> interface A { void Foo(); } interface B { void Foo(); }
<mq32> class C : A, B { void A.Foo() { } void B.Foo() { } }
<mq32> whereas a normal implementation looks like this:
<mq32> class C : A { public void Foo() { } }
<daurnimator> mq32: if I have a `C`, how do I call them?
<mq32> you have to explicitly cast into the interface
<mq32> lemme test
<daurnimator> mq32: for just the conflicting case? or the general case?
<daurnimator> if just the conflicting case... I guess that's okay, but I think that people's tendency for defensive coding will make it a mess where people use it too much
<daurnimator> if its the general case.... I don't get the ergonomics I'm after
<mq32> look here: https://ideone.com/7GYepc
<mq32> it's a quite nice solution
<daurnimator> https://docs.groovy-lang.org/next/html/documentation/core-traits.html#_multiple_inheritance_conflicts in groovy last definition wins by default; or you can pick...
<mq32> oof :D
<mq32> btw, refresh the ideone link, i've changed a bit
traviss has joined #zig
<daurnimator> in scala: https://scala-lang.org/files/archive/spec/2.13/05-classes-and-objects.html#class-members > . It is also an error if a template contains two members (directly defined or inherited) with the same name and the same erased type
protty has quit [Remote host closed the connection]
<daurnimator> mq32: I'm a little confused with your example: could you show an example of an interface adding "helper" methods?
<mq32> what is a helper method?
<mq32> C# has only "pure" interfaces
<daurnimator> e.g. base class implements `fn add(x) {}`, and now you want to add a `fn inc() { return add(1); }`
<mq32> ah
<daurnimator> --> the whole idea of "mixins" is to have a library of these wrappers that you can add to your object
<mq32> i'll make an example
<mq32> but keep in mind: C# can't do implementation of methods in templates
<mq32> *interfaces
<daurnimator> mq32: I think that's the whole point though: the question is: if you implement methods in interfaces/templates, then how do you handle collisions
<mq32> c# doesn't allow the call then and requires an explicit cast
rjtobin has quit [Quit: Leaving]
<daurnimator> mq32: how does that work with chaining?
<daurnimator> mq32: e.g. what if an interface implements or requires another interface?
<mq32> you can just use inheritance on interfaces
<mq32> interface B : A { }
<mq32> which will require all methods from A to be available when implementing B
<mq32> extension methods in C# are quite powerful as well. you can even implement them on generics
ltriant has joined #zig
muffindrake has quit [Ping timeout: 250 seconds]
muffindrake has joined #zig
ur5us has quit [Ping timeout: 250 seconds]
return0e_ has joined #zig
return0e has quit [Ping timeout: 276 seconds]
adamkowalski has joined #zig
<adamkowalski> What options do we have for sets in the standard library?
<daurnimator> adamkowalski: std.HashMap(T, void)
return0e_ has quit [*.net *.split]
nullheroes has quit [*.net *.split]
traviss has quit [*.net *.split]
dddddd has quit [*.net *.split]
slice has quit [*.net *.split]
sammich has quit [*.net *.split]
Sargun has quit [*.net *.split]
wilsonk has quit [*.net *.split]
lupine has quit [*.net *.split]
tdeo has quit [*.net *.split]
shachaf has quit [*.net *.split]
dom96 has quit [*.net *.split]
programi1 has quit [*.net *.split]
<adamkowalski> daurnimator: thanks! if I want to construct a set of items (but the items are already stored somewhere else) should I just store the pointers in the HashMap?
<adamkowalski> Or if the struct is a union of u64 types just with different tags, should I store it by value?
<daurnimator> depends on the lifetime of the items and the set...
<adamkowalski> It is still a "primitive" type at that point right
<daurnimator> what is?
<adamkowalski> a union(enum) of many different u64 types
<adamkowalski> the lifetime of the items is going to be longer then the lifetime of the set
<adamkowalski> so storing pointers is not dangerous
<adamkowalski> however a union will be the size of the largest member anyway right? so it will be 64 bits
<adamkowalski> and a pointer will be 64 bits
<adamkowalski> so it seems like it doesn't matter?
return0e has joined #zig
casaca has joined #zig
<daurnimator> adamkowalski: if its a tagged union then it will be size of largest member + tag size
<daurnimator> (+ alignment)
<adamkowalski> Thanks! Speaking of tagged unions, is there something akin to if let in Rust?
<adamkowalski> I know I can switch on the tag and then do something, but what if I only care about one case
<andrewrk> what's the floating point operation called, that is "ceil" but always away from zero
<andrewrk> `0.1 -> 2` `-0.1 -> -2`
<daurnimator> andrewrk: towards infinities?
<andrewrk> yes
<daurnimator> that's what its called
<andrewrk> ceil?
<daurnimator> either "round_towards_infinity" or "round_away_from_zero"
<daurnimator> "ceil" is usually taken to mean towards positive infinity.
<daurnimator> i.e. `0.1 -> 2`, `-0.1 -> 0`
<daurnimator> uh, `0.1 -> 1`
<daurnimator> I assume you mean that before?
<andrewrk> I want: 0.1 -> 1, -0.1 -> -1
<daurnimator> yep that would be "infinity"
<andrewrk> what libm function is that
<daurnimator> there isn't one IIRC. round-towards-infinity isn't defined as an IEEE754 mode
<data-man> C++ has nearbyint
<daurnimator> usually the modes are: up, down, zero, near
<adamkowalski> andrewrk: I'm having an issue with recursion. The compiler says it cannot resolve inferred error set: not fully analyzed yet
<daurnimator> adamkowalski: recursive functions need to specify their error set
<adamkowalski> Is there a way to query a function for it's error set? I should just be able to to look at all the functions I call try on and take the union of that right?
<daurnimator> data-man: in C that's FE_TONEAREST
<andrewrk> round is so close, but it's off by 0.5
<daurnimator> andrewrk: do you have a usecase for this?
* daurnimator thought you might have been asking for reasons of completion
<andrewrk> yeah it's for the codegen of comparison operators between ints and floats
<andrewrk> I'm working on merging the oldest open pull request
<andrewrk> new language change: comparison operators (<, >, >=, <=, !=, ==) work on any combination of ints and floats, no type errors
<daurnimator> sounds good. probably has some real funky edge cases!
<andrewrk> especially with vectors
<andrewrk> it's sound though, one can always answer the boolean question, regardless of the types
<adamkowalski> const error_set = @TypeOf(visited_nodes.putNoClobber).ReturnType.ErrorSet;
<adamkowalski> this complains that field access is not supported
<adamkowalski> Can I just query a hashmap directly? None of the error sets are listed in the source for hash map so it's hard to get that information haha
<andrewrk> adamkowalski, give the function an empty error set, and let the compiler tell you the errors you need to put in there
<andrewrk> this may be able to be improved in the future, inferred error sets of recursive functions
<adamkowalski> awesome, thanks!
<daurnimator> andrewrk: `@as(f16, 4096) <= @as(u16, 4095)` ?
<adamkowalski> Wow that was easy.
<adamkowalski> andrewrk: you also said in one of your streams that we should start using the async functionality to make sure our recursive functions don't stack overflow right?
<adamkowalski> Would that also apply to tail recursive functions?
<andrewrk> daurnimator, that codegens as @as(i17, op1) <= @as(i17, op2)
<andrewrk> assuming the operands are runtime known
<daurnimator> andrewrk: okay; similar question: `@as(f32, 33554432) <= @as(u16, 33554431)`
<daurnimator> uh, u32 on the right
<andrewrk> I don't see how this question is different
<daurnimator> andrewrk: because then I follow up with the question: what about `@as(f32, 3.4028234664e1038) <= @as(32, 0xFFFFFFF)`
<andrewrk> there is a mathematically correct answer to this comparison, which is clearly `false`
<daurnimator> yes mathematically its fine, but for codegen, wouldn't you need a branch before each comparison to check if the f32 is out of range of the integer before you try and convert it to an `i33`?
<daurnimator> for a given pair like f32/u32 there are numbers in one range that aren't in the other; and vice versa
<andrewrk> yes, I don't know how to codegen this without branching
<daurnimator> It seems like a tricky problem to figure out how to do it with a minimal amount of branching: you'd at least need one for checking too large; one for checking too small; and one for the comparison itself?
<andrewrk> yeah, I can tell you what it's going to do in stage1: error: TODO implement this
<daurnimator> though even then you'd probably need to do a check for fractional amounts..... though maybe you can do something clever with subtraction there
casaca has quit [Quit: leaving]
<daurnimator> but yeah: I was curious if you had figured out an elegant way to do it
<andrewrk> nope, only the realization that according to the type system, it is sound to allow for any (numeric) types
<andrewrk> which, I would argue, makes the language smaller. since it lets you do something that makes sense to be able to do
<andrewrk> maybe some hardware has float/int comparison instructions, idk
<daurnimator> you also can get lost in the realm of ULPs... e.g. when comparing an integer to a float, are you comparing it when the integer is converted to a float?
<andrewrk> I don't know that TLA
<andrewrk> each value has a mathematical number that it represents; that is what is being compared
<daurnimator> it doesn't though
<daurnimator> floating point values essentially represent a range
<data-man> andrewrk: What do you think about new std.search module? binarySearch, Bitap, etc.
<data-man> And move to std.search some funcs from std.sort
<daurnimator> from x-ULP/2 to x+ULP/2
<andrewrk> daurnimator, I see your point
<daurnimator> andrewrk: e.g. if I write `@as(f16, 4095)`, then it's == to `@as(f16, 4096)`
<andrewrk> hmm that's a decent argument in favor of not allowing the comparison
<daurnimator> you *can* still compare them though: @as(f16, 4096) is obviously <= @as(u32, 5000)
<daurnimator> but only for certain values
<daurnimator> or at least: if it's within 1 ULP.... the answer is "its complicated"
<daurnimator> Hmm... if you convert both operands to floating point.... is it always correct?
<daurnimator> I think yes; unless you get an infinity
<daurnimator> `@as(f16, 4096) <= @as(u16, 4095)` should be: `@as(f16, 4096) <= @as(f16, @as(u16, 4095))` which is: `@as(f16, 4096) <= @as(f16, 4096)` which is `true`
adamkowalski has quit [Ping timeout: 265 seconds]
ltriant has quit [Quit: leaving]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 265 seconds]
<daurnimator> andrewrk: ^
THFKA4 has quit [Ping timeout: 245 seconds]
<Snektron> <daurnimator "I can't say I like rust's soluti"> You can already kinda do that with your mixin strategy
<Snektron> Then you would create a wrapper type every time you want to use a method
<Snektron> Ex Random(&rng).int(u2)
<Snektron> Hm, i guess that is a lot more different that i thought
demizer has quit [Remote host closed the connection]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 252 seconds]
lunamn has quit [Ping timeout: 250 seconds]
lunamn has joined #zig
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 250 seconds]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 245 seconds]
<merlyndmg> Is it possible to hit this line of code? https://github.com/ziglang/zig/blob/master/src/translate_c.cpp#L2888
adamkowalski has joined #zig
<merlyndmg> I think that might be referring to a C++ enum, e.g. `SomeEnum::SomeEnumValue`
<merlyndmg> Does zig ever try to parse C++ in that way, or just C?
adamkowalski has quit [Ping timeout: 268 seconds]
<merlyndmg> and how would one test out the remainder of that bunch? i.e. this line https://github.com/ziglang/zig/blob/master/src/translate_c.cpp#L2898
<merlyndmg> It would be on one of the sides of a && or ||, of course, but what would the expression look like to trigger that line?
adamkowalski has joined #zig
vexu has joined #zig
_Vi has quit [Ping timeout: 246 seconds]
adamkowalski has quit [Ping timeout: 265 seconds]
adamkowalski has joined #zig
<vexu> merlyndmg: I think that should work if you copy the `.Typdef` switch value from `transType`.
adamkowalski has quit [Ping timeout: 245 seconds]
ur5us has joined #zig
adamkowalski has joined #zig
mahmudov has quit [Ping timeout: 268 seconds]
vexu has quit [Quit: WeeChat 2.6]
jokoon has joined #zig
adamkowalski has quit [Ping timeout: 250 seconds]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 265 seconds]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 252 seconds]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 265 seconds]
adamkowalski has joined #zig
marmotini_ has joined #zig
darithorn has quit [Quit: Leaving]
adamkowalski has quit [Ping timeout: 246 seconds]
ur5us has quit [Ping timeout: 245 seconds]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 252 seconds]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 246 seconds]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 250 seconds]
return0e_ has joined #zig
adamkowalski has joined #zig
return0e_ has quit [Remote host closed the connection]
adamkowalski has quit [Ping timeout: 276 seconds]
return0e_ has joined #zig
return0e_ has quit [Remote host closed the connection]
knebulae has quit [Read error: Connection reset by peer]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 245 seconds]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 265 seconds]
return0e_ has joined #zig
adamkowalski has joined #zig
lunamn has quit [Quit: leaving]
sammich has joined #zig
shachaf has joined #zig
lupine has joined #zig
adamkowalski has quit [Ping timeout: 250 seconds]
tdeo has joined #zig
slice has joined #zig
programi1 has joined #zig
dom96 has joined #zig
_Vi has joined #zig
data-man has quit [Ping timeout: 265 seconds]
merlyndmg has quit [Ping timeout: 260 seconds]
jokoon has quit [Read error: Connection reset by peer]
jokoon has joined #zig
marmotini_ has quit [Remote host closed the connection]
wilsonk has joined #zig
bgiannan has quit [Quit: WeeChat 2.6]
knebulae has joined #zig
return0e_ has quit []
return0e_ has joined #zig
nephele has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
nephele has joined #zig
marmotini_ has joined #zig
bgiannan has joined #zig
<bgiannan> what happens to a `for (a_slice) |item, i|` loop if i remove things from the slice in the loop?
<Snektron> It explodes
<Snektron> It depends on the implementation and how you are removing it, bgiannan
<bgiannan> i figured
<Snektron> Probably wiser to calculate the index yourself
<bgiannan> right
<Snektron> Looks less nice but youre guaranteed that it works, and is probably also more readable
frmdstryr has joined #zig
dingenskirchen has quit [Remote host closed the connection]
commande1 has joined #zig
commande1 has quit [Client Quit]
dingenskirchen has joined #zig
protty has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
dingenskirchen has quit [Client Quit]
dingenskirchen has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
nephele has quit [Remote host closed the connection]
dingenskirchen has quit [Quit: dingenskirchen]
nephele has joined #zig
dingenskirchen has joined #zig
WendigoJaeger has joined #zig
WendigoJaeger has quit [Remote host closed the connection]
WendigoJaeger has joined #zig
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
<fengb> Is it kosher to use struct assignment as memcopy?
<fengb> I know it works right now, but the semantics look pretty weird
<mq32> fengb, what do you mean?
dddddd has joined #zig
<mq32> a = b; instead of memcpy( &b, &a, @sizeOf(@TypeOf(a))
<mq32> ?
<fengb> Yeah
<mq32> i think it's the way better option
<mq32> allows better code generation
<fengb> It looks like var sorted = mmu.dyn.oam;`
<mq32> also is more readable
<fengb> But it doesn't look like a memory copy
<mq32> every variable assignment is a memcpy
<fengb> All because oam is a struct with an array (not slice)
<mq32> i was *so* happy that zig has value arrays
<mq32> this code is much easier to understand than a memcpy
<fengb> Yes I know, but it feels really weird since most languages don't have value arrays
<mq32> sadly!
<fengb> Even though you can convince C to have them by sticking in a struct...
<fengb> (Why is C so weird?)
<mq32> because it is old and "i++" was a single instruction back then
<fengb> I find it amazing that `a[i + 4] = 1` is a single instruction in x86
<fengb> Dereference, offset, assignment? Totally the same thing 👍
<mq32> yep
<mq32> fun fact
<mq32> memcpy(&a, &b, X); is a single instruction on x86
<fengb> I did not know that
<fengb> Well that expalins the @memcpy intrinsic :P
<fengb> Oh I've seen that before. I should actually learn x86
<fengb> Also lol tripod
<WendigoJaeger> https://www.felixcloutier.com/x86/movs:movsb:movsw:movsd:movsq is a great reference for x86 instructions
<fengb> I wonder how that'd be encoded in microops. And how much more efficient is it compared to a RISC memcpy
presiden has joined #zig
<pixelherodev> x86 != efficiency :P
<fengb> x86 is amazingly cache efficient
return0e_ has quit [Remote host closed the connection]
return0e_ has joined #zig
<mq32> fengb: modern x86 processors are pretty much RISC processors emulating x86 in hardware :D
<pixelherodev> As I said
<pixelherodev> != efficient
<fengb> Yeah, I mean more of how efficient a single instruction memcpy can be compared with a traditional RISC instruction set
<mq32> it isn't efficient
<pixelherodev> ^
<pixelherodev> Right, but in practice, it *is* multiple RISC instructions
<mq32> rep movsb is slower than manually coded memcpy
<mq32> MUCH slower
<pixelherodev> Those are just hidden away
<fengb> wat, then why use it
<pixelherodev> Because it's one x86 instruction.
<pixelherodev> Which means cleaner asm
<pixelherodev> At least, that's my guess
waleee-cl has joined #zig
<fengb> I think I need a better color to indicate "transparent" https://imgur.com/f0ZLVY8
<mq32> fengb, pretty much nobody uses it :D
<mq32> pixelherodev, use foof!
<pixelherodev> foof?
<mq32> 0xFF00FF, also called magenta :D
<mq32> (i need to spread foof as a replacement for magenta)
<pixelherodev> mq32, wrong person
<pixelherodev> :)
<mq32> oh damn ;D
<pixelherodev> Freaking compiler segfaults...
<pixelherodev> Zig, that is - not mine
<mq32> my brain kinda messed up because of the join message
<pixelherodev> Gotcha
<protty> lupine: ever since https://tokio.rs/blog/2019-10-scheduler/ its exciting to see that rust libraries are starting to utilize golang's scheduler model
scientes has joined #zig
<fengb> Cert expired D:
marmotini has joined #zig
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
<Snektron> <mq32 "memcpy(&a, &b, X); is a single i"> not on any optimizing compiler
<waleee-cl> Is the static builds from master on ziglang.org compiled in debug mode?
marmotini has quit [Ping timeout: 246 seconds]
<andrewrk> Release
<waleee-cl> Downloaded the latest and tried (and noticed that that was the case)
<pixelherodev> Is a segfault in ir_render_br via a llvm::BasicBlock::getContext call a known issue?
<andrewrk> pixelherodev, no
<mq32> Snektron: as i said, it's not efficient in speed, but only in size :D
<pixelherodev> Yay
<pixelherodev> I've run into this a number of times I think and just worked around it
<pixelherodev> But I'm holding off on pulling Zig until 0.6
<Cadey> is there a maybe type in the standard lib?
<Snektron> ?<type>
<Cadey> how about an either?
<pixelherodev> You mean a union?
<Cadey> can you return a union in a comptime function that returns a type?
<pixelherodev> A union is a type, so yes
<Snektron> sure
<Cadey> can you define methods on a union?
<pixelherodev> 99% sure
<Snektron> yes
<andrewrk> yes you can, and you probably want to give your union a tag
<pixelherodev> ^
<fengb> Yes, you can also define methods on an enum if you want
leeward has joined #zig
<leeward> I get an error when I try to run this example: https://ziglang.org/documentation/master/#Import-from-C-Header-File
<fengb> andrewrk: you mentioned reworking how format is implemented. I believe generators will simplify it tremendously
<leeward> main.zig:8:19: error: expected token ')', found 'StringLiteral'
<fengb> Naturally embedding a context and iterator
<leeward> Am I doing something wrong? I thought the examples were tested.
<andrewrk> fengb, yes I agree
<andrewrk> leeward, they are tested, can you post your source?
<leeward> https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(fontScale:14,j:1,lang:zig,selection:(endColumn:1,endLineNumber:1,positionColumn:1,positionLineNumber:1,selectionStartColumn:1,selectionStartLineNumber:1,startColumn:1,startLineNumber:1),source:'const+c+%3D+@cImport(%7B%0A++++//+See+https://github.com/ziglang/zig/issues/515%0A++++@cDefine(%22_NO_CRT_STDIO_INLINE%22,+%221%22)%3B%0A++++@cInclude(%22stdio.h%22)%3B%0A%7D)%3B%0A%0Apub+fn+main()+void+%7B%0A++++_+%
<leeward> 3D+c.printf(c%22hello%5Cn%22)%3B%0A%7D%0A%0A'),l:'5',n:'0',o:'Zig+source+%231',t:'0')),k:41.28191675410983,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:z050,filters:(b:'0',binary:'1',commentOnly:'0',demangle:'0',directives:'0',execute:'1',intel:'0',libraryCode:'1',trim:'1'),fontScale:14,j:1,lang:zig,libs:!(),options:'',selection:(endColumn:1,endLineNumber:1,positionColumn:1,positionLineNumber:1,selectionStartColumn:1,selectionStartLineNumber:1,st
<leeward> artColumn:1,startLineNumber:1),source:1),l:'5',n:'0',o:'zig+0.5.0+(Editor+%231,+Compiler+%231)+Zig',t:'0')),k:25.384749912556842,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:output,i:(compiler:1,editor:1,fontScale:14,wrap:'1'),l:'5',n:'0',o:'%231+with+zig+0.5.0',t:'0')),k:33.33333333333333,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4
<leeward> Holy crap
<leeward> sorry, didn't realize that would be that long
<andrewrk> your source does not match the example code you linked
<andrewrk> here it is fixed: https://godbolt.org/z/xn-uay
<scientes> how does it convert that to a C string?
* scientes never noticed that
<scientes> cause printf needs it null terminated
<leeward> Gah, thanks. I think I crossed versions.
<andrewrk> scientes, btw I took your proposal to make comparisons work for all integer types, about to push to master
<scientes> cool
<fengb> I'm actually really glad c"" is gone. I had thought that it returned c pointers, and inferred [*c] pointers were null terminated pointers
<Snektron> hm
<Snektron> i get segfaults when allocating too much stack
<leeward> While I'm on the subject, is there a canonical way to implement an opaque data structure in Zig? I've got a C library that I'd like to replace, and it's built around passing opaque struct pointers around.
<Snektron> @OpaqueType()
<andrewrk> Snektron, zig doesn't yet have the ability to detect stack usage at compile-time and request more at startup, but that is planned
<leeward> Snektron: Thanks!
<scientes> const slice: [:0]const u8 = "hello";
<andrewrk> Snektron, one problem I haven't quite worked out is what to do when we know we need a certain amount of stack space, but zig is not in charge of calling main()
<scientes> ahh that is really clever
<scientes> and it makes some of the stdlib work better on linux
<pixelherodev> This is... weird
<pixelherodev> That segfault I mentioned?
<pixelherodev> Returning an error seems to trigger it...
<pixelherodev> Rather, under specific conditions, *any* return seems to
<fengb> andrewrk: I think this generator style is the "least bad" right now with async: https://github.com/fengb/zig-tmpl/blob/master/src/main.zig#L94
<pixelherodev> Or, worse: any *branch*
<fengb> It works and allows arbitrary yields along the entire stack
<pixelherodev> Even @panic
<leeward> Snektron: So if I want to export an opaque type in a generated header, I'll just "export const foo = @OpaqueType();"?
<scientes> const slice: [:0]const u8 = "hello";
<scientes> this also allows using null-terminated style with --release-small
<Snektron> andrewrk, did you consider to add it to TypeInfo? if you still want to remove recursion, you could provide an @typeInfo(main).Fn.required_stack_space
<Snektron> leeward, i think you're only allowed pointers to opaque types
<leeward> Snektron: Oh, right, there should be a * in there.
<leeward> er, an &?
<Snektron> oh wait
<Snektron> even with recursion, that value could be ?usize for required stack space
<andrewrk> Snektron, it's not really part of the type; 2 functions with the same type could have different stack requirements
<Snektron> depending on the invocation, yeah...
<fengb> Could we annotate function pointers with max stack size?
<Snektron> Thats another thing
<fengb> (Should we?)
<leeward> Snektron: Yeah, but that doesn't talk about generating header files. I need my library's users to have a name for the opaque type.
<andrewrk> fengb, I think that will be a necessary component of eliminating stack overflow at compile time
<Snektron> leeward, i think those OpaqueType's export just like normal types
<Snektron> andrewrk, you could always have @requiredStackSpace(expr)
<fengb> The only caveat to OpaqueTypes is that they can only exist as pointers and you can't dereference them, similar to forward declared structs in C
<Snektron> thats alright when you export them
<leeward> Snektron: Trying it
<Snektron> btw, are promises still a thing?
<Snektron> Because the documentation still lists them under TypeInfo
<leeward> Hey it worked! Nifty.
<leeward> Hmm, ok, so here's the C code I want to generate: "typedef struct foo foo_t"
<leeward> Instead, it's generating "struct foo_t;"
<leeward> Is this a thing I can do, and if not, will it ever be?
<leeward> Also, I'm guessing that my C API needs to have a bunch of functions that accept the opaque pointer type and @ptrCast it to the thing it's supposed to be, then call the function that actually does the thing with the pointer.
<leeward> A trivial example:
<leeward> Is that a reasonable model for a library in Zig that's called by C?
<fengb> Seems like you can just export do_thing directly
<leeward> Well, there's a bug: "zig build-lib src/main.zig" generates a header with this in it: `struct ThingHolder(i8,8);`
<Snektron> great, thanks
<leeward> But point taken. You may be right.
<fengb> leeward: oops yeah I see it. Probably a bug :P
<pixelherodev> Zig had promises?
<fengb> They were the old async stuff
<pixelherodev> Ah
<andrewrk> they were basically `anyframe`
<pixelherodev> Gotcha
<leeward> fengb: Hmm, even if I alias my comptime-instantiated type, it still generates that line. Definitely a bug. Time to search the bug db.
<Snektron> with more compile errors
<pixelherodev> I think any branch in a nested-while loop fails
<pixelherodev> Though there might be more to it, I need to nail down the minimal reproducing test case
<fengb> andrewrk: https://github.com/ziglang/zig/issues/3893 I'm having a hard time figuring out how this should work
<pixelherodev> I'd argue it should parse the signature and only the signature
<pixelherodev> So you'd be able to determine that it returns Foo and takes no parameters, but it wouldn't evaluate the function itself
<andrewrk> fengb, I think @typeInfo is going to stop having declarations in it
<pixelherodev> If you only analyze the type of a function without calling it, there's no need to parse the function, and thus it shouldn't be parsed
<andrewrk> something as drastic as removing decls isn't necessarily needed though. now that we have lazy values, they can be used to tackle this problem
<leeward> I don't see it in there. Filed: https://github.com/ziglang/zig/issues/3924
<leeward> Incidentally, am I right in assuming that I just don't have permission to add labels like `bug` to issues I raise and PRs I submit? I've seen other people add tags to my stuff, but I don't see an obvious way to do it myself.
<shakesoda> leeward: yeah, github restricts that to people with write access to the repo etc
<shakesoda> i think there might be a second permission level for it also, but not sure
<leeward> shakesoda: Excellent. Just wanted to make sure I wasn't creating more extra work for people than I needed to.
mahmudov has joined #zig
dimenus has joined #zig
<andrewrk> don't worry, the effort of labeling issues is nothing compared to the effort of actually solving the problem
<leeward> Hmm, getting a link error with that printf example from before: lld: error: unable to find library -lC
<andrewrk> if only zig could be improved, by futzing with labels all day :P
<shakesoda> andrewrk: wouldn't that be a convenient alternate reality, lol
<andrewrk> leeward, your `C` should be `c`
<shakesoda> as a maintainer of various things i always rather preferred doing them myself anyway
<leeward> Of course it should.
<leeward> andrewrk: thanks
<leeward> shakesoda: I understand that. Having no label is better than having wrong labels.
mahmudov has quit [Ping timeout: 265 seconds]
return0e_ has quit []
<fengb> I thought about lazy values, but that could lead to non deterministic declarations
<fengb> e.g. running type info later can yield different results
<andrewrk> that's a good point
<andrewrk> fengb, a non-disruptive small improvement would be to make lazy all the declarations though. so if you never accessed the decls field then none of them get poked
<andrewrk> and accessing decls field would mean all get poked
<fengb> Ah I see. That’d make sense
<fengb> That should fix it for this formatting issue. Thanks
<andrewrk> alright, oldest "ball-is-in-my-court" pull request is now in November
dingenskirchen has quit [Quit: dingenskirchen]
jjido has joined #zig
<dimenus> andrewrk: how long have you been working on zig fulltime now? a year?
<andrewrk> since 2018 Jun 07. there was another stretch of time before that, adding up to about 1 year as well
<dimenus> still enjoying it?
<andrewrk> yes
<andrewrk> impatient for async I/O & self-hosted to be further along though
merlyndmg has joined #zig
<leeward> I'm having trouble linking a simple C program to a library written in Zig. The Zig source code is from mathtest.zig in https://ziglang.org/documentation/master/#Exporting-a-C-Library and this is what I'm seeing: https://pastebin.com/7jQrcBc8
<andrewrk> leeward, I think you want --bundle-compiler-rt
dingenskirchen has joined #zig
<leeward> $ zig build-lib --bundle-compiler-rt src/add.zig
<leeward> andrewrk: like that? If so, no change.
<leeward> Oh, if I link to libadd.a it's better.
<leeward> :P
<andrewrk> leeward, you could also do -fno-stack-check
<leeward> andrewrk: Ooh, that might be preferable.
<mq32> can somebody explain why the "kernel" step isn't executed when doing "zig build run"?
<mq32> i'd expect that it is built when running qemu_step
<andrewrk> mq32, that looks right to me
<andrewrk> this is where it would be nice to have build_runner.zig support a graph visualization option
<andrewrk> there's a better way to set this up though mq32
<mq32> okay, please share your wisdom with me :
<mq32> when doing "zig build run" with the above script, no "bin" folder is created
<andrewrk> addSystemCommand() with the first args, but not the path to your artifact output path, then use qemu_step.addArtifactArg(kernel)
<andrewrk> then you don't need the explicit dependOn() and the build system is aware of where the kernel gets built to etc
<mq32> tanks!
<andrewrk> I think that makes it run from the install dir as well, but I'd have to double check
<andrewrk> mq32, yes, when you make it aware that it's the path of another artifact, it gets smarter: https://github.com/ziglang/zig/blob/170de5ecae27373149db247ca0cff464e090e31b/lib/std/build.zig#L2139
<Snektron> does zig have any way to write large numbers?
<andrewrk> std.math.big.Int ?
<Snektron> like 1_000_000 in python/rust or 1'000'000 in c++
<mq32> :)
<Snektron> i realize "writing large numbers" is quite ambiguous
_Vi has quit [Ping timeout: 246 seconds]
<pixelherodev> This is odd
<pixelherodev> If I don't catch the error and just exit the function calling the function for which codegen is failing, I get a completely different segfault
mahmudov has joined #zig
<Snektron> hmm thats too bad, andrewrk
<mq32> andrewrk, similar topic than number separators: would it be possible and reasonable to make zig fmt allow some alignments in declarations?
<mq32> if one is writing matrices or similar, it's really hard to read them after a zig fmt removes all white space
<andrewrk> matrices? zig fmt already aligns arrays
<mq32> huh? how come i never noticed tha?
<pixelherodev> ... or not. I somehow got an entirely different error without changing the code but at least I'm getting this one consistently now?
darithorn has joined #zig
<mq32> i can swear that i haven't seen that working
<andrewrk> pixelherodev, if you're trying to debug a crash in llvm, I recommend a debug build
<andrewrk> there's probably a useful assert that you're not hitting otherwise
dingenskirchen has quit [Remote host closed the connection]
tines9 has quit [Ping timeout: 252 seconds]
<pixelherodev> ... I don't think I can afford to that anytime soon
tines9 has joined #zig
<pixelherodev> It takes a lot of hours and battery life, and I'm w/o a charger for the rest of the day (I use a spare battery instead of a charger because it's easier to carry)
<pixelherodev> Hmm
<pixelherodev> I think I might be running into #3029 actually
<pixelherodev> The stack traces are very very similar
mahmudov has quit [Ping timeout: 248 seconds]
<pixelherodev> But it's not a simple inline for this time...
merlyndmg has quit [Ping timeout: 260 seconds]
<pixelherodev> Huh
<pixelherodev> Found a workaround for this
<pixelherodev> It only happens when that return is inside of a while
<pixelherodev> Using a boolean and returning outside the loop works
<pixelherodev> I think my original suspicious of it being a nested loop issue was right
<pixelherodev> I think the basic block in question is one of the conditional blocks for the innermost loop
<pixelherodev> Furthermore, `break` in the loop causes the same issue, so it's not a return
<pixelherodev> And it also only triggers *inside of the conditional*
<pixelherodev> This is really odd
<pixelherodev> I have `if (std.mem.eql) {...} else {return error / break / etc}` -> panic
<pixelherodev> s/panic/segfault
<pixelherodev> With `else {failed = true;} if (failed) {break / return error / etc` it works fine
<pixelherodev> I think Zig is generating invalid IR
<pixelherodev> Going to use `--verbose-llvm-ir` and see if I can figure this out
mahmudov has joined #zig
wootehfoot has joined #zig
<pixelherodev> andrewrk, correct me if I'm wrong, but returning an error should not generate `ret void` in the IR?
<pixelherodev> Ah, was looking in the wrong place
<pixelherodev> Gah
<pixelherodev> That error table is huge
<pixelherodev> almost 5000 characters :(
<andrewrk> if you don't use @errorName then it doesn't generate one
<andrewrk> also there is optimization opportunity with error sets, not taken advantage of
<pixelherodev> Switching to @panic made it far easier to trace
<pixelherodev> Since it's just a global with the string, a global for the slice containing that string, and the call to panic using the second global
<pixelherodev> There a LLVM cli program to validate a module?
<andrewrk> probably opt
<pixelherodev> ... huh. I split out the breaking part into its own function to make the IR easier to analyze
<pixelherodev> And the segfault vanished
<andrewrk> it can sometimes be an in-memory-only problem
<pixelherodev> No, I mean the normal compiler worked
<pixelherodev> Ah! Found the IR problem!
<pixelherodev> `br i1 %5567, label %ErrRetReturn1276, <null operand!>, !dbg !17228`
<pixelherodev> `<null operand!>`
<pixelherodev> ... I think it might be an error merging error sets?
lunamn has joined #zig
<pixelherodev> Weirdly, the error isn't even in the IR corresponding to the changed code
<pixelherodev> It's in the unchanged then branch
<pixelherodev> huh. And removing the error return from there causes an entirely different segfault which occurs before the codegen stage :(
<pixelherodev> weird. Removing the entire then branch causes the same thing.
<pixelherodev> Some integer overflow
_Vi has joined #zig
doublex__ has joined #zig
doublex_ has quit [Ping timeout: 250 seconds]
<pixelherodev> huh. A grep for `null operand` gives nothing in the zig src
<pixelherodev> Am I to assume that's from LLVM?
protty has quit [Ping timeout: 260 seconds]
<pixelherodev> ... I have no clue how to really debug this...
<pixelherodev> Or not
<pixelherodev> Just remembered metadata exists :D
<pixelherodev> Okay, so this seems to occur in a very limited set of circumstances: has to be a conditional inside of a nested loop with two different branches which either never return (e.g. panic) or return immediately
<pixelherodev> There's an entirely *different* bug that occurs if I remove either branch of the conditional without making some other tweaks :P
<pixelherodev> Importantly, the second bug only occurs if the *else* branch specifically has such a branch
<pixelherodev> So, correction: the second bug doesn't occur if only the else branch is removed
* lupine wonders about fuzz testing compilers with randomly generated programs
<pixelherodev> Okay, here's another weird bit
<andrewrk> lupine, you're assuming that finding bugs is the bottleneck. we have 247 open bug reports
<pixelherodev> With `if (a) {} else { branch }`, segfault
<pixelherodev> With `if (a) {} else if (!a) {branch }`, compiles fine
<lupine> hehe
<pixelherodev> There a way to specify that e.g. past contributors can set labels in issues they open?
<andrewrk> there is not
<pixelherodev> Or possibly create a team for new contributors that gives them very limited permissions - such as setting labels?
<pixelherodev> Eh
<pixelherodev> That's probably more work
<pixelherodev> then just setting the labels manually :P
<pixelherodev> Yeah, this isn't just a hyper-specific bug
<pixelherodev> Plenty of other places I'm switching from debug.warnings to returning errors that are running into the exact same thing
TheLemonMan has joined #zig
<TheLemonMan> pixelherodev, are you trying to narrow down a bug in the LLVM IR?
<pixelherodev> No
<pixelherodev> Codegen
<pixelherodev> Zig compiler is producing invalid IR
<pixelherodev> ziglang/zig#3925
<TheLemonMan> hmm, are you using an inline for?
<pixelherodev> Nope
<pixelherodev> I know which issue you're referring to
<pixelherodev> That was my first thought as well
<pixelherodev> I suspect it might be the same issue though
<pixelherodev> I'll look into the inline for tonight, but it's quite possibly the same issue
<pixelherodev> An easy way to test: `zig build-exe ... --verbose-llvm-ir` 2>temp ; opt temp; rm temp`
<pixelherodev> Pass in an inline for to that
<pixelherodev> If you get a message about "expected value in address space, received <null operand!>" it's probably the same issue
<pixelherodev> It gets more interesting - returning an error from the if statement works fine
<pixelherodev> Adding a non-branching else condition works
<TheLemonMan> oh, so the error comes from opt?
<pixelherodev> No
<pixelherodev> `opt` verifies the LLVM IR
<pixelherodev> And detects that it's not valid
<pixelherodev> Adding a branch *in the else* doesn't break the else
<pixelherodev> The else still generates correctly
<TheLemonMan> ...so it's `opt` that raises the error
<pixelherodev> No.
<pixelherodev> zig will still segfault there.
<pixelherodev> Because it's generating invalid IR and then trying to produce valid asm from it
<pixelherodev> opt just tells you what Zig is doing wrong
<pixelherodev> Well
<pixelherodev> Okay I see what you meant
<pixelherodev> The `opt` is what causes the error message to print, yes
<pixelherodev> Anyways, I think I figured out the specific logic that's breaking it
<pixelherodev> Adding in a branch in the else shifts the target of the if branch - at least *logically*
<pixelherodev> But that reference hasn't been updated
<pixelherodev> And is thus null
<pixelherodev> Branch in the if doesn't cause the same problem, because that's calculated before its target is
ur5us has joined #zig
<leeward> How does allowzero interact with optional pointers?
<leeward> Should `var p: ?*allowzero u8 = undefined` be legal?
FireFox317 has joined #zig
<TheLemonMan> yup, it's codegen'd as a *u8 and a i1 to store whether it's null or not
<leeward> So the thing in https://ziglang.org/documentation/master/#Optional-Pointers about optional pointers being guaranteed to be the same size as a pointer isn't true when using allowzero?
<TheLemonMan> that'd be unsound if it were true, don't you agree?
dingenskirchen has joined #zig
<leeward> I do. I'm just pointing out a bug in the documentation.
<leeward> Though I think there's a bug with coercion. If I try to coerce a ?*u32 to a ?*allowzero u32, I get a segfault.
<leeward> I would expect it to either succeed or fail to compile.
<TheLemonMan> do you have a minimal test case?
leeward has quit [Quit: Leaving]
leeward has joined #zig
FireFox317 has quit [Ping timeout: 276 seconds]
FireFox317 has joined #zig
protty has joined #zig
WendigoJaeger_ has joined #zig
<protty> anyone know why the test cases from https://github.com/ziglang/zig/pull/3918 are failing? doesnt look like it says anything
WendigoJaeger has quit [Remote host closed the connection]
WendigoJaeger_ is now known as WendigoJaeger
<pixelherodev> Okay, so uh - with a file opened via openWrite, is there an equivalent to fflush I need to use?
protty34 has joined #zig
<pixelherodev> Never mind.
* pixelherodev smacks his head into a wall
<pixelherodev> I was using the wrong file path :P
<TheLemonMan> leeward, good catch, you've found a simple yet gnarly-to-fix bug :)
<leeward> TheLemonMan: fun. Should I file it?
<protty34> fengb: looks like its always for single-threaded release-fast but cant find the reason of failure. All tests (excluding [free|net|open]bsd) work fine locally through qemu & wine
<TheLemonMan> leeward, sure thing, I have a one-line fix ready but I'm not 100% sure it's the right thing to do™ atm
protty has quit [Remote host closed the connection]
protty34 has quit [Remote host closed the connection]
protty has joined #zig
leeward has quit [Quit: Quit]
leeward has joined #zig
<pixelherodev> What bug is this?
<pixelherodev> Ah
<TheLemonMan> protty, the windows build is slightly more informative as it exits with EXCEPTION_ACCESS_VIOLATION
waleee-cl has quit [Quit: Connection closed for inactivity]
ur5us has quit [Ping timeout: 245 seconds]
jokoon has quit [Quit: jokoon]
FireFox317 has quit [Ping timeout: 265 seconds]
ur5us has joined #zig
<frmdstryr> protty34: Could you benchmark https://github.com/frmdstryr/zhp on your computer? Interested to see how it compares to the other results in your gist
<protty> TheLemonMan: you're right, its definitely segfaulting, but looks like it does so without outputting the test binary in zig-cache + the core dump backtrace in gdb is stripped..
dimenus has quit [Ping timeout: 248 seconds]
<protty> frmdstryr: sure, I can try it out
protty has quit [Remote host closed the connection]
FireFox317 has joined #zig
protty has joined #zig
<daurnimator> andrewrk: could you quickly verify https://github.com/ziglang/zig/issues/2930#issuecomment-566133164 for me? not sure if I was doing the wrong thing
leeward has quit [Quit: Leaving]
wootehfoot has quit [Quit: Leaving]
_Vi has quit [Ping timeout: 245 seconds]
<TheLemonMan> protty, you're hitting a compiler bug, yay
<TheLemonMan> protty, and I have a workaround for you!
<Snektron> i hit one in gcc the other day
<protty> uh oh / yay
<TheLemonMan> protty, make sure your `Held` structure is never zero-sized, IOW make `lock_init` always `false`
<protty> frmdstryr: https://gist.github.com/kprotty/3f369f46293a421f09190b829cfb48f7#file-newresults-md believe its due to the current impl of std.event.Loop. Its not hitting full cpu utilization and the worst case latencies are quite high on my end
<TheLemonMan> it's just another form of #3497, another silly yet nasty bug
protty has quit [Remote host closed the connection]
protty has joined #zig
<protty> ah ok. Its in the single threaded Mutex which is already in master. are other test cases hitting this as well?
<frmdstryr> protty: Thanks!
jjido has quit [Quit: Connection closed for inactivity]
<fengb> `Easy peasy.` followed by some arcane voodoo encantation
<TheLemonMan> aand I also have a fix
<andrewrk> hello TheLemonMan
<andrewrk> how are things in the citrus world
<TheLemonMan> life's wildly swinging between easy peasy lemon squeezy and difficult difficult lemon difficult
<TheLemonMan> other than that I'm happy to unwind a bit by fixing some bug here and there
<andrewrk> haha
<andrewrk> you might be interested in this branch, if I can get it to work: https://github.com/ziglang/zig/commits/ir-clean-up-vars
<andrewrk> it gets rid of the mem_slot thing, making all allocas the same, and gets rid of the differences in result locations between comptime code and non-comptime code
<andrewrk> lots of regressions to fix before it can be merged tho
<TheLemonMan> oh that sounds cool
<TheLemonMan> less tests -> less regressions to fix -> faster turnaround!
<andrewrk> lol
<andrewrk> the next major blocker for self-hosted is async I/O in std. the next major blocker for that is getting std.fmt.format to work as an iterator rather than using a callback function, so that std.fmt.format doesn't ever have to be async
<andrewrk> so that we can make std.os.write participate in async I/O
<TheLemonMan> aand I'm done for today, gn everybody!
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<andrewrk> good night
layneson has joined #zig
layneson has quit [Client Quit]