Re: [R-pkg-devel] Warning in dir.create(vd2 <- "vign_test"): 'vign_test' already exists

[Uwe Ligges]

On 16.03.2020 00:09, Spencer Graves wrote:

Hello, All:


   Under Windows 10, "R CMD check sos_2.0-1.tar.gz" cloned from 
"https://github.com/sbgraves237/sos; ends with:



* checking rebuild of vignettes outputs ...Warning in dir.create(vd2 <- 
"vign_test"):  'vign_test' already exists


I do not get it when checking your package.

Best,
Uwe Ligges





   Under macOS 10.15.3 it finishes fine.


   "grep 'vign_test'" failed to find anything.


   ???
   Thanks,
   Spencer Graves


p.s.  Running R 3.6.3 on both machines with "update.packates()" clean.

__
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

Re: [R-pkg-devel] An invalid URLs

[Uwe Ligges]

On 13.03.2020 12:59, Ivan Krylov wrote:

On Fri, 13 Mar 2020 11:02:06 +0300
Ivan Krylov  wrote:


the remote server could deny requests from such automated user
agents, only allowing clients that look like browsers


Here is what I have been able to observe:

If wait for some time, then try to access http://www.malacards.org/
using cURL, I start getting 403 errors in both cURL and browser.

If wait for some time, then go to http://www.malacards.org/ using a
browser and click on a few links, subsequent access using cURL from
the same IP address also starts working (for a while).

Given the paranoid nature of the website's security system, it's hard
to offer a good solution to your problem: linking to it may place
people running R CMD check into temporary ban, while not linking to it
does not seem polite.



Well, then mention the URL in plain text but not link

Best,
Uwe Ligges

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

Re: [R-pkg-devel] packaging biosig for R

[Uwe Ligges]

On 16.03.2020 10:58, Duncan Murdoch wrote:

On 16/03/2020 3:00 a.m., Alois Schlögl wrote:


Thanks for your response. For *nix (Linux, MacOSX), this can be
achieved. For windows, currently the only way to compile libbiosig is
through mingw-cross-compiler environment (MXE) [1]  or in cygwin.
Currently, libbiosig does not compile with with VC++for various reasons,
and libbiosig has some hard dependencies (libiconv, suitesparse, dcmtk),
(there are dependencies on libb64, tinyxml), I'm wondering what the best
approach would be.

- Would it be ok, if libbiosig.dll is distributed in binary form ?


I think the answer to that is that it would not be allowed, but I'm not 
part of CRAN.




- Or would you accept a package that currently runs only on
MacOSX/Homebrew and Linux but not on Windows ?


There are some packages like that on CRAN, but it is certainly 
discouraged.  Bioconductor has its own rules; you might want to ask 
there, given the subject matter of your package.


Thanks, Duncan, same from here, just to confrim from a "part of CRAN" 
point of view.


Best,
Uwe Ligges




Duncan Murdoch





Alois Schlögl

[1] https://github.com/schloegl/mxe



Am 3/16/20 um 2:08 AM schrieb Duncan Murdoch:

I suspect the question in this case depends on the availability of
libbiosig.  If CRAN test machines don't have that and its source isn't
included in the R package, then it will fail on initial install.  CRAN
doesn't have a lot of resources to install difficult libraries; I have
no idea if that applies in this case.

I believe the most robust way to handle this sort of package is to
have a configure script that looks for the lib on the installing
machine, and uses that copy if found, otherwise compiles it from source.

Duncan Murdoch



On 15/03/2020 3:41 p.m., Jeff Newmiller wrote:

I am just a lurker (not representing CRAN) but I am having a hard
time understanding your question.

Binary packages are a convenience for users, not a method for
submitting packages. When you have an R package accepted it is
accepted in source format.
If it doesn't exclude support for Windows or MacOSX then it will (in
time) be compiled into a binary form for distribution in addition to
being distributed is source form.

As the maintainer, your responsibility is merely to confirm that your
source package is properly configured to be built in binary form
before you submit it to CRAN. This is normally accomplished by
successfully building it as binary in a testing environment. There
are various guides out there that can be helpful in accomplishing
this, e.g. [1].

[1] https://kbroman.org/pkg_primer/pages/cran.htm


On March 15, 2020 1:07:41 AM PDT, "Alois Schlögl"
 wrote:


Dear R packagers,


the Biosig project [1] supports reading of about 50 different data
format [2]. Recently, a language binding to R was added, because a 
user

of Biosig asked for it.


I've read the policy [3], and it seems the biosig would qualify as
binary package. The underlying library (libbiosig) can be installed

- on linux from source, or through debian/ubuntu package

- on MacOSX through Homebrew.

- for Windows I'm using MXE mingw-cross-compiler environment to build
libbiosig.dll


Would it be feasible to provide a package of biosig on cran ? What 
need

to be considered ?


Kind regards

 Alois



[1] http://biosig.sourceforge.net/download.html

[2] http://pub.ist.ac.at/~schloegl/biosig/TESTED

[3] https://cran.r-project.org/web/packages/policies.html

__
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-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Examples for functions called by Shiny server

[Uwe Ligges]

In general:

- You need examples for exported functions.
- You should test s much of the package as possible, of course.
- For shiny you have code on ./inst, but there should only be code for 
shiny, not additional fdiunctionaliyt that should be striiped out and 
made availabe via functions defined in ./R.


I haven't looked at the details, but if you fullfilled tjhe above, 
please simply resubmit or in case you do not need to change anytrhing, 
simply say so and respond to the CRAN team member CCing 
cran-submissions@...



Best,
Uwe Ligges





On 16.03.2020 05:22, R. Mark Sharp wrote:

I have been asked to provide examples within the Rd files of my package 
(github.com/rmsharp/nprcgenekeepr ) by 
the CRAN package reviewer. I have to export those functions called by the server.R 
script (or use ::: notation), which in turn generates an Rd file that is to have the 
example.

I cannot think of a meaningful example for a function that creates the content 
of a new Shiny tabpanel when an error is detected.

Suggestions are eagerly sought.

Mark
R. Mark Sharp, Ph.D.
Data Scientist and Biomedical Statistical Consultant
7526 Meadow Green St.
San Antonio, TX 78251
mobile: 210-218-2868
rmsh...@me.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

Re: [R-pkg-devel] parglm: cannot reproduce error

[Benjamin Christoffersen]

Sorry for posting twice. I thought that the mail had not been send out
but it seems like it has been:
https://stat.ethz.ch/pipermail/r-package-devel/2020q1/thread.html

Den man. 16. mar. 2020 kl. 12.19 skrev Benjamin Christoffersen
:
>
> Dear Sirs,
>
> Recently, my parglm package was pulled of CRAN because of a segfault
> on Solaris and an issue on the OpenBLAS additional issues test.
>
> I started by trying to reproduce the Solaris issue but failed to
> reproduce the error
> with `rhub::checkonsolaris()`. Then I tried to reproduce the OpenBLAS error.
> First, I build R-devel with
> `–with-blas="/usr/lib/x86_64-linux-gnu/openblas/libblas.so.3"` and
> `–with-lapack="/usr/lib/x86_64-linux-gnu/openblas/liblapack.so.3"`
> which one gets from `libopenblas-dev` if I recall correctly on my own
> Ubuntu machine (version 18.04, gcc 8.3.0). However, there where no
> issues or segfaults when I ran `CMD check –as-cran
> –no-stop-on-test-error`.
>
> Then I build the following docker image:
> https://gist.github.com/boennecd/fd0625daf11aae3304e9e9a9a6cfea7d
>
> where I do as described in the following two links (I think):
> https://www.stats.ox.ac.uk/pub/bdr/Rblas/README.txt &
> https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-devel-linux-x8664-fedora-gcc
>
> However when I started the container and ran:
>  - `/opt/R-devel/lib64/R/bin/R CMD check –as-cran
> –no-stop-on-test-error –use-valgrind`
>  - `/opt/R-devel/lib64/R/bin/R CMD check –as-cran –no-stop-on-test-error`
>
> then I got no issues or segfaults.
>
> So, although that other people have asked similar questions before,
> can anyone spot what I did wrong when I tried to reproduce the error
> and if not what should I do? Any help is much appreciated.
>
> There are no other issues with both ASAN and UBSAN checks with gcc and
> clang on my own machine.
>
> Sincerely Yours,
> Benjamin Christoffersen

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

[R-pkg-devel] parglm: cannot reproduce error

[Benjamin Christoffersen]

Dear Sirs,

Recently, my parglm package was pulled of CRAN because of a segfault
on Solaris and an issue on the OpenBLAS additional issues test.

I started by trying to reproduce the Solaris issue but failed to
reproduce the error
with `rhub::checkonsolaris()`. Then I tried to reproduce the OpenBLAS error.
First, I build R-devel with
`–with-blas="/usr/lib/x86_64-linux-gnu/openblas/libblas.so.3"` and
`–with-lapack="/usr/lib/x86_64-linux-gnu/openblas/liblapack.so.3"`
which one gets from `libopenblas-dev` if I recall correctly on my own
Ubuntu machine (version 18.04, gcc 8.3.0). However, there where no
issues or segfaults when I ran `CMD check –as-cran
–no-stop-on-test-error`.

Then I build the following docker image:
https://gist.github.com/boennecd/fd0625daf11aae3304e9e9a9a6cfea7d

where I do as described in the following two links (I think):
https://www.stats.ox.ac.uk/pub/bdr/Rblas/README.txt &
https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-devel-linux-x8664-fedora-gcc

However when I started the container and ran:
 - `/opt/R-devel/lib64/R/bin/R CMD check –as-cran
–no-stop-on-test-error –use-valgrind`
 - `/opt/R-devel/lib64/R/bin/R CMD check –as-cran –no-stop-on-test-error`

then I got no issues or segfaults.

So, although that other people have asked similar questions before,
can anyone spot what I did wrong when I tried to reproduce the error
and if not what should I do? Any help is much appreciated.

There are no other issues with both ASAN and UBSAN checks with gcc and
clang on my own machine.

Sincerely Yours,
Benjamin Christoffersen

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

Re: [R-pkg-devel] packaging biosig for R

[Duncan Murdoch]

On 16/03/2020 3:00 a.m., Alois Schlögl wrote:


Thanks for your response. For *nix (Linux, MacOSX), this can be
achieved. For windows, currently the only way to compile libbiosig is
through mingw-cross-compiler environment (MXE) [1]  or in cygwin.
Currently, libbiosig does not compile with with VC++for various reasons,
and libbiosig has some hard dependencies (libiconv, suitesparse, dcmtk),
(there are dependencies on libb64, tinyxml), I'm wondering what the best
approach would be.

- Would it be ok, if libbiosig.dll is distributed in binary form ?


I think the answer to that is that it would not be allowed, but I'm not 
part of CRAN.




- Or would you accept a package that currently runs only on
MacOSX/Homebrew and Linux but not on Windows ?


There are some packages like that on CRAN, but it is certainly 
discouraged.  Bioconductor has its own rules; you might want to ask 
there, given the subject matter of your package.


Duncan Murdoch





Alois Schlögl

[1] https://github.com/schloegl/mxe



Am 3/16/20 um 2:08 AM schrieb Duncan Murdoch:

I suspect the question in this case depends on the availability of
libbiosig.  If CRAN test machines don't have that and its source isn't
included in the R package, then it will fail on initial install.  CRAN
doesn't have a lot of resources to install difficult libraries; I have
no idea if that applies in this case.

I believe the most robust way to handle this sort of package is to
have a configure script that looks for the lib on the installing
machine, and uses that copy if found, otherwise compiles it from source.

Duncan Murdoch



On 15/03/2020 3:41 p.m., Jeff Newmiller wrote:

I am just a lurker (not representing CRAN) but I am having a hard
time understanding your question.

Binary packages are a convenience for users, not a method for
submitting packages. When you have an R package accepted it is
accepted in source format.
If it doesn't exclude support for Windows or MacOSX then it will (in
time) be compiled into a binary form for distribution in addition to
being distributed is source form.

As the maintainer, your responsibility is merely to confirm that your
source package is properly configured to be built in binary form
before you submit it to CRAN. This is normally accomplished by
successfully building it as binary in a testing environment. There
are various guides out there that can be helpful in accomplishing
this, e.g. [1].

[1] https://kbroman.org/pkg_primer/pages/cran.htm


On March 15, 2020 1:07:41 AM PDT, "Alois Schlögl"
 wrote:


Dear R packagers,


the Biosig project [1] supports reading of about 50 different data
format [2]. Recently, a language binding to R was added, because a user
of Biosig asked for it.


I've read the policy [3], and it seems the biosig would qualify as
binary package. The underlying library (libbiosig) can be installed

- on linux from source, or through debian/ubuntu package

- on MacOSX through Homebrew.

- for Windows I'm using MXE mingw-cross-compiler environment to build
libbiosig.dll


Would it be feasible to provide a package of biosig on cran ? What need
to be considered ?


Kind regards

     Alois



[1] http://biosig.sourceforge.net/download.html

[2] http://pub.ist.ac.at/~schloegl/biosig/TESTED

[3] https://cran.r-project.org/web/packages/policies.html

__
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

Re: [R-pkg-devel] packaging biosig for R

[Alois Schlögl]

Thanks for your response. For *nix (Linux, MacOSX), this can be
achieved. For windows, currently the only way to compile libbiosig is
through mingw-cross-compiler environment (MXE) [1]  or in cygwin.
Currently, libbiosig does not compile with with VC++for various reasons,
and libbiosig has some hard dependencies (libiconv, suitesparse, dcmtk),
(there are dependencies on libb64, tinyxml), I'm wondering what the best
approach would be.

- Would it be ok, if libbiosig.dll is distributed in binary form ?

- Or would you accept a package that currently runs only on
MacOSX/Homebrew and Linux but not on Windows ?


Alois Schlögl 

[1] https://github.com/schloegl/mxe



Am 3/16/20 um 2:08 AM schrieb Duncan Murdoch:
> I suspect the question in this case depends on the availability of
> libbiosig.  If CRAN test machines don't have that and its source isn't
> included in the R package, then it will fail on initial install.  CRAN
> doesn't have a lot of resources to install difficult libraries; I have
> no idea if that applies in this case.
>
> I believe the most robust way to handle this sort of package is to
> have a configure script that looks for the lib on the installing
> machine, and uses that copy if found, otherwise compiles it from source.
>
> Duncan Murdoch
>
>
>
> On 15/03/2020 3:41 p.m., Jeff Newmiller wrote:
>> I am just a lurker (not representing CRAN) but I am having a hard
>> time understanding your question.
>>
>> Binary packages are a convenience for users, not a method for
>> submitting packages. When you have an R package accepted it is
>> accepted in source format.
>> If it doesn't exclude support for Windows or MacOSX then it will (in
>> time) be compiled into a binary form for distribution in addition to
>> being distributed is source form.
>>
>> As the maintainer, your responsibility is merely to confirm that your
>> source package is properly configured to be built in binary form
>> before you submit it to CRAN. This is normally accomplished by
>> successfully building it as binary in a testing environment. There
>> are various guides out there that can be helpful in accomplishing
>> this, e.g. [1].
>>
>> [1] https://kbroman.org/pkg_primer/pages/cran.htm
>>
>>
>> On March 15, 2020 1:07:41 AM PDT, "Alois Schlögl"
>>  wrote:
>>>
>>> Dear R packagers,
>>>
>>>
>>> the Biosig project [1] supports reading of about 50 different data
>>> format [2]. Recently, a language binding to R was added, because a user
>>> of Biosig asked for it.
>>>
>>>
>>> I've read the policy [3], and it seems the biosig would qualify as
>>> binary package. The underlying library (libbiosig) can be installed
>>>
>>> - on linux from source, or through debian/ubuntu package
>>>
>>> - on MacOSX through Homebrew.
>>>
>>> - for Windows I'm using MXE mingw-cross-compiler environment to build
>>> libbiosig.dll
>>>
>>>
>>> Would it be feasible to provide a package of biosig on cran ? What need
>>> to be considered ?
>>>
>>>
>>> Kind regards
>>>
>>>     Alois
>>>
>>>
>>>
>>> [1] http://biosig.sourceforge.net/download.html
>>>
>>> [2] http://pub.ist.ac.at/~schloegl/biosig/TESTED
>>>
>>> [3] https://cran.r-project.org/web/packages/policies.html
>>>
>>> __
>>> 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