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/
redj has joined #zig
<tgschultz> man, errorsets are so broken. It's hard to make any significant changes to the interface pattern because of it.
<tgschultz> can't be inferred if they're empty. can't be inferred sometimes for no apparent reason. Sometimes they just assert the compiler.
<tgschultz> to be fair, some of these are just comptime related type checking errors. Like they way it likes to assert when it encounters an undefined symbol
ijneb has joined #zig
MajorLag has joined #zig
tgschultz has quit [Ping timeout: 268 seconds]
MajorLag is now known as tgschultz
MajorLag has joined #zig
tgschultz has quit [Ping timeout: 244 seconds]
MajorLag is now known as tgschultz
<tgschultz> great, integration tests won't even give me traces with a debug build.
redj has quit [Ping timeout: 255 seconds]
redj has joined #zig
<tgschultz> narrowed the problem down to combining error sets in a return type. Which is great, since I can't refer them.
<tgschultz> *infer
<tgschultz> I think I'm just going to have to take a break from working on zig before I start hating it.
<andrewrk> tgschultz, I think the problem is you're trying to improve zig while avoiding bug fixing. it's not really possible at this stage of maturity
<andrewrk> I wouldn't be able to do any significant features/improvement without fixing bugs along the way either
<andrewrk> I mean I don't blame you
<andrewrk> but that's why it's not working
<andrewrk> bugs also meaning design flaws such as the empty error sets situation that you identified
<tgschultz> I'd fix the bugs if I could. I just don't have the familiarity with how compilers are structured so I can't really follow what's going in.
<tgschultz> yeah, I know, it's nobody's fault really, zig is still early days, it's just frustrating.
<andrewrk> yeah, big time
<andrewrk> even I'm frustrated that I can't progress as fast as I want to
<andrewrk> I wish I could hire somebody
<scientes> I'm having the same problems with coding LLVM, but its that I can write the feature far faster than I can write it in a maintainable way
<scientes> and a reviewable way
kristoff_it has joined #zig
<tgschultz> ok this is strange. stage1.zig in `stage2_render_ast` it appears to have switch prongs that I can't tell where they're coming from. It should only be possible for the errorset of COutStream or Allocator to be produced from its call to render(). I don't think it is a coincidence that this is where the assertion failure happens
kristoff_it has quit [Ping timeout: 246 seconds]
<tgschultz> ah, ok. It's my fault for making a bad assumption about the error set of COutStream.
<tgschultz> I'm ok with this. I can accept problems that are my fault as long as they make sense.
adsr has joined #zig
_whitelogger has joined #zig
scientes has quit [Ping timeout: 245 seconds]
<tgschultz> well I'm feeling a lot better now that I'm making progress again. that'll probably change when I have to deal with async allocators again, but I've got a good feeling about plan C for tackling them. worst case I'll just not rewrite Allocator until after coroutines are redone.
_whitelogger has joined #zig
_whitelogger has joined #zig
kristoff_it has quit [Ping timeout: 258 seconds]
redj has quit [Ping timeout: 268 seconds]
redj has joined #zig
coolreader18 has joined #zig
qazo has joined #zig
kristoff_it has joined #zig
jjido has joined #zig
kristoff_it has quit [Ping timeout: 255 seconds]
qazo has quit [Ping timeout: 268 seconds]
qazo has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
Aransentin has joined #zig
mikdusan has quit [Read error: Connection reset by peer]
Aransentin has quit [Ping timeout: 256 seconds]
Sahnvour has joined #zig
qazo has quit [Ping timeout: 245 seconds]
qazo has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mikdusan has joined #zig
qazo has quit [Read error: Connection reset by peer]
scientes has joined #zig
kristoff_it has joined #zig
wootehfoot has joined #zig
wilsonk has joined #zig
kristoff_it has quit [Remote host closed the connection]
Sahnvour has quit [Quit: Leaving]
Aransentin has joined #zig
wootehfoot has quit [Quit: Leaving]
wootehfoot has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 252 seconds]
<Aransentin> I have questions ( or perhaps complaints :) ) about epoll in Zig's standard library. I wanted to make an event loop with it on Linux for my program, so I used std.os.linuxEpollCreate and friends:
<Aransentin> 1. Why are they located in std.os and named linuxFOO? Seems odd to me when there's os.linux.
<Aransentin> 2. linuxEpollWait catches EINTR and restarts the loop with the same timeout, which was kinda unexpected. If SIGINT is raised I wanted it to quit so I can quickly cleanup my resources, not have to wait twice as long (worst case) for the timeout to expire.
<Aransentin> 3. linuxEpollWait calls posix.epoll_wait and handles a few errors, but I'd like to use seccomp which can (in theory, though I only want EPERM) return any error.
<Aransentin> 4. posix.epoll_wait then actually calls linux.epoll_pwait! If I can't guarantee that only the syscalls I want are emitted I can't make reliable seccomp filters, and this makes me sad :(
<Aransentin> Basically the ideal thing for me would be to have a fairly thin Zig wrapper around all the kernel syscalls that converts any returned errors to Zig errors. Is something like that planned?
jjido has joined #zig
_whitelogger has joined #zig
<tgschultz> Aransentin: std.os.linux should directly expose the syscall. It won't convert the errors, but you could use http://zig.tgschultz.com/errno_to_error.zig
<Aransentin> Ah, that's nice
<Aransentin> As for directly exposing syscalls, check out e.g. https://github.com/ziglang/zig/blob/master/std/os/linux.zig#L1439-L1441
<Aransentin> epoll_wait simply calls epoll_pwait
<Aransentin> Which for normal usage would be okay, but I'd like to be able to predict exactly what the program will do :)
<tgschultz> I'm not sure the reasoning for that, sorry.
<tgschultz> you should be able to call syscallN(SYS_epoll_wait, ...) though.
<scientes> Aransentin, arm64 doesn't even have epoll_wait, so that is my fault
<scientes> Aransentin, and glibc also won't call those syscalls
<Aransentin> Just pwait? Aha.
<scientes> like it will use openat() if you use open()
<scientes> its kinda annoying in strace, but its the way things are
<scientes> the code could be patched up, but it would required fixing some bugs
coolreader18 has quit [Ping timeout: 258 seconds]
<BitPuffin> is there short hand syntax for initializing a struct to zero
kristoff_it has joined #zig
<emekankurumeh[m]> no, you have to std.mem.secureZero(&struct_instance)
<emekankurumeh[m]> there you used to a zeros keyword, but it was removed
<BitPuffin> hmm, but that doesn't really work well with nested literals
<mikdusan> BitPuffin: is your intention to really init zero? or simply undefined until filling in real values later?
<BitPuffin> really init zero
<mikdusan> (just checking) :)
<BitPuffin> :)
kristoff_it has quit [Ping timeout: 246 seconds]
<BitPuffin> but my workaround now is just to not use the struct init syntax then because that's a pain
<BitPuffin> so I'm gonna set fields individually
<BitPuffin> which lets me do zero
<BitPuffin> mikdusan: but usually I code so that zero is initialization as much as possible
<BitPuffin> emekankurumeh: doesn't seem to quite work
<BitPuffin> since the secureZero function returns *T
<BitPuffin> rather than []T
<mikdusan> std.mem.set(u8, dst, 0);
<mikdusan> but secureZero reutrns void. ?
<BitPuffin> yes it does
<BitPuffin> set has the same problem it seems
<BitPuffin> so I guess the question is how do I get a slice from a single struct
<BitPuffin> mikdusan: yes, is that [0..] necessary?
<BitPuffin> Either way
<BitPuffin> can just wrap this into a function and it should be handy
<mikdusan> yes because []Foo{ foo } is an array of size 1 -> [1]Foo; and to convert that to slice the syntax is array[0..] or array[0..array.len-1] equiv. or your range choice.
<mikdusan> iirc there was talk of making []Foo{ foo} syntax change to avoid confusion. it's really just a convenience and this is equiv [1]Foo{ foo }; but by inferring array size it's a bit confusing looks like slice
<BitPuffin> hmm I thought zig did implicit cast where it was safe and unambiguous
<BitPuffin> also doesn't foo get copied into the array in your version maybe
<mikdusan> BitPuffin: i think you're right. i'm an idiot.
<BitPuffin> Everyone makes mistakes :)
<mikdusan> BitPuffin: this just really copies what secureZero does for a standalone (ie. without slice). https://gist.github.com/mikdusan/26391f8dd5ee849f3408cb39990fe56d
<BitPuffin> But yeah I wonder why zeroes was removed
kristoff_it has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<BitPuffin> mikdusan: maybe I should make a proc that takes a type and does zero init and returns the struct
<Aransentin> Question about build.zig: I'm running a (slow) external tool to preprocess a couple of files. Can you get a addSystemCommand step to only run when some specific file(s) have changed?
SamTebbs33 has joined #zig
kristoff_it has quit [Ping timeout: 252 seconds]
jjido has joined #zig
<scientes> Aransentin, I don't use builder, but that sounds like a feature that ninja has
<scientes> I never understood why Zig has to have to much NIH
<scientes> *so
<Aransentin> Yeah, nautrally I could use a makefile or something
<scientes> Make is really bad
<scientes> but IMHO builder should really use ninja
<Aransentin> Eh, make works well enough. I know how to use it fairly well too, which is a big plus :)
<scientes> but i guess builder has higher aspirations
<scientes> Zig is structured a little differn't where the whole source is compiled at once
<scientes> so it kind of has to do its own build system, and it will need alot of work in LLVM to do multi-threaded compiles
<scientes> like C has header files to reduce memory usage, but computers don't really need that any more
<scientes> zig's approach makes sense, but it means alot has to be redone
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<scientes> perhaps it could still use ninja to build c stuff.
<Aransentin> Ah, okay. I'm fairly ignorant how builder works under the hood, mostly mashing together examples I found on github right now
<scientes> Like I think zig could benifit a bunch if glibc's libm was make usable without glibc
wootehfoot has quit [Quit: Leaving]
<scientes> I've never used it, I can just use build-exe
wootehfoot has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
jjido_ has joined #zig
<BitPuffin> scientes: once you make a programming language you've already swallowed the NIH pill :)
<Aransentin> Another question: Can you force-import a file that has some test/export that you want to run, but you don't want to do anything with directly?
<Aransentin> (since the files are lazy-loaded means the "export" function in it will never be parsed)
<Aransentin> I guess I can put and call some noop() function in it that'll get optimized away in the end, but there has to be a nicer way of solving it
<andrewrk> hi Aransentin
<andrewrk> if you want to unconditionally import, replace `test "std"` with `comptime`
<Aransentin> Yep, that worked brilliantly
<Aransentin> Thanks!
<andrewrk> Aransentin, as for your question about epoll earlier - I have an in progress very breaking (sorry!) change to address that which is so far 29 files changed, 3510 insertions(+), 3224 deletions. See https://github.com/ziglang/zig/issues/2380 for more details
<scientes> yeah I did some of that too, but it wasn't ready for release
<scientes> but I felt it should use @typeMember() so that the all the syscalls still work
<andrewrk> scientes, yes I'm solving that problem as well
<andrewrk> scientes, I recognize it's not really fair - if you had submitted exactly these changes as a PR, it would have been very difficult to review & merge
<scientes> yes I realized that as well
<scientes> I also wanted to fix getError's excessiveness, in most syscalls (but not mmap()) you can just do < 0
<scientes> or rather a direct switch()
<andrewrk> I'm fixing that too
<scientes> cause success always returns 0
<andrewrk> here I'll push my wip branch
<scientes> and then I do want to do mapping of zig errors to errno, but that is tricky to do cleanly
<andrewrk> that's a whole separate proposal which may or may not work
TheLemonMan has joined #zig
<BitPuffin> andrewrk: how come zeroes was removed?
<andrewrk> `system` is mapped to `c` when linking libc
<scientes> andrewrk, that write() bug actually isn't like that, I looked at the source code
<scientes> i will accept any value, but only write/read that much
<andrewrk> BitPuffin, zero initialization makes the not-always-correct assumption that the bit pattern of all 0's is a useful and valid state
<scientes> so there is nothing to fix
<scientes> if it did exist, it was only like <2.6.32
<andrewrk> scientes, that's good to know, thanks
<BitPuffin> andrewrk: well it's very useful to code that assumes zero is initialization. Partially because it's very cheap to init to zero
<andrewrk> BitPuffin, for example if you had any pointers in your struct, and you initialized it to zeroes, your pointers which are never supposed to be null are now null
<BitPuffin> Yeah it doesn't work for pointers
<andrewrk> init to undefined is even cheaper
<andrewrk> plus, if you init to undefined, zig can provide safety protection
<BitPuffin> Yeah but you can't write code that assumes undefined is properly initialized
<andrewrk> well yeah that's entirely the point
<scientes> it will never be slower to explicitely initialize
<BitPuffin> However I can write programs where most objects can be valid when initialized to zero
<scientes> because if hardware shows up that initializes it for you (and there are proposals as such) the compiler will optimize out the initializations
<BitPuffin> Either way. It's a surmountable thing
<TheLemonMan> andrewrk, you probably want to pull the trigger on #2493 too
<scientes> well, actually I don't think the compiler knows that mmap() returns zero-initialized data.....
<BitPuffin> Can just make a function that inits a struct to zero from a comptime type argument
<andrewrk> TheLemonMan, yeah, sorry I wanted to try to finish up my PR and then do around of reviews
<andrewrk> if it's blocking you I can take a look
<andrewrk> TheLemonMan, oh neat did you use ir_print_instruction in the debugger?
<TheLemonMan> yup
<andrewrk> to make you aware, ConstPtrMutRuntimeVar & friends are a flawed way to represent comptime mutability. I believe the "root cause" fix is going to be representing this information with scopes: https://github.com/ziglang/zig/issues/1487
<andrewrk> this fix is good though, thanks! trigger pulled
<BitPuffin> andrewrk: can even compile time refuse to init to zero if the type contains non nullable pointers I think :)
<TheLemonMan> comptime pointers are a hassle in pretty much every language I've worked on heh
<andrewrk> TheLemonMan, do you have a project you're working on in zig or are you contributing to the compiler for its own sake?
<TheLemonMan> I like to work on compilers, for me it's a way to relieve some stress while doing something productive heh
<andrewrk> well your contributions have been very valuable so thanks
<andrewrk> BitPuffin, in summary: zig has scopes for variables, which is compile-time enforcement of only using a value when it is well-defined and intended to be used. however this is coarse grained - sometimes it's only known at runtime whether a value is well-defined or not
<andrewrk> for this case we have the concept of `undefined`. you can assign `undefined` to a value and then zig's runtime safety mechanisms can help prevent accidental use
<andrewrk> there are some such safety mechanisms in place already - writing 0xaa, valgrind-aware annotations - but more are planned
<scientes> its also using llvm's UndefValue if it gets that far, on --release-fast mode
<andrewrk> `zeroes` is in conflict with these safety protections. it comes down to one of the "zen" statements: Communicate intent precisely.
<andrewrk> this precision gives both safety/debuggability in the safe build modes and performance in the unsafe build modes
<andrewrk> btw has anyone checked out this project? https://github.com/dbandstra/zang/ the demos are pretty cool
<TheLemonMan> noice
<TheLemonMan> andrewrk, what was the problem with stack probes on osx?
<andrewrk> TheLemonMan, my mind is somewhere else, can you remind me of the context?
<TheLemonMan> hmm, you've disabled them in a7346ea4
<andrewrk> ahh
<andrewrk> did you see the commit message? looks like I explained it there
<TheLemonMan> yep, but what are the steps to reproduce the failure? I'll probably have a look at lld source code sometimes soon
<andrewrk> in build.zig, remove the logic that treats macos separately in addLibUserlandStep
<andrewrk> if you could solve this, it would probably solve everything: https://github.com/ziglang/zig/issues/1981
<tgschultz> speaking of unusable files, re: DOS and freestanding generating elfs, objcopy can convert to a format I can almost use, but it doesn't seem to translate the relocation table (either that or the PE capable DMPI loader I'm usuing doesn't pay any attention to them). That's ok, I don't need relocation, but I don't know how to tell the compiler to output everything without relocation and assuming a base address.
<tgschultz> --disable-pic didn't seem to work
<andrewrk> tgschultz, what are you looking at to determine that it is in fact generating PIC?
<andrewrk> can I see the linker line that it ends up using?
<tgschultz> the disassembly of the result. the addresses it references are not valid. I don't usually work at this level so I may be doing one or several things wrong.
<tgschultz> How would I determine that?
<tgschultz> lld -error-limit=0 --gc-sections -m elf_i386 -static -o .\dos .\dos.o C:\Users\Tanner Schultz\AppData\Local\zig\stage1\o\S1QNaJtAnGiI6LpiK4Nh1SOa-mVbGPsrF5ZK_dGjYrxhM6T1hvKmjCU-OLn9T0UH\libbuiltin.a C:\Users\Tanner Schultz\AppData\Local\zig\stage1\o\3Zxob99r1bdyo8gdIX4a9Nvr3VpLpxceWgBbftcpgvy_1jKy99qj3it6-mbfGAeF\libcompiler_rt.a --allow-shlib-undefined
<andrewrk> are you looking at the output of build-obj or build-exe?
<scientes> look at objdump --all tgschultz
<andrewrk> looks like you're using build-obj which is going to produce a relocatable object. I don't think it's possible to create a non-relocatable object. try using build-exe
<tgschultz> andrewrk: build-exe, though the .o file doesn't seem any different. scientes: objdump just says file format elf32-i386
<andrewrk> ah my mistake
<scientes> --all
<scientes> that gives you a high-level overview of the contents of an elf
<tgschultz> scientes that was with all, there's only one file, which is a very short bit of assembly to call DPMI and switch to protected mode... In fact, the zig file I'm using is completely empty so I'm only engaging the assembler.
<tgschultz> I suspect there's something relatively obvious I'm missing about all this
<andrewrk> that could easily be true but I don't see it either
<scientes> then you could try --disassemble
<andrewrk> my approach would be to try to come up with an example that does work, and try to see what's different about it
<scientes> --disassemble --all
<andrewrk> e.g. with msvc or whatever other people do to make these dos exes
<tgschultz> well for starters they don't output ELFs.
<tgschultz> but yeah, I'm still looking in to how this is supposed to work. Once I get get into protected mode and verify I can talk to the DPMI host, then thigns should go more smoothly (I hope).
<andrewrk> they output COFFs?
<andrewrk> I think we can do that
<tgschultz> I'm not sure what the object format would be, but the end result is a DOS MZ (not PE) exe I think. I've found surprisingly little documentation about 32bit dos programs.
<tgschultz> But I do think starting with COFF output instead of ELF would probably be smoother.
<scientes> tgschultz, what are you trying to do?
<tgschultz> scientes: my bad, I used -all instead of --all, I am indeed getting a more informative dump.
<tgschultz> scientes: a side project, exploring the ability to build 32bit DOS programs with zig. Possibly even stdlib support. Personally I'd just like to make a DOS game with it, mode 13h and all that.
TheLemonMan has quit [Ping timeout: 258 seconds]
<scientes> cause DOS can't run without an emulator on 64-bit machines
<scientes> its kinda dead
<tgschultz> I'm aware of that.
<tgschultz> I'm using a debuger enabled build of DOSBox for now
<tgschultz> I'll switch to a serious emulator later on
<tgschultz> like qemu
<scientes> do those work with games?
<scientes> I thought DOS games had timing stuff that didn't work with emulators
<tgschultz> Old DOS games used a lot of tricks, though according to the demoscene, who would know, DOSBox is actually not very good at emulating a lot of the trickier things. I just mean using a more complete emulator to prove to myself that it is likely to work on real hardware, well, without lugging out some hardware I have that actually runs DOS anyway.
<scientes> but this is new development.....
<scientes> maybe you should do baremetal ARM
<tgschultz> That's not intereting to me at this time.
<scientes> or AVR-8, llvm has some support for that (although gcc's is better
<scientes> ok, it not my business
<tgschultz> This is really just for my personal amusement, though if it becomes reasonable to do so, it's possible zig could support DOS-i386 as a target. There's a surprising amount of DOS still running in the world.
shritesh has joined #zig
<scientes> Zig on baremetal is really exciting for real work...
<scientes> so anyone hacking on it can push zig forward
<tgschultz> Eventually I'd like to do that, but there's nothing about that right now that really interests me. If a completely open platform comes along, I may be interested in building a new OS on it, but that seems unlikely in the near future. RISC-V is taking off, apparently, but there's no such thing as an open GPU for instance.
<scientes> ARM-M is pretty good, there are a bunch of proprietary implementations of it
<scientes> well actually not the M version, more the high-power versions
<scientes> there are like 4 differn't high-performance completely independent implementations of ARMv8 instruction set
<scientes> and Mali open driver just got merged into Linux kernel
<scientes> or maybe the next one, its in drm tree
<tgschultz> the driver is open, but Mali isn't.
<tgschultz> and if I was using the linux kernel then it wouldn't be bare metal anyway.
<scientes> doing 3d bare meta would be pretty intense
<scientes> i don't think anyone could pull that off
<jjido_> ...
jjido_ is now known as jjido
<scientes> anyways, a MMU is nice
shritesh has quit [Quit: segfault]
<andrewrk> tgschultz, something to try: hack up codegen.cpp init() function. look for LLVMSetTarget. hack that triple_str to be "i686-unknown-none-coff" and see if that changes anything
<BitPuffin> andrewrk: Yeah that makes sense. Especially with the emphasis on safety. While I do think there is room for a version of zero init that only allows it when it is safe to do so. I don't think it's strictly necessary to have it as an officially supported thing as it appears I can just make a procedure that does exactly what I want.
<scientes> BitPuffin, you can just wrap an allocator
<scientes> its quite simple
<scientes> and if you use arena allocator...oh wait I think we write 0xaa now...
<BitPuffin> Since I mainly wanna use Zig for games (and surprisingly maybe some web dev for fun) my concern skews a bit towards getting out of my way more than safety at times.
<BitPuffin> scientes: can't I just instantiate a struct on the stack from a type parameter and return it?
<andrewrk> "safety" also means "find your bugs quickly so you can iterate faster"
<scientes> low level stuff really needs to get this right
<BitPuffin> Yeah and the times when it does I'm really happy about it
<BitPuffin> Which is part of why I'm excited about zig
<andrewrk> BitPuffin, I think this will solve your use case: https://github.com/ziglang/zig/issues/485
<BitPuffin> Cuz it seems like more than rust it seems to buy time thanks to safety without costing time fighting with the safety mechanisms
<BitPuffin> andrewrk: true! Except when I'm interacting with C types :)
<scientes> you can do that with c types
<scientes> there is no reason it wouldn't work with c types
<andrewrk> scientes, in auto generated @cImport output you don't have access to the definitions
<scientes> but you could just redefine it
<scientes> with an extern
<andrewrk> the type?
<scientes> yes
<scientes> C code does this all the time
<scientes> not so much in C++, because its so complicated
<BitPuffin> Yeah but I don't wanna redefine them
<BitPuffin> That's friction I can live without
SamTebbs33 has quit [Quit: leaving]
SamTebbs33 has joined #zig
<scientes> BitPuffin, you might be able to do it with @typeInfo so that it is safe
<BitPuffin> The super handy interop with C is a killer feature for me. One of the main reasons I hopped from nim is because I don't wanna sit there writing bindings or fighting with c2nim
<scientes> this could be totally automatic
<scientes> you could just iterate through the namespace and add initializers
<BitPuffin> scientes: yep exactly my thinking. Basically any plain scalar type can safely init to zero I think
<scientes> requires fixing a few bugs
<BitPuffin> Hmm didn't know I could mutate namespace at compile time
<andrewrk> I'm not aware of that being possible
<tgschultz> writing a metafunction that iterates through a struct's member and sets everything to a reasonable "zero" value where it makes sense to do so is possible. Look at serializer/deserializer for how it inspects a type all the way down to the primitives, then just set them to 0 instead of writing/reading them from a stream.
<scientes> oh, i thought you could monkey patch
<scientes> guess i hadn't tried it
<andrewrk> if it were possible to monkey patch, I would change things so that it became not possible
<BitPuffin> Macro hater :p
<andrewrk> yes
<scientes> that is a good thing
<BitPuffin> So other than monkey patch. Can you make new code?
<andrewrk> BitPuffin, have you read about how formatted printing works?
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jjido has joined #zig
Aransentin has quit []
tyler569 has quit [Ping timeout: 246 seconds]
shritesh has joined #zig
shritesh has quit [Client Quit]
SamTebbs33 has quit [Read error: Connection reset by peer]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
SimonNa has joined #zig
tgschultz has quit [Ping timeout: 246 seconds]
tgschultz has joined #zig
MajorLag has joined #zig
tgschultz has quit [Ping timeout: 268 seconds]
MajorLag is now known as tgschultz
coolreader18 has joined #zig
coolreader18 has quit [Client Quit]
coolreader18 has joined #zig
<coolreader18> andrewrk: I made a PR for TI-Nspire support #2513, would you be able to check it out?
<andrewrk> coolreader18, yes, apologies for the delay. After I finish up this branch I'm working on, I'll do around of PR review
<coolreader18> 👍
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 258 seconds]
<scientes> coolreader18, it would be alot cooler if you didn't use the c libraries
<scientes> but non-the-less cool
coolreader18 has quit [Quit: Leaving]