Hi guys, have you considered keeping

Try

?

'Try<out A>' is deprecated. Try will be deleted soon as it promotes eager execution of effects, so it's better if you work with Either's suspend constructors or an effect handler like IO

I do not think that its existence promotes eager execution of effects. This is how

Try

works and simetimes it is what you want. I tried to replace it with

Either.catch

but then I have to run it with

runBlocking

and it looks strange.

IO is also a bad abstraction in Kotlin

We also want to remove many methods like map and flatMap from many data types and move them to a type class modules because the new computation blocks like

either

eliminate the need to ever map or flatMap and Either so it’s one operator vs 15 to learn for a beginner

I assume that it will be released after Kotlin 1.4.

MVar is now called ConcurrentVar

They no longer depend on F

is it time to deprecate

CallK

from the retrofit integrations? With Retrofit's native

suspend

support it's not needed anymore. Creates a bit of confusion: https://github.com/LordRaydenMK/Android-Fx-Examples/issues/8

Hey all, I’m interested in getting involved and contributing in arrow. Apologies if I missed some documentation explaining any first steps but most things seemed to point toward reaching out via slack or twitter. Is there anything I could pick up to start contributing that is newbie friendly, or any documentation I should be reading? Thanks! Big fan of y’alls work and have been using arrow more and more at work (while also getting into FP)

I’m testing auto-module (my own plugin) on the incubator project to see if it would make our life easier 🙂 https://github.com/arrow-kt/arrow-incubator/pull/122 If people like it and find it useful I’ll happily propagate it to other repos. I have a new feature on the works for AM that will also streamline the use of composite builds and I was planning to use that to simplify the current build stack… but probably for after v1.0

@simon.vergauwen Do we have something like

callbackFlow

for

Streams

? 🙂

First try at nullable

mapN

https://github.com/arrow-kt/arrow-core/pull/189 Would appreciate any feedback!

I’m investigating doing android bindings with Stream. Would there be any objection in creating a repository called

arrow-android

where we can put all android related libs? and slowly move things like

arrow-fx-android

and similar over there. It will help with discoverability as well as remove Android build dependencies from other repositories (which can cause minor build time increases)

Guessing from the documentation the recommended way to check compatibility with other arrow-repos and operate over local changes in those is to use

installAllWithLocalDeps

. This is pretty nice, but for me it fails on the

arrow-android

module because of a missing sdk. Can we change this method to skip failure rather than full on crash? Building anything with

arrow-android

as a dep should still fail, but at least one can build anything else without problems. This will mean

buildAllWithLocalDeps

will still fail, but

buidWithLocalDeps

shouldn't, which I think is preferable.

Need one review on this one: https://github.com/arrow-kt/arrow/pull/2182 PS: thank you @Rachel 😃

Anyone else experienced this? https://github.com/arrow-kt/arrow-fx/issues/234

So, regarding this There are several options, I’m interested on knowing what you all think 🙂 1️⃣ Create a new repository called

arrow-extras

and create a module called

arrow-smash

2️⃣ Create a sole repository called

arrow-smash

with

Can

,

Smash

and

Wedge

from this hackage 3️⃣ Create a module inside

arrow-core

called

arrow-core-extras

(to be moved along to

arrow-datatypes

when we untangle

arrow-core

4️⃣ Something completely different (please comment) Thank you all

hi @simon.vergauwen, is published the dependency in Maven?

Hey, I am currently looking at adding a few benchmarks to various things (for my stm pr first and later delimited continuations) and I've been wondering if we have a common setup/already set up benchmarks to look at. The

arrow-benchmarks-fx

module in

arrow-fx

seems like a good start but it does not have

fx-coroutines

benchmarks as far as I can tell (do we even have some and if so where?) so I am not sure if that package is still supposed to be used... Also does it make sense to automate running benchmarks and show results in prs if any relevant code changes? (Could be a manual task as well but just having a way to compare performance for a pr and visualize the changes if we have benchmarks set up would be nice). Any ideas? I'd love to do some groundwork here so that adding benchmarks throughout other arrow repos becomes a more straightforward process...

If anyone has a chance I have a small PR in arrow-core that needs a second reviewer. Thanks! https://github.com/arrow-kt/arrow-core/pull/227

If anyone is free at all I’d like to solicit some advice on https://github.com/arrow-kt/arrow-fx/pull/279. I’m trying to add

parMapN

up to arity 9 but I’m running into some issues 1.

ParTupledN

has a huge amount of lag for me in intellij once I kind of scaffolded out the new functions. To the point it’s basically impossible to use intellij to edit that particular file. I haven’t been able to find a solution for that on my own (looks like the the kotlin plugins type checker freaks out when code analysis runs, so anytime anything is edited on the page). I don’t know if its just me, but if it isn’t, is this code new enough that I can split it into multiple files (it’s getting a bit big anyway). I would hope that might help, but its just a guess. 2. Many of the arrow coroutine tests hang indefinitely for me when running the tests locally (though they appear to work in the builds on the PR, such as https://github.com/arrow-kt/arrow-fx/actions/runs/243281626 ) Is this another me problem or is there something weird happening? 3. I’m adding some tests for parMapN for arity 2 and 3 (since it already exists), but it looks like arity 3 was failing one of the tests

"parMapN 3 cancels losers if a failure occurs in one of the tasks"

. When messing with the test I found that putting the winner in the third position always caused a hang, so I updated

parMapN 3

to use

parMapN 2

instead of the existing implementation of

parMapN(ctx, fa, fb, fc, f)

and it appears to have fixed it. Is that correct or is there a reason to definitely be using the stand alone implementation of N = 3 instead of composing with N = 2? Any suggestions appreciated! Thanks!

^ Heres a PR for this https://github.com/arrow-kt/arrow-fx/pull/279 I’m rebuilding after it failed on a stream Cancellation test (and confirmed it passes locally) so it’s either flaky or there is a bug for a particular input. I don’t think that failure is related to my changes because I didn’t see

parMapN

being used in

parJoin

but I didn’t dig through it exhaustively. https://github.com/arrow-kt/arrow-fx/pull/279/checks?check_run_id=1082708601

^ wanted to bump this https://github.com/arrow-kt/arrow-fx/pull/279 when anyone gets the chance! Thanks!

I just made an extension function to replace it locally.

inline fun <reified A, reified B> Either<Throwable, A>.product(f: () -> Either<Throwable, B>): Either<Throwable, Tuple2<A, B>> {
    return this.flatMap { a -> f().map { b -> a toT b } }
}

if someone can help with setting up a new module/repo, I am happy to start working on this one: https://github.com/arrow-kt/arrow-core/issues/238

Hey Arrows! (Is that a term?) I've added an issue to discuss arrow and Gradle. Any feedback from any fellow Gradle nerds will be more than welcomed 🙂 https://github.com/arrow-kt/arrow/issues/2220

I created the module and moved

Option

there. At first I made

arrow-option

depend on

arrow-core-data

(

Option

need

Show

,

Predicate

,

Either

and a few other utilities from core-data). However arrow-core-data also needs

Option

.

MonadLogic

,

Monoidal

,

Semigroup

,

Travers

etc... use it internally or in a public API. Since

Option

was marked for deprecation, I assume removing the

Option

usages from arrow-core-data is the way to go, right?

Hi all anyone able to review? Thanks and happy monday! https://github.com/arrow-kt/arrow-fx/pull/279

Ready for a review whenever someone has the time... thanks https://github.com/arrow-kt/arrow-core/pull/239

Literally a 1 char change: https://github.com/arrow-kt/arrow-fx/pull/286/files If anyone is feeling lucky 😎

What’s our strategy on the time API? Do we keep on using arrow’s Duration for new APIs or do we use

kotlin.time

instead? I’m asking as it requires opt-in 🙂