[GitHub] [arrow] kou closed issue #14816: [Release] Make dev/release/06-java-upload.sh reusable from other project

2022-12-02 Thread GitBox


kou closed issue #14816: [Release] Make dev/release/06-java-upload.sh reusable 
from other project
URL: https://github.com/apache/arrow/issues/14816


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@arrow.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[jira] [Created] (ARROW-18423) [Python] Expose reading a schema from an IPC message

2022-12-02 Thread Andre Kohn (Jira)
Andre Kohn created ARROW-18423:
--

 Summary: [Python] Expose reading a schema from an IPC message
 Key: ARROW-18423
 URL: https://issues.apache.org/jira/browse/ARROW-18423
 Project: Apache Arrow
  Issue Type: Improvement
  Components: Python
Reporter: Andre Kohn


Pyarrow currently does not implement reading the Arrow schema from an IPC 
message.

[https://github.com/apache/arrow/blob/80b389efe902af376a85a8b3740e0dbdc5f80900/python/pyarrow/ipc.pxi#L1094]

 

We'd like to consume Arrow IPC stream data like the following:

```

    schema_msg = pyarrow.ipc.read_message(result_iter.next().data)
    schema = pyarrow.ipc.read_schema(schema_msg)
    for batch_data in result_iter:
        batch_msg = pyarrow.ipc.read_message(batch_data.data)
        batch = pyarrow.ipc.read_record_batch(batch_msg, schema)
```

 

The associated (tiny) PR on GitHub implements this reading by binding the 
existing C++ function.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [arrow] kou closed issue #14819: [CI][RPM] CentOS 9 Stream nightly CI is failed

2022-12-02 Thread GitBox


kou closed issue #14819: [CI][RPM] CentOS 9 Stream nightly CI is failed
URL: https://github.com/apache/arrow/issues/14819


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@arrow.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [arrow] kou opened a new issue, #14829: [CI][R][Homebrew] Nightly CI jobs aren't maintained

2022-12-02 Thread GitBox


kou opened a new issue, #14829:
URL: https://github.com/apache/arrow/issues/14829

   ### Describe the bug, including details regarding any error messages, 
version, and platform.
   
   `homebrew-r-autobrew` and `homebrew-r-brew` nightly CI jobs are failing in 
past 3 months:
   
   Can we maintain them? If we can't maintain them, can we remove them? Are 
they useful to maintain something?
   
   http://crossbow.voltrondata.com/
   
   Task Name | Since Last Successful Build | Last Successful Commit | Last 
Successful Build | First Failure | 9 Days Ago | 8 Days Ago | 7 Days Ago | 6 
Days Ago | 5 Days Ago | 4 Days Ago | 3 Days Ago | 2 Days Ago | Most Recent 
Failure
   -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
   homebrew-r-autobrew | 94 days | cf27001 | pass | fail | fail | fail | fail | 
fail | fail | fail | fail | fail | fail
   homebrew-r-brew | 83 days | a63e60b | pass | fail | fail | fail | fail | 
fail | fail | fail | fail | fail | fail
   
   
   
   ### Component(s)
   
   Continuous Integration, R


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@arrow.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [arrow] kou opened a new issue, #14828: [CI][Conda] Nightly CI jobs aren't maintained

2022-12-02 Thread GitBox


kou opened a new issue, #14828:
URL: https://github.com/apache/arrow/issues/14828

   ### Describe the bug, including details regarding any error messages, 
version, and platform.
   
   Nightly CI jobs for Conda were fixed by @h-vetinari and @xhochy in GH-14102 
but most nightly CI jobs are failing again this past month.
   
   Can we maintain them? If we can't maintain them, can we remove them? Are 
they useful to maintain https://github.com/conda-forge/arrow-cpp-feedstock ?
   
   http://crossbow.voltrondata.com/
   
   Task Name | Since Last Successful Build | Last Successful Commit | Last 
Successful Build | First Failure | 9 Days Ago | 8 Days Ago | 7 Days Ago | 6 
Days Ago | 5 Days Ago | 4 Days Ago | 3 Days Ago | 2 Days Ago | Most Recent 
Failure
   -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
   conda-win-vs2019-py37-r40 | 78 days | 5e6da78 | pending | fail | fail | fail 
| fail | fail | fail | fail | fail | fail | fail
   conda-win-vs2019-py38 | 65 days | 60c9383 | pending | fail | fail | fail | 
fail | fail | fail | fail | fail | fail | fail
   conda-linux-gcc-py310-arm64 | 29 days | 8e3a1e1 | pass | fail | fail | fail 
| fail | fail | fail | fail | fail | fail | fail
   conda-linux-gcc-py310-cpu | 29 days | 8e3a1e1 | pass | fail | fail | fail | 
fail | fail | fail | fail | fail | fail | fail
   conda-linux-gcc-py37-arm64 | 29 days | 8e3a1e1 | pass | fail | fail | fail | 
fail | fail | fail | fail | fail | fail | fail
   conda-linux-gcc-py37-cpu-r40 | 29 days | 8e3a1e1 | pass | fail | fail | fail 
| fail | fail | fail | fail | fail | fail | fail
   conda-linux-gcc-py37-cpu-r41 | 29 days | 8e3a1e1 | pass | fail | fail | fail 
| fail | fail | fail | fail | fail | fail | fail
   conda-linux-gcc-py37-cuda | 29 days | 8e3a1e1 | pass | fail | fail | fail | 
fail | fail | fail | fail | fail | fail | fail
   conda-linux-gcc-py37-ppc64le | 29 days | 8e3a1e1 | pass | fail | fail | fail 
| fail | fail | fail | fail | fail | fail | fail
   conda-linux-gcc-py38-arm64 | 29 days | 8e3a1e1 | pass | fail | fail | fail | 
fail | fail | fail | fail | fail | fail | fail
   conda-linux-gcc-py38-cpu | 29 days | 8e3a1e1 | pass | fail | fail | fail | 
fail | fail | fail | fail | fail | fail | fail
   conda-linux-gcc-py38-cuda | 29 days | 8e3a1e1 | pass | fail | fail | fail | 
fail | fail | fail | fail | fail | fail | fail
   conda-linux-gcc-py38-ppc64le | 29 days | 8e3a1e1 | pass | fail | fail | fail 
| fail | fail | fail | fail | fail | fail | fail
   conda-linux-gcc-py39-arm64 | 29 days | 8e3a1e1 | pass | fail | fail | fail | 
fail | fail | fail | fail | fail | fail | fail
   conda-linux-gcc-py39-cpu | 29 days | 8e3a1e1 | pass | fail | fail | fail | 
fail | fail | fail | fail | fail | fail | fail
   conda-linux-gcc-py39-cuda | 29 days | 8e3a1e1 | pass | fail | fail | fail | 
fail | fail | fail | fail | fail | fail | fail
   conda-linux-gcc-py39-ppc64le | 29 days | 8e3a1e1 | pass | fail | fail | fail 
| fail | fail | fail | fail | fail | fail | fail
   conda-osx-arm64-clang-py38 | 29 days | 8e3a1e1 | pass | fail | fail | fail | 
fail | fail | fail | fail | fail | fail | fail
   conda-osx-arm64-clang-py39 | 29 days | 8e3a1e1 | pass | fail | fail | fail | 
fail | fail | fail | fail | fail | fail | fail
   conda-osx-clang-py37-r40 | 29 days | 8e3a1e1 | pass | fail | fail | fail | 
fail | fail | fail | fail | fail | fail | fail
   conda-osx-clang-py37-r41 | 29 days | 8e3a1e1 | pass | fail | fail | fail | 
fail | fail | fail | fail | fail | fail | fail
   conda-osx-clang-py38 | 29 days | 8e3a1e1 | pass | fail | fail | fail | fail 
| fail | fail | fail | fail | fail | fail
   conda-osx-clang-py39 | 29 days | 8e3a1e1 | pass | fail | fail | fail | fail 
| fail | fail | fail | fail | fail | fail
   conda-linux-gcc-py310-cuda | 15 days | 501b799 | pass | fail | fail | fail | 
fail | fail | fail | fail | fail | fail | fail
   conda-linux-gcc-py310-ppc64le | 15 days | 501b799 | pass | fail | fail | 
fail | fail | fail | fail | fail | fail | fail | fail
   conda-osx-arm64-clang-py310 | 15 days | 501b799 | pass | fail | fail | fail 
| fail | fail | fail | fail | fail | fail | fail
   conda-osx-clang-py310 | 15 days | 501b799 | pass | fail | fail | fail | fail 
| fail | fail | fail | fail | fail | fail
   
   
   
   ### Component(s)
   
   Continuous Integration, Packaging


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@arrow.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [arrow] kou closed issue #14801: [C++] CMake config files for Dataset are not copied to the install directory

2022-12-02 Thread GitBox


kou closed issue #14801: [C++] CMake config files for Dataset are not copied to 
the install directory 
URL: https://github.com/apache/arrow/issues/14801


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@arrow.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[jira] [Created] (ARROW-18422) [C++] Provide enum reflection utility

2022-12-02 Thread Ben Kietzman (Jira)
Ben Kietzman created ARROW-18422:


 Summary: [C++] Provide enum reflection utility
 Key: ARROW-18422
 URL: https://issues.apache.org/jira/browse/ARROW-18422
 Project: Apache Arrow
  Issue Type: Improvement
  Components: C++
Reporter: Ben Kietzman
Assignee: Ben Kietzman


Now that we have c++17, we could try again with ARROW-13296



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [arrow] paleolimbot closed issue #14813: [R] Install from local source on MacOS fails build after Abseil build step

2022-12-02 Thread GitBox


paleolimbot closed issue #14813: [R] Install from local source on MacOS fails 
build after Abseil build step
URL: https://github.com/apache/arrow/issues/14813


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@arrow.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [arrow] LucyMcGowan opened a new issue, #14826: write_dataset is crashing on my machine

2022-12-02 Thread GitBox


LucyMcGowan opened a new issue, #14826:
URL: https://github.com/apache/arrow/issues/14826

   ### Describe the bug, including details regarding any error messages, 
version, and platform.
   
   When I run the following example from the documentation, it seems to crash. 
   
   ```
   library(arrow)
   one_level_tree <- tempfile()
   write_dataset(mtcars, one_level_tree, partitioning = "cyl")
   ```
   
   This reprex appears to crash R.
   See standard output and standard error for more details.
   
    Standard output and error
   
   ``` sh
   ✖ Install the styler package in order to use `style = TRUE`.
   
*** caught illegal operation ***
   address 0x11746ec1f, cause 'illegal opcode'
   
   Traceback:
1: ExecPlan_Write(self, node, 
prepare_key_value_metadata(node$final_metadata()), ...)
2: plan$Write(final_node, options, path_and_fs$fs, path_and_fs$path, 
partitioning, basename_template, existing_data_behavior, max_partitions, 
max_open_files, max_rows_per_file, min_rows_per_group, max_rows_per_group)
3: write_dataset(mtcars, one_level_tree, partitioning = "cyl")
4: eval(expr, envir, enclos)
5: eval(expr, envir, enclos)
6: eval_with_user_handlers(expr, envir, enclos, user_handlers)
7: withVisible(eval_with_user_handlers(expr, envir, enclos, user_handlers))
8: withCallingHandlers(withVisible(eval_with_user_handlers(expr, envir, 
enclos, user_handlers)), warning = wHandler, error = eHandler, message = 
mHandler)
9: doTryCatch(return(expr), name, parentenv, handler)
   10: tryCatchOne(expr, names, parentenv, handlers[[1L]])
   11: tryCatchList(expr, classes, parentenv, handlers)
   12: tryCatch(expr, error = function(e) {call <- conditionCall(e)if 
(!is.null(call)) {if (identical(call[[1L]], quote(doTryCatch))) 
call <- sys.call(-4L)dcall <- deparse(call, nlines = 1L)
prefix <- paste("Error in", dcall, ": ")LONG <- 75Lsm <- 
strsplit(conditionMessage(e), "\n")[[1L]]w <- 14L + nchar(dcall, type = 
"w") + nchar(sm[1L], type = "w")if (is.na(w)) w <- 14L + 
nchar(dcall, type = "b") + nchar(sm[1L], type = "b")if 
(w > LONG) prefix <- paste0(prefix, "\n  ")}else prefix <- 
"Error : "msg <- paste0(prefix, conditionMessage(e), "\n")
.Internal(seterrmessage(msg[1L]))if (!silent && 
isTRUE(getOption("show.error.messages"))) {cat(msg, file = outFile) 
   .Internal(printDeferredWarnings())}invisible(structure(msg, class = 
"try-error", condition = e))})
   13: try(f, silent = TRUE)
   14: handle(ev <- 
withCallingHandlers(withVisible(eval_with_user_handlers(expr, envir, 
enclos, user_handlers)), warning = wHandler, error = eHandler, message = 
mHandler))
   15: timing_fn(handle(ev <- 
withCallingHandlers(withVisible(eval_with_user_handlers(expr, envir, 
enclos, user_handlers)), warning = wHandler, error = eHandler, message = 
mHandler)))
   16: evaluate_call(expr, parsed$src[[i]], envir = envir, enclos = enclos, 
debug = debug, last = i == length(out), use_try = stop_on_error != 2L, 
keep_warning = keep_warning, keep_message = keep_message, output_handler = 
output_handler, include_timing = include_timing)
   17: evaluate::evaluate(...)
   18: evaluate(code, envir = env, new_device = FALSE, keep_warning = 
!isFALSE(options$warning), keep_message = !isFALSE(options$message), 
stop_on_error = if (is.numeric(options$error)) options$error else {if 
(options$error && options$include) 0Lelse 2L}, 
output_handler = knit_handlers(options$render, options))
   19: in_dir(input_dir(), evaluate(code, envir = env, new_device = FALSE, 
keep_warning = !isFALSE(options$warning), keep_message = 
!isFALSE(options$message), stop_on_error = if (is.numeric(options$error)) 
options$error else {if (options$error && options$include) 
0Lelse 2L}, output_handler = knit_handlers(options$render, 
options)))
   20: eng_r(options)
   21: block_exec(params)
   22: call_block(x)
   23: process_group.block(group)
   24: process_group(group)
   25: withCallingHandlers(if (tangle) process_tangle(group) else 
process_group(group), error = function(e) {setwd(wd)
cat(res, sep = "\n", file = output %n% "")message("Quitting from lines 
", paste(current_lines(i), collapse = "-"), " (", 
knit_concord$get("infile"), ") ")})
   26: process_file(text, output)
   27: knitr::knit(knit_input, knit_output, envir = envir, quiet = quiet)
   28: rmarkdown::render(input, quiet = TRUE, envir = globalenv(), encoding = 
"UTF-8")
   29: (function (input) {rmarkdown::render(input, quiet = TRUE, envir = 
globalenv(), encoding = "UTF-8")})(input = 
base::quote("front-ray_reprex.R"))
   30: (function (what, args, quote = FALSE, envir = parent.frame()) {if 

[GitHub] [arrow] lwhite1 opened a new issue, #14825: [Java] [Doc] Improve documentation for streaming file handling in VectorSchemaRoot

2022-12-02 Thread GitBox


lwhite1 opened a new issue, #14825:
URL: https://github.com/apache/arrow/issues/14825

   ### Describe the enhancement requested
   
   See comments in issue #14812
   
   ### Component(s)
   
   Documentation, Java


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@arrow.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [arrow] assignUser opened a new issue, #14824: [CI] r-binary-packages should only upload artifacts if all tests succeed

2022-12-02 Thread GitBox


assignUser opened a new issue, #14824:
URL: https://github.com/apache/arrow/issues/14824

   ### Describe the enhancement requested
   
   Currently the upload step is missing a dependency on the centos binary test.
   
   ### Component(s)
   
   Continuous Integration


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@arrow.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [arrow] AlenkaF opened a new issue, #14822: [Docs] Update the documentation to include the new GitHub issue workflow

2022-12-02 Thread GitBox


AlenkaF opened a new issue, #14822:
URL: https://github.com/apache/arrow/issues/14822

   ### Describe the enhancement requested
   
   As we are moving towards GitHub issues for Arrow issue reports, the 
documentation needs to be updated so that the contributors have a place to look 
if they need the information about the workflow we are/will be having.
   
   The issue will be divided into multiple subtasks (parts of the 
documentation) so that the review process will be easier:
   
   - [ ] https://github.com/apache/arrow README
   - [ ] https://github.com/apache/arrow/tree/master/r README
   - [ ] https://arrow.apache.org/community/ 
   - [ ] 
https://arrow.apache.org/docs/dev/developers/guide/step_by_step/finding_issues.html
   - [ ] https://arrow.apache.org/docs/dev/developers/guide/communication.html
   - [ ] 
https://arrow.apache.org/docs/dev/developers/bug_reports.html#bug-reports 
   - [ ] Version specific project docs warnings https://arrow.apache.org/docs/
 Tracked here: https://issues.apache.org/jira/browse/ARROW-18363
 https://github.com/apache/arrow-site/pull/275
 https://github.com/apache/arrow/pull/14687
   
   ### Component(s)
   
   Documentation


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@arrow.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org