I am using the libGMT API of GMT 5.4.5 to upgrade a plotting program that previously wrote out gmt 4 commands into a script, wrote data to files, and then ran that all in a subshell. As you can imagine, it was quite slow. I am trying to convert the whole thing to use libGMT modules and to build all the data structures in memory, to avoid the time penalty of hitting the disk for a lot of reads and writes.
I have almost all of it working except the pslegend command. For some reason, it draws the enclosing box, and then barfs Postscript code to STDOUT or STDERR instead of writing it to the virtual Postscript file like all the other commands did. Any ideas where I might be going wrong, or is this a known bug with the pslegend module? If so, any known workarounds?
I do not have the option of upgrading GMT; the system I am writing for is locked down (RHEL7), though in the near future we may be upgrading to RHEL8 standard. I cannot post code from the entire program, though snippets may be possible, if necessary.
Thank you for any help you can provide.
Hi Cynthia. It is great that you are using libgmt and we would love to help you. However, my comment feels a bit like cheering on someone with a broken ski and a missing pole in a race - you feel for the person and admire the effort, but know that this may not end well.
I can only comment in general terms and I understand you are not in charge of the system, but: Whoever is in charge needs to understand that locking things down and rely on very old open source distributions is asking for the impossible. There are lots of bugs in the GMT 5 API despite us fixing quite a few for GMT/MEX. Since then, the Julia and PyGMT wrappers have exposed lots of issues (that otherwise lay dormant as they are not used within GMT itself except via the external calls) and we have fixed tons of these. Because all our time and effort goes to 6.x and we have no mechanism nor desire to look at obsolete GMT 5 code, we cannot offer you any useful advice when you run into things like this. You have to use the latest version of GMT for this to be feasible. We could then offer you lots of inside help since only us developers really understand what is happening under the hood.
I understand you cannot update RHEL7 and that it only offers gmt 5.4.3, but are you not even allowed to download a tarball with the latest 6.3.0 or use git to clone the repo?
I’ll ask, but my customers are very shy of running afoul of IA (Information Assurance), especially for one program that already works, I’m just improving it. I hope that RHEL8 has a newer version of GMT.
I brute-forced the malfunctioning pslegend thing in the end: wrote out the PS file without closing it out, and used a system() call to append ‘gmt pslegend’ command output to the postscript file. It looks like the 5.4.5 gmt module for pslegend does not pass the virtual output file tag down to the subordinate commands that actually draw the legend. Hopefully this is fixed in gmt 6.x and up.
And let me add to what Paul said that it would be really lovely if would get interested in pursuing the real motive for witch those PS in’memory were created in first place. => to let the ghostscript lib make make the raster conversion all in memory and without the need to use intermediary files.
That I know off, only me had used it on Windows (oddly the piping/fork code doesn’t work on unix but do on Windows) but our piping solution is also too slow.