Re: [R-pkg-devel] Package submission to CRAN not passing incoming checks

[Kasper Daniel Hansen]

1. The version number complaint is the use of 0.1.2-9033. It is complaining
about 9033. Personally, I would not use the - style, but that is a
personal choice I guess. R-exts says
  "The mandatory ‘Version’ field gives the version of the package. This is
a sequence of at least *two* (and usually three) non-negative integers
separated by single ‘.’ or ‘-’ characters. The canonical form is as shown
in the example, and a version such as ‘0.01’ or ‘0.01.0’ will be handled as
if it were ‘0.1-0’. It is *not* a decimal number, so for example 0.9 < 0.75
since 9 < 75."
2. Those are not URLs, they are DOIs. The Rd format has a \doi{} command
you should use
3. If your examples generate files, I would use the tempfile() command from
base R.

On Mon, Apr 22, 2024 at 8:25 PM Petersen, Isaac T <
isaac-t-peter...@uiowa.edu> wrote:

> Dear R-package-devel,
>
> This my first post--I read the posting guidelines, but my apologies in
> advance if I make a mistake.
>
> I am trying to post my R package to CRAN. I just submitted it to CRAN but
> received a note that the package "does not pass the incoming checks
> automatically".
>
> Here are the results from win-builder:
> https://win-builder.r-project.org/incoming_pretest/petersenlab_0.1.2-9033_20240415_212322/
>
> As far as I can tell, there are 3 notes to address. However, I'm not sure
> how to address them.
>
> 1) The first note appears to be "Version contains large components", which
> includes the contents of the LICENSE file (CC BY 4.0). I'm not sure if this
> is a problem that needs to be addressed (or how to address it).
>
> 2) The second note says:
>
> "Found the following (possibly) invalid file URIs:
>   URI: 10.1177/0146621613475471
> From: man/itemInformation.Rd
>   URI: 10.1177/0146621613475471
> From: man/standardErrorIRT.Rd"
>
> However, I verified that those DOIs resolve correctly, so I'm not sure how
> to address this note.
>
> 3) The third note (in the Debian but not Windows version) says:
>
> "* checking for non-standard things in the check directory ... NOTE
> Found the following files/directories:
>   ‘encryptionKey.RData’ ‘encrypytedCredentials.txt’"
>
> These files are generated in the examples for one of the functions to
> demonstrate how to read data using an encryption key:
> https://github.com/DevPsyLab/petersenlab/blob/9ece9d7dc32727c1315a03bc2810cc9c957971d1/R/readEncryptedData.R#L24.
> I'm not sure if this is a problem that needs to be addressed (or how to
> address it).
>
> The source code for my R package (petersenlab) is here:
> https://github.com/DevPsyLab/petersenlab
>
> Thanks very much in advance,
> Isaac
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
Best,
Kasper

[[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] GPL + other licence

[Kasper Daniel Hansen]

There are 3 solutions.  (1) You (get permission) to change the library to
GPL.  (2) You get permission to change the license of the R code to
whatever license the library is released under.  (3) you split the package.

You have investigated (1) and it does not work.  I would suggest thinking
about (2) provided the license of the library is decent.  This is what we
did with Rgraphviz some years ago; Graphviz itself is licensed under the
Eclipse public license and there was no way I could get a company to change
the license of that code.

I would do whatever I can to avoid splitting the package.

Best,
Kasper

On Fri, Apr 6, 2018 at 8:44 PM, David C Sterratt 
wrote:

> Dear all,
>
> I'd appreciate help with a licence conundrum I have with the geometry
> package (https://davidcsterratt.github.io/geometry/) that I maintain.
>
> The geometry package contains some functions (e.g. convhulln(),
> delaunayn()) that wrap the Qhull library (http://www.qhull.org), which
> has its own, non-GPL, licence. The geometry package includes this source
> code, and wraps it in C files that have GPL licence headers.
>
> The geometry package also has functions that are not derived from Qhull
> code and which are licensed under GPL, including a number of functions
> that are ports of the Matlab distmesh package, and some other useful
> functions to do with triangulation and coordinate systems (e.g.
> tsearch() and cart2bary()).
>
> I inherited this situation when I took over maintaining the package 8
> years ago, though I have added functions to both Qhull-derived and GPL
> categories.
>
> In October last year I submitted the latest version of the geometry
> package, which adds quite a bit of useful functionality:
> https://github.com/davidcsterratt/geometry/blob/master/pkg/NEWS
>
> I received the following response from the CRAN maintainers:
>
>   For the license. It is CRAN policy that a package has to have a single
>   license. Can you manage to convince all copyright hoders (e.g. of
>   Qhull) to relicense under GPL?
>
> I tried persuading the author of Qhull. He replied:
>
>   There's only one license and that's the one included with the code
>   (COPYING.txt). Several years ago, I tried to clarify the license with
>   the Univ. of Minn. but had no success. So I think the best approach is
>   to keep the original license as is. It has not been an issue so far.
>
> At the same time as I wrote to the Qhull maintainer, I wrote to the CRAN
> maintainers:
>
>   I have written to the Qhull maintainer, but I doubt he will want to
>   change the license, since Qhull is used in proprietary software such
>   as MATLAB. Assuming this is the case, we'll have to create a new
>   package - I would need help with managing the change for dependent
>   packages.
>
> The CRAN maintainers replied:
>
>   Please try to find out how this can work.
>
> In principle I could create a package containing only the functions
> derived from Qhull (but still with GPL headers in the wrapper C files,
> see e.g.,
> https://github.com/davidcsterratt/geometry/blob/
> master/pkg/src/Rconvhulln.c
> But wouldn't this package still have to have two licenses, due to the
> GPL headers?
>
> I don't want to start on any package splitting without having a plan
> agreed that I know will be OK for CRAN. It would be quite a bit of work,
> as there are a number of packages that depend on geometry, so I would
> have to check all the revdeps for functions that they call in the
> geometry package. I would have to then perhaps write wrapper functions
> in the geometry package to make sure any functions moved to a new
> package still worked when called from revdeps.
>
> I know the CRAN maintainers are busy, so any help from the list would be
> much appreciated.
>
> Best wishes,
>
> David.
>
> --
> David C Sterratt, Senior Research Associate
> Institute for Adaptive and Neural Computation, School of Informatics
> University of Edinburgh, 10 Crichton Street, Edinburgh EH8 9AB, Scotland,
> UK
> http://homepages.inf.ed.ac.uk/sterratt - tel: +44 131 651 1739
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
> __
> 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] multiple bibentry()s in CITATION

[Kasper Daniel Hansen]

I apologize for not being clear.  The printing of header depends on the
output style.  Indeed text works, but say
  print(citation("minfi"), style = "HTML")
does not.  Btw., I agree it might be nice to control the printing of header.

On Mon, Mar 27, 2017 at 9:07 AM, Achim Zeileis <achim.zeil...@uibk.ac.at>
wrote:

> On Mon, 27 Mar 2017, Kasper Daniel Hansen wrote:
>
> Thanks.  It would be great to have this working in 3.4.  In Bioc there are
>> multiple packages with CITATION files with multiple entries, one such
>> example is minfi
>>  bioconductor.org/packages/minfi
>>
>> On my wishlist is that it would be great to have support for printing the
>> header field which many people use to give a context for the citation. This
>> is important because when you list multiple papers you need (I think) some
>> explanation for when to cite the different ones.
>>
>
> But this is what citation("pkg_name") or print(bibentry_object, style =
> "citation") already do or am I missing something.
>
> I haven't installed "minfi" but just sourced the CITATION into an object x
> and the print(x, style = "citation") seemed to work as intended.
>
> But this is probably a good example where even adding four BibTeX items
> leads to scrolling even on console windows with many lines and columns. In
> these cases it would likely be better not to display any BibTeX and rather
> add a hint as to how the BibTeX can be obtained if desired. In addition to
> Martin's idea with 'citation(package="pkg", bibtex.max=Inf)' one could also
> use 'toBibtex(citation("pkg"))'. The latter, of course, only gives the
> BibTeX but again for long lists like the one in minfi it is probably more
> digestable in separate chunks...
>
> Best,
> Z
>
> Best,
>> Kasper
>>
>> On Mon, Mar 27, 2017 at 7:25 AM, Martin Maechler <
>> maech...@stat.math.ethz.ch
>>
>>> wrote:
>>>
>>
>> Fox, John <j...@mcmaster.ca>
>>>>>>>> on Mon, 16 Jan 2017 15:44:05 + writes:
>>>>>>>>
>>>>>>>
>>>> Dear Martin,
>>>> Thanks for addressing this question, if belatedly!
>>>
>>>> After a little bit of thought, perhaps a default somewhere between 1
>>> and Inf makes sense, along with an additional argument to citation:
>>> citation(package="pkg", bibtex.max=n), with default bibtex.max=
>>> getOption("citation.bibtex.max"), where the citation.bibtex.max option
>>> is
>>> initially set to something like 4. If the number of available citations
>>> exceeds bibtex.max, then a message like "there are additional BiBTeX
>>> citations, enter 'citation(package="pkg", bibtex.max=Inf)' to see all of
>>> them."
>>>
>>> In the mean time, I have always used my proposed change.
>>> I think any number between 1 and Inf is so much arbitrary that
>>> inspite of your good thoughts I kept the *new* default at Inf.
>>>
>>> and because of this open question, I have forgotten to commit
>>> the change to the development version of R !
>>>
>>> I have done so now, however not ported it yet to  "R 3.4.0 alpha".
>>> If not much surfaces (in CRAN / Bioc checks), we may port it in
>>> time for 3.4.0.
>>>
>>>
>>> Martin
>>>
>>>> Best,
>>>> John
>>>
>>>>> -Original Message-
>>>>> From: Martin Maechler [mailto:maech...@stat.math.ethz.ch]
>>>>> Sent: Monday, January 16, 2017 10:02 AM
>>>>> To: Fox, John <j...@mcmaster.ca>
>>>>> Cc: r-package-devel@r-project.org
>>>>> Subject: Re: [R-pkg-devel] multiple bibentry()s in CITATION
>>>>>
>>>>>>>>>> Fox, John <j...@mcmaster.ca>
>>>>>>>>>> on Fri, 2 Sep 2016 15:42:46 + writes:
>>>>>
>>>>> (which is more than 4 months ago)
>>>>>
>>>>>> Dear list members,
>>>>>> I've noticed that citation(package="pkg") generates both a text
>>>>> citation and a BiBTeX entry when the CITATION file contains a
>>> single
>>>>> call to bibentry() or citEntry(), but that only text citations are
>>> shown
>>>>> if there are multiple calls to bibentry() or citEntry().
>>>>>

Re: [R-pkg-devel] multiple bibentry()s in CITATION

[Kasper Daniel Hansen]

Thanks.  It would be great to have this working in 3.4.  In Bioc there are
multiple packages with CITATION files with multiple entries, one such
example is minfi
  bioconductor.org/packages/minfi

On my wishlist is that it would be great to have support for printing the
header field which many people use to give a context for the citation. This
is important because when you list multiple papers you need (I think) some
explanation for when to cite the different ones.

Best,
Kasper

On Mon, Mar 27, 2017 at 7:25 AM, Martin Maechler  wrote:

> > Fox, John 
> > on Mon, 16 Jan 2017 15:44:05 + writes:
>
> > Dear Martin,
> > Thanks for addressing this question, if belatedly!
>
> > After a little bit of thought, perhaps a default somewhere between 1
> and Inf makes sense, along with an additional argument to citation:
> citation(package="pkg", bibtex.max=n), with default bibtex.max=
> getOption("citation.bibtex.max"), where the citation.bibtex.max option is
> initially set to something like 4. If the number of available citations
> exceeds bibtex.max, then a message like "there are additional BiBTeX
> citations, enter 'citation(package="pkg", bibtex.max=Inf)' to see all of
> them."
>
> In the mean time, I have always used my proposed change.
> I think any number between 1 and Inf is so much arbitrary that
> inspite of your good thoughts I kept the *new* default at Inf.
>
> and because of this open question, I have forgotten to commit
> the change to the development version of R !
>
> I have done so now, however not ported it yet to  "R 3.4.0 alpha".
> If not much surfaces (in CRAN / Bioc checks), we may port it in
> time for 3.4.0.
>
>
> Martin
>
> > Best,
> > John
>
> >> -Original Message-
> >> From: Martin Maechler [mailto:maech...@stat.math.ethz.ch]
> >> Sent: Monday, January 16, 2017 10:02 AM
> >> To: Fox, John 
> >> Cc: r-package-devel@r-project.org
> >> Subject: Re: [R-pkg-devel] multiple bibentry()s in CITATION
> >>
> >> > Fox, John 
> >> > on Fri, 2 Sep 2016 15:42:46 + writes:
> >>
> >> (which is more than 4 months ago)
> >>
> >> > Dear list members,
> >> > I've noticed that citation(package="pkg") generates both a text
> >> citation and a BiBTeX entry when the CITATION file contains a single
> >> call to bibentry() or citEntry(), but that only text citations are
> shown
> >> if there are multiple calls to bibentry() or citEntry().
> >>
> >> > Is this behaviour intentional? In my opinion, it's useful always
> >> to show the BiBTeX (although it's available through
> >> toBibtex(citation(package="pkg")) ).
> >>
> >> > The Writing R Extensions manual says, "A CITATION file will
> >> contain *calls* [my emphasis] to function bibentry."
> >>
> >> > Thanks,
> >> > John
> >>
> >> and you did not get a reply
> >> I had wanted but forgotten about it ... two parts :
> >>
> >> 1)  On November 24, 2012,  I had improved R with an option to get
> this
> >> so this has been a "hidden gem" ;-) for a while in R:
> >>
> >> > options(citation.bibtex.max = Inf)
> >> > citation(package = "Rcmdr")
> >>
> >> To cite the 'Rcmdr' package in publications use:
> >>
> >> Fox, J., and Bouchet-Valat, M. (2017). Rcmdr: R Commander. R package
> >> version 2.3-2.
> >>
> >> A BibTeX entry for LaTeX users is
> >>
> >> @Manual{,
> >> title = {{Rcmdr: R Commander}},
> >> author = {John Fox and Milan Bouchet-Valat},
> >> year = {2017},
> >> note = {R package version 2.3-2},
> >> url = {http://socserv.socsci.mcmaster.ca/jfox/Misc/Rcmdr/},
> >> }
> >>
> >> Fox, J. (2017). Using the R Commander: A Point-and-Click Interface
> or
> >> R. Boca Raton FL:
> >> Chapman and Hall/CRC Press.
> >>
> >> A BibTeX entry for LaTeX users is
> >>
> >> @Book{,
> >> title = {Using the {R Commander}: A Point-and-Click Interface for
> >> {R}},
> >> author = {John Fox},
> >> year = {2017},
> >> publisher = {Chapman and Hall/CRC Press},
> >> address = {Boca Raton {FL}},
> >> url = {http://socserv.mcmaster.ca/jfox/Books/RCommander/},
> >> }
> >>
> >> Fox, J. (2005). The R Commander: A Basic Statistics Graphical User
> >> Interface to R.
> >> Journal of Statistical Software, 14(9): 1--42.
> >>
> >> A BibTeX entry for LaTeX users is
> >>
> >> @Article{,
> >> title = {The {R} {C}ommander: A Basic Statistics Graphical User
> >> Interface to {R}},
> >> author = {John Fox},
> >> year = {2005},
> >> journal = {Journal of Statistical Software},
> >> volume = {14},
> >> number = {9},
> >> pages = {1--42},
> >> url = {http://www.jstatsoft.org/v14/i09},
> >> }
> >>
> >> >
> >> 

Re: [R-pkg-devel] Weird MAKEFLAGS bug

[Kasper Daniel Hansen]

For a package, you should not mess with the optimization flag unless you
are disabling high optimization because it produces wrong code.  If people
want to use higher optimization flags, they'll compile with higher flags.

On Tue, Jan 10, 2017 at 3:39 PM, Costas Tsirogiannis 
wrote:

> Thanks a lot, indeed it worked using the Makevars file. I still do not
> understand why the command-line input fails but so be it.
>
> One more quick question: if I include the Makevars file in my package code
> then the requested flags are used every time somebody installs my package
> in his system. However, -O2 is a gcc-specific flag so it won't work for
> every compiler. Is there a simple way to declare another optimization flag
> in Makevars, that works for all compilers?
>
> Thanks for all the help,
>
> --Constantinos
>
> On 10 January 2017 at 12:39, Dirk Eddelbuettel  wrote:
>
> >
> > On 10 January 2017 at 11:55, Costas Tsirogiannis wrote:
> > | Greetings and thanks for previously offered solutions,
> > |
> > | I am developing a package that makes use of C++ code, and I want to
> > compile
> > | this code for testing reasons with the "R CMD SHLIB" command. Using
> > Ubuntu
> > | and gcc 5.4, and because for certain reasons I have to use the c++0x
> > | standard, I try the following command:
> > |
> > | > MAKEFLAGS='CXXFLAGS=-std=c++0x -lpthread -O2' R CMD SHLIB
> > MyMainCode.cpp
> > |
> > | For some weird reason, flag -O2 is not recognized properly and I get
> the
> > | following error message:
> > |
> > | > make: *** unknown output-sync type '2'.  Stop.
> > |
> > | If I try -O3, I get "unknown output-sync type '3' ", and so on.
> > Everything
> > | works fine if I drop this optimization flag. Could you suggest a
> > workaround
> > | for that?
> >
> > Sounds weird. Wonder if something else could go on here.
> >
> > But in general, using ~/.R/Makevars is better.  Try that.
> >
> > edd@max:~$ grep FLAGS ~/.R/Makevars | grep -v "^#"
> > CFLAGS +=  -O3 -Wall -pipe -pedantic -std=gnu99
> > CXXFLAGS +=   -O3 -Wall -pipe -Wno-unused -pedantic
> > FFLAGS += -O3 -g0 -Wall -pipe
> > FCFLAGS += -O3 -g0 -Wall -pipe
> > CXX1XFLAGS=-O3 -Wall -pipe -Wno-unused -pedantic
> > FLAGS=-Wall -O3
> > DYLIB_LDFLAGS = -Wl,-S -shared -fopenmp# $(CFLAGS) $(CPICFLAGS)
> > SHLIB_CXXLDFLAGS = -Wl,-S -shared
> > SHLIB_CXX1XLDFLAGS = -Wl,-S -shared
> > SHLIB_FCLDFLAGS = -Wl,-S -shared
> > SHLIB_LDFLAGS = -Wl,-S -shared# $(CFLAGS) $(CPICFLAGS)
> > edd@max:~$
> >
> > Dirk
> >
> > --
> > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> >
>
> [[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] Wrapping a third-party c++ library

[Kasper Daniel Hansen]

Remember there are no rules for a configure script, there is only the
tradition that it is a script you invoke prior to make.  "Hand-written"
configure scripts can do anything they want.  In this case, I had a 2s look
at the configure script in the ngs project which ultimately are a series of
"konfigure.perl" scripts which may be hand written.  It is hard to even
know what options the script supports without reading the code. My perl is
rusty but the perl script seems to reference build-prefix and prefix.
Also, see the wiki
  https://github.com/ncbi/ngs/wiki/Building-and-Installing-from-Source
You should look carefully at ./configure --help, but I am sure you know all
this.

This could indeed be painful.  Probably doable, assuming infinite time
though.

Best,
Kasper



On Tue, Aug 23, 2016 at 11:13 AM, Sean Davis  wrote:

> Thanks for the reply and feedback, Dirk.
>
> > On Aug 23, 2016, at 10:59 AM, Dirk Eddelbuettel  wrote:
> >
> >
> > hi Sean,
> >
> > On 23 August 2016 at 09:13, Sean Davis wrote:
> > | I am trying to wrap a third-party toolkit that provides a C++ API.
> The code is open source and includes a license that allows me to include it
> directly in an R package.  Right now, I am happy if I can get ANY build
> (linux, windows, or Mac) working.  The rough build process looks like that
> given here (starting at the highlighted line):
> > |
> > | https://github.com/seandavi/SRA2R/blob/master/inst/docker/
> install_ngs_sdk.sh#L22
> > |
> > | Unfortunately, these configure scripts are not standard autoconfig
> flavor, so they seem pretty fragile (even with a —prefix, they try to
> install stuff into system libraries).  My goal is to include the source of
> the two partner libraries and build shared libraries in the R installation
> hierarchy.  I simply do not have enough experience using configure scripts
> to know how to translate what I have noted above into something that would
> be expected to get the installation right in the r package directory and
> allow linking.
> > |
> > | Any concrete suggestions about how to move this forward are much
> appreciated.
> >
> > Local shared libraries is hard(est). I would not start there.
> >
> > System shared libraries is easy (just ask all the database packages,
> graphics
> > formats packages etc pp) -- but you then push the burden onto your users
> to
> > actually *have* these system libraries.  Not easy with "obscure" science
> stuff.
>
> It is complicated further by the fact that the group who develops this
> software distributes it as binaries to many users.
>
> > Middle ground: _static_ library in your package.  Tweak and bend the
> required
> > libraries til they cooperate, then adjust.  This has been done since time
> > immortal, see eg the Matrix package and its several subdirectories.
> Still
> > not trivial, but doable.
>
> Probably beyond my patience level, but….
>
> > Easiest 'dirty' solution: throw all source files into your package's
> src/ and
> > hope for the best.  Works for small packages.
>
> Yeah, I have tried that in the past and perhaps after some cleanup the
> code can get there.
>
> > Long story short: for something complicated like this, maybe a Docker
> > container is the best you can do :-/
>
> Yeah, docker is what I have been living with for months and it is a great
> solution for development, but moving that paradigm the the standard
> scientific HPC environment just isn’t happening despite all the problems it
> would potentially bypass.
>
> Nice to know that, while my R foo is limited compared to others on this
> list, I am not crazy to think that this might be hard.
>
> Sean
>
>
> >
> > Dirk
> >
> > --
> > 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

Re: [R-pkg-devel] relation between vignettes and help files

[Kasper Daniel Hansen]

Well, I think it would be a headache, and suboptimal, to require vignettes
to be renderable as text.  There are several issues including that not all
vignettes have an included "source" file; there are packages with important
vignettes which are only available as PDFs (or HTML).  Also math and plot
rendering.  I don't think this is what Martin was alluding to.

But being able to link between the help files and the vignettes would be
great.  In Bioconductor we have been using vignettes for ages and they
contain a lot of extremely useful information, to the extent that I would
always first look at the vignette and only look at the Rd file for
technical details.

Best,
Kasper



On Fri, Jul 15, 2016 at 1:23 PM, Boylan, Ross  wrote:

> One issue with integrating vignettes into the help system is that
> vignettes are
> more likely to have material (figures, math) that renders poorly or not at
> all as text.
> I also mostly use ESS on terminal rather than graphical interface, and so
> like the  plain text version of things.  OTOH, I used Sweave specifically
> so
> I could put math in the vignette.
>
> Does anyone have any thoughts about the substantive division of info
> between help files and
> vignettes?
> Ross
> 
> From: Martin Maechler [maech...@stat.math.ethz.ch]
> Sent: Friday, July 15, 2016 5:32 AM
> To: Duncan Murdoch
> Cc: Enrico Schumann; Boylan, Ross; r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] relation between vignettes and help files
>
> ..
> It is even worse, isn't it: Nowadays html help pages are (almost)
> always created *dynamically* via R's help() or help.start();
> For my setup of 1000s of packages in my libraries in .libPaths(),
> generating all the html pages is too costly
> [I think Rstudio is now smart and does this in the background
>  for its *own* package data base ?? -- I wish we would enable to
>  do this easily in base R !]
>
> and I am using (ESS with) "text" help_type, and so these links
> to the url in doc/html  would not work for me.
>
> I wonder if we should not think harder about this, and provide a
> portable solution.
>
> I do agree that it should be very desirable to have links portably,
> in *both* directions between
>   our "reference manuals"  ( = the help pages)  and
>   our "user's manuals" ( = the vignettes ).
>
> Martin
>
> __
> 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] Creating Accessor Methods

[Kasper Daniel Hansen]

Creating functions that looks like they have the same name, but have
different internals is exactly (one of) the purposes of having methods.

Best,
Kasper

On Thu, Mar 10, 2016 at 4:04 PM, Glenn Schultz  wrote:

> Hello Joris,
>
> Thank worked perfectly.  My main concern was that I was creating multiple
> methods which may have the same name but different signature. Just over
> thinking things I guess but I appreciate your time answering my question.
>
> Glenn
>
> > On Mar 10, 2016, at 8:13 AM, Joris Meys  wrote:
> >
> > Hi Glenn,
> >
> > that is actually as easy as defining a generic and defining a method for
> each class to extract the slot. I do this literally in every package I
> write.
> >
> > setGeneric('duration', function(x, ...) standardGeneric('duration')
> >
> > setMethod('duration', signature = 'MBSCashFlow', function(x) { x@Duration
> })
> > setMethod('duration', signature = 'REMICCashFlow', function(x)
> {x@Duration})
> > etc...
> >
> > I suggest you take a close look at Hadley Wickham's books 'Advanced R'
> and 'R packages', both freely available online.
> >
> > This is the relevant section of the first book :
> http://adv-r.had.co.nz/OO-essentials.html <
> http://adv-r.had.co.nz/OO-essentials.html>
> > This is the other book : http://r-pkgs.had.co.nz/ <
> http://r-pkgs.had.co.nz/>
> >
> > Cheers
> > Joris
> >
> > On Thu, Mar 10, 2016 at 3:05 PM, Glenn Schultz  > wrote:
> > All,
> >
> > I have a package with to S4 classes (MBSCashFlow, REMICCashFlow and
> BondCashFlow) all of which contain the slot Duration.  I would like have an
> accessor Duration that would work on multiple signatures.  Is this
> possible?  I have checked my books, help, BioConductor tutorials and it
> appears that this is not possible.  Has anyone ever run into this situation?
> >
> > Best Glenn
> > __
> > R-package-devel@r-project.org 
> mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel <
> https://stat.ethz.ch/mailman/listinfo/r-package-devel>
> >
> >
> >
> > --
> > Joris Meys
> > Statistical consultant
> >
> > Ghent University
> > Faculty of Bioscience Engineering
> > Department of Mathematical Modelling, Statistics and Bio-Informatics
> >
> > tel : +32 9 264 59 87
> > joris.m...@ugent.be
> > ---
> > Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php <
> http://helpdesk.ugent.be/e-maildisclaimer.php>
>
> [[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] Running tests on 32-bit and 64-bit

[Kasper Daniel Hansen]

Perhaps related: in the Bioconductor minfi package I do some checking on
somewhat large matrices (450,000 times n).  To save space, I compute a hash
of the correct result using the digest package.  As you, I ran into obvious
issues with precision across platforms.  To solve this, I take the matrix
and run it through sprintf() with (my choice) 6 digits and then I hash the
resulting character matrix.  It works pretty nice for my purpose.

You find minfi on github.  Code is in
  inst/unitTests/test_preprocess.R  (testing using Runit)
  inst/testData/testData/testData_preprocessQuantile.R (creating the
reference correct matrix - this is only intended to be re-run when the
algorithm change)
  R/utils.R for the two convenience functions .digestMatrix and
.digestVector

Best,
Kasper

On Mon, Aug 17, 2015 at 5:03 AM, Thierry Onkelinx thierry.onkel...@inbo.be
wrote:

 Dear all,

 Is there an easy way to run the tests of a package on both a 32-bit and
 64-bit version? Ideally it should work when using R CMD check --as-cran on
 all OS's. Although I expect that multi architecture versions are only
 available on windows. So a Windows only solution will be fine as well.

 The origin of the problem is that I calculate some SHA1 hashed on objects
 containing floating point numbers. The floating points have different
 precision on 32-bit and 64-bit, and thus different hashes. I'm trying to
 work around that problem. And thus need an easy way to run tests on both
 32-bit and 64-bit.

 Best regards,

 ir. Thierry Onkelinx
 Instituut voor natuur- en bosonderzoek / Research Institute for Nature and
 Forest
 team Biometrie  Kwaliteitszorg / team Biometrics  Quality Assurance
 Kliniekstraat 25
 1070 Anderlecht
 Belgium

 To call in the statistician after the experiment is done may be no more
 than asking him to perform a post-mortem examination: he may be able to say
 what the experiment died of. ~ Sir Ronald Aylmer Fisher
 The plural of anecdote is not data. ~ Roger Brinner
 The combination of some data and an aching desire for an answer does not
 ensure that a reasonable answer can be extracted from a given body of data.
 ~ John Tukey

 [[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