<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]
<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 (it.next()) |buf| write(buf);
<andrewrk>
daurnimator, yeah, understood. the root breaking change is std.os.write is going to become an async function when std.io.mode == .evented
<marler8997_>
iterator might not work as well, since you'd have to track extra context between each call
<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. os.read 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 std.os.read 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 time...it'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>
daurnimator, indeed that was an inspiring demo :)
<andrewrk>
these 2 snippets I feel are nice and simple - the usage of std.net.TcpServer 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 EAGAIN...how 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 ziglang.org 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?
<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>
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.
<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