Re: [Rd] Base R examples that write to current working directory

[Martin Maechler]

> Gabe Becker 
> on Tue, 3 Apr 2018 21:16:12 -0700 writes:

> Martin et al,
> I have submitted a patch on bugzilla which fixes all of the examples I
> could easily find which were not already writing only to temporary files 
or
> switching to a temp directory before writing files to the working
> directory. https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17403

> Passes make check-devel so the examples run and the packages that were
> modified pass check.

Thank you very much, Gabe,

I've committed most of it now (to R-devel only, to be ported to
3.5.0 alpha, later).

There are some issues I've wanted to postpone and open for
discussion, e.g., here (on R-devel):

https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17403#c3  :

1) All(?) the file-based graphics devices have a default file
   name which resides in the current working directory,
   pdf(), postscript(), png(), ..., and pictex().

   We may think that this *default* should be changed, rather
   than the documentation, e.g., for pictex() , from
   "Rplots.tex" to  tempfile("Rplots.tex")

2) The write() function, for 30 years back compatibility with S,
   has a default  'file = "data"'

   Should we change the default to use "", the same as
   write.table() uses, or also something tempfile() based?


https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17403#c4  :

3)  prompt() and promptData()  [and possibly other prompt*()] :

   I did not apply your proposed changes here, see the
   R-bugzilla for reasoning.

   Still one may want to propose changing the default behavior
   from using the getwd() working directory to tempdir() instead.
   

Martin


> On Tue, Apr 3, 2018 at 2:37 AM, Martin Maechler 

> wrote:

>> > Henrik Bengtsson 
>> > on Fri, 30 Mar 2018 10:14:04 -0700 writes:
>> 
>> > So, the proposal would then be to write to tempdir(),
>> > correct?  If so, I see three alternatives:
>> 
>> > 1. explicitly use file.path(tempdir(), filename), or
>> > tempfile() everywhere.
>> 
>> I think it should clearly be  '1.',
>> as both '2.' and '3.' would need new functionality in R.
>> 
>> Ideally we'd get the patch within a day or two, so we can safely
>> apply it also to  R 3.5.0 alpha  (before it turns beta!).
>> 
>> I think the 'eval.path' argument to example() is a nice idea,
>> but also changing its default to  tempdir() is definitely out of
>> the question for R 3.5.0.
>> 
>> Martin
>> 
>> 
>> > 2. wrap example code in a withTempDir({ ... }) call.
>> 
>> > 3. Add an 'eval.path' (*) argument to example() and make
>> > it default to eval.path = tempdir(). This would probably
>> > be backward compatible and keep the code example clean.
>> > The downside is when a user runs an example and can't
>> > locate produced files. (*) or 'wd', 'workdir', ...
>> 
>> > /Henrik
>> 
>> > On Fri, Mar 30, 2018 at 9:25 AM, Uwe Ligges
>> >  wrote:
>> >>
>> >>
>> >> On 30.03.2018 00:08, Duncan Murdoch wrote:
>> >>>
>> >>> On 29/03/2018 5:23 PM, Hadley Wickham wrote:
>> 
>>  Hi all,
>> 
>>  Given the recent CRAN push to prevent examples writing
>>  to the working directory, is there any interest in
>>  fixing base R examples that write to the working
>>  directory? A few candidates are the graphics devices,
>>  file.create(), writeBin(), writeChar(), write(), and
>>  saveRDS(). I'm sure there are many more.
>> 
>>  One way to catch these naughty examples would be to
>>  search for unlink() in examples: e.g.,
>> 
>>  https://github.com/wch/r-source/search?utf8=✓=unlink+
>> extension%3ARd=
>> 

>> .
>>  Of course, simply cleaning up after yourself is not
>>  sufficient because if those files existed before the
>>  examples were run, the examples will destroy them.
>> 
>> >>>
>> >>> Why not put together a patch that fixes these?  This
>> >>> doesn't seem to be something that needs discussion,
>> >>> fixing the bad examples would be a good idea.
>> >>
>> >>
>> >> Seconded. CRAN would not accept these base packages,
>> >> hence we should urgently give better examples.
>> >>
>> >> Best, Uwe
>> >>
>> >>> Duncan Murdoch



> -- 
> Gabriel Becker, Ph.D
> Scientist
> Bioinformatics and Computational Biology
> Genentech Research

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

Re: [Rd] utils::unzip ignores overwrite argument, effectively

[Tomas Kalibera]

Thanks, fixed in R-devel.
Tomas

On 12/20/2017 02:38 PM, Gábor Csárdi wrote:

It does give a warning, but then it overwrites the files, anyway.
Reproducible example below.

This is R 3.4.3, but it does not seem to be fixed in R-devel:
https://github.com/wch/r-source/blob/4a9ca3e5ac6b19d7faa7c9290374f7604bf0ef64/src/main/dounzip.c#L171-L174

FYI,
Gábor

dir.create(tmp <- tempfile())
setwd(tmp)

cat("old1\n", file = "file1")
cat("old2\n", file = "file2")

utils::zip("files.zip", c("file1", "file2"))
#>   adding: file1 (stored 0%)
#>   adding: file2 (stored 0%)

unlink("file2")
cat("new1\n", file = "file1")
readLines("file1")
#> [1] "new1"

utils::unzip("files.zip", overwrite = FALSE)
#> Warning message:
#> In utils::unzip("files.zip", overwrite = FALSE) :
#>not overwriting file './file1

readLines("file1")
#> [1] "old1"

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


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

Re: [Rd] Base R examples that write to current working directory

[Gabe Becker]

Martin et al,

I have submitted a patch on bugzilla which fixes all of the examples I
could easily find which were not already writing only to temporary files or
switching to a temp directory before writing files to the working
directory. https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17403

Passes make check-devel so the examples run and the packages that were
modified pass check.

Best,
~G

On Tue, Apr 3, 2018 at 2:37 AM, Martin Maechler 
wrote:

> > Henrik Bengtsson 
> > on Fri, 30 Mar 2018 10:14:04 -0700 writes:
>
> > So, the proposal would then be to write to tempdir(),
> > correct?  If so, I see three alternatives:
>
> > 1. explicitly use file.path(tempdir(), filename), or
> > tempfile() everywhere.
>
> I think it should clearly be  '1.',
> as both '2.' and '3.' would need new functionality in R.
>
> Ideally we'd get the patch within a day or two, so we can safely
> apply it also to  R 3.5.0 alpha  (before it turns beta!).
>
> I think the 'eval.path' argument to example() is a nice idea,
> but also changing its default to  tempdir() is definitely out of
> the question for R 3.5.0.
>
> Martin
>
>
> > 2. wrap example code in a withTempDir({ ... }) call.
>
> > 3. Add an 'eval.path' (*) argument to example() and make
> > it default to eval.path = tempdir(). This would probably
> > be backward compatible and keep the code example clean.
> > The downside is when a user runs an example and can't
> > locate produced files. (*) or 'wd', 'workdir', ...
>
> > /Henrik
>
> > On Fri, Mar 30, 2018 at 9:25 AM, Uwe Ligges
> >  wrote:
> >>
> >>
> >> On 30.03.2018 00:08, Duncan Murdoch wrote:
> >>>
> >>> On 29/03/2018 5:23 PM, Hadley Wickham wrote:
> 
>  Hi all,
> 
>  Given the recent CRAN push to prevent examples writing
>  to the working directory, is there any interest in
>  fixing base R examples that write to the working
>  directory? A few candidates are the graphics devices,
>  file.create(), writeBin(), writeChar(), write(), and
>  saveRDS(). I'm sure there are many more.
> 
>  One way to catch these naughty examples would be to
>  search for unlink() in examples: e.g.,
> 
>  https://github.com/wch/r-source/search?utf8=✓=unlink+
> extension%3ARd=
> 
> .
>  Of course, simply cleaning up after yourself is not
>  sufficient because if those files existed before the
>  examples were run, the examples will destroy them.
> 
> >>>
> >>> Why not put together a patch that fixes these?  This
> >>> doesn't seem to be something that needs discussion,
> >>> fixing the bad examples would be a good idea.
> >>
> >>
> >> Seconded. CRAN would not accept these base packages,
> >> hence we should urgently give better examples.
> >>
> >> Best, Uwe
> >>
> >>
> >>
> >>> Duncan Murdoch
> >>>
> >>> __
> >>> R-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >>
> >> __
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Gabriel Becker, Ph.D
Scientist
Bioinformatics and Computational Biology
Genentech Research

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Fwd: [CRAN-pretest-archived] CRAN submission Boom 0.8

[Steven Scott]

Thanks Dirk.  IMO the package is in good shape otherwise.  I'll wait hear
from the CRAN maintainers.
S

On Wed, Apr 4, 2018 at 2:53 PM, Dirk Eddelbuettel  wrote:

>
> On 4 April 2018 at 14:15, Steven Scott wrote:
> | These appear to be caused by an ill formed std::set or std::function in
> the
> | STL implementation of the host machine.  If I'm reading that wrong
> someone
> | please let me know.
>
> AFAICT it needs C++11 explicitly set which that machine (with a new
> clang-6.0
> installation) did not provide by default.  This has bitten a few other
> compilations lately as well but should get sorted out in due course.
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Fwd: [CRAN-pretest-archived] CRAN submission Boom 0.8

[Dirk Eddelbuettel]

On 4 April 2018 at 14:15, Steven Scott wrote:
| These appear to be caused by an ill formed std::set or std::function in the
| STL implementation of the host machine.  If I'm reading that wrong someone
| please let me know.

AFAICT it needs C++11 explicitly set which that machine (with a new clang-6.0
installation) did not provide by default.  This has bitten a few other
compilations lately as well but should get sorted out in due course.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

[R-pkg-devel] CRAN Pre-Test Problems -- FSA Package

[Derek Ogle]

I recently submitted a new version (v0.8.19) of my FSA package to CRAN. It was 
rejected at the pre-test level because of problems with automatic checks. There 
were three links for me to see what these problems were.

The first link from CRAN was to a win-builder check log 
(https://win-builder.r-project.org/incoming_pretest/FSA_0.8.19_20180403_023758/Windows/00check.log)
 that contained the single following warning:

* checking Rd cross-references ... WARNING
package 'DescTools' exists but was not installed under R >= 2.10.0 so xrefs 
cannot be checked

This is related to a cross-reference link in my documentation. Should I just 
remove this link (this link did not cause problems when I had submitted my 
package previously)?

The second link from CRAN was to my current (v0.8.17) package on CRAN 
(https://cran.r-project.org/web/checks/check_results_FSA.html). This shows 
several warnings related to a function in a dependent package (car) being 
deprecated. The new version of my package (the one I am trying to submit to 
CRAN) is meant to address these issues. As far as I can tell, through checks on 
my local machine, on win-builder, appVeyor, and Travis-Ci, these issues have 
been addressed. I don't know how to address this pre-test issue, except to 
submit the new version of my package. [Note there is another warning on this 
page related to the RMark package. That warning has existed for many versions 
of my package and has been ignored by CRAN in the past.]

The third link from CRAN 
(https://win-builder.r-project.org/incoming_pretest/FSA_0.8.19_20180403_023758/Windows/)
 was to the same set of win-builder results which only shows the same warning 
as the first link above.

I did reply to the CRAN submission with this same set of questions but have not 
yet received a reply. [This is not a critique, just pointing out what I have 
done.]

Any suggestions for how to handle these issues to satisfy the pre-test (and 
other tests) of CRAN?

Thank you for any advice.

[[alternative HTML version deleted]]

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

[R-pkg-devel] Fwd: [CRAN-pretest-archived] CRAN submission Boom 0.8

[Steven Scott]

I've been trying to update the Boom package to the next version, and it
hasn't been going so well.  Hoping someone can help me figure out what next
steps I should take.

I got the attached mail from auto-check.  From what I can tell the new
version of Boom (0.8.0) has two issues.  Some long path names, and a large
install size.  Both are pre-existing issues shared with previous Boom
versions.  Nothing can be done about the long path names (but they have
never caused a problem in the past), and the large install size has to do
with the -g flag passed by R CMD INSTALL, which I don't control.  In past
versions of Boom we've let both these issues go.

The auto-check script also flags an ERROR which seems to be related to
version 0.7.0 (the current version).  Clicking through to the compiler
errors (
https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/Boom-00install.html)
gives:

* installing to library
‘/home/hornik/tmp/R.check/r-devel-clang/Work/build/Packages’
* installing *source* package ‘Boom’ ...
** package ‘Boom’ successfully unpacked and MD5 sums checked
** libs
make[1]: Entering directory '/tmp/Rtmpnqufqi/R.INSTALL4d314a0b9495/Boom/src'
clang++-6.0  -I"/home/hornik/tmp/R.check/r-devel-clang/Work/build/include"
-DNDEBUG -I. -I../inst/include -IBmath -Imath/cephes
-DNO_BOOST_THREADS -DNO_BOOST_FILESYSTEM -DADD_ -DRLANGUAGE
-I"/home/hornik/tmp/R.check/r-devel-clang/Work/build/Packages/BH/include"
-I/usr/local/include   -fpic  -g -O3 -Wall -pedantic -mtune=native -c
Models/Bart/PoissonBartModel.cpp -o Models/Bart/PoissonBartModel.o
In file included from Models/Bart/PoissonBartModel.cpp:19:
In file included from ../inst/include/Models/Bart/PoissonBartModel.hpp:24:
In file included from ../inst/include/Models/Bart/Bart.hpp:22:
In file included from
/usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/set:60:
In file included from
/usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_tree.h:65:
/usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_function.h:545:9:
error: redefinition of '__not_overloaded<_Tp, _Up>'
struct __not_overloaded<_Tp, _Up> : __not_overloaded2<_Tp, _Up> { };
   ^~
/usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_function.h:531:9:
note: previous definition is here
struct __not_overloaded<_Tp, _Up, __void_t<
   ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_function.h:608:9:
error: redefinition of '__not_overloaded<_Tp, _Up>'
struct __not_overloaded<_Tp, _Up> : __not_overloaded2<_Tp, _Up> { };
   ^~
/usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_function.h:594:9:
note: previous definition is here
struct __not_overloaded<_Tp, _Up, __void_t<
   ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_function.h:671:9:
error: redefinition of '__not_overloaded<_Tp, _Up>'
struct __not_overloaded<_Tp, _Up> : __not_overloaded2<_Tp, _Up> { };
   ^~
/usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_function.h:657:9:
note: previous definition is here
struct __not_overloaded<_Tp, _Up, __void_t<
   ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_function.h:734:9:
error: redefinition of '__not_overloaded<_Tp, _Up>'
struct __not_overloaded<_Tp, _Up> : __not_overloaded2<_Tp, _Up> { };
   ^~
/usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_function.h:720:9:
note: previous definition is here
struct __not_overloaded<_Tp, _Up, __void_t<
   ^
4 errors generated.
/home/hornik/tmp/R.check/r-devel-clang/Work/build/etc/Makeconf:166:
recipe for target 'Models/Bart/PoissonBartModel.o' failed
make[1]: *** [Models/Bart/PoissonBartModel.o] Error 1
make[1]: Leaving directory '/tmp/Rtmpnqufqi/R.INSTALL4d314a0b9495/Boom/src'
ERROR: compilation failed for package ‘Boom’
* removing ‘/home/hornik/tmp/R.check/r-devel-clang/Work/build/Packages/Boom’

These appear to be caused by an ill formed std::set or std::function in the
STL implementation of the host machine.  If I'm reading that wrong someone
please let me know.

Thanks!
S

-- Forwarded message --
From: 
Date: Wed, Apr 4, 2018 at 1:21 PM
Subject: [CRAN-pretest-archived] CRAN submission Boom 0.8
To: steve.the.bayes...@gmail.com
Cc: cran-submissi...@r-project.org


Dear maintainer,

package Boom_0.8.tar.gz does not pass the incoming checks automatically,
please see the following pre-tests:
Windows: 
Status: 4 NOTEs
Debian: 

Re: [Bioc-devel] Missed deadline

[Kenneth Condon]

Hi Gabe & Levi,

Here is my current plan:

1 - complete the requirements checklist (
http://www.bioconductor.org/developers/package-submission/)
2 - get feedback the in-house NGS team, and then from the rest of in-house
bioinformatics (others who use R more may spot some issues)
3 - set up pull requests release on github for community testing
4 - advertise github repo on bioconductor and biostars forums
5 - compare to other packages
6 - write paper (decide which journal)
7 - have submission of paper + package ready for October deadline.

Regarding the sequence of events - do other authors usually release on
bioconductor before submission of a paper or at the same time?
What would you recommend?

Thanks for the help

Kenneth

On Tue, Apr 3, 2018 at 4:56 PM, Gabe Becker  wrote:

> Indeed, and to be a bit more explicit about Levi's point, you *can*
> publish your package to bioconductor any time after the deadline, it will
> simply go to the development repo for ~6 months, which, as he points out,
> may not be a bad thing if it's not ready yet.
>
> On Tue, Apr 3, 2018 at 8:06 AM, Levi Waldron 
> wrote:
>
>> On Tue, Apr 3, 2018 at 5:32 AM, Kenneth Condon 
>> wrote:
>>
>> > Have I missed the deadline for the latest release? I have created a
>> > package, that runs great but there are a number of errors still from R
>> CMD
>> > check that I am sorting out.
>> >
>> > This is my first R package so I'm not sure if development is far enough
>> > along, although I suspect it might be.
>> >
>>
>> IMHO, when you're not sure a package is mature enough, and especially for
>> a
>> first package, it's actually better to miss the release deadline and allow
>> bioc-devel users test your package for 6 months before entering the
>> release
>> cycle. Making significant bug fixes and other changes becomes more
>> complicated and more of a pain for you and your users once you are in the
>> release...
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>>
>
>
> --
> Gabriel Becker, Ph.D
> Scientist
> Bioinformatics and Computational Biology
> Genentech Research
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Missed deadline

[Kasper Daniel Hansen]

This is a subjective question. As a paper reviewer I like to see the
package accepted. That increases trust.  As a package reviewer I like some
idea of what the package actually does, so a statement like "we implement X
which is described in (XX, in preparation), is also irritating.

Unless you're trying to not show anything prior to publication (which
happens) I like submitting the package first.

On Wed, Apr 4, 2018 at 12:31 PM, Kenneth Condon 
wrote:

> Hi Gabe & Levi,
>
> Here is my current plan:
>
> 1 - complete the requirements checklist (
> http://www.bioconductor.org/developers/package-submission/)
> 2 - get feedback the in-house NGS team, and then from the rest of in-house
> bioinformatics (others who use R more may spot some issues)
> 3 - set up pull requests release on github for community testing
> 4 - advertise github repo on bioconductor and biostars forums
> 5 - compare to other packages
> 6 - write paper (decide which journal)
> 7 - have submission of paper + package ready for October deadline.
>
> Regarding the sequence of events - do other authors usually release on
> bioconductor before submission of a paper or at the same time?
> What would you recommend?
>
> Thanks for the help
>
> Kenneth
>
> On Tue, Apr 3, 2018 at 4:56 PM, Gabe Becker  wrote:
>
> > Indeed, and to be a bit more explicit about Levi's point, you *can*
> > publish your package to bioconductor any time after the deadline, it will
> > simply go to the development repo for ~6 months, which, as he points out,
> > may not be a bad thing if it's not ready yet.
> >
> > On Tue, Apr 3, 2018 at 8:06 AM, Levi Waldron <
> lwaldron.resea...@gmail.com>
> > wrote:
> >
> >> On Tue, Apr 3, 2018 at 5:32 AM, Kenneth Condon 
> >> wrote:
> >>
> >> > Have I missed the deadline for the latest release? I have created a
> >> > package, that runs great but there are a number of errors still from R
> >> CMD
> >> > check that I am sorting out.
> >> >
> >> > This is my first R package so I'm not sure if development is far
> enough
> >> > along, although I suspect it might be.
> >> >
> >>
> >> IMHO, when you're not sure a package is mature enough, and especially
> for
> >> a
> >> first package, it's actually better to miss the release deadline and
> allow
> >> bioc-devel users test your package for 6 months before entering the
> >> release
> >> cycle. Making significant bug fixes and other changes becomes more
> >> complicated and more of a pain for you and your users once you are in
> the
> >> release...
> >>
> >> [[alternative HTML version deleted]]
> >>
> >> ___
> >> Bioc-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >>
> >>
> >
> >
> > --
> > Gabriel Becker, Ph.D
> > Scientist
> > Bioinformatics and Computational Biology
> > Genentech Research
> >
>
> [[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

[Bioc-devel] BioC 3.7: build failing on Mac (merida2) because Cairo not available

[Ramon Diaz-Uriarte]

Dear All,

A package I maintain (ADaCGH2) is giving an error during  build
(http://bioconductor.org/checkResults/devel/bioc-LATEST/ADaCGH2/merida2-buildsrc.html)
because Cairo is not available. A quick look at other packages that depend
on Cairo shows the same problem there.

What should we do?


Best,


R.

--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain

Phone: +34-91-497-2412

Email: rdia...@gmail.com
   ramon.d...@iib.uam.es

http://ligarto.org/rdiaz

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

[Bioc-devel] Bioc-devel changes and SummarizedExperiment class

[Leonard Goldstein]

Hi Hervé,

Some recent changes in bioc-devel are causing trouble with
SummarizedExperiment objects if the rowRanges slot inherits from
GRangesList. Please see example below.

Thanks in advance for your help.

Leonard

--
> library(SGSeq)
>
> ## SGVariants object inherits from GRangesList


> is(sgv_pred)
 [1] "SGVariants" "GRangesList"
 [3] "Paths"  "GenomicRangesList"
 [5] "CompressedRangesList"   "GenomicRanges_OR_GRangesList"
 [7] "RangesList" "CompressedList"
 [9] "GenomicRanges_OR_GenomicRangesList" "List"
[11] "Vector" "list_OR_List"
[13] "Annotated"
>
> ## example counts


> counts <- matrix(1:2, ncol = 1)
>
> ## creating SummarizedExperiment object fails


> SummarizedExperiment(assays = list(counts), rowRanges = sgv_pred)
class: RangedSummarizedExperiment
dim: 2 1
metadata(0):
assays(1): ''
Error in .local(object, ..., verbose) : unused argument (check = FALSE)
>
> ## works after coercing to GRangestList


> SummarizedExperiment(assays = list(counts), rowRanges = as(sgv_pred,
"GRangesList"))
class: RangedSummarizedExperiment
dim: 2 1
metadata(0):
assays(1): ''
rownames: NULL
rowData names(20): from to ... variantType variantName
colnames: NULL
colData names(0):
>
> sessionInfo()
R Under development (unstable) (2017-10-20 r73567)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Red Hat Enterprise Linux Server release 6.6 (Santiago)

Matrix products: default
BLAS:
/gnet/is2/p01/apps/R/3.5.0-20171105-devel/x86_64-linux-2.6-rhel6/lib64/R/lib/libRblas.so
LAPACK:
/gnet/is2/p01/apps/R/3.5.0-20171105-devel/x86_64-linux-2.6-rhel6/lib64/R/lib/libRlapack.so

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

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

other attached packages:
 [1] SGSeq_1.13.5SummarizedExperiment_1.9.16
 [3] DelayedArray_0.5.23 BiocParallel_1.13.3
 [5] matrixStats_0.53.1  Biobase_2.39.2
 [7] Rsamtools_1.31.3Biostrings_2.47.12
 [9] XVector_0.19.9  GenomicRanges_1.31.23
[11] GenomeInfoDb_1.15.5 IRanges_2.13.28
[13] S4Vectors_0.17.39   BiocGenerics_0.25.3

loaded via a namespace (and not attached):
 [1] Rcpp_0.12.16  compiler_3.5.0
 [3] GenomicFeatures_1.31.10   prettyunits_1.0.2
 [5] bitops_1.0-6  tools_3.5.0
 [7] zlibbioc_1.25.0   progress_1.1.2
 [9] biomaRt_2.35.13   digest_0.6.15
[11] bit_1.1-13RSQLite_2.1.0
[13] memoise_1.1.0 lattice_0.20-35
[15] pkgconfig_2.0.1   igraph_1.2.1
[17] Matrix_1.2-13 DBI_0.8
[19] GenomeInfoDbData_1.1.0rtracklayer_1.39.9
[21] httr_1.3.1stringr_1.3.0
[23] bit64_0.9-8   grid_3.5.0
[25] R6_2.2.2  AnnotationDbi_1.41.4
[27] XML_3.98-1.10 blob_1.1.1
[29] magrittr_1.5  GenomicAlignments_1.15.13
[31] RUnit_0.4.31  assertthat_0.2.0
[33] stringi_1.1.7 RCurl_1.95-4.10
>
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Tensorflow support for bioconductor packages

[Kieran Campbell]

Hi all,

Thanks for your replies. I had a look at the greta package
(https://github.com/greta-dev/greta) on CRAN that uses tensorflow,
which seemingly exports the install_tensorflow function but still
requires the user to call it, so it looks like that's the best way to
go for now. I'll submit our first package to bioc issues this week and
highlight this exchange, and we can take it from there.

Thanks again for all your help,

Kieran


On 30 March 2018 at 11:55, Hervé Pagès  wrote:
> FWIW the tensorflow authors didn't opt for automatic lazy installation:
>
>   > run_example("hello.R")
>   Error: Installation of TensorFlow not found.
>
>   Python environments searched for 'tensorflow' package:
>/usr/bin/python2.7
>/usr/bin/python3.5
>
>   You can install TensorFlow using the install_tensorflow() function.
>
> Would be interesting to know why.
>
> install_tensorflow() has various arguments and the chances that it
> will just work and do the right thing when called with no argument
> are low. There is also this 'restart_session' argument that is TRUE
> by default and will only work within RStudio. This suggests that after
> successful completion R needs to be restarted before the tensorflow
> package becomes operational. I didn't test that but that's something
> you might want to investigate before opting for lazy installation.
>
> Also it might help to look at how the handful of CRAN packages that
> depend on tensorflow handle this. These packages are listed in the
> reverse dependencies section of the tensorflow landing page:
>
>   https://cran.r-project.org/web/packages/tensorflow/index.html
>
> We'll install the tensorflow Python module on the build machines when
> you submit your package.
>
> Cheers,
> H.
>
>
>
> On 03/29/2018 10:08 AM, Michael Lawrence wrote:
>>
>> The problem with requiring explicit tensor flow installation is that
>> it is tantamount to a system dependency in many ways, and those are
>> annoying. Herve points out the problems with installing at load time.
>> My suggestion was to install the package the first time someone tries
>> to e.g. load an R matrix into a tensor. That way, you know that
>> examples and vignettes will always just work (if the installation
>> works) on any build machine, without any admin intervention. And, the
>> last thing a user wants when running an example is an error, even if
>> that error is easily remedied. One downside is that the user could
>> have just forgotten to point the package to a system installation of
>> tensorflow, in which case they will be cursing themselves for
>> forgetting while watching the installation process. You could check
>> for interactive() and then prompt the user to avoid that case.
>>
>> On Thu, Mar 29, 2018 at 9:44 AM, Kieran Campbell
>>  wrote:
>>>
>>> Hi Hervé, Michael,
>>>
>>> Thanks for your feedback. I will add in the reticulate check to ensure
>>> tensorflow is installed prior to running and appropriate sections in
>>> the vignettes. We have one package essentially ready for submission to
>>> bioc, so is the best route forward to submit now or wait until
>>> tensorflow is installed on the build servers?
>>>
>>> Many thanks
>>>
>>> Kieran
>>>
>>>
>>> On 28 March 2018 at 15:10, Hervé Pagès  wrote:

 On 03/28/2018 02:41 PM, Hervé Pagès wrote:
>
>
> Hi Kieran,
>
> Note that you can execute arbitrary code at load time by defining
> an .onLoad() hook in your package. So you *could* put something
> like this in your package:
>
> .onUnload <- function(libpath)
> {
>   if (!reticulate::py_module_available("tensorflow"))
>   tensorflow::install_tensorflow()
> }



 should be .onLoad() in the above code

 more below...

>
> However, having things being automatically downloaded/installed
> on the user machine at package load-time is not a good idea. There
> are just too many things that can go wrong.
>
> For example, I just tried to run tensorflow::install_tensorflow()
> on my laptop (Ubuntu 16.04) and was successful only after the 3rd
> attempt (I had to make some changes/adjustments to my system between
> each attempt). And Debian Linux is probably the easiest target!
>
> Also note that install.packages() tries to load the package at the
> end of the installation when installing from source so if the
> .onUnload() hook fails, install.packages() considers that


^^^
 .onLoad()

 same here, sorry

 H.


> the installation of the package failed and it removes it.
>
> Finally note that this installation needs to download hundreds of
> Mb of Python stuff.
>
> So this is probably the reasons why the authors of the tensorflow
> CRAN package chose to separate installation of the tensorflow Python
> module from 

[Bioc-devel] problem in rbind with DelayedArray / HDF5Array package

[Elizabeth Purdom]

Hello,

I am trying to do a rbind a normal (in memory) matrix with a HDF5Matrix object 
or DelayedArray object and I am hitting problems. I’m using the development 
version of R and bioconductor (as of 2 weeks ago) and HDF5Array_1.7.9,   
DelayedArray_0.5.23 — see sessionInfo at end of email.

Basically if I apply rbind between my normal matrix and a HDF5Matrix, I get an 
error that a method doesn't exist for a DataTable class. If I force my 
HDF5Matrix object into a DelayedMatrix object using ‘as', I either get 1) a 
warning that it doesn’t know how to select a method (even if I use 
DelayedArray::rbind in my command) or 2) In addition to the warning, an error 
that the column names don’t match, even though neither object has colnames 
(they are NULL). Which of these I get depends on the order of the entries to 
rbind — the warning-only version occurs if the DelayedMatrix object is first. 

The warning-only option version gives the correct answer, but I want to 
understand how to avoid the warning, since I am using this in a package. 

It also seems like a bug that it would matter the order of the arguments, nor 
why I need to manually manipulate the HDF5Matrix into a DelayedMatrix object in 
order to do rbind. 

Thanks,
Elizabeth Purdom

Here is my code setting up the objects:

> testdata<-matrix(rnorm(1000),nrow=100,ncol=10)
> testhdf<-HDF5Array::writeHDF5Array(testdata, "./trash.h5")
> class(testhdf)
[1] "HDF5Matrix"
attr(,"package")
[1] “HDF5Array"

Here are the errors/warnings I’m getting, some of which depend on the order of 
the entries into rbind:

> test1<-rbind(testhdf,testdata) #error is independent of order of entries
Error in rbind(...) : 
  missing 'rbind' method for DataTable class HDF5Matrix
> test2<-DelayedArray::rbind(as(testhdf,"DelayedMatrix"),testdata)
Warning message:
In methods:::.selectDotsMethod(classes, .MTable, .AllMTable) :
  multiple direct matches: "DelayedMatrix", "DataFrame"; using the first of 
these
> test3<-DelayedArray::rbind(testdata,as(testhdf,"DelayedMatrix"))
Error in rbind(...) : 
  column names for arg 2 do not match those of first arg
In addition: Warning message:
In methods:::.selectDotsMethod(classes, .MTable, .AllMTable) :
  multiple direct matches: "DataFrame", "DelayedMatrix"; using the first of 
these

> colnames(testdata)
NULL
> colnames(as(testhdf,"DelayedMatrix"))
NULL

Here is my sessionInfo:

> sessionInfo()
R Under development (unstable) (2018-03-22 r74446)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: OS X El Capitan 10.11.6

Matrix products: default
BLAS: 
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK: 
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

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

other attached packages:
[1] HDF5Array_1.7.9 rhdf5_2.23.5DelayedArray_0.5.23 
BiocParallel_1.13.3 IRanges_2.13.28
[6] S4Vectors_0.17.38   BiocGenerics_0.25.3 matrixStats_0.53.1 

loaded via a namespace (and not attached):
[1] compiler_3.5.0 tools_3.5.0Rhdf5lib_1.1.5  

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

[Bioc-devel] web browser support missing in the build system? new package, IGV

[Paul Shannon]

Perhaps my newly submitted package times out because no web browser is 
available on the build systems?

   https://github.com/paul-shannon/IGV

The build times out on linux and OS X at the “creating vignettes” stage. But 
since the package is a wrapper around igv.js running in the browser, no 
vignette, examples or unit tests are possible without a web browser to talk to.

Is this the right diagnosis?  If so, is there a remedy?  If not, I welcome 
suggestions of where to look.

 - Paul

P.S.  With the next devel build, BrowserViz - the underlying package providing 
message transport between R and the browser via websockets - should be 
available on Windows also.  So -if- browser support is missing on the build 
machines, and -if- it is reasonable to add it, then maybe we can reduce the 
maintenance burden by restricting vignette/examples/tests to one architecture.

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

Re: [Bioc-devel] Missed deadline

[Gabe Becker]

Kenneth,

I agree with Kasper. I generally like the approach of getting the software
out there sooner rather than later. Especially if the paper you are talking
about is a method paper about the software algorithm, rather than a result
paper. In that case, getting it into a public, DOI'ed repository quickly
protects you from being scooped (if that is a concern of yours, it's
generally not a super large one of mine).

This will also give the community and package reviewers a chance to give
you feedback, resulting in the paper being written about a better piece of
software when it does happen. Just like manuscripts, no (ok, *vanishingly
few *but almost surely not yours or mine) software is perfect after its
first development pass, so i'd strongly advise you not to think of your
software as 'complete' the moment you hit submit. Consider it an important
part of the development process.

Best,
~G

On Wed, Apr 4, 2018 at 4:34 AM, Kasper Daniel Hansen <
kasperdanielhan...@gmail.com> wrote:

> This is a subjective question. As a paper reviewer I like to see the
> package accepted. That increases trust.  As a package reviewer I like some
> idea of what the package actually does, so a statement like "we implement X
> which is described in (XX, in preparation), is also irritating.
>
> Unless you're trying to not show anything prior to publication (which
> happens) I like submitting the package first.
>
> On Wed, Apr 4, 2018 at 12:31 PM, Kenneth Condon 
> wrote:
>
>> Hi Gabe & Levi,
>>
>> Here is my current plan:
>>
>> 1 - complete the requirements checklist (
>> http://www.bioconductor.org/developers/package-submission/)
>> 2 - get feedback the in-house NGS team, and then from the rest of in-house
>> bioinformatics (others who use R more may spot some issues)
>> 3 - set up pull requests release on github for community testing
>> 4 - advertise github repo on bioconductor and biostars forums
>> 5 - compare to other packages
>> 6 - write paper (decide which journal)
>> 7 - have submission of paper + package ready for October deadline.
>>
>> Regarding the sequence of events - do other authors usually release on
>> bioconductor before submission of a paper or at the same time?
>> What would you recommend?
>>
>> Thanks for the help
>>
>> Kenneth
>>
>> On Tue, Apr 3, 2018 at 4:56 PM, Gabe Becker  wrote:
>>
>> > Indeed, and to be a bit more explicit about Levi's point, you *can*
>> > publish your package to bioconductor any time after the deadline, it
>> will
>> > simply go to the development repo for ~6 months, which, as he points
>> out,
>> > may not be a bad thing if it's not ready yet.
>> >
>> > On Tue, Apr 3, 2018 at 8:06 AM, Levi Waldron <
>> lwaldron.resea...@gmail.com>
>> > wrote:
>> >
>> >> On Tue, Apr 3, 2018 at 5:32 AM, Kenneth Condon 
>> >> wrote:
>> >>
>> >> > Have I missed the deadline for the latest release? I have created a
>> >> > package, that runs great but there are a number of errors still from
>> R
>> >> CMD
>> >> > check that I am sorting out.
>> >> >
>> >> > This is my first R package so I'm not sure if development is far
>> enough
>> >> > along, although I suspect it might be.
>> >> >
>> >>
>> >> IMHO, when you're not sure a package is mature enough, and especially
>> for
>> >> a
>> >> first package, it's actually better to miss the release deadline and
>> allow
>> >> bioc-devel users test your package for 6 months before entering the
>> >> release
>> >> cycle. Making significant bug fixes and other changes becomes more
>> >> complicated and more of a pain for you and your users once you are in
>> the
>> >> release...
>> >>
>> >> [[alternative HTML version deleted]]
>> >>
>> >> ___
>> >> Bioc-devel@r-project.org mailing list
>> >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> >>
>> >>
>> >
>> >
>> > --
>> > Gabriel Becker, Ph.D
>> > Scientist
>> > Bioinformatics and Computational Biology
>> > Genentech Research
>> >
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>


-- 
Gabriel Becker, Ph.D
Scientist
Bioinformatics and Computational Biology
Genentech Research

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] problem in rbind with DelayedArray / HDF5Array package

[Peter Hickey]

Does `rbind(testhdf, DelayedArray(testdata))` give you what you want?

On Wed, 4 Apr 2018 at 14:58 Elizabeth Purdom 
wrote:

> Hello,
>
> I am trying to do a rbind a normal (in memory) matrix with a HDF5Matrix
> object or DelayedArray object and I am hitting problems. I’m using the
> development version of R and bioconductor (as of 2 weeks ago) and
> HDF5Array_1.7.9,   DelayedArray_0.5.23 — see sessionInfo at end of email.
>
> Basically if I apply rbind between my normal matrix and a HDF5Matrix, I
> get an error that a method doesn't exist for a DataTable class. If I force
> my HDF5Matrix object into a DelayedMatrix object using ‘as', I either get
> 1) a warning that it doesn’t know how to select a method (even if I use
> DelayedArray::rbind in my command) or 2) In addition to the warning, an
> error that the column names don’t match, even though neither object has
> colnames (they are NULL). Which of these I get depends on the order of the
> entries to rbind — the warning-only version occurs if the DelayedMatrix
> object is first.
>
> The warning-only option version gives the correct answer, but I want to
> understand how to avoid the warning, since I am using this in a package.
>
> It also seems like a bug that it would matter the order of the arguments,
> nor why I need to manually manipulate the HDF5Matrix into a DelayedMatrix
> object in order to do rbind.
>
> Thanks,
> Elizabeth Purdom
>
> Here is my code setting up the objects:
>
> > testdata<-matrix(rnorm(1000),nrow=100,ncol=10)
> > testhdf<-HDF5Array::writeHDF5Array(testdata, "./trash.h5")
> > class(testhdf)
> [1] "HDF5Matrix"
> attr(,"package")
> [1] “HDF5Array"
>
> Here are the errors/warnings I’m getting, some of which depend on the
> order of the entries into rbind:
>
> > test1<-rbind(testhdf,testdata) #error is independent of order of entries
> Error in rbind(...) :
>   missing 'rbind' method for DataTable class HDF5Matrix
> > test2<-DelayedArray::rbind(as(testhdf,"DelayedMatrix"),testdata)
> Warning message:
> In methods:::.selectDotsMethod(classes, .MTable, .AllMTable) :
>   multiple direct matches: "DelayedMatrix", "DataFrame"; using the first
> of these
> > test3<-DelayedArray::rbind(testdata,as(testhdf,"DelayedMatrix"))
> Error in rbind(...) :
>   column names for arg 2 do not match those of first arg
> In addition: Warning message:
> In methods:::.selectDotsMethod(classes, .MTable, .AllMTable) :
>   multiple direct matches: "DataFrame", "DelayedMatrix"; using the first
> of these
>
> > colnames(testdata)
> NULL
> > colnames(as(testhdf,"DelayedMatrix"))
> NULL
>
> Here is my sessionInfo:
>
> > sessionInfo()
> R Under development (unstable) (2018-03-22 r74446)
> Platform: x86_64-apple-darwin15.6.0 (64-bit)
> Running under: OS X El Capitan 10.11.6
>
> Matrix products: default
> BLAS:
> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
> LAPACK:
> /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib
>
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> other attached packages:
> [1] HDF5Array_1.7.9 rhdf5_2.23.5DelayedArray_0.5.23
> BiocParallel_1.13.3 IRanges_2.13.28
> [6] S4Vectors_0.17.38   BiocGenerics_0.25.3 matrixStats_0.53.1
>
> loaded via a namespace (and not attached):
> [1] compiler_3.5.0 tools_3.5.0Rhdf5lib_1.1.5
>
> ___
> 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] problem in rbind with DelayedArray / HDF5Array package

[Elizabeth Purdom]

Yes that does get around the problem, thanks! 

I would note, though, that for me at least, its a workaround and not ideal 
functionality, since to use it in my function means that I now I have to have 
two different code snippets depending on whether my input object (here 
`testhdf`) is a matrix or a HDF5Matrix (rather than it automatically using the 
class definitions to give a reasonable result which is what usually happens). 

Thanks,
Elizabeth

> On Apr 4, 2018, at 9:07 PM, Peter Hickey  wrote:
> 
> Does `rbind(testhdf, DelayedArray(testdata))` give you what you want?
> 
> On Wed, 4 Apr 2018 at 14:58 Elizabeth Purdom  > wrote:
> Hello,
> 
> I am trying to do a rbind a normal (in memory) matrix with a HDF5Matrix 
> object or DelayedArray object and I am hitting problems. I’m using the 
> development version of R and bioconductor (as of 2 weeks ago) and 
> HDF5Array_1.7.9,   DelayedArray_0.5.23 — see sessionInfo at end of email.
> 
> Basically if I apply rbind between my normal matrix and a HDF5Matrix, I get 
> an error that a method doesn't exist for a DataTable class. If I force my 
> HDF5Matrix object into a DelayedMatrix object using ‘as', I either get 1) a 
> warning that it doesn’t know how to select a method (even if I use 
> DelayedArray::rbind in my command) or 2) In addition to the warning, an error 
> that the column names don’t match, even though neither object has colnames 
> (they are NULL). Which of these I get depends on the order of the entries to 
> rbind — the warning-only version occurs if the DelayedMatrix object is first.
> 
> The warning-only option version gives the correct answer, but I want to 
> understand how to avoid the warning, since I am using this in a package.
> 
> It also seems like a bug that it would matter the order of the arguments, nor 
> why I need to manually manipulate the HDF5Matrix into a DelayedMatrix object 
> in order to do rbind.
> 
> Thanks,
> Elizabeth Purdom
> 
> Here is my code setting up the objects:
> 
> > testdata<-matrix(rnorm(1000),nrow=100,ncol=10)
> > testhdf<-HDF5Array::writeHDF5Array(testdata, "./trash.h5")
> > class(testhdf)
> [1] "HDF5Matrix"
> attr(,"package")
> [1] “HDF5Array"
> 
> Here are the errors/warnings I’m getting, some of which depend on the order 
> of the entries into rbind:
> 
> > test1<-rbind(testhdf,testdata) #error is independent of order of entries
> Error in rbind(...) :
>   missing 'rbind' method for DataTable class HDF5Matrix
> > test2<-DelayedArray::rbind(as(testhdf,"DelayedMatrix"),testdata)
> Warning message:
> In methods:::.selectDotsMethod(classes, .MTable, .AllMTable) :
>   multiple direct matches: "DelayedMatrix", "DataFrame"; using the first of 
> these
> > test3<-DelayedArray::rbind(testdata,as(testhdf,"DelayedMatrix"))
> Error in rbind(...) :
>   column names for arg 2 do not match those of first arg
> In addition: Warning message:
> In methods:::.selectDotsMethod(classes, .MTable, .AllMTable) :
>   multiple direct matches: "DataFrame", "DelayedMatrix"; using the first of 
> these
> 
> > colnames(testdata)
> NULL
> > colnames(as(testhdf,"DelayedMatrix"))
> NULL
> 
> Here is my sessionInfo:
> 
> > sessionInfo()
> R Under development (unstable) (2018-03-22 r74446)
> Platform: x86_64-apple-darwin15.6.0 (64-bit)
> Running under: OS X El Capitan 10.11.6
> 
> Matrix products: default
> BLAS: 
> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
> LAPACK: 
> /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib
> 
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
> 
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
> 
> other attached packages:
> [1] HDF5Array_1.7.9 rhdf5_2.23.5DelayedArray_0.5.23 
> BiocParallel_1.13.3 IRanges_2.13.28
> [6] S4Vectors_0.17.38   BiocGenerics_0.25.3 matrixStats_0.53.1
> 
> loaded via a namespace (and not attached):
> [1] compiler_3.5.0 tools_3.5.0Rhdf5lib_1.1.5
> 
> ___
> 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