I found Apache Thrift registers the following MIME types:
* application/vnd.apache.thrift.binary
* application/vnd.apache.thrift.compact
* application/vnd.apache.thrift.json
https://www.iana.org/assignments/media-types/media-types.xhtml
Thrift uses "vnd.apache." prefix[1].
[1]
Rinke Hoekstra created ARROW-7226:
-
Summary: [JSON] Json loader fails on example in documentation.
Key: ARROW-7226
URL: https://issues.apache.org/jira/browse/ARROW-7226
Project: Apache Arrow
Arrow Build Report for Job nightly-2019-11-21-0
All tasks:
https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2019-11-21-0
Failed Tasks:
- conda-osx-clang-py27:
URL:
https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2019-11-21-0-azure-conda-osx-clang-py27
-
On Wed, 20 Nov 2019 20:50:12 -0800
Micah Kornfield wrote:
> A recent PR for datasets [1] seems to have introduced the convention of
> aliasing "std::shared_ptr" with "TypePtr" for some type. I think in
> the past we had decided not to use a convention like this but I can't find
> the thread.
This notation is already used in some parts of the codebase [1]. I
think it was introduced when absorbing gandiva and then in a draft of
the logical operations in the compute module. I have no strong opinion
for/against. I find it convenient to reduce typing, but the style
guide argue against
Antoine Pitrou created ARROW-7225:
-
Summary: [C++] `*std::move(Result)` calls T copy constructor
Key: ARROW-7225
URL: https://issues.apache.org/jira/browse/ARROW-7225
Project: Apache Arrow
Hello,
I'd like some clarification on the spec and intent for dense arrays.
Currently, it is specified that offsets of a dense union are "in order /
increasing" (*). However, it is not obvious whether repeated values are
allowed or not.
I suspect the intent is to avoid having people exploit
Hello,
There's some ambiguity whether a union array's "types" buffer stores
physical child ids, or logical type codes.
Some of our C++ tests assume the former:
https://github.com/apache/arrow/blob/master/cpp/src/arrow/array_union_test.cc#L107-L123
Some of our C++ tests assume the latter:
On Thu, 21 Nov 2019 08:40:10 -0500
Francois Saint-Jacques wrote:
> This notation is already used in some parts of the codebase [1]. I
> think it was introduced when absorbing gandiva and then in a draft of
> the logical operations in the compute module. I have no strong opinion
> for/against. I
Zhuo Peng created ARROW-7227:
Summary: [Python] Provide wrappers for ConcatenateWithPromotion()
Key: ARROW-7227
URL: https://issues.apache.org/jira/browse/ARROW-7227
Project: Apache Arrow
Issue
hi folks,
We're accruing some bug reports relating to the C# library when it
comes to interop with other languages
Nowhere in
https://github.com/apache/arrow/blob/master/csharp/README.md
is it clearly stated that such problems are to be anticipated.
Until C# participates in the integration
hi Andong,
Yes. Here is the commit implementing these changes
https://github.com/apache/arrow/commit/3eaceec8561d6b783d56f7b82e091c19e7fb043c#diff-32981a13284db7a021131df49e6cd203
- Wes
On Thu, Nov 21, 2019 at 12:44 AM Andong Zhan wrote:
>
> Hi Arrow developers,
>
> We noticed that since
hi Antoine,
The latter is correct, or at least what is intended in the specification.
For example, if the type metadata indices codes [0, 5, 10], then the
"types" buffer should contain values selected from these values rather
than physical child indexes (which would be [0, 1, 2] in this case)
hi Antoine,
It's a good question.
The intent when we wrote the specification was to be strictly
monotonic, but there seems nothing especially harmful about relaxing
the constraint to allow for repeated values or even non-monotonicity
(strict or otherwise). For example, if we had the union
['a',
+1 (binding). Thanks Micah
On Wed, Nov 20, 2019 at 10:42 PM Micah Kornfield wrote:
>
> Hello,
> As discussed on [1], I've proposed clarifications in a PR [2] that
> clarifies:
>
> 1. It is not required that all dictionary batches occur at the beginning
> of the IPC stream format (if a the first
I think we should mostly be careful about public APIs. With public
APIs we should write out the types and avoid aliases. With
implementation details and private/protected class members, I think it
is fine to use aliases.
On Thu, Nov 21, 2019 at 11:06 AM Antoine Pitrou wrote:
>
> On Thu, 21 Nov
Forgot to say, My vote is +1 (binding).
On Thu, Nov 21, 2019 at 12:09 PM Wes McKinney wrote:
> +1 (binding). Thanks Micah
>
> On Wed, Nov 20, 2019 at 10:42 PM Micah Kornfield
> wrote:
> >
> > Hello,
> > As discussed on [1], I've proposed clarifications in a PR [2] that
> > clarifies:
> >
> >
Zhuo Peng created ARROW-7229:
Summary: [C++] Unify ConcatenateTables APIs
Key: ARROW-7229
URL: https://issues.apache.org/jira/browse/ARROW-7229
Project: Apache Arrow
Issue Type: Improvement
Zhuo Peng created ARROW-7228:
Summary: [Python] Expose RecordBatch.FromStructArray in Python.
Key: ARROW-7228
URL: https://issues.apache.org/jira/browse/ARROW-7228
Project: Apache Arrow
Issue
Hi Micah,
I was trying to create an Int64Builder class but kept getting a type
identifier error. So, I did a bit of digging and realized I was looking at
the latest commit of libarrow.pxd on GitHub which wasn't actually released
as part of 0.15.1.
Thanks for your help anyways!
Suhail
On Sat,
Wes McKinney created ARROW-7230:
---
Summary: [C++] Use vendored std::optional instead of
boost::optional in Gandiva
Key: ARROW-7230
URL: https://issues.apache.org/jira/browse/ARROW-7230
Project: Apache
Hmm, I also thought the intention was monotonically increasing. I can't
think of a strong reason one way or another. If the argument about code to
do random access is the same in all cases, is there any benefit to forcing
any order at all? Memory prefetching?
On Thu, Nov 21, 2019 at 11:48 AM Wes
Micah Kornfield created ARROW-7234:
--
Summary: [C++] Add Result to APIs to Gandiva
Key: ARROW-7234
URL: https://issues.apache.org/jira/browse/ARROW-7234
Project: Apache Arrow
Issue Type:
Micah Kornfield created ARROW-7239:
--
Summary: [C++] Add Result to APIs to plasma
Key: ARROW-7239
URL: https://issues.apache.org/jira/browse/ARROW-7239
Project: Apache Arrow
Issue Type:
Micah Kornfield created ARROW-7240:
--
Summary: [C++] Add Result to APIs to arrow/util
Key: ARROW-7240
URL: https://issues.apache.org/jira/browse/ARROW-7240
Project: Apache Arrow
Issue Type:
Micah Kornfield created ARROW-7231:
--
Summary: [C++] Parent bug for tracking migration to Result
Key: ARROW-7231
URL: https://issues.apache.org/jira/browse/ARROW-7231
Project: Apache Arrow
Micah Kornfield created ARROW-7235:
--
Summary: [C++] Add Result to APIs to arrow/io
Key: ARROW-7235
URL: https://issues.apache.org/jira/browse/ARROW-7235
Project: Apache Arrow
Issue Type:
Micah Kornfield created ARROW-7236:
--
Summary: [C++] Add Result to APIs to arrow/csv
Key: ARROW-7236
URL: https://issues.apache.org/jira/browse/ARROW-7236
Project: Apache Arrow
Issue Type:
Micah Kornfield created ARROW-7232:
--
Summary: [C++] Add Result to APIs to core vector structures
Key: ARROW-7232
URL: https://issues.apache.org/jira/browse/ARROW-7232
Project: Apache Arrow
Micah Kornfield created ARROW-7233:
--
Summary: [C++] Add Result APIs to IPC module
Key: ARROW-7233
URL: https://issues.apache.org/jira/browse/ARROW-7233
Project: Apache Arrow
Issue Type:
This is an interesting question.
IMO, to support repeated values, we also need to design a "coherency
protocol", to avoid the scenario where once a value is witten, the change
is propagated to another slot unexpectedly.
Best,
Liya Fan
On Fri, Nov 22, 2019 at 1:34 PM Micah Kornfield
wrote:
>
>
> I think we should mostly be careful about public APIs. With public
> APIs we should write out the types and avoid aliases. With
> implementation details and private/protected class members, I think it
> is fine to use aliases.
My concern with this is that in general if the types are in the
Micah Kornfield created ARROW-7237:
--
Summary: [C++] Add Result to APIs to arrow/json
Key: ARROW-7237
URL: https://issues.apache.org/jira/browse/ARROW-7237
Project: Apache Arrow
Issue Type:
Micah Kornfield created ARROW-7238:
--
Summary: [C++] Add Result to APIs to arrow/adapters
Key: ARROW-7238
URL: https://issues.apache.org/jira/browse/ARROW-7238
Project: Apache Arrow
Issue
34 matches
Mail list logo
