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

Config branch... #402

Closed
wants to merge 18 commits into from
Closed

Conversation

ldecicco-USGS
Copy link
Member

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.

Merge branch 'master' of github.com:USGS-R/gsplot into configBranch

# Conflicts:
#	R/config.R
#	inst/doc/gsplotIntro.html
Merge branch 'master' of github.com:ldecicco-USGS/gsplot into configBranch

# Conflicts:
#	inst/doc/gsplotIntro.html
@coveralls
Copy link

Coverage Status

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

@@ -1,4 +1,5 @@
gsconfig <- new.env(parent = emptyenv())
gsconfig$orignial.par <- par(no.readonly = TRUE)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ldecicco-USGS "original"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

HAHAHAHA

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, learned how to wipe out a branch and this is what happens

@coveralls
Copy link

Coverage Status

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

@coveralls
Copy link

Coverage Status

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

@ldecicco-USGS ldecicco-USGS changed the title Config branch...somewhat WIP Config branch... Aug 17, 2016
@lindsayplatt
Copy link

@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

image

@ldecicco-USGS
Copy link
Member Author

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
Copy link

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
Copy link

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
Copy link

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

image

@ldecicco-USGS
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Member Author

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
Copy link

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
Copy link

should we up to 0.7.1 when this merges??

@ldecicco-USGS
Copy link
Member Author

Yeah

@coveralls
Copy link

Coverage Status

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

@lindsayplatt
Copy link

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
Copy link

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

image

this branch

image

@ldecicco-USGS
Copy link
Member Author

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

@lindsayplatt
Copy link

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

@ldecicco-USGS
Copy link
Member Author

Forgot about this...will try to do soon

@lindsayplatt
Copy link

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

@@ -70,14 +71,14 @@ add_to_view <- function(object, call.args, side, where){
#' gsplot:::filter_arguments('points', x=1:5, y=1:5, xlim=c(0,10), ylim=c(0,10),
#' callouts(labels=c(rep(NA, 4), "oh")))$extracted.args
#' @keywords internal
filter_arguments <- function(fun.name, ...){
filter_arguments <- function(fun.name, ..., custom.config = FALSE){
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

was thinking that default would be custom.config = NULL since that is what you would get if
custom.config = object[["global"]][["config"]][["config.file"]] didn't exist. Maybe I missed it, but where do you test for !custom.config or where is that used?

@lindsayplatt
Copy link

@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
Copy link

lindsayplatt commented Oct 24, 2016

par issues: #254

pass config a list or a filename

@ldecicco-USGS
Copy link
Member Author

I'm just going to start over

@ldecicco-USGS ldecicco-USGS deleted the configBranch branch February 10, 2017 15:33
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

Successfully merging this pull request may close these issues.

4 participants