[jira] [Commented] (ARROW-7288) [R] read_parquet() freezes on Windows
[ https://issues.apache.org/jira/browse/ARROW-7288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17016839#comment-17016839 ] Hiroaki Yutani commented on ARROW-7288: --- This seems a locale-dependent problem. In my locale, {code:r} Sys.setlocale("LC_ALL", 'Japanese') {code} the problem is reproducible. But, if I change the locale to {code:r} Sys.setlocale("LC_ALL", 'English') {code} it works fine. > [R] read_parquet() freezes on Windows > - > > Key: ARROW-7288 > URL: https://issues.apache.org/jira/browse/ARROW-7288 > Project: Apache Arrow > Issue Type: Bug > Components: R >Affects Versions: 0.15.1 > Environment: R 3.6.1 on Windows 10 >Reporter: Hiroaki Yutani >Priority: Major > > The following example on read_parquet()'s doc freezes (seems to wait for the > result forever) on my Windows. > df <- read_parquet(system.file("v0.7.1.parquet", package="arrow")) > The CRAN checks are all fine, which means the example is successfully > executed on the CRAN Windows. So, I have no idea why it doesn't work on my > local. > [https://cran.r-project.org/web/checks/check_results_arrow.html] > Here's my session info in case it helps: > {code:java} > > sessioninfo::session_info() > - Session info > - > setting value > version R version 3.6.1 (2019-07-05) > os Windows 10 x64 > system x86_64, mingw32 > ui RStudio > language en > collate Japanese_Japan.932 > ctypeJapanese_Japan.932 > tz Asia/Tokyo > date 2019-12-01 > - Packages > - > package * version date lib source > arrow * 0.15.1.1 2019-11-05 [1] CRAN (R 3.6.1) > assertthat0.2.12019-03-21 [1] CRAN (R 3.6.0) > bit 1.1-14 2018-05-29 [1] CRAN (R 3.6.0) > bit64 0.9-72017-05-08 [1] CRAN (R 3.6.0) > cli 1.1.02019-03-19 [1] CRAN (R 3.6.0) > crayon1.3.42017-09-16 [1] CRAN (R 3.6.0) > fs1.3.12019-05-06 [1] CRAN (R 3.6.0) > glue 1.3.12019-03-12 [1] CRAN (R 3.6.0) > magrittr 1.5 2014-11-22 [1] CRAN (R 3.6.0) > purrr 0.3.32019-10-18 [1] CRAN (R 3.6.1) > R62.4.12019-11-12 [1] CRAN (R 3.6.1) > Rcpp 1.0.32019-11-08 [1] CRAN (R 3.6.1) > reprex0.3.02019-05-16 [1] CRAN (R 3.6.0) > rlang 0.4.22019-11-23 [1] CRAN (R 3.6.1) > rstudioapi0.10 2019-03-19 [1] CRAN (R 3.6.0) > sessioninfo 1.1.12018-11-05 [1] CRAN (R 3.6.0) > tidyselect0.2.52018-10-11 [1] CRAN (R 3.6.0) > withr 2.1.22018-03-15 [1] CRAN (R 3.6.0) > [1] C:/Users/hiroaki-yutani/Documents/R/win-library/3.6 > [2] C:/Program Files/R/R-3.6.1/library > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (ARROW-7045) [R] Factor type not preserved in Parquet roundtrip
[ https://issues.apache.org/jira/browse/ARROW-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17008799#comment-17008799 ] Hiroaki Yutani edited comment on ARROW-7045 at 1/6/20 12:29 PM: I think I found the cause. This is because {{ParquetArrowWriterProperties$store_schema()}} is not called by default, the first {{if}} branch in {{ParquetArrowWriterProperties$create}} below: {code:r} if (!use_deprecated_int96_timestamps && is.null(coerce_timestamps) && !allow_truncated_timestamps) { shared_ptr(ParquetArrowWriterProperties, parquet___default_arrow_writer_properties()) } else { builder <- shared_ptr(ParquetArrowWriterPropertiesBuilder, parquet___ArrowWriterProperties___Builder__create()) builder$store_schema() builder$set_int96_support(use_deprecated_int96_timestamps) builder$set_coerce_timestamps(coerce_timestamps) builder$set_allow_truncated_timestamps(allow_truncated_timestamps) shared_ptr(ParquetArrowWriterProperties, parquet___ArrowWriterProperties___Builder__build(builder)) } {code} (https://github.com/apache/arrow/blob/dd6b17d0cc1a77aaff84c5a4472ac73bc79486af/r/R/parquet.R#L208-L217) Actually, specifying either of the arguments works. For example: {code:r} test_that("Factors are preserved when writing/reading from Parquet", { tf <- tempfile() on.exit(unlink(tf)) df <- data.frame(a = factor(c("a", "b"))) write_parquet(df, tf, allow_truncated_timestamps = TRUE) expect_equivalent(read_parquet(tf), df) }) {code} According to https://github.com/apache/arrow/pull/5077 : bq. Add ArrowWriterProperties::store_schema() option which stores the Arrow schema used to create a Parquet file in a special ARROW:schema key in the metadata, so that we can detect that a column was originally DictionaryArray. This option is off by default, but enabled in the Python bindings. We can always make it the default in the future I think the R bindings can follow the Python and always use {{ParquetArrowWriterPropertiesBuilder}} instead of {{default_arrow_writer_properties()}}. If this sounds good, I'm happy to send a PR for this. was (Author: yutannihilation): I think I found the cause. This is because {{ParquetArrowWriterProperties$store_schema()}} is not called by default, the first {{if}} branch in {{ParquetArrowWriterProperties$create}} below: {code:java} if (!use_deprecated_int96_timestamps && is.null(coerce_timestamps) && !allow_truncated_timestamps) { shared_ptr(ParquetArrowWriterProperties, parquet___default_arrow_writer_properties()) } else { builder <- shared_ptr(ParquetArrowWriterPropertiesBuilder, parquet___ArrowWriterProperties___Builder__create()) builder$store_schema() builder$set_int96_support(use_deprecated_int96_timestamps) builder$set_coerce_timestamps(coerce_timestamps) builder$set_allow_truncated_timestamps(allow_truncated_timestamps) shared_ptr(ParquetArrowWriterProperties, parquet___ArrowWriterProperties___Builder__build(builder)) } {code} (https://github.com/apache/arrow/blob/dd6b17d0cc1a77aaff84c5a4472ac73bc79486af/r/R/parquet.R#L208-L217) Actually, specifying either of the arguments works. For example: {code:java} test_that("Factors are preserved when writing/reading from Parquet", { tf <- tempfile() on.exit(unlink(tf)) df <- data.frame(a = factor(c("a", "b"))) write_parquet(df, tf, allow_truncated_timestamps = TRUE) expect_equivalent(read_parquet(tf), df) }) {code} According to https://github.com/apache/arrow/pull/5077 : bq. Add ArrowWriterProperties::store_schema() option which stores the Arrow schema used to create a Parquet file in a special ARROW:schema key in the metadata, so that we can detect that a column was originally DictionaryArray. This option is off by default, but enabled in the Python bindings. We can always make it the default in the future I think the R bindings can follow the Python and always use {{ParquetArrowWriterPropertiesBuilder}} instead of {{default_arrow_writer_properties()}}. If this sounds good, I'm happy to send a PR for this. > [R] Factor type not preserved in Parquet roundtrip > -- > > Key: ARROW-7045 > URL: https://issues.apache.org/jira/browse/ARROW-7045 > Project: Apache Arrow > Issue Type: Bug > Components: R >Reporter: Neal Richardson >Priority: Major > > {code:r} > test_that("Factors are preserved when writing/reading from Parquet", { > tf <- tempfile() > on.exit(unlink(tf)) > df <- data.frame(a = factor(c("a", "b"))) > write_parquet(df, tf) > expect_equivalent(read_parquet(tf), df) > }) > {code} > Fails: > {code} > `object` not equivalent to `expected`. > Component “a”: target is character, current is factor > {code} > This has to do with the translation with Parquet and not the R
[jira] [Commented] (ARROW-7045) [R] Factor type not preserved in Parquet roundtrip
[ https://issues.apache.org/jira/browse/ARROW-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17008799#comment-17008799 ] Hiroaki Yutani commented on ARROW-7045: --- I think I found the cause. This is because {{ParquetArrowWriterProperties$store_schema()}} is not called by default, the first {{if}} branch in {{ParquetArrowWriterProperties$create}} below: {code:java} if (!use_deprecated_int96_timestamps && is.null(coerce_timestamps) && !allow_truncated_timestamps) { shared_ptr(ParquetArrowWriterProperties, parquet___default_arrow_writer_properties()) } else { builder <- shared_ptr(ParquetArrowWriterPropertiesBuilder, parquet___ArrowWriterProperties___Builder__create()) builder$store_schema() builder$set_int96_support(use_deprecated_int96_timestamps) builder$set_coerce_timestamps(coerce_timestamps) builder$set_allow_truncated_timestamps(allow_truncated_timestamps) shared_ptr(ParquetArrowWriterProperties, parquet___ArrowWriterProperties___Builder__build(builder)) } {code} (https://github.com/apache/arrow/blob/dd6b17d0cc1a77aaff84c5a4472ac73bc79486af/r/R/parquet.R#L208-L217) Actually, specifying either of the arguments works. For example: {code:java} test_that("Factors are preserved when writing/reading from Parquet", { tf <- tempfile() on.exit(unlink(tf)) df <- data.frame(a = factor(c("a", "b"))) write_parquet(df, tf, allow_truncated_timestamps = TRUE) expect_equivalent(read_parquet(tf), df) }) {code} According to https://github.com/apache/arrow/pull/5077 : bq. Add ArrowWriterProperties::store_schema() option which stores the Arrow schema used to create a Parquet file in a special ARROW:schema key in the metadata, so that we can detect that a column was originally DictionaryArray. This option is off by default, but enabled in the Python bindings. We can always make it the default in the future I think the R bindings can follow the Python and always use {{ParquetArrowWriterPropertiesBuilder}} instead of {{default_arrow_writer_properties()}}. If this sounds good, I'm happy to send a PR for this. > [R] Factor type not preserved in Parquet roundtrip > -- > > Key: ARROW-7045 > URL: https://issues.apache.org/jira/browse/ARROW-7045 > Project: Apache Arrow > Issue Type: Bug > Components: R >Reporter: Neal Richardson >Priority: Major > > {code:r} > test_that("Factors are preserved when writing/reading from Parquet", { > tf <- tempfile() > on.exit(unlink(tf)) > df <- data.frame(a = factor(c("a", "b"))) > write_parquet(df, tf) > expect_equivalent(read_parquet(tf), df) > }) > {code} > Fails: > {code} > `object` not equivalent to `expected`. > Component “a”: target is character, current is factor > {code} > This has to do with the translation with Parquet and not the R <--> Arrow > type mapping (unlike ARROW-7028). If you write_feather and read_feather, the > test passes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARROW-7288) [R] read_parquet() freezes on Windows
[ https://issues.apache.org/jira/browse/ARROW-7288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiroaki Yutani updated ARROW-7288: -- Description: The following example on read_parquet()'s doc freezes (seems to wait for the result forever) on my Windows. df <- read_parquet(system.file("v0.7.1.parquet", package="arrow")) The CRAN checks are all fine, which means the example is successfully executed on the CRAN Windows. So, I have no idea why it doesn't work on my local. [https://cran.r-project.org/web/checks/check_results_arrow.html] Here's my session info in case it helps: {code:java} > sessioninfo::session_info() - Session info - setting value version R version 3.6.1 (2019-07-05) os Windows 10 x64 system x86_64, mingw32 ui RStudio language en collate Japanese_Japan.932 ctypeJapanese_Japan.932 tz Asia/Tokyo date 2019-12-01 - Packages - package * version date lib source arrow * 0.15.1.1 2019-11-05 [1] CRAN (R 3.6.1) assertthat0.2.12019-03-21 [1] CRAN (R 3.6.0) bit 1.1-14 2018-05-29 [1] CRAN (R 3.6.0) bit64 0.9-72017-05-08 [1] CRAN (R 3.6.0) cli 1.1.02019-03-19 [1] CRAN (R 3.6.0) crayon1.3.42017-09-16 [1] CRAN (R 3.6.0) fs1.3.12019-05-06 [1] CRAN (R 3.6.0) glue 1.3.12019-03-12 [1] CRAN (R 3.6.0) magrittr 1.5 2014-11-22 [1] CRAN (R 3.6.0) purrr 0.3.32019-10-18 [1] CRAN (R 3.6.1) R62.4.12019-11-12 [1] CRAN (R 3.6.1) Rcpp 1.0.32019-11-08 [1] CRAN (R 3.6.1) reprex0.3.02019-05-16 [1] CRAN (R 3.6.0) rlang 0.4.22019-11-23 [1] CRAN (R 3.6.1) rstudioapi0.10 2019-03-19 [1] CRAN (R 3.6.0) sessioninfo 1.1.12018-11-05 [1] CRAN (R 3.6.0) tidyselect0.2.52018-10-11 [1] CRAN (R 3.6.0) withr 2.1.22018-03-15 [1] CRAN (R 3.6.0) [1] C:/Users/hiroaki-yutani/Documents/R/win-library/3.6 [2] C:/Program Files/R/R-3.6.1/library {code} was: The following example on read_parquet()'s doc freezes (seems to wait for the result foever) on my Windows. df <- read_parquet(system.file("v0.7.1.parquet", package="arrow")) The CRAN checks are all fine, which means the example is successfully executed on the CRAN Windows. So, I have no idea why it doesn't work on my local. https://cran.r-project.org/web/checks/check_results_arrow.html Here's my session info in case it helps: {code} > sessioninfo::session_info() - Session info - setting value version R version 3.6.1 (2019-07-05) os Windows 10 x64 system x86_64, mingw32 ui RStudio language en collate Japanese_Japan.932 ctypeJapanese_Japan.932 tz Asia/Tokyo date 2019-12-01 - Packages - package * version date lib source arrow * 0.15.1.1 2019-11-05 [1] CRAN (R 3.6.1) assertthat0.2.12019-03-21 [1] CRAN (R 3.6.0) bit 1.1-14 2018-05-29 [1] CRAN (R 3.6.0) bit64 0.9-72017-05-08 [1] CRAN (R 3.6.0) cli 1.1.02019-03-19 [1] CRAN (R 3.6.0) crayon1.3.42017-09-16 [1] CRAN (R 3.6.0) fs1.3.12019-05-06 [1] CRAN (R 3.6.0) glue 1.3.12019-03-12 [1] CRAN (R 3.6.0) magrittr 1.5 2014-11-22 [1] CRAN (R 3.6.0) purrr 0.3.32019-10-18 [1] CRAN (R 3.6.1) R62.4.12019-11-12 [1] CRAN (R 3.6.1) Rcpp 1.0.32019-11-08 [1] CRAN (R 3.6.1) reprex0.3.02019-05-16 [1] CRAN (R 3.6.0) rlang 0.4.22019-11-23 [1] CRAN (R 3.6.1) rstudioapi0.10 2019-03-19 [1] CRAN (R 3.6.0) sessioninfo 1.1.12018-11-05 [1] CRAN (R 3.6.0) tidyselect0.2.52018-10-11 [1] CRAN (R 3.6.0) withr 2.1.22018-03-15 [1] CRAN (R 3.6.0) [1] C:/Users/hiroaki-yutani/Documents/R/win-library/3.6 [2] C:/Program Files/R/R-3.6.1/library {code} > [R] read_parquet() freezes on Windows > - > > Key: ARROW-7288 > URL: https://issues.apache.org/jira/browse/ARROW-7288 > Project: Apache Arrow > Issue Type: Bug > Components: R >Affects Versions: 0.15.1 > Environment: R 3.6.1 on Windows 10 >Reporter: Hiroaki Yutani >Priority: Major > > The following example on read_parquet()'s doc freezes (seems to wait for the > result forever) on my Windows. > df <- read_parquet(system.file("v0.7.1.parquet", package="arrow")) > The CRAN checks are all fine, which means the example is successfully > executed on the CRAN Wi
[jira] [Created] (ARROW-7288) [R] read_parquet() freezes on Windows
Hiroaki Yutani created ARROW-7288: - Summary: [R] read_parquet() freezes on Windows Key: ARROW-7288 URL: https://issues.apache.org/jira/browse/ARROW-7288 Project: Apache Arrow Issue Type: Bug Components: R Affects Versions: 0.15.1 Environment: R 3.6.1 on Windows 10 Reporter: Hiroaki Yutani The following example on read_parquet()'s doc freezes (seems to wait for the result foever) on my Windows. df <- read_parquet(system.file("v0.7.1.parquet", package="arrow")) The CRAN checks are all fine, which means the example is successfully executed on the CRAN Windows. So, I have no idea why it doesn't work on my local. https://cran.r-project.org/web/checks/check_results_arrow.html Here's my session info in case it helps: {code} > sessioninfo::session_info() - Session info - setting value version R version 3.6.1 (2019-07-05) os Windows 10 x64 system x86_64, mingw32 ui RStudio language en collate Japanese_Japan.932 ctypeJapanese_Japan.932 tz Asia/Tokyo date 2019-12-01 - Packages - package * version date lib source arrow * 0.15.1.1 2019-11-05 [1] CRAN (R 3.6.1) assertthat0.2.12019-03-21 [1] CRAN (R 3.6.0) bit 1.1-14 2018-05-29 [1] CRAN (R 3.6.0) bit64 0.9-72017-05-08 [1] CRAN (R 3.6.0) cli 1.1.02019-03-19 [1] CRAN (R 3.6.0) crayon1.3.42017-09-16 [1] CRAN (R 3.6.0) fs1.3.12019-05-06 [1] CRAN (R 3.6.0) glue 1.3.12019-03-12 [1] CRAN (R 3.6.0) magrittr 1.5 2014-11-22 [1] CRAN (R 3.6.0) purrr 0.3.32019-10-18 [1] CRAN (R 3.6.1) R62.4.12019-11-12 [1] CRAN (R 3.6.1) Rcpp 1.0.32019-11-08 [1] CRAN (R 3.6.1) reprex0.3.02019-05-16 [1] CRAN (R 3.6.0) rlang 0.4.22019-11-23 [1] CRAN (R 3.6.1) rstudioapi0.10 2019-03-19 [1] CRAN (R 3.6.0) sessioninfo 1.1.12018-11-05 [1] CRAN (R 3.6.0) tidyselect0.2.52018-10-11 [1] CRAN (R 3.6.0) withr 2.1.22018-03-15 [1] CRAN (R 3.6.0) [1] C:/Users/hiroaki-yutani/Documents/R/win-library/3.6 [2] C:/Program Files/R/R-3.6.1/library {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (ARROW-4113) [R] Version number patch broke build
[ https://issues.apache.org/jira/browse/ARROW-4113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16728608#comment-16728608 ] Hiroaki Yutani edited comment on ARROW-4113 at 12/26/18 2:15 AM: - {quote}Is "0.12.0-0" smaller than "0.12.0"? {quote} No (I didn't know this until now...). {code:java} package_version("0.12.0-0") == package_version("0.12.0") #> [1] TRUE{code} One common practice is to add .9000 to the tail of the current released version to represent "development version." So, in this case, the version would be 0.11.0.9000. c.f. [http://r-pkgs.had.co.nz/description.html#version] I guess you want to include "0.12.0" in the version string to indicate it's the development version of "0.12.0." But, as far as I know, R has no nice way to do that. Some possible choices are here: # use "0.11.0.9000" for development, and "0.12.0" for release # use "0.12.0" both for development and release (c.f. Apache Spark's SparkR uses this strategy: [https://github.com/apache/spark/commit/9bf397c0e45cb161f3f12f09bd2bf14ff96dc823#diff-06e745873945c43e0e5cf512efa992e9R3]) # use "0.12.0-0" for development, and "0.12.0-1" for release (c.f [rstan|https://cran.r-project.org/src/contrib/Archive/rstan/]'s patch version is 1-origin) was (Author: yutannihilation): {quote}Is "0.12.0-0" smaller than "0.12.0"? {quote} No (I didn't know this until now...). {code} package_version("0.12.0-0") == package_version("0.12.0") #> [1] TRUE{code} One common practice is to add .9000 to the tail of the current released version to represent "development version." So, in this case, the version would be 0.11.0.9000. c.f. [http://r-pkgs.had.co.nz/description.html#version] I guess you want to include "0.12.0" in the version string to indicate it's the development version of "0.12.0." But, as far as I know, R has no nice way to do that. Some possible choices are here: # use "0.11.0.9000" for development, and "0.12.0" for release # use "0.12.0" both for development and release # use "0.12.0-0" for development, and "0.12.0-1" for release (c.f [rstan|https://cran.r-project.org/src/contrib/Archive/rstan/]'s patch version is 1-origin) > [R] Version number patch broke build > > > Key: ARROW-4113 > URL: https://issues.apache.org/jira/browse/ARROW-4113 > Project: Apache Arrow > Issue Type: Bug > Components: R >Reporter: Wes McKinney >Priority: Major > Fix For: 0.12.0 > > > The patch > https://github.com/apache/arrow/commit/385c4384eb0dcc384b443f24765c64e9d6d88d28 > broke the R build (which is in allowed_failures right now) > {code} > Building with: R CMD build > 0.22s$ R CMD build . > * checking for file ‘./DESCRIPTION’ ... OK > * preparing ‘arrow’: > * checking DESCRIPTION meta-information ... ERROR > Malformed package version. > See section 'The DESCRIPTION file' in the 'Writing R Extensions' > manual. > The command "R CMD build ." failed and exited with 1 during . > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARROW-4113) [R] Version number patch broke build
[ https://issues.apache.org/jira/browse/ARROW-4113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16728843#comment-16728843 ] Hiroaki Yutani commented on ARROW-4113: --- Thanks, I too feel option 1. is best among them since many R developers are familiar with that manner. > [R] Version number patch broke build > > > Key: ARROW-4113 > URL: https://issues.apache.org/jira/browse/ARROW-4113 > Project: Apache Arrow > Issue Type: Bug > Components: R >Reporter: Wes McKinney >Priority: Major > Fix For: 0.12.0 > > > The patch > https://github.com/apache/arrow/commit/385c4384eb0dcc384b443f24765c64e9d6d88d28 > broke the R build (which is in allowed_failures right now) > {code} > Building with: R CMD build > 0.22s$ R CMD build . > * checking for file ‘./DESCRIPTION’ ... OK > * preparing ‘arrow’: > * checking DESCRIPTION meta-information ... ERROR > Malformed package version. > See section 'The DESCRIPTION file' in the 'Writing R Extensions' > manual. > The command "R CMD build ." failed and exited with 1 during . > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARROW-4113) [R] Version number patch broke build
[ https://issues.apache.org/jira/browse/ARROW-4113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16728608#comment-16728608 ] Hiroaki Yutani commented on ARROW-4113: --- {quote}Is "0.12.0-0" smaller than "0.12.0"? {quote} No (I didn't know this until now...). {code} package_version("0.12.0-0") == package_version("0.12.0") #> [1] TRUE{code} One common practice is to add .9000 to the tail of the current released version to represent "development version." So, in this case, the version would be 0.11.0.9000. c.f. [http://r-pkgs.had.co.nz/description.html#version] I guess you want to include "0.12.0" in the version string to indicate it's the development version of "0.12.0." But, as far as I know, R has no nice way to do that. Some possible choices are here: # use "0.11.0.9000" for development, and "0.12.0" for release # use "0.12.0" both for development and release # use "0.12.0-0" for development, and "0.12.0-1" for release (c.f [rstan|https://cran.r-project.org/src/contrib/Archive/rstan/]'s patch version is 1-origin) > [R] Version number patch broke build > > > Key: ARROW-4113 > URL: https://issues.apache.org/jira/browse/ARROW-4113 > Project: Apache Arrow > Issue Type: Bug > Components: R >Reporter: Wes McKinney >Priority: Major > Fix For: 0.12.0 > > > The patch > https://github.com/apache/arrow/commit/385c4384eb0dcc384b443f24765c64e9d6d88d28 > broke the R build (which is in allowed_failures right now) > {code} > Building with: R CMD build > 0.22s$ R CMD build . > * checking for file ‘./DESCRIPTION’ ... OK > * preparing ‘arrow’: > * checking DESCRIPTION meta-information ... ERROR > Malformed package version. > See section 'The DESCRIPTION file' in the 'Writing R Extensions' > manual. > The command "R CMD build ." failed and exited with 1 during . > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)