dddddd has quit [Remote host closed the connection]
marmotini_ has joined #zig
<fengb>
Is there a quick way to have Zig output what functions are referenced?
marmotini_ has quit [Ping timeout: 268 seconds]
<daurnimator>
andrewrk: reviewing the callconv change commit: looks like `_DllMainCRTStartup` got wrapped differently..... was that a manual thing you did or is fmt missing the trailing comma?
<daurnimator>
andrewrk: I also saw you got rid of the extra LICENSE file... connectFree issue solved?
<scientes>
<daurnimator> scientes: you've always been able to execute on godbolt
<scientes>
daurnimator, this is not true
<daurnimator>
scientes: since at least 2017 I think?
<hryx>
Oh, sorry. I made a change to the std json parser which addressed some of the cases in #2379, but I missed a few cases. It had to do with disallowing "overlong" encoding of some characters, which I had slightly misunderstood
<hryx>
Just giving you TMI since you were helping me with the subject last night :)
<hryx>
(or yesterday, depending on your time zone)
ltriant has quit [Quit: leaving]
_whitelogger has joined #zig
schme245 has joined #zig
schme245 has quit [Ping timeout: 258 seconds]
SimonNa has quit [Remote host closed the connection]
doublex_ has joined #zig
doublex__ has quit [Ping timeout: 260 seconds]
schme245 has joined #zig
neceve has joined #zig
THFKA4 has quit [Ping timeout: 252 seconds]
<scientes>
hryx, did you keep the state-machine model?
marmotini_ has quit [Read error: Connection reset by peer]
<scientes>
that SIMD one is just for kicks, doesn't make any sense until it has been ported to use generic SIMD
<hryx>
all I gotta say is, there be some smartypantses out there making computers go fast
<scientes>
there is a intellectual draw to this sort of thing too
<hryx>
def! I'm just being silly
<scientes>
the avx-512-VBMI instructions could probably make it even much faster still
dddddd has joined #zig
<scientes>
with vpermb
return0e_ has joined #zig
traviss has quit [Read error: Connection reset by peer]
ur5us has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
neceve has quit [Ping timeout: 258 seconds]
neceve has joined #zig
marmotini_ has joined #zig
marmotini_ has quit [Ping timeout: 260 seconds]
neceve has quit [Ping timeout: 265 seconds]
neceve has joined #zig
marmotini_ has joined #zig
marmotini_ has quit [Ping timeout: 268 seconds]
schme245 has quit [Remote host closed the connection]
schme245 has joined #zig
vexu has joined #zig
schme245 has quit [Remote host closed the connection]
schme245 has joined #zig
return0__ has joined #zig
return0e has quit [Ping timeout: 268 seconds]
phillyiscool has joined #zig
<phillyiscool>
Hi, new to Zig. What is the best way to pass an array of structs to a function. In C you would need to add a length parameter. I thought maybe Zig's compile time could infer the length but it doesn't appear to
phillyiscool has quit [Remote host closed the connection]
dimenus has joined #zig
GrooveStomp has joined #zig
phillyiscool has joined #zig
<phillyiscool>
So it seems like you can put slices on a struct in Zig. Is this automatically turned into a linked list?
<phillyiscool>
I guess in my brain I keep trying to translate what I write in Zig to C. I was expecting to have to build my own linked list structures, but it appears I might never (or rarely) need to do so?
<mq32>
you rarely need to
<mq32>
but no, Zig does nothing automatically
<mq32>
if you store a slice in a struct, you just store a pointer+len
<phillyiscool>
Right
<phillyiscool>
I usually use linked lists in C, but I guess I could have been doing it this way instead
<mq32>
there are reasons for linked lists and reasons for arrays
<mq32>
both applies in zig
<phillyiscool>
Yeah of course
<phillyiscool>
From reading the docs, it seems that Zig chooses whether to pass a struct by value or reference.
<phillyiscool>
I guess this means that you don't need to use pointers nearly as often in Zig?
<mq32>
yeah
<phillyiscool>
That's nice
<phillyiscool>
Last question, is it practical to write a library for use from C using Zig?
<phillyiscool>
I played around with `build-lib` but the header file doesn't contain any of the functions. I can worry about learning this later, just wondering if C consumers is an intended use-case
dimenus|work has joined #zig
dimenus has quit [Killed (moon.freenode.net (Nickname regained by services))]
dimenus|work is now known as dimenus
Guest49625 has joined #zig
<Snektron>
phillyiscool, don't forget to use `export` for functions you want to use in C
<phillyiscool>
"One of the primary use cases for Zig is exporting a library with the C ABI for other programming languages to call into."
<phillyiscool>
🤦♂️ I missed that
<phillyiscool>
Thanks Snektron!
<Snektron>
mq32, there aren't many reasons for a linked list in my experience
<Snektron>
arrays are much faster
<mq32>
very dynamic data structures are an example
<mq32>
like "you don't delete data, but only move it from one list to another"
<Snektron>
I think i used std::list in c++ only once, that was when implementing some algorithm which heavily used insertion and deletion
<Snektron>
though it would probably still be faster with a vector
<mq32>
it depends, it's still helpful to store your nodes in a continuous storage
<Snektron>
better would probably be a B-tree
<phillyiscool>
Are `export` and `pub` mutually exclusive it seems?
<Snektron>
`pub export` seems to work
<phillyiscool>
Ah yeah, i see that now
<phillyiscool>
Is there a strcmp equivalent?
<phillyiscool>
I should say, how do you compare strings?
<mq32>
std.mem.eql(u8, strA, "hello")
<phillyiscool>
interesting
return0e_ has quit [Remote host closed the connection]
frmdstryr has joined #zig
return0e has joined #zig
redj has quit [Read error: Connection reset by peer]
<fengb>
mq32: I thought a bit about returning generators. We still need @resultLocation, and the function somehow needs to only have one argument that’s the *YieldType
redj has joined #zig
<fengb>
That way the createGen can return a generic that’s both the async frame and the data
phillyiscool has quit [Remote host closed the connection]
<fengb>
So for initializing generator function state, we’ll also need closures or something OO based (@fieldParentPtr, mixin, etc)
traviss has joined #zig
marmotini_ has joined #zig
<Snektron>
fengb:
<Snektron>
why do you need @resultLocation for returning frames?
<fengb>
It's more that the async function needs a pointer to dump its yielded value
<Snektron>
ah
marmotini_ has quit [Ping timeout: 268 seconds]
<fengb>
And I need to return both: the frame to keep it alive, and the data so it can yield stuff
<fengb>
I actually don't know if you can copy the async frame but I guess there should be nothing wrong with it
<mq32>
as long as you don't resume the old pointer… ?
<Snektron>
Sounds like it would be better to have some language primitive for this
<mq32>
you can probably work around this by using a thread_local, but that sounds unclean
<fengb>
Snektron: I'm not disagreeing. I just want to see how far I can take userland generators. It seems to work decently once you get used to the pattern
<fengb>
There's been another try at generators and it's quite complicated. I think it ultimately used @fieldParentPtr to solve all of these problems
waleee-cl has joined #zig
<GrooveStomp>
Is it possible to do a C-like forward declaration of a struct in Zig?
<mq32>
GrooveStomp: nope, as it is not required in zig
<mq32>
just declare where you like and use where you like
<GrooveStomp>
I've essentially built a tangled mess of dependencies. :-)
<mq32>
that should not hinder zig from beeing free of forward declarations :D
<fengb>
Zig resolves types nonlinearly so it should just work
<fengb>
Unless there’s a really bad cycle, but the compiler should warn you about that
<GrooveStomp>
I'm still *very* new to Zig, so a lot of what I'm writing now is very exploration based. I'm splitting up my code into a base package that does platform-specific imports, not dissimilar from how the std os package works in Zig. The problem is... I have a dependency cycle where conceptually I think this specific piece of code should live in the os-specific file; but it needs to update state at the non-platform-specific interface layer. Obviously I need
<GrooveStomp>
to think harder about this issue; but something like a forward declaration would let me move past it for the time being. :-)
<GrooveStomp>
Alright, family is waking up. Time to start the day.
GrooveStomp has quit [Quit: Leaving]
<fengb>
Great, if I run every file test separately, everything works, but if I run it against std.zig, the compiler segfaults :(
<fengb>
OH WAIT
<fengb>
I'm dumb :P
<scientes>
how do i execute my godbolt programs?
<scientes>
nvm
schme245 has quit [Remote host closed the connection]
phillyiscool has joined #zig
<phillyiscool>
Does the return type `type` always refer to an argument type?
<mq32>
no
<mq32>
it refers to any type
<mq32>
fn IReturnI32() type { return i32; }
<phillyiscool>
Ah ok
<phillyiscool>
So the return struct pattern is not just for generics
<Snektron>
not neccesarily
<Snektron>
type is just a type
<mq32>
i just had a stupid idea…
<Snektron>
`const ty: type = type; const int32: ty = i32;`
<phillyiscool>
What does this error mean?
<phillyiscool>
error: unable to evaluate constant expression
<phillyiscool>
Nevermind, I'm jumping too far ahead in my learning :)
<fengb>
I've been seeing that whenever something that's runtime known is trying to be shoved into comptime
phillyiscool has quit [Remote host closed the connection]
<Snektron>
how do these bugs happen in the first place
<Snektron>
Seems like such a weird place to have a bug
<andrewrk>
changing requirements
<andrewrk>
stage1 is continually having its assumptions yanked out from underneath it as the language evolves
<Snektron>
you'd expect the sizeof to require the type to be analyzed, which in turn would make sure that all fields have unique names
<Snektron>
yeah i suppose thats not good for stability
<fengb>
`[x] The compiler crashes if you look at it funny`
<fengb>
Mangle the semantics completely, do a rain dance, and the compiler crashes!
<Snektron>
hey, thats like my uni assignment on compilers last year
<andrewrk>
only when the language stops changing will there stop being new bugs introduced
<andrewrk>
which is a good reason to stabilize the language as much as possible before writing the self hosted compiler
<fengb>
Oh I'm not complaining about the bug. I find it funny that Vexu stumbled upon that bug at all
<schme245>
is there any difference in memory layout of having an array of u8, vs an array of structs with 3 u8 fields?
<schme245>
(I'm coming from a Java background so this is somewhat new terrain for me)
<fengb>
Struct memory layout is undefined so yes they're different
<fengb>
Packed structs have well defined layout so `[3]u8` should be the same as `packed struct { u8, u8, u8 }`
<schme245>
and a regular struct _can_ be the same but is not _guaranteed_ to be the same?
<fengb>
It's almost definitely not the same, due to additional hidden safety fields
<fengb>
Those are removed only on release-safe or release-fast
mahmudov has quit [Ping timeout: 240 seconds]
<schme245>
I see, thanks fengb
<fengb>
Hmm... so there's no safety or padding at the moment. So you "might" be able to get away with it for now... but you really shouldn't rely on it :P
return0e has quit [Remote host closed the connection]
<fengb>
If you want memory guarantees, use packed or extern structs (which are C ABI compatible)
<andrewrk>
hryx, happy to see you contributing again :)
<hryx>
andrewrk: happy to be back :]
<schme245>
gotcha, I'm trying to understand what the performance implications of putting stuff in structs is, and I guess the short answer is that you don't need to worry too much, especially if you are using packed structs
<fengb>
Structs fields are "free" since they're just offsets in memory. The only thing that might impact performance would be size and alignment
<Snektron>
Alright so i had some free time and some more coming up, so i started working on some Vulkan spec to Zig generator
<Snektron>
I made a nice xml parser that is adequate for parsing the spec
<Snektron>
However i already ran into a problem
<fengb>
Did you use regex? 🙃
<Snektron>
Of course not
<Snektron>
i did use recursion tho, thats like the Zig equivalent of using regex
<Snektron>
Anyway,
<andrewrk>
lol
<scientes>
Snektron, except that regex does not have recursion
<scientes>
its a state machine
<scientes>
that is the whole point
<Snektron>
Vulkan imports some foreign types, mainly with extensions providing platform support
* scientes
reads up and notice that xml was being talked about, which cannot be parsed with regex
<Snektron>
But these types are not opaque, instead Vulkan depends on platform headers to provide some times
<Snektron>
types*
<Snektron>
I'm wondering what the best way would be to translate those to Zig?
<andrewrk>
Snektron, so the canonical definition of the types are not in the xml, but in .h files? where do the .h files come from?
* scientes
needs to read more context
<Snektron>
andrewrk, they are supposed to be proved by the implementor i think
<Snektron>
Vulkan provides guards to enable platform-related extensions
<Snektron>
Those also include the relevant headers
<Snektron>
But they are not provided by Vulkan
<andrewrk>
the implementor of what?
<Snektron>
imo a design mistake
<andrewrk>
is there an ABI to match or no?
<Snektron>
The developer wanting to use Vulkan
_Vi has joined #zig
<Snektron>
andrewrk, yes, the types are passed to Vulkan functions which are imported from some library
<Snektron>
(usually the graphics driver)
<andrewrk>
oh this is the part that interacts with x or wayland or windows API
<Snektron>
yeah
<Snektron>
I think they should have enforced the types to be pointers so developers have a better time generating bindings
<Snektron>
but they didn't
<Snektron>
I think they are mostly just typedefs to integers or pointers, in fact in the Vulkan spec repository there are some headers providing substitute typedefs
<Snektron>
but i'm not quite sure if those are correct
<andrewrk>
the first thing I would try is to hard-code the answer for all the supported targets. it's annoying but it would make things "just work" for users of the package
<Snektron>
I can import some of the platform related types from the standard library yeah, the windows ones for example
<Snektron>
for the others i might just need to use the subtitute
<Snektron>
Another possibility was importing the types from @import("root") and specify users to define platform dependent types there if supporting those is desired
<Snektron>
But im not really a fan of that
<Snektron>
I guess ripping types from the headers isn't too different from what the standard library does at the moment, but i feel like OS headers might be a little more stable than library headers
<andrewrk>
yeah this is a rather annoying problem
<Snektron>
Especially stuff like google games platform
<andrewrk>
because the person depending on your vulkan package probably also depends on (directly or indirectly) the windowing library API separately, and you need these to be the same versions
<Snektron>
To make matters worse, some types are actually hidden behind an NDA
<Snektron>
I'd rather keep the Vulkan stuff seperated from anything like that and instead add something to glue them together
<andrewrk>
this way the person depending on your package is using it for the windowing library and does not separately depend on a windowing library
<andrewrk>
that makes sense too
<Snektron>
that would also allow the development of OpenGL bindings
<dimenus>
Snektron: it possible to only have one command buffer for multiple swap chain images of the command itself is completely static?
<dimenus>
or is it always advised to not share between swap chain images?
schme245 has quit [Remote host closed the connection]
decentpenguin has joined #zig
<Snektron>
dimensus, thats definitely possible
<Snektron>
although, i do think you have to bind that image if i remember correctly
<Snektron>
yeah i think that limits you
<Snektron>
But i think quite often you're rebuilding that commandbuffer almost every frame anyway
<Snektron>
unless its just some intermediary stage
<Snektron>
but then you're probably rendering to a single image and not a swap chain
<Snektron>
oh wait, by reviewing some old code i see that the image target is specified when the command buffer is submitted to the graphics queue
schme245 has joined #zig
<Snektron>
in which case its perfectly find to reuse that command buffer
<Snektron>
fine*
<Snektron>
On the other hand, i did use some hack to avoid creating a framebuffer
schme245 has quit [Remote host closed the connection]
frmdstryr has quit [Ping timeout: 268 seconds]
vexu has quit [Quit: WeeChat 2.7]
SimonNa has joined #zig
frmdstryr has joined #zig
<fengb>
Github should have a separate "fixed" status for issues
decentpenguin has quit [Quit: decentpenguin]
<fengb>
andrewrk: how will threads work with async? Will there be new primitives for stuff like Thread.spawnAsync(func)?
<fengb>
Oh wait, I see loop can be created with threadpools
<fengb>
Neat, it automatically starts with core number of threads
mahmudov has quit [Read error: No route to host]
<frmdstryr>
Is there a gdb that can evaluate zig expressions?
protty has joined #zig
mahmudov has joined #zig
<protty>
hey, question about string formatting through std.fmt: how would you print a []const u8 with padded spaces right aligned until it reaches 50 chars? have tried doing `{: >50}` but that doesnt look to be it
<andrewrk>
fengb, have a look as well at startCpuBoundOperation
marmotini_ has joined #zig
return0e has joined #zig
return0e has quit [Client Quit]
marmotini_ has quit [Ping timeout: 258 seconds]
marmotini_ has joined #zig
vexu has joined #zig
_Vi has quit [Ping timeout: 245 seconds]
marmotini_ has quit [Remote host closed the connection]
ur5us has joined #zig
GrooveStomp has joined #zig
protty has quit [Remote host closed the connection]
<dimenus>
andrewrk: below 20 PRs!
<andrewrk>
😅
<dimenus>
vulkan is so silly when you're only submitting a couple draw cmds
<dimenus>
5k FPS on an integrated GPU
<dimenus>
(reimplementing learnopengl.com's breakout in Zig/Vulkan)
GrooveStomp has quit [Remote host closed the connection]
riba has joined #zig
Astronothing has joined #zig
riba has quit [Ping timeout: 258 seconds]
<frmdstryr>
Is there any way to make a variable volatile?
<frmdstryr>
I'm trying to increment a counter from a SysTick_IRQ and it just stays at 0
<frmdstryr>
the IRQ is firing because it toggles the LED and I can break and step through it
<andrewrk>
I added --release-fast and it looks to me that _sys_tick is updated 1000 times with the correct values
<andrewrk>
if I remove volatile, then the entire thing turns into label: nop; jmp label;
schme245 has joined #zig
<andrewrk>
whew. alright. oldest pull request that is awaiting review is less than 1 day old
<frmdstryr>
Hmm.. i don't get why it doesn't do anything on the acutal board though, will keep digging
waleee-cl has quit [Quit: Connection closed for inactivity]
<SyrupThinker>
Is there any particular reason that the code model option hasn't been exposed yet except for "hasn't been done yet"? If not I'd like to add that
<andrewrk>
I would love a feature of github where every user had exactly 1 vote and they could put it on a particular issue
<andrewrk>
the feature would default to making the newest issue you open be your voted issue, and if it gets closed, your vote switches to the freshest issue you opened or previously had your vote on
<andrewrk>
but you could switch your vote at any time explicitly to indicate what is blocking you
<andrewrk>
SyrupThinker, code model, you mean PIC ?
<andrewrk>
I took great care to make the default correct, but we also have -fPIC and -fno-PIC
<SyrupThinker>
While related its a different option
<SyrupThinker>
I have symbols that are placed above 0x7effffff, but the default code model for x86_64 doesn't allow that
vexu has quit [Quit: WeeChat 2.7]
<andrewrk>
you're talking about a linker script?
<SyrupThinker>
Well, yes, a linker script, is involved, but the codegen needs to account for it due to the changed addressing
<andrewrk>
this is something I will have to learn more about before having a good answer
<fengb>
andrewrk: would it be helpful to have an allocator just for testing? FBA that reuses the buffer at the beginning of every test
<andrewrk>
fengb, I believe that would be the same question as, should the test runner reset std.debug.global_allocator between test runs
<fengb>
Sure, but migrate it to somewhere that it's more obviously just for testing
<andrewrk>
std.testing.allocator
<andrewrk>
that seems pretty nice
<andrewrk>
it an even give a @compileError if !builtin.is_test. "nice try, slacker!!"
<andrewrk>
the only reason I can think of not to do this, is if we want to support the use case of providing your own test runner
<fengb>
lol
<andrewrk>
then it gives another mandatory chore a custom test runner would have to do, and now the use case probably wants to also override the allocator used for testing
<andrewrk>
which is maybe a good thing
<andrewrk>
anyway yeah I'd support a std.testing.allocator. especially if it went ahead and deleted std.debug.global_allocator
<fengb>
👍
<fengb>
I figured this would be better than people reaching for the page_allocator as a stopgap
<andrewrk>
good point
<andrewrk>
here's another question though- should it detect leaks? e.g. when the debug general purpose allocator is done, should that be the testing allocator? and the test runner would call detectLeaks() after every test
<SyrupThinker>
andrewrk: Thanks, I'll just work on it so that I can use it and make a pull request for when you have one
<fengb>
I tend to use a FBA and never free because it's slightly easier inside the testing context
<andrewrk>
fengb, how about std.testing.arena and std.testing.allocator
<andrewrk>
the latter will fail the test if leaks are detected
<fengb>
Sounds good
<fengb>
I can be pretty lazy so I figure others will be too :P
<andrewrk>
yes, and better to have tests with an arena than no tests
<frmdstryr>
So instead of updating the var _sys_tick (at addess 0x24000010) it's updating address 0x24000014
<frmdstryr>
I can't get gdb to print sys_tick it just says optimized out
<frmdstryr>
it is loading and storing, just not the _sys_tick var
dimenus has quit [Ping timeout: 260 seconds]
ltriant has joined #zig
<andrewrk>
maybe you can look at the disassembly
<andrewrk>
which architecture is this?
<frmdstryr>
If i hardcode the address it works
<frmdstryr>
armv7-em
<frmdstryr>
the stm32h743
<frmdstryr>
It seems like the &_sys_tick is taking up stack space or something?
<andrewrk>
frmdstryr, I hope this is not a bug that incorrectly caused there to be 2 _sys_tick globals
<frmdstryr>
when i printed 0x2400010 and 0x24000014 they gdb was showing _sys_tick for both
<andrewrk>
uh oh
<andrewrk>
frmdstryr, try doing the @ptrCast with volatile inline where you need it as a sanity check
<daurnimator>
Snektron: I use linked lists all the time: its the only real way to allow appending to lists without allocations (assuming you already have the object)
<andrewrk>
does the code sometimes access 0x24000010 and sometimes access 0x24000014?
<frmdstryr>
getSysTick() is always returning 0 in time.zig
<frmdstryr>
meaning it's using _sys_tick
<andrewrk>
I believe volatile is a red herring by the way
<andrewrk>
there's no reason for this to be volatile
<andrewrk>
that's just complicating your debugging process
<frmdstryr>
How does the compiler know to not optimize the sleep delay loop then?
<andrewrk>
does it work in debug mode?
<frmdstryr>
it is in debug mode
<andrewrk>
well first of all there are no optimizations on then
<andrewrk>
but also it can and should optimize the sleep delay loop
<frmdstryr>
the code has no idea that the ISR is firing
<andrewrk>
the optimizer will not change the meaning of data; if you have a variable x=0 adn then increment it 100 times, and read it, you will get 100. maybe the memory access gets dropped, but you will get 100
<andrewrk>
oh, you have a data race then
<andrewrk>
you need atomics
<andrewrk>
@atomicRmw to update the number, @atomicLoad to read it
<andrewrk>
volatile is 100% a red herring here. volatile is for mmio
<frmdstryr>
It's a single core, idk how atomics matter
<frmdstryr>
but i'll try it
<andrewrk>
it matters because otherwise you can load part of a number, and then the interrupt modifies the data, and then load the rest of the number
<andrewrk>
atomics are required when there is more than 1 thread (an interrupt counts)
<andrewrk>
the data race is for sure a problem. but I suspect there may be still another issue
<andrewrk>
why not have startu.zig @import("main.zig") and delete the addObject from your build script?
<andrewrk>
oh, this explains everything
<frmdstryr>
yea, trying that now, was just using what was there from the other project
<andrewrk>
you ported this from C right?
<andrewrk>
in C the global variable is probably declared in a .h file, and so it is exported from one of the object files and referenced as an external symbol in another
<frmdstryr>
yes
<andrewrk>
you can do that in zig, you would need to export the global explicitly though
<andrewrk>
but I would recommend instead to have startup.zig @import("main.zig") because avoiding needless exported symbols makes for better codegen
<andrewrk>
if you want multiple object files to share state, you gotta explicitly export the state you want to share
<frmdstryr>
it's working now
<andrewrk>
and then use extern in the one importing it
<andrewrk>
that's true in C too, it's just easy to do on accident
<andrewrk>
nice
<frmdstryr>
sweet
<frmdstryr>
thanks!
<andrewrk>
np glad we got it sorted out
<andrewrk>
I should stop assuming it's a compiler bug before thinking of other things :)
<tdeo>
are there any examples of std.event.Loop other than the chat server livestream? i'm trying to play around with it to write a pure zig wayland server
<tdeo>
not sure why in the livestream beginOneEvent() is called once and that's it
<andrewrk>
tdeo, not really, that's an area of the std lib I'm hoping to improve soon - fengb and I are doing some premilimary work on it
<andrewrk>
beginOneEvent has to do with reference counting how many async things are in progress, so the loop doesn't shut down while, e.g. waiting for an http request to respond
<andrewrk>
the event loop is supposed to do it entirely for you, so putting it in the chat server was a workaround for a bug
<tdeo>
ah
<fengb>
andrewrk: I encountered 2 major blocking bugs. Still have to reduce the second one
<fengb>
I also don’t understood how moving to iterators solves outstreams >_>
<andrewrk>
ah
<andrewrk>
fengb, the main issue is that async function pointer calls cause problems with zig figuring out how big async function frames are
<andrewrk>
there are many places in std where the callback function supplied to std.fmt.format ultimately calls std.os.write
<andrewrk>
so that bubbled all the way up to make std.fmt.format async, which is just unnecessary and complicated
<andrewrk>
making it into an iterator (more importantly, getting rid of the callback) makes it the caller's problem whether or not they are async. std.fmt.format can stop caring
<fengb>
Hmm well I hope making format always async doesn’t hurt semantics >_>
<andrewrk>
well if we do the iterator thing then it will be always *not async*
<fengb>
Does that mean we would remove the print function too?
<andrewrk>
oh you mean with the generator thing
<fengb>
Yeah
<andrewrk>
you're not making any runtime-known function pointer calls. that's the important thing
<andrewrk>
so zig can figure out the stack sizes of stuff
<fengb>
Ah okay
<fengb>
Yeah doing the comptime recursion seems so magical
<andrewrk>
another thing that could solve this for now would be making the callback function comptime. there is 1 callsite that wants it to be runtime, but maybe that could be solved separately
<andrewrk>
that might actually be something I do because I'm tired of not working on async I/O in std