New implementation of getJsonObject #1893

res-life · 2024-03-25T01:15:58Z

Add a new version of Get json object to replace old version

Signed-off-by: Haoyang Li haoyangl@nvidia.com
Signed-off-by: Chong Gao res_life@163.com

* Add Json Parser; Add Json Parser utility; Define internal interfaces; Copy get-json-obj CUDA code from cuDF; Signed-off-by: Chong Gao <res_life@163.com> * Code format --------- Signed-off-by: Chong Gao <res_life@163.com> Co-authored-by: Chong Gao <res_life@163.com>

Signed-off-by: Chong Gao <res_life@163.com> Co-authored-by: Chong Gao <res_life@163.com>

…1863) Signed-off-by: Chong Gao <res_life@163.com> Co-authored-by: Chong Gao <res_life@163.com>

* Add JNI for GetJsonObject Signed-off-by: Haoyang Li <haoyangl@nvidia.com> * clean up Signed-off-by: Haoyang Li <haoyangl@nvidia.com> * Parse json path in plugin Signed-off-by: Haoyang Li <haoyangl@nvidia.com> * Apply suggestions from code review Co-authored-by: Nghia Truong <7416935+ttnghia@users.noreply.github.com> * Use table_view Signed-off-by: Haoyang Li <haoyangl@nvidia.com> * Update java Signed-off-by: Haoyang Li <haoyangl@nvidia.com> * Apply suggestions from code review Co-authored-by: Nghia Truong <7416935+ttnghia@users.noreply.github.com> * clean up Signed-off-by: Haoyang Li <haoyangl@nvidia.com> * use matched enum for type Signed-off-by: Haoyang Li <haoyangl@nvidia.com> * clean up Signed-off-by: Haoyang Li <haoyangl@nvidia.com> * upmerge Signed-off-by: Haoyang Li <haoyangl@nvidia.com> * format Signed-off-by: Haoyang Li <haoyangl@nvidia.com> --------- Signed-off-by: Haoyang Li <haoyangl@nvidia.com> Co-authored-by: Nghia Truong <7416935+ttnghia@users.noreply.github.com>

Signed-off-by: Chong Gao <res_life@163.com> Co-authored-by: Chong Gao <res_life@163.com>

* Optimize match_current_field_name using less memory Signed-off-by: Chong Gao <res_life@163.com> * Convert a function to device code * Add a JNI test case * Add JNI test case * Change nesting depth to 4 * Change nesting depth to 8 to fix test Signed-off-by: Haoyang Li <haoyangl@nvidia.com> * remove clang format change Signed-off-by: Haoyang Li <haoyangl@nvidia.com> --------- Signed-off-by: Chong Gao <res_life@163.com> Signed-off-by: Haoyang Li <haoyangl@nvidia.com> Co-authored-by: Chong Gao <res_life@163.com>

* Change recursive to iterative Signed-off-by: Chong Gao <res_life@163.com> --------- Signed-off-by: Chong Gao <res_life@163.com> Co-authored-by: Chong Gao <res_life@163.com>

res-life · 2024-03-25T01:31:06Z

build

res-life · 2024-03-25T03:12:55Z

@ttnghia Help review

Signed-off-by: Haoyang Li <haoyangl@nvidia.com>

res-life · 2024-03-25T09:10:45Z

build

res-life · 2024-03-25T11:38:36Z

build

revans2 · 2024-03-25T20:46:51Z

src/main/cpp/src/JSONUtilsJni.cpp

+
+extern "C" {
+JNIEXPORT jlong JNICALL Java_com_nvidia_spark_rapids_jni_JSONUtils_getJsonObject(
+  JNIEnv* env, jclass, jlong input_column, jint size, jobjectArray path_instructions)


nit: why do we need size if the path_instructions is an array that stores the size in it?

revans2 · 2024-03-25T20:49:45Z

src/main/cpp/src/JSONUtilsJni.cpp

+    for (int i = 0; i < size; i++) {
+      jobject instruction = env->GetObjectArrayElement(path_instructions, i);
+      JNI_NULL_CHECK(env, instruction, "path_instruction is null", 0);
+      jclass instruction_class = env->GetObjectClass(instruction);


nit: can we have a follow on where we change this to be 3 arrays? one that is an int array for the type, another that is a string array, and the last one would be a long array? This would reduce the number of reflection calls that would need to be done. This is very minor.

Humnn, probably I was the one that asked for using array of structs instead of individual arrays. But yeah for data transfer from Java to C++ then individual arrays seem to be better. I'm sorry @res-life.

Edit: I have a better idea. We want to have array of structs because that is simpler to iterate through the instructions. With individual arrays, we still can use thrust::zip_iterator to zip together multiple arrays with just one iterator and iterate through them easily. Of course this is not required to be in this PR but future work.

thrust::zip_iterator looks good, will do in a follow-on

revans2 · 2024-03-25T20:54:03Z

src/test/java/com/nvidia/spark/rapids/jni/GetJsonObjectTest.java

+  @Test
+  void getJsonObjectTest() {
+    JSONUtils.PathInstructionJni[] query = new JSONUtils.PathInstructionJni[2];
+    query[0] = new JSONUtils.PathInstructionJni(JSONUtils.PathInstructionType.KEY, "", -1);


Do we support arrays yet? I don't see any tests that include an array index that is not -1.

Added a case to query $[1][2]

revans2 · 2024-03-25T20:55:07Z

src/main/java/com/nvidia/spark/rapids/jni/JSONUtils.java

+  }
+
+  public enum PathInstructionType {
+    SUBSCRIPT,


nit: I would prefer to have the enum to int mapping be specific instead of using the ordinal. It is minor, but helps to prevent issues where one is updated and the other is missed.

will do in a follow-on

revans2 · 2024-03-25T20:55:48Z

src/main/java/com/nvidia/spark/rapids/jni/JSONUtils.java

+    NAMED
+  }
+
+  public static class PathInstructionJni {


Could we have some javadocs on this, and the constructor. It is not always clear what it does.

will do in a follow-on

revans2 · 2024-03-25T20:56:06Z

src/main/java/com/nvidia/spark/rapids/jni/JSONUtils.java

+    }
+  }
+
+  public static ColumnVector getJsonObject(ColumnVector input, int size, PathInstructionJni[] path_instructions) {


Again not sure why size is needed here.

ttnghia

Flush my first round of review for quick response while continuing the review process. Overall, I don't find any big concerns since we are currently prioritizing correctness over clean code. But definitely we need to have follow up work with a lot of things to do.

ttnghia · 2024-03-25T21:12:12Z

src/main/cpp/src/get_json_object.cu

+namespace spark_rapids_jni {
+
+namespace detail {
+// namespace {


Nit: left over for removal. Or it should be uncommented.

Done, removed.

ttnghia · 2024-03-25T21:17:29Z

src/main/cpp/src/get_json_object.cu

+__device__ bool evaluate_path(json_parser<>& p,
+                              json_generator<>& g,
+                              write_style style,
+                              path_instruction const* path_ptr,
+                              int path_size)
+{
+  return path_evaluator::evaluate_path(p, g, style, path_ptr, path_size);
+}


Oh this is just calling to another function. Why do we ever need it?

Done, removed.

src/main/cpp/src/get_json_object.cu

ttnghia · 2024-03-25T21:25:11Z

src/main/cpp/src/get_json_object.cu

+ * @param commands The command buffer to be applied to the string. Always ends
+ * with a path_operator_type::END
+ * @param out_buf Buffer user to store the results of the query (nullptr in the
+ * size computation step)


Nit: This is better for readability.

Suggested change

* @param commands The command buffer to be applied to the string. Always ends

* with a path_operator_type::END

* @param out_buf Buffer user to store the results of the query (nullptr in the

* size computation step)

* @param commands The command buffer to be applied to the string. Always ends

* with a path_operator_type::END

* @param out_buf Buffer user to store the results of the query (nullptr in the

* size computation step)

ttnghia · 2024-03-25T21:26:05Z

src/main/cpp/src/get_json_object.cu

+ * This kernel operates in a 2-pass way.  On the first pass, it computes
+ * output sizes.  On the second pass it fills in the provided output buffers
+ * (chars and validity)


Suggested change

* This kernel operates in a 2-pass way. On the first pass, it computes

* output sizes. On the second pass it fills in the provided output buffers

* (chars and validity)

* This kernel operates in a 2-pass way. On the first pass it computes the

* output sizes. On the second pass, it fills in the provided output buffers

* (chars and validity).

ttnghia · 2024-03-25T22:37:30Z

src/main/cpp/src/get_json_object.hpp

+      CUDF_HOST_DEVICE context& operator=(const context& other)
+      {
+        token          = other.token;
+        case_path      = other.case_path;
+        g              = other.g;
+        style          = other.style;
+        path_ptr       = other.path_ptr;
+        path_size      = other.path_size;
+        task_is_done   = other.task_is_done;
+        dirty          = other.dirty;
+        is_first_enter = other.is_first_enter;
+        child_g        = other.child_g;
+
+        return *this;


This seems to have nothing special, so just leave the compiler do it.

Suggested change

CUDF_HOST_DEVICE context& operator=(const context& other)

{

token = other.token;

case_path = other.case_path;

g = other.g;

style = other.style;

path_ptr = other.path_ptr;

path_size = other.path_size;

task_is_done = other.task_is_done;

dirty = other.dirty;

is_first_enter = other.is_first_enter;

child_g = other.child_g;

return *this;

CUDF_HOST_DEVICE context& operator=(context const&) = default;

ttnghia · 2024-03-25T22:40:39Z

src/main/cpp/src/get_json_object.hpp

+ * input json string is invalid.
+ */
+std::unique_ptr<cudf::column> get_json_object(
+  cudf::strings_column_view const& col,


Suggested change

cudf::strings_column_view const& col,

cudf::strings_column_view const& input,

ttnghia · 2024-03-25T22:42:16Z

src/main/cpp/src/json_parser.hpp

+template <bool allow_single_quotes           = curr_allow_single_quotes,
+          bool allow_unescaped_control_chars = curr_allow_unescaped_control_chars,
+          int max_json_nesting_depth         = curr_max_json_nesting_depth,
+          int max_string_utf8_bytes          = curr_max_string_utf8_bytes,
+          int max_num_len                    = curr_max_num_len,
+          bool allow_tailing_sub_string      = curr_allow_tailing_sub_string>


Nit: Oh no, too many template parameters. They will make compilation very slow. We should better use run time parameters, except only the parameters that need to be known at compile time. In future work we have to clean up this.

Only have one template combination.

Will do in a follow-on.

ttnghia · 2024-03-25T22:44:54Z

src/main/cpp/src/json_parser.hpp

+/**
+ * write style when writing out JSON string
+ */


My comment for the docs in this file is similar to the previous one: Don't use non-standard oxygen. I'm fine to leave them for now but we have to cleanup in the follow up work.

Will do in a follow-on.

ttnghia · 2024-03-25T22:45:20Z

src/main/cpp/src/json_parser.hpp

+  /**
+   * is current position EOF
+   */
+  CUDF_HOST_DEVICE inline bool eof(char const* pos) { return pos >= json_end_pos; }


Also CUDF_HOST_DEVICEs need to be only __device__ if possible.

res-life · 2024-03-26T00:41:03Z

Flush my first round of review for quick response while continuing the review process. Overall, I don't find any big concerns since we are currently prioritizing correctness over clean code. But definitely we need to have follow up work with a lot of things to do.

Yes, follow up things:

Performance tuning/improvement.
Convert test cases on CPU to GPU.

res-life · 2024-03-26T02:50:40Z

build

thirtiseven · 2024-03-26T09:44:26Z

src/test/java/com/nvidia/spark/rapids/jni/GetJsonObjectTest.java

+
+    String JSON = "[100.0,200.000,351.980]";
+    String expectedStr = "[100.0,200.000,351.980]";
+    try (


Seems it is a temp test data?

* Support number normalization Signed-off-by: Haoyang Li <haoyangl@nvidia.com> * delete cpp test and add a java test case Signed-off-by: Haoyang Li <haoyangl@nvidia.com> --------- Signed-off-by: Haoyang Li <haoyangl@nvidia.com>

ttnghia · 2024-03-26T21:37:56Z

src/main/cpp/src/get_json_object.hpp

+/**
+ * write JSON style
+ */
+enum class write_style { raw_style, quoted_style, flatten_style };


Nit: Enum class values should be ALL_CAP. In addition, they don't have to all have the suffix _style.

Suggested change

enum class write_style { raw_style, quoted_style, flatten_style };

enum class write_style { RAW, QUOTED, FLATTEN };

BTW, why path_instruction_type is outside while write_style is inside namespace detail?

src/main/cpp/src/JSONUtilsJni.cpp refers to it.

res-life · 2024-03-26T22:36:08Z

src/main/cpp/src/json_parser.hpp

+        case 't':
+          if (nullptr != copy_dest && write_style::unescaped == w_style) { *copy_dest++ = '\t'; }
+          if (copy_dest != nullptr && write_style::escaped == w_style) {
+            if (copy_dest != nullptr) {


Check again: copy_dest != nullptr, it is redudant.
Go through all copy_dest and w_style related paths.
And add cases.

mythrocks · 2024-03-26T22:52:18Z

Could we consider changing the title of this PR? Perhaps "New implementation of getJsonObject", or something more descriptive?

mythrocks · 2024-03-26T22:55:21Z

src/main/cpp/src/ftos_converter.cuh

  bool scientificNotation = (exp < -3) || (exp >= 7);

  // Values in the interval [1E-3, 1E7) are special.
  if (scientificNotation) {
    // Print in the format x.xxxxxE-yy.
-    for (uint32_t i = 0; i < olength - 1; ++i) {
-      uint32_t const c = output % 10;
+    for (int i = 0; i < olength - 1; ++i) {


Not necessary to change this, but we could have gotten away with the following:

Suggested change

for (int i = 0; i < olength - 1; ++i) {

for (auto i = 0; i < olength - 1; ++i) {

Alternatively, let's use int32_t consistently. No need to bring int into it also.

Will do in a follow-on.

res-life · 2024-03-26T23:02:01Z

Could we consider changing the title of this PR? Perhaps "New implementation of getJsonObject", or something more descriptive?

Done.

mythrocks · 2024-03-26T23:24:51Z

src/main/cpp/src/ftos_converter.cuh

+  // no NaN in json
+  if (exponent) {
+    if (sign) {
+      memcpy(result, "\"-Infinity\"", 11);


Nitpick: Feel free to ignore:

I had to count the characters to make sure 11 is right. :]
One trick is to use sizeof("\"-Infinity\"") - 1. That is constexpr and should yield 11.
I suspect strlen("\"-Infinity\"") is more readable, but I'm not sure it's constexpr in __device__. (I know it is in __host__ C++.)

Will do in a follow-on.

mythrocks · 2024-03-26T23:31:09Z

src/main/cpp/src/ftos_converter.cuh

@@ -1424,4 +1475,15 @@ __device__ inline int format_float(double value, int digits, bool is_float, char
  }
 }

+//===== json_parser utility =====
+
+__device__ inline int double_normalization(double value, char* output)


Let's consider renaming this to normalize_double().
Also, consider a function doc line indicating the protocol of returning the number of characters if output is nullptr.

Will do in a follow-on.

ttnghia · 2024-03-26T21:39:09Z

src/main/cpp/src/get_json_object.hpp

+    : output(nullptr), output_len(0), hide_outer_array_tokens(_hide_outer_array_tokens)
+  {
+  }
+  __device__ json_generator<>& operator=(const json_generator<>& other)


Suggested change

__device__ json_generator<>& operator=(const json_generator<>& other)

__device__ json_generator<>& operator=(json_generator<> const& other)

ttnghia · 2024-03-26T21:39:45Z

src/main/cpp/src/get_json_object.hpp

+/**
+ * write JSON style
+ */
+enum class write_style { raw_style, quoted_style, flatten_style };


BTW, why path_instruction_type is outside while write_style is inside namespace detail?

ttnghia · 2024-03-26T23:24:43Z

src/main/cpp/src/get_json_object.hpp

+/**
+ * path evaluator which can run on both CPU and GPU
+ */
+struct path_evaluator {


Nit: Device code and/or class with device code should be placed in .cu or .cuh files. .hpp files should never contain device code.

ttnghia · 2024-03-26T23:26:38Z

src/main/cpp/src/get_json_object.hpp

+    constexpr int max_path_depth = 32;
+
+    // stack
+    context stack[max_path_depth];


I'm not sure about this declaration but feel really nervous about it. Typically, a GPU thread has very limited resources (memory/registers etc). Reserving a large array in a thread will stress on the resources, which results in fewer number of threads per block and reduces performance. Probably the better way is to declare this as a shared memory array instead. I'm not 100% sure until we can run profiling on this.

In addition, the code below also has a lot of if/else branches without any thread sync. Thus, thread divergence may occur which causes further slowdown. I have little idea about what can we improve for that huge while loop 😢

I filed a following on perf issue:
#1907

ttnghia · 2024-03-26T23:32:30Z

src/main/cpp/src/json_parser.hpp

+enum class write_style {
+  // e.g.: '\\r' is a string with 2 chars '\' 'r', writes 1 char '\r'
+  unescaped,
+
+  // * e.g.: '"' is a string with 1 char '"', writes out 4 chars '"' '\' '\"'
+  // '"'
+  escaped
+};


Suggested change

enum class write_style {

// e.g.: '\\r' is a string with 2 chars '\' 'r', writes 1 char '\r'

unescaped,

// * e.g.: '"' is a string with 1 char '"', writes out 4 chars '"' '\' '\"'

// '"'

escaped

};

enum class write_style {

// e.g.: '\\r' is a string with 2 chars '\' 'r', writes 1 char '\r'

UNESCAPED,

// * e.g.: '"' is a string with 1 char '"', writes out 4 chars '"' '\' '\"'

// '"'

ESCAPED

};

Will fix in a follow-on

ttnghia · 2024-03-26T23:33:05Z

src/main/cpp/src/json_parser.hpp

+class json_parser {
+ public:
+  __device__ inline json_parser(char const* const _json_start_pos, cudf::size_type const _json_len)
+    : json_start_pos(_json_start_pos),
+      json_end_pos(_json_start_pos + _json_len),
+      curr_pos(_json_start_pos)
+  {
+  }
+


Again, device code should be in .cuh file.

Will fix in a follow-on

mythrocks · 2024-03-26T23:45:58Z

src/main/cpp/src/ftos_converter.cuh

+
+__device__ inline int double_normalization(double value, char* output)
+{
+  if (output == nullptr) {


I haven't fully grasped the control flow, so this might be a silly observation:

We might be inadvertently checking output == nullptr multiple times, both from the call-site and here. Since this is a __device__ function, this might amount to a lot of calls.

In a follow-up, there might be value in separating those call chains. Computing the sizes can be done separately from actually writing the normalized value. Just a thought for future consideration.

Will fix in a follow-on

mythrocks · 2024-03-26T23:47:13Z

src/main/cpp/src/get_json_object.cu

+    auto const& [type, name, index] = inst;
+    switch (type) {
+      case path_instruction_type::SUBSCRIPT:
+        path_commands.emplace_back(path_instruction{path_instruction_type::SUBSCRIPT});


Nitpick: If we're using emplace_back, we might be able to get away with:

Suggested change

path_commands.emplace_back(path_instruction{path_instruction_type::SUBSCRIPT});

path_commands.emplace_back(path_instruction_type::SUBSCRIPT);

res-life · 2024-03-27T07:56:03Z

build

Signed-off-by: Haoyang Li <haoyangl@nvidia.com>

res-life · 2024-03-27T08:12:11Z

For further verification, please run compute-sanitizer with Java test to make sure we don't have memory bug (using the tutorial for standalone mode in https://nvidia.github.io/spark-rapids/docs/dev/compute_sanitizer.html).

Done for the JNI case: GetJsonObjectTest.java

res-life · 2024-03-27T08:38:49Z

build

res-life · 2024-03-27T08:46:32Z

Filed 3 follow-on issues:
Doc follow-on: #1905
Comments follow-on: #1906
Perf follow-on: #1907

res-life · 2024-03-27T11:05:43Z

Now the GetJsonObjectTest.java already tested all the case paths of evaluate_path.
And Spark-Rapids PR also verified the issues:

Fixes #10218
Fixes #10212
Fixes #10194
Fixes #10196
Fixes #10537
Fixes #10216
Fixes #10217
Fixes #9033

@ttnghia I think it's safe to merge this PR now.

res-life · 2024-03-27T13:23:32Z

build

res-life · 2024-03-27T13:30:22Z

Sorry, one more fix.
Please allow me to say it again: I think it's safe to merge this PR now.
Locally, I got a 100% code coverage for JSON generator and evaluate_path.

ttnghia · 2024-03-27T14:07:23Z

I think it's safe to merge this PR now.

Is there any chance to run compute-sanitizer on the tests before merging?

thirtiseven · 2024-03-27T15:39:26Z

I think it's safe to merge this PR now.

Is there any chance to run compute-sanitizer on the tests before merging?

Tests can pass with sanitizer on.

Merging it…

res-life and others added 9 commits March 10, 2024 08:35

get-json-object: match current field name (#1857)

e3dfdaa

Signed-off-by: Chong Gao <res_life@163.com> Co-authored-by: Chong Gao <res_life@163.com>

get-json-object: add utility write_escaped_text for JSON generator (#…

72d2994

…1863) Signed-off-by: Chong Gao <res_life@163.com> Co-authored-by: Chong Gao <res_life@163.com>

get-json-object: main flow (#1868)

304bf71

Signed-off-by: Chong Gao <res_life@163.com> Co-authored-by: Chong Gao <res_life@163.com>

get-json-object: Recursive to iterative (#1890)

5b922ce

* Change recursive to iterative Signed-off-by: Chong Gao <res_life@163.com> --------- Signed-off-by: Chong Gao <res_life@163.com> Co-authored-by: Chong Gao <res_life@163.com>

Fix bug

d312a7a

Format

50481ab

res-life mentioned this pull request Mar 25, 2024

[FEA] GetJsonObject: Implement get-json-object in JNI repo as Spark does #1823

Closed

15 tasks

thirtiseven mentioned this pull request Mar 25, 2024

Use new jni kernel for getJsonObject NVIDIA/spark-rapids#10581

Merged

This was referenced Mar 25, 2024

[FEA] Fix GetJsonObject NVIDIA/spark-rapids#10254

Open

GetJsonObject: Merge feature branch to release branch #1891

Closed

thirtiseven added 2 commits March 25, 2024 11:26

Merge branch 'branch-24.04' into get-json-object-feature

c971f61

Use uppercase for path_instruction_type

e7801bd

Signed-off-by: Haoyang Li <haoyangl@nvidia.com>

Add test cases from Baidu

3c561f7

res-life changed the title ~~Get json object: merge branch feature to release branch~~ Get json object: merge feature branch to release branch Mar 25, 2024

res-life requested review from ttnghia and revans2 March 25, 2024 11:54

revans2 reviewed Mar 25, 2024

View reviewed changes

ttnghia reviewed Mar 25, 2024

View reviewed changes

Fix escape char error; add test case

848c92b

thirtiseven reviewed Mar 26, 2024

View reviewed changes

getJsonObject number normalization (#1897)

2ae268a

* Support number normalization Signed-off-by: Haoyang Li <haoyangl@nvidia.com> * delete cpp test and add a java test case Signed-off-by: Haoyang Li <haoyangl@nvidia.com> --------- Signed-off-by: Haoyang Li <haoyangl@nvidia.com>

ttnghia reviewed Mar 26, 2024

View reviewed changes

res-life commented Mar 26, 2024

View reviewed changes

mythrocks reviewed Mar 26, 2024

View reviewed changes

res-life changed the title ~~Get json object: merge feature branch to release branch~~ New implementation of getJsonObject Mar 26, 2024

mythrocks reviewed Mar 26, 2024

View reviewed changes

ttnghia reviewed Mar 26, 2024

View reviewed changes

mythrocks reviewed Mar 26, 2024

View reviewed changes

Add test cases; Fix a bug

a204efa

follow up escape/unescape bug fix

9686754

Signed-off-by: Haoyang Li <haoyangl@nvidia.com>

Minor refactor

01e6029

Add a case; Fix bug

fa02fc9

ttnghia approved these changes Mar 27, 2024

View reviewed changes

thirtiseven merged commit 87216f2 into branch-24.04 Mar 27, 2024
3 checks passed

res-life deleted the get-json-object-feature branch March 27, 2024 15:48

	cudf::strings_column_view const& col,
	cudf::strings_column_view const& input,

	enum class write_style { raw_style, quoted_style, flatten_style };
	enum class write_style { RAW, QUOTED, FLATTEN };

	for (int i = 0; i < olength - 1; ++i) {
	for (auto i = 0; i < olength - 1; ++i) {

	__device__ json_generator<>& operator=(const json_generator<>& other)
	__device__ json_generator<>& operator=(json_generator<> const& other)

	path_commands.emplace_back(path_instruction{path_instruction_type::SUBSCRIPT});
	path_commands.emplace_back(path_instruction_type::SUBSCRIPT);

New implementation of getJsonObject #1893

New implementation of getJsonObject #1893

Conversation

res-life commented Mar 25, 2024

res-life commented Mar 25, 2024

res-life commented Mar 25, 2024

res-life commented Mar 25, 2024

res-life commented Mar 25, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ttnghia Mar 25, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ttnghia left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

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

res-life commented Mar 26, 2024

res-life commented Mar 26, 2024

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

mythrocks commented Mar 26, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

res-life commented Mar 26, 2024

mythrocks Mar 26, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

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

res-life commented Mar 27, 2024

res-life commented Mar 27, 2024

res-life commented Mar 27, 2024

res-life commented Mar 27, 2024 • edited Loading

ttnghia Mar 25, 2024 •

edited

Loading

ttnghia left a comment •

edited

Loading

mythrocks Mar 26, 2024 •

edited

Loading

res-life commented Mar 27, 2024 •

edited

Loading

res-life commented Mar 27, 2024 •

edited

Loading