[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=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=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 <--> Arrow
>
[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=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
[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=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=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=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)
