[SPARK-27768][SQL] Support Infinity/NaN-related float/double literals case-insensitively #25331

dilipbiswal · 2019-08-01T21:09:25Z

What changes were proposed in this pull request?

Here is the problem description from the JIRA.

When the inputs contain the constant 'infinity', Spark SQL does not generate the expected results.

SELECT avg(CAST(x AS DOUBLE)), var_pop(CAST(x AS DOUBLE))
FROM (VALUES ('1'), (CAST('infinity' AS DOUBLE))) v(x);
SELECT avg(CAST(x AS DOUBLE)), var_pop(CAST(x AS DOUBLE))
FROM (VALUES ('infinity'), ('1')) v(x);
SELECT avg(CAST(x AS DOUBLE)), var_pop(CAST(x AS DOUBLE))
FROM (VALUES ('infinity'), ('infinity')) v(x);
SELECT avg(CAST(x AS DOUBLE)), var_pop(CAST(x AS DOUBLE))
FROM (VALUES ('-infinity'), ('infinity')) v(x);
 The root cause: Spark SQL does not recognize the special constants in a case insensitive way. In PostgreSQL, they are recognized in a case insensitive way. 

Link: https://www.postgresql.org/docs/9.3/datatype-numeric.html

In this PR, the casting code is enhanced to handle these special string literals in case insensitive manner.

How was this patch tested?

Added tests in CastSuite and modified existing test suites.

dilipbiswal · 2019-08-01T21:16:53Z

cc @gatorsmile @dongjoon-hyun @maropu

maropu · 2019-08-01T21:36:57Z

ok, I'll check in hours ;)

dongjoon-hyun · 2019-08-01T21:44:59Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/Cast.scala

            $evPrim = Float.valueOf($c.toString());
          } catch (java.lang.NumberFormatException e) {
-            $evNull = true;
+              final String $str = $c.toString().trim();


indentation?

Although this is called only in case of exceptions, it would be great to call .toString once by reusing the one in line 1265.

@dongjoon-hyun oops.. sorry.. i will fix.

dongjoon-hyun · 2019-08-01T21:51:14Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/Cast.scala

+            Float.NaN
+          } else {
+            null
+          }


To avoid duplications, shall we make a function for this since we have the same Float logic twice here and line 1268?

@dongjoon-hyun The assignment variable names are different ? Is there an example i can follow where codegen and non-codegen code is refactored to a function ?

We don't need an assignment if you handle everything inside the function.
The function will return the right-side value of the assignment.

@dongjoon-hyun Ah... thanks .. will try.

dongjoon-hyun · 2019-08-01T21:52:31Z

sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/CastSuite.scala

    }
  }
+
+  test("SPARK-27768 process infinity, -infinity , nan in case insensitive manner") {


Actually, this is not a bug. Instead, this is a behavior change for PostgreSQL compatibility.
Previously, Spark works like Java/Scala/Hive.

@dongjoon-hyun OK.. will remove the JIRA id.

sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/CastSuite.scala

sql/core/src/test/resources/sql-tests/inputs/pgSQL/aggregates_part1.sql

maropu · 2019-08-01T23:41:57Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/Cast.scala

      buildCast[UTF8String](_, s => try s.toString.toDouble catch {
-        case _: NumberFormatException => null
+        case _: NumberFormatException =>
+          val str = s.trim.toString


Its just a check; do we support this case, e.g., ' infinity '? (I know pg does so though). If we support this case, IMO you'd be better to clearly describe in the PR description, which case this PR try to support.

@maropu Currently i trim spaces from both ends and compare. So this case should work.
Ok.. i will update the description.

maropu · 2019-08-01T23:42:52Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/Cast.scala

-        case _: NumberFormatException => null
+        case _: NumberFormatException =>
+          val str = s.trim.toString
+          if (str.equalsIgnoreCase("infinity")) {


just a check; we don't support some alternatives, e.g., inf, -inf, ... ?https://github.com/postgres/postgres/blob/master/src/backend/utils/adt/float.c#L194

@maropu We don't support inf and -inf, should we support ?

Is there another db-like systems supporting this, e.g., DB2?

@maropu Yes.. db2 does allow inf and -inf. Lets add in spark also ? Thanks a lot for pointing this..

IMO some users might think inf is more common, e.g., even in python, both inf and infinity can be used;

Python 3.6.8 |Anaconda, Inc.| (default, Dec 29 2018, 19:04:46) >>> float('inf') inf >>> float('infinity') inf

Its ok to wait for other reviewer's comments. @gatorsmile @dongjoon-hyun

@gatorsmile @dongjoon-hyun Could you please help make a decision on whether to support inf, +inf for positive infinity and '-inf` for negative infinity ? Thanks a lot. Thanks again @maropu for pointing this.

As @maropu mentioned, since PostgreSQL supports that, I'm +1 for supporting it.

else if (pg_strncasecmp(num, "inf", 3) == 0) { val = get_float4_infinity(); endptr = num + 3; } else if (pg_strncasecmp(num, "+inf", 4) == 0) { val = get_float4_infinity(); endptr = num + 4; } else if (pg_strncasecmp(num, "-inf", 4) == 0) { val = -get_float4_infinity(); endptr = num + 4; }

@dongjoon-hyun OK.. thanks.. i will make the change.

SparkQA · 2019-08-02T00:36:31Z

Test build #108533 has finished for PR 25331 at commit 68c45e1.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

kiszk · 2019-08-02T04:22:10Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/Cast.scala

      buildCast[UTF8String](_, s => try s.toString.toFloat catch {
-        case _: NumberFormatException => null
+        case _: NumberFormatException =>
+          val str = s.trim.toString


Can we merge lines 551-560 and 577-586 into one function? Since the return type will be Any, we can merge two cases Float and Double into one.

SparkQA · 2019-08-02T10:47:40Z

Test build #108557 has finished for PR 25331 at commit b7d9de1.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

dilipbiswal · 2019-08-02T19:31:04Z

@dongjoon-hyun I have incorporated the changes.. Please take a look when you get a chance. I am not fully sure if the refactoring between codegen and non-codegen is necessary. I guess, since this code path is exercised only in the exception path, its okay to go for code-reuse in this specific case :-)

viirya · 2019-08-02T19:52:14Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/Cast.scala

      }
  }

+


Revert this newline?

@viirya Thx.. will do.

viirya · 2019-08-02T19:56:46Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/Cast.scala

+      buildCast[UTF8String](_, s => {
+        val floatStr = s.toString
+        try floatStr.toFloat catch {
+          case _: NumberFormatException =>


Should we explicitly match strings we want? We can avoid try-catch of an exception for the known strings.

@viirya So my idea here was that.. since we don't expect these kind of literals a lot i.e its not a common case .. we don't change our normal processing path to add any possible runtime costs. Thats why we keep all these in the exception processing.

I like the @viirya approach for readability, but I understand your concern for the performance. So, could you check actual performance changes?

@maropu Oops.. didn't see this comment. I suppose i have to use the benchmark framework for this ? Appreciate any tip on this..

Could we check the numbers by a simple query?, e.g.,

scala> spark.range(10).selectExpr("CAST(double(id) AS STRING) a").write.save("/tmp/test") scala> spark.read.load("/tmp/test").selectExpr("CAST(a AS DOUBLE)").write.format("noop").save()

In another pr, I observed that a logic depending on exceptions cause high performance penalties: lz4/lz4-java#143
So, I'm a bit worried that this current logic has the same issue.

@maropu Actually my input data didn't contain any of these special literals. Basically i was testing with the condition when we don't hit the catch block. Basically we are trying optimize for the best case ?

I just make sure that a small number of inf/-inf does not worse the prformance. If this is true, I think the current code looks ok to me.

@maropu In the mean time i had tried with 1% of data being 'inf' and i can confirm that it does not hurt the performance :-)

Sounds good.

Sounds nice, too ;)

viirya · 2019-08-02T19:59:00Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/Cast.scala


  def resolvableNullability(from: Boolean, to: Boolean): Boolean = !from || to
+
+


Looks like an extra empty line?

@viirya Thx.. will do.

SparkQA · 2019-08-03T00:29:58Z

Test build #108583 has finished for PR 25331 at commit 928e4c1.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

srowen

Wait, where does "infiNity" come up? or "+infinity"? I don't think this is how the JVM or Python renders them?

srowen · 2019-08-07T19:14:34Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/Cast.scala

+
+  def processFloatingPointSpecialLiterals(v: String, isFloat: Boolean): Any = {
+    val str = v.trim
+    if (str.equalsIgnoreCase("infinity") || str.equalsIgnoreCase("+infinity")) {


Do you need Locale.ROOT here? it's a really obscure possibility, but "i" can cause problems

@srowen OK.. will add Locale.ROOT by following how its used in other places.

dilipbiswal · 2019-08-07T20:36:43Z

@srowen

Wait, where does "infiNity" come up? or "+infinity"? I don't think this is how the JVM or Python renders them?

May i please request you to refer to the discussions in the associated JIRA ? Basically our intention here is accept these "special" float and double literals in a case insensitive manner as some other database systems allow them ? Do you see a problem here ?

… insensitive manner

viirya · 2019-08-09T06:05:40Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/Cast.scala


  def resolvableNullability(from: Boolean, to: Boolean): Boolean = !from || to
+
+  def processFloatingPointSpecialLiterals(v: String, isFloat: Boolean): Any = {


Actually some literals like InFiniTy can be casted, it looks a bit weird. However, postgresql accepts such things. Maybe add a comment here to explain why allowing case insensitive match?

@viirya Does this look ok ?

We process literals such as 'Infinity', 'Inf', '-Infinity' and 'NaN' in case insensitive manner to be compatible with other database systems such as Postgres and DB2.

I feel ok. Other reviewers may also have advice too.

SparkQA · 2019-08-09T07:05:02Z

Test build #108861 has finished for PR 25331 at commit e901dc4.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

maropu · 2019-08-09T09:57:08Z

retest this please

SparkQA · 2019-08-09T13:43:14Z

Test build #108876 has finished for PR 25331 at commit e901dc4.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

SparkQA · 2019-08-12T19:16:18Z

Test build #108982 has finished for PR 25331 at commit 429048b.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

dongjoon-hyun · 2019-08-13T01:10:53Z

docs/sql-migration-guide-upgrade.md

+        </tr>
+        <tr>
+          <td>
+            CAST('infinity' TO DOUBLE)<br>


If this is a SQL syntax, TO -> AS?

dongjoon-hyun · 2019-08-13T01:11:47Z

Thank you for the decision, @srowen !

dongjoon-hyun · 2019-08-13T01:13:52Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/Cast.scala

+
+  /**
+   * We process literals such as 'Infinity', 'Inf', '-Infinity' and 'NaN' etc in case
+   * insensitive manner to be compatible with other database systems such as Postgres and DB2.


Postgres -> PostgreSQL.

dongjoon-hyun · 2019-08-13T01:27:42Z

@dilipbiswal . I update the PR title because this PR focuses on only Spark's float/double data types while PostgreSQL have more special cases in other data types like the following date.

postgres=# select cast('infinity' as date);
   date
----------
 infinity
(1 row)

dongjoon-hyun · 2019-08-13T01:29:25Z

docs/sql-migration-guide-upgrade.md

+            <b>Operation</b>
+          </th>
+          <th>
+            <b>Result prior to spark 3.0</b>


spark -> Spark.

dongjoon-hyun · 2019-08-13T01:29:31Z

docs/sql-migration-guide-upgrade.md

+            <b>Result prior to spark 3.0</b>
+          </th>
+          <th>
+            <b>Result starting spark 3.0</b>


dongjoon-hyun · 2019-08-13T01:30:47Z

docs/sql-migration-guide-upgrade.md

+        </tr>
+        <tr>
+          <td>
+            CAST('nan' TO FLOAT)


Please fix all instances of CAST. It seems to wrong as I commented in the above.

@dongjoon-hyun oops...thanks.. fixed.

dongjoon-hyun · 2019-08-13T01:45:43Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/Cast.scala

+            $evPrim = Float.valueOf($floatStr);
          } catch (java.lang.NumberFormatException e) {
-            $evNull = true;
+            Float f = (Float) Cast.processFloatingPointSpecialLiterals($floatStr, true);


Float -> final Float?

dongjoon-hyun · 2019-08-13T01:45:57Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/Cast.scala

+            $evPrim = Double.valueOf($doubleStr);
          } catch (java.lang.NumberFormatException e) {
-            $evNull = true;
+            Double d = (Double) Cast.processFloatingPointSpecialLiterals($doubleStr, false);


Double -> final Double?

dongjoon-hyun · 2019-08-13T01:49:30Z

sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/CastSuite.scala

+    checkEvaluation(cast("-infinity", FloatType), Float.NegativeInfinity)
+    checkEvaluation(cast("-infiniTy", FloatType), Float.NegativeInfinity)
+    checkEvaluation(cast("  -infinity  ", FloatType), Float.NegativeInfinity)
+    checkEvaluation(cast("  -inf  ", FloatType), Float.NegativeInfinity)


Do we have negative cases returning NULL in somewhere else?

dongjoon-hyun · 2019-08-13T01:51:47Z

sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/CastSuite.scala

+
+    checkEvaluation(cast("nan", FloatType), Float.NaN)
+    checkEvaluation(cast("nAn", FloatType), Float.NaN)
+    checkEvaluation(cast(" nan ", FloatType), Float.NaN)


nit. Can we have ' -naN ', too?

dongjoon-hyun · 2019-08-13T01:58:15Z

sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/CastSuite.scala

+
+    checkEvaluation(cast("nan", DoubleType), Double.NaN)
+    checkEvaluation(cast("nAn", DoubleType), Double.NaN)
+    checkEvaluation(cast(" nan ", DoubleType), Double.NaN)


Sorry for asking this, but can we use the following shorter form?

Seq("inf", "+inf", "infinity", "+infiNity", " infinity ").foreach { value => checkEvaluation(cast(value, FloatType), Float.PositiveInfinity) } Seq("-infinity", "-infiniTy", " -infinity ", " -inf ").foreach { value => checkEvaluation(cast(value, FloatType), Float.NegativeInfinity) } Seq("inf", "+inf", "infinity", "+infiNity", " infinity ").foreach { value => checkEvaluation(cast(value, DoubleType), Double.PositiveInfinity) } Seq("-infinity", "-infiniTy", " -infinity ", " -inf ").foreach { value => checkEvaluation(cast(value, DoubleType), Double.NegativeInfinity) } Seq("nan", "nAn", " nan ").foreach { value => checkEvaluation(cast(value, FloatType), Float.NaN) } Seq("nan", "nAn", " nan ").foreach { value => checkEvaluation(cast(value, DoubleType), Double.NaN) }

sql/core/src/test/resources/sql-tests/results/pgSQL/float4.sql.out

dongjoon-hyun · 2019-08-13T02:02:45Z

sql/core/src/test/resources/sql-tests/results/pgSQL/float8.sql.out

 struct<CAST(nan AS DOUBLE):double>
 -- !query 11 output
-NULL
+NaN


Please remove SPARK-28060 in float8.sql.

dongjoon-hyun · 2019-08-13T02:04:02Z

Thanks. @dilipbiswal . I'll review once more after you fix the above comments.

SparkQA · 2019-08-13T07:05:02Z

Test build #109014 has finished for PR 25331 at commit 1a5d978.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

dilipbiswal · 2019-08-13T07:13:02Z

retest this please

SparkQA · 2019-08-13T10:47:13Z

Test build #109025 has finished for PR 25331 at commit 1a5d978.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

dongjoon-hyun

+1, LGTM. Merged to master.
Thank you, @dilipbiswal , @maropu , @kiszk , @viirya , @srowen.

dilipbiswal · 2019-08-14T00:08:59Z

Thanks a lot @dongjoon-hyun @maropu @kiszk @viirya @srowen for very detailed review. Appreciate it very much !!

DylanGuedes · 2019-08-14T19:23:46Z

Hey @dilipbiswal , I get the following error for inline tables (although it work great for normal tables):

SELECT a, b,                                                                                                                                                  
       SUM(b) OVER(ORDER BY A ROWS BETWEEN 1 PRECEDING AND CURRENT ROW)                                                                                       
FROM (VALUES(1,1),(2,2),(3,'NaN'),(4,3),(5,4)) t(a,b);

org.apache.spark.sql.AnalysisException
incompatible types found in column col2 for inline table; line 3 pos 6

However, as I said, it works fine for normal tables:

insert into numerics values (0, 'NaN', 'NaN', '-1000');
select f_float4, sum(f_float4) over (order by f_float8 rows between 1 preceding and current row) from numerics;

Do you know if this is related to me making use of a window function or it is related to case-insensitively NaN for inline tables?

dilipbiswal · 2019-08-14T21:48:55Z

Hello @DylanGuedes

Don't think its related to case sensitivity. I have not looked at it in detail, but from a cursory look it seems like we are not able to promote the col2 values to a common type in this code path. Removing windowing all together, the following fails :

spark-sql> select * from (VALUES(1,1),(2,2),(3,'NaN'),(4,3),(5,4));
Error in query: incompatible types found in column col2 for inline table; line 1 pos 15

What is the table definition for numerics ? In case of normal table, the target type is known and so we try to implicitly convert/cast the input values to the target type. It is slightly different in case of inline tables.

DylanGuedes · 2019-08-15T12:03:58Z

Thank you for your answer, @dilipbiswal
numerics has the following scheme:

create table numerics (                                                                                                                                     |2
    id int,                                                                                                                                                 |2
    f_float4 float,                                                                                                                                         |2
    f_float8 float,                                                                                                                                         |2
    f_numeric int                                                                                                                                           |2
) using parquet;

dongjoon-hyun reviewed Aug 1, 2019

View reviewed changes

sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/CastSuite.scala Outdated Show resolved Hide resolved

dongjoon-hyun reviewed Aug 1, 2019

View reviewed changes

sql/core/src/test/resources/sql-tests/inputs/pgSQL/aggregates_part1.sql Show resolved Hide resolved

dongjoon-hyun added the SQL label Aug 1, 2019

maropu reviewed Aug 1, 2019

View reviewed changes

kiszk reviewed Aug 2, 2019

View reviewed changes

viirya reviewed Aug 2, 2019

View reviewed changes

maropu mentioned this pull request Aug 7, 2019

[SPARK-23160][SQL][TEST] Port window.sql #24881

Closed

srowen reviewed Aug 7, 2019

View reviewed changes

dilipbiswal added 6 commits August 8, 2019 18:05

[SPARK-27768] Infinity, -Infinity, NaN should be recognized in a case…

1011c2c

… insensitive manner

Code review

19957ac

Code review

6ce5094

viirya comment

5b3b734

Code review

48795b1

Locale fix

e901dc4

dilipbiswal force-pushed the double_infinity branch from 928e4c1 to e901dc4 Compare August 9, 2019 04:43

viirya reviewed Aug 9, 2019

View reviewed changes

migration guide

429048b

dongjoon-hyun reviewed Aug 13, 2019

View reviewed changes

dongjoon-hyun changed the title ~~[SPARK-27768][SQL] Infinity, -Infinity, NaN should be recognized in a case insensitive manner.~~ [SPARK-27768][SQL] Support Inf/Infinity/-Inf/-Infinity/NaN float/double literals case-insensitively Aug 13, 2019

dongjoon-hyun changed the title ~~[SPARK-27768][SQL] Support Inf/Infinity/-Inf/-Infinity/NaN float/double literals case-insensitively~~ [SPARK-27768][SQL] Support Infinity/NaN-related float/double literals case-insensitively Aug 13, 2019

dongjoon-hyun reviewed Aug 13, 2019

View reviewed changes

docs/sql-migration-guide-upgrade.md Outdated

<b>Operation</b>

</th>

<th>

<b>Result prior to spark 3.0</b>

Copy link

Member

dongjoon-hyun Aug 13, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

spark -> Spark.

dongjoon-hyun reviewed Aug 13, 2019

View reviewed changes

sql/core/src/test/resources/sql-tests/results/pgSQL/float4.sql.out Show resolved Hide resolved

dongjoon-hyun reviewed Aug 13, 2019

View reviewed changes

Code review

1a5d978

dongjoon-hyun approved these changes Aug 13, 2019

View reviewed changes

dongjoon-hyun closed this in 331f265 Aug 13, 2019


		def resolvableNullability(from: Boolean, to: Boolean): Boolean = !from \|\| to


		def resolvableNullability(from: Boolean, to: Boolean): Boolean = !from \|\| to

		def processFloatingPointSpecialLiterals(v: String, isFloat: Boolean): Any = {

[SPARK-27768][SQL] Support Infinity/NaN-related float/double literals case-insensitively #25331

[SPARK-27768][SQL] Support Infinity/NaN-related float/double literals case-insensitively #25331

Uh oh!

Conversation

dilipbiswal commented Aug 1, 2019

What changes were proposed in this pull request?

How was this patch tested?

Uh oh!

dilipbiswal commented Aug 1, 2019

Uh oh!

maropu commented Aug 1, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dilipbiswal Aug 2, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dilipbiswal Aug 2, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dongjoon-hyun Aug 4, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SparkQA commented Aug 2, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SparkQA commented Aug 2, 2019

Uh oh!

dilipbiswal commented Aug 2, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

maropu Aug 3, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

dilipbiswal Aug 2, 2019 •

edited

Loading

dilipbiswal Aug 2, 2019 •

edited

Loading

dongjoon-hyun Aug 4, 2019 •

edited

Loading

dilipbiswal commented Aug 2, 2019 •

edited

Loading

maropu Aug 3, 2019 •

edited

Loading

dilipbiswal commented Aug 7, 2019 •

edited

Loading