[R-pkg-devel] Fwd: [R] a question of etiquette

2020-06-01 Thread R. Mark Sharp
Adelchi, I have a similar situation where I had made all of the typical academic references within the code and documentation for a small but important function my package uses. I was asked by the CRAN reviewers to add the author of that function to the DESCRIPTION Authors@R section. I added

Re: [R-pkg-devel] Fwd: [R] a question of etiquette

2020-06-01 Thread Uwe Ligges
If you copy code, you have to make sure that you can use it under the currrent license of your package, and you have to make sure to declare copright holders and authors. As the code is part of the package now, therese are of course now also copyright holders and authors of your package.

Re: [R-pkg-devel] Warning: S4 exports specified in 'NAMESPACE' but not defined in package

2020-06-01 Thread Wang, Zhu
Thanks Sebastian, and I appreciate the suggestion. Best, Zhu -Original Message- From: R-package-devel On Behalf Of Sebastian Meyer Sent: Monday, June 1, 2020 1:53 PM To: r-package-devel@r-project.org Subject: Re: [R-pkg-devel] Warning: S4 exports specified in 'NAMESPACE' but not

Re: [R-pkg-devel] Warning: S4 exports specified in 'NAMESPACE' but not defined in package

2020-06-01 Thread Sebastian Meyer
This is a new check in R-devel. The NEWS say: > R CMD check etc now warn when a package exports non-existing S4 classes or > methods, also in case of no "methods" presence In your case, the NAMESPACE contains > exportClasses("bujar") > exportMethods("show") but the package neither defines an

Re: [R-pkg-devel] R_MAKEVARS_USER fail to pass down to sub-makes?

2020-06-01 Thread Jan Gorecki
What is the problem exactly? variable name is hardcoded, and variable value is hardcoded as well. How it is possible for the second `system` call to deliver different makevars file than the first one? This is the problem in question. Yes, I haven't thought about Windows. I should have mentioned I

Re: [R-pkg-devel] R_MAKEVARS_USER fail to pass down to sub-makes?

2020-06-01 Thread Jeff Newmiller
Each call to system is independent, so it definitely is a problem. Use Sys.setenv to make changes in environment variables that can be used within system calls. Bash is not involved with the system call on Windows... so your syntax for setting an environment variable is not portable. On June

Re: [R-pkg-devel] R_MAKEVARS_USER fail to pass down to sub-makes?

2020-06-01 Thread Jan Gorecki
Thank you Jeff for your comments. Yet they does not seem to be related. a) Environment variable is created inside `system` command, so env var stays valid for the command. Which is confirmed in the first call that properly shows CFLAGS. b) Syntax passed checkbashisms so I expect no problems due to

Re: [R-pkg-devel] Warning: S4 exports specified in 'NAMESPACE' but not defined in package

2020-06-01 Thread Wang, Zhu
Thanks Max for the very helpful reply. Best, Zhu From: Max Turgeon Sent: Monday, June 1, 2020 11:53 AM To: Wang, Zhu ; R-package-devel@r-project.org Subject: Re: Warning: S4 exports specified in 'NAMESPACE' but not defined in package Good morning, I had a quick look at the source file on

Re: [R-pkg-devel] Warning: S4 exports specified in 'NAMESPACE' but not defined in package

2020-06-01 Thread Max Turgeon
Good morning, I had a quick look at the source file on CRAN, and I don't see any evidence that you're using S4 classes...? Indeed, at the end of your function 'bujar', you are defining the class of the results using "class(x) <- value", which is an S3 idiom. If indeed you're using S3

[R-pkg-devel] Warning: S4 exports specified in 'NAMESPACE' but not defined in package

2020-06-01 Thread Wang, Zhu
Dear All, I received warnings regarding a package: https://cran.r-project.org/web/checks/check_results_bujar.html The warning still occurred after I changed export(bujar, gcv.enet) to export(bujar) in NAMESPACE. The function bujar was defined in the package, so I probably missed something in

Re: [R-pkg-devel] R_MAKEVARS_USER fail to pass down to sub-makes?

2020-06-01 Thread Jeff Newmiller
I don't know anything about the function of that environment variable, but a) system() invokes a child process so environment variable changes made using it will only affect the child process created by that system call. b) The syntax you have used is shell-specific, so does not look portable.

Re: [R-pkg-devel] Workflow for Javascript in package?

2020-06-01 Thread Duncan Murdoch
On 01/06/2020 9:15 a.m., Bryan Hanson wrote: Duncan, I don’t think it is a particularly clever or efficient example, but my package exCon does some of what you describe.  Additional disclaimer: I’m not very good at serious Javascript, and find the scoping rules challenging.  Even so, exCon

Re: [R-pkg-devel] Workflow for Javascript in package?

2020-06-01 Thread Bryan Hanson
Duncan, I don’t think it is a particularly clever or efficient example, but my package exCon does some of what you describe. Additional disclaimer: I’m not very good at serious Javascript, and find the scoping rules challenging. Even so, exCon works pretty well on large data sets. But you

[R-pkg-devel] R_MAKEVARS_USER fail to pass down to sub-makes?

2020-06-01 Thread Jan Gorecki
Hi package devel support, I am trying to use R_MAKEVARS_USER to customize build, rather than .R/Makevars. It is properly displayed from config CFLAGS but during package install it doesn't seem to work. In R-admin in "6.3.3 Customizing package compilation" there is: > Note that these mechanisms

[R-pkg-devel] Workflow for Javascript in package?

2020-06-01 Thread Duncan Murdoch
The rgl package includes a large amount of Javascript source to handle the display of output in browsers using rglwidget(). Currently this is mostly in one big file (inst/htmlwidgets/lib/rglClass/rglClass.src.js), but I'd like to make some improvements: - splitting it into separate files

Re: [R-pkg-devel] *not* re-making package if contents haven't changed

2020-06-01 Thread Georgi Boshnakov
Maybe let 'git' decide which files have changed? Georgi Boshnakov -Original Message- From: R-package-devel On Behalf Of Greg Minshall Sent: 01 June 2020 03:57 To: r-package-devel@r-project.org Subject: [R-pkg-devel] *not* re-making package if contents haven't changed hi. i use emacs