On 3 August 2016 at 22:26, Bob Rudis wrote:
| I came across https://cran.rstudio.com/web/packages/boxoffice/index.html
| in CRAN today and while I don't expect CRAN to be a legal authority,
| should there not be some kind of policy for excluding R packages that
| deliberately violate (data) site T
I came across https://cran.rstudio.com/web/packages/boxoffice/index.html
in CRAN today and while I don't expect CRAN to be a legal authority,
should there not be some kind of policy for excluding R packages that
deliberately violate (data) site ToS? (I'm asking this here vs sending
a note to CRAN f
On 3 August 2016 at 17:35, Duncan Murdoch wrote:
| No, you are reading something into my messages that isn't there. I
| think I understand your suggestion now (CRAN should test with no
| Suggested packages present, not with all of them present). That is less
| work than they currently do.
An
Thanks for the good specific suggestions Kevin and Max. It is amazing
that great help is available from the R community in such a short time.
Clearly everybody thinks that these issues should be fixed before I even
try to submit to CRAN (and I fully agree that they shouldn't lower their
standa
On Wed, Aug 3, 2016 at 3:09 PM, MTurgeon wrote:
> Hi Ege,
>
> For writing to standard output/error, you can use Rcout or Rcerr (defined by
> Rcpp; they even have a vignette showing how to use it in the Rcpp gallery).
> Alternatively, if you're using C code, you can replace printf by Rprintf
> (thi
It looks like most of these usages of std::cout, std::cerr and abort
are coming from the logging infrastructure:
https://github.com/micolous/s2-geometry-library/blob/master/geometry/base/logging.h
If you wanted to make this work on CRAN, you could patch these files
in a number of ways:
You could
Hi Ege,
For writing to standard output/error, you can use Rcout or Rcerr
(defined by Rcpp; they even have a vignette showing how to use it in the
Rcpp gallery). Alternatively, if you're using C code, you can replace
printf by Rprintf (this is explained in Writing R extensions, section 6.5).
On 03/08/2016 5:59 PM, Ege Rubak wrote:
The main things seem to be related to (travis log is at
https://travis-ci.org/spatstat/s2/jobs/149578339):
1. Deprecated C++ headers and .
2. Compiled code that calls entry points which might terminate R or
write to stdout/stderr.
Is it hopeless to ge
The main things seem to be related to (travis log is at
https://travis-ci.org/spatstat/s2/jobs/149578339):
1. Deprecated C++ headers and .
2. Compiled code that calls entry points which might terminate R or
write to stdout/stderr.
Is it hopeless to get on CRAN with warnings like these?
I d
On 03/08/2016 5:36 PM, Ege Rubak wrote:
Hi,
I would like to port Google's s2-library for spherical geometry (see
e.g. https://github.com/micolous/s2-geometry-library for a fork on
GitHub). It is not a standard library that can easily be installed on
various systems, so I would like to include th
Hi,
I would like to port Google's s2-library for spherical geometry (see
e.g. https://github.com/micolous/s2-geometry-library for a fork on
GitHub). It is not a standard library that can easily be installed on
various systems, so I would like to include the source code in the R
package. The c
On 03/08/2016 2:03 PM, Dirk Eddelbuettel wrote:
On 3 August 2016 at 13:44, Duncan Murdoch wrote:
| On 03/08/2016 11:17 AM, Dirk Eddelbuettel wrote:
| >
| > On 3 August 2016 at 16:21, Uwe Ligges wrote:
| > |
| > |
| > | On 03.08.2016 16:14, Dirk Eddelbuettel wrote:
| > | >
| > | > On 3 August 201
On 3 August 2016 at 13:44, Duncan Murdoch wrote:
| On 03/08/2016 11:17 AM, Dirk Eddelbuettel wrote:
| >
| > On 3 August 2016 at 16:21, Uwe Ligges wrote:
| > |
| > |
| > | On 03.08.2016 16:14, Dirk Eddelbuettel wrote:
| > | >
| > | > On 3 August 2016 at 16:00, Uwe Ligges wrote:
| > | > | On 03.08.2
On 03/08/2016 11:17 AM, Dirk Eddelbuettel wrote:
On 3 August 2016 at 16:21, Uwe Ligges wrote:
|
|
| On 03.08.2016 16:14, Dirk Eddelbuettel wrote:
| >
| > On 3 August 2016 at 16:00, Uwe Ligges wrote:
| > | On 03.08.2016 14:24, Dirk Eddelbuettel wrote:
| > | > Then again, users of TravisCI know th
On 3 August 2016 at 17:39, Uwe Ligges wrote:
| On 03.08.2016 17:17, Dirk Eddelbuettel wrote:
| > On 3 August 2016 at 16:21, Uwe Ligges wrote:
| >
| > But then you are treating Suggests as Depends and installing irregardless.
|
| Yes, because I want to check all the runtime code on CRAN and not on
Hi Mark,
if you consider backward compatibility (and potential compatibility with
other compilers) a worthy goal, you can easily reduce manually in a
'#pragma omp critical' block. An example here (around the middle of the
page):
http://www.parallelr.com/r-and-openmp-boosting-compiled-code-on-mult
On 03.08.2016 17:17, Dirk Eddelbuettel wrote:
On 3 August 2016 at 16:21, Uwe Ligges wrote:
|
|
| On 03.08.2016 16:14, Dirk Eddelbuettel wrote:
| >
| > On 3 August 2016 at 16:00, Uwe Ligges wrote:
| > | On 03.08.2016 14:24, Dirk Eddelbuettel wrote:
| > | > Then again, users of TravisCI know tha
On 3 August 2016 at 16:21, Uwe Ligges wrote:
|
|
| On 03.08.2016 16:14, Dirk Eddelbuettel wrote:
| >
| > On 3 August 2016 at 16:00, Uwe Ligges wrote:
| > | On 03.08.2016 14:24, Dirk Eddelbuettel wrote:
| > | > Then again, users of TravisCI know that just toggling
| > | >
| > | > _R_CHECK_FORCE_S
After about a three hour slog through my code I was able to track down and
eliminate any non-essential function calls. The function call removal
significantly decreased the stack size, removing the requirement for
R_CStackLimit bound to be changed.
Thanks,
Jonathan Lisic
> On Aug 3, 2016, a
Hi,
I just had a CRAN rejection due to setting R_CStackLimit = (uintptr_t)-1 , e.g
Found non-API call to R: ‘R_CStackLimit’.
This stack limit change is done to avoid stack overruns when I use OpenMP with
C. Are there other ways around this issue? or should I just accept the large
performanc
I am using #pragma omp statements all over the place and this is the only
type causing crashes. I'm guessing it has something to do with travis
building on a 12.04 ubuntu VM with a rather old gcc (4.6.3).
2. Is there a workaround, or should I just go for another build service
(which one)?
Yo
On 03.08.2016 16:14, Dirk Eddelbuettel wrote:
On 3 August 2016 at 16:00, Uwe Ligges wrote:
| On 03.08.2016 14:24, Dirk Eddelbuettel wrote:
| > Then again, users of TravisCI know that just toggling
| >
| > _R_CHECK_FORCE_SUGGESTS_=FALSE
|
| I was travelling, hence a delayed response:
|
| Why us
On 3 August 2016 at 16:00, Uwe Ligges wrote:
| On 03.08.2016 14:24, Dirk Eddelbuettel wrote:
| > Then again, users of TravisCI know that just toggling
| >
| > _R_CHECK_FORCE_SUGGESTS_=FALSE
|
| I was travelling, hence a delayed response:
|
| Why users of TravisCI? It is documented in the manual.
On 03.08.2016 14:24, Dirk Eddelbuettel wrote:
On 2 August 2016 at 19:45, Duncan Murdoch wrote:
| Why not put together code to implement your idea, and see how big the
| problem would be to phase it in, by seeing how many packages fail under it?
Ahh, the old 'put-up-or-shut-up' gambit, very ni
On 03.08.2016 15:20, Thomas J. Leeper wrote:
The issue seems to boil down to the fact that Suggests is covering two
very different use cases: (a) conditional package code and (b)
example/test/vignette code.
Consider a package (say "foo") that is only used in tests. Users do
not need "foo" sinc
On 03.08.2016 15:04, Mark van der Loo wrote:
Recommends: only gets installed, can be used via if(requireNamespace())
from the package and in pkg tests[1] [snip]
Build-Depends: gets installed before build, removed after.
Suggests: only installed when requested at install.packages() and only
used
Closely related to the different QR variations, Claudia Beleites and I
have a very crude start on some attempts to categorize different svd
approaches in R. Perhaps it's worth combining efforts with QR because of
the overlap and producing a sort of enlarged vignette or even a Task
View. I suggest c
Thanks Dirk! that did it. I wasn't aware of the trusty 14.04 option.
Just adding
sudo: required
dist: trusty
at the top of my .travis.yaml solved it
https://docs.travis-ci.com/user/trusty-ci-environment/,
Cheers,
Mark
Op wo 3 aug. 2016 om 14:38 schreef Dirk Eddelbuettel :
>
> On 3 August
The issue seems to boil down to the fact that Suggests is covering two
very different use cases: (a) conditional package code and (b)
example/test/vignette code.
Consider a package (say "foo") that is only used in tests. Users do
not need "foo" since package code never calls it. If our package
ins
Thanks for the input Peter. I suppose I never looked at lm() to see how it
was used there. Given that though, do you see any reason then to not
create an S3/S4 method if different methods are used for different
functions? I'm just looking for some design guidance from the community
here before I
>> Recommends: only gets installed, can be used via if(requireNamespace())
>> from the package and in pkg tests[1] [snip]
>> Build-Depends: gets installed before build, removed after.
>> Suggests: only installed when requested at install.packages() and only
>> used in examples/vignettes.
[snip]
>
On 3 August 2016 at 08:13, Mark van der Loo wrote:
| Dear pkg developers,
|
|
| I'm working on a package using C code and openMP. The package builds and
| tests fine on my own machine[1] and also on r-hub[2]. However on travis-ci
| the build crashes[3] with the following message (plus a few simi
On 2 August 2016 at 19:45, Duncan Murdoch wrote:
| Why not put together code to implement your idea, and see how big the
| problem would be to phase it in, by seeing how many packages fail under it?
Ahh, the old 'put-up-or-shut-up' gambit, very nice. Big fan of that myself.
I have been sitting o
On 03/08/2016 5:32 AM, Mark van der Loo wrote:
After reading the link in Dirk's initial reply, how about adding fields
'Recommends' and 'Build-Depends' to DESCRIPTION as in Debian?
Recommends: only gets installed, can be used via if(requireNamespace())
from the package and in pkg tests[1]. [Deb
After reading the link in Dirk's initial reply, how about adding
fields 'Recommends'
and 'Build-Depends' to DESCRIPTION as in Debian?
Recommends: only gets installed, can be used via if(requireNamespace())
from the package and in pkg tests[1]. [Debian: The Recommends field should
list packages tha
Dear pkg developers,
I'm working on a package using C code and openMP. The package builds and
tests fine on my own machine[1] and also on r-hub[2]. However on travis-ci
the build crashes[3] with the following message (plus a few similar):
gower.c:297:29: error: expected ‘+’, ‘*’, ‘-’, ‘&’, ‘^’,
36 matches
Mail list logo
