sorry, I know this is more of a Gradle question ab...

# arrow

[Jörg Winter]

sorry, I know this is more of a Gradle question about work-in-progress 😄... but is arrow-fx-stm (SNAPSHOT) available in some maven repository or do I have to clone and build it locally ?
..because: this seems so much more intuitive than setting up e.g. channels, events, actors etc. !
https://arrow-kt.io/docs/next/apidocs/arrow-fx-stm/arrow.fx.stm/-s-t-m/index.html

[Jannis]

All of arrows snapshots should be in:

maven { url "<https://oss.jfrog.org/artifactory/oss-snapshot-local/>" } // for SNAPSHOT builds

[Jörg Winter]

that doesn't work for the STM module currently

[Jannis]

well it is there: https://oss.jfrog.org/artifactory/oss-snapshot-local/io/arrow-kt/arrow-fx-stm/0.12.0-SNAPSHOT/
Weird...

[Jannis]

..because: this seems so much more intuitive than setting up e.g. channels, events, actors etc. !

It is, but comes at a cost. I need to append a section that addresses it properly.
In short: Use STM if you don't need peak performance and if you don't write to one variable very very frequently (contention is poison for STM). In most cases this should be true and thus STM is a great choice to fight lock complexity

[Jannis]

Hmm I am able to add it as a dep on a local project. Either thats because I have it somehow cached or there is something else going on

[Jannis]

Btw if you have some feedback on either the docs or stm itself (if we can get it working 🙈) please tell me, I really want to make sure it itself and its docs work properly till the next release^^

[Jörg Winter]

Are integration-level tests in place for STM already ? (something like the money-transfer example, as a test)
that's what I would try to do with STM myself

[Jannis]

There are, though not a lot iirc. The problem is, to perform an integration test thats actually useful you need a lot of contention on the variables (to trigger abort/retry behavior reliably).
The money transfer example is one of them, another one is testing TQueue under write heavy load and verifying that it does not skip elements or adds them twice.
I'd like more, especially contention heavy tests since those verify correctness the best, I'll look into that after the holidays^^

[Jannis]

Also concurrent writes to one variable are also tested to be linear. So some of the core guarantees should be decently well tested

[Jannis]

I have yet to break the guarantees somehow, tho, since this is a concurrency abstraction, that likely doesn't mean much 😅