async method builders are so poorly documented i feel like i'm just guessing how this stuff works
async method builders are so poorly documented i feel like i'm just guessing how this stuff works
PAh my mistake it was Cyrus, not Fred
Pgot my language designers mixed up
Phate it when that happens
P
Kunitask ironically is a good place to look to learn them lol, thats where i started. my velvet.async thing maybe also depending
GitHub
Contribute to Khitiara/Velvet.Async development by creating an account on GitHub.
Mdankedanke
Mthe fact its actually trying to implement async methods and not iterators is a bit confusing lol
Klol
Kalmost like thats what its for
Mso AwaitUnsafeOnCompleted is basically MoveNext
Ksorta, its ContinueWith(MoveNext)
Kbasically
MGist
i get paid for this shit. GitHub Gist: instantly share code, notes, and snippets.
Mthe
return default!; at the bottom is mandatory because if you use a generic AsyncMethodBuilder it always assumes its a task with a resultMwait the asyncstatemachine it generates is still a reference type 
Mi thought that was the whole point
Munless. it's a c# 10 feature.
KI think it is still a reference type because it has to work across async boundaries
Mbut there are no async boundaries because nothing is actually async because its just a generator
Kand the stack gets destroyed a whole lot
Mcould do that with a ref value type?
Mi think?
Kyeah but this is async method builder
Kthe whole infrastructure for it is built around what async needs
Kwhich is to say the state machine needs to be on the heap
Kin later c# you might get struct ones but then you end up with IAsyncStateMachineBox<T>
Mhumbug humbug
Qhey everyone, is there anything available on using silk.net within a MAUI application?
Pnope
Qthanks
Qi could only find somebody asking about this some time ago
Pyou can use Silk.NET on .NET 6+ Android and iOS, but not MAUI today
QI take it that also includes regular WPF?
Qah perfect thats good to hear
Qreally loving it so far and would like to also make a port for mobile soon
Pyeah no support for that yet, it’s all technically possible (even MAUI) but really we want to publish a package that makes it easy, we don’t want our users writing thousands of lines just to bridge their UI framework and Silk.NET
Qi was figuring perhaps the GL context could be created from an existing control in there
Qyeah thats very understandable
Qim already grateful theres an option for android
Pon WinForms yes because they make it dead easy, WPF is so much more complicated because you’re trying to make a GL context within a D3D9 window
Qahh.....
Pwhich is possible! It is just extremely difficult
Qyeah they kept telling me to use OpenTK https://github.com/opentk/GLWpfControl
GitHub
A fast native control for OpenTK 4.x + 3.x on WPF. - GitHub - opentk/GLWpfControl: A fast native control for OpenTK 4.x + 3.x on WPF.
Qbut i like silk.net
Qthe alternative is i find a way to host the current silk.net window within wpf somehow?
Qbut it's like you said, all very hacky
Qand i'd prefer MAUI then anyways
Pyeah so that one (as of recently) does basically what we’d be doing, in that it uses GL_NV_dx_interop.
Pbut we want to take time to make it all generic so we can mop up WinForms, WPF, MAUI, and Avalonia all at once
Qam i wrong to assume MAUI would be a great base for general cross-platform stuff?
