[jira] [Created] (ARROW-4155) [Rust] Implement array_ops::sum() for PrimitiveArray

[Andy Grove (JIRA)]

Andy Grove created ARROW-4155:
-

 Summary: [Rust] Implement array_ops::sum() for PrimitiveArray
 Key: ARROW-4155
 URL: https://issues.apache.org/jira/browse/ARROW-4155
 Project: Apache Arrow
  Issue Type: Improvement
  Components: Rust
Reporter: Andy Grove
Assignee: Andy Grove
 Fix For: 0.12.0


In array_ops we should implement sum() that will return Option for a 
PrimitiveArray



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Format specification document?

[Kohei KaiGai]

Hello,

I'm now trying to understand the Apache Arrow format for my application.
Is there a format specification document including meta-data layout?

I checked out the description at:
https://github.com/apache/arrow/tree/master/docs/source/format
https://github.com/apache/arrow/tree/master/format

The format/IPC.rst says an arrow file has the format below:








Then, STREAMING FORMAT begins from SCHEMA-message.
The message chunk has the format below:






I made an arrow file using pyarrow [*1]. It has the following binary.

[kaigai@saba ~]$ cat /tmp/sample.arrow | od -Ax -t x1 | head -16
00  41 52 52 4f 57 31 00 00 8c 05 00 00 10 00 00 00
10  00 00 0a 00 0e 00 06 00 05 00 08 00 0a 00 00 00
20  00 01 03 00 10 00 00 00 00 00 0a 00 0c 00 00 00
30  04 00 08 00 0a 00 00 00 ec 03 00 00 04 00 00 00
40  01 00 00 00 0c 00 00 00 08 00 0c 00 04 00 08 00
50  08 00 00 00 08 00 00 00 10 00 00 00 06 00 00 00
60  70 61 6e 64 61 73 00 00 b4 03 00 00 7b 22 70 61
70  6e 64 61 73 5f 76 65 72 73 69 6f 6e 22 3a 20 22
80  30 2e 32 32 2e 30 22 2c 20 22 63 6f 6c 75 6d 6e
90  73 22 3a 20 5b 7b 22 6d 65 74 61 64 61 74 61 22
a0  3a 20 6e 75 6c 6c 2c 20 22 6e 75 6d 70 79 5f 74
b0  79 70 65 22 3a 20 22 69 6e 74 36 34 22 2c 20 22
c0  6e 61 6d 65 22 3a 20 22 69 64 22 2c 20 22 66 69
d0  65 6c 64 5f 6e 61 6d 65 22 3a 20 22 69 64 22 2c
e0  20 22 70 61 6e 64 61 73 5f 74 79 70 65 22 3a 20
f0  22 69 6e 74 36 34 22 7d 2c 20 7b 22 6d 65 74 61

The first 64bit is "ARROW1\0\0\0", and the next 32bit is 0x058c (=1420)
that is reasonable for SCHEMA-message length.
The next 32bit is 0x0010 (=16). It may be metadata_size of the FlatBuffer.
The IPC.rst does not mention about FlatBuffer metadata, so I tried to skip
next 16bytes, expecting message body begins at 0x20.
However, the first 16bit (version) is 0x0001 (=V2), the next byte is 0x03
(= RecordBatch, not Schema!), and the following 64bit is 0x0a0010(!).
It is obviously I'm understanding incorrectly.

Is there documentation stuff to introduce detailed layout of the arrow format?

Thanks,

[*1] Steps to make a sample arrow file
$ python3.5
>>> import pyarrow as pa
>>> import pandas as pd
>>> X = pd.read_sql(sql="SELECT * FROM hogehoge LIMIT 1000", 
>>> con="postgresql://localhost/postgres")
>>> Y = pa.Table.from_pandas(X)
>>> f = pa.RecordBatchFileWriter('/tmp/sample.arrow', Y.schema)
>>> f.write_table(Y)
>>> f.close()

-- 
HeteroDB, Inc / The PG-Strom Project
KaiGai Kohei 

[jira] [Created] (ARROW-4154) [GLib] Add GArrowDecimal128DataType

[Kouhei Sutou (JIRA)]

Kouhei Sutou created ARROW-4154:
---

 Summary: [GLib] Add GArrowDecimal128DataType
 Key: ARROW-4154
 URL: https://issues.apache.org/jira/browse/ARROW-4154
 Project: Apache Arrow
  Issue Type: New Feature
  Components: GLib
Reporter: Kouhei Sutou
Assignee: Kouhei Sutou






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [Rust] crate versions and release process

[Andy Grove]

+1 from me. Keeping the code in a single repo makes sense but no need to
artificially keep versions numbers consistent between the sub-crates.

Andy.

On Wed, Jan 2, 2019 at 10:28 PM Chao Sun  wrote:

> Hi,
>
> This is related to an earlier email I sent regarding separating the Rust
> implementation into sub crates. See some early discussions in this PR
> [1].  As we could have multiple crates for the project in future (e.g.,
> arrow, parquet, orc, gandiva), I'm wondering whether we can keep different
> versions for these crates. For instance, the parquet crate use to have
> version 0.4.2 before merging into arrow, and I think it's better to
> maintain the continuity there.
>
> Another thing is about release cycles. I understand that it is best to keep
> the release cycles for these crates the same as arrow's. However, it's
> possible in future that we may need a minor release for a critical bug fix
> of a particular crate, and to follow the overall release process for that
> seems like an overkill and not quite feasible.
>
> Therefore, I'm proposing to:
> 1. allow different versions for sub-crates.
> 2. follow the overall release schedule, but maintain the flexibility of
> doing separate releases when necessary.
>
> Thought?
>
> Chao
>
> [1]: https://github.com/apache/arrow/pull/3291#issuecomment-450950275
>

[jira] [Created] (ARROW-4153) [GLib] Add builder_append_value() for consistency

[Kouhei Sutou (JIRA)]

Kouhei Sutou created ARROW-4153:
---

 Summary: [GLib] Add builder_append_value() for consistency
 Key: ARROW-4153
 URL: https://issues.apache.org/jira/browse/ARROW-4153
 Project: Apache Arrow
  Issue Type: New Feature
  Components: GLib
Reporter: Kouhei Sutou
Assignee: Kouhei Sutou


Because we use builder_append_values() for multiple values.

builder_append() is deprecated.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARROW-4152) [GLib] Remove an example to show Torch integration

[Kouhei Sutou (JIRA)]

Kouhei Sutou created ARROW-4152:
---

 Summary: [GLib] Remove an example to show Torch integration
 Key: ARROW-4152
 URL: https://issues.apache.org/jira/browse/ARROW-4152
 Project: Apache Arrow
  Issue Type: Improvement
  Components: GLib
Reporter: Kouhei Sutou
Assignee: Kouhei Sutou


Because Torch is not in active development.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Move arrow-site.git to gitbox

[Krisztián Szűcs]

+1

On Thu, Jan 3, 2019 at 4:34 PM Wes McKinney  wrote:

> +1
>
> On Thu, Jan 3, 2019, 9:22 AM Uwe L. Korn 
> > Hello,
> >
> > as requested per the mail from ASF infra, I would like to move the
> > arrow-site git repo to gitbox. This is the repo used for the distribution
> > of the rendered version of the website. Some +1s or a point why we should
> > consider alternatives would help to bring this forward. If there is
> > consensus in the next day(s), I'll create an INFRA ticket.
> >
> > Uwe
> >
>

[jira] [Created] (ARROW-4151) [Rust] Restructure project directories

[Chao Sun (JIRA)]

Chao Sun created ARROW-4151:
---

 Summary: [Rust] Restructure project directories 
 Key: ARROW-4151
 URL: https://issues.apache.org/jira/browse/ARROW-4151
 Project: Apache Arrow
  Issue Type: Task
  Components: Rust
Reporter: Chao Sun
Assignee: Chao Sun


As discussed in here 
https://github.com/apache/arrow/pull/3291#issuecomment-450980172, we should 
have separate directories for {{arrow}}, {{parquet}}, etc, similar to the C++ 
project.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Enabling an installation path for Arrow R users

[Wes McKinney]

To have non-trivial R use, we have to get install.package working, which I
think means integration with CRAN. There are a lot of logistical issues
around build and packaging on each platform. It would be great to have a
written summary of the best practices for each platform for getting
bindings plus non-trivial C++ libraries installed on each platform.

Additionally, it would be great to have source build instructions for each
platform to help grow the developer community.

On Thu, Jan 3, 2019, 10:02 AM Uwe L. Korn  We probably need to support both, conda-forge and CRAN. As a first shot,
> conda-forge will be much easier to setup as we should have a better build
> toolchain available there and this could also then be used in the
> multilanguage scenario demos really well. From my experience, the usage of
> conda in the R world seems to be very small, so to get a user base, we will
> need to invest in CRAN.
>
> TL;DR: We should start with conda-forge.
>
> Uwe
>
> On Thu, Jan 3, 2019, at 10:02 AM, Jonathan Chiang wrote:
> >
> > Hi,
> >
> > Long term, I believe getting an arrow package onto cran would be most
> > useful for R users. Building arrow in R on Mac was easier than Linux for
> > me. I was still having trouble installing after spending a couple hours
> > or so.
> >
> > Typically if you can install.package from cran is most convenient.
> > Devtools installation from a github repository if it works across
> > different OSes would suffice.
> >
> > Most growing R users are typically using RStudio, so conda may be
> > inconvenient for R users, because it requires installing IR kernel  for
> > anaconda.
> >
> > Whatever installation method or strategy you used for feather was easy
> > for me to install as a R user.
> >
> > Thanks,
> > Jonathan
> >
> > > On Jan 2, 2019, at 11:59 PM, Krisztián Szűcs <
> szucs.kriszt...@gmail.com> wrote:
> > >
> > > Perhaps an R conda-forge feedstock?
> > > I'm not sure how widely conda-forge is used in the R commmunity,
> > > but it already hosts around a thousand packages[1].
> > >
> > > [1] https://github.com/conda-forge?=r-
> > >
> > >> On Wed, Jan 2, 2019 at 6:09 PM Wes McKinney 
> wrote:
> > >>
> > >> hi folks,
> > >>
> > >> With 0.12 around the corner and significant progress on the R bindings
> > >> project (sufficient for Spark integration [1]), I am wondering how
> > >> everyday R users are going to be able to install the software
> > >> respectively on Linux, macOS, and Windows. Thoughts about the strategy
> > >> for this?
> > >>
> > >> Thanks
> > >> Wes
> > >>
> > >> [1]: https://github.com/apache/arrow/pull/3001
> > >>
>

Please Remove me From List

[Zack Reder]

Thanks!

Re: Enabling an installation path for Arrow R users

[Uwe L. Korn]

We probably need to support both, conda-forge and CRAN. As a first shot, 
conda-forge will be much easier to setup as we should have a better build 
toolchain available there and this could also then be used in the multilanguage 
scenario demos really well. From my experience, the usage of conda in the R 
world seems to be very small, so to get a user base, we will need to invest in 
CRAN.

TL;DR: We should start with conda-forge.

Uwe

On Thu, Jan 3, 2019, at 10:02 AM, Jonathan Chiang wrote:
> 
> Hi, 
> 
> Long term, I believe getting an arrow package onto cran would be most 
> useful for R users. Building arrow in R on Mac was easier than Linux for 
> me. I was still having trouble installing after spending a couple hours 
> or so. 
> 
> Typically if you can install.package from cran is most convenient. 
> Devtools installation from a github repository if it works across 
> different OSes would suffice.
> 
> Most growing R users are typically using RStudio, so conda may be 
> inconvenient for R users, because it requires installing IR kernel  for 
> anaconda.   
> 
> Whatever installation method or strategy you used for feather was easy 
> for me to install as a R user. 
> 
> Thanks,
> Jonathan 
> 
> > On Jan 2, 2019, at 11:59 PM, Krisztián Szűcs  
> > wrote:
> > 
> > Perhaps an R conda-forge feedstock?
> > I'm not sure how widely conda-forge is used in the R commmunity,
> > but it already hosts around a thousand packages[1].
> > 
> > [1] https://github.com/conda-forge?=r-
> > 
> >> On Wed, Jan 2, 2019 at 6:09 PM Wes McKinney  wrote:
> >> 
> >> hi folks,
> >> 
> >> With 0.12 around the corner and significant progress on the R bindings
> >> project (sufficient for Spark integration [1]), I am wondering how
> >> everyday R users are going to be able to install the software
> >> respectively on Linux, macOS, and Windows. Thoughts about the strategy
> >> for this?
> >> 
> >> Thanks
> >> Wes
> >> 
> >> [1]: https://github.com/apache/arrow/pull/3001
> >> 

[jira] [Created] (ARROW-4150) [C++] Buffer data should never be null

[Antoine Pitrou (JIRA)]

Antoine Pitrou created ARROW-4150:
-

 Summary: [C++] Buffer data should never be null
 Key: ARROW-4150
 URL: https://issues.apache.org/jira/browse/ARROW-4150
 Project: Apache Arrow
  Issue Type: Wish
  Components: C++
Affects Versions: 0.11.1
Reporter: Antoine Pitrou


When a 0-byte buffer is allocated, or at the start of a BufferBuilder, the 
buffer's data pointer can be null. This leads to passing null arguments (with 
zero sizes) to standard functions such as memset() and memcpy() in many places. 
UBSAN doesn't like it.

Since a null pointer often means "failed allocating" or "programmer error", we 
might want to use a non-null pointer to a static empty piece of data instead.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Move arrow-site.git to gitbox

[Wes McKinney]

+1

On Thu, Jan 3, 2019, 9:22 AM Uwe L. Korn  Hello,
>
> as requested per the mail from ASF infra, I would like to move the
> arrow-site git repo to gitbox. This is the repo used for the distribution
> of the rendered version of the website. Some +1s or a point why we should
> consider alternatives would help to bring this forward. If there is
> consensus in the next day(s), I'll create an INFRA ticket.
>
> Uwe
>

Move arrow-site.git to gitbox

[Uwe L. Korn]

Hello,

as requested per the mail from ASF infra, I would like to move the arrow-site 
git repo to gitbox. This is the repo used for the distribution of the rendered 
version of the website. Some +1s or a point why we should consider alternatives 
would help to bring this forward. If there is consensus in the next day(s), 
I'll create an INFRA ticket.

Uwe

Re: Parallel processing

[Antoine Pitrou]

Hi Romain,

No, it's better if you use the CPU thread pool directly (or through
TaskGroup, if that suits your execution model better).

Regards

Antoine.


Le 03/01/2019 à 14:29, Romain Francois a écrit :
> Hello, 
> 
> Are the functions in parallel.h the de facto model for parallelisation in 
> arrow ? 
> https://github.com/apache/arrow/blob/42cf69abfc1368c9884f4581811e2e7900c98fcd/cpp/src/arrow/util/parallel.h
>  
> 
> 
> Just wondering if things like intel tbb were considered, IIRC managing 
> threads manually can be expensive and tasks are usually cheaper. 
> 
> Romain
> 

Re: Bison error when making thrift on macOS

[Romain Francois]

Thanks. I'll give that a go if/when I need to build thrift.

Romain

> Le 2 janv. 2019 à 17:07, Wes McKinney  a écrit :
> 
> You stumbled on https://issues.apache.org/jira/browse/PARQUET-1319.
> See 
> https://github.com/apache/parquet-cpp/commit/d15d2687e9f154e69e956e2a56c8d1fd6c3b7ac8
> (which is part of Arrow's ThirdpartyToolchain.cmake)
> 
> You can pass `-DBISON_EXECUTABLE=/path/to/homebrew/bison` when building
> 
> - Wes
> 
> On Wed, Jan 2, 2019 at 7:20 AM Romain Francois  wrote:
>> 
>> Turns out I already have a thrift installed through brew, but cmake needed 
>> help to figure it out, I have added
>> 
>> export THRIFT_HOME="/usr/local/Cellar/thrift/0.11.0"
>> 
>> to my ~/.bash_profile
>> 
>> 
>>> Le 2 janv. 2019 à 14:00, Romain Francois  a écrit :
>>> 
>>> This might be relevant, I'm getting:
>>> 
>>> -- THRIFT_HOME:
>>> -- Thrift compiler/libraries NOT found:  (THRIFT_INCLUDE_DIR-NOTFOUND, 
>>> THRIFT_STATIC_LIB-NOTFOUND). Looked in system search paths.
>>> -- Thrift include dir: 
>>> /Users/romain/git/apache/arrow/cpp/release/thrift_ep/src/thrift_ep-install/include
>>> -- Thrift static library: 
>>> /Users/romain/git/apache/arrow/cpp/release/thrift_ep/src/thrift_ep-install/lib/libthrift.a
>>> -- Thrift compiler: 
>>> /Users/romain/git/apache/arrow/cpp/release/thrift_ep/src/thrift_ep-install/bin/thrift
>>> 
>>> As part of the cmake (full below). I have a brew installed thrift, maybe 
>>> this is not picked up ?
>>> 
>>> Romain
>>> 
>>> 
>>> 
>>> romain@purrplex ~/git/apache/arrow/cpp/release $ cmake .. 
>>> -DARROW_PARQUET=ON -DCMAKE_BUILD_TYPE=Release 
>>> -DARROW_BOOST_USE_SHARED:BOOL=Off
>>> -- Building using CMake version: 3.13.2
>>> -- The C compiler identification is AppleClang 10.0.0.10001044
>>> -- The CXX compiler identification is AppleClang 10.0.0.10001044
>>> -- Check for working C compiler: 
>>> /Library/Developer/CommandLineTools/usr/bin/cc
>>> -- Check for working C compiler: 
>>> /Library/Developer/CommandLineTools/usr/bin/cc -- works
>>> -- Detecting C compiler ABI info
>>> -- Detecting C compiler ABI info - done
>>> -- Detecting C compile features
>>> -- Detecting C compile features - done
>>> -- Check for working CXX compiler: 
>>> /Library/Developer/CommandLineTools/usr/bin/c++
>>> -- Check for working CXX compiler: 
>>> /Library/Developer/CommandLineTools/usr/bin/c++ -- works
>>> -- Detecting CXX compiler ABI info
>>> -- Detecting CXX compiler ABI info - done
>>> -- Detecting CXX compile features
>>> -- Detecting CXX compile features - done
>>> -- Arrow version: 0.12.0 (full: '0.12.0-SNAPSHOT')
>>> -- Found PkgConfig: /usr/local/bin/pkg-config (found version "0.29.2")
>>> clang-tidy not found
>>> clang-format found at /usr/local/opt/llvm@6/bin/clang-format
>>> infer not found
>>> -- Found cpplint executable at 
>>> /Users/romain/git/apache/arrow/cpp/build-support/cpplint.py
>>> -- Compiler command: env LANG=C 
>>> /Library/Developer/CommandLineTools/usr/bin/c++ -v
>>> -- Compiler version: Apple LLVM version 10.0.0 (clang-1000.10.44.4)
>>> Target: x86_64-apple-darwin18.2.0
>>> Thread model: posix
>>> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
>>> 
>>> -- Compiler id: AppleClang
>>> Selected compiler clang 4.1.0svn
>>> -- Performing Test CXX_SUPPORTS_SSE4_2
>>> -- Performing Test CXX_SUPPORTS_SSE4_2 - Success
>>> -- Performing Test CXX_SUPPORTS_ALTIVEC
>>> -- Performing Test CXX_SUPPORTS_ALTIVEC - Success
>>> -- Performing Test CXX_SUPPORTS_ARMCRC
>>> -- Performing Test CXX_SUPPORTS_ARMCRC - Failed
>>> Configured for RELEASE build (set with cmake 
>>> -DCMAKE_BUILD_TYPE={release,debug,...})
>>> -- Build Type: RELEASE
>>> -- BOOST_VERSION: 1.67.0
>>> -- BROTLI_VERSION: v0.6.0
>>> -- DOUBLE_CONVERSION_VERSION: v3.1.1
>>> -- FLATBUFFERS_VERSION: 02a7807dd8d26f5668ffbbec0360dc107bbfabd5
>>> -- GBENCHMARK_VERSION: v1.4.1
>>> -- GFLAGS_VERSION: v2.2.0
>>> -- GLOG_VERSION: v0.3.5
>>> -- GRPC_VERSION: v1.14.1
>>> -- GTEST_VERSION: 1.8.0
>>> -- JEMALLOC_VERSION: 17c897976c60b0e6e4f4a365c751027244dada7a
>>> -- LZ4_VERSION: v1.7.5
>>> -- ORC_VERSION: 1.5.1
>>> -- PROTOBUF_VERSION: v3.6.1
>>> -- RAPIDJSON_VERSION: v1.1.0
>>> -- RE2_VERSION: 2018-10-01
>>> -- SNAPPY_VERSION: 1.1.3
>>> -- THRIFT_VERSION: 0.11.0
>>> -- ZLIB_VERSION: 1.2.8
>>> -- ZSTD_VERSION: v1.3.7
>>> -- Found pthread: /usr/lib/libpthread.dylib
>>> -- Boost version: 1.68.0
>>> -- Found the following Boost libraries:
>>> --   regex
>>> --   system
>>> --   filesystem
>>> -- Boost include dir: /usr/local/include
>>> -- Boost libraries: 
>>> /usr/local/lib/libboost_regex-mt.a/usr/local/lib/libboost_system-mt.a/usr/local/lib/libboost_filesystem-mt.a
>>> Added static library dependency boost_system_static: 
>>> /usr/local/lib/libboost_system-mt.a
>>> Added static library dependency boost_filesystem_static: 
>>> /usr/local/lib/libboost_filesystem-mt.a
>>> Added static library dependency boost_regex_static: 
>>> /usr/local/lib/libboost_regex-mt.a
>>> Added static library dependency double-conversion_static: 
>>> 

Parallel processing

[Romain Francois]

Hello, 

Are the functions in parallel.h the de facto model for parallelisation in arrow 
? 
https://github.com/apache/arrow/blob/42cf69abfc1368c9884f4581811e2e7900c98fcd/cpp/src/arrow/util/parallel.h
 


Just wondering if things like intel tbb were considered, IIRC managing threads 
manually can be expensive and tasks are usually cheaper. 

Romain

[NOTICE] Mandatory migration of git repositories to gitbox.apache.org

[Apache Infrastructure Team]

Hello, arrow folks.
As stated earlier in 2018, all git repositories must be migrated from
the git-wip-us.apache.org URL to gitbox.apache.org, as the old service
is being decommissioned. Your project is receiving this email because
you still have repositories on git-wip-us that needs to be migrated.

The following repositories on git-wip-us belong to your project:
 - arrow-site.git


We are now entering the mandated (coordinated) move stage of the roadmap,
and you are asked to please coordinate migration with the Apache
Infrastructure Team before February 7th. All repositories not migrated
on February 7th will be mass migrated without warning, and we'd appreciate
it if we could work together to avoid a big mess that day :-).

Moving to gitbox means you will get full write access on GitHub as well,
and be able to close/merge pull requests and much more.

To have your repositories moved, please follow these steps:

- Ensure consensus on the move (a link to a lists.apache.org thread will
  suffice for us as evidence).
- Create a JIRA ticket at https://issues.apache.org/jira/browse/INFRA

Your migration should only take a few minutes. If you wish to migrate
at a specific time of day or date, please do let us know in the ticket.

As always, we appreciate your understanding and patience as we move
things around and work to provide better services and features for
the Apache Family.

Should you wish to contact us with feedback or questions, please do so
at: us...@infra.apache.org.


With regards,
Apache Infrastructure

Re: Enabling an installation path for Arrow R users

[Jonathan Chiang]

Hi, 

Long term, I believe getting an arrow package onto cran would be most useful 
for R users. Building arrow in R on Mac was easier than Linux for me. I was 
still having trouble installing after spending a couple hours or so. 

Typically if you can install.package from cran is most convenient. Devtools 
installation from a github repository if it works across different OSes would 
suffice.

Most growing R users are typically using RStudio, so conda may be inconvenient 
for R users, because it requires installing IR kernel  for anaconda.   

Whatever installation method or strategy you used for feather was easy for me 
to install as a R user. 

Thanks,
Jonathan 

> On Jan 2, 2019, at 11:59 PM, Krisztián Szűcs  
> wrote:
> 
> Perhaps an R conda-forge feedstock?
> I'm not sure how widely conda-forge is used in the R commmunity,
> but it already hosts around a thousand packages[1].
> 
> [1] https://github.com/conda-forge?=r-
> 
>> On Wed, Jan 2, 2019 at 6:09 PM Wes McKinney  wrote:
>> 
>> hi folks,
>> 
>> With 0.12 around the corner and significant progress on the R bindings
>> project (sufficient for Spark integration [1]), I am wondering how
>> everyday R users are going to be able to install the software
>> respectively on Linux, macOS, and Windows. Thoughts about the strategy
>> for this?
>> 
>> Thanks
>> Wes
>> 
>> [1]: https://github.com/apache/arrow/pull/3001
>> 

[jira] [Created] (ARROW-4149) [CI/C++] Parquet test misses ZSTD compression codec in CMake 3.2 nightly builds

[Krisztian Szucs (JIRA)]

Krisztian Szucs created ARROW-4149:
--

 Summary: [CI/C++] Parquet test misses ZSTD compression codec in 
CMake 3.2 nightly builds
 Key: ARROW-4149
 URL: https://issues.apache.org/jira/browse/ARROW-4149
 Project: Apache Arrow
  Issue Type: Bug
  Components: C++
Reporter: Krisztian Szucs
Assignee: Krisztian Szucs


See build https://travis-ci.org/kszucs/crossbow/builds/474545470



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARROW-4148) [CI/Python] Disable ORC on nightly Alpine builds

[Krisztian Szucs (JIRA)]

Krisztian Szucs created ARROW-4148:
--

 Summary: [CI/Python] Disable ORC on nightly Alpine builds
 Key: ARROW-4148
 URL: https://issues.apache.org/jira/browse/ARROW-4148
 Project: Apache Arrow
  Issue Type: Bug
  Components: Continuous Integration
Reporter: Krisztian Szucs
Assignee: Krisztian Szucs


See CI failure https://travis-ci.org/kszucs/crossbow/builds/474545437



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Enabling an installation path for Arrow R users

[Krisztián Szűcs]

Perhaps an R conda-forge feedstock?
I'm not sure how widely conda-forge is used in the R commmunity,
but it already hosts around a thousand packages[1].

[1] https://github.com/conda-forge?=r-

On Wed, Jan 2, 2019 at 6:09 PM Wes McKinney  wrote:

> hi folks,
>
> With 0.12 around the corner and significant progress on the R bindings
> project (sufficient for Spark integration [1]), I am wondering how
> everyday R users are going to be able to install the software
> respectively on Linux, macOS, and Windows. Thoughts about the strategy
> for this?
>
> Thanks
> Wes
>
> [1]: https://github.com/apache/arrow/pull/3001
>