Are

arrow-fx

tests supposed to work now? Running like

./gradlew :arrow-fx-rx2:test

but no tests are executed.

Hey, currently there are a few problems that came up after the repo split that concern

arrow-test

. • It being in its own repo means other repos will use a snapshot version of it. This means that the changes we are testing are not present in the compiled code of

arrow-test

. As an example: I have a pr that changes the signature of a method in

Applicative

in

arrow-core

. In

arrow-test

we have, in

TraverseLaws

, a law which uses

Id.applicative

and

IO.applicative

which both come from the snapshot of

arrow-core

. This means they don't have the changes and this leads to `AbstractMethodError`'s at runtime. This was partially solved by @Rachel with a short term workaround already by recompiling

arrow-test

with a current version of the current repo before testing. For this pr this meant that the tests using

Id.applicative

worked fine, but

IO.applicative

still failed because it came from

arrow-fx

and that is not being recompiled (it does not even have the required changes!). There are probably other compile issues similar to this, which are less discover-able and harder to debug. • Any change in a core repo that changes a datatypes representation, it's equality instance or any method signature covered by laws has to first change

arrow-test

otherwise it will never pass a test. This is a significant hindrance for changes as it leads to lots of fractured prs. In my opinion the best way out of this is to split

arrow-test

for each repo, such that

arrow-core

has

arrow-test-core

etc. Then force

arrow-test-core

to only depend on local projects (or other

arrow-test-*

). This would mean that changes to, for example,

arrow-core

that would otherwise need to go to

arrow-test

are now local. It still means we need to create follow up prs in the other repos, but solves the issues with the laws. Splitting this up is also a fast process which can be done incrementally: Create a new module per repo, copy all laws/generators and eq instances for this repo and last make all local tests depend on it. This technically should mean no test has to change (although some laws may have to change, like

TraverseLaws

). Unrelated to this I'd also propose to rename

arrow-test

to something like

arrow-laws

as it really only contains laws, generators and equality instances, not actual tests. Thoughts/opinions/other ideas?

Hi, I noticed references to 'd-arrow' in the incubator module !

Hi, this is kind of a repeat of last saturdays message: There are a few more problems currently present because of the repo split that need to be addressed: Problems currently (That I can think of): • it is impossible to predict where changes break code. Even for someone who knows almost the entire arrow code base it is hard to predict. This means it is literally impossible for new contributors to predict how much work something will be and equally hard for a maintainer to then judge it for them^^ • Breaking changes will make all master branches of other repos that depend on it breaking. This means no other branch on those repos can merge and integrate it (and thus not be merged at all). This has two side-effects atm: It produces a ton of issues automatically and it stalls development. • Some thought experiments (not yet encountered, but not unlikely especially as we get more and more repos): What do we do if we merge a pr that is breaking, only to then discover (probably much later) that it cannot be solved in upstream libs? Reverting changes is possible yet annoying and could mean a lot of work that will likely fall to maintainers and not the one who did the initial contribution. Same scenario but this time the contributor who introduced the breakage does not solve it on upstream libs. This means yet more work for maintainers. Both of these are extra work for maintainers, which is fine if the maintainer that has to deal with it has a chance to discuss that pr prior, but because we don't know if a pr breaks upstream libs that is hard to do. So this kind of overlaps with the first point. • Overlapping with point 2: Third party libs working on snapshots will get constant (seemingly random) breakages because they always go to latest. And the other libs may or may not have fixed the breakage. This makes snapshots outside the internal arrow ecosystem unusable. Aside from that the snapshots don't work at all anyway atm. There are probably things I am missing but those are the most pressing things atm I think @simon.vergauwen and I were talking about a few things that we could possibly do do improve this. I'll post those in a thread for this message. As always: Ideas/thoughts down below please ^^

Hi @Rachel, what is the purpose of the arrow-docs project of the incubator module ? Note that the configuration of its pom conflicts with that of the global doc module.

can you please rewrite it without using fx, see if there’s any improvement?

Better metrics than cats when using flatMap :D

Hi there! We’re actively working on releasing the next arrow version, 0.10.5, that comes with some deprecations, quite a lot of fixes and improvements, before moving to 0.11 and BIO and other interesting features 🙂 So far we’ve merged most of the PRs, only 2 left Changes in tests + fixes from myself -> https://github.com/arrow-kt/arrow-fx/pull/46/ Deprecate ap from @Jannis -> https://github.com/arrow-kt/arrow-core/pull/40 Please, if you have something in mind that should be added to this release, don’t hesitate on replying on a thread!

Hi, is somewhere available the documentation for 0.11.0?

Hi, for contributing to Arrow lib is there any setup and guideline doc? I referred this, but felt it’s not comprehensive: https://github.com/arrow-kt/arrow/blob/master/docs/move-to-multi-repo/README.md Cc: @Rachel

Hi folks, I’m trying to reactivate the ConcurrentLaws tests in incubator but I got no luck so far, it seems there’s a flaky scenario specifically within the

cancellableReceivesCancelSignal

test, any help here would be greatly appreciated. Also, I noticed that incubator provides its own instances of genK and eqK for IO -> https://github.com/arrow-kt/arrow-incubator/blob/master/arrow-mtl-data/src/test/kotlin/arrow/mtl/test/generators/GenK.kt#L20 so I’d also like to ask if there’s a specific reason not to use the provided in fx-test // cc @Jannis

A proposal for a new kind encoding we need to support N-arity in type class hierarchies for Bifunctor and Trifunctor, … effects https://github.com/arrow-kt/arrow-core/issues/88

I'm working on a retrofit

CallAdapter

that would work with:

interface Service {

    @GET("/")
    suspend fun bodyEither(): Either<String, String>

    @GET("/")
    suspend fun bodyResponseE(): ResponseE<String, String>
}

// a more FP/Kotlin friendly version of retrofit2.Response
data class ResponseE<E, A>(
    val raw: okhttp3.Response,
    val code: Int,
    val message: String?,
    val headers: Headers,
    val body: Either<E, A>
) {

    val isSuccessful: Boolean = raw.isSuccessful
}

where the you can put the error body on the left. Would that be a good fit for

arrow-integrations

?

+1 or -1 for renaming

Either.cond

to

Either.invariant

and making the left side the error one?

anyone else would like to chime in?

⬆️ (about above 3 messages) when should I plan to have any CR? (not rushing but planning) 😉

no, but you can do it like this :

fun <A> Validated<NonEmptyList<YourType>, A>.toIO(): IO<A> {
    return when (this) {
        is Valid -> this.a.just()
        is Invalid -> YourErrorType(this.e).raiseError()
    }
}

Hey everyone, I’m wondering if anyone has had this issue before and how to resolve it. I’m creating a new module in the

arrow-fx

project and I need to target

jdk8

. I’ve changed the dependency to kotlin to use

kotlin-stdlib-jdk8

and I’ve added the following:

compileKotlin {
    kotlinOptions.jvmTarget = "1.8"
}
compileTestKotlin {
    kotlinOptions.jvmTarget = "1.8"
}

sourceCompatibility = "1.8"
targetCompatibility = "1.8"

I wasn’t sure if I needed both (kotlin and java compatibility markers) but I was trying to make it work. I’ve even changed

JAVA_VERSION

to be

1.8

on the modules

gradle.properties

file. Any who, despite all these changes, I’m getting the following errors from Animal Sniffer:

[Undefined reference] arrow.fx.(_IO.kt:19)
  >> boolean java.util.concurrent.CompletableFuture.complete(Object)

[Undefined reference] arrow.fx.(_IO.kt:20)
  >> boolean java.util.concurrent.CompletableFuture.completeExceptionally(Throwable)

[Undefined reference] arrow.fx.(_IO.kt:21)
  >> boolean java.util.concurrent.CompletableFuture.completeExceptionally(Throwable)

[Undefined reference] arrow.fx.(_IO.kt:8)
  >> Object java.util.concurrent.CompletableFuture.get()

[Undefined reference] arrow.fx.(_IO.kt:16)
  >> java.util.concurrent.CompletableFuture

[Undefined reference] arrow.fx.(_IO.kt:16)
  >> void java.util.concurrent.CompletableFuture.<init>()

[Undefined reference] arrow.fx.(_IO.kt:12)
  >> boolean java.util.concurrent.CompletableFuture.cancel(boolean)

I’m having a look at this ticket: https://github.com/arrow-kt/arrow-fx/issues/153 These APIs were introduced on the jdk8, so this module needs to target that version (hence why it’s a separate module) Anyone has experienced on how to configure animal sniffer in this instance? If you want to check it locally this is the branch: https://github.com/arrow-kt/arrow-fx/tree/pabs-completable-future-integration

how do I update this page? -> https://arrow-kt.io/docs/0.10/quickstart/projects/ I wanna add a new project 🙂

Hi, I’m working on integrating Micrometer with

IO

. I simply want to register the time it took to execute the

IO

. I have implemented

.timed

extension function that can be executed on IO. But I also want to have the possibility to call

.timed

on a function that returns IO. And have to generate 22 versions of that method 🙂. You have probably had the same “issue” (like with

memoize

). Do you have some ready to copy solution 🙂?

anyone else has thoughts on this -> https://github.com/arrow-kt/arrow-integrations/pull/26

Hi everyone! I'm new in FP, category theory, etc. world but a decent Kotlin developer! I want to start contributing on arrow. Mostly interested on making it multiplatform. Do you mind to introduce me some simple issues that I can jump in? 😄

I applied the suggestions by @Leandro Borges Ferreira https://github.com/arrow-kt/arrow-integrations/pull/26 this PR is now ready to review and hopefully merge 😄

Hi everyone! I created a PR https://github.com/arrow-kt/arrow-core/pull/129 to add

filterIsInstance

and

traverseFilterIsInstance

but I have a problem •

arrow-meta

cannot handle

java.lang.Class

correctly. It generates

import kotlin.Class

which doesn't exist! I tried to add

.replace("java.lang.Class", "")

in

fun String.asKotlin(): String

but it didn't solve the problem! Also in

fun TypeName.Classy.asKotlin(): TypeName.Classy

there is a condition for

Iterable

but didn't work with

Class

! • Also I tried with

kotlin.reflect.KClass<T : Any>

but

arrow-meta

cannot handle the

T : Any

part! Any suggestion to solve it?

Hi, I’m about: https://github.com/arrow-kt/arrow-integrations/pull/28 I found problem to solve: In case of returning

IO<Nothing, A>

Kotlin compiler(??? or Jvm?) erases all information about generics in this class. If method returns

IO<E, A>

where E is any type but

Nothing

, generic info is kept. Retrofit integration needs generic info, because Retrofit is a runtime library. I’ve also tested merged into master suspend + Either integration and it fails in the same place. Do anyone has some more knowledge about bytecode representation of

Nothing

and why compiler/Jvm do that only for

Nothing

type? Below are photos with brakepoint on

adapterType = method.getGenericReturnType()

(HttpServiceMethod.java:62)

Hi, during the last couple of days I've tried to handle this issue: https://github.com/arrow-kt/arrow-fx/issues/168 I've selected this as an opportunity to better understand FP and how Arrow works and at the same time to give my little help to this project. Actually the problem behind this issue was bigger than expected, as the fix on

ParApplicative

was quite easy but then it let some other hidden bugs come out... One on IO related to stack safety and one on Rx2 related to fork/join. I've patched the code in order to make it work but, without knowledge about the rationale of the design of the code, I suppose that there could be better ways to solve them. Anyway, my PR is: https://github.com/arrow-kt/arrow-fx/pull/167. How should I proceed now?

For those of you that have seen and reviewed @simon.vergauwen work in the suspend library over the last 4 weeks introducing suspend without IO and the same power please show your approval or comments here today. This is going in today to get a snapshot ready for Kotliners. https://github.com/arrow-kt/arrow-fx/pull/169

Is there a documentation on how to pull Arrow's source code and build it locally? A kind of intro to contributing to Arrow...