Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running info on vector memory inputs return UNIX timestamps instead of ISO datetimes #4241

Closed
weiji14 opened this issue Sep 20, 2020 · 48 comments
Assignees

Comments

@weiji14
Copy link
Member

weiji14 commented Sep 20, 2020

Description of the problem

UNIX timestamps (e.g. 1577836800) are returned instead of ISO datetimes (e.g. 2020-01-01T00:00:00) when running info on virtual tables. Originally noticed at GenericMappingTools/pygmt#619 (comment), check also #3396 where datetime inputs were originally accepted into GMT_Put_Vector.

Full script that generated the error

Sorry that I can't write C code, but given an input like so:

z time
10 2020-01-01T00:00:00
13 2020-01-02T00:00:00
12 2020-01-03T00:00:00
15 2020-01-04T00:00:00
14 2020-01-05T00:00:00

and then running info from PyGMT from the branch at GenericMappingTools/pygmt#619 (each column is passed into C API using GMT_Put_Vector)

import pygmt

# create data array 'table' and pass it into `info`
pygmt.info(table=table, V="d")

Full error message

gmtinfo [INFORMATION]: Processing input table data
gmtinfo [DEBUG]: gmtapi_init_import: Passed family = Data Table and geometry = Point|Line|Poly
gmtinfo (gmtapi_init_import): tried to free unallocated memory
gmtinfo [DEBUG]: gmtapi_init_import: Added 1 new sources
gmtinfo [DEBUG]: GMT_Init_IO: Returned first Input object ID = 0
gmtinfo [DEBUG]: gmtapi_init_export: Passed family = Data Table and geometry = Point|Line|Poly
gmtinfo [DEBUG]: Object ID 1 : Registered Data Table File /tmp/pygmt-gykf5n3t.txt as an Output resource with geometry Point|Line|Poly [n_objects = 2]
gmtinfo [DEBUG]: gmtapi_init_export: Added 1 new destination
gmtinfo [DEBUG]: GMT_Init_IO: Returned first Output object ID = 1
gmtinfo [DEBUG]: GMT_Begin_IO: Mode value 1 not considered (ignored)
gmtinfo [DEBUG]: GMT_Begin_IO: Initialize record-by-record access for Input
gmtinfo [DEBUG]: gmtapi_next_io_source: Selected object 0
gmtinfo [INFORMATION]: Reading Data Table from Input memory location via vector
gmtinfo [DEBUG]: GMT_Begin_IO: Input resource access is now enabled [record-by-record]
gmtinfo [DEBUG]: GMT_Begin_IO: Initialize record-by-record access for Output
gmtinfo [DEBUG]: gmtapi_next_io_source: Selected object 1
gmtinfo [INFORMATION]: Writing Data Table to file /tmp/pygmt-gykf5n3t.txt
gmtinfo [DEBUG]: GMT_Begin_IO: Output resource access is now enabled [record-by-record]
gmtinfo [DEBUG]: Number of numerical output columns has been set to 0
gmtinfo [DEBUG]: GMT_End_IO: Input resource access is now disabled
gmtinfo [DEBUG]: GMT_End_IO: Output resource access is now disabled
gmtinfo (GMT_gmtinfo): tried to free unallocated memory
gmtinfo (GMT_gmtinfo): tried to free unallocated memory
gmtinfo [DEBUG]: gmtlib_unregister_io: Unregistering object no 1 [n_objects = 1]
gmtinfo (gmtlib_free_tmp_arrays): tried to free unallocated memory

Actual outcome

<vector memory>: N = 5 <10/15> <1577836800/1578182400>

Expected outcome

<vector memory>: N = 5 <10/15> <2020-01-01T00:00:00/2020-01-05T00:00:00>

System information

  • Operating system: Linux
  • GMT version (gmt --version): 6.1.1
@PaulWessel
Copy link
Member

Hm, yes since what is returned is a text record I agree there is no good reason it should not be formatted as you expect here. If -C was used then you would get a numerical record and it would have UNIX time of course, but here it is text. I will try to have a look as to why it is not doing the formatting.

@PaulWessel
Copy link
Member

I would like to add another section to the DEVELOPER RESOURCES sidebar on debugging, for how to debug pyGMT via Xcode on macOS. Been a month since last time and cannot find all the step that @seisman helped with. Since I am a complete python rookie there is not much mental memory on even the most basics, so I need that recipe, which also had some issues with setting shared-dir and possibly library paths for all to work. Maybe @seisman could resurrect his instructions and I can turn it into a section in the developer RST?

@PaulWessel
Copy link
Member

And @joa-quim has given similar instructions for setting up GMT.jl so I can debug cases he finds directly in Xcode as well?

@weiji14
Copy link
Member Author

weiji14 commented Sep 20, 2020

I would like to add another section to the DEVELOPER RESOURCES sidebar on debugging, for how to debug pyGMT via Xcode on macOS. Been a month since last time and cannot find all the step that @seisman helped with. Since I am a complete python rookie there is not much mental memory on even the most basics, so I need that recipe, which also had some issues with setting shared-dir and possibly library paths for all to work. Maybe @seisman could resurrect his instructions and I can turn it into a section in the developer RST?

Issue is at #3778. I should probably start to learn C too at some point 😆

@seisman
Copy link
Member

seisman commented Sep 20, 2020

The steps to debug PyGMT via Xcode was discussed in #3829.

Here is a summary:

  1. Install PyGMT following the official instructions
# add conda-forge channel
conda config --prepend channels conda-forge
# NOTE: the next step is different from the PyGMT official instructions, because we want to use the GMT dev version
conda create --name pygmt python=3.8 pip numpy pandas xarray netcdf4 packaging
# activate the pygmt envirionment
conda activate pygmt

# install pygmt in editable/development mode
cd pygmt
make install
  1. Compile GMT using Xcode
  2. Tell PyGMT where to find the GMT library by setting the environmental variable GMT_LIBRARY_PATH
export GMT_LIBRARY_PATH=~/Gits/gmt/gmt/build/xcode/src/Debug
  1. Open Xcode
  2. Run a python console, attach the process id in xcode, and run PyGMT codes in the Python console and xcode will stop at the breakpoint.

@joa-quim
Copy link
Member

joa-quim commented Sep 20, 2020

Issue is at #3778. I should probably start to learn C too at some point

Please, please join the Force.

Debugging from any of the environments (Matlab, Julia, Python) should all the same procedure.

  1. Open the shell (ML IDE, Julia or Py REPL), type the command that will trigger the program to debug, but HOLD ON
  2. Open the debugger an Attach to process (this is VS talk, Xcode does similar but on its own way). The process is either the Matlab running process or Julia, Py shells.
  3. Open the source code of the program to be debugged ans set break points.
  4. Go back to 1. and hit RETURN

@seisman
Copy link
Member

seisman commented Sep 20, 2020

@weiji14 Perhaps we should merge GenericMappingTools/pygmt#619 first (mark the tests as xfail) and provide a minimal Python script to reproduce the issue. Your example above is incomplete, and @PaulWessel will need to rewrite a working script before debugging.

@joa-quim
Copy link
Member

Ofc, on Unix everything is more complicated 😈

@weiji14
Copy link
Member Author

weiji14 commented Sep 20, 2020

Please, please join the Force.

http://www.nooooooooooooooo.com/

Ofc, on Unix everything is more complicated 😈

Yeah, I'm on Linux which doesn't seem to have Xcode 🤷

@weiji14 Perhaps we should merge GenericMappingTools/pygmt#619 first (mark the tests as xfail) and provide a minimal Python script to reproduce the issue. Your example above is incomplete, and @PaulWessel will need to rewrite a working script before debugging.

Yep, give me a few minutes to finish up that PR.

@PaulWessel
Copy link
Member

Yes, it would be great if a snipped of Python code demonstrating the problem is submitted since that is not something I will know how to do. Same with Julia of course and @joa-quim usually posts a Julia command or mex command. We just want to lower the threshold for all of us to do these things. Even C-novices should be able to step in the the C library and at least detect where a crash happens - often that is enough of a clue for the C-team to figure things out.

@joa-quim
Copy link
Member

joa-quim commented Sep 20, 2020

Good question for Linux. I guess that gcc should have an equivalent mechanism to Attach to process ID and from that on, the doing should be the same ... except that using gdb is an act of masochism.

@PaulWessel
Copy link
Member

On Linux, I have done lots of debugging using ddd, and even on macOS before Apple switched to clang and it became a bit harder (and I have not paid too much attention). But I dont know if you can connect to the process in ddd the same way we do in Xcode or Visual Studio.

@PaulWessel
Copy link
Member

ddd is just a graphical front-end to gdb which I assume can connect to other processes.

@PaulWessel
Copy link
Member

@joa-quim, do you mind posting the usual setup for a newbie to install GMT.jl from the developer version, including installing julia. I know you have some of that on your site but it would help me put the docs together if you can (like @seisman) cut/paste in here while I am thinking about this.

@weiji14
Copy link
Member Author

weiji14 commented Sep 21, 2020

Ok, GenericMappingTools/pygmt#619 has been merged, and I'm starting to have a go at debugging using gdbgui (installed via pip install gdbgui). Will see if I can figure this out. Below is the Python code to run after following PyGMT installation instructions (pip install https://github.com/GenericMappingTools/pygmt/archive/master.zip), and launching Python:

import pygmt
import pandas as pd

table = pd.DataFrame(
    data={
        "z": [10, 13, 12, 15, 14],
        "time": pd.date_range(start="2020-01-01", periods=5),
    }
)
output = pygmt.info(table=table, V="d")
print(output)
# <vector memory>: N = 5 <10/15> <1577836800/1578182400>

@PaulWessel
Copy link
Member

Hi @seisman, since I have done these before and have a pygmt directory:

# add conda-forge channel
conda config --prepend channels conda-forge
# NOTE: the next step is different from the PyGMT official instructions, because we want to use the GMT dev version
conda create --name pygmt python=3.8 pip numpy pandas xarray netcdf4 packaging
# activate the pygmt envirionment
conda activate pygmt

is there a simpler step now to just pull new pygmt and then proceed to the make install step?

@seisman
Copy link
Member

seisman commented Sep 21, 2020

is there a simpler step now to just pull new pygmt and then proceed to the make install step?

Just run the following commands to update your local pygmt:

cd pygmt 
git pull

you even don't need to install pygmt again.

then open a Python console, and type:

import pygmt
pygmt.show_versions()

@PaulWessel
Copy link
Member

As for GMT/MEX there are some quirks we need to figure out and probably improve (this is for macOS - for Windows I think it is simpler because @joa-quim sticks the mex builds in with the main GMT - and these are also in the official installer). Below. xbuild is the top of my build directory with Xcode:

  • It currently requires gmtmex to be built with xcode so we can get an entry. This requires a GMT xcode workspace, like GMT.xcodeproj built by Cmake. It tried to make something like that manually for Matlab and Octave by hacking GMT.xcodeproj but that is not simple and Xcode changes a lot.
  • The configuration sets paths to include files and libraries etc, but gmt-config does not know how to handle things from an xcode build dir. As far as I can tell, none of the static *.h files are copied over, and only the *.h deriving from *.h.in are configured under xbuild/src. However, gmt-config expects things to be under xbuild/src/gmt but nothing there. So the normal gmt-config --incudedir etc does not work. That means manually configuring stuff on the gmtmex side.
  • Because of this, what I usually do is build gmtmex with xcode, but link with a regular GMT debug (not xcode) build directory which has all the needed files that gmt-config looks for.

I can think of a few options for this mess:

  1. Include gmtmex.c and gmtmex_parser.[ch] in the main GMT repo since they are C codes that must be compiled. This would let us set a stop point in the gmtmex.c program which is called by gmt.m from matlab.
  2. Only build these if the builder has set some info (MATLAB, other flags) in CmakeConfigAdvanced.cmake
  3. Note sure, but perhaps gmtmex only retains the Matlab *.m files and tests with building happening in the GMT tree.
  4. Perhaps this would simplify the release of the GMT bundle if we included things here as well. As a few of you know, it is hard to get the macOS gmtmex distribution to find the right libraries (e.g., netcdf, hdf) since MATLAB also ship these and when libgmt calls netcdf calling hdf we go boom in the wrong lib which is much older than ours). The share/tools/gmt_prepmex.sh has all the sordid details.

Maybe gmtmex should be a supplement of GMT, @seisman and @joa-quim ?

@PaulWessel
Copy link
Member

you even don't need to install pygmt again.

then open a Python console, and type:

import pygmt
pygmt.show_versions()

Must be a missing step:

cd pygmt
git pull [lots of updates]
make install 
pip install --no-deps -e .
Obtaining file:///Users/pwessel/GMTdev/pygmt
Installing collected packages: pygmt
  Attempting uninstall: pygmt
    Found existing installation: pygmt 0.1.2+30.gbe75223
    Uninstalling pygmt-0.1.2+30.gbe75223:
      Successfully uninstalled pygmt-0.1.2+30.gbe75223
  Running setup.py develop for pygmt
Successfully installed pygmt
(base) pwessel@macnut:~/GMTdev/pygmt-> export GMT_LIBRARY_PATH=/Users/pwessel/GMTdev/gmt-dev/xbuild/src/Debug
(base) pwessel@macnut:~/GMTdev/pygmt-> python
Python 3.8.3 (default, May 19 2020, 13:54:14) 
[Clang 10.0.0 ] :: Anaconda, Inc. on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pygmt
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/pwessel/GMTdev/pygmt/pygmt/__init__.py", line 15, in <module>
    from .session_management import begin as _begin, end as _end
  File "/Users/pwessel/GMTdev/pygmt/pygmt/session_management.py", line 4, in <module>
    from .clib import Session
  File "/Users/pwessel/GMTdev/pygmt/pygmt/clib/__init__.py", line 8, in <module>
    from .session import Session
  File "/Users/pwessel/GMTdev/pygmt/pygmt/clib/session.py", line 10, in <module>
    from packaging.version import Version
ModuleNotFoundError: No module named 'packaging'

@weiji14
Copy link
Member Author

weiji14 commented Sep 21, 2020

Hmm, can you try pip install packaging (in the command-line) to get the missing dependency? Do the same for other packages if it still complains.

@PaulWessel
Copy link
Member

Thanks that works. I forgot I have miniconda so presumably there is a difference in the install vs full conda. Yet, this used to run a month ago...

@PaulWessel
Copy link
Member

Can now recreate your case and have it stop in the C in Xcode again. But pushing my bedtime...

@weiji14
Copy link
Member Author

weiji14 commented Sep 21, 2020

No hurry, can do it tomorrow 😉

@PaulWessel
Copy link
Member

OK, so quick to figure out why this happens: Some modules read an entire dataset into memory (e.g., gmtconvert) while others read record-by-record (gmtinfo). The dataset-readers are carefully scanning the first record and would figure out what data type is in each column (in the case you did not use -f). Here, there is no such scanning and there is no -f1T passed to gmt info to tell it to expect absolute time in col 1. If I add f="1T" then I get

': N = 5 <10/15> <2020-01-01T00:00:00/2020-01-05T00:00:00>\n'

but also some memory WARNINGS from the lib since I compile with a MEM_DEBUG setting.

That some modules requires -f and others can figure out is an inconsistency we should work on to fix.

@joa-quim
Copy link
Member

do you mind posting the usual setup for a newbie to install GMT.jl from the developer version,

You mean the master version?

Installing GMT.jl is pretty simple

  1. Install Julia from https://julialang.org/
  2. In the Julia console type ] add GMT

Note, the ] changes the prompt to the pkg> mode, and the add GMT installs the last registered version. If one wants to go to the developing version we must install the master version. That is achieved with add GMT#master. Just not sure on how to come back to a registered version without removing ] rm GMT and installing again (with no #master).

@PaulWessel
Copy link
Member

I think we install julia via brew and port so more like port install julia I think. I am writing for macOS first. I would only care about master. Developers will only look for bugs in master anyway. Even you probably just use master most of the time. OK, so typing GMT#master. Any need to set path to the Xcode GMT library probably?

@PaulWessel
Copy link
Member

@joa-quim I cannot do

julia> push!(Libdl.DL_LOAD_PATH, "$GMT_LIBRARY_PATH")

Can I use a shell variable in this command? It works with copy/paste of the actual path of course.

@joa-quim
Copy link
Member

Ah, you are talking about GMT master, not GMT.jl master. GMT.jl doesn't care about that. It uses whatever the system tells gmt --show-library, but for debugging in Mac you need to set the env variable GMT_LIBRARY pointing to the debug lib. Note that's not the LIB_PATH but the dylib itself.

In Julia you can run shell commands using the syntax run(`the command`) but that's not what you need here.

@PaulWessel
Copy link
Member

OK, so for Julia I can set things like export GMT_LIBRARY=/Users/pwessel/GMTdev/gmt-dev/xbuild/src/Debug/libgmt.dylib while for PyGMT I must set export GMT_LIBRARY_PATH=/Users/pwessel/GMTdev/gmt-dev/xbuild/src/Debug instead. Would be nice if it was the same, but not big deal.

Yes, I was coming at this from the C side, so we want to use GMT master of course. As or GMT.jl master or not, will need your input on that, but presumably you dont want bug reports for older GMT.jl? So OK to use GMT#master for this?

@seisman
Copy link
Member

seisman commented Sep 21, 2020

I think that could be possible if pygmt used the equivalent of
string(chop(read(`gmt --show-library`, String)))
As a bonus it would probably release the need of setting a GMT_LIBRARY_PATH

PyGMT is trying its best to avoid system calls, but gmt --show-library sounds a good idea to me. I'll open a PyGMT issue for more discussions.

@PaulWessel
Copy link
Member

PaulWessel commented Sep 21, 2020

So not out of the woods with Julia. I made sure I rebuilt the xcode libgmt. I have the new Xcode 12.0, released a few days ago. I follow the recipe of attaching to julia etc. Running one of Joaquim's examples (using GMT, then a few calcs, then a call to coast) takes me to the stop point I have set in the API in GMT_Call_Module. But there is sits, and I cannot examine any variables nor can I click step to get into the function. So unable to debug. I have done this before with an earlier Xcode so the recipe should work, but maybe 12.0 has a glitch. Yet, the PyGMT debug seemed to work. I do not know what the issue might be though. Update: Works with PyGMT.

@joa-quim
Copy link
Member

Funny, since sometime now I notice that in VS when I try to access the call stack it hangs for a while (and processors are working hard doing no-shit), but then after that while things resume to work fine. This happens only if I try to access the stack, otherwise all works fine.

@PaulWessel
Copy link
Member

Yes, so gets to break point but the little console window in Xcode that shows the stack variables just has a spinning thingy indicating it is working hard. I will let it sit but this is not just a few seconds - I don't think it will finish. So clicking step in wont work because it is "busy". Notice all the things listed under the Thread in the side-bar. I dont remember all that before.

xcode

@PaulWessel
Copy link
Member

So I cannot get out of this spin cycle and thus cannot debug Julia anymore. Not cool.

@PaulWessel
Copy link
Member

Will try Xcode 11.7. Only 7.5 Gb zip to download and expand, etc..

@PaulWessel
Copy link
Member

Xcode 11.7 works so will make a note in the debug notes.

@joa-quim
Copy link
Member

Good, but damn it.

@PaulWessel
Copy link
Member

I think the initial issue here got buried in debugging discussion. Hi @weiji14, please confirm that this is still a problem..

@weiji14
Copy link
Member Author

weiji14 commented Oct 25, 2020

Yes, still a problem on GMT master. Had to silence the error messages two days ago at GenericMappingTools/pygmt#668 as it was getting annoying.

@stale
Copy link

stale bot commented Jan 23, 2021

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions.

@stale stale bot added the stale This will not be worked on label Jan 23, 2021
@stale stale bot closed this as completed Feb 2, 2021
@seisman seisman reopened this Feb 2, 2021
@maxrjones maxrjones self-assigned this Feb 11, 2021
@stale stale bot removed the stale This will not be worked on label Feb 11, 2021
weiji14 added a commit to GenericMappingTools/pygmt that referenced this issue Feb 24, 2021
Fixes problem with pygmt.info not being able to handle datetime64 inputs.
I.e. `ValueError: could not convert string to float: '2021-01-01T12:34:56'`
However, users will still need to use`pygmt.info(..., f="0T")` until
upstream issue at GenericMappingTools/gmt#4241
is resolved. Also added two extra unit tests using numpy datetime64 types.
weiji14 added a commit to GenericMappingTools/pygmt that referenced this issue Mar 3, 2021
Fixes problem with pygmt.info not being able to handle datetime64 inputs.
I.e. `ValueError: could not convert string to float: '2021-01-01T12:34:56'`
However, users will still need to use`pygmt.info(..., coltypes="0T")` until
upstream issue at GenericMappingTools/gmt#4241
is resolved. Also added two extra unit tests using numpy datetime64 types.

* Use common alias coltypes (f) in tests and make a note on the workaround
@maxrjones
Copy link
Member

@weiji14 the output appears as you wanted it - is this because of workarounds implemented in PyGMT? Would you be able to provide an example that still demonstrates the bug for debugging purposes?

import pygmt
import pandas as pd

table = pd.DataFrame(
    data={
        "z": [10, 13, 12, 15, 14],
        "time": pd.date_range(start="2020-01-01", periods=5),
    }
)
output = pygmt.info(table=table, V="d")
print(output)

#<vector memory>: N = 5 <10/15> <2020-01-01T00:00:00/2020-01-05T00:00:00>

@weiji14
Copy link
Member Author

weiji14 commented Mar 14, 2021

Hmm, you might be right! I see that the these two units tests at https://github.com/GenericMappingTools/pygmt/blob/v0.3.1/pygmt/tests/test_info.py#L67-L107 are passing on GMT master (i.e. 6.2.0) now at the GMT Latest tests (https://github.com/GenericMappingTools/pygmt/runs/2104362367?check_suite_focus=true#step:14:324). Not sure when this got fixed 😅

Just to double check, could you try this example out (passing in only one datetime column from a numpy array).

import pandas as pd
import pygmt

table = pd.date_range(start="2020-01-01", periods=5).to_numpy()
output = pygmt.info(table=table, per_column=True, V="d")
print(output)
# ['2020-01-01T00:00:00' '2020-01-05T00:00:00']

@maxrjones
Copy link
Member

Hmm, you might be right! I see that the these two units tests at https://github.com/GenericMappingTools/pygmt/blob/v0.3.1/pygmt/tests/test_info.py#L67-L107 are passing on GMT master (i.e. 6.2.0) now at the GMT Latest tests (https://github.com/GenericMappingTools/pygmt/runs/2104362367?check_suite_focus=true#step:14:324). Not sure when this got fixed 😅

Just to double check, could you try this example out (passing in only one datetime column from a numpy array).

import pandas as pd
import pygmt

table = pd.date_range(start="2020-01-01", periods=5).to_numpy()
output = pygmt.info(table=table, per_column=True, V="d")
print(output)
# ['2020-01-01T00:00:00' '2020-01-05T00:00:00']

Output looks good, I think:

gmtinfo [INFORMATION]: Processing input table data
gmtinfo [DEBUG]: gmtapi_init_import: Passed family = Data Table and geometry = Point|Line|Poly
gmtinfo [DEBUG]: gmtapi_init_import: Added 1 new sources
gmtinfo [DEBUG]: GMT_Init_IO: Returned first Input object ID = 0
gmtinfo [DEBUG]: gmtapi_init_export: Passed family = Data Table and geometry = Point|Line|Poly
gmtinfo [DEBUG]: Object ID 1 : Registered Data Table File /var/folders/48/71lnqfxj77j8wrw6k0rtklv00000gq/T/pygmt-57pz3p76.txt as an Output resource with geometry Point|Line|Poly [n_objects = 2]
gmtinfo [DEBUG]: gmtapi_init_export: Added 1 new destination
gmtinfo [DEBUG]: GMT_Init_IO: Returned first Output object ID = 1
gmtinfo [DEBUG]: GMT_Begin_IO: Mode value 1 not considered (ignored)
gmtinfo [DEBUG]: GMT_Begin_IO: Initialize record-by-record access for Input
gmtinfo [DEBUG]: gmtapi_next_io_source: Selected object 0
gmtinfo [INFORMATION]: Reading Data Table from Input memory location via vector
gmtinfo [DEBUG]: GMT_Begin_IO: Input resource access is now enabled [record-by-record]
gmtinfo [DEBUG]: GMT_Begin_IO: Initialize record-by-record access for Output
gmtinfo [DEBUG]: gmtapi_next_io_source: Selected object 1
gmtinfo [INFORMATION]: Writing Data Table to file /var/folders/48/71lnqfxj77j8wrw6k0rtklv00000gq/T/pygmt-57pz3p76.txt
gmtinfo [DEBUG]: GMT_Begin_IO: Output resource access is now enabled [record-by-record]
gmtinfo [DEBUG]: GMT_End_IO: Input resource access is now disabled
gmtinfo [DEBUG]: GMT_End_IO: Output resource access is now disabled
==> 2 API Objects at end of GMTAPI_Garbage_Collection entry
--------------------------------------------------------
K.. ID RESOURCE.... FAMILY.... ACTUAL.... DIR... S O M L
--------------------------------------------------------
* 0  0 7fb7aa6283a0 Data Table Vector     Input  2 Y N 0
* 1  1            0 Data Table Data Table Output 2 Y N 1
--------------------------------------------------------
gmtinfo [DEBUG]: gmtlib_unregister_io: Unregistering object no 1 [n_objects = 1]
==> 1 API Objects at end of GMTAPI_Garbage_Collection exit
--------------------------------------------------------
K.. ID RESOURCE.... FAMILY.... ACTUAL.... DIR... S O M L
--------------------------------------------------------
* 0  0 7fb7aa6283a0 Data Table Vector     Input  2 Y N 0
--------------------------------------------------------
['2020-01-01T00:00:00' '2020-01-05T00:00:00']

@weiji14
Copy link
Member Author

weiji14 commented Mar 14, 2021

Nice, I'll close this issue then and wait for GMT 6.2.0 to be released. Thanks everyone!

@weiji14 weiji14 closed this as completed Mar 14, 2021
@maxrjones
Copy link
Member

Fixed by #4849

sixy6e pushed a commit to sixy6e/pygmt that referenced this issue Dec 21, 2022
…appingTools#960)

Fixes problem with pygmt.info not being able to handle datetime64 inputs.
I.e. `ValueError: could not convert string to float: '2021-01-01T12:34:56'`
However, users will still need to use`pygmt.info(..., coltypes="0T")` until
upstream issue at GenericMappingTools/gmt#4241
is resolved. Also added two extra unit tests using numpy datetime64 types.

* Use common alias coltypes (f) in tests and make a note on the workaround
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants