problems with statically linked Boost

[Alex Samuel]

Hello,

I am having some troubles using the Continuum PyArrow conda package 
dependencies in conjunction with internal C++ extension modules.

Apparently, Arrow and Parquet link Boost statically.  We have some internal 
packages containing C++ code that linking Boost libs dynamicaly.  If we import 
Feather as well as our own extension modules into the same Python process, we 
get random segfaults in Boost.  I think what's happening is that our extension 
modules are picking up Boost's symbols from Arrow and Parquet already loaded 
into the process, rather than from our own Boost shared libs.

Could anyone explain the policy for linking Boost in binary distributions, 
particularly conda packages?  What is your expectation for how other C++ 
extension modules should be built?

Thanks in advance,
Alex

Upgrade to Clang-5.0

[Phillip Cloud]

After https://github.com/apache/arrow/pull/1597 is merged arrow-cpp will
now pin clang to version 5.0. Please upgrade your clang installations.

Thanks,
Phillip

Re: Arrow for MATLAB?

[Nick Haddad]

Thanks Wes,

I will look these over!

-Nick

 
On 2/15/18, 12:45 PM, "Wes McKinney"  wrote:

hi Nick,

I would strongly encourage you to focus your energies on supporting
the general Arrow streaming and file formats as described in
   http://arrow.apache.org/docs/ipc.html. It's fine to support Feather,
so long as you restrict yourself to the API defined in
https://github.com/apache/arrow/blob/master/cpp/src/arrow/ipc/feather.h

As soon as we have reasonable R bindings for the Arrow C++ libraries,
I would like to replace the internal details of the Feather format
with the Arrow IPC format, deprecating the metadata defined in
https://github.com/apache/arrow/blob/master/cpp/src/arrow/ipc/feather.fbs

Please let us know how things go and if there's anything we can do to help.

Thanks,
Wes

On Thu, Feb 15, 2018 at 9:48 AM, Nick Haddad  
wrote:
> Uwe and Joris,
>
> I work for MathWorks. We plan to contribute Feather read/write capability 
in the near future. Interesting idea about MATLAB and Arrow. We’ll take a look 
as well.
>
> Thanks
> -Nick
>
>
> On 2/14/18, 3:39 AM, "Joris Peeters"  wrote:
>
> Yeah, pinging Mathworks might be worth it. It feels like this is 
something
> that could be of great value to them. Aside from HDF5 & mat files 
(both on
> disk), it can be really tedious to efficiently share data from 
anywhere
> with MATLAB, so it's becoming increasingly isolated.
> I'm going to play around for a few days with Arrow & the Matlab C++ 
API,
> getting a bit more familiar with it and maybe hacking a small 
prototype
> together. Currently it's just out-of-hours, though, so don't expect 
major
> magic. :)
>
> Thanks,
> -J
>
> On Tue, Feb 13, 2018 at 2:33 PM, Phillip Cloud  
wrote:
>
> > The MathWorks is in the process of starting to contribute. I spoke 
with
> > them a couple weeks ago about this and they were excited about it. 
I can
> > ping them to see if they are still interested.
> >
> > On Tue, Feb 13, 2018, 09:24 Uwe L. Korn  wrote:
> >
> > > Hello Joris,
> > >
> > > this is only due to lack of someone doing it and probably due to 
lack of
> > > people that have the experience to do that. I had a short look at
> > Matlab's
> > > C++ API and the interfaces seem to be promising enough
> > > https://de.mathworks.com/help/matlab/matlab-data-array.html that 
once
> > > someone attempts it, it should not be hard to build.
> > >
> > > If you want to try to take a shot, we are happy to help if there 
are
> > > problems with the Arrow side of things.
> > >
> > > Uwe
> > >
> > > On Tue, Feb 13, 2018, at 2:41 PM, Joris Peeters wrote:
> > > > Hello,
> > > >
> > > > Is anyone aware of plans (or concrete projects) to add MATLAB 
bindings
> > > for
> > > > Arrow? I'm interested in exchanging data between Java, Python, 
..., and
> > > > MATLAB - and Arrow sounds like a great solution.
> > > >
> > > > I couldn't find any pre-existing effort, though, so curious if 
that is
> > > due
> > > > to a lack of interest or because there might be underlying 
reasons that
> > > > would make this very hard to achieve.
> > > >
> > > > Best,
> > > > -Joris.
> > >
> >
>
>

[jira] [Created] (ARROW-2167) [C++] Building Orc extensions fails with the default BUILD_WARNING_LEVEL=Production

[Phillip Cloud (JIRA)]

Phillip Cloud created ARROW-2167:


 Summary: [C++] Building Orc extensions fails with the default 
BUILD_WARNING_LEVEL=Production
 Key: ARROW-2167
 URL: https://issues.apache.org/jira/browse/ARROW-2167
 Project: Apache Arrow
  Issue Type: Improvement
  Components: C++
Affects Versions: 0.8.0
Reporter: Phillip Cloud


Building orc_ep fails because there are a bunch of upstream warnings like not 
providing {{override}} on virtual destructor subclasses, and using {{0}} as the 
{{nullptr}} constant and the default {{BUILD_WARNING_LEVEL}} is {{Production}} 
which includes {{-Wall}} (all warnings as errors).

I see that there are different possible options for {{BUILD_WARNING_LEVEL}} so 
it's possible for developers to deal with this issue.

It seems easier to let EPs build with whatever the default warning level is for 
the project rather than force our defaults on those projects.

Generally speaking, are we using our own CXX_FLAGS for EPs other than Orc?



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

[jira] [Created] (ARROW-2166) [GLib] Implement Slice for Column

[yosuke shiro (JIRA)]

yosuke shiro created ARROW-2166:
---

 Summary: [GLib] Implement Slice for Column
 Key: ARROW-2166
 URL: https://issues.apache.org/jira/browse/ARROW-2166
 Project: Apache Arrow
  Issue Type: New Feature
Reporter: yosuke shiro


Add {{Slice}} api to Column.



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