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/
<fengb> Interrupts kinda break “no hidden control flow” paradigm
<pixelherodev> Not really
<pixelherodev> fengb, the interrupt will occur in the midst of other code yes, but it has zero effect on it
ntgg has joined #zig
<fengb> Hmm so I’d consider tossing the interrupt handler in an async frame and resume on interrupt
<fengb> I suppose that require an event loop which you might not have >_>
<pixelherodev> I've got it actually
<pixelherodev> Just using a function table
<pixelherodev> Calling into it from asm
micparke has joined #zig
<pixelherodev> Which leads to my latest question: if I have a function declared `export` and `noreturn`, and it takes parameters, can I `jmp` to it from asm, or do I have to `call` it?
<fengb> Does that automatically suspend the rest of the program?
<pixelherodev> Well, for critical exceptions, it literally `@panic`s
<pixelherodev> For normal interrupts - keyboard, timer, etc - it calls the handler then returns right back to where it was before
<pixelherodev> It's sort of like how I'm running VLC and HexChat at the same time and neither affects the other :)
<pixelherodev> (and looooots more)
<fengb> I think you want nakedcc but I don’t really grok call conventions
<micparke> What allows a function to be imported?
<pixelherodev> Has to be declared `pub`
<micparke> Thanks!
<pixelherodev> No problem
<micparke> What does `export` mean then?
<pixelherodev> That's to make it accessible from e.g. C
<micparke> Ah!
<pixelherodev> I think I need to `call` it - I *think* the function expects to see a return address even if it never returns
<pixelherodev> I'm also trying to cheat and use 4 lines of comptime code to declare 32 functions :P
<pixelherodev> (isr0, isr1, isr2... isr31)
<pixelherodev> Some very inefficient `@cImport`ing :P
<pixelherodev> Perhaps fortunately, that doesn't seem possible
<micparke> Using 5.0 on Windows, and it's the first time I've gotten a runtime error in a zig build from a missing DLL, VCRUNGTIME140_1.dll
<micparke> Looks like I'm missing the 2019 version of MSVC
ntgg has quit [Ping timeout: 240 seconds]
<pixelherodev> Is there a way to use comptime reflection to get a function's address from its name?
<pixelherodev> Never mind that's a terrible idea anyways
<andrewrk> micparke, it's a bug, should be fixed shortly.
<pixelherodev> What's the correct type for a function pointer? `var`?
<pixelherodev> `function`, rather?
<pixelherodev> Never mind, figured it out
<andrewrk> pixelherodev, here's an example: https://ziglang.org/documentation/master/std/#std;mem.Allocator
<pixelherodev> Yeah, I already got it :) Thanks though!
muffindrake has quit [Ping timeout: 276 seconds]
muffindrake has joined #zig
<emekankurumeh[m]> pixelherodev: do you have this stuff in a repo somewhere? i tried to make a i3686 kernel in zig before but i always got stuck on setting up interrupts
<pixelherodev> Give me two minutes and I can push the interrupts
<andrewrk> emekankurumeh[m], there are a couple i386 kernel examples
<scientes> has anyone tried avr-8?
<emekankurumeh[m]> does llvm support avr?
<scientes> not as well as gcc
<scientes> but it does
<pixelherodev> emekankurumeh[m], https://git.sr.ht/~pixelherodev/LIMNOS
<emekankurumeh[m]> i considered getting a arduino nano, or embedded development but i got a stm32 board instead
<andrewrk> avr is an experimental target in llvm
<scientes> avr-8 is quite limited
<pixelherodev> Since I just got interrupts working literally five minutes ago, when you boot it dumps basic info (memory, bootloader, cmdline, etc), initializes the heap, then prints TIMER forever
<pixelherodev> Okay, so I may have forgotten to add `asm volatile("cli");` to the panic function, but it's fixed locally :P
<pixelherodev> Heads up that f128 isn't usable in i386-freestanding - "undefined symbol: __divtf3"
<pixelherodev> Oh, and timing is off in the code in the repo - didn't manually specify that reload_value is u16, so it ended up getting butchered
<andrewrk> pixelherodev, that's just a tiny improvement to compiler-rt away from working just fine
<pixelherodev> I'm going to see if I can patch that one then :)
<andrewrk> you can see there were a lot of additions in 0.5.0: https://ziglang.org/download/0.5.0/release-notes.html#compiler-rt
<emekankurumeh[m]> what happens if a async function suspends in another thread?
<andrewrk> emekankurumeh[m], this is the same question as "what happens if a function running in another thread returns?"
<andrewrk> `return` and `await` in async functions are thread-safe
<emekankurumeh[m]> nevermind, you can't start a thread using a async function
<andrewrk> you can, however, make an async function called switchToAnotherThread()
<andrewrk> (and have it do as advertised)
<emekankurumeh[m]> Thread.new works with an async function?
<andrewrk> no
<andrewrk> I need to do a lot more documentation about how to use async functions in zig
edr has quit [Quit: ZNC 1.6.5 - http://znc.in]
<andrewrk> emekankurumeh[m], you could suspend, and then have a different thread resume it
<emekankurumeh[m]> would the thread with the suspended function just burn CPU, or would it just "sleep"?
chemist69 has quit [Ping timeout: 250 seconds]
chemist69 has joined #zig
<andrewrk> emekankurumeh[m], `suspend` sends control flow back to either the `async` or the `resume`
<muffindrake> '(Note that Windows line endings (CRLF) are not allowed, and hard tabs are not allowed.)'
<muffindrake> Huh, now that's a statement.
<emekankurumeh[m]> discussion on whitespace is a bit of a dead horse and considered off-topic
<muffindrake> I was simply stumped to see that in the docs. You don't see this kind of pragmatism everywhere.
<torque> what if beating dead horses is my favorite pastime
<pixelherodev> Then take it elsewhere?
<emekankurumeh[m]> better watch out for PeTA then
<muffindrake> Is there a #deadhorse channel?
<muffindrake> Sounds like a meeting place for animal cruelty and necrophilia alike.
<pixelherodev> Okaaay then, someone ping me when the conversation gets less creepy
<andrewrk> that will be right now, please
<muffindrake> Direct your complaints to torque.
<muffindrake> The docs mention global assembly - at precisely which point is that inserted?
<andrewrk> it becomes part of the compilation unit
<andrewrk> if you want it to go into a specific section, you can use the assembly syntax for that
ltriant has quit [Quit: leaving]
edr has joined #zig
tdeo has quit [Remote host closed the connection]
tdeo has joined #zig
bgiannan has quit [Quit: WeeChat 2.6]
bgiannan has joined #zig
micparke has quit [Ping timeout: 260 seconds]
mahmudov has joined #zig
ntgg has joined #zig
<muffindrake> I've read through the docs, and am looking at the standard library now. What concrete examples for memory allocation can I look at?
<mq32> muffindrake, want to create or use an allocator?
<muffindrake> I want to know what to do and what not to do to allocate memory.
<mq32> good start for either side is the allocator interface itself: https://ziglang.org/documentation/master/std/#std;mem.Allocator
<mq32> usually, you do something like
<mq32> var x : *MyType = myAllocator.create(MyType);
<mq32> defer myAllocator.destroy(x);
<muffindrake> What's the specific difference between errdefer and defer?
<mq32> errdefer is only called when the current block/function returns with an error
<mq32> usual pattern is something like this:
<mq32> fn make() !*T { var t = alloc.create(T); errdefer alloc.destroy(t); /* here be failing code */ return t; }
knebulae has quit [Ping timeout: 265 seconds]
marijnfs has joined #zig
sepisoad has joined #zig
knebulae has joined #zig
<daurnimator> huzzah. issue closing spree
ntgg has quit [Ping timeout: 276 seconds]
<muffindrake> How is the general purpose allocator coming along, anyway?
<muffindrake> I'd be fine just linking to libc and using some allocator interface for malloc/free, if there's such a thing.
<muffindrake> Or if there's a well-tested general purpose allocator, I'd use that instead of a full libc.
<mikdusan> i haven't used it in a while but try `std.heap.c_allocator`
<mq32> muffindrake, you can just link libc anduse what mikdusan just said :D
<muffindrake> Ah, fine.
<ceymard> is it possible to manufacture function calls at comptime ?
<mikdusan> also if you have code that is amenible to arena... use direct_allocator as backing for an arena allocator
<ceymard> as in, I give a function in a var parameter
<ceymard> and I want in turn to call it with all its arguments
<mq32> ceymard, i don't think so
<mq32> haven't found a way yet
<ceymard> okay, scrap that idea
<mq32> i would like to have that, but it's a complex thing
<ceymard> when iterating over a struct field with @TypeInfo
<ceymard> is the order guaranteed to be that of declaration ?
<ceymard> struct fields*
<mq32> my "closures in user land"-idea died by not having that ability
<mq32> what would be cool though: the ability to call a function with a struct providing all the parameters
doublex has joined #zig
ntgg has joined #zig
<mikdusan> ceymard: struct field layout is only guaranteed when packed
return0e has quit [Ping timeout: 265 seconds]
return0e has joined #zig
return0e has quit [Read error: Connection reset by peer]
<ceymard> mikdusan: even when doing meta-stuff ?
<mikdusan> i believe so
<ceymard> I'm not talking about memory layout, but playing with @typeInfo
<ceymard> ok
return0e has joined #zig
<mq32> mikdusan: extern should also guarantee field order
ntgg has quit [Ping timeout: 276 seconds]
<muffindrake> Isn't an extern struct supposed to be used only for interoperability with C APIs?
<mq32> muffindrake, no. "extern" just means that the struct layout follows the C ABI
<muffindrake> I'll get this right at some point, I'm sure.
<mq32> it means that zig follows certain rules on how to lay out memory and align elements in the struct
<muffindrake> The normal 'struct' declaration tries to make field access as quick as possible, but makes no guarantees about layout, no? What is the reasoning for 'packed struct'?
<mikdusan> with a guaranteed layout you can use structs to interface with structured binary data. for example, audio or video bitstreams
<mikdusan> kernel interfaces too
sepisoad has quit [Quit: Connection closed for inactivity]
<Snektron> muffindrake: theres @inlineCall, @noInlineCall, @NewStackCall, @asyncCall which do what you want i think
<mq32> <muffindrake> What is the reasoning for 'packed struct'?
<mq32> you want packed structs if the memory layout MUST BE exact, bit perfect
<mq32> there's a lot of use cases: communcations (ethernet, wifi, ...), storage (binary files), MMIO (hardware access)
squeek502 has quit [Ping timeout: 265 seconds]
jmiven has quit [Quit: bye]
jmiven has joined #zig
nrdmn has quit [Read error: Connection reset by peer]
_whitelogger has joined #zig
<Snektron> I realized i can probably make the parser im writing use async
<Snektron> but im not sure if thats intended usage
<Snektron> Basically you'd write the token to a location and then suspend
<Snektron> and resume to get the next
<mq32> Snektron, you can also just use a generator pattern
<mq32> var parser = Parser.parse(slice); while(parser.next()) |tok| { }
<Snektron> Sure, but with async you can just use a simple stack-based parser
<fengb> No context: you can use async to implement a generator!
<fengb> Oh that’s the architecture you just proposed
<Snektron> Though its a bit annoying to do so since suspend cant return a value
<Snektron> Would be cool if it could
<mq32> Snektron, that would be a higher level concept
<mq32> you can probably create something like
<mq32> Generator(T, function)
<fengb> I’ve been wanting to implement a generic generator but it gets messy really quick
<mq32> yeah
<mq32> my biggest problem right now is that i don't get how i can work with multiple "event loops"
<mq32> so what happens if i'm doing "await"
<fengb> That was my attempt at making a recursive generator
<mq32> ah
<mq32> you can probably use push/pull semantic for the "out" variable
<fengb> Reusing the same suspend point let me sidestep multiple async contexts
ninepoints has joined #zig
<ninepoints> two days ago in despair, I reached for libllvm to make a language because I was so fed up with all the other alternatives. while coding, I found zig!
<ninepoints> has most of the things I was going for (low level, comptime, no gc, simd) and more on the roadmap (hot reloading)
<ninepoints> pretty excited!
<mq32> hey ninepoints
<mq32> yeah, zig is quite awesome :)
<ninepoints> :)
<ninepoints> i'm pretty new, but my background is in graphics engines and networking engines (mostly console but also desktop). my goal is to use zig for a new renderer I'm cooking up
<ninepoints> as in, pretty new to zig. Before zig, I've coded C++ for ~18 years or so (and continue to do so for my day job)
<mq32> ah nice, i'm into graphics stuff as well
<mq32> i have a small library for OpenGL and similar
<mq32> do you have experience writing reliable UDP libraries? *grin*
<fengb> But the U stands for unreliable 🙃
<ninepoints> yes i used to work on games you've probably played if you're a gamer hehe
<ninepoints> there's a protocol literally called rudp (bit of an oxymoron, that)
<ninepoints> i don't do much networking anymore, mostly rendering and graphics
<mq32> hm
<mq32> i'm trying to create a reliable UDP library for zig right now
<ninepoints> ah ok, how can i help
<mq32> ** remove UDP
<mq32> reliable networking
<mq32> but not for gaming, but ad-hoc connectionless networking
<mq32> so not built on IP
<ninepoints> similar foundation yea
<ninepoints> I've worked with WebRTC protocols also (voip, teleconferencing, SFUs, MCUs, etc)
<ninepoints> do you need encryption?
<ninepoints> or is this the layer below that
<mq32> not for a proof of concept
<ninepoints> ok sure
<mq32> also i have no idea how to apply encryption to this
<mq32> packet size is <= 250 byte
<ninepoints> look at DTLS
<ninepoints> which is how control packets are encrypted via UDP for browser calls (like facebook messenger, slack, etc)
<ninepoints> but let's ignore encryption for now
<mq32> yeah
<mq32> my current state is a prototype that sends messages via IP/broadcast
<mq32> but, you know, transport layer is exchangeably
<mq32> and i don't want to have wireless hardware with me all day :D
<mq32> => query, don't want to spam offtopic
<ninepoints> in a production library, the hardest thing to deal with is congestion (resend/retry policies)
<mikdusan> how about something like QUIC
ntgg has joined #zig
<ninepoints> also, be sure to detect the MTU and leverage the full width
<mq32> MTU is 250 byte
<ninepoints> QUIC is pretty nice but I'm not sure how latency sensitive it is
<ninepoints> mq32: are you saying the MTU is statically coded to be 250 bytes?
<mq32> yep
<mq32> at least for the tech i'm looking at
<ninepoints> what's your packet header like?
<mq32> right now i have "sequenceID, from, to, flags (reliable, ACK)"
<mq32> sequenceID is 16 bit, from,to are both similar to MAC, flags is 8 bit
<mq32> sequence id will be used for reliable resending
<ninepoints> are you doing nacks also
waleee-cl has joined #zig
<ninepoints> mentioning because in many situations, an ack-per-packet is often really chatty and it's cheaper to nack the packets that aren't received
<mq32> not yet, but would probably be reasonable
<mq32> but how to NAK?
<ninepoints> haha well, that's sort of up to you. on the receiving side, you decide what is unreasonable time to wait for a missing packet before nacking
<ninepoints> in real-world situations, this policy is highly dynamic depending on bandwidth and network conditions
<ninepoints> so it's common to have a "policy" abstraction
<ninepoints> (disclaimer, this is all stuff i did >10 years ago)
riba has joined #zig
<riba> hi, i'm getting a compile error i don't quite get and hope you guys can maybe help me with it
<ninepoints> :thumbsup:
<mq32> riba, what's it?
<riba> i imported some definitions from a C library, and now i'm trying to initialize this struct which wants a string
<mq32> ninepoints: i have the fortunate situation that i have zero devices between my endpoints
<riba> i give it a c""-string but i get error: cast discards const qualifier
<riba> i don't get where the cast is
<mq32> riba, your struct probably wants a "[*c]u8" instead of "[*c]const u8"
<riba> when i try to give it a zig-string the type is just c string as far as i can tell
<mq32> does the string has to be mutable?
<riba> it doesn't need to be mutable
<riba> i tried making a var that contains this string but got the same
<riba> wait, do i have to specify the var type so const is not derived?
<mq32> no
<mq32> string literals cannot be mutable
<companion_cube> 0 device, not even an ethernet cable?
<mq32> companion_cube: correct. point-to-point via 802.11/wlan
<mq32> how is the struct defined in C?
<companion_cube> dang, nice
riba_ has joined #zig
<riba_> hit the wrong button
<riba_> when i try to give it a zig string i get error: expected type '[*c]u8', found '[9]u8', so yeah i need a non-const c-string
<mq32> just put some text into a var:
<mq32> var mutstring = "Hello, World!" ++ ([1]u8 { 0 } ** 50); // hello world and 50 zeroes
<mq32> then use &mutstring
<mq32> companion_cube: i'm trying to create some kind of "distributed OS thingy"
<companion_cube> oh boy
<mq32> so ad-hoc remote file system and stuff *grin*
<mq32> (what? this is nuts? ... no way!)
<ninepoints> RIP
<mq32> :D
<mq32> ninepoints: good thing is that my "focus" is quite small
<mq32> every device i can reach by my own transmitter is there, everything else does not exist
<ninepoints> i just noticed zig supports the half-float. that's pretty great
<mq32> yeah
riba has quit [Ping timeout: 268 seconds]
<mq32> this makes stuff a lot easier (both f16 and the communcation)
<riba_> mq32: i tried putting it into a var and giving it the address, but now i get error: expected type '[*c]u8', found '*[*]const u8'
<ninepoints> you'll probably want a nack based approach all the more then mq32
<ninepoints> since the links are unlikely to be lossy?
<mq32> yeah probably
<mq32> so if i receive a packet 0, then 2
<mq32> i send the sender of 2: "hey, i lost packet 1"
<mq32> right?
<mq32> <ninepoints> since the links are unlikely to be lossy?
<ninepoints> yes, but not necessarily immediately, since order isn't guaranteed
<mq32> probably lossy a.f. as it's wifi
<mq32> order is guaranteed <3
<ninepoints> on your end, you'll want a buffer to do reconstruction
<ninepoints> oh what
<ninepoints> lol then yea
<mq32> it's wifi
<mq32> i send a packet, it either is there as soon as my send is completed or it's lost
<mq32> i know that immediatly
<ninepoints> hmm i actually don't know if a typically router guarantees order on the local link
<ninepoints> s/typically/typical
<riba_> in C everything is a char * so i guess it's kind of correct that zig complains, but i'm trying to statically initialize everything and it seems there is no way to do that in zig?
<mq32> ninepoints, i don't use a router
<mq32> i'm doing point-to-point wifi without having a station/AP
<ninepoints> ok got it
<mq32> riba_: strings in C are usually "char const *"
<mikdusan> riba_: `var buffer: [64]u8 = undefined; var p: [*c]u8 = &buffer;`
<riba_> mq32: sorry, i meant the definition of this struct the char *
<riba_> +has
<mq32> yeah then you need to provide mutable memory
<mq32> ninepoints: i should probably test how lossy my link is
<mq32> maybe i can even do that this evening :)
<muffindrake> String literals are of type char[n] in C, and they're not const. Just that modifying a string literal is undefined behaviour.
<mq32> muffindrake: depends on the version if string literals are const or not
<ninepoints> mq32: yea i mean, you're lucky you have a well defined setup. you can tune all the windows and timers etc to your situation
<mq32> but yeah, you're right
<muffindrake> There is no C standard where string literals are const
<mq32> ninepoints: yep. i'm gonna have fun with this project and i will be learning a lot.
<riba_> mikdusan: i'll try that
<mikdusan> riba_: it's just a stack buffer. do you need a buffer on a heap?
<riba_> i feel like it's a sensible exception if everything is initialized at comptime
<riba_> wait, can i just make it a comptime var
<mq32> yes, you can :D
<riba_> it seems i can't because the scope is global or something
SquantMuts has joined #zig
<riba_> i'm trying to write a plugin and i need to call a macro on this initialized struct
<mq32> plugin and macro sounds like magic
<mq32> you probably have to recreate the macro magic by hand
<riba_> well i didn't even get that far since i cannot create the struct
<ninepoints> hmm... no operator overloading
<riba_> okay, so if i make my own struct which looks exactly the same i could make the types const and use it how i'd like to, correct?
<mikdusan> ninepoints: no op overloading. clarity. no RAII - instead use defer and errdefer. no inheritance. there is struct methods.
<riba_> and it's an extern struct
<riba_> i've been statically initializing everything in my C code so i assume it doesnt really have to be mutable
<tgschultz> with result location changes, operator overloading is now an especially terrible idea.
<ninepoints> I think op overloading is the only thing I am confused by
<ninepoints> That means I have no way to implement a numeric-like entity
<ninepoints> tgschultz: could you elaborate?
<fengb> andrewrk says we’re lucky to get operators at all 🙃
<tgschultz> `x = x.func();` is now a footgun if func is something like `fn(self: Self) Self { return Self{ .x = self.y, .y = self.x, }; }`
<ninepoints> why do we need to overload =
<tgschultz> so if func overloads `~`, for example, this now looks like `x = ~x;`, which is a perfectly safe operation under normal cirucmstances, but has now hidden a dangerous function call.
<ninepoints> are there no footguns in the language whatsover?
<tgschultz> ideally no.
<tgschultz> currently there are several, but that's considered something that needs fixing
<ninepoints> so, i'd like to at least proffer my perspective on operators specifically
<tgschultz> There's a length issue in the tracker about it, as I recall.
<ninepoints> which is that users of the language should be able to define new numeric types
<ninepoints> i've read them just now
<ninepoints> i might have a different perspective because i'm a graphics engineer and maybe i'm not the target audience
<tgschultz> it's a general purpose language, so I think pretty much any use case is part of the target audience
<ninepoints> but if the language requires that any numeric type be provided solely by the language itself, that's a severe limitation
<muffindrake> Oh, a thing that is probably of use to me. Is there a way to execute a zig source file like a script?
<ninepoints> I do not view using function calls where operators suffice as being remotely acceptable in cases such as these (complex numbers dual quats, multivectors, etc)
<ninepoints> main reason being too much semantic meaning is loss. operators imply associativity, commutivity, and read naturally
<fengb> muffindrake: zig run file.zig
<mikdusan> muffindrake: `zig run foo.zig -- arg1 arg2 ...` is probably as close as you get
<tgschultz> The problem is that zig very much leans towards readability and clarity over writability
<ninepoints> that's what I'm saying
<ninepoints> readability and clarity is absolutely compromised
<ninepoints> and i stare at math code all day
<tgschultz> with operator overloading you're trading one kind of clarity for antoher. you hide function calls.
<ninepoints> i've read this, in the docs
<fengb> Zig code isn’t designed for math
<ninepoints> fengb: ok maybe that's it then
<tgschultz> My personal suggestion for this was some kind of comptime DSL interpreter
<mq32> ninepoints, we graphics programmers are on a lone foot here *grin*
<mikdusan> math. always so dang special
ntgg has quit [Ping timeout: 268 seconds]
<tgschultz> math is already its own DSL (several, actually...)
<ninepoints> right... but making it a special snowflake seems like an odd choice
<ninepoints> i really do appreciate many aspects of the language, but without that well...
<ninepoints> i actually can't even begin to port my code
<ninepoints> it would be literally unreadable
<tgschultz> mathify("<insert LaTeX here>", a, b, c, d, e);
<mq32> ninepoints, i'm struggling as well
<ninepoints> latex would read like shit lol
<ninepoints> no joke and i'm 100% fluent in latex
<tgschultz> only if your IDE didn't support rendering it
<ninepoints> i can't tell if you're trolling me
<mq32> i think he is, at least a bit
<tgschultz> I've never used LaTeX, not a math guy
<ninepoints> eh oh well, zig was interesting to look at at least
<ninepoints> but i can't imagine any of my colleagues biting if they can't even define a complex number lol
<mikdusan> well u can but not with operator overloading
<mq32> *zig, but i'm still struggling
<ninepoints> yea i know
<tgschultz> I'm jsut saying, math is already a DSL and if you do a lot of heavy math work, maybe it makes sense to write equations in a form that actually is that math, but I think instead of baking it into the language we should have a facility to interpret it for you
<ninepoints> we don't write add(x, y) for integers for a reason
<mikdusan> mq32: is zug unsigned and zig signed?
<ninepoints> i think different domains require brevity for common operations
<mq32> mikdusan, zug is unsigned zig :D
<mq32> tgschultz, yeah but it gets horribly messy with function syntax even for simple linear algebra
<mq32> when * und + aren't options
<ninepoints> and the degree to which i can improve brevity and maintain control speakes to the expressiveness of the language
<mq32> > p - k1 + k2*clamp( dot(k1-p,k2)/dot2(k2), 0.0, 1.0 ); // is already hard to read, but
<ninepoints> english is expressive because it affords me a lot of words at my disposal
<ninepoints> zig, is very not expressive (although it's very impressive in other ways)
<tgschultz> mq32, I'm saying: go ahead and write your vector math in whatever makes sense, then have a comptime function that you pass that string to and it generates the calls to functions.
<mq32> > vec2.sub(p, vec2.add(k1, vec2.scale(k2, clamp(vec2.dot(vec2.sub(k1,p),k2) / vec2.dot(k2,k2), 0.0, 1.0))
<tgschultz> english is also one of the hardest languages in the world to learn. even its native speakers screw it up constantly.
<mq32> tgschultz: that wouldn't make it any more readable at all
<tgschultz> why not?
<mq32> because then i have the problem of something like <?zigvec ?> blocks in zig code
<fengb> I don’t think expressiveness is a design goal of zig
<tgschultz> WTF? How is that anything like what I said?
<ninepoints> haha a programming language that isn't shooting for expressiveness
<mq32> because otherwise i could never mix zig code and vector math code
<ninepoints> this conversation depresses me. i really do feel like this language has a lot of potential
<mq32> the problem is that if i change it to a comptime compiler (which i cannot do quite well right now afaik)
<ninepoints> but because we're afraid of people confusing an operator with a function call... that's the end of the discussion
<mq32> it gets even more worse to read
<fengb> ninepoints: I don’t think zig is for you then
<mq32> because i suddenly have several names in several languages for the same variables
<tgschultz> Why not? In best case it could look like this: `vectorMath("<string of vector math howeer you like it");`, but that would need some facility to accesss variables outside the function scope, if only at comptime
<ninepoints> fengb: nor many others
<ninepoints> pretty sure i can speak for most of the people in my industry
<mq32> tgschultz: vectorMath("p - k1 + k2*clamp( dot(k1-p,k2)/dot2(k2), 0.0, 1.0 )", ???)
<mq32> how do i pass my variable names here?
<mq32> <ninepoints> pretty sure i can speak for most of the people in my industry
<tgschultz> The problem with expressiveness is you end up like C++ with 40 different languages that kinda look the same sometimes
<mq32> true dat. game dev and graphics require operator overloads to create at least *some* readable code
<ninepoints> i'd seek a middle ground. like no need to overload , -> *
<tgschultz> mq32, first of all, you wouldn't use function calls in the string but your own notation, and secondly as I said it would require some ability to peek at variables outside the scope in a comptime call.
<ninepoints> also your comptime parser suggestion makes no sense lol
<mq32> yeah, but clamp() and dot() are actually some quite common functions
<ninepoints> one, compile times are a thing
<ninepoints> and codebases i work on have 1.5+ million lines of code
<ninepoints> much of which are code to do things like, skinning on animation bones, or integrating log-luminance levels, or constructing kd-trees idk
<tgschultz> If my suggestion makes no sense, I haven't seen a coherent argument as to why not
<ninepoints> i'm typing it out jeez
<mq32> tgschultz: maybe something like Rust Macros could be a thing for zig, but i don't know. those are horribly overcomplicated in the end
<ninepoints> so the suggestion on deck is that each of those expressions would need to be parsed and compiled separately
<ninepoints> i'm really not buying it lol
<tgschultz> not compiled separately, not any more so than ArrayList(u8) is compiled separately
<ninepoints> wat
<ninepoints> the "string" expression in each situation is distinct
<ninepoints> you have to parse each one
<tgschultz> so is every call to ArrayList(T)
<tgschultz> yes
<tgschultz> and?
<ninepoints> not to mention, we're talking hundreds of lines. how do you debug that
<mq32> tgschultz: ArrayList(T) is cached.
<ninepoints> yea lol i'm being trolled i must be
<mq32> we don't create a new ArrayList every line of code
<tgschultz> only where T is identical, which would be the same here
<fengb> It'd be like format()
<fengb> You can bounce in and out of context at comptime
<mq32> there's a big difference between 1 Mio lines of of "ArrayList(T)" and "ArrayList(T1), ArrayList(T2), ..., ArrayList(T1000000)"
<mikdusan> well ninepoints is correct that there is comptime cost for such a thing. but zig also doesn't bear the comptime cost of _repeated_ template compilations where params are equal but in diff units
<fengb> tgschultz is a big fan of his comptime hacks. I'm not really in favor but still
<ninepoints> i mean, it just speaks to the lack of experience in the code i'm talking about
<ninepoints> it's completely untenable
<ninepoints> but like someone else mentioned, zig might just not be for game dev
<tgschultz> yaeh, I mean, no one ever writes such code in C where there's also no operator overloading
<ninepoints> AAA has no one in C
<mq32> no one writes games in C anymore because it's a pain not to have operator overloading
<ninepoints> every studio i'm aware of is on C++
<ninepoints> operator overloading + templates + polymorphism (for the game logic peeps)
<mq32> ninepoints: polymorphism isn't much needed for games
<mq32> luckily
<mq32> btw
<ninepoints> yea i never use it myself
<companion_cube> this is so confusing that 'polymorphism' isn't parametric polymorphism
<mq32> we're always talking about "operator overloading" is the same syntax as "builtin operators"
<fengb> You can get polymorphism with function pointers
<mq32> the argument against operator overloading is: "you cannot distinct it from a function call"
<mq32> so: what do you think about separate overloading syntax?
<mq32> this would contradict "Reduce the amount one must remember.", but would favour "Communicate intent precisely." (#zen)
<mikdusan> example?
<mq32> something like "a `+` b"
<mq32> where i can recognize both "+" and that it's actually not "+"
<tgschultz> some kind of infix function syntax would be acceptable I think
<fengb> I've been thinking that maybe we could have a pipe operator or "infix" operator
<fengb> a |dot| b == dot(a, b)
<mq32> and i can implement only operators on the same types
<companion_cube> a `dot` b :D
<mq32> so, no "Vec2 * Vec2", but only "Vec2 `*` Vec2"
<companion_cube> like in haskell
<tgschultz> pipe is already used for capture syntax so that could get confusing, but it does look nice
<fengb> Backticks is probably better yeah
<fengb> It was a thing in Elm but they removed it in favor of backticks
<mq32> i can write up a proposal later if you want, i'm thinking a long time about this already :D
<fengb> I'm still trying to find a blurb why
<fengb> Er... removed backticks in favor of pipe operator
<mq32> fengb: backticks are a dead key
<mq32> it's hard to type for non-nodeadkey-keyboards
doublex_ has joined #zig
<mq32> usually you type à instead of `a
<ninepoints> i'd be ok with a haskell-like infix operator notation i think
<ninepoints> it retains the left-to-right readability of an expression at least
<companion_cube> a 🤔+ b
<ninepoints> which is the main issue with the usage of function composition
<riba_> is there a way to print the info of a c-imported struct definition?
<companion_cube> a *👀 b
doublex has quit [Ping timeout: 264 seconds]
<mikdusan> i'm going to ask the obvious: why not access operator? ma .+ mb .* mc <-- i did purposely use .* to show that we already use that for deref
<mq32> mikdusan, i think that's a) harder to read, b) ambigious and c) not symmetrical
<tgschultz> mb.* vs mb .* is too close for my comfort
<mq32> so "ma .add mb" is kinda weird
<mq32> what is also to be considered is operator precedence for custom operators
<fengb> ma .+. mb .*. mc 🙃
<companion_cube> a ~+~ b
<mq32> where there is a very simple answer: "evaluation left to right with no operator mnixing"
<mq32> a ~~~ b
<mq32> :D
<tgschultz> even primitive operators will probably have compiler enforced disambiguation
<mikdusan> on that subject i'm not sure the rabbit hole of _also_ overloading precedence is wise
<mq32> overloading precedence is horror
<mikdusan> swift
<fengb> a 💩+🤮 b
<mq32> it makes parsing the language quite impossible
<companion_cube> don't overload the precedence, use the same as the "normal" operators
<mq32> also, another thing to consider: only allow known-symbol operators, single-symbol operators, text-only operators?
<companion_cube> OCaml doesn't have overloading, but you can write infix functions
<fengb> I personally think it should be any regular function that's 2 arguments
<fengb> I suppose that's the Haskell way
doublex has joined #zig
riba_ has quit [Ping timeout: 240 seconds]
<companion_cube> tbh infix operator overloading strays quite far from "better C"
doublex_ has quit [Ping timeout: 240 seconds]
<mq32> oh
<mq32> the infix idea is like ... 2 years old :D
<fengb> I really don't like UFCS
<tgschultz> I'm not surprised it's an old idea. I am alittle surprised it was closed though.
<tgschultz> I don't really like infix fuction call either, but as an alternative to operator overloading it's far more palatable to me.
<mq32> tgschultz: it doesn't read like it's off the table forever though
<mq32> i'm with you that "classic operator overloading" is a horrible idea with hidden control flow, but having at least some way to infix-call functions is a benefit for any algebra-heavy code with custom types
<emekankurumeh[m]> it was just closed because it was forgotten
<tgschultz> Yes, I've been convinced of that by empassioned arguments in its favor.
<mq32> my biggest problem with readability with function calls (be it "normal" or UFCS calls) is that the actual information is clobbered in a horrible mess of parens
<tgschultz> `a #plus b` doesn't look bad either. Still doesn't feel very 'zig' to me, but I'm not really sure what that means anyway.
<mq32> i'm still in for "a `+` b"
<ninepoints> +1
<mq32> yes, it's more to type, but it's also easier to parse for me (and the compiler doesn't care anyways)
<tgschultz> well the parens may end up being necessary anyway, even with primitives. getting the operator precidence wrong is a pretty common problem.
<mq32> yeah
<mq32> but i want to add something to my point on parens: i'm reordering larger function calls into multiple lines instead of making new local variables
<ninepoints> associativity is huge though. never underestimate how simple a * b * c is to write compared to mul(a, mul(b, c))
<ninepoints> (extrapolating to many many variables/indeterminates)
<mq32> because i have to come up with good names for them (which isn't really useful when doing math because stuff is like sum_of_a_and_b_times_c)
<mq32> did you mean "how simple a * b * c is to *READ* compared to mul(a, mul(b, c))"
<ninepoints> yes
<ninepoints> both really
<emekankurumeh[m]> i suppose that's what https://github.com/ziglang/zig/issues/114 if for
<mq32> i don't care for writing. it's the same level of hardness because the thought process is the same
<ninepoints> i always optimize for reading also
<mq32> but having to de-cypher a function call is harder as soon as it's nested
<mq32> emekankurumeh[m]: yeah, i'm totally in on that, even though it adds some parens
doublex has quit [Ping timeout: 268 seconds]
<mq32> "(a `*` b) `+` (c `*` d)" is still way more readable than "add(mul(a,b),mul(c,d))" (even though the example is quite small)
<mikdusan> how about "no hidden allocations"; is that compatible with the vast majority of custom math operators?
<ninepoints> adding an allocation in an operator is a sin punishable by death
<ninepoints> jk
<emekankurumeh[m]> would infix operations only be free functions? or would they have to be fully qualified?
<companion_cube> ninepoints: hey what about bigints? :o
<mikdusan> good point
<emekankurumeh[m]> what about stack allocations?
<ninepoints> usage of bigints is also a sin
<mikdusan> stack i think is excluded from that
<tgschultz> I feel like allocations must definitely be out
<ninepoints> push and pop are not "allocations" in the colloquial sense
<tgschultz> heap allocations that is
<ninepoints> big int, tbh, i've never found a use for?
<mikdusan> making a compiler you'll need it
<ninepoints> why not just a dynamically resizing array in that case
<ninepoints> why is it a number necessarily
<emekankurumeh[m]> that's why i always do call my functions with @newStackCall([]u8{}, func, ...) to i don't do any sinful allocations
<mikdusan> because it can do number'ish things
<mq32> <tgschultz> I feel like allocations must definitely be out
<mq32> +1
<mq32> mikdusan: on your original question: i would even forbid errors on infix calls
<fengb> I think stack allocations should be fine. The compiler would theoretically detect the max stack allocation
<mq32> try (a `+` b)
<emekankurumeh[m]> ewww, what about infix functions failing?
<tgschultz> forbidding errors also makes sense
<ninepoints> how can the compiler detect that when recursion is possible
<fengb> There's a separate issue for safe recursion. It's semi-solved
<tgschultz> should be a requirement shouldn't it? infix must take exactly 2 parameters (of the same type?) and return exactly one non-optional non-error.
<mq32> ninepoints: zig has/will get safe recursion, meaning: you have to allocate a new stack to solve this
<mq32> tgschultz, yep, exactly my proposal :)
<ninepoints> oh runtime detection you mean?
<mq32> the good thing about both forbidden errors and allocations is: this reduces the use of infix calls a lot, thus making misuse much harder
<fengb> The proof of concept is solved, but the implementation is currently... not pretty
<mq32> ninepoints: no, comptime. zig can calculate "deepest possible stack level" for *some* functions, otherwise if there is no guaranteed stop-condition, you have to heap-allocate new stack
<tgschultz> ideally we'd also guarantee pureness of infix
<fengb> ninepoints: Yeah, we can recurse using the heap instead of a stack frame, and it follows the same semantics as OOM at that point
<ninepoints> got it
<mq32> so no side effects for infix operators? yes, please :D
<emekankurumeh[m]> perhaps you would just `try` the whole expression? try (a `/` b)
<ninepoints> i was going to make my infix plus spawn a new thread and allocate a 1 gb texture
<tgschultz> Why not? cpp lets << do io
<emekankurumeh[m]> but with errors you can catch divide by zero errors
<fengb> try (cout `<<` "hello world\n")
<fengb> Looks fine to me
<fengb> 🙃
<emekankurumeh[m]> infix closures anyone?
<mikdusan> no side effects yes, but i think there should be a way to inject runtime safety error for overflows/whatever just like current safety checks are done
<fengb> I feel like we're now tossing together random jargon
ntgg has joined #zig
<tgschultz> mikdusan, that makes sense to me
<tgschultz> but yeah, how to reconcile "no side effects except this one big one"
doublex has joined #zig
<fengb> Zig doesn't detect side effects atm
<mq32> one question is left out: how to declare such infix operators?
<mikdusan> i suppose the overload impl would always have a const self and then naming convention for the ops
<mq32> my idea was to just make it pretty similar to struct funs
<mikdusan> maybe even -> pub fn @`+`(self: Matrix, other: Matrix)
<mq32> struct { const Self = @This(); x: f32, y: f32, pub fn `·`(a: Self, b:Self) f32 { … } }
mahmudov has quit [Ping timeout: 245 seconds]
<tgschultz> well i still prefer the `#op` convention, and that could work by just saying you can call any struct decl fn with the pattern `fn(T,T)T` using it.
<tgschultz> so `a #op b` is just sugar for `a.op(b)`
<emekankurumeh[m]> with certain constraints with on the prototype of op
<tgschultz> yeah, it has to be `fn(T,T)T` where T is @typeOf a and b
<emekankurumeh[m]> though `a #@"+" b` looks kinda ugly
<tgschultz> then don't do that?
<tgschultz> `a #plus b`
<emekankurumeh[m]> fair
<fengb> I don't like # since it looks like a comment but it's pretty unambiguous
<mq32> i would allow the operators changing the return type, otherwise something like "dot product" could not be implemented
<emekankurumeh[m]> why would we mandate that the types be the same?
<emekankurumeh[m]> that wouldn't allow multiplying scalars and vectors, or broadcast operators
casaca has quit [Ping timeout: 276 seconds]
casaca has joined #zig
<tgschultz> true
* companion_cube looks at rust's operator overloading :-°
<emekankurumeh[m]> i mean, the Allocator interface used to be fused to the language for async functions
<tgschultz> yeah, and I was quite pleased when that went away personally.
casaca has quit [Ping timeout: 268 seconds]
<torque> why would an infix function need to be something special (besides only having two arguments)? If there's a specific syntax for calling a function as infix, then any normal function should be able to be used this way
casaca has joined #zig
<torque> the bigger problem with trying to create a math dsl within zig is that a lack of function overloading means `scalar dot vector` would end up having a different infix name than `vector dot vector`
<torque> so actual math purists would probably not be wild about it
<tgschultz> how would that work for fns that took 3 parameters and could return a nullable? `(a #op b c).?` ?
<torque> I think it's reasonable to say that infix can only take two arguments, so trying to use a function with 3 parameters would be a compile error
<torque> just like if you tried to call `my3argfunc(a,b)`
<torque> as for unwrapping the optionals, that seems like it follows from how you'd do it with a normal function
<emekankurumeh[m]> well, you could have the second argument be var parameter and comptime switch on the type
<torque> that's a good point
<emekankurumeh[m]> instead of function overloading
<fengb> Is (a #op b c).? any better than a.op(b, c).?
<mq32> <emekankurumeh[m]> why would we mandate that the types be the same?
<ntgg> is there a better way to write this line? `if (end) |end_char| if (end_char == char) return i;`
<emekankurumeh[m]> that would be invalid
<mq32> i think there's a more important question that needs to be solved previously: "in what scope does the resolver search for the user-defined infix function?
<torque> why would scope resolution be any different than for normal functions?
<tgschultz> yeah, but it gets nasty in a hurry: `try (a #op b #op c)` coould only work if op took error unions for all parameters, so you'd have to do `try (try a #op b) #op c` which isn't any better than the situation with normal function calls. I guess the solution could just be "don't do that then".
<emekankurumeh[m]> torque: where would a #op b look for op?
<emekankurumeh[m]> inside a? inside b? inside the global scope?
<emekankurumeh[m]> @ntgg
<torque> right
<mq32> torque: why is that needed? because i want to declare an operator `+` for both Vec2 and Vec3
<torque> I forget about the method syntax sometimes
<mq32> otherwise the whole idea of adding overloaded operators for readability is gone
<torque> is it? you could just explicitly import your operators
<emekankurumeh[m]> ntgg: `if (end != null and end.? == char) return i;`?
<torque> `const dot = Vec2.dot` or whatever
<muffindrake> Has there been work on a json parser in zig?
<companion_cube> const `*` = Vec2.dot
<mq32> torque, this will only work if you only use Vec2 in your code
<mq32> muffindrake: std.json should fulfill all your needs
<emekankurumeh[m]> yes there is one in the std lib
<torque> see earlier claim about the issue with lack of function overloading
<muffindrake> I'm blind
<pixelherodev> Given that LLVM is supposed to have a C backend, is it possible to compiler Zig into C?
<muffindrake> It's right there in the directory :(
<pixelherodev> s/compiler/compile
<emekankurumeh[m]> being able to link to doc page is quite satisfying
<tgschultz> pixelherodev if LLVM has a C backend, probably yeah
<ntgg> emekankurumeh[m]: oh right, thanks.
<mq32> pixelherodev: yes, there even *was* a C backend in the old days
<mq32> but it was removed :(
<pixelherodev> Drats :P
<torque> this would be an interesting application of that overloading proposal that explicitly defines overloads from groups of functions
<emekankurumeh[m]> Julia seems to have revived it
<companion_cube> fwiw in OCaml people something define `Foo.Infix` that you can open locally to overload infix operators
<mq32> emekankurumeh[m], yeah but it's "bad" as i've tried it, it didn't emit standard C and used "modern" features
<companion_cube> (since infix operators are just normal functions, and `open` puts them into scope)
<pixelherodev> It also seems to require LLVM 8
<emekankurumeh[m]> perhaps we can come up with some comptime magic import the operators automatically?
<pixelherodev> So apparently LLVM just didn't feel the need to update the docs and say "Nope doesn't exist"?
<fengb> pixelherodev: you can compile LLVM to wasm, and there's a few wasm to C compilers 🙃
<companion_cube> 😂
<pixelherodev> ... that's a terrible plan but I feel like doing it just to make a point now :P
<fengb> The C output is terrible though since it's translating a stack language. But still
<mq32> the important question is: does it output C89?
<fengb> Probably? wasm is a dirt simple language so no idea why it'd do anything more complicated
<mq32> would be quite cool to have some "* → K&R C" compiler
<pixelherodev> If it's only being used as a step in a convoluted compilation process it's probably mildly tolerable, but definitely not worth the effot
nrdmn has joined #zig
wootehfoot has joined #zig
sossy has joined #zig
ky1ko has quit [Remote host closed the connection]
mahmudov has joined #zig
FireFox317 has joined #zig
Ichorio has joined #zig
lunamn has joined #zig
lunamn_ has quit [Ping timeout: 240 seconds]
<mq32> andrewrk: i need a shirt! where do i get one?!
<emekankurumeh[m]> we have shirts?!
<emekankurumeh[m]> what about stickers?
riba has joined #zig
<mq32> i'll print that and sticker it to my new laptop as his firstie
gunnarahlberg has joined #zig
<riba> i'm trying to recreate the struct that's giving me problems because i need to initialiaze it statically but it has char * fields (i.e. non-const)
<gunnarahlberg> hi! does anyone know of plans to work with libsodium?
<riba> now i'm getting to the function pointers and it's getting weird
<riba> can i print info on an imported type somewhere?
<mq32> riba: you can even look at the zig code ;)
<mq32> there's somewhere your code in zig-cache
<mq32> you can use "zig translate-c" as well to convert headers
<riba> mq32: good point, thanks
<riba> i failed to use translate-c but i don't quite remember why
<nrdmn> ok I was skeptical about mascots and logos
<nrdmn> but that's pretty metal
<riba> somehow i feel like there should be a feature somewhere that makes it unnecessary to copy stuff from the zig-cache dir
<riba> the "just trust me dude" mode
<mq32> riba, you should be able to do everything "by-hand"
<riba> mq32: yes, but i'm only doing this because a thing that works in my c code does not work in the zig code because someone 20 years ago decided to omit the const at the struct definition
<fengb> Andrew doesn’t want to run a store, but Cadey offered something
<andrewrk> gunnarahlberg, libsodium is a C library. Zig has good integration with C libraries
<companion_cube> that's why `const` should be the default… :/
<gunnarahlberg> andrewrk, yea thank you, Zig has good integration with C libraries, I totally concur with that.
<andrewrk> riba, try --verbose-cimport
<gunnarahlberg> andrewrk, just wanted to check were Zig will draw the line, e.g. to re-implement libsodium in Zig or not :)
<FireFox317> riba: You could change the definition in zig to take a const and use that one instead. It should still work with the c library tho
<riba> andrewrk: thanks, i now realize that it does exactly what i want. i tried it before but the output was unexpectedly long and i didn't even think to scroll
<gunnarahlberg> e.g. if someone would want to implement a https://developer.okta.com/blog/2019/10/17/a-thorough-introduction-to-paseto in Zig, that would require something like what libsodium does
<riba> FireFox317: that's what i'm currently doing :D
<riba> let's see if it will work with the macro magic
<andrewrk> gunnarahlberg, this question will probably be left up to the zig community. I don't think the compiler or package manager will have a dependency on these abstractions
<THFKA4> TLS tho
<companion_cube> iirc the design of the package manager would be to bootstrap without TLS
<companion_cube> just dl with normal http, then use a checksum
<THFKA4> hardcoded checksum? checksum also downloaded with http?
<andrewrk> that will be an option, and it's also planned that packages can have "plugins" for supporting additional fetching protocols
<andrewrk> THFKA4, "Trust On First Use"
<companion_cube> I imagine there could be a checksum hardcorded for the first stage of the package manager?
<companion_cube> so it can install its plugins or whatever :p
<andrewrk> right. the first person to ever download and install a dependency is responsible for verifying the checksum / being on a secure internet connection, and then the checksum is committed to source control along with the list of dependencies / versions
<FireFox317> andrewrk: I'm not sure if you knew this but if you past a link to the std documentation website in the irclient (I'm using HexChat), and click on it it only links to the part before the ';' i.e. https://ziglang.org/documentation/master/std/#std;json
<FireFox317> Wait
<FireFox317> On the client it links correctly, but on the irclog it doesn't (firefox)
<andrewrk> ah, interesting
<andrewrk> there are some adjustments that need to be made to the URL
<FireFox317> That is probably an issue of the irclog's link parsing and turning it into a <a> tag then
<FireFox317> According to this stackoverflow post (https://stackoverflow.com/a/1178053), that links to the RFC, a semicolon is a reserved symbol in a URL
<riba> working with glib is a bit of a pain so far
<FireFox317> Hmm, it does show up in the example section of the RFC tho
<riba> i have a function that returns c.gboolean but i cannot return c.TRUE
<riba> it seems it's an error in the import? i don't quite get it
<riba> error: expected type 'bool', found 'comptime_int'
<riba> pub const TRUE = !FALSE;
<riba> while FALSE is defined like this: pub const FALSE = 0;
<riba> i guess you can't negate an int and expect something good to happen in zig?
<andrewrk> riba, in zig a bool must either be true or false; integers do not implicitly cast to booleans. you can use `x != 0` to convert
FireFox317 has quit [Ping timeout: 240 seconds]
<riba> andrewrk: that sounds useful, but the @cImport is creating these automatically
<riba> i can just define my own TRUE to be 1, just didn't expect compile errors from the autogenerated code
<andrewrk> translated C can be a little rough around the edges. it's not in its final form yet
FireFox317 has joined #zig
<andrewrk> macros are especially hard to translate because they are not even C. they're an abominable combination of context sensitive preprocessor language mixed with C
<Snektron> That ziguana looks like a crocodile
<Snektron> But its cute too
gunnarahlberg has quit [Ping timeout: 260 seconds]
<riba> okay, now the compiler is crashing
<riba> TODO implement get_c_type for more types
<riba> Unable to dump stack trace: debug info stripped
<andrewrk> riba, congrats, you're truly one of us now
<riba> how do i debug this? :D
<andrewrk> with a debugger. what OS are you on?
<riba> fedora
<riba> i assume i need to compile it myself first with debugging symbols activated?
<andrewrk> oh, this is to do with generating .h files. do you need that?
<riba> i don't
<andrewrk> --disable-gen-h
<andrewrk> this feature belongs in self-hosted only
<riba> i see, yeah this worked now
<Cadey> fengb: i'm waiting on approval from legal at work :(
<riba> i think i need to stop for today though, thanks for all the help
<andrewrk> Cadey, you got your work to pay for zig t shirts?
<Cadey> andrewrk: No, they made me sign a contract that says i need approval to moonlight things
<Cadey> It's a Quebec being backwards thing
<andrewrk> oh, that's shady
<andrewrk> I'm surprised the legal system there even allows that
<Cadey> Me too
<Cadey> i'm working on trying to get a lot of it reversed, but it's hard given i work for an e-commerce company
<Snektron> The infamous general allocator thats being worked on, is that more than a linked list? Or is that the debug allocator too?
<Snektron> It kinda surprised me that thats missing, it shouldn't be too hard to make something like that right?
<Snektron> A teacher of mine made one and it wasn't that complex
<Snektron> Maybe that peforms really bad or something
<andrewrk> Snektron, have a look at the roadmap on the readme: https://github.com/andrewrk/zig-general-purpose-allocator/
<andrewrk> there's also the question of, ok, but what about when you want to turn off debug mode?
<Snektron> I suppose you have two options
<Snektron> Either introduce a builtin debug mode
<Snektron> Or make the debug allocator wrap another
<andrewrk> and it already supports wrapping another. the point is that we don't have a general purpose release mode allocator, designed for performance
<Snektron> Ah yes, i forgot about mode
<Snektron> Hmm, sounds like a good project, though i kinda already was making something else
<Snektron> Ill try to read some papers and see if i can cook up something
<fengb> Simple allocators aren't too hard
<fengb> But they can get hairy real fast
<fengb> You should try writing one! It's actually pretty fun in Zig
<Snektron> But not always fast
<Snektron> I find writing Zig really refreshing
<Snektron> But on the other side, i've become really allocation aware, and i have a tendency of overengineering so that doesnt mix well
<Snektron> Because i'll just get stuck trying to find a more efficient way
<andrewrk> I think that's good for libraries
squeek502 has joined #zig
<andrewrk> for applications, they'll probably come up with some kind of strategy that makes it easier to iterate quickly with regards to memory allocation. e.g. for a command line tool, arena allocator for the entire lifetime of the program is fine
<Snektron> Depends on the program of course
<Snektron> Though i wonder in which cases it really matters
<Snektron> I mean i've never had the need to write a custom allocator in C++ before
<FireFox317> I mean for games I think it does really matter a lot what kind of allocator you use, which brings me to a point of the game developer that was here earlier, he was asking for operator overloading. We should really come up with some way to make them happy, because it would enable a lot more game developers to use zig, I think. However, we do have some game devs already and they are happy with status quo, so I'm not really sure
<Snektron> I read a bit about thag
<Snektron> I think its not just operator overloading
<Snektron> Whats missing is some way of extending things without it being too involving
<Snektron> For example, Rust has the trait system for this
<Snektron> Even in c++ its possible, although a bit clunky, but operator overloading can be used for that
<Snektron> For example << and >>, but also the usage of | in the new ranges
<THFKA4> the hard part will be reconciling this type dispatching with the "no hidden control flow" goal of the language
<FireFox317> Jup good point THFKA4
<Snektron> Writing a long computation pipeline without something like that is not nice
<Snektron> Working with C++ iterators is really nasty, everyone knows that
<Snektron> And the way formatting works for a custom type is not really the best as well i'd say
<Snektron> You'll probably run into conflicts really often if thats used as standard method
sossy has quit [Remote host closed the connection]
<FireFox317> I mean for games I think it does really matter a lot what kind of allocator you use, which brings me to a point of the game developer that was here earlier, he was asking for operator overloading. We should really come up with some way to make them happy, because it would enable a lot more game developers to use zig, I think. However, we do have some game devs already and they are happy with status quo, so I'm not really sure
<FireFox317> Whoooops my bad -_-
FireFox317 has quit [Ping timeout: 265 seconds]
wootehfoot has quit [Read error: Connection reset by peer]
waleee-cl has quit [Quit: Connection closed for inactivity]
<muffindrake> This wiki entry states Zig has no metaprogramming. That's not correct, or is it?
<andrewrk> it doesn't really have any meta programming
<andrewrk> unless you count reflection
<muffindrake> Oops. I am conflating Generics with that. My bad.
<muffindrake> Please confirm that we in fact have generics, and that I didn't imagine reading about them in the zig docs.
ntgg has quit [Quit: Lost terminal]
<muffindrake> Hurray.
Ichorio has quit [Ping timeout: 264 seconds]
riba has quit [Ping timeout: 240 seconds]
<mq32> btw, "unreachable" is a great concept
<mq32> if(blabla()) unreachable;
<mq32> this is just more expressive to add an assert instead of just discarding a value
<andrewrk> that can be shortened to assert(!blabla());
<mq32> yeah, but i have still some bad memories of doing something like the assert with business logic
<mq32> and the compiler optimized that away in release mode :D
<andrewrk> there's no "buts" here, assert is literally if (!ok) unreachable
<mq32> yeah, i know :D
<Snektron> The compiler also removes if (thing()) unreachable in release mode
<mq32> Snektron, also if thing() may not be always true?
<mq32> what i'm doing is if(@atomicRmw(…) != someAssertedValue) unreachable;
<mq32> so it would be quite painful to have the atomicRmw removed
doublex has quit [Ping timeout: 276 seconds]