It's me again. I am trying to wrap Client[F]. (I have Trace[F] instance there)
def apply[F[_]: Trace: Sync](client: Client[F]): Client[F] = {
Client[F] { request =>
val spanName: String = ???
for {
b <- Trace[F].span(spanName) { //should be F[]
}
//only have Resource[F, Response[F]] type for
//client.run(modifiedRequest))
} yield ???
}
}Can't get how to transform Resource to wrap it with Trace[F].span
run map apply
map lift
map map lift
grasshopper
map lift
map map lift
grasshopper
You would do this while your are wiring up your client and you should be mostly operating in concrete monads anyway
So i'm looking to implement natchez and I understand that kleisli does not work with ConcurrentEffect, some of my program has it anyways. If I'm trying to work around it do I want do something like keeping my effect as F[_] and then using Kleisli.liftK on the specific code I'm working with or are there better ways to do this? (I'm fairly new to Kleisli and how best to handle this)
So, one thing that is worth mentioning, you can usually implement an algebra in F that requires ConcurrentEffect and then use FunctorK type things to lift into the Kleisli. You won't be able to trace through the algebra that needs the ConcurrentEffect bound, but you can integrate it in the rest of the system. The implementation of mapK can sometimes even be done for you using cats-tagless.
@bluemoon it doesn't help you today, but some good news: in CE3 you won't have that problem
just scoping out what's there - it's an ecosystem niche with no mature options
natchez generally should beat "do it in-house" regardless of version
Generalizing the Kleisli instance to Local would also be good.
if there was a baseline "just copies the readme" microsite with editable pages that's probably enough to start gathering PRs
Related to the Kleisli instance we actually have a LensedSpan type class that we use to pack different bits it with the span and produces Trace using the explicit lens operation on Kleisli trace. I can PR this if something you would want (and it would save us in the long term from a random implicit import).
We are a little behind I just hate upgrading those components because grpc has no concept of compatibility from what I can tell
There are way too many fires burning atm. Between Scala 3 and CE3 there's not a lot of time for extinguishing other things.
i.e.
Trace[F].span(“stream”)(s.compile.drain)
So, the alternative option (and I haven't really exploded this, is that spans are resources yourself. I think you could probably define a pipe that traces a stream and does something like
Stream.eval(Kleisli.ask).flatMap(span => Stream.resource(span.subspan("name"))) >> innerStream
Generalising slightly from the above problem, so far as I can see if I have
F[_] : Trace there's no way to have Stream[F, A] that embeds a subspan without wrapping in an F[_] given the present Trace API, unless I specifically assume that F is Kleisli, is this correct? If so this seems to be a bit of a pain point for writing transparent wrappers around other libs that inolve Stream, perhaps the API could be adjusted to accomodate scenarios like this?
There is a WIP out there somewhere
I find myself copying and pasting convenience code to make Natchez'
Trace constraint place nice with munit-cats-effect between various projects and I was wondering if it would make sense to A. add an munit module to Natchez, B. add a Natchez module to munit-cats-effect, C. create a library independent of the two or D. not bother cos its only a wee bit of code