<daurnimator>
andrewrk: can you confirm you're into the box?
<andrewrk>
confirmed, thanks!
<andrewrk>
how do I get it to be 32 bit arm?
<andrewrk>
uname -m: aarch64
<andrewrk>
wanted: uname -m: arm
<daurnimator>
andrewrk: arm64 can run arm32 I think; main missing piece would be a 32bit libc for debian I sort of know how to install that; but nixos you're the expert :P
<andrewrk>
what I need is to run `docker build` in an environment that thinks it is 32 bit arm
<andrewrk>
that could actually be done with qemu probably. even if it takes all day, it's just every 6 months
<andrewrk>
it is nice to have arm64 hardware to test with though
<daurnimator>
so quick story... I once tried running docker on an arm64 box; but someone had mislabelled a 32bit arm image as arm64. suprisingly it worked without me realising for ages.
<daurnimator>
now how to *make* docker pick 32 bit arm images... I've gotta google that :P
<andrewrk>
hmm. I'm confused as to why the -lc behavior tests are passing on the arm CI. pessimistically it probably means static linking didn't work
<andrewrk>
dammit. I suspected this might happen. docker does not properly namespace based on architecture
<scientes>
so &a[2] doesn't crash anymore
<scientes>
and i'm working on making it work
<scientes>
*on vectors
<daurnimator>
andrewrk: did you swap out docker for an arm32 docker binary as the link above does?
<andrewrk>
I'm probably not going to have time for arm32 today
<daurnimator>
andrewrk: okay. you want me to leave that server up for you?
<tgschultz>
andrewrk, re streams and errorsets: It seems to me that what I'd normally do is write a ton of data and then call flush() at the end. Those writes could have errored almost immediately but I didn't know that and all that data is now in fairy land. Although, I suppose that just means calling flush a lot to check for errors?
<andrewrk>
daurnimator, yeah is there any reason not keep it up?
<daurnimator>
tgschultz: re: flushing .... it can get confusing when there are multiple layers (which there almost always is)
<andrewrk>
tgschultz, right, you'd call flush when you want to check for errors
<daurnimator>
tgschultz: e.g. does "flush" mean pushed down to the next layer? or all the way?
<andrewrk>
that's defined by what the underlying stream of the buffered stream is
<daurnimator>
andrewrk: it might not be in zig....
<tgschultz>
One thing that will work out for this plan: bitstreams are already buffered by necessity.
<daurnimator>
e.g. stream -> TLS wraper (e.g. openssl) -> TCP socket -> kernel main buffering -> network device buffering
<daurnimator>
there is a "flush to next layer" at all points
<daurnimator>
IMO the "best" answer is to automaticaly attempt flushing to the next layer if its cheap or you're full.
<daurnimator>
but then also offer a flush() call for each layer
<tgschultz>
So this would mean you're leaning towards interfaces being anyerror? I'm in favor of that, it was much simpler to work with.
<andrewrk>
tgschultz, yes it's fair to say I'm leaning towards that
<daurnimator>
tgschultz: note that if an "autoflush" fails then you don't have to report it immediately: you can save it for the next flush() call. write() can just return error.BufferFull or something
THFKA4 has joined #zig
<tgschultz>
I think the idea is that write would not fail at all, it would just eat the data. Which is probably ok.
<daurnimator>
tgschultz: the write should definently fail...
<tgschultz>
well that is an option anyway, we could have a small set of generic errors and you have to ask for more complete information
<daurnimator>
tgschultz: I would say that flush() is per-"layer" and could report exact errors. write() would be generic and just tell you to call flush() for actual error info
<tgschultz>
I think that makes sense, so write can return generic errors or "error in lower layer".
<daurnimator>
tgschultz: now what I haven't figured out yet, is a way to indicate that a given buffer is long-lived and doesn't e.g. need to be copied
<daurnimator>
I think for the sake of progress I might have to ignore that optimization :(
<daurnimator>
Though for certain use cases that's... annoying
<daurnimator>
though with "autoflush" we can make it okay for many use cases: if there is nothing in your buffer you can try and call the write() syscall immediately; and then only add it to your buffer if you get a partial write or EAGAIN
<daurnimator>
Though there are times where you don't want that. I've solved it before with an argument to write() of "buffering mode" -> pass an enum of .AutoFlush/.NoFlush
<daurnimator>
andrewrk: sorry didn't answer your question: I would shut it down if you don't think you'd get back to it for a few days. at $1 an hour idling for 3 days is.... a waste of resources.
<andrewrk>
ok didn't realize you were paying $1/hour for it. it's more convenient for me to pay for my own so that I don't depend on anyone to get it up or down
<daurnimator>
andrewrk: I'm not paying; it's donated from the arm foundation/packet.net.
Ichorio has quit [Ping timeout: 264 seconds]
<andrewrk>
ok well same thing goes, it's not useful to me if I have to ping someone to gain access
<andrewrk>
I appreciate your efforts
<daurnimator>
andrewrk: right. hence me asking to add you as a person that can spin up servers. hopefully they'll get back to me today
<daurnimator>
andrewrk: as long as you expect to get back to things in the next 1-5 days I'm fine to leave it running
<andrewrk>
yeah leave it up for a couple days then please, I'll try to figure out this child process stdout EBADF thing
reductum has quit [Quit: WeeChat 2.6]
traviss has quit [Ping timeout: 245 seconds]
<daurnimator>
k
<muffindrake>
Is there a scanf equivalent function in the standard library?
<muffindrake>
I've already looked at fmt.zig, unless I missed something.
<tgschultz>
I don't believe there is
<andrewrk>
muffindrake, depending on your use case, mem.separate or mem.tokenize might be what you want
<muffindrake>
Indeed, some use cases may be covered by those functions, but they're still no real replacement for scanf
<andrewrk>
scanf is possible with zig's language facilities but nobody has written the std lib code for it
<daurnimator>
I still wish someone would port a PEG library to zig. Maybe that someone will end up being me
* daurnimator
emailed Adrian (of Ragel) to ask about zig as a target....
muffindrake has quit [Ping timeout: 252 seconds]
muffindrake has joined #zig
<andrewrk>
traviss, if we improve translate-c we can remove that _NO_CRT_STDIO_INLINE hack too
diltsman has joined #zig
<diltsman>
My code was compiling on Windows. Then I upgraded my VS2019 community installation to the latest patch/build release. After that it fails to find the libc installation. Any ideas?
<daurnimator>
diltsman: there was a recent issue with vs2019 optimisations. I think we commited a fix to turn off some optimizations in vs2019
<diltsman>
So,getting the latest Zig build might fix it?
<daurnimator>
diltsman: indeed.
<mikdusan>
"fails to find the libc installation" <-- looks like `zig-cache/native_libc.txt` needs to be updated?
<pixelherodev>
What's the correct way to compare enum members? In C, I'd just do `>=`/`<=` (e.g. to check if something is a valid letter, `>= A and <= Z', but that's apparently not valid in Zig
<daurnimator>
pixelherodev: enum members don't have ordering
<daurnimator>
pixelherodev: however if you're actually assigning values, you can use @enumToInt
<pixelherodev>
Yeah that's what I thought
<pixelherodev>
Wasn't sure if there was a better option though
<pixelherodev>
Having to specify that on every use gets annoying, but much better than e.g. equality checking twenty different values in an unordered list
<daurnimator>
pixelherodev: given letters are ordered... they aren't a good match for an enum
<scientes>
andrewrk, so you found the writing-back-to-stack ugly in my patch, but that was caused by your decision to not stack allocate vectors, which turned out to be a poor decision, but that is only blocking &a[3] like gcc-9 does
<andrewrk>
scientes, when you say stack allocating, in zig compiler internals you mean making handle_is_ptr true for vectors, right?
<scientes>
yep
<andrewrk>
let's discuss this, but also, related, I've been pondering how to implement array indexing of vectors and I had an idea today at the gym of how to do it
<scientes>
oh wait
<scientes>
handle_is_ptr(Int) returns false
<scientes>
so maybe not
<andrewrk>
I think it will be clean and nice for users, and it allows x[y] syntax, with y as possibly comptime or not
<scientes>
I mean like ints
<scientes>
which are stack allocated
<andrewrk>
vectors are stack allocated the same way ints are
<scientes>
oh, then how do i access the result-loc?
<scientes>
I guess I was just having difficulty with the result-loc stuff
<scientes>
ResultLoc
<andrewrk>
yeah. it's the worst part of the compiler internals at the moment :(
<scientes>
as that is part of stack allocating
<andrewrk>
vectors shouldn't be affected much by result loc stuff though
<andrewrk>
anyway my idea for this is to make there be a type, like I explained earlier, analogous to when you do &x.y of packed structs
<scientes>
but that doesn't allow the flexibility that gcc-9 allows
<andrewrk>
however, there will also be a type for when the element index is runtime known.
<scientes>
and i think it is fundamentally wrong
<scientes>
the pointer should just point to the stack allocation
<andrewrk>
and so when you see this runtime known element index type, if you have for some reason access to the runtime value (e.g. if the instruction id happens to be VectorElemPtr) then you do the operation. otherwise fail with a compile error
<scientes>
so it doesn't work with u7, but it does with u8 and u24
<andrewrk>
let me take your branch and try to work this into it, and see if you like it
<scientes>
it just means that the pointer is excessively typed
<scientes>
and lacks all the flexibility of pointers, so its hardly a pointer
<scientes>
I feel all these weird pointers should just be replaced by bit-granularity pointers
<scientes>
if we want that
<andrewrk>
come up with a list of code examples that you think should work re: vector indexing (you can probably pull them all from your test cases) and I'll show you that they'll all pass with my strategy
<scientes>
yeah, good idea
<diltsman>
daurnimator, that didn't work. mikdusan, I deleted zig-cache before building.
<andrewrk>
diltsman, can you observe this problem with `zig.exe libc`?
<diltsman>
Unable to determine vcruntime.h path
<andrewrk>
sounds like msvc detection needs to be improved. you can work around this with a libc.txt file in the meantime
<andrewrk>
the sooner we get away from depending on msvc the better... we're actually pretty close
<daurnimator>
diltsman: pass the path to it as an argument to zig
Ichorio has quit [Read error: Connection reset by peer]
<pixelherodev>
daurnimator, not an enum of letters; it's keycodes for my kernel :P
<pixelherodev>
Codes are translated from raw input from the keyboard into the internal list; if they match certain patterns (letter, number, etc) then characters are appended to an additional "raw text" buffer that can be read via /dev/stdin
<euantor>
Note that the GitHub Actions one is a bit behind as they changed the syntax a bunch fairly recently and I haven't gotten around to updating it yet
<bgiannan>
Circle-CI is fine
qazo has quit [Read error: Connection reset by peer]
marijnfs_ has joined #zig
mahmudov has quit [Ping timeout: 245 seconds]
marijnfs_ has quit [Quit: WeeChat 2.6]
LargeEpsilon has quit [Ping timeout: 268 seconds]
LargeEpsilon has joined #zig
keithdc has joined #zig
jokoon has joined #zig
waleee-cl has joined #zig
nrdmn has quit [Read error: Connection reset by peer]
riba has joined #zig
riba was kicked from #zig by ChanServ [Banned: negative attitude and low effort]
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<pixelherodev>
Was the compiler crashing if no `builtin` is declared in the root source file a deliberate decision?
<pixelherodev>
Line 9098 of codegen.cpp: `assert(builtin_tld != nullptr);`
<pixelherodev>
I believe it was added in commit 17eb24a7e
<pixelherodev>
... oh wait. My bad, sorry - this is failing if there's no *std.builtin*
<pixelherodev>
That makes way more sense
jjido has joined #zig
traviss has quit [Ping timeout: 245 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<pixelherodev>
This is a byte alignment issue, not a big alignment issue
<pixelherodev>
More to the point, the compiler is *erroring out*
<pixelherodev>
It's *noticing* that the size is wrong
<pixelherodev>
line 7846 of analyze.cpp in the stage1 compiler
<pixelherodev>
But while i can easily find the location where the error happens, I've almost no familiarity with the stage1 compiler code base, so I can't figure out what's causing it in anything resembling a reasonable timef rame
<mikdusan>
i'd put money down that implementing #3133 will fix #2627
<pixelherodev>
Sure, but that's not exactly *less* complex
LargeEpsilon has quit [Ping timeout: 240 seconds]
jjido has joined #zig
<mikdusan>
andrewrk: `ir_build_const_import()` doesn't seem to be used anywhere. can I nuke it?
<andrewrk>
mikdusan, yes
<mikdusan>
ugh sorry my grep-fu failed. it's actually referenced
<pixelherodev>
Hmm, it's detecting the bit count correctly
<pixelherodev>
had it dump some debug values to files named after their structs, this is coming in handy
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<pixelherodev>
u48 apparently isn't registering as byte-aligned
<pixelherodev>
As a result, it thinks it's mis-aligned, and packs it
<pixelherodev>
I think I might be able to send a fix for this today
jjido has joined #zig
<pixelherodev>
Yeah, it's rounding up to u64, which has *two* negative effects resulting in the six bytes I was observing: two for the 48->64 change, plus four from the padding due to misalignment
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
waleee-cl has quit [Quit: Connection closed for inactivity]
<pixelherodev>
So, as a temporary workaround, avoiding non-native integer sizes seems to fix the problem - the real problem is that e.g. `[5]u8` is turned into a u64
<pixelherodev>
Splitting into two arrays, a `[4]` and a `[1]` in this example, "fixes" the problem
jjido has joined #zig
jjido has quit [Client Quit]
jjido has joined #zig
marijnfs has quit [Ping timeout: 245 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
riba has joined #zig
<riba>
hi :D
<andrewrk>
welcome back riba :)
<scientes>
pixelherodev, the real problem is that e.g. `[5]u8` is turned into a u64
<scientes>
wut
waleee-cl has joined #zig
<mq32>
scientes: sounds like a good optimization to me
Ichorio has joined #zig
<andrewrk>
idea: if the root source file has `pub const os = struct {...};` then std.os will do `usingnamespace root.os;`
<andrewrk>
this simple thing accomplishes 2 things: (1) you can fill in extra OS definitions that are not present in the zig standard library yet
<andrewrk>
(2) freestanding targets can supply implementations and then take advantage of std lib code or other packages which want to use os functions
<mq32>
+2
<dingenskirchen>
related, is there a summary of all the STL "magic" root pub const's available somwhere?
dingenskirchen has quit [Read error: Connection reset by peer]
dingenskirchen1 has joined #zig
dingenskirchen1 is now known as dingenskirchen
dingenskirchen has quit [Client Quit]
reductum has joined #zig
dingenskirchen has joined #zig
marijnfs_ has joined #zig
dingenskirchen has quit [Remote host closed the connection]
<andrewrk>
you can search for @import("root") in the std lib. there are only 6 hits
reductum has quit [Quit: WeeChat 2.6]
<pixelherodev>
"idea: if the root source file has `pub const os = struct {...};` then std.os will do `usingnamespace root.os;`" ... gah! So many interesting things I want to work on, so little time!
riba has quit [Ping timeout: 264 seconds]
<tgschultz>
2 sounds like a great idea.
<pixelherodev>
Compiler bug is higher priority for me though
<pixelherodev>
I already have an acceptable mod of the standard lib for my project, so fixing up upstream stdlib isn't high priority for me personally (though of course I would *love* to not have to maintain the port)
<pixelherodev>
A compiler bug that directly affects me to the point that I have a workaround in a very basic piece of code bothers me far more
<andrewrk>
pixelherodev, which issue is that?
<pixelherodev>
2627
<tgschultz>
You know, for magic names like this, and like those used by serialize/deserialize and fmt, it would be nice to somehow indicate what namespace they are intended to be consumbed by, in order to avoid conflicts and make the code easier to follow
<pixelherodev>
I've largely tracked down the issue, I just need to get more familiar with the code before I can fix it
<pixelherodev>
Well if that's not done by Sunday I'll probably have my own fix ready :)
<andrewrk>
that's handy
<andrewrk>
so much to do
<andrewrk>
I think to optimize for long term success of zig project I might need to focus my efforts on language stabilization
<pixelherodev>
I completely agree
<pixelherodev>
Stability is one of the most important properties a language can have
<andrewrk>
aarch64-linux builds are now available on ziglang.org/download
<scientes>
oh waoh
<scientes>
does that mean the C ABI went in?
<emekankurumeh[m]>
how do we get the build OS now?
<emekankurumeh[m]>
nevermind
<andrewrk>
std.Target.current.os
<andrewrk>
builtin.os still works
<emekankurumeh[m]>
i was importing "std" instead of "builtin"
<andrewrk>
scientes, I did enough with regards to C ABI to get zig to build
<andrewrk>
currently only behavior tests are enabled on CI testing but I'm running some tests to see what passes to increase coverage, and then make sure issues are open for what is disabled
<andrewrk>
back to the root file os thing - this starts to show a way that zig can provide support for operating systems via third party packages and for hobby OS's rather than having to upstream everything
<andrewrk>
because you could, for example, depend on a zig package and use it like this: `pub const os = @import("MyHobbyOS-std-os");`
<pixelherodev>
... I take back what I said about liking that idea. I'm now *obsessed* with that idea. That honestly sounds amazing.
<andrewrk>
so now you can make your hobby os and provide official zig std lib integrations
<andrewrk>
without having to get them merged into zig itself
<emekankurumeh[m]>
i did something like that in my hobby os
<pixelherodev>
Yours is pluto?
<emekankurumeh[m]>
you just need to add it as a library and it just "hooks" in
<pixelherodev>
...yeaaaah... i see what you mean :P
<emekankurumeh[m]>
but can your's even bootstrap? /s
<pixelherodev>
No, but it almost has SATA capability. Almost.
<pixelherodev>
:P
<emekankurumeh[m]>
that's ... rather impressive
<pixelherodev>
Definitely got the most advanced PCI support of any Zig kernel
<pixelherodev>
It can list *any* PCI device's device and vendor names
<pixelherodev>
*Any*.
<andrewrk>
pixelherodev, what arch are you targeting so far?
<pixelherodev>
x86, though I'm planning on shifting the focus to amd64 later
mahmudov has joined #zig
<pixelherodev>
I embedded the PCI IDs file used by lspci and wrote a simplistic parser
<andrewrk>
damn. I was going to ask you to write an xbox 360 controller driver for me if it was arm, so I could use it in clashos :P
<andrewrk>
that also involves USB, which I understand to be the stuff of nightmares
<pixelherodev>
Heh, sorry. Might be worth trying if I ever get an HDMI->VGA adapter; I'm stuck on a VGA monitor but I have a RPi 3 that someone gifted me :P
<pixelherodev>
I'm actually planning on getting USB support in soonish
<emekankurumeh[m]>
be careful, zig is good enough that your os could start the singularity...
<andrewrk>
ha, don't worry it's not a general purpose OS. just a bare metal video game
<pixelherodev>
I know, I saw; I was rather impressed honestly
<pixelherodev>
I'd heard bare metal on an RPi could be a pain due to the convoluted GPU loading
<andrewrk>
most of that work was markfirmware
<pixelherodev>
s/loading/bootloading
<andrewrk>
oh, the bootloading was my work
<pixelherodev>
The one place pluto will probably always have me beat: I have no plan of writing a bootloader; after I switch primary target to amd64, I plan on implementing the EFI stub so that it can be loaded by the firmware
<pixelherodev>
For now, QEMU's more than adequate
<pixelherodev>
s/QEMU's/QEMU is
<jaredmm>
Is the expectation that "all" of the Windows API will eventually be contained within a Windows namespace/package? I know that when including Windows.h, there are issues with the insanity of certain macros or defines.
<andrewrk>
jaredmm, I don't think the standard library will ever have fully complete windows API definitions, but it will have the most common ones. I foresee a third party package that does usingnamespace and then fills in the gaps.
<jaredmm>
Something like what raulgrell was doing with zig-window?
<jaredmm>
(win32_types may be a better example, but I'm not sure what was auto-generated vs manual).
<andrewrk>
ah I see. yes something like that
<emekankurumeh[m]>
windows header's are actually crazy, if you use @cImport you get mountains of errors from redefines depending on what you import
<andrewrk>
some of that is translate-c's fault. but yeah windows.h is not exactly the most straightforward c code
<jaredmm>
Yeah, even things that seem straightforward can given errors. #defines that reference other #defines. I wasn't sure if the direction was to improve the handling of C in Zig or if it should be handled with a reimplementation of the APIs in Zig.
<pixelherodev>
The hardest part of the kernel is that I insist on documenting all the values instead of just writing the hex values and forgetting what they mean :P
<pixelherodev>
Also, holy *hell* ACPI is *huge*
<pixelherodev>
And this is just revision *1.0*!
<pixelherodev>
I'm going to just implement on an as-needed basis for now ;P
<tgschultz>
There's a reason there haven't really been any viable new OSs since the 90s.
<pixelherodev>
I'm well aware, it's why I'm doing this for fun
<pixelherodev>
If I ever decide I want to do this for real (highly unlikely), I'd at the *least* wrap Linux kernel module
<pixelherodev>
s/module/modules/
<pixelherodev>
Graphics drivers alone are absolutely impossible otherwise
<tgschultz>
Yeah, I know, I'm just expressing my dissapointment in the state of technology
<pixelherodev>
I completely agree, but I also recognize it won't change
<andrewrk>
I have hope
<pixelherodev>
If the goal is a viable OS, it's actually not impossible, it just requires more than a few volunteers and the willingness to cut corners for the legitimately impossible drivers
<pixelherodev>
Hardware wise, backwards compatibility is given far too much important to go away any time soon
<tgschultz>
Less than that I think, if you specifically choose to only support one set of hardware. Of course it has to be so much of an improvement that people are willing to buy new hardware.
<pixelherodev>
True, but I was talking more generally usable
<emekankurumeh[m]>
is supposed to allow modifying the return value of a function that's immediately bound in an optional block?
<pixelherodev>
Seriously, two dozen people working full-time for a year even should be able to make a loooot of headway, especially on a well-managed project
<pixelherodev>
But that's not going to happen, because the funding doesn't exist, and for the most part volunteers need day jobs, and the number of qualified people is already pretty low
<andrewrk>
such an organization could start by targeting only very specific hardware at first
mahmudov has quit [Remote host closed the connection]
<pixelherodev>
True - honestly, in this channel alone we probably have enough people to do it, if we could all afford to spend time on it
<pixelherodev>
Plus, the requirement for specific hardware means that the full team would have to agree on what hardware to target, and that's another potential point of contention
<tgschultz>
There's the other problem: when discussing this sort of thing with others I find that people have rather vastly different ideas of what they want. You'd need the right people, all heading towards the same goal.
<pixelherodev>
Exactly
mahmudov has joined #zig
<pixelherodev>
A lot of software projects can produce acceptable results with a fractured team, but an OS requires cohesion
<pixelherodev>
The barriers of entry are simply too high without it
<pixelherodev>
Honestly, I'm going to focus on a lot of the building blocks in my kernel - individual, low-level drivers for x86/x64 - and I'll decide where to go from there
<mikdusan>
emekankurumeh[m]: #3527, I believe `zig build ...` takes more than one target. how does that work with passing additional args via `-- ...` ?
<andrewrk>
tgschultz, I do think if zig succeeds it will help make this goal in general more possible though, because there would be proliferation of zig packages *that would all work correctly in freestanding mode*
<pixelherodev>
^ that's one of the amazing benefits Zig offers
<pixelherodev>
AFAIK The *only* language where freestanding code is simple to write
<pixelherodev>
No weird config hacks, no custom cross-compilers, no loss of the standard library...
<tgschultz>
well, parts of the standard library obviously don't work
mahmudov has quit [Remote host closed the connection]
<pixelherodev>
True, but a ton of it does
<tgschultz>
at least today, sounds like andrew has a plan for that
<pixelherodev>
Most of it works actually
<pixelherodev>
Even I/O and FS stuff wouldn't be hard to integrate even *before* that plan is finished
<mq32>
pixelherodev: as you're writing a hobby OS: do you know Týndur?
<mq32>
i'll probably nag you a bit tomorrow, want to create some "OS" for i386 with zig as well
<mq32>
but not as in "general purpose OS" but more as in "pico-8-clone on bare x86 metal"
<pixelherodev>
Heh, that's actually hilarious - not your idea, but because my kernel was originally going to be a VM for a different FC, and likely still will be :)
<mq32>
"FC as in Fake Computer"?
<mq32>
:D
<mq32>
/Console
mahmudov has joined #zig
<mq32>
still have to make some concept on how that thing should run in the end (how the user controls it), but the hardware case is fixed already :D
<pixelherodev>
Fantasy Console, yeah
<mq32>
ah yeah. people do cool stuff with those... :)
<mq32>
pico-8 has a quite active demo scene
<emekankurumeh[m]>
mikdusan: i hadn't really thought about that, perhaps that would be up to the user?
<Snektron>
Why is a range in slice-syntax with two dots but a range in a switch with 3?
<Snektron>
Seems like a strange inconsistency
<pixelherodev>
Going to just ACPICA for now (though I'll leave the rest of the code as is so I can come back to it later)
<pixelherodev>
s/just/just use/
<mikdusan>
another way to look at it wrt intervals, the 10 is open: `[0..10]`, and `'a'...'z'` the z is closed; so 'a'..'z' would be inconsistent from that perspective
<Snektron>
oh yes, i didnt realize that
traviss has joined #zig
traviss has left #zig ["Leaving"]
traviss has joined #zig
diltsman has quit [Read error: Connection reset by peer]