Re: Contribution etiquette?

Also, if you do have bandwidth and interest in doing code reviews, this is also super helpful, so feel free to chime in on GitHub if you want to do a code review (either on outstanding or merged patches while we are in commit-then-review mode). On Wed, Mar 16, 2016 at 3:08 PM, Wes McKinney

[jira] [Created] (ARROW-68) Update setup_build_env and third-party script to be more userfriendly

Micah Kornfield created ARROW-68: Summary: Update setup_build_env and third-party script to be more userfriendly Key: ARROW-68 URL: https://issues.apache.org/jira/browse/ARROW-68 Project: Apache

[jira] [Created] (ARROW-70) C++: Add "lite" DCHECK macros used in parquet-cpp

Wes McKinney created ARROW-70: - Summary: C++: Add "lite" DCHECK macros used in parquet-cpp Key: ARROW-70 URL: https://issues.apache.org/jira/browse/ARROW-70 Project: Apache Arrow Issue Type: New

Re: [jira] [Created] (ARROW-68) Update setup_build_env and third-party script to be more userfriendly

how do i unsubscribe from this? sorry, went to issues.apache.org says i don't have an account, can't recover with this email address not sure how i got on here, but i would like to get off sorry again, thanks On Wed, Mar 16, 2016 at 7:58 PM, Micah Kornfield (JIRA) wrote: >

Re: Understanding "shared" memory implications

hi Kai, This sounds like it might merit a separate thread to discuss the growth of Arrow as a modular ecosystem of libraries in different programming languages and related tools (we've discussed shared memory data access and metadata representation, but not questions around ownership and

RE: Understanding "shared" memory implications

Hi Wes, Thanks for the helpful clarifying and am glad to know you're also well moving on the project. Yes I will look closely to the project, raising my specific comments in the mailing list. Regards, Kai -Original Message- From: Wes McKinney [mailto:w...@cloudera.com] Sent: Friday,

Re: Understanding "shared" memory implications

I've been under the impression that exposing memory to be shared directly and not copied WAS, in fact, the responsibility of Arrow. In fact, I read this in [1] and this is turned me on to Arrow in the first place. [1]

Re: [jira] [Created] (ARROW-68) Update setup_build_env and third-party script to be more userfriendly

Hi, I want to unsubscribe to this forum, help please, Thanks, 2016-03-17 13:35 GMT+00:00 J. Albert Bowden : > how do i unsubscribe from this? > > sorry, went to issues.apache.org > > says i don't have an account, can't recover with this email address > > not sure how

Re: Understanding "shared" memory implications

It has always been the expectation that no system would be required to use a particular piece of Arrow software to "use Arrow" (hence the importance of having a well-defined specification for memory and metadata). However, we should also not expect all systems to create their own implementations

[jira] [Resolved] (ARROW-55) Python: fix legacy Python (2.7) tests and add to Travis CI

[ https://issues.apache.org/jira/browse/ARROW-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wes McKinney resolved ARROW-55. --- Resolution: Fixed Issue resolved by pull request 25 [https://github.com/apache/arrow/pull/25] >

[jira] [Commented] (ARROW-64) Add zsh support to C++ build scripts

[ https://issues.apache.org/jira/browse/ARROW-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15198295#comment-15198295 ] Wes McKinney commented on ARROW-64: --- [~xhochy] I am unable to assign this to you, so feel free to

RE: Understanding "shared" memory implications

Sounds good to have all these compatible, modular goals and changes, for Apache Arrow, in the early stage. On the other hand, not being afraid of changes keep evolving towards the core goals and the well-defined initiatives, which is also important. Parquet is relevant and also a good example.

Re: Understanding "shared" memory implications

I have similar concerns as Todd stated below. With an mmap-based approach, we are treating shared memory objects like files. This brings in all filesystem related considerations like ACL and lifecycle mgmt. Stepping back a little, the shared-memory work isn't really specific to Arrow. A few

Re: Understanding "shared" memory implications

I always thought Arrow was just an in-memory format, and it is the responsibility of whoever else that want to use it to carry that responsibilities out, because depending on workloads, different frameworks might pick very different applications. Otherwise it seems to be doing too much and having

Re: [jira] [Created] (ARROW-68) Update setup_build_env and third-party script to be more userfriendly

hello, You can unsubscribe from dev@arrow.apache.org by sending an email to dev-unsubscr...@apache.arrow.org However: if you are not interested in keeping an eye on the engineering work that is being done on the project (the JIRA updates), consider setting up and email filter matching on

Re: Understanding "shared" memory implications

@Todd: agree entirely on prototyping design. My goal is throw out some ideas and some POC code and then we can explore from there. My main thoughts have initially been around lifecycle management. I've done some work previously where a consistently sized shared buffer using mmap has improved

[jira] [Updated] (ARROW-64) Add zsh support to C++ build scripts

[ https://issues.apache.org/jira/browse/ARROW-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Nadeau updated ARROW-64: Assignee: Uwe L. Korn > Add zsh support to C++ build scripts > >