Re: [R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission JuliaConnectoR 0.5.0
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
>>>
Re: [R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission JuliaConnectoR 0.5.0
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
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Error creating union class: object ‘.__C__compMatrix’ not found
Hi, following up on this. Has anybody encountered this issue or could give some insights on it? Is there anything I can do here, except avoiding using Matrix in the union class? Thanks [[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] attach
On 06/04/2020 10:59 a.m., Ben Bolker wrote: Fair enough. I'm going to derail/repurpose this thread to ask a couple of questions about attach(). I have often used with() for situations where I want to evaluate a bunch of expressions with the elements of a parameter vector, e.g. inside a gradient function for deSolve::ode(). However, I have found this very hard to debug because (AFAIK) you can't debug-step through the components of a with() expression. Potential solutions for this include 1. attach(params); on.exit(detach(params)) * this will be flagged by CRAN * I have found some really surprising (to me) precedence issues with this _when used in a package context_ - it looks like the elements in 'params' are found _after_ built-in objects in R?? (I have to take some time to make a MRE of this I suspect what happened is that you had a copy of a built-in function in the global environment. The global environment always comes ahead of attach()'d environments. On the other hand, with() gets it right. You can see this: x <- 123 df <- data.frame(x = 456) with(df, x) #> [1] 456 attach(df) #> The following object is masked _by_ .GlobalEnv: #> #> x x #> [1] 123 detach(df) As for debugging, the setBreakpoint() function can set a breakpoint in the code block in with(). RStudio uses that or some equivalent for setting breakpoints, so it can set breakpoints within the block. If you call debug() on a function and get to a with() statement, you can eventually get to the code within it by hitting "s" (step in) several times. It's fairly scary stepping into .Internal(), but it does eventually get you there. Duncan Murdoch 2. The zeallot package does 'unpacking' as with Python tuples. I was worried about dragging in tidyverse dependencies, but it looks like it doesn't actually Import: anything. This doesn't quite do what I want, as I want to unpack using the names in the object (which makes it look perfect for the attach() solution) Thoughts? On 2020-04-06 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 Dirk __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission JuliaConnectoR 0.5.0
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()
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
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
--
Stefan Lenz
Institut für Medizinische Biometrie und Statistik
Medizinische Fakultät / Universitätsklinikum Freiburg
Postadresse: Stefan-Meier-Str. 26, 79104 Freiburg
Tel.: 0761/203-6670
E-Mail: l...@imbi.uni-freiburg.de
__
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
My case is a little bit different from the use of global variables for data
described in the Stackoverflow post.
I import a data base which contains function names of Julia functions from a
Julia package.
This is analogous to loading a package in R.
The goal is to make it possible to call Julia functions like R functions.
If you call library(...) in R then the functions contained in the package are
also available in the global search path.
In this case it doesn't make sense to use "with".
I am open to suggestions how I can change it to make it better, but the goal is
really to be able to write
juliaUsing("SomeJuliaPackage") # exports myJuliaFunction
myJuliaFunction()
same as you would write
library("MyRPackage") # exports myRFunction
myRFunction()
Best wishes
Stefan
ursprüngliche Nachricht-
Von: Dirk Eddelbuettel [e...@debian.org]
An: Ben Bolker [bbol...@gmail.com]
Kopie: Stefan Lenz IMBI [l...@imbi.uni-freiburg.de], List r-package-devel
[r-package-devel@r-project.org]
Datum: Mon, 6 Apr 2020 09:49:49 -0500
-
>
> 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
>
> Dirk
>
--
Stefan Lenz
Institut für Medizinische Biometrie und Statistik
Medizinische Fakultät / Universitätsklinikum Freiburg
Postadresse: Stefan-Meier-Str. 26, 79104 Freiburg
Tel.: 0761/203-6670
E-Mail: l...@imbi.uni-freiburg.de
__
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
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 https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] attach
Fair enough. I'm going to derail/repurpose this thread to ask a couple of questions about attach(). I have often used with() for situations where I want to evaluate a bunch of expressions with the elements of a parameter vector, e.g. inside a gradient function for deSolve::ode(). However, I have found this very hard to debug because (AFAIK) you can't debug-step through the components of a with() expression. Potential solutions for this include 1. attach(params); on.exit(detach(params)) * this will be flagged by CRAN * I have found some really surprising (to me) precedence issues with this _when used in a package context_ - it looks like the elements in 'params' are found _after_ built-in objects in R?? (I have to take some time to make a MRE of this 2. The zeallot package does 'unpacking' as with Python tuples. I was worried about dragging in tidyverse dependencies, but it looks like it doesn't actually Import: anything. This doesn't quite do what I want, as I want to unpack using the names in the object (which makes it look perfect for the attach() solution) Thoughts? On 2020-04-06 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 > > Dirk > __ 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
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 Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ 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
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. cheers Ben Bolker On Mon, Apr 6, 2020 at 8:28 AM Stefan Lenz IMBI wrote: > > Dear all, > > I just submitted the new package "JuliaConnectoR" to CRAN. > (See https://github.com/stefan-m-lenz/JuliaConnectoR ) > The submission does not pass the automatic checks because of two notes (see > below). > One note is simply that I am a new submitter. > The other note is because of the the use of "attach". > But I am certain that I am using "attach" in the right way. In its > documentation, under "Good practice" , it says, > "In programming, functions should not change the search path unless that is > their purpose." > Here this is exactly the purpose because one of the main functionalities of > the package is to add Julia functions to the search path. > Can anybody help me with this? > Best wishes > Stefan > > ursprüngliche Nachricht- > Von: Stefan Lenz [stefan-m-l...@web.de ] > An: l...@imbi.uni-freiburg.de > Datum: Mon, 6 Apr 2020 14:04:21 +0200 > -- > > > > > >Gesendet: Montag, 06. April 2020 um 13:04 Uhr > >Von: lig...@statistik.tu-dortmund.de > >An: stefan-m-l...@web.de > >Cc: cran-submissi...@r-project.org > >Betreff: [CRAN-pretest-archived] CRAN submission JuliaConnectoR 0.5.0 > >Dear maintainer, > > > >package JuliaConnectoR_0.5.0.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 > >Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64 > >Check: CRAN incoming feasibility, Result: NOTE > >Maintainer: 'Stefan Lenz stefan-m-l...@web.de ' > > > >New submission > > > >Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64 > >Check: R code for possible problems, Result: NOTE > >Found the following calls to attach(): > >File 'JuliaConnectoR/R/importing.R': > >attach(funenv, name = envName) > >See section 'Good practice' in '?attach'. > > > __ > Stefan Lenz > > Institut für Medizinische Biometrie und Statistik > Medizinische Fakultät / Universitätsklinikum Freiburg > > Postadresse: Stefan-Meier-Str. 26, 79104 Freiburg > > Tel.: 0761/203-6670 > E-Mail: l...@imbi.uni-freiburg.de > [[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-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission JuliaConnectoR 0.5.0
Dear all, I just submitted the new package "JuliaConnectoR" to CRAN. (See https://github.com/stefan-m-lenz/JuliaConnectoR ) The submission does not pass the automatic checks because of two notes (see below). One note is simply that I am a new submitter. The other note is because of the the use of "attach". But I am certain that I am using "attach" in the right way. In its documentation, under "Good practice" , it says, "In programming, functions should not change the search path unless that is their purpose." Here this is exactly the purpose because one of the main functionalities of the package is to add Julia functions to the search path. Can anybody help me with this? Best wishes Stefan ursprüngliche Nachricht- Von: Stefan Lenz [stefan-m-l...@web.de ] An: l...@imbi.uni-freiburg.de Datum: Mon, 6 Apr 2020 14:04:21 +0200 -- > > >Gesendet: Montag, 06. April 2020 um 13:04 Uhr >Von: lig...@statistik.tu-dortmund.de >An: stefan-m-l...@web.de >Cc: cran-submissi...@r-project.org >Betreff: [CRAN-pretest-archived] CRAN submission JuliaConnectoR 0.5.0 >Dear maintainer, > >package JuliaConnectoR_0.5.0.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 >Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64 >Check: CRAN incoming feasibility, Result: NOTE >Maintainer: 'Stefan Lenz stefan-m-l...@web.de ' > >New submission > >Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64 >Check: R code for possible problems, Result: NOTE >Found the following calls to attach(): >File 'JuliaConnectoR/R/importing.R': >attach(funenv, name = envName) >See section 'Good practice' in '?attach'. __ Stefan Lenz Institut für Medizinische Biometrie und Statistik Medizinische Fakultät / Universitätsklinikum Freiburg Postadresse: Stefan-Meier-Str. 26, 79104 Freiburg Tel.: 0761/203-6670 E-Mail: l...@imbi.uni-freiburg.de [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
