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 th
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.
Best
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
defined
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 S
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
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 1
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
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
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 instead
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 S
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.
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 work
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 may
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 d
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 wit
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 o
16 matches
Mail list logo
