Re: [R-pkg-devel] About dataset in my own package
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
[R-pkg-devel] RIOT 2020: canceled
After carefully considering the current situation regarding COVID-19, we decided to cancel this year's RIOT workshop. Best regards, Stepan On 25. 02. 20 17:47, Stepan wrote: I hope you don’t mind us using this mailing list for a small advertisement, but we think it is relevant for this group: We'd like to invite you to RIOT 2020 - the 5rd workshop on R Implementation, Optimization and Tooling [1]. It will take place co-located with, and during, useR! 2020 in St. Louis on July 8th. RIOT is an excellent venue for deep technical discussions about R implementations, tools, optimizations and R extensions, and will be very interesting for anyone interested in what’s under the hood of R. The RIOT workshop topics include experience reports and technical details of novel R extensions. For example: ALTREP implementations, approaches to parallelization of R, integration with other (parallel, distributed, ...) computing engines, etc. Regards, Stepan Sindelar, Lukas Stadler (Oracle Labs), Jan Vitek (Northeastern), Alexander Bertram (BeDataDriven) [1] http://riotworkshop.github.io/ __ 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
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 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 f
Re: [R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission JuliaConnectoR 0.5.0
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 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
[R-pkg-devel] Windows specific install error
Hello everyone, My package seems to pass all the CRAN checks for Linux but fails to install on Windows. This is the contents of 00install.out: * installing *source* package 'DiPALM' ... ** using staged installation ** R ** data ** inst ** byte-compile and prepare package for lazy loading Error: .onLoad failed in loadNamespace() for 'S4Vectors', details: call: validObject(.Object) error: invalid class "LLint" object: superclass "integer_OR_LLint" not defined in the environment of the object's class Execution halted ERROR: lazy loading failed for package 'DiPALM' * removing 'd:/RCompile/CRANincoming/R-devel/lib/DiPALM' If I understand the error, it's saying that the CRAN server cannot load the S4Vectors package because one of classes it depends on is not defined. I'm guessing this is a namespace issue? I've taken a few shots at adding directives to my NAMESPACE file but obviously I don't know what I'm doing or maybe the error has nothing to do with my package namespace. Any insight would be greatly appreciated. Thank you! [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Windows specific install error
This is the same as https://stat.ethz.ch/pipermail/r-package-devel/2020q1/005256.html and due I believe to stale packages on the CRAN windows builder; the solution is I believe on the CRAN side. Martin Morgan On 4/7/20, 6:14 PM, "R-package-devel on behalf of Ryan Sartor" wrote: Hello everyone, My package seems to pass all the CRAN checks for Linux but fails to install on Windows. This is the contents of 00install.out: * installing *source* package 'DiPALM' ... ** using staged installation ** R ** data ** inst ** byte-compile and prepare package for lazy loading Error: .onLoad failed in loadNamespace() for 'S4Vectors', details: call: validObject(.Object) error: invalid class "LLint" object: superclass "integer_OR_LLint" not defined in the environment of the object's class Execution halted ERROR: lazy loading failed for package 'DiPALM' * removing 'd:/RCompile/CRANincoming/R-devel/lib/DiPALM' If I understand the error, it's saying that the CRAN server cannot load the S4Vectors package because one of classes it depends on is not defined. I'm guessing this is a namespace issue? I've taken a few shots at adding directives to my NAMESPACE file but obviously I don't know what I'm doing or maybe the error has nothing to do with my package namespace. Any insight would be greatly appreciated. Thank you! [[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
