https://kotlinlang.org logo
#arrow-contributors
Title
# arrow-contributors
j

Jannis

02/22/2020, 12:01 PM
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?
👍 1
p

pakoito

02/22/2020, 12:03 PM
Thoughts/opinions/other ideas?
Back to monorepo 😄
j

Jannis

02/22/2020, 12:05 PM
Nah^^ Splitting
arrow-test
is a good idea even with a monorepo. It was always such a mess 😅
r

raulraja

02/22/2020, 12:13 PM
I agree Janis, also ideally all laws are part of the typeclasses to get closer to how meta can discover them
s

simon.vergauwen

02/22/2020, 12:17 PM
Yes, I agree with you @Jannis! I proposed the same thing yesterday.
r

raulraja

02/22/2020, 12:31 PM
Meta may be able to verify laws at compile time if the user provides a Gen for a data type in a extension proof that can be resolved as a constant expression
The IDE would tell the user in real time of the structure of it's type as provided by the Gen instance follows the law. It would also allow users to encode tests and predicates alongside their declarations and optionally allowing then to eliminate the laws and gen instances at runtime
j

Jannis

02/22/2020, 12:34 PM
That would be running a property test at compile time right? This is only better if the test is super fast and thus gives direct feedback, which would be amazing^^. Other than that I don't see the benefit over having normal tests.
r

raulraja

02/22/2020, 12:35 PM
The benefit is that as it evolves as something like Scala stainless we can add a means of formal verification of properties
stainless supports @law
Checks for totality of functions
Preconditions and postconditions etc.
Make the language safer and bring stronger static analysis. Laws are a piece of all that if we recognize type classes as first class citizens
As for how fast the test is it should be pretty fast as in now provided the Gen sample uses simple constant evaluable values such as: Id(1)
Also the laws can be used in the IDE to highlight or not compile unsafe calls over types that do not abide the constrains the typeclass imposes as laws.
arrow 2
When I said Gen I meant our own definition of it.
j

Jannis

02/22/2020, 12:58 PM
Well I am definitely interested^^ For the current problems: I'll prepare a pr for
arrow-core
where we can discuss this approach further, because this really needs to be solved asap, because it will be blocking for some pull requests...
👍 2
Just figured out that
arrow-core-data
for some reason has a dependency on all of arrow (through
arrow-docs
which comes from
arrow-ank
). This makes my initial plan of copying the source and just deleting/changing everything that fails to compile impossible for now, because you can actually do
fx
and
mtl
etc in `arrow-core`^^ I'll add the pr when this is fixed, already wrote rachel because I have no idea how that even happens 😅
r

Rachel

02/24/2020, 9:31 AM
arrow-test
and
arrow-docs
are the two "hot" points.
arrow-docs
should be re-organized as well. It was split and it doesn't contain the site. However, it still has source code that is used for code snippets from the apidocs and it can be split as well for every library.
👍 2
j

Jannis

02/24/2020, 2:28 PM
@raulraja just saw

https://youtu.be/dkO59PTcNxA

. Stainless is very interesting and definitely worth it 😅 generating equivalence classes from code and checking them is a great concept (at least that is my impression of how it works, haven't checked the source)
👍 1
r

Rachel

02/25/2020, 1:58 AM
There is already a solution for
arrow-test
and
arrow-docs
. It will be improved during next days.
a

Arkadii Ivanov

02/25/2020, 11:38 AM
@Rachel Is see that
arrow-test
was archived. Aaaaaandd, my PR (https://github.com/arrow-kt/arrow-test/pull/10) was abandoned, again 😄 How should I proceed with the PR? It blocks my another PR (https://github.com/arrow-kt/arrow-fx/pull/33).
a

aballano

02/25/2020, 11:39 AM
@Arkadii Ivanov yes, we had to adapt the repo as previously the tests were splitted as you see
so now arrow-fx contains its own tests, so no need to split tests and code in multiple PRs, you just need to import your changes to the new arrow-fx-tests module and continue your PR in arrow-fx
r

Rachel

02/25/2020, 11:40 AM
Sorry @Arkadii Ivanov, I missed writing a message on those PRs
Thanks @aballano 🙌
👍 1
s

simon.vergauwen

02/25/2020, 12:05 PM
Ouch >< sorry for the inconvenience @Arkadii Ivanov. We can continue the discussion there, I cannot answer in the PR since the repo is archived.
a

Arkadii Ivanov

02/25/2020, 12:11 PM
Thanks guys, I will import changes to the
arrow-fx
PR.
r

Rachel

02/25/2020, 12:12 PM
Thanks @Arkadii Ivanov, sorry for the inconvenience!
a

Arkadii Ivanov

02/25/2020, 12:13 PM
No worries 👍
👍 1
10 Views