API limitations and bugs

Added by Paul over 4 years ago

The API offers many ways to read/write data; many of these have not been tested or tested in a very limited setting. Here are some issues that are appearing that will need to be fixed. I am listing them here since they are in the borderline of bugs and feature:

  1. When reading dataset via user vector: Should be possible to register arrays that have NaNs as segment breakers. The Import_Data section for GMT_IS_VECTOR should count how many segments, allocate the # of segments, then loop over them and assign pointers to &V→vector[start], etc. (or allocate/memcpy if GMT_IS_DUPLICATE). Similarly on output to user vector we should write the different dataset segments into a single vector with NaNs. If only one segment then no NaNs are needed. This would mirror what we are doing for the mex API.
  2. For user data registered via V, how to reuse a resource? I.e., you want to use the vector twice: Once for drawing line and once for plotting symbols. Currently, would have to register two resources. I suspect GMT_Get_ID could be told to reset the "used" flag; this would eliminate need for extra mode flags, etc.
  3. Need to experiment with how to pass some simple text strings to pstext? Via a user char matrix? We have code/case for that but this section of API is untested. The matrix would be of fixed row length and hold actual chars. Would another mode be needed where we pass a pointer to an array of strings, i.e., char *mystrings[] = {"First string", "second string", "third string"}? This would certainly be easier on the C user, no?
  4. Registering more than one resource and using them in the same program seems problematic the way the internal VIA stuff works right now. It should be possible to call psxy with files myfile.txt @GMTAPI@-000000 and @GMTAPI@-000001, i.e., a real file and two registered resources.

We basically have to extend the api test directory with more examples and these may actually be C codes that should be linked with the API and run, perhaps from regular test scripts that first call a helper-script to do the compilation since that is platform specific. I.e., for *nix in might just be

gcc -I<pathtogmtinclude> userprog.c -L<pathtogmtlib> -o userprog

but the details could be handled via a gmtusercompile.sh.in script. I am writing gmtlogo.c which will be a good test case for some of the above issues. it should not be hard to add some simple cases designed to break the api along the lines above. Before we start we should decide what is deemed a bug fix and what is a feature upgrade for 5.2

Replies (1)

RE: API limitations and bugs - Added by Paul over 1 year ago

I think most of these old concerns have been dealt with in 5.3 with the new GMT_Open_VirtualFile, etc. The fact that the GMT/MATLAB toolbox is working well shows that many of these things are fairly stable. More testing is needed though to exercise all the loose parts in the API. The Python module will add more testing as well.