About gmt core syntax

Lounge
1

Hi @moderators ,

I vaguely remember mentioning it at some point but never formally asked : do futur version of GMT (7?) plan to adopt a syntax closer to other softwares ? (like latex or julia?)

This come with the whole discussion about long-name options

\begin{environment}[options]
     commands [...]
\end{environment}

-OR-

environment{options,...
    commands{options}
}

IMO the first method is cleaner and closer to what already exists, but the second seems more natural for long-names.

e.g.:

\begin{gmt}[format="png,pdf"]

    makecpt palette="rainbow" range="0,100,1" output="mycpt"
    grdfilter region="0,360/-90/90" type="median" flag="4" input="x.nc" step="10" output="y.nc"

    \begin{figure}[subplot="1,2",name="myfigure"]
        \begin{subplot}[position="1,1",size="10cm,5cm"]
            coast region="0,360/-90/90" projection="mercator" resolution="crude" clip="on"
            grdimage input="@earth_relief_03m" intensity="defaults" color="mycpt"
            coast clip="off"
        \end{subplot}
        [...]
    \end{figure}
    [...]
\end{gmt}

VS

gmt[format="png,pdf"]{
    makecpt[palette="rainbow", range="0,100,1", output="mycpt"]
    grdfilter[region="0,360/-90/90", type="median", flag="4", input="x.nc", step="10", output="y.nc"]
    
    figure[subplot="1,2",name="myfigure"]{
        subplot[position="1,1",size="10cm,5cm"]{
            coast[region="0,360/-90/90", projection="mercator", resolution="crude", clip="on"]
            grdimage[input="@earth_relief_03m", intensity="defaults", color="mycpt"]
            coast[clip="off"]
        }
        [...]
    }
    [...]
} # close GMT session

Thoughts ?

2

PreScript: I don’t need to be convinced on the need of something like this but what you propose I have no idea on how it can be implement other than from Julia, and even there …

The thing is one would need some macro language that would convert that syntax to plain shell calls to the GMT modules. No shell knows what to do with coast[... and writing such macro language is unreasonable. Again, things like the Julia PackageCompiler may, in some time, become viable alternatives to build such type of interface (based on GMT.jl ofc) but other than that, I have no idea.

3

Is it already doing that in a way ? From shell-ish to c to postscript ?

4

Sorry, who’s "already doing that in a way?"

5

GMT ? No ?

6

But GMT cannot do anything of the sort coast[... the shell would not let it. Not to mention on who would parse \begin{gmt}[...

7

Hi guys. The reality is that the wrappers is the place to make GMT very simple since they are more powerful in handling keyward/value arguments and can augment GMT with built-in computational capabilities. For the plain GMT shell command line, which must support 30 years of existing users and sripts, we will slowly evolve it toward long-format, but that means simply replacing things like -R0/5/0/5 with --region=0/5/0/5 to make it easier to understand a GMT script you did not write yourself.

It can be a fun programming exercise to declare a Latex-inspired interface like the one you proposed above and convert that syntax to GMT module calls, but my plate is already too full to add more. I hope GMT 7 will be able to deliver the long-option interface and strengthen all other aspects so that the externals can rely in it.

1 Like
8

Clearly I don’t know enough on how things are handle on the back-end side.

I would have thought the script was looking keywords so something like

coast[region="0,1/0,1",projection="mercator"]

would have become arguments like

called function : coast
#--- needed arguments : ---
region="0,1/0,1"
projection="mercator"
# --- optional arguments : ---
color=""
[...]

Candidly, I thought it is how it already works. (using similar text matching function to sort things out like awk or sed would do)

9

But that’s what GMT.jl is doing already, so what else are you looking for?

Well, very close to that

coast(region="0/1/0/1", projection="Mercator")
10

If I reformulate my original question : will GMT syntax will become close to what’s Julia’s wrapper or others are currently doing ?

That doesn’t mean that I want to use Julia to run GMT.

From @pwessel answer, I assume it is a long term objective, but not realistic due to the shear amount of work.

1 Like
12

And if by GMT syntax you mean what we type into a shell script then there would be a huge headache to escape all those special symbols like [], (), etc. So it would not look very clean anyway, hence we are limited to what the shell will let us do without complications, i.e., --keyword=value.

13

Sensible. Well, at least this way ensures backward compatibility:)

Thanks,