Templated LayoutBuilder #1494

ManasviGoyal · 2022-06-08T10:13:31Z

To develop a templated GrowableBuffer and the Layout builders that use this buffer. There will be two headers: GrowableBuffer.h and LayoutBuilder.h. This will allow using them in an external project without linking to the awkward libraries.

This can be a separate PR:
Documentation of LayoutBuilder.h

ianna

Great! Please, see minor comments. Thanks.

src/awkward/cpp-headers/GrowableBuffer.h

codecov · 2022-06-08T10:42:37Z

Codecov Report

Merging #1494 (8531563) into main (78a6535) will increase coverage by 0.23%.
The diff coverage is 60.81%.

Impacted Files	Coverage Δ
src/awkward/_v2/contents/indexedoptionarray.py	`89.14% <54.54%> (-0.70%)`	⬇️
src/awkward/_v2/highlevel.py	`70.77% <57.60%> (-2.76%)`	⬇️
src/awkward/_v2/_connect/numba/arrayview.py	`96.76% <100.00%> (ø)`
src/awkward/_v2/contents/content.py	`76.61% <100.00%> (ø)`
src/awkward/_v2/operations/ak_copy.py	`100.00% <100.00%> (ø)`
src/awkward/_v2/operations/ak_is_none.py	`96.55% <100.00%> (+0.39%)`	⬆️
src/awkward/_v2/record.py	`76.86% <100.00%> (-0.18%)`	⬇️
src/awkward/_v2/types/recordtype.py	`86.72% <100.00%> (-0.35%)`	⬇️
src/awkward/_v2/types/numpytype.py	`88.09% <0.00%> (-1.20%)`	⬇️
src/awkward/_v2/contents/bitmaskedarray.py	`66.41% <0.00%> (-0.76%)`	⬇️
... and 17 more

ManasviGoyal · 2022-06-08T10:47:35Z

Great! Please, see minor comments. Thanks.

Done. Should I add the descriptions of the methods too?

ianna · 2022-06-08T12:04:13Z

Great! Please, see minor comments. Thanks.

Done. Should I add the descriptions of the methods too?

Yes, please, it's a good idea!

jpivarski · 2022-06-08T16:19:02Z

This is looking good! One thing, though: the GrowableBuffer will always (?) be used by external code that wants to do "copy to an external buffer" and "concatenation" as one operation. That's why we think the panels approach is a step up in performance: we know that external code will have to copy the data out of a GrowableBuffer so that that external code can own it, and if we have to do a copy anyway, we might as well concatenate in the same operation. With concatenation being "free," having no extra performance cost, that's why we can let the data be discontiguous as it grows and letting it be discontiguous as it grows lets us avoid more expensive ways of growing a buffer (reallocating and copying).

So the class needs to have an interface like

void concatenate(PRIMITIVE* external_pointer) const noexcept {
    // always iterates over panels, copying data into external_pointer
    // assumes that the buffer; external code should have allocated it with the right length()
    // this function does not change any of the GrowableBuffer's internal panels; they're left as-is
}

for external code to be able to use concatenate-and-copy in one operation.

For use in ArrayBuilder, it will need zeros, empty, arange constructors (see original GrowableBuffer). For use in AwkwardForth as a replacement for ForthOutputBuffer, it will need another suite of methods.

ArrayBuilder will be an immediate use-case, AwkwardForth is down the road. Only worry about the ArrayBuilder methods for now.

ianna

This looks good! Please, see my comments inlined.

src/awkward/_v2/cpp-headers/GrowableBuffer.h

src/awkward/_v2/cpp-headers/LayoutBuilder.h

ianna

Thanks! This looks good. The tests run.
@jpivarski - please, have a look. Thanks!

ianna · 2022-07-05T09:59:53Z

@jpivarski - I've added a cmake configuration to run the cpp-header only tests here. It's a separate PR because there are no hooks to pytest yet.

ianna · 2022-07-05T11:18:42Z

@ManasviGoyal - please, cherry-pick this commit that clears the warnings when the tests are built with the project flags on MacOS. Thanks.

ManasviGoyal · 2022-07-05T12:28:47Z

@ManasviGoyal - please, cherry-pick this commit that clears the warnings when the tests are built with the project flags on MacOS. Thanks.

Done!

ianna · 2022-07-05T15:42:54Z

@ManasviGoyal - I've stared testing the new GrowableBuffer implementation on an ArrayBuilder: see #1529

I think, we need to extend the GrowableBuffer API with a fill method that would take one (possibly multi-pannel) GrowableBuffer<FROM_PRIMITIVE> and make another (one panel) GrowableBuffer<TO_PRIMITIVE>.

There are several cases where it is needed for building arrays. Here is one example how a current one is used:

    GrowableBuffer<std::complex<double>> buffer =
      GrowableBuffer<std::complex<double>>::empty(initial, old.reserved());
    int64_t* oldraw = old.ptr().get();
    std::complex<double>* newraw = buffer.ptr().get();
    for (size_t i = 0;  i < 2*old.length();  i++) {
      newraw[i] = {static_cast<double>(oldraw[i]), 0};
    }
    buffer.set_length(old.length());
    old.clear();

jpivarski

The GrowableBuffer is great and I would sign off on it right now.

The LayoutBuilder, on the other hand, is about halfway between the simple/fast tool that it could be and where ArrayBuilder is now. I have a lot of inline comments, but I think I could explain what I'm thinking a little better with a prototype. Most of this code can be used as-is—what I'll show with the prototype is a way to prune off some methods that are getting in the way and show how it can all fit together. I'll write it up in Python because it will be faster for me to write it that way; you have a good handle on the C++isms, and I think you'll have no trouble translating.

I'll post that here as soon as I can.

If you want to split this PR into one PR for GrowableBuffer and another for LayoutBuilder, then we'll be able to merge the GrowableBuffer part right away.

src/awkward/_v2/cpp-headers/LayoutBuilder.h

tests-cpp/test-layout-builder.cpp

ManasviGoyal · 2022-07-06T00:34:30Z

The GrowableBuffer is great and I would sign off on it right now.

Great! Thanks.

The LayoutBuilder, on the other hand, is about halfway between the simple/fast tool that it could be and where ArrayBuilder is now. I have a lot of inline comments, but I think I could explain what I'm thinking a little better with a prototype. Most of this code can be used as-is—what I'll show with the prototype is a way to prune off some methods that are getting in the way and show how it can all fit together. I'll write it up in Python because it will be faster for me to write it that way; you have a good handle on the C++isms, and I think you'll have no trouble translating.

Thanks. The prototype really gives a better idea to improve upon the implementation. I'll update the PR with the changes that you suggested.

If you want to split this PR into one PR for GrowableBuffer and another for LayoutBuilder, then we'll be able to merge the GrowableBuffer part right away.

Yes, it will be better to split the PR so that GrowableBuffer can be merged. I'll do the same. Thanks.

jpivarski · 2022-07-06T02:21:44Z

I finished writing the prototype. Along the way, I realized that there are some subtle issues, such as dealing with records that have no fields and regular arrays with inner size 0. There also needs to be a different builder for records with named fields ("records") and records whose fields are not named ("tuples").

I ran into some hard choices when trying to write Python that is intended to illustrate how it would be implemented in C++. Specifically, there were a few places where the C++ should pass references to integers and strings to be able to modify them remotely. You just can't do that in Python. To simulate this, I made a

class Ref:
    def __init__(self, value):
        self.value = value

because Python passes all mutable objects as references, so "reference.value = 3" means

// reference has C++ type &int
reference = 3;

I hope my meaning is clear.

I'm looking forward to the full C++ version of all of this!

ManasviGoyal · 2022-07-06T07:59:10Z

I finished writing the prototype. Along the way, I realized that there are some subtle issues, such as dealing with records that have no fields and regular arrays with inner size 0. There also needs to be a different builder for records with named fields ("records") and records whose fields are not named ("tuples").

I ran into some hard choices when trying to write Python that is intended to illustrate how it would be implemented in C++. Specifically, there were a few places where the C++ should pass references to integers and strings to be able to modify them remotely. You just can't do that in Python. To simulate this, I made a
class Ref:
    def __init__(self, value):
        self.value = value
because Python passes all mutable objects as references, so "reference.value = 3" means
// reference has C++ type &int
reference = 3;
I hope my meaning is clear.

I'm looking forward to the full C++ version of all of this!

Yes. It is clear. I'll make the requested changes and update the soon. Thanks!

for more information, see https://pre-commit.ci

ianna

@ManasviGoyal and @jpivarski - the PR looks good. It implements all types and their tests defined in Jim's prototype. There are some places where I'd suggest to use a type aliases. Such as:

using Contents = typename std::tuple<BUILDERS...>;

and declare:

Contents contents_;

and more tests are needed to check that parameters are correctly placed in the forms.

I'll do a more thorough review after @ManasviGoyal has a chance to do any final touches.

src/awkward/_v2/cpp-headers/awkward/LayoutBuilder.h

jpivarski

Very nice! There are just a few things to fix, described inline.

jpivarski · 2022-07-22T20:18:03Z

src/awkward/_v2/cpp-headers/awkward/GrowableBuffer.h

+    PRIMITIVE
+    last() const {
+      if (ptr_->length() == 0) {
+        throw std::runtime_error("Buffer is empty");


Eventually, these functions should be noexcept and have some default action for such cases. However, doing that after a performance-test framework is set up would be more useful, so that we can see how much it matters.

src/awkward/_v2/cpp-headers/awkward/LayoutBuilder.h

jpivarski · 2022-07-22T20:40:19Z

src/awkward/_v2/cpp-headers/awkward/LayoutBuilder.h

+    Builder builder;
+  };
+
+  template <unsigned INITIAL, typename PRIMITIVE>


Why is the initial size of the buffer a compile-time constant?

This should become a runtime value, passed down through instance constructors, not template parameters.

With it in the template parameter, every C++ user is going to have to specify INITIAL at every node of the tree. That's a lot of boilerplate for a value they usually don't care about. They'll usually take a default that gets passed in from above, or through a BuilderOptions.

The reason it's a parameter at all, instead of hard-coded into the code, is so that we have some leverage when doing performance tests. Users, even C++ users, will trust whatever optimal value we come up with from those performance tests. They're not going to want to have to type it.

The users will not see it - we can type alias it as in the test examples. The reason why we need it as a template parameter - we use the default constructors. The builders are allocated on the stack and so their GrowableBuffers. We could change it, but let’s discuss it on Wednesday first. Thanks

Okay, the initial GrowableBuffer size has to be a compile-time constant for a C++ reason: you need to use default constructors. (Why is that?)

And if GrowableBuffers are parameterized by more than one parameter—if they need to have a different first panel size from subsequent panel sizes as we discussed in the last meeting—do all of those have to become template parameters?

If this is the case, then we need to provide type aliases as part of the header-only package, with some choice of GrowableBuffer parameters hard-coded. C++ users of this package need to be able to say LayoutBuilder::Numpy<float> without having to set up an alias on their own.

src/awkward/_v2/cpp-headers/awkward/utils.h

tests-cpp/test_1494-layout-builder.cpp

src/awkward/_v2/cpp-headers/awkward/LayoutBuilder.h

ManasviGoyal · 2022-07-22T22:47:18Z

@ManasviGoyal and @jpivarski - the PR looks good. It implements all types and their tests defined in Jim's prototype. There are some places where I'd suggest to use a type aliases. Such as:
using Contents = typename std::tuple<BUILDERS...>;
and declare:
Contents contents_;
and more tests are needed to check that parameters are correctly placed in the forms.

I'll do a more thorough review after @ManasviGoyal has a chance to do any final touches.

@ianna What kind of parameters the users might use? One I think will be "__array__": "string". Are there any other?

jpivarski · 2022-07-22T22:52:55Z

I forgot to check that all the node types can have parameters, all different from each other. Some of them, like __array__ == "string", are functional, having meanings that will be used by Awkward Array, but they can be anything at all. Some applications put documentation strings in there, and others have general metadata, like units.

At the C++ level, the parameters can just be a string. In Python, it will have to resolve to something JSON-formatted, but the C++ doesn't have to enforce that.

ianna

@ManasviGoyal - beginning identifiers with an underscore is considered poor programming style.

src/awkward/_v2/cpp-headers/awkward/GrowableBuffer.h

src/awkward/_v2/cpp-headers/awkward/LayoutBuilder.h

ManasviGoyal · 2022-07-25T16:53:26Z

Hi, @jpivarski. Should we keep the type of offsets, starts, stops, mask, etc. fixed in the code or should we make them templated parameters so that users can use different types as needed?

jpivarski · 2022-07-25T18:13:33Z

Hi, @jpivarski. Should we keep the type of offsets, starts, stops, mask, etc. fixed in the code or should we make them templated parameters so that users can use different types as needed?

The types of all of these Indexes (offsets, starts, stops, mask, etc.) should be templated. Most of them can be int32, uint32, or int64, so LayoutBuilder needs the flexibility to switch between these. The exceptions are ByteMasked masks, which only have one option, int8, BitMasked masks, which have only one option, uint8, and Union tags, which only have one option, int8.

You could check the v1 Content subclasses, in src/libawkward/array/*.cc, to see which templates are actually instantiated. LayoutBuilder should be reproducing the same set of types.

ianna · 2022-07-25T21:03:37Z

Hi, @jpivarski. Should we keep the type of offsets, starts, stops, mask, etc. fixed in the code or should we make them templated parameters so that users can use different types as needed?

The types of all of these Indexes (offsets, starts, stops, mask, etc.) should be templated. Most of them can be int32, uint32, or int64, so LayoutBuilder needs the flexibility to switch between these. The exceptions are ByteMasked masks, which only have one option, int8, BitMasked masks, which have only one option, uint8, and Union tags, which only have one option, int8.

You could check the v1 Content subclasses, in src/libawkward/array/*.cc, to see which templates are actually instantiated. LayoutBuilder should be reproducing the same set of types.

I'd suggest that it goes to the next PR.

ManasviGoyal · 2022-07-25T21:10:00Z

Hi, @jpivarski. Should we keep the type of offsets, starts, stops, mask, etc. fixed in the code or should we make them templated parameters so that users can use different types as needed?

The types of all of these Indexes (offsets, starts, stops, mask, etc.) should be templated. Most of them can be int32, uint32, or int64, so LayoutBuilder needs the flexibility to switch between these. The exceptions are ByteMasked masks, which only have one option, int8, BitMasked masks, which have only one option, uint8, and Union tags, which only have one option, int8.
You could check the v1 Content subclasses, in src/libawkward/array/*.cc, to see which templates are actually instantiated. LayoutBuilder should be reproducing the same set of types.

I'd suggest that it goes to the next PR.

Actually, I already added the changes.

ianna · 2022-07-25T21:12:38Z

Hi, @jpivarski. Should we keep the type of offsets, starts, stops, mask, etc. fixed in the code or should we make them templated parameters so that users can use different types as needed?

The types of all of these Indexes (offsets, starts, stops, mask, etc.) should be templated. Most of them can be int32, uint32, or int64, so LayoutBuilder needs the flexibility to switch between these. The exceptions are ByteMasked masks, which only have one option, int8, BitMasked masks, which have only one option, uint8, and Union tags, which only have one option, int8.
You could check the v1 Content subclasses, in src/libawkward/array/*.cc, to see which templates are actually instantiated. LayoutBuilder should be reproducing the same set of types.

I'd suggest that it goes to the next PR.

Actually, I already added the changes.

Fantastic! Is it ready for review? Thanks!

ManasviGoyal · 2022-07-25T21:20:25Z

Hi, @jpivarski. Should we keep the type of offsets, starts, stops, mask, etc. fixed in the code or should we make them templated parameters so that users can use different types as needed?

The types of all of these Indexes (offsets, starts, stops, mask, etc.) should be templated. Most of them can be int32, uint32, or int64, so LayoutBuilder needs the flexibility to switch between these. The exceptions are ByteMasked masks, which only have one option, int8, BitMasked masks, which have only one option, uint8, and Union tags, which only have one option, int8.
You could check the v1 Content subclasses, in src/libawkward/array/*.cc, to see which templates are actually instantiated. LayoutBuilder should be reproducing the same set of types.

I'd suggest that it goes to the next PR.

Actually, I already added the changes.

Fantastic! Is it ready for review? Thanks!

Besides the BitMasked part that we were discussing, yes, everything else is ready for review.

ianna · 2022-07-25T21:23:28Z

Hi, @jpivarski. Should we keep the type of offsets, starts, stops, mask, etc. fixed in the code or should we make them templated parameters so that users can use different types as needed?

The types of all of these Indexes (offsets, starts, stops, mask, etc.) should be templated. Most of them can be int32, uint32, or int64, so LayoutBuilder needs the flexibility to switch between these. The exceptions are ByteMasked masks, which only have one option, int8, BitMasked masks, which have only one option, uint8, and Union tags, which only have one option, int8.
You could check the v1 Content subclasses, in src/libawkward/array/*.cc, to see which templates are actually instantiated. LayoutBuilder should be reproducing the same set of types.

I'd suggest that it goes to the next PR.

Actually, I already added the changes.

Fantastic! Is it ready for review? Thanks!

Besides the BitMasked part that we were discussing, yes, everything else is ready for review.

Thanks! Yes, I have a solution for that, but let's do it in the next PR.

jpivarski

I still have a question about including GrowableBuffer parameters as compile-time template parameters, but this is looking good for merging now. Any minor issues can be picked up in later PRs.

jpivarski · 2022-07-25T21:23:09Z

src/awkward/_v2/cpp-headers/awkward/LayoutBuilder.h

+    Builder builder;
+  };
+
+  template <unsigned INITIAL, typename PRIMITIVE>


Okay, the initial GrowableBuffer size has to be a compile-time constant for a C++ reason: you need to use default constructors. (Why is that?)

And if GrowableBuffers are parameterized by more than one parameter—if they need to have a different first panel size from subsequent panel sizes as we discussed in the last meeting—do all of those have to become template parameters?

If this is the case, then we need to provide type aliases as part of the header-only package, with some choice of GrowableBuffer parameters hard-coded. C++ users of this package need to be able to say LayoutBuilder::Numpy<float> without having to set up an alias on their own.

ianna · 2022-07-25T22:07:20Z

I still have a question about including GrowableBuffer parameters as compile-time template parameters, but this is looking good for merging now. Any minor issues can be picked up in later PRs.

Thanks, I'll merge this one and rebase #1560 that restores BuilderOptions.

ianna

Looks good! Thanks.

* Added GrowableBuffer.h * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Added namespace * added methods and description * overloaded append method for adding an array * changed path of GrowableBuffer.h * start working on LayoutBuilder.h * some tests for LayoutBuilder.h * remove templete parameter for offset in ListOffsetLayoutBuilder * added forms * modified RecordLayoutBuilder and some other changes * modified previous tests and added new tests * changes to fix form * changes in layout builder and growable buffer * change back * fixed ListOffsetLayoutBuilder for nested lists * added ListLayoutBuilder * added IndexLayoutBuilder * added UnmaskedLayoutBuilder * added IndexedOptionLayoutBuilder * changed back to vector of unique_ptr * fixed clear() and dump() in recordlayoutbuilder * fixed form and indexedlayoutbuilder index type * fixed some tests and added more tests * added test-listoffset-of-numpy * introduce form_key_id parameter * add licence info * nontype template id parameter * added default value for forms and other miscellaneous changes * overload append method and fix indexedoptionlayoutbuilder * modified and added more tests for different builders * fixed the order of methods * removed redundant code * fix error in type_to_form() * modify to_buffers, remove dump() and other changes * add dump() * fix ListOffsetLayoutBuilder length() * add EmptyLayoutBuilder * addressed Ianna's comments * removed extra headers * cleanup warnings * Start writing prototype for all Forms. * Just RecordForm and UnionForm are left. * Finished RecordForm and UnionForm. * Correctly handling records/tuples with no fields and regular arrays of size 0. * Nicely formatted. * add more types to fix NumpyLayoutBuilder form * remove begun_ * fix append functions and rename append array as extend * make methods noexcept and fix tests * rename builders and add sub namespace * added set_id method in builders * added is_valid method * added buffer_nbytes method * added parameters * some fixes * added RegularLayoutBuilder and other changes * added ByteMaskedLayoutBuilder * added EmptyRecordLayoutBuilder and set_parameters * added BitMasked * added BitMaskedLayoutBuilder * update BitMasked * fix merge issues * misc changes * add layout builder test to cmake * add field and field_append to Record, restructure and cleanup * remove variant and builder pointers * remove -> syntax, use . * fix record and modify tests * add IndexedOption_Record test * fix record and modify tests * fix headers and method names * use enum and user-defined map to std::string for the field names * is_valid for record * use error std::string for validity checks * add Tuple and its test * add Union and a test * fix union and test * add union form and test * test tuple * fixes and cleanup * remove underscore * remove append method from class Field * fix form parameters and add tests * add current_length() * templated builder index and fixed form * fix include path Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: Ianna Osborne <ianna.osborne@cern.ch> Co-authored-by: Jim Pivarski <jpivarski@gmail.com>

ManasviGoyal marked this pull request as draft June 8, 2022 10:20

ianna requested changes Jun 8, 2022

View reviewed changes

src/awkward/cpp-headers/GrowableBuffer.h Outdated Show resolved Hide resolved

src/awkward/cpp-headers/GrowableBuffer.h Outdated Show resolved Hide resolved

src/awkward/cpp-headers/GrowableBuffer.h Outdated Show resolved Hide resolved

ManasviGoyal force-pushed the manasvi/templeted_growablebuffer_and_layoutbuilder branch from 1ada767 to 764c20f Compare June 19, 2022 19:55

This was referenced Jun 30, 2022

modified the implementation of GrowableBuffer to use multiple Panels #1479

Closed

start working on growable buffer #1472

Closed

ManasviGoyal marked this pull request as ready for review July 4, 2022 09:59

ManasviGoyal requested a review from ianna July 4, 2022 10:00

ianna requested changes Jul 4, 2022

View reviewed changes

ianna approved these changes Jul 5, 2022

View reviewed changes

ianna requested a review from jpivarski July 5, 2022 09:53

ianna mentioned this pull request Jul 5, 2022

array builder with new growable buffer #1529

Closed

jpivarski requested changes Jul 5, 2022

View reviewed changes

ManasviGoyal marked this pull request as draft July 6, 2022 01:19

jpivarski changed the title ~~Templated GrowableBuffer and LayoutBuilder~~ Templated LayoutBuilder Jul 6, 2022

ManasviGoyal and others added 5 commits July 7, 2022 20:32

Added GrowableBuffer.h

dace9d8

[pre-commit.ci] auto fixes from pre-commit.com hooks

da94ff3

for more information, see https://pre-commit.ci

Added namespace

629643b

added methods and description

0dc9e79

overloaded append method for adding an array

28e38f3

ianna added 2 commits July 22, 2022 15:45

add union form and test

904c6fd

test tuple

59cc0c5

ianna reviewed Jul 22, 2022

View reviewed changes

src/awkward/_v2/cpp-headers/awkward/LayoutBuilder.h Outdated Show resolved Hide resolved

ianna marked this pull request as ready for review July 22, 2022 15:04

ianna requested a review from jpivarski July 22, 2022 15:04

jpivarski requested changes Jul 22, 2022

View reviewed changes

ManasviGoyal added 3 commits July 23, 2022 03:24

fixes and cleanup

ad28b1f

remove underscore

fe259df

remove append method from class Field

75c2e72

fix form parameters and add tests

bb5f246

ianna requested changes Jul 23, 2022

View reviewed changes

src/awkward/_v2/cpp-headers/awkward/GrowableBuffer.h Outdated Show resolved Hide resolved

src/awkward/_v2/cpp-headers/awkward/LayoutBuilder.h Outdated Show resolved Hide resolved

src/awkward/_v2/cpp-headers/awkward/LayoutBuilder.h Outdated Show resolved Hide resolved

ManasviGoyal added 2 commits July 26, 2022 02:33

add current_length()

f05489e

templated builder index and fixed form

4bd2418

fix include path

8531563

jpivarski approved these changes Jul 25, 2022

View reviewed changes

ianna approved these changes Jul 25, 2022

View reviewed changes

ianna merged commit f18526c into main Jul 25, 2022

ianna deleted the manasvi/templeted_growablebuffer_and_layoutbuilder branch July 25, 2022 22:10

jpivarski mentioned this pull request Nov 4, 2022

chore: remove v2 Python highlevel LayoutBuilder from main-v1. #1863

Merged

Templated LayoutBuilder #1494

Templated LayoutBuilder #1494

Conversation

ManasviGoyal commented Jun 8, 2022 • edited Loading

ianna left a comment

Choose a reason for hiding this comment

codecov bot commented Jun 8, 2022 • edited Loading

Codecov Report

ManasviGoyal commented Jun 8, 2022

ianna commented Jun 8, 2022 • edited Loading

jpivarski commented Jun 8, 2022

ianna left a comment

Choose a reason for hiding this comment

ianna left a comment

Choose a reason for hiding this comment

ianna commented Jul 5, 2022

ianna commented Jul 5, 2022

ManasviGoyal commented Jul 5, 2022

ianna commented Jul 5, 2022

jpivarski left a comment

Choose a reason for hiding this comment

ManasviGoyal commented Jul 6, 2022

jpivarski commented Jul 6, 2022

ManasviGoyal commented Jul 6, 2022

ianna left a comment

Choose a reason for hiding this comment

jpivarski left a comment

Choose a reason for hiding this comment

jpivarski Jul 22, 2022

Choose a reason for hiding this comment

jpivarski Jul 22, 2022

Choose a reason for hiding this comment

ianna Jul 23, 2022

Choose a reason for hiding this comment

jpivarski Jul 25, 2022

Choose a reason for hiding this comment

ManasviGoyal commented Jul 22, 2022 • edited Loading

jpivarski commented Jul 22, 2022

ianna left a comment

Choose a reason for hiding this comment

ManasviGoyal commented Jul 25, 2022

jpivarski commented Jul 25, 2022

ianna commented Jul 25, 2022

ManasviGoyal commented Jul 25, 2022

ianna commented Jul 25, 2022 • edited by ManasviGoyal Loading

ManasviGoyal commented Jul 25, 2022

ianna commented Jul 25, 2022

jpivarski left a comment

Choose a reason for hiding this comment

jpivarski Jul 25, 2022

Choose a reason for hiding this comment

ianna commented Jul 25, 2022

ianna left a comment

Choose a reason for hiding this comment

ManasviGoyal commented Jun 8, 2022 •

edited

Loading

codecov bot commented Jun 8, 2022 •

edited

Loading

ianna commented Jun 8, 2022 •

edited

Loading

ManasviGoyal commented Jul 22, 2022 •

edited

Loading

ianna commented Jul 25, 2022 •

edited by ManasviGoyal

Loading