[R-pkg-devel] recommendation: codetoolsBioC

2015-07-13 Thread Kasper Daniel Hansen
With the new NAMESPACE requirements of importing everything in the bundled
packages I would like to recommend using
  writeNamespaceImports
from codetoolsBioC.  This analyzes your code and produces a NAMESPACE file
with all imports.  Of course, you might benefit from checking it manually.

This package is from Bioconductor, but you need to check it out from svn
(it was never officially released).

svn co
https://hedgehog.fhcrc.org/gentleman/bioconductor/trunk/madman/Rpacks/codetoolsBioC


Perhaps similar tools exists elsewhere now; this package has been around
for quite a while.

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] Running tests on 32-bit and 64-bit

2015-08-17 Thread 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 
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


Re: [R-pkg-devel] Creating Accessor Methods

2016-03-10 Thread 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] set generic and methods when slot is a function

2016-03-28 Thread Kasper Daniel Hansen
This syntax
  Omega(x = 1)
seems weird.  How do you know that this call should refer back to the Model
object and not some other hypothetical Model2 object?  The code you're
defining should make something like this work
  Omega(Model)(x=1)
where you can see the direct dependence on the Model object.

(unrelated: One experience from Bioconductor, is that it is good to have
explicit constructors for S4 objects instead of using new("...").)

Best,
Kasper

On Mon, Mar 28, 2016 at 2:09 PM, Glenn Schultz  wrote:

> All,
> I am creating a mortgage prepayment model package.  The idea is to create
> a class FRMModelFunction and each slot in the class is a function that may
> be use in the prepayment. So I would like to create a generic and method
> that will allow me to call the slot by name.  However, I think that I am
> missing something in my setup
>
> If I run the below code I can do the following
>
> Omega(Model) which returns the function
>
> Omega <- Omega(Model) which then assigns the function and allows me to
> pass values and get a result from Omega(x = 1)
>
> However I can also get a result by directly accessing the slot
>
> Model@Omega(x=1)
>
> What I want to do is set a generic and method so that I can do the
> following
>
> Omega(x=1)
>
> The below is close but still not what I would like to have.  Is what  I
> have described possible and if so what have I missed?
>
> Glenn
>
>
> setGeneric("Omega", function(object,...) {standardGeneric("Omega")})
>
>  setMethod("Omega", signature = "FRMModelFunction",
>definition = function(object){object@Omega})
>
>  setClass("FRMModelFunction",
>   representation(
> Omega = "function"))
>
>  Model <- new("FRMModelFunction",
>Omega = function(x = numeric()) {return(max(0, min(1, x)))}
>)
> __
> 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] Data for unit testing in packages

2016-05-20 Thread Kasper Daniel Hansen
Very similar here.  I use the RUnit framework, which has testing scripts in
  inst/unitTests

I put scripts for creating the test data in
  inst/testData
and save rda files into
  inst/unitTests

I create the data set by R CMD BATCH and I save the .Rout file which
creates the test data, so I have a record of which packages / versions was
used to create it.

Kasper

On Fri, May 20, 2016 at 2:34 PM, Ben Bolker  wrote:

>
>   I usually put it in inst/testdata and access it via system.file()
>
>
> On 16-05-20 01:45 PM, carlos cinelli wrote:
> > Do you guys have any suggestions on how to store data for unit testing?
> >
> > I am implementing some methods to estimate matrix entries from the
> > marginals.  The input of the function is the row and column sums and the
> > output is a N x N matrix.
> >
> > What I am doing today is constructing the expected output by hand.
> >
> > One example I am testing is a 7 x 7 matrix, which is fine to just put the
> > code to create it on the test script.
> >
> > However, I also want to create tests on larger examples, say a 1000 x
> 1000
> > matrix, in which it would not be very handy to leave the code on the
> script.
> >
> > Do you have any suggestions or best practices for that?
> >
> > Best,
> >
> > Carlos
> >
> >   [[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
>

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

2016-07-15 Thread 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] Wrapping a third-party c++ library

2016-08-23 Thread 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] Weird MAKEFLAGS bug

2017-01-11 Thread 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] no visible global function definition for ‘par’

2017-01-30 Thread Kasper Daniel Hansen
On Mon, Jan 30, 2017 at 12:04 PM, Cathy Lee Gierke  wrote:

> That is the obvious solution, but it doesn't seem correct:  I have pdf
> included in the description, and namespace files, yet it is being called
> out.  Additionally, aren't most of these pkgs in the packages included by
> default?
>

No, they are not. Read the documentation and see the error

And up until yesterday, I didn't have any of these problems.  I've been
> compiling and running this for several years.  But now I want to release to
> CRAN, so I've been fixing minor issuesand suddenly this mass of Notes.
>

I have no idea what you did previously to ignore this. But the
behaviour/error you see is always caused by an incomplete NAMESPACE; its
very common.

Perhaps follow the advice from all the other replies.

Best,
Kasper



> Thank you,
>
> Cathy Lee Gierke
>
>
> *“Darkness cannot drive out darkness: only light can do that. Hate cannot
> drive out hate: only love can do that.” *
> *“The arc of the moral universe is long, but it bends towards justice.”*
> *“Nothing in the world is more dangerous than sincere ignorance and
> conscientious stupidity.” *
> *“Never forget that everything Hitler did in Germany was legal.”   *
> *“Forgiveness is not an occasional act, it is a constant attitude.” *
> *“Injustice anywhere is a threat to justice everywhere.”  *
>
> ― Martin Luther King Jr.
>
> 
>
> On Mon, Jan 30, 2017 at 10:52 AM, Brian G. Peterson 
> wrote:
>
> > The error you reference below is pretty clear, I think.
> >
> > You need to add imports for all the functions you're using from other
> > packages.
> >
> > See: https://cran.r-project.org/doc/manuals/r-release/R-exts.
> > html#Specifying-imports-and-exports
> >
> > Regards,
> >
> > Brian
> >
> >
> > --
> > Brian G. Petersonhttp://braverock.com/brian/
> > Ph: 773-459-4973 <(773)%20459-4973>
> > IM: bgpbraverock
> >
> >
> > On Mon, 2017-01-30 at 10:39 -0600, Cathy Lee Gierke wrote:
> >
> > Yes, that seemed to get rid of the NOTEbut it doesn't seem to make
> > much difference other than that.  i.e., it seems to process the same
> using
> > CATkit vs CATkit_2.06.tar.gz!
> >
> > Here is the main error that I am getting.  I just upgraded to the latest
> R
> > version, fyi.
> >
> > Everything was fine, a few minor warnings...now this.  Description and
> > namespace are proper.  These pkgs should all be part of the R base,
> aren't
> > they? Anyone know why I should get these errors?  Thanks!
> >
> > * checking R code for possible problems ... NOTE
> >
> > Actogram: no visible global function definition for ‘par’
> >
> > Actogram: no visible global function definition for ‘barplot’
> >
> > Actogram: no visible global function definition for ‘box’
> >
> > Actogram: no visible global function definition for ‘text’
> >
> > Actogram: no visible global function definition for ‘mtext’
> >
> > Actogram: no visible binding for global variable ‘end’
> >
> > AutoCorr: no visible global function definition for ‘par’
> >
> > AutoCorr: no visible global function definition for ‘layout’
> >
> > AutoCorr: no visible global function definition for ‘acf’
> >
> > AutoCorr: no visible global function definition for ‘abline’
> >
> > AutoCorr: no visible global function definition for ‘title’
> >
> > AutoCorr: no visible global function definition for ‘mtext’
> >
> > AutoCorr: no visible global function definition for ‘var’
> >
> > AutoCorr: no visible binding for global variable ‘end’
> >
> > CATCosinor: no visible global function definition for ‘par’
> >
> > CATCosinor: no visible global function definition for ‘pdf’
> >
> > CATCosinor: no visible global function definition for ‘jpeg’
> >
> > CATCosinor: no visible global function definition for ‘png’
> >
> > CATCosinor: no visible global function definition for ‘tiff’
> >
> > . A zillion more for every function I have..
> >
> > periCosinor: no visible global function definition for ‘par’
> >
> > periCosinor: no visible global function definition for ‘fft’
> >
> > Undefined global functions or variables:
> >
> >   TukeyHSD abline acf aov as.raster axis barplot box boxplot ccf
> >
> >   coefficients dev.cur dev.off drop1 end fft gray heat.colors image
> >
> >   jpeg layout legend lines median model.tables mtext na.action na.omit
> >
> >   palette par pdf pf plot plot.new png points rainbow rasterImage
> >
> >   read.table str strwidth tail terrain.colors text tiff title ts var
> >
> >   write.table
> >
> > Consider adding
> >
> >   importFrom("grDevices", "as.raster", "dev.cur", "dev.off", "gray",
> >
> >  "heat.colors", "jpeg", "palette", "pdf", "png", "rainbow",
> >
> >  "terrain.colors", "tiff")
> >
> >   importFrom("graphics", "abline", "axis", "barplot", "box", "boxplot",
> >
> >  "image", "layout", "legend", "lines", "mtext", "par",
> >
> >  "plot", "plot.new", "points", "rasterImage", "strwidth",
> >
> >  "text"

Re: [R-pkg-devel] While using R CMD check: LaTex error: File `inconsolata.sty' not found

2017-02-05 Thread Kasper Daniel Hansen
If you installed MacTex basic, you should have the command line utility
  tlmgr
available. On my system it is in
  /Library/TeX/texbin/tlmgr
and you may need to add this to your path. Using this, it is simple to
install additional packages, by
  tlmgr install inconsolata
You probably need to add a sudo to this, so the full command becomes
  sudo tlmgr install inconsolata

(depending on how old MacTex is compared to recent releases, you _may_ need
to update tlmgr itself first.  I think it will be something like
  tlmgr update --self
but the program will tell you about this when you run it)

Best,
Kasper

On Sun, Feb 5, 2017 at 8:20 AM, Cathy Lee Gierke  wrote:

> I cannot find any recent solution to this problem, and older ones do not
> seem to work.
>
> I just installed the small version of MacTeX called BasicTeX, to allow my
> package to build PDFs.   http://tug.org/mactex/morepackages.html
>
> Everything worked, except I get the error  "LaTex error: File
> `inconsolata.sty' not found".  I tried to install inconsolata.sty as
> suggested here,
> https://stat.ethz.ch/pipermail/r-help//2013-July/356743.html but
> get an error saying zi4 is not there when following the Read.Me install
> instructions:
>
> Mac OS X: Method A (recommended): type
>
> >sudo mkdir -p /usr/local/texlive/texmf-local/web2c
> >sudo cp -Rfp * /usr/local/texlive/texmf-local
> >sudo echo Map zi4.map >> /usr/local/texlive/texmf-local/web2c/updmap.cfg
> >sudo mktexlsr
> ..
>
> kpsewhich zi4.sty returns nothing
>
> kpsewhich inconsolata.sty returns nothing
>
> So they must not be installed.  Any idea how to fix this?
>
> Thanks much,
> Cathy Lee Gierke
>
>
> *“Darkness cannot drive out darkness: only light can do that. Hate cannot
> drive out hate: only love can do that.” *
> *“The arc of the moral universe is long, but it bends towards justice.”*
> *“Nothing in the world is more dangerous than sincere ignorance and
> conscientious stupidity.” *
> *“Never forget that everything Hitler did in Germany was legal.”   *
> *“Forgiveness is not an occasional act, it is a constant attitude.” *
> *“Injustice anywhere is a threat to justice everywhere.”  *
>
> ― Martin Luther King Jr.
>
> 
>
> [[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] multiple bibentry()s in CITATION

2017-03-27 Thread 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},
> >> }
> >>
> >> >
> >> 
> >>
> >> This all works "obviously" (;-) via utils:::format.bibentry ()

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

2017-03-27 Thread 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 
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 
>>>>>>>> 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

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

2024-04-22 Thread 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

2018-04-10 Thread 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] R-extension requirement about third-party random number generators (RNG)

2024-09-27 Thread Kasper Daniel Hansen
John,

Your post does not have many details but why do you think that
instantiating 4 instances of the Mersenne Twister will keep the streams
independent? It is possible to get independent streams, but it will need
more work.

Best,
Kasper

On Fri, Sep 27, 2024 at 11:17 AM Dirk Eddelbuettel  wrote:

>
> On 27 September 2024 at 16:58, John Clarke wrote:
> | [...] -- the RNG state management strategy appears almost 'magical' to me
> | especially inside RCPP. It is possible, I just don't understand how to
> use it.
>
> See Section 6.3 of WRE: The pair of GetRNGstate() and PutRNGstate() is all
> there is in terms of an interface, and all we call (and old-school macros
> ensure it ends in the generated glue code Rcpp produces for you). Pretty
> much
> everything else around RNGSs is (quite) opaque (as Section 6.3 states) and
> Rcpp does not go there.
>
> Cheers,  Dirk
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> 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