Hi,
Field RdMacros was introduced in file DESCRIPTION to allow users to import
LaTeX-like macros from other packages.
Currently 'R CMD Check --as-cran' gives a NOTE:
> Unknown, possibly mis-spelled, field in DESCRIPTION:
> ?RdMacros?
A small package demonstrating this is available at
http://www.maths.manchester.ac.uk/~gb/testRdMacro_0.0.2.tar.gz
(and this is the source:
http://www.maths.manchester.ac.uk/~gb/testRdMacro_src.tar.gz).
I get the message on my Linux and Windows machines and on win-builder.
Same problem is on the FAQ at
https://github.com/gaborcsardi/argufy#frequently-asked-questions
but with no indication if it has been reported.
Thanks,
Georgi
--
Dr Georgi Boshnakov tel: (+44) (0)161 306 3684
School of Mathematics fax: (+44) (0)161 306 3669
Alan Turing Building 1.125
The University of Manchester email: Georgi.Boshnakov at manchester.ac.uk
Oxford Road
Manchester M13 9PL
UK
________________________________________
From: R-devel [r-devel-bounces at r-project.org] on behalf of r-devel-request at
r-project.org [r-devel-request at r-project.org]
Sent: 09 April 2016 11:00
To: r-devel at r-project.org
Subject: R-devel Digest, Vol 158, Issue 6
Send R-devel mailing list submissions to
r-devel at r-project.org
To subscribe or unsubscribe via the World Wide Web, visit
https://stat.ethz.ch/mailman/listinfo/r-devel
or, via email, send a message with subject or body 'help' to
r-devel-request at r-project.org
You can reach the person managing the list at
r-devel-owner at r-project.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of R-devel digest..."
Today's Topics:
1. Re: [PATCH] fix CHECK_this_length in sprintf.c
(Matthew Fowles Kulukundis)
2. Re: (no) circular dependency (Adrian Du?a)
3. Re: (no) circular dependency (Mark van der Loo)
4. Re: (no) circular dependency (Dmitri Popavenko)
5. Re: (no) circular dependency (Gabriel Becker)
6. PR# for match.arg(arg) (Suharto Anggono Suharto Anggono)
7. Re: (no) circular dependency (Gregory Warnes)
8. Re: Under Windows, Rgui and Rterm crash if one tries to close
the graphic device while identify or locator are running
(Duncan Murdoch)
9. Re: (no) circular dependency (Adrian Du?a)
10. Re: (no) circular dependency (Hadley Wickham)
11. Re: (no) circular dependency (Adrian Du?a)
----------------------------------------------------------------------
Message: 1
Date: Thu, 7 Apr 2016 11:21:56 -0400
From: Matthew Fowles Kulukundis <matt.fowles at gmail.com>
To: Martin Maechler <maechler at stat.math.ethz.ch>
Cc: r-devel at r-project.org
Subject: Re: [Rd] [PATCH] fix CHECK_this_length in sprintf.c
Message-ID:
<CAApERuYJ3zfLTc=H3LJkqV4Nx1U_s5=1iJE4hDH1iXbWRBaL3A at
mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
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.
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.
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.
Cheers,
Matt
On Thu, Apr 7, 2016 at 6:46 AM, Martin Maechler <maechler at
stat.math.ethz.ch>
wrote:
> >>>>> Matthew Fowles Kulukundis <matt.fowles at
gmail.com>
> >>>>> 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 at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
------------------------------
Message: 2
Date: Fri, 8 Apr 2016 14:59:28 +0300
From: Adrian Du?a <dusa.adrian at unibuc.ro>
To: Mark van der Loo <mark.vanderloo at gmail.com>
Cc: r-devel <r-devel at r-project.org>
Subject: Re: [Rd] (no) circular dependency
Message-ID:
<CAJ=0CtB83wvrWkyVy05ZXyGfAt9hiMnU+QpD=_h7E62dUe=iPg at
mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi Mark,
Uhm... sometimes this is not always possible.
For example I have a package QCA which produces truth tables (all
combinations of presence / absence of causal conditions), and it uses the
venn package to draw a Venn diagram.
It is debatable if one should assimilate the "venn" package into the
QCA
package (other people might want Venn diagrams but not necessarily the
other QCA functions).
On the other hand, the package venn would like to use the QCA package to
demonstrate its abilities to plot Venn diagrams based on truth tables
produced by the QCA package. Both have very different purposes, yet both
use functions from each other.
So I'm with Bill Dunlap here that several smaller packages are preferable
to one larger one, but on the other hand I can't separate those functions
into a third package: the truth table production is very specific to the
QCA package, while plotting Venn diagrams is very specific to the venn
package. I don't see how to separate those functions from their main
packages and create a third one that each would depend on.
This is just an example, there could be others as well, reason for which I
am (still) looking for a solution to:
- preserve the current functionalities in packages A and B (to follow
Dmitri's original post)
- be able to use functions from each other
- yet avoid circular dependency
I hope this explains it,
Adrian
On Thu, Apr 7, 2016 at 11:36 PM, Mark van der Loo <mark.vanderloo at
gmail.com>
wrote:
> 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 <dmitri.popavenko at
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.onkelinx at 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 <dmitri.popavenko at
gmail.com
>> >:
>> >
>> >> 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 at r-project.org mailing list
>> >> https://stat.ethz.ch/mailman/listinfo/r-devel
>> >>
>> >
>> >
>>
>> [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-devel at 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]]
------------------------------
Message: 3
Date: Fri, 08 Apr 2016 12:03:32 +0000
From: Mark van der Loo <mark.vanderloo at gmail.com>
To: Adrian Du?a <dusa.adrian at unibuc.ro>
Cc: r-devel <r-devel at r-project.org>
Subject: Re: [Rd] (no) circular dependency
Message-ID:
<CAOKDuOg93kDmgjMTPwanWgyqeUk1CESQ3dYK_QiC+FEOx8w0MA at
mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Well, I'm not saying that Dmitri _should_ do it. I merely mention it as an
option that I think is worth thinking about -- it is easy to overlook the
obvious :-). Since we have no further info on the package's structure we
can't be sure..
Op vr 8 apr. 2016 om 13:59 schreef Adrian Du?a <dusa.adrian at unibuc.ro>:
> Hi Mark,
>
> Uhm... sometimes this is not always possible.
> For example I have a package QCA which produces truth tables (all
> combinations of presence / absence of causal conditions), and it uses the
> venn package to draw a Venn diagram.
> It is debatable if one should assimilate the "venn" package into
the QCA
> package (other people might want Venn diagrams but not necessarily the
> other QCA functions).
>
> On the other hand, the package venn would like to use the QCA package to
> demonstrate its abilities to plot Venn diagrams based on truth tables
> produced by the QCA package. Both have very different purposes, yet both
> use functions from each other.
>
> So I'm with Bill Dunlap here that several smaller packages are
preferable
> to one larger one, but on the other hand I can't separate those
functions
> into a third package: the truth table production is very specific to the
> QCA package, while plotting Venn diagrams is very specific to the venn
> package. I don't see how to separate those functions from their main
> packages and create a third one that each would depend on.
>
> This is just an example, there could be others as well, reason for which I
> am (still) looking for a solution to:
> - preserve the current functionalities in packages A and B (to follow
> Dmitri's original post)
> - be able to use functions from each other
> - yet avoid circular dependency
>
> I hope this explains it,
> Adrian
>
>
> On Thu, Apr 7, 2016 at 11:36 PM, Mark van der Loo <
> mark.vanderloo at gmail.com> wrote:
>
>> 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 <dmitri.popavenko at
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.onkelinx at 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
<dmitri.popavenko at gmail.com
>>> >:
>>> >
>>> >> 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 at r-project.org mailing list
>>> >> https://stat.ethz.ch/mailman/listinfo/r-devel
>>> >>
>>> >
>>> >
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> ______________________________________________
>>> R-devel at 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]]
------------------------------
Message: 4
Date: Fri, 8 Apr 2016 17:36:10 +0300
From: Dmitri Popavenko <dmitri.popavenko at gmail.com>
To: Mark van der Loo <mark.vanderloo at gmail.com>, William Dunlap
<wdunlap at tibco.com>
Cc: Adrian Du?a <dusa.adrian at unibuc.ro>, r-devel
<r-devel at r-project.org>
Subject: Re: [Rd] (no) circular dependency
Message-ID:
<CAJL_pojJDwU9-e3faZTgQ2BpRAoB1MhzAVZ_7Tz4vYJ7bXkKqA at
mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Thanks all, I don't know either (for the moment).
It's all in the design phase still. Generally, I would also like to keep
specific functions in specific packages, if at all possible.
On Fri, Apr 8, 2016 at 3:03 PM, Mark van der Loo <mark.vanderloo at
gmail.com>
wrote:
> Well, I'm not saying that Dmitri _should_ do it. I merely mention it as
an
> option that I think is worth thinking about -- it is easy to overlook the
> obvious :-). Since we have no further info on the package's structure
we
> can't be sure..
>
>
>
>
> Op vr 8 apr. 2016 om 13:59 schreef Adrian Du?a <dusa.adrian at
unibuc.ro>:
>
>> Hi Mark,
>>
>> Uhm... sometimes this is not always possible.
>> For example I have a package QCA which produces truth tables (all
>> combinations of presence / absence of causal conditions), and it uses
the
>> venn package to draw a Venn diagram.
>> It is debatable if one should assimilate the "venn" package
into the QCA
>> package (other people might want Venn diagrams but not necessarily the
>> other QCA functions).
>>
>> On the other hand, the package venn would like to use the QCA package
to
>> demonstrate its abilities to plot Venn diagrams based on truth tables
>> produced by the QCA package. Both have very different purposes, yet
both
>> use functions from each other.
>>
>> So I'm with Bill Dunlap here that several smaller packages are
preferable
>> to one larger one, but on the other hand I can't separate those
functions
>> into a third package: the truth table production is very specific to
the
>> QCA package, while plotting Venn diagrams is very specific to the venn
>> package. I don't see how to separate those functions from their
main
>> packages and create a third one that each would depend on.
>>
>> This is just an example, there could be others as well, reason for
which
>> I am (still) looking for a solution to:
>> - preserve the current functionalities in packages A and B (to follow
>> Dmitri's original post)
>> - be able to use functions from each other
>> - yet avoid circular dependency
>>
>> I hope this explains it,
>> Adrian
>>
>>
>> On Thu, Apr 7, 2016 at 11:36 PM, Mark van der Loo <
>> mark.vanderloo at gmail.com> wrote:
>>
>>> 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 <dmitri.popavenko at
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.onkelinx at 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 <
>>>> dmitri.popavenko at gmail.com>:
>>>> >
>>>> >> 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 at r-project.org mailing list
>>>> >> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>> >>
>>>> >
>>>> >
>>>>
>>>> [[alternative HTML version deleted]]
>>>>
>>>> ______________________________________________
>>>> R-devel at 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]]
------------------------------
Message: 5
Date: Fri, 8 Apr 2016 08:37:12 -0700
From: Gabriel Becker <gmbecker at ucdavis.edu>
To: Dmitri Popavenko <dmitri.popavenko at gmail.com>
Cc: Adrian Du?a <dusa.adrian at unibuc.ro>, r-devel
<r-devel at r-project.org>
Subject: Re: [Rd] (no) circular dependency
Message-ID:
<CADwqtCP9Cmo6xy1zw86=k-SZckUUM5n_0qL8HbwcG5SyRTCQrw at
mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Another, perhaps slightly off the wall reframing of the 3-package
possibility:
Have packages B, a, and UserFacingA, as follows
*a* contains all the functionality in your A package that
*does not depend on B*
*B* *imports from* *a* and is essentially unchanged
*UserFacingA* *Depends* on *a* and *imports from* *B*, it implements all
functionality from your package A that *does depend on* *B*, and gets the
rest from package *a*
Users, then would only ever install or load B and UserFacingA. They
wouldn't need to care much,if at all, about package a.
~G
On Fri, Apr 8, 2016 at 7:36 AM, Dmitri Popavenko <dmitri.popavenko at
gmail.com> wrote:
> Thanks all, I don't know either (for the moment).
> It's all in the design phase still. Generally, I would also like to
keep
> specific functions in specific packages, if at all possible.
>
> On Fri, Apr 8, 2016 at 3:03 PM, Mark van der Loo <mark.vanderloo at
gmail.com
> >
> wrote:
>
> > Well, I'm not saying that Dmitri _should_ do it. I merely mention
it as
> an
> > option that I think is worth thinking about -- it is easy to overlook
the
> > obvious :-). Since we have no further info on the package's
structure we
> > can't be sure..
> >
> >
> >
> >
> > Op vr 8 apr. 2016 om 13:59 schreef Adrian Du?a <dusa.adrian at
unibuc.ro>:
> >
> >> Hi Mark,
> >>
> >> Uhm... sometimes this is not always possible.
> >> For example I have a package QCA which produces truth tables (all
> >> combinations of presence / absence of causal conditions), and it
uses
> the
> >> venn package to draw a Venn diagram.
> >> It is debatable if one should assimilate the "venn"
package into the QCA
> >> package (other people might want Venn diagrams but not necessarily
the
> >> other QCA functions).
> >>
> >> On the other hand, the package venn would like to use the QCA
package to
> >> demonstrate its abilities to plot Venn diagrams based on truth
tables
> >> produced by the QCA package. Both have very different purposes,
yet both
> >> use functions from each other.
> >>
> >> So I'm with Bill Dunlap here that several smaller packages are
> preferable
> >> to one larger one, but on the other hand I can't separate
those
> functions
> >> into a third package: the truth table production is very specific
to the
> >> QCA package, while plotting Venn diagrams is very specific to the
venn
> >> package. I don't see how to separate those functions from
their main
> >> packages and create a third one that each would depend on.
> >>
> >> This is just an example, there could be others as well, reason for
which
> >> I am (still) looking for a solution to:
> >> - preserve the current functionalities in packages A and B (to
follow
> >> Dmitri's original post)
> >> - be able to use functions from each other
> >> - yet avoid circular dependency
> >>
> >> I hope this explains it,
> >> Adrian
> >>
> >>
> >> On Thu, Apr 7, 2016 at 11:36 PM, Mark van der Loo <
> >> mark.vanderloo at gmail.com> wrote:
> >>
> >>> 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 <
> dmitri.popavenko at 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.onkelinx at 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 <
> >>>> dmitri.popavenko at gmail.com>:
> >>>> >
> >>>> >> 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 at r-project.org mailing list
> >>>> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>>> >>
> >>>> >
> >>>> >
> >>>>
> >>>> [[alternative HTML version deleted]]
> >>>>
> >>>> ______________________________________________
> >>>> R-devel at 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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Gabriel Becker, PhD
Associate Scientist (Bioinformatics)
Genentech Research
[[alternative HTML version deleted]]
------------------------------
Message: 6
Date: Fri, 8 Apr 2016 16:39:47 +0000 (UTC)
From: Suharto Anggono Suharto Anggono <suharto_anggono at yahoo.com>
To: <R-devel at r-project.org>
Subject: [Rd] PR# for match.arg(arg)
Message-ID:
<124284635.225797.1460133587830.JavaMail.yahoo at mail.yahoo.com>
Content-Type: text/plain; charset=UTF-8
In "R News", in "Changes in R 3.3.0", in "New
Features", a news item is
match.arg(arg) (the one-argument case) is faster; so is sort.int(). (PR#16640)
While it was motivated by speeding up tapply, it is in a separate bug number:
16652 (https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16652).
------------------------------
Message: 7
Date: Fri, 8 Apr 2016 13:04:20 -0400
From: Gregory Warnes <greg at warnes.net>
To: Gabriel Becker <gmbecker at ucdavis.edu>
Cc: Adrian Du?a <dusa.adrian at unibuc.ro>, r-devel
<r-devel at r-project.org>
Subject: Re: [Rd] (no) circular dependency
Message-ID: <AE89F9A5-A0C3-4046-8A7B-617987541804 at warnes.net>
Content-Type: text/plain; charset="UTF-8"
A third possibility, which I use in my gtools and gdata packages, is to use
soft-links to create a copy of the relevant functions from one package in the
other. I make sure these functions are *not* exported, so no conflicts are
created, and the use of soft-links mean the code never gets out of sync.
-Greg
--
Change your thoughts and you change the world.
--Dr. Norman Vincent Peale
> On Apr 8, 2016, at 11:37 AM, Gabriel Becker <gmbecker at ucdavis.edu>
wrote:
>
> Another, perhaps slightly off the wall reframing of the 3-package
> possibility:
>
> Have packages B, a, and UserFacingA, as follows
>
> *a* contains all the functionality in your A package that
> *does not depend on B*
> *B* *imports from* *a* and is essentially unchanged
> *UserFacingA* *Depends* on *a* and *imports from* *B*, it implements all
> functionality from your package A that *does depend on* *B*, and gets the
> rest from package *a*
>
> Users, then would only ever install or load B and UserFacingA. They
> wouldn't need to care much,if at all, about package a.
>
> ~G
>
> On Fri, Apr 8, 2016 at 7:36 AM, Dmitri Popavenko <dmitri.popavenko at
gmail.com
>> wrote:
>
>> Thanks all, I don't know either (for the moment).
>> It's all in the design phase still. Generally, I would also like to
keep
>> specific functions in specific packages, if at all possible.
>>
>> On Fri, Apr 8, 2016 at 3:03 PM, Mark van der Loo <mark.vanderloo at
gmail.com
>> wrote:
>>
>>> Well, I'm not saying that Dmitri _should_ do it. I merely
mention it as
>> an
>>> option that I think is worth thinking about -- it is easy to
overlook the
>>> obvious :-). Since we have no further info on the package's
structure we
>>> can't be sure..
>>>
>>>
>>>
>>>
>>> Op vr 8 apr. 2016 om 13:59 schreef Adrian Du?a <dusa.adrian at
unibuc.ro>:
>>>
>>>> Hi Mark,
>>>>
>>>> Uhm... sometimes this is not always possible.
>>>> For example I have a package QCA which produces truth tables
(all
>>>> combinations of presence / absence of causal conditions), and
it uses
>> the
>>>> venn package to draw a Venn diagram.
>>>> It is debatable if one should assimilate the "venn"
package into the QCA
>>>> package (other people might want Venn diagrams but not
necessarily the
>>>> other QCA functions).
>>>>
>>>> On the other hand, the package venn would like to use the QCA
package to
>>>> demonstrate its abilities to plot Venn diagrams based on truth
tables
>>>> produced by the QCA package. Both have very different purposes,
yet both
>>>> use functions from each other.
>>>>
>>>> So I'm with Bill Dunlap here that several smaller packages
are
>> preferable
>>>> to one larger one, but on the other hand I can't separate
those
>> functions
>>>> into a third package: the truth table production is very
specific to the
>>>> QCA package, while plotting Venn diagrams is very specific to
the venn
>>>> package. I don't see how to separate those functions from
their main
>>>> packages and create a third one that each would depend on.
>>>>
>>>> This is just an example, there could be others as well, reason
for which
>>>> I am (still) looking for a solution to:
>>>> - preserve the current functionalities in packages A and B (to
follow
>>>> Dmitri's original post)
>>>> - be able to use functions from each other
>>>> - yet avoid circular dependency
>>>>
>>>> I hope this explains it,
>>>> Adrian
>>>>
>>>>
>>>> On Thu, Apr 7, 2016 at 11:36 PM, Mark van der Loo <
>>>> mark.vanderloo at gmail.com> wrote:
>>>>
>>>>> 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 <
>> dmitri.popavenko at 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.onkelinx at 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 <
>>>>>> dmitri.popavenko at gmail.com>:
>>>>>>>
>>>>>>>> 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 at r-project.org mailing list
>>>>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>>>
>>>>>> [[alternative HTML version deleted]]
>>>>>>
>>>>>> ______________________________________________
>>>>>> R-devel at 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 at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> --
> Gabriel Becker, PhD
> Associate Scientist (Bioinformatics)
> Genentech Research
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
------------------------------
Message: 8
Date: Fri, 8 Apr 2016 13:05:47 -0400
From: Duncan Murdoch <murdoch.duncan at gmail.com>
To: Henrik Bengtsson <henrik.bengtsson at gmail.com>
Cc: R-devel <r-devel at r-project.org>
Subject: Re: [Rd] Under Windows, Rgui and Rterm crash if one tries to
close the graphic device while identify or locator are running
Message-ID: <5707E4EB.4030108 at gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
On 05/04/2016 3:35 PM, Duncan Murdoch wrote:> On 05/04/2016 11:56 AM, Henrik Bengtsson wrote:
> > If of any help,
> >
> > I can reproduce this (on Windows 7) back to at least R 3.0.3 but
it's
> > not there in R 3.0.0. (I have *not* checked with R 3.0.1 and 3.0.2
> > which I don't have installed).
>
> That doesn't necessarily mean that 3.0.0 was fine. It's a segfault
(I'd
> guess some memory being accessed after being freed), and it comes and
> goes as I add debugging print statements --- so it might have been there
> in 3.0.0 but we just got lucky and it never surfaced.
>
> Still, it's a start, and I'll try bisecting between 3.0.0 and 3.0.3
to
> see if some change caused it, rather than just triggered it.
I've tracked this down, and I believe I have a working fix now. The
issue was that the bug fix for PR#14872, a similar problem on Linux,
fixed Linux and introduced a new bug in Windows. For future reference,
the problem is that it is currently not safe to call error() in a
Windows event handler. We may try to fix that over the summer, the
current fix just avoids doing it.
Duncan Murdoch
------------------------------
Message: 9
Date: Fri, 8 Apr 2016 22:25:09 +0300
From: Adrian Du?a <dusa.adrian at unibuc.ro>
To: Gregory Warnes <greg at warnes.net>
Cc: r-devel <r-devel at r-project.org>
Subject: Re: [Rd] (no) circular dependency
Message-ID:
<CAJ=0CtDGJMC7PhscyC4PBFp8_9ikFbvkiGpYECgo3T5LRJaw+A at
mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi Greg,
That's interesting but I assume those are self-contained functions.
In my case, the truthTable() function from package QCA depends on numerous
other functions in the QCA package so I'm not sure how feasible it is to
copy everything from each package to every other package.
Best,
Adrian
On Fri, Apr 8, 2016 at 8:04 PM, Gregory Warnes <greg at warnes.net> wrote:
> A third possibility, which I use in my gtools and gdata packages, is to
> use soft-links to create a copy of the relevant functions from one package
> in the other. I make sure these functions are *not* exported, so no
> conflicts are created, and the use of soft-links mean the code never gets
> out of sync.
>
> -Greg
>
> *-- *
> *Change your thoughts and you change the world.*
> --Dr. Norman Vincent Peale
>
> On Apr 8, 2016, at 11:37 AM, Gabriel Becker <gmbecker at ucdavis.edu>
wrote:
>
> Another, perhaps slightly off the wall reframing of the 3-package
> possibility:
>
> Have packages B, a, and UserFacingA, as follows
>
> *a* contains all the functionality in your A package that
> *does not depend on B*
> *B* *imports from* *a* and is essentially unchanged
> *UserFacingA* *Depends* on *a* and *imports from* *B*, it implements all
> functionality from your package A that *does depend on* *B*, and gets the
> rest from package *a*
>
>
> Users, then would only ever install or load B and UserFacingA. They
> wouldn't need to care much,if at all, about package a.
>
> ~G
>
> On Fri, Apr 8, 2016 at 7:36 AM, Dmitri Popavenko <
> dmitri.popavenko at gmail.com
>
> wrote:
>
>
> Thanks all, I don't know either (for the moment).
>
> It's all in the design phase still. Generally, I would also like to
keep
>
> specific functions in specific packages, if at all possible.
>
>
> On Fri, Apr 8, 2016 at 3:03 PM, Mark van der Loo <mark.vanderloo at
gmail.com
>
>
> wrote:
>
>
> Well, I'm not saying that Dmitri _should_ do it. I merely mention it as
>
> an
>
> option that I think is worth thinking about -- it is easy to overlook the
>
> obvious :-). Since we have no further info on the package's structure
we
>
> can't be sure..
>
>
>
>
>
> Op vr 8 apr. 2016 om 13:59 schreef Adrian Du?a <dusa.adrian at
unibuc.ro>:
>
>
> Hi Mark,
>
>
> Uhm... sometimes this is not always possible.
>
> For example I have a package QCA which produces truth tables (all
>
> combinations of presence / absence of causal conditions), and it uses
>
> the
>
> venn package to draw a Venn diagram.
>
> It is debatable if one should assimilate the "venn" package into
the QCA
>
> package (other people might want Venn diagrams but not necessarily the
>
> other QCA functions).
>
>
> On the other hand, the package venn would like to use the QCA package to
>
> demonstrate its abilities to plot Venn diagrams based on truth tables
>
> produced by the QCA package. Both have very different purposes, yet both
>
> use functions from each other.
>
>
> So I'm with Bill Dunlap here that several smaller packages are
>
> preferable
>
> to one larger one, but on the other hand I can't separate those
>
> functions
>
> into a third package: the truth table production is very specific to the
>
> QCA package, while plotting Venn diagrams is very specific to the venn
>
> package. I don't see how to separate those functions from their main
>
> packages and create a third one that each would depend on.
>
>
> This is just an example, there could be others as well, reason for which
>
> I am (still) looking for a solution to:
>
> - preserve the current functionalities in packages A and B (to follow
>
> Dmitri's original post)
>
> - be able to use functions from each other
>
> - yet avoid circular dependency
>
>
> I hope this explains it,
>
> Adrian
>
>
>
> On Thu, Apr 7, 2016 at 11:36 PM, Mark van der Loo <
>
> mark.vanderloo at gmail.com> wrote:
>
>
> 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 <
>
> dmitri.popavenko at 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.onkelinx at 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 <
>
> dmitri.popavenko at gmail.com>:
>
>
> 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 at r-project.org mailing list
>
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
>
>
> [[alternative HTML version deleted]]
>
>
> ______________________________________________
>
> R-devel at 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 at r-project.org mailing list
>
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
>
>
> --
> Gabriel Becker, PhD
> Associate Scientist (Bioinformatics)
> Genentech Research
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel at 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]]
------------------------------
Message: 10
Date: Fri, 8 Apr 2016 14:34:48 -0500
From: Hadley Wickham <h.wickham at gmail.com>
To: Adrian Du?a <dusa.adrian at unibuc.ro>
Cc: r-devel <r-devel at r-project.org>
Subject: Re: [Rd] (no) circular dependency
Message-ID:
<CABdHhvEtyz2f-v7=LQRHonh3h8hQS_hQ9_4E=Cve_QOT3QmmAQ at
mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
In that scenario, I would expect that QCA would suggest Venn and Venn
would suggest QCA. Then there's no circular dependency problem.
Hadley
On Fri, Apr 8, 2016 at 6:59 AM, Adrian Du?a <dusa.adrian at unibuc.ro>
wrote:> Hi Mark,
>
> Uhm... sometimes this is not always possible.
> For example I have a package QCA which produces truth tables (all
> combinations of presence / absence of causal conditions), and it uses the
> venn package to draw a Venn diagram.
> It is debatable if one should assimilate the "venn" package into
the QCA
> package (other people might want Venn diagrams but not necessarily the
> other QCA functions).
>
> On the other hand, the package venn would like to use the QCA package to
> demonstrate its abilities to plot Venn diagrams based on truth tables
> produced by the QCA package. Both have very different purposes, yet both
> use functions from each other.
>
> So I'm with Bill Dunlap here that several smaller packages are
preferable
> to one larger one, but on the other hand I can't separate those
functions
> into a third package: the truth table production is very specific to the
> QCA package, while plotting Venn diagrams is very specific to the venn
> package. I don't see how to separate those functions from their main
> packages and create a third one that each would depend on.
>
> This is just an example, there could be others as well, reason for which I
> am (still) looking for a solution to:
> - preserve the current functionalities in packages A and B (to follow
> Dmitri's original post)
> - be able to use functions from each other
> - yet avoid circular dependency
>
> I hope this explains it,
> Adrian
>
>
> On Thu, Apr 7, 2016 at 11:36 PM, Mark van der Loo <mark.vanderloo at
gmail.com>
> wrote:
>
>> 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 <dmitri.popavenko at
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.onkelinx at 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
<dmitri.popavenko at gmail.com
>>> >:
>>> >
>>> >> 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 at r-project.org mailing list
>>> >> https://stat.ethz.ch/mailman/listinfo/r-devel
>>> >>
>>> >
>>> >
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> ______________________________________________
>>> R-devel at 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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
http://hadley.nz
------------------------------
Message: 11
Date: Sat, 9 Apr 2016 12:36:09 +0300
From: Adrian Du?a <dusa.adrian at unibuc.ro>
To: Hadley Wickham <h.wickham at gmail.com>
Cc: r-devel <r-devel at r-project.org>
Subject: Re: [Rd] (no) circular dependency
Message-ID:
<CAJ=0CtC-aEHqhdGej-ER_usA1vCuDvAX6R5XO4vrpj9UgH_tJA at
mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On Fri, Apr 8, 2016 at 10:34 PM, Hadley Wickham <h.wickham at gmail.com>
wrote:
> In that scenario, I would expect that QCA would suggest Venn and Venn
> would suggest QCA. Then there's no circular dependency problem.
>
Right, this is exactly what I was pointing myself in the first email:
- 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
The only trouble with "Suggest" is the namespace of A is not
automatically
loaded with package B (the reverse would work because package A depends on
package B).
So the only other option that I found was to make use of requireNamespace()
and use A::foo() inside the functions of B.
Or as Hadley advices, make both packages A and B suggest each other and use
requireNamespace() inside the functions of both. That would also work.
Adrian
--
Adrian Dusa
University of Bucharest
Romanian Social Data Archive
Soseaua Panduri nr.90
050663 Bucharest sector 5
Romania
[[alternative HTML version deleted]]
------------------------------
Subject: Digest Footer
_______________________________________________
R-devel at r-project.org mailing list DIGESTED
https://stat.ethz.ch/mailman/listinfo/r-devel
------------------------------
End of R-devel Digest, Vol 158, Issue 6
***************************************
