Re: [Rd] (no) circular dependency
Hi all, Oh right, I wasn't aware there is an r-package-devel list (probably better suited for this question). So I'm getting all sorts of advice, to create a big package and also better to have multiple smaller ones. Sure, all of those are possible, just less attractive. Adrian's suggestion might work (thanks), will have to see. Best, Dmitri On Fri, Apr 8, 2016 at 12:17 AM, William Dunlap wrote: > > but this strategy quickly inflates the number of packages on CRAN. > > CRAN contains 8210 packages today, so I would not worry about > adding an extra one. > > Also, I think several small packages are preferable to one large one > because attaching a big one just to get the one or two functions you > want is also a waste. > > > Bill Dunlap > TIBCO Software > wdunlap tibco.com > > On Thu, Apr 7, 2016 at 1:22 PM, Dmitri Popavenko < > dmitri.popave...@gmail.com> wrote: > >> Hi Thierry, >> >> Thanks for that, the trouble is functions are package specific so moving >> from one package to another could be a solution, but I would rather save >> that as a last resort. >> >> As mentioned, creating a package C with all the common functions could >> also >> be an option, but this strategy quickly inflates the number of packages on >> CRAN. If no other option is possible, that could be the way but I was >> still >> thinking about a more direct solution if possible. >> >> Best, >> Dmitri >> >> On Thu, Apr 7, 2016 at 3:47 PM, Thierry Onkelinx < >> thierry.onkel...@inbo.be> >> wrote: >> >> > Dear Dmitri, >> > >> > If it's only a small number of functions then move them the relevant >> > functions for A to B so that B works without A. Then Import these >> functions >> > from B in A. Hence A depends on B but B is independent of A. >> > >> > It is requires to move a lot of functions than you better create a >> package >> > C with all the common functions. Then A and B import those functions >> from C. >> > >> > Best regards, >> > >> > ir. Thierry Onkelinx >> > Instituut voor natuur- en bosonderzoek / Research Institute for Nature >> and >> > Forest >> > team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance >> > Kliniekstraat 25 >> > 1070 Anderlecht >> > Belgium >> > >> > To call in the statistician after the experiment is done may be no more >> > than asking him to perform a post-mortem examination: he may be able to >> say >> > what the experiment died of. ~ Sir Ronald Aylmer Fisher >> > The plural of anecdote is not data. ~ Roger Brinner >> > The combination of some data and an aching desire for an answer does not >> > ensure that a reasonable answer can be extracted from a given body of >> data. >> > ~ John Tukey >> > >> > 2016-04-06 8:42 GMT+02:00 Dmitri Popavenko > >: >> > >> >> Hello all, >> >> >> >> I would like to build two packages (say A and B), for two different >> >> purposes. >> >> Each of them need one or two functions from the other, which leads to >> the >> >> problem of circular dependency. >> >> >> >> Is there a way for package A to import a function from package B, and >> >> package B to import a function from package A, without arriving to >> >> circular >> >> dependency? >> >> Other suggestions in the archive mention building a third package that >> >> both >> >> A and B should depend on, but this seems less attractive. >> >> >> >> I read about importFrom() into the NAMESPACE file, but I don't know >> how to >> >> relate this with the information in the DESCRIPTION file (other than >> >> adding >> >> each package to the Depends: field). >> >> >> >> Thank you, >> >> Dmitri >> >> >> >> [[alternative HTML version deleted]] >> >> >> >> __ >> >> R-devel@r-project.org mailing list >> >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> >> > >> > >> >> [[alternative HTML version deleted]] >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (no) circular dependency
> but this strategy quickly inflates the number of packages on CRAN. CRAN contains 8210 packages today, so I would not worry about adding an extra one. Also, I think several small packages are preferable to one large one because attaching a big one just to get the one or two functions you want is also a waste. Bill Dunlap TIBCO Software wdunlap tibco.com On Thu, Apr 7, 2016 at 1:22 PM, Dmitri Popavenko wrote: > Hi Thierry, > > Thanks for that, the trouble is functions are package specific so moving > from one package to another could be a solution, but I would rather save > that as a last resort. > > As mentioned, creating a package C with all the common functions could also > be an option, but this strategy quickly inflates the number of packages on > CRAN. If no other option is possible, that could be the way but I was still > thinking about a more direct solution if possible. > > Best, > Dmitri > > On Thu, Apr 7, 2016 at 3:47 PM, Thierry Onkelinx > > wrote: > > > Dear Dmitri, > > > > If it's only a small number of functions then move them the relevant > > functions for A to B so that B works without A. Then Import these > functions > > from B in A. Hence A depends on B but B is independent of A. > > > > It is requires to move a lot of functions than you better create a > package > > C with all the common functions. Then A and B import those functions > from C. > > > > Best regards, > > > > ir. Thierry Onkelinx > > Instituut voor natuur- en bosonderzoek / Research Institute for Nature > and > > Forest > > team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance > > Kliniekstraat 25 > > 1070 Anderlecht > > Belgium > > > > To call in the statistician after the experiment is done may be no more > > than asking him to perform a post-mortem examination: he may be able to > say > > what the experiment died of. ~ Sir Ronald Aylmer Fisher > > The plural of anecdote is not data. ~ Roger Brinner > > The combination of some data and an aching desire for an answer does not > > ensure that a reasonable answer can be extracted from a given body of > data. > > ~ John Tukey > > > > 2016-04-06 8:42 GMT+02:00 Dmitri Popavenko : > > > >> Hello all, > >> > >> I would like to build two packages (say A and B), for two different > >> purposes. > >> Each of them need one or two functions from the other, which leads to > the > >> problem of circular dependency. > >> > >> Is there a way for package A to import a function from package B, and > >> package B to import a function from package A, without arriving to > >> circular > >> dependency? > >> Other suggestions in the archive mention building a third package that > >> both > >> A and B should depend on, but this seems less attractive. > >> > >> I read about importFrom() into the NAMESPACE file, but I don't know how > to > >> relate this with the information in the DESCRIPTION file (other than > >> adding > >> each package to the Depends: field). > >> > >> Thank you, > >> Dmitri > >> > >> [[alternative HTML version deleted]] > >> > >> __ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > >> > > > > > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (no) circular dependency
At the risk of stating the over-obvious: there's also the option of creating just a single package containing all functions. None of the functions that create the interdependencies need to be exported that way. Btw, his question is probably better at home at the r-package-devel list. Best, M On Thu, Apr 7, 2016, 22:24 Dmitri Popavenko wrote: > Hi Thierry, > > Thanks for that, the trouble is functions are package specific so moving > from one package to another could be a solution, but I would rather save > that as a last resort. > > As mentioned, creating a package C with all the common functions could also > be an option, but this strategy quickly inflates the number of packages on > CRAN. If no other option is possible, that could be the way but I was still > thinking about a more direct solution if possible. > > Best, > Dmitri > > On Thu, Apr 7, 2016 at 3:47 PM, Thierry Onkelinx > > wrote: > > > Dear Dmitri, > > > > If it's only a small number of functions then move them the relevant > > functions for A to B so that B works without A. Then Import these > functions > > from B in A. Hence A depends on B but B is independent of A. > > > > It is requires to move a lot of functions than you better create a > package > > C with all the common functions. Then A and B import those functions > from C. > > > > Best regards, > > > > ir. Thierry Onkelinx > > Instituut voor natuur- en bosonderzoek / Research Institute for Nature > and > > Forest > > team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance > > Kliniekstraat 25 > > 1070 Anderlecht > > Belgium > > > > To call in the statistician after the experiment is done may be no more > > than asking him to perform a post-mortem examination: he may be able to > say > > what the experiment died of. ~ Sir Ronald Aylmer Fisher > > The plural of anecdote is not data. ~ Roger Brinner > > The combination of some data and an aching desire for an answer does not > > ensure that a reasonable answer can be extracted from a given body of > data. > > ~ John Tukey > > > > 2016-04-06 8:42 GMT+02:00 Dmitri Popavenko : > > > >> Hello all, > >> > >> I would like to build two packages (say A and B), for two different > >> purposes. > >> Each of them need one or two functions from the other, which leads to > the > >> problem of circular dependency. > >> > >> Is there a way for package A to import a function from package B, and > >> package B to import a function from package A, without arriving to > >> circular > >> dependency? > >> Other suggestions in the archive mention building a third package that > >> both > >> A and B should depend on, but this seems less attractive. > >> > >> I read about importFrom() into the NAMESPACE file, but I don't know how > to > >> relate this with the information in the DESCRIPTION file (other than > >> adding > >> each package to the Depends: field). > >> > >> Thank you, > >> Dmitri > >> > >> [[alternative HTML version deleted]] > >> > >> __ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > >> > > > > > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (no) circular dependency
Hi Dmitri,
I was thinking about something similar for my packages. There might be
other (more clever) ways, but one way is to:
- make package A dependent on package B (so that the namespace of B is
automatically available when loading package A)
- make package B "Suggest" package A (not "Depend" which leads to circular
dependency), and that if I am not mistaken will lead to automatically
install package A when package B is installed
- use requireNamespace("A") inside the function(s) of package B which uses
functions of package A
- directly use A::foo() inside those functions
Didn't try this yet, but in theory it should work (I might try this
approach myself actually). I would also be curious if there are more clever
ways to deal with this.
I hope it helps,
Adrian
On Thu, Apr 7, 2016 at 11:22 PM, Dmitri Popavenko <
dmitri.popave...@gmail.com> wrote:
> Hi Thierry,
>
> Thanks for that, the trouble is functions are package specific so moving
> from one package to another could be a solution, but I would rather save
> that as a last resort.
>
> As mentioned, creating a package C with all the common functions could also
> be an option, but this strategy quickly inflates the number of packages on
> CRAN. If no other option is possible, that could be the way but I was still
> thinking about a more direct solution if possible.
>
> Best,
> Dmitri
>
> On Thu, Apr 7, 2016 at 3:47 PM, Thierry Onkelinx >
> wrote:
>
> > Dear Dmitri,
> >
> > If it's only a small number of functions then move them the relevant
> > functions for A to B so that B works without A. Then Import these
> functions
> > from B in A. Hence A depends on B but B is independent of A.
> >
> > It is requires to move a lot of functions than you better create a
> package
> > C with all the common functions. Then A and B import those functions
> from C.
> >
> > Best regards,
> >
> > ir. Thierry Onkelinx
> > Instituut voor natuur- en bosonderzoek / Research Institute for Nature
> and
> > Forest
> > team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance
> > Kliniekstraat 25
> > 1070 Anderlecht
> > Belgium
> >
> > To call in the statistician after the experiment is done may be no more
> > than asking him to perform a post-mortem examination: he may be able to
> say
> > what the experiment died of. ~ Sir Ronald Aylmer Fisher
> > The plural of anecdote is not data. ~ Roger Brinner
> > The combination of some data and an aching desire for an answer does not
> > ensure that a reasonable answer can be extracted from a given body of
> data.
> > ~ John Tukey
> >
> > 2016-04-06 8:42 GMT+02:00 Dmitri Popavenko :
> >
> >> Hello all,
> >>
> >> I would like to build two packages (say A and B), for two different
> >> purposes.
> >> Each of them need one or two functions from the other, which leads to
> the
> >> problem of circular dependency.
> >>
> >> Is there a way for package A to import a function from package B, and
> >> package B to import a function from package A, without arriving to
> >> circular
> >> dependency?
> >> Other suggestions in the archive mention building a third package that
> >> both
> >> A and B should depend on, but this seems less attractive.
> >>
> >> I read about importFrom() into the NAMESPACE file, but I don't know how
> to
> >> relate this with the information in the DESCRIPTION file (other than
> >> adding
> >> each package to the Depends: field).
> >>
> >> Thank you,
> >> Dmitri
> >>
> >> [[alternative HTML version deleted]]
> >>
> >> __
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >
> >
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Adrian Dusa
University of Bucharest
Romanian Social Data Archive
Soseaua Panduri nr.90
050663 Bucharest sector 5
Romania
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (no) circular dependency
Hi Thierry, Thanks for that, the trouble is functions are package specific so moving from one package to another could be a solution, but I would rather save that as a last resort. As mentioned, creating a package C with all the common functions could also be an option, but this strategy quickly inflates the number of packages on CRAN. If no other option is possible, that could be the way but I was still thinking about a more direct solution if possible. Best, Dmitri On Thu, Apr 7, 2016 at 3:47 PM, Thierry Onkelinx wrote: > Dear Dmitri, > > If it's only a small number of functions then move them the relevant > functions for A to B so that B works without A. Then Import these functions > from B in A. Hence A depends on B but B is independent of A. > > It is requires to move a lot of functions than you better create a package > C with all the common functions. Then A and B import those functions from C. > > Best regards, > > ir. Thierry Onkelinx > Instituut voor natuur- en bosonderzoek / Research Institute for Nature and > Forest > team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance > Kliniekstraat 25 > 1070 Anderlecht > Belgium > > To call in the statistician after the experiment is done may be no more > than asking him to perform a post-mortem examination: he may be able to say > what the experiment died of. ~ Sir Ronald Aylmer Fisher > The plural of anecdote is not data. ~ Roger Brinner > The combination of some data and an aching desire for an answer does not > ensure that a reasonable answer can be extracted from a given body of data. > ~ John Tukey > > 2016-04-06 8:42 GMT+02:00 Dmitri Popavenko : > >> Hello all, >> >> I would like to build two packages (say A and B), for two different >> purposes. >> Each of them need one or two functions from the other, which leads to the >> problem of circular dependency. >> >> Is there a way for package A to import a function from package B, and >> package B to import a function from package A, without arriving to >> circular >> dependency? >> Other suggestions in the archive mention building a third package that >> both >> A and B should depend on, but this seems less attractive. >> >> I read about importFrom() into the NAMESPACE file, but I don't know how to >> relate this with the information in the DESCRIPTION file (other than >> adding >> each package to the Depends: field). >> >> Thank you, >> Dmitri >> >> [[alternative HTML version deleted]] >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [PATCH] fix CHECK_this_length in sprintf.c
> Matthew Fowles Kulukundis
> on Thu, 7 Apr 2016 11:21:56 -0400 writes:
> Martin~
> Sorry about the bad patch. I work on C++ at Google. We built a check for
> clang-tidy that identifies errors of this form and discovered the error
> here as part of our search. I am just trying to be a good citizen and
> upstream a fix, but I must have gotten sloppy as I was doing a bunch of
> these.
Thank you, Matt, for the extra context... indeed the sloppyness was not a
big deal..
> Thanks for fixing it and finding the a test for it,
> I actually had no idea how to trigger this codepath and have never used R.
I see. But note that you misunderstood (probably my bad
English):
I did *NOT* find a test for it (and showed a case that did not
work as test, as it does not trigger an error [remember the
macro is CHECK_..() and actually shouled produce a useful error
message in a -- yet to find -- test case.
> If you are curious, the upstream check for clang-tidy is
> http://reviews.llvm.org/D18766
> You may consider running some of the other clang-tidy checks on your
source
> base, they will likely find other bugs.
Thank you!
At the moment, I'm too overloaed with other duties / todos.
But it is good, to have this available, and other R-devel
readers may want to help the R core team by finding and patching
(or at least reporting) such bugs.
Martin
> Cheers,
> Matt
> On Thu, Apr 7, 2016 at 6:46 AM, Martin Maechler
> wrote:
>> > Matthew Fowles Kulukundis
>> > on Tue, 5 Apr 2016 11:17:30 -0400 writes:
>>
>> > All~
>> > CHECK_this_length macro expands to multiple statements making it
>> unsafe to
>> > use in a single line `if` statement (as is happening near line
>> 335). This
>> > fixes the macro using the standard `do { } while (0)` macro trick.
>>
>> yes, but you forgot the closing '}' ... so you could not even
>> have compiled R after applying your patch.
>>
>> Also, it would be nice to contrive a minimal example where the
>> change makes a difference. This "fails" to trigger :
>>
>>
>> as.double.foo <- function(x) x[FALSE]
>> x <- structure(3, class="foo")
>> as.numeric(x) # numeric(0)
>>
>> sprintf("%d !", x)# "3 !" instead of giving an error
>>
>>
>> Thank you, Matt, in any case; this (with the "{" !) has now gone
>> into the source.
>>
>> Martin
>>
>> > Matt
>> > x[DELETED ATTACHMENT external: r-sprintf.patch, text/x-patch]
>> > __
>> > R-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>>
> [[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (no) circular dependency
Dear Dmitri, If it's only a small number of functions then move them the relevant functions for A to B so that B works without A. Then Import these functions from B in A. Hence A depends on B but B is independent of A. It is requires to move a lot of functions than you better create a package C with all the common functions. Then A and B import those functions from C. Best regards, ir. Thierry Onkelinx Instituut voor natuur- en bosonderzoek / Research Institute for Nature and Forest team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance Kliniekstraat 25 1070 Anderlecht Belgium To call in the statistician after the experiment is done may be no more than asking him to perform a post-mortem examination: he may be able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher The plural of anecdote is not data. ~ Roger Brinner The combination of some data and an aching desire for an answer does not ensure that a reasonable answer can be extracted from a given body of data. ~ John Tukey 2016-04-06 8:42 GMT+02:00 Dmitri Popavenko : > Hello all, > > I would like to build two packages (say A and B), for two different > purposes. > Each of them need one or two functions from the other, which leads to the > problem of circular dependency. > > Is there a way for package A to import a function from package B, and > package B to import a function from package A, without arriving to circular > dependency? > Other suggestions in the archive mention building a third package that both > A and B should depend on, but this seems less attractive. > > I read about importFrom() into the NAMESPACE file, but I don't know how to > relate this with the information in the DESCRIPTION file (other than adding > each package to the Depends: field). > > Thank you, > Dmitri > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [PATCH] fix CHECK_this_length in sprintf.c
> Matthew Fowles Kulukundis
> on Tue, 5 Apr 2016 11:17:30 -0400 writes:
> All~
> CHECK_this_length macro expands to multiple statements making it unsafe to
> use in a single line `if` statement (as is happening near line 335). This
> fixes the macro using the standard `do { } while (0)` macro trick.
yes, but you forgot the closing '}' ... so you could not even
have compiled R after applying your patch.
Also, it would be nice to contrive a minimal example where the
change makes a difference. This "fails" to trigger :
as.double.foo <- function(x) x[FALSE]
x <- structure(3, class="foo")
as.numeric(x) # numeric(0)
sprintf("%d !", x)# "3 !" instead of giving an error
Thank you, Matt, in any case; this (with the "{" !) has now gone
into the source.
Martin
> Matt
> x[DELETED ATTACHMENT external: r-sprintf.patch, text/x-patch]
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Assignment operator and deep copy for calling C functions
This is discussed in the "Writing R Extensions" manual section 5.9.10:
Named objects and copying.
.Call does not copy its arguments and it is not safe to modify them, as
you have found, since multiple symbols may refer to the same object. If
you are going to modify an argument to .Call you should take a deep
copy with "duplicate" first, and your function should return the
modified copy.
It is probably also worth mentioning Rcpp, which provides a friendlier
interface to R than the C API. In Rcpp you use clone() to force a deep
copy.
Martyn
On Tue, 2016-04-05 at 15:38 +, Thorsten R wrote:
> Hi All,
>
> i have a problem in understanding what the assignment operator '<-
> ' really is doing.
> If i create two numeric arrays in R and copy one into the other with
> '<-' and
> afterwards change one array by calling a C function, both arrays are
> changed!
>
> The problem I am facing can easily be seen in the following example:
> (The following R code and the C function is attached and the C
> function can be compiled with R CMD SHLIB test.c.)
>
> First include the c function:
> dyn.load("test.so")
>
> Let's start with 2 arrays:
> a <- rep(0, 5)
> b <- rep(1, 5)
>
> Now print the memory addresses:
> print(sprintf("a: %sb: %s", tracemem(a), tracemem(b) ))
> [1] "a: <0x29d34e0>b: <0x29946e0>"
>
> oky, they are different! Now copy a into b and print again the
> addresses:
> b <- a
> print(sprintf("a: %sb: %s", tracemem(a), tracemem(b) ))
> [1] "a: <0x29d34e0>b: <0x29d34e0>"
>
> Ugh they are the same. If I now call my C function, which writes
> 0,1,2,3,4 into an array of 5 doubles,
> of course 'both' arrays are changed:
> .Call("test", b)
> print( cbind(a,b) )
> a b
> [1,] 0 0
> [2,] 1 1
> [3,] 2 2
> [4,] 3 3
> [5,] 4 4
>
>
> If i just change one element of b instead of calling the c function,
> then a full copy of b is made:
> a <- rep(0, 5)
> b <- rep(1, 5)
> print(sprintf("a: %sb: %s", tracemem(a), tracemem(b) ))
> [1] "a: <0x2994b58>b: <0x2912ff8>"
>
> b <- a
> print(sprintf("a: %sb: %s", tracemem(a), tracemem(b) ))
> [1] "a: <0x2994b58>b: <0x2994b58>"
>
> b[1] <- 5
> print(sprintf("a: %sb: %s", tracemem(a), tracemem(b) ))
> "a: <0x2994b58>b: <0x29134d8>"
>
> print( cbind(a,b) )
> a b
> [1,] 0 5
> [2,] 0 0
> [3,] 0 0
> [4,] 0 0
> [5,] 0 0
>
>
> So what is happening here? What is the 'right' way to ensure a deep
> copy before using Call?
> I am currently using a for loop and copy every single element.
>
> Thanks!
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel---
This message and its attachments are strictly confidenti...{{dropped:8}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
