ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
clownpriest has joined #zig
sagecode has joined #zig
sagecode has quit [Ping timeout: 260 seconds]
isd1 has joined #zig
isd has quit [Ping timeout: 248 seconds]
isd1 has quit [Quit: Leaving.]
clownpriest has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
darithorn has joined #zig
clownpriest has joined #zig
Perelandric has quit [Ping timeout: 260 seconds]
pianofingers has quit [Quit: Leaving]
frmdstryr has quit [Ping timeout: 240 seconds]
clownpriest has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
isd has joined #zig
darithorn has quit [Quit: Leaving]
isd has quit [Quit: Leaving.]
<donpdonp> warn("pipeok %d\n", pipeok); => error: Unused arguments (pipe_ok is a c_int)
<donpdonp> not sure how to make zig happy here
<donpdonp> whoops, brain was in another langauge. %d should be {}. grin.
<donpdonp> whoops, brain was in another langauge. %d should be {}. grin.
<donpdonp> (ignore that repeat ":)
avisaven has joined #zig
avisaven_ has joined #zig
avisaven has quit [Ping timeout: 260 seconds]
avisaven_ has quit [Quit: Page closed]
dbandstra has joined #zig
zig009 has joined #zig
xtreak has joined #zig
very-mediocre has joined #zig
very-mediocre has quit [Ping timeout: 260 seconds]
zig009 has quit [Ping timeout: 260 seconds]
very-mediocre has joined #zig
xtreak has quit [Remote host closed the connection]
xtreak has joined #zig
xtreak has quit [Ping timeout: 265 seconds]
xtreak has joined #zig
very-mediocre has quit [Ping timeout: 260 seconds]
<GitHub87> [zig] andrewrk closed pull request #1084: Dir Open, Next, Close; DeleteDir for Windows (master...DirOpenWin) https://git.io/vh2tn
<GitHub43> zig/master 3dd9af9 Andrew Kelley: implement std.os.Dir for windows...
<GitHub43> [zig] andrewrk pushed 1 new commit to master: https://git.io/vhw6Y
dbandstra has quit [Quit: Leaving]
<GitHub86> [zig] andrewrk pushed 1 new commit to master: https://git.io/vhwiu
<GitHub86> zig/master 7580e39 Andrew Kelley: zig fmt
davr0s has joined #zig
very-mediocre has joined #zig
hoppetosse has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
donlzx has joined #zig
donlzx has quit [Ping timeout: 260 seconds]
donlzx has joined #zig
davr0s has joined #zig
xtreak has quit [Remote host closed the connection]
xtreak has joined #zig
xtreak has quit [Ping timeout: 268 seconds]
ofelas has quit [Ping timeout: 256 seconds]
ofelas has joined #zig
xtreak has joined #zig
Wizermil has joined #zig
JinShil has quit [Quit: Leaving]
xtreak_ has joined #zig
xtreak has quit [Ping timeout: 256 seconds]
xtreak has joined #zig
xtreak_ has quit [Ping timeout: 240 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
xtreak has quit [Ping timeout: 240 seconds]
noonien has joined #zig
byronh__ has quit [Ping timeout: 240 seconds]
byronh__ has joined #zig
byronh__ has quit [Ping timeout: 240 seconds]
byronh__ has joined #zig
donlzx has quit [Remote host closed the connection]
Wizermil has quit [Quit: Wizermil]
sagecode has joined #zig
ManDeJan has joined #zig
<donpdonp> fn do() { var thing = Thing{...} }
<donpdonp> fn do() { var thing = Thing{...}; list.append(thing) }
<donpdonp> assuming list is outside do(), is that wrong? will the memory for Thing{} get trashed once do() exits?
very-mediocre has quit [Ping timeout: 260 seconds]
Hejsil has joined #zig
<Hejsil> donpdonp, that depends on how the list stores thing
<donpdonp> its a std.ArrayList
<Hejsil> If your list is ArrayList(Thing), then the array list copies your thing, and there is no prob
Wizermil has joined #zig
<Hejsil> If your list is ArrayList(*const Thing) then it copies a pointer to thing, and you have a problem
<donpdonp> interesting.
<donpdonp> var actors: std.ArrayList(Actor)
<Hejsil> Well, you are storing Actor, and not *Actor, so your list owns that memory
<donpdonp> im getting weird behavior, but im also doing werid things - putting the &actor into pthread_create's void*
<donpdonp> inside do it looks good (gdb) p actor
<donpdonp> $3 = (struct Actor *) 0x7fffffffd1a0
<donpdonp> (gdb) p *actor
<donpdonp> $4 = {thread = 140737108252416, read_fd = 5, payload = {ptr = 0x2372a3 <global_allocator_mem+523> "https://mastodon.xyz/@donpdonp", len = 30}}
<donpdonp> has an address and value, but in the thread its 0'ed out
<donpdonp> net.go actor Actor@7fffffffd1a0
<donpdonp> net.go id 0 payload -= =-
<donpdonp> the ptr is the same but thread(called id) is 0, and inbetween -= =- should be the URL
<Hejsil> A snipped of code would give me a better idea of the problem :)
<Hejsil> Though, dangling pointers could come from anywhere, so idk if you can give a small snippet
<Hejsil> andrewrk, are hard links suppose to be treated as different files by the Zig compiler?
<Hejsil> Aka, hard links that point to the same inode
Hejsil has quit [Quit: Page closed]
xtreak has joined #zig
Hejsil has joined #zig
xtreak has quit [Ping timeout: 240 seconds]
ManDeJan has quit [Quit: Page closed]
<donpdonp> thx for the feedback. im away from my laptop for a bit
<donpdonp> standing in line at an airport
Tobba has quit [Read error: Connection reset by peer]
Tobba has joined #zig
<donpdonp> sorry for the sloppy state of the code. line 51 calls pthread_create with the data field set to the actor variable
<donpdonp> the destination is line 33 and somewhere inbetween the struct gets zeroed.
<bheads_> sigh.... zig errror: TODO for loop on var args
<donpdonp> heh. patches welcome i bet :)
<bheads_> lol I really need to get my head around the compiler internals, probably faster to rewrite this function as a while loop :)
<donpdonp> Hejsil: the tip about the copy operation led me to the fix. i was passing the ptr to the struct before the append()
<donpdonp> now i do list.at(last) and I get the right copy in memory. thx.
<Hejsil> Ooh, nice
davr0s has joined #zig
<donpdonp> wel i spoke too soon, still seeing some weirdness, but i have more tools to use now :)
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Wizermil has quit [Quit: Wizermil]
very-mediocre has joined #zig
davr0s has joined #zig
<donpdonp> before pthread_create: payload []const u8@7ffe827d5f20 x30x
<donpdonp> after (in receiver function): payload -= []const u8@7ffe827d5f20 x0x =-
<donpdonp> thats from a field in the struct that gets passed.
<donpdonp> first its len30, then len0. same address. sigh.
clownpriest has joined #zig
zig009 has joined #zig
zig009 has quit [Client Quit]
<donpdonp> the struct from the arraylist matches before/after as well. actor_copy Actor@7ffe827d5f10 net.go actor Actor@7ffe827d5f10 (receiver)
<donpdonp> i suppose i should try and shrink this down toa test case.
<bheads_> Do varargs seal a function signature?
mahmudov has quit [Ping timeout: 240 seconds]
<bheads_> I have a function: pub fn put(self: *Self, args: ...) !void { ...} then: try a.put(u8('e')); try a.put([]u8{"llo"}); I get the error: error: expected type 'u8', found '[3]u8'
<bheads_> lol nm []u8{"llo"} is not valid!
hoppetosse has quit [Ping timeout: 265 seconds]
<donpdonp> the simple case of my struct memory prob seems to work fine.
<Hejsil> Do you append more actors while in your thread?
<Hejsil> Or, in general. Do you append after taking a pointer to an item in the list?
<donpdonp> nope.
* donpdonp gets in line to board a plane
<Hejsil> Well, that was my best guess
<bodie_> andrewrk, very nice doc! :D I notice there's a new notation with the angle brackets which has interface-like semantics. have you thought about generalizing this feature?
Hejsil has quit [Quit: Page closed]
bheads__ has joined #zig
bheads_ has quit [Ping timeout: 256 seconds]
<very-mediocre> bodie_ i see coroutine docs were added
<very-mediocre> reminds me I'd like to toy with generator style streams
<bheads__> is there a way to do varargs of a given type? args: T ... ? or should I just check them at comptime and fail if not the right type?
<very-mediocre> don't think so
<clownpriest> someone should post an issue proposal about that. seems like something that would be a really useful addition
<clownpriest> though i think there are plans to get rid of varargs entirely? idk why, they're great
<clownpriest> tho i could be wrong
<very-mediocre> Could be wrong but from what I gather, they may be replaced with Tuples
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<byronh__> Either way, i guess I will just check the type at comptime. Almost have this appender done.
<very-mediocre> here it is
<clownpriest> is "///" supposed to start a doc comment? i dont see mention of it in the documentation, but some of the standard library seems to follow this convention
mahmudov has joined #zig
<byronh__> Thanks, cant wait for tuples
<very-mediocre> Yeah I like where this is going
jjido has joined #zig
<clownpriest> we need a good interface/trait/concept system for this to be really tight, i think. tho i also think that has the potential to bloat the language too much
<very-mediocre> Was just thinking the same thing, I think interfaces are inevitable
<clownpriest> yeah
<very-mediocre> Was reading the proposal for tuple args would use "var" as the type
<very-mediocre> feels a bit loose
<clownpriest> same lol
<clownpriest> can i "+" all these vars? who knows!
<very-mediocre> even Rust's "innovative" thing, traits, boils down to interfaces
<clownpriest> yeah
<very-mediocre> I read on github that Golang style implicit interfaces were rejected though
<clownpriest> from personal experience, it's not ideal
<jjido> Traits are interfaces with generic methods no?
<bheads__> I would have thought it would be args: tuple
<bheads__> se need to build a good std.meta then we can just use duck typing
bavier` has quit [Quit: Leaving]
<clownpriest> just need to make sure alexandrescu stays out of it
<bheads__> should have functions like isArrayOf(comptime arry: type, comptime T: type) bool { .. is arry an array of Ts
<very-mediocre> jjido: lots of subtleties but it's like you can provide an implementation for anything in order to make it match the trait
<very-mediocre> sort of like interfaces, but you add the part where a struct conforms to the trait almost like a mixin
<bheads__> I think we should skip interfaces and use concepts or duck typing
<very-mediocre> instead of defining the struct like "mystruct implements mytrait"
<very-mediocre> doesn't runtime duck typing carry an overhead?
<bheads__> comptime duck typing
<clownpriest> bheads__ how would you express that something satisfies an interface with isarrayof()?
<clownpriest> does the type itself carry that information?
<clownpriest> unless T is a trait, and arry implements it somewhere
<very-mediocre> I could be way off base, but I feel like the least painful solution would be what TypeScript does with anonymous objects
<clownpriest> i'd rather not check all the possible types that could potentially satify the behavior i need it to accept
<bheads__> pub fn isAllocator(T: type) bool { ... meta.hasFunction(T, "alloc", fn (self: *Allocator, byte_count: usize, alignment: u29) Error![]u8)); .. all the allocator functions
<bheads__> then in your code
<bheads__> comptime if (!isAllocator(T)) unreachable
<clownpriest> hmm
<clownpriest> nice
<bheads__> so the check is a comptime bool function
<clownpriest> and it's all userland?
<bheads__> yes
<clownpriest> that is pretty sweet
<bheads__> yep, thats what I like about it
<bheads__> we only need things like typeInfo
<bheads__> and the stdlib has a good meta package that makes writting them easier
<bheads__> but you dont need std.meta, you can roll your own
<clownpriest> right
<clownpriest> you working on a std.meta right now?
<bheads__> I have bits of one in a project, but I am going to start my own utils git repo where I put some common code
<clownpriest> cool
<bheads__> I am still trying to get a hang of typeInfo and friends
<bheads__> but running into comptime bugs
<very-mediocre> Typescript style tuples with union types: pub fn whatever(len: usize, tuple: *[x: usize, y: f32] | *[x: usize, y: *SomeStruct, z: f64])
<very-mediocre> the compiler could infer the return type
<very-mediocre> so you wouldn't have to type all of that out
<very-mediocre> er remove the pointer, assume tuples are value types
<very-mediocre> if you return various types of tuples they could be inferred
<very-mediocre> I think I need coffee, I'm not impressed with myself :)
<very-mediocre> that can go wrong in so many ways
<bheads__> lol
<bheads__> If you know the types to return, then its just a struct
<very-mediocre> yeah but it's a bit boilerplate-y
<bheads__> pub fn frog(t: tuple) tuple { return .{1, 2}; }
<bheads__> fn chewit() (struct{ x: i32, y: u32}) { return .{.x = -32, .y = 0}; }
<bheads__> need to be able to inline a struct in a function signature
<very-mediocre> that's decent
<bheads__> the name could be chewit.return or @TypeInfo(@typeOf(chewit)).Fn.return_type
<very-mediocre> andrewrk points out in the github issue that multiple types of tuples could be returned
<very-mediocre> so structs wouldn't work, that's why I got into implicit union types
<bheads__> or just meta.returnType(chewit)
<bheads__> thats where tuple comes in
<very-mediocre> right
<bheads__> you dont know whats packed in it
<very-mediocre> this brings us back to the "var" or "tuple" typ
<very-mediocre> being a bit loose
<bheads__> right, I think andrew was say all vars are now at least a tuple of 1
<very-mediocre> hm
<very-mediocre> but say a function can return 2 kinds of tuples with different signatures
<very-mediocre> surely some static analysis could be done by inferring the return type as a union type
<very-mediocre> rather than keeping it as a loose "tuple"
<very-mediocre> the problem arises when you try to assign the result of a function like that
<bheads__> right, tuples will be tricky
<very-mediocre> like `var whatever = function_with_2_return_types()`
<very-mediocre> this only works if you have implicit union types
<bheads__> also I think var == tuple will lead to lots of code that rejects var as a tuple
<very-mediocre> so whatever would be of type [type1 | type2]
<very-mediocre> how so?
<bheads__> right now var is a single argument, so all of that code now needs to support it as an array of 0 or more arguments
<very-mediocre> right
<bheads__> so if you want 1 var type you have to check the type and reject it if not
<bheads__> I think var should stay and tuple added as a type
<very-mediocre> yeah, i think so
<very-mediocre> but then that feels a bit loose
<bheads__> plus there is code that does fn fishbones(x: var) @typeOf(x) { ... }
<bheads__> how does that translate that x is now a tuple?
<very-mediocre> implicit union type of all possible returned tuples :)
<very-mediocre> or
<very-mediocre> interface that all returned tuples must conform to
<very-mediocre> meaning if the function returns type1 or type2
<very-mediocre> x is of type {type1|type2}
<very-mediocre> or
<bheads__> right but now fn abs(x: var) @typeOf(x) { if (x < 0) return -x; else return x; }
<very-mediocre> otherwise we're in interface territory
<bheads__> that code is simple and readable
<very-mediocre> true
<bheads__> but if x is now a tuple... what happens?
<very-mediocre> good point
<very-mediocre> keeping simplicity is gonna be challenging
<very-mediocre> not to sound like a broken record, but this brings me back to interfaces
<very-mediocre> because what i described above with the implicit union types... yikes
<very-mediocre> with an interface that function would still be clear
<bheads__> maybe the compiler could see that x is not used as a tuple and not make it a tuple, but thats to much like magic
<bheads__> you can do that same with duck typing
<bheads__> comptime if (!meta.isNumberType(@typeOf(x)) unreachable;
<bheads__> in the function
<very-mediocre> true
<very-mediocre> it's cool but feels a bit boilerplatey
<very-mediocre> because when you're doing `isNumberType`
<very-mediocre> is that not really just an interface?
<very-mediocre> what you're saying is the type has to conform to a certain contract
<bheads__> no its a comptime function
<very-mediocre> i mean effectively an interface, not literally
<very-mediocre> like equivalent
<bheads__> I would think more of a constraint
<very-mediocre> that meta statement is verifying that the type can have abs() done on it
<very-mediocre> (at compile time, which is the cool part)
<bheads__> right
<very-mediocre> but i wonder if it's not just simpler to say
<bheads__> I would love to move that into the function signature, or the argument
<very-mediocre> fn abs(x: Numerical) Numerical { if (x < 0) return -x; else return x; }
<very-mediocre> feels more readable
<very-mediocre> hm, I see
<bheads__> but thats a type
<very-mediocre> it's an interface
<very-mediocre> it would accept any type that implements that interface
<bheads__> abs(x: var) @typeOf(x) if(meta.isNumber(x)) { ... }
<very-mediocre> call it INumerical if you're from the C++ world
<very-mediocre> hm, that's pretty nice
<very-mediocre> but will there be something like "isNumber" for every situation?
<bheads__> thats how D solved this problem
<very-mediocre> what if you need a more complex constraint
<very-mediocre> just to be clear, I'm not knocking the idea, just playing devil's advocate
<bheads__> no, but you can write your own
<very-mediocre> i think compile time features are very exciting
<bheads__> just write a function that tests the T
<bheads__> then use that
<bheads__> meta is just the building blocks
<clownpriest> maybe we just blow everything up and become haskell? http://learnyouahaskell.com/types-and-typeclasses
<very-mediocre> isn't that more convoluted than writing an interface?
<clownpriest> i'll show myself out....
<bheads__> nope
<very-mediocre> lol
<bheads__> ban clowns
<bheads__> lol
<clownpriest> lol
<very-mediocre> ok zig is finished i guess
<very-mediocre> andrewrk had a good run
<bheads__> fn isMyDuck(comptime T: type) bool { return meta.hasFn(T, "quack", fn () void) && meta.hasFn(T, "eatCrackers", fn(i32) !void); }
<bheads__> it might not be a clean as a java interface but they are simple to write
<bheads__> you can even check if the struct has or doesn't have member
<bheads__> return !meta.hasFn(T, "bark", fn() void) ...
<bheads__> cant do that in java
<bheads__> besides zig doesnt have inheritence (thank thor!) so interfaces dont mean as much
xtreak has joined #zig
<very-mediocre> My mediocre brain can't keep up, I forgot how this solves the assignment problem
<bheads__> lol whats the assignment problem?
<very-mediocre> var something = function_that_returns_n_types_of_things();
<very-mediocre> what's the type of `something`?
<bheads__> ahhh tuple unpacking
<bheads__> yeah thats tricky
<bheads__> so var x = fn1(); // x is now a tuple
<very-mediocre> yeah but is "tuple" sufficient as a type?
<very-mediocre> it could be anything
<bheads__> var x: i32, var y: i3, z) = fn1(); // unpack the tuple
<bheads__> probably will be an annonmus struct
<very-mediocre> what if various tuple signatures can be returned
<bheads__> then its going to need an allocator!
<very-mediocre> the tuple deconstruction idea is cool, I was thrilled when they added that to JavaScript
<bheads__> also you cant unpack like that then
<very-mediocre> yeah
<bheads__> you can only upack if the compiler knows the tuple signatre
<very-mediocre> not sure what that means for ergonomics
<bheads__> which is why I think returning an inline struct type makes more sense
<bheads__> not to different then returning a []T right, you will need to process the array
<bheads__> a tuple is like a []var array
<bheads__> just each element may change
<very-mediocre> []T works thanks to compile time
<bheads__> right
<very-mediocre> i'm still iffy on `tuple` or `var`
<bheads__> []UnionOfAllTypes
<very-mediocre> Back to the dreaded implicit, inferred union of all return types :)
<very-mediocre> i think with tuples, we have to face the music
<bheads__> that may only need to exists for runtime tuples
<very-mediocre> it's not a dynamic language in the end
<bheads__> if the tuple is known at comptime then it can be a struct
<very-mediocre> yes we are aligned regarding comptime
<bheads__> :)
<bheads__> but runtime tuples will suck anyways since you will need to allocate the storage for them
<very-mediocre> true
<very-mediocre> the thing is when i think of tuples, i think of that python experience
<very-mediocre> or the javascript experience with anonymous objects
<very-mediocre> this cannot be that
<bheads__> yeah, its simple when you have a gc
<very-mediocre> so it begs the question, why not just define a union containing a bunch of structs
hoppetosse has joined #zig
<bheads__> you can make a simple tuple right now, make an array of a union of all types you want to support
<bheads__> you can also return multiple types
<bheads__> just make a struct
<very-mediocre> yep, so then what do tuples do
<bheads__> tuples really are just a QOL
<bheads__> reduce code written
<very-mediocre> agreed but then it feels like instead of adding a new concept
<bheads__> simpler interfaces
<very-mediocre> something could be done to improve the ergonomics of what's already there
<bheads__> tuples may only exists as a replacement for varargs
<very-mediocre> a terrible example, but an example nonetheless: those inferred union param/return types
<bheads__> right, maybe all tuples have to be known at compile time
<bheads__> then its simple
<bheads__> you can cant add or remove from a tuple
<bheads__> its sealed
<very-mediocre> 👍
<bheads__> might be andrews plan all along
<very-mediocre> I'm sure he will find a good solution
<very-mediocre> for me these are just fleeting thoughts
<bheads__> lol
<bheads__> maybe: var x = tuple{1 , 2, 3};
LucidToroise has joined #zig
<bheads__> var y = tuple{ x.!, 4}; // y is now 1, 2, 3, 4
LucidToroise has quit [Client Quit]
<very-mediocre> that's kind of JavaScripty
<very-mediocre> er, in the good way, i mean
<bheads__> some way to expand a tuple into another tuple
<bheads__> then var z = y[0..2]; // 1, 2
LucidTortoise has joined #zig
<bheads__> slice the tuple down
<bheads__> the tuple type is still know in comptime
<bheads__> okay, I gotta go. later all
<LucidTortoise> Just watched the talk. Now I am excited.
<very-mediocre> cya bheads__
<LucidTortoise> So, is Rust still an interesting option for people jumping on to Zig?
lorde_kumamon[m] has quit [Remote host closed the connection]
sg-james[m] has quit [Remote host closed the connection]
dtz has quit [Remote host closed the connection]
bb010g has quit [Remote host closed the connection]
pqflx3[m] has quit [Read error: Connection reset by peer]
clebermatheus[m] has quit [Remote host closed the connection]
kammd[m] has quit [Remote host closed the connection]
<andrewrk> Hejsil, I haven't considered how hard links should work. How it works now is that the resolved, absolute path of a file is the unique identifier of a source file for importing
byronh__ has quit [Ping timeout: 240 seconds]
xtreak has quit [Ping timeout: 260 seconds]
<andrewrk> which means that hard links and soft links alike count as different source files according to the importing system
<andrewrk> bodie_, do you have a specific proposal? regarding angle bracket syntax
byronh__ has joined #zig
Ichorio has joined #zig
LucidTortoise has quit [Quit: Leaving]
<andrewrk> LucidTortoise, hope you liked it. I'd definitely recommend trying Rust
bheads_ has joined #zig
bheads__ has quit [Ping timeout: 240 seconds]
byronh__ has quit [Ping timeout: 240 seconds]
<clownpriest> andrewrk, are "///" comments for docs? it's not mentioned in the current documentation, but show up in the stdlib
<andrewrk> clownpriest, yes
<andrewrk> I will add that to the docs today
<clownpriest> is there a documentation generator currently implemented?
<andrewrk> not yet
<clownpriest> kewl
byronh__ has joined #zig
pqflx3[m] has joined #zig
jjido has quit [Read error: Connection reset by peer]
davr0s has joined #zig
<bodie_> andrewrk, no, just curious about your thoughts / whether you're thinking of adding something like traits
<bodie_> or compile-time interfaces or whatever
<bodie_> I guess that's what the new comptime stuff is for
byronh__ has quit [Ping timeout: 245 seconds]
<andrewrk> angle brackets are unrelated to that - I just needed something that was not ambiguous with parenthesis because those are used for the function call syntax
<andrewrk> there is an open issue for traits or whatever, and it's this: https://github.com/ziglang/zig/issues/130
<andrewrk> if we can get away with *not* having that, that would be the best case
<andrewrk> but I'll do a proof of concept GUI in zig before making that decision
bheads__ has joined #zig
bheads_ has quit [Ping timeout: 260 seconds]
lorde_kumamon[m] has joined #zig
bb010g has joined #zig
dtz has joined #zig
sg-james[m] has joined #zig
kammd[m] has joined #zig
clebermatheus[m] has joined #zig
byronh__ has joined #zig
dbandstra2 has joined #zig
clownpri_ has joined #zig
clownpri_ has quit [Client Quit]
clownpriest has quit [Ping timeout: 276 seconds]
clownpriest has joined #zig
<GitHub119> [zig] isaachier opened pull request #1100: Add test.h and foo.h to gitignore (master...gitignore-test-and-foo-headers) https://git.io/vhrpW
Tobba_ has joined #zig
Tobba has quit [Ping timeout: 264 seconds]
clownpriest has quit [Ping timeout: 276 seconds]
byronh__ has quit [Ping timeout: 245 seconds]
byronh__ has joined #zig
byronh__ has quit [Ping timeout: 276 seconds]
byronh__ has joined #zig
very-mediocre has quit [Ping timeout: 260 seconds]
byronh__ has quit [Ping timeout: 276 seconds]
mahmudov has quit [Ping timeout: 240 seconds]
<GitHub143> [zig] andrewrk pushed 1 new commit to master: https://git.io/vhoIT
<GitHub143> zig/master 2594132 Andrew Kelley: fix ability to call mutating methods on zero size structs...
clownpriest has joined #zig
<GitHub37> zig/master fdd9cf0 Andrew Kelley: better debugging for CI failures of std.atomic
<GitHub37> [zig] andrewrk pushed 1 new commit to master: https://git.io/vhoI5
byronh__ has joined #zig
<GitHub188> [zig] andrewrk closed pull request #1100: Add test.h and foo.h to gitignore (master...gitignore-test-and-foo-headers) https://git.io/vhrpW
<GitHub86> [zig] andrewrk pushed 1 new commit to master: https://git.io/vhoL8
<GitHub86> zig/master 13d3255 Andrew Kelley: docgen: don't leave garbage .h files lying around...
mahmudov has joined #zig
mahmudov has quit [Read error: Connection reset by peer]
mahmudov has joined #zig
<GitHub41> [zig] andrewrk closed pull request #1056: WIP: Add snapcraft.yaml (master...snapcraft) https://git.io/vh4Ef
very-mediocre has joined #zig
byronh__ has quit [Ping timeout: 276 seconds]
byronh__ has joined #zig
hoppetosse has quit [Ping timeout: 260 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
ysengrimm has quit [Quit: The Lounge - https://thelounge.chat]
davr0s has joined #zig
ysengrimm has joined #zig
hoppetosse has joined #zig
noonien has quit [Quit: Connection closed for inactivity]
very-mediocre has quit [Quit: Page closed]
hoppetosse has quit [Ping timeout: 260 seconds]
bheads has joined #zig
dtz has quit [Read error: Connection reset by peer]
clebermatheus[m] has quit [Remote host closed the connection]
kammd[m] has quit [Remote host closed the connection]
lorde_kumamon[m] has quit [Remote host closed the connection]
pqflx3[m] has quit [Remote host closed the connection]
sg-james[m] has quit [Remote host closed the connection]
bb010g has quit [Read error: Connection reset by peer]
hoppetosse has joined #zig
<GitHub86> [zig] isaachier opened pull request #1101: Fix types in AST switch statements (master...ast-switch-fixes) https://git.io/vhoZS
pqflx3[m] has joined #zig
bb010g has joined #zig
lorde_kumamon[m] has joined #zig
dtz has joined #zig
sg-james[m] has joined #zig
kammd[m] has joined #zig
clebermatheus[m] has joined #zig
clownpriest has quit [Ping timeout: 256 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Ichorio has quit [Ping timeout: 256 seconds]
dbandstra2 has quit [Ping timeout: 260 seconds]
<bheads> Having an issue with tests the function at line 223
<bheads> When I include the last test of the file and run zig test there is no output
<bheads> not even an error
<andrewrk> that sounds like a zig bug
<bheads> okay I will get a reduced set and post a bug
<bheads> so when I isolate the code it works...
<bheads> nm git is messing with me
<andrewrk> thanks
dtz has quit [Remote host closed the connection]
clebermatheus[m] has quit [Remote host closed the connection]
sg-james[m] has quit [Remote host closed the connection]
kammd[m] has quit [Remote host closed the connection]
bb010g has quit [Write error: Connection reset by peer]
pqflx3[m] has quit [Remote host closed the connection]
lorde_kumamon[m] has quit [Write error: Connection reset by peer]
clownpriest has joined #zig
<clownpriest> bheads__, is there a way to check function signatures using this sort of thing?
<clownpriest> i dont see it currently implemented, but in principle
pqflx3[m] has joined #zig
<byronh__> Yeah you can, just neess more work
<GitHub151> [zig] andrewrk pushed 1 new commit to master: https://git.io/vho2f
<GitHub151> zig/master 86adc1e Andrew Kelley: add docs and missing test case for merging error sets...
<byronh__> Check out @typeInfo in the docs
<andrewrk> oops
<clownpriest> byronh__, wow that's cool
<clownpriest> seems like this totally obviates the need for language semantics concerning traits
<clownpriest> though i guess the tradeoff is verbosity?
<andrewrk> I'm not following along in the discussion fully, but in general zig is willing to have more verbosity in exchange for fewer language features
<andrewrk> provided that the verbosity does not lead to footguns or other kinds of bad habits
<clownpriest> andrewrk, basically just use @typeinfo to design a general purpose library that takes care of everything interfaces would do
<clownpriest> have libraries explicitly ensure their contracts with that library
<bheads> So far a I found a few bugs, but also it seems like typeInfo turns function args and returns into vars
<andrewrk> bheads, really, it should distinguish between generic functions and non-generic functions
<bheads> not all of them, but its turned alloc in fn(*Allocator, var, var) var
<bheads> which is hard to validate
<andrewrk> it's a generic function. we had to stop evaluating the parameters at arg[1]
<bheads> yeah, I get it, just makes duck typing hard to detect
<bheads> makes me wonder if @compiles would help
<andrewrk> I'm very skeptical that @compiles is a good idea
<bheads> yeah, I just dont know how to solve type checking generics
<bheads> I would like to take a type T and check that its can be used as an Allocator
<bheads> or an Iterator, or some other traits concept
bb010g has joined #zig
lorde_kumamon[m] has joined #zig
dtz has joined #zig
sg-james[m] has joined #zig
kammd[m] has joined #zig
clebermatheus[m] has joined #zig
<bheads> clownpriest, if you have an idea of a traits check for function args let me know and I can add it
<clownpriest> will do
<clownpriest> is there a way to implement methods on primitive types?
<andrewrk> no
<clownpriest> word