Re: [Bioc-devel] need advice on how to fix build error in windows

[Kasper Daniel Hansen]

Just wait; this is caused by failures upstream of the pd package; partly at
least by affxparser which I maintain (and which was fixed yesterday;
hurray).  Hopefully this will get sorted out soon; a lot of people are
trying to work hard to fix this.

Kasper

On Fri, Apr 8, 2016 at 5:36 PM, Dan Tenenbaum 
wrote:

> It's fine in today's build report.
> Dan
>
>
> On April 8, 2016 1:31:24 PM PDT, Krithika Bhuvaneshwar <
> kb...@georgetown.edu> wrote:
> >Dear Biconductor team,
> >
> >We are developers of newly accepted Bioconductor package CINdex. Our
> >package is meant for DNA copy number data analysis, and the example
> >data we use is from Affymetrix SNP 6.0 , so we use
> >'pd.genomewidesnp.6' annotation package for Affymetrix SNP 6.0 in our
> >vignette.
> >
> >Our package built without errors before the Windows tool chain error
> >started. Now the error is "there is no package called
> >'pd.genomewidesnp.6'. Execution halted".
> >
> >We see that package 'pd.genomewidesnp.6' is not present in BioC 3.3
> >devel. So will the 'pd.genomewidesnp.6'  from Bio C 3.2 be carried
> >over to the production version ?
> >
> >My question is: how do we go about resolving this error, which is
> >dependent on another package ? Will fixing the windows tool chain fix
> >the problem, in which case we just wait and watch ?
> >
> >We definitely want to have our package in BioC 3.3 release.. So any
> >advice will help
> >
> >Thanks,
> >Krithika
> >
> >___
> >Bioc-devel@r-project.org mailing list
> >https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Feedback on OrganismDb development

[Obenchain, Valerie]

On 04/08/2016 02:34 PM, Obenchain, Valerie wrote:
> Hi,
>
> It sounds like we have agreement on these points:
>
> - Add support for sequences
> - Keep the OrganismDb name
> - Do provide pre-built packages
>
> I'm not sure we got much weigh in on the package name. I tend towards a
> more descriptive name. This post (to me) is an example of the confusion
> that can come from a very general name:
>
> https://support.bioconductor.org/p/80612/

By 'use some development' I mean we have them on the TODO to work on
after the release.

Valerie
>
>
> These areas could use some development:
>
> - More support for Ensembl-based tracks:
> I don't think we're moving to ENSEMBL as a default (sorry Tim!) but we
> can provide more Ensembl-centric TxDbs.
>
> - Role of AnnotationHub:
> We have thought of storing the sqlite dbs in AnnotationHub and creating
> an OrganismDb on the fly. There is the issue of working off-line that
> Tim brought mentioned. We plan to do some testing with this after the
> release.
>
> - Better advertise the useful operations one can do with OrganismDb such
> as seqinfo, seqlengths, symbol translations etc.
>
>
> Tim and Ludwig, you asked for a few specific organisms. In devel we now
> have TxDbs for all mentioned except ecoli and arabidopsis so you can
> make your own OrganismDb with makeOrganismPackage().  I'm planning to
> send out a summary email to bioc-devel out that highlights the new Txdbs
> and other changes to the annotation in 3.3.
>
> Thanks for the feedback.
> Valerie
>
>
> On 04/07/2016 08:38 AM, Tim Triche, Jr. wrote:
>> My only concern regarding AnnotationHub is offline use. I find that
>> I'm more productive if I turn off the network interface altogether...
>> Maybe I'm the only one. BiomaRt also scarred me a little. 
>>
>> --t
>>
>> On Apr 7, 2016, at 8:34 AM, Vincent Carey > > wrote:
>>
>>>
>>> On Thu, Apr 7, 2016 at 11:24 AM, Tim Triche, Jr.
>>> > wrote:
>>>
>>> Great!  This is an awesome opportunity to move to ENSEMBL as a
>>> default ;-) (only half kidding, by the way)
>>>
>>> 1) BSGenome/2bit would be great -- I use this sometimes to
>>> generate fusion transcripts with defined breakpoints to
>>> supplement existing txomes
>>>
>>> 2) class name: don't change it
>>>
>>> 3) pre made packages: god yes. Try creating an ENSEMBL TxDb from
>>> a GTF on a laptop sometime!  I am planning to try and help a bit
>>> in this respect with direct Reactome mappings of various ID types
>>> for downstream analysis so this is not just a feature request, I
>>> will help with it.
>>>
>>>
>>> I think this is a different concern.  The TxDb infrastructure seems
>>> sound, and EnsDb is useful too... but they are not well-harmonized;
>>> TxDb works nicely with Gviz.  I do think that we should have a richer
>>> collection of interoperable transcript model sources packaged.  But
>>> the OrganismDb discipline, if I understand it correctly, only
>>> specifies links among diverse annotation packages and helps with
>>> cross-package joins.
>>>
>>> An afterthought -- maybe the TxDb annotation package discipline will
>>> give way to queries to AnnotationHub.  OrganismDb instance
>>> construction would specify AnnotationHub entities that comprise the
>>> instance and, on use, retrieve form AnnotationHub whatever is not in
>>> the cache.
>>>  
>>>
>>>
>>> Thanks for picking this up. I and others use the organismdbi
>>> packages all the time and was wondering what would become of them
>>> now that Marc moved to Seattle Children's. It is great to hear
>>> that they will receive renewed attention because it is a really
>>> handy infrastructure. About all I could ask for is Drosophila,
>>> Danio, and Caenorhabditis organism packages ;-)
>>>
>>> Thank you,
>>>
>>> --t
>>>
>>> > On Apr 7, 2016, at 7:34 AM, Obenchain, Valerie
>>> >> > wrote:
>>> >
>>> > BioC developers,
>>> >
>>> > After the release we plan to continue development the
>>> OrganismDb class
>>> > and packages. This email outlines some ideas for future
>>> direction. We're
>>> > interested in feedback on these points as well as other
>>> thoughts people
>>> > might have.
>>> >
>>> > ## Background
>>> >
>>> > The OrganismDb class is defined in the OrganismDbi package and
>>> consists
>>> > of a TxDb object and the combined mappings from GO.db and an
>>> OrgDb. It
>>> > supports the select() interface as well as several range-based
>>> > extractors such as exons(), transcripts(), etc. The idea was
>>> that given
>>> > a particular organism, a user would only need a single package
>>> to access
>>> > both system biology and transcripts-centric annotations.
>>> >
>>> > We currently 

[Bioc-devel] Bioconductor 3.3 release: annotation summary

[Obenchain, Valerie]

Hi,

This is a heads up about a few changes we've made to the production of
in-house annotations for Bioconductor 3.3.

# Microarray packages:
 
We will propagate but no longer rebuild the ChipDb, probe and cdf
packages. These data have been static for some time. The packages will
continue to be available in future releases as the same version they are
in the current devel branch.


# KEGG.db

KEGG.db will be propagated at the same version and not rebuilt. KEGG
went commercial several years ago and the alternative is the REST
interface in KEGGREST.


# Inparanoid

The Inparanoid packages will be propagated at the same version and not
rebuilt:

http://www.bioconductor.org/packages/release/BiocViews.html#___InparanoidDb

The last data release was 2007. Is there interest in using homologene
(http://www.ncbi.nlm.nih.gov/homologene) as a replacement? Those data
are 'new' as of May 2014.


# db0, OrgDb, PFAM.db and GO.db

Nothing special here, just rebuilt them.


# TxDb

The only track modified since last release was
TxDb.Rnorvegicus.UCSC.rn5.refGene so that was updated. We've added a few
new TxDbs (refGene track) in the interest of supplying compatible cross
coverage of BSgenome, TxDb and OrgDb packages. These are the building
blocks of the OrganismDb packages and we plan to make use of them after
the release.

Bioconductor 3.3 will host compatible BSgenome, TxDb and OrgDb packages
for these organisms:
human: hg38
chimp: panTro4
cow: bostau8
worm: ce11
dog: canFam3
fly: dm6
zebrafish: danRer10
chicken: galGal4
rhesus: rheMac3
mouse: mm10
rat: rn6
yeast: sacCer3
pig: susScr3


# BSgenome, SNPlocs, XSNPlocs

Herve added BSgenome packages for danRer10, taeGut2 and ce11. He also
added these two contributed by Timothée Flutre:

BSgenome.Vvinifera.URGI.IGGP12Xv0
BSgenome.Vvinifera.URGI.IGGP12Xv2


# OrganismDb

We currently host 3 of these for human, mouse and rat. The packages
don't contain data but instead point to GO.db and a compatible
TxDb/OrgDb pair and for this reason don't need to be updated. We plan on
actively developing this family after the release so no new packages of
this type were generated fro Bioconductor 3.3.

This is my first go-round at producing the annotation packages and they
are now in the devel branch. If you see anything strange or inconsistent
please let me know asap so I can fix before the release.

Thanks.
Valerie



This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] need advice on how to fix build error in windows

[Dan Tenenbaum]

It's fine in today's build report.
Dan


On April 8, 2016 1:31:24 PM PDT, Krithika Bhuvaneshwar  
wrote:
>Dear Biconductor team,
>
>We are developers of newly accepted Bioconductor package CINdex. Our
>package is meant for DNA copy number data analysis, and the example
>data we use is from Affymetrix SNP 6.0 , so we use
>'pd.genomewidesnp.6' annotation package for Affymetrix SNP 6.0 in our
>vignette.
>
>Our package built without errors before the Windows tool chain error
>started. Now the error is "there is no package called
>'pd.genomewidesnp.6'. Execution halted".
>
>We see that package 'pd.genomewidesnp.6' is not present in BioC 3.3
>devel. So will the 'pd.genomewidesnp.6'  from Bio C 3.2 be carried
>over to the production version ?
>
>My question is: how do we go about resolving this error, which is
>dependent on another package ? Will fixing the windows tool chain fix
>the problem, in which case we just wait and watch ?
>
>We definitely want to have our package in BioC 3.3 release.. So any
>advice will help
>
>Thanks,
>Krithika
>
>___
>Bioc-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/bioc-devel

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Feedback on OrganismDb development

[Obenchain, Valerie]

Hi,

It sounds like we have agreement on these points:

- Add support for sequences
- Keep the OrganismDb name
- Do provide pre-built packages

I'm not sure we got much weigh in on the package name. I tend towards a
more descriptive name. This post (to me) is an example of the confusion
that can come from a very general name:

https://support.bioconductor.org/p/80612/


These areas could use some development:

- More support for Ensembl-based tracks:
I don't think we're moving to ENSEMBL as a default (sorry Tim!) but we
can provide more Ensembl-centric TxDbs.

- Role of AnnotationHub:
We have thought of storing the sqlite dbs in AnnotationHub and creating
an OrganismDb on the fly. There is the issue of working off-line that
Tim brought mentioned. We plan to do some testing with this after the
release.

- Better advertise the useful operations one can do with OrganismDb such
as seqinfo, seqlengths, symbol translations etc.


Tim and Ludwig, you asked for a few specific organisms. In devel we now
have TxDbs for all mentioned except ecoli and arabidopsis so you can
make your own OrganismDb with makeOrganismPackage().  I'm planning to
send out a summary email to bioc-devel out that highlights the new Txdbs
and other changes to the annotation in 3.3.

Thanks for the feedback.
Valerie


On 04/07/2016 08:38 AM, Tim Triche, Jr. wrote:
> My only concern regarding AnnotationHub is offline use. I find that
> I'm more productive if I turn off the network interface altogether...
> Maybe I'm the only one. BiomaRt also scarred me a little. 
>
> --t
>
> On Apr 7, 2016, at 8:34 AM, Vincent Carey  > wrote:
>
>>
>>
>> On Thu, Apr 7, 2016 at 11:24 AM, Tim Triche, Jr.
>> > wrote:
>>
>> Great!  This is an awesome opportunity to move to ENSEMBL as a
>> default ;-) (only half kidding, by the way)
>>
>> 1) BSGenome/2bit would be great -- I use this sometimes to
>> generate fusion transcripts with defined breakpoints to
>> supplement existing txomes
>>
>> 2) class name: don't change it
>>
>> 3) pre made packages: god yes. Try creating an ENSEMBL TxDb from
>> a GTF on a laptop sometime!  I am planning to try and help a bit
>> in this respect with direct Reactome mappings of various ID types
>> for downstream analysis so this is not just a feature request, I
>> will help with it.
>>
>>
>> I think this is a different concern.  The TxDb infrastructure seems
>> sound, and EnsDb is useful too... but they are not well-harmonized;
>> TxDb works nicely with Gviz.  I do think that we should have a richer
>> collection of interoperable transcript model sources packaged.  But
>> the OrganismDb discipline, if I understand it correctly, only
>> specifies links among diverse annotation packages and helps with
>> cross-package joins.
>>
>> An afterthought -- maybe the TxDb annotation package discipline will
>> give way to queries to AnnotationHub.  OrganismDb instance
>> construction would specify AnnotationHub entities that comprise the
>> instance and, on use, retrieve form AnnotationHub whatever is not in
>> the cache.
>>  
>>
>>
>> Thanks for picking this up. I and others use the organismdbi
>> packages all the time and was wondering what would become of them
>> now that Marc moved to Seattle Children's. It is great to hear
>> that they will receive renewed attention because it is a really
>> handy infrastructure. About all I could ask for is Drosophila,
>> Danio, and Caenorhabditis organism packages ;-)
>>
>> Thank you,
>>
>> --t
>>
>> > On Apr 7, 2016, at 7:34 AM, Obenchain, Valerie
>> > > wrote:
>> >
>> > BioC developers,
>> >
>> > After the release we plan to continue development the
>> OrganismDb class
>> > and packages. This email outlines some ideas for future
>> direction. We're
>> > interested in feedback on these points as well as other
>> thoughts people
>> > might have.
>> >
>> > ## Background
>> >
>> > The OrganismDb class is defined in the OrganismDbi package and
>> consists
>> > of a TxDb object and the combined mappings from GO.db and an
>> OrgDb. It
>> > supports the select() interface as well as several range-based
>> > extractors such as exons(), transcripts(), etc. The idea was
>> that given
>> > a particular organism, a user would only need a single package
>> to access
>> > both system biology and transcripts-centric annotations.
>> >
>> > We currently have 3 OrganismDb packages
>> >
>> 
>> (http://www.bioconductor.org/packages/release/BiocViews.html#___OrganismDb).
>> > These are light weight and don't contain any data themselves
>> but instead
>> > point to the GO.db, OrgDb and TxDb packages.
>> >
>> > ## Current 

[Bioc-devel] need advice on how to fix build error in windows

[Krithika Bhuvaneshwar]

Dear Biconductor team,

We are developers of newly accepted Bioconductor package CINdex. Our
package is meant for DNA copy number data analysis, and the example
data we use is from Affymetrix SNP 6.0 , so we use
'pd.genomewidesnp.6' annotation package for Affymetrix SNP 6.0 in our
vignette.

Our package built without errors before the Windows tool chain error
started. Now the error is "there is no package called
'pd.genomewidesnp.6'. Execution halted".

We see that package 'pd.genomewidesnp.6' is not present in BioC 3.3
devel. So will the 'pd.genomewidesnp.6'  from Bio C 3.2 be carried
over to the production version ?

My question is: how do we go about resolving this error, which is
dependent on another package ? Will fixing the windows tool chain fix
the problem, in which case we just wait and watch ?

We definitely want to have our package in BioC 3.3 release.. So any
advice will help

Thanks,
Krithika

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] (no) circular dependency

[Hadley Wickham]

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  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 
> 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 
>> wrote:
>>
>>> Hi Thierry,
>>>
>>> Thanks for that, the trouble is functions are package specific so moving
>>> from one package to another could be a solution, but I would rather save
>>> that as a last resort.
>>>
>>> As mentioned, creating a package C with all the common functions could
>>> also
>>> be an option, but this strategy quickly inflates the number of packages on
>>> CRAN. If no other option is possible, that could be the way but I was
>>> still
>>> thinking about a more direct solution if possible.
>>>
>>> Best,
>>> Dmitri
>>>
>>> On Thu, Apr 7, 2016 at 3:47 PM, Thierry Onkelinx <
>>> thierry.onkel...@inbo.be>
>>> wrote:
>>>
>>> > Dear Dmitri,
>>> >
>>> > If it's only a small number of functions then move them the relevant
>>> > functions for A to B so that B works without A. Then Import these
>>> functions
>>> > from B in A. Hence A depends on B but B is independent of A.
>>> >
>>> > It is requires to move a lot of functions than you better create a
>>> package
>>> > C with all the common functions. Then A and B import those functions
>>> from C.
>>> >
>>> > Best regards,
>>> >
>>> > ir. Thierry Onkelinx
>>> > Instituut voor natuur- en bosonderzoek / Research Institute for Nature
>>> and
>>> > Forest
>>> > team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance
>>> > Kliniekstraat 25
>>> > 1070 Anderlecht
>>> > Belgium
>>> >
>>> > To call in the statistician after the experiment is done may be no more
>>> > than asking him to perform a post-mortem examination: he may be able to
>>> say
>>> > what the experiment died of. ~ Sir Ronald Aylmer Fisher
>>> > The plural of anecdote is not data. ~ Roger Brinner
>>> > The combination of some data and an aching desire for an answer does not
>>> > ensure that a reasonable answer can be extracted from a given body of
>>> data.
>>> > ~ John Tukey
>>> >
>>> > 2016-04-06 8:42 GMT+02:00 Dmitri Popavenko >> >:
>>> >
>>> >> Hello all,
>>> >>
>>> >> I would like to build two packages (say A and B), for two different
>>> >> purposes.
>>> >> Each of them need one or two functions from the other, which leads to
>>> the
>>> >> problem of circular dependency.
>>> >>
>>> >> Is there a way for package A to import a function from package B, and
>>> >> package B to import a function from package A, without arriving to
>>> >> circular
>>> >> dependency?
>>> >> Other suggestions in the archive mention building a third package that
>>> >> both
>>> >> A and B should depend on, but this seems less attractive.
>>> >>
>>> >> I read about importFrom() into the NAMESPACE file, but I don't know
>>> how to
>>> >> relate this with the information in the DESCRIPTION file (other than
>>> >> adding
>>> >> each package to the Depends: field).
>>> >>
>>> >> Thank you,
>>> >> Dmitri
>>> >>
>>> >> [[alternative 

Re: [Rd] (no) circular dependency

[Adrian Dușa]

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  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  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.popave...@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 
>
> 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 :
>
>
> 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.vander...@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.popave...@gmail.com>
>
> wrote:
>
>
> Hi Thierry,
>
>
> Thanks for that, the trouble is functions are package specific so
>
> moving
>
> from one package to another could be a solution, but I would rather
>
> save
>
> that as a last resort.
>
>
> As mentioned, creating a package C with all the common functions could
>
> also
>
> be an option, but this strategy quickly inflates the number of
>
> packages
>
> on
>
> CRAN. If no other option is possible, that could be the way but I was
>
> still
>
> thinking about a more direct solution if possible.
>
>
> Best,
>
> Dmitri
>
>
> On Thu, Apr 7, 2016 at 3:47 PM, Thierry Onkelinx <
>
> thierry.onkel...@inbo.be>
>
> wrote:
>
>
> Dear Dmitri,
>
>
> If it's only a small number of functions then move them the relevant
>
> functions for A to B so that B 

Re: [Rd] Under Windows, Rgui and Rterm crash if one tries to close the graphic device while identify or locator are running

[Duncan Murdoch]

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

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] (no) circular dependency

[Gregory Warnes]

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  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 > 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 > 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 :
>>> 
 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.vander...@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.popave...@gmail.com>
> wrote:
> 
>> Hi Thierry,
>> 
>> Thanks for that, the trouble is functions are package specific so
>> moving
>> from one package to another could be a solution, but I would rather
>> save
>> that as a last resort.
>> 
>> As mentioned, creating a package C with all the common functions could
>> also
>> be an option, but this strategy quickly inflates the number of
>> packages
>> on
>> CRAN. If no other option is possible, that could be the way but I was
>> still
>> thinking about a more direct solution if possible.
>> 
>> Best,
>> Dmitri
>> 
>> On Thu, Apr 7, 2016 at 3:47 PM, Thierry Onkelinx <
>> thierry.onkel...@inbo.be>
>> wrote:
>> 
>>> Dear Dmitri,
>>> 
>>> If it's only a small number of functions then move them the relevant
>>> functions for A to B so that B works without A. Then Import these
>> functions
>>> from B in A. Hence A depends on B but B is independent of A.
>>> 
>>> It is requires to move a lot of 

[Rd] PR# for match.arg(arg)

[Suharto Anggono Suharto Anggono via R-devel]

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).

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] (no) circular dependency

[Gabriel Becker]

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  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  >
> 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 :
> >
> >> 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.vander...@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.popave...@gmail.com>
> >>> wrote:
> >>>
>  Hi Thierry,
> 
>  Thanks for that, the trouble is functions are package specific so
> moving
>  from one package to another could be a solution, but I would rather
> save
>  that as a last resort.
> 
>  As mentioned, creating a package C with all the common functions could
>  also
>  be an option, but this strategy quickly inflates the number of
> packages
>  on
>  CRAN. If no other option is possible, that could be the way but I was
>  still
>  thinking about a more direct solution if possible.
> 
>  Best,
>  Dmitri
> 
>  On Thu, Apr 7, 2016 at 3:47 PM, Thierry Onkelinx <
>  thierry.onkel...@inbo.be>
>  wrote:
> 
>  > Dear Dmitri,
>  >
>  > If it's only a small number of functions then move them the relevant
>  > functions for A to B so that B works without A. Then Import these
>  functions
>  > from B in A. Hence A depends on B but B is independent of A.
>  >
>  > It is requires to move a lot of functions than you better create a
>  package
>  > C with all the common functions. Then A and B import those functions
>  from C.
>  >
>  > Best regards,
>  >
>  > ir. Thierry Onkelinx
>  > Instituut voor natuur- en bosonderzoek / Research Institute for
>  Nature and
>  > Forest
>  > team Biometrie & Kwaliteitszorg / team Biometrics & Quality
> Assurance
>  > Kliniekstraat 25
>  > 1070 Anderlecht
>  > Belgium
>  >
>  > To call in the statistician after the experiment is done may be 

Re: [Rd] (no) circular dependency

[Dmitri Popavenko]

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 
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 :
>
>> 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.vander...@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 
>>> wrote:
>>>
 Hi Thierry,

 Thanks for that, the trouble is functions are package specific so moving
 from one package to another could be a solution, but I would rather save
 that as a last resort.

 As mentioned, creating a package C with all the common functions could
 also
 be an option, but this strategy quickly inflates the number of packages
 on
 CRAN. If no other option is possible, that could be the way but I was
 still
 thinking about a more direct solution if possible.

 Best,
 Dmitri

 On Thu, Apr 7, 2016 at 3:47 PM, Thierry Onkelinx <
 thierry.onkel...@inbo.be>
 wrote:

 > Dear Dmitri,
 >
 > If it's only a small number of functions then move them the relevant
 > functions for A to B so that B works without A. Then Import these
 functions
 > from B in A. Hence A depends on B but B is independent of A.
 >
 > It is requires to move a lot of functions than you better create a
 package
 > C with all the common functions. Then A and B import those functions
 from C.
 >
 > Best regards,
 >
 > ir. Thierry Onkelinx
 > Instituut voor natuur- en bosonderzoek / Research Institute for
 Nature and
 > Forest
 > team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance
 > Kliniekstraat 25
 > 1070 Anderlecht
 > Belgium
 >
 > To call in the statistician after the experiment is done may be no
 more
 > than asking him to perform a post-mortem examination: he may be able
 to say
 > what the experiment died of. ~ Sir Ronald Aylmer Fisher
 > The plural of anecdote is not data. ~ Roger Brinner
 > The combination of some data and an aching desire for an answer does
 not
 > ensure that a reasonable answer can be extracted from a given body of
 data.
 > ~ John Tukey
 >
 > 2016-04-06 8:42 GMT+02:00 Dmitri Popavenko <
 dmitri.popave...@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 

Re: [Rd] (no) circular dependency

[Mark van der Loo]

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 :

> 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.vander...@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 
>> wrote:
>>
>>> Hi Thierry,
>>>
>>> Thanks for that, the trouble is functions are package specific so moving
>>> from one package to another could be a solution, but I would rather save
>>> that as a last resort.
>>>
>>> As mentioned, creating a package C with all the common functions could
>>> also
>>> be an option, but this strategy quickly inflates the number of packages
>>> on
>>> CRAN. If no other option is possible, that could be the way but I was
>>> still
>>> thinking about a more direct solution if possible.
>>>
>>> Best,
>>> Dmitri
>>>
>>> On Thu, Apr 7, 2016 at 3:47 PM, Thierry Onkelinx <
>>> thierry.onkel...@inbo.be>
>>> wrote:
>>>
>>> > Dear Dmitri,
>>> >
>>> > If it's only a small number of functions then move them the relevant
>>> > functions for A to B so that B works without A. Then Import these
>>> functions
>>> > from B in A. Hence A depends on B but B is independent of A.
>>> >
>>> > It is requires to move a lot of functions than you better create a
>>> package
>>> > C with all the common functions. Then A and B import those functions
>>> from C.
>>> >
>>> > Best regards,
>>> >
>>> > ir. Thierry Onkelinx
>>> > Instituut voor natuur- en bosonderzoek / Research Institute for Nature
>>> and
>>> > Forest
>>> > team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance
>>> > Kliniekstraat 25
>>> > 1070 Anderlecht
>>> > Belgium
>>> >
>>> > To call in the statistician after the experiment is done may be no more
>>> > than asking him to perform a post-mortem examination: he may be able
>>> to say
>>> > what the experiment died of. ~ Sir Ronald Aylmer Fisher
>>> > The plural of anecdote is not data. ~ Roger Brinner
>>> > The combination of some data and an aching desire for an answer does
>>> not
>>> > ensure that a reasonable answer can be extracted from a given body of
>>> data.
>>> > ~ John Tukey
>>> >
>>> > 2016-04-06 8:42 GMT+02:00 Dmitri Popavenko >> >:
>>> >
>>> >> Hello all,
>>> >>
>>> >> I would like to build two packages (say A and B), for two different
>>> >> purposes.
>>> >> Each of them need one or two functions from the other, which leads to
>>> the
>>> >> problem of circular dependency.
>>> >>
>>> >> Is there a way for package A to import a function from package B, and
>>> >> package B to import a function from package A, without arriving to
>>> >> circular
>>> >> dependency?
>>> >> Other suggestions in the archive mention building a third package that
>>> >> both
>>> >> A and B should depend on, but this seems less attractive.
>>> >>
>>> >> I read about importFrom() into the NAMESPACE file, but I don't know
>>> how to
>>> >> relate this with the information in the DESCRIPTION file (other than
>>> >> adding
>>> >> each 

Re: [Rd] (no) circular dependency

[Adrian Dușa]

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 
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 
> wrote:
>
>> Hi Thierry,
>>
>> Thanks for that, the trouble is functions are package specific so moving
>> from one package to another could be a solution, but I would rather save
>> that as a last resort.
>>
>> As mentioned, creating a package C with all the common functions could
>> also
>> be an option, but this strategy quickly inflates the number of packages on
>> CRAN. If no other option is possible, that could be the way but I was
>> still
>> thinking about a more direct solution if possible.
>>
>> Best,
>> Dmitri
>>
>> On Thu, Apr 7, 2016 at 3:47 PM, Thierry Onkelinx <
>> thierry.onkel...@inbo.be>
>> wrote:
>>
>> > Dear Dmitri,
>> >
>> > If it's only a small number of functions then move them the relevant
>> > functions for A to B so that B works without A. Then Import these
>> functions
>> > from B in A. Hence A depends on B but B is independent of A.
>> >
>> > It is requires to move a lot of functions than you better create a
>> package
>> > C with all the common functions. Then A and B import those functions
>> from C.
>> >
>> > Best regards,
>> >
>> > ir. Thierry Onkelinx
>> > Instituut voor natuur- en bosonderzoek / Research Institute for Nature
>> and
>> > Forest
>> > team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance
>> > Kliniekstraat 25
>> > 1070 Anderlecht
>> > Belgium
>> >
>> > To call in the statistician after the experiment is done may be no more
>> > than asking him to perform a post-mortem examination: he may be able to
>> say
>> > what the experiment died of. ~ Sir Ronald Aylmer Fisher
>> > The plural of anecdote is not data. ~ Roger Brinner
>> > The combination of some data and an aching desire for an answer does not
>> > ensure that a reasonable answer can be extracted from a given body of
>> data.
>> > ~ John Tukey
>> >
>> > 2016-04-06 8:42 GMT+02:00 Dmitri Popavenko > >:
>> >
>> >> Hello all,
>> >>
>> >> I would like to build two packages (say A and B), for two different
>> >> purposes.
>> >> Each of them need one or two functions from the other, which leads to
>> the
>> >> problem of circular dependency.
>> >>
>> >> Is there a way for package A to import a function from package B, and
>> >> package B to import a function from package A, without arriving to
>> >> circular
>> >> dependency?
>> >> Other suggestions in the archive mention building a third package that
>> >> both
>> >> A and B should depend on, but this seems less attractive.
>> >>
>> >> I read about importFrom() into the NAMESPACE file, but I don't know
>> how to
>> >> relate this with the information in the DESCRIPTION file (other than
>> >> adding
>> >> each package to the Depends: field).
>> >>
>> >> Thank you,
>> >> Dmitri
>> >>
>> >> [[alternative HTML version deleted]]
>> >>
>> >> __
>> >> R-devel@r-project.org mailing list
>> >> https://stat.ethz.ch/mailman/listinfo/r-devel
>> >>
>> >
>> >
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [PATCH] fix CHECK_this_length in sprintf.c

[Matthew Fowles Kulukundis]

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 
wrote:

> > Matthew Fowles Kulukundis 
> > on Tue, 5 Apr 2016 11:17:30 -0400 writes:
>
> > All~
> > CHECK_this_length macro expands to multiple statements making it
> unsafe to
> > use in a single line `if` statement (as is happening near line
> 335).  This
> > fixes the macro using the standard `do { } while (0)` macro trick.
>
> yes, but you forgot the closing '}' ... so you could not even
> have compiled R after applying your patch.
>
> Also, it would be nice to contrive a minimal example where the
> change makes a difference.  This  "fails" to trigger :
>
> 
> as.double.foo <- function(x) x[FALSE]
> x <- structure(3, class="foo")
> as.numeric(x) # numeric(0)
>
> sprintf("%d !", x)# "3 !"  instead of giving an error
> 
>
> Thank you, Matt, in any case; this (with the "{" !) has now gone
> into the source.
>
> Martin
>
> > Matt
> > x[DELETED ATTACHMENT external: r-sprintf.patch, text/x-patch]
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Bioc-devel] Feedback on OrganismDb development

[Ludwig Geistlinger]

Dear Valerie,

Thank you for the update.

1) Class name: I'd definitely prefer the exisiting naming over the three
other suggestions you gave.

2) Pre-made packages: Yes, I think it would be great to have such packages
available for well-established Bioc model organisms, i.e. as returned by
AnnotationForge::available.db0pkgs(), or at the very least for

ecoli (Escherichia.coli)
yeast (Saccharomyces.cerevisiae)
arabidopsis (Arabidopsis.thaliana)
fly (Drosophila.melanogaster)
zebrafish (Danio.rerio)
worm (Caenorhabditis.elegans)

(in addition to the exisiting 3 for human, mouse and rat)

Thx & Best,
Ludwig

-- 
Dipl.-Bioinf. Ludwig Geistlinger

Lehr- und Forschungseinheit für Bioinformatik
Institut für Informatik
Ludwig-Maximilians-Universität München
Amalienstrasse 17, 2. Stock, Büro A201
80333 München

Tel.: 089-2180-4067
eMail: ludwig.geistlin...@bio.ifi.lmu.de

> BioC developers,
>
> After the release we plan to continue development the OrganismDb class
and packages. This email outlines some ideas for future direction. We're
interested in feedback on these points as well as other thoughts people
might have.
>
> ## Background
>
> The OrganismDb class is defined in the OrganismDbi package and consists
of a TxDb object and the combined mappings from GO.db and an OrgDb. It
supports the select() interface as well as several range-based
> extractors such as exons(), transcripts(), etc. The idea was that given
a particular organism, a user would only need a single package to access
both system biology and transcripts-centric annotations.
>
> We currently have 3 OrganismDb packages
> (http://www.bioconductor.org/packages/release/BiocViews.html#___OrganismDb).
These are light weight and don't contain any data themselves but instead
point to the GO.db, OrgDb and TxDb packages.
>
> ## Current issues
>
> - Support for sequence representation
>
> We've discussed incorporating an optional sequence component, maybe
BSgenome or 2bit or ... ?
>
>
> - Class name
>
> OrganismDb is similar to OrgDb which could cause some confusion. We are
considering renaming ... here are a few ideas. Let us know what you
think or add your suggestion.
>
> OrganismDb (fine as is, leave it)
> FullOrgDb
> CrossDb
> MultipleDb
>
>
> - Package name
>
> The current names are not very descriptive: Homo.sapiens, Mus.musculus
and Rattus.norvegicus.  We'd like to follow the naming convention used
in our BSgenome and TxDb packages which means including the source,
build and track from the TxDb as well as preceding with the class type.
>
> For example, the current 'Homo.sapiens' package would be renamed
'OrganismDb.Hsapiens.UCSC.hg19.knownGene'.
>
>
> - Pre-made packages
>
> Is it useful to supply pre-made packages or just increase awareness of
the helpers so users can make their own? Current helpers:
>
>> ?makeOrganism
> ?makeOrganismDbFromBiomart  ?makeOrganismDbFromTxDb
> ?makeOrganismDbFromUCSC ?makeOrganismPackage
>
> NOTE: makeOrgansimPackage() will be renamed to makeOrganismDbPackage().
>
>
> Thanks.
> Valerie
>
>
> This email message may contain legally privileged and/or confidential
information.  If you are not the intended recipient(s), or the employee
or agent responsible for the delivery of this message to the intended
recipient(s), you are hereby notified that any disclosure, copying,
distribution, or use of this email message is prohibited.  If you have
received this message in error, please notify the sender immediately by
e-mail and delete this email message from your computer. Thank you.
___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] rhdf5 and left-justified output in h5ls - is this sensible?

[Aaron Lun]

Dear List, Bernd;

I've noticed that h5ls now left-justifies its output. For example, if I 
were to run example(h5ls) on my BioC-devel system, I would get:



  group   name ltype corder_valid corder cset   otype num_attrs
0  /fooH5L_TYPE_HARDFALSE  00 H5I_GROUP   0
1  /foo B  H5L_TYPE_HARDFALSE  00 H5I_DATASET 0
2  /foo foobaa H5L_TYPE_HARDFALSE  00 H5I_GROUP   0
  dclass  dtype  stype rank   dimmaxdim
0 0
1  FLOAT H5T_IEEE_F64LE SIMPLE3 5 x 2 x 2 5 x 2 x 2
2 0


... whereas if I run it on release, I would get:


  group   name ltype corder_valid corder cset   otype num_attrs
0 /foo H5L_TYPE_HARDFALSE  00   H5I_GROUP 0
1  /foo  B H5L_TYPE_HARDFALSE  00 H5I_DATASET 0
2  /foo foobaa H5L_TYPE_HARDFALSE  00   H5I_GROUP 0
  dclass  dtype  stype rank   dimmaxdim
0 0
1  FLOAT H5T_IEEE_F64LE SIMPLE3 5 x 2 x 2 5 x 2 x 2
2 0


Now, my problem is that I use h5ls to determine what data substructures 
are available in a particular *.h5 file, and how I should load them with 
h5read. I can do this on release:


> x <- h5ls("ex_ls_dump.h5",all=TRUE)
> h5read("ex_ls_dump.h5", file.path(x$group[2], x$name[2]))
# gives me the data under /foo/B

... but not on BioC-devel:

> Error in h5read("ex_ls_dump.h5", file.path(x$group[2], x$name[2])) :
>   Object /foo/B  does not exist in this HDF5 file.

... due to the extra spaces. Suffice to say that it was a rather 
unpleasant surprise to get at 2am in the morning!


I can't see any purpose of the left-justification except for aesthetics. 
Is it sensible to compromise the expected behaviour of the function just 
to make its output look pretty?


Here's the session information for my devel build:


R Under development (unstable) (2016-02-24 r70217)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.4 LTS

locale:
 [1] LC_CTYPE=en_GB.UTF-8   LC_NUMERIC=C
 [3] LC_TIME=en_GB.UTF-8LC_COLLATE=en_GB.UTF-8
 [5] LC_MONETARY=en_GB.UTF-8LC_MESSAGES=en_GB.UTF-8
 [7] LC_PAPER=en_GB.UTF-8   LC_NAME=C
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] rhdf5_2.15.6

loaded via a namespace (and not attached):
[1] zlibbioc_1.17.1 tools_3.3.0


... and again, for release:


R version 3.2.2 (2015-08-14)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.4 LTS

locale:
 [1] LC_CTYPE=en_GB.UTF-8   LC_NUMERIC=C
 [3] LC_TIME=en_GB.UTF-8LC_COLLATE=en_GB.UTF-8
 [5] LC_MONETARY=en_GB.UTF-8LC_MESSAGES=en_GB.UTF-8
 [7] LC_PAPER=en_GB.UTF-8   LC_NAME=C
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] rhdf5_2.14.0

loaded via a namespace (and not attached):
[1] zlibbioc_1.16.0 tools_3.2.2


Cheers,

Aaron

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel