Config branch...

[ldecicco-USGS]

I had been using the dev.off to fix the bleeding par, but that had an unintended consequence when kniting. This PR instead goes back to the original scheme where we'd save the original par in the gsconfig, then reset all of those pars if someone changes the config (either with loadConfig or in the call to the gsplot object). This somewhat alters all the figures because now the background tends to be translucent instead of white. I actually think that's better, but would like to hear more discussion.

[coveralls]

Coverage decreased (-0.4%) to 79.102% when pulling c287996dfc2d4b3188234485d3f44a27cee5821c on ldecicco-USGS:configBranch into bc8f472e74f4a7173d1a4ca2c7d45a0e0c09e287 on USGS-R:master.

[coveralls]

Coverage decreased (-0.5%) to 79.034% when pulling 272cede746d08bd5539a56a88b7ca067bbf145e4 on ldecicco-USGS:configBranch into bc8f472e74f4a7173d1a4ca2c7d45a0e0c09e287 on USGS-R:master.

[coveralls]

Coverage increased (+0.1%) to 79.638% when pulling bbfc10f70158446c8779471cbb4ed9370db01ed2 on ldecicco-USGS:configBranch into bc8f472e74f4a7173d1a4ca2c7d45a0e0c09e287 on USGS-R:master.

[lindsayplatt]

@ldecicco-USGS I'm on your branch (and built/reloaded), but this is still causing an issue. It's like the way legend handles par is messing it up because it looks ok when I exclude legend.name. However, not sure why the axis() call is being ignored for changing side.2$lim.

g1 <- gsplot() %>% 
  lines(1:9, seq(1,3, by=0.25), 
        legend.name="second line") %>% 

  # formatting y axes
  axis(side=2, at=1:10) 

layout(matrix(1:2, 1, 2))
g1
g1

[ldecicco-USGS]

I did not test out my branch at all with layout...I'm not sure what happens with par there.

I totally agree that legend is mucking up nice par behaviors. I've noticed this in the past too. It's the only function that directly changes par, and then unchanges it back at the end. I'm guessing that's the root of the problem.

I'm guessing what you are seeing there is something I've been concerned about for a little while now. Because we are changing par in the building up of the gsplot object....it's possible to get 2 different printed outputs using the same object if par gets changed from one print to the next. I'm guessing that's what's going on here. I'd have to explore what layout does with par to know what's going on here and how we'd want to deal with it in the longer term.

[lindsayplatt]

It happens when you just print the plot twice in a row as well, layout was just easier to show them side by side

[lindsayplatt]

It only changes par when draw_legend is called, which doesn't happen here because I never have the legend drawn. I only added legend.name, but never used legend(). So I think something else is at play here

[lindsayplatt]

Actually, calling legend() just made that issue stop...what is happening?!

g1 <- gsplot() %>% 
  lines(1:9, seq(1,3, by=0.25), 
        legend.name="second line") %>% 

  # formatting y axes
  axis(side=2, at=1:10) %>% legend()

layout(matrix(1:2, 1, 2))
g1
g1

[ldecicco-USGS]

I'm just saying:

1. I think we need to re-think how we deal with draw_legend in general I know this is not the case that you are talking about right here and now
2. This particular case is different, and I'm looking into it (personally, on my own time at home tonight)

[ldecicco-USGS]

Here's how I'd start doing some troubleshooting for par things:

g1 <- gsplot() %>% 
  lines(1:9, seq(1,3, by=0.25), 
        legend.name="second line") %>% 
  axis(side=2, at=1:10) 
x <- par(no.readonly = TRUE)
g1
y <- par(no.readonly = TRUE)
all.equal(x, y)
 [1] "Component “mgp”: Mean relative difference: 0.55"      
 [2] "Component “pin”: Mean relative difference: 0.1922864" 
 [3] "Component “plt”: Mean relative difference: 0.1891681" 
 [4] "Component “tcl”: Mean relative difference: 1.6"       
 [5] "Component “usr”: Mean relative difference: 6"         
 [6] "Component “xaxp”: Mean relative difference: 1.833333" 
 [7] "Component “xaxs”: 1 string mismatch"                  
 [8] "Component “xpd”: 1 element mismatch"                  
 [9] "Component “yaxp”: Mean relative difference: 0.6666667"
[10] "Component “yaxs”: 1 string mismatch"          

[ldecicco-USGS]

The difference between the 2 graphs in par seems to be xpd...

g1 <- gsplot() %>% 
  lines(1:9, seq(1,3, by=0.25), 
        legend.name="second line") %>% 
  axis(side=2, at=1:10) %>% legend()
x <- par(no.readonly = TRUE)
g1
y <- par(no.readonly = TRUE)
all.equal(x, y)
[1] "Component “mgp”: Mean relative difference: 0.55"      
[2] "Component “pin”: Mean relative difference: 0.1922864" 
[3] "Component “plt”: Mean relative difference: 0.1891681" 
[4] "Component “tcl”: Mean relative difference: 1.6"       
[5] "Component “usr”: Mean relative difference: 6"         
[6] "Component “xaxp”: Mean relative difference: 1.833333" 
[7] "Component “xaxs”: 1 string mismatch"                  
[8] "Component “yaxp”: Mean relative difference: 0.6666667"
[9] "Component “yaxs”: 1 string mismatch"        

[lindsayplatt]

Oh and having xpd be different would explain all of that. Adding this fixes the issue, so now I can figure out where that's being changed.

g1 <- gsplot(xpd=FALSE) %>% 
  lines(1:9, seq(1,3, by=0.25), 
        legend.name="second line") %>% 

  # formatting y axes
  axis(side=2, at=1:10) 

layout(matrix(1:2, 1, 2))
g1
g1

[lindsayplatt]

should we up to 0.7.1 when this merges??

[ldecicco-USGS]

Yeah

[coveralls]

Coverage increased (+0.1%) to 79.638% when pulling 20c9a11899ccda196a4d5a2a7b6cb41fb800f14c on ldecicco-USGS:configBranch into bc8f472e74f4a7173d1a4ca2c7d45a0e0c09e287 on USGS-R:master.

[lindsayplatt]

I tested this with repgen and the only thing I noticed that was different was a legend was being cutoff. I'm trying to recreate a simple example.

[lindsayplatt]

Something with this branch seems to be ignoring par.

par(mar=c(5,4,10,2))

g1 <- gsplot() %>% 
  points(1:10, 1:10, pch=20, legend.name="first points") %>% 
  lines(4:1, 4:1, legend.name="first line") %>% 
  points(c(3,7,4), c(9,3,6), pch=20, col="black", legend.name="second points") %>% 
  legend(location="above")
g1

v0.7.0

this branch

[ldecicco-USGS]

I can fix that...maybe by the end of the day...silly mistake

[lindsayplatt]

Oh ok cool! Think that might also fix #405 ??

[ldecicco-USGS]

Forgot about this...will try to do soon

[lindsayplatt]

I was thinking we could take a look tomorrow at the sprint planning meeting as well

[lindsayplatt]

@ldecicco-USGS do you remember what we concluded about this? Is there more work to do?

I see that it potentially fixes #405, #392, #130

[lindsayplatt]

par issues: https://github.com/USGS-R/gsplot/issues/254

pass config a list or a filename

[ldecicco-USGS]

I'm just going to start over