Re: [R-pkg-devel] How to obtain intercept of intercept-only glm in Fortran?

[Ivan Krylov]

On Sat, 4 May 2019 22:41:16 +
"Wang, Zhu"  wrote:

> In an R package I would like to compute intercept for an
> intercept-only GLM in a Fortran subroutine.

If all else fails, you could use R API [*] to call coef(glm.fit(...)),
though it might require writing a C or C++ wrapper to avoid translating
all function prototypes from Rinternals.h into Fortran 2003 C
interoperability syntax.

-- 
Best regards,
Ivan

[*]:
https://cran.r-project.org/doc/manuals/R-exts.html#Evaluating-R-expressions-from-C

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

Re: [R-pkg-devel] Writing to files without altering working directory in R package

[Jim Hester]

For what it's worth, the recommendation to use `tempfile()` is very
confusing to R users.

Often users (particularly new users) jump directly to examples when
reading documentation and when you have these more complicated
examples they do not realize they can just use a simple string
literal.

See https://github.com/tidyverse/readr/issues/635 for an issue where
multiple users explicitly request examples which do _not_ use
`tempfile()`.

On Fri, May 3, 2019 at 7:59 PM Duncan Murdoch  wrote:
>
> On 03/05/2019 6:33 p.m., Jarrett Phillips wrote:
> > Hello,
> >
> > My R package has a function with an argument to specify whether numerical
> > results should be outputted to a CSV file.
> >
> > CRAN policy stipulates verbatim that
> >
> > Packages should not write in the user’s home filespace (including
> > clipboards), nor anywhere else on the file system apart from the R
> > session’s temporary directory (or during installation in the location
> > pointed to by TMPDIR: and such usage should be cleaned up). Installing into
> > the system’s R installation (e.g., scripts to its bin directory) is not
> > allowed.
> >
> > I know I should use tempdir() within my package function, but I've not seen
> > any examples on how this is best done within existing R packages.
> >
> > Within my package documentation examples for my function, I have the lines:
> >
> >   \dontshow{.oldwd <- setwd(tempdir())}
> >
> > ... some R code ...
> >
> > \dontshow{setwd(.oldwd)}
> >
> > but I have been informed that this is not the accepted way.
> >
> > Any ideas from the community on how do do this properly?
>
> Use the tempfile() function to generate a filename in the temporary
> directory.  You might want to use the "pattern" or "fileext" arguments,
> but don't change the "tmpdir" argument.
>
> Then write to that file.
>
> For example,
>
> filename <- tempfile(fileext = ".csv")
> write.csv(df, filename)
>
> It's a good idea to clean up afterwards using
>
> unlink(filename)
>
> __
> 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] Writing to files without altering working directory in R package

[Jeff Newmiller]

You cannot go littering the user directories with sample files. Such examples 
would have to be dontrun, but in order to make some of the example runnable as 
is you would also need examples that use system.file paradigm. If you store the 
temporary file name in a variable then the user can retrieve the contents of 
that file briefly after running the example. Such practice of separating the 
call to tempfile from your function call also makes it a little clearer that 
the file name can be created using other methods than via system.file.

On May 6, 2019 9:16:42 AM PDT, Jim Hester  wrote:
>For what it's worth, the recommendation to use `tempfile()` is very
>confusing to R users.
>
>Often users (particularly new users) jump directly to examples when
>reading documentation and when you have these more complicated
>examples they do not realize they can just use a simple string
>literal.
>
>See https://github.com/tidyverse/readr/issues/635 for an issue where
>multiple users explicitly request examples which do _not_ use
>`tempfile()`.
>
>On Fri, May 3, 2019 at 7:59 PM Duncan Murdoch
> wrote:
>>
>> On 03/05/2019 6:33 p.m., Jarrett Phillips wrote:
>> > Hello,
>> >
>> > My R package has a function with an argument to specify whether
>numerical
>> > results should be outputted to a CSV file.
>> >
>> > CRAN policy stipulates verbatim that
>> >
>> > Packages should not write in the user’s home filespace (including
>> > clipboards), nor anywhere else on the file system apart from the R
>> > session’s temporary directory (or during installation in the
>location
>> > pointed to by TMPDIR: and such usage should be cleaned up).
>Installing into
>> > the system’s R installation (e.g., scripts to its bin directory) is
>not
>> > allowed.
>> >
>> > I know I should use tempdir() within my package function, but I've
>not seen
>> > any examples on how this is best done within existing R packages.
>> >
>> > Within my package documentation examples for my function, I have
>the lines:
>> >
>> >   \dontshow{.oldwd <- setwd(tempdir())}
>> >
>> > ... some R code ...
>> >
>> > \dontshow{setwd(.oldwd)}
>> >
>> > but I have been informed that this is not the accepted way.
>> >
>> > Any ideas from the community on how do do this properly?
>>
>> Use the tempfile() function to generate a filename in the temporary
>> directory.  You might want to use the "pattern" or "fileext"
>arguments,
>> but don't change the "tmpdir" argument.
>>
>> Then write to that file.
>>
>> For example,
>>
>> filename <- tempfile(fileext = ".csv")
>> write.csv(df, filename)
>>
>> It's a good idea to clean up afterwards using
>>
>> unlink(filename)
>>
>> __
>> 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

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] package cartograflow_1.0.0.tar.gz

[Uwe Ligges]

This should be fine.

Please always keep  CCed.

Best,
Uwe Ligges


On 05.05.2019 14:44, cartograf...@gmail.com wrote:

Hi,

After I submitted my package I received some remarks e.g add the exmple 
that I've taken into account.
So, I used R-devel CMD check, I've always one 1 note about maintener 
which it's not a problem to submit and another note due to package size.

...
* checking installed package size ... NOTE
   installed size is  5.0Mb
   sub-directories of 1Mb or more:
     doc   4.4Mb
...
I would like to know if I can submit in CRAN with this note if not, do 
you hnow how I can solve this issue?
In vignette directories the html file size is of 4.3MB. I don't know how 
I can reduce the size. There are a lot of picture (cartography).


Thanks in advance to your reply
Sylvain

Le dimanche 7 avril 2019 à 21:32:07 UTC+2, Duncan Murdoch 
 a écrit :



On 07/04/2019 3:01 p.m., cartograf...@gmail.com 
 wrote:

 > Thanks!
 > So, I've already check and I didn't see the descrption of the note in
 > 00check.log.
 > The only thing I can say is that there's a problem with Author.
 > I tried to put Authors@R  and it also generates notes.
 > Do you have any idea?
 >
 > You will find hereafter the copy of the file 00check.log.
 > Thanks in advance
 > 
 > * using log directory ‘/home/sylvain/svn/cartograflow.Rcheck’
 > * using R Under development (unstable) (2019-04-04 r76316)
 > * using platform: x86_64-pc-linux-gnu (64-bit)
 > * using session charset: UTF-8
 > * using option ‘--as-cran’
 > * checking for file ‘cartograflow/DESCRIPTION’ ... OK
 > * this is package ‘cartograflow’ version ‘1.0.0.0’
 > * package encoding: UTF-8
 > * checking CRAN incoming feasibility ... NOTE
 > Maintainer: ‘Sylvain Blondeau >’

 >
 > New submission
 >
 > Author field should be Authors@R.   Current value is:
 >    c(person("Sylvain", "Blondeau", email = "blondeau.sylv...@yahoo.fr 
",

 > role = c("cre","aut")),
 >      person("other", "other", email = "other.ot...@gmail.com 
",

 > role = c("aut")))

That second author doesn't look right, but I don't think the note is
complaining about that.  I think you probably have put something like
this in your DESCRIPTION file:

Author:  c(person("Sylvain", "Blondeau", email =
"blondeau.sylv...@yahoo.fr ", role = 
c("cre","aut")),
             person("other", "other", email = "other.ot...@gmail.com 
",

role = c("aut")))

and what it is saying is that you should instead use

Authors@R :  c(person("Sylvain", "Blondeau", email =
"blondeau.sylv...@yahoo.fr ", role = 
c("cre","aut")),
             person("other", "other", email = "other.ot...@gmail.com 
",

role = c("aut")))

If my guess is right and you fix it, you may still get a NOTE.  To make
it easier for the CRAN maintainers to know who to contact in case of an
issue with the package, they display information about the package
maintainer in a NOTE.  Since most NOTEs indicate likely problems, it
would probably make sense for them to use some other formatting for the
message, but that's how it is.

Duncan Murdoch



 > * checking package namespace information ... OK
 > * checking package dependencies ... OK
 > * checking if this is a source package ... OK
 > * checking if there is a namespace ... OK
 > * checking for executable files ... OK
 > * checking for hidden files and directories ... OK
 > * checking for portable file names ... OK
 > * checking for sufficient/correct file permissions ... OK
 > * checking serialization versions ... OK
 > * checking whether package ‘cartograflow’ can be installed ... OK
 > * checking installed package size ... OK
 > * checking package directory ... OK
 > * checking for future file timestamps ... OK
 > * checking ‘build’ directory ... OK
 > * checking DESCRIPTION meta-information ... OK
 > * checking top-level files ... OK
 > * checking for left-over files ... OK
 > * checking index information ... OK
 > * checking package subdirectories ... OK
 > * checking R files for non-ASCII characters ... OK
 > * checking R files for syntax errors ... OK
 > * checking whether the package can be loaded ... OK
 > * checking whether the package can be loaded with stated dependencies 
... OK

 > * checking whether the package can be unloaded cleanly ... OK
 > * checking whether the namespace can be loaded with stated dependencies
 > ... OK
 > * checking whether the namespace can be unloaded cleanly ... OK
 > * checking use of S3 registration ... OK
 > * checking dependencies in R code ... OK
 > * checking S3 generic/method consistency ... OK
 > * checking replacement functions ... OK
 > * checking foreign function calls ... OK
 > * checking R code for possible problems ... OK
 > * checking R