Thanks. This work has been pushed off a bit because I need to get existing
PRs into better shape. Hopefully 1.9 is released when I pick it up
(otherwise I would lean towards forking for the time being as well).
On Tue, Mar 12, 2019 at 3:01 AM Uwe L. Korn wrote:
> Hello Micah,
>
> > Uwe, I'm
Wes McKinney created ARROW-4850:
---
Summary: [CI] Integration test failures do not fail the Travis CI
build
Key: ARROW-4850
URL: https://issues.apache.org/jira/browse/ARROW-4850
Project: Apache Arrow
Uwe L. Korn created ARROW-4849:
--
Summary: [C++] Add docker-compose entry for testing Ubuntu Bionic
build with system packages
Key: ARROW-4849
URL: https://issues.apache.org/jira/browse/ARROW-4849
Jeroen created ARROW-4848:
-
Summary: Static libparquet not compiled with -DARROW_STATIC on
Windows
Key: ARROW-4848
URL: https://issues.apache.org/jira/browse/ARROW-4848
Project: Apache Arrow
Issue
Wes McKinney created ARROW-4847:
---
Summary: [Python] Add pyarrow.table factory function that
dispatches to various ctors based on type of input
Key: ARROW-4847
URL: https://issues.apache.org/jira/browse/ARROW-4847
Wes McKinney created ARROW-4846:
---
Summary: [Java] Update Jackson to 2.9.8
Key: ARROW-4846
URL: https://issues.apache.org/jira/browse/ARROW-4846
Project: Apache Arrow
Issue Type: Improvement
Hello Joris,
'/data/home/jpeeter/apps/anaconda3/envs/testarrow/lib/fromArrowStream.mexa64':
/data/home/jpeeter/apps/anaconda3/envs/testarrow/lib/fromArrowStream.mexa64:
undefined symbol: _ZNK5arrow6Status8ToStringEv.
sounds like fromArrowStream.mexa64 was still compiled using
Jeroen created ARROW-4845:
-
Summary: Compiler warnings on Windows
Key: ARROW-4845
URL: https://issues.apache.org/jira/browse/ARROW-4845
Project: Apache Arrow
Issue Type: Bug
Components: R
Jeroen created ARROW-4844:
-
Summary: Static libarrow is missing vendored libdouble-conversion
Key: ARROW-4844
URL: https://issues.apache.org/jira/browse/ARROW-4844
Project: Apache Arrow
Issue Type:
Andy Grove created ARROW-4843:
-
Summary: [Rust] [DataFusion] Parquet data source should support
DATE
Key: ARROW-4843
URL: https://issues.apache.org/jira/browse/ARROW-4843
Project: Apache Arrow
Uwe L. Korn created ARROW-4840:
--
Summary: [C++] Persist CMake options in generated header
Key: ARROW-4840
URL: https://issues.apache.org/jira/browse/ARROW-4840
Project: Apache Arrow
Issue Type:
I've cleaned up my issues for Rust, moving most of them to 0.14.0.
I have two PRs in progress that I would appreciate reviews on:
https://github.com/apache/arrow/pull/3671 - [Rust] Table API (a.k.a
DataFrame)
https://github.com/apache/arrow/pull/3851 - [Rust] Parquet data source in
DataFusion
Uwe L. Korn created ARROW-4842:
--
Summary: [C++] Persist CMake options in pkg-config files
Key: ARROW-4842
URL: https://issues.apache.org/jira/browse/ARROW-4842
Project: Apache Arrow
Issue Type:
Uwe L. Korn created ARROW-4841:
--
Summary: [C++] Persist CMake options in generated CMake config
Key: ARROW-4841
URL: https://issues.apache.org/jira/browse/ARROW-4841
Project: Apache Arrow
Issue
[A] Short background:
We are working on a MEX library that converts a binary array (representing
an Arrow stream or file) into MATLAB structs. This is in
parallel/complement to what already exists in the main Arrow project, which
focuses on feather, but the hope is certainly to contribute back
Eric Erhardt created ARROW-4839:
---
Summary: [C#] Add NuGet support
Key: ARROW-4839
URL: https://issues.apache.org/jira/browse/ARROW-4839
Project: Apache Arrow
Issue Type: Improvement
I disagree. I think we need a forcing function to create some urgency
to work out any of the problems that may come up. If we need to make a
0.13.1 to fix problems that are not caught during the release (and
producing binary artifacts) then I think that is okay
On Tue, Mar 12, 2019 at 9:53 AM
> Having C# NuGet package working would be nice
I've opened https://issues.apache.org/jira/browse/ARROW-4839 for this and I
will be working on it this week. I'd like to see an official Arrow NuGet
package on www.nuget.org soon, so getting it in this release would work out
perfect from my side.
Hi,
The CMake refactor is huge enough to cause unexpected post-release
defects. I'd consider shipping it with the next release and let is stabilize
during the development of 0.14.
On Tue, Mar 12, 2019 at 3:41 PM Wes McKinney wrote:
> hi Uwe,
>
> I would be OK with trying to release next week.
hi Uwe,
I would be OK with trying to release next week. Let's see what others
think. Getting the CMake refactor in and packaging sorted out is the
big priority for the C++-using ecosystem. I haven't seen anything
hugely pressing in the other impls based on the recent patch flow.
Having C# NuGet
Hello,
two things come to my mind:
* I'm spending now some time again on the CMake refactor. The only blocker I
currently see is the issue with detecting the correct gtest libraries on
Windows. Otherwise this can go in. Being very confident about my work: This
will break things even though
hi folks,
I think we are on track to be able to release toward the end of this
month. My proposed timeline:
* This week (March 11-15): feature/improvement push mostly
* Next week (March 18-22): shift to bug fixes, stabilization, empty
backlog of feature/improvement JIRAs
* Week of March 25:
Francois Saint-Jacques created ARROW-4838:
-
Summary: [C++] Implement safe Make constructor
Key: ARROW-4838
URL: https://issues.apache.org/jira/browse/ARROW-4838
Project: Apache Arrow
Krisztian Szucs created ARROW-4837:
--
Summary: [C++] Support c++filt on a custom path in the run-test.sh
script
Key: ARROW-4837
URL: https://issues.apache.org/jira/browse/ARROW-4837
Project: Apache
Kouhei Sutou created ARROW-4835:
---
Summary: [GLib] Add boolean operations
Key: ARROW-4835
URL: https://issues.apache.org/jira/browse/ARROW-4835
Project: Apache Arrow
Issue Type: New Feature
Mike Pedersen created ARROW-4836:
Summary: "Cannot tell() a compressed stream" when using
RecordBatchStreamWriter
Key: ARROW-4836
URL: https://issues.apache.org/jira/browse/ARROW-4836
Project: Apache
Hello Micah,
> Uwe, I'm not sure I understand what type of support/help you are thinking
> of. Could you elaborate a little bit more before I reach out?
I would help them with the same build system improvement we have done in the
recent time (and are currently) doing in Arrow for C++. Nothing
+1 on Make and MakeUnsafe
On Mon, Mar 11, 2019 at 3:15 PM Francois Saint-Jacques <
fsaintjacq...@gmail.com> wrote:
> I can settle with Micah's proposal of `MakeValidate`, though I'd prefer
> that Make is safe by default and responsible users use MakeUnsafe :), I'll
> settle with the pragmatic
28 matches
Mail list logo
