I am currently working on the

Functor instance Queue

ticket. I know this should be a fairly simple task sorry if I ask something obbvious :S , I have no previous experience with the

Queue

solution so I looked into the mentioned

ZIO Queue

(to be precise the

trait ZQueue[-RA, +EA, -RB, +EB, -A, +B]

) implementation. If I understand correctly we currently dont have a

ZQueue

equivalent implementation in :arrow:, our queue is representing a general

zio.internal.MutableConcurrentQueue

. To be able to implement the

Functor

we have to make sure the Queue captures the previous queue reference and the f function to be able to deplete the original queue. TL;DR: we have to create a

ZQueue

equivalent in :arrow: and implement

Functor

on it instead of Queue. I believe it is a slightly more work than a simple typeclass. I would be super happy to implement it, but before that I just want to make sure I am on the right path here 🙂 @simon.vergauwen

May someone help me out here with Contravariant 🙂 . The Prelude looks like this:

class ForOp private constructor() {
  companion object
}
typealias OpOf<A, X> = arrow.Kind2<ForOp, A, X>
typealias OpPartialOf<A> = arrow.Kind<ForEither, A>

@Suppress("UNCHECKED_CAST", "NOTHING_TO_INLINE")
inline fun <A, X> OpOf<A, X>.fix(): Op<A, X> =
  this as Op<A, X>


@higherkind
data class Op<A, X>(val f: (X) -> A) {
  fun <B> compose(other: Op<B, A>): Op<B, X> =
    Op(other.f compose f)

  fun <B> compose(g: (A) -> B): Op<B, X> =
    compose(Op(g))
}

inline fun <A, X> Op<A, X>.k(): Kind2<ForOp, A, X> = TODO() // does that make sense?

now I want to define:

interface OpContravariant<C> : Contravariant<Conested<ForOp, C>>

How does that look like. I tried it, but I could not find something tangible. cc @Ariostonj

Is there a reason

StateT<F, S, A>

is defined with

Kind<F, (S) -> Kind<F, Tuple2<S, A>>>

? The double

Kind<F, *>

are weird. I am currently rewriting some tests for higher coverage and noticed a bunch of failures with monad-applicative-consistency (monad derived ap doing different things than normal ap) and

StateT

is the last one that still fails.

I've just tried building arrow locally. Everything but one test passed:

> Task :arrow-free-data:test FAILED

with latest commit. Using Mac OS 10.14.6, using Java

8.0.232.j9-adpt

. I tried to look at the build server, but couldn't find the latest build. Is this expected? If not, what could I do to make this test pass?

I finally got this done. I’d appreciate reviews https://github.com/arrow-kt/arrow/pull/1534 🙂

Is it just me or are code blocks on next.arrow-kt.io broken? Happens on both chrome and brave on linux

Is there a way to use terms with an internal modifier in tests. That has been changes in 1.3.61 AFAIK. https://github.com/arrow-kt/arrow/pull/1920 Most of them are in ArrowFx

Does mtl has flaky tests? If I run the tests on

mtl-data

they’re fine locally, but not in CI. https://github.com/arrow-kt/arrow/pull/1921/checks?check_run_id=383792628 Or am I doing something wrong.

@simon.vergauwen @raulraja are we at a point where we can go for 0.11?

Hello! There have been a couple of weeks since I last ran the Arrow project, but now suddenly I'm not able to compile/build it:

./gradlew dokka

Gives me:

> Task :arrow-core:kaptKotlin FAILED
e: [kapt] An exception occurred: java.lang.StackOverflowError
        at arrow.meta.encoder.jvm.KotlinPoetEncoder$DefaultImpls.toMeta(KotlinPoetEncoder.kt:88)
(...)

Tried several things already, like increasing the Java heap size, starting from a fresh repo, and even removing all of

~/.gradle/

directory with no luck 😢, and I'm not able to overcome that yet. Has anybody faced something like this recently? Might this be related to this issue: https://github.com/arrow-kt/arrow/issues/1927?

I like the idea of segregate modules into repository, but not at that low level, some modules could be stored into the same git repository as they are related, arrow-ank and arrow-ank-gradle could be in the same git repo for instance same for those with arrow-xxx-yyy structure that share the same

xxx

, WDYT? there is a technical issue about structure in that way?

I should read the whole thing before thinking too much ^^

Hi, the build linked to my PR is in error ! Maybe linked to https://github.com/arrow-kt/arrow/pull/1968 My PR only adds fx syntax to Free monads... a side effect ! In local, I also noted that from time to time the fx tests fail.

2020-01-27T10:24:35.4063911Z arrow.fx.IOTest > IORacePair should be stack safe FAILED
2020-01-27T10:24:35.4064309Z     java.lang.StackOverflowError
2020-01-27T10:24:35.4064546Z         at <http://arrow.fx.IO|arrow.fx.IO>$Companion.racePair(IO.kt:53)

2020-01-27T10:24:35.4727789Z arrow.fx.IOTest > IORaceTriple should be stack safe FAILED
2020-01-27T10:24:35.4727909Z     java.lang.StackOverflowError
2020-01-27T10:24:35.4728010Z         at <http://arrow.fx.IO|arrow.fx.IO>$Companion.raceTriple(IO.kt:53)
...

Hi, I prepared a PR with additional tests for the Free package; and, I added a new benchmarking project for the trampoline part... Interesting: for calculations of the Fibonacci sequence, there is approximately 30% difference between the Trampoline/Eval approaches.

When writing test for new(0.11.0)

toIO()

(mentioned today in #arrow), I saw that

attempt

is like:

fun attempt(): IO<E, Either<Throwable, A>>

While in Scala Cats there is:

val x: IO[Either[Int, String]] = IO[Either[Int, String]] { Left(1) }
val y: IO[Either[Throwable, Either[Int, String]]] = x.attempt

def attempt: IO[Either[Throwable, A]]

Won’t be more intuitive to type it like this? Also in actual form I am unable to call

IO.attempt().unsafeRunSync()

, because

unsafeRunSync

is like:

fun <A> IOOf<Nothing, A>.unsafeRunSync(): A

Hello guys. I started implementing an interop module for Reaktive. Checked existing implementations for RxJava2 and Reactor. The CororutineContext->Scheduler converter appears to be implemented incorrectly. E.g. "tasks scheduled on a Worker are guaranteed to be executed sequentially and in a non-overlapping fashion", but here they are being executed in parallel: https://github.com/arrow-kt/arrow/blob/397b84f1366662c8a0f4c3ea02717e1c74ccc990/modules/fx/arrow-fx-rx2/src/main/kotlin/arrow/fx/rx2/CoroutineContextRx2Scheduler.kt#L29. And I believe same issue in Reactor module. So I'm wondering is there any reason of such an implementation or it's just a bug?

So I did pretty much everything, stuck with

racePair

implementation for

Maybe

. I implemented

CoroutineContext

->`Scheduler` interop properly and now race conditions affect tests more often. Already spend ~8h of debugging, ended up with a different implementation that works. So what is going on (will explain in terms of the existing

RxJava2

implementation and the

racePairCanJoinLeft

test):

override fun <A, B> CoroutineContext.racePair(fa: MaybeKOf<A>, fb: MaybeKOf<B>): MaybeK<RacePair<ForMaybeK, A, B>> =
    asScheduler().let { scheduler ->
      Maybe.create<RacePair<ForMaybeK, A, B>> { emitter ->
        val sa = ReplaySubject.create<A>()
        val sb = ReplaySubject.create<B>()
        val dda = fa.value()
          /*
          * 1:
          * We subscribe to "fa".
          * This has "subscribeOn" operator somewhere in the upstream.
          * So the subscription is asynchronous.
           */
          .subscribe(sa::onNext, sa::onError)
        val ddb = fb.value().subscribe(sb::onNext, sb::onError)
        emitter.setCancellable { 
          /*
           * 3:
           * This is called after emission in Step 2 is done.
           * Here is the race condition.
           * If this is called BEFORE Step 1 is actually subscribed
           * and value is delivered to "sa", then test fails with timeout.
           */
          dda.dispose(); ddb.dispose() 
        }
        val ffa = Fiber(sa.firstElement().k(), MaybeK { dda.dispose() })
        val ffb = Fiber(sb.firstElement().k(), MaybeK { ddb.dispose() })
        sa.subscribe({
          emitter.onSuccess(RacePair.First(it, ffb))
        }, { e -> emitter.tryOnError(e) }, emitter::onComplete)
        sb.subscribe({
          /*
           * 2:
           * We receive a value here and emit it to downstream.
           * This eventually disposes this Maybe after emission is done. 
           */
          emitter.onSuccess(RacePair.Second(ffa, it))
        }, { e -> emitter.tryOnError(e) }, emitter::onComplete)
      }.subscribeOn(scheduler).observeOn(Schedulers.trampoline()).k()
    }

So I ended up with the following implementation:

override fun <A, B> CoroutineContext.racePair(fa: Kind<ForMaybeK, A>, fb: Kind<ForMaybeK, B>): Kind<ForMaybeK, RacePair<ForMaybeK, A, B>> {
    val scheduler = asScheduler()
    val coa: ConnectableObservable<A> = fa.value().subscribeOn(scheduler).asObservable().replay(bufferSize = 1)
    val cob: ConnectableObservable<B> = fb.value().subscribeOn(scheduler).asObservable().replay(bufferSize = 1)
    lateinit var da: RxDisposable
    coa.connect { da = it }
    lateinit var db: RxDisposable
    cob.connect { db = it }
    val ma = coa.firstOrComplete()
    val mb = cob.firstOrComplete()

    return merge(
      ma.map { RacePairResult.First(it) },
      mb.map { RacePairResult.Second(it) }
    )
      .firstOrComplete()
      .map {
        when (it) {
          is RacePairResult.First -> RacePair.First(winner = it.value, fiberB = Fiber(join = mb.k(), cancel = MaybeK(db::dispose)))
          is RacePairResult.Second -> RacePair.Second(fiberA = Fiber(join = ma.k(), cancel = MaybeK(da::dispose)), winner = it.value)
        }
      }
      .k()
  }

  private sealed class RacePairResult<out A, out B> {
    class First<A>(val value: A) : RacePairResult<A, Nothing>()
    class Second<B>(val value: B) : RacePairResult<Nothing, B>()
  }

The 47deg people are on a retreat, I may have time to take a look later today or Sunday

Ok here is another problem: In

maybek.kt

we have the following function:

override fun <A, B> CoroutineContext.racePair(fa: MaybeKOf<A>, fb: MaybeKOf<B>): MaybeK<RacePair<ForMaybeK, A, B>> =
    asScheduler().let { scheduler ->
      Maybe.create<RacePair<ForMaybeK, A, B>> { emitter ->
        val sa = ReplaySubject.create<A>()
        val sb = ReplaySubject.create<B>()
        val dda = fa.value().subscribe(sa::onNext, sa::onError)
        val ddb = fb.value().subscribe(sb::onNext, sb::onError)
        emitter.setCancellable { dda.dispose(); ddb.dispose() } // <-- This is the line in question
        val ffa = Fiber(sa.firstElement().k(), MaybeK { dda.dispose() })
        val ffb = Fiber(sb.firstElement().k(), MaybeK { ddb.dispose() })
        sa.subscribe({
          emitter.onSuccess(RacePair.First(it, ffb))
        }, { e -> emitter.tryOnError(e) }, emitter::onComplete)
        sb.subscribe({
          emitter.onSuccess(RacePair.Second(ffa, it))
        }, { e -> emitter.tryOnError(e) }, emitter::onComplete)
      }.subscribeOn(scheduler).observeOn(Schedulers.trampoline()).k()
    }

I pointed the line that I would like to discuss. I don't think this is correct to dispose BOTH subscriptions when the main stream is succeeded. If a

Winner

produced a value then the main

Maybe

completes and this callback gets executed. So the

Loser

terminates as well. In my

Reaktive

implementation I fixed this but now

racePairCanCancelsLoser

fails since:

val loser = s.release().bracket(use = { never<String>() }, release = { p.complete(i) })

The

Loser

never completes because no one cancels it and it is

never

completes by itself. Such a change fixes the test and looks. What do you think?

@Rachel @raulraja I had a discussion with @simon.vergauwen the other day about helping with the Arrow MPP effort. Please feel free to send me a PM / mention me if you think there is something I can contribute to in this topic.

We're creating the new repositories

We'll provide the details before

Hey @Richard Gibson @Scott Christopher @kioba, I rewrote the internals of

Queue

which was based on

ZIO

to how

MVar

is build in Arrow and Cats-effects which uses lower level constructs such as

atomic

with

tailrec

instead of

Ref

. You can find the PR here, https://github.com/arrow-kt/arrow/pull/2081, there is some impact on the API. Since we can offer a more powerful API but 2 use-cases are removed. Dropping and bounded queue with capacity 0. Looking forward to your feedback on the PR 🙂

Hi fellow contributors, this move will be done tomorrow Thursday at 10.00 am GMT. The contributions will be blocked at that time during 1 hour (or maybe less time). We'll publish messages before and after the move. Please, find details here: https://github.com/arrow-kt/arrow/tree/starting-point/docs/move-to-multi-repo (it's located in a branch, so the URL will change after the move; that documentation will remain in arrow repository). If there are pending PRs at that time, don't worry, branches will be moved to the correspondent repositories. If you're working in a forked repository, find the steps to follow after the move: https://github.com/arrow-kt/arrow/blob/starting-point/docs/move-to-multi-repo/how-to-move-a-pr.md Thanks for your collaboration!!

The move is finished!! We're going to follow with the next steps (closing PRs, move issues, etc), however, contributions are open again 🎉

The readme icons are broken I think?

Could I suggest to refresh the pinned items in the org github page?