date:20190904

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 be practical from my side,
> because I have to borrow someone's system who is using win32. If not, I ran
> it on macOS with '--force-multiarch' and it's clean. Except one note about
> '.BBSoptions' file, I guess it's okay? Any clarifications would be
> appreciated.

Short answer: The suggestion to run 'R CMD check --force-multiarch' was 
for you so you can reproduce the error.

Long answer: Any Windows system I know from the last 15 years or so can 
run processes in 64-bit or 32-bit mode. As you can see here

   https://cran.r-project.org/bin/windows/base/

the Windows binary for R that is available on CRAN is a 32/64 bit 
binary. This means that it can be run in either mode. You can choose the 
mode in which you want to run R by specifying --arch x64 or --arch i386 
when invoking R. The 64-bit mode is the default so starting R with 'R 
--arch x64' is the same as just starting it with 'R'. The startup 
message tells you if R is running in 64-bit or 32-bit mode.

Now about packages: You can check your package with 'R --arch x64 CMD 
check' (or just 'R CMD check') in which case all the examples and unit 
tests are run in 64-bit mode. If you check your package with 'R --arch 
i386 CMD check' then all the examples and unit tests are run in 32-bit 
mode. If you check your package with 'R CMD check --force-multiarch' 
then all the examples and unit tests are run in both 32-bit and 64-bit. 
This is the recommended way to fully check a package on Windows. Note 
that this is also what our build system does. See for example the 
command used to check the Biobase package on our Windows server tokay1:
https://bioconductor.org/checkResults/3.10/bioc-LATEST/Biobase/tokay1-checksrc.html

AFAIK almost nobody runs R in 32-bit mode on Windows these days so it is 
not a big deal to mark your package as unsupported on 32-bit Windows. 
The only reason we check that packages run fine on 32-bit Windows is 
because we **distribute** Windows binary packages that are also 32/64 
bit binaries (like R itself) and we want to make sure that the bi-arch 
binaries work as expected. And the only reason we distribute these 
Windows bi-arch binaries is because that's what the CRAN folks do.

Hope this helps,

H.

> 
> Thank you.
> 
> 
> On Wed, Sep 4, 2019 at 9:38 PM Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com> wrote:
> 
>> 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 <
>> lori.sheph...@roswellpark.org> wrote:
>>
>>> 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:* Venu Thatikonda 
>>> *Sent:* Wednesday, September 4, 2019 3:11:56 PM
>>> *To:* Kasper Daniel Hansen 
>>> *Cc:* Shepherd, Lori ; bioc-devel <
>>> bioc-devel@r-project.org>
>>> *Subject:* Re: [Bioc-devel] 'tokay1' error but passed other OS
>>>
>>> @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 as
>>> suggested. I can create a small example to reproduce the error(?), to open
>>> an issue at rtracklayer, please let me know if that's okay.
>>>
>>> Thank you.
>>>
>>> On Wed, Sep 4, 2019 at 8:50 PM Kasper Daniel Hansen <
>>> kasperdanielhan...@gmail.com> wrote:
>>>
 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 <
 lori.sheph...@roswellpark.org> wrote:

> 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) and will post the issue link in your open
> issue on the Contributions

[R-pkg-devel] DESCRIPTION file errors

2019-09-04 Thread Eric Leifer

Hello,
I submitted a new package to CRAN, and received the following error message.
# start error message
 Possibly mis-spelled words in DESCRIPTION:
Bunn (12:30)
Couper (12:39)
EV (11:10)
Follmann (14:40)
JF (14:25)
Kolecki (14:29)
Leifer (14:5)
Slud (11:5)
Troendle (14:16)

  Malformed Description field: should contain one or more complete
sentences.
# end error message
I believe I am getting the error message because I am including references
in the Description field of my DESCRIPTION file.  Here's what my
Description field looks like:
# start Description field
Description:
Used for the design and analysis of a 2x2 factorial trial for
a time-to-event endpoint.  Performs power calculations and significance
testing.  Important reference papers include
Slud EV. (1994) 
Lin DY, Gong J, Gallo P, Bunn PH, Couper D. (2016)

Leifer ES, Troendle JF, Kolecki A, Follmann DA. (2019)
<
https://github.com/EricSLeifer/factorial2x2/blob/master/Leifer%20et%20al%20Factorial.pdf
>
# end Description field
Question:  should I be including my references in a different format in the
Description field?  Should I include references in my DESCRIPTION file at
all?

Thank you in advance for any help.
Eric

[[alternative HTML version deleted]]

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

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 someone's system who is using win32. If not, I ran
it on macOS with '--force-multiarch' and it's clean. Except one note about
'.BBSoptions' file, I guess it's okay? Any clarifications would be
appreciated.

Thank you.

On Wed, Sep 4, 2019 at 9:38 PM Kasper Daniel Hansen <
kasperdanielhan...@gmail.com> wrote:

> 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 <
> lori.sheph...@roswellpark.org> wrote:
>
>> 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:* Venu Thatikonda 
>> *Sent:* Wednesday, September 4, 2019 3:11:56 PM
>> *To:* Kasper Daniel Hansen 
>> *Cc:* Shepherd, Lori ; bioc-devel <
>> bioc-devel@r-project.org>
>> *Subject:* Re: [Bioc-devel] 'tokay1' error but passed other OS
>>
>> @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 as
>> suggested. I can create a small example to reproduce the error(?), to open
>> an issue at rtracklayer, please let me know if that's okay.
>>
>> Thank you.
>>
>> On Wed, Sep 4, 2019 at 8:50 PM Kasper Daniel Hansen <
>> kasperdanielhan...@gmail.com> wrote:
>>
>>> 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 <
>>> lori.sheph...@roswellpark.org> wrote:
>>>
 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) and will post the issue link in your open
 issue on the Contributions tracker to also monitor.

 In the meantime you could add a file  .BBSoptions that contains the
 line UnsupportedPlatforms: win32  to get an accurate build report and avoid
 building on the 32 bit window until the issue is resolved.

 Lori Shepherd

 Bioconductor Core Team

 Roswell Park Cancer Institute

 Department of Biostatistics & Bioinformatics

 Elm & Carlton Streets

 Buffalo, New York 14263
 --
 *From:* Bioc-devel  on behalf of
 Kasper Daniel Hansen 
 *Sent:* Wednesday, September 4, 2019 1:41:28 PM
 *To:* Venu Thatikonda 
 *Cc:* bioc-devel 
 *Subject:* Re: [Bioc-devel] 'tokay1' error but passed other OS

 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 running into this.

 It would be great to get this fixed, although that is not your package's
 issue.  One possible alternative is
 https://github.com/dpryan79/libBigWig
 which Brent Peterson recommends. I don't know if that works on Windows,
 but
 at least its not Kent tools.

 Best,
 Kasper

 On Wed, Sep 4, 2019 at 11:45 AM Venu Thatikonda >>> >
 wrote:

 > 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: https://github.com/Bioconductor/Contributions/issues/1215
 >
 > Build report:
 >
 http://bioconductor.org/spb_reports/ALPS_buildreport_20190827110407.html
 >
 > Any update/suggestions would be helpful.
 >
 > Thank you.
 >
 > --
 > Best regards
 > Venu Thatikonda
 > https://itsvenu.github.io/
 >
 > [[alternative HTML version deleted]]
 >
 >

Re: [Rd] reverse dependency checks

2019-09-04 Thread Iñaki Ucar

On Tue, 3 Sep 2019 at 14:53, Therneau, Terry M., Ph.D. via R-devel
 wrote:
>
> I remember there was advice about a server that one could use for reverse 
> dependency
> checks, but I forgot to write it down.  (Or I did save the info and forgot 
> where I saved
> it...)   I have been doing the checks for survival myself, but the count is 
> getting out of
> hand (663, not counting bioconductor).
>
> Any pointers?

You could try Yihui's crandalf [1]. Locally, I don't know what you are
using, but there are a few alternatives. Notably, Dirk's prrd [2] (the
only one that I tried myself and I can thus recommend), Gabor's
revdepcheck [3] and R's brand new tools::check_packages_in_dir().

[1] https://github.com/yihui/crandalf
[2] https://github.com/eddelbuettel/prrd
[3] https://github.com/r-lib/revdepcheck

Iñaki

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

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

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 great.  Please tag me when you do
> so I can keep track of it also @lshep on GitHub
> Cheers
>
> Get Outlook for Android 
>
> --
> *From:* Venu Thatikonda 
> *Sent:* Wednesday, September 4, 2019 3:11:56 PM
> *To:* Kasper Daniel Hansen 
> *Cc:* Shepherd, Lori ; bioc-devel <
> bioc-devel@r-project.org>
> *Subject:* Re: [Bioc-devel] 'tokay1' error but passed other OS
>
> @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 as
> suggested. I can create a small example to reproduce the error(?), to open
> an issue at rtracklayer, please let me know if that's okay.
>
> Thank you.
>
> On Wed, Sep 4, 2019 at 8:50 PM Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com> wrote:
>
>> 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 <
>> lori.sheph...@roswellpark.org> wrote:
>>
>>> 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) and will post the issue link in your open issue on
>>> the Contributions tracker to also monitor.
>>>
>>>
>>> In the meantime you could add a file  .BBSoptions that contains the line
>>> UnsupportedPlatforms: win32  to get an accurate build report and avoid
>>> building on the 32 bit window until the issue is resolved.
>>>
>>>
>>> Lori Shepherd
>>>
>>> Bioconductor Core Team
>>>
>>> Roswell Park Cancer Institute
>>>
>>> Department of Biostatistics & Bioinformatics
>>>
>>> Elm & Carlton Streets
>>>
>>> Buffalo, New York 14263
>>> --
>>> *From:* Bioc-devel  on behalf of
>>> Kasper Daniel Hansen 
>>> *Sent:* Wednesday, September 4, 2019 1:41:28 PM
>>> *To:* Venu Thatikonda 
>>> *Cc:* bioc-devel 
>>> *Subject:* Re: [Bioc-devel] 'tokay1' error but passed other OS
>>>
>>> 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 running into this.
>>>
>>> It would be great to get this fixed, although that is not your package's
>>> issue.  One possible alternative is
>>> https://github.com/dpryan79/libBigWig
>>> which Brent Peterson recommends. I don't know if that works on Windows,
>>> but
>>> at least its not Kent tools.
>>>
>>> Best,
>>> Kasper
>>>
>>> On Wed, Sep 4, 2019 at 11:45 AM Venu Thatikonda 
>>> wrote:
>>>
>>> > 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: https://github.com/Bioconductor/Contributions/issues/1215
>>> >
>>> > Build report:
>>> >
>>> http://bioconductor.org/spb_reports/ALPS_buildreport_20190827110407.html
>>> >
>>> > Any update/suggestions would be helpful.
>>> >
>>> > Thank you.
>>> >
>>> > --
>>> > Best regards
>>> > Venu Thatikonda
>>> > https://itsvenu.github.io/
>>> >
>>> > [[alternative HTML version deleted]]
>>> >
>>> > ___
>>> > Bioc-devel@r-project.org mailing list
>>> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>> >
>>>
>>>
>>> --
>>> Best,
>>> Kasper
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> ___
>>> Bioc-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>
>>> 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

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

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: Venu Thatikonda 
Sent: Wednesday, September 4, 2019 3:11:56 PM
To: Kasper Daniel Hansen 
Cc: Shepherd, Lori ; bioc-devel 

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

@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 as 
suggested. I can create a small example to reproduce the error(?), to open an 
issue at rtracklayer, please let me know if that's okay.

Thank you.

On Wed, Sep 4, 2019 at 8:50 PM Kasper Daniel Hansen 
mailto:kasperdanielhan...@gmail.com>> wrote:
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 
mailto:lori.sheph...@roswellpark.org>> wrote:

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) and will post the issue link in your open issue on the 
Contributions tracker to also monitor.

In the meantime you could add a file  .BBSoptions that contains the line 
UnsupportedPlatforms: win32  to get an accurate build report and avoid building 
on the 32 bit window until the issue is resolved.

Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263

From: Bioc-devel 
mailto:bioc-devel-boun...@r-project.org>> on 
behalf of Kasper Daniel Hansen 
mailto:kasperdanielhan...@gmail.com>>
Sent: Wednesday, September 4, 2019 1:41:28 PM
To: Venu Thatikonda mailto:thatikond...@gmail.com>>
Cc: bioc-devel mailto:bioc-devel@r-project.org>>
Subject: Re: [Bioc-devel] 'tokay1' error but passed other OS

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 running into this.

It would be great to get this fixed, although that is not your package's
issue.  One possible alternative is https://github.com/dpryan79/libBigWig
which Brent Peterson recommends. I don't know if that works on Windows, but
at least its not Kent tools.

Best,
Kasper

On Wed, Sep 4, 2019 at 11:45 AM Venu Thatikonda 
mailto:thatikond...@gmail.com>>
wrote:

> 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: https://github.com/Bioconductor/Contributions/issues/1215
>
> Build report:
> http://bioconductor.org/spb_reports/ALPS_buildreport_20190827110407.html
>
> Any update/suggestions would be helpful.
>
> Thank you.
>
> --
> Best regards
> Venu Thatikonda
> https://itsvenu.github.io/
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

--
Best,
Kasper

[[alternative HTML version deleted]]

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

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.

--
Best,
Kasper

--
Best regards
Venu Thatikonda
https://itsvenu.github.io/

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

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 as
suggested. I can create a small example to reproduce the error(?), to open
an issue at rtracklayer, please let me know if that's okay.

Thank you.

On Wed, Sep 4, 2019 at 8:50 PM Kasper Daniel Hansen <
kasperdanielhan...@gmail.com> wrote:

> 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 <
> lori.sheph...@roswellpark.org> wrote:
>
>> 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) and will post the issue link in your open issue on
>> the Contributions tracker to also monitor.
>>
>>
>> In the meantime you could add a file  .BBSoptions that contains the line
>> UnsupportedPlatforms: win32  to get an accurate build report and avoid
>> building on the 32 bit window until the issue is resolved.
>>
>>
>> Lori Shepherd
>>
>> Bioconductor Core Team
>>
>> Roswell Park Cancer Institute
>>
>> Department of Biostatistics & Bioinformatics
>>
>> Elm & Carlton Streets
>>
>> Buffalo, New York 14263
>> --
>> *From:* Bioc-devel  on behalf of
>> Kasper Daniel Hansen 
>> *Sent:* Wednesday, September 4, 2019 1:41:28 PM
>> *To:* Venu Thatikonda 
>> *Cc:* bioc-devel 
>> *Subject:* Re: [Bioc-devel] 'tokay1' error but passed other OS
>>
>> 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 running into this.
>>
>> It would be great to get this fixed, although that is not your package's
>> issue.  One possible alternative is https://github.com/dpryan79/libBigWig
>> which Brent Peterson recommends. I don't know if that works on Windows,
>> but
>> at least its not Kent tools.
>>
>> Best,
>> Kasper
>>
>> On Wed, Sep 4, 2019 at 11:45 AM Venu Thatikonda 
>> wrote:
>>
>> > 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: https://github.com/Bioconductor/Contributions/issues/1215
>> >
>> > Build report:
>> >
>> http://bioconductor.org/spb_reports/ALPS_buildreport_20190827110407.html
>> >
>> > Any update/suggestions would be helpful.
>> >
>> > Thank you.
>> >
>> > --
>> > Best regards
>> > Venu Thatikonda
>> > https://itsvenu.github.io/
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > ___
>> > Bioc-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> >
>>
>>
>> --
>> Best,
>> Kasper
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>> 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.
>
>
>
> --
> Best,
> Kasper
>


-- 
Best regards
Venu Thatikonda
https://itsvenu.github.io/

[[alternative HTML version deleted]]

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

Re: [Rd] reverse dependency checks

2019-09-04 Thread Juan Telleria Ruiz de Aguirre

https://builder.r-hub.io/

El martes, 3 de septiembre de 2019, Therneau, Terry M., Ph.D. via R-devel <
r-devel@r-project.org> escribió:

> I remember there was advice about a server that one could use for reverse
> dependency
> checks, but I forgot to write it down.  (Or I did save the info and forgot
> where I saved
> it...)   I have been doing the checks for survival myself, but the count
> is getting out of
> hand (663, not counting bioconductor).
>
> Any pointers?
>
> Terry Therneau
>
>
> [[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: [Bioc-devel] 'tokay1' error but passed other OS

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 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) and will post the issue link in your open issue on
> the Contributions tracker to also monitor.
>
>
> In the meantime you could add a file  .BBSoptions that contains the line
> UnsupportedPlatforms: win32  to get an accurate build report and avoid
> building on the 32 bit window until the issue is resolved.
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Cancer Institute
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
> --
> *From:* Bioc-devel  on behalf of Kasper
> Daniel Hansen 
> *Sent:* Wednesday, September 4, 2019 1:41:28 PM
> *To:* Venu Thatikonda 
> *Cc:* bioc-devel 
> *Subject:* Re: [Bioc-devel] 'tokay1' error but passed other OS
>
> 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 running into this.
>
> It would be great to get this fixed, although that is not your package's
> issue.  One possible alternative is https://github.com/dpryan79/libBigWig
> which Brent Peterson recommends. I don't know if that works on Windows, but
> at least its not Kent tools.
>
> Best,
> Kasper
>
> On Wed, Sep 4, 2019 at 11:45 AM Venu Thatikonda 
> wrote:
>
> > 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: https://github.com/Bioconductor/Contributions/issues/1215
> >
> > Build report:
> > http://bioconductor.org/spb_reports/ALPS_buildreport_20190827110407.html
> >
> > Any update/suggestions would be helpful.
> >
> > Thank you.
> >
> > --
> > Best regards
> > Venu Thatikonda
> > https://itsvenu.github.io/
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
>
> --
> Best,
> Kasper
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> 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.



-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

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

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 99.99% of Windows users is the 64-bit arch.

H.


On 9/4/19 10:51, Shepherd, Lori wrote:
> 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) and will post the issue link in your open issue on the 
> Contributions tracker to also monitor.
> 
> 
> In the meantime you could add a file  .BBSoptions that contains the line 
> UnsupportedPlatforms: win32  to get an accurate build report and avoid 
> building on the 32 bit window until the issue is resolved.
> 
> 
> Lori Shepherd
> 
> Bioconductor Core Team
> 
> Roswell Park Cancer Institute
> 
> Department of Biostatistics & Bioinformatics
> 
> Elm & Carlton Streets
> 
> Buffalo, New York 14263
> 
> 
> From: Bioc-devel  on behalf of Kasper 
> Daniel Hansen 
> Sent: Wednesday, September 4, 2019 1:41:28 PM
> To: Venu Thatikonda 
> Cc: bioc-devel 
> Subject: Re: [Bioc-devel] 'tokay1' error but passed other OS
> 
> 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 running into this.
> 
> It would be great to get this fixed, although that is not your package's
> issue.  One possible alternative is 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dpryan79_libBigWig=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=cLVKSXICD34PS8AZqtoyaNp-NKH4jvXvlMjVW8jt_0s=ujpFo4P7955D90ROfqBqHGmRhZnyQQXnY-dRu0IrCHg=
> which Brent Peterson recommends. I don't know if that works on Windows, but
> at least its not Kent tools.
> 
> Best,
> Kasper
> 
> On Wed, Sep 4, 2019 at 11:45 AM Venu Thatikonda 
> wrote:
> 
>> 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: 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Bioconductor_Contributions_issues_1215=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=cLVKSXICD34PS8AZqtoyaNp-NKH4jvXvlMjVW8jt_0s=auK8S9mNR1K0mIEc6Dyi8jeHYdf6Ijtzg29zCGvjdRw=
>>
>> Build report:
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_spb-5Freports_ALPS-5Fbuildreport-5F20190827110407.html=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=cLVKSXICD34PS8AZqtoyaNp-NKH4jvXvlMjVW8jt_0s=j5hCJlgAQJoMHlJFjSemKuaI7vmqAT90vBkVeTmXP5s=
>>
>> Any update/suggestions would be helpful.
>>
>> Thank you.
>>
>> --
>> Best regards
>> Venu Thatikonda
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__itsvenu.github.io_=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=cLVKSXICD34PS8AZqtoyaNp-NKH4jvXvlMjVW8jt_0s=6PbKmuIeMjhsNWRno7PAuILcsvVkhURn29ZwDQkuzCY=
>>
>>  [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=cLVKSXICD34PS8AZqtoyaNp-NKH4jvXvlMjVW8jt_0s=-lNwAVk3ZfGl_BHMfLr8DZ70ZaK5S86ONSjxMJVtu_s=
>>
> 
> 
> --
> Best,
> Kasper
> 
>  [[alternative HTML version deleted]]
> 
> ___
> Bioc-devel@r-project.org mailing list
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=cLVKSXICD34PS8AZqtoyaNp-NKH4jvXvlMjVW8jt_0s=-lNwAVk3ZfGl_BHMfLr8DZ70ZaK5S86ONSjxMJVtu_s=
> 
> 
> 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.
>   [[alternative HTML version deleted]]
> 
>

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

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) and will post the issue link in your open issue on the 
Contributions tracker to also monitor.

In the meantime you could add a file  .BBSoptions that contains the line 
UnsupportedPlatforms: win32  to get an accurate build report and avoid building 
on the 32 bit window until the issue is resolved.

Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263

From: Bioc-devel  on behalf of Kasper Daniel 
Hansen 
Sent: Wednesday, September 4, 2019 1:41:28 PM
To: Venu Thatikonda 
Cc: bioc-devel 
Subject: Re: [Bioc-devel] 'tokay1' error but passed other OS

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 running into this.

It would be great to get this fixed, although that is not your package's
issue.  One possible alternative is https://github.com/dpryan79/libBigWig
which Brent Peterson recommends. I don't know if that works on Windows, but
at least its not Kent tools.

Best,
Kasper

On Wed, Sep 4, 2019 at 11:45 AM Venu Thatikonda 
wrote:

> 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: https://github.com/Bioconductor/Contributions/issues/1215
>
> Build report:
> http://bioconductor.org/spb_reports/ALPS_buildreport_20190827110407.html
>
> Any update/suggestions would be helpful.
>
> Thank you.
>
> --
> Best regards
> Venu Thatikonda
> https://itsvenu.github.io/
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

--
Best,
Kasper

[[alternative HTML version deleted]]

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

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.
[[alternative HTML version deleted]]

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

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

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 running into this.

It would be great to get this fixed, although that is not your package's
issue.  One possible alternative is https://github.com/dpryan79/libBigWig
which Brent Peterson recommends. I don't know if that works on Windows, but
at least its not Kent tools.

Best,
Kasper

On Wed, Sep 4, 2019 at 11:45 AM Venu Thatikonda 
wrote:

> 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: https://github.com/Bioconductor/Contributions/issues/1215
>
> Build report:
> http://bioconductor.org/spb_reports/ALPS_buildreport_20190827110407.html
>
> Any update/suggestions would be helpful.
>
> Thank you.
>
> --
> Best regards
> Venu Thatikonda
> https://itsvenu.github.io/
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

[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: https://github.com/Bioconductor/Contributions/issues/1215

Build report:
http://bioconductor.org/spb_reports/ALPS_buildreport_20190827110407.html

Any update/suggestions would be helpful.

Thank you.

-- 
Best regards
Venu Thatikonda
https://itsvenu.github.io/

[[alternative HTML version deleted]]

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

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

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 module available on our Windows builders at the moment
because we need to update Python to Python 3 on these machines first (AFAIK
tensorflow is only available for Python 3 on Windows). This is something that
we are currently working on.

As for the Mac builders, we have tensorflow there but unfortunately it's an old
version because recent versions of are broken on El Capitan (this is the Mac OS
version that, for various reasons, we are stuck with at the moment). This
prevents us from installing the tensorflow_probability module which requires a
recent version of tensorflow.

The tensorflow and tensorflow_probability modules are available on our Linux
builders.

All this means that if you replace some old C++ code with TensorFlow then we
will need to mark your package as unavailable on Windows and Mac, at least for
now. Sorry. I wonder if there was something wrong with this old C++ code. I
would recommend that you stick to it if you can.

Best,

Right now tensorflow is unavailable on our windows server (tokay1)�as
we have not updated to python 3 (but will be in the near future)� The
windows error can be ignored for now.

Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263

*From:* Bioc-devel
on
behalf of
Simon Dirmeier
*Sent:* Monday, September 2, 2019 6:08:45 AM
*To:* bioc-devel@r-project.org

*Subject:* [Bioc-devel] Build error due to TensorFlow installation
Dear all,

since I replaced some old C++ code with TensorFlow I am getting some
build errors on merida1 and tokay1 regarding installation (even though I
install TF and TF Probability during /.onLoad/)

https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_netReg_merida1-2Dbuildsrc.html=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Iy8WHNH6twF-8QkJjKa7MOIXm9mYjGg4pBlLb2CGiq8=wjC8b2uCm0PJgQ1LRO_CTrqNvfGKpEKN0N6QN23Sbd0=

Does anyone know how I can fix this or did anyone use TF with
Bioconductor so far?

Many thanks in advance.

Best,

Simon

��� [[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Iy8WHNH6twF-8QkJjKa7MOIXm9mYjGg4pBlLb2CGiq8=98vYdk5e2ryxlWN99O68ty2dUHnoE23VPU9TwSF8rPc=

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.

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Iy8WHNH6twF-8QkJjKa7MOIXm9mYjGg4pBlLb2CGiq8=98vYdk5e2ryxlWN99O68ty2dUHnoE23VPU9TwSF8rPc=

--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319

[[alternative HTML version deleted]]

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

Re: [Rd] [ALTREP] What is the meaning of the return value of Is_sorted and No_NA function?

2019-09-04 Thread Wang Jiefei

Hi,

I've found the answers to my questions:

1. For sort function, here are some macros defined in Rinternal.h:
/* ALTREP sorting support */
enum {SORTED_DECR_NA_1ST = -2,
  SORTED_DECR = -1,
  UNKNOWN_SORTEDNESS = INT_MIN, /*INT_MIN is NA_INTEGER! */
  SORTED_INCR = 1,
  SORTED_INCR_NA_1ST = 2,
  KNOWN_UNSORTED = 0};

The macro names are pretty self-explanatory. The current implementation
only supports the ascending sort.

2. For anyNA, it goes to(Real SEXP)

===coerce.c===
if(REAL_NO_NA(x))
   return FALSE;
ITERATE_BY_REGION(x, xD, i, nbatch, double, REAL, {
for (int k = 0; k < nbatch; k++)
   if (ISNAN(xD[k]))
return TRUE;
   });

===altrep.c===
int REAL_NO_NA(SEXP x)
{
return ALTREP(x) ? ALTREAL_DISPATCH(No_NA, x) : 0;
}

If the argument x is not an ALTREP, the function will return 0, and a
default method will be used, so there is no way to return true without loop
over the argument x right now. I hope this could be changed in the future.

Best,
Jiefei





On Tue, Sep 3, 2019 at 2:49 PM Wang Jiefei  wrote:

> Hi,
>
>
>
> I would like to figure out the meaning of the return value of these two
> functions. Here are the default definitions I find from R source code:
>
>
>
> static int altreal_Is_sorted_default(SEXP x) { return UNKNOWN_SORTEDNESS;
> }
>
> static int altreal_No_NA_default(SEXP x) { return 0; }
>
> I guess the macro *UNKNOWN_SORTEDNESS *in *Is_sorted* and 0 in *No_NA *simply 
> means
> unknown sorted/NA status of the vector, so R will loop over the vector and
> find the answer. However, what should we return in these functions to
> indicate whether the vector has been sorted/ contains NA? My initial guess
> is 0/1 but since *NA_NA *uses 0 as its default value so it will be
> ambiguous. Are there any macros to define yes/no return values for these
> functions? I would appreciate any thought here.
>
>
>
> Best,
>
> Jiefei
>
>
>

[[alternative HTML version deleted]]

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

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 
> 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 & Bioinformatics
> 
> Elm & Carlton Streets
> 
> Buffalo, New York 14263
> 
> 
> From: Bioc-devel  on behalf of Christopher 
> John 
> Sent: Wednesday, September 4, 2019 5:48:54 AM
> To: bioc-devel@r-project.org 
> Subject: [Bioc-devel] Version number error
> 
> 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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> 
> 
> 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.
>   [[alternative HTML version deleted]]
> 
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

[Rd] '==' operator: inconsistency in data.frame(...) == NULL

2019-09-04 Thread Hilmar Berger

Dear all,

I just stumbled upon some behavior of the == operator which is at least 
somewhat inconsistent.

R version 3.6.1 (2019-07-05) -- "Action of the Toes"
Copyright (C) 2019 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)

 > list(a=1:3, b=LETTERS[1:3]) == NULL
logical(0)
 > matrix(1:6, 2,3) == NULL
logical(0)
 > data.frame(a=1:3, b=LETTERS[1:3]) == NULL # same for == logical(0)
Error in matrix(if (is.null(value)) logical() else value, nrow = nr, 
dimnames = list(rn,  :
   length of 'dimnames' [2] not equal to array extent

 > data.frame(NULL) == 1
<0 x 0 matrix>
 > data.frame(NULL) == NULL
<0 x 0 matrix>
 > data.frame(NULL) == logical(0)
<0 x 0 matrix>

I wonder if data.frame() == NULL should also return 
a value instead of an error. R help reads:

"At least one of |x| and |y| must be an atomic vector, but if the other 
is a list *R* attempts to coerce it to the type of the atomic vector: 
this will succeed if the list is made up of elements of length one that 
can be coerced to the correct type.

If the two arguments are atomic vectors of different types, one is 
coerced to the type of the other, the (decreasing) order of precedence 
being character, complex, numeric, integer, logical and raw."

It is not clear from the help what to expect for NULL or empty atomic 
vectors. It is also strange that for list() there is no error but for 
data.frame() with the same data an error is thrown. I can see that there 
might be reasons to return logical(0) instead of FALSE, but I do not 
fully understand why there should be differences between e.g. matrix() 
and data.frame().

Also, It is at least somewhat strange that data.frame(NULL) == NULL and 
similar expressions return an empty matrix, while comparing a normal 
filled matrix to NULL returns logical(0).

Even if this behavior is expected, the error message shown by 
data.frame(...) == NULL is not very informative.

Thanks and best regards,

Hilmar





[[alternative HTML version deleted]]

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

Re: [Rd] possible bug in R's configure check for C++11 features

I'm sorry, I'm an idiot for not noticing this. That's what happens when you
have been stuck in configure/make hell for a while.

Best,
Kasper

On Tue, Sep 3, 2019 at 10:54 PM Simon Urbanek 
wrote:

> Kasper,
>
> I haven’t checked in depth, so just to clarify: you *are* setting
> CXX11=g++ so it is doing what you asked it to. Since the settings are
> inherited upwards, this implies that you are setting both CXX14 and CXX17
> to g++. So I’m not quite sure I understand your concern.
>
> Cheers,
> Simon
>
>
>
> > On Sep 3, 2019, at 9:02 PM, Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com> wrote:
> >
> > I am trying to compile R under a new setup, and frankly, I have had a lot
> > of problems, but I think the stuff below points to a possible bug in R's
> > (custom) configure checks for C++11/14/17, but not for C++98.
> >
> > This is a report about R from the R-3-6 branch, with a svn checkout from
> > today, revision r77135.
> >
> > In my case the compiler name is x86_64-conda_cos6-linux-gnu-g++, not
> g++. I
> > denote this in my configure call, using the CC variable. A snippet of the
> > full configure is
> >
> > ../${SRCDIR}/configure SHELL='/bin/bash' \
> >   --prefix="${CONDA_PREFIX}/R/${R_VERSION}" \
> >   CC="x86_64-conda_cos6-linux-gnu-gcc" \
> >   CXX="x86_64-conda_cos6-linux-gnu-g++" \
> >   F77="x86_64-conda_cos6-linux-gnu-gfortran" \
> >   FC="$F77" \
> >   CFLAGS="-Wall -mtune=amdfam10 -g -O2 -I${CONDA_PREFIX}/include"\
> >   CXXFLAGS="-Wall -mtune=amdfam10 -g -O2 -I${CONDA_PREFIX}/include" \
> >   F77FLAGS="-Wall -g -O2 -mtune=amdfam10 -I${CONDA_PREFIX}/include" \
> >   CXX11="g++" \
> >   CXX11STD="-std=c++11" \
> >   CXX11FLAGS="-Wall -mtune=amdfam10 -g -O2 -I${CONDA_PREFIX}/include" \
> >   CXX11PICFLAGS="-fPIC" \
> >
> > Where $CONDA_PREFIX is given in my script.
> >
> > The output in config.log is given below. Note that in the test for c++98,
> > it uses the "right" CC, but in the test for c++11 it uses g++. This looks
> > wrong to me:
> >
> > configure:28111: checking whether x86_64-conda_cos6-linux-gnu-g++
> supports
> > C++98 features with -std=gnu++98
> > configure:28130: x86_64-conda_cos6-linux-gnu-g++  -std=gnu++98 -c -Wall
> > -mtune=amdfam10 -g -O2
> > -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
> > -fpic -DNDEBUG -D_FORTIFY_SOURCE=2 -O2 conftest.cp
> > p >&5
> > configure:28130: $? = 0
> > configure:28139: result: yes
> > configure:28315: checking whether g++ -std=c++11 supports C++11 features
> > configure:28607: g++ -std=c++11 -c -Wall -mtune=amdfam10 -g -O2
> > -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
> > -fPIC -DNDEBUG -D_FORTIFY_SOURCE=2 -O2 conftest.cpp >&5
> > ../R-3.6-src/configure: line 2355: g++: command not found
> > configure:28607: $? = 127
> > configure: failed program was:
> >
> > I have similar issues (wrong CC using when compiling the test program)
> with
> > the test for c++14, whereas the test for c++17 has empty space where the
> CC
> > variable should be?
> >
> > I can fix this issue by adding a soft link in my PATH from g++ to my
> > compiler of choice. In this case configure finishes and reports that I
> have
> > full C++17 capabilities. Weirdly, in the output, note that the C++
> compiler
> > is "wrong" again, despite my configure call:
> >
> >  Source directory:../R-3.6-src
> >  Installation directory:
> > /jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/R/3.6
> >
> >  C compiler:  x86_64-conda_cos6-linux-gnu-gcc  -Wall
> > -mtune=amdfam10 -g -O2
> > -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
> >  Fortran fixed-form compiler:
> >
> /jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/bin/x86_64-conda_cos6-linux-gnu-gfortran
> > -fno-optimize-sibling-calls -fopenmp -march=nocona -mtune=haswell
> > -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2
> > -ffunction-sections -pipe
> >
> >  Default C++ compiler:g++ -std=c++11   -Wall -mtune=amdfam10 -g
> > -O2
> -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
> >  C++98 compiler:  x86_64-conda_cos6-linux-gnu-g++
> -std=gnu++98
> > -Wall -mtune=amdfam10 -g -O2
> > -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
> >  C++11 compiler:  g++ -std=c++11   -Wall -mtune=amdfam10 -g
> > -O2
> -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
> >  C++14 compiler:  g++ -std=gnu++14   -Wall -mtune=amdfam10 -g
> > -O2
> -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
> >  C++17 compiler:  g++ -std=gnu++17  -Wall -mtune=amdfam10 -g
> > -O2
> -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
> >  Fortran free-form compiler:
> >
> /jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/bin/x86_64-conda_cos6-linux-gnu-gfortran
> > -fno-optimize-sibling-calls
> >  Obj-C compiler:
> >
> >
> >
> >

Re: [Bioc-devel] Version number error

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 & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Christopher 
John 
Sent: Wednesday, September 4, 2019 5:48:54 AM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] Version number error

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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


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.
[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Version number error

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 Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Christopher 
John 
Sent: Wednesday, September 4, 2019 5:48:54 AM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] Version number error

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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


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.
[[alternative HTML version deleted]]

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

[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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[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
https://stat.ethz.ch/mailman/listinfo/bioc-devel

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