new subtyping issues #19998

vtjnash · 2017-01-12T20:16:39Z

these are issues found with subtyping after #18457, and other related punchlist items.

intersection failure

julia> A = Tuple{Type{Tuple{Vararg{E, N} where N}}} where E
Tuple{Type{Tuple{Vararg{E,N} where N}}} where E

julia> B = Tuple{Type{Tuple{Vararg{E, N}}}} where N where E
Tuple{Type{Tuple{Vararg{E,N}}}} where N where E

julia> typeintersect(B, A)
Assertion failed: ((jl_value_t*)btemp->var != btemp->ub), function finish_unionall, file /Users/jameson/julia/src/subtype.c, line 1159.

#18457 (comment)

tuple length subtyping inside invariant parameter:

julia> (Ref{Tuple{Int, Vararg{Int, N}}} where N) <: (Ref{Tuple{Vararg{Int, N}}} where N)
false

another intersection failure:

typeintersect(Tuple{Int, Ref{Pair{K,V}}} where V where K,
              Tuple{Any, Ref{Pair{T,T}} where T })

This overflows the union state stack.

subtype environment sub-optimality preventing a dispatch match, and subtyping error

julia> A = Ref{Tuple{T}} where T;
julia> B = Ref{Tuple{VecElement{S}} where S};
julia> ccall(:jl_match_method, Any, (Any, Any), B, A)
svec(Ref{Tuple{VecElement{S}} where S}, svec(T <: (VecElement{S} where S)))

julia> A = Tuple{Ref{Tuple{T}}, Ref{T}} where T;
julia> B = Tuple{Ref{Tuple{VecElement{S}} where S}, Ref{VecElement{Int}}}
julia> B <: A
true # should be false

a possibly related case is:

julia> A = Ref{Tuple{T, T}} where T;
julia> B = Ref{Tuple{S, Any} where S};
julia> B <: A
true # should be false
# a similar case, but that isn't wrong:
julia> A = Pair{Tuple{T, T}, T} where T;
julia> B = Pair{Tuple{S, Any} where S, Any};
julia> B <: A
true # correct

Specificity issue in ColorTypes:

julia> (g(::Type{TC}) where TC <: (TransparentColor{C, T, N} where T where N) where C) = C
g (generic function with 1 method)

julia> g(ColorTypes.TransparentColor{ColorTypes.RGB{Float32}, Float32, 4})
ColorTypes.RGB{Float32}

julia> (g(::Type{TC}) where TC <: TransparentColor) = 1
g (generic function with 2 methods)

julia> g(ColorTypes.TransparentColor{ColorTypes.RGB{Float32}, Float32, 4})
1

julia> methods(g)
# 2 methods for generic function "g":
g{TC<:ColorTypes.TransparentColor}(::Type{TC}) in Main at REPL[16]:1
g{C,TC<:(ColorTypes.TransparentColor{C,T,N} where T where N)}(::Type{TC}) in Main at REPL[14]:1

broken leaftype normalization (relative to codegen / inference assumptions for performance optimization)
Vector{T} where Int <: T <: Int should return Vector{Int}
so that isleaftype(T) guarantees isa(T, DataType) and pointer-egal

related to that normalization failure, it doesn't notice that T <: Int describes a Union with exactly two elements:

julia> (Ref{T} where T <: Int) <: Union{Ref{Union{}}, Ref{Int}}
false

Possibly wrong TypeVar serialization with new typesystem Possibly wrong TypeVar serialization with new typesystem #20324

error thrown when trying to fill in sparam bounds with a non-type:

julia> ccall(:jl_match_method, Any, (Any, Any), Tuple{0}, Tuple{T} where T)
ERROR: TypeError: TypeVar: in upper bound, expected Type, got Int64
Stacktrace:
 [1] anonymous at <missing>:0
 [2] eval(::Module, ::Any) at ./boot.jl:236
 [3] eval_user_input(::Any, ::Base.REPL.REPLBackend) at REPL.jl:66
 [4] macro expansion; at REPL.jl:97 [inlined]
 [5] (::Base.REPL.##1#2{Base.REPL.REPLBackend})() at event.jl:73

inconsistent handling of tuple leaftype covariance normalization

julia> (Tuple{S, Int} where S <: Int) <: Tuple{T, T} where T <: Real
false

Specificity: Tuple{Type{Nullable{T}}, Void} where T should be more specific than Tuple{Type{Nullable{T}}, T} where T.

type-intersection fails to sufficiently consider that a typevar may match a non-type: issue #20869

The text was updated successfully, but these errors were encountered:

StefanKarpinski · 2017-01-13T18:05:48Z

Is this a list of 0.6-blocking issues?

vtjnash · 2017-01-13T18:47:49Z

no, it's a summary of bugs that won't be fixed by #18457

StefanKarpinski · 2017-01-13T19:53:02Z

That doesn't really answer my question.

JeffBezanson · 2017-01-16T17:18:26Z

It's a list of things he found while reviewing #18457 that don't block merging it. These are generally minor bugs or follow-on work items that don't block 0.6.

tkelman · 2017-01-16T17:31:24Z

We really shouldn't leave the ambiguity test turned off for very long though. That's the most urgent of these to fix.

vtjnash · 2017-01-16T18:45:58Z

whoever added "add test cases for all closed issues", can you list the issues that still need test-cases so we can cross them off as we go?

@tkelman there's no ordering in the above list, just a task list to keep track of everything

tkelman · 2017-01-16T18:47:58Z

Jeff is the one closing them, I've been grepping the test folder for references to each of them but haven't found any hits. (except 18450 and 11840)

edit: any of these cases that are covered by existing tests, should at least cross-reference the relevant issue in a comment / testset description

Added tests for issues JuliaLang#12580, JuliaLang#18348, JuliaLang#13165, JuliaLang#11803, JuliaLang#12721 Enabled tests for JuliaLang#11840

Added tests for issues JuliaLang#12580, JuliaLang#18348, JuliaLang#13165, JuliaLang#11803, JuliaLang#12721 Enabled extra tests for JuliaLang#11840, however, that isssue is not resolved yet but needs tests triggering it.

pabloferz · 2017-01-19T15:02:44Z

I found that you can't do subtypes(Type) now, but

let T = TypeVar{:T}
    subtypes(Type{T})
end

works.

EDIT: NVM, I think that is covered by the first item on the list.

thofma · 2017-01-19T16:03:02Z

@pabloferz See also #20086 and #20084 (if you want subtypes to not be removed)

TotalVerb · 2017-01-20T03:09:10Z

Is the following expected?

julia> Array{NTuple{N, Int} where N} <: (Array{NTuple{N, T} where N}) where T
true

julia> Array{NTuple{N, Integer} where N} <: (Array{NTuple{N, T} where N}) where T
false

I would expect that, since the T is not in covariant position, it should be allowed to range over Integer.

vtjnash · 2017-01-20T05:10:36Z

Yes. On the left, each element of the tuple can be any subtype of Integer. On the right, each element of the tuple must be the same subtype of Any.

TotalVerb · 2017-01-20T05:15:06Z

What do you mean by each element of the tuple ranging over any subtype of Integer? The tuple should is in invariant position on both left and right.

Added tests for issues JuliaLang#12580, JuliaLang#18348, JuliaLang#13165, JuliaLang#12721 For JuliaLang#11803 it was decidided that no tests are needed. Enabled extra tests for JuliaLang#11840, however, that isssue is not resolved yet but needs new tests triggering it.

vtjnash · 2017-01-22T06:49:52Z

note that we can coerce that "subtype environment sub-optimality preventing a dispatch match" further to convince it to give other (related) bad answers for other leaftypes:

julia> A = Tuple{Ref{Tuple{T}}, T} where T;
julia> B = Tuple{Ref{Tuple{VecElement{S}} where S}, VecElement{Int}};
julia> ccall(:jl_match_method, Any, (Any, Any), B, A)
svec(Tuple{Ref{Tuple{VecElement{S}} where S}, VecElement{Int64}},
svec(VecElement{Int64})) # expected `VecElement`

julia> A = Tuple{Ref{Tuple{T}}, T, T} where T;
julia> B = Tuple{Ref{Tuple{VecElement{S}} where S}, VecElement{Int}, VecElement{Float64}};
julia> ccall(:jl_match_method, Any, (Any, Any), B, A)
svec(Tuple{Ref{Tuple{VecElement{S}} where S}, VecElement{Int64}, VecElement{Float64}},
svec(Union{VecElement{Float64}, VecElement{Int64}})) # expected `VecElement`

julia> A = Pair{Ref{Tuple{T}}, T} where T;
julia> B = Pair{Ref{Tuple{VecElement} where S}, VecElement};
julia> ccall(:jl_match_method, Any, (Any, Any), B, A)
svec(Pair{Ref{Tuple{VecElement{S}} where S}, VecElement},
svec(Union{VecElement, VecElement{S}})) # expected `VecElement`

vtjnash · 2017-01-22T19:52:44Z

alright, I've finally managed to turn that incorrect environment into a subtyping error, and updated the top issue with the example

mauro3 · 2017-01-23T09:47:46Z

show of parametrized types doesn't show the type parameters anymore:

julia> immutable B{T}
       a::T
       end

julia> B 
B # used to be B{T}

Is this intentional or a regression? If the former, what is the preferred way get this information? dump works but is a bit on the verbose side. Let me know if should I open an issue for this.

TotalVerb · 2017-01-23T19:29:03Z

@mauro3

julia> Array
Array

julia> Base.unwrap_unionall(Array)
Array{T,N}

Keno · 2017-01-24T00:42:17Z

I do agree though that the printing for general UnionAlls needs to be revised to show the type parameters.

mauro3 · 2017-01-24T07:22:46Z

I had a look at the show method

julia/base/show.jl

Line 185 in 06fa32c

function print_without_params(x::ANY)

and it looks like the parameter printing was explicitly disabled by @JeffBezanson.

JeffBezanson · 2017-01-24T23:12:35Z

the printing for general UnionAlls needs to be revised to show the type parameters.

Example? Type parameters are certainly shown in general.

I decided to show types like Array the way they are usually written in code. This becomes especially nice when printing method signatures, e.g. f(x::Array, y::Array) instead of f(x::Array{T,N} where N where T, y::Array{T,N} where N where T). I'm open to changes here. We could use this only for :compact printing, or use a show/display distinction as in the verbose printing of Chars.

JeffBezanson · 2017-01-24T23:20:22Z

(Ref{T} where T <: Int) <: Union{Ref{Union{}}, Ref{Int}}

I don't worry too much about this one. I don't think subtyping should be expected to enumerate possible values of unionall variables.

I agree we can and should normalize Vector{T} where Int <: T <: Int (though constantly checking variable bounds for type equality could prove expensive), but the same argument almost applies. isleaftype returns false for this type.

vtjnash · 2017-01-24T23:55:49Z

but the same argument almost applies

in the second case, it could be undesirable since it could make f(::Type{Ref{Int}}) harder to infer (we don't know that Type.parameters[1] is DataType, so we would need to remove the isConstType predicate from inference and replace it with false.).

the first case doesn't have that issue, so I agree that it's not as likely to be a problem.

amitmurthy · 2017-01-31T03:06:36Z

As this is a meta-issue tracking issues in the new type system, referencing #20324 here.

andyferris · 2017-02-16T04:52:01Z

I've been pointed here for a strange error in StaticArrays. The most alarming thing (to me) is that dispatch is not deterministic, in the sense that calling method "A", constructing some object "B", and then calling the method "A" again results in a different (and incorrect) dispatch; see JuliaArrays/StaticArrays.jl#106 (comment).

If someone could let me know if this error appears related to the things here or is orthogonal, I would appreciate it.

maleadt · 2017-02-16T10:52:48Z

~~Is this expected?~~

julia> Tuple{Tuple{Int64},Int64} <: NTuple{N} where N
false

julia> Tuple{Int64,Tuple{Int64}} <: NTuple{N} where N
false

Didn't read the NEWS

The type NTuple{N} now refers to tuples where every element has the same type (since it is shorthand for NTuple{N,T} where T). To get the old behavior of matching any tuple, use NTuple{N,Any}

tkelman · 2017-02-16T11:36:53Z

NTuple's have to be homogenous now - if that's not mentioned clearly enough in news then we should clarify it

felixrehren · 2017-02-16T14:02:37Z

Added PR #20627 with tests for #2552, #8625, #8915, #11407 (off the bottom of the list)
I couldn't reproduce #6721, because when defining SubgraphObject it runs into an error UndefVarError: T not defined, so I wonder if this one is still relevant
Is the list currently up-to-date? I don't see anything ticked off by #20407

felixrehren · 2017-02-17T11:58:58Z

Added tests for #12814 #16922 #17943 #18892 #19159 #19413 #19041 #18985 to #20627
#12596 seems to be nothing to do, as original problem is no longer replicatable (TypeVar no longer has boolean bound field, and second reported problem was determined to be working as intended)

If these are correct, this ticks off all the "add test case"s on the list so far

JeffBezanson · 2017-02-18T20:39:52Z

On the ColorTypes specificity issue: this is one of those cases where we need to automatically restrict the bounds of method typevars; in TransparentColor the C parameter is C<:Color, and in the other method definition it's C<:Any, so the current ordering is technically corrrect. Adding C<:Color should fix it.

part of #19998

vtjnash · 2017-03-07T17:27:29Z

Also added a request to document the type-system parameter matching, as this is a current source of bugs in the inference results (such as #20847) and subtyping errors (already listed above).

martinholters · 2017-03-14T12:44:58Z

I did some fuzzing where I verified that for types a, b, and x, such that x <: a && x <: b, all of the following hold:

typeintersect(a, b) == typeintersect(b, a)
x <: typeintersect(a, b)
typeintersect(a, b) <: a
typeintersect(a, b) <: b

Here are some problematic cases I hit:

julia> versioninfo()
Julia Version 0.6.0-pre.alpha.142
Commit 64409a0cae* (2017-03-14 04:20 UTC)
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.9.1 (ORCJIT, ivybridge)

julia> let a = Tuple{Float64,T7} where T7,
           b = Tuple{S5,Tuple{S5}} where S5,
           x = Tuple{Float64,Tuple{Float64}}
           typeintersect(a, b) <: b
       end
false

julia> let a = Tuple{T1,T1} where T1,
           b = Tuple{Val{S2},S6} where S2 where S6,
           x = Tuple{Val{Float64},Val{Float64}}
           typeintersect(a, b) == typeintersect(b, a)
       end
false

julia> let a = Val{Tuple{T1,T1}} where T1,
           b = Val{Tuple{Val{S2},S6}} where S2 where S6,
           x = Val{Tuple{Val{Float64},Val{Float64}}}
           typeintersect(a, b) <: a
       end
false # true since #21295

julia> let a = Tuple{Float64,T3,T4} where T4 where T3,
           b = Tuple{S2,Tuple{S3},S3} where S2 where S3,
           x = Tuple{Float64,Tuple{1},1}
           typeintersect(a, b) == typeintersect(b, a)
       end
false

julia> let a = Tuple{T1,Tuple{T1}} where T1,
           b = Tuple{Float64,S3} where S3,
           x = Tuple{Float64,Tuple{Float64}}
           typeintersect(a, b) <: a
       end
false

julia> let a = Tuple{5,T4,T5} where T4 where T5,
           b = Tuple{S2,S3,Tuple{S3}} where S2 where S3,
           x = Tuple{5,Float64,Tuple{Float64}}
           typeintersect(a, b) == typeintersect(b, a)
       end
false

julia> let a = Tuple{T2,Tuple{T4,T2}} where T4 where T2,
           b = Tuple{Float64,Tuple{Tuple{S3},S3}} where S3,
           x = Tuple{Float64,Tuple{Tuple{Float64},Float64}}
           typeintersect(a, b) <: b
       end
false

julia> let a = Tuple{Tuple{T2,4},T6} where T2 where T6,
           b = Tuple{Tuple{S2,S3},Tuple{S2}} where S2 where S3,
           x = Tuple{Tuple{Int64,4},Tuple{Int64}}
           typeintersect(a, b) == typeintersect(b, a)
       end
false

julia> let a = Tuple{T3,Int64,Tuple{T3}} where T3,
           b = Tuple{S3,S3,S4} where S4 where S3,
           x = Tuple{Int64,Int64,Tuple{Int64}}
           typeintersect(a, b) <: a
       end
false

julia> let a = Tuple{T1,Val{T2},T2} where T2 where T1,
           b = Tuple{Float64,S1,S2} where S2 where S1,
           x = Tuple{Float64,Val{Int64},Int64}
           typeintersect(a, b) == typeintersect(b, a)
       end
false

julia> let a = Tuple{T1,Val{T2},T2} where T2 where T1,
           b = Tuple{Float64,S1,S2} where S2 where S1,
           x = Tuple{Float64,Val{Int64},Int64}
           typeintersect(a, b) <: a
       end
false

julia> let a = Tuple{Float64,T1} where T1,
           b = Tuple{S1,Tuple{S1}} where S1,
           x = Tuple{Float64,Tuple{Float64}}
           typeintersect(a, b) <: b
       end
false

julia> let a = Tuple{Val{T1},T2,T2} where T2 where T1,
           b = Tuple{Val{Tuple{S2}},S3,Float64} where S2 where S3,
           x = Tuple{Val{Tuple{4}},Float64,Float64}
           typeintersect(a, b) == typeintersect(b, a)
       end
false # true since #21295

julia> let a = Tuple{Val{T1},T2,T2} where T2 where T1,
           b = Tuple{Val{Tuple{S2}},S3,Float64} where S2 where S3,
           x = Tuple{Val{Tuple{4}},Float64,Float64}
           x <: typeintersect(a, b)
       end
false # true since #21295

julia> let a = Tuple{T1,T2,T2} where T1 where T2,
           b = Tuple{Val{S2},S2,Float64} where S2,
           x = Tuple{Val{Float64},Float64,Float64}
           x <: typeintersect(a, b)
       end
false

julia> let a = Val{Tuple{T1,Val{T2},Val{Int64},Tuple{Tuple{T3,5,Float64},T4,T2,T5}}} where T1 where T5 where T4 where T3 where T2,
           b = Val{Tuple{Tuple{S1,5,Float64},Val{S2},S3,Tuple{Tuple{Val{Float64},5,Float64},2,Float64,S4}}} where S2 where S3 where S1 where S4
           typeintersect(b, a)
       end
ERROR: StackOverflowError:
Stacktrace:
 [1] typeintersect(::Any, ::Any) at ./reflection.jl:305

(Unless I'm mistaken, these should all give true.)

Should I open a dedicated issue for tracking those?

vtjnash · 2019-07-08T17:37:03Z

I was going back through and reviewing the OP here. There's still many that don't have confirmed tests, but are fixed now (the corresponding issue is closed).

In the above comment, all of those return true now except two:

julia> let a = Tuple{T3,Int64,Tuple{T3}} where T3,
           b = Tuple{S3,S3,S4} where S4 where S3,
           x = Tuple{Int64,Int64,Tuple{Int64}}
           typeintersect(a, b) <: a
       end
false # subtype is wrong about (Tuple{S3,S3,S4} where S4<:Tuple{Int64} where S3<:Int64) -- possibly a normalization issue?

julia> let a = Tuple{T1,Val{T2},T2} where T2 where T1,
           b = Tuple{Float64,S1,S2} where S2 where S1,
           x = Tuple{Float64,Val{Int64},Int64}
           typeintersect(a, b) <: a
       end
false # suboptimal, but valid (type-intersection was over-approximated)

kshyatt added the types and dispatch Types, subtyping and method dispatch label Jan 12, 2017

mauro3 added a commit to mauro3/julia that referenced this issue Jan 17, 2017

Added misc tests referenced in JuliaLang#19998

ce8e163

Added tests for issues JuliaLang#12580, JuliaLang#18348, JuliaLang#13165, JuliaLang#11803, JuliaLang#12721 Enabled tests for JuliaLang#11840

mauro3 added a commit to mauro3/julia that referenced this issue Jan 17, 2017

Added misc tests referenced in JuliaLang#19998

2970623

Added tests for issues JuliaLang#12580, JuliaLang#18348, JuliaLang#13165, JuliaLang#11803, JuliaLang#12721 Enabled tests for JuliaLang#11840

mauro3 added a commit to mauro3/julia that referenced this issue Jan 17, 2017

Added misc tests referenced in JuliaLang#19998

c2f5a97

Added tests for issues JuliaLang#12580, JuliaLang#18348, JuliaLang#13165, JuliaLang#11803, JuliaLang#12721 Enabled tests for JuliaLang#11840

mauro3 mentioned this issue Jan 17, 2017

Misc tests for issues fixed by jb/subtype #20097

Merged

mauro3 mentioned this issue Jan 18, 2017

New type system: stackoverflow when defining method #20103

Closed

TotalVerb mentioned this issue Jan 18, 2017

methods of closure Error showing value of type Base.MethodList #20111

Closed

vtjnash mentioned this issue Jan 20, 2017

eltype(Tuple{...}) less specific than 0.5 #20143

Closed

vtjnash added this to the 0.6.0 milestone Jan 22, 2017

timholy mentioned this issue Jan 26, 2017

False ambiguity with Union #20246

Closed

vtjnash mentioned this issue Feb 2, 2017

grabbag of subtyping punchlist items #20407

Merged

rdeits mentioned this issue Feb 16, 2017

Dispatch issues with size() on v0.6-dev JuliaArrays/StaticArrays.jl#106

Closed

felixrehren mentioned this issue Feb 16, 2017

assorted subtyping tests #20627

Merged

JeffBezanson added a commit that referenced this issue Feb 21, 2017

tolerate non-types as Tuple parameters better

e8d2d95

part of #19998

JeffBezanson mentioned this issue Feb 21, 2017

tolerate non-types as Tuple parameters better #20722

Merged

vtjnash mentioned this issue Mar 14, 2017

fix #20992 #21013

Merged

JeffBezanson modified the milestones: 0.6.x, 0.6.0 Apr 4, 2017

This was referenced Apr 7, 2017

type intersection fix for #21243 and #21250 #21295

Merged

Some more typeintersect tests #21339

Merged

JeffBezanson mentioned this issue Apr 16, 2017

Missed leaf type canonicalization #21400

Closed

JeffBezanson modified the milestones: 0.6.x, 1.0.x Sep 18, 2018

Keno mentioned this issue Apr 17, 2019

Fix some vararg-related subtyping issues #31698

Merged

vtjnash closed this as completed Apr 8, 2021

vtjnash mentioned this issue Apr 8, 2021

known subtyping issue #40407

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

new subtyping issues #19998

new subtyping issues #19998

vtjnash commented Jan 12, 2017 •

edited

Loading

StefanKarpinski commented Jan 13, 2017

vtjnash commented Jan 13, 2017

StefanKarpinski commented Jan 13, 2017

JeffBezanson commented Jan 16, 2017

tkelman commented Jan 16, 2017

vtjnash commented Jan 16, 2017

tkelman commented Jan 16, 2017 •

edited

Loading

pabloferz commented Jan 19, 2017 •

edited

Loading

thofma commented Jan 19, 2017 •

edited

Loading

TotalVerb commented Jan 20, 2017

vtjnash commented Jan 20, 2017

TotalVerb commented Jan 20, 2017

vtjnash commented Jan 22, 2017 •

edited

Loading

vtjnash commented Jan 22, 2017

mauro3 commented Jan 23, 2017

TotalVerb commented Jan 23, 2017

Keno commented Jan 24, 2017

mauro3 commented Jan 24, 2017

JeffBezanson commented Jan 24, 2017

JeffBezanson commented Jan 24, 2017

vtjnash commented Jan 24, 2017

amitmurthy commented Jan 31, 2017

andyferris commented Feb 16, 2017

maleadt commented Feb 16, 2017 •

edited

Loading

tkelman commented Feb 16, 2017

felixrehren commented Feb 16, 2017 •

edited

Loading

felixrehren commented Feb 17, 2017 •

edited

Loading

JeffBezanson commented Feb 18, 2017

vtjnash commented Mar 7, 2017

martinholters commented Mar 14, 2017 •

edited

Loading

vtjnash commented Jul 8, 2019

new subtyping issues #19998

new subtyping issues #19998

Comments

vtjnash commented Jan 12, 2017 • edited Loading

StefanKarpinski commented Jan 13, 2017

vtjnash commented Jan 13, 2017

StefanKarpinski commented Jan 13, 2017

JeffBezanson commented Jan 16, 2017

tkelman commented Jan 16, 2017

vtjnash commented Jan 16, 2017

tkelman commented Jan 16, 2017 • edited Loading

pabloferz commented Jan 19, 2017 • edited Loading

thofma commented Jan 19, 2017 • edited Loading

TotalVerb commented Jan 20, 2017

vtjnash commented Jan 20, 2017

TotalVerb commented Jan 20, 2017

vtjnash commented Jan 22, 2017 • edited Loading

vtjnash commented Jan 22, 2017

mauro3 commented Jan 23, 2017

TotalVerb commented Jan 23, 2017

Keno commented Jan 24, 2017

mauro3 commented Jan 24, 2017

JeffBezanson commented Jan 24, 2017

JeffBezanson commented Jan 24, 2017

vtjnash commented Jan 24, 2017

amitmurthy commented Jan 31, 2017

andyferris commented Feb 16, 2017

maleadt commented Feb 16, 2017 • edited Loading

tkelman commented Feb 16, 2017

felixrehren commented Feb 16, 2017 • edited Loading

felixrehren commented Feb 17, 2017 • edited Loading

JeffBezanson commented Feb 18, 2017

vtjnash commented Mar 7, 2017

martinholters commented Mar 14, 2017 • edited Loading

vtjnash commented Jul 8, 2019

vtjnash commented Jan 12, 2017 •

edited

Loading

tkelman commented Jan 16, 2017 •

edited

Loading

pabloferz commented Jan 19, 2017 •

edited

Loading

thofma commented Jan 19, 2017 •

edited

Loading

vtjnash commented Jan 22, 2017 •

edited

Loading

maleadt commented Feb 16, 2017 •

edited

Loading

felixrehren commented Feb 16, 2017 •

edited

Loading

felixrehren commented Feb 17, 2017 •

edited

Loading

martinholters commented Mar 14, 2017 •

edited

Loading