Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    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
    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
    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!