Add subset #2496

bkamins · 2020-10-22T10:56:45Z

This follows #2314 discussion.

bkamins · 2020-10-22T10:58:11Z

Let us confirm if the functionality is as we like it before I write the tests. Thank you!

pdeffebach

Thanks for implementing this!

I don't think you've gotten all the missing logic worked out yet.

julia> df = DataFrame(a = [1, 1, 1, 2, 2, 2, 2], b = [1, 1, 2, 101, 101, 102, missing]);

julia> where(df, :b => (t -> t .> mean(t)))
ERROR: MethodError: no method matching &(::Missing)

I think this only shows up when we return exactly one column that contains missing values. Proabably a missing method for (&)(missing)

docs/src/man/comparisons.md

src/abstractdataframe/where.jl

matthieugomez · 2020-10-23T16:51:43Z

This looks great! I just have two comments about missing values.

I'm not a fan of introducing a new kwarg dropmissing = true. As I said in another thread, I don't like R multiplication of na.rm, na.omit etc. I think it'd be better to have no keyword argument at all.

Also, I support dropping rows with missing values because that is why what R/sql/stata do. But @nalimilan was concerned about it, so maybe it would be worth having a vote somewhere to make sure others agree.

bkamins · 2020-10-23T18:12:03Z

Thank you both for looking into it. Indeed there are some rough edges - thank you for catching them (such things happen if tests are not written yet)

(&)(missing) error

This is exactly the reason. I will fix this.

Also, I support dropping rows with missing values because that is why what R/sql/stata do.

I think we should drop them (but clearly indicate that we behave here differently than expected).

I'm not a fan of introducing a new kwarg dropmissing = true.

I would assume that it would be hardly used, so it is not that problematic hopefully. On the other hand having it makes, in particular, sure that users notice more easily that we have a non-standard behavior here.

In general - thank you for the feedback. I will fix the mistake, and let us wait for @nalimilan to comment when he has time (I would not put a vote on it - I think us four have enough understanding of the ecosystem to decide).

pdeffebach · 2020-10-23T18:15:27Z

w.r.t &. I used reduce(and, eachcol(df)) which I think might be better because it doesn't specialize on number of arguments.

bkamins · 2020-10-23T18:20:25Z

w.r.t &. I used reduce(and, eachcol(df))

This is less efficient as it will not be able to do broadcasting fusion (you will have allocations grow linearly with the number of conditions).

bkamins · 2020-10-23T18:30:52Z

see JuliaLang/julia#38157

bkamins · 2020-10-23T21:20:56Z

I have thought of pros and cons of dropping row vs erroring on missing.

The question is - if we error on missing how do we cleanly handle something like:

where(df, :x => ByRow(>=(1)), :y => ByRow(>=(2)))

assuming both :x and :y may contain missings.

You would have to write something like:

where(df, :x => x -> coalesce.(x .>= 1, false), :y => y -> coalesce.(y .>= 1, false))

which seems verbose (but indeed it is not the end of the world and at least it is explicit).
If we chose to error on missing by default then I think we do not need dropmissing kwarg, as then using coalesce seems fine for me.

By the way. Can you please comment what would be the recommended style of writing simple filters:

where(df, :x => ByRow(>=(1)), :y => ByRow(>=(2)))

or

where(df, :x => x -> x .>= 1, :y => y -> y .>= 1)

?

The benefit of:

where(df, :x => ByRow(>=(1)), :y => ByRow(>=(2)))

is that it is compiled once, while both:

where(df, :x => x -> x .>= 1, :y => y -> y .>= 1)
where(df, :x => x -> coalesce.(x .>= 1, false), :y => y -> coalesce.(y .>= 1, false))

would be compiled anew on every call.

bkamins · 2020-10-24T09:44:03Z

@pdeffebach + @matthieugomez : if you could spare some time it would be great if you could comment with examples similar to my above that you find typical use-cases, so that we have more hands-on material to make an informed decision what to do. Thank you!

bkamins · 2020-10-27T22:38:20Z

@nalimilan - do you have an opinion what we should do with handling of missing by where given the discussion?

nalimilan · 2020-10-30T09:39:16Z

Sorry I've given the priority to breaking issues. I think this one could wait for post-0.22 so that we have time to find the best design.

I think having a dropmissing/skipmissing keyword argument is nice as it's simpler to use than coalesce. I'm still not completely sure whether the default should be true or false (as I said I think we need to discuss a general plan for missing values first).

Regarding the name of that argument, dropmissing already exists in our API so it's not completely new, but I agree with @matthieugomez that since other functions take a skipmissing keyword argument it would be easier for users to be consistent.

src/abstractdataframe/where.jl

nalimilan · 2020-10-30T09:23:04Z

src/abstractdataframe/where.jl

+function where(df::AbstractDataFrame, @nospecialize(args...);
+               dropmissing::Bool=true, view::Bool=false)
+    row_selector = _get_where_conditions(df, args, dropmissing)
+    return view ? Base.view(df, row_selector, :) : df[row_selector, :]
+end


Probably worth using @inline to avoid the type instability, with @noinline in _get_where_conditions (with inference tests to prevent regressions). Same for the GroupedDataFrame method.

OK - I have added @inline. I keep this comment open to remember testing against it when we finalize the design.

The code is type unstable even with @inline and @noinline in _get_where_conditions. Do you think it can be resolved somehow? (and do you think it is so problematic given DataFrame is type unstable anyway?)

That's weird. We use this kind of pattern elsewhere and it works, right? Is row_selector correctly inferred?

@nalimilan - given we add ungroup kwarg I am not sure we can get type stability here, do we? (as now we have yet another option of the return value related to the second kwarg)

ungroup shouldn't really make things worse as long as the function is inlined and the value of arguments know at compile time. But if that doesn't work in the first place...

This is what I have now:

julia> @code_warntype subset(DataFrame(a=1:10), :a => ByRow(<(4)), view=false, skipmissing=false) Variables #unused#::Core.Compiler.Const(DataFrames.var"#subset##kw"(), false) @_2::NamedTuple{(:view, :skipmissing),Tuple{Bool,Bool}} @_3::Core.Compiler.Const(DataFrames.subset, false) df::DataFrame args::Tuple{Pair{Symbol,ByRow{Base.Fix2{typeof(<),Int64}}}} skipmissing::Bool view::Bool @_8::Bool @_9::Bool Body::Any 1 ── %1 = Base.haskey(@_2, :skipmissing)::Core.Compiler.Const(true, false) │ %1 │ %3 = Base.getindex(@_2, :skipmissing)::Bool │ %4 = (%3 isa DataFrames.Bool)::Core.Compiler.Const(true, false) │ %4 └─── goto #3 2 ── Core.Compiler.Const(:(%new(Core.TypeError, Symbol("keyword argument"), :skipmissing, DataFrames.Bool, %3)), false) └─── Core.Compiler.Const(:(Core.throw(%7)), false) 3 ┄─ (@_8 = %3) └─── goto #5 4 ── Core.Compiler.Const(:(@_8 = false), false) 5 ┄─ (skipmissing = @_8) │ %13 = Base.haskey(@_2, :view)::Core.Compiler.Const(true, false) │ %13 │ %15 = Base.getindex(@_2, :view)::Bool │ %16 = (%15 isa DataFrames.Bool)::Core.Compiler.Const(true, false) │ %16 └─── goto #7 6 ── Core.Compiler.Const(:(%new(Core.TypeError, Symbol("keyword argument"), :view, DataFrames.Bool, %15)), false) └─── Core.Compiler.Const(:(Core.throw(%19)), false) 7 ┄─ (@_9 = %15) └─── goto #9 8 ── Core.Compiler.Const(:(@_9 = false), false) 9 ┄─ (view = @_9) │ %25 = (:skipmissing, :view)::Core.Compiler.Const((:skipmissing, :view), false) │ %26 = Core.apply_type(Core.NamedTuple, %25)::Core.Compiler.Const(NamedTuple{(:skipmissing, :view),T} where T<:Tuple, false) │ %27 = Base.structdiff(@_2, %26)::Core.Compiler.Const(NamedTuple(), false) │ %28 = Base.pairs(%27)::Core.Compiler.Const(Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}(), false) │ %29 = Base.isempty(%28)::Core.Compiler.Const(true, false) │ %29 └─── goto #11 10 ─ Core.Compiler.Const(:(Core.tuple(@_2, @_3, df)), false) └─── Core.Compiler.Const(:(Core._apply_iterate(Base.iterate, Base.kwerr, %32, args)), false) 11 ┄ %34 = Core.tuple(skipmissing, view, @_3, df)::Core.Compiler.PartialStruct(Tuple{Bool,Bool,typeof(subset),DataFrame}, Any[Bool, Bool, Core.Compiler.Const(DataFrames.subset, false), DataFrame]) │ %35 = Core._apply_iterate(Base.iterate, DataFrames.:(var"#subset#406"), %34, args)::Any └─── return %35 julia> f() = subset(DataFrame(a=1:10), :a => ByRow(<(4)), view=false, skipmissing=false) f (generic function with 1 method) julia> @code_warntype f() Variables #self#::Core.Compiler.Const(f, false) Body::Any 1 ─ %1 = (1:10)::Core.Compiler.Const(1:10, false) │ %2 = (:a,)::Core.Compiler.Const((:a,), false) │ %3 = Core.apply_type(Core.NamedTuple, %2)::Core.Compiler.Const(NamedTuple{(:a,),T} where T<:Tuple, false) │ %4 = Core.tuple(%1)::Core.Compiler.Const((1:10,), false) │ %5 = (%3)(%4)::Core.Compiler.Const((a = 1:10,), false) │ %6 = Core.kwfunc(Main.DataFrame)::Core.Compiler.Const(Core.var"#Type##kw"(), false) │ %7 = (%6)(%5, Main.DataFrame)::DataFrame │ %8 = (<)(4)::Core.Compiler.Const(Base.Fix2{typeof(<),Int64}(<, 4), false) │ %9 = Main.ByRow(%8)::Core.Compiler.Const(ByRow{Base.Fix2{typeof(<),Int64}}(Base.Fix2{typeof(<),Int64}(<, 4)), false) │ %10 = (:a => %9)::Core.Compiler.Const(:a => ByRow{Base.Fix2{typeof(<),Int64}}(Base.Fix2{typeof(<),Int64}(<, 4)), false) │ %11 = (:view, :skipmissing)::Core.Compiler.Const((:view, :skipmissing), false) │ %12 = Core.apply_type(Core.NamedTuple, %11)::Core.Compiler.Const(NamedTuple{(:view, :skipmissing),T} where T<:Tuple, false) │ %13 = Core.tuple(false, false)::Core.Compiler.Const((false, false), false) │ %14 = (%12)(%13)::Core.Compiler.Const((view = false, skipmissing = false), false) │ %15 = Core.kwfunc(Main.subset)::Core.Compiler.Const(DataFrames.var"#subset##kw"(), false) │ %16 = (%15)(%14, Main.subset, %7, %10)::Any └── return %16

(not passing kwargs does not change this)

Maybe the reason is that we have a vararg function with @nospecialize?

removing @nospecialize did not change anything.

src/abstractdataframe/where.jl

bkamins · 2020-10-30T16:05:33Z

I think this one could wait for post-0.22 so that we have time to find the best design.

Sure - we can skip it for now to gather more feedback what would be best (especially concrete examples so that we can judge between both designs).

src/abstractdataframe/where.jl

bkamins · 2020-11-04T10:34:06Z

Given the discussion in #2417 I have changed my mind and think that dropmissing=false should be the default in DataFrames.jl.

However, what we should discuss I think is @pdeffebach thinks that DataFramesMeta.jl should use the dropmissing=true by default (and also then in other operations missings would be propagated). In this way we would have a different default in DataFrames.jl and DataFramesMeta.jl consistently (and users could choose what they prefer). Would that work?

pdeffebach · 2020-11-04T15:22:15Z

I have to admit that #2417 is a bit of a niche and tangential issue to base this decision on.

I am okay with a bifurcation in DataFramesMeta. I suppose I will probably start out with mimicking DataFrames and then change it if enough people complain?

This really underscores how we need to

Use :x instead of x for lhs assignment, which opens the door for
Allowing keyword arguments to be passed.

Then it matters less what the default behavior in @where is. The user can always control it.

bkamins · 2020-12-08T17:11:41Z

I would like to revive this PR and make a decision:

do we need where (I vote yes); here the only discussion could be that where is also a keyword in Julia Base, so e.g. some users might be confused and it is very likely that some IDEs might be confused with highlighting
if we add where what should be the default for dropmissing kwarg (I think it should be false)

pdeffebach · 2020-12-09T14:30:37Z

I'm fine with a different name for where, not sure what it would be though.

I'm okay with dropmissing = true by default, I guess. One reasoning is that if users want to use && and ||, which I think is pretty common inside those expressions, they will need to handle missings anyways. Hopefully something like spreadmissings can make help this.

matthieugomez · 2020-12-10T02:31:22Z

The only thing I feel strongly about is that dropmissing should be called skipmissing if it defaults to false.

nalimilan · 2020-12-11T08:33:35Z

As I said somewhere before I'm not a fan of the name where since all other functions in the API are verbs, and there's a (small) confusion with the where T syntax. I'd be inclined to use something else, like subset (R term) instead. Anyway our terminology is quite different from SQL since the only term in common is select.

Regarding missings, I think we should be consistent everywhere, and since we are strict in select and transform by default (no propagation of missing values) I think we shouldn't drop missing values automatically here either. But DataFramesMeta should probably choose a more permissive approach in all functions.

bkamins · 2020-12-11T08:42:01Z

OK, so I vote for:

subset as a verb (this is OK as we treat data frame as a collection of rows)
skipmissing=false as a kwarg name and default value

bkamins · 2021-01-01T21:44:47Z

I would even avoid mentioning it.

OK - I will add a comment in the code though.

Co-authored-by: Milan Bouchet-Valat <nalimilan@club.fr>

src/abstractdataframe/subset.jl

nalimilan · 2021-01-02T20:47:39Z

src/abstractdataframe/subset.jl

+@inline function subset(gdf::GroupedDataFrame, @nospecialize(args...);
+                        skipmissing::Bool=false, view::Bool=false)


Doesn't have to be implemented right now, but I guess at some point it will make sense to support ungroup=false to get a GroupedDataFrame like with select/transform?

This is what I had in an initial implementation. Then I thought that the problem is that ungroup=false does not give us any benefit (as in select/transform as we have to run groupby anyway) and complicates the API. But given you raised it I think it is OK to have it for consistency. I will add it back.

We could apply the grouping code directly to group indices, using the same path as refarray/refpool. It could often be faster than using the original columns. Maybe leave a TODO?

src/abstractdataframe/subset.jl

nalimilan · 2021-01-02T20:55:20Z

src/abstractdataframe/where.jl

+function where(df::AbstractDataFrame, @nospecialize(args...);
+               dropmissing::Bool=true, view::Bool=false)
+    row_selector = _get_where_conditions(df, args, dropmissing)
+    return view ? Base.view(df, row_selector, :) : df[row_selector, :]
+end


That's weird. We use this kind of pattern elsewhere and it works, right? Is row_selector correctly inferred?

Co-authored-by: Milan Bouchet-Valat <nalimilan@club.fr>

src/abstractdataframe/subset.jl

nalimilan · 2021-01-03T15:29:49Z

src/abstractdataframe/subset.jl

+@inline function subset(gdf::GroupedDataFrame, @nospecialize(args...);
+                        skipmissing::Bool=false, view::Bool=false)


We could apply the grouping code directly to group indices, using the same path as refarray/refpool. It could often be faster than using the original columns. Maybe leave a TODO?

Co-authored-by: Milan Bouchet-Valat <nalimilan@club.fr>

bkamins · 2021-01-03T16:32:15Z

I have applied the same fix in the other docstring.

bkamins · 2021-01-03T17:21:35Z

We could apply the grouping code directly to group indices

You mean to use gdf.groups[row_selector] and based on this create groups faster?
The code would be something like:

res.newuniquetempcol = gdf.groups[row_selector]
gdf2 = groupby(res, :newuniquetempcol)
copy!(gdf2.cols, gdf.cols)
select!(res, 1:ncol(res)-1)
return res

Do you think it would be worth it (I expect this code-path will not be used much).

nalimilan · 2021-01-03T17:25:25Z

Yes, something like this. That's not super important, but it doesn't hurt (at least as a TODO).

bkamins · 2021-01-03T17:35:00Z

I will add it as TODO, as I do not want to overcomplicate the code now.

bkamins · 2021-01-03T17:46:32Z

I left a TODO, as:

in some cases it will be slower than doing groupby on the original column (e.g. when grouping by CategoricalArray it is faster)
in some cases it will be the same
in some cases of course it will be faster

In order to do a fully fast implementation we should treat gdf.groups[row_selector] as categorical (which it is in fact), but this would complicate code more than what I proposed above (we would have to use a special grouping path as you proposed).

bkamins · 2021-01-06T16:31:11Z

OK - so regarding this PR is there anything we should discuss or it is good to be merged?

nalimilan

It would be nice to fix the return type stability issue at some point, but this doesn't have to block the PR.

src/abstractdataframe/subset.jl

bkamins · 2021-01-06T20:10:43Z

@pdeffebach, @matthieugomez - I will merge this PR later this week. Please comment if you want to add something to the discussion before merging.

pdeffebach · 2021-01-08T16:02:11Z

This PR looks good to me. I have a few suggestions.

Is it too late to rename skipmissing to missingasfalse? The second is more clear and doesn't conflict with Base.skipmissing
There is a section in the docs called "Taking a Subset" which makes no mention of this. Perhaps we should add a line in the docs? We also don't mention filter there. (Could be a separate PR)
Compile time is not great. I'm getting about .25 seconds for every call with an anonymous function, compared to about .15 seconds with an equivalent transform call. This can also be fixed in another PR, or more realistically a massive 1.X PR.
Do we have an opinionated way to do "OR" operations? Particularly with broadcasting and avoiding || as that doesn't play well with missing.

bkamins · 2021-01-08T18:38:25Z

These are good points. Thank you for raising them.

Is it too late to rename skipmissing to missingasfalse?

I thought @matthieugomez wanted skipmissing exactly to reduce number of words to learn. Also groupby uses skipmissing to mean the same what we mean here (i.e. drop missings). I am not sure what is best here (naming is always super hard).

There is a section in the docs called "Taking a Subset" which makes no mention of this.

I will add filter and subset in this PR to this section.

Compile time is not great.

This is strange. I would think that it should be the same as the most compilation work should be with select. I will try to investigate (but as you know these things are hard; c.f. #2566 which I will probably want to follow up before 1.0 release).

Do we have an opinionated way to do "OR" operations?

Probably one would have to do it manually (which means it would be not very convenient). My thinking was that "OR" is needed much less frequently than "AND" (and if you need "OR" you probably want it on the same column, which can be expressed using an anonymous function).

bkamins · 2021-01-08T23:24:53Z

I started updating the manual, but given the discussion we had today on Slack I gave up - it was too ad hoc. The manual needs to be updated. I have opened a separate PR for this: #2595.

nalimilan · 2021-01-09T21:26:25Z

IMO using skipmissing everywhere is indeed better for simplicity.

bkamins · 2021-01-09T22:33:54Z

I have investigated the performance related to compilation and I could not improve things here (the compilation time is mostly select except for the first call where we compile also other methods):

~/Desktop/Dev/DF_dev$ julia --banner=no
 Activating environment at `~/Desktop/Dev/DF_dev/Project.toml`
julia> using DataFrames

julia> df = DataFrame(a=true)
1×1 DataFrame
 Row │ a    
     │ Bool 
─────┼──────
   1 │ true

julia> @time subset(df, :a => ByRow(x -> x))
  1.042957 seconds (2.91 M allocations: 149.359 MiB, 2.55% gc time)
1×1 DataFrame
 Row │ a    
     │ Bool 
─────┼──────
   1 │ true

julia> @time subset(df, :a => ByRow(x -> x))
  0.248947 seconds (603.93 k allocations: 30.169 MiB, 5.64% gc time)
1×1 DataFrame
 Row │ a    
     │ Bool 
─────┼──────
   1 │ true

julia> @time subset(df, :a => ByRow(x -> x))
  0.225462 seconds (603.94 k allocations: 30.172 MiB)
1×1 DataFrame
 Row │ a    
     │ Bool 
─────┼──────
   1 │ true


~/Desktop/Dev/DF_dev$ julia --banner=no
 Activating environment at `~/Desktop/Dev/DF_dev/Project.toml`
julia> using DataFrames

julia> df = DataFrame(a=true)
1×1 DataFrame
 Row │ a    
     │ Bool 
─────┼──────
   1 │ true

julia> @time select(df, :a => ByRow(x -> x))
  0.609927 seconds (1.77 M allocations: 90.192 MiB, 4.28% gc time)
1×1 DataFrame
 Row │ a_function 
     │ Bool       
─────┼────────────
   1 │       true

julia> @time select(df, :a => ByRow(x -> x))
  0.213393 seconds (563.55 k allocations: 27.732 MiB, 5.39% gc time)
1×1 DataFrame
 Row │ a_function 
     │ Bool       
─────┼────────────
   1 │       true

julia> @time select(df, :a => ByRow(x -> x))
  0.214110 seconds (563.56 k allocations: 27.735 MiB, 5.01% gc time)
1×1 DataFrame
 Row │ a_function 
     │ Bool       
─────┼────────────
   1 │       true

I will wait for a feedback and if there are no more comments I am going to merge this PR soon as is now.

bkamins · 2021-01-11T16:46:42Z

Thank you!

bkamins added grouping non-breaking The proposed change is not breaking priority labels Oct 22, 2020

bkamins added this to the 1.0 milestone Oct 22, 2020

bkamins mentioned this pull request Oct 22, 2020

[BREAKING] Multicolumn transformations for GoupedDataFrame #2481

Merged

bkamins mentioned this pull request Oct 22, 2020

Release 0.22 tracking #2484

Closed

20 tasks

bkamins requested a review from nalimilan October 22, 2020 10:58

pdeffebach reviewed Oct 23, 2020

View reviewed changes

docs/src/man/comparisons.md Outdated Show resolved Hide resolved

src/abstractdataframe/where.jl Outdated Show resolved Hide resolved

src/abstractdataframe/where.jl Outdated Show resolved Hide resolved

src/abstractdataframe/where.jl Outdated Show resolved Hide resolved

nalimilan reviewed Oct 30, 2020

View reviewed changes

bkamins commented Oct 30, 2020

View reviewed changes

src/abstractdataframe/where.jl Outdated Show resolved Hide resolved

pdeffebach reviewed Nov 3, 2020

View reviewed changes

src/abstractdataframe/where.jl Outdated Show resolved Hide resolved

bkamins mentioned this pull request Nov 4, 2020

add predicate support for names and more tests #2417

Merged

bkamins and others added 3 commits January 1, 2021 22:45

Apply suggestions from code review

48cc618

Co-authored-by: Milan Bouchet-Valat <nalimilan@club.fr>

corrections after code review

1c28639

improve test coverage

9655daf

nalimilan reviewed Jan 2, 2021

View reviewed changes

bkamins and others added 2 commits January 3, 2021 12:50

Apply suggestions from code review

058c06e

Co-authored-by: Milan Bouchet-Valat <nalimilan@club.fr>

add ungroup kwarg and fix docstring

2ae30ca

nalimilan reviewed Jan 3, 2021

View reviewed changes

bkamins and others added 2 commits January 3, 2021 17:31

Apply suggestions from code review

2f7a919

Co-authored-by: Milan Bouchet-Valat <nalimilan@club.fr>

fix doc

1e481c6

add TODO for faster groupby

e43afb5

nalimilan approved these changes Jan 6, 2021

View reviewed changes

src/abstractdataframe/subset.jl Outdated Show resolved Hide resolved

remove @inline

6704541

pdeffebach approved these changes Jan 11, 2021

View reviewed changes

bkamins merged commit 6519d31 into JuliaData:main Jan 11, 2021

bkamins deleted the add_where branch January 11, 2021 16:46

bkamins mentioned this pull request Jan 11, 2021

rebased version for #2327 add filter subsetting to docs #2598

Closed

		@inline function subset(gdf::GroupedDataFrame, @nospecialize(args...);
		skipmissing::Bool=false, view::Bool=false)

Add subset #2496

Add subset #2496

Conversation

bkamins commented Oct 22, 2020

bkamins commented Oct 22, 2020

pdeffebach left a comment

Choose a reason for hiding this comment

matthieugomez commented Oct 23, 2020 • edited Loading

bkamins commented Oct 23, 2020

pdeffebach commented Oct 23, 2020

bkamins commented Oct 23, 2020

bkamins commented Oct 23, 2020

bkamins commented Oct 23, 2020

bkamins commented Oct 24, 2020

bkamins commented Oct 27, 2020

nalimilan commented Oct 30, 2020

Choose a reason for hiding this comment

bkamins Oct 30, 2020 • 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

bkamins commented Oct 30, 2020

bkamins commented Nov 4, 2020

pdeffebach commented Nov 4, 2020 • edited by nalimilan Loading

bkamins commented Dec 8, 2020

pdeffebach commented Dec 9, 2020

matthieugomez commented Dec 10, 2020

nalimilan commented Dec 11, 2020

bkamins commented Dec 11, 2020

bkamins commented Jan 1, 2021

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

bkamins commented Jan 3, 2021

bkamins commented Jan 3, 2021

nalimilan commented Jan 3, 2021

bkamins commented Jan 3, 2021

bkamins commented Jan 3, 2021

bkamins commented Jan 6, 2021

nalimilan left a comment

Choose a reason for hiding this comment

bkamins commented Jan 6, 2021

pdeffebach commented Jan 8, 2021

bkamins commented Jan 8, 2021

bkamins commented Jan 8, 2021

nalimilan commented Jan 9, 2021

bkamins commented Jan 9, 2021

bkamins commented Jan 11, 2021

matthieugomez commented Oct 23, 2020 •

edited

Loading

bkamins Oct 30, 2020 •

edited

Loading

pdeffebach commented Nov 4, 2020 •

edited by nalimilan

Loading