Re: [R-pkg-devel] Rd files: using \link[pkg]{foo} when file names differ between OSs

[Ramon Diaz-Uriarte]

Dear Duncan,

On Mon, 16-April-2018, at 17:52:10, Duncan Murdoch  
wrote:
> On 16/04/2018 11:35 AM, Ramon Diaz-Uriarte wrote:
>> Dear All,
>> 
>> Two recent threads in the bioconductor devel mailing list
>> (https://stat.ethz.ch/pipermail/bioc-devel/2018-April/013156.html and
>> https://stat.ethz.ch/pipermail/bioc-devel/2018-April/013259.html) are
>> related to packages that have different names of html files in different
>> operating systems.
>> 
>> For example, parallel has a file called mclapply in Linux. So using, from
>> the Rd file of another package, \link[parallel]{mclapply} works fine under
>> Linux, but does not under Windows, because there is no mclapply.html file
>> in Windows (there is a mcdummies file).
>> 
>> 
>> Is there any recommended way to proceed in these cases?
>> 
>> 
>> Yes, section 2.5 of Writing R Extensions indicates that \link[pkg]{foo}
>> and \link[pkg:bar]{foo} are rarely needed; so the simplest way to proceed
>> would be to avoid \link[pkg]{foo} and \link[pkg:bar]{foo}. I am asking for
>> the cases where, as noted in 2.5, "more than one package offers help on a
>> topic".
>
> You could make the links conditional on the OS.  For example,
>
> #ifdef windows
> See \link[parallel]{mcdummies}.
> #endif
> #ifdef unix
> See \link[parallel]{mclapply}.
> #endif

Thanks. I wasn't aware that was possible.



>
> The other possibility (useful if there are major differences between the 
> platforms) is to have two copies of the help file, one in man/unix, one 
> in man/windows, but that doesn't seem appropriate from your description.

I think the previous one is better (actually, for my specific cases right
now, I was able to solve the problem using \link{foo} since only one
packages offers help on the topic I link to).



Best,

R.


>
> Duncan Murdoch
>> 
>> 
>> Thanks,
>> 
>> 
>> R.
>> 
>> --
>> Ramon Diaz-Uriarte
>> Department of Biochemistry, Lab B-25
>> Facultad de Medicina
>> Universidad Autónoma de Madrid
>> Arzobispo Morcillo, 4
>> 28029 Madrid
>> Spain
>> 
>> Phone: +34-91-497-2412
>> 
>> Email: rdia...@gmail.com
>> ramon.d...@iib.uam.es
>> 
>> http://ligarto.org/rdiaz
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 


-- 
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid 
Arzobispo Morcillo, 4
28029 Madrid
Spain

Phone: +34-91-497-2412

Email: rdia...@gmail.com
   ramon.d...@iib.uam.es

http://ligarto.org/rdiaz

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

[R-pkg-devel] CRAN pretest archived because of 2 NOTEs

[Gertjan van den Burg]

While waiting to get this message posted to the list, I've solved the 
problem by copying the stdlib rand() and srand() functions into my 
package under a different name. This makes the check pass and ensures my 
RNG does not interfere with R's RNG.


I do think that if this NOTE causes immediate dismissal of a package, it 
shouldn't be a NOTE but an ERROR. Otherwise it just leads to a lot of 
wasted time waiting for a reply from the maintainers to respond to the note.



Dear all,

My CRAN submission doesn't pass the pre-tests and gets archived. I've
emailed cran-submissi...@r-project.org explaining that these are false
positives, but since I haven't heard back in 10 days I don't think anyone
read that. Same thing for the submission comments (which also explained it).

The first note is:

* checking CRAN incoming feasibility ... NOTE
Maintainer: ‘Gertjan van den Burg ’

New submission

Possibly mis-spelled words in DESCRIPTION:
   GenSVM (8:18, 10:61, 15:2, 16:26, 19:11)
   Multiclass (4:22)
   SVMs (14:25, 15:42)
   misclassifications (11:49)
   multiclass (8:53, 14:14, 15:31)


These words are not mis-spelled, so this is a false positive.

The second note is:

* checking compiled code ... NOTE
File ‘gensvm/libs/gensvm_wrapper.so’:
   Found ‘rand’, possibly from ‘rand’ (C)
 Objects: ‘gensvm/src/gensvm_cv_util.o’, ‘gensvm/src/gensvm_init.o’,
   ‘gensvm/lib/libgensvm.a’
   Found ‘srand’, possibly from ‘srand’ (C)
 Objects: ‘gensvm/src/gensvm_train.o’, ‘gensvm/lib/libgensvm.a’

Compiled code should not call entry points which might terminate R nor
write to stdout/stderr instead of to the console, nor use Fortran I/O
nor system RNGs.

See ‘Writing portable packages’ in the ‘Writing R Extensions’ manual.


This is probably why the package is rejected. I have a valid use case for
using rand() and srand(): I'm trying to maintain compatibility of this
package with the corresponding Python package. By using rand en srand users
can reproduce models in both languages.

Does anyone have any ideas on how I can get the package excepted to CRAN?

Thanks,

Gertjan van den Burg



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

Re: [R-pkg-devel] CRAN pretest archived because of 2 NOTEs

[Hadley Wickham]

For the purposes of CRAN submission, you should basically treat every
NOTE as an ERROR.

Hadley

On Wed, Apr 18, 2018 at 3:36 AM, Gertjan van den Burg
 wrote:
> While waiting to get this message posted to the list, I've solved the
> problem by copying the stdlib rand() and srand() functions into my package
> under a different name. This makes the check pass and ensures my RNG does
> not interfere with R's RNG.
>
> I do think that if this NOTE causes immediate dismissal of a package, it
> shouldn't be a NOTE but an ERROR. Otherwise it just leads to a lot of wasted
> time waiting for a reply from the maintainers to respond to the note.
>
>> Dear all,
>>
>> My CRAN submission doesn't pass the pre-tests and gets archived. I've
>> emailed cran-submissi...@r-project.org explaining that these are false
>> positives, but since I haven't heard back in 10 days I don't think anyone
>> read that. Same thing for the submission comments (which also explained
>> it).
>>
>> The first note is:
>>
>> * checking CRAN incoming feasibility ... NOTE
>> Maintainer: ‘Gertjan van den Burg ’
>>
>> New submission
>>
>> Possibly mis-spelled words in DESCRIPTION:
>>GenSVM (8:18, 10:61, 15:2, 16:26, 19:11)
>>Multiclass (4:22)
>>SVMs (14:25, 15:42)
>>misclassifications (11:49)
>>multiclass (8:53, 14:14, 15:31)
>>
>>
>> These words are not mis-spelled, so this is a false positive.
>>
>> The second note is:
>>
>> * checking compiled code ... NOTE
>> File ‘gensvm/libs/gensvm_wrapper.so’:
>>Found ‘rand’, possibly from ‘rand’ (C)
>>  Objects: ‘gensvm/src/gensvm_cv_util.o’, ‘gensvm/src/gensvm_init.o’,
>>‘gensvm/lib/libgensvm.a’
>>Found ‘srand’, possibly from ‘srand’ (C)
>>  Objects: ‘gensvm/src/gensvm_train.o’, ‘gensvm/lib/libgensvm.a’
>>
>> Compiled code should not call entry points which might terminate R nor
>> write to stdout/stderr instead of to the console, nor use Fortran I/O
>> nor system RNGs.
>>
>> See ‘Writing portable packages’ in the ‘Writing R Extensions’ manual.
>>
>>
>> This is probably why the package is rejected. I have a valid use case for
>> using rand() and srand(): I'm trying to maintain compatibility of this
>> package with the corresponding Python package. By using rand en srand
>> users
>> can reproduce models in both languages.
>>
>> Does anyone have any ideas on how I can get the package excepted to CRAN?
>>
>> Thanks,
>>
>> Gertjan van den Burg
>>
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
http://hadley.nz

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

[R-pkg-devel] CRAN pretest archived because of 2 NOTEs

[Gertjan van den Burg]

Thanks for your comment. Your suggestion wouldn't solve my original 
problem unfortunately, because then I'd have to reverse engineer R's RNG 
for my Python package. Besides, the quality of the random numbers 
doesn't really matter here, it only matters that they're the same across 
my packages.


Gertjan

On 04/18/2018 08:00 PM, Dirk Eddelbuettel wrote:

On 18 April 2018 at 11:36, Gertjan van den Burg wrote:
| While waiting to get this message posted to the list, I've solved the
| problem by copying the stdlib rand() and srand() functions into my
| package under a different name. This makes the check pass and ensures my
| RNG does not interfere with R's RNG.

I recommend against that. The check, while dated, is valid because many (old)
implementations of rand and srand were of (now known) poor quality.

You have R, you should use its RNGs. Your users may expect that. Accessing eg
runif is easy and documented, and we can trust the RNG behind it.

Dirk



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

Re: [R-pkg-devel] CRAN pretest archived because of 2 NOTEs

[Iñaki Úcar]

2018-04-18 22:49 GMT+02:00 Gertjan van den Burg :
> Thanks for your comment. Your suggestion wouldn't solve my original problem
> unfortunately, because then I'd have to reverse engineer R's RNG for my
> Python package. Besides, the quality of the random numbers doesn't really
> matter here, it only matters that they're the same across my packages.

You could instead write a vignette instructing the user on how to
replace the default RNG with your SyncRNG. Wouldn't this solve the
problem?

Iñaki

>
> Gertjan
>
> On 04/18/2018 08:00 PM, Dirk Eddelbuettel wrote:
>>
>> On 18 April 2018 at 11:36, Gertjan van den Burg wrote:
>> | While waiting to get this message posted to the list, I've solved the
>> | problem by copying the stdlib rand() and srand() functions into my
>> | package under a different name. This makes the check pass and ensures my
>> | RNG does not interfere with R's RNG.
>>
>> I recommend against that. The check, while dated, is valid because many
>> (old)
>> implementations of rand and srand were of (now known) poor quality.
>>
>> You have R, you should use its RNGs. Your users may expect that. Accessing
>> eg
>> runif is easy and documented, and we can trust the RNG behind it.
>>
>> Dirk
>>
>
> __
> 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] CRAN pretest archived because of 2 NOTEs

[Gertjan van den Burg]

Unless I'm missing something, I don't think this would work. The random 
numbers are generated in the C library and while I could replace the RNG 
I use now with the RNG from SyncRNG, requiring the users to take action 
for this seems to place an unnecessary burden on them.


Gertjan

On 04/18/2018 10:01 PM, Iñaki Úcar wrote:

2018-04-18 22:49 GMT+02:00 Gertjan van den Burg :

Thanks for your comment. Your suggestion wouldn't solve my original problem
unfortunately, because then I'd have to reverse engineer R's RNG for my
Python package. Besides, the quality of the random numbers doesn't really
matter here, it only matters that they're the same across my packages.

You could instead write a vignette instructing the user on how to
replace the default RNG with your SyncRNG. Wouldn't this solve the
problem?

Iñaki


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

Re: [R-pkg-devel] CRAN pretest archived because of 2 NOTEs

[J C Nash]

If NOTEs are going to be treated as errors, then a lot of infrastructure (all my
packages for optimization and nonlinear modelling, which are dependencies of
a few dozen other packages etc.) will disappear. This is because they have 
version
numbering I've been using in some form that pre-dates R and uses -M(M).D(D).
e.g., NOTE "Version contains large components (2018-3.28)"

I believe changing it to a "smaller" value will mean the submission is refused
on an ERROR since the numbering will be out of order.

So perhaps it is time either to revisit NOTEs to drop some unnecessary ones,
and also to make some careful decisions and change critical ones to WARNINGs or
ERRORs.

One of the major concerns I have is that it is desirable that CRAN be the
true repository for R packages, and that increased restrictions -- especially
if unnecessary -- will surely increase the movement to informal distribution
on other platforms like Github. Such fragmentation of the package universe
weakens R as a resource, and we see quite a lot of this recently.

I'm strongly in favour of having fairly strict standards, but also of ensuring
that only necessary restrictions are enforced. Even more, I believe we must
keep working to make satisfying the standards as easy as possible. R has done
a good job of this, but there is always room to improve.

JN




On 2018-04-18 01:40 PM, Hadley Wickham wrote:
> For the purposes of CRAN submission, you should basically treat every
> NOTE as an ERROR.
> 
> Hadley
> 
> On Wed, Apr 18, 2018 at 3:36 AM, Gertjan van den Burg
>  wrote:
>> While waiting to get this message posted to the list, I've solved the
>> problem by copying the stdlib rand() and srand() functions into my package
>> under a different name. This makes the check pass and ensures my RNG does
>> not interfere with R's RNG.
>>
>> I do think that if this NOTE causes immediate dismissal of a package, it
>> shouldn't be a NOTE but an ERROR. Otherwise it just leads to a lot of wasted
>> time waiting for a reply from the maintainers to respond to the note.
>>
>>> Dear all,
>>>
>>> My CRAN submission doesn't pass the pre-tests and gets archived. I've
>>> emailed cran-submissi...@r-project.org explaining that these are false
>>> positives, but since I haven't heard back in 10 days I don't think anyone
>>> read that. Same thing for the submission comments (which also explained
>>> it).
>>>
>>> The first note is:
>>>
>>> * checking CRAN incoming feasibility ... NOTE
>>> Maintainer: ‘Gertjan van den Burg ’
>>>
>>> New submission
>>>
>>> Possibly mis-spelled words in DESCRIPTION:
>>>GenSVM (8:18, 10:61, 15:2, 16:26, 19:11)
>>>Multiclass (4:22)
>>>SVMs (14:25, 15:42)
>>>misclassifications (11:49)
>>>multiclass (8:53, 14:14, 15:31)
>>>
>>>
>>> These words are not mis-spelled, so this is a false positive.
>>>
>>> The second note is:
>>>
>>> * checking compiled code ... NOTE
>>> File ‘gensvm/libs/gensvm_wrapper.so’:
>>>Found ‘rand’, possibly from ‘rand’ (C)
>>>  Objects: ‘gensvm/src/gensvm_cv_util.o’, ‘gensvm/src/gensvm_init.o’,
>>>‘gensvm/lib/libgensvm.a’
>>>Found ‘srand’, possibly from ‘srand’ (C)
>>>  Objects: ‘gensvm/src/gensvm_train.o’, ‘gensvm/lib/libgensvm.a’
>>>
>>> Compiled code should not call entry points which might terminate R nor
>>> write to stdout/stderr instead of to the console, nor use Fortran I/O
>>> nor system RNGs.
>>>
>>> See ‘Writing portable packages’ in the ‘Writing R Extensions’ manual.
>>>
>>>
>>> This is probably why the package is rejected. I have a valid use case for
>>> using rand() and srand(): I'm trying to maintain compatibility of this
>>> package with the corresponding Python package. By using rand en srand
>>> users
>>> can reproduce models in both languages.
>>>
>>> Does anyone have any ideas on how I can get the package excepted to CRAN?
>>>
>>> Thanks,
>>>
>>> Gertjan van den Burg
>>>
>>
>> __
>> 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] CRAN pretest archived because of 2 NOTEs

[Ben Bolker]

  Your points are well taken, but it's also necessary (IMO) for the CRAN
maintainers to have some flexibility, while still being able to hold
package maintainers to account.

   Long-time package maintainers (like you) have some issues that new
submitters don't; the large-component check was "only" instituted three
years ago
.
 As Duncan suggested,
CRAN maintainers are more likely to make allowances for long-time
maintainers ...

  In the spirit of your suggestion, I would say I'd like to see the
information provided by Dirk at
 about providing
defaults/exceptions for the spell-checker made public/official --
several recent posts have shown package maintainers getting distracted
by spell-check false positives and missing potentially more serious
NOTEs.  (This information may exist elsewhere, but I couldn't find it
either in "Writing R Extensions" or the CRAN Repository Policy ...)


On 2018-04-18 02:13 PM, J C Nash wrote:
> If NOTEs are going to be treated as errors, then a lot of infrastructure (all 
> my
> packages for optimization and nonlinear modelling, which are dependencies of
> a few dozen other packages etc.) will disappear. This is because they have 
> version
> numbering I've been using in some form that pre-dates R and uses 
> -M(M).D(D).
> e.g., NOTE "Version contains large components (2018-3.28)"
> 
> I believe changing it to a "smaller" value will mean the submission is refused
> on an ERROR since the numbering will be out of order.
> 
> So perhaps it is time either to revisit NOTEs to drop some unnecessary ones,
> and also to make some careful decisions and change critical ones to WARNINGs 
> or
> ERRORs.
> 
> One of the major concerns I have is that it is desirable that CRAN be the
> true repository for R packages, and that increased restrictions -- especially
> if unnecessary -- will surely increase the movement to informal distribution
> on other platforms like Github. Such fragmentation of the package universe
> weakens R as a resource, and we see quite a lot of this recently.
> 
> I'm strongly in favour of having fairly strict standards, but also of ensuring
> that only necessary restrictions are enforced. Even more, I believe we must
> keep working to make satisfying the standards as easy as possible. R has done
> a good job of this, but there is always room to improve.
> 
> JN
> 
> 
> 
> 
> On 2018-04-18 01:40 PM, Hadley Wickham wrote:
>> For the purposes of CRAN submission, you should basically treat every
>> NOTE as an ERROR.
>>
>> Hadley
>>
>> On Wed, Apr 18, 2018 at 3:36 AM, Gertjan van den Burg
>>  wrote:
>>> While waiting to get this message posted to the list, I've solved the
>>> problem by copying the stdlib rand() and srand() functions into my package
>>> under a different name. This makes the check pass and ensures my RNG does
>>> not interfere with R's RNG.
>>>
>>> I do think that if this NOTE causes immediate dismissal of a package, it
>>> shouldn't be a NOTE but an ERROR. Otherwise it just leads to a lot of wasted
>>> time waiting for a reply from the maintainers to respond to the note.
>>>
 Dear all,

 My CRAN submission doesn't pass the pre-tests and gets archived. I've
 emailed cran-submissi...@r-project.org explaining that these are false
 positives, but since I haven't heard back in 10 days I don't think anyone
 read that. Same thing for the submission comments (which also explained
 it).

 The first note is:

 * checking CRAN incoming feasibility ... NOTE
 Maintainer: ‘Gertjan van den Burg ’

 New submission

 Possibly mis-spelled words in DESCRIPTION:
GenSVM (8:18, 10:61, 15:2, 16:26, 19:11)
Multiclass (4:22)
SVMs (14:25, 15:42)
misclassifications (11:49)
multiclass (8:53, 14:14, 15:31)


 These words are not mis-spelled, so this is a false positive.

 The second note is:

 * checking compiled code ... NOTE
 File ‘gensvm/libs/gensvm_wrapper.so’:
Found ‘rand’, possibly from ‘rand’ (C)
  Objects: ‘gensvm/src/gensvm_cv_util.o’, ‘gensvm/src/gensvm_init.o’,
‘gensvm/lib/libgensvm.a’
Found ‘srand’, possibly from ‘srand’ (C)
  Objects: ‘gensvm/src/gensvm_train.o’, ‘gensvm/lib/libgensvm.a’

 Compiled code should not call entry points which might terminate R nor
 write to stdout/stderr instead of to the console, nor use Fortran I/O
 nor system RNGs.

 See ‘Writing portable packages’ in the ‘Writing R Extensions’ manual.


 This is probably why the package is rejected. I have a valid use case for
 using rand() and srand(): I'm trying to maintain compatibility of this
 package with the corresponding Python package. By using rand en srand
 users
 can reproduce