OK, so I may have misunderstood this a bit. It sounds like it would be
better for more people to contribute to my fork? This could be workable.

Thanks,

Andy.

On Fri, Mar 30, 2018 at 4:51 PM, Wes McKinney <[email protected]> wrote:

> hi Andy,
>
> > What exactly is the approval process? I know this is slightly tricky
> because this PR is for a language that the current contributors generally
> don't have experience with.
>
> Ideally once this gets off the ground with multiple active
> contributors, it would be nice too have another contributor
> acknowledge that they've taken a look at a patch and that it looks
> good. In the meantime, committers can merge the patches as long as the
> build isn't broken.
>
> Thanks
> Wes
>
> On Fri, Mar 30, 2018 at 12:43 PM, Andy Grove <[email protected]>
> wrote:
> > As you've probably seen, I have been working away on
> > https://github.com/apache/arrow/pull/1804
> >
> > Most recently I had started adding type-safe traits for performing
> > operations on arrays.
> >
> > For example:
> >
> > trait ArrayOps<T> {
> >     fn compare(&self, other: &Array, f: &Fn(T,T) -> bool) ->
> > Result<Vec<bool>, Error>;
> >     fn compute(&self, other: &Array, f: &Fn(T,T) -> T) -> Result<Vec<T>,
> > Error>;
> > }
> >
> > This makes it easy to perform operations on arrays using closures.
> >
> > let a = Array::from(vec![1,2,3,4,5]);
> > let b = Array::from(vec![5,4,3,2,1]);
> > let c = a.compute(&b, &|a: i32,b: i32| a * b).unwrap();
> > assert_eq!(c, vec![5,8,9,8,5]);
> >
> > I'm a bit concerned that I'm working alone on the PR and wanted to see if
> > there is a better way since there are others who are waiting to start
> > contributing.
> >
> > I would really like to see the current PR merged so that they can jump in
> > too.
> >
> > What exactly is the approval process? I know this is slightly tricky
> > because this PR is for a language that the current contributors generally
> > don't have experience with.
> >
> > Thanks,
> >
> > Andy.
>

Reply via email to