Ianna Osborne

@pviscone - I'm running on darwin macOS 11.6 Clang 14.0.6, Python 3.10.8, and ``` >>> ROOT.__version__ '6.26/10' >>> ak.__version__ '2.3.1' >>> np.__version__ '1.23.5' ``` I have tried to go to...

> Well, this is strange ... I _was_ able to reproduce this but suddenly am no longer able. When it was segfaulting, it didn't seem to be the `memcpy`, which...

just as a reminder to myself - the warnings on MacOS in awkward-2.5.1rc1 are as follows: ```c++ In file included from /Users/yana/Projects/PR2818/awkward/awkward-cpp/src/libawkward/io/json.cpp:19: /Users/yana/Projects/PR2818/awkward/awkward-cpp/include/awkward/io/json.h:153:31: warning: implicit conversion changes signedness: 'int64_t' (aka...

`ArrayBuilder` has only `Int64Builder`. We could extend the API to support `int32`.

I think, there is a more type friendly option to use a `LayoutBuilder`, but it currently lacks pythonization: ```c++ template using NumpyBuilder = awkward::LayoutBuilder::Numpy; ```

@essoca - Could you, please, try to change it as follows to pin the `ArrayView`: ```python array = ak.Array([[[0, 1], [2, 3]], [[4, 5]]], backend='cuda') gpu_arr_type = array.numba_type @nb.cuda.jit(types.void(gpu_arr_type), extensions=[ak.numba.cuda])...

@essoca - thanks, I can reproduce the error. It is definitely a bug! I think it is related to our way of a generated C++ `ArrayView` typing that is unique...

> Thanks @ianna. Could you be a bit more explicit about what should be done for that to work? When `array` is initially created, it has a `numba_type`, its `_numbaview`...

@essoca - I think, the PR #3115 fixes the issue. What would be your expectations if the signature type does not correspond to the array type passed to the kernel?

> Is it a new version of CuPy? (I'm assuming that Jitify is a part of CuPy, rather than a dependency, but if it's the latter: is it a new...