Re: [R-pkg-devel] Package Vignette depends on Ensembl, server certificate issue?

[Jeff Newmiller]

Maybe use r.rsp?

https://blog.r-hub.io/2020/06/03/vignettes/
How to include my pre-print / cheatsheet as a PDF vignette?



On April 8, 2021 12:39:20 PM PDT, "Dr. Connie Brett" 
 wrote:
>Hello,
>I have a package (DGEobj) that depends on the Ensembl service to look
>up information used to build the vignette.  My builds work fine on
>Travis, locally and on R-hub.  Occasionally I have seen blips with
>regard to internet-based resources not being available, and my vignette
>depends on a number of internet resources to get example datasets. 
>However when I submitted my package to CRAN today the failures Windows
>and Debian were that the server certificate verification failed ( SSL
>certificate problem: unable to get local issuer certificate).
>I’m not sure if there is something I can do about this or if this is
>considered a "false positive" per the email - it seems like a "wait and
>retry" issue.  I don’t want to be rude uploading the package again
>without a change or erroneously emailing in response to the rejection. 
>How should this be handled properly now and into the future?  It isn’t
>feasible to not use Ensembl for this vignette.
>Thanks for your insight and feedback!
>
>Flavor: r-devel-windows-ix86+x86_64
>Check: re-building of vignette outputs, Result: WARNING
> Error(s) in re-building vignettes:
> --- re-building 'DGEobj_Overview.Rmd' using rmarkdown
>
> Ensembl site unresponsive, trying asia mirror
> Quitting from lines 259-280 (DGEobj_Overview.Rmd) 
>Error: processing vignette 'DGEobj_Overview.Rmd' failed with
>diagnostics:
> SSL certificate problem: unable to get local issuer certificate
> --- failed re-building 'DGEobj_Overview.Rmd'
>
> SUMMARY: processing the following file failed:
>   'DGEobj_Overview.Rmd'
>
> Error: Vignette re-building failed.
> Execution halted
>
>
>Flavor: r-devel-linux-x86_64-debian-gcc
>Check: re-building of vignette outputs, Result: WARNING
> Error(s) in re-building vignettes:
> --- re-building 'DGEobj_Overview.Rmd' using rmarkdown
>
> Ensembl site unresponsive, trying asia mirror
> Quitting from lines 235-256 (DGEobj_Overview.Rmd) 
>Error: processing vignette 'DGEobj_Overview.Rmd' failed with
>diagnostics:
> server certificate verification failed. CAfile: none CRLfile: none
> --- failed re-building 'DGEobj_Overview.Rmd'
>
> SUMMARY: processing the following file failed:
>   'DGEobj_Overview.Rmd'
>
> Error: Vignette re-building failed.
> Execution halted
>   [[alternative HTML version deleted]]
>
>__
>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] Installed image not found in Debian

[Jeff Newmiller]

Why aren't you using system.file()?

On May 11, 2021 1:45:37 PM PDT, Tiago Olivoto  wrote:
>Dear all,
>I just submitted a new package 'pliman' (
>https://github.com/TiagoOlivoto/pliman) and it does not pass the
>incoming
>checks automatically.
>I have some images that are under '/inst/tmp_images' to be installed
>with
>the package. In some examples and Vignettes, I use the helper function
>image_pliman() <
>https://github.com/TiagoOlivoto/pliman/blob/master/R/utils_imagem.R#L125>
>to get the patch of a given image
>
>Then, I use image_import() <
>https://github.com/TiagoOlivoto/pliman/blob/master/R/utils_imagem.R#L69>
>to
>import the image into R.
>
>All tests passed in Windows <
>https://win-builder.r-project.org/incoming_pretest/pliman_0.1.0_20210511_212904/Windows/00check.log>
>but an error was got in Debian <
>https://win-builder.r-project.org/incoming_pretest/pliman_0.1.0_20210511_212904/Debian/00check.log
>>
>The error occurs when image_import () has been called, for example
>
>image_import(image_pliman("soybean_touch.jpg"))
>Error:  'soybean_touch' not found in
>.//srv/hornik/tmp/CRAN/pliman.Rcheck/pliman/tmp_images
>
>It seems that this error comes from this check <
>https://github.com/TiagoOlivoto/pliman/blob/master/R/utils_imagem.R#L92-L97>
>that checks if the image name is available in the directory. Please,
>see a
>toy example with my data.
>
># Get the patch of the image
>image <- image_pliman("soybean_touch.jpg")
>image
>[1]
>"E:/Documents/R/win-library/4.0/pliman/tmp_images/soybean_touch.jpg"
>
># Get the directory of the image
>img_dir <- file_dir(image)
>> img_dir
>[1] "E:/Documents/R/win-library/4.0/pliman/tmp_images"
>
># Get all files in the directory
>> all_files <- sapply(list.files(img_dir), file_name)
>> all_files
>background.jpgla_back.jpgla_leaf.jpg  la_leaves.JPG
>  "background"  "la_back"  "la_leaf""la_leaves"
>la_pattern.JPGla_temp.jpg objects_300dpi.jpg   sev_back.jpg
>  "la_pattern"  "la_temp"   "objects_300dpi" "sev_back"
>sev_healthy.jpg   sev_leaf.jpgsev_leaf_nb.jpg 
>sev_sympt.jpg
> "sev_healthy" "sev_leaf"  "sev_leaf_nb""sev_sympt"
> soy_green.jpg  soybean_grain.jpg  soybean_touch.jpg
>   "soy_green""soybean_grain""soybean_touch"
>
># Get the name of the image and check if it is in the directory
>> img_name <- file_name(image)
>> img_name
>[1] "soybean_touch"
>
>if(!grepl("http", img_dir, fixed = TRUE) & !img_name %in% all_files){
>  stop(" '", img_name, "' not found in ", img_dir,  call. = FALSE)
>}
>
>In this case, there is no error since  "soybean_touch" is in
>'all_files'
>
>I have no idea how to fix this issue and why this error occurs only on
>Debian and not on Windows. Any suggestion to fix the error and/or
>improve
>the code will be welcome!
>Thanks in advance,
>Tiago
>
>   [[alternative HTML version deleted]]
>
>__
>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] \donttest{} and writing outputs to tempdir()

[Jeff Newmiller]

Make examples shorter so they can run faster. Wrapping everything in donttest 
means that running examples() does nothing, which is counterproductive.

Techinically, vignettes are not tests or examples... but they do have the 
advantage that they don't have to run quickly. But that doesn't make a vignette 
a substitute for either examples or tests.

As for writing to the wrong place, you should probably just double check. 

On June 1, 2021 9:39:43 PM PDT, Danielle Maeser  wrote:
>Hello,
>
>I received the following comments from a CRAN maintainer, and I don't
>understand why they were an issue. I'd appreciate any insight you can
>provide.
>
>Danielle
>
>
>
>
>
>
>
>*All your examples are wrapped in \donttest{} and therefore do not
>gettested.Please unwrap the examples if that is feasible and if they
>can
>beexecuted in < 5 sec for each Rd file or create additionally small
>toyexamples to allow automatic testing.*
>
>I don't think I can unwrap the examples in \donttest{} because they
>cannot
>be executed in <5 seconds for each Rd file, and the automatic testing
>of
>toy data is satisfied in the vignettes I provide for each function.
>Therefore, I am not sure what change to make here.
>
>
>
>
>*Please ensure that your functions do not write by default or in
>yourexamples/vignettes/tests in the user's home filespace (including
>thepackage directory and getwd()). This is not allowed by CRAN
>policies.In
>your examples/vignettes/tests you can write to tempdir().*
>
>Additionally, all of my vignettes write the output of each function to
>tempdir(). Therefore, I am not sure why this is a problem.

-- 
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] Question about preventing CRAN package archival

[Jeff Newmiller]

MIT is more permissive than GPL2, so there is a collision there. But you may be 
able to work it out with the author?

On June 2, 2021 10:36:00 AM PDT, Ben Staton  wrote:
>My package uses the MIT license, so would that not meet the
>compatibility
>requirements?
>
>I will attempt to reach out to the package author - thanks for your
>help!
>
>On Wed, Jun 2, 2021 at 10:31 AM Ben Bolker  wrote:
>
>> That all sounds exactly right.
>>GPL >= 2 allows you to use the material without asking permission
>as
>> long as your package is compatibly licensed (e.g. also GPL).
>>Under normal circumstances it would be polite to ask permission,
>but
>> if the reason for doing this is that the maintainer is unreachable in
>> the first place ...
>>
>>   If you want to try a little harder, it seems quite possible that
>you
>> can reach the matrixcalc maintainer at the (personal) e-mail address
>> shown in this page:
>>
>>
>https://www.facebook.com/photo/?fbid=10208324530363130&set=ecnf.1000413042
>>
>>(Possibly an identity confusion, but I rate that as unlikely based
>on
>> other facebook snooping)
>>
>>I don't think a short, polite e-mail request would be out of
>bounds,
>> they can always ignore it or tell you to go away.
>>
>>cheers
>> Ben Bolker
>>
>> On 6/2/21 1:15 PM, Ben Staton wrote:
>> > Hello,
>> >
>> > Thank you for your detailed list of solutions.
>> >
>> > I was initially tempted to go with option 1 (move matrixcalc to
>suggests
>> > and check for its existence before using functions that rely on
>it), but
>> as
>> > mentioned, this is not a long term fix.
>> >
>> > I unfortunately can't take on the responsibilities of option 2
>(becoming
>> > the package maintainer) -- there is much that this package does
>that I do
>> > not understand, and do not wish to feign authority!
>> >
>> > I plan to take option 3 (copy the needed functions into my
>package).
>> There
>> > are only three functions I need from matrixcalc, and all three are
>fairly
>> > simple (is.square.matrix
>> > ,
>> > is.symmetric.matrix
>> > , and
>> > is.positive.definite
>> > ) and
>> there
>> > is only one function in postpack that needs them. I plan to define
>them
>> > within the postpack function. matrixcalc is licensed under GPL >= 2
>and
>> > based on my scan of the license text, this is allowed. Is that
>correct?
>> >
>> > Regarding option 4 (contacting the matrixcalc maintainer), the
>original
>> > email from CRAN mentioned that they have attempted to contact the
>package
>> > author with no response.
>> >
>> > Thank you!
>> >
>> > On Wed, Jun 2, 2021 at 9:52 AM J C Nash 
>wrote:
>> >
>> >> I just downloaded the source matrixcalc package to see what it
>> contained.
>> >> The functions
>> >> I looked at seem fairly straightforward and the OP could likely
>develop
>> >> equivalent features
>> >> in his own code, possibly avoiding a function call. Avoiding the
>> function
>> >> call means NAMESPACE etc. are not involved, so fewer places for
>getting
>> >> into
>> >> trouble, assuming the inline code works properly.
>> >>
>> >> JN
>> >>
>> >>
>> >> On 2021-06-02 12:37 p.m., Duncan Murdoch wrote:
>> >>> On 02/06/2021 12:13 p.m., Ben Staton wrote:
>>  Hello,
>> 
>>  I received an email notice from CRAN indicating that my R
>package
>>  ('postpack') will be archived soon if I do not take any action
>and I
>> >> want
>>  to avoid that outcome. The issue is not caused by my package,
>but
>> >> instead a
>>  package that my package depends on:
>> 
>>  "... package 'matrixcalc' is now scheduled for archival on
>2021-06-09,
>>  and archiving this will necessitate also archiving its strong
>reverse
>>  dependencies."
>> 
>>  Evidently, xyz has been returning errors on new R builds
>prompting
>> CRAN
>> >> to
>>  list it as a package to be archived. My package, 'postpack' has
>>  'matrixcalc' listed in the Imports field, which I assume is why
>I
>> >> received
>>  this email.
>> 
>>  I want to keep 'postpack' active and don't want it to be
>archived. I
>> >> still
>>  need package 'matrixcalc' for my package, but not for most
>functions.
>> >> Could
>>  I simply move package 'matrixcalc' to the Suggests list and
>submit the
>> >> new
>>  version to CRAN to remove the "Strong Reverse Dependency" issue
>that
>>  triggered this email to avoid CRAN from archiving my package?
>> >>>
>> >>> That's part of one solution, but not the best solution.
>> >>>
>> >>> If you move it to Suggests, you should make sure that your
>package
>> >> checks for it before every use, and falls back to
>> >>> some other calculation if it is not present.  Be aware that once
>it is
>> >> archived, almost none of your users will have it
>> >>> available, so this is kind of like dropping the function

Re: [R-pkg-devel] Question about preventing CRAN package archival

[Jeff Newmiller]

... but you went ahead and did it anyway.

MIT software can be absorbed by GPL2 software, but not vice versa since MIT 
allows the code to be further incorporated into and distributed as non-free 
software, a permission not granted by GPL2.

I am opposed to people snarfing GPL2 code up for their non-free software 
tarpits, and transferring GPL2 code to MIT without the GPL2 author explicitly 
re-releasing as MIT would allow that.

On June 2, 2021 11:51:01 PM PDT, Berwin A Turlach  
wrote:
>G'day Jeff,
>
>On Wed, 02 Jun 2021 11:34:21 -0700
>Jeff Newmiller  wrote:
>
>Not that I want to get involved in old discussions :), but...
>
>> MIT is more permissive than GPL2,
>
>... this statement depends on how one defines "permissive".
>
>MIT requires that you fulfil: "The above copyright notice and this
>permission notice shall be included in all copies or substantial
>portions of the Software." (https://opensource.org/licenses/MIT)
>
>Whereas GPL 2 merely requires that you "[...] conspicuously and
>appropriately publish on each copy an appropriate copyright notice and
>disclaimer of warranty [...]".
>
>Thus, arguably, GPL 2 is more permissive.
>
>>  so there is a collision there. 
>
>Well, luckily the FSF does not think that the MIT license is
>incompatible with the GPL license, though it finds the term "MIT
>license" misleading and discourages its use, see
>https://www.gnu.org/licenses/license-list.html
>
>Cheers,
>
>   Berwin

-- 
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] How to sent possible bug report to maintainer

[Jeff Newmiller]

This is a job for a detective, not a package developer mailing list participant.

If this condition persists, CRAN will archive the package, as maintaining a 
valid email address is required.

On June 18, 2021 5:29:20 PM PDT, mai zhou  wrote:
>Dear developers,
>
>I was trying to send an email to the maintainer of package tpAUC,
>on the information page, he/she has the address ly...@purdue.edu
>But my email bounced back.
>
>Can anyone tell me how I can contact him/her for a question/report?
>
>Mai Z
>
>
>This is what I got:
>
>Address not found
>Your message wasn't delivered to *ly...@purdue.edu* because the address
>couldn't be found, or is unable to receive mail.
>
>   [[alternative HTML version deleted]]
>
>__
>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] Assignments to the global environment and use of on.exit

[Jeff Newmiller]

Just don't. E.g. 
https://stackoverflow.com/questions/12598242/global-variables-in-packages-in-r

On June 22, 2021 1:47:56 AM PDT, Siddhanta Phuyal 
 wrote:
> Hello,
>
>A few weeks ago, I submitted a package to CRAN. The automated system
>rejected the package showing the following note:
>
>Found the following assignments to the global environment:
>  File 'EuclideanSD/R/EuclideanSD.R':
>assign("nums", x, envir = globalenv())
>
>Context of the problem:
>
>The package has a function that takes a vector from the user. The
>vector is
>used by the shiny app to produce the desired output. The sever and UI
>functions are located inside the 'inst' folder. Since they are located
>at a
>different location, the server function cannot directly access the
>vector
>received by the function from the user. Hence, the package creates a
>global
>variable to store the data which can also be used by the server
>function.
>
>The solution I offered:
>
>However, before assigning the variable to a global environment, the
>function checks whether there is a variable with the same name in the
>global environment. If there is such a variable, then the function
>restores
>that variable back to its original state by using on.exit(num<-oldnum)
>prior to exiting the function. On the contrary, if such a variable does
>not
>exist, then the variable assigned to the global environment is removed
>on
>exit. I have included the code to clarify my argument. Please see below
>for
>the code:
>
>if (exists("nums",where = 1)){
>oldnums <- nums
>nums <- x
>shiny::runApp(system.file(package="EuclideanSD","app"))
>on.exit(nums<-oldnums)
>
>  }else{
>assign("nums",x,envir = globalenv())
>shiny::runApp(system.file(package="EuclideanSD","app"))
>on.exit(remove("nums",pos=1))
>  }
>
>I tried to explain the same to the maintainers of CRAN by replying to
>the
>message that I got from the CRAN. However, there was no response.
>
>I have two questions that I hope to get help from this community:
>
>1) Is my solution reasonably okay with the requirements of the CRAN?
>2) If the solution is not okay, what could be the better solution?
>However,
>the features of the package cannot be changed. For example, the data
>has to
>be fed through the function and not through the website.
>
>Thank you for your help.
>
>Looking forward to hearing from you.
>
>Best Regards,
>Siddhanta Phuyal
>
>   [[alternative HTML version deleted]]
>
>__
>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] Spelling and manual CRAN inspection

[Jeff Newmiller]

Spelling has different importance to different people. You are expressing a 
value judgement that differs from the values of R Core, but are presenting your 
opinion as if they are facts. My point is that your challenging attitude IMO 
makes having a conversation about those concerns difficult. (I am not 
associated with R Core in any way, and do in fact empathize with your 
frustration with the process.)

I think it is worth pointing out that spelling errors in the DESCRIPTION file 
are of greater significance than other areas of a package as they can affect 
assignment of responsibility and permissions, as well as reflecting poorly on 
the CRAN summary web pages. I suspect that problems with DESCRIPTION files in 
the past lead to this requirement.

I would encourage you to pause for a day or two before sending off messages 
like this in the future... a lesson I have learned the hard way myself.

On July 16, 2021 9:08:27 AM PDT, "Kevin R. Coombes"  
wrote:
>Hi,
>
>  I have been updating a couple of R packages this morning. One of them
>triggered a manual inspection for "possibly mis-spelled words in
>DESCRIPTION" for my last name (Coombes) --- even though none of the
>other 20 packages that I maintain has ever triggered that particular
>NOTE. A second package also triggered a manual inspection for
>mis-spelled words including "Proteomics". (These flags only arose on
>the
>debian CRAN machine, not the Windows CRAN machine, and not on my home
>machines. And let's ignore how many spelling corrections I had to make
>while typing this email)
>
>*My question, however, is: why should this NOTE ever trigger a manual
>inspection?* That makes more work for the CRAN maintainers, who I am
>sure have better things to do than evaluate spelling. Anything that
>would actually stop the package from working (mis-spelling a keyword,
>or
>mis-spelling the name of package that is imported) is going to cause an
>automatic ERROR and a rejection of the submission without making more
>work for the CRAN maintainers. The other mis-spellings may reflect
>poorly on the package author, but since they are NOTEs, it is easy
>enough to get them fixed for the next round without making human
>eyeballs look at them.
>
>Best,
>    Kevin
>
>__
>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] Additional CRAN Checks

[Jeff Newmiller]

Exactly what errors do you think you found? It is not an error for a package to 
be compatible with a range of versions of R.

On September 6, 2021 4:02:08 AM PDT, Colin Gillespie  
wrote:
>Dear All,
>
>Sorry if this is the wrong mailing address.
>
>I was doing a little investigation of R versions in packages and
>discovered a number of errors:
>
>https://cran.r-project.org/web/packages/bartCause/index.html  - R (≥ 3.1-0)
>https://cran.r-project.org/web/packages/activityGCMM/index.html  - R (3.00)
>https://cran.r-project.org/web/packages/deTestSet/index.html - R (≥ 2.01)
>
>and also
>
>https://cran.r-project.org/web/packages/NGSSEML/ - R (≥ 1.9.0), R (≥
>3.5.0), R (≥ 3.5.0), R (≥ 3.5.0), R (≥ 3.5.0), R (≥ 3.5.0), R (≥
>3.5.0)
>
>Overall I detected ~40 packages with issues:
>
>c("activityGCMM", "behavr", "bioassays", "bvpSolve", "celestial",
>"chest", "CRTSize", "csppData", "damr", "deTestSet", "diagram",
>"directPA", "DiscreteFDR", "ecolMod", "ecp", "epibasix", "europepmc",
>"fabisearch", "FDX", "ggetho", "hyper.fit", "MedSurvey", "NBPSeq",
>"NetIndices", "NFWdist", "OmegaG", "primer", "RATest", "refund",
>"RmarineHeatWaves", "rmcfs", "rootSolve", "RPPASPACE", "scopr",
>"scoringRules", "seqDesign", "shape", "sleepr", "SMPracticals",
>"text", "tggd", "zeitgebr")
>
>It seems like this would be a useful check to implement on the R CMD check.
>
>Thanks
>
>Colin
>
>
>Dr Colin Gillespie
>https://twitter.com/csgillespie
>
>__
>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] Packages required but not available

[Jeff Newmiller]

This advice would apply if the errors were being generated on a computer under 
the package developer's control... but this looks like it is from a repo 
submission.

That said, if the developer has installed packages not currently in BioC for 
R4.1.1 they may need to wait for those packages to propagate in the official 
BioC repo and then to the submission test computers.

On September 11, 2021 3:47:32 PM PDT, dbosa...@gmail.com wrote:
>Reminder that you have to re-install any packages that your oncoPredict 
>package depends on for the new R version 4.1.1.  Packages are 
>downloaded/installed to a specific R version.  If you switch to another 
>version, everything needs to be reinstalled.  I always get this error after 
>upgrading or switching R versions.
>
> �
>
>If you’ve already reinstalled and are still getting the error, then maybe it 
>is something with your NAMESPACE or DESCRIPTION file.  Like if you are using a 
>package inside a function, but forget to add it to the DESCRIPTION.  Or you 
>put it in the DESCRIPTION, but forget to add the @import roxygen directive 
>above your function so that it gets into the NAMESPACE.  
>
> �
>
>Those are the situations that most commonly generate this error, from what I 
>have seen.  
>
> �
>
>From: Danielle Maeser  
>Sent: Saturday, September 11, 2021 6:28 PM
>To: dbosa...@gmail.com; R Package Devel 
>Subject: Re: [R-pkg-devel] Packages required but not available
>
> �
>
>Hi David,
>
> �
>
>Yes. I did recently upgrade R. �
>
> �
>
>On Sat, Sep 11, 2021 at 4:28 PM  > wrote:
>
>Danielle:
>
>Did you recently upgrade to R 4.1.1?
>
>David
>
>
>-Original Message-
>From: R-package-devel  > On Behalf Of Danielle Maeser 
>via R-package-devel
>Sent: Saturday, September 11, 2021 5:10 PM
>To: R Package Devel  >
>Subject: [R-pkg-devel] Packages required but not available
>
>Hello,
>
>I received the following output from my package, oncoPredict.
>
>However, I don't understand how to correct this error. I've tested the advice 
>here:
>https://stackoverflow.com/questions/14358814/error-in-r-cmd-check-packages-required-but-not-available
>without success.
>
>Any thoughts as to how this error can be fixed?
>
>Danielle Maeser
>
>
>
>
>
>
>*Version: 0.1Check: package dependenciesResult: ERROR �  � Packages required
>but not available: �  �  �'org.Hs.eg.db', 'TxDb.Hsapiens.UCSC.hg19.knownGene',
>'maftools', �  �  �'TCGAbiolinks'*
> � * � See section ‘The DESCRIPTION file’ in the ‘Writing R Extensions’*
>
>* �  � manual.Flavor: r-release-macos-x86_64
>*
>--
>Ph.D. Student
>Bioinformatics and Computational Biology University of Minnesota
>
> �  �  �  � [[alternative HTML version deleted]]
>
>__
>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] NOTE related to Miniconda installation

[Jeff Newmiller]

I can't really see why it should be "recommended" to handle installing system 
requirements inside an R package. There are many ways to satisfy such 
requirements that would not involve miniconda. If you were determined to 
provide such support, doing so in a normal function documented in a vignette 
seems more appropriate.

On September 17, 2021 11:55:07 AM PDT, "Walter, Vonn" 
 wrote:
>Hi Everyone,
>
>I am developing a package (called mypackage in the text below) that uses 
>reticulate to call a Python script for computational efficiency.  At some 
>point during the development of the package I read that it would be good to 
>verify installation of Miniconda.  Thus mypackage includes an onLoad.R file 
>that asks users to either confirm that Miniconda is installed or to proceed 
>with installation on Miniconda.  When I run devtools::check() I get a NOTE 
>related to my onLoad.R file, and this seems to be causing problems when I 
>submit the package to CRAN.  There are no WARNINGs or ERRORs.  Any thoughts 
>would be greatly appreciated.
>
>Thanks,
>
>Vonn
>
>* checking R code for possible problems ... [19s] NOTE
>File 'mypackage/R/onLoad.R':
>  .onLoad calls:
>packageStartupMessage("You should install miniconda before using this 
> package")
>
>See section 'Good practice' in '?.onAttach'.
>
>Here's the code/text from my onLoad.R file:
>
>#' Perform necessary tasks when the mypackage package is loaded
>#'
>#'
>miniconda_installation <- NULL
>miniconda_permission <- NULL
>numpy_import <- NULL
>
>.onLoad <- function(libname, pkgname)
>{
>miniconda_installation <- utils::askYesNo("Is miniconda 
> installed?")
>
>if (isFALSE(miniconda_installation))
>{
>miniconda_permission <- 
> utils::askYesNo("Install miniconda?  Downloads 50MB and takes time.")
>
>if (isTRUE(miniconda_permission))
>{
>reticulate::install_miniconda()
>} else{
>
> packageStartupMessage("You should install miniconda before using this 
> package")
>}
>
>numpy_import <- reticulate::import("numpy", 
> delay_load = TRUE)
>}
>}
>
>
>
>   [[alternative HTML version deleted]]
>
>__
>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] What is a "retired"package?

[Jeff Newmiller]

There is nothing official about that term. However, the meaning as intended by 
the package authors seems pretty clear to me, and if some organization decides 
not to allow software that is not being maintained to be relied upon then that 
is their decision. I don't think slapping a different label on "I am not fixing 
this hot mess" is going to change that organization's stance, and expecting the 
author to play that game is unreasonable.

Welcome to the downside of package interdependencies. I highly recommend that 
you migrate away from plyr, either by absorbing the key functions you need from 
it or by relying on different packages.

On September 21, 2021 8:15:28 AM PDT, "Lenth, Russell V" 
 wrote:
>I received a request that I remove the 'plyr' package from the Imports for my 
>package, because plyr is retired. Indeed, the README file for plyr states:
>
>> plyr is retired: this means only changes necessary to keep it on CRAN 
> will be made. 
>> We recommend using dplyr (for data frames) or purrr (for lists) instead.
>
>This says "retired" but it also suggests that plyr will continue to be 
>maintained. And that is a good thing because plyr has over 700 direct 
>reverse-dependents, and almost 2000 if we include indirect reverse 
>dependencies. 
>
>So it seems to me that it isn't a problem at all to have my package import 
>plyr. I use its 'aaply' and 'alply' functions, which are like 'apply' but work 
>for any dimensional array. There are no obvious replacements in purrr or 
>dplyr, and if there were and I used them instead, it would increase my 
>indirect dependencies to several packages that are not actually needed.
>
>The user requesting that I drop plyr states that this is needed to satisfy 
>regulatory needs, that it is problematic to qualify my package since it 
>imports a retired package. 
>
>So my question is: Is there a specific meaning in CRAN for "retired," or is 
>that just loose language from the plyr developers? I did not find the term in 
>"CRAN Repository Policy" or "Writing R Extensions." It appears that my user or 
>their regulatory agency thinks it means that it could be deprecated in the 
>near future. (If that is indeed what it means, there are 700+ packages in 
>trouble!) Otherwise, perhaps the appropriate request may be to the plyr 
>maintainers to modify how they describe its status, so as to avoid confusion.
>
>Russ Lenth
>University of Iowa
>
>__
>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] [External] Re: What is a "retired"package?

[Jeff Newmiller]

As you previously quoted:

> plyr is retired: this means only changes necessary to keep it on CRAN will be 
> made.

That excludes bugfixes related to any specific use cases it is not currently 
capable of handling. In other words, if it doesn't handle the data you pass 
along to it from your users, or there turns out to be a security problem (I 
agree, not likely, but remember these agencies don't shade things by "likely") 
then the plyr maintainers aren't promising to fix it. Take it "as-is". This is 
exactly what this "agency" you are being hassled by is concerned about... not 
the label applied to that status.

On September 21, 2021 8:50:32 AM PDT, "Lenth, Russell V" 
 wrote:
>... "I am not fixing this hot mess"??? To the contrary, the README contains a 
>clearly expressed intention to maintain plyr to keep in on CRAN.
>
>RL
>
>-Original Message-
>From: Jeff Newmiller  
>Sent: Tuesday, September 21, 2021 10:36 AM
>To: r-package-devel@r-project.org; Lenth, Russell V ; 
>r-package-devel@r-project.org
>Subject: [External] Re: [R-pkg-devel] What is a "retired"package?
>
>There is nothing official about that term. However, the meaning as intended by 
>the package authors seems pretty clear to me, and if some organization decides 
>not to allow software that is not being maintained to be relied upon then that 
>is their decision. I don't think slapping a different label on "I am not 
>fixing this hot mess" is going to change that organization's stance, and 
>expecting the author to play that game is unreasonable.
>
>Welcome to the downside of package interdependencies. I highly recommend that 
>you migrate away from plyr, either by absorbing the key functions you need 
>from it or by relying on different packages.
>

-- 
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] [External] Re: What is a "retired"package?

[Jeff Newmiller]

I agree... but trouble is in the eyes of the beholder. If OP's approval process 
requires use of actively-maintained software, then use of code depending on one 
of these "retired"/"superceded" packages could indeed be a problem... for the 
OP. OP cannot expect to be able to impose those requirements on others though.

On September 21, 2021 9:48:28 AM PDT, Hadley Wickham  
wrote:
>> But for the broader question, Jeff is saying that there really are 700 
>> packages that are in potential trouble!
>
>I think that's rather an overstatement of the problem — there's
>nothing wrong with plyr; it's just no longer under active development.
>If anything, plyr is one of the safest packages to depend upon because
>you can know it will never change :)
>
>Hadley
>

-- 
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] Internet resources and Errors

[Jeff Newmiller]

Grace is in the eyes of the beholder.

Using stop in your functions can be perfectly valid. But within the context of 
examples or tests you need to catch those errors because one key definition of 
success in normal building of a package is that no uncaught errors occur. So 
either don't call those functions during package check, or catch the errors and 
move on. The former is probably best (no point in wasting time if you are going 
to ignore the failure anyway)... only run them interactively or when running 
full tests during development.


On September 24, 2021 8:27:32 AM PDT, Roy Mendelssohn - NOAA Federal via 
R-package-devel  wrote:
>Just so I am clear,  I should not call stop(),  but instead call a return() 
>and return something or other  (there is nothing to skip to - it is doing a 
>data download and either it works or it failed).  Is there a preferred 
>something to return?  And it is okay to write a message to the screen?  
>
>I should add that when I first ran into this awhile back I asked what "failed 
>gracefully" means,  and never received a response.  To me,  writing out a 
>message to the user and stopping is graceful exit, but obviously it is not.  
>What would help then, since this problem has been cited by others, is more 
>explicit guidelines as to what constitutes a graceful exit with examples.  My 
>$0.02
>
>-Roy
>
>
>
>> On Sep 24, 2021, at 8:03 AM, Ben Bolker  wrote:
>> 
>>  I think you're not supposed to stop().
>> 
>>  You should just proceed with the other tests (skipping any tests/examples 
>> that depend on access to the inaccessible internet resources, or values 
>> derived from the failing call, to work)
>> 
>>  Does that help?
>> 
>> On 9/24/21 10:49 AM, Roy Mendelssohn - NOAA Federal via R-package-devel 
>> wrote:
>>> Hi All:
>>> I am getting dinged again on CRAN  (just Solaris for some reason),  and the 
>>> problem is how to exit if there is a failure of accessing the resource,  I 
>>> know it has been discussed here before,  but I just am not understanding 
>>> what is desired to end properly. As I have been reminded:
>>> 'Packages which use Internet resources should fail gracefully with an 
>>> informative message
>>> if the resource is not available or has changed (and not give a check 
>>> warning nor error).'
>>> All internet calls are wrapped in 'try()'.  If that shows an error,  I  
>>> write a message to the screen about the error,  and call stop(), perhaps 
>>> with a further message in that call.   Somehow this does not appear to meet 
>>> the standard.Can someone then please tell me what I should do instead.  
>>> The point is I have checked that the access to the internet resources has 
>>> worked,  i have seen that it hasn't,  now what should be the steps to take 
>>> to exit gracefully.
>>> I also want to add to what others have said about the frustrations of 
>>> dealing with Solaris.  I have spent a fair amount of time getting things to 
>>>  work with Solaris which no one uses.  In this instance the package test is 
>>> only failing on Solaris.   Not a good use of limited time IMO.
>>> Thanks for any advice.
>>> -Roy
>>> **
>>> "The contents of this message do not reflect any position of the U.S. 
>>> Government or NOAA."
>>> **
>>> Roy Mendelssohn
>>> Supervisory Operations Research Analyst
>>> NOAA/NMFS
>>> Environmental Research Division
>>> Southwest Fisheries Science Center
>>> ***Note new street address***
>>> 110 McAllister Way
>>> Santa Cruz, CA 95060
>>> Phone: (831)-420-3666
>>> Fax: (831) 420-3980
>>> e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/
>>> "Old age and treachery will overcome youth and skill."
>>> "From those who have been given much, much will be expected"
>>> "the arc of the moral universe is long, but it bends toward justice" -MLK 
>>> Jr.
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 
>> -- 
>> Dr. Benjamin Bolker
>> Professor, Mathematics & Statistics and Biology, McMaster University
>> Director, School of Computational Science and Engineering
>> Graduate chair, Mathematics & Statistics
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>**
>"The contents of this message do not reflect any position of the U.S. 
>Government or NOAA."
>**
>Roy Mendelssohn
>Supervisory Operations Research Analyst
>NOAA/NMFS
>Environmental Research Division
>Southwest Fisheries Science Center
>***Note new street address***
>110 McAllister Way
>Santa Cruz, CA 95060
>Phone: (831)-420-3666
>Fax: (831) 420-3980
>e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/
>
>"Old age and treachery will overcome youth and skill."
>"From those who have been given much, much will be expected" 
>"the arc of the moral universe is lon

Re: [R-pkg-devel] if statements in NAMESPACE file

[Jeff Newmiller]

What if you are on Windows but running R at the command prompt, or via cygwin, 
or in the console window of RStudio?

This seems unstable to me.

On September 30, 2021 11:52:16 AM PDT, Andrew Simmons  
wrote:
>Hello,
>
>
>I'm updating my package 'this.path' which is supposed to retrieve the
>absolute path of the executing script when called. It's similar to 'here',
>except that 'here' constructs paths relative to a project directory,
>whereas 'this.path' constructs paths relative to script directories. I was
>updating the section where I retrieve the executing script's path while
>running from a script open in Rgui for Windows, and I needed
>utils::getWindowsHandles to do such a thing. But utils::getWindowsHandles
>is a Windows only function, I
>would imagine that 'utils' contains a similar line of code as above:
>
>
>if (.Platform$OS.type == "windows")
>getWindowsHandles <- function() ...
>
>
>and then in the NAMESPACE:
>
>
>if (.Platform$OS.type == "windows")
>export(getWindowsHandles)
>
>
>so I'd like to change my code to getWindowsHandles and import
>getWindowsHandles from utils, but I can only do that on Windows, and so the
>conditional importing should work for me. At no point does my function
>mis-behave because of a attempting to use a function that isn't exported on
>that platform, because within the function it only uses getWindowsHandles
>if the OS is Windows.
>
>
>On Thu, Sep 30, 2021 at 11:01 AM Mark Miller 
>wrote:
>
>> Returning to the original question, if it's helpful: I'd like to know what
>> constraints led to considering an export only available on Windows, and see
>> if we can suggest some other designs. It'd be good to keep the user's
>> mental model abstracted from the platform they're working on. There are
>> often unavoidable differences due to platform, but usually they're handled
>> with warnings and errors rather than selective exports.
>>
>> On Thu, Sep 30, 2021 at 3:40 AM Berry Boessenkool <
>> berryboessenk...@hotmail.com> wrote:
>>
>> >
>> > One of the very best fortunes nominations!
>> >
>> > [...]
>> >
>> >   I suspect something like
>> >
>> >if (stats::runif(1) > 0.5) export(someFunction)
>> >
>> > would work too, for a particularly frustrating experience for your
>> > users.  It would mean half the installs export the function, and half
>> > don't.
>> >
>> > Duncan Murdoch
>> >
>> >
>> > [[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
>>
>
>   [[alternative HTML version deleted]]
>
>__
>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] if statements in NAMESPACE file

[Jeff Newmiller]

Expecting a window handle relevant to the script to exist for the purpose of 
identifying a path seem to be orthogonal problems to me. But Andrew has 
indicated offlist that he has alternate code for other cases only uses this 
technique when appropriate.

I still feel this is too convoluted as a way to identify a path, but if he 
covers all cases then my opinion is just an opinion.

On September 30, 2021 2:34:48 PM PDT, Duncan Murdoch  
wrote:
>On 30/09/2021 5:21 p.m., Jeff Newmiller wrote:
>> What if you are on Windows but running R at the command prompt, or via 
>> cygwin, or in the console window of RStudio?
>> 
>> This seems unstable to me.
>
>Sorry, too much context missing.  What's unstable?
>
>Duncan Murdoch
>
>> 
>> On September 30, 2021 11:52:16 AM PDT, Andrew Simmons  
>> wrote:
>>> Hello,
>>>
>>>
>>> I'm updating my package 'this.path' which is supposed to retrieve the
>>> absolute path of the executing script when called. It's similar to 'here',
>>> except that 'here' constructs paths relative to a project directory,
>>> whereas 'this.path' constructs paths relative to script directories. I was
>>> updating the section where I retrieve the executing script's path while
>>> running from a script open in Rgui for Windows, and I needed
>>> utils::getWindowsHandles to do such a thing. But utils::getWindowsHandles
>>> is a Windows only function, I
>>> would imagine that 'utils' contains a similar line of code as above:
>>>
>>>
>>> if (.Platform$OS.type == "windows")
>>> getWindowsHandles <- function() ...
>>>
>>>
>>> and then in the NAMESPACE:
>>>
>>>
>>> if (.Platform$OS.type == "windows")
>>> export(getWindowsHandles)
>>>
>>>
>>> so I'd like to change my code to getWindowsHandles and import
>>> getWindowsHandles from utils, but I can only do that on Windows, and so the
>>> conditional importing should work for me. At no point does my function
>>> mis-behave because of a attempting to use a function that isn't exported on
>>> that platform, because within the function it only uses getWindowsHandles
>>> if the OS is Windows.
>>>
>>>
>>> On Thu, Sep 30, 2021 at 11:01 AM Mark Miller 
>>> wrote:
>>>
>>>> Returning to the original question, if it's helpful: I'd like to know what
>>>> constraints led to considering an export only available on Windows, and see
>>>> if we can suggest some other designs. It'd be good to keep the user's
>>>> mental model abstracted from the platform they're working on. There are
>>>> often unavoidable differences due to platform, but usually they're handled
>>>> with warnings and errors rather than selective exports.
>>>>
>>>> On Thu, Sep 30, 2021 at 3:40 AM Berry Boessenkool <
>>>> berryboessenk...@hotmail.com> wrote:
>>>>
>>>>>
>>>>> One of the very best fortunes nominations!
>>>>>
>>>>> [...]
>>>>>
>>>>>I suspect something like
>>>>>
>>>>> if (stats::runif(1) > 0.5) export(someFunction)
>>>>>
>>>>> would work too, for a particularly frustrating experience for your
>>>>> users.  It would mean half the installs export the function, and half
>>>>> don't.
>>>>>
>>>>> Duncan Murdoch
>>>>>
>>>>>
>>>>>  [[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
>>>>
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> 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] Lists vs Attributes

[Jeff Newmiller]

Duncan has used the phrase "do regular operations on the object" to divide the 
use cases and emphasized that needing the attributes might be important, but he 
did not come out and remind you that if you _do_ perform regular operations on 
it then the outputs of those operations are likely to lose the attributes, 
which is why you might want to avoid relying on them if that is an issue for 
your class use cases.

On October 1, 2021 5:30:56 PM PDT, Duncan Murdoch  
wrote:
>On 01/10/2021 6:14 p.m., Reed A. Cartwright wrote:
>> I'm rethinking the interface of a package, specifically how external binary
>> data is formatted for use in R. I can't decide if it is better to use
>> attributes to store metadata or use a list to hold the main data and
>> metadata as separate elements.
>
>Is the object like some other common R object?  You say it's a 16x16x16 
>array of integers.  Is there an advantage to treating it *exactly* like 
>that, so x[1,2,3] gives an integer?  Then put the other stuff in attributes.
>
>Is it weird enough that x[1,2,3] *needs* to look at the other attributes 
>to know what to return?  Does it never make sense to do regular 
>operations on the object, as though it really was 16x16x16 array of 
>integers?  Then make it a list of different components, and spend the 
>time to define methods to handle any operations that do make sense.
>
>Both approaches are possible; you want to choose the one that is 
>easiest, and most maintainable.
>
>Duncan Murdoch
>
>> 
>> Here's is what one datatype currently looks like:
>> 
>> List of 2
>>   $ : int [1:16, 1:16, 1:16] 9 9 9 9 10 10 1 1 14 14 ...
>>..- attr(*, "palette")=List of 16
>>   [snip]
>>   $ : int [1:16, 1:16, 1:16] 1 1 1 1 1 1 1 1 1 1 ...
>>..- attr(*, "palette")=List of 2
>>   [snip]
>>- attr(*, "offset")= int 3
>> 
>> It's a list of two 16x16x16 arrays of integers. Each array has its own
>> "palette" attribute. Each value in the array refers to a specific element
>> of the palette. In addition the entire list has an offset attribute.
>> 
>> I am considering alternative strategies for representing this data, and I
>> would like any opinions on which style is recommended and why?
>> 
>> List of 3
>>   $ index  :List of 2
>>..$ : int [1:16, 1:16, 1:16] 9 9 9 9 10 10 1 1 14 14 ...
>>..$ : int [1:16, 1:16, 1:16] 1 1 1 1 1 1 1 1 1 1 ...
>>   $ palette:List of 2
>>..$ :List of 16
>>..$ :LIST of 2
>>   $ offset : int 3
>> 
>> or
>> 
>> List of 2
>>   $ :List of 2
>>..$ index: int [1:16, 1:16, 1:16] 9 9 9 9 10 10 1 1 14 14 ...
>>..$ palette:List of 16
>>   $ : List of 2
>>   ..$ index : int [1:16, 1:16, 1:16] 1 1 1 1 1 1 1 1 1 1 ...
>>   ..$ palette : List of 2
>>   - attr(*, "offset")= int 3
>> 
>> Thanks.
>> 
>>  [[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

-- 
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] [Tagged] Re: multithreading in packages

[Jeff Newmiller]

Keep in mind that by embedding this decision into your package you may be 
consuming a resource (cores) that may be more efficiently allocated by an 
application-level partitioning. of available resources. I for one am not a fan 
of this kind of thinking, and it makes system requirements for your package 
more complex even if you allow me to disable it.

On October 9, 2021 7:34:55 AM PDT, Vladimir Dergachev  
wrote:
>
>
>On Sat, 9 Oct 2021, Ivan Krylov wrote:
>
>> В Thu, 7 Oct 2021 21:58:08 -0400 (EDT)
>> Vladimir Dergachev  пишет:
>>
>>>* My understanding from reading documentation and source code is
>>> that there is no dedicated support in R yet, but there are packages
>>> that use multithreading. Are there any plans for multithreading
>>> support in future R versions ?
>>
>> Shared memory multithreading is hard to get right in a memory-safe
>> language (e.g. R), but there's the parallel package, which is a part of
>> base R, which offers process-based parallelism and may run your code on
>> multiple machines at the same time. There's no communication _between_
>> these machines, though. (But I think there's an MPI package on CRAN.)
>
>Well, the way I planned to use multitheading is to speedup processing of 
>very large vectors, so one does not have to wait seconds for the command 
>to return. Same could be done for many built-in R primitives.
>
>>
>>>* pthread or openmp ? I am particularly concerned about
>>> interaction with other packages. I have seen that using pthread and
>>> openmp libraries simultaneously can result in incorrectly pinned
>>> threads.
>>
>> pthreads-based code could be harder to run on Windows (which is a
>> first-class platform for R, expected to be supported by most packages).
>
>Gábor Csárdi pointed out that R is compiled with mingw on Windows and 
>has pthread support - something I did not know either.
>
>> OpenMP should be cross-platform, but Apple compilers are sometimes
>> lacking; the latest Apple likely has been solved since I've heard about
>> it. If your problem can be made embarrassingly parallel, you're welcome
>> to use the parallel package.
>
>I used parallel before, it is very nice, but R-level only. I am looking 
>for something to speedup response of individual package functions so they 
>themselves can be used of part of more complicated code.
>
>>
>>>* control of maximum number of threads. One can default to openmp
>>> environment variable, but these might vary between openmp
>>> implementations.
>>
>> Moreover, CRAN-facing tests aren't allowed to consume more than 200%
>> CPU, so it's a good idea to leave the number of workers in control of
>> the user. According to a reference guide I got from openmp.org, OpenMP
>> implementations are expected to understand omp_set_num_threads() and
>> the OMP_NUM_THREADS environment variable.
>
>Oh, this would never be run through CRAN tests, it is meant for data that 
>is too big for CRAN.
>
>I seem to remember that the Intel compiler used a different environmental 
>variable, but it could be this was fixed since the last time I used it.
>
>best
>
>Vladimir Dergachev
>
>>
>> -- 
>> Best regards,
>> Ivan
>>
>__
>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] Inconsistent available package dependencies

[Jeff Newmiller]

You should ALWAYS build with the latest stable AND the latest development 
versions of R before submitting.

On November 15, 2021 6:33:12 PM PST, Michael Hellstern  wrote:
>Hi all,
>
>I maintain a package (netgsa) that has been on CRAN since september 2021
>and recently got an email about CRAN check failures. There are 2 errors and
>1 warning. The failures are listed here:
>https://cran.r-project.org/web/checks/check_results_netgsa.html.
>
>The failures are a result of Bioconductor packages. Both errors are about
>package dependencies not being available (org.Hs.eg.db and/or ndexr) while
>the warning comes from the vignette building failing which is caused by an
>error in the graphite package. I checked and these packages were and still
>are available on Bioconductor. The errors occurred on macOS 10.13.6. While
>not exactly the same OS, I ran R CMD check --as-cran on my macOS 10.15.7
>and did not get any errors or warnings. It seems odd that I would get a
>package dependency availability error for only 2 flavors and that I would
>not be able to reproduce this on a similar OS.
>
>I searched online but have not found anything useful. I built the package
>under R 4.0.2 which is now a little dated so am wondering if it is related
>to this? Do I need to rebuild using the most recent version of R? Any
>advice on how to resolve this would be greatly appreciated!
>
>Best,
>
>Mike
>
>   [[alternative HTML version deleted]]
>
>__
>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] socketConnection, delay when reading from

[Jeff Newmiller]

This is a null-terminated message protocol [1]. It has to be processed one byte 
at a time.

[1] https://docs.basex.org/wiki/Server_Protocol

On November 27, 2021 7:45:31 AM PST, Gabor Grothendieck 
 wrote:
>Whether the length is variable or not isn't relevant. The point is
>whether the message is prefaced by a length or command from which the
>length can be derived.  Maybe it is not and you will have to rely on
>inefficient methods but in many cases protocols are designed to avoid
>such problems.
>
>On Sat, Nov 27, 2021 at 9:40 AM Ben Engbers  wrote:
>>
>> No, according to the specification the minimal number of bytes that is
>> returned is 2. There is no maximum. (When querying a database you never
>> know on forehand how many records match the query so by definition you
>> can't calculate the size of the message).
>>
>> In some C, C++ or Java-code I found on internet, it was possible to
>> change the timeout settings so that there would be no delay. Of course
>> this would have as consequence that in your code you have to deal with
>> the possibility that the message has not been completely returned.
>>
>> In R you can set the timeout to 0 but that results in errors (at least
>> on Windows)
>>
>> Op 27-11-2021 om 14:57 schreef Gabor Grothendieck:
>> > Does the message start with a length or a command whose argument length is 
>> > known
>> > depending on the particular command?
>> > If so first read the length or command and from that the length of the
>> > remainder of
>> > the message can be determined.
>> >
>> > On Sat, Nov 27, 2021 at 4:09 AM Ben Engbers  
>> > wrote:
>> >>
>> >>
>> >> Hi,
>> >>
>> >> I have been working on a R-client for the BaseX XML-database and version
>> >> 0.9.2 is nearly finished (submitting version 0.9.0 was rejected by CRAN).
>> >> Version 0.3 of RBaseX can be found here
>> >> (https://cran.microsoft.com/web/packages/RBaseX/index.html).
>> >>
>> >> The client-server protocol specifies that the communication between the
>> >> client and the database is based on a socket. The code (below) shows how
>> >> I create that socket.
>> >>
>> >> Writing to the socket works perfect. Reading from the sockets (see
>> >> second codeblock) also produces correct results. The problem however is
>> >> that the timeout, as specified when initializing the socket, causes a 1
>> >> second delay for every read-operation.
>> >> I have experimented a lot with different settings and have been
>> >> searching a lot on internet, but I can't find any method to get rid of
>> >> that delay. (In C or C++ that should be easier but I have never before
>> >> had any need to use those languages).
>> >> The very first version of my client used a block-size of 1 when reading.
>> >> That gave acceptable response times for small query-results but reading
>> >> large responses from the database took very long time.
>> >>
>> >> Do you have any suggestions on how to cope with this problem?
>> >>
>> >> Ben Engbers
>> >>
>> >> -
>> >>   CreateSocket = function(host, port = 1984L, username, password) {
>> >> tryCatch(
>> >>   {conn <- private$conn <- socketConnection(
>> >> host = "localhost", port,
>> >> open = "w+b", server = FALSE, blocking = TRUE, encoding =
>> >> "UTF-8", timeout = 1)
>> >>   }, error = function(e) {
>> >> stop("Cannot open the connection")
>> >>   }
>> >> )
>> >>
>> >> -
>> >>
>> >> readBin_ <- function(conn) {
>> >> chars_read <- raw(0)
>> >> rd <- readBin(conn, what = "raw", 1024)
>> >> while(length(rd) == 1024) {
>> >>   chars_read <- c(chars_read, rd)
>> >>   rd <- readBin(conn, "raw", 1024)
>> >>   }
>> >> if (length(rd) > 0) chars_read <- c(chars_read, rd)
>> >> return(chars_read)
>> >> }
>> >>
>> >> __
>> >> 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] socketConnection, delay when reading from

[Jeff Newmiller]

Maybe time to learn it. At least to assemble complete messages.

That said, the design of this protocol is intrinsically inefficient. Maybe they 
will upgrade if the software gets popular.

On November 27, 2021 8:24:36 AM PST, Ben Engbers  
wrote:
>Op 27-11-2021 om 17:03 schreef Jeff Newmiller:
>> This is a null-terminated message protocol [1]. It has to be processed one 
>> byte at a time.
>> 
>> [1] https://docs.basex.org/wiki/Server_Protocol
>> 
>The message may contain embedded 0x00's. To distinguish these embedded 
>0x00's (and 0xFF's) from a terminating 0x00, embedded 0x00's and 0xFFare 
>prefixed with a 0xFF byte. This means that when you process one byte at 
>a time you have to perform a check on every byte. This results in 
>totally unacceptable response times (My first version of this client was 
>based on this approach)
>
>The only alternative solution I can think off is to use C++ to create a 
>socket and a function that reads from the socket. But since I have 
>hardly any experience with C++ programming nor using the rcpp package
>
>Ben

-- 
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] socketConnection, delay when reading from

[Jeff Newmiller]

Google?

https://developer.r-project.org/Blog/public/2020/03/17/socket-connections-update/

https://www.digitalocean.com/community/tutorials/understanding-sockets

https://developer.ibm.com/tutorials/l-sockpit/

On November 27, 2021 2:36:48 PM PST, Ben Engbers  wrote:
>Hi,
>
>Looks promising! Where can I find more information or tutorials about 
>psock or parallel computing?
>
>Best,
>Ben
>
>Op 27-11-2021 om 20:19 schreef Tomas Kalibera:
>> On 11/27/21 8:05 PM, Tomas Kalibera wrote:
>> 
>> This is an extended demo with socketSelect() used to wait on the client 
>> for some data to be available, to avoid consuming too much CPU by 
>> polling. To be pasted into two R sessions running on the same computer.
>> You would have to replace the function done() with something figuring 
>> out from the data whether it is complete or not, based on the protocol.
>> 
>> Best
>> Tomas
>> 
>> 
>> # the client
>> 
>> con2 <- socketConnection("localhost", port = 6011, open = "rb")
>> cat("Connected...\n")
>> total <- 0
>> 
>> done <- function(n) {
>>    n >= 2e8
>> }
>> 
>> while(!done(total)) {
>>     cat("Waiting for data to become ready...\n")
>>     socketSelect(list(con2))
>>     cat("Reading data...\n")
>>     r <- readBin(con2, "raw", 1024)
>>     total <- total + length(r)
>>     cat("Read", length(r), "bytes (total ", total, ").\n")
>> }
>> close(con2)
>> 
>> # the server
>> 
>> n <- 1e8
>> w <- as.raw(runif(n, 0, 255))
>> con1 <- socketConnection(port = 6011, blocking = TRUE, server = TRUE, 
>> open="a+b")
>> cat("Connected...\n")
>> writeBin(w, con1)
>> cat("Sent data the first time, sleeping...\n")
>> Sys.sleep(10)
>> cat("Sending data the second time...\n")
>> writeBin(w, con1)
>> cat("Data sent to client...\n")
>> close(con1)
>> 
>>>
>>> Best
>>> Tomas
>>>
>>> # the client
>>>
>>> con2 <- socketConnection("localhost", port = 6011, open = "rb")
>>> cat("Connected...\n")
>>> total <- 0
>>>
>>> done <- function(n) {
>>>   n >= 1e8
>>> }
>>>
>>> while(!done(total)) {
>>>    r <- readBin(con2, "raw", 1024)
>>>    total <- total + length(r)
>>>    cat("Read", length(r), "bytes (total ", total, ").\n")
>>> }
>>> close(con2)
>>>
>>> # the server
>>>
>>> n <- 1e8
>>> w <- as.raw(runif(n, 0, 255))
>>> con1 <- socketConnection(port = 6011, blocking = TRUE, server = TRUE, 
>>> open="a+b")
>>> cat("Connected...\n")
>>> writeBin(w, con1)
>>> cat("Data sent to client...\n")
>>> close(con1)
>>>

 Ben

 __
 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] Is using global assignment in package tests allowed?

[Jeff Newmiller]

I don't know the answer to your question, but "beyond my ken" doesn't sound 
like a very convincing reason. Mucking with any environment that isn't yours is 
asking for trouble... the behavior you depend on today may come into conflict 
with the code you are coordinating with when you least expect it.

Is your code in a public version control repo?

On January 27, 2022 6:55:49 AM PST, James Pustejovsky  wrote:
>Hello,
>
>I'm writing unit tests using testthat for a package that we want to submit
>to CRAN. Because of some aspect of how testthat works (which is beyond my
>ken), I have only been able to get my tests to work by using global
>assignment (<<-) to create some objects on which the tests are then run.
>However, per CRAN policy: "Packages should not modify the global
>environment (user’s workspace)."
>
>Does anyone know whether this policy applies to all code within the
>package, including unit tests? Or does it apply just to the code and
>functions in /R?
>Or to all code that is executed as part of checking the package (i.e., code
>that is never run can use <<-)?
>
>James
>
>   [[alternative HTML version deleted]]
>
>__
>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] handling of byte-order-mark on r-devel-linux-x86_64-debian-clang machine

[Jeff Newmiller]

Thanks to the ubiquity of Excel and its misguided inclusion of BOM codes in its 
UTF-8 CSV format, this optimism about encoding being a corner case seems 
premature. There are actually multiple options in Excel for writing CSV files, 
and only one of them (not the first one fortunately) has this "feature", but I 
(and various beginners I end up helping) seem to encounter these silly files 
far more frequently than seems reasonable.

On April 5, 2022 11:20:37 AM PDT, Tomas Kalibera  
wrote:
>
>On 3/28/22 13:16, Ivan Krylov wrote:
>> On Mon, 28 Mar 2022 09:54:57 +0200
>> Tomas Kalibera  wrote:
>>
>>> Could you please clarify which part you found somewhat confusing,
>>> could that be improved?
>> Perhaps "somewhat confusing" is an overstatement, sorry about that. All
>> the information is already there in both ?file and ?readLines, it just
>> requires a bit of thought to understand it.
>>
 When reading from a text connection, the connections code, after
 re-encoding based on the ‘encoding’ argument, returns text that is
 assumed to be in native encoding; an encoding mark is only added by
 functions that read from the connection, so e.g.  ‘readLines’ can
 be instructed to mark the text as ‘"UTF-8"’ or ‘"latin1"’, but
 ‘readLines’ does no further conversion.  To allow reading text in
 ‘"UTF-8"’ on a system that cannot represent all such characters in
 native encoding (currently only Windows), a connection can be
 internally configured to return the read text in UTF-8 even though
 it is not the native encoding; currently ‘readLines’ and ‘scan’ use
 this feature when given a connection that is not yet open and, when
 using the feature, they unconditionally mark the text as ‘"UTF-8"’.
>> The paragraph starts by telling the user that the text is decoded into
>> the native encoding, then tells about marking the encoding (which is
>> counter-productive when decoding arbitrarily-encoded text into native
>> encoding) and only then presents the exception to the native encoding
>> output rule (decoding into UTF-8). If I'm trying to read a
>> CP1252-encoded file on a Windows 7 machine with CP1251 as the session
>> encoding, I might get confused by the mention of encoding mark between
>> the parts that are important to me.
>>
>> It could be an improvement to mention that exception closer to the
>> first point of the paragraph and, perhaps, to split the "encoding mark"
>> part from the "text connection decoding" part:
>>
 Functions that read from the connection can add an encoding mark
 to the returned text. For example, ‘readLines’ can be instructed
 to mark the text as ‘"UTF-8"’ or ‘"latin1"’, but does no further
 conversion.

 When given a connection that is not yet open and has a non-default
 ‘encoding’ argument, ‘readLines’ and ‘scan’ internally configure the
 connection to read text in UTF-8. Otherwise, the text after decoding
 is assumed to be in native encoding.
>> (Maybe this is omitting too much and should be expanded.)
>>
>> It could also be helpful to mention the fact that the encoding argument
>> to readLines() can be ignored right in the description of that
>> argument, inviting the user to read the Details section for more
>> information.
>
>Thanks for the suggestions, I've rewritten the paragraphs, biasing 
>towards users who have UTF-8 as the native encoding as this is going to 
>be the majority. These users should not have to worry much about the 
>encoding marks anymore, nor about the internal UTF-8 mode of the 
>connections code. But the level of detail I think needs to remain as 
>long as these features are supported - the level of detail is based on 
>numerous questions and bug reports.
>
>Best
>Tomas
>
>__
>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] Rlang and Code Evalutation Within Aesthetics

[Jeff Newmiller]

Things like sensible legends are also impeded by using complex expressions in 
aesthetics mappings, so call it a workaround if you like but creating the data 
frame the way it should be _before_ giving it to ggplot has always been 
recommended.

On April 30, 2022 5:09:51 AM PDT, Duncan Murdoch  
wrote:
>On 30/04/2022 8:00 a.m., Dario Strbenac wrote:
>> Good day,
>> 
>> I am troubled understanding why the following example doesn't work:
>> 
>>> characteristicsList
>> $x
>> `Classifier Name`
>>> ggplot2::aes(fill = if(TRUE) NULL else 
>>> !!rlang::sym(characteristicsList[["fillColour"]]))
>> Error in `rlang::sym()`:
>> ! Can't convert NULL to a symbol.
>>> rlang::last_error()
>> 10. rlang::sym(characteristicsList[["fillColour"]])
>> 
>> but the following does work without error:
>> 
>>> if(TRUE) NULL else !!rlang::sym(characteristicsList[["fillColour"]])
>> NULL # It is desirably avoiding the else part.
>> 
>> The first example seems to be evaluating the else part, even though the if 
>> condition is true.
>> 
>> The overall aim is to allow the end-user to specify a named list of 
>> appearance-modifying parameters, and for the function to create a ggplot 
>> with them, without being bamboozled if the end-user's list doesn't contain 
>> the specification for fill colour variable name or line colour variable name 
>> (like the list in the example above does not have). Thanks in advance for 
>> any suggested reading.
>
>I'm pretty sure this isn't the right place to ask about ggplot2, but that 
>looks like a bug to me.
>
>Duncan Murdoch
>
>__
>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] Inquiry

[Jeff Newmiller]

If you haven't settled on exactly which approach you want to use in 
accomplishing the main goals of your exported package functions, then hiding 
the gory details can make it easier to tell people later to sod off when you 
decide those gory details functions should act different or use different 
function signatures.

Anyone regularly using ::: earns the lack of reproducibility they get.

On September 27, 2022 6:37:28 PM PDT, Rolf Turner  
wrote:
>
>On Tue, 27 Sep 2022 07:43:03 +
>Georgi Boshnakov  wrote:
>
>> >...functions, that are not meant to be called directly by users,
>> >should be documented in a file named -internal.Rd.  
>> 
>> This is one option, convenient in the use-case of the question. But
>> why export a function that you actively don't want the users to know
>> about?
>
>
>
>Why would you not want users to know about functions?  This strikes me
>as being overly authoritarian. Of course, to export or not to export
>is the choice of the package author.  It is also sensible to try to
>protect users from shooting themselves in the foot.  However if they
>really want to shoot themselves in the foot, that's their call.
>
>Anyway, users can always get at non-exported functions using ":::".
>
>cheers,
>
>Rolf Turner
>

-- 
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] How to decrease time to import files in xlsx format?

[Jeff Newmiller]

It looks like you are reading directly from URLs? How do you know the delay is 
not network I/O delay?

Parallel computation is not a panacea. It allows tasks _that are CPU-bound_ to 
get through the CPU-intensive work faster. You need to be certain that your 
tasks actually can benefit from parallelism before using it... there is a 
significant overhead and added complexity to using parallel processing that 
will lead to SLOWER processing if mis-used.

On October 4, 2022 11:29:54 AM PDT, Igor L  wrote:
>Hello all,
>
>I'm developing an R package that basically downloads, imports, cleans and
>merges nine files in xlsx format updated monthly from a public institution.
>
>The problem is that importing files in xlsx format is time consuming.
>
>My initial idea was to parallelize the execution of the read_xlsx function
>according to the number of cores in the user's processor, but apparently it
>didn't make much difference, since when trying to parallelize it the
>execution time went from 185.89 to 184.12 seconds:
>
># not parallelized code
>y <- purrr::map_dfr(paste0(dir.temp, '/', lista.arquivos.locais),
>   readxl::read_excel, sheet = 1, skip = 4, col_types =
>c(rep('text', 30)))
>
># parallelized code
>plan(strategy = future::multicore(workers = 4))
>y <- furrr::future_map_dfr(paste0(dir.temp, '/', lista.arquivos.locais),
> readxl::read_excel, sheet = 1, skip = 4,
>col_types = c(rep('text', 30)))
>
> Any suggestions to reduce the import processing time?
>
>Thanks in advance!
>

-- 
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] Issue handling datetimes: possible differences between computers

[Jeff Newmiller]

... which is why tidyverse functions and Python datetime handling irk me so 
much.

Is tidyverse time handling intrinsically broken? They have a standard practice 
of reading time as UTC and then using force_tz to fix the "mistake". Same as 
Python.

On October 9, 2022 6:57:06 PM PDT, Simon Urbanek  
wrote:
>Alexandre,
>
>it's better to parse the timestamp in correct timezone:
>
>> foo = as.POSIXlt("2021-10-01", "UTC")
>> as.POSIXct(as.character(foo), "Europe/Berlin")
>[1] "2021-10-01 CEST"
>
>The issue stems from the fact that you are pretending like your timestamp is 
>UTC (which it is not) while you want to interpret the same values in a 
>different time zone. The DST flags varies depending on the day (due to DST 
>being 0 or 1 depending on the date) and POSIXlt does not have that information 
>since you only attached the time zone without updating it:
>
>> str(unclass(as.POSIXlt(foo, "Europe/Berlin")))
>List of 9
> $ sec  : num 0
> $ min  : int 0
> $ hour : int 0
> $ mday : int 1
> $ mon  : int 9
> $ year : int 121
> $ wday : int 5
> $ yday : int 273
> $ isdst: int 0
> - attr(*, "tzone")= chr "Europe/Berlin"
>
>note that isdst is 0 from the UTC entry (which doesn't have DST) even though 
>that date is actually DST in CEST. Compare that to the correctly parsed 
>POSIXlt:
>
>> str(unclass(as.POSIXlt(as.character(foo), "Europe/Berlin")))
>List of 11
> $ sec   : num 0
> $ min   : int 0
> $ hour  : int 0
> $ mday  : int 1
> $ mon   : int 9
> $ year  : int 121
> $ wday  : int 5
> $ yday  : int 273
> $ isdst : int 1
> $ zone  : chr "CEST"
> $ gmtoff: int NA
> - attr(*, "tzone")= chr "Europe/Berlin"
>
>where isdst is 1 since it is indeed the DST. The OS difference seems to be 
>that Linux respects the isdst information from POSIXlt while Windows and macOS 
>ignores it. This behavior is documented: 
>
> At all other times ‘isdst’ can be deduced from the
> first six values, but the behaviour if it is set incorrectly is
> platform-dependent.
>
>You can re-set isdst to -1 to make sure R will try to determine it:
>
>> foo$isdst = -1L
>> as.POSIXct(foo, "Europe/Berlin")
>[1] "2021-10-01 CEST"
>
>So, generally, you cannot simply change the time zone in POSIXlt - don't 
>pretend the time is in UTC if it's not, you have to re-parse or re-compute the 
>timestamps for it to be reliable or else the DST flag will be wrong.
>
>Cheers,
>Simon
>
>
>> On 10/10/2022, at 1:14 AM, Alexandre Courtiol  
>> wrote:
>> 
>> Hi R pkg developers,
>> 
>> We are facing a datetime handling issue which manifests itself in a
>> package we are working on.
>> 
>> In context, we noticed that reading datetime info from an excel file
>> resulted in different data depending on the computer we used.
>> 
>> We are aware that timezone and regional settings are general sources
>> of troubles, but the code we are using was trying to circumvent this.
>> We went only as far as figuring out that the issue happens when
>> converting a POSIXlt into a POSIXct.
>> 
>> Please find below, a minimal reproducible example where `foo` is
>> converted to `bar` on two different computers.
>> `foo` is a POSIXlt with a defined time zone and upon conversion to a
>> POSIXct, despite using a set time zone, we end up with `bar` being
>> different on Linux and on a Windows machine.
>> 
>> We noticed that the difference emerges from the system call
>> `.Internal(as.POSIXct())` within `as.POSIXct.POSIXlt()`.
>> We also noticed that the internal function in R actually calls
>> getenv("TZ") within C, which is probably what explains where the
>> difference comes from.
>> 
>> Such a behaviour is probably expected and not a bug, but what would be
>> the strategy to convert a POSIXlt into a POSIXct that would not be
>> machine dependent?
>> 
>> We finally noticed that depending on the datetime used as a starting
>> point and on the time zone used when calling `as.POSIXct()`, we
>> sometimes have a difference between computers and sometimes not...
>> which adds to our puzzlement.
>> 
>> Many thanks.
>> Alex & Liam
>> 
>> 
>> ``` r
>> ## On Linux
>> foo <- structure(list(sec = 0, min = 0L, hour = 0L, mday = 1L, mon =
>> 9L, year = 121L, wday = 5L, yday = 273L, isdst = 0L),
>> class = c("POSIXlt", "POSIXt"), tzone = "UTC")
>> 
>> bar <- as.POSIXct(foo, tz = "Europe/Berlin")
>> 
>> bar
>> #> [1] "2021-10-01 01:00:00 CEST"
>> 
>> dput(bar)
>> #> structure(1633042800, class = c("POSIXct", "POSIXt"), tzone =
>> "Europe/Berlin")
>> ```
>> 
>> ``` r
>> ## On Windows
>> foo <- structure(list(sec = 0, min = 0L, hour = 0L, mday = 1L, mon =
>> 9L, year = 121L, wday = 5L, yday = 273L, isdst = 0L),
>> class = c("POSIXlt", "POSIXt"), tzone = "UTC")
>> 
>> bar <- as.POSIXct(foo, tz = "Europe/Berlin")
>> 
>> bar
>> #> [1] "2021-10-01 CEST"
>> 
>> dput(bar)
>> structure(1633046400, class = c("POSIXct", "POSIXt"), tzone = 
>> "Europe/Berlin")
>> ```
>> 
>> -- 
>> Alexandre Courtiol, www.datazoogang.de
>> 
>> __
>> R

Re: [R-pkg-devel] Issue handling datetimes: possible differences between computers

[Jeff Newmiller]

I have no idea how to get readxl::read_excel to import a timestamp column in a 
timezone. It is true that Excel has no concept of timezones, but the data one 
finds there usually came from a text file at some point. Importing as character 
is a feasible strategy, but trying to convince an intermediate user to go to 
that much trouble is a headache when the issue is ignored in the help file.

It is evidently possible to specify a locale input to readr::read_csv, but the 
default behaviour guesses timestamp columns and assumes "UTC", and a file may 
contain data from different timezones (UTC and local civil are a common 
combination). Again, character import and manual conversion are needed.

On October 10, 2022 9:40:42 AM PDT, Hadley Wickham  wrote:
>On Sun, Oct 9, 2022 at 9:31 PM Jeff Newmiller  wrote:
>>
>> ... which is why tidyverse functions and Python datetime handling irk me so 
>> much.
>>
>> Is tidyverse time handling intrinsically broken? They have a standard 
>> practice of reading time as UTC and then using force_tz to fix the 
>> "mistake". Same as Python.
>
>Can you point to any docs that lead you to this conclusion so we can
>get them fixed? I strongly encourage people to parse date-times in the
>correct time zone; this is why lubridate::ymd_hms() and friends have a
>tz argument.
>
>Hadley
>

-- 
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] Cannot submit package due to false-positive rejection

[Jeff Newmiller]

This is definitely not a false positive. Find a way to not run long calcs 
during the CRAN build. There is no alternative.

One way this can be done is by only running your examples when an environment 
variable of your choosing exists. Since CRAN machines won't configure that 
variable, you can get around this hard requirement.

On October 28, 2022 12:48:44 PM PDT, Ying Li via R-package-devel 
 wrote:
>Hello all,
>
>Our package did not pass the automagical checks when submitted to CRAN. We 
>think the rejection is a false positive, so we �reply-all to that message and 
>explain� as following the official instruction. We provided explanation for 
>all notes in that email (replied to 
>cran-submissi...@r-project.org) but did 
>not receive any message after 9 days.
>
>I am looking for suggestions on what to do in this case: should we continue 
>waiting for CRAN team�s reply? Or is it necessary to eliminate those notes and 
>then submit the package again?
>
>Below are the notes from CRAN teams' auto-check service and our explanation 
>send to CRAN team:
>
>>Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64
>>Check: CRAN incoming feasibility, Result: NOTE
>> Maintainer: 'Arindam RoyChoudhury 
>> mailto:arr2...@med.cornell.edu>>'
>
>>  New submission
>
>>  Possibly misspelled words in DESCRIPTION:
>>Peng (17:5)
>>Phylogenetics (17:32)
>>   al (17:13)
>>et (17:10)
>
>> Size of tarball: 14208488 bytes
>
>Explain:  This is a new submission. These words are not misspelled.
>
>>Flavor: r-devel-windows-x86_64
>>Check: examples, Result: NOTE
>>  Examples with CPU (user + system) or elapsed time > 10s
>>   user system elapsed
>>  RDM 40.05   0.89   40.94
>
>Explain:  This is because a large dataset is used in the example. An example 
>with large dataset is necessary, as this package is meant for analyzing large 
>datasets.
>
>
>>Flavor: r-devel-linux-x86_64-debian-gcc
>>Check: examples, Result: NOTE
>> Examples with CPU (user + system) or elapsed time > 5s
>>  user system elapsed
>>  RDM 24.399  0.888  25.289
>
>Explain:  This is because a large dataset is used in the example. An example 
>with large dataset is necessary, as this package is meant for analyzing large 
>datasets.
>
>Any suggestions or comments would be appreciated. Thank you in advance!
>
>Best,
>Ying
>
>
>
>   [[alternative HTML version deleted]]
>

-- 
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] Logical Inconsistency of check regarding URL?

[Jeff Newmiller]

Educating package authors about the semantics of URLs is not really something 
the CRAN maintainers should have to do. A slash at the end of a URL implies 
different URL construction for relative URLs based on the original one. [1]

I am not sure why you think https is no more secure than http... that is 
exactly why it exists. Again, not the job of CRAN maintainers to explain this 
to you.

It is not appropriate to rely on URL redirection (from deepbionics to github) 
in a package... redirections are extra work and hide the true url from the user 
anyway.

As for having the same URL accepted in one package but rejected in another... 
well, CRAN moderators are not perfect. They try to automate identification of 
issues that have previously caused problems, but maybe they don't catch 
everything every time.

Yes, making software that doesn't break in odd situations is hard. Thank you 
for making an effort, and thank CRAN for remembering all of these mysterious 
problems and warning you to fix things that might only break in situations you 
haven't directly encountered before they puzzle new R users.

[1] 
https://stackoverflow.com/questions/5948659/when-should-i-use-a-trailing-slash-in-my-url

On November 28, 2022 11:19:40 PM PST, "Dr. habil. Michael Thrun" 
 wrote:
>Dear All,
>I got from Uwe the following message after uploading an update of my package 
>“DatabionicSwarm”.  "Found the  following (possibly) invalid URLs: URL:  
>https://www.deepbionics.org (moved to  https://mthrun.github.io/index) From: 
>DESCRIPTION Status: 301 Message: Moved Permanently
>Please change http --> https, add trailing slashes, or follow moved content as 
>appropriate.
>"
> I asked then
>"
>Dear Uwe,
>your request states to either
>Please  change http --> https, add trailing slashes or to  follow moved 
>content as appropriate.
>As it is not  appropriate to follow content, I select the first   choice. the 
>URL is 
>"https://www.deepbionics.org/"; 
> which mets both conditions of beeing "https" and 
> having at the end one "/".
>What is the problem?  Please elaborate.
>You already accepted another  package GeneralizedUmatrix today with exactly 
>same 
> url. I really dont understand it. Please be so kind 
> to elabore.”
>
> As an answer I got
>"You are abusig the system! Again: ”
>
>Hence, I have several questions.
>First, do we not communicate with CRAN anymore through the submission 
>procedure of the package? If not, which is the correct line of communication 
>in such a case?
>
>Second, are the answers that we get now fully automatically generated? It 
>would be strange for me to believe that Uwe would provide such an answer to my 
>polite request.
>
>Third, why can I have a CRAN package "DataVisualizations" with this URL 
>online, another one named "GeneralizedUmatrix" uploaded the same day with the 
>same URL, which both are OK, but the URL in "DatabionicSwarm" is not?
>
>Forth, can't we have more clear feedback messages?
>I mean, having in the description the URL "https://www.deepbionics.org/"; and 
>getting the feedback "http --> https, add trailing slashes or ... "does not 
>make any sense. Also, could someone please explain why is a "/" at the end of 
>an URL necessary? What is the technical background to this?
>
>Fifth, why do we need https/TLS/SSL? I have to pay a monthly fee for a 
>certificate to apply this to my website so that CRAN accepts my URL - and as 
>far as I can tell, it makes things only more complex but not more secure 
>(e.g., https://www.elektronik-kompendium.de/sites/net/1906041.htm). Or in 
>other words, it seems to me that we are expected to pay to follow the 
>guideline of having a certificate instead of making better code with fewer 
>bugs. I am no security expert, but my baseline in computer science is always 
>if a tool is more complex, then the chances are lower that it works as 
>intended, and the possibilities are higher that it has unintended and 
>potentially risky side effects.
>
>Best Regards
>
>Michael
> 
>__
>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] Question on Description/Citing Feedback

[Jeff Newmiller]

Isn't the whole purpose of creating a new package to introduce new algorithms? 
That there is a history related to the modelsummary package is fine, but I 
think the request is for references to published discussion of why modelsummary 
needed to be augmented with new algorithms. It seems to me that other than 
mentioning that this package augments modelsummary that issue is moot... rather 
you need to expand on why this package is relevant.

On December 16, 2022 10:06:44 AM PST, Michael Topper  
wrote:
>Hello all,
>
>I just received feedback from my first CRAN submission. Currently, I am a
>little confused as to one point of the feedback which reads:
>
>
>
>
>
>
>
>
>
>*If there are references describing the methods in your package, pleaseadd
>these in the description field of your DESCRIPTION file in the formauthors
>(year) authors (year) authors (year, ISBN:...)or if
>those are not available: with no space after 'doi:', 'arXiv:',
>'https:' and angle brackets forauto-linking. (If you want to add a title as
>well please put it inquotes: "Title")*
>
>For some background:
>
>   - My package is named panelsummary. The link to the github can be found
>   here: https://github.com/michaeltopper1/panelsummary
>   - My package inherits some documentation of some of the parameters from
>   the package modelsummary
>   . In particular, two
>   of my functions (panelsummary::panelsummary and
>   panelsummary::panelsummary_raw) share a couple of the same arguments as
>   modelsummary::modelsummary. I used roxygen2 (@inherits) to generate
>   documentation for the shared arguments.
>   - Because of this inherited documentation, I have also included the
>   author/creator of modelsummary as a copyright holder in the DESCRIPTION
>   file with a comment.
>
>
>My confusion:
>
>   - I understand the Description portion of the DESCRIPTION file needs to
>   be edited, but I'm a little confused as to what I am supposed to add and
>   how. Do I need to include a citation to the published paper of
>   modelsummary and describe where I use the documentation? Modelsummary was
>   published in the journal of statistical software and the following was
>   included on the modelsummary release information:
>  - Arel-Bundock, Vincent (2022). “modelsummary: Data and Model
>  Summaries in R.” Journal of Statistical Software, 103(1), 1-23.
>  doi:10.18637/jss.v103.i01 https://doi.org/10.18637/jss.v103.i01.’
>
>What would be most helpful:
>
>   - If there is any other Description file from another package that
>   contains an example of what to do in such a situation, this would be
>   greatly appreciated!
>
>Please let me know if any additional details are needed, and thank you so
>much for your help/time!
>
>Michael
>
>   [[alternative HTML version deleted]]
>
>__
>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] Pretest failed and I fail to find out what's the problem

[Jeff Newmiller]

Long build time for vignettes?

On January 22, 2023 10:51:30 AM PST, Klaus Schliep  
wrote:
> Dear all,
>
>I try to submit a new version of the package phangorn and got the mail back:
>
>"Dear maintainer,
>
>package phangorn_2.11.0.tar.gz does not pass the incoming checks
>automatically, please see the following pre-tests:
>Windows: <
>https://win-builder.r-project.org/incoming_pretest/phangorn_2.11.0_20230122_175755/Windows/00check.log
>>
>Status: OK
>Debian: <
>https://win-builder.r-project.org/incoming_pretest/phangorn_2.11.0_20230122_175755/Debian/00check.log
>>
>Status: OK"
>
>I am kind of puzzled as to what the problem is, but it might well be that I
>missed something? I appreciate any suggestions.
>
>Kind regards,
>Klaus Schliep
>
>

-- 
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] Problems with devtools::build() in R

[Jeff Newmiller]

Your mistake is confusing a tool designed for _iterative development_ for a 
tool designed for _delivery_.

Use R CMD build the way WRE says you should.

On May 16, 2023 9:07:05 AM PDT, Jarrett Phillips  
wrote:
>Hi All,
>
>I'm trying to generate a `tar.gz` file on a Mac for R package submission to
>CRAN but am having issues.
>
>I'm using `devtools`, specifically `build()` and `install()`.
>
>My package relies on compiled code via `Rcpp/RcppArmadillo`.
>
>build("HACSim_OO")
>── R CMD build
>─
>✔  checking for file ‘/Users/jarrettphillips/Desktop/HAC
>simulation/HACSim_OO/DESCRIPTION’ ...
>─  preparing ‘HACSim’:
>✔  checking DESCRIPTION meta-information ...
>─  cleaning src
>─  installing the package to process help pages
> ---
>─  installing *source* package ‘HACSim’ ...
>   ** using staged installation
>   ** libs
>   clang++ -arch arm64 -std=gnu++11 -
>I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
> -I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/Rcpp/include'
>-I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/RcppArmadillo/include'
>-I/opt/R/arm64/include-fPIC  -falign-functions=64 -Wall -g -O2  -Wall
>-pedantic -fdiagnostics-color=always -c RcppExports.cpp -o RcppExports.o
>   clang++ -arch arm64 -std=gnu++11
>-I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
> -I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/Rcpp/include'
>-I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/RcppArmadillo/include'
>-I/opt/R/arm64/include-fPIC  -falign-functions=64 -Wall -g -O2  -Wall
>-pedantic -fdiagnostics-color=always -c accumulate.cpp -o accumulate.o
>   clang++ -arch arm64 -std=gnu++11 -dynamiclib
>-Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module
>-multiply_defined suppress -L/Library/Frameworks/R.framework/Resources/lib
>-L/opt/R/arm64/lib -o HACSim.so RcppExports.o accumulate.o
>-L/Library/Frameworks/R.framework/Resources/lib -lRlapack
>-L/Library/Frameworks/R.framework/Resources/lib -lRblas
>-L/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.6.0/12.0.1
>-L/opt/R/arm64/gfortran/lib -lgfortran -lemutls_w -lquadmath
>-F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework
>-Wl,CoreFoundation
>   ld: warning: directory not found for option
>'-L/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.6.0/12.0.1'
>   ld: warning: directory not found for option
>'-L/opt/R/arm64/gfortran/lib'
>   ld: library not found for -lgfortran
>   clang: error: linker command failed with exit code 1 (use -v to see
>invocation)
>   make: *** [HACSim.so] Error 1
>   ERROR: compilation failed for package ‘HACSim’
>─  removing
>‘/private/var/folders/r4/xm5blbcd2tn06tjv00lm1c78gn/T/RtmpN4uaYR/Rinstdf4219594de/HACSim’
> ---
>ERROR: package installation failed
>Error in `(function (command = NULL, args = character(),
>error_on_status = TRUE, …`:
>! System command 'R' failed
> ---
> Exit status: 1
> stdout & stderr: 
> ---
>Type .Last.error to see the more details.
>
>`clang` is installed (since I am able to run the code within my package)
>and I've verified by typing `gcc` in the Mac Terminal. I've also installed
>`Homebrew` and `gfortran`, verifying via typing in the Terminal.
>
>Any idea on what's going on how to fix the issue(s)?
>
>Thanks!
>
>Cheers,
>
>Jarrett
>
>   [[alternative HTML version deleted]]
>
>__
>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 broke with R 4.3.0

[Jeff Newmiller]

if (any(c( "alaska", "hawaii") %in% zoom)){}

On June 27, 2023 9:11:09 AM PDT, "Göran Broström"  wrote:
>
>
>Den 2023-06-27 kl. 17:17, skrev Göran Broström:
>> If(zoom %in% c(“alaska”,  “hawaii”)…
>
>Wrong, maybe
>
>if (("alaska" %in% zoom) || ("hawaii" %in% zoom)){}
>
>
>> 
>> Göran
>> 
>>> 27 juni 2023 kl. 16:32 skrev arilamst...@gmail.com:
>>> 
>>> It appears that my R package choroplethr broke due to this change in R
>>> 4.3.0:
>>> 
>>> CHANGES IN R 4.3.0:
>>> 
>>> SIGNIFICANT USER-VISIBLE CHANGES:
>>> 
>>> Calling && or || with LHS or (if evaluated) RHS of length greater than one
>>> is now always an error, with a report of the form
>>> 
>>> 'length = 4' in coercion to 'logical(1)'
>>> Environment variable R_CHECK_LENGTH_1_LOGIC2 no longer has any effect.
>>> 
>>> The specific line which broke is this:
>>> https://github.com/arilamstein/choroplethr/blob/master/R/usa.R#L24
>>> 
>>> The bug can be reproduced like this:
>>> 
>>> zoom = c("arizona", "arkansas", "louisiana", "minnesota", "mississippi",
>>>   "montana", "new mexico", "north dakota", "oklahoma", "pennsylvania",
>>>   "tennessee", "virginia", "california", "delaware", "west virginia",
>>>   "wisconsin", "wyoming", "alabama", "alaska", "florida", "idaho",
>>>   "kansas", "maryland", "colorado", "new jersey", "north carolina",
>>>   "south carolina", "washington", "vermont", "utah", "iowa",
>>> "kentucky",
>>>   "maine", "massachusetts", "connecticut", "michigan", "missouri",
>>>   "nebraska", "nevada", "new hampshire", "new york", "ohio", "oregon",
>>>   "rhode island", "south dakota", "district of columbia", "texas",
>>>   "georgia", "hawaii", "illinois", "indiana")
>>> 
>>> if (zoom == "alaska" || zoom == "hawaii") {}
>>> Error in zoom == "alaska" || zoom == "hawaii" :
>>>   'length = 51' in coercion to 'logical(1)'
>>> 
>>> I have two questions:
>>> 
>>> 1. Can someone explain why this change was introduced to the language?
>>> 2. Can someone tell me if there is a preferred, idiomatic way to rewrite my
>>> code?
>>> 
>>> I came up with two solutions that work. The first checks whether zoom is of
>>> length 1:
>>> 
>>> if ((length(zoom) == 1) && (zoom %in% c("alaska", "hawaii"))) { }
>>> 
>>> The second keeps the vector recycling, but then uses all to coerce the
>>> vector to be a single value. In retrospect, I think I likely assumed that
>>> this is what R < 4.3.0 was doing when the code worked. (But I wrote this
>>> code many years ago, so I can't be sure!):
>>> 
>>> if (all(zoom == "alaska") || all(zoom == "hawaii")) {}
>>> 
>>> Thanks in advance.
>>> 
>>> Ari
>>> 
>>> [[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
>
>__
>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] Public URLs for help for versions of base packages

[Jeff Newmiller]

Sure. On your computer. Install the old version of R and let it serve the 
relevant docs.

Dunno of anyone doing this historical dive online for you though. Why would you 
want preformatted docs if you didn't have those old versions installed?

On June 29, 2023 4:23:55 PM PDT, David Hugh-Jones  
wrote:
>That’s useful to know. But is there anywhere with preformatted HTML pages?
>
>Cheers, D
>
>On Thu, 29 Jun 2023 at 21:46, Ivan Krylov  wrote:
>
>> On Thu, 29 Jun 2023 20:22:47 +0100
>> David Hugh-Jones  wrote:
>>
>> > I'm looking for a source of online help for R base
>> > packages, which covers all versions (for some reasonable value of
>> > "all"). So e.g. the equivalent of `?lm` for R 4.1.0.
>>
>> These live in the R source tree, under src/library:
>> https://svn.r-project.org/R/trunk/src/library/
>>
>> For the actual releases of R, you may have to go looking at the
>> branches inside that repository, e.g., the following command:
>>
>> svn log \
>>
>> https://svn.r-project.org/R/branches/R-4-1-branch/src/library/stats/man/lm.Rd
>>
>> ...should tell you the history of ?lm until the latest R-4.1-patched.
>>
>> Do the Git mirrors track these release branches? The branching model of
>> Subversion [*] is different from the Git model, so perhaps not.
>>
>> --
>> Best regards,
>> Ivan
>>
>> [*] https://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html
>>

-- 
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 Load fails to find 3rd Party DLL

[Jeff Newmiller]

Use of precompiled code is not allowed in CRAN. This looks like your package 
needs to be distributed elsewhere... e.g. via GitHub.

On July 12, 2023 6:41:11 AM PDT, Russell Almond  
wrote:
>I have an R package (RNetica available at 
>https://ralmond.r-universe.dev/RNetica and 
>https://github.com/ralmond/RNetica) which links to a 3rd party library 
>Netica.dll, so RNetica.dll (built from my C code) calls the 3rd party code.
>
>The config.win script downloads Netica.dll and moves it into the 
>libs/x64 directory, where it should get loaded when RNetica.dll is 
>loaded.  However this is not happening:
>
>Here is the relevant portion of the build log (build is on R-universe, 
>but I think it is the same script as CRAN):
>
>```
>
>cp 
>"/d/a/ralmond/ralmond/RNETIC~1.RCH/00_PKG~1/RNetica/src/Netica/Netica_API_5
>10/lib64/Netica.dll" 
>"D:/a/ralmond/ralmond/RNetica.Rcheck/00LOCK-RNetica/00new/R
>Netica/libs/x64"
>   cp 
>"/d/a/ralmond/ralmond/RNETIC~1.RCH/00_PKG~1/RNetica/src/Netica/Netica_API_5
>10/lib64/Netica.lib" 
>"D:/a/ralmond/ralmond/RNetica.Rcheck/00LOCK-RNetica/00new/R
>Netica/libs/x64"
>   C:\rtools43\x86_64-w64-mingw32.static.posix\bin\nm.exe: 'NeticaDLL': 
>No such f
>ile
>   gcc -shared -s -static-libgcc -o RNetica.dll tmp.def Cases.o 
>Continuous.o Edge
>s.o Experience.o Inference.o Networks.o Node.o Random.o Registration.o 
>Session.o
>  -L. 
>-LD:/a/ralmond/ralmond/RNetica.Rcheck/00LOCK-RNetica/00new/RNetica/libs/x64
>  -lNetica -LC:/rtools43/x86_64-w64-mingw32.static.posix/lib/x64 
>-LC:/rtools43/x8
>6_64-w64-mingw32.static.posix/lib -LC:/R/bin/x64 -lR
>   C:\rtools43\x86_64-w64-mingw32.static.posix\bin/ld.exe: internal 
>error: aborti
>ng at ../../binutils-2.40/ld/ldlang.c:527 in compare_section
>   C:\rtools43\x86_64-w64-mingw32.static.posix\bin/ld.exe: please report 
>this bug
>   collect2.exe: error: ld returned 1 exit status
>```
>
>A little bit of searching on the internet, indicates that Windows 
>sometimes reports Dll A not found when Dll A needs Dll B and it can't 
>find B.
>
>This used to work under older versions of R and the tool chain and I 
>don't think I've changed anything related to the C side of the code.
>
>1) Have the paths changed, so I no longer should be moving the (64 bit 
>version of the) 3rd party DLL to `libs/x64`?
>
>2) Is there something that has changed with the mingw tools (nm.exe and 
>ld.exe) which are changing things?
>
>3) Is there a change on how win32 and win64 variants are handled (I have 
>both 32 and 64 bit copies of the 3rd party DLL, I just need to move them 
>to the right places).
>
>Thanks for any enlightenment you can offer,
>
>     --Russell Almond
>
>
>
>

-- 
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] Trouble with long-running tests on CRAN debian server

[Jeff Newmiller]

To whom are you addressing this question? The OpenMP developers who define the 
missing-OMP_THREAD_LIMIT behaviour and-or supply default config files? The CRAN 
server administrators who set the variable in their site-wide configuration 
intentionally or unintentionally? Or the package authors expected to kludge in 
settings to override those defaults for CRAN testing while not overriding them 
in normal use?

I would vote for explicitly addressing this (rhetorical?) question to the CRAN 
server administrators...

On August 23, 2023 6:31:01 AM PDT, Uwe Ligges  
wrote:
>I (any many collegues here) have been caught several times by the following 
>example:
>
>1. did something in parallel on a cluster, set up via parallel::makeCluster().
>2. e.g. allocated 20 cores and got them on one single machine
>3. ran some code in parallel via parLapply()
>
>Bang! 400 threads;
>So I have started 20 parallel processes, each of which is using the 
>automatically set max. 20 threads as OMP_THREAD_LIMIT was also adjusted by the 
>cluster to 20 (rather than 1).
>
>Hence, I really believe a default should always be small, not only in examples 
>and tests, but generally. And people who aim for more should be able to 
>increase the defaults.
>
>Do you believe a software that auto-occupies a 96 core machines with 96 
>threads by default is sensible?
>
>Best,
>Uwe Ligges
>
>
>
>
>
>
>On 21.08.2023 21:59, Berry Boessenkool wrote:
>> 
>> If you add that to each exported function, isn't that a lot of code to read 
>> + maintain?
>> Also, it seems like unnecessary computational overhead.
>>  From a software design point of view, it might be nicer to set that in the 
>> examples + tests.
>> 
>> Regards,
>> Berry
>> 
>> 
>> From: R-package-devel  on behalf of 
>> Scott Ritchie 
>> Sent: Monday, August 21, 2023 19:23
>> To: Dirk Eddelbuettel 
>> Cc: r-package-devel@r-project.org 
>> Subject: Re: [R-pkg-devel] Trouble with long-running tests on CRAN debian 
>> server
>> 
>> Thanks Dirk and Ivan,
>> 
>> I took a slightly different work-around of forcing the number of threads to
>> 1 when running functions of the test dataset in the package, by adding the
>> following to each user facing function:
>> 
>> ```
>># Check if running on package test_data, and if so, force data.table to
>> be
>># single threaded so that we can avoid a NOTE on CRAN submission
>>if (isTRUE(all.equal(x, ukbnmr::test_data))) {
>>  registered_threads <- getDTthreads()
>>  setDTthreads(1)
>>  on.exit({ setDTthreads(registered_threads) }) # re-register so no
>> unintended side effects for users
>>}
>> ```
>> (i.e. here x is the input argument to the function)
>> 
>> It took some trial and error to get to pass the CRAN tests; the number of
>> columns in the input data was also contributing to the problem.
>> 
>> Best,
>> 
>> Scott
>> 
>> 
>> On Mon, 21 Aug 2023 at 14:38, Dirk Eddelbuettel  wrote:
>> 
>>> 
>>> On 21 August 2023 at 16:05, Ivan Krylov wrote:
>>> | Dirk is probably right that it's a good idea to have OMP_THREAD_LIMIT=2
>>> | set on the CRAN check machine. Either that, or place the responsibility
>>> | on data.table for setting the right number of threads by default. But
>>> | that's a policy question: should a CRAN package start no more than two
>>> | threads/child processes even if it doesn't know it's running in an
>>> | environment where the CPU time / elapsed time limit is two?
>>> 
>>> Methinks that given this language in the CRAN Repository Policy
>>> 
>>>If running a package uses multiple threads/cores it must never use more
>>>than two simultaneously: the check farm is a shared resource and will
>>>typically be running many checks simultaneously.
>>> 
>>> it would indeed be nice if this variable, and/or equivalent ones, were set.
>>> 
>>> As I mentioned before, I had long added a similar throttle (not for
>>> data.table) in a package I look after (for work, even). So a similar
>>> throttler with optionality is below. I'll add this to my `dang` package
>>> collecting various functions.
>>> 
>>> A usage example follows. It does nothing by default, ensuring 'full power'
>>> but reflects the minimum of two possible options, or an explicit count:
>>> 
>>>  > dang::limitDataTableCores(verbose=TRUE)
>>>  Limiting data.table to '12'.
>>>  > Sys.setenv("OMP_THREAD_LIMIT"=3);
>>> dang::limitDataTableCores(verbose=TRUE)
>>>  Limiting data.table to '3'.
>>>  > options(Ncpus=2); dang::limitDataTableCores(verbose=TRUE)
>>>  Limiting data.table to '2'.
>>>  > dang::limitDataTableCores(1, verbose=TRUE)
>>>  Limiting data.table to '1'.
>>>  >
>>> 
>>> That makes it, in my eyes, preferable to any unconditional 'always pick 1
>>> thread'.
>>> 
>>> Dirk
>>> 
>>> 
>>> ##' Set threads for data.table respecting possible local settings
>>> ##'
>>> ##' This function set the number of threads \pkg{data.table} will use
>>> ##' while reflecting two possible machine-speci

Re: [R-pkg-devel] Trouble with long-running tests on CRAN debian server

[Jeff Newmiller]

I think one should be very cautious about overriding "standard" mechanisms for 
controlling software infrastructure like OpenMP.  You risk making the task of 
navigating the already-complex task of configuring the software environment 
even more complex by increasing the number of places you have to look in to 
find out why the mechanism documented by OpenMP is having no effect.

It may be that R Core agrees with you and creates an R-specific setting to 
control this... but IMO it should be accompanied by warning messages to help 
people figure out why their real work is underperforming if they link with 
compiled code that is supposed to make use of threads.

On August 23, 2023 7:24:46 AM PDT, Uwe Ligges  
wrote:
>
>
>On 23.08.2023 15:58, Jeff Newmiller wrote:
>> To whom are you addressing this question? The OpenMP developers who define 
>> the missing-OMP_THREAD_LIMIT behaviour and-or supply default config files? 
>> The CRAN server administrators who set the variable in their site-wide 
>> configuration intentionally or unintentionally? Or the package authors 
>> expected to kludge in settings to override those defaults for CRAN testing 
>> while not overriding them in normal use?
>
>Of course , the CRAN teams controls the env vars on the CRAN servers, but not 
>on a server a user might use. And a user is typically unaware that a package 
>uses multithreading.
>R users are typically not developers with a lot of insight in computer 
>science. Most R users I know would not even know how to set an env var.
>
>So why do you ecxpect your users to set an appropriate OMP_THREAD_LIMIT? 
>Particularly when they aim at parallelization, they have to set it to 1.
>I advocate not only to limit the number of cores for CRAN but also (and 
>inparticular)  the default! Something we cannot check easily.
>
>
>An alternative would be to teach R to set OMP_THREAD_LIMIT=1 locally by 
>default and a mechanism to change that for users.
>
>Best,
>Uwe Ligges
>
>
>> 
>> I would vote for explicitly addressing this (rhetorical?) question to the 
>> CRAN server administrators...
>> 
>> On August 23, 2023 6:31:01 AM PDT, Uwe Ligges 
>>  wrote:
>>> I (any many collegues here) have been caught several times by the following 
>>> example:
>>> 
>>> 1. did something in parallel on a cluster, set up via 
>>> parallel::makeCluster().
>>> 2. e.g. allocated 20 cores and got them on one single machine
>>> 3. ran some code in parallel via parLapply()
>>> 
>>> Bang! 400 threads;
>>> So I have started 20 parallel processes, each of which is using the 
>>> automatically set max. 20 threads as OMP_THREAD_LIMIT was also adjusted by 
>>> the cluster to 20 (rather than 1).
>>> 
>>> Hence, I really believe a default should always be small, not only in 
>>> examples and tests, but generally. And people who aim for more should be 
>>> able to increase the defaults.
>>> 
>>> Do you believe a software that auto-occupies a 96 core machines with 96 
>>> threads by default is sensible?
>>> 
>>> Best,
>>> Uwe Ligges
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 21.08.2023 21:59, Berry Boessenkool wrote:
>>>> 
>>>> If you add that to each exported function, isn't that a lot of code to 
>>>> read + maintain?
>>>> Also, it seems like unnecessary computational overhead.
>>>>   From a software design point of view, it might be nicer to set that in 
>>>> the examples + tests.
>>>> 
>>>> Regards,
>>>> Berry
>>>> 
>>>> 
>>>> From: R-package-devel  on behalf of 
>>>> Scott Ritchie 
>>>> Sent: Monday, August 21, 2023 19:23
>>>> To: Dirk Eddelbuettel 
>>>> Cc: r-package-devel@r-project.org 
>>>> Subject: Re: [R-pkg-devel] Trouble with long-running tests on CRAN debian 
>>>> server
>>>> 
>>>> Thanks Dirk and Ivan,
>>>> 
>>>> I took a slightly different work-around of forcing the number of threads to
>>>> 1 when running functions of the test dataset in the package, by adding the
>>>> following to each user facing function:
>>>> 
>>>> ```
>>>> # Check if running on package test_data, and if so, force data.table to
>>>> be
>>>> # single threaded so that we can avoid a NOTE on CRAN submission
>>>> if (isTRUE(all.equal(x, ukbnmr::test_data))) {
>>>>   register

Re: [R-pkg-devel] Re-building vignettes had CPU time 9.2 times elapsed time

[Jeff Newmiller]

Sanity seems to be in the eye of the beholder. FWIW I am certainly not CRAN or 
R Core, but I pretty strongly disagree with any package that defaults to using 
more than 2 cores. If I am using a shared HPC I can get in trouble if I 
over-consume cpu resources ... i.e. I may be given access to 10 cores out of 
128, and I would rather be reading the documentation to figure out how to boost 
performance on my own time rather than getting kicked out for not playing nice 
on the sysadmin's schedule.

Data.table can do lots of things to educate users how to or make it easier to 
reserve more resources, but they cannot argue with my sysadmin for me.

On August 25, 2023 4:01:33 PM PDT, Dirk Eddelbuettel  wrote:
>
>On 25 August 2023 at 18:45, Duncan Murdoch wrote:
>| The real problem is that there are two stubborn groups opposing each 
>| other:  the data.table developers and the CRAN maintainers.  The former 
>| think users should by default dedicate their whole machine to 
>| data.table.  The latter think users should opt in to do that.
>
>No, it feels more like it is CRAN versus the rest of the world.
>
>Take but one example, and as I may have mentioned elsewhere, my day job
>consists in providing software so that (to take one recent example)
>bioinformatics specialist can slice huge amounts of genomics data.  When that
>happens on a dedicated (expensive) hardware with dozens of cores, it would be
>wasteful to have an unconditional default of two threads. It would be the end
>of R among serious people, no more, no less. Can you imagine how the internet
>headlines would go: "R defaults to two threads". 
>
>And it is not just data.table as even in the long thread over in its repo we
>have people chiming in using OpenMP in their code (as data.table does but
>which needs a different setter than the data.table thread count).
>
>It is the CRAN servers which (rightly !!) want to impose constraints for when
>packages are tested.  Nobody objects to that.
>
>But some of us wonder if settings these defaults for all R user, all the
>time, unconditional is really the right thing to do.  Anyway, Uwe told me he
>will take it to an internal discussion, so let's hope sanity prevails.
>
>Dirk

-- 
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] Re-building vignettes had CPU time 9.2 times elapsed time

[Jeff Newmiller]

You have a really bizarre way of twisting what others are saying, Dirk. I have 
seen no-one here saying 'limit R to 2 threads' except for you, as a way to 
paint opposing views to be absurd.

What _is_ being said is that users need to be in control_, but _the default 
needs to do least harm_ until those users take responsibility for that control. 
Do not turn the throttle up until the user is prepared for the consequences. 
Trying to subvert that responsibility into packages by default is going to make 
more trouble than giving the people using those packages simple examples of how 
to take that control.

A similar problem happens when users discover .Rprofile and insert all those 
pesky library statements into it, making their scripts irreproducible. If 
data.table made a warp10() function that activated this current default 
performance setting then the user would be clearly at fault for using it in an 
inappropriate environment like a shared HPC or the CRAN servers. Don't put a 
brick on the accelerator of a teenager's car before they even figure out where 
the brakes are.

On August 25, 2023 6:17:04 PM PDT, Dirk Eddelbuettel  wrote:
>
>On 26 August 2023 at 12:05, Simon Urbanek wrote:
>| In reality it's more people running R on their laptops vs the rest of the 
>world.
>
>My point was that we also have 'single user on really Yuge workstation'. 
>
>Plus we all know that those users are often not sysadmins, and do not have
>our levels of accumulated systems knowledge.
>
>So we should give _more_ power by default, not less.
>
>| [...] they will always be saying blatantly false things like "R is not for 
>large data"
>
>By limiting R (and/or packages) to two threads we will only get more of
>these.  Our collective call.
>
>This whole thread is pretty sad, actually.
>
>Dirk
>

-- 
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] R Package Development -- PDF Manual without Index

[Jeff Newmiller]

CRAN doesn't care about whether devtools is happy. R CMD check --as-cran needs 
to work, e.g. as in [1].

Devtools is a convenience tool to help put all of the necessary bits in the 
right places in your source code according to [2]. But if there is any 
disagreement about what works, devtools is never the definitive answer.

If you put your current package source code online, as in on GitHub and share 
that here, then someone may be able to help you bridge the gap to satisfy both 
devtools and CRAN.

[1] https://kbroman.org/pkg_primer/pages/check.html
[2] https://cran.r-project.org/doc/manuals/R-exts.html

On September 2, 2023 11:50:57 AM PDT, John Carter Hall  
wrote:
>Hello R-Package-Devel Mailing List,
>
>I am new to R package development, and am having to limp a project across the 
>line after my organization has gone through significant changes in recent 
>weeks.
>As such, I am emailing to understand what I can do to solve an error I am 
>having:
>
>The Error
>
>Flavor: r-devel-linux-x86_64-debian-gcc
>Check: PDF version of manual without index, Result: ERROR
>
>The Issue
>
>For whatever reason, the R CMD check​ desires different fields in the 
>DESCRIPTION file than does the devtools::check() function (particularly w.r.t. 
>the 'Author' field), and so I have to use devtools to build/check the package. 
>The devtools::build_manual function, however, does not work, and so I am 
>forced to utilize Rd2pdf to create my PDF manual.
>
>I have to make the manual via Windows due to issues with an Ubuntu 
>installation of my package. However, the package is intended for Linux/Debian 
>audiences.
>
>What I Need Help With
>
>I believe I have the manual created. I do not know if this manual needs to be 
>created when CRAN does their checks, but I have the document (I am comparing 
>its appearance to the manual of ggplot2​, and the structure is similar). I do 
>not know where it needs to be located. I have tried the root directory of the 
>package, the doc​ folder, etc... but nothing works.
>
>What can I do?
>
>Best,
>Carter
>
>
>   [[alternative HTML version deleted]]
>
>__
>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] Fw: [CRAN-pretest-archived] CRAN Submission moodlequizR 1.0.1

[Jeff Newmiller]

I don't know how you can negotiate with CRAN regarding attach, but one approach 
is to return the data frame and instruct your students to write

  moodledata <- paste.data()

instead of

  paste.data()

since either is just as obscure as the other in the mind of a beginner and the 
former promotes better understanding of R and good practice.

On September 6, 2023 11:01:45 AM PDT, Wolfgang Rolke via R-package-devel 
 wrote:
>Hi,
>
>I am trying to upload a package to CRAN but keep getting the error message 
>below. The issue seems to be the use of attach in one of my routines. As I 
>explain in the cran-comments.md this use of assign is intentional.
>
>The routine paste.data is used by undergraduate student with very little R 
>knowledge to transfer data from moodle quizzes into R. They can simply copy
>  the data in moodle, switch to R and run paste.data(). The data is assigned 
> to the global   environment under the name moodledata and can be used to find 
> the solution to the moodle quiz. I have been using this routine with my 
> students for several years without any problems.
>
>What do I need to do to get passed this automatic check?
>
>Thanks,
>Wolfgang
>
>
>From: lig...@statistik.tu-dortmund.de 
>Sent: Wednesday, September 6, 2023 1:10 PM
>To: Wolfgang Rolke 
>Cc: cran-submissi...@r-project.org 
>Subject: [CRAN-pretest-archived] CRAN Submission moodlequizR 1.0.1
>
>Dear maintainer,
>
>package moodlequizR_1.0.1.tar.gz does not pass the incoming checks 
>automatically, please see the following pre-tests:
>Windows: 
>>
>Status: 2 NOTEs
>Debian: 
>>
>Status: 2 NOTEs
>
>
>
>Please fix all problems and resubmit a fixed version via the webform.
>If you are not sure how to fix the problems shown, please ask for help on the 
>R-package-devel mailing list:
>>
>If you are fairly certain the rejection is a false positive, please reply-all 
>to this message and explain.
>
>More details are given in the directory:
>>
>The files will be removed after roughly 7 days.
>
>No strong reverse dependencies to be checked.
>
>Best regards,
>CRAN teams' auto-check service

-- 
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] NOTE for a suggested package

[Jeff Newmiller]

Remove the library function call...

On February 23, 2019 3:43:15 PM PST, Mohammad Ali Nilforooshan 
 wrote:
>I'm struggling to stop receiving a NOTE about a suggested package, and
>it
>seems to be the problem for many people. Your help is really
>appreciated.
>
>In the function, I have:
>
>if(requireNamespace("doParallel", quietly=TRUE))
>{
>   library("doParallel")
>   cl = parallel::makeCluster(ncl)
>   doParallel::registerDoParallel(cl)
>   Q = foreach(i=ggID, .combine='cbind') %dopar% ## do something
>} else {
>   ## do something else
>}
>
>In DESCRIPTION, I have:
>
>Suggests:
>   doParallel (>= 1.0.14)
>
>This is the NOTE that I receive:
>
>'library' or 'require' call to 'doParallel' in package code.
>Please use :: or requireNamespace() instead.
>See section 'Suggested packages' in the 'Writing R Extensions' manual.
>
>   [[alternative HTML version deleted]]
>
>__
>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] problems with .mod files

[Jeff Newmiller]

Don't run R CMD check against your working directory... only run it against 
your tar.gz source file. The devtools package will do this for you 
automatically from within R for convenience.

On February 28, 2019 4:50:18 AM PST, "Rampal S. Etienne" 
 wrote:
>Dear Remi,
>
>The mod files are not in the src folder or in the tarball I submit to
>CRAN, but I still get warnings that there are created. I have tried to
>clean them by specifying this in the makefile, but then I get other
>issues.
>
>Rampal
>
>
>On 28-2-2019 0:02, Rémi Piatek wrote:
>> These *.mod files are automatically created during compilation
>whenever 
>> there is a module in the corresponding source file. They should not
>be 
>> in the src folder of your package when you submit it to CRAN, but
>they 
>> should not be a problem when they get created in this folder during 
>> compilation.
>>
>> Try to add the following line in .Rbuildignore (if this file does not
>
>> exist, create it in the main directory of your package):
>>
>> ^.*\.mod
>>
>> This will prevent R from including any *.mod files when building your
>
>> package.
>>
>> I hope this is helpful.
>>
>> Best,
>>
>> Remi
>>
>>
>> On 2/26/19 10:00 PM, r-package-devel-requ...@r-project.org wrote:
>>> Date: Mon, 25 Feb 2019 17:13:51 +0100
>>> From: "Rampal S. Etienne"
>>> To:R-package-devel@r-project.org
>>> Subject: [R-pkg-devel] problems with .mod files
>>> Message-ID:
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Hello,
>>>
>>> I have been trying for weeks to get a package on CRAN, but keep
>>> receiving warnings and notes, and errors using R-hub. The problems
>>> started when I used FORTRAN code to speed up some functions. This
>>> FORTRAN code introduces .mod files which are not accepted in the src
>>> folder. I followed suggestions by Avraham Adler to clean the src
>folder
>>> from this file by introducing a makefile with a clean command in it,
>but
>>> then I get other errors, and above all, recently this solution did
>not
>>> seem to remove the .mod file on some systems, as I still got the
>warning
>>> that this file was found in the src folder (but not on my machine!).
>>>
>>> So my question is: how do I prevent the creation of .mod files
>during
>>> compilation of the FORTRAN code, or how do I tell R that these files
>are
>>> OK in the src folder?
>>>
>>> Regards,
>>>
>>> Rampal Etienne
>>>
>>>
>>
>>  [[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

-- 
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] regarding solution of these warning and note

[Jeff Newmiller]

Do you have a question? If so, please read the Posting Guide and follow its 
recommendations. (e.g. What did you do to trigger these errors in enough detail 
that we could trigger them? What is your desired outcome?)

On March 3, 2019 1:11:45 PM PST, Krishan Gupta  wrote:
>Original: no visible binding for global variable
>  ‘filter_normalized_data’
>Seurat: no visible binding for global variable ‘filter_normalized_data’
>genes_filter: no visible binding for global variable
>  ‘filter_normalized_data’
>Undefined global functions or variables:
>  filter_normalized_data
>
>
>checking installed package size ... NOTE
>  installed size is  6.4Mb
>  sub-directories of 1Mb or more:
>data   5.5Mb
>
>*Thanks and Regards*
>
>
>*Krishan GuptaPhD Scholar*
>
>   [[alternative HTML version deleted]]
>
>__
>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] Calls not declared

[Jeff Newmiller]

I did not see any mention of the distinction between Depends and Imports in the 
DESCRIPTION file... which is always a risk when duplicating existing 
documentation in an email. Imports is preferred because the user does not have 
to put definitions only needed inside your package into their public search 
path (easier to make under-the-hood changes to the package implementation), but 
Depends is better when they cannot make use of your package without those 
definitions (e.g. you return a ggplot object from one of your functions).

So do keep reading the documentation... email is just a kickstart.

On March 11, 2019 8:19:33 AM PDT, Duncan Murdoch  
wrote:
>On 11/03/2019 9:53 a.m., Elias Carvalho wrote:
>> I am developing my first package and found these errors when checking
>it.
>> 
>> Any help?
>> 
>> 
>> * checking dependencies in R code ... WARNING
>> 'library' or 'require' calls not declared from:
>>‘qgraph’ ‘semPlot’ ‘sna’ ‘xlsx’
>
>Without seeing your package I might be wrong, but I believe this says 
>that you have something like
>
>library(qgraph)
>
>somewhere in your R code, without listing
>
>Depends: qgraph
>
>in your DESCRIPTION file.
>
>HOWEVER, fixing this warning will lead to a different one, because 
>that's not the recommended way to do things now.  There are two 
>possibilities:
>
>1.  Your package is useless without the dependency.
>
>In this case, you should put
>
>Imports:  qgraph, ...
>
>in the DESCRIPTION file (where ... lists the other packages with the 
>same status), and list the functions in those packages in your
>NAMESPACE 
>file, using
>
>importFrom(qgraph, ...)
>
>etc.  (If you use Roxygen, you use comments in the source to get it to 
>put this into your NAMESPACE file.)
>
>2.  Your package works without the dependency, but you may want to
>issue 
>errors or warnings if it is missing.
>
>Then you should put
>
>Suggests:  qgraph, ...
>
>in the DESCRIPTION file, and to use a function from it, use something
>like
>
>if (requireNamespace("qgraph")) {
>   qgraph::foo(...)
>} else
>   warning("qgraph is not available.")
>
>Duncan Murdoch
>
>__
>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] Calls not declared

[Jeff Newmiller]

Ah, so as long as you don't need to call a normal function to make use of the 
returned object you don't need Depends. But in this example, the user would 
then need to call library(ggplot2) in order to, say, change an axis title.

A bit more subtle than I thought.

On March 11, 2019 10:07:12 AM PDT, Duncan Murdoch  
wrote:
>On 11/03/2019 11:32 a.m., Jeff Newmiller wrote:
>> I did not see any mention of the distinction between Depends and
>Imports in the DESCRIPTION file... which is always a risk when
>duplicating existing documentation in an email. Imports is preferred
>because the user does not have to put definitions only needed inside
>your package into their public search path (easier to make
>under-the-hood changes to the package implementation), but Depends is
>better when they cannot make use of your package without those
>definitions (e.g. you return a ggplot object from one of your
>functions).
>> 
>
>You don't need Depends to be able to handle ggplot2 objects. You'll get
>
>the methods when the package is loaded, so they'll print fine without 
>having ggplot2 on the search list.
>
>There are very few cases nowadays where it makes sense to use Depends.
>
>Duncan Murdoch
>
>> So do keep reading the documentation... email is just a kickstart.
>> 
>> On March 11, 2019 8:19:33 AM PDT, Duncan Murdoch
> wrote:
>>> On 11/03/2019 9:53 a.m., Elias Carvalho wrote:
>>>> I am developing my first package and found these errors when
>checking
>>> it.
>>>>
>>>> Any help?
>>>>
>>>>
>>>> * checking dependencies in R code ... WARNING
>>>> 'library' or 'require' calls not declared from:
>>>> ‘qgraph’ ‘semPlot’ ‘sna’ ‘xlsx’
>>>
>>> Without seeing your package I might be wrong, but I believe this
>says
>>> that you have something like
>>>
>>> library(qgraph)
>>>
>>> somewhere in your R code, without listing
>>>
>>> Depends: qgraph
>>>
>>> in your DESCRIPTION file.
>>>
>>> HOWEVER, fixing this warning will lead to a different one, because
>>> that's not the recommended way to do things now.  There are two
>>> possibilities:
>>>
>>> 1.  Your package is useless without the dependency.
>>>
>>> In this case, you should put
>>>
>>> Imports:  qgraph, ...
>>>
>>> in the DESCRIPTION file (where ... lists the other packages with the
>>> same status), and list the functions in those packages in your
>>> NAMESPACE
>>> file, using
>>>
>>> importFrom(qgraph, ...)
>>>
>>> etc.  (If you use Roxygen, you use comments in the source to get it
>to
>>> put this into your NAMESPACE file.)
>>>
>>> 2.  Your package works without the dependency, but you may want to
>>> issue
>>> errors or warnings if it is missing.
>>>
>>> Then you should put
>>>
>>> Suggests:  qgraph, ...
>>>
>>> in the DESCRIPTION file, and to use a function from it, use
>something
>>> like
>>>
>>> if (requireNamespace("qgraph")) {
>>>qgraph::foo(...)
>>> } else
>>>warning("qgraph is not available.")
>>>
>>> Duncan Murdoch
>>>
>>> __
>>> 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] Re :Re: Re :Re: Re :Re: package cartograflow_0.0.0.9000.tar.gz

[Jeff Newmiller]

don't you think other.ot...@gmail.com is inappropriate?

On April 7, 2019 12:01:59 PM PDT, "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")))
>* 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 Rd files ... OK
>* checking Rd metadata ... OK
>* checking Rd line widths ... OK
>* checking Rd cross-references ... OK
>* checking for missing documentation entries ... OK
>* checking for code/documentation mismatches ... OK
>* checking Rd \usage sections ... OK
>* checking Rd contents ... OK
>* checking for unstated dependencies in examples ... OK
>* checking installed files from ‘inst/doc’ ... OK
>* checking files in ‘vignettes’ ... OK
>* checking examples ... OK
>* checking for unstated dependencies in ‘tests’ ... OK
>* checking tests ... OK
>  Running ‘testthat.R’
>* checking for unstated dependencies in vignettes ... OK
>* checking package vignettes in ‘inst/doc’ ... OK
>* checking re-building of vignette outputs ... OK
>* checking PDF version of manual ... OK
>* DONE
>Status: 1 NOTE
>
>
>Le dimanche 7 avril 2019 à 18:22:32 UTC+2, Duncan Murdoch
> a écrit :  
> 
> On 07/04/2019 12:16 p.m., cartograf...@gmail.com wrote:
>> Hi,Thanks to your reply and your information. Right now it stays only
>one note when I've made R-devel CMD CHECK --as-cran. So, I didn't
>identified this note in repertory R.check. What's file I've to
>check?I'd like to know if I can new submission in CRAN with one
>note. Sylvain
>
>It will be in cartograflow.Rcheck/00check.log.
>
>Duncan Murdoch
>
>> 
>> 
>> 
>> Envoyé depuis Yahoo Mail pour Android
>>  
>>    Le jeu., avr. 4, 2019 à 17:09, Maëlle
>SALMON a écrit :    I'd recommend reading
>https://r-pkgs.org/description.html#dependencies (and the rest of the
>book is very good as well), it'll help you understand why and how to
>declare dependencies.
>> 
>> 
>> 
>> 
>>      Den torsdag 4 april 2019 17:05:02 CEST, cartograf...@gmail.com
> skrev:
>>  
>>  How I can declare the dependencies in DESCRIPTION file?
>>   depends: library(dplyr,dependencies =TRUE)
>> Thanks
>> Envoyé depuis Yahoo Mail pour Android
>>  
>>    Le jeu., avr. 4, 2019 à 14:42, Uwe
>Ligges a écrit :   or forgot to
>declare a dependency on that package in the
>> DESCRIPTION file...
>> 
>> Best,
>> Uwe Ligges
>> 
>> On 04.04.2019 13:34, Sebastian Meyer wrote:
>>> There are probably no clairvoyants around here. So, again, without
>>> access to the up-to-date source code of your package, nobody will be
>>> able to help.
>>>
>>> "there is no pac

Re: [R-pkg-devel] read-only mirror of the CRAN R package repository on GitHub

[Jeff Newmiller]

I don't think "CRAN" (R Core)  _ever_ did this... it was a volunteer effort by 
someone independently.

On April 11, 2019 4:16:47 PM PDT, Mohammad Ali Nilforooshan 
 wrote:
>Hi,
>
>In the past, there were read-only mirrors of the CRAN R packages on
>GitHub
>(i.e., https://github.com/cran/).
>I cannot find this for my R package (ggroups), which became available
>on
>CRAN a few weeks ago. Does CRAN still provide package repositories on
>GitHub? If yes, please elaborate how the review and permissions are
>handled.
>
>Thank you
>M. A. Nilforooshan
>
>   [[alternative HTML version deleted]]
>
>__
>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] long file names in tar

[Jeff Newmiller]

You could go down this rabbit hole if you like, but I suspect it has something 
to do with maintaining compatibility with multiple operating systems and I 
doubt R Core will explore the consequences of this change for you. Windows, for 
example, allows long file names but has some nasty corners that break if your  
total path+filename is 260+ characters and packages do get installed in 
directories fairly deep into the directory structure on a regular basis (e.g. 
packrat). Other tools that the R ecosystem depends on could also have internal 
constraints that come up when one tool builds on another and so on.

Have fun with that!

On April 18, 2019 11:02:15 AM PDT, Steven Scott  
wrote:
>Thanks Dirk,
>Yes, I've done the same, and I agree the rules are the rules.  Rules
>should
>be updated when they're no longer helpful, or when their cost outweighs
>their benefit.  I'm curious whether that might be the case here.
>Cheers,
>Steve
>
>
>On Thu, Apr 18, 2019 at 10:54 AM Dirk Eddelbuettel 
>wrote:
>
>>
>> On 18 April 2019 at 10:37, Steven Scott wrote:
>> | My Boom package makes a C++ library available to package authors
>(mainly
>> | me).  The wrapped library is used outside of R and must comply with
>> | external style rules such as UseLongDescriptiveNames, and files
>must be
>> | named for the class they contain.  From time to time a
>> | LongDescriptiveFileName, when paired with its full directory path,
>> exceeds
>> | 100 characters.
>> |
>> | This creates a conflict with CRAN's rules about long file names,
>which
>> | stems from tar.  I'm wondering what this community thinks about
>asking
>> for
>> | that rule to be relaxed.  Both gnu tar and posix tar now allow
>unlimited
>> | length filenames, and the ustar format allows names up to 256
>characters.
>> |
>> | I'm interested in the opinions of people on this list about whether
>this
>> | rule has outlived its usefulness.  Thanks.
>>
>> There are no "opinions". There is CRAN Repo Policy.
>>
>> The BH package your Boom depends upon is actually named BH in part
>because
>> having a two-letter name shrunk the set of files violating this very
>> constraint.  Yet at every release I still get to renamed one file,
>and
>> update
>> one include statement.  All documented in the ChangeLog.
>>
>> So I would change the filenames, and move on.
>>
>> 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

-- 
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] 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] Writing to files without altering working directory in R package

[Jeff Newmiller]

I find the idea of using setwd in examples disturbing, because I try to avoid 
using setwd at all as a way to delegate my choice of working directory to the 
operating system actions taken when starting R. In other words, I recommend to  
beginners that they start R in their working directory and leave it there all 
the time, using relative paths as much as possible. Since examples are likely 
to be run in the middle of an analysis in order to develop the next step in the 
analysis, leaving my wd elsewhere would be counterproductive. Having a leftover 
variable that tells me where the data were written is simpler than using setwd 
to and from the temp directory. More hand holding than that belongs in a 
tutorial or vignette.

Note that if you wrap the example up in a vignette then changing to the temp 
directory seems fair to me (if CRAN allows it) because the context is more like 
 a complete, self-contained analysis.

On May 7, 2019 11:32:49 AM PDT, Henrik Bengtsson  
wrote:
>I agree that setwd(), tempdir(), etc. clutter up examples.  At the
>same time, I respect the CRAN policy - it's conservative approach has
>helped us avoid a wild-west working environment. One approach that
>might help bring some standardization, instead of each package
>developer rolls their own, and avoid having to have that tempdir code
>in there is to have example() handle this.  For example, add a
>workdir=tempdir() argument to example() and have example() change to
>that directory temporarily, and report on the working directory at the
>end.
>
>> example(foo)
>...
>Any output files produced by this example may be found in the
>temporary working directory '/tmp/alice/Rtmp4faDCv'.
>
>This could be a message or a warning.  One could also imagine using
>workdir=getOption("example.workdir", tempdir()) as the default.  If
>properly done, this would allow the user to set
>options(example.workdir = quote(getwd())) if they'd like to write to
>the current directory.
>
>What it does not solve is when a user cut'n'paste code, but maybe that
>could be considered acceptable because in that case the user is not
>running/source code, but calling it themself.
>
>My $.02
>
>/Henrik
>
>
>
>
>These messages can be skipped if called with example(...,
>workdir=getwd()).
>
>On Tue, May 7, 2019 at 10:57 AM Duncan Murdoch
> wrote:
>>
>> On 06/05/2019 12:16 p.m., 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()`.
>>
>> I think beginners rarely like the help pages, and that's really to be
>> expected:  help pages need to be complete and correct, and beginners
>> really need a small subset of possibilities.  Beginners need
>tutorials.
>>
>> In the Github issue, you mentioned pollution of the working
>directory,
>> but I think a bigger problem is destruction of user data, e.g. if a
>user
>> has a file "wine.csv", and the example writes to that file.
>>
>> So you need to do something to protect users.  I think making
>examples a
>> little complicated by using setwd(tempdir()) with a literal filename,
>or
>> writing to tempfile() is worth it.
>>
>> Duncan Murdoch
>>
>> >
>> > 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" a

Re: [R-pkg-devel] noL

[Jeff Newmiller]

It pays to read the archives before posting 
https://stat.ethz.ch/pipermail/r-package-devel/2019q2/003941.html

On May 16, 2019 6:31:19 AM PDT, "Goldfeld, Keith" 
 wrote:
>Good morning -
>
>I have one final issue that is preventing me from a successful
>submission of my package simstudy to CRAN. In one of my examples, I sum
>a vector of probabilities and check to make sure they sum to one.
>
>I am getting an "noLD" error - so there is some issue with a long
>double. I
>am a at a bit of a loss on how to go about fixing this (would rounding
>help),
>but more importantly, how can I check this to make sure I have fixed it
>-
>since I do not get an error on my local system (and it passes all other
>checks.)
>
>I've included the log from the noLD
>(https://www.stats.ox.ac.uk/pub/bdr/noLD/simstudy.out) below.
>
>- Keith
>
>
>* checking examples ... ERROR
>Running examples in �simstudy-Ex.R� failed
>The error most likely occurred in:
>
>> ### Name: genCorOrdCat
>> ### Title: Generate correlated ordinal categorical data
>> ### Aliases: genCorOrdCat
>>
>> ### ** Examples
>>
>>  Set definitions
>>
>> baseprobs <- matrix(c(0.2, 0.1, 0.1, 0.6,
>+   0.7, 0.2, 0.1, 0,
>+   0.5, 0.2, 0.3, 0,
>+   0.4, 0.2, 0.4, 0,
>+   0.6, 0.2, 0.2, 0),
>+ nrow = 5, byrow = TRUE)
>>
>> set.seed(333)
>> dT <- genData(1000)
>>
>> dX <- genCorOrdCat(dT, adjVar = NULL, baseprobs = baseprobs,
>+prefix = "q", rho = .125, corstr = "cs")
>Error in genCorOrdCat(dT, adjVar = NULL, baseprobs = baseprobs, prefix
>= "q",  :
>  Probabilities are not properly specified
>Execution halted
>* checking for unstated dependencies in vignettes ... OK
>* checking package vignettes in �inst/doc� ... OK
>* checking re-building of vignette outputs ... OK
>* checking PDF version of manual ... OK
>* DONE
>
>Status: 1 ERROR
>See
>�/data/gannet/ripley/R/packages/tests-noLD/simstudy.Rcheck/00check.log�
>for details.
>
>
>
>This email message, including any attachments, is for\ ...{{dropped:6}}

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

Re: [R-pkg-devel] note

[Jeff Newmiller]

Regarding the global variables... I found [1] illuminating, in particular the 
comments on the solution.

[1] 
https://stackoverflow.com/questions/41954302/where-to-create-package-environment-variables

On June 4, 2019 11:07:20 AM PDT, Duncan Murdoch  
wrote:
>On 04/06/2019 8:36 a.m., Bernd  JAGLA wrote:
>> Hi,
>> 
>> 
>> I am trying to submit a package with a shiny app to cran.
>> 
>> I get 2 notes that I don't know how to resolve. I would appreciate
>very much any suggestions/help.
>> 
>> 
>> Thanks a lot.
>> 
>> 
>> It seems the first note is on possibly misspelled words. I am using
>camel-case to "explain" the name of the app, the app's name itself is
>mostly capitalized, and the others are either names of objects or the
>title (Transcriptomics), which I believe should be capitalized... So, I
>don't really know how to overcome this.
>
>Explain in your submission note why you spelled things the way you did.
>
>Generally non-English words should be in single quotes; see 
>https://cloud.r-project.org/web/packages/submission_checklist.html. 
>But 
>"sHiny" looks wrong in any case if it is not quoted.
>> 
>> 
>> With respect to the TRONCO license, I believe the reason for the
>message is that they included a custom file, but they are also using
>GPL3 (which I am required to use by my company) I don't see a
>solution...
>
>TRONCO is a Bioconductor package, and isn't declaring its GPL-3 license
>
>in the format that CRAN wants.  Explain this in your submission note.
>> 
>> 
>> Then, there are some global variables and things that are only
>defined under the inst directory. I came about the solution of putting
>the main part of my app /inst by finding similar solutions on google. I
>ran into a whole bunch of problems with putting everything under /R and
>I can create a package etc on GitHub and locally and install them
>through GitHub or locally. The only caveat is that I had to define
>these variables to pass the arguments as there are different
>environments involved... I think I chose the variable names in a way
>that shouldn't interfere with anything...
>
>Don't create global variables. The global environment is off limits to 
>you. You can have an environment in your package that contains those 
>variables.  This one you'll have to change, not just explain like the 
>others.
>
>Duncan Murdoch
>> 
>> 
>> As you can imagine by now, this is the first package I am submitting
>and it is quite a daunting task, so I am very sorry to haven't
>understood by now all the documentation and I am still hoping that the
>approach I took is viable. 😉
>> 
>> 
>> Thanks for taking the time to look into this.
>> 
>> 
>> Here is the log:
>> 
>> * using log directory
>'d:/RCompile/CRANincoming/R-devel/SCHNAPPs.Rcheck'
>> * using R Under development (unstable) (2019-06-03 r76654)
>> * using platform: x86_64-w64-mingw32 (64-bit)
>> * using session charset: ISO8859-1
>> * checking for file 'SCHNAPPs/DESCRIPTION' ... OK
>> * checking extension type ... Package
>> * this is package 'SCHNAPPs' version '0.1.2'
>> * package encoding: UTF-8
>> * checking CRAN incoming feasibility ... NOTE
>> Maintainer: 'Bernd Jagla '
>> 
>> New submission
>> 
>> Possibly mis-spelled words in DESCRIPTION:
>>APPlication (8:32)
>>SCHNAPPs (8:45)
>>SingleCellExperiment (11:5)
>>Transcriptomics (4:9)
>>sHiny (8:26)
>> 
>> Package has a FOSS license but eventually depends on the following
>> package which may restrict use:
>>TRONCO
>> 
>> Size of tarball: 14400839 bytes
>> * 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 hidden files and directories ... OK
>> * checking for portable file names ... OK
>> * checking whether package 'SCHNAPPs' 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
>> * loading checks for arch 'i386'
>> ** 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 loading without being on the library search path ... OK
>> ** checking use of S3 registration ... OK
>> * loading checks for arch 'x64'
>> ** checking whether the package can be loaded ... OK
>> ** checking whether the package can be loaded with stated

Re: [R-pkg-devel] try() in R CMD check --as-cran

[Jeff Newmiller]

>> any(is.infinite(fval)) || any(is.na(fval))
>
>a little typo here: it should be '|', not '||', right ?

Since `any` collapses the vectors to length 1 either will work, but I would 
prefer `||`.

On June 7, 2019 6:51:29 AM PDT, Serguei Sokol  wrote:
>On 07/06/2019 15:31, Sebastian Meyer wrote:
>> The failure stated in the R CMD check failure report is:
>> 
>>>   --- failure: length > 1 in coercion to logical ---
>> 
>> This comes from --as-cran performing useful extra checks via setting
>the
>> environment variable _R_CHECK_LENGTH_1_LOGIC2_, which means:
>> 
>>> check if either argument of the binary operators && and || has
>length greater than one.
>> 
>> (see
>https://cran.r-project.org/doc/manuals/r-release/R-ints.html#Tools)
>> 
>> The failure report also states the source of the failure:
>> 
>>>   --- call from context ---
>>> fchk(x, benbad, trace = 3, y)
>>>   --- call from argument ---
>>> is.infinite(fval) || is.na(fval)
>> 
>> The problem is that both is.infinite(fval) and is.na(fval) return
>> vectors of length 10 in your test case:
>> 
>>>   --- value of length: 10 type: logical ---
>>>   [1] FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE
>> 
>> The || operator works on length 1 Booleans. Since fval can be of
>length
>> greater than 1 at that point, the proper condition seems to be:
>> 
>> any(is.infinite(fval)) || any(is.na(fval))
>a little typo here: it should be '|', not '||', right ?
>
>Best,
>Serguei.
>
>> Am 07.06.19 um 14:53 schrieb J C Nash:
>>> Sorry reply not quicker. For some reason I'm not getting anything in
>the thread I started!
>>> I found the responses in the archives. Perhaps cc: nas...@uottawa.ca
>please.
>>>
>>> I have prepared a tiny (2.8K) package at
>>> http://web.ncf.ca/nashjc/jfiles/fchk_2019-6.5.tar.gz
>>>
>>> R CMD check --> OK
>>>
>>> R CMD check --as-cran --> 1 ERROR, 1 NOTE
>>>
>>> The error is in an example:
>>>
 benbad<-function(x, y){
 # y may be provided with different structures
 f<-(x-y)^2
 } # very simple, but ...

 y<-1:10
 x<-c(1)
 cat("test benbad() with y=1:10, x=c(1)\n")
 tryfc01 <- try(fc01<-fchk(x, benbad, trace=3, y))
 print(tryfc01)
 print(fc01)
>>>
>>> There's quite a lot of output, but it doesn't make much sense to me,
>as
>>> it refers to code that I didn't write.
>>>
>>> The function fchk is attempting to check if functions provided for
>>> optimization do not violate some conditions e.g., character rather
>than
>>> numeric etc.
>>>
>>> JN
>>>
>>>
>>> On 2019-06-07 8:44 a.m., J C Nash wrote:
 Uwe Ligges ||gge@ @end|ng |rom @t@t|@t|k@tu-dortmund@de
 Fri Jun 7 11:44:37 CEST 2019

  Previous message (by thread): [R-pkg-devel] try() in R CMD
>check --as-cran
  Next message (by thread): [R-pkg-devel] using package data in
>package code
  Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

 Right, what problem are you talking about? Can you tell us which
>check
 it is and what it actually complained about.
 There is no check that looks at the sizes of x and y in
>exypressions
 such as
 (x - y)^2.
 as far as I know.

 Best,
 Uwe

 On 07.06.2019 10:33, Berry Boessenkool wrote:
>
> Not entirely sure if this is what you're looking for:
>
>https://github.com/wch/r-source/blob/trunk/src/library/tools/R/check.R
> It does contain --as-cran a few times and there's the
>change-history:
>
>https://github.com/wch/r-source/commits/trunk/src/library/tools/R/check.R
>
> Regards,
> Berry
>
>
> 
> From: R-package-devel r-project.org> on behalf of J C Nash 
> Sent: Thursday, June 6, 2019 15:03
> To: List r-package-devel
> Subject: [R-pkg-devel] try() in R CMD check --as-cran
>
> After making a small fix to my optimx package, I ran my usual R
>CMD check --as-cran.
>
> To my surprise, I got two ERRORs unrelated to the change. The
>errors popped up in
> a routine designed to check the call to the user objective
>function. In particular,
> one check is that the size of vectors is the same in expressions
>like (x - y)^2.
> This works fine with R CMD check, but the --as-cran seems to have
>changed and it
> pops an error, even when the call is inside try(). The irony that
>the routine in
> question is intended to avoid problems like this is not lost on
>me.
>
> I'm working on a small reproducible example, but it's not small
>enough yet.
> In the meantime, I'm looking for the source codes of the scripts
>for "R CMD check" and
> "R CMD check --as-cran" so I can work out why there is this
>difference, which seems
> to be recent.
>
> Can someone send/post a link? I plan to figure this out and
>provide feedback,
> as I suspect it is going to affect others. However, it may be a
>few days or even
> weeks if past experience is a guide.
>
> JN
>
> _

Re: [R-pkg-devel] Link compiled C object to internal package file

[Jeff Newmiller]

What do you mean by

"call an external text file"

? Text files are data... do you want to open it and read it? Are you familiar 
with the system.file() function?


On June 19, 2019 5:45:51 AM CDT, mark padgham  wrote:
>Dear All,
>
>I'm developing a package which primarily relies on C code that itself
>has to call an external text file representing a dictionary or lookup
>table. The location of this file is defined in a C macro, the file
>itself packaged in "./inst/dict/" and so currently called
>as
>"#define mylocation './dict/'". I can load the package and
>all works well, yet the tests fail because the compiled object
>("./src/") can not find this file **in tests only**. My
>primary request would then be advice for where best to place such files
>that need to be called directly by compiled objects, and how to direct
>the compiled object to such files? Failing that, advice on why such
>attempts at linking compiled objects to external files might fail only
>during tests, yet work otherwise, would be appreciated.
>
>Other important info: Yes, the external dictionary file **must** be
>linked directly from the compiled object, not at run time. This means
>that no R-based solutions can be implemented, and so the problem can
>only be solved in this case through figuring out how to direct a
>compiled object to connect to an additional package-internal file.
>
>Thanks in advance,
>
>mark
>
>__
>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] access is denied

[Jeff Newmiller]

I have not had much luck doing package development on network drives. Try using 
a local drive.

On June 20, 2019 11:26:42 AM CDT, Tomas Kalibera  
wrote:
>If you have not already done so, I'd check the package directory (and 
>its parent) is not opened in any application, including Windows 
>Explorer, including current working directory in any command prompt.
>I'd 
>also make sure the package is not loaded in any R session. The error 
>message may be caused by that the file or directory is locked.
>
>Best
>Tomas
>
>On 6/20/19 5:49 PM, Dennis Boos wrote:
>> Developers,
>>
>> I recently was successful getting a package into CRAN with your help.
>> But now I'm working on a second package and am stuck immediately. 
>Here
>> is what I have done.
>>
>> 1. Created the base package using
>http://r-pkgs.had.co.nz/package.html
>> to get started.
>> 2. Then
>>
>>> library(devtools) > document() Updating fsr documentation First time
>> using roxygen2. Upgrading automatically... Error in
>> normalizePath(path.expand(path), winslash, mustWork) :
>>
>path[1]="\\wolftech.ad.ncsu.edu\cos\stat\Redirect\boos\Documents\srcis\fsr.package\fsr":
>> Access is denied In addition: Warning messages: 1: In
>> normalizePath(path.expand(path), winslash, mustWork) :
>>
>path[1]="\\wolftech.ad.ncsu.edu\cos\stat\Redirect\boos\Documents\srcis\fsr.package\fsr":
>> Access is denied 2: In normalizePath(path.expand(path), winslash,
>> mustWork) :
>>
>path[1]="\\wolftech.ad.ncsu.edu\cos\stat\Redirect\boos\Documents\srcis\fsr.package\fsr/DESCRIPTION":
>> Access is denied
>>
>>
>> What am I missing?  I didn't have this problem before.  I have
>> re-downloaded RStudio and Rtools, but get the same results.
>>
>> Dennis
>>
>
>__
>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] The correct way to put additional DLLs on windows?

[Jeff Newmiller]

A) You cannot assume the package code will have write access to the library 
directories. The user/admin who installs the package may never load the package.

B) Downloading binary files for execution without the direct involvement of the 
user/admin is a security risk.

C) Open-source package license means the source code is part of the package. 
Downloading binaries later fails this requirement.

On July 1, 2019 10:03:07 PM PDT, Jialin Ma  wrote:
>Hi everyone,
>
>Currently my package has a script downloading additional DLLs
>into "inst/libs" and being called in "Makevars.win". In this way these
>DLLs get copied to libs when installing the package and I am able to
>load them with "library.dynam".
>
>However R CMD check gives the following warning.
>
>  * checking package subdirectories ... WARNING
> Found the following non-empty subdirectories of 'inst' also used by R:
>inst/libs
> It is recommended not to interfere with package subdirectories used by
>  R.
>
>I was wondering what would be the best practice for my case, or I am
>safe
>to ignore this warning (suppose I am planing for a CRAN submission).
>
>I know many packages will download static library and link them at
>compile
>time. But I haven't see any example with additional DLL files.
>
>Thanks.
>Jialin Ma
>
>__
>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] CRAN-compatible location for output of example code?

[Jeff Newmiller]

https://stat.ethz.ch/R-manual/R-devel/library/base/html/tempfile.html

?tempdir

On July 4, 2019 3:25:25 PM PDT, Michael Gruenstaeudl 
 wrote:
>Assume an R package that generates a figure ('output.pdf') as the
>result 
>of executing the example code specified in one of the manual files
>(i.e. 
>an .Rd file). The example code specifies the figure to be saved to the 
>root directory of the package (i.e., where files DESCRIPTION and 
>NAMESPACE are located).
>
>\examples{
>...
>outFile <- paste(getwd(), "output.pdf", sep="")
>...
>}
>
>Upon submitting the package to CRAN, I receive the NOTE that the 
>following note:
>
>Flavor: r-devel-linux-x86_64-debian-gcc
>Check: for non-standard things in the check directory, Result: NOTE
>   Found the following files/directories:
> 'output.pdf'
>
>To which folder should I have the example code save the output file in 
>order for the code to be compatible with the CRAN submission
>guidelines?
>
>__
>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

[R-pkg-devel] Block quote in an Rd file?

[Jeff Newmiller]

Not seeing in "Writing R Extensions" a way to annotate a block quote in an Rd 
file. Any suggestions?
-- 
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] Block quote in an Rd file?

[Jeff Newmiller]

Ehh... not that much. Will make do with a couple of quote marks. Thanks for the 
confirmation.

On July 4, 2019 5:48:56 PM PDT, Duncan Murdoch  wrote:
>On 04/07/2019 7:43 p.m., Jeff Newmiller wrote:
>> Not seeing in "Writing R Extensions" a way to annotate a block quote
>in an Rd file. Any suggestions?
>
>I don't think there is a built-in one.  If you are determined to have 
>one, you could define your own user-defined macro to do it.  It'll be 
>ugly, because you need to output different text depending on whether
>the 
>help page is being displayed in plain text, HTML or LaTeX.  See
>sections 
>2.11 and 2.13 of Writing R Extensions for the docs.
>
>Duncan Murdoch

-- 
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] "Progress reports" for examples in packages --- SOLVED.

[Jeff Newmiller]

This is why I only put localization variables in .Rprofile and am always 
putting such options into my project-specific scripts.

This may sound like I am a masochist, but I hate sharing my scripts with 
someone else contaminated with compatibility bombs like that.

On July 6, 2019 8:19:27 PM PDT, Rolf Turner  wrote:
>
>
>Just thought it might be of interest were I to give a progress report
>( :-) ) on this problem.
>
>I managed to track down and fix what was going wrong.  It turns out
>that 
>the issue was "stringsAsFactors".  I *hate* stringsAsFactors being TRUE
>
>so I have a call to options() setting it to FALSE in my .Rprofile.
>
>But of course R CMD check sets it to TRUE.  In my code, I create at one
>
>point a one-row data frame.  I use a data frame so that the object is 
>consistent with appears in other contexts in the code.  I extracting
>the 
>entries of the data frame in question from other objects.  Some of
>these 
>entries are strings ... uh-oh!  When they get changed to factors and 
>then passed on to a function which passes them on to (e.g.) binomial() 
>they wind up taking values like, e.g., 1, where "logit" was what was 
>intended.
>
>I had the function that calls binomial() wrapped up in a try() with 
>silent=TRUE, since there are occasional circumstances in which there 
>would be a "legitimate" fail (and I wanted to create a missing value if
>there was such a fail).  However there was *always* a fail due to the
>stringsAsFactors contretemps, so the overall result was useless and the
>
>repeat{ } loop repeated.  Endlessly.  When R CMD check was run.
>(But everything was of course just ducky when I ran the example "as 
>myself".)
>
>The fix, once I found the problem, was simple; just stick in a
>stringsAsFactors=FALSE in the relevant call to data.frame().
>
>Finding the problem, obvious as it is in retrospect, was a nightmare. 
>It required many many many attempts with cat() statements inserted at 
>various places (in accordance with the advice given by Ben Bolker).  I 
>had the devil's own time figuring out what to cat()!
>
>I found, once I'd tracked down which example was the culprit (by doing
>tail -f pkge-Ex.Rout), that I could use \dontrun{} on all of the
>*other* 
>examples and get the same puzzling behaviour.  This speeded up the 
>process considerably.
>
>Don't know if there is any message to take away from all of the 
>foregoing (other than that Rolf Turner is pretty stupid) but I thought 
>that some list members might find the story to be of interest.
>
>cheers,
>
>Rolf Turner

-- 
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] Example fails in check

[Jeff Newmiller]

Pipes are very functional, unlike data.table. However, their extensive use of 
non-standard evaluation a la `subset` or `with` does complicate the package 
check process.

As to the actual question, Imports announces that the magrittr package is a 
private dependency for your package. Users would have to load that package  if 
they wanted to use it also. Since examples are run as if they were the user, 
they are subject to that same constraint. The advantage of having Imports 
rather than Depends is that you have more flexibility to change which 
dependencies you use to achieve your goals as a package without affecting the 
functions that the user has to be prepared to use our avoid, and the user is on 
their own as to which packages they use.

On July 26, 2019 12:13:17 AM PDT, Uwe Ligges  
wrote:
>I'd suggest not to use pipes in package code, as the parser does not 
>know about them and hence debugging, error messages  are more 
>obfuscated.
>
>Why not use he functional way of R?
>
>
>For the question: I guess you do not have a corresponding entry in the 
>NAMESPACE file?
>
>Best,
>Uwe
>
>
>
>On 26.07.2019 08:37, Sigbert Klinke wrote:
>> Hi,
>> 
>> im my package development I get the following error when checking an 
>> example:
>> 
>>  > m <- findMatch('test', x[[1]], FUN='leven(code)') %>%
>addWave(x[[2]])
>> 
>>    Error in findMatch("test", x[[1]], FUN = "leven(code)") %>% 
>> addWave(x[[2]]) :
>>      could not find function "%>%"
>>    Execution halted
>> 
>> In my DESCRIPTION file I wrote
>> 
>> Imports:
>>    rio,
>>    stringi,
>>    magrittr
>> 
>> So, I expected that magrittr is loaded when the example is executed.
>> 
>> If I add an "library(magrittr)" at the beginning of the example then
>the 
>> example is okay.
>> 
>> Any ideas what goes wrong?
>> 
>> Sigbert
>>
>
>__
>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] NAMESPACE issue and grDevices

[Jeff Newmiller]

I think yes. If a direct user of graphics opted not to call smoothScatter then 
they would have no need to even install KernSmooth. However, since generics 
automatically trigger loading of class-specific methods, one of which in your 
case includes that dependency, your package cannot avoid at least importing 
KernSmooth.

On August 24, 2019 7:36:44 AM PDT, Kevin Coombes  
wrote:
>Hi,
>
>I've been building a package and hit a NAMESPACE issue that took a
>while 
>to resolve.
>
>My package implements a (new) generic function, and the method for a 
>package in the class calls the "smoothScatter" function from the 
>"graphics" package. I could build and install the package successfully,
>
>and when I used the generic function, it worked just fine.
>
>However, when I ran "R CMD check --as-cran", it threw an error from
>both 
>the examples in man pages and a test script. Specifically, the error
>was 
>"package KernSmooth not available". I eventually worked around this 
>problem by changing the DESCRIPTION file to "IMPORT KernSmooth" (even 
>though I didn't have to actually import anything in "NAMESPACE").
>
>The underlying issue appears to be that
>     graphics::smoothScatter
>calls a non-exported function from "grDevices"
>  grDevices:::.smoothScatterCalcDensity
>which in turn calls an explicitly qualified function from "KernSmooth"
>     KernSmooth::bkde2D
>
>To complicate matters
>     graphics IMPORTs grDevices
>but
>     grDevices only SUGGESTs KernSmooth.
>
>Since my package already IMPORTed the graphics package and had
>     importFrom("graphics", "smoothScatter")
>in the NAMESPACE, I was surprised that I had to track back through the 
>code to find this dependency and had to make it explicitly known within
>
>the interface to my package.
>
>Is there something else my package should do? Or should "grDevices" 
>actually IMPORT "KernSmooth"?
>
>Best,
>   Kevin
>
>__
>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] URL of a frame (or a vignette)?

[Jeff Newmiller]

Wouldn't you just refer to [1] or one of the links mentioned there?

[1] https://cran.r-project.org/package=bssm

On September 1, 2019 7:22:43 AM PDT, Spencer Graves 
 wrote:
>Hello:
>
>
>   How can I get a URL for a frame?
>
>
>   Specifically, I want a URL that I can cite for the "bssm: 
>Bayesian Inference of Non-linear and
>Non-Gaussian State Space Models in R" vignette in the bssm package on 
>CRAN.  If the package is installed, it's available there as
>"bssm.pdf".  
>However, I want to include it in an RMarkdown vignette I'm writing, and
>
>I'd rather not force the reader to be on a computer with the package 
>installed -- and force myself to figure out a way to find it in that 
>case, if that can even be done.
>
>
>   Thanks,
>   Spencer Graves
>
>__
>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] URL of a frame (or a vignette)?

[Jeff Newmiller]

I am not going to claim definitive knowledge, but my understanding of CRAN is 
that only the package URL that I copied from the page itself will remain if the 
package is archived. Thus, unless the package vignette has a non-CRAN permanent 
URL (e.g. arXiv) it may be safer in the long run to link through the main 
package URL.

On September 1, 2019 8:13:22 AM PDT, Georgi Boshnakov 
 wrote:
>Correction: 
>
>https://cran.r-project.org/package=bssm/vignettes/bssm.pdf
>
>
>-Original Message-
>From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On
>Behalf Of Georgi Boshnakov
>Sent: 01 September 2019 15:57
>To: Spencer Graves; Jeff Newmiller; r-package-devel@r-project.org
>Subject: Re: [R-pkg-devel] URL of a frame (or a vignette)?
>
>It may be better to use the canonical url,
>https://cran.r-project.org/package=bssm, as in:
>
>https://cran.r-project.org/package=bssm/bssm.pdf
>
>By the way, the vignettes for an installed package can be found by
>
>vignette(package="bssm")
>
>or
>
>help(package="bssm", help_type = "html")
>
>The latter has the advantage that it present links in a browser even if
>by default the help is presented in text mode.
>
>
>Georgi Boshnakov
>
>
>
>-Original Message-
>From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On
>Behalf Of Spencer Graves
>Sent: 01 September 2019 15:42
>To: Jeff Newmiller; r-package-devel@r-project.org
>Subject: Re: [R-pkg-devel] URL of a frame (or a vignette)?
>
>Hi, Jeff:
>
>
>  That's what I needed.  I clicked on the vignette I wanted and got
>
>the following:
>
>
>https://cran.r-project.org/web/packages/bssm/vignettes/bssm.pdf
>
>
>   Thanks,
>   Spencer Graves
>
>
>On 2019-09-01 09:37, Jeff Newmiller wrote:
>> Wouldn't you just refer to [1] or one of the links mentioned there?
>>
>> [1] https://cran.r-project.org/package=bssm
>>
>> On September 1, 2019 7:22:43 AM PDT, Spencer Graves
> wrote:
>>> Hello:
>>>
>>>
>>>    How can I get a URL for a frame?
>>>
>>>
>>>    Specifically, I want a URL that I can cite for the "bssm:
>>> Bayesian Inference of Non-linear and
>>> Non-Gaussian State Space Models in R" vignette in the bssm package
>on
>>> CRAN.  If the package is installed, it's available there as
>>> "bssm.pdf".
>>> However, I want to include it in an RMarkdown vignette I'm writing,
>and
>>>
>>> I'd rather not force the reader to be on a computer with the package
>>> installed -- and force myself to figure out a way to find it in that
>>> case, if that can even be done.
>>>
>>>
>>>    Thanks,
>>>    Spencer Graves
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
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] URL of a frame (or a vignette)?

[Jeff Newmiller]

I don't know if [1] implies vignette persistence after archiving, but it might. 
I think it just has to fall back to a warning with an archive link to qualify. 
(Quite a slick trick if so because there can potentially be a parade of 
different package vignettes over time.)

[1] https://stat.ethz.ch/pipermail/r-package-devel/2016q3/001100.html


On September 1, 2019 8:49:52 AM PDT, Duncan Murdoch  
wrote:
>On 01/09/2019 11:33 a.m., Spencer Graves wrote:
>>     What's the difference between
>> 
>> 
>> https://cran.r-project.org/package=bssm/vignettes/bssm.pdf
>> 
>> 
>>     and
>> 
>> 
>> https://cran.r-project.org/web/packages/bssm/vignettes/bssm.pdf
>> 
>> 
>>     When I tried the former, it automatically changed to the
>latter.
>> Is the former considered to be more stable?
>
>CRAN puts this on every package page:
>
>"Please use the canonical form https://CRAN.R-project.org/package= 
>to link to this page."
>
>I think one of the checks will complain if it notices you give the link
>
>in a different form.  I forget which URLs it checks.
>
>Duncan Murdoch

-- 
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] meta-question

[Jeff Newmiller]

I don't think this list is only for questions about submitting to CRAN, but it 
is specific to writing packages for R. If your question could just as
easily apply to another language then you probably ought to ask elsewhere.

Perhaps https://softwareengineering.stackexchange.com/help/on-topic ?

On September 7, 2019 6:48:39 AM PDT, David Hugh-Jones 
 wrote:
>Hi all,
>
>A meta-question: I am developing a new package (
>https://github.com/hughjonesd/santoku) and I would like to ask some
>questions. But they are not about e.g. R CMD check or CRAN submission -
>instead they're more abstract questions of software design. Is this the
>right place to ask?
>
>Cheers,
>David
>
>   [[alternative HTML version deleted]]
>
>__
>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] What counts as an API change?

[Jeff Newmiller]

Both of your examples are incompatible.

foo <- function (a, b, c, d, e = NA )

(add with default value) would be compatible.

Your second example cannot be made compatible even with default values because 
the positional behaviour has changed.

On September 25, 2019 6:51:58 AM PDT, David Hugh-Jones 
 wrote:
>Hi all,
>
>Philosophical question. My package follows semantic versioning (
>https://semver.org). Incompatible API changes should trigger a major
>version upgrade. OK, but what counts as an incompatible change to an R
>API?
>Suppose my current function signature is
>
>foo <- function (a, b, c, d)
>
>and the new one is
>
>foo <- function (a, b, c, d, e)
>
>is that compatible? What if I add an argument, but not at the end:
>
>foo <- function (a, b, c, e, d)
>
>That would be incompatible if people have been calling the arguments by
>order rather than by name. But sometimes that is unlikely: I doubt if
>many
>people write
>
>lm(y ~ x, mydata, z==3, f, na.omit, "qr", FALSE, FALSE, TRUE, TRUE,
>FALSE)
>
>Should I be strict or relaxed about this?
>
>Cheers,
>David
>
>   [[alternative HTML version deleted]]
>
>__
>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] What counts as an API change?

[Jeff Newmiller]

"assume default values are provided."

Ah, no. Choosing to specify or not specify default values is a critical step. 
As is deciding where any ... argument will be placed (all specific arguments 
after that have to be named when called so positional compatibility cannot come 
back to bite you).

"I wonder if it always matters"

That would depend on the relationship you plan to maintain with users of your 
package. Still, sometimes breaking changes are necessary for a better future.

I think the definition of breaking is pretty clear if you are precise in your 
argument lists. (R CMD check is very helpful in pestering you to document your 
arguments, so you do have the opportunity to be precise in your API 
definition.) It is really bad to have silent changes in behavior, and precision 
in specification is crucial to avoid that if you distribute packages.

On September 25, 2019 7:27:25 AM PDT, David Hugh-Jones 
 wrote:
>Hi Jeff,
>
>You're right. Indeed, assume default values are provided. I should have
>been more precise.
>
>I understand that the positional behaviour has changed. But I wonder if
>it
>always matters. OTOH I appreciate the force of the idea that an API
>change
>is an API change, and should be defined precisely.
>
>Best,
>David
>
>
>On Wed, 25 Sep 2019 at 15:01, Jeff Newmiller 
>wrote:
>
>> Both of your examples are incompatible.
>>
>> foo <- function (a, b, c, d, e = NA )
>>
>> (add with default value) would be compatible.
>>
>> Your second example cannot be made compatible even with default
>values
>> because the positional behaviour has changed.
>>
>> On September 25, 2019 6:51:58 AM PDT, David Hugh-Jones <
>> davidhughjo...@gmail.com> wrote:
>> >Hi all,
>> >
>> >Philosophical question. My package follows semantic versioning (
>> >https://semver.org). Incompatible API changes should trigger a major
>> >version upgrade. OK, but what counts as an incompatible change to an
>R
>> >API?
>> >Suppose my current function signature is
>> >
>> >foo <- function (a, b, c, d)
>> >
>> >and the new one is
>> >
>> >foo <- function (a, b, c, d, e)
>> >
>> >is that compatible? What if I add an argument, but not at the end:
>> >
>> >foo <- function (a, b, c, e, d)
>> >
>> >That would be incompatible if people have been calling the arguments
>by
>> >order rather than by name. But sometimes that is unlikely: I doubt
>if
>> >many
>> >people write
>> >
>> >lm(y ~ x, mydata, z==3, f, na.omit, "qr", FALSE, FALSE, TRUE, TRUE,
>> >FALSE)
>> >
>> >Should I be strict or relaxed about this?
>> >
>> >Cheers,
>> >David
>> >
>> >   [[alternative HTML version deleted]]
>> >
>> >__
>> >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.
>>

-- 
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] What counts as an API change?

[Jeff Newmiller]

No "maybe" about it.

On September 25, 2019 2:28:27 PM PDT, David Hugh-Jones 
 wrote:
>Thanks Jeff. My function is currently:
>
>insert_column <- function (ht, ..., after = 0, copy_cell_props = TRUE)
>
>and I want to add a `fill` argument:
>
>insert_column <- function (ht, ..., after = 0, fill = NULL,
>copy_cell_props
>= TRUE)
>
>This is definitely the best place for the fill argument - I wouldn't
>like
>to put it after copy_cell_props.
>
>Actually, thinking about it, both after and copy_cell_props have to be
>named arguments, given the position of ... . So maybe this is my get
>out of
>jail free card. If I add "fill", existing function calls won't break,
>and I
>can call this "adding functionality in a backwards-compatible manner".
>
>David
>
>
>On Wed, 25 Sep 2019 at 17:26, Jeff Newmiller 
>wrote:
>
>> "assume default values are provided."
>>
>> Ah, no. Choosing to specify or not specify default values is a
>critical
>> step. As is deciding where any ... argument will be placed (all
>specific
>> arguments after that have to be named when called so positional
>> compatibility cannot come back to bite you).
>>
>> "I wonder if it always matters"
>>
>> That would depend on the relationship you plan to maintain with users
>of
>> your package. Still, sometimes breaking changes are necessary for a
>better
>> future.
>>
>> I think the definition of breaking is pretty clear if you are precise
>in
>> your argument lists. (R CMD check is very helpful in pestering you to
>> document your arguments, so you do have the opportunity to be precise
>in
>> your API definition.) It is really bad to have silent changes in
>behavior,
>> and precision in specification is crucial to avoid that if you
>distribute
>> packages.
>>
>> On September 25, 2019 7:27:25 AM PDT, David Hugh-Jones <
>> davidhughjo...@gmail.com> wrote:
>> >Hi Jeff,
>> >
>> >You're right. Indeed, assume default values are provided. I should
>have
>> >been more precise.
>> >
>> >I understand that the positional behaviour has changed. But I wonder
>if
>> >it
>> >always matters. OTOH I appreciate the force of the idea that an API
>> >change
>> >is an API change, and should be defined precisely.
>> >
>> >Best,
>> >David
>> >
>> >
>> >On Wed, 25 Sep 2019 at 15:01, Jeff Newmiller
>
>> >wrote:
>> >
>> >> Both of your examples are incompatible.
>> >>
>> >> foo <- function (a, b, c, d, e = NA )
>> >>
>> >> (add with default value) would be compatible.
>> >>
>> >> Your second example cannot be made compatible even with default
>> >values
>> >> because the positional behaviour has changed.
>> >>
>> >> On September 25, 2019 6:51:58 AM PDT, David Hugh-Jones <
>> >> davidhughjo...@gmail.com> wrote:
>> >> >Hi all,
>> >> >
>> >> >Philosophical question. My package follows semantic versioning (
>> >> >https://semver.org). Incompatible API changes should trigger a
>major
>> >> >version upgrade. OK, but what counts as an incompatible change to
>an
>> >R
>> >> >API?
>> >> >Suppose my current function signature is
>> >> >
>> >> >foo <- function (a, b, c, d)
>> >> >
>> >> >and the new one is
>> >> >
>> >> >foo <- function (a, b, c, d, e)
>> >> >
>> >> >is that compatible? What if I add an argument, but not at the
>end:
>> >> >
>> >> >foo <- function (a, b, c, e, d)
>> >> >
>> >> >That would be incompatible if people have been calling the
>arguments
>> >by
>> >> >order rather than by name. But sometimes that is unlikely: I
>doubt
>> >if
>> >> >many
>> >> >people write
>> >> >
>> >> >lm(y ~ x, mydata, z==3, f, na.omit, "qr", FALSE, FALSE, TRUE,
>TRUE,
>> >> >FALSE)
>> >> >
>> >> >Should I be strict or relaxed about this?
>> >> >
>> >> >Cheers,
>> >> >David
>> >> >
>> >> >   [[alternative HTML version deleted]]
>> >> >
>> >> >__
>> >> >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.
>> >>
>>
>> --
>> Sent from my phone. Please excuse my brevity.
>>

-- 
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] Fwd: Passing CRAN check when an examples must save a file

[Jeff Newmiller]

Read the Posting Guide... sending html formatted email corrupts your message.

Reading between the garbage...

a) Pasting an extension is not necessary.
b) using tempfile() in your example as an argument to sink( file=) is a 
straightforward way to illustrate that a file can be created.

On September 27, 2019 5:16:30 PM PDT, Tiago Olivoto  
wrote:
>Dear all,
>I had the same problem when I submitted my R package 'metan' to CRAN
>for
>the first time.
>
>"Please ensure that your functions do not write by default or in your
>examples/vignettes/tests in the user's home filespace (including the
>package directory and getwd()). In your examples/vignettes/tests you
>can
>write to tempdir()"
>
>I have several 'summary()' functions like:
>
>
>
>
>
>
>
>
>*summary.waasb <- function(object, export = FALSE, file.name
> = "summary_waasb", ...) {  # do all I need here  if
>(export == TRUE) {sink(paste0(file.name ,
>".txt"))
># do all I need heresink()  }}*
>
>All 'export' arguments are set to 'FALSE'. So, no file is generated in
>the
>user's working directory.
>Is the above function not according to the CRAN policies?
>
>In two vignettes I have a code like:
>
>
>
>*```{r, eval=FALSE }summary(stat_ge, export = TRUE)```*
>
>Please, note that 'eval = FALSE'. Could this be the problem?
>The suggestion is to write to a tempdir() but even looking at the
>Duncan
>Murdoch's answer I cannot see how to do that in my case.
>Looking for any suggestion.
>Best regards,
>Tiago Olivoto
>
>
>
>
>
>
>
>
>
>-- Forwarded message -
>De: Duncan Murdoch 
>Date: sex, 27 de set de 2019 às 09:44
>Subject: Re: [R-pkg-devel] Passing CRAN check when an examples must
>save a
>file
>To: Zachary Flynn , 
>
>
>On 26/09/2019 11:43 p.m., Zachary Flynn wrote:
>> I am working on a function in a package that saves a file.  I want to
>write
>> an example to document the function so it must save a file, but when
>I do,
>> the automatic CRAN checks reject the package because there is a
>> non-standard file saved in the directory when the second test runs
>(first,
>> it runs a test on Windows where the check error does not occur, then
>on
>> Linux where it does).  The relevant check output is:
>>
>> * checking for non-standard things in the check directory ... NOTE
>> Found the following files/directories:
>>‘Produc.csv’
>>
>> There is no file called Produc.csv anywhere in the directory (the
>> error doesn't show up in the first run on Windows).
>>
>> It is generated by running the example code which automatic CRAN
>> testing might be doing in between running the Windows and Linux
>> checks?
>>
>> How do I write an example that must save a file to be an example of
>> using the function without triggering this issue?
>
>Save the file to the temporary directory, ẹ.g.
>
>   filename <- file.path(tempdir(), "Prodục.csv")
>   write.csv(something, file = filename)
>
>You could clean up at the end of the example with
>
>   unlink(filename)
>
>but you shouldn't rely on this alone to prevent the error:  if you're
>writing files, you should *only* be doing it in the temporary
>directory.
>
>Duncan Murdoch
>
>__
>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

-- 
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] Seeking for best way to manage package transitive dependencies

[Jeff Newmiller]

Seems quite clear to me. If dplyr chooses to re-implement pipes (e.g. based on 
[1]) then you should not be importing from magrittr unless you had a specific 
reason to, and if you do then you should not make assumptions about where the 
dplyr pipe came from.

[1] https://github.com/moodymudskipper/fastpipe

On October 10, 2019 9:09:08 AM PDT, Alexandre Courtiol 
 wrote:
>I agree in general, but don't think that the situation is always so
>straightforward.
>A good example of the complexity is the case of reexported functions:
>functions from other packages aimed at being used by users without the
>need
>to load them from their original package.
>For a concrete example, let's take the pipe (%>%): the pipe comes
>originally from {magrittr} but is reexported by many other packages
>(e.g.
>{dplyr}).
>So if your package relies on {dplyr} and reexport the pipe too, then
>one
>could argue that you simply need to import {dplyr} and not {magrittr}.
>I am not so sure I would agree with this (but my heart is not settled
>on
>the matter) for 2 reasons:
>- first, if you to reexport the pipe, your documentation would (I
>think)
>link to a documentation linking to a documentation...
>- second, you would not give credit to the {magrittr} developers (yes,
>in
>part the same people in that case, but that is not the point).
>Looking at what RSudio people chose to do in that precise example, it
>seems
>that packages directly refer to {magrittr}.
>I think that in the end it is a matter of weighing the pros and cons,
>and
>that may depend on the case.
>Re-exports may be a special case but giving credit to the right
>developers
>may be worth thinking about whatever the situation.
>++
>Alex
>
>
>
>
>On Thu, 10 Oct 2019 at 17:28, Cesko Voeten
>
>wrote:
>
>> Package B should import only the packages and functions that are used
>by
>> package B. If package B does not use functions from package C,
>package B
>> should not import package C. What package A does is package A's
>problem,
>> not package B's. If package A requires package C, install.packages()
>will
>> automatically install it when package C is being installed, just as
>package
>> C is installed when package B is being installed.
>>
>> I submit the following thought experiment: suppose that, at a later
>point
>> in time, package A is re-written to not need package C. In this case,
>it
>> would be incorrect for package B to still needlessly import package
>C.
>>
>> Best,
>> Cesko
>>
>> Op 10-10-2019 om 17:14 schreef neonira Arinoem:
>> > Suppose package B imports package A and package A imports package
>C.
>> >
>> > Shall package B import package C, knowing that package B will use
>> functions
>> > from package A that are using functions from package C ?
>> >
>> >
>> > Currently, package B imports package C. This leads to a note from
>CRAN
>> > stating
>> >
>> > Namespace in Imports field not imported from: ‘lubridate’
>> >All declared Imports should be used.
>> >
>> > Doing so, I expect package B user not to worry about needed package
>B
>> > dependencies.
>> >
>> >   What is the best way to to manage package transitive
>dependencies, in
>> such
>> > a case ?
>> >
>> > Neonira.
>> >
>> >   [[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
>>

-- 
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] winbuilder fails for package depending on rJava

[Jeff Newmiller]

I suspect David did not read the subject line. This is about winbuilder [1]. I 
don't know who runs that service (Uwe?), but this sounds like they need to 
investigate.

[1] https://win-builder.r-project.org/

On October 29, 2019 9:28:23 AM PDT, David Winsemius  
wrote:
>
>On 10/29/19 4:48 AM, Kevin Kuo wrote:
>> Seems like all rev deps of rJava are failing Windows checks with the
>same
>> error. Might be a Java architecture mismatch issue?
>
>Copied from the rJava GitHub page:
>
>==
>
>
>  Bug reports
>
>Please userJava GitHub issues page 
>
>
>to report bugs.
>
>
>(Seems likely that Simon would be aware of such a problem.)
>
>
>
>
>I get no errors in Ubuntu 18.04 with:
>
>
>|install.packages("rJava",,"http://rforge.net";) |
>
>You are supposed to offer your OS and other version details with a bug 
>report.

-- 
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] winbuilder fails for package depending on rJava

[Jeff Newmiller]

Once again, you can color me mystified. Are you reading logs not referred to in 
this email thread?

On October 29, 2019 12:28:59 PM PDT, David Winsemius  
wrote:
>
>On 10/29/19 12:22 PM, Jeff Newmiller wrote:
>> I suspect David did not read the subject line. This is about
>winbuilder [1]. I don't know who runs that service (Uwe?), but this
>sounds like they need to investigate.
>
>
>Correct on the first point, but when I go to that page it says:
>
>
>Pleasedo notupload packages of other maintainers (particularly not 
>without changing the Maintainer field to your own e-mail address, if
>you 
>have permissions to do that), because the maintainer indicated in the 
>maintainer field of the DESCRIPTION file get response from us. Pleasedo
>
>notupload Bioconductor packages or CRAN packages.

-- 
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] winbuilder fails for package depending on rJava

[Jeff Newmiller]

My understanding is that the failure of rJava in the winbuilder server is 
likely to be a system configuration error specific to that server, and is a 
sysadmin issue rather than a package maintainer issue. But the sysadmin may 
know different.

On October 29, 2019 4:23:24 PM PDT, David Winsemius  
wrote:
>
>On 10/29/19 2:12 PM, Jeff Newmiller wrote:
>> Once again, you can color me mystified. Are you reading logs not
>referred to in this email thread?
>
>Hi Jeff;
>
>I suppose am reading  else. I ran:
>
>maintainer("rJava")
>
>
>... and the result was Simon Urbanek's name (which wasn't surprising to
>
>me), and did not match the name of the OP.
>
>So I was (and am) puzzled that  Kevin was using win-builder on rJava.

-- 
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] How to Document and S3 Method for the Parenthesis Class?

[Jeff Newmiller]

There are three types of quoting in R... " and ' are for strings, and ` 
(backtick) is for symbols.

On November 7, 2019 6:35:49 AM PST, b...@denney.ws wrote:
>Hi,
>
> 
>
>Short version of the question:  How does one document a method for the
>"("
>class in a .Rd file?
>
> 
>
>Details:
>
>I recently contributed to the digest package functions to assist with
>generating sha1 hashes for formula objects.  Sometimes within formula,
>the
>parenthesis ("(") class is used, for example [1]:
>
> 
>
>> class((a~(b+c))[[3]])
>
>[1] "("
>
> 
>
>So, I wrote a method to handle that class, too.  When trying to
>document it
>in the .Rd file, I tried the following code, but when checking the
>documentation, it gets an error:
>
> 
>
>\method{sha1}{"("}(x, digits = 14, zapsmall = 7, ..., algo = "sha1")
>
> 
>
>The error when checking the documentation is:
>
> 
>
>> checking Rd \usage sections ... WARNING
>
>  Bad \usage lines found in documentation object 'sha1':
>
>   method{sha1}{"("}(x, digits = 14, zapsmall = 7, ...,
>algo = "sha1")
>
>  
>
>  Functions with \usage entries need to have the appropriate \alias
>
>  entries, and all their arguments documented.
>
>  The \usage entries must correspond to syntactically valid R code.
>
>  See chapter 'Writing R documentation files' in the 'Writing R
>
>  Extensions' manual.
>
> 
>
>I have tried variants of escaping the parenthesis like "\(" and "\\("
>and
>the unescaped variant "(", too.
>
> 
>
>Thanks,
>
> 
>
>Bill
>
> 
>
>[1] In case the first thought is, "don't write formula which have a
>full
>side within redundant parentheses", something equivalent to this was
>created
>by update.formula().
>
>
>   [[alternative HTML version deleted]]
>
>__
>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] How to Document and S3 Method for the Parenthesis Class?

[Jeff Newmiller]

That works not because of how the language works but because that is how the 
`<-` function works.

On November 7, 2019 7:47:57 AM PST, b...@denney.ws wrote:
>That's fair, though it's not 100% consistent because code like the
>following works for symbols, too:
>
>"(\\@" <- 1
>
>(This is selected to show how bad things can be done-- not as an
>example to advocate.)
>
>-Original Message-
>From: Jeff Newmiller  
>Sent: Thursday, November 7, 2019 10:43 AM
>To: r-package-devel@r-project.org; b...@denney.ws
>Subject: Re: [R-pkg-devel] How to Document and S3 Method for the
>Parenthesis Class?
>
>There are three types of quoting in R... " and ' are for strings, and `
>(backtick) is for symbols.
>
>On November 7, 2019 6:35:49 AM PST, b...@denney.ws wrote:
>>Hi,
>>
>> 
>>
>>Short version of the question:  How does one document a method for the
>
>>"("
>>class in a .Rd file?
>>
>> 
>>
>>Details:
>>
>>I recently contributed to the digest package functions to assist with 
>>generating sha1 hashes for formula objects.  Sometimes within formula,
>
>>the parenthesis ("(") class is used, for example [1]:
>>
>> 
>>
>>> class((a~(b+c))[[3]])
>>
>>[1] "("
>>
>> 
>>
>>So, I wrote a method to handle that class, too.  When trying to 
>>document it in the .Rd file, I tried the following code, but when 
>>checking the documentation, it gets an error:
>>
>> 
>>
>>\method{sha1}{"("}(x, digits = 14, zapsmall = 7, ..., algo = "sha1")
>>
>> 
>>
>>The error when checking the documentation is:
>>
>> 
>>
>>> checking Rd \usage sections ... WARNING
>>
>>  Bad \usage lines found in documentation object 'sha1':
>>
>>   method{sha1}{"("}(x, digits = 14, zapsmall = 7,
>..., 
>>algo = "sha1")
>>
>>  
>>
>>  Functions with \usage entries need to have the appropriate \alias
>>
>>  entries, and all their arguments documented.
>>
>>  The \usage entries must correspond to syntactically valid R code.
>>
>>  See chapter 'Writing R documentation files' in the 'Writing R
>>
>>  Extensions' manual.
>>
>> 
>>
>>I have tried variants of escaping the parenthesis like "\(" and "\\("
>>and
>>the unescaped variant "(", too.
>>
>> 
>>
>>Thanks,
>>
>> 
>>
>>Bill
>>
>> 
>>
>>[1] In case the first thought is, "don't write formula which have a 
>>full side within redundant parentheses", something equivalent to this 
>>was created by update.formula().
>>
>>
>>  [[alternative HTML version deleted]]
>>
>>__
>>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.

-- 
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] Including in my vignette a figure drawn outside R

[Jeff Newmiller]

You could use DiagrammeR.

On December 3, 2019 7:36:19 AM PST, Michael Dewey  
wrote:
>I am planning to include a flow-chart in the vignette of one of my 
>packages (metap). I am planning to draw it using dot from Graphviz. I 
>know that there is Rgraphviz which would do the whole thing in R but I 
>do this sort of thing rarely and I suspect the overhead of learning how
>
>to do it in Rgraphviz would outweigh the benefit.
>
>So my question is: if I wish to be a good Open Source citizen should I 
>just bundle the .pdf file resulting from dot with the vignette or
>should 
>I provide the .gv file which generated it? I think from reading Writing
>
>R Extensions that in either case I just put them in the directory along
>
>with my .Rnw file but please disabuse me of that impression if false.
>
>The package will need to live on CRAN if that makes a difference.

-- 
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] New Package olr 4 NOTES

[Jeff Newmiller]

I have not had good luck building packages for final delivery using devtools... 
use the command line, Luke!

On December 5, 2019 7:40:46 AM PST, Mat Fok via R-package-devel 
 wrote:
>Hi Max,
>Following your comment about, ".Rbuildignore is used by R CMD build to
>exclude some files from the bundled package. If you created the tar.gz
>file manually, then .Rbuildignore was, well, ignored. And .Rproj.user
>would then have been included in the tarball."
>I assume that if I create the tar.gz file "automatically" through R and
>not 7zip, then the .Rbuildignore is not ignored and I won't have the
>problem of .Rproj.user being included in the tarball:
>
>devtools::build(pkg = "C:/Rstuff/olr", path = NULL, binary = FALSE,
>vignettes = TRUE, manual = FALSE, args = NULL, quiet = FALSE)
>
>√  checking for file 'C:\Rstuff\olr/DESCRIPTION' ...-  preparing
>'olr':√  checking DESCRIPTION meta-information ...-  checking for LF
>line-endings in source and make files and shell scripts-  checking for
>empty or unneeded directories-  building 'olr_1.0.0.2000.tar.gz'   [1]
>"C:/Rstuff/olr_1.0.0.2000.tar.gz"
>Thank you very much!
>
>
>
>
>
>On Thursday, December 5, 2019, 9:25 AM, Max Turgeon
> wrote:
>
>#yiv7416260906 -- P {margin-top:0;margin-bottom:0;}#yiv7416260906 
>.Rbuildignore is used by R CMD build to exclude some files from the
>bundled package. If you created the tar.gz file manually, then
>.Rbuildignore was, well, ignored. And .Rproj.user would then have been
>included in the tarball.
>
>
>
>
>
>Max Turgeon
>Assistant ProfessorDepartment of Statistics
>Department of Computer Science
>University of Manitobamaxturgeon.ca
>
>
>
>
>
>From: R-package-devel  on behalf
>of Mat Fok via R-package-devel 
>Sent: December 5, 2019 8:17 AM
>To: Martin Maechler
>Cc: R-package-devel
>Subject: Re: [R-pkg-devel] New Package olr 4 NOTES I meant
>.Rbuildignore.
>
>
>Sent from Yahoo Mail for iPhone
>
>
>On Thursday, December 5, 2019, 3:19 AM, Martin Maechler
> wrote:
>
>> Mat Fok via R-package-devel 
>>    on Wed, 4 Dec 2019 22:25:47 + writes:
>
>    > Hi,
>    > Thank you. I am wondering why the log would output .Rproj.user
>when it was already in the .Rignorefile. Hope the .Rignore file is
>correct anyways as I have mentioned below.
>
>If you really use .Rignore then no wonder you have problems.
>The correct file name is  .Rbuildignore
>
>Martin
>
>    > Thanks,
>    > Mathew
>
>
>
>
>    [[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

-- 
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] pandoc lua filter error with win devel check

[Jeff Newmiller]

Pandoc is not part of the standard R documentation tooling... you must be doing 
something special, and doing something special makes getting a package accepted 
more challenging. Perhaps if you were more specific you might get a more 
specific response.

On January 6, 2020 1:38:44 PM PST, Fernando Roa  wrote:
>Hi people,
>
>I got an error in vignettes after checking as win. devel. with
>devtools (check_win_devel):
>
>pandoc.exe: unrecognized option
>`--lua-filter=refs/multiple-bibliographies.lua'
>
>May I ignore it?
>
>Best,

-- 
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] For reproducibility issue

[Jeff Newmiller]

As an existing package I suspect that it already calls the R RNG, but the 
default RNG changed [1] so you need to call
RNGkind(sample.kind = "Rounding") before calling set.seed in your test code to 
compare with old results.

[1] 
https://stackoverflow.com/questions/47199415/is-set-seed-consistent-over-different-versions-of-r-and-ubuntu/56381613#56381613

On January 17, 2020 6:39:14 AM PST, Ivan Krylov  wrote:
>On Fri, 17 Jan 2020 13:55:39 +
>وليد خلف معوض المطيرى  wrote:
>
>> So, does anyone have an idea of how to solve this issue.
>
>"Writing R Extensions", 1.6. Writing portable packages:
>
>>> Compiled code should not call the system random number generators
>>> such as rand, drand48 and random, but rather use the interfaces to
>>> R’s RNGs described in Random numbers. In particular, if more than
>>> one package initializes the system RNG (e.g. via srand), they will
>>> interfere with each other.
>
>>> Nor should the C++11 random number library be used, nor any other
>>> third-party random number generators such as those in GSL.
>
>It somewhat less convenient to call the R random number generator from
>Fortran than it would be from C or C++, but still possible. There is a
>F77-style example of such use [1], but since you are already using
>iso_c_binding, you should be able to declare the C API [2] right in the
>Fortran source:
>
>subroutine GetRNGState() bind(c)
>end subroutine
>
>subroutine PutRNGstate() bind(c)
>end subroutine
>
>As a bonus, you get to use the R distribution functions [3], without
>the need to implement them yourself from uniformly distributed samples:
>
>function rnorm(mu, sigma) bind(c) result(ret)
> use intrinsic, iso_c_binding, only: c_double
> real(c_double), value :: mu, sigma
> real(c_double) ret
>end function
>
>function rgamma(shape, scale) bind(c) result(ret)
> use intrinsic, iso_c_binding, only: c_double
> real(c_double), value :: shape, scale
> real(c_double) ret
>end function
>
>(The prototypes above are unchecked; I haven't written any Fortran 2003
>in more than a year.)

-- 
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] Optional library dependencies for compiled code

[Jeff Newmiller]

Complex system dependencies are not cleanly handled by the R packaging system, 
but Suggesting other packages is. You could create or re-use an existing 
package for each external dependency and possibly even let the user specify 
which one they want to your dependent package the way DBI handles database 
drivers. This gives you a clean isolated system dependency for each 
"compression driver" that you can handle with configure to be slick or force 
the user to address the system dependency with a simple external call.

On January 29, 2020 7:30:25 AM PST, Dirk Eddelbuettel  wrote:
>
>Guido,
>
>On 29 January 2020 at 15:11, Guido Kraemer wrote:
>| I am developing an R package that can make (optional, but strongly 
>| recommended) use of a number of external compression algorithms. What
>is 
>| the best strategy if I want to distribute this as an R package?
>Because
>
>It's actually a fairly difficult issue.
>
>I have packages on GitHub but not on CRAN for that very reason (of
>difficult
>to bundle external libraries).
>
>| the package is for reading large external data sets, the package will
>
>| probably not be very useful without compression.
>| 
>| - Make a hard dependency on all external libraries and make user 
>| manually disable it if they cannot install a library for some reason?
>
>Could do, but probably means the package cannot get onto CRAN as the
>build
>will fail "as shipped" ?
>
>Also forces users to set up build options etc.  Hard. May reduce use.
> 
>| - Make no dependency on external libraries and have the user compile
>it 
>| manually if they want compression?
>
>Same, no? Too much user dependency.
> 
>| - Look for installed libraries and use only these? (If so: How would
>I 
>| do this during the installation of an R package?)
>
>I once added the ability to use a system / existing 'nlopt' library to
>the
>'nloptr' package.  The package still defaults to downloading a tar.gz
>and
>building during its build, but can use the system library for a
>speedup.  You
>could look at that. All done via configure.
>
>There are other "tricks". At least one package I know cheats (at least
>on
>Linux), comes empty and tells you to install what is needed and
>reinstall.
>That passes the letter of the law ("hey, the package builds on CRAN")
>but
>hardly the spirit of the law.
> 
>| - How does this work on Windows?
>
>Even less easily.
> 
>| The possible compressions are: blosc, zlib, bzip2, lz4, xz
>
>Some of these are a given with R.
>
>For my Debian builds I enable at least zlib, bzip2, lzma -- but I have
>to
>"pretty soon" look into a similar list for another project.  My plan
>there is
>bundle the sources of the missing compressors (and other libraries I
>need)
>and trigger a static library build (for each, or maybe all) from
>configure.
>
>Dirk

-- 
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] Warning: parse error in file 'Rraven-Ex.R'

[Jeff Newmiller]

In your examples.

On February 4, 2020 5:53:08 PM PST, Marcelo Araya Salas  
wrote:
>Hi all
>
>I got this error from CRAN tests:
>
>Warning: parse error in file 'Rraven-Ex.R':
>'\.' is an unrecognized escape in character string starting ""\."
>
>However, I can't find the original file where the error is found. I
>have
>try unsuccessfully for several hours :(
>
>any suggestions on how to find it?
>
>thanks!
>
>Marcelo
>
>
>
>El mar., 4 feb. 2020 a las 8:34, Dirk Eddelbuettel ()
>escribió:
>
>>
>> On 4 February 2020 at 08:15, Marcelo Araya Salas wrote:
>> | I found it here:
>> |
>> | ftp://cran.r-project.org/incoming/archive/
>> |
>> | not sure what that's suppose to mean
>>
>> "It's dead."
>>
>> It generally means you will have gotten an email with the reasoning. 
>But
>> whatever is in archive/ is no longer processed.
>>
>> 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

-- 
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] Private S3 Method not Found

[Jeff Newmiller]

I don't think it is possible to avoid exporting S3 methods from a package and 
still have the class behave as intended. Use a regular function if name 
encapsulation is important to you.

On February 17, 2020 8:33:30 AM PST, b...@denney.ws wrote:
>Thanks for the pointer!  Adding
>"S3method(knit_print_helper_formula,name)" to the NAMESPACE seems to
>have fixed it.
>
>For others who come across this, in roxygen2 parlance, that means
>using:
>
>#' @method knit_print_helper_formula name
>#' @export
>
>Even though the actual export is not desired.
>
>Thanks,
>
>Bill
>
>-Original Message-
>From: Duncan Murdoch  
>
>On 17/02/2020 10:05 a.m., b...@denney.ws wrote:
> 
>> Does anyone know why the S3 method for name class objects is not
>found 
>> when checking the package?
>
>I think you need to register knit_print_helper_formula.name as an S3
>method even if the generic is not exported.  I forget whether you do
>this in the NAMESPACE file or at runtime using registerS3method.
>
>__
>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] First R package, want to release to CRAN, have some questions about R CMD check and README.md

[Jeff Newmiller]

README.md is a github convention... do not try to treat it like part of the R 
package documentation. Instead, list it in your .Rbuildignore file and use it 
to inform developers how to change the package and to direct (potential) users 
browsing the GitHub repo to read the more conventional R documentation of 
vignettes.

On March 7, 2020 1:55:24 PM PST, Jeffry Hesse  wrote:
>Hi there!
>
>I and a few others have been working on an R package we'd like to get
>on
>CRAN. The package itself checks R dependencies to see if they have a
>known
>CWE or CVE attached to them, and is intended to help R developers get a
>better understanding on the quality of the dependencies they use!
>
>An example of it running is here:
>
>https://61-244738782-gh.circle-artifacts.com/0/~/oysteR/oysteR.Rcheck/00install.out
>
>And example of the output of R CMD check is here:
>
>https://61-244738782-gh.circle-artifacts.com/0/~/oysteR/oysteR.Rcheck/00check.log
>
>I have had some confusing experiences thus far with a README.md file,
>and
>excluded it in our .Rbuildignore, because I kept getting:
>
>* checking top-level files ... WARNING
>Conversion of ‘README.md’ failed:
>"template" (line 18, column 17):
>unexpected "("
>expecting "." or "$"
>
>This error is very cryptic to me, and I couldn't figure it out after a
>bunch of wonderful googling :)
>
>The README.rmd file is here:
>https://github.com/sonatype-nexus-community/oysteR/blob/master/README.Rmd
>
>Output README.md generated with rmarkdown is here:
>https://raw.githubusercontent.com/sonatype-nexus-community/oysteR/master/README.md
>
>Ideally I think it would be nice to include it in our R package, but
>that
>WARNING keeps scaring me :)
>
>If anyone has any insight into the cause of that warning, would love to
>know.
>
>Any other feedback on the package would be great too! I'm not an R
>developer by trade (but love it), and this is my first go at this.
>Figured
>I'd reach out here to hopefully help save some back and forth between
>CRAN
>maintainers when I go to submit.
>
>CODE: https://github.com/sonatype-nexus-community/oysteR
>
>Also, we are actively looking for contributors that want to help out,
>so if
>this project interests you, come on over!
>
>Cheers, and thanks in advance for any help!

-- 
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] First R package, want to release to CRAN, have some questions about R CMD check and README.md

[Jeff Newmiller]

My opinion is that vignettes make or break the uptake of a package... but they 
are not mandatory.

I like to have a 'dev' directory where I keep meta-files like README.Rmd... of 
course that gets listed in .Rbuildignore also.

I don't know about oysteR.Rmd. There are approved ways to have vignettes 
compiled as part of your package, but AFAIK that is not required.

On March 7, 2020 3:05:01 PM PST, Jeffry Hesse  wrote:
>Good to know!
>
>Right now we are using the README.rmd file to create the README.md, I
>imagine we'd create something akin to oysteR.rmd to create the
>vignette?
>The documentation on publishing to CRAN is great, but it's hard to tell
>what a best practice is in this area. Also are vignettes strongly
>suggested
>or mandatory? R CMD check is not failing for us right now without
>having
>them, hence the question!
>
>Appreciate the help!
>
>On Sat, Mar 7, 2020 at 1:55 PM Jeff Newmiller
>
>wrote:
>
>> README.md is a github convention... do not try to treat it like part
>of
>> the R package documentation. Instead, list it in your .Rbuildignore
>file
>> and use it to inform developers how to change the package and to
>direct
>> (potential) users browsing the GitHub repo to read the more
>conventional R
>> documentation of vignettes.
>>
>> On March 7, 2020 1:55:24 PM PST, Jeffry Hesse 
>wrote:
>> >Hi there!
>> >
>> >I and a few others have been working on an R package we'd like to
>get
>> >on
>> >CRAN. The package itself checks R dependencies to see if they have a
>> >known
>> >CWE or CVE attached to them, and is intended to help R developers
>get a
>> >better understanding on the quality of the dependencies they use!
>> >
>> >An example of it running is here:
>> >
>> >
>>
>https://61-244738782-gh.circle-artifacts.com/0/~/oysteR/oysteR.Rcheck/00install.out
>> >
>> >And example of the output of R CMD check is here:
>> >
>> >
>>
>https://61-244738782-gh.circle-artifacts.com/0/~/oysteR/oysteR.Rcheck/00check.log
>> >
>> >I have had some confusing experiences thus far with a README.md
>file,
>> >and
>> >excluded it in our .Rbuildignore, because I kept getting:
>> >
>> >* checking top-level files ... WARNING
>> >Conversion of ‘README.md’ failed:
>> >"template" (line 18, column 17):
>> >unexpected "("
>> >expecting "." or "$"
>> >
>> >This error is very cryptic to me, and I couldn't figure it out after
>a
>> >bunch of wonderful googling :)
>> >
>> >The README.rmd file is here:
>>
>>https://github.com/sonatype-nexus-community/oysteR/blob/master/README.Rmd
>> >
>> >Output README.md generated with rmarkdown is here:
>> >
>>
>https://raw.githubusercontent.com/sonatype-nexus-community/oysteR/master/README.md
>> >
>> >Ideally I think it would be nice to include it in our R package, but
>> >that
>> >WARNING keeps scaring me :)
>> >
>> >If anyone has any insight into the cause of that warning, would love
>to
>> >know.
>> >
>> >Any other feedback on the package would be great too! I'm not an R
>> >developer by trade (but love it), and this is my first go at this.
>> >Figured
>> >I'd reach out here to hopefully help save some back and forth
>between
>> >CRAN
>> >maintainers when I go to submit.
>> >
>> >CODE: https://github.com/sonatype-nexus-community/oysteR
>> >
>> >Also, we are actively looking for contributors that want to help
>out,
>> >so if
>> >this project interests you, come on over!
>> >
>> >Cheers, and thanks in advance for any help!
>>
>> --
>> Sent from my phone. Please excuse my brevity.
>>

-- 
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] First R package, want to release to CRAN, have some questions about R CMD check and README.md

[Jeff Newmiller]

Apparently I am behind the times... both README (plain text) and README.md 
(markdown) are now recognized files by R. But the Rmd file does need to be 
ignored.

On March 7, 2020 4:09:03 PM PST, "Robert M. Flight"  wrote:
>Umm, but README.md becomes README.html on CRAN, and it is very nice to
>have.
>
>I'm not sure what the error you are seeing is, but having README on
>CRAN is
>nice.
>
>Have you .Rbuildignore 'd README.Rmd?? That should be ignored if I
>remember
>correctly.
>
>-Robert
>
>On Sat, Mar 7, 2020, 5:55 PM Jeff Newmiller 
>wrote:
>
>> README.md is a github convention... do not try to treat it like part
>of
>> the R package documentation. Instead, list it in your .Rbuildignore
>file
>> and use it to inform developers how to change the package and to
>direct
>> (potential) users browsing the GitHub repo to read the more
>conventional R
>> documentation of vignettes.
>>
>> On March 7, 2020 1:55:24 PM PST, Jeffry Hesse 
>wrote:
>> >Hi there!
>> >
>> >I and a few others have been working on an R package we'd like to
>get
>> >on
>> >CRAN. The package itself checks R dependencies to see if they have a
>> >known
>> >CWE or CVE attached to them, and is intended to help R developers
>get a
>> >better understanding on the quality of the dependencies they use!
>> >
>> >An example of it running is here:
>> >
>> >
>>
>https://61-244738782-gh.circle-artifacts.com/0/~/oysteR/oysteR.Rcheck/00install.out
>> >
>> >And example of the output of R CMD check is here:
>> >
>> >
>>
>https://61-244738782-gh.circle-artifacts.com/0/~/oysteR/oysteR.Rcheck/00check.log
>> >
>> >I have had some confusing experiences thus far with a README.md
>file,
>> >and
>> >excluded it in our .Rbuildignore, because I kept getting:
>> >
>> >* checking top-level files ... WARNING
>> >Conversion of ‘README.md’ failed:
>> >"template" (line 18, column 17):
>> >unexpected "("
>> >expecting "." or "$"
>> >
>> >This error is very cryptic to me, and I couldn't figure it out after
>a
>> >bunch of wonderful googling :)
>> >
>> >The README.rmd file is here:
>>
>>https://github.com/sonatype-nexus-community/oysteR/blob/master/README.Rmd
>> >
>> >Output README.md generated with rmarkdown is here:
>> >
>>
>https://raw.githubusercontent.com/sonatype-nexus-community/oysteR/master/README.md
>> >
>> >Ideally I think it would be nice to include it in our R package, but
>> >that
>> >WARNING keeps scaring me :)
>> >
>> >If anyone has any insight into the cause of that warning, would love
>to
>> >know.
>> >
>> >Any other feedback on the package would be great too! I'm not an R
>> >developer by trade (but love it), and this is my first go at this.
>> >Figured
>> >I'd reach out here to hopefully help save some back and forth
>between
>> >CRAN
>> >maintainers when I go to submit.
>> >
>> >CODE: https://github.com/sonatype-nexus-community/oysteR
>> >
>> >Also, we are actively looking for contributors that want to help
>out,
>> >so if
>> >this project interests you, come on over!
>> >
>> >Cheers, and thanks in advance for any help!
>>
>> --
>> 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
>>

-- 
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] slightly polemic question re R CMD check

[Jeff Newmiller]

You seem to think this is a bad thing. R does encourage lenient argument 
checking... what rock have you been under for the last 20 years?

On March 8, 2020 5:41:51 AM PDT, David Hugh-Jones  
wrote:
>You're quite right :-) But I think the polemic still holds, because I
>have
>to add manual argument checking to all my methods, which has a cost in
>lines of code. Indeed, few base R methods have chosen to do this. In
>effect, the current setup encourages writing methods with "lenient"
>argument specifications.
>
>Thank you for the suggestion about ellipsis.
>
>On Sun, 8 Mar 2020, 11:04 Gábor Csárdi,  wrote:
>
>> You can add the ... argument to chop.default(), and then check that
>> length(list(...)) is zero.
>>
>> Also, you might be interested in the ellipsis package.
>>
>> Gabor
>>
>> On Sun, Mar 8, 2020 at 10:56 AM David Hugh-Jones
>>  wrote:
>> >
>> > Hi all,
>> >
>> > My package defines the following method and generic:
>> >
>> > chop <- function (x, ...) UseMethod("chop")
>> >
>> > chop.default <- function (x, breaks, labels, extend = NULL, drop =
>TRUE)
>> {
>> > ... }
>> >
>> > R CMD check then gives a warning:
>> >
>> > W  checking S3 generic/method consistency (695ms)
>> >chop:
>> >  function(x, ...)
>> >chop.default:
>> >  function(x, breaks, labels, extend, drop)
>> >
>> >See section ‘Generic functions and methods’ in the ‘Writing R
>> >Extensions’ manual.
>> >
>> > I can fix this by adding a ... argument to chop.default:
>> >
>> > chop.default <- function (x, breaks, labels, extend = NULL, drop =
>> > TRUE, ...)
>> >
>> > But that makes the code less robust because e.g.
>> >
>> > chop(x, Breaks = 1:3)
>> >
>> > will no longer throw an error from the misspelled argument.
>> >
>> > Or I can write:
>> >
>> > chop(x, breaks, labels, extend, drop) UseMethod("chop")
>> >
>> > but this means I cannot use a different interface for a different
>method.
>> >
>> > This seems like a mistake. (That's the polemic.) Or am I missing a
>better
>> > way? (That's the question.)
>> >
>> > David
>> >
>> > [[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

-- 
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] slightly polemic question re R CMD check

[Jeff Newmiller]

R encourages the use of ... particularly in S3 generics, to avoid 
over-depending on inheritance to enable flexible use of these generics. That 
is, when you call the generic without knowing which class you are giving it, 
you cannot specify class-specific arguments. However, some methods have obvious 
alternative class-specific behaviors that are typically enabled using 
class-specific arguments (e.g. plot). You cannot support both fully-generic 
calls and class-specific calls without giving the generic some flexibility that 
won't get used in some cases.


On March 8, 2020 9:41:51 AM PDT, David Hugh-Jones  
wrote:
>Hi Jeff,
>
>I wouldn't say R encourages that in general. Non-generic functions will
>throw an error if you use a non-existent argument. And some generic
>functions check for it:
>
>seq(1, 3, blah = 1)
>[1] 1 2 3
>Warning message:
>In seq.default(1, 3, blah = 1) :
> extra argument ‘blah’ will be disregarded
>
>In fact there is even a `chkDots()` function to help with this - which,
>despite having used R or 17 years, I first discovered today :-). So, it
>seems the R base developers thought lenient argument checking could be
>a
>bad thing, presumably because it lets errors go undetected.
>
>Maybe chkDots is a reasonable workaround. But I wonder what the
>rationale
>is for R CMD check enforcing that methods *must* be as lenient as the
>generic. It seems to lead to a lot of documentation of the form:
>
>@param ... Not used.
>
>Cheers,
>David
>
>
>On Sun, 8 Mar 2020 at 16:24, Jeff Newmiller 
>wrote:
>
>> You seem to think this is a bad thing. R does encourage lenient
>argument
>> checking... what rock have you been under for the last 20 years?
>>
>> On March 8, 2020 5:41:51 AM PDT, David Hugh-Jones <
>> davidhughjo...@gmail.com> wrote:
>> >You're quite right :-) But I think the polemic still holds, because
>I
>> >have
>> >to add manual argument checking to all my methods, which has a cost
>in
>> >lines of code. Indeed, few base R methods have chosen to do this. In
>> >effect, the current setup encourages writing methods with "lenient"
>> >argument specifications.
>> >
>> >Thank you for the suggestion about ellipsis.
>> >
>> >On Sun, 8 Mar 2020, 11:04 Gábor Csárdi, 
>wrote:
>> >
>> >> You can add the ... argument to chop.default(), and then check
>that
>> >> length(list(...)) is zero.
>> >>
>> >> Also, you might be interested in the ellipsis package.
>> >>
>> >> Gabor
>> >>
>> >> On Sun, Mar 8, 2020 at 10:56 AM David Hugh-Jones
>> >>  wrote:
>> >> >
>> >> > Hi all,
>> >> >
>> >> > My package defines the following method and generic:
>> >> >
>> >> > chop <- function (x, ...) UseMethod("chop")
>> >> >
>> >> > chop.default <- function (x, breaks, labels, extend = NULL, drop
>=
>> >TRUE)
>> >> {
>> >> > ... }
>> >> >
>> >> > R CMD check then gives a warning:
>> >> >
>> >> > W  checking S3 generic/method consistency (695ms)
>> >> >chop:
>> >> >  function(x, ...)
>> >> >chop.default:
>> >> >  function(x, breaks, labels, extend, drop)
>> >> >
>> >> >See section ‘Generic functions and methods’ in the ‘Writing R
>> >> >Extensions’ manual.
>> >> >
>> >> > I can fix this by adding a ... argument to chop.default:
>> >> >
>> >> > chop.default <- function (x, breaks, labels, extend = NULL, drop
>=
>> >> > TRUE, ...)
>> >> >
>> >> > But that makes the code less robust because e.g.
>> >> >
>> >> > chop(x, Breaks = 1:3)
>> >> >
>> >> > will no longer throw an error from the misspelled argument.
>> >> >
>> >> > Or I can write:
>> >> >
>> >> > chop(x, breaks, labels, extend, drop) UseMethod("chop")
>> >> >
>> >> > but this means I cannot use a different interface for a
>different
>> >method.
>> >> >
>> >> > This seems like a mistake. (That's the polemic.) Or am I missing
>a
>> >better
>> >> > way? (That's the question.)
>> >> >
>> >> > David
>> >> >
>> >> > [[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
>>
>> --
>> Sent from my phone. Please excuse my brevity.
>>

-- 
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] slightly polemic question re R CMD check

[Jeff Newmiller]

... also, the only reason non-generic functions using ellipsis can throw an 
error when an argument is not used is that they keep passing ... on to 
functions that recursively encounter fumctions that eventually do not accept an 
ellipsis argument. If the function calls a generic with an ellipsis argument 
then we are back into the generic conundrum again and the user will experience 
the normal function failing to catch unused arguments.

On March 8, 2020 10:14:49 AM PDT, Jeff Newmiller  
wrote:
>R encourages the use of ... particularly in S3 generics, to avoid
>over-depending on inheritance to enable flexible use of these generics.
>That is, when you call the generic without knowing which class you are
>giving it, you cannot specify class-specific arguments. However, some
>methods have obvious alternative class-specific behaviors that are
>typically enabled using class-specific arguments (e.g. plot). You
>cannot support both fully-generic calls and class-specific calls
>without giving the generic some flexibility that won't get used in some
>cases.
>
>
>On March 8, 2020 9:41:51 AM PDT, David Hugh-Jones
> wrote:
>>Hi Jeff,
>>
>>I wouldn't say R encourages that in general. Non-generic functions
>will
>>throw an error if you use a non-existent argument. And some generic
>>functions check for it:
>>
>>seq(1, 3, blah = 1)
>>[1] 1 2 3
>>Warning message:
>>In seq.default(1, 3, blah = 1) :
>> extra argument ‘blah’ will be disregarded
>>
>>In fact there is even a `chkDots()` function to help with this -
>which,
>>despite having used R or 17 years, I first discovered today :-). So,
>it
>>seems the R base developers thought lenient argument checking could be
>>a
>>bad thing, presumably because it lets errors go undetected.
>>
>>Maybe chkDots is a reasonable workaround. But I wonder what the
>>rationale
>>is for R CMD check enforcing that methods *must* be as lenient as the
>>generic. It seems to lead to a lot of documentation of the form:
>>
>>@param ... Not used.
>>
>>Cheers,
>>David
>>
>>
>>On Sun, 8 Mar 2020 at 16:24, Jeff Newmiller 
>>wrote:
>>
>>> You seem to think this is a bad thing. R does encourage lenient
>>argument
>>> checking... what rock have you been under for the last 20 years?
>>>
>>> On March 8, 2020 5:41:51 AM PDT, David Hugh-Jones <
>>> davidhughjo...@gmail.com> wrote:
>>> >You're quite right :-) But I think the polemic still holds, because
>>I
>>> >have
>>> >to add manual argument checking to all my methods, which has a cost
>>in
>>> >lines of code. Indeed, few base R methods have chosen to do this.
>In
>>> >effect, the current setup encourages writing methods with "lenient"
>>> >argument specifications.
>>> >
>>> >Thank you for the suggestion about ellipsis.
>>> >
>>> >On Sun, 8 Mar 2020, 11:04 Gábor Csárdi, 
>>wrote:
>>> >
>>> >> You can add the ... argument to chop.default(), and then check
>>that
>>> >> length(list(...)) is zero.
>>> >>
>>> >> Also, you might be interested in the ellipsis package.
>>> >>
>>> >> Gabor
>>> >>
>>> >> On Sun, Mar 8, 2020 at 10:56 AM David Hugh-Jones
>>> >>  wrote:
>>> >> >
>>> >> > Hi all,
>>> >> >
>>> >> > My package defines the following method and generic:
>>> >> >
>>> >> > chop <- function (x, ...) UseMethod("chop")
>>> >> >
>>> >> > chop.default <- function (x, breaks, labels, extend = NULL,
>drop
>>=
>>> >TRUE)
>>> >> {
>>> >> > ... }
>>> >> >
>>> >> > R CMD check then gives a warning:
>>> >> >
>>> >> > W  checking S3 generic/method consistency (695ms)
>>> >> >chop:
>>> >> >  function(x, ...)
>>> >> >chop.default:
>>> >> >  function(x, breaks, labels, extend, drop)
>>> >> >
>>> >> >See section ‘Generic functions and methods’ in the ‘Writing
>R
>>> >> >Extensions’ manual.
>>> >> >
>>> >> > I can fix this by adding a ... argument to chop.default:
>>> >> >
>>> >> > chop.default <- function (x, breaks, labels, extend = NULL,
>drop
>>=
&g

Re: [R-pkg-devel] [EXTERNAL] Re: slightly polemic question re R CMD check

[Jeff Newmiller]

Re backwards specialization... you could also say that a vector is a special 
kind of matrix... but it most definitely is not that way in R.

On March 9, 2020 9:51:47 AM PDT, Hong Ooi  wrote:
>I tend to agree. Having ... as an argument for a specific method is
>often unnecessary, and furthermore, can result in errors being hidden.
>Eg you think you're calling
>
>methodname(arg1, arg2="whatever")
>
>but you're really calling
>
>methodname(arg1, ar2="whatever")
>
>and the misspelling isn't picked up, because it gets swallowed by the
>... .
>
>IMO the whole reason for the current state of affairs is because of a
>wart in how lm and glm were implemented back in the S-Plus days. A glm
>object inherits from lm, which doesn't make a lot of sense. It should
>really be the other way round: the specific case should inherit from
>the general, so that an lm is a glm, not a glm is an lm. It's way too
>late to change this now, of course.
>
>
>-Original Message-
>From: R-package-devel  On Behalf
>Of David Hugh-Jones
>Sent: Sunday, 8 March 2020 6:28 PM
>To: Jeff Newmiller 
>Cc: R package devel 
>Subject: [EXTERNAL] Re: [R-pkg-devel] slightly polemic question re R
>CMD check
>
>I see the logic, but it seems in practice people often write specific
>methods with their own specific arguments. (Think of the many plot or
>print
>methods for different objects, for example.) Here, enforcing a ...
>argument
>does not buy us much. All that we really need is that plot(x) will work
>for
>many classes of x. Beyond that, we expect users to read the
>method-specific
>documentation.
>
>Maybe this is an antipattern. It just seems that S3 methods have turned
>out
>to be often used that way. Enforcing ... hasn't stopped it, and causes
>some
>awkwardnesses in documentation and error checking. To be clear, I'm not
>arguing against the generic having flexibility. I'm arguing against
>enforcing that the method always accepts every argument that the
>generic
>could accept.
>
>
>
>
>On Sun, 8 Mar 2020, 17:14 Jeff Newmiller, 
>wrote:
>
>> R encourages the use of ... particularly in S3 generics, to avoid
>> over-depending on inheritance to enable flexible use of these
>generics.
>> That is, when you call the generic without knowing which class you
>are
>> giving it, you cannot specify class-specific arguments. However, some
>> methods have obvious alternative class-specific behaviors that are
>> typically enabled using class-specific arguments (e.g. plot). You
>cannot
>> support both fully-generic calls and class-specific calls without
>giving
>> the generic some flexibility that won't get used in some cases.
>>
>>
>> On March 8, 2020 9:41:51 AM PDT, David Hugh-Jones <
>> davidhughjo...@gmail.com> wrote:
>> >Hi Jeff,
>> >
>> >I wouldn't say R encourages that in general. Non-generic functions
>will
>> >throw an error if you use a non-existent argument. And some generic
>> >functions check for it:
>> >
>> >seq(1, 3, blah = 1)
>> >[1] 1 2 3
>> >Warning message:
>> >In seq.default(1, 3, blah = 1) :
>> > extra argument ‘blah’ will be disregarded
>> >
>> >In fact there is even a `chkDots()` function to help with this -
>which,
>> >despite having used R or 17 years, I first discovered today :-). So,
>it
>> >seems the R base developers thought lenient argument checking could
>be
>> >a
>> >bad thing, presumably because it lets errors go undetected.
>> >
>> >Maybe chkDots is a reasonable workaround. But I wonder what the
>> >rationale
>> >is for R CMD check enforcing that methods *must* be as lenient as
>the
>> >generic. It seems to lead to a lot of documentation of the form:
>> >
>> >@param ... Not used.
>> >
>> >Cheers,
>> >David
>> >
>> >
>> >On Sun, 8 Mar 2020 at 16:24, Jeff Newmiller
>
>> >wrote:
>> >
>> >> You seem to think this is a bad thing. R does encourage lenient
>> >argument
>> >> checking... what rock have you been under for the last 20 years?
>> >>
>> >> On March 8, 2020 5:41:51 AM PDT, David Hugh-Jones <
>> >> davidhughjo...@gmail.com> wrote:
>> >> >You're quite right :-) But I think the polemic still holds,
>because
>> >I
>> >> >have
>> >> >to add manual argument checking to all my methods, which has a
>cost
>> >in
>> >> >lines of code. 

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

[Jeff Newmiller]

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

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

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

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


On March 15, 2020 1:07:41 AM PDT, "Alois Schlögl"  
wrote:
>
>Dear R packagers,
>
>
>the Biosig project [1] supports reading of about 50 different data
>format [2]. Recently, a language binding to R was added, because a user
>of Biosig asked for it. 
>
>
>I've read the policy [3], and it seems the biosig would qualify as
>binary package. The underlying library (libbiosig) can be installed
>
>- on linux from source, or through debian/ubuntu package
>
>- on MacOSX through Homebrew.
>
>- for Windows I'm using MXE mingw-cross-compiler environment to build
>libbiosig.dll 
>
>
>Would it be feasible to provide a package of biosig on cran ? What need
>to be considered ?
>
>
>Kind regards
>
>   Alois
>
>
>
>[1] http://biosig.sourceforge.net/download.html
>
>[2] http://pub.ist.ac.at/~schloegl/biosig/TESTED
>
>[3] https://cran.r-project.org/web/packages/policies.html
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
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] [FWD] [CRAN-pretest-archived] CRAN submission JuliaConnectoR 0.5.0

[Jeff Newmiller]

One could take the position that the library and require functions were a 
mistake to begin with and that all contributed packages should be accessed 
using ::...  or one could recognize that these functions are an expected 
feature of R at this point and then it is not defensible to ban the proposed 
approach of importing names as Stefan wants to. I don't think it is fair to 
require this higher level of specificity just because it involves use of attach.

That said, another feature of R packages is the integrated help system... 
importing Julia functions wholesale may lead to problems with consistency in 
navigating the help files. IMO it may be justifiable to ban this particular 
syntactic convenience to maintain some separation in the minds of users looking 
for help on these new functions, since the syntactic and semantic structure of 
functions from another language may not align well with normal R functions. But 
I am not familiar with Julia or Stefan's package or the support it brings in 
this area... I just disagree with banning a "library" lookalike function "just 
because" it happens to involve attach.

On April 6, 2020 8:40:12 AM PDT, Duncan Murdoch  
wrote:
>On 06/04/2020 11:25 a.m., Stefan Lenz IMBI wrote:
>> Yes, as I wrote earlier, I would like to imitate the behaviour of
>loading an R package
>> 
>>   juliaUsing("SomeJuliaPackage") # exports myJuliaFunction
>>   myJuliaFunction()
>> 
>> like R:
>> 
>>   library("MyRPackage") # exports myRFunction
>>   myRFunction()
>> 
>> I could return an environment, such that the call becomes
>> 
>>   attach(juliaUsing("SomeJuliaPackage"))
>>   myJuliaFunction()
>
>I wouldn't use it that way.  I'd write it as
>
> sjp <- juliaUsing("SomeJuliaPackage")
> sjp$myJuliaFunction()
>
>This is similar to the advice to use pkg::foo() rather than
>library(pkg) 
>followed by plain foo() in the code.
>
>Duncan Murdoch
>
>> 
>> But calling juliaUsing(), as it is now, takes care that if a package
>is imported a second time,
>> the first data base is removed via detach().
>> This way, users do not have to worry about calling juliaUsing()
>mutliple times in a script, same
>> as R users don't have to worry about calling library() multiple
>times.
>> If you call the code with attach() multiple times and do not detach,
>you get your screen cluttered with
>> warnings "xxx is masked by xxx".
>> So I would say it would decrease user-friendliness to return an
>environment.
>> I also want to make explicit, that the call to attach
>> occurs only once in my code, after creating the environment:
>> 
>>   envName <- paste0("JuliaConnectoR:", absoluteModulePath)
>>   if (envName %in% search()) {
>>   detach(envName, character.only = TRUE)
>>   }
>>   attach(funenv, name = envName)
>> 
>> This code is only called by juliaImport() and juliaUsing(), which
>aren't called by any other function of
>> the package
>> and are supposed to be called directly by the user.
>> 
>> Stefan
>>   
>> ursprüngliche Nachricht-
>> Von: Duncan Murdoch [murdoch.dun...@gmail.com]
>> An: Dirk Eddelbuettel [e...@debian.org], Ben Bolker
>[bbol...@gmail.com]
>> Kopie: List r-package-devel [r-package-devel@r-project.org]
>> Datum: Mon, 6 Apr 2020 11:00:09 -0400
>> -
>>   
>>   
>>> On 06/04/2020 10:49 a.m., Dirk Eddelbuettel wrote:

 On 6 April 2020 at 08:38, Ben Bolker wrote:
 | Just reply to the CRAN maintainers and explain this situation.
>It¨s
 | slightly buried, but the e-mail you received does say:
 |
 | > If you are fairly certain the rejection is a false positive,
>please reply-all to this
 | > message and explain.

 True, but this misses the "Letter of the law" versus the "Spirit of
>the law".

 It might be worth mentioning that use of attach() is seen, to find
>one poor
 analogy, pretty much like use of global variables these days. "Just
>because
 you could does not mean you should".

 See e.g. one of the first google hits for 'r do not use attach'
>here:

>https://stackoverflow.com/questions/10067680/why-is-it-not-advisable-to-use-attach-in-r-and-what-should-i-use-instead
>>>
>>> I don't have a strong opinion on this: the proposed use seems to be
>no
>>> worse than library() or require(). Those are fine for users to use,
>but
>>> are discouraged in a package. If the attach() never happens without
>an
>>> explicit request from the user (and that's what it sounds like), I'd
>say
>>> it's probably okay.
>>>
>>> However, there is an easy workaround: just return the environment
>>> without attaching it. Then the user has the choice of attaching it,
>or
>>> using it as a prefix when they call the functions in it. So it's not
>as
>>> though this will destroy the utility of the package if Stefan isn't
>>> allowed to call attach().
>>>
>>> Duncan Murdoch
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> h

Re: [R-pkg-devel] About dataset in my own package

[Jeff Newmiller]

Either use the data() function to retrieve it or use the

LazyData: true

line in your DESCRIPTION file.

On April 6, 2020 11:25:21 PM PDT, jared_wood  wrote:
>Dear all，
>
>I have three datasets (drugbank.rda edgar.rda mala.rda) in my package
>and I put them in the document folder which called “data”.
>
> 
>
>And I just use the dataset in the function. However, here comes a note:
>
> 
>
>drugbank_disease_gene: no visible binding for global variable
>
>'drugbank'
>
>  edgar_disease_gene: no visible binding for global variable 'edgar'
>
>  malacards_disease_gene: no visible binding for global variable 'mala'
>
>  Undefined global functions or variables:
>
>drugbank edgar mala
>
> 
>
>It shows that I need to do something else. I am confused and I don’
>know what need to do next.
>
> 
>
>Thanks for your attention. 
>
>| |
>jared_wood
>|
>|
>jared_w...@163.com
>|
>签名由网易邮箱大师定制
>   [[alternative HTML version deleted]]
>
>__
>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] [FWD] [CRAN-pretest-archived] CRAN submission JuliaConnectoR 0.5.0

[Jeff Newmiller]

I did not say "interfere"... I said "problems with consistency". I don't think 
your wholesale import of functions without corresponding help pages is 
consistent with the normal use of R, which will make reading R code written 
with this mechanism in place a painful source of trouble for help forums.

On the other hand, if the code is prefaced with an environment name then there 
will be no expectation that a help page should exist on the part of someone 
reading that code for the first time. (It will be no less obscure, but at least 
it won't be misleading.)

On April 7, 2020 9:40:02 AM PDT, Stefan Lenz IMBI  
wrote:
>Thank you very much for your comment. 
>Could you elaborate how you think that it could interfere with the help
>system?
>I haven't yet connected the Julia help with the R help, as the R help
>system is quite complex and RStudio handles it again differently. So
>it's simply like the functions were declared on the command line. They
>have no help.
>A simply way to print the help for a Julia function, e.g. the function
>"first", is to call
> juliaEval("@doc first")
>This then simply prints the output on the command line.
>
> 
>ursprüngliche Nachricht-
>Von: Jeff Newmiller [jdnew...@dcn.davis.ca.us]
>An: r-package-devel@r-project.org, Duncan Murdoch
>[murdoch.dun...@gmail.com], Stefan Lenz IMBI
>[l...@imbi.uni-freiburg.de]
>Datum: Mon, 06 Apr 2020 10:51:53 -0700
>-
> 
> 
>> One could take the position that the library and require functions
>were a mistake 
>> to begin with and that all contributed packages should be accessed
>using ::... or 
>> one could recognize that these functions are an expected feature of R
>at this 
>> point and then it is not defensible to ban the proposed approach of
>importing 
>> names as Stefan wants to. I don't think it is fair to require this
>higher level of 
>> specificity just because it involves use of attach.
>> 
>> That said, another feature of R packages is the integrated help
>system... 
>> importing Julia functions wholesale may lead to problems with
>consistency in 
>> navigating the help files. IMO it may be justifiable to ban this
>particular 
>> syntactic convenience to maintain some separation in the minds of
>users looking 
>> for help on these new functions, since the syntactic and semantic
>structure of 
>> functions from another language may not align well with normal R
>functions. But I 
>> am not familiar with Julia or Stefan's package or the support it
>brings in this 
>> area... I just disagree with banning a "library" lookalike function
>"just 
>> because" it happens to involve attach.
>> 
>> On April 6, 2020 8:40:12 AM PDT, Duncan Murdoch
> 
>> wrote:
>>>On 06/04/2020 11:25 a.m., Stefan Lenz IMBI wrote:
>>>> Yes, as I wrote earlier, I would like to imitate the behaviour of
>>>loading an R package
>>>> 
>>>> juliaUsing("SomeJuliaPackage") # exports myJuliaFunction
>>>> myJuliaFunction()
>>>> 
>>>> like R:
>>>> 
>>>> library("MyRPackage") # exports myRFunction
>>>> myRFunction()
>>>> 
>>>> I could return an environment, such that the call becomes
>>>> 
>>>> attach(juliaUsing("SomeJuliaPackage"))
>>>> myJuliaFunction()
>>>
>>>I wouldn't use it that way. I'd write it as
>>>
>>> sjp <- juliaUsing("SomeJuliaPackage")
>>> sjp$myJuliaFunction()
>>>
>>>This is similar to the advice to use pkg::foo() rather than
>>>library(pkg) 
>>>followed by plain foo() in the code.
>>>
>>>Duncan Murdoch
>>>
>>>> 
>>>> But calling juliaUsing(), as it is now, takes care that if a
>package
>>>is imported a second time,
>>>> the first data base is removed via detach().
>>>> This way, users do not have to worry about calling juliaUsing()
>>>mutliple times in a script, same
>>>> as R users don't have to worry about calling library() multiple
>>>times.
>>>> If you call the code with attach() multiple times and do not
>detach,
>>>you get your screen cluttered with
>>>> warnings "xxx is masked by xxx".
>>>> So I would say it would decrease user-friendliness to return an
>>>environment.
>>>> I also want to make explicit, that the call to attach
>>>> occurs only o

Re: [R-pkg-devel] Add SystemRequirements of imported package in description file?

[Jeff Newmiller]

AFAIK, no, though if the upstream package cannot (or won't) be implemented 
without that system requirement and it really is a requirement for this package 
then you might want to indicate "libzzz via Package X" just to be clear for 
users. If it isn't a requirement for most of your functionality then you may 
want to use Suggests to alleviate the problem.

On April 9, 2020 12:51:56 AM PDT, Dominik Leutnant  
wrote:
>Hi all,
>
>should “SystemRequirements” of an imported package be listed in the
>description file of a package?
>
>General scenario:
>- Package X imports Package Y.
>- Package Y lists “libzzz” as SystemRequirements.
>
>Should Package X list the SystemRequirements “libzzz” as well?
>(question occurred @ https://github.com/dleutnant/influxdbr/issues/47)
>
>Thank you and happy easter!
>Dominik
>
>
>
>Dr. Dominik Leutnant
>Department of Civil Engineering
>Institute for Infrastucture·Water·Resources·Environment (IWARU)
>WG Urban Hydrology and Water Management
>
>Muenster University of Applied Sciences
>Corrensstr. 25
>FRG-48149 Münster
>Germany
>
>Tel.:  +49 (0) 251/83-65274
>Mail:  leutn...@fh-muenster.de
>Web: https://www.fh-muenster.de/
>
>
>   [[alternative HTML version deleted]]
>
>__
>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] Appropriate keyword in help file.

[Jeff Newmiller]

You can get away with a lot if you are not distributing your package. But I 
usually try to satisfy R CMD check at least.

On April 16, 2020 5:50:04 PM PDT, Rolf Turner  wrote:
>
>On 17/04/20 12:14 pm, Duncan Murdoch wrote:
>
>> On 16/04/2020 8:12 p.m., Rolf Turner wrote:
>>>
>>> I'm writing a package (just for my own use, for the time being at
>least)
>>> that contains a function for estimating the parameters of a
>>> distribution.  The function is essentially a wrapper for fitdistr()
>from
>>> the MASS package.
>>>
>>> When I looked at RShowDoc("KEYWORDS"), I could not find an
>appropriate
>>> keyword to use in the help file for this function.  There's "htest &
>>> Statistical Inference", but that's not right, since this function is
>>> about estimation, not hypothesis testing.  I'd hoped that there'd be
>a
>>> keyword "estimation" (or "point estimation") or something like that,
>but
>>> there isn't.
>>>
>>> I guess I can use "utilities" (???) or "misc", but these seem a bit
>>> unsatisfactory.
>>>
>>> Can anyone suggest a better idea?
>> 
>> Don't use any keyword. When was the last time you searched on one?
>
>
>I have *never* in my life searched on a keyword! :-)
>
>I just thought that it was an Immutable Law of the Universe that a help
>
>file had to have at least one keyword, and that the R Gods would rain 
>fire and brimstone down upon one's head if no keyword was supplied.
>
>In a similar vein:  would the R Gods allow me to make up my own keyword
>
>rather than choosing from those listed by RShowDoc("KEYWORDS")?
>
>Thanks.
>
>cheers,
>
>Rolf

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