Discussion
I have pondered about stuff, and concluded that things are difficult.
I can't really make the roto bindings dependent on a trait, because the Roto-side Request.new() needs a concrete type.
So the only viable path is to have MeansOfProduction::new() have a library argument too.
...unless I move those traits to the other crate, but then I have circular dependency, which ain't gonna fly either.
Oooor... I wrap http::Request in a thin newtype, and impl the trait for that, because the newtype is local. I can do that.
...except I still need to impl roto_library() for iocaine-powder::Dom, in a third crate, because the roto library requires constructing the type I wrapped in the third crate.
So, uhhh... yeah. This is not good this way.
I need the http types to be implementable by third party crates.
This is gonna be Difficult™.
Okay, gonna try a new approach.
HAH! Progress. BIG progress. I might be able to get rid of the whole channel thing now!
I love committing type crimes. Half the fun of using a strongly typed language is doing type crimes.
Okay, halfway there. The SexDungeon trait is now http impl agnostic, by virtue of being a generic trait over R: Top.
Now to make MeansOfProduction generic over R: Top too!
Yay! Got rid of channels.
8 files changed, 84 insertions(+), 253 deletions(-)
This is the kind of development I like. Same features with less code! And I ain't even done yet.
Now, there are some ugly parts too, like:
let mut mop = MeansOfProduction::new(server.script())?;
<MeansOfProduction<dom::Trainee> as SexDungeon<dom::Trainee>>::run_tests(&mut mop)
.map_err(|_| {
miette::miette!("Tests for http-server `{}` failed.", server.name())
})?;
This is a bit bullshit.
Luckily, that's an older artifact! I don't actually need that ugly hint!
let mut mop: MeansOfProduction<dom::Trainee> =
MeansOfProduction::new(server.script())?;
mop.run_tests().map_err(|_| {
miette::miette!("Tests for http-server `{}` failed.", server.name())
})?;
Still need to explicitly specify the type, but this is far less ugly.
Nice, nice, progress is being made.
I guess I should elaborate on that, LOL!
So I currently have http::Request wrapped in a thin layer that implements sex_dungeon::top::Top (though, I'm going to rename the module back to dom, so it'll be sex_dungeon::dom::Top), and I'm >< this close to having a generic impl Roleplay for Top, which will allow me to move the http::Request wrapper to a separate crate.
Ooof. Well. I might not be able to have a generic implementation for the trait, due to Roto limitations. Hmm hmm.
Unleeess... I stop using the library! macro, and construct the Library by hand. That could work.
...and the http wrapping is now in a separate crate, demonstrating that it can be implemented that way!
Whee!
And with dropping the channel stuff, iocaine-powder no longer depends on tokio either!
Currently nothing depends on tokio. Hehehe.
A'ight. Now I need to do the same for http::Request, then I can re-implement Bruce (the HTTP server), after which I can start working on the new Nam-Shub of Enki.
It's within the realm of possibilities that I get to implement three ifs in a trenchcoat by the end of the weekend.
Goddammit. Obviously, I can't have impl<T: Bottom> Roleplay for T and impl<T: Top> Roleplay for T at the same time.
❯ cargo run -q -- runtime output -m GET -p /foo -H host=example.com
Sub(
Response {
status: 200,
version: HTTP/1.1,
headers: {
"x-ok": "default",
},
body: (),
},
)
No body yet, and some of the things aren't wired up yet, but we're getting there.
I have a small dog looking at me with innocent puppy eyes, begging for a nap. I'm unable to resist, so will continue the work after a well deserved break.
But before that! I'll have to do some benchmarks, because I'm more sure than I want to be that I'm cloning too much.
First benchmarks: The trivial Roto test suite runs at 31.5µs median. That's not a great metric, but was the easiest to implement.
The decide() benchmark is 328ns/request. That I like. But I don't remember what the iocaine3 trivial benchmark was like, so... I guess I'll run that too.
Huh. Last time I measured, QMK was at 993ns/request for decide(). So the current speed is better, but also the current script is also much simpler.
I think I'll need a more fair comparison.
Next: try the same test, but with Request being a dummy.
iocaine 4 + Dummy no-op decide: ~42ns median.
Now that's much better, and it validates that the wrapping is the bottleneck.
Bah! Back to the drawing board! I can't implement a trait one crate A for a type in crate B, in crate C, becaue either A or B has to be in the same crate.
So I need to
impl<T> Top for http::Request<T>iniocaine-powder.