Rewrite how -i works internally for external sources#5392
Conversation
Easier to have a simple test here than trace general cases in externals.
|
The previous broken cases now work well with this branch. |
|
Thanks, taking of WIP. The old fix was a wack-a-mole fix. Fixed one thing and broke another. No way to fix both without this rewrite. Once tested with PyGMT and approved I will merge and then work on similar upgrades for a few other places in the API where this appears, and it may likely lead to improvements such as doing -o2,1,2,2 etc being allowed. |
|
Thanks. And at the end we'll need another release. |
|
OK, will look at this later - have some errands that need to be done first... |
|
Should be OK now, @seisman. |
|
Now all PyGMT tests pass. |
|
@PaulWessel , you mentioned "Only testing matrices and vectors here as testing datasets revealed some unrelated issues that will be dealt with later". I'm debugging GenericMappingTools/pygmt#1440 and find that the Lines 3932 to 3940 in b33d6d8 is incorrect. Do you know if this is related to the known issues for for |
|
No, please continue, and let me know if you need help. |


Description of proposed changes
There were several conceptual issues with how we had implemented -i when reading from matrices and vectors (and datasets) from memory. This has now been fixed (I hope) and we are now using a procedure more like this:
Thus, the
colis just a dummy loop variable and the in/out-cols can be independent from that.col_pos_outcovers the same values that col does, but not necessarily in any particular order, andcol_pos_inmay go outside that range and even have repeats. I added a new test program (testapi_columns.c) driven by test script apicolumns_icol.sh, which passes. Note: Only testing matrices and vectors here as testing datasets revealed some unrelated issues that will be dealt with later.Keeping this at WIP to see if it fixes recent trouble related to external tables in PyGMT (@seisman) and GMT.jl (@joa-quim).