problems with RdMacros in file DESCRIPTION

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
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
***************************************