Current iteration #242

mvanaken · 2018-07-31T21:52:53Z

Implementation of current iteration for Rep, Repn and While loops. The loops are 0-based, meaning that the first iteration of a loop returns 0 when CURRENT_ITERATION is used.
This issue is scoped to only implement referencing to the current iteration. Current iteration of nested loops are supported, but the implementation to reference to a parent loop from within nested loops is handled in a different issue (#240).

TODO based on review comments:

Include token check within iterations, to ensure that the closeBranch is done with the same token as the addBranch?
Improve last test of CurrentIterationTests, which is that a 0-sized def should not influence the current iteration count.

…pression.

… iterable and counting siblings a long the way.

… it represents. Cleaned up test a bit.

…ves coverage.

…nd count the iterations of the iterable afterwards.

…de an iterable scope.

…mpty.

codecov · 2018-07-31T22:08:48Z

Codecov Report

Merging #242 into master will decrease coverage by 0.14%.
The diff coverage is 96.36%.

@@             Coverage Diff              @@
##             master     #242      +/-   ##
============================================
- Coverage       100%   99.85%   -0.15%     
- Complexity     1016     1025       +9     
============================================
  Files            90       92       +2     
  Lines          1381     1387       +6     
  Branches        141      141              
============================================
+ Hits           1381     1385       +4     
- Misses            0        1       +1     
- Partials          0        1       +1

Impacted Files	Coverage Δ	Complexity Δ
...src/main/java/io/parsingdata/metal/token/Post.java	`100% <100%> (ø)`	`10 <2> (ø)`	⬇️
.../src/main/java/io/parsingdata/metal/token/Sub.java	`100% <100%> (ø)`	`20 <1> (ø)`	⬇️
...src/main/java/io/parsingdata/metal/token/RepN.java	`100% <100%> (ø)`	`11 <4> (-4)`	⬇️
.../src/main/java/io/parsingdata/metal/token/Seq.java	`100% <100%> (ø)`	`12 <1> (ø)`	⬇️
.../src/main/java/io/parsingdata/metal/token/Pre.java	`100% <100%> (ø)`	`10 <1> (ø)`	⬇️
.../src/main/java/io/parsingdata/metal/token/Tie.java	`100% <100%> (ø)`	`16 <1> (ø)`	⬇️
...java/io/parsingdata/metal/token/IterableToken.java	`100% <100%> (ø)`	`12 <12> (?)`
...rc/main/java/io/parsingdata/metal/token/Token.java	`100% <100%> (ø)`	`15 <1> (+1)`	⬆️
.../src/main/java/io/parsingdata/metal/token/Cho.java	`100% <100%> (ø)`	`11 <1> (ø)`	⬇️
...rc/main/java/io/parsingdata/metal/token/While.java	`100% <100%> (ø)`	`9 <5> (-5)`	⬇️
... and 6 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f432c33...5442e7a. Read the comment docs.

ccreeten · 2018-08-01T20:42:16Z

core/src/main/java/io/parsingdata/metal/expression/value/reference/CurrentIteration.java

+    }
+
+    private Trampoline<ParseGraph> findCurrentIterable(final ParseItem item, final ParseGraph iterableCandidate) {
+        if (!item.isGraph()) { return complete(() -> iterableCandidate); }


What would happen if I would do something like rep(def("val", CURRENT_ITERATION)) or rep(tie(any("val"), CURRENT_ITERATION))? Because when I eval the expression, there is no value to stop at? Seems like it would blow up?

If you mean infinite loop, no, but there will be a null pointer exception, because the head becomes null. Nice catch! Will add item == null to this if statement and add tests.

Ah, I see your point now. Because a def of size 0 is not added to the parseGraph. However, then the iterable is in fact empty, which will return an empty value and the parsing will fail, see line 50. So it will not blow up.

It is a nice discussion though what you would expect to be "an iteration". Should a parsing attempt, where eventually 0 bytes are parsed, be considered an iteration? Also, would we expect rep(def("val", add(CURRENT_ITERATION, con(1)))) to work?

Actually, if I read the code as is, I think your first comment does happen (I indeed meant something like a NPE)? Because there is no value yet when you eval CURRENT_ITERATION, and the only way the recursion stops is if it encounters a value? Could you add these samples as a test?

As to the discussion, I would probably expect your example to work, because we are in fact in an iteration? I also think conceptually a 0 bytes parsed should still be considered an iteration, as I feel it is the iteration that happens, not what happens inside the iteration (wow, confusing sentence 😄). What would be the downsides of this, or what problems would it pose?

I implemented CURRENT_INDEX differently. Instead of extracting it from ParseGraph, it is kept in the ParseState. I added tests for examples similar to rep(def("val", add(CURRENT_ITERATION, con(1)))).

I will need to improve the code a little before I commit.

ccreeten · 2018-08-01T20:42:36Z

core/src/main/java/io/parsingdata/metal/expression/value/reference/CurrentIteration.java

+
+/**
+ * A {@link ValueExpression} that represents the current iteration in an
+ * iterable {@link io.parsingdata.metal.token.Token} (e.g. when inside a


Perhaps import the class names?

ccreeten · 2018-08-01T20:42:48Z

core/src/main/java/io/parsingdata/metal/expression/value/reference/CurrentIteration.java

@@ -0,0 +1,84 @@
+/*
+ * Copyright 2013-2016 Netherlands Forensic Institute


ccreeten · 2018-08-01T20:44:46Z

core/src/main/java/io/parsingdata/metal/expression/value/reference/CurrentIteration.java

+        return ImmutableList.create(Optional.of(createFromNumeric(currentIteration, new Encoding())));
+    }
+
+    private Trampoline<ParseGraph> findCurrentIterable(final ParseItem item, final ParseGraph iterableCandidate) {


I would really like some inline comments or javadoc stating what these things do 😄

Not applicable anymore. ;) These methods are removed, because of the new implementation.

ccreeten · 2018-08-02T22:45:29Z

core/src/main/java/io/parsingdata/metal/expression/value/reference/CurrentIteration.java

+
+    @Override
+    public ImmutableList<Optional<Value>> eval(final ParseState parseState, final Encoding encoding) {
+        final ParseGraph currentIterable = findCurrentIterable(parseState.order, ParseGraph.EMPTY).computeResult();


Cool way to calculate the iteration by the way 😄

…within ParseState, instead of extracting it out of the ParseGraph. The iteration is now independent on the parse result.

rdvdijk

Looks pretty good to me! Please see my comments.

Also: I think you need to cover one more branch somewhere to get coverage back to 100%.

rdvdijk · 2018-08-24T12:54:31Z

.gitignore

@@ -1,5 +1,6 @@
 # Maven
 target/
+out/


Interesting, where did this come from?

Ah, good question! Apparently, IntelliJ has created this directory during build. Unclear why though. Wasn't planning to commit this. Will remove it.

rdvdijk · 2018-08-24T13:00:45Z

core/src/main/java/io/parsingdata/metal/expression/value/reference/CurrentIteration.java

+        if (parseState.iterations.head == null) {
+            return ImmutableList.create(Optional.empty());
+        }
+        return ImmutableList.create(Optional.of(createFromNumeric(parseState.iterations.head, new Encoding())));


The default new Encoding() is probably good enough here. For a minute I thought we needed to pass the encoding on, but I think this is correct.

Side note: Don't we have a DEFAULT_ENCODING available somewhere? I wonder how often we do new Encoding() like this.

No, there is not a default encoding as constant available. We do this 6 times in core; 4 in Shorthand, 1 in CurrentOffset, and 1 in CurrentIteration. In test scope we call it 7 times.

Good point: #245

rdvdijk · 2018-08-24T13:11:14Z

core/src/test/java/io/parsingdata/metal/expression/value/reference/CurrentIterationTest.java

+        return Arrays.asList(new Object[][] {
+            { "[0, 1, 2, 3, 255] rep(CURRENT_ITERATION), def(255)", seq(rep(VALUE_EQ_ITERATION), VALUE_EQ_255), stream(0, 1, 2, 3, 255), enc(), true },
+            { "[0, 1, 2, 3] repn=4(CURRENT_ITERATION)", repn(VALUE_EQ_ITERATION, con(4)), stream(0, 1, 2, 3), enc(), true },
+            { "[255, 0, 1, 2, 3, 255] def(255), while<3(CURRENT_ITERATION), def (255)", seq(VALUE_EQ_255, whl(VALUE_EQ_ITERATION, not(eq(con(3)))), VALUE_EQ_255), stream(255, 0, 1, 2, 3, 255), enc(), true },


Nitpick: the description of the test should actually be while!=3 instead of while<3 right?

Yes, correct. I will adjust it.

rdvdijk · 2018-08-24T13:18:56Z

core/src/test/java/io/parsingdata/metal/expression/value/reference/CurrentIterationTest.java

+            { "[0, 1] seq(!CURRENT_ITERATION, ...)", seq(VALUE_NOT_EQ_ITERATION, VALUE_NOT_EQ_ITERATION), stream(0, 1), enc(), true },
+            { "[0] !CURRENT_ITERATION", VALUE_NOT_EQ_ITERATION, stream(0), enc(), true },
+            { "[0 | 0, 1 | 0, 0, 2 | 0, 0, 0, 3] rep(CURRENT_ITERATION)", rep(def("value", add(CURRENT_ITERATION, con(1)), eqNum(CURRENT_ITERATION))), stream(0, 0, 1, 0, 0, 2, 0, 0, 0, 3), enc(), true },
+            { "[1, 1, 0, 1 | 0 | 2 | 3] repn=4(size), rep(def(any, sizeRef(CURRENT_INDEX)))", seq(repn(def("size", 1), con(4)), rep(def("value", nth(ref("size"), CURRENT_ITERATION)))), stream(1, 1, 0, 1, 0, 2, 3), enc(), true },


I had to read this last case over a few times until I understood what is going on here. Would it be possible to add a separate unit test to make absolutely sure that this works as intended? The expression nth(ref("size"), CURRENT_ITERATION) will result in three times a 1 and one time a 0. But did that happen in the expected order, for example?

Well, yes, it happed in the expected order, which is why I omitted the 1, but I do understand why it is confusing. I wanted to add a test that resulted in a 0-size def, which does not result into an item within the parseGraph, but does count as a iteration.

Please let me know when you've added that test 👍

I've improved the above test to verify this behaviour. It now does the following:

Iterate over a list of sizes (repn=4, read in the values (1, 1, 0, 1)).

Iterate again for 4 times (repn=4), this time only parsing a value if not(eq(nth(ref("size"), CURRENT_ITERATION), so if the CURRENT_ITERATIONth value in the list is non-zero (this happens in iterations 0, 1 and 3.

Then parse a value of 1 byte that must be equal to CURRENT_ITERATION.

The fact that the parsed and value-checked values are 0, 1 and 3 verifies that CURRENT_ITERATION continues counting even if an iteration does not produce a value (when is implemented with a zero-size def inside a cho).

I agree with the original comment that the test is a little complex, maybe now even more so. We should probably simplify it, but for now I think verifying behaviour is most important.

core/src/main/java/io/parsingdata/metal/token/Rep.java

core/src/main/java/io/parsingdata/metal/token/IterableToken.java

rdvdijk · 2018-08-24T13:33:55Z

core/src/main/java/io/parsingdata/metal/data/ParseState.java

@@ -36,43 +37,55 @@
    public final ParseGraph order;
    public final BigInteger offset;
    public final Source source;
+    public final ImmutableList<BigInteger> iterations;


Something that now could happen is that closeBranch(Token) is called with a Token that was not the one used for addBranch(Token). This would of course be a bug, but since these methods are public, we might need to guard for it. We could fix that by keeping track which token is used for the iteration. E.g. something like:

public final ImmutableList<Pair<Token, BigInteger>> iterations;

Whenever we call closeBranch(Token), we can verify that the Token of the current iteration is indeed the one being passed. We could even pass Token to iter() and be sure that we are iterating the expected Token (but that might be overkill).

(Note: We have a Pair class in Selection, but it is not generic.)

Good suggestion! I'm usually not a fan of using a Pair class, but I cannot think of an alternative, other then creating a new class, which would most likely be implemented as the Pair class. ;)

Should it in this case be an identity comparison instead of a (semantic) equality?

Oh that's a good point... If we want to really make sure we are using the same object, instead of just an equal one.

core/src/main/java/io/parsingdata/metal/token/IterableToken.java

rdvdijk · 2018-08-24T13:36:49Z

core/src/main/java/io/parsingdata/metal/data/ParseState.java

    }

    public static ParseState createFromByteStream(final ByteStream input) {
        return createFromByteStream(input, ZERO);
    }

    public ParseState addBranch(final Token token) {
-        return new ParseState(order.addBranch(token), source, offset);
+        if (token.isIterable()) {


This could be a oneliner... Does @jvdb approve of this heresy? 🤣

Yes, it could, but should it? ;) The code now clearly shows the difference between the two states, which will not be as clear if it is a oneliner. @jvdb will approve this, I'm sure! :D

To be entirely honest, seeing multiple identical addBranch()-invocations does hurt a little... But I'm not religious about this :)

Ok, so you both would prefer:

return new ParseState(order.addBranch(token), source, offset, token.isIterable() ? iterations.add(ZERO) : iterations);

?

I would prefer that yes 👍

jvdb

I was a little worried when looking at the top of the diff and saw the addition of a list to the ParseState. But it does make the implementation of CurrentIteration so much simpler (and more correct in corner cases) that it's absolutely worth the added data (which is going to be negligible in terms of memory usage/speed anyway).

I think @rdvdijk's point about checking that the correct Token is closed is a valid point though, so please let's have a look at doing that.

Furthermore, a very nice optimization of the iterable tokens by using a base class. The amount of red in the diff of the affected classes says enough!

I do hope however that we can fix the BetterCodeHub score though, so let's look at that as well.

In short: excellent work!!

ccreeten · 2018-08-28T15:17:42Z

core/src/main/java/io/parsingdata/metal/data/ParseState.java

        this.order = checkNotNull(order, "order");
        this.source = checkNotNull(source, "source");
        this.offset = checkNotNegative(offset, "offset");
+        this.iterations = checkNotNull(iterations, "iteration");


Minor, missing s.

ccreeten · 2018-08-28T15:21:41Z

core/src/main/java/io/parsingdata/metal/data/ParseState.java

+        return new ParseState(order.add(parseReference), source, offset, iterations);
+    }
+
+    public ParseState iter() {


iterate/addIteration?

Ok, iterate it is.

core/src/main/java/io/parsingdata/metal/expression/value/reference/CurrentIteration.java

ccreeten · 2018-08-28T15:25:11Z

core/src/main/java/io/parsingdata/metal/expression/value/reference/CurrentIteration.java

+/**
+ * A {@link ValueExpression} that represents the 0-based current iteration in an
+ * iterable {@link Token} (e.g. when inside a {@link Rep} or {@link RepN}).
+ */


Perhaps also mention it can be checked if a Token is iterable, using a method reference link?

ccreeten · 2018-08-28T15:25:39Z

core/src/main/java/io/parsingdata/metal/token/IterableToken.java

+
+    public final Token token;
+
+    IterableToken(String name, final Token token, Encoding encoding) {


Missing final.

ccreeten · 2018-08-28T15:27:19Z

core/src/main/java/io/parsingdata/metal/token/IterableToken.java

+        this.token = checkNotNull(token, "token");
+    }
+
+    protected final Optional<ParseState> parse(final Environment environment, final Function<Environment, Boolean> stopCondition, final Function<Environment, Optional<ParseState>> ifIterationFails) {


Function<Env, Boolean> = Predicate<Env> :) (unless you would want it to return a null)

core/src/main/java/io/parsingdata/metal/token/IterableToken.java

ccreeten · 2018-08-28T15:35:07Z

core/src/main/java/io/parsingdata/metal/token/RepN.java

-            .map(nextParseState -> intermediate(() -> iterate(environment.withParseState(nextParseState), count - 1)))
-            .orElseGet(() -> complete(Util::failure));
+        final BigInteger count = counts.head.get().asNumeric();
+        return parse(environment, env -> env.parseState.iterations.head.compareTo(count) >= 0, env -> failure());


Perhaps add a method like ParseState#currentIteration = iterations.head?

ccreeten · 2018-08-28T15:42:36Z

core/src/main/java/io/parsingdata/metal/token/IterableToken.java

+            return complete(() -> success(environment.parseState.closeBranch(this)));
+        }
+        return token
+                .parse(environment)


My head is a bit foggy, but isn't this an unsafe recursive call? If you would just nest iterable tokens which do not stop at the first iteration?

core/src/main/java/io/parsingdata/metal/expression/value/reference/CurrentIteration.java

core/src/main/java/io/parsingdata/metal/data/ParseState.java

core/src/main/java/io/parsingdata/metal/token/IterableToken.java

ccreeten · 2018-09-10T16:18:24Z

The updated current iteration implementation is very nicely done by the way 😄

core/src/main/java/io/parsingdata/metal/data/ParseState.java

core/src/main/java/io/parsingdata/metal/expression/value/reference/CurrentIteration.java

rdvdijk · 2018-09-12T10:38:23Z

core/src/test/java/io/parsingdata/metal/expression/value/reference/CurrentIterationTest.java

+            { "[0, 1] seq(!CURRENT_ITERATION, ...)", seq(VALUE_NOT_EQ_ITERATION, VALUE_NOT_EQ_ITERATION), stream(0, 1), enc(), true },
+            { "[0] !CURRENT_ITERATION", VALUE_NOT_EQ_ITERATION, stream(0), enc(), true },
+            { "[0 | 0, 1 | 0, 0, 2 | 0, 0, 0, 3] rep(CURRENT_ITERATION)", rep(def("value", add(CURRENT_ITERATION, con(1)), eqNum(CURRENT_ITERATION))), stream(0, 0, 1, 0, 0, 2, 0, 0, 0, 3), enc(), true },
+            { "[1, 1, 0, 1 | 0 | 2 | 3] repn=4(size), rep(def(any, sizeRef(CURRENT_INDEX)))", seq(repn(def("size", 1), con(4)), rep(def("value", nth(ref("size"), CURRENT_ITERATION)))), stream(1, 1, 0, 1, 0, 2, 3), enc(), true },


Please let me know when you've added that test 👍

…and CURRENT_ITERATION behaviour inside an IterableToken.

@rdvdijk

…d javadoc. Based on review comments from @rdvdijk and @ccreeten.

…mmutablePair class.

core/src/main/java/io/parsingdata/metal/data/ImmutablePair.java

core/src/test/java/io/parsingdata/metal/EqualityTest.java

core/src/main/java/io/parsingdata/metal/data/ParseState.java

core/src/main/java/io/parsingdata/metal/data/ImmutablePair.java

jvdb and others added 15 commits July 2, 2018 22:53

#236: Basic, compiling and failing tests for the CurrentIndex ValueEx…

e725c68

…pression.

#236: Added test for another Token that needs to be included: While.

e6b2f37

#236: Basic implementation and tests.

0e12551

#236: Added (failing) test for using CurrentIndex in a nested iterable.

dac4afb

#236: Improved currentIndex implementation by looking for the deepest…

b449cff

… iterable and counting siblings a long the way.

#236: Renamed CurrentIndex to CurrentIteration to better reflect what…

a294916

… it represents. Cleaned up test a bit.

#236: Fixed one of the CurrentIteration tests.

ec291c2

#236: Simplified implementation of CurrentIteration, which also impro…

c3c961e

…ves coverage.

#236: Improved test coverage for CurrentIteration.

cab9c3e

#236: Converted CurrentIteration to use trampolines for recursion.

3450821

#236: Added unit test for CurrentIteration.

0d2401b

#236: Keep track of the last iterable instead of the last iteration a…

ad98634

…nd count the iterations of the iterable afterwards.

#236: Small refactorings.

f8f5034

#236: Make CurrentIteration return empty value when referencing outsi…

a17967c

…de an iterable scope.

#236: More tests. Unfortunately, no way to more precisely check for e…

b2961aa

…mpty.

mvanaken requested review from jvdb and rdvdijk July 31, 2018 21:52

mvanaken added this to the 7.2.0 milestone Jul 31, 2018

mvanaken requested a review from ccreeten August 1, 2018 06:48

ccreeten requested changes Aug 1, 2018

View reviewed changes

ccreeten reviewed Aug 2, 2018

View reviewed changes

mvanaken mentioned this pull request Aug 3, 2018

Parameterized parse verification #244

Merged

mvanaken added 2 commits August 20, 2018 23:47

#236: New implementation for current iteration, which is now tracked …

6fa43c5

…within ParseState, instead of extracting it out of the ParseGraph. The iteration is now independent on the parse result.

#236: Removed redundant import.

ebfcf71

rdvdijk requested changes Aug 24, 2018

View reviewed changes

mvanaken added 2 commits August 24, 2018 23:48

#236: Processed review comments of @rdvdijk.

6b72849

#236: Included ToString test for ParseState with iterations.

fe71ac2

jvdb approved these changes Aug 28, 2018

View reviewed changes

ccreeten reviewed Aug 28, 2018

View reviewed changes

ccreeten reviewed Aug 29, 2018

View reviewed changes

core/src/main/java/io/parsingdata/metal/expression/value/reference/CurrentIteration.java Show resolved Hide resolved

mvanaken and others added 3 commits September 3, 2018 10:26

#236: Processed review comments from @rdvdijk @ccreeten.

8f9d2c3

#236: Fixed a failing test.

97a66c5

#236: Added test to repair test coverage.

5442e7a

ccreeten reviewed Sep 10, 2018

View reviewed changes

core/src/main/java/io/parsingdata/metal/data/ParseState.java Outdated Show resolved Hide resolved

ccreeten reviewed Sep 10, 2018

View reviewed changes

core/src/main/java/io/parsingdata/metal/token/IterableToken.java Show resolved Hide resolved

rdvdijk requested changes Sep 12, 2018

View reviewed changes

jvdb added 4 commits September 15, 2018 14:58

236: Improved CurrentIterationTest.

93716c3

236: Improved CurrentIterationTest to actually verify zero-sized Def …

fd803d8

…and CURRENT_ITERATION behaviour inside an IterableToken.

#236: Replaced null-check with isEmpty()-call, added newline, improve…

c63f84c

…d javadoc. Based on review comments from @rdvdijk and @ccreeten.

#236: Removed dependency on the javafx Pair class by adding trivial I…

840c354

…mmutablePair class.

rdvdijk approved these changes Sep 17, 2018

View reviewed changes

core/src/main/java/io/parsingdata/metal/data/ImmutablePair.java Show resolved Hide resolved

core/src/test/java/io/parsingdata/metal/EqualityTest.java Show resolved Hide resolved

core/src/main/java/io/parsingdata/metal/data/ParseState.java Outdated Show resolved Hide resolved

ccreeten reviewed Sep 17, 2018

View reviewed changes

core/src/main/java/io/parsingdata/metal/data/ImmutablePair.java Show resolved Hide resolved

ccreeten approved these changes Sep 17, 2018

View reviewed changes

jvdb merged commit 762b9f1 into master Sep 17, 2018

jvdb deleted the current-index branch September 17, 2018 12:58

jvdb removed this from the 8.0.0 milestone Sep 17, 2018

		@@ -0,0 +1,84 @@
		/*
		* Copyright 2013-2016 Netherlands Forensic Institute

@@ @@ -1,5 +1,6 @@ @@
               # Maven
               target/
+              out/


		public final Token token;

		IterableToken(String name, final Token token, Encoding encoding) {

Current iteration #242

Current iteration #242

Conversation

mvanaken commented Jul 31, 2018 • edited by jvdb Loading

codecov bot commented Jul 31, 2018 • edited Loading

Codecov Report

ccreeten Aug 1, 2018 • edited Loading

Choose a reason for hiding this comment

mvanaken Aug 2, 2018 • edited Loading

Choose a reason for hiding this comment

mvanaken Aug 2, 2018 • edited Loading

Choose a reason for hiding this comment

ccreeten Aug 2, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rdvdijk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mvanaken Aug 24, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mvanaken Aug 24, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jvdb Sep 15, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jvdb left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ccreeten commented Sep 10, 2018

Choose a reason for hiding this comment

mvanaken commented Jul 31, 2018 •

edited by jvdb

Loading

codecov bot commented Jul 31, 2018 •

edited

Loading

ccreeten Aug 1, 2018 •

edited

Loading

mvanaken Aug 2, 2018 •

edited

Loading

mvanaken Aug 2, 2018 •

edited

Loading

ccreeten Aug 2, 2018 •

edited

Loading

mvanaken Aug 24, 2018 •

edited

Loading

mvanaken Aug 24, 2018 •

edited

Loading

jvdb Sep 15, 2018 •

edited

Loading

jvdb left a comment •

edited

Loading