monix/monix-bio

GKhotyan

@GKhotyan

Ok, great)

GKhotyan

@GKhotyan

@Avasil Hi! I made pull request with methods absorb and absorbWith which you write few days ago monix/monix-bio#180. Hope, it make sense :)

Piotr Gawryś

@Avasil

Thank you, I'll take a look tonight!

WesselVS

@WesselVS

Hi there, thanks for this great library! Are there plans to integrate the just merged improved tracing from monix? Also, if I were to take a shot at this myself, what would be a good approach? Is bio forked from monix, so that I can pull in the master branch from monix into bio?

Piotr Gawryś

@Avasil

Hello @WesselVS

Are there plans to integrate the just merged improved tracing from monix?

Yes, I've planned to do this after releasing stack traces for Monix that I want to do within a few days

Also, if I were to take a shot at this myself, what would be a good approach?

It would require copying relevant changes from this PR: https://github.com/monix/monix/pull/1267/files
monix-bio depends on monix-execution so RingBuffer will be available but the rest needs to be duplicated.

The structure is very similar so integration should be a straightforward but manual task.

Is bio forked from monix, so that I can pull in the master branch from monix into bio?

It's not a fork but it depends on some modules

If you'd like to help out then that would be fantastic

WesselVS

@WesselVS

Thanks! Ok, so I’m pretty far, all of the unit tests of bio succeed, but the tracing tests that I ported from monix fail with a off-by-one error, monix produces one additional trace. I’m going to look into this. Really fun to see the internals of the library.

Piotr Gawryś

@Avasil

but the tracing tests that I ported from monix fail with a off-by-one error, monix produces one additional trace.

That's acceptable, the best way to check is to print the stack trace, compare to monix.eval.Task and decide if both make sense

Awesome, it will speed up monix-bio release a lot :)

WesselVS

@WesselVS

Thanks! Just out of curiosity: I'm seeing this in the monix trace (in the test captures bracket frames of FullStackTracingSuite):

TaskTrace: 13 frames captured
 ├ apply @ tracing.FullStackTracingSuite$.new (FullStackTracingSuite.scala:117)
 ├ apply @ tracing.FullStackTracingSuite$.new (FullStackTracingSuite.scala:117)
 ├ runToFuture @ tracing.FullStackTracingSuite$.new (FullStackTracingSuite.scala:130)
 ├ <clinit> @ tracing.FullStackTracingSuite$.new (FullStackTracingSuite.scala:117)
 ├ runToFuture @ tracing.FullStackTracingSuite$.new (FullStackTracingSuite.scala:130)
 ├ pure @ tracing.FullStackTracingSuite$.new (FullStackTracingSuite.scala:117)
 ├ runToFuture @ tracing.FullStackTracingSuite$.new (FullStackTracingSuite.scala:130)
 ├ <clinit> @ tracing.FullStackTracingSuite$.new (FullStackTracingSuite.scala:117)
 ├ bracket @ tracing.FullStackTracingSuite$.new (FullStackTracingSuite.scala:117)
 ├ flatMap @ tracing.FullStackTracingSuite$.new (FullStackTracingSuite.scala:117)
 ├ flatMap @ tracing.FullStackTracingSuite$.new (FullStackTracingSuite.scala:117)
 ├ flatMap @ tracing.FullStackTracingSuite$.traced (FullStackTracingSuite.scala:12)
 ╰ map @ tracing.FullStackTracingSuite$.new (FullStackTracingSuite.scala:120)

Why is runToFuture there 3 times? The trace I'm getting in monix-bio lists the runToFuture only 2 times, but I'm trying to figure out why it's there more than once.

WesselVS

@WesselVS

PR: monix/monix-bio#190

WesselVS

@WesselVS

and a silly small one, since I miss *> <* pretty bad from monix: monix/monix-bio#191

Piotr Gawryś

@Avasil

Thank you, I will take a look as soon as I deal with main monix release :)

Piotr Gawryś

@Avasil

Regarding repeated runToFuture - I haven't figured it out yet, don't worry about it. Hopefully, we will clean up it in the future but that's fine for now

WesselVS

@WesselVS

Ok, thanks! Eagerly waiting for this to be released :)

Piotr Gawryś

@Avasil

Sadly, I didn't manage to finish the release last weekend but there's a good chance I will pull the trigger tomorrow and review your bio PR during the weekend :) Shouldn't take long to release the new monix-bio version

WesselVS

@WesselVS

Awesome!

WesselVS

@WesselVS

Hi Piotr, when do you have time to look at the traces PR?

Piotr Gawryś

@Avasil

Hi, I have it on my today's todo list! I will probably merge it and then aim to have a release around the weekend after I port some other changes and make some adjustments if needed

WesselVS

@WesselVS

Alright, cool! Thanks

Piotr Gawryś

@Avasil

Released 1.1.0 with stack traces :) https://github.com/monix/monix-bio/releases/tag/v1.1.0
cc @WesselVS

WesselVS

@WesselVS

Very nice! Thank you

Eliav Lavi

@eliavlavi

Hello! I am wondering if there's any example showing interop with Future - while using a custom error type and not working with Throwable. Any tip?

Eliav Lavi

@eliavlavi

More specifically... I am working with the Scanamo lib, which returns a Future[Either[SomeFailure, A]] for many of its operations. I would like transform that into an IO[SomeFailure, A] and work with it until I have to actually serve the data (then runToFuture). I assume whatever used to be a failed Future in the past is a fatal\terminal error in the context of IO... am I getting it right? Is this a supported use case?

Piotr Gawryś

@Avasil

Hello @eliavlavi

Your understanding is correct. It's similar with fromTryEither

It's equivalent of IO.deferFuture(f).hideErrors.rethrow.
Unfortunately, there's no built-in operator for that but I think we really need it if you're interested in contributing.
I see that I even implemented TaskFromFutureEither in low-level code but I don't remember why I didn't expose it in the API :sweat_smile:

Eliav Lavi

@eliavlavi

Thanks @Avasil, that helped!
Do you mean you'd like to have a def fromFutureEither[E, A](a: => Future[Either[E, A]]): IO[E, A]?

Piotr Gawryś

@Avasil

Yes

Eliav Lavi

@eliav-lavi

Cool. I'll try work on that.

(Seems fit in IO.scala right under def fromFuture to me, but I am not sure where should the test go - TaskFromFutureSuite.scala? new file?)

Piotr Gawryś

@Avasil

Thank you, I've left some comments on PR, new file is perfectly fine

Eliav Lavi

@eliav-lavi

Thanks, fixed and added 🙃

WesselVS

@WesselVS

At work, we use Monix’s observable a lot, that uses monix.eval.Task. We defined an implicit conversion between bio and eval tasks. What’s the proper way of doing this?

Piotr Gawryś

@Avasil

@WesselVS You can do a conversion like this: https://bio.monix.io/docs/cats-effect#monixevaltask

I have some plans to make Observable easier to use with IO[E, A] (without conversions) but it is not a top priority for me right now

Rohan Sircar

@rohan-sircar

Task(...).onErrorHandleWith {
    case _: SomeException => IO.raiseError(MyError(...))
    case other => IO.terminate(other)
  }

is this the correct way to lift recoverable exceptions to ADT and have the other exception terminate the IO?

Piotr Gawryś

@Avasil

@rohan-sircar Looks good. It might be useful to add an error handling method accepting a partial function to the library to decrease boilerplate

Rohan Sircar

@rohan-sircar

have other exceptions terminate the IO*

Thanks, I thought there would be a method to do this defined so I was confused when I didn't find one.
So something like this?

def liftErrors[E, T](
      task: Task[T]
  )(pf: PartialFunction[Throwable, IO[E, T]]): IO[E, T] =
    task.onErrorHandleWith(ex => pf.applyOrElse(ex, IO.terminate))

Piotr Gawryś

@Avasil

Yes, but probably directly on IO with (implicit ev: E <:< Throwable) and I'm not sure about the name. I feel like it could make sense if onErrorRecoverWith would work like that but it's not an option now. Maybe new variant of mapError and flatMapError ( the latter is missing atm), something like mapErrorPartial /mapErrorSome/ mapErrorOnly(whatever would be more consistent with other libraries)

Rohan Sircar

@rohan-sircar

By Eyou mean the error type of the current Task right?
So like this?

final def mapErrorPartial[E1, B >: A](pf: PartialFunction[E, IO[E1, B]])(implicit ev: E <:< Throwable): IO[E1, B] =
    onErrorHandleWith(ex => pf.applyOrElse(ex, IO.terminate))

Currently onErrorRecoverWith for Task fixes the resulting error type to Throwable

onErrorRecoverWith[E1 >: Throwable, B >: T](pf: PartialFunction[Throwable,IO[E1,B]]): IO[E1,B]

Piotr Gawryś

@Avasil

By E you mean the error type of the current Task right?

Yes

So like this?

Yeah, that's what I had in mind. I'm not sure if it matters if we use PartialFunction[Throwable,IO[E1,B]], or the other one

Rohan Sircar

@rohan-sircar

I had to write it like this to get it to typecheck

final def mapErrorPartial[E1, B >: A](pf: PartialFunction[E, IO[E1, B]])(implicit E: E <:< Throwable): IO[E1, B] =
    onErrorHandleWith(ex => pf.applyOrElse(ex, (ex: E) => IO.terminate(E(ex))))

I'll try adding some test cases

Rohan Sircar

@rohan-sircar

@Avasil monix/monix-bio#238

Rohan Sircar

@rohan-sircar

oh no ^^"

Piotr Gawryś

@Avasil

I was worried for a sec when I saw scalaJS errors :D

Rohan Sircar

@rohan-sircar

me too xd

WesselVS

@WesselVS

Hi Piotr, just wondering, what are the long term plans for bio? Is it still being maintained? What about scala 3 support?

Piotr Gawryś

@Avasil

I plan to keep maintaining it but my focus is currently on a monix/monix update for Scala 3 and CE3 which are also blockers for bio.
I think it's possible to get Scala 3 release before the official one but I won't make any promises

Regarding long-term plans, it is hugely dependant on the outcome of the "core" Monix CE3 update but the direction is not clear at the moment so it's difficult for me to provide any details. :sweat_smile: I know for sure that I'd like to have a competitive IO[E, A] implementation that works well with various ecosystems of libraries

WesselVS

@WesselVS

Alright! Thanks for the headsup and the effort!

Where communities thrive

People

Repo info

Activity