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

2.16 does not fix problem of missing parser errors #431

Open
jgabry opened this Issue Jul 10, 2017 · 21 comments

Comments

Projects
None yet
7 participants
@jgabry
Member

jgabry commented Jul 10, 2017

Summary:

When installed from Mac binary the parser errors that were missing in v2.15 are still missing for me in v2.16. Installing from source works, but not having the parser errors when installing from binary seems like a big problem.

Reproducible Steps:

// saved in test.stan
data{
  int N; 
  real y[N];
}
parameters{
  real mu;
}
model {
  y ~ normal(mu, 1)
}
rstan::stanc(file = "test.stan")

Current Output:

> rstan::stanc(file = "test.stan")
Error in rstan::stanc(file = "Desktop/test.stan") : 
  c++ exception (unknown reason)

Expected Output:

The same parser error I would get if I had installed from source, i.e.,

> rstan::stanc(file = "test.stan")
SYNTAX ERROR, MESSAGE(S) FROM PARSER:

  error in 'model_test' at line 10, column 1
  -------------------------------------------------
     8: model {
     9:   y ~ normal(mu, 1)
        ^
  -------------------------------------------------

PARSER EXPECTED: ";"
Error in stanc(model_code = paste(program, collapse = "\n"), model_name = model_cppname,  : 
  failed to parse Stan model 'test' due to the above error.

RStan Version:

2.16.2

R Version:

3.4.1

Operating System:

OS X 10.12.5

@bob-carpenter bob-carpenter added this to the 2.15.1++ milestone Jul 10, 2017

@bob-carpenter

This comment has been minimized.

Show comment
Hide comment
@bob-carpenter

bob-carpenter Jul 10, 2017

Contributor

It'd be great if you could patch this in RStan, as I think the error messages are super important.

Please file an issue with stan-dev/stan if you need me to fix something with the parser itself to make this possible.

The milestones aren't up to date in the issues, so I just set this to 2.15.1++.

Contributor

bob-carpenter commented Jul 10, 2017

It'd be great if you could patch this in RStan, as I think the error messages are super important.

Please file an issue with stan-dev/stan if you need me to fix something with the parser itself to make this possible.

The milestones aren't up to date in the issues, so I just set this to 2.15.1++.

@bob-carpenter bob-carpenter added the bug label Jul 10, 2017

@maverickg

This comment has been minimized.

Show comment
Hide comment
@maverickg

maverickg Jul 11, 2017

Contributor

see old issue in the previous version here #405

If you can fix it by installing from source, I would say that implies this is not a bug that we can fix. I feel like the pre-built binary version from CRAN for Mac is somehow incompatible with your local environment.

I had this problem too. But I have no way to tell what's wrong with the binary file downloaded from CRAN.

Contributor

maverickg commented Jul 11, 2017

see old issue in the previous version here #405

If you can fix it by installing from source, I would say that implies this is not a bug that we can fix. I feel like the pre-built binary version from CRAN for Mac is somehow incompatible with your local environment.

I had this problem too. But I have no way to tell what's wrong with the binary file downloaded from CRAN.

@bob-carpenter

This comment has been minimized.

Show comment
Hide comment
@bob-carpenter

bob-carpenter Jul 11, 2017

Contributor

I just installed 2.16.2 and don't have this problem in either the GUI or RStudio:

> library(rstan)
Loading required package: ggplot2
Loading required package: StanHeaders
rstan (Version 2.16.2, packaged: 2017-07-03 09:24:58 UTC, GitRev: 2e1f913d3ca3)
For execution on a local, multicore CPU with excess RAM we recommend calling
rstan_options(auto_write = TRUE)
options(mc.cores = parallel::detectCores())
> stan_model("miss-semi.stan")
SYNTAX ERROR, MESSAGE(S) FROM PARSER:

  error in 'model105c33fb88e54_miss_semi' at line 10, column 1
  -------------------------------------------------
     8: model {
     9:   y ~ normal(mu, 1)
        ^
  -------------------------------------------------

PARSER EXPECTED: ";"
Error in stanc(file = file, model_code = model_code, model_name = model_name,  : 
  failed to parse Stan model 'miss-semi' due to the above error.
> 
> sessionInfo()
R version 3.3.2 (2016-10-31)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: OS X Yosemite 10.10.5

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] rstan_2.16.2         StanHeaders_2.16.0-1 ggplot2_2.2.1       

loaded via a namespace (and not attached):
 [1] colorspace_1.3-2 scales_0.4.1     assertthat_0.1   lazyeval_0.2.0   plyr_1.8.4       tools_3.3.2     
 [7] inline_0.3.14    gtable_0.2.0     tibble_1.2       gridExtra_2.2.1  Rcpp_0.12.8      grid_3.3.2      
[13] stats4_3.3.2     munsell_0.4.3   

P.S. I would prefer to see "error in miss-semi.stan" rather than "model105c33fb88e54_miss_semi"---is there something I can do in the parser inputs/outputs to make that possible? I was assuming that the file name was passed in for the naming.

Contributor

bob-carpenter commented Jul 11, 2017

I just installed 2.16.2 and don't have this problem in either the GUI or RStudio:

> library(rstan)
Loading required package: ggplot2
Loading required package: StanHeaders
rstan (Version 2.16.2, packaged: 2017-07-03 09:24:58 UTC, GitRev: 2e1f913d3ca3)
For execution on a local, multicore CPU with excess RAM we recommend calling
rstan_options(auto_write = TRUE)
options(mc.cores = parallel::detectCores())
> stan_model("miss-semi.stan")
SYNTAX ERROR, MESSAGE(S) FROM PARSER:

  error in 'model105c33fb88e54_miss_semi' at line 10, column 1
  -------------------------------------------------
     8: model {
     9:   y ~ normal(mu, 1)
        ^
  -------------------------------------------------

PARSER EXPECTED: ";"
Error in stanc(file = file, model_code = model_code, model_name = model_name,  : 
  failed to parse Stan model 'miss-semi' due to the above error.
> 
> sessionInfo()
R version 3.3.2 (2016-10-31)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: OS X Yosemite 10.10.5

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] rstan_2.16.2         StanHeaders_2.16.0-1 ggplot2_2.2.1       

loaded via a namespace (and not attached):
 [1] colorspace_1.3-2 scales_0.4.1     assertthat_0.1   lazyeval_0.2.0   plyr_1.8.4       tools_3.3.2     
 [7] inline_0.3.14    gtable_0.2.0     tibble_1.2       gridExtra_2.2.1  Rcpp_0.12.8      grid_3.3.2      
[13] stats4_3.3.2     munsell_0.4.3   

P.S. I would prefer to see "error in miss-semi.stan" rather than "model105c33fb88e54_miss_semi"---is there something I can do in the parser inputs/outputs to make that possible? I was assuming that the file name was passed in for the naming.

@davidaknowles

This comment has been minimized.

Show comment
Hide comment
@davidaknowles

davidaknowles Sep 22, 2017

I was having this problem (also on Mac), installing from source fixed it.

davidaknowles commented Sep 22, 2017

I was having this problem (also on Mac), installing from source fixed it.

@jgabry

This comment has been minimized.

Show comment
Hide comment
@jgabry

jgabry Sep 22, 2017

Member
Member

jgabry commented Sep 22, 2017

@davharris

This comment has been minimized.

Show comment
Hide comment
@davharris

davharris Jan 13, 2018

Contributor

Looks like this is still an issue as of 2.17.2: stan-dev/stan#2458

If it can't be fixed in the next version, would it be possible to add some kind of warning for users with bad installations? Figuring out what was going on tonight took me something like a half hour.

Contributor

davharris commented Jan 13, 2018

Looks like this is still an issue as of 2.17.2: stan-dev/stan#2458

If it can't be fixed in the next version, would it be possible to add some kind of warning for users with bad installations? Figuring out what was going on tonight took me something like a half hour.

@bob-carpenter

This comment has been minimized.

Show comment
Hide comment
@bob-carpenter

bob-carpenter Jan 15, 2018

Contributor

Sorry this still isn't fixed. This is a critical bug that will warrant a patch release if we can fix it. I have no idea where messages are getting lost on the way from Stan to RStan.

The first thing I'd check is that everything's getting flushed on the iostream to which these messages are being sent. That kind of default can change with new implementations.

  • Works on my machine with RStan 2.17.2 installed from binaries through R GUI an RStudio on OS X v10.10.5 and Xcode 7.2.1.

  • @mitzimorris just confirmed it's still broken through R terminal on OS X v10.13.2 and Xcode v9.2. She just reinstalled 2.17.2 from binaries and the error messages are being swallowed.

Contributor

bob-carpenter commented Jan 15, 2018

Sorry this still isn't fixed. This is a critical bug that will warrant a patch release if we can fix it. I have no idea where messages are getting lost on the way from Stan to RStan.

The first thing I'd check is that everything's getting flushed on the iostream to which these messages are being sent. That kind of default can change with new implementations.

  • Works on my machine with RStan 2.17.2 installed from binaries through R GUI an RStudio on OS X v10.10.5 and Xcode 7.2.1.

  • @mitzimorris just confirmed it's still broken through R terminal on OS X v10.13.2 and Xcode v9.2. She just reinstalled 2.17.2 from binaries and the error messages are being swallowed.

@bgoodri

This comment has been minimized.

Show comment
Hide comment
@bgoodri

bgoodri Jan 15, 2018

Contributor
Contributor

bgoodri commented Jan 15, 2018

@mitzimorris

This comment has been minimized.

Show comment
Hide comment
@mitzimorris

mitzimorris Jan 15, 2018

Member

@davharris where should this warning be? put another way, where would you expect to find this information?

Member

mitzimorris commented Jan 15, 2018

@davharris where should this warning be? put another way, where would you expect to find this information?

@mitzimorris

This comment has been minimized.

Show comment
Hide comment
@mitzimorris

mitzimorris Jan 15, 2018

Member

I've edited the RStan wiki page and added a troubleshooting section - hope this is useful.
https://github.com/stan-dev/rstan/wiki

Member

mitzimorris commented Jan 15, 2018

I've edited the RStan wiki page and added a troubleshooting section - hope this is useful.
https://github.com/stan-dev/rstan/wiki

@davharris

This comment has been minimized.

Show comment
Hide comment
@davharris

davharris Jan 15, 2018

Contributor

Thanks all of you for continuing to look into this.

@mitzimorris I realize that I don't know what it's like to work with CRAN on something this complicated, but here are some possibly-naive suggestions.

  • Would it be possible to use error handling/exceptions to catch the "unknown reason" error and print something more informative instead?

  • Alternatively (since there may be downsides to wrapping all calls to the parser in exception-handling code), I personally think it's a severe enough issue to justify the same sort of approach in the package's .onAttach function.

On the other hand, my experience with the bug may have been unusually bad: I'd imagine that there would be a lot more long, duplicate issue threads about this if people were routinely getting as mixed up as I did.

Anyway, thanks again.

Contributor

davharris commented Jan 15, 2018

Thanks all of you for continuing to look into this.

@mitzimorris I realize that I don't know what it's like to work with CRAN on something this complicated, but here are some possibly-naive suggestions.

  • Would it be possible to use error handling/exceptions to catch the "unknown reason" error and print something more informative instead?

  • Alternatively (since there may be downsides to wrapping all calls to the parser in exception-handling code), I personally think it's a severe enough issue to justify the same sort of approach in the package's .onAttach function.

On the other hand, my experience with the bug may have been unusually bad: I'd imagine that there would be a lot more long, duplicate issue threads about this if people were routinely getting as mixed up as I did.

Anyway, thanks again.

@davharris

This comment has been minimized.

Show comment
Hide comment
@davharris

davharris Jan 15, 2018

Contributor

Actually, maybe I take that last bit back. I forgot about the discourse site. Looks like people have been posting about it there instead. There are over a dozen threads about "unknown reason" there, although it looks like only some of them are about this issue. It's also been raised by a few people here and in the main Stan repo.

Contributor

davharris commented Jan 15, 2018

Actually, maybe I take that last bit back. I forgot about the discourse site. Looks like people have been posting about it there instead. There are over a dozen threads about "unknown reason" there, although it looks like only some of them are about this issue. It's also been raised by a few people here and in the main Stan repo.

@bob-carpenter

This comment has been minimized.

Show comment
Hide comment
@bob-carpenter

bob-carpenter Jan 16, 2018

Contributor
Contributor

bob-carpenter commented Jan 16, 2018

@davharris

This comment has been minimized.

Show comment
Hide comment
@davharris

davharris Jan 16, 2018

Contributor

Excellent. So when your exception catcher sees c++ exception (unknown reason), it can print something like c++ exception (unknown reason): if you're seeing this message on Mac OS X with a CRAN binary, try re-installing rstan from source. Right?

Contributor

davharris commented Jan 16, 2018

Excellent. So when your exception catcher sees c++ exception (unknown reason), it can print something like c++ exception (unknown reason): if you're seeing this message on Mac OS X with a CRAN binary, try re-installing rstan from source. Right?

@mitzimorris

This comment has been minimized.

Show comment
Hide comment
@mitzimorris

mitzimorris Jan 17, 2018

Member

a message directing folks to a specific page in the RStan wiki might be more general, although also more indirect. I've added a "Troubleshooting" section to the main page. More is needed.

Member

mitzimorris commented Jan 17, 2018

a message directing folks to a specific page in the RStan wiki might be more general, although also more indirect. I've added a "Troubleshooting" section to the main page. More is needed.

@bob-carpenter

This comment has been minimized.

Show comment
Hide comment
@bob-carpenter

bob-carpenter Jan 17, 2018

Contributor

@davharris If we could reliably print messages from exceptions, we wouldn't need to tell people to re-install from source! We're already catching the exception with the informative error message. The problem is getting error messages from our exceptions through the R plumbing when installed from CRAN.

Contributor

bob-carpenter commented Jan 17, 2018

@davharris If we could reliably print messages from exceptions, we wouldn't need to tell people to re-install from source! We're already catching the exception with the informative error message. The problem is getting error messages from our exceptions through the R plumbing when installed from CRAN.

@davharris

This comment has been minimized.

Show comment
Hide comment
@davharris

davharris Jan 17, 2018

Contributor

@bob-carpenter Oh, I think I see where the disconnect is: I meant R exceptions, and it sounds like maybe you meant C++ exceptions? I'll stop pestering you though. I can imagine this is very frustrating.

Contributor

davharris commented Jan 17, 2018

@bob-carpenter Oh, I think I see where the disconnect is: I meant R exceptions, and it sounds like maybe you meant C++ exceptions? I'll stop pestering you though. I can imagine this is very frustrating.

@bob-carpenter

This comment has been minimized.

Show comment
Hide comment
@bob-carpenter

bob-carpenter Jan 17, 2018

Contributor
Contributor

bob-carpenter commented Jan 17, 2018

@davharris

This comment has been minimized.

Show comment
Hide comment
@davharris

davharris Jan 17, 2018

Contributor

Great. Here's a simple example of what I was trying to suggest:

This function is our "parser." It can succeed, fail, or do something weird and uninformative.

mock_parser = function(result) {
  if (result == "success") {
    return("Parsed output")
  } 
  if (result == "failure") {
    stop("Typical parser error")
  }
  if (result == "uninformative") {
    stop("something uninformative")
  }
}

Here's our exception handling (described in more detail below):

with_exceptions = function(result){
  tryCatch(
    mock_parser(result = result), 
    error = function(e){
      if (e$message == "something uninformative") {
        stop(simpleError("useful error message"))
      } else {
        stop(e)
      }
    }
  )
}

If the "parser" succeeds, our handler passes along the parsed output. If it fails, it passes along the error message, unless it's our uninformative message. In that case, it replaces the error message with something useful.

> with_exceptions("success")
[1] "Parsed output"
> with_exceptions("failure")
Error in mock_parser(result = result) : Typical parser error
> with_exceptions("uninformative")
Error: useful error message
Contributor

davharris commented Jan 17, 2018

Great. Here's a simple example of what I was trying to suggest:

This function is our "parser." It can succeed, fail, or do something weird and uninformative.

mock_parser = function(result) {
  if (result == "success") {
    return("Parsed output")
  } 
  if (result == "failure") {
    stop("Typical parser error")
  }
  if (result == "uninformative") {
    stop("something uninformative")
  }
}

Here's our exception handling (described in more detail below):

with_exceptions = function(result){
  tryCatch(
    mock_parser(result = result), 
    error = function(e){
      if (e$message == "something uninformative") {
        stop(simpleError("useful error message"))
      } else {
        stop(e)
      }
    }
  )
}

If the "parser" succeeds, our handler passes along the parsed output. If it fails, it passes along the error message, unless it's our uninformative message. In that case, it replaces the error message with something useful.

> with_exceptions("success")
[1] "Parsed output"
> with_exceptions("failure")
Error in mock_parser(result = result) : Typical parser error
> with_exceptions("uninformative")
Error: useful error message
@davharris

This comment has been minimized.

Show comment
Hide comment
@davharris

davharris Jan 17, 2018

Contributor

If this looks like a good approach, I'd be happy to submit a pull request this weekend, by the way.

Contributor

davharris commented Jan 17, 2018

If this looks like a good approach, I'd be happy to submit a pull request this weekend, by the way.

@bob-carpenter

This comment has been minimized.

Show comment
Hide comment
@bob-carpenter

bob-carpenter Jan 17, 2018

Contributor

I don't know R---that's up to @bgoodri, @maverickg, and @jgabry

Contributor

bob-carpenter commented Jan 17, 2018

I don't know R---that's up to @bgoodri, @maverickg, and @jgabry

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment