### Rationale for this change
The Arrow GDB pretty-printers do not support run-end encoded data types.
### What changes are included in this PR?
Add GDB pretty-printer support and tests for `run-end encoded` types, scalars, and arrays.
### Are these changes tested?
Yes.
### Are there any user-facing changes?
No.
* GitHub Issue: #50658
Authored-by: fenfeng9 <fenfeng9@qq.com>
Signed-off-by: Antoine Pitrou <antoine@python.org>
### Rationale for this change
The Arrow GDB pretty-printers support `Decimal128` and `Decimal256`, but do not support `Decimal32` or `Decimal64`.
### What changes are included in this PR?
* Add GDB pretty-printer support and tests for `Decimal32` and `Decimal64`.
* Remove the unused `max_type_id` variable.
### Are these changes tested?
Yes.
### Are there any user-facing changes?
No.
* GitHub Issue: #50660
Authored-by: fenfeng9 <fenfeng9@qq.com>
Signed-off-by: Antoine Pitrou <antoine@python.org>
### Rationale for this change
`gdb_arrow.py` mirrors the C++ `arrow::Type::type` enum by position, but it is missing several newer type IDs.
The upcoming pretty-printer sub-issues(https://github.com/apache/arrow/issues/50656) share this dependency.
### What changes are included in this PR?
Adds the missing `RunEndEncoded, BinaryView, ListView, and Decimal32/64` type IDs in the same order as the C++ enum.
Individual pretty-printer support will be implemented separately.
### Are these changes tested?
### Are there any user-facing changes?
No.
* GitHub Issue: #50680
Authored-by: fenfeng9 <fenfeng9@qq.com>
Signed-off-by: Antoine Pitrou <antoine@python.org>
### Rationale for this change
`test_gdb.py` would fail on 32-bit platforms because the gdb extension errors out when a timestamp value is larger than the platform's time_t.
### What changes are included in this PR?
1. Catch `OverflowError` from the Python datetime module when trying to format a timestamp
2. Tweak the expected test results on 32-bit
### Are these changes tested?
Yes.
### Are there any user-facing changes?
No.
* GitHub Issue: #40153
Authored-by: Antoine Pitrou <antoine@python.org>
Signed-off-by: Antoine Pitrou <antoine@python.org>
### Rationale for this change
Support showing metadata of nested DataType which have child fields.
### What changes are included in this PR?
Add an optional argument "show_metadata" to the ToString() of DataType and other DataType derived class. And we also add it to TypeHolder::ToString().
### Are these changes tested?
Yes, I add tests for changes.
### Are there any user-facing changes?
No.
Closes: #39864
* Closes: #39864
Lead-authored-by: xiansen.chen <xiansen.chen@openpie.com>
Co-authored-by: Antoine Pitrou <antoine@python.org>
Signed-off-by: Antoine Pitrou <antoine@python.org>
This was a pretty painful refactoring project, but all for the better long term.
I will do my best to improve the PR summary to explain changes as I go through the PR myself, but the basic summary is that argument shape is no longer part of kernel signatures (or expressions or anything else) -- the "all scalar" evaluation case is handled by promoting scalars to ArraySpan of length 1. This enabled the deletion of many "duplicate" kernel implementations and uncovered some bugs in some kernel implementations as a result of passing many sliced length-1 inputs up-promoted from scalars.
This had painful knock-on effects because some scalar values -- sparse unions and some other non-primitive types -- were not "well-formed" enough to be able to be converted to ArraySpan without needing to allocate memory. As a result, I had to change the requirements (and in the case of sparse unions, the representation to correspond to a "single row view" of a SparseUnionArray -- i.e. the "value" for a sparse union is now a vector of scalars rather than a single scalar, even though only one of the values in the vector is the "active" scalar) of some scalar values to not allow null values. We should / could consider implementing scalars altogether internally as arrays of length 1 but we can discuss that as a follow up.
Some other interesting stuff in here is the new experimental `arrow::TypeHolder` struct which allows us to pass around either `const DataType*` or `std::shared_ptr<DataType>` in contexts where type ownership isn't strictly necessary. So now we can deal only with raw pointers when doing type signature checking / kernel dispatching, for example. We should look at refactoring other code where we deal with `shared_ptr<DataType>` (but don't necessarily need to preserve ownership) to use TypeHolder.
There's some unfinished business here:
* The GLib bindings must be refactored to follow this work
Lead-authored-by: Wes McKinney <wesm@apache.org>
Co-authored-by: Sutou Kouhei <kou@clear-code.com>
Signed-off-by: Wes McKinney <wesm@apache.org>
Expressions evaluated by GDB are evaluated in the scope of the C++ namespace of the currently selected frame.
Therefore, when inside a Parquet frame, `arrow::<some type>` would be looked up as `parquet::arrow::<some type>` and fail.
Closes#12434 from pitrou/ARROW-15652-gdb-parquet
Authored-by: Antoine Pitrou <antoine@python.org>
Signed-off-by: Antoine Pitrou <antoine@python.org>
When printing a arrow::Array or arrow::ArrayData, try to print the array contents as well as its metadata.
This is implemented for all primitive and binary-like types.
Other types will only display the array metadata.
Example:
```
(gdb) p *heap_binary_array.get()
$23 = arrow::BinaryArray of length 3, offset 0, null count 1 = {[0] = null, [1] = "abcd", [2] = "\000\037\377"}
```
Closes#12315 from pitrou/ARROW-15389-gdb-array-preview
Authored-by: Antoine Pitrou <antoine@python.org>
Signed-off-by: David Li <li.davidm96@gmail.com>
When auto-loaded, a GDB plugin should attach itself to the specific objfile being debugged.
This allows for potentially multiple inferiors being debugged at once, using different versions of Arrow C++.
Closes#12236 from pitrou/ARROW-15423-gdb-auto-load
Authored-by: Antoine Pitrou <antoine@python.org>
Signed-off-by: Sutou Kouhei <kou@clear-code.com>
fenfeng9