Came across this one on arrow-fx 🤔

I must be doing something wrong here: https://github.com/arrow-kt/arrow-fx/pull/292/files#diff-ba2103c512331dbd5ba7a4540e5d8b36R56 If anyone has a chance to have a look at why the test doesn’t work or has a better idea on how to do this dsl for testing Streams, I’ll buy them a beer 🙂

This pr is now pretty much done: https://github.com/arrow-kt/arrow-fx/pull/270 A review is much appreciated. This brings software transactional memory to arrow with quite a few datatypes already implemented.

https://arrow-kt.io/docs/apidocs/arrow-core-data/arrow.core/-either/catch.html Hei . I got fooled by formatting here and through Arrow is saying Either.catch is deprecated. But its is for

~~catch~~

Can you please beautify it 🙂

just to confirm: we are waiting on https://github.com/arrow-kt/arrow-core/issues/147 to be fixed before merging https://github.com/arrow-kt/arrow-core/pull/239 right?

I get:

org.gradle.api.GradleScriptException: A problem occurred evaluating project ':arrow-meta'.
	at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:93)
	at org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl$2.run(DefaultScriptPluginFactory.java:237)
	at org.gradle.configuration.ProjectScriptTarget.addConfiguration(ProjectScriptTarget.java:77)
[...]
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
	at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
Caused by: org.gradle.api.GradleException: tools.jar not found at your JAVA_HOME dir /usr/lib/jvm/java-11-openjdk-amd64.
Building with a JRE or JDK9 is currently not supported

Maybe tools.jar is no more used and it is a bad check to have?:

def toolsJar = Jvm.current().getToolsJar()

    if (!toolsJar)
        throw new GradleException("tools.jar not found at your JAVA_HOME dir ${Jvm.current().getJavaHome().getAbsolutePath()}.\n" +
                "Building with a JRE or JDK9 is currently not supported.")

I'm getting this error with ktlint:

Not a valid Kotlin file (expecting a parameter declaration) (cannot be auto-corrected)

The line in question has a trailing comma, is this something we need to enable on ktlint? Or maybe we need to upgrade ktlint? I found this, but there doesn't seem to be any resolution, it's just closed 🤔 https://github.com/pinterest/ktlint/issues/729

I am playing with

DelimitedScope

to implement

option {}

continuation and I realised that

DelimContScope

can not manage

null

as a

shift

return value. the implementation already using nullable to show that the block is done. I replaced the nullable type with a quick GADT to represent empty state and allow nullable value:

private val nextShift = atomic<Shift<(suspend () -> R)>>(Empty)

is there any better way to avoid constant boxing for the return values of shifts?

I am getting a dependency resolution error on my PR after updating with the latest

Arrow-Core

. Is this a known issue?

Working on a new encoding for 1.0 to get closer to suspend, continuations and computational blocks and further away from Haskell Like type classes, kind emulation, etc as those are the less popular and most costly to maintain arrow features. This new encoding is based on arrow-continuations for binding but general enough to model any other functionality besides monad bind which is what’s shown in here. Now we are basing continuations and monad bind in arrow-continuations we can get rid of the nasty reflection tricks 🎉 and we are almost MPP. Feel free to comment in a thread here if anyone has any opinions, suggestions or questions. Thanks! https://gist.github.com/raulraja/5f29a00df261d8fbcfa94b6f2dd44ec6

@simon.vergauwen https://github.com/arrow-kt/arrow-fx/pull/289/files README was a very good reference point. whenever i wanted to refresh my moemory on something, I knew I can always go back to this reference point. I am sad to say https://arrow-kt.io/docs/fx/ doesn’t give a good overview. Seldom, I need to check api docs, which is basically what I get out of main

fx

webpage. The rest is very confusing, and have fewer examples than what was mentioned in the README before the PR I mentioned. I would really appreciate if this README was expanded. And above all, if you can take a look at what I going on https://arrow-kt.io/docs/fx/ , it would be amazing. I think you guys will promote. coroutines integrated solutions more and more, which is natural. The webpage should reflect that, with rich set of examples from the README. I don’t understand the point of

kotlinx.coroutines

section from the website, now that we have

arrow-fx-coroutines

. Also Why

IO integration

contains

kotlinx.coroutines

when

Coroutines Integration

contains the same sub section ? I think

Coroutines Integration

should just be removed, and

Quick start

should be enriched and expanded. The Data type section is now pointing to

arrow-fx-coroutines

but contains no practical examples. Its just a neat and more described version of api docs. There are many who use fx a lot, but not necessarily are well versed with fp concepts, which makes things hard, if we want to use API from the library without good docs. For me personally, things have gotten way easier, since I have migrated from arrow from Try.catch to IO.invoke, to Either.catch, and have been using since 2018. So I know where to look, who to ask. I know there are a lot at your plate, but honestly, so do I, and its a shame after using this library for more than about 3 years, I haven’t already started contributing. Things have been way too busy. I hope, I, in future, instead of requesting things, should be able to make time to raise PRs instead. 🙂 But until then, here is my request 😅

In case someone can help review 🙏 so we can push these fixes https://github.com/arrow-kt/arrow-core/pull/259

Hei. I just pulled

arrow-fx

, thinking to raise a PR (or atleast trying to), so I want to build the project from intellij. But I am getting this :

Kotlin: Supertypes of the following classes cannot be resolved. Please make sure you have the required dependencies in the classpath:
    class arrow.core.computations.EitherEffect, unresolved supertypes: arrow.continuations.Effect

Can anyone help me 🙂 A lot of files don’t compile because computation class are missing, I am guessing because of error above. Using jdk 1.8, but it has scala dep as well, so I am getting this too :

scalac: '13' is not a valid choice for '-target'

I'm not sure but I think you need to be part of the org to be able to create branches and push to them. Typically people use a forked repo to make a PR, unless you're a frequent contributor.

Has anyone ever experienced an error like this while using arrow?

Could not initialize class arrow.core.Either$Left

This is in a rather complex bit of code so I have no clue how to reproduce it in simple terms. The function that fails also works if called from a different method, but fails with others.

Do we have anything like this for nullable fx comprehensions? Maybe something similar to this: https://pl.kotl.in/nE6WSBhy0 Thought I ask before adding a ticket to look at it 😅

I did

parMapN

arity 7 (based on the arity 6 implementation) however kotest doesn't have the

checkAll

method with arity 7, so I could not implement the same tests as for arity 6 https://github.com/arrow-kt/arrow-fx/pull/356 any ideas for how to fix, or should I create a ticket with kotest?

On the parMap/parTupled topic... I did 2 PRs and most of the work is updating the test after a copy paste 🙈 Could we do the arity 10, use that fun as an oracle and express lower arity test in terms of that? Cc @simon.vergauwen

Hey all, I'm working on

Flow.retry

using

Schedule

you can find the PR here: https://github.com/arrow-kt/arrow-fx/pull/378 It's built atop the

Flow.retryWhen

operator and it seems to be working.... am I on the right path? any ideas how to test the

delay

part then retrying?

is there a roadmap issue or a Github project with the issues needed for 0.12 and 1.0?

Hei. are files in

arrow-fx

lib’s

arrow-benchmarks-fx

module’s compiled with jdk 1.6 ? I am gettinh this error :

e: /arrow-fx/arrow-benchmarks-fx/src/jmh/kotlin/arrow/benchmarks/Cancellable.kt: (28, 8): Cannot inline bytecode built with JVM target 1.8 into bytecode that is being built with JVM target 1.6. Please specify proper '-jvm-target' option

Thus every cmd + f9 fails Does arrow supports 1.6 😮 ? I have excluded those modules from build, so I can continue

PSA on parMapN in arrow-fx https://youtrack.jetbrains.com/issue/KTIJ-897

Back to monorepo? https://github.com/arrow-kt/arrow-fx/pull/396 I'm curious of the reasoning behind this 🙂

message has been deleted

Hei maintainers. Will you please https://github.com/arrow-kt/arrow/branches/stale remove the stale branches and delete the branches that are already merged or closed, and perhaps make this as a practice ? Gives a much better picture on the new upcoming changes. Sorry for policing, but I like go through branches once in a while to keep myself updated on new changes that may come.

Are we planning to (or have already) support for

kotlin.Result

?It’s becoming stable on 1.5? If only we get comprehensions would be a nice addition IMHO 🙂

val friendsNames: Result<List<String>> = result {
  val user = getCurrentUser().bind() // Result<User>
  val friends = friendsFor(user).bind() // Result<List<User>>
  friends.map { it.name }
}

Hi all! i am currently looking at this ask https://github.com/arrow-kt/arrow-integrations/issues/45 and am gathering inputs from folks here before I change anything. That issue seems to be a low hanging fruit which also doesn’t have a universal answer due to json & type unions. On one hand my initial instinct is to go with the semantics done in argonaut / circe which currently serializes as a configurable keyname e.g.

data class Foo(val foo: Either<FooLeftADT, FooRightThing>)
// serializes to
{
  "foo": {
    "left": ${leftValue.asJson}
    // or "right": ${rightValue.asJson}
  }
}

That shape is awkward but the codec above guarantees roundtrip. On the other hand, I also realize that

Helios

(which is by the way is a great library!!) is doing it without i.e.

// which yields
{
  "foo": ${leftValue.asJson}
    // or "foo": ${rightValue.asJson}
}

personally I do see the temptation of breaking codec laws in the second / helios variant. They are less awkward and more universally acceptable when we’re talking about microservices interop. However, a similar proposition was raised to circe and was declined - most likely due to the codec being unlawful. Of course, at the end of the day, both can be correct, and there’s no stopping us to implement a configurable knob for users to switch between one and the other. I don’t personally serialize

Either<L, R>

myself. I normally advocate folding it to a proper sealed type in the internal projects in my company so to avoid this problem altogether and also make sure the api contract plays well with various microservices written in multiple languages / paradigms. Having said that I’m somewhat indifferent. by the way the same thing can’t be said for

ior

keen to hear Arrow :arrow: crews’ thoughts.

I’m not sure how actively do we use Discussions but I’m thinking about adding topics like these there instead of (or as well as) in here