Recent searches
Search options
For my sins I'm continuing to play around with this coroutine library I wrote as part of my recent blog post. As I've been trying to write a proper test suite I've found that a surprising amount of things work when I expected them to break spectacularly. You definitely shouldn't use it over the upcoming coroutine feature that's currently available on nightly, but being able to play around with an API that resembles python generators is proving to be a lot of fun 
@sminez see, when you say things like this, I feel a lot more justified in continuing to poke about "crates.io when?"
@sminez maybe just needs an auto-deprecation when proper coroutines reach stability.
@sminez@hachyderm.io@oac what have we said previously about you being an enabler? 
I need to test things properly (and see if someone who understands validating the sound-ness of unsafe APIs can double check what I'm doing) but beyond that I think I'm ending up with a slightly different API from what will be landing with the coroutine feature. So direct compatibility probably isn't going to be possible 
OK, I'm getting close to caving and publishing https://github.com/sminez/crimes as an actual crate if I can round out the documentation and test suite...
Things that have changed my mind:
1. https://docs.rs/genawaiter/latest/genawaiter/ is already a thing, using a somewhat similar approach? But it looks like its abandoned and makes use of proc macros. Either way, it looks like there's prior art in this space and I _think_ what I've got is a little neater? Not sure about performance yet though.
2. The more I add QOL methods and helpers to this, the more it feels like an actual nice API(!)
3. Now I _really_ want to use it inside of ad and see what sorts of mischief I can get up to 
All that said, I think I'll write a follow up to https://www.sminez.dev/socrates-is-a-state-machine/ first to try and encourage people to take a look at the design and tear me a new one when they find issues in it.
If that goes reasonably well, then please direct your "why have you done this?!" complaints to @oac as he's the one encouraging me
@fasterthanlime not sure if you pay attention to mentions, but given that this was inspired by your recent article I'd like to give you credit (/ hold you partly responsible depending on your point of view!)
I'd love to read the follow up blog post explaining how you got away with it (covering up your crimes with a nice API)
@oac a lot of it has been ripping out unnecessary crimes if I'm honest. Packaging everything up in a single struct gets rid of a lot of the sharp edges and the main remaining issue is the fact that you really can't treat the async function you're writing as a normal Future. That said, the failure mode there is identical to what happens if you try to await a tokio specific future (like tokio::io::sleep) outside of the tokio runtime (explicit panic). So maybe even that isn't too bad?
I need to run things under a debugger to double check how it all plays out under the hood and do some better testing, but so far it all seems surprisingly reasonable now
@sminez 9p mention detected 
@kmg Indeed! I wrote a 9p library to provide an acme-style filesystem interface for my text editor (ad). The current impl uses blocking IO and spawns a thread per client connection and I wanted to move over to using async, but I _didn't_ want to drop support for the synchronous API.
So...one rather deep rabbit hole later I've got a coroutine library, a sans-io version of the 9p library in the works and I'm just about ready to actually start wiring up async in ad
@sminez @oac @fasterthanlime HEL YEAH SOMEBODY FINALLY DID IT!!!