Re: [Bioc-devel] 'tokay1' error but passed other OS

2019-09-04 Thread Pages, Herve
On 9/4/19 14:10, Venu Thatikonda wrote: > @Lori, sure. I will open the issue with an example. > > @Daniel, I didn't understand, I thought this suggestion is for Lori (?). > > Do I need to run `R CMD check --force-multiarch` on a windows 32bit system > from my side? If that's the case, It won't

Re: [Bioc-devel] 'tokay1' error but passed other OS

2019-09-04 Thread Venu Thatikonda
@Lori, sure. I will open the issue with an example. @Daniel, I didn't understand, I thought this suggestion is for Lori (?). Do I need to run `R CMD check --force-multiarch` on a windows 32bit system from my side? If that's the case, It won't be practical from my side, because I have to borrow

Re: [Bioc-devel] 'tokay1' error but passed other OS

2019-09-04 Thread Kasper Daniel Hansen
Venu, you should really follow Herve's suggestion and use R CMD check --force-multiarch and report back the result. On Wed, Sep 4, 2019 at 3:32 PM Shepherd, Lori wrote: > Venu, > If you can produce a minimal example that can reproduce it and open the > issue on rtracklayer github that would be

Re: [Bioc-devel] 'tokay1' error but passed other OS

2019-09-04 Thread Shepherd, Lori
Venu, If you can produce a minimal example that can reproduce it and open the issue on rtracklayer github that would be great. Please tag me when you do so I can keep track of it also @lshep on GitHub Cheers Get Outlook for Android From:

Re: [Bioc-devel] 'tokay1' error but passed other OS

2019-09-04 Thread Venu Thatikonda
@Daniel, I guess using libBigWig cause even more problems while build, check commands as this is an non R library. But I'm not sure if this works out. @Lori, Thanks a lot for looking into the error. Interesting to see what's missing from win32. I will add the .BBSoptions file and bump the version

Re: [Bioc-devel] 'tokay1' error but passed other OS

2019-09-04 Thread Kasper Daniel Hansen
Thanks My experience with rtracklayer, bigwig and windows is indeed on some windows machines it works, and others it don't. Not sure what the deciding factor is, but if it is truly 32 vs 64 bit, that's interesiting On Wed, Sep 4, 2019 at 1:51 PM Shepherd, Lori wrote: > I looked into this more

Re: [Bioc-devel] 'tokay1' error but passed other OS

2019-09-04 Thread Pages, Herve
Also note that since the error is specific to 32-bit Windows, you need to run 'R CMD check --force-multiarch' on your package source tarball in order to reproduce the error. Without the --force-multiarch flag, 'R CMD check' only runs the examples and unit tests for the default arch, which, for

Re: [Bioc-devel] 'tokay1' error but passed other OS

2019-09-04 Thread Shepherd, Lori
I looked into this more on our builders. The examples run fine on 64 bit. This seems to be caused by a 32-bit Windows specific ERROR from the rtracklayer summary() function for BigWigFile objects. I will open an issue with rtracklayer (when I can come up with a minimal reproducible example)

Re: [Bioc-devel] 'tokay1' error but passed other OS

2019-09-04 Thread Kasper Daniel Hansen
Well, yes, its the status on the build system which matters. In your case it looks like you're doing BigWig parsing. Unfortunately, some of the tools we have for reading BigWig (tracklayer) does not work reliably on Windows - sometimes it works, sometimes it doesn't. My _guess_ is that you're

[Bioc-devel] 'tokay1' error but passed other OS

2019-09-04 Thread Venu Thatikonda
Hi, One of my packages during the review is giving an error in bioc windows system. When I build and check from my side in a windows system, there is no error. It's been over a week, not sure what's happening? Should I do something from my side? Bioc issue:

Re: [Bioc-devel] Build error due to TensorFlow installation

2019-09-04 Thread Pages, Herve
Hi Simon, On 9/3/19 09:11, Simon Dirmeier wrote: ... Do you think it would be possible to install TensorFlow and TensorFlow-Probability on the builders? I'd assume that many would profit from that. As Lori mentioned at the end of her email (see below), we can't make the tensorflow Python

Re: [Bioc-devel] Version number error

2019-09-04 Thread Turaga, Nitesh
I suspect this was a Bioconductor hook rejecting the "version" number? Is that correct Chris? Please also reply with the exact error message. Best, Nitesh > On Sep 4, 2019, at 7:58 AM, Shepherd, Lori > wrote: > > Or perhaps just providing the git commands you tried and the ERROR that was

Re: [Bioc-devel] Version number error

2019-09-04 Thread Shepherd, Lori
Or perhaps just providing the git commands you tried and the ERROR that was produced with the original 1.7.9991 would be a better place to start so we can evaluate the ERROR. Cheers, Lori Shepherd Bioconductor Core Team Roswell Park Cancer Institute Department of Biostatistics &

Re: [Bioc-devel] Version number error

2019-09-04 Thread Shepherd, Lori
normally the x.y.z of a version number we increase in whole numbers - I would try 1.7.10 It would also be helpful if you showed the commands you tried with the actually ERROR message so we could better diagnose. Please include this information if the problem is still occurring. Lori

[Bioc-devel] Version number error

2019-09-04 Thread Christopher John
Hi I tried to update M3C as follows, and I got an error. What is wrong with the new version number please? What should it be? Version: 1.7.999 --> Version: 1.7.9991 Thanks, Chris [[alternative HTML version deleted]] ___

[Bioc-devel] Fwd: Version number update problem

2019-09-04 Thread Christopher John
Hi I tried to update as follows, and I got an error. What is wrong with the new version number please? Version: 1.7.999 --> Version: 1.7.9991 Thanks, Chris [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list

Re: [Bioc-devel] EXTERNAL: MultiAssayExperiment silently converting RangedSummarizedExperiments into SummarizedExperiments.

2019-09-04 Thread Pages, Herve
Hi Marcel, Charles, Looks like S4Vectors:::coerceToSimpleList() is being to zealous here. I've tweaked the function a little (in S4Vectors 0.23.21) so that elements in the supplied list get coerced only when the 2nd argument (element.type) is specified. This fixes both Marcel's and Charles'