Conversation
|
Wouldn't this be reverting #490? But |
|
Yes, it's a little complicated. See GenericMappingTools/gmt#3528 for the long discussions. Please let me know if it's still unclear to you. |
|
Yeah, it looks complicated. The discussion looks to be focused on vectors, I'm not quite sure how grids are dealt with.
|
They're all handled in the same way. I'll try to write a short summary for this. External programs like PyGMT can pass any data (vector, matrix, grid) to GMT API. It's safe if GMT only read the memory, but sometimes GMT also changes the memory or even free them. That's why we have so many crashes with GMT 6.0. For any input data, we can add a modifier to
Actually, when |
|
Using |
I don't know, I'd actually prefer to find bugs in GMT 😆. On a more serious note, if we're duplicating memory, then we might as well write the data to file and pass that into PyGMT. There should be a smarter way to handle this. |
Sorry, I don't understand what you mean here. Could you explain it a little more? |
|
Sorry, what I mean is that one of PyGMT's core features is being able to pass in PyData data structures (e.g. numpy, pandas, xarray) directly into GMT, that is, without going through the pain of writing it to a .txt, .csv or .nc file. I know that |
|
That, said, we were using |
Are you sure Line 1248 in 216f5d2 When using If I switch to using |
That's based on my understanding of What Paul said in GenericMappingTools/gmt#3528. |




Description of proposed changes
Changing
GMT_IN|GMT_IS_REFERENCEtoGMT_INwhen passing data to GMT, to find more potential bugs in GMT.Fixes #
Reminders
make formatandmake checkto make sure the code follows the style guide.doc/api/index.rst.