ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
kllr_sbstn has quit [Remote host closed the connection]
_whitelogger has joined #zig
<daurnimator> Is that proposal for function definitions as expressions going anywhere soon?
<andrewrk> epoll could be a lot better. it has several annoying issues to work around
batok has quit [Remote host closed the connection]
<saskwach> Is there a canonical way to iterate over a range of indices in Zig?
<saskwach> I just want to count.
<andrewrk> var i: usize = 0; while (i < len) : (i += 1) {}
<saskwach> ouch
<andrewrk> ?
<saskwach> Oh, wait, that (i += 1) is in parentheses after the condition.
<saskwach> So `while (termination-condition) : (run-each-loop) { body }`?
<saskwach> er, where <termination-condition> terminates the loop when it's false.
<saskwach> Ah, I see: WhileContinueExpr in the grammar.
<saskwach> Yeah, I was looking for it under `for`.
<saskwach> Any plan to have an iterator along the lines of Python's `range` in the standard library?
muffindrake has quit [Ping timeout: 276 seconds]
muffindrake has joined #zig
mahmudov has quit [Remote host closed the connection]
Ichorio has joined #zig
<tgschultz> saskwach, you can kinda do it with an fn that returns [_]void, but only for 0-N. This might not be 100% correct, but: `pub fn range(n: usize) [n]void { return [1]void{ void{}, } ** n; }` `for(range(10)) |_, i| { ... }`
Ichorio has quit [Ping timeout: 264 seconds]
<saskwach> I was thinking of a simple struct with a `next` method and a counter.
<saskwach> Like the iterator in array_list.
<tgschultz> yeah, you can do that, but it's actually more complicated than just using a normal while loop
chemist69_ has joined #zig
Ichorio has joined #zig
Ichorio has quit [Read error: Connection reset by peer]
chemist69 has quit [Ping timeout: 265 seconds]
<marler8997_> saskwach: I wrote a CounterRange, a small post about it here:
<daurnimator> andrewrk: indeed epoll has weird things. e.g. it works on file *descriptions* not file *descriptors*.
<daurnimator> e.g. if I dup() a file descriptor, I get a second file descriptor pointing at the same file description
<daurnimator> there's a few other things around that work in the same way that you might not expect. e.g. the O_NONBLOCK flag.
<andrewrk> daurnimator, some code you might enjoy looking at:
<andrewrk> in summary: is dead, no longer needed now that we have better evented I/O integrations wit
<daurnimator> andrewrk: k. looking now
<daurnimator> andrewrk: FYI backlog is deprecated as a listen argument. Lets be modern and not have it
<marler8997_> are you sure it's deprecated on all platforms?
<andrewrk> what do you mean it's deprecated? does the os not provide that configurability anymore?
<daurnimator> andrewrk: most Oses now ignore the argument.
<marler8997_> andrewrk: I believe I've read that some platforms ignore it now
<marler8997_> I'd recomment a default value, and/or a wrapper function
<marler8997_> listen(sock)...listenBacklock(sock, backlog)
<daurnimator> + be lazy and don't implement the latter
<andrewrk> sounds good if most OS's ignore it anyway
<daurnimator> you're always going to need a `serverFromExistingFD(4)`
<andrewrk> but look at the difference in this test pre- and post- async/await rewrite:
<daurnimator> if someone really wants to pass the listen backlog argument, they can use the lower level function and pass the fd ownership
<marler8997_> the point is to make the platform-independent abstraction orthogonal to zig's "flavor" of the api
<marler8997_> if you want to pass in a backlog, you shouldn't need to start having platform "if"s
<daurnimator> marler8997_: why not? when only some platforms support it....
<marler8997_> all platforms conform to the same API
<daurnimator> marler8997_: note that some platforms allow all sorts of listen filtering
<marler8997_> in which case you would need platform ifs
<marler8997_> but if all platforms use the same API, you shouldn't need platform ifs to use that common api
<marler8997_> if (builtin.os == Windows), backlog) else if (builtin.os == Linux) std.os.linux.sock.listen(sock, backlog) ... etc
<andrewrk> I hope someone here knows windows networking and wants to contribute
<daurnimator> andrewrk: could you make it handle multiple clients at a time with just a few lines?
<marler8997_> I wrote a "shim" layer to the winsock API
<marler8997_> we had to write a library that filtered all networking calls to either the default windows stack, or an external network stack
<andrewrk> daurnimator, yes, easy
<daurnimator> andrewrk: I know it..... I don't particularly want to contribute though. I don't use windows myself....
<daurnimator> though I'm happy to mentor it
<daurnimator> If anyone here *is* interested, I would say an excellent first step is porting to zig
<daurnimator> just line-for-line would be fine
<marler8997_> goodness using overlapps...
<andrewrk> #3557 is going to be annoying
<andrewrk> it involves the fact that std.fmt.format uses a non-comptime function pointer, which calls write() sometimes
<andrewrk> var args + involved comptime code execution + runtime-known function pointer + async function
<andrewrk> that's about as complicated as you can make a zig function
<andrewrk> it's weird that format could suspend, but it makes sense if the output function is calling non-blocking write()
<daurnimator> andrewrk: you could also have a return type that depends on a comptime-side-effect-having call based on argument types :P
<andrewrk> I was thinking it might be nice to turn std.fmt.format into an iterator
<marler8997_> hmmmm, interesting idea
<daurnimator> andrewrk: I've used std.fmt.format as a template for other functions. so your changes here are going to be pretty impactful across the board
<andrewrk> idk something like: var it = format("a = {}, b = {}\n", a, b); while ( |buf| write(buf);
<andrewrk> daurnimator, yeah, understood. the root breaking change is std.os.write is going to become an async function when == .evented
<marler8997_> iterator might not work as well, since you'd have to track extra context between each call
<daurnimator> andrewrk: oh I know why. I'm saying its a good thing; and whatever you go with, I'd also update e.g.
<marler8997_> with a format function, you can use the position inside your function to keep track of what's been printed and what's to come
<andrewrk> marler8997_, I think that information could be available as an iterator field
<daurnimator> marler8997_: `it` could encapsulate a @Frame containing the context...
<andrewrk> anyway I'll try it and see. I'm determined to make std.os.write participate in event-based I/O
<marler8997_> daurnimator: would that allow you to arbitrarily resume a function at any point?
<andrewrk> btw daurnimator another use case for noasync popped up today:
<andrewrk> daurnimator, the whole point of this is to do blocking file system operations in a thread, since they never return EAGAIN. so these calls will not suspend. however without "noasync" then posixFsRun becomes async, which is not allowed since that's the Thread.spawn entry function
<andrewrk> so these annotations assert that the function calls will never suspend, even though e.g. is generated as an async function (because of networking)
<daurnimator> andrewrk: why can't a Thread.spawn entry function be async again?
<andrewrk> if it suspended, where would control flow go?
<andrewrk> it's the same thing as trying to suspend in _start
<andrewrk> suspend in machine code is `ret`
<andrewrk> also this question misses the point. these function calls *will not* suspend and if they did suspend something would be broken
<daurnimator> right... so we're sort of generating machine code (the suspend `ret`) that never gets hit....
<marler8997_> I really need to see more of this async/await stuff in action to wrap my head around it
<daurnimator> btw, the fs.Request type is a lot like the uring SQE type on linux
<daurnimator> I wonder if we can make them the same thing
<andrewrk> `loop.waitUntilFdReadable(fd)` is an async function, so calling it is a suspend point
<andrewrk> elsewhere in the code, this suspend point will be activated, because is used for non blocking networking
<andrewrk> but in this case for the file system thread, the code provides a runtime guarantee that this will not happen
<daurnimator> which reminds me of a misc idea I had: trying to make slices have the same in-memory layout as a struct iov. I had the idea of a new root file thing: `pub fn slice(comptime T: type) type { return struct { ptr: [*]T, len: usize }; }
<marler8997_> there's been a few times I've needed and/or wanted to the know the internal structure of a slice in D
<marler8997_> having it defined as a struct means the app will have access to all the info that a struct provides
<marler8997_> it seems structs are the answer to everything, namespace, tuples, slices? I guess C had it right all along :)
<daurnimator> yep. and e.g. making it `extern` could make it possible to export slice-taking functions as ABI
<andrewrk> marler8997_, re: async/await stuff, I really should do some more documentation and blog posts on the subject. i'm pretty sure I invented something new here that no other language has ever done, and the semantics are sound, but of course nobody knows how it works because it's not something that exists elsewhere.
<andrewrk> i'll do that after more of the std lib is integrated with it
<marler8997_> yeah I've even watched your YouTube vides and I still have a hard's just such a foreign concept, it's hard to relate it to anything that currently exists
<daurnimator> andrewrk: yeah zig's async/await is pretty novel; I still take partial credit cause of the demo I gave you on how we solved "function colours" in Lua :)
<marler8997_> which means the only way that I"ll learn it is by seeing examples and using it
<andrewrk> marler8997_, did you see the linked snippets here?
<andrewrk> daurnimator, indeed that was an inspiring demo :)
<andrewrk> these 2 snippets I feel are nice and simple - the usage of and the implementation
<marler8997_> a nice example, but I don't understand it since I can't see the full stack of the function calls
<marler8997_> is os.accept4 what causes the suspend?
<marler8997_> oh wait, you have strace
<marler8997_> still grokking...
<marler8997_> so, when acccept returns does the socket get added to epoll?
<marler8997_> ah, loop.waitUntilFdReadable
<marler8997_> so...what's the purpose of the code being inside the suspend block? isn't it equivalent to just running it before calling "suspend"?
<andrewrk> marler8997_, because it denotes where the function will get resumed. consider that as soon as you call epoll_ctl it can be resumed
<andrewrk> you can have 1 thread finishing out the suspend block (after the call to epoll_ctl) and 2nd thread has already resumed it
<marler8997_> hmmm, so then wouldn't suspend; foo(); be equivalent to suspend { foo(); } ???
<andrewrk> you're missing the part where it gets resumed
<marler8997_> yeah I don't think I understand what "resume" means....
<marler8997_> once a thread is "resumed", I would guess control flow resumes after the suspend block
<marler8997_> and the code inside the "suspend" block is the "resume code"???
LargeEpsilon has joined #zig
<andrewrk> we're not talking about threads
<andrewrk> this all works single threaded
knebulae has quit [Quit: Leaving]
jjido has joined #zig
knebulae has joined #zig
marijnfs has joined #zig
FireFox317 has joined #zig
<mq32> mikdusan: i solved my mysterious triple fault... at least 50% of it
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nikoala has joined #zig
return0e has quit [Ping timeout: 240 seconds]
return0e has joined #zig
FireFox317 has quit [Remote host closed the connection]
emekankurumeh[m] has quit [Read error: Connection reset by peer]
BitPuffin has quit [Remote host closed the connection]
Demos[m] has quit [Remote host closed the connection]
D3zmodos has quit [Remote host closed the connection]
dtz has quit [Write error: Connection reset by peer]
fengb has quit [Remote host closed the connection]
vegai has quit [Remote host closed the connection]
Snektron has quit [Remote host closed the connection]
jicksaw has quit [Ping timeout: 240 seconds]
jicksaw has joined #zig
fengb has joined #zig
LargeEpsilon has quit [Ping timeout: 252 seconds]
dtz has joined #zig
Demos[m] has joined #zig
BitPuffin has joined #zig
Snektron has joined #zig
D3zmodos has joined #zig
vegai has joined #zig
riba has joined #zig
LargeEpsilon has joined #zig
riba has quit [Ping timeout: 268 seconds]
FireFox317 has joined #zig
<FireFox317> andrewrk: Do you mind updating the online std documentation with the current master, because the js error fix (#3550) is not on yet
waleee-cl has joined #zig
<andrewrk> FireFox317, done
<FireFox317> Thanks!
<andrewrk> I need to finish that merging tool
<FireFox317> No problem man, do the work that's most fun! The std docs were supposed to come in the stage2 anyway, so we are happy with what we have now :)
<andrewrk> that is a trick to staying productive - allowing myself to jump around in what I work on
<companion_cube> structured procrastination
<andrewrk> it's so effective
qazo has quit [Read error: Connection reset by peer]
dimenus has joined #zig
jjido has joined #zig
jjido has quit [Client Quit]
qazo has joined #zig
<dimenus> where is the ci build script for mingw?
<andrewrk> there isn't one
<dimenus> ah, are we not building mingw/msys anymore?
<andrewrk> mingw was never an officially supported target, but emekoi has dilligently kept it working
<dimenus> wow, i've totally misunderstood how that all works this whole time
<dimenus> thanks
<dimenus> i always equated mingw64 with MSYS2
<dimenus> didn't realize mingw-w64 was a separate thing (and more of a linux toolchain to support windows dev then host windows)
<andrewrk> MSYS2 is the toolchain, and what people usually mean when they say "mingw"
<andrewrk> MinGW is 32 bits only, and that makes it not very useful to me. but the project is not dead
<andrewrk> mingw-w64 supports i386, x86_64, aarch64, and arm, and it's what MSYS2 is based on
<andrewrk> zig ships with the ability to compile mingw-w64 from source, which gives us a libc for 4 windows targets
<dimenus> mingw-w64 supports those all targets as hosts, correct?
<dimenus> ah, i also didn't really realize that windows on arm was a thing
<dimenus> lol
<dimenus> TIL
<andrewrk> yeah it took me a hot minute to figure this out when I was doing libc stuff
<dimenus> ok, i'll use the regular msvc compiled toolchain then on windows :)
<andrewrk> goodness, the llvm-dev mailing list is blowing up, everybody's pants are on fire trying to move to GitHub as the official repo
dimenus has quit [Read error: Connection reset by peer]
LargeEpsilon has quit [Ping timeout: 276 seconds]
FireFox317 has quit [Remote host closed the connection]
FireFox317 has joined #zig
wootehfoot has joined #zig
FireFox317 has quit [Ping timeout: 240 seconds]
LargeEpsilon has joined #zig
plumm has joined #zig
<plumm> ./3
<plumm> ok so from my understanding, its atm impossible to use std.fmt or any of the format apis at compiletime
<andrewrk> have you tried bufPrint
<lunamn> bufPrint uses varargs, and those aren't on comptime, issue 313
<plumm> yeah, if my usecase is bufPrint(buf[0..], "{}", s) i mind as well use the .format directly
<andrewrk> hm zig is getting a little old for var args to still not work
moo has joined #zig
wootehfoot has quit [Ping timeout: 265 seconds]
<plumm> andrewrk: how would i go by calling format on just the argument itself? can I just leave a majority of the options as void since there is no buf/allocator?
<plumm> very confused
moo has quit [Quit: Leaving]
wootehfoot has joined #zig
Ichorio has joined #zig
LargeEpsilon has quit [Ping timeout: 246 seconds]
<andrewrk> goodness, why is it so complicated to download netbsd source?
<andrewrk> how did you get from to this link?
dingenskirchen has quit [Remote host closed the connection]
<muffindrake> I didn't. I searched for 'netbsd source' on ddg and that was the third result.
<andrewrk> my comment stands then, since I followed the official path
dingenskirchen has joined #zig
<fengb> Maybe their site is deprecated and Google is now official 🙃
<andrewrk> (thanks though muffindrake I was able to find what I wanted from that official mirror)
dimenus has joined #zig
LargeEpsilon has joined #zig
dimenus has quit [Read error: Connection reset by peer]
knebulae has quit [Ping timeout: 240 seconds]
LargeEpsilon has quit [Ping timeout: 252 seconds]
knebulae has joined #zig
<ky1ko> andrewrk, from, "developers->browse source"
<ky1ko> it's a cvs repository
<ky1ko> tarballs are also available at
knebulae has quit [Ping timeout: 276 seconds]
<ky1ko> as well as on the same path for any netbsd mirror
<andrewrk> ky0ko, "browse source" isn't going to help me grep
<ky1ko> then download that repository using cvs, just as you would download it with git if it were a git repository
<andrewrk> I saw this page: and then saw the instructions regarding environment variables
<andrewrk> and I stand by my comment about this process being overly complicated
<ky1ko> that is a relic of cvs unfortunately
<andrewrk> it gives netbsd the impression of being a relic of the past as well
jjido has joined #zig
<ky1ko> it is nontrivial to move from cvs to git and retain history for a project like netbsd, and they desire that
<ky1ko> it's been actively discussed for a while and hopefully they'll move to it. in the meantime i recommend the release tarballs
<andrewrk> that's what I was looking for, never found one
marijnfs_ has joined #zig
clktmr has joined #zig
knebulae has joined #zig
<mq32> heyhoh
<mq32> is there a way to include "anynomous" padding fields in packed structs?
<mq32> i remember some discussion from github about using "_ : u3" for padding
<andrewrk> mq32, give it a unique name and a default value
<mq32> yeah, i'm calling them _0, _1 and so on
<andrewrk> padding1: u3 = undefined,
<andrewrk> or maybe 0, depending on how it's supposed to work
<andrewrk> what problem would taking away the name solve?
<mq32> to give an unnamed padding a name ^^
<mq32> there's a value that is just "defined zero"
<andrewrk> this would introduce more problems than it solves. better that all fields have names
<mq32> maybe you're right
<mq32> but right now i have different problems...
<mq32> it looks like my packed struct is not having the layout i want altough i double-checked it already
wootehfoot has quit [Read error: Connection reset by peer]
Ichorio has quit [Ping timeout: 264 seconds]
LargeEpsilon has joined #zig
<pixelherodev> There's a bug with that still IIRC
LargeEpsilon has quit [Ping timeout: 276 seconds]
<mq32> pixelherodev, nah. turns out i'm just stupid and assume that decimals are hexadecimals :D
<mq32> but i think i found a bug with inline assembler:
<mq32> you cannot pass direct memory locations via "m"
<mq32> but that is probably different in Zig than in C, dunno
<mq32> how do you call lgdt and lidt?
<pixelherodev> mq32, actually, you can pass direct memory locations
<pixelherodev> That's what I'm doing for CPUID to initialize the FPU
<mq32> okay? can you show me how?
<andrewrk> recommended is to use ={reg} when possible which means "when the inline assembly begins, this register will have this value"
<mq32> asm volatile ("lidt %[var]" :: [var] "m" my_val);
<andrewrk> err the = is for outputs. but you get the idea
<pixelherodev> my_val should be in parentheses IIRC
<mq32> pixelherodev, yeah i typed that from memory :D
<mq32> andrewrk: i need a certain memory location emitted instead of of a register variable
<mq32> but it failed with internal compiler error :D
<andrewrk> I see, any register will do but it needs to have a certain value
<mq32> the instruction cannot take register values
<pixelherodev> mq32, I just made it a global and did `lgdt GDTD`
<mq32> pixelherodev: same here
<pixelherodev> Don't forget to set segment registers ;)
<mq32> i still wonder why i get a triple fault
<mq32> segments are already set :)
<mq32> i survived this :D
<pixelherodev> After you do `lgdt` you need to set segments
<mq32> yeah
<pixelherodev> Ah, that's what you meant
<pixelherodev> Thought you were implying you were using the ones set by [insert bootloader here]
<mq32> no, the GDT is already set up with linear segments
<pixelherodev> Where's your triple fault? IDT?
<mq32> yeah
<pixelherodev> Ah
<pixelherodev> Fun!
<mq32> IDT is loaded correctly (qemu tells me in the interrupt log)
<mq32> but it faults
<pixelherodev> You can compare against mine if you want
<mq32> yeah, sure :)
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ltriant has joined #zig
<mq32> looks like you're following the same tutorial as me?
<pixelherodev> Nope
<pixelherodev> Not following any tutorial :)
<mq32> ah no. little differences :D
<pixelherodev> Just using the OSDevers wiki for general info, and the specs for more details when applicable
<mq32> then: you missed something
<pixelherodev> I currently have like six ACPI-related specs, USB specs, etc
<pixelherodev> mq32, ?
<mq32> one: you don't need cli on each interrupt
<mq32> use interrupt gates for interrupt type
<mq32> this will disable eflags.if
<mq32> when entering the interrupt
<mq32> => automatic CLI
<mq32> also interrupt 8, 10…14 and 17 will push an error code to the stack
<pixelherodev> Wait what?
<pixelherodev> The interrupt gate thing sure
<pixelherodev> But since when did - wait, *17*?
<pixelherodev> Ohhh, interrupts interrupts
<pixelherodev> Not IRQs
<mq32> yeah, take a look here (actual "production" code)
<mq32> okay. i found my problem. i didn't understand the selector right ^^
<pixelherodev> What were you doing?
<mq32> using 0x01 instead of 0x08 for the selector
<pixelherodev> Ah
<pixelherodev> Yeah, that would do it :)
<mq32> didn't understand that it must be the same as the selector register content :D
marijnfs_ has quit [Quit: WeeChat 2.6]
<pixelherodev> It's the *offset*, not the index, yeah
<daurnimator> ky1ko: moving from CVS to git is relatively trivial: reposurgeon essentially does it out of the box, and well.
<mq32> pixelherodev, AH. *facepalm*
<mq32> someone could've made x86 a nice architecture ... but they didn't
<fengb> Learning Z80 gave me some understanding of x86’s idiosyncrasies
<mikdusan> hey mq32 what was the culprit in your ub before from a few days ago?
<mq32> looks like it was stupidity from my side paired with the SSE stuff
<mikdusan> ok; you've satisfied my curiosity :)
<mq32> haha :D
<mq32> i now also found those xmm registers
<mq32> and they're gone since the last update
<mq32> btw, pixelherodev: you don't need your assembler stubs in interrupts.zig
<pixelherodev> Regarding the error codes being pushed on 8,10,11,12,13,14,17, I'm going to take some time to browse through the huge Intel manuals and get back to you :)
<pixelherodev> Oh?
<pixelherodev> Macros you mean?
<pixelherodev> Ohhh, comptime
<pixelherodev> Neat
<mq32> comptime is love. comptime is live
<pixelherodev> That one yours?
<mq32> yeah
<pixelherodev> Hmm
<pixelherodev> Makes me think I should add a driver for early serial usage also
<mq32> yeah, my "driver" is just for qemu
<pixelherodev> My current driver uses a heap-allocated ring buffer, and only actually writes on interrupts
<mq32> because as soon as i switch to 640x480x4bpp, the text output is gone
<pixelherodev> I use serial for debug info at all times
<pixelherodev> Keeps the actual terminal cleaner
<mq32> yeah, true
<mq32> and you can grep on serial output
<pixelherodev> Still need to find e.g. a serial->USB cord though so I can actually use it on, say, my PC
<pixelherodev> Yeah
<mq32> but you know what? i'm gonna start that on real hardware now *grin*
<pixelherodev> Warning: might need to tweak a few things for that to work :P
<pixelherodev> Then again, you don't seem to be using any floats yet
<mq32> nah, probably never will
<mq32> when wsa the last time you've seen an actual 1GB SD Card? :D
<pixelherodev> I use float math for the timer
<pixelherodev> To make it a bit more precise
<pixelherodev> So that crashed my kernel before I set up the FPU :P
<oats> I somehow got a ping notification for the word "floats"
<oats> that's odd
<pixelherodev> ... sorry!
<oats> pixelherodev: lol, no worries
<oats> I'm more amused than anything
<pixelherodev> Yeah, that is kind of funny
* oats will have to look into that...
<pixelherodev> Ah, the nice feeling when you commit all your work and finally have a clean repo again :)
<andrewrk> I'm trying to get there...
<pixelherodev> mq32, alrighty, I can confirm that error code stuff
<ky1ko> daurnimator, there's a large number of other concerns as well, like how well git runs with very large repositories on hosts with <128mb of ram. or rather, how well it doesn't run. an sgi indy with 64mb of ram can be expected to do a cvs checkout of the netbsd sources. but not a git clone. real netbsd users and devs expect to be able to use low-spec hardware.
<pixelherodev> ~page 2917 of the Intel manuals at the moment :)
<ky1ko> that, plus nobody's put together a solid transition plan for the infrastructure
<daurnimator> ky1ko: true. but those are not concerns about converting to git; but the flow associated with git. Its probably possible to keep a CVS mirror of git master branch; and have git as the source of truth.
<mq32> <pixelherodev> mq32, alrighty, I can confirm that error code stuff
<daurnimator> ky1ko: but your concerns go back to the original point andrew made: if you need to run on an SGI indy with 64mb of ram, then netbsd may just be a relic of the past...
<pixelherodev> mq32, since there's no license I'll ask here: mind if I steal that interrupts code for myself?
<mq32> from my code? go ahead
<mq32> yeah i would be baffled if it wouldn't be like this
<mq32> tyndur is a quite "complete" OS
<pixelherodev> No yeah I figured, but I felt it'd be worth checking anyways
<mq32> i really hate that we need that licence stuff
<daurnimator> btw, I created a os-dragonfly label and added relevant issues to it.
<andrewrk> thanks daurnimator
Ichorio has joined #zig
<daurnimator> Has anyone asked for a dwarf code for zig?
<daurnimator> (from GCC I think?)
<andrewrk> I remember starting this process but I don't think I got as far as sending a patch.
<pixelherodev> mq32, fun story: I'm already using interrupt gates
<pixelherodev> 99% sure
<pixelherodev> Which means the `cli` is even *more* unnecessary :P
<mq32> lol
clktmr has quit [Ping timeout: 265 seconds]
<mq32> i got to get some sleep, but now is the time to make some actual progress on the system
<andrewrk> argh what is this nonsense error
<daurnimator> Looks like this is how Go got added:
<mq32> still need to get paging up, but then i'm ready :)
<pixelherodev> What are you making it for?
<oats> whatever happened to that one OS written in zig, I think it was called "zen" or something
<daurnimator> I'll file an issue there
<andrewrk> oats, my buddy andrea got bored of it and is traveling the world or something like that
<oats> heh, fair enough
<andrewrk> daurnimator, oh, I did this part
<mq32> pixelherodev: I have gotten some really cool industrial control case which is missing some innards... and i thought it would be cool to create some fake console out of this with bare metal x86
<mq32> so this project will be similar to pico-8 in the basic idea, but will feature some very different stuff
<pixelherodev> Ah, right :)
<ky1ko> daurnimator, that's primarily the example i use because i run that in my home lab, but i want to note i'm personally aware of netbsd developers who really do not have access to modern hardware, and for whom these are actual concerns.
<ky1ko> much modern software doesn't take well to being run with low resources, and when you know you have devs without access to anything better than a core solo laptop with less than a gig of ram, salvaged from an attic somewhere, you are wary of that.
<ky1ko> that is, sort of the use case of netbsd, in my experience
<daurnimator> andrewrk: oh. lucky I checked here before hitting submit