date:20160825

[R-pkg-devel] Compiler choice on CRAN (R-windows-oldrel)

2016-08-25 Thread Mark van der Loo

Dear listers,


Compilation of my gower pkg fails on R-oldrel-windows. I am pretty sure
that this is because it uses gcc 4.6.3 which has limited support for OpenMP
(the errors are the same as I got on the old travis-ci build environment,
see my related question[1]).

Now, according to the Rtools page[2], since R3.2.2 "Both the gcc 4.6.3
toolchain and a toolchain based on gcc 4.9.3 and mingw-w64 v3 are now
included." Not sure what that says about CRAN, but I'm hoping/guessing it
uses Rtools the same way as we do.

So I guess I have the following options:

- make my package depend on R>=3.3
- Alter my code (as kindly suggested by Ott Toomet in [1])
- Tell CRAN to use the modern compiler.

Obviously, the latter would be easiest. Is this is even possible? For a
local installation I could set an environment variable[3], but how about
doing this at CRAN?

Thanks,
Mark


[1] https://stat.ethz.ch/pipermail/r-package-devel/2016q3/000983.html
[2] https://cran.r-project.org/bin/windows/Rtools/
[3]
https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Customizing-package-compilation

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Compiler choice on CRAN (R-windows-oldrel)

2016-08-25 Thread peter dalgaard

I don't have hard info on ABI compatibility between gcc versions, but there 
have been issues in the past, at least with with gfortran.

Now, many people/schools will have R-3.2.x installed, built with gcc 4.6.y. We 
cannot retroactively recompile their installation, nor expect them to install a 
new version built with gcc 4.9.z. This raises a specific question and a generic 
one:

- specific: Will a package binary of gower built with 4.9 work with R built 
with 4.6?
- generic: Is is sufficiently likely that a given package if compiled with a 
different compiler version that CRAN would consider having a mechanism to 
specify a particular compiler version?

I suspect that the answer to the second question is no.

Whether to condition on R >= 3.3 is a good idea largely depends on two things

- the user base (would they upgrade R anyways?)
- are there other packages that depends on gower? (CRAN keeps only the newest 
version of a package so requiring a newer R could affect users with less 
aggressive update policies. This already happened when the pbkrtest package 
update rendered the car package unloadable.)

You do have a 4th option: conditionalize the _code_ on the R version, then 
remove old-style code when 3.2.x becomes history.

-pd

On 25 Aug 2016, at 11:20 , Mark van der Loo  wrote:

> Dear listers,
> 
> 
> Compilation of my gower pkg fails on R-oldrel-windows. I am pretty sure
> that this is because it uses gcc 4.6.3 which has limited support for OpenMP
> (the errors are the same as I got on the old travis-ci build environment,
> see my related question[1]).
> 
> Now, according to the Rtools page[2], since R3.2.2 "Both the gcc 4.6.3
> toolchain and a toolchain based on gcc 4.9.3 and mingw-w64 v3 are now
> included." Not sure what that says about CRAN, but I'm hoping/guessing it
> uses Rtools the same way as we do.
> 
> So I guess I have the following options:
> 
> - make my package depend on R>=3.3
> - Alter my code (as kindly suggested by Ott Toomet in [1])
> - Tell CRAN to use the modern compiler.
> 
> Obviously, the latter would be easiest. Is this is even possible? For a
> local installation I could set an environment variable[3], but how about
> doing this at CRAN?
> 
> Thanks,
> Mark
> 
> 
> [1] https://stat.ethz.ch/pipermail/r-package-devel/2016q3/000983.html
> [2] https://cran.r-project.org/bin/windows/Rtools/
> [3]
> https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Customizing-package-compilation
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Compiler choice on CRAN (R-windows-oldrel)

2016-08-25 Thread Mark van der Loo

Thank you Peter, good points.

Good to know for sure (or a.s.) that compiler specification at CRAN is not
an option. The 4th option is interesting as well. I may just do that.

Thanks again!
Mark









Op do 25 aug. 2016 om 12:17 schreef peter dalgaard :

> I don't have hard info on ABI compatibility between gcc versions, but
> there have been issues in the past, at least with with gfortran.
>
> Now, many people/schools will have R-3.2.x installed, built with gcc
> 4.6.y. We cannot retroactively recompile their installation, nor expect
> them to install a new version built with gcc 4.9.z. This raises a specific
> question and a generic one:
>
> - specific: Will a package binary of gower built with 4.9 work with R
> built with 4.6?
> - generic: Is is sufficiently likely that a given package if compiled with
> a different compiler version that CRAN would consider having a mechanism to
> specify a particular compiler version?
>
> I suspect that the answer to the second question is no.
>
> Whether to condition on R >= 3.3 is a good idea largely depends on two
> things
>
> - the user base (would they upgrade R anyways?)
> - are there other packages that depends on gower? (CRAN keeps only the
> newest version of a package so requiring a newer R could affect users with
> less aggressive update policies. This already happened when the pbkrtest
> package update rendered the car package unloadable.)
>
> You do have a 4th option: conditionalize the _code_ on the R version, then
> remove old-style code when 3.2.x becomes history.
>
> -pd
>
> On 25 Aug 2016, at 11:20 , Mark van der Loo 
> wrote:
>
> > Dear listers,
> >
> >
> > Compilation of my gower pkg fails on R-oldrel-windows. I am pretty sure
> > that this is because it uses gcc 4.6.3 which has limited support for
> OpenMP
> > (the errors are the same as I got on the old travis-ci build environment,
> > see my related question[1]).
> >
> > Now, according to the Rtools page[2], since R3.2.2 "Both the gcc 4.6.3
> > toolchain and a toolchain based on gcc 4.9.3 and mingw-w64 v3 are now
> > included." Not sure what that says about CRAN, but I'm hoping/guessing it
> > uses Rtools the same way as we do.
> >
> > So I guess I have the following options:
> >
> > - make my package depend on R>=3.3
> > - Alter my code (as kindly suggested by Ott Toomet in [1])
> > - Tell CRAN to use the modern compiler.
> >
> > Obviously, the latter would be easiest. Is this is even possible? For a
> > local installation I could set an environment variable[3], but how about
> > doing this at CRAN?
> >
> > Thanks,
> > Mark
> >
> >
> > [1] https://stat.ethz.ch/pipermail/r-package-devel/2016q3/000983.html
> > [2] https://cran.r-project.org/bin/windows/Rtools/
> > [3]
> >
> https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Customizing-package-compilation
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> --
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Office: A 4.23
> Email: pd@cbs.dk  Priv: pda...@gmail.com
>
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Compiler choice on CRAN (R-windows-oldrel)

2016-08-25 Thread Uwe Ligges




On 25.08.2016 13:14, Mark van der Loo wrote:

Thank you Peter, good points.

Good to know for sure (or a.s.) that compiler specification at CRAN is not
an option. The 4th option is interesting as well. I may just do that.

Thanks again!
Mark


For Windows, indeed, you are tight to gcc 4.6.3 for R < 3.3.0 and to gcc 
4.9.3 for R >= 3.3.0. If your package fails for gcc 4.6.3 we can live 
with it.


Same for the other platform CRAN runs checks for, typically there is one 
compiler (as specified on the CRAN web pages).


Best,
Uwe Ligges














Op do 25 aug. 2016 om 12:17 schreef peter dalgaard :


I don't have hard info on ABI compatibility between gcc versions, but
there have been issues in the past, at least with with gfortran.

Now, many people/schools will have R-3.2.x installed, built with gcc
4.6.y. We cannot retroactively recompile their installation, nor expect
them to install a new version built with gcc 4.9.z. This raises a specific
question and a generic one:

- specific: Will a package binary of gower built with 4.9 work with R
built with 4.6?
- generic: Is is sufficiently likely that a given package if compiled with
a different compiler version that CRAN would consider having a mechanism to
specify a particular compiler version?

I suspect that the answer to the second question is no.

Whether to condition on R >= 3.3 is a good idea largely depends on two
things

- the user base (would they upgrade R anyways?)
- are there other packages that depends on gower? (CRAN keeps only the
newest version of a package so requiring a newer R could affect users with
less aggressive update policies. This already happened when the pbkrtest
package update rendered the car package unloadable.)

You do have a 4th option: conditionalize the _code_ on the R version, then
remove old-style code when 3.2.x becomes history.

-pd

On 25 Aug 2016, at 11:20 , Mark van der Loo 
wrote:


Dear listers,


Compilation of my gower pkg fails on R-oldrel-windows. I am pretty sure
that this is because it uses gcc 4.6.3 which has limited support for

OpenMP

(the errors are the same as I got on the old travis-ci build environment,
see my related question[1]).

Now, according to the Rtools page[2], since R3.2.2 "Both the gcc 4.6.3
toolchain and a toolchain based on gcc 4.9.3 and mingw-w64 v3 are now
included." Not sure what that says about CRAN, but I'm hoping/guessing it
uses Rtools the same way as we do.

So I guess I have the following options:

- make my package depend on R>=3.3
- Alter my code (as kindly suggested by Ott Toomet in [1])
- Tell CRAN to use the modern compiler.

Obviously, the latter would be easiest. Is this is even possible? For a
local installation I could set an environment variable[3], but how about
doing this at CRAN?

Thanks,
Mark


[1] https://stat.ethz.ch/pipermail/r-package-devel/2016q3/000983.html
[2] https://cran.r-project.org/bin/windows/Rtools/
[3]


https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Customizing-package-compilation


  [[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com




[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] robust download function in R (similar to wget)?

2016-08-25 Thread Lucas Ferreira Mation

I am creating this package 
that has to download data from some sources that are a bit
unstable/unreliable. The problem is described in this issue
.

Is there a more "robust" download fucntion in R?
Something similar to wget, that would:

- where there are errors, repeat the download a few times before giving up,
preferably, using partial data on a file being downloaded from previous
attempts
- check the integrity of the downloaded file

As this has to be embedded in an R package, the solution needs to be OS
independent and require no installation of external software by the user.

regards
Lucas

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] robust download function in R (similar to wget)?

2016-08-25 Thread Joshua Ulrich

Try downloader: https://cran.r-project.org/package=downloader

On Thu, Aug 25, 2016 at 7:47 AM, Lucas Ferreira Mation
 wrote:
> I am creating this package 
> that has to download data from some sources that are a bit
> unstable/unreliable. The problem is described in this issue
> .
>
> Is there a more "robust" download fucntion in R?
> Something similar to wget, that would:
>
> - where there are errors, repeat the download a few times before giving up,
> preferably, using partial data on a file being downloaded from previous
> attempts
> - check the integrity of the downloaded file
>
> As this has to be embedded in an R package, the solution needs to be OS
> independent and require no installation of external software by the user.
>
> regards
> Lucas
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
Joshua Ulrich  |  about.me/joshuaulrich
FOSS Trading  |  www.fosstrading.com
R/Finance 2016 | www.rinfinance.com

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Compiler choice on CRAN (R-windows-oldrel)

2016-08-25 Thread Mark van der Loo

Thanks Uwe. Very clear.

I'll post the solution I chose, so people can find it later. The problem is
that GCC <= 4.6.3 (at least) does not implement OpenMP reduction statements.

So now I do something like this:

#ifdef _OPENMP
#include 
#endif

#ifdef __GNUC__
#if __GNUC__ <= 4 & __GNUC_MINOR__ <= 6
#else
#define HAS_REDUCTION
#endif
#endif

/* more code */

  #ifdef HAS_REDUCTION
  #pragma omp parallel for reduction(min:imin), reduction(max:imax)
  #endif
  for (int i=0; i:

>
>
> On 25.08.2016 13:14, Mark van der Loo wrote:
> > Thank you Peter, good points.
> >
> > Good to know for sure (or a.s.) that compiler specification at CRAN is
> not
> > an option. The 4th option is interesting as well. I may just do that.
> >
> > Thanks again!
> > Mark
>
> For Windows, indeed, you are tight to gcc 4.6.3 for R < 3.3.0 and to gcc
> 4.9.3 for R >= 3.3.0. If your package fails for gcc 4.6.3 we can live
> with it.
>
> Same for the other platform CRAN runs checks for, typically there is one
> compiler (as specified on the CRAN web pages).
>
> Best,
> Uwe Ligges
>
>
>
>
>
> >
> >
> >
> >
> >
> >
> >
> >
> > Op do 25 aug. 2016 om 12:17 schreef peter dalgaard :
> >
> >> I don't have hard info on ABI compatibility between gcc versions, but
> >> there have been issues in the past, at least with with gfortran.
> >>
> >> Now, many people/schools will have R-3.2.x installed, built with gcc
> >> 4.6.y. We cannot retroactively recompile their installation, nor expect
> >> them to install a new version built with gcc 4.9.z. This raises a
> specific
> >> question and a generic one:
> >>
> >> - specific: Will a package binary of gower built with 4.9 work with R
> >> built with 4.6?
> >> - generic: Is is sufficiently likely that a given package if compiled
> with
> >> a different compiler version that CRAN would consider having a
> mechanism to
> >> specify a particular compiler version?
> >>
> >> I suspect that the answer to the second question is no.
> >>
> >> Whether to condition on R >= 3.3 is a good idea largely depends on two
> >> things
> >>
> >> - the user base (would they upgrade R anyways?)
> >> - are there other packages that depends on gower? (CRAN keeps only the
> >> newest version of a package so requiring a newer R could affect users
> with
> >> less aggressive update policies. This already happened when the pbkrtest
> >> package update rendered the car package unloadable.)
> >>
> >> You do have a 4th option: conditionalize the _code_ on the R version,
> then
> >> remove old-style code when 3.2.x becomes history.
> >>
> >> -pd
> >>
> >> On 25 Aug 2016, at 11:20 , Mark van der Loo 
> >> wrote:
> >>
> >>> Dear listers,
> >>>
> >>>
> >>> Compilation of my gower pkg fails on R-oldrel-windows. I am pretty sure
> >>> that this is because it uses gcc 4.6.3 which has limited support for
> >> OpenMP
> >>> (the errors are the same as I got on the old travis-ci build
> environment,
> >>> see my related question[1]).
> >>>
> >>> Now, according to the Rtools page[2], since R3.2.2 "Both the gcc 4.6.3
> >>> toolchain and a toolchain based on gcc 4.9.3 and mingw-w64 v3 are now
> >>> included." Not sure what that says about CRAN, but I'm hoping/guessing
> it
> >>> uses Rtools the same way as we do.
> >>>
> >>> So I guess I have the following options:
> >>>
> >>> - make my package depend on R>=3.3
> >>> - Alter my code (as kindly suggested by Ott Toomet in [1])
> >>> - Tell CRAN to use the modern compiler.
> >>>
> >>> Obviously, the latter would be easiest. Is this is even possible? For a
> >>> local installation I could set an environment variable[3], but how
> about
> >>> doing this at CRAN?
> >>>
> >>> Thanks,
> >>> Mark
> >>>
> >>>
> >>> [1] https://stat.ethz.ch/pipermail/r-package-devel/2016q3/000983.html
> >>> [2] https://cran.r-project.org/bin/windows/Rtools/
> >>> [3]
> >>>
> >>
> https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Customizing-package-compilation
> >>>
> >>>   [[alternative HTML version deleted]]
> >>>
> >>> __
> >>> R-package-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>
> >> --
> >> Peter Dalgaard, Professor,
> >> Center for Statistics, Copenhagen Business School
> >> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> >> Phone: (+45)38153501
> >> Office: A 4.23
> >> Email: pd@cbs.dk  Priv: pda...@gmail.com
> >>
> >>
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] robust download function in R (similar to wget)?

2016-08-25 Thread Dirk Eddelbuettel


On 25 August 2016 at 08:24, Joshua Ulrich wrote:
| Try downloader: https://cran.r-project.org/package=downloader

Also, if you really want wget / know how to parameterise wget you can
... just depend on _wget itself_ which you can

a) test for via Sys.which("wget")

b) select as an option for download.file() and hence all file access.

Dirk

| On Thu, Aug 25, 2016 at 7:47 AM, Lucas Ferreira Mation
|  wrote:
| > I am creating this package 
| > that has to download data from some sources that are a bit
| > unstable/unreliable. The problem is described in this issue
| > .
| >
| > Is there a more "robust" download fucntion in R?
| > Something similar to wget, that would:
| >
| > - where there are errors, repeat the download a few times before giving up,
| > preferably, using partial data on a file being downloaded from previous
| > attempts
| > - check the integrity of the downloaded file
| >
| > As this has to be embedded in an R package, the solution needs to be OS
| > independent and require no installation of external software by the user.
| >
| > regards
| > Lucas
| >
| > [[alternative HTML version deleted]]
| >
| > __
| > R-package-devel@r-project.org mailing list
| > https://stat.ethz.ch/mailman/listinfo/r-package-devel
| 
| 
| 
| -- 
| Joshua Ulrich  |  about.me/joshuaulrich
| FOSS Trading  |  www.fosstrading.com
| R/Finance 2016 | www.rinfinance.com
| 
| __
| R-package-devel@r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] robust download function in R (similar to wget)?

2016-08-25 Thread Bob Rudis

libcurl (which the RCurl & curl packages are built on) do not inherently
have retry or resume partial capabilities, but those could be packaged up
into a "robustdownloader" package. There's no guarantee of wget or curl
binaries being on a system (especially Windows, even with an Rtools
installation, rly great platform there). Windows does have a PowerShell
`wget` alias for `Invoke-WebRequest` but it's woefully less powerful than
wget-proper and doesn't support the features you need and it relies on
PowerShell).

I'd suggest the creation of a separate package for robust downloading and
then relying on that or keep the solution you've got by PR #56.

On Thu, Aug 25, 2016 at 9:56 AM, Dirk Eddelbuettel  wrote:

>
> On 25 August 2016 at 08:24, Joshua Ulrich wrote:
> | Try downloader: https://cran.r-project.org/package=downloader
>
> Also, if you really want wget / know how to parameterise wget you can
> ... just depend on _wget itself_ which you can
>
> a) test for via Sys.which("wget")
>
> b) select as an option for download.file() and hence all file access.
>
> Dirk
>
> | On Thu, Aug 25, 2016 at 7:47 AM, Lucas Ferreira Mation
> |  wrote:
> | > I am creating this package  lucasmation/microdadosBrasil>
> | > that has to download data from some sources that are a bit
> | > unstable/unreliable. The problem is described in this issue
> | > .
> | >
> | > Is there a more "robust" download fucntion in R?
> | > Something similar to wget, that would:
> | >
> | > - where there are errors, repeat the download a few times before
> giving up,
> | > preferably, using partial data on a file being downloaded from previous
> | > attempts
> | > - check the integrity of the downloaded file
> | >
> | > As this has to be embedded in an R package, the solution needs to be OS
> | > independent and require no installation of external software by the
> user.
> | >
> | > regards
> | > Lucas
> | >
> | > [[alternative HTML version deleted]]
> | >
> | > __
> | > R-package-devel@r-project.org mailing list
> | > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> |
> |
> |
> | --
> | Joshua Ulrich  |  about.me/joshuaulrich
> | FOSS Trading  |  www.fosstrading.com
> | R/Finance 2016 | www.rinfinance.com
> |
> | __
> | R-package-devel@r-project.org mailing list
> | https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Compiler choice on CRAN (R-windows-oldrel)

Re: [R-pkg-devel] Compiler choice on CRAN (R-windows-oldrel)

Re: [R-pkg-devel] Compiler choice on CRAN (R-windows-oldrel)

Re: [R-pkg-devel] Compiler choice on CRAN (R-windows-oldrel)

[R-pkg-devel] robust download function in R (similar to wget)?

Re: [R-pkg-devel] robust download function in R (similar to wget)?

Re: [R-pkg-devel] Compiler choice on CRAN (R-windows-oldrel)

Re: [R-pkg-devel] robust download function in R (similar to wget)?

Re: [R-pkg-devel] robust download function in R (similar to wget)?

9 matches

Site Navigation

Mail list logo

Footer information