Skip to content

An inset bug #4757

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

Closed
seisman opened this issue Feb 6, 2021 · 8 comments
Closed

An inset bug #4757

seisman opened this issue Feb 6, 2021 · 8 comments
Labels
bug Something isn't working

Comments

@seisman
Copy link
Member

seisman commented Feb 6, 2021

Full script that generated the error

The issue was originally found in GenericMappingTools/pygmt#788

gmt begin map png
  gmt coast -Ba -Gbrown -RMG+r2 -Slightblue -Wthin
  gmt inset begin -DjTL+w3.5c+o0.2c -F+pgreen -M0
    gmt coast -EMG+gred -Ggray -JG47/-20/?c -Rg -Swhite
  gmt inset end
gmt end show

Full error message

coast [WARNING]: 1.37795i not a valid number and may not be decoded properly.
plot [WARNING]: 1.37795i not a valid number and may not be decoded properly.
inset [WARNING]: 1.37795i not a valid number and may not be decoded properly.
Actual outcome Expected outcome
image image

The red Madagascar is not incorrectly placed.

System information

  • Operating system: macOS
  • GMT version (gmt --version): 6.2.0_36c8106_2021.02.05
@seisman seisman added the bug Something isn't working label Feb 6, 2021
@seisman seisman changed the title A inset bug An inset bug Feb 6, 2021
@PaulWessel
Copy link
Member

Seems you have a hanging "c" after -JG47/-20/? which is not expected. There is no reason to append a unit to something that will be computed. So i would suggest we do this:

  1. Give error if more than ? is found, or we can be nice and just ignore anything beyond ?. Right now we replace ? with 1.37795i and you get 1.37795ic.
  2. Try to expedite the plan to eliminate the ? altogether since it is problematic for some shells, so that -JG47/-20/ is all that should be given?

For plan 2, I think it will be just as easy to find either a lone trailing / -in -J or look for the few cases where the scale or width is not the last argument (-JP I think) so that we look for //, meaning a missing argument, no?

@seisman
Copy link
Member Author

seisman commented Feb 6, 2021

Seems you have a hanging "c" after -JG47/-20/? which is not expected. There is no reason to append a unit to something that will be computed.

Yes, it makes sense.

For plan 2, I think it will be just as easy to find either a lone trailing / -in -J or look for the few cases where the scale or width is not the last argument (-JP I think) so that we look for //, meaning a missing argument, no?

We discussed this before in #3916. I'm OK with eliminating ?, but I don't like it, because I feel that 47/-20/ or 47/-20//60 is not as readable as 47/-20/? or 47/-20/?/60. Especially users may only type a single / even though the documentation uses //.

@PaulWessel
Copy link
Member

Perhaps we can make the ? optional. We have to be backwards compatible anyway. But the csh ? problem is real so need to be addressed.

@PaulWessel
Copy link
Member

So perhaps close this as not really a bug but feature?

@seisman
Copy link
Member Author

seisman commented Feb 6, 2021

Perhaps we can make the ? optional.

Yes, this would be better!

@seisman
Copy link
Member Author

seisman commented Feb 6, 2021

Closing as not a bug.

@seisman seisman closed this as completed Feb 6, 2021
@joa-quim
Copy link
Member

joa-quim commented Feb 6, 2021

Perhaps we can make the ? optional.

Don't remember how but I'm using the? in Julia generated commands.

@PaulWessel
Copy link
Member

Yep, not getting rid of it but making that optional is the goal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants