You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@arrow.apache.org by "Francois Saint-Jacques (Jira)" <ji...@apache.org> on 2020/02/13 19:22:00 UTC

[jira] [Commented] (ARROW-7844) [R] array_to_vector is not thread safe

    [ https://issues.apache.org/jira/browse/ARROW-7844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17036448#comment-17036448 ] 

Francois Saint-Jacques commented on ARROW-7844:
-----------------------------------------------


{code:java}
Parquet file reading/writing: .........S..............Warning: stack imbalance in '.Call', 145 then 144
Warning: stack imbalance in '{', 141 then 140
Warning: stack imbalance in '{', 134 then 133
1..

══ Skipped ═════════════════════════════════════════════════════════════════════
1. write_parquet() handles various compression_level= specs (@test-parquet.R#66) - Reason: Arrow C++ not built with support for gzip

══ Failed ══════════════════════════════════════════════════════════════════════
── 1. Failure: Lists are preserved when writing/reading from Parquet (@test-parq
`object` not equivalent to `expected`.
Component “int”: Component 3: Numeric: lengths (4, 2) differ
{code}


> [R] array_to_vector is not thread safe
> --------------------------------------
>
>                 Key: ARROW-7844
>                 URL: https://issues.apache.org/jira/browse/ARROW-7844
>             Project: Apache Arrow
>          Issue Type: Bug
>          Components: R
>            Reporter: Neal Richardson
>            Assignee: Francois Saint-Jacques
>            Priority: Major
>
> See [https://travis-ci.org/ursa-labs/arrow-r-nightly/jobs/649649349#L373-L375] for an example on public CI. I was seeing this locally this week but figured I'd screwed up my env somehow.
> {code}
> ── 1. Failure: Lists are preserved when writing/reading from Parquet (@test-parq
>   `object` not equivalent to `expected`.
>   Component "num": Component 1: target is numeric, current is character
> {code}
> It's not always the same column in the data.frame that is affected. Also strange that it's only one column. You'd think that if it were transposing the order somehow, you'd get two that were swapped.
> The test itself is straightforward (https://github.com/apache/arrow/blob/master/r/tests/testthat/test-parquet.R#L124-L137) so this is somewhat troubling.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)