Re: CRAN packages maintained by you

[Joshua N Pritikin]

On Sat, Jul 04, 2015 at 08:31:08PM +0200, Kurt Hornik wrote:
> Dear maintainers,
>
> This concerns the packages
>
> BayesXsrc CLME ETAS FedData NonpModelCheck OpenMx RCA RJSONIO
> RSocrata SINGLE SeqGrapheR TDA bclust bmk clickstream cobs99 ff
> fuzzyMM glmmGS gromovlab hashFunction lda loe mbest modMax msr
> multic netgen netweavers powell qtbase restlos robustlmm wombsoft
>
> maintained by one of you, for which R CMD check finds problems in the
> 'whether package can be installed' check, see below for details.
>
> Can we pls have updates fixing these within the next 2 weeks?
>
> Note that other R CMD check problems may need to be addressed as well.
>
> Best
> -k
>
> Maintainer: Joshua N. Pritikin <jpri...@pobox.com>
> Package: OpenMx Version: 2.2.4
> Check: whether package can be installed ... WARNING
> Found the following significant warnings:
> /home/hornik/tmp/R.check/r-devel-clang/Work/build/Packages/StanHeaders/include/stan/agrad/rev/var.hpp:160:20: warning: 'long long' is a C++11 extension [-Wc++11-long-long]
> /home/hornik/tmp/R.check/r-devel-clang/Work/build/Packages/StanHeaders/include/stan/agrad/rev/var.hpp:170:11: warning: 'long long' is a C++11 extension [-Wc++11-long-long]
> See ‘/home/hornik/tmp/R.check/r-devel-clang/Work/PKGS/OpenMx.Rcheck/00install.out’ for details.
> See: <http://CRAN.R-project.org/web/checks/check_results_OpenMx.html>

This is actually a problem with the StanHeaders package, not with
OpenMx.

[Ben Goodrich]

On Saturday, July 4, 2015 at 8:51:55 PM UTC-4, Joshua Pritikin wrote:

> Check: whether package can be installed ... WARNING
>   Found the following significant warnings:
>     /home/hornik/tmp/R.check/r-devel-clang/Work/build/Packages/StanHeaders/include/stan/agrad/rev/var.hpp:160:20: warning: 'long long' is a C++11 extension [-Wc++11-long-long]
>     /home/hornik/tmp/R.check/r-devel-clang/Work/build/Packages/StanHeaders/include/stan/agrad/rev/var.hpp:170:11: warning: 'long long' is a C++11 extension [-Wc++11-long-long]
>   See ‘/home/hornik/tmp/R.check/r-devel-clang/Work/PKGS/OpenMx.Rcheck/00install.out’ for details.
> See: <http://CRAN.R-project.org/web/checks/check_results_OpenMx.html>

This is actually a problem with the StanHeaders package, not with
OpenMx.

Yes, this was the warning that got rstan rejected for the second time. It was fixed by Bob a while ago.

Ben

 

[Daniel Lee]

Ben, what are the next steps we need to take? (I don't know enough of the CRAN process to know what your last comment means practically in terms of what we need to do.)

 

[Ben Goodrich]

On Sunday, July 5, 2015 at 11:02:25 AM UTC-4, Daniel Lee wrote:

Yes, this was the warning that got rstan rejected for the second time. It was fixed by Bob a while ago.

Ben, what are the next steps we need to take? (I don't know enough of the CRAN process to know what your last comment means practically in terms of what we need to do.)

It means we need to upload a StanHeaders post 05e74e8becb7cf6f798f314e5148480ba94e1500. In practice, we need a more recent commit due to the Boost update, the std::cout removals, etc. Basically, we just need a StanHeaders, but it can wait for #1520.

Ben

[Daniel Lee]

Got it. I'm trying to get the math library operational asap. Probably later today or tomorrow.

--
You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Joshua N Pritikin]

On Sun, Jul 05, 2015 at 08:20:12AM -0700, Ben Goodrich wrote:
> It means we need to upload a StanHeaders post
> 05e74e8becb7cf6f798f314e5148480ba94e1500. In practice, we need a more
> recent commit due to the Boost update, the std::cout removals, etc.
> Basically, we just need a StanHeaders, but it can wait for #1520.

#1520 is closed. What's the latest progress on an updated StanHeaders?

--
Joshua N. Pritikin
Department of Psychology
University of Virginia
485 McCormick Rd, Gilmer Hall Room 102
Charlottesville, VA 22904
http://people.virginia.edu/~jnp3bc

[Ben Goodrich]

On Wednesday, July 15, 2015 at 12:12:46 AM UTC-4, Joshua Pritikin wrote:

#1520 is closed. What's the latest progress on an updated StanHeaders?

We've been ready. I would like to see 1539 merged, but I guess I will just apply that patch to StanHeaders 2.7.0 manually.

Ben

[Daniel Lee]

Ben, is there a problem with using the tagged problem of Stan 2.7.0? It seems like applying a patch breaks the idea of using tagged versions.

I'd prefer to be a little more disciplined. Why don't you get 2.7.0 out as-is. It'll give us a way to move forward with releasing future versions.

Daniel

[Ben Goodrich]

On Wednesday, July 15, 2015 at 9:06:06 AM UTC-4, Daniel Lee wrote:

Ben, is there a problem with using the tagged problem of Stan 2.7.0? It seems like applying a patch breaks the idea of using tagged versions.

I'd prefer to be a little more disciplined. Why don't you get 2.7.0 out as-is. It'll give us a way to move forward with releasing future versions.

I meant applying the patch to StanHeaders locally before it gets uploaded to CRAN. The StanHeaders GitHub subrepo ordinarily points to master so tags don't mean much to us anyway.

Ben

[Bob Carpenter]

What's #1539? I don't see it as a pull request or issue on stan-dev/stan.
Is it part of stan-dev/math now?

How about creating a 2.7.1 and using that?

Do we need to have more of a consensus on deciding when to wrap a release?
I want to avoid the "just one more thing" problem that's been dragging
down our recent releases, especially as we move to having to support more
quirky platforms.

- Bob

[Ben Goodrich]

On Wednesday, July 15, 2015 at 7:53:07 PM UTC-4, Bob Carpenter wrote:

What's #1539?  I don't see it as a pull request or issue on stan-dev/stan.
Is it part of stan-dev/math now?

https://github.com/stan-dev/stan/pull/1539
 

How about creating a 2.7.1 and using that?

It could wait for 2.7.1 but who knows how long that will take.
 

Do we need to have more of a consensus on deciding when to wrap a release?
I want to avoid the "just one more thing" problem that's been dragging
down our recent releases, especially as we move to having to support more
quirky platforms.

I think it is fine to apply small patches pending for the next release to StanHeaders rather than rereleasing everything right then. But in this case it would need "just one more thing" for ADVI to work, which is having a mechanism to not die on the first exception it catches.

Ben

[Bob Carpenter]

I agree that we should fix that, too.

Whether we should hold up RStan is a separate issue. I think there
are always going to be more things we want to fix at this point --- there
are a ton of issues we just moved to 2.7.0++ because we couldn't get them
into 2.7.0. So at some point, we're going to have to just be releasing
without everything fixed.

If this is something that's going to crash R, then I agree that
we shouldn't release. My suggestion would then be not to include
ADVI in RStan 2.7.0 --- no reason it has to go in now.

I think we're going to have to be targeting a quick 2.7.1 to
solve remaining Intel compiler issues, top-level test scripts, etc.
that didn't make it into 2.7.0.

- Bob

[Daniel Lee]

I'm with Bob:

- release RStan 2.7.0 without ADVI.

- use the tagged v2.7.0 for StanHeaders.

- when 2.7.1 is ready, we can go ahead and release that.

It's still unclear when we'll sort out Intel compiler issues, the ADVI fix so that it's tested from within Stan, what else we fix.

Daniel

[Sebastian Weber]

I can concur that staying with the tagged versions is a good thing. At least I am making the assumption that when running all the cmdstan tests (including Stan C++ and Stan math) then I am guaranteed to get the same result for rstan based on the assumption that the code is exactly the same, i.e. for rstan I then only need to run the R CMD check and that's it. If StanHeaders is different from the tagged stan, then this does not hold any more.

... I can understand that having this blocking ADVI in rstan is not nice, but rstan 2.7.0 is awaited by many (including myself) even without ADVI. BTW, is a planned earlier release of StanHeaders+rstan 2.7.0 on mc-stan scheduled? I mean earlier than on CRAN?

Sebastian