ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
kristoff_it has joined #zig
fubd has joined #zig
fubd has quit [Remote host closed the connection]
kristoff_it has quit [Ping timeout: 244 seconds]
fubd has joined #zig
<fubd> has anyone made a minimal imgui-like in zig yet?
<daurnimator> sorry all; have been out sick for a couple of days
<daurnimator> anything good I missed in scrollback?
<Tetralux> asyncfn semantics back and forth
<Tetralux> talk about 'defer return'/'defer try' xD
laaron has quit [Quit: ZNC 1.7.1 -]
laaron has joined #zig
<scientes> fubd, if you mean imgur, there is no networking
<fubd> scientes: I meant more an immediate mode UI library, like the kind useful for example, games
<scientes> dimenus is working on a vulkan library IIRC
<scientes> I'm also working on SIMD
<daurnimator> someone was working on sokol
<scientes> which would be essential for ray tracing
<scientes> daurnimator, what is sokol, all I can find is what it was named after
<daurnimator> scientes:
<scientes> looks similar to YMCA
<scientes> oh i see, its a pun on vulkan
<scientes> oh, vulcano != vulture
batok has quit [Remote host closed the connection]
<scientes> qt6 is also writing a graphics api compat layer
<scientes> there are so many of them!
<daurnimator> qt? no thanks. although its the best, you really *have to* write C++ to use it
<scientes> C++17 too
<daurnimator> I was so hopeful for libui ( but development died :(
<daurnimator> I'm hopeful that letoram can suggest good UI primitives for zig....
<daurnimator> nrdmn: I don't understand in your uefi PR why you have the default values set to undefined
<fubd> I'm really missing odin's function overloading
<fubd> i find myself writing tons of wordyFunctionsThatLookLikeObjectiveC
<fubd> and not feeling like making comptime type switches for every overload is sustainable
<daurnimator> fubd: got some examples to share?
<scientes> fubd, and it doesn't work for optional arguments either
<daurnimator> fubd: note that you *can* do function overloading in zig by switching on `@typeOf(somearg)`. but it's not recommended....
<scientes> opt1: var, op2: var, op3: var
<daurnimator> fubd: that looks like a good usecase for switching on the type of an argument
<scientes> daurnimator, unless its (comptime T: type .. @typeOf(T)
<scientes> or rather switch (T)
<scientes> what are those vector types? because you can write code that works with any vector length
<scientes> although I kinda need to make pointer arithmatic work for that...need to polish up the patch
<daurnimator> fubd: `fn setUniformInt(uniform_id: c.GLint, value: var) void { switch(@typeId(@typeOf(value))) { .Int => c.glUniform1i(uniform_id, value), .Float => c.glUniform1f(uniform_id, value), else => @compileError("invalid type to setUniform"), } }`
<fubd> scientes: struct { x: f32, y: f32, z: f32 }
<scientes> Vec3, Vec4...
<fubd> if I used something like data: [N]f32
<fubd> then everywhere I access the vector, I have to use[1]
<scientes> that isn't a vector
<scientes> use (comptime vlen: u32, v: @Vector(vlen, foo))
ky0ko has quit [Disconnected by services]
ky1ko has joined #zig
<fubd> I was scared away by the docs on using @Vector yet
<fubd> but if anyone has actual game code that is using it and wants to share examples I'd love to see
<fubd> s/game/anything
<daurnimator> fubd: yeah @Vector needs more work. scientes has been doing most of it.
kristoff_it has joined #zig
<fubd> awesome :)
<scientes> I really need inferred return types to be implemented
<scientes> I know that can be a foot-gun, but it means that much more can be implemented in user-space
<fubd> oh yeah, i ran into that with something else...
<scientes> also, maybe someone could help with C ABI for @Vector
<fubd> daurnimator: one thing that nags at me about using :var for overloading is definitely that you use the clarity of seeing function types for each parameter in the function definition
kristoff_it has quit [Ping timeout: 248 seconds]
<fubd> in odin you can just say
<fubd> foo :: proc{
<fubd> and then look to the definitions of each function for the possible matches
<fubd> i suppose having proper pattern matching could let you unpack types right in the first couple lines of a var function
<fubd> but yeah it definitely feels less readable/discoverable
<fubd> \/toolable
<scientes> yeah but the only "fix" for that is something like Haskell's type system, which honestly I don't understand
<scientes> this is kind of a side-effect of powerful comptime
<fubd> the syntax for explicit function overloading couldn't just write out the comptime function for a set of type switches?
<daurnimator> fubd: you might want to follow
<fubd> daurnimator: thanks, i'll dig into more of the active issues and try to contribute there too
<scientes> because you can still use named
<scientes> its clear
<fubd> yeah I like that
<Tetralux> +10
<scientes> i just got something better
<fubd> now I'm deep into var-ifying this function, and i need a "is this thing stringlike" function
<scientes> not sure about the syntax though
<Tetralux> I don't use the explicit proc overloading very often in Odin, but when I do, I love it.
<Tetralux> If I had my way, we'd already have function overloading.
<fubd> i passed [4]u8
<scientes> we can just allow functions to be types
<fubd> but I compared to
<fubd> if (@typeOf(uniform) == []const u8) {
<scientes> the problem is getting a handle on the current function
<scientes> but i guess the "overload" keyboard is exactly that
<scientes> except we could split the matching from the execution
<Tetralux> I'm not sure I like the idea of anon fns with overloading like in that comment.
<Tetralux> I'd rather they just be named
<Tetralux> pub const init = overload { initNamed, dup }
<Tetralux> Or even
<Tetralux> pub fn init = overload { initNamed, dup }
<Tetralux> Then it's easier to change from no overload, to two overloads.
<Tetralux> Though the former is perhaps more important.
<Tetralux> It's depends on how much syntax you save from changing when you change it.
laaron has quit [Quit: ZNC 1.7.1 -]
<Tetralux> It's not clear why burying what's happening from the compiler is useful for that.
<Tetralux> How are tools meant to determine the overloads if they can't just be told by the compiler?
<Tetralux> Besides which, having 'overload {}' makes parsing all you need to do to discover it.
fubd has quit [Ping timeout: 260 seconds]
laaron has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 245 seconds]
<Tetralux> I actually quite like `fn { overload1, overload2 }` .. quick to type - easy to understand, surely?
<daurnimator> Tetralux: I'm not a fan.... requires a lot of context to understand
<Tetralux> A lot of context? You mean like is it `fn(` or `fn{` ? xD
<Tetralux> Gotta say - that seems fairly trivial to me.
<Tetralux> Did you have a specific example in mind?
<daurnimator> Tetralux: like... why would that not be an array initialiser of functions?
<daurnimator> i dunno, it just looks quite close to other things to me.
<Tetralux> Wouldn't functions need to have the parens `fn()` so that you know it takes no args?
<daurnimator> no? it could be referencing functions in scope
<daurnimator> the only difference would be [_] preceding it
<Tetralux> I mean, if you have fns that have different signatures -- or the same for that matter -- and you wanted to store them in a typed array, you would not be able to specify them as the eltype because the signature is part of the type.
<Tetralux> But also, `fn` is not a function pointer, `*fn` is.
<scientes> Tetralux, did you look at my proposal?
<scientes> yes
<Tetralux> It's not too bad.
<scientes> the way of having a function without a type signature, not sure about that
<scientes> `naked` is a similar concept
<Tetralux> Maybe you get around it with `.{initWithString, initWithSelf}`
<scientes> no, don't need new syntax
<Tetralux> Yeah, but we're getting that syntax anyway right.
<Tetralux> the `fn {` seems weird in that though.
<scientes> now its naked fn() {
<Tetralux> `init = fn {` that is.
<scientes> init = naked fn() {
NI33_ has quit [Ping timeout: 245 seconds]
Tetralux has quit [Ping timeout: 245 seconds]
<nairou> So this is confusing... I wrote a build.zig to compile an existing C-only program (no zig code). Compiles fine, but immediately crashes when run. I try to debug it, and the very first thing it does (before even reaching main) is hit a panic. zig code. "Cannot access memory at address 0xfffffffffffffff8". I'm not sure where to start with this. Why is there zig code in here? What would cause it to crash before it even began?
ltriant has quit [Ping timeout: 244 seconds]
marijnfs__ has joined #zig
marijnfs_ has quit [Ping timeout: 248 seconds]
laaron has quit [Quit: ZNC 1.7.1 -]
laaron has joined #zig
ky0ko has joined #zig
Tetralux has joined #zig
ltriant has joined #zig
<Tetralux> scientes: Maybe you could do something more like `pub const init = std.dispatch.overload(@This(), .{initWithString, initWithSelf});
<Tetralux> Still though.
<Tetralux> nairou: That's a weird one.
ltriant has quit [Ping timeout: 272 seconds]
marijnfs has joined #zig
marijnfs__ has quit [Ping timeout: 272 seconds]
_whitelogger has joined #zig
ltriant has joined #zig
ltriant has quit [Ping timeout: 245 seconds]
ltriant has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 272 seconds]
<andrewrk> nairou: you can start with --verbose-cc
<andrewrk> And --verbose-link
<andrewrk> You can try substituting the system linker, or you can try substituting clang, or you can try changing flags to narrow down the issue
<andrewrk> When you say it hits a panic in zig code, where do you see zig code? Can I see the error message?
<fengb> andrewrk: should aliasing builtins be supported? `const smallNoInlineCall = @noInlineCall;`
<andrewrk> fengb: there are a lot of problems with that
<andrewrk> As a workaround for your use case for now can you put your call/inline call in an if statement?
<fengb> Yeah, I was gonna write a proposal for @call but that wouldn't be useful without aliasing
<andrewrk> best thing to do is to detail your use case. you'll at least get something recommended of how to do it
<fengb> Sounds good thanks
<daurnimator> fengb: aren't you after something like: `const callFunc = if (builtin.mode == .ReleaseSmall) @noInlineCall else @call; callFunc(myfunc, arg1, arg2)`
<emekankurumeh[m]> with @call we can remove @noInlineCall, @inlineCall and @asyncCall. perhaps @newStackCall as well.
<daurnimator> I think a solution to this should consider
nairou_ has joined #zig
nairou has quit [Remote host closed the connection]
<fengb> daurnimator: yes but I can’t alias builtins so adding @call doesn’t fix things :/
<daurnimator> fengb: indeed. however you can hack something up using my stupid workaround in that issue :p
<fengb> My current solution is to have a inline wrapper func to do the dispatch but it looks clunky
<fengb> But less clunky than your proposal lol
<daurnimator> fengb: I was more suggesting that your wrapper func could be more 'universal'
<emekankurumeh[m]> #2930 should be fixed by tuples/anonymous structs right?
<daurnimator> emekankurumeh[m]: tuples might get us closer (or might not): but still need the "arguments of function X as tuple" function.
<daurnimator> I was also meaning to experiement with varargs to see if that 9 argument limit could be fixed with some recursion
<fengb> I think we all have a different idea of what @call should do :/
<emekankurumeh[m]> well if we are removing varargs then a anon struct is the way to go right?
<daurnimator> emekankurumeh[m]: how does an anon struct solve the issue?
<daurnimator> emekankurumeh[m]: for 2930 the question is how to call a function with an arbitrary number of arguments.
andrewrk has quit [Ping timeout: 245 seconds]
andrewrk has joined #zig
laaron has quit [Quit: ZNC 1.7.1 -]
laaron has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
ltriant has quit [Quit: leaving]
laaron has quit [Remote host closed the connection]
kristoff_it has joined #zig
laaron has joined #zig
kristoff_it has quit [Remote host closed the connection]
kristoff_it has joined #zig
NI33_ has joined #zig
laaron has quit [Quit: ZNC 1.7.1 -]
laaron has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
<gonz_> 04:10:50 <Tetralux> If I had my way, we'd already have function overloading.
<gonz_> If everyone had their way with one thing we'd have everything.
mikdusan1 has joined #zig
<gonz_> Overloading is obviously popular, I'm not discounting that. Most bad features that complicates languages at the very least start out popular enough to be implemented.
<gonz_> This is why I was trying to stress values as an up-front thing a while ago. If you have certain values that you can point to and say "These things are more important than X, and this compromises them" it's much easier to coalesce on these kinds of things.
<gonz_> But also to actually have concrete examples would be good.
mikdusan has quit [Ping timeout: 268 seconds]
<gonz_> It would be more helpful if people could infer easily that "my unwillingness to type 10 lines is not as important for zig as the willingness to keep odd keywords and complication out of it"
rom1504 has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
gamester has quit [Quit: Leaving]
NI33_ has quit [Ping timeout: 272 seconds]
Ichorio has joined #zig
ntgg has joined #zig
<mq32> hey
NI33_ has joined #zig
Ichorio has quit [Ping timeout: 264 seconds]
<samtebbs> mq32: o/
<mq32> i had a realization the last days:
<mq32> if zig gets both the function literals (#1717) and the proposed object semantics (#2938), making closures would be quite elegant via interfaces
<mq32> having a generic interface Callable(T:type) that has only one function "invoke" with the same signature as T
<mq32> a closure could then be an object that just implements this interface
_whitelogger has joined #zig
ntgg has quit [Ping timeout: 245 seconds]
andersfr has joined #zig
andersfr has quit []
<samtebbs> Then you'd need to figure out how capturing would work
ntgg has joined #zig
<samtebbs> You could go with the C++ route and make each "closure" a struct that has a field for each variable captured, and then assign to those fields when creating the closure
<samtebbs> The suitability of that to Zig is up for debate though
<mq32> it seems like the only possible way to do so
<shachaf> D has a nice feature for closures that are only used while a stack frame is active, where captures are made relative to the stack frame.
<mq32> that only works when you have stack frames
<shachaf> Yes, it's not suitable for general closures.
<mq32> samtebbs: the idea behind this interface thing is: i *could* implement closures with interfaces in userland, so a capturing closure would just be a syntactic sugar coating to remove redundant code
<mq32> let's say we capture everything by-value, but expose the captured variables as pub struct fields
<mq32> var counter:i32 = 0;
<mq32> var closure = fn() i32 { counter += 1; return counter; };
<mq32> _=closure.invoke(); _=closure.invoke();
ntgg has quit [Ping timeout: 246 seconds]
laaron has quit [Quit: ZNC 1.7.1 -]
laaron has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
laaron has quit [Remote host closed the connection]
laaron- has joined #zig
<samtebbs> Looks good to me
<daurnimator> what if closures took a @Frame?
<mq32> daurnimator: i don't think @Frame and closures are compatible without doing more hacks
<daurnimator> Aren't @Frames essentially a struct of local variables to a function?
<daurnimator> I guess with a closure you'd want to refer to multiple parent scopes...
<mq32> it depends on how @Frames are generated
<mq32> if they capture all local variables, it would be inefficient because closures can allocate all local variables on the stack and require only the captures to be stored
<daurnimator> mq32: I would think that they are a union of all local variables in scope at the various suspend points
<daurnimator> though now I'm having some memories bubble up of that time I implemented closures in another thing...
<daurnimator> let me go read my old code for a min
<mq32> 👍
<daurnimator> okay nope; that implementation used stack indirection. let me go check lua's which I've audited before...
<daurnimator> okay. lua's implementation is at least more translatable to zig; but it may violate the "hidden control flow" rule.... so we may need to make things explicit
<daurnimator> In lua, *if* a function created a closure, then when it returns, it "closes" that closure.
<daurnimator> what does that mean? => closure always use values by reference; however, each variable in the closure has an additional "hidden-ish" field
<daurnimator> when a closure is "closed", then it swaps the reference from a reference to the parent's variable, to storing it in the hidden field
<daurnimator> Lets imagine the following zig code: `fn foo() (fn() i32) { var x = getx(); const bar = fn() u32 { return x; }; return bar; }`
<daurnimator> at the point *before* foo returns, then bar's `x` points to the x on the stack. after the `return`, it has to be captured inside of `bar`
<daurnimator> mq32: ^ make sense?
<mq32> i'm trying to follow
<mq32> but if i understand correctly, this would require move semantics, right?
<mq32> (when the closure is moved(closed), the reference stored in the closure must update)
<daurnimator> yes.... though you may want to define what you mean by "move semantics"
<mq32> (moving the closure would require to change the captured reference)
<daurnimator> what do you mean by "moving the closure"
<mq32> copying/returning/otherwise changing its address
<daurnimator> we haven't got to "moving closures" yet (which is another topic we should get to). with the example above the value of `x` will get moved though
<mq32> so our closure requires to have some transparent field "x : *i32" and "x_backing_store : i32" and as soon as we close the closure, x will point to the backing_store, right?
<daurnimator> yep
<mq32> what value will bar reference, then?
<mq32> because returning the closure "bar" in the example will "change" the location of x
<daurnimator> ah yes. that's what you mean
<mq32> address of x_backing_store will change then
<mq32> also when i copy the closure value
<daurnimator> I haven't brought that up yet because copy elision semantics means we haven't hit that yet ;)
<mq32> heh
<mq32> assuming i would only use the return value at the point where i got it
<mq32> var a = make_closure(); var b = a; // this would break stuff
<daurnimator> mq32: well one thing is that it means the return value is a "fat function"
<daurnimator> ==> it's more than a function pointer getting returned; it's a function pointer + the closed variables
<mq32> that's clear
<mq32> but we just said that we require a backing store for the closed variables
<daurnimator> so... what if it returned a value of type @Closure
<mq32> and a reference that may be changed
<mq32> imho for most usecases it would be sufficient to have "downward closures" (so passing them *down* the call stack, not upwards)
<mq32> creating closures that allow this is easier (proposed solution is above)
<mq32> but: having full-featured closures would be still nice
<daurnimator> what would be the point of a "downward closure" as you call them?
<mq32> it's simpler in terms of memory management, implementation and explanation
<mq32> (because every captured variable just needs to be a pointer to the original var
<mq32> but that will not work if you leave your current stack frame
<daurnimator> I meant in terms of usage
<daurnimator> and also... I wouldn't call this a closure
<daurnimator> the whole thing about closures is the ... closing :P
<daurnimator> otherwise they're just "functions inside of functions" or something
<mq32> ah
<mq32> it's an improved callback thing
<mq32> so passing a compare function with dynamic comparison value
<daurnimator> So what if we had... `const bar = @Closure(somefunc); var x = bar.valueOf("x"); bar.close("x", &x);`
<daurnimator> mmm no. that wouldn't work well with the above example
ntgg has joined #zig
laaron- has quit [Remote host closed the connection]
laaron has joined #zig
laaron has quit [Quit: ZNC 1.7.1 -]
laaron has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
nairou has joined #zig
ntgg has quit [Read error: Connection reset by peer]
batok has joined #zig
andersfr has joined #zig
lluchs has joined #zig
andersfr has quit []
marijnfs has quit [Remote host closed the connection]
marijnfs has joined #zig
laaron has quit [Remote host closed the connection]
Akuli has joined #zig
laaron has joined #zig
<fengb> Do processors naturally span alignment boundaries? e.g. struct { a: u29, b: u6, c: u29 }
<daurnimator> 'processors'?
<daurnimator> fengb: in general: no unless you use `packed`
<fengb> I mean can CPUs even access that type of data or should I split it out to pairs of u29 + u3 and merge the u6 together manually
<Tetralux> I feel like that version of a closure is WAY too overcomplicated for zig.
<fengb> This scrollback is long
<Tetralux> The idea of an interface for a closure is also a no-no. I hate FnOnce/FnMut in Rust. It's not clear what those names even mean at face value.
<Tetralux> Things should be trivial to understand by their transparency.
<Tetralux> Otherwise, it becomes like exceptions: I don't really know how it works, but it does.
<Tetralux> I'd consider that a bad thing.
<fengb> We need something like an interface if we have fat closures
<Tetralux> I'm not sure we even need closures.
<fengb> That's a different topic then
<Tetralux> Whereas, the embedded type semantics I'd probably use a decent amount.
<Tetralux> I'd rather have locally-defined fns than closures personally.
<gonz_> Tetralux: The issue is mostly that everyone has their own pet feature. I think I agree mostly with what you said but I also am skeptical that my personal feelings about "Things that would be nice to have" have much merit.
<Tetralux> I mean... things are emperically useful.
<fengb> Therefore C++ is the most useful >_>
<Tetralux> You can look at code that uses certain features.
<mikdusan1> Tetralux: what do you mean by "locally-defined fns" ? we already can define fns
<Tetralux> See how readable, understandable, and neat it is.
<gonz_> Tetralux: The usefulness of things can be less than the complication they add in the long run.
<Tetralux> And think about how features could be used, maybe gravitate usage towards the best one.
<Tetralux> etc, etc, etc.
<Tetralux> mikdusan1: I prepared a paste for that:
<Tetralux> The point being: The syntax is the same regardless of declaration scope.
<mikdusan1> ok so just sugar. we can do that today with struct.
<Tetralux> In _no_ way is that sugar.
<gonz_> I keep harping on about explicitly stating values and here's where I think that's useful. Making clear what zig emphasizes and examples of what that encompasses is valuable.
<Tetralux> It just means "f is not visible outside this scope."
<Tetralux> But it's a static fn, _just_ like 'f' is.
<fengb> I think anon functions need local definition semantics
<Tetralux> Wait - why would I want a struct in order to declare a fn locally?
<mq32> <Tetralux> The idea of an interface for a closure is also a no-no.
<Tetralux> That makes no sense xD
<fengb> Implementation detail. Functions can only go "inside" of structs
<Tetralux> An incorrect detail. xD
<Tetralux> That comment is somewhat tongue-in-cheek, since
<Tetralux> It's VERY clear what that paste does.
<mq32> why is that a no-no? *if* we got interfaces, it would be an "only one way to do things"-thingy with syntax sugar for trivial @Callable() interfaces
<Tetralux> We don't need anything so opaque, for one thing.
<mikdusan1> Tetralux: looks like sugar to me.
<Tetralux> mq32: I do not want interface things for fns.
<fengb> mikdusan1: we need it for anonymous functions to be remotely useful
<Tetralux> That's OOP **** and I would soundly reject such a thing.
<mikdusan1> fengb: i know that
<Tetralux> f() should be a fn call.
<Tetralux> Not f.invoke.
<Tetralux> Only-one-way-to-do-things.
<mq32> yeah
<Tetralux> *fn(...), not Closure
<fengb> Um... Zig has OOP already, sorry to say
Akuli has quit [Remote host closed the connection]
<mq32> but it will probably result in having two different function types
<Tetralux> It does - and I don't especially love that.
<mq32> that's what i want to solve with the interfacy-stuff
<Tetralux> But we have `if () {}` (the parens) so without it it'd be painful like C.
<mq32> it would be obvious if something takes a "callable" or a "function"
<mq32> which are different things
<Tetralux> It only really bothers me a decent amount when adding methods to a poly struct.
<companion_cube> Tetralux: what's x.f() though?
<Tetralux> Method or field call.
<Tetralux> Whereas without methods, it'd always be field call.
<companion_cube> so it's not really one way of doing things? :p
<Tetralux> Correct.
<companion_cube> @callable seems unavoidable if you want closures, but not anonymous functions
<Tetralux> Personally, I'd prefer UFCS than methods.
<Tetralux> But that's just me.
<fengb> I wonder if we should borrow some Lua there, i.e. different syntax for method call
<Tetralux> I like dot honestly.
<Tetralux> I'm not sure what else you'd put there.
<mq32> as long as we don't do PHP-Style (using -> for method call)
<Tetralux> I'm not a fan of ':' from Lua.
<Tetralux> xD
<companion_cube> mq32: so you're find with --> ?
<companion_cube> fine*
<mq32> a=>b()
<companion_cube> a~~>b()
<fengb> ... I can't not read that as "a sperm into b"
<fengb> Embrace the inner 13 year old
<gonz_> a8===D~~~d()
<Tetralux> I'd honestly prefer -> over any of those xD
* mq32 just sits giggling in his office
* Tetralux giggles at that iamge
<companion_cube> a🍆b()
<fengb> What I mean is, "a.b" can sometimes stick the self variable as first arg
<Tetralux> a->f(), method call; a.f(), field call
<fengb> But it depends on field vs method
<fengb> If we had a different invocation type, there'd be no ambiguity
<daurnimator> there's an issue for that
<Tetralux> Either way, I care a lot less about that than I do about closures being sane xD
<Tetralux> And I care a decent amount less about that than I do about composition.
<daurnimator> Tetralux: you have a weird definition of a closure if it doesn't close over anything
<fengb> Trips up newcomers that you have to do allocator.reallocFn(allocator, ...)
<Tetralux> I don't consider non-capturing local functions, closures.
<Tetralux> But they fill the same role for me.
<Tetralux> I don't need closures if I have those.
<mq32> it's definitly a different thing
<Tetralux> But they're a helluva lot simpler than closures though.
<daurnimator> fengb: see just above in my link for my issue...
<Tetralux> mq32: Different, but not _so_ different really.
<daurnimator> Tetralux: very different...
<Tetralux> Just 0-captures vs >0-captures.
<mq32> i meant closures and function literals
<daurnimator> and I believe function assigning syntax is accepted
<mq32> syntactically not much, but semantically
<daurnimator> so Tetralux you already have your feature coming
<Tetralux> I'm not sure I like the idea of having to do
<fengb> daurnimator: I was actually thinking the other direction. a:foo() always invokes as whereas never does
<Tetralux> `pub const f = fn(args...) returnType {}`
<Tetralux> everywhere.
<Tetralux> vs
<mikdusan1> daurnimator: in that proposal, i wonder when a->b() and a.b(), if compiler should emit shadowing error?
halosghost has joined #zig
<Tetralux> `fn f(args...) returnType {}
<daurnimator> mikdusan1: that would be one solution
<mikdusan1> personally i prefer a:foo() over a->foo() . the "extera vertical dot" is clear enough that something extra is happening.
<fengb> There's also a⫶foo()
<fengb> lol that looks like a smudge on my screen
<mikdusan1> a→Foo()
<mq32> a»foo()
<daurnimator> a⇒foo()
<daurnimator> which could be pass 2 arguments automatically
<daurnimator> or a⭆foo() to pass 4 arguments ;)
rsdimenus has joined #zig
<rsdimenus> has anyone done a stack allocator in zig yet?
<daurnimator> rsdimenus: huh? what do you mean by that?
<daurnimator> rsdimenus: just use a FixedBufferAllocator on some stack allocated memory
<Tetralux> Is the idea for interfaces that they are an comptime-only thing that doesn't make it to machine code?
<Tetralux> Or are they really more a Go-like thing?
<fengb> We probably need something like vtable dispatch
<Tetralux> That sounds awful.
<scientes> ehhhh
<scientes> i don't want a runtime
<fengb> You don't but people do
<daurnimator> tiehuis has gone through 4 or 5 different interface proposals
<daurnimator> you should have a look at them
<Tetralux> I'd rather it was just the structs that implement the interface and the interface it just a way of saying "yes, this struct must have these methods" or something.
<fengb> tgschultz also has some ideas
<gonz_> rsdimenus: There is a `StackFallbackAllocator` in `std.heap`
<daurnimator> oh right sorry it was tgschultz not tiehuis
<mq32> comptime solution for interfaces is quite restricted and we already have that (just pass a var parameter and validate it's interface)
<rsdimenus> gonz_: thanks that's what I'm looking for I think
<fengb> Current ideas are keeping it in userland unless proven otherwise
<gonz_> rsdimenus: I suspect so too, but honestly I have neither used it nor really read the source, I've just seen it in passing.
<fengb> @fieldParentPtr can be used as an adhoc interface, but it's a slight footgun
<fengb> That's how we currently do it and it works, but there's a few issues
<rsdimenus> basically i just have a bunch of work to do in a function and I want to free the whole chunk in a block
<daurnimator> fengb: I've been messing around in traceback generation and the current Steam/SeekableStream interface is *terrible*
<mq32> fengb: vtable-interfaces would require a "fat pointer" with pointer+vtable
<daurnimator> rsdimenus: that's ArenaAllocator
<gonz_> Yeah, you can just set up the arena at the top, defer `deinit` and just allocate wildly
<fengb> Here's the idea I like the most right now but it also has a hidden footgun
<rsdimenus> it's kind of a combination of both, I could have a top level arena allocator and a stack allocator below it
<rsdimenus> because eg if I'm reading a file, I only want one open at once anyway
<rsdimenus> so I should be able to reuse that memory
<fengb> Sorry, I didn't mean vtable specifically. But we do need dynamic dispatch for libraries
<mq32> fengb, is there a simple example on how to use that pull request?
<fengb> It's very similar to how we do @fieldParentPtr, but with an explicit wrapping instead of pointer math to break into the parent
<mq32> ah yeah
<mq32> it's pretty much just vtable stuff
LargeEpsilon has joined #zig
<mq32> i rather have a fat pointer than having the stuff that c++ does
<fengb> Well I don't know what C++ does >_>
<mq32> they prepend a vtable pointer to a struct if it inherits virtual functions
<mq32> so struct X : Y { int x; } gets struct { Y::vtable_t * vtable; int x };
<fengb> I don't really want inheritance
<mq32> object inheritance or interface implementation/inheritance?
<fengb> Oh I see
<fengb> Object inheritance
<mq32> yeah. C++ can't differentiate between interfaces and classes
<mq32> if you implement multiple interfaces, it starts to get weird
<mq32> Object o; InterfaceA * a = &o; InterfaceB * b = &o; if((void*)a == (void*)b) // fails
<mq32> same object, different pointer
<mq32> because of vtable offset
<mq32> (pointer to interface vtable must be at offset 0)
<fengb> I prefer Go interfaces or Rust traits, or even status quo manual vtable like generic interfaces
<fengb> Although I do think a fat closure could solve it more elegantly
<mq32> go interface is duck typing?
<fengb> Defined duck typing yeah
<mq32> "if it looks like a duck and walks liks a duck, it's a duck" :P
<mq32> so: if the struct implements all required methods, it can be cast to that interface
<fengb> Structural typing, not nominal
<fengb> Yeah
<mq32> i'm more the fan of explicit stuff, but i can understand why that is appealing :)
<mq32> can i store references to go interfaces?
<fengb> no, they only have method definitions
<fengb> I actually kinda prefer Zig status quo. You have a "generic" struct you cast into
<fengb> But there's a loss of flexibility if you only need a partial interface
<mq32> <fengb> no, they only have method definitions
<mq32> that's not what i meant
<mq32> but i just checked with a online go compiler and it "works"
<fengb> Oh I totally misunderstood your question
<fengb> I thought you said "can i store references _in_ go interfaces"
<mq32> tiny words can make huge difference
<mikdusan1> weakness with go is looking at a struct and it's implementation, how do you tell that oh this struct conforms to an interface by... you know... looking at the code
LargeEpsilon has quit [Ping timeout: 245 seconds]
<mq32> mikdusan1, yeah i prefer the explicit statement: "i want to implement this interface" better
<fengb> But the strength is you can define adhoc partial interfaces and don't need to muck around with consumed code
<mq32> rust does that for traits with separated blocks
<mq32> fengb: yeah i can see that point beeing a good argument
<fengb> Hey wat, you're not allowed to agree with me on the internet
<mq32> ha! i'm breaking the law of the internetz!
<mq32> i really like that we can explore programming language concepts here without everyone saying: "this is stupid"
<companion_cube> mq32: this is stupid
<mq32> kek
<companion_cube> (don't thank me)
<scientes> mq32, hehe
<scientes> I got good feedback on my SIMD questions here
<fengb> There are no bad ideas, only tradeoffs
<scientes> it was much faster than github
<companion_cube> I don't know, I feel like some things truly are bad ideas
<companion_cube> like auto coercions à la JS' ==
<mq32> fengb: we could do a malloc on every local variable we have and store them in a malloc'd frame for every function call!
<fengb> I'm trying to be nice :(
<companion_cube> :D
<mq32> companion_cube: I can find positive arguments for the == thing :D
<mq32> oh and another one: we could make the default number type a 16 bit half-float!
<mq32> got to go
<fengb> The only number type
<companion_cube> why not f17? 🤔
<fengb> Okay, let's remove JS from the equation >_>
<scientes> yeah lets do NAN packing for no reason at all :)
<scientes> even though we don't have a gc
laaron has quit [Quit: ZNC 1.7.1 -]
laaron has joined #zig
porky11 has joined #zig
<rsdimenus> does linux append a newline to files on disk automatically?
<rsdimenus> or maybe vim does?
<fengb> vim
<scientes> i had to set vscode to add those because daurnimator was giving me grief :)
<fengb> Linux kernel doesn't care about terminating newlines but a lot of userland utils do
<rsdimenus> why would it automatically append a newline?
<rsdimenus> ah
<fengb> Also it's the posix standard apparently
<companion_cube> so… an empty file is invalid?
<fengb> Just text files
<fengb> And only posix purists
LargeEpsilon_ has joined #zig
<rsdimenus> that's just an annoying feature/bug
<rsdimenus> imo
<rsdimenus> ah, the bug was actually with SplitIterator
<rsdimenus> it was returning true for an extra loop than it should have
<andrewrk> rsdimenus, double check those docs
<andrewrk> you might be getting mem.separate and mem.tokenize mixed up
<rsdimenus> no, i can see the docs say that it should return null
<rsdimenus> but it doesn't
<rsdimenus> if start and end are both 0, it still returns a valid slice not the '
<rsdimenus> null value
<nairou> andrewrk, you asked last night what the error was when my C-only program panics in zig code when I run it. Here's what I see in gdb:
<andrewrk> looks like that behavior is documented in a test case
<andrewrk> nairou, can I see your build script?
<andrewrk> I'm guessing you're running an old binary that didn't get updated as you thought it did
<nairou> I delete zig-cache before builds, to be safe
<rsdimenus> andrewrk: my apologies, of what use is the first scenario?
<rsdimenus> eg an empty string
<andrewrk> nairou, I'm pretty sure you depend on libc
<andrewrk> but you're not linking it
<andrewrk> linkSystemLibrary with "dl" "m" "pthread" those are all part of libc. delete those and uncomment your linkSystemLibrary "c"
<nairou> andrewrk: Thanks. I had that line uncommented before and got all sorts of other linker errors, but now I'm thinking I might know what the other errors come from. I'll try that, thanks.
<rsdimenus> nevermind, I get it. sorry false alarm!
<andrewrk> no worries rsdimenus there are plenty of bugs so your paranoia is justified
<rsdimenus> tokenize is the right one for line parsing, eg tokenize(file_slice, "\r\n")
<nairou> Yup, that did the trick, after fixing the other link error. Woot
<andrewrk> rsdimenus, yes and the other one is good for deserializing, e.g. CSV
kristoff_it has quit [Ping timeout: 245 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 258 seconds]
wootehfoot has joined #zig
Akuli has joined #zig
LargeEpsilon_ has quit [Read error: Connection reset by peer]
LargeEpsilon_ has joined #zig
batok has quit [Remote host closed the connection]
LargeEpsilon_ has quit [Ping timeout: 245 seconds]
kristoff_it has joined #zig
<mq32> andrewrk, do you have a plan when you stream next?
<nairou> Yeah I've been loving the status update streams
omglasers2 has joined #zig
<andrewrk> planning to do one today at 17:00 EDT (3.5 hours from now)
kristoff_it has quit [Ping timeout: 268 seconds]
<mq32> *happy*
laaron has quit [Quit: ZNC 1.7.1 -]
laaron has joined #zig
batok has joined #zig
laaron has quit [Quit: ZNC 1.7.1 -]
laaron has joined #zig
<Akuli> midnight here in finland, lol
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
huuskes has joined #zig
Akuli has quit [Quit: Leaving]
<lunamn> are there plans for a future 'zig build test' where the test build links against the libraries in build.zig?
<andrewrk> lunamn, you can already do that
<andrewrk> have a look at zig's own build.zig for example
<lunamn> oh i see so not given by default, gotcha
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
porky11 has quit [Quit: Leaving]
Tetralux has quit [Ping timeout: 245 seconds]
wootehfoot has quit [Read error: Connection reset by peer]
andersfr has joined #zig
andersfr has quit [Client Quit]
nairou has quit [Remote host closed the connection]
Tetralux has joined #zig
<rsdimenus> how do you debug the zig compiler? gdb detaches after the child process is spun up
<Tetralux> theres a child process?
<andrewrk> any time a child process is spawned and crashes, zig will print out the command line of it so you can debug it directly
laaron has quit [Remote host closed the connection]
laaron has joined #zig
<andrewrk> I'm going to start the stream soon will be doing a status update
Ichorio has joined #zig
halosghost has quit [Quit: WeeChat 2.5]
omglasers2 has quit [Quit: Leaving]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 268 seconds]
schme245 has joined #zig
schme245 has quit [Client Quit]
<mq32> stream broke down and i got to go
<mq32> but: andrewrk, the stuff you showed looks very promising
<andrewrk> I see what you did there
<fengb> Maybe you could sync up later?
* andrewrk facepalms
schme245 has joined #zig
Firefox317 has joined #zig
<Firefox317> Yeah you were about to run the cool code ;(
vramana has joined #zig
<mq32> cool_demo = await stream_frame;
<vramana> Can you some explain typeToId function here ?
<andrewrk> oh did the part where it produced invalid LLVM not show up?
<Firefox317> Nope you didn't run any of the file url download example
<Firefox317> Before that the stream already went down
<andrewrk> maybe I'll have the bug fixed by the time it finishes uploading to youtube :)
<fengb> Twitch said “no more bugs” and it was good
<vramana> if (T == @field(Node, @memberName(Id, i))) This line is incredibly confusing. @memberName call will gave possible value in Id enum after that @field will be called with Node and a value of Id but that's not a field of Node at all. I am misreading something I don't know what.
<Firefox317> So you are not gonna continue the stream? Anyways the progress on the branch is awesome
<andrewrk> Firefox317, I finished it offline and uploading to youtube now. Next week's demo should be more complete
<Firefox317> Great!
<vramana> I get it now. It accessing the struct type inside the Node.
<vramana> I feel so dumb.
<batok> what was the name of the branch shown in twitch?
Ichorio has quit [Ping timeout: 264 seconds]
<andrewrk> batok, rewrite-coroutines
<batok> cool thanks
Firefox317 has quit [Ping timeout: 260 seconds]
laaron has quit [Remote host closed the connection]
laaron has joined #zig
kristoff_it has joined #zig
schme245 has quit [Remote host closed the connection]
kristoff_it has quit [Ping timeout: 246 seconds]
mikdusan1 has quit [Ping timeout: 246 seconds]
<fengb> These new async semantics are so elegant
<fengb> Is there something equivalent to @packedSizeOf?
<Tetralux> Is that not just @sizeOf?
<Tetralux> Does @sizeOf ignore if the struct is padded or not?
<Tetralux> Surely not.
<fengb> @sizeOf is padded size
<fengb> I’ll just hardcode this stuff for now. No need to make it generic yet
<andrewrk> fengb, pay attention to packed structs are going to get more generally useful with this
<andrewrk> here's the vid with the missing stream content. give it a few dozen minutes for HD to become available:
<fengb> Ah I see
<andrewrk> fengb, I just fixed one of the issues; another remains
laaron has quit [Quit: ZNC 1.7.1 -]
ltriant has joined #zig
laaron has joined #zig
<fengb> Will there be a way to await on multiple coroutines like promise.all?
<fengb> Or the opposite, await until the first one completes
<fengb> First completion, not first listed coroutine
<andrewrk> that sounds like std.event.Group and std.event.Channel, respectively
<fengb> Ah okay
<andrewrk> there's also std.event.Future
<andrewrk> I did a lot of proof of concepts before determining I needed to redo the semantics
<fengb> I think it’s funny that I can grok all of this but still have no clue how continuations work
<shachaf> Continuations are quite a bit more general.
<shachaf> In fact I'm pretty sure they're more general than anyone needs.
<shachaf> (But they're also pretty simple.)
<fengb> I use Redux every day and its continuation passing style still boggles my mind
<shachaf> I'll watch that video at home, I'm curious how things ended up.
<shachaf> I don't know Redux but I agree that writing in CPS is very awkward.
<fengb> andrewrk mentioned that these async functions are basically CPS. And he somehow made it understandable. It's good stuff 👍
<shachaf> Hmm, it's a special case of continuations (as are most kinds of control flow).
<shachaf> In particular it's a kind of "one-shot continuation", which is much easier to implement efficiently.