Re: [Bioc-devel] R version dependency

[Lori Shepherd]

All versions of Bioconductor are closely associated to a version of R to
ensure proper testing.  We do not currently test packages outside the
current release and devel versions of Bioconductor.  The current
Bioconductor release will always run on the current version of R.  The
current Bioconductor devel for half the year will run on the current
version of R and the second half of the year R-devel to prep for the annual
R release.


Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center


On Tue, Apr 23, 2024 at 5:47 AM Richard Heery 
wrote:

> So the version of R depended on determines the version of Bioconductor that
> the BBS will use when testing the package?
>
>
>
> On Tue, 23 Apr 2024 at 04:41, Anatoly Sorokin  wrote:
>
> > Hi,
> > You can even set 3.5 if your code working with that version of R, but
> > BiocManager won't load the latest Bioconductor version (3.19) unless you
> > have R 4.4.
> >
> > Cheers,
> > Anatoly
> >
> > On Tue, Apr 23, 2024 at 2:57 AM Richard Heery 
> > wrote:
> >
> >> Hi all,
> >>
> >> I'm wondering what we should now list as the R version in the Depends
> >> section of the description file: the current version 4.3.3 or the
> >> development version 4.4?
> >>
> >> Cheers,
> >>
> >> Richard
> >>
> >> [[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
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] R version dependency

[Richard Heery]

So the version of R depended on determines the version of Bioconductor that
the BBS will use when testing the package?



On Tue, 23 Apr 2024 at 04:41, Anatoly Sorokin  wrote:

> Hi,
> You can even set 3.5 if your code working with that version of R, but
> BiocManager won't load the latest Bioconductor version (3.19) unless you
> have R 4.4.
>
> Cheers,
> Anatoly
>
> On Tue, Apr 23, 2024 at 2:57 AM Richard Heery 
> wrote:
>
>> Hi all,
>>
>> I'm wondering what we should now list as the R version in the Depends
>> section of the description file: the current version 4.3.3 or the
>> development version 4.4?
>>
>> Cheers,
>>
>> Richard
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] R version dependency

[Anatoly Sorokin]

Hi,
You can even set 3.5 if your code working with that version of R, but
BiocManager won't load the latest Bioconductor version (3.19) unless you
have R 4.4.

Cheers,
Anatoly

On Tue, Apr 23, 2024 at 2:57 AM Richard Heery 
wrote:

> Hi all,
>
> I'm wondering what we should now list as the R version in the Depends
> section of the description file: the current version 4.3.3 or the
> development version 4.4?
>
> Cheers,
>
> Richard
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] R version dependency

[Hervé Pagès]

If you're submitting a new package, you might be asked to set this to R 
(>= 4.4). At least it used to be that way but I'm not sure this is still 
enforced.

Otherwise you don't need to do anything.

Best,

H.

On 4/22/24 10:56, Richard Heery wrote:
> Hi all,
>
> I'm wondering what we should now list as the R version in the Depends
> section of the description file: the current version 4.3.3 or the
> development version 4.4?
>
> Cheers,
>
> Richard
>
>   [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org  mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

-- 
Hervé Pagès

Bioconductor Core Team
hpages.on.git...@gmail.com

[[alternative HTML version deleted]]

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

[Bioc-devel] R version dependency

[Richard Heery]

Hi all,

I'm wondering what we should now list as the R version in the Depends
section of the description file: the current version 4.3.3 or the
development version 4.4?

Cheers,

Richard

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] R version check in BiocChech

[Shepherd, Lori]

Depending on your reviewer, they MAY let you slide with a different version 
dependency despite the BiocCheck WARNING... maybe...


However ...


It is strongly, strongly recommended that all new package depend on the version 
of R that it will be released under.  New packages currently being accepted 
will be released under Bioc 3.7 which will be associated with R 3.5.   So as 
mentioned, eventually users will want to update to use the latest versions 
anyways.  While new packages could be compatible with earlier versions of Bioc 
and R releases,  we at Bioconductor cannot guarantee that, which is why we 
generally insist for consistency sake that the R requirement is the latest 
version.  R versions can have subtle difference that can have a cascading 
effect on packages - similarly with packages that are used in dependencies - 
Since the Bioconductor build system is set up to test under the latest version 
testing scenario, that is all we can guarantee for compatibility and why we 
check for this.


Perhaps others will want to chime in as well with further reasoning.



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel <bioc-devel-boun...@r-project.org> on behalf of Alexey 
Sergushichev <alserg...@gmail.com>
Sent: Tuesday, February 20, 2018 4:26:35 AM
To: Vincent Carey
Cc: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] R version check in BiocChech

> It _is_ the developer's choice.  But a developer of packages for the
Bioconductor
> project commits to using R-devel during certain pre-release phases,
depending
> on proximity in time to a point release of R.  (See
http://bioconductor.org/developers/how-to/useDevel/)
> for full details.)  BiocCheck verifies that this commitment is met.

No, BiocCheck doesn't verify this, it just checks for presence of
dependence on R >= 3.5. It actually doesn't check, whether I have installed
it on my computer at all; or how often I'm updating R-devel and test my
package against it; or whether I do some manual tests, as unit tests are
running regularly by BioConductor automatically.

--
Alexey



On Mon, Feb 19, 2018 at 9:03 PM, Vincent Carey <st...@channing.harvard.edu>
wrote:

>
>
> On Mon, Feb 19, 2018 at 11:27 AM, Alexey Sergushichev <alserg...@gmail.com
> > wrote:
>
>> Kevin,
>>
>> > It does not request users to make R-devel a _requirement_ of their
>> package.
>>
>> Sadly it does for new packages. New packages submitted to Bioconductor 3.7
>> are _required_ to have R >= 3.5 dependency, otherwist BiocCheck will
>> result
>> in a warning (
>> https://github.com/Bioconductor/BiocCheck/blob/be9cd6e36d95f
>> 8bf873b52427d2a97fce6fbb9b9/R/checks.R#L23)
>> and warnings aren't allowed for new package submission.
>>
>> > Here, I think the decision here boils down to how far back in terms of R
>> versions the developer is willing to support the package. I suppose one
>> could state R�2.3 if they're confident about it.
>>
>> That's the problem: this is true for packages already in Bioconductor, but
>> it's not ture for the new package submissions.
>>
>> Aaron,
>>
>> > Personally, I haven't found it to be particularly difficult to update R,
>> > or to run R-devel in parallel with R 3.4, even without root privileges.
>>
>> I find it much harder for a normal user to install R-devel (and update it
>> properly, because it's a development version) and running
>> 'devtools::install_github("blabla/my_package")'.
>>
>> > I think many people underappreciate the benefits of moving to the latest
>> > version of R.
>>
>> Don't you think it should be a developer's choice whether to use such new
>> features or ignore them and have a potentially bigger audience?
>>
>
> It _is_ the developer's choice.  But a developer of packages for the
> Bioconductor
> project commits to using R-devel during certain pre-release phases,
> depending
> on proximity in time to a point release of R.  (See
> http://bioconductor.org/developers/how-to/useDevel/)
> for full details.)  BiocCheck verifies that this commitment is met.
>
>
>>
>> > Enforcing version consistency avoids heartache during release and
>> > debugging.
>>
>> But it's a developer's heartache. As I said, it even can't be attributed
>> to
>> Bioconductor at all, as it's not possible to install the package from
>> bioc-devel, unless you have the corresponding R version.
>>
>>
>> --
>> Alexey
>>
>>
>>
>> On Mon, Feb 19, 2018 at 6:38 PM, Aaron Lun <a...@w

Re: [Bioc-devel] R version check in BiocChech

[Alexey Sergushichev]

> It _is_ the developer's choice.  But a developer of packages for the
Bioconductor
> project commits to using R-devel during certain pre-release phases,
depending
> on proximity in time to a point release of R.  (See
http://bioconductor.org/developers/how-to/useDevel/)
> for full details.)  BiocCheck verifies that this commitment is met.

No, BiocCheck doesn't verify this, it just checks for presence of
dependence on R >= 3.5. It actually doesn't check, whether I have installed
it on my computer at all; or how often I'm updating R-devel and test my
package against it; or whether I do some manual tests, as unit tests are
running regularly by BioConductor automatically.

--
Alexey



On Mon, Feb 19, 2018 at 9:03 PM, Vincent Carey 
wrote:

>
>
> On Mon, Feb 19, 2018 at 11:27 AM, Alexey Sergushichev  > wrote:
>
>> Kevin,
>>
>> > It does not request users to make R-devel a _requirement_ of their
>> package.
>>
>> Sadly it does for new packages. New packages submitted to Bioconductor 3.7
>> are _required_ to have R >= 3.5 dependency, otherwist BiocCheck will
>> result
>> in a warning (
>> https://github.com/Bioconductor/BiocCheck/blob/be9cd6e36d95f
>> 8bf873b52427d2a97fce6fbb9b9/R/checks.R#L23)
>> and warnings aren't allowed for new package submission.
>>
>> > Here, I think the decision here boils down to how far back in terms of R
>> versions the developer is willing to support the package. I suppose one
>> could state R≥2.3 if they're confident about it.
>>
>> That's the problem: this is true for packages already in Bioconductor, but
>> it's not ture for the new package submissions.
>>
>> Aaron,
>>
>> > Personally, I haven't found it to be particularly difficult to update R,
>> > or to run R-devel in parallel with R 3.4, even without root privileges.
>>
>> I find it much harder for a normal user to install R-devel (and update it
>> properly, because it's a development version) and running
>> 'devtools::install_github("blabla/my_package")'.
>>
>> > I think many people underappreciate the benefits of moving to the latest
>> > version of R.
>>
>> Don't you think it should be a developer's choice whether to use such new
>> features or ignore them and have a potentially bigger audience?
>>
>
> It _is_ the developer's choice.  But a developer of packages for the
> Bioconductor
> project commits to using R-devel during certain pre-release phases,
> depending
> on proximity in time to a point release of R.  (See
> http://bioconductor.org/developers/how-to/useDevel/)
> for full details.)  BiocCheck verifies that this commitment is met.
>
>
>>
>> > Enforcing version consistency avoids heartache during release and
>> > debugging.
>>
>> But it's a developer's heartache. As I said, it even can't be attributed
>> to
>> Bioconductor at all, as it's not possible to install the package from
>> bioc-devel, unless you have the corresponding R version.
>>
>>
>> --
>> Alexey
>>
>>
>>
>> On Mon, Feb 19, 2018 at 6:38 PM, Aaron Lun  wrote:
>>
>> > I'll just throw in my two cents here.
>> >
>> > I think many people underappreciate the benefits of moving to the latest
>> > version of R. If you inspect the R-devel NEWS file, there's a couple of
>> > nice fixes/features that a developer might want to take advantage of:
>> >
>> > - sum() doesn't give NAs upon integer overflow anymore.
>> > - New ...elt(n) and ...length() functions for dealing with ellipses.
>> > - ALTREP support for 1:n sequences (wow!)
>> > - zero length subassignment in a non-zero index fails correctly.
>> >
>> > The previous 3.4.0 release also added support for more DLLs being loaded
>> > at once, which was otherwise causing headaches in workflows. And 3.4.2
>> > had a bug fix to LAPACK, which did result in a few user-level changes in
>> > some packages like edgeR. So there are considerable differences between
>> > the versions of R, especially if one is a package developer.
>> >
>> > Enforcing version consistency avoids heartache during release and
>> > debugging. There's a choice between users getting annoyed about having
>> > to update R, and then updating R, and everything working as a result; or
>> > everyone (developers/users) wasting some time figuring out whether a bug
>> > in a package is due to the code in the package itself or the version of
>> > R. The brief annoyance in the first option is better than the chronic
>> > grief of the second option, especially given that the solution to the
>> > problem in the second option would be to update R anyway.
>> >
>> > Personally, I haven't found it to be particularly difficult to update R,
>> > or to run R-devel in parallel with R 3.4, even without root privileges.
>> >
>> > -Aaron
>> >
>> > On 19/02/18 14:55, Kevin RUE wrote:
>> > > Hi Alexey,
>> > >
>> > > I do agree with you that there is no harm in testing against other
>> > version
>> > > of R. In a way, that is even good practice, considering that many HPC
>> > users
>> > > do not always 

Re: [Bioc-devel] R version check in BiocChech

[Vincent Carey]

On Mon, Feb 19, 2018 at 11:27 AM, Alexey Sergushichev 
wrote:

> Kevin,
>
> > It does not request users to make R-devel a _requirement_ of their
> package.
>
> Sadly it does for new packages. New packages submitted to Bioconductor 3.7
> are _required_ to have R >= 3.5 dependency, otherwist BiocCheck will result
> in a warning (
> https://github.com/Bioconductor/BiocCheck/blob/
> be9cd6e36d95f8bf873b52427d2a97fce6fbb9b9/R/checks.R#L23)
> and warnings aren't allowed for new package submission.
>
> > Here, I think the decision here boils down to how far back in terms of R
> versions the developer is willing to support the package. I suppose one
> could state R≥2.3 if they're confident about it.
>
> That's the problem: this is true for packages already in Bioconductor, but
> it's not ture for the new package submissions.
>
> Aaron,
>
> > Personally, I haven't found it to be particularly difficult to update R,
> > or to run R-devel in parallel with R 3.4, even without root privileges.
>
> I find it much harder for a normal user to install R-devel (and update it
> properly, because it's a development version) and running
> 'devtools::install_github("blabla/my_package")'.
>
> > I think many people underappreciate the benefits of moving to the latest
> > version of R.
>
> Don't you think it should be a developer's choice whether to use such new
> features or ignore them and have a potentially bigger audience?
>

It _is_ the developer's choice.  But a developer of packages for the
Bioconductor
project commits to using R-devel during certain pre-release phases,
depending
on proximity in time to a point release of R.  (See
http://bioconductor.org/developers/how-to/useDevel/)
for full details.)  BiocCheck verifies that this commitment is met.


>
> > Enforcing version consistency avoids heartache during release and
> > debugging.
>
> But it's a developer's heartache. As I said, it even can't be attributed to
> Bioconductor at all, as it's not possible to install the package from
> bioc-devel, unless you have the corresponding R version.
>
>
> --
> Alexey
>
>
>
> On Mon, Feb 19, 2018 at 6:38 PM, Aaron Lun  wrote:
>
> > I'll just throw in my two cents here.
> >
> > I think many people underappreciate the benefits of moving to the latest
> > version of R. If you inspect the R-devel NEWS file, there's a couple of
> > nice fixes/features that a developer might want to take advantage of:
> >
> > - sum() doesn't give NAs upon integer overflow anymore.
> > - New ...elt(n) and ...length() functions for dealing with ellipses.
> > - ALTREP support for 1:n sequences (wow!)
> > - zero length subassignment in a non-zero index fails correctly.
> >
> > The previous 3.4.0 release also added support for more DLLs being loaded
> > at once, which was otherwise causing headaches in workflows. And 3.4.2
> > had a bug fix to LAPACK, which did result in a few user-level changes in
> > some packages like edgeR. So there are considerable differences between
> > the versions of R, especially if one is a package developer.
> >
> > Enforcing version consistency avoids heartache during release and
> > debugging. There's a choice between users getting annoyed about having
> > to update R, and then updating R, and everything working as a result; or
> > everyone (developers/users) wasting some time figuring out whether a bug
> > in a package is due to the code in the package itself or the version of
> > R. The brief annoyance in the first option is better than the chronic
> > grief of the second option, especially given that the solution to the
> > problem in the second option would be to update R anyway.
> >
> > Personally, I haven't found it to be particularly difficult to update R,
> > or to run R-devel in parallel with R 3.4, even without root privileges.
> >
> > -Aaron
> >
> > On 19/02/18 14:55, Kevin RUE wrote:
> > > Hi Alexey,
> > >
> > > I do agree with you that there is no harm in testing against other
> > version
> > > of R. In a way, that is even good practice, considering that many HPC
> > users
> > > do not always have access to the latest version of R, and that Travis
> is
> > > making this fairly easy.
> > >
> > > Now, with regard to your latest reply, I am wondering whether we're
> > having
> > > confusion here between the "R≥x.x" requirement, and the version(s) of R
> > > that you use to develop/test your package (the version of R installed
> on
> > > your own machine).
> > >
> > > First, I think the "R≥x.x" does not have an explicit rule.
> > > To me, the point of this requirement is to declare the oldest version
> of
> > R
> > > that the package has been tested/validated for. This does not
> necessarily
> > > have to be the _next_ version of R (see the core Bioc package
> S4Vectors:
> > > https://bioconductor.org/packages/release/bioc/html/S4Vectors.html,
> and
> > I
> > > am sure there are older requirements in other packages).
> > > Here, I think the decision here boils down to how far back 

Re: [Bioc-devel] R version check in BiocChech

[Aaron Lun]

>  > Personally, I haven't found it to be particularly difficult to update R,
>  > or to run R-devel in parallel with R 3.4, even without root privileges.
> 
> I find it much harder for a normal user to install R-devel (and update 
> it properly, because it's a development version) and running 
> 'devtools::install_github("blabla/my_package")'.

There seem to be two issues here.

The first is regarding the usability of your specific package. For this, 
Kevin's suggestion (and what you are already doing) is pretty 
reasonable. It's just a branch with a single altered commit (>= 3.5 to 
 >= 3.4); it costs nothing, and you can delete it later.

However, this "solution" will only last until the next BioC release, at 
which point biocLite() will only work on R 3.5.*. So, sooner or later, 
your users will have to update their versions of R.

Which leads us to the second question. Should Bioconductor, as a 
project, enforce the use of the latest R version? The core team will 
have better things to say than me on this topic, but for me, the answer 
is an unqualified yes. We get the latest features, bugfixes and 
improvements; a considerable set of benefits, IMHO.

>  > I think many people underappreciate the benefits of moving to the latest
>  > version of R.
> 
> Don't you think it should be a developer's choice whether to use such 
> new features or ignore them and have a potentially bigger audience?

It's true that a developer might not need the latest cutting-edge 
features in the latest version of R. But they should incorporate bug 
fixes to the underlying infrastructure, or changes to existing 
functionality that result in different behaviour.

Of course, it would be difficult to ask every developer to read through 
the NEWS to see if the changes affect their package. It is much easier 
for everyone to just use the latest version of R; then we only have to 
deal with bugs in the latest version, not previously solved ones.

And besides; let's say, hypothetically, BioC didn't have a R version 
requirement. Unless you're using a quite restricted subset of packages, 
you'll encounter a package somewhere that requires the latest R version. 
In my workflows, I know that I load at least 100 packages; only one of 
them needs to have R (>= 3.5) to force me to upgrade anyway.

>  > Enforcing version consistency avoids heartache during release and
>  > debugging.
> 
> But it's a developer's heartache. As I said, it even can't be attributed 
> to Bioconductor at all, as it's not possible to install the package from 
> bioc-devel, unless you have the corresponding R version.

Yes, that's the point. To paraphrase what I tell my colleagues:

Bugs in a BioC-release package with R 3.4 = my problem
Bugs in a BioC-devel package with R 3.5 = my problem
Bugs in a BioC-devel package with R 3.4 = not my problem

 From my perspective, the version requirements in biocLite() ensure that 
the user is doing things properly; and if they follow the rules, any 
bugs are therefore the fault of my package. If the users don't follow 
the rules, they're on their own - but at least they know what the rules 
are, because it's pretty inconvenient to break them.

Cheers,

Aaron

> On Mon, Feb 19, 2018 at 6:38 PM, Aaron Lun  > wrote:
> 
> I'll just throw in my two cents here.
> 
> I think many people underappreciate the benefits of moving to the latest
> version of R. If you inspect the R-devel NEWS file, there's a couple of
> nice fixes/features that a developer might want to take advantage of:
> 
> - sum() doesn't give NAs upon integer overflow anymore.
> - New ...elt(n) and ...length() functions for dealing with ellipses.
> - ALTREP support for 1:n sequences (wow!)
> - zero length subassignment in a non-zero index fails correctly.
> 
> The previous 3.4.0 release also added support for more DLLs being loaded
> at once, which was otherwise causing headaches in workflows. And 3.4.2
> had a bug fix to LAPACK, which did result in a few user-level changes in
> some packages like edgeR. So there are considerable differences between
> the versions of R, especially if one is a package developer.
> 
> Enforcing version consistency avoids heartache during release and
> debugging. There's a choice between users getting annoyed about having
> to update R, and then updating R, and everything working as a result; or
> everyone (developers/users) wasting some time figuring out whether a bug
> in a package is due to the code in the package itself or the version of
> R. The brief annoyance in the first option is better than the chronic
> grief of the second option, especially given that the solution to the
> problem in the second option would be to update R anyway.
> 
> Personally, I haven't found it to be particularly difficult to update R,
> or to run R-devel in parallel with R 3.4, even without root privileges.
> 
> 

Re: [Bioc-devel] R version check in BiocChech

[Alexey Sergushichev]

Kevin,

> It does not request users to make R-devel a _requirement_ of their
package.

Sadly it does for new packages. New packages submitted to Bioconductor 3.7
are _required_ to have R >= 3.5 dependency, otherwist BiocCheck will result
in a warning (
https://github.com/Bioconductor/BiocCheck/blob/be9cd6e36d95f8bf873b52427d2a97fce6fbb9b9/R/checks.R#L23)
and warnings aren't allowed for new package submission.

> Here, I think the decision here boils down to how far back in terms of R
versions the developer is willing to support the package. I suppose one
could state R≥2.3 if they're confident about it.

That's the problem: this is true for packages already in Bioconductor, but
it's not ture for the new package submissions.

Aaron,

> Personally, I haven't found it to be particularly difficult to update R,
> or to run R-devel in parallel with R 3.4, even without root privileges.

I find it much harder for a normal user to install R-devel (and update it
properly, because it's a development version) and running
'devtools::install_github("blabla/my_package")'.

> I think many people underappreciate the benefits of moving to the latest
> version of R.

Don't you think it should be a developer's choice whether to use such new
features or ignore them and have a potentially bigger audience?

> Enforcing version consistency avoids heartache during release and
> debugging.

But it's a developer's heartache. As I said, it even can't be attributed to
Bioconductor at all, as it's not possible to install the package from
bioc-devel, unless you have the corresponding R version.


--
Alexey



On Mon, Feb 19, 2018 at 6:38 PM, Aaron Lun  wrote:

> I'll just throw in my two cents here.
>
> I think many people underappreciate the benefits of moving to the latest
> version of R. If you inspect the R-devel NEWS file, there's a couple of
> nice fixes/features that a developer might want to take advantage of:
>
> - sum() doesn't give NAs upon integer overflow anymore.
> - New ...elt(n) and ...length() functions for dealing with ellipses.
> - ALTREP support for 1:n sequences (wow!)
> - zero length subassignment in a non-zero index fails correctly.
>
> The previous 3.4.0 release also added support for more DLLs being loaded
> at once, which was otherwise causing headaches in workflows. And 3.4.2
> had a bug fix to LAPACK, which did result in a few user-level changes in
> some packages like edgeR. So there are considerable differences between
> the versions of R, especially if one is a package developer.
>
> Enforcing version consistency avoids heartache during release and
> debugging. There's a choice between users getting annoyed about having
> to update R, and then updating R, and everything working as a result; or
> everyone (developers/users) wasting some time figuring out whether a bug
> in a package is due to the code in the package itself or the version of
> R. The brief annoyance in the first option is better than the chronic
> grief of the second option, especially given that the solution to the
> problem in the second option would be to update R anyway.
>
> Personally, I haven't found it to be particularly difficult to update R,
> or to run R-devel in parallel with R 3.4, even without root privileges.
>
> -Aaron
>
> On 19/02/18 14:55, Kevin RUE wrote:
> > Hi Alexey,
> >
> > I do agree with you that there is no harm in testing against other
> version
> > of R. In a way, that is even good practice, considering that many HPC
> users
> > do not always have access to the latest version of R, and that Travis is
> > making this fairly easy.
> >
> > Now, with regard to your latest reply, I am wondering whether we're
> having
> > confusion here between the "R≥x.x" requirement, and the version(s) of R
> > that you use to develop/test your package (the version of R installed on
> > your own machine).
> >
> > First, I think the "R≥x.x" does not have an explicit rule.
> > To me, the point of this requirement is to declare the oldest version of
> R
> > that the package has been tested/validated for. This does not necessarily
> > have to be the _next_ version of R (see the core Bioc package S4Vectors:
> > https://bioconductor.org/packages/release/bioc/html/S4Vectors.html, and
> I
> > am sure there are older requirements in other packages).
> > Here, I think the decision here boils down to how far back in terms of R
> > versions the developer is willing to support the package. I suppose one
> > could state R≥2.3 if they're confident about it.
> >
> > On a separate note, going back to the Bioc guideline that I initially
> > highlighted ("Package authors should develop against the version of *R*
> that
> > will be available to users when the *Bioconductor* devel branch becomes
> the
> > *Bioconductor* release branch."), this rather refers to the
> forward-looking
> > guideline that the cutting-edge version of any R package should be
> > compatible with the cutting edge version of R, and that developers should
> > be 

Re: [Bioc-devel] R version check in BiocChech

[Aaron Lun]

I'll just throw in my two cents here.

I think many people underappreciate the benefits of moving to the latest 
version of R. If you inspect the R-devel NEWS file, there's a couple of 
nice fixes/features that a developer might want to take advantage of:

- sum() doesn't give NAs upon integer overflow anymore.
- New ...elt(n) and ...length() functions for dealing with ellipses.
- ALTREP support for 1:n sequences (wow!)
- zero length subassignment in a non-zero index fails correctly.

The previous 3.4.0 release also added support for more DLLs being loaded 
at once, which was otherwise causing headaches in workflows. And 3.4.2 
had a bug fix to LAPACK, which did result in a few user-level changes in 
some packages like edgeR. So there are considerable differences between 
the versions of R, especially if one is a package developer.

Enforcing version consistency avoids heartache during release and 
debugging. There's a choice between users getting annoyed about having 
to update R, and then updating R, and everything working as a result; or 
everyone (developers/users) wasting some time figuring out whether a bug 
in a package is due to the code in the package itself or the version of 
R. The brief annoyance in the first option is better than the chronic 
grief of the second option, especially given that the solution to the 
problem in the second option would be to update R anyway.

Personally, I haven't found it to be particularly difficult to update R, 
or to run R-devel in parallel with R 3.4, even without root privileges.

-Aaron

On 19/02/18 14:55, Kevin RUE wrote:
> Hi Alexey,
> 
> I do agree with you that there is no harm in testing against other version
> of R. In a way, that is even good practice, considering that many HPC users
> do not always have access to the latest version of R, and that Travis is
> making this fairly easy.
> 
> Now, with regard to your latest reply, I am wondering whether we're having
> confusion here between the "R≥x.x" requirement, and the version(s) of R
> that you use to develop/test your package (the version of R installed on
> your own machine).
> 
> First, I think the "R≥x.x" does not have an explicit rule.
> To me, the point of this requirement is to declare the oldest version of R
> that the package has been tested/validated for. This does not necessarily
> have to be the _next_ version of R (see the core Bioc package S4Vectors:
> https://bioconductor.org/packages/release/bioc/html/S4Vectors.html, and I
> am sure there are older requirements in other packages).
> Here, I think the decision here boils down to how far back in terms of R
> versions the developer is willing to support the package. I suppose one
> could state R≥2.3 if they're confident about it.
> 
> On a separate note, going back to the Bioc guideline that I initially
> highlighted ("Package authors should develop against the version of *R* that
> will be available to users when the *Bioconductor* devel branch becomes the
> *Bioconductor* release branch."), this rather refers to the forward-looking
> guideline that the cutting-edge version of any R package should be
> compatible with the cutting edge version of R, and that developers should
> be working with R-devel to ensure this.
> In other words, this only refers to the version of R that the developer
> should have installed on their own machine. It does not request users to
> make R-devel a _requirement_ of their package.
> 
> I hope this addresses your question better, and I am curious to hear if
> anyone else has an opinion or precisions to weigh in on this topic.
> 
> Best,
> Kevin
> 
> 
> On Mon, Feb 19, 2018 at 12:19 PM, Alexey Sergushichev 
> wrote:
> 
>> Hello Kevin,
>>
>> Well, bioc-devel packages are tested against bioc-devel (and R-3.5) in any
>> case. What I'm saying is that aside from testing the package against
>> bioc-devel, I can as well test against bioc-release too on my own. If the
>> package doesn't work with bioc-devel it shouldn't pass bioc-devel checks,
>> if the package is properly developed and has a good test coverage. So I see
>> no problem in allowing developers to test against other versions, on top of
>> developing against bioc-devel. And as it's only possible to install the
>> package from github and not from Bioconductor, the developer alone is
>> responsible for the package to work properly.
>>
>> I can't really see a scenario, where requiring R >= 3.5 helps to improve
>> the package quality.
>>
>>> A short-term workaround can be to create a git branch (e.g. "3.4").
>>
>> That's the way I'm doing too, but supporting two branches different only
>> in R version looks ridiculous and unnecessary.
>>
>> --
>> Alexey
>>
>>
>>
>>
>>
>> On Mon, Feb 19, 2018 at 12:48 PM, Kevin RUE  wrote:
>>
>>> Dear Alexey,
>>>
>>> The reason is somewhat implicitly given at https://www.bioconductor.or
>>> g/developers/how-to/useDevel/ :
>>> "Package authors should develop against the version of *R* 

Re: [Bioc-devel] R version check in BiocChech

[Kevin RUE]

Hi Alexey,

I do agree with you that there is no harm in testing against other version
of R. In a way, that is even good practice, considering that many HPC users
do not always have access to the latest version of R, and that Travis is
making this fairly easy.

Now, with regard to your latest reply, I am wondering whether we're having
confusion here between the "R≥x.x" requirement, and the version(s) of R
that you use to develop/test your package (the version of R installed on
your own machine).

First, I think the "R≥x.x" does not have an explicit rule.
To me, the point of this requirement is to declare the oldest version of R
that the package has been tested/validated for. This does not necessarily
have to be the _next_ version of R (see the core Bioc package S4Vectors:
https://bioconductor.org/packages/release/bioc/html/S4Vectors.html, and I
am sure there are older requirements in other packages).
Here, I think the decision here boils down to how far back in terms of R
versions the developer is willing to support the package. I suppose one
could state R≥2.3 if they're confident about it.

On a separate note, going back to the Bioc guideline that I initially
highlighted ("Package authors should develop against the version of *R* that
will be available to users when the *Bioconductor* devel branch becomes the
*Bioconductor* release branch."), this rather refers to the forward-looking
guideline that the cutting-edge version of any R package should be
compatible with the cutting edge version of R, and that developers should
be working with R-devel to ensure this.
In other words, this only refers to the version of R that the developer
should have installed on their own machine. It does not request users to
make R-devel a _requirement_ of their package.

I hope this addresses your question better, and I am curious to hear if
anyone else has an opinion or precisions to weigh in on this topic.

Best,
Kevin


On Mon, Feb 19, 2018 at 12:19 PM, Alexey Sergushichev 
wrote:

> Hello Kevin,
>
> Well, bioc-devel packages are tested against bioc-devel (and R-3.5) in any
> case. What I'm saying is that aside from testing the package against
> bioc-devel, I can as well test against bioc-release too on my own. If the
> package doesn't work with bioc-devel it shouldn't pass bioc-devel checks,
> if the package is properly developed and has a good test coverage. So I see
> no problem in allowing developers to test against other versions, on top of
> developing against bioc-devel. And as it's only possible to install the
> package from github and not from Bioconductor, the developer alone is
> responsible for the package to work properly.
>
> I can't really see a scenario, where requiring R >= 3.5 helps to improve
> the package quality.
>
> > A short-term workaround can be to create a git branch (e.g. "3.4").
>
> That's the way I'm doing too, but supporting two branches different only
> in R version looks ridiculous and unnecessary.
>
> --
> Alexey
>
>
>
>
>
> On Mon, Feb 19, 2018 at 12:48 PM, Kevin RUE  wrote:
>
>> Dear Alexey,
>>
>> The reason is somewhat implicitly given at https://www.bioconductor.or
>> g/developers/how-to/useDevel/ :
>> "Package authors should develop against the version of *R* that will be
>> available to users when the *Bioconductor* devel branch becomes the
>> *Bioconductor* release branch."
>>
>> In other words, developing against the _next_ version of R ensures that
>> all packages in development are tested in the environment where they will
>> be released to the general community. In particular, that environment
>> includes the latest devel version of all Bioconductor packages, that will
>> become their next release version.
>> If developers were allowed to develop and test their package in the
>> _current_ version of R, there is no guarantee that those packages would
>> still work when they are made available with the _next_ version of R (e.g.
>> if one of their dependencies is about to introduce some breaking changes).
>> That could cause all sorts of trouble in the first builds on the next
>> Bioconductor release, which is meant to be a place storing stable working
>> code.
>>
>> Overall, you will do yourself and your users a favor developing with the
>> _next_ version of R, as this is a forward-looking strategy, as explained
>> above. In contrast, the short-term benefit of developing with the _current_
>> version of R is largely outweighed by the risk of wasting time looking at
>> code that is about to be deprecated.
>>
>> A short-term workaround can be to create a git branch (e.g. "3.4"), where
>> the R version requirement is downgraded. Then, you can always keep
>> developing against R-devel on your master branch and back-port the more
>> recent commit to the "3.4" branch by typing "git rebase master 3.4" in your
>> shell.
>> A recent example of this situation can be found in the discussion here as
>> a branch to the original repository 

Re: [Bioc-devel] R version check in BiocChech

[Alexey Sergushichev]

Hello Kevin,

Well, bioc-devel packages are tested against bioc-devel (and R-3.5) in any
case. What I'm saying is that aside from testing the package against
bioc-devel, I can as well test against bioc-release too on my own. If the
package doesn't work with bioc-devel it shouldn't pass bioc-devel checks,
if the package is properly developed and has a good test coverage. So I see
no problem in allowing developers to test against other versions, on top of
developing against bioc-devel. And as it's only possible to install the
package from github and not from Bioconductor, the developer alone is
responsible for the package to work properly.

I can't really see a scenario, where requiring R >= 3.5 helps to improve
the package quality.

> A short-term workaround can be to create a git branch (e.g. "3.4").

That's the way I'm doing too, but supporting two branches different only in
R version looks ridiculous and unnecessary.

--
Alexey





On Mon, Feb 19, 2018 at 12:48 PM, Kevin RUE  wrote:

> Dear Alexey,
>
> The reason is somewhat implicitly given at https://www.bioconductor.or
> g/developers/how-to/useDevel/ :
> "Package authors should develop against the version of *R* that will be
> available to users when the *Bioconductor* devel branch becomes the
> *Bioconductor* release branch."
>
> In other words, developing against the _next_ version of R ensures that
> all packages in development are tested in the environment where they will
> be released to the general community. In particular, that environment
> includes the latest devel version of all Bioconductor packages, that will
> become their next release version.
> If developers were allowed to develop and test their package in the
> _current_ version of R, there is no guarantee that those packages would
> still work when they are made available with the _next_ version of R (e.g.
> if one of their dependencies is about to introduce some breaking changes).
> That could cause all sorts of trouble in the first builds on the next
> Bioconductor release, which is meant to be a place storing stable working
> code.
>
> Overall, you will do yourself and your users a favor developing with the
> _next_ version of R, as this is a forward-looking strategy, as explained
> above. In contrast, the short-term benefit of developing with the _current_
> version of R is largely outweighed by the risk of wasting time looking at
> code that is about to be deprecated.
>
> A short-term workaround can be to create a git branch (e.g. "3.4"), where
> the R version requirement is downgraded. Then, you can always keep
> developing against R-devel on your master branch and back-port the more
> recent commit to the "3.4" branch by typing "git rebase master 3.4" in your
> shell.
> A recent example of this situation can be found in the discussion here as
> a branch to the original repository https://github.com/csoneson/iS
> EE/pull/124 and here as a fork https://github.com/mdshw5
> /iSEE/commit/6fb98192a635a6222491b66fb0474dc38f922495
>
> I hope this helps.
>
> Best wishes,
> Kevin
>
>
> On Mon, Feb 19, 2018 at 8:02 AM, Alexey Sergushichev 
> wrote:
>
>> Dear Bioconducotr community,
>>
>> I wonder, what is the reason behind requirement for dependency R >= 3.5
>> (currently) for new packages?
>>
>> As a developer I really want an installation of my package to be as easy
>> as
>> possible and want my package to be easily installed from github. So
>> currently, when I develop a package I put a R >= 3.4 in my DESCRIPTION and
>> test it using Travis against bioc-release. Then, before submission
>> to Bioconductor, I have to change R >= 3.4 dependency to R >= 3.5, so that
>> the package passes BiocCheck. However, most users don't have R-devel
>> installed, so they have R 3.4 in the best case, and for these users I
>> create another repository branch with R >= 3.4 dependency.
>>
>> Overall, it is quite bothersome and it doesn't really make sense to me to
>> to restrict potential users in this way. Am I the only one who have issues
>> with this? Am I missing something? Or may be this check could be removed?
>>
>> Best,
>> Alexey Sergushichev
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] R version check in BiocChech

[Kevin RUE]

Dear Alexey,

The reason is somewhat implicitly given at
https://www.bioconductor.org/developers/how-to/useDevel/ :
"Package authors should develop against the version of *R* that will be
available to users when the *Bioconductor* devel branch becomes the
*Bioconductor* release branch."

In other words, developing against the _next_ version of R ensures that all
packages in development are tested in the environment where they will be
released to the general community. In particular, that environment includes
the latest devel version of all Bioconductor packages, that will become
their next release version.
If developers were allowed to develop and test their package in the
_current_ version of R, there is no guarantee that those packages would
still work when they are made available with the _next_ version of R (e.g.
if one of their dependencies is about to introduce some breaking changes).
That could cause all sorts of trouble in the first builds on the next
Bioconductor release, which is meant to be a place storing stable working
code.

Overall, you will do yourself and your users a favor developing with the
_next_ version of R, as this is a forward-looking strategy, as explained
above. In contrast, the short-term benefit of developing with the _current_
version of R is largely outweighed by the risk of wasting time looking at
code that is about to be deprecated.

A short-term workaround can be to create a git branch (e.g. "3.4"), where
the R version requirement is downgraded. Then, you can always keep
developing against R-devel on your master branch and back-port the more
recent commit to the "3.4" branch by typing "git rebase master 3.4" in your
shell.
A recent example of this situation can be found in the discussion here as a
branch to the original repository https://github.com/csoneson/iSEE/pull/124
and here as a fork
https://github.com/mdshw5/iSEE/commit/6fb98192a635a6222491b66fb0474dc38f922495

I hope this helps.

Best wishes,
Kevin


On Mon, Feb 19, 2018 at 8:02 AM, Alexey Sergushichev 
wrote:

> Dear Bioconducotr community,
>
> I wonder, what is the reason behind requirement for dependency R >= 3.5
> (currently) for new packages?
>
> As a developer I really want an installation of my package to be as easy as
> possible and want my package to be easily installed from github. So
> currently, when I develop a package I put a R >= 3.4 in my DESCRIPTION and
> test it using Travis against bioc-release. Then, before submission
> to Bioconductor, I have to change R >= 3.4 dependency to R >= 3.5, so that
> the package passes BiocCheck. However, most users don't have R-devel
> installed, so they have R 3.4 in the best case, and for these users I
> create another repository branch with R >= 3.4 dependency.
>
> Overall, it is quite bothersome and it doesn't really make sense to me to
> to restrict potential users in this way. Am I the only one who have issues
> with this? Am I missing something? Or may be this check could be removed?
>
> Best,
> Alexey Sergushichev
>
> [[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] R version check in BiocChech

[Alexey Sergushichev]

Dear Bioconducotr community,

I wonder, what is the reason behind requirement for dependency R >= 3.5
(currently) for new packages?

As a developer I really want an installation of my package to be as easy as
possible and want my package to be easily installed from github. So
currently, when I develop a package I put a R >= 3.4 in my DESCRIPTION and
test it using Travis against bioc-release. Then, before submission
to Bioconductor, I have to change R >= 3.4 dependency to R >= 3.5, so that
the package passes BiocCheck. However, most users don't have R-devel
installed, so they have R 3.4 in the best case, and for these users I
create another repository branch with R >= 3.4 dependency.

Overall, it is quite bothersome and it doesn't really make sense to me to
to restrict potential users in this way. Am I the only one who have issues
with this? Am I missing something? Or may be this check could be removed?

Best,
Alexey Sergushichev

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] R version-dependent segfault

[Vladimir Kiselev]

Hi Martin,

Great, many thanks for your support and advice. The bug is now fixed for
all the reporters. The solution was simple - I removed both:

#include 
using namespace Rcpp;

from the cpp file and then used Rcpp:: everywhere I needed an Rcpp
function. So that the header at the end looked like this:

#include 
using namespace arma;

For the record, here is a link to this issue on GitHub:
https://github.com/hemberg-lab/SC3/issues/33

Many thanks again,
Cheers,
Vladimir


On Thu, Jan 5, 2017 at 7:32 PM Martin Morgan 
wrote:

> On 01/05/2017 11:10 AM, Vladimir Kiselev wrote:
> > Dear Martin,
> >
> > Many thanks for your reply, it was really helpful. My collaborator ran
> > the commands you suggested and got the following output:
> >
> > *
> > $ Rscript norm_laplacian.R
> > /home/jake/miniconda3/lib/R/bin/R CMD SHLIB -o 'sourceCpp_2.so'
> >  'norm_laplacian.cpp'
> > g++ -I/home/jake/miniconda3/lib/R/include -DNDEBUG
> >  -I/home/jake/miniconda3/include
> >  -I"/home/jake/R/x86_64-pc-linux-gnu-library/3.3/Rcpp/include"
> > -I"/home/jake/R/x86_64-pc-linux-gnu-library/3.3/RcppArmadillo/include"
> > -I"/home/jake/Documents"   -fpic  -I/home/jake/miniconda3/include  -c
> > norm_laplacian.cpp -o norm_laplacian.o
> > g++ -shared -L/home/jake/miniconda3/lib/R/lib
> > -L/home/jake/miniconda3/lib -lgfortran -o sourceCpp_2.so
> > norm_laplacian.o -L/home/jake/miniconda3/lib/R/lib -lRlapack
> > -L/home/jake/miniconda3/lib/R/lib -lRblas -lgfortran -lm -lquadmath
> > -L/home/jake/miniconda3/lib/R/lib -lR
> > R version 3.3.2 (2016-10-31)
> > Platform: x86_64-pc-linux-gnu (64-bit)
> > Running under: Ubuntu 16.10
> >
> > 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] stats graphics  grDevices utils datasets  base
> >
> > other attached packages:
> > [1] Rcpp_0.12.8
> >
> > loaded via a namespace (and not attached):
> > [1] tools_3.3.2   RcppArmadillo_0.7.600.1.0
> >
> > $ g++ --version|head -n1
> > g++ (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
> > *
> >
> > So running the simplified code did not produce a segfault and suggested
> > that the problem was in SC3::norm_laplacian(). And indeed, running
> > valgrind with SC3::norm_laplacian(matrix(runif(100), nrow = 10)) did
> > catch the error:
> >
> > *
> > $ R -d valgrind -f norm_laplacian.R
> > ==7046== Memcheck, a memory error detector
> > ==7046== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> > ==7046== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for
> > copyright info
> > ==7046== Command: /home/jake/miniconda3/lib/R/bin/exec/R -f
> norm_laplacian.R
> > ==7046==
> >
> > R version 3.3.2 (2016-10-31) -- "Sincere Pumpkin Patch"
> > Copyright (C) 2016 The R Foundation for Statistical Computing
> > Platform: x86_64-pc-linux-gnu (64-bit)
> >
> >> library(Rcpp)
> >> sourceCpp("norm_laplacian.cpp", showOutput=TRUE)
> > /home/jake/miniconda3/lib/R/bin/R CMD SHLIB -o 'sourceCpp_2.so'
> >  'norm_laplacian.cpp'
> > g++ -I/home/jake/miniconda3/lib/R/include -DNDEBUG
> >  -I/home/jake/miniconda3/include
> >  -I"/home/jake/R/x86_64-pc-linux-gnu-library/3.3/Rcpp/include"
> > -I"/home/jake/R/x86_64-pc-linux-gnu-library/3.3/RcppArmadillo/include"
> > -I"/home/jake/Documents"   -fpic  -I/home/jake/miniconda3/include  -c
> > norm_laplacian.cpp -o norm_laplacian.o
> > g++ -shared -L/home/jake/miniconda3/lib/R/lib
> > -L/home/jake/miniconda3/lib -lgfortran -o sourceCpp_2.so
> > norm_laplacian.o -L/home/jake/miniconda3/lib/R/lib -lRlapack
> > -L/home/jake/miniconda3/lib/R/lib -lRblas -lgfortran -lm -lquadmath
> > -L/home/jake/miniconda3/lib/R/lib -lR
> >> xx <- norm_laplacian(matrix(runif(100), nrow = 10))
> >> SC3::norm_laplacian(matrix(runif(100), nrow = 10))
> > ==7046== Use of uninitialised value of size 8
> > ==7046==at 0x213645B8: direct_max (op_max_meat.hpp:362)
> > ==7046==by 0x213645B8: max (Mat_meat.hpp:6801)
> > ==7046==by 0x213645B8: norm_laplacian(arma::Mat)
> > (cppFunctions.cpp:87)
> > ==7046==by 0x21360E8C: SC3_norm_laplacian (RcppExports.cpp:49)
> > ==7046==by 0x521DE81: R_doDotCall (in
> > /home/jake/miniconda3/lib/R/lib/libR.so)
> > ==7046==by 0x522BD99: do_dotcall (in
> > /home/jake/miniconda3/lib/R/lib/libR.so)
> > ==7046==by 0x5267AAC: Rf_eval (in
> > /home/jake/miniconda3/lib/R/lib/libR.so)
> > ==7046==by 0x526B0A7: do_begin (in
> > /home/jake/miniconda3/lib/R/lib/libR.so)
> > ==7046==by 0x526789E: Rf_eval (in
> > /home/jake/miniconda3/lib/R/lib/libR.so)
> > ==7046==by 0x5268B8C: Rf_applyClosure (in
> > /home/jake/miniconda3/lib/R/lib/libR.so)
> > ==7046==by 0x5267BBF: Rf_eval (in
> > /home/jake/miniconda3/lib/R/lib/libR.so)

Re: [Bioc-devel] R version-dependent segfault

[Martin Morgan]

On 01/05/2017 11:10 AM, Vladimir Kiselev wrote:

Dear Martin,

Many thanks for your reply, it was really helpful. My collaborator ran
the commands you suggested and got the following output:

*
$ Rscript norm_laplacian.R
/home/jake/miniconda3/lib/R/bin/R CMD SHLIB -o 'sourceCpp_2.so'
 'norm_laplacian.cpp'
g++ -I/home/jake/miniconda3/lib/R/include -DNDEBUG
 -I/home/jake/miniconda3/include
 -I"/home/jake/R/x86_64-pc-linux-gnu-library/3.3/Rcpp/include"
-I"/home/jake/R/x86_64-pc-linux-gnu-library/3.3/RcppArmadillo/include"
-I"/home/jake/Documents"   -fpic  -I/home/jake/miniconda3/include  -c
norm_laplacian.cpp -o norm_laplacian.o
g++ -shared -L/home/jake/miniconda3/lib/R/lib
-L/home/jake/miniconda3/lib -lgfortran -o sourceCpp_2.so
norm_laplacian.o -L/home/jake/miniconda3/lib/R/lib -lRlapack
-L/home/jake/miniconda3/lib/R/lib -lRblas -lgfortran -lm -lquadmath
-L/home/jake/miniconda3/lib/R/lib -lR
R version 3.3.2 (2016-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.10

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] stats graphics  grDevices utils datasets  base

other attached packages:
[1] Rcpp_0.12.8

loaded via a namespace (and not attached):
[1] tools_3.3.2   RcppArmadillo_0.7.600.1.0

$ g++ --version|head -n1
g++ (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
*

So running the simplified code did not produce a segfault and suggested
that the problem was in SC3::norm_laplacian(). And indeed, running
valgrind with SC3::norm_laplacian(matrix(runif(100), nrow = 10)) did
catch the error:

*
$ R -d valgrind -f norm_laplacian.R
==7046== Memcheck, a memory error detector
==7046== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==7046== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for
copyright info
==7046== Command: /home/jake/miniconda3/lib/R/bin/exec/R -f norm_laplacian.R
==7046==

R version 3.3.2 (2016-10-31) -- "Sincere Pumpkin Patch"
Copyright (C) 2016 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)


library(Rcpp)
sourceCpp("norm_laplacian.cpp", showOutput=TRUE)

/home/jake/miniconda3/lib/R/bin/R CMD SHLIB -o 'sourceCpp_2.so'
 'norm_laplacian.cpp'
g++ -I/home/jake/miniconda3/lib/R/include -DNDEBUG
 -I/home/jake/miniconda3/include
 -I"/home/jake/R/x86_64-pc-linux-gnu-library/3.3/Rcpp/include"
-I"/home/jake/R/x86_64-pc-linux-gnu-library/3.3/RcppArmadillo/include"
-I"/home/jake/Documents"   -fpic  -I/home/jake/miniconda3/include  -c
norm_laplacian.cpp -o norm_laplacian.o
g++ -shared -L/home/jake/miniconda3/lib/R/lib
-L/home/jake/miniconda3/lib -lgfortran -o sourceCpp_2.so
norm_laplacian.o -L/home/jake/miniconda3/lib/R/lib -lRlapack
-L/home/jake/miniconda3/lib/R/lib -lRblas -lgfortran -lm -lquadmath
-L/home/jake/miniconda3/lib/R/lib -lR

xx <- norm_laplacian(matrix(runif(100), nrow = 10))
SC3::norm_laplacian(matrix(runif(100), nrow = 10))

==7046== Use of uninitialised value of size 8
==7046==at 0x213645B8: direct_max (op_max_meat.hpp:362)
==7046==by 0x213645B8: max (Mat_meat.hpp:6801)
==7046==by 0x213645B8: norm_laplacian(arma::Mat)
(cppFunctions.cpp:87)
==7046==by 0x21360E8C: SC3_norm_laplacian (RcppExports.cpp:49)
==7046==by 0x521DE81: R_doDotCall (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x522BD99: do_dotcall (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x5267AAC: Rf_eval (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x526B0A7: do_begin (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x526789E: Rf_eval (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x5268B8C: Rf_applyClosure (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x5267BBF: Rf_eval (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x52A6C1E: Rf_ReplIteration (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x52A6DD1: R_ReplConsole (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x52A8758: run_Rmainloop (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==
==7046== Invalid read of size 8
==7046==at 0x213645B8: direct_max (op_max_meat.hpp:362)
==7046==by 0x213645B8: max (Mat_meat.hpp:6801)
==7046==by 0x213645B8: norm_laplacian(arma::Mat)
(cppFunctions.cpp:87)
==7046==by 0x21360E8C: SC3_norm_laplacian (RcppExports.cpp:49)
==7046==by 0x521DE81: R_doDotCall (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x522BD99: do_dotcall (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x5267AAC: Rf_eval (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x526B0A7: do_begin (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x526789E: Rf_eval (in
/home/jake/miniconda3/lib/R/lib/libR.so)

Re: [Bioc-devel] R version-dependent segfault

[Vladimir Kiselev]

Dear Martin,

Many thanks for your reply, it was really helpful. My collaborator ran the
commands you suggested and got the following output:

*
$ Rscript norm_laplacian.R
/home/jake/miniconda3/lib/R/bin/R CMD SHLIB -o 'sourceCpp_2.so'
 'norm_laplacian.cpp'
g++ -I/home/jake/miniconda3/lib/R/include -DNDEBUG
 -I/home/jake/miniconda3/include
 -I"/home/jake/R/x86_64-pc-linux-gnu-library/3.3/Rcpp/include"
-I"/home/jake/R/x86_64-pc-linux-gnu-library/3.3/RcppArmadillo/include"
-I"/home/jake/Documents"   -fpic  -I/home/jake/miniconda3/include  -c
norm_laplacian.cpp -o norm_laplacian.o
g++ -shared -L/home/jake/miniconda3/lib/R/lib -L/home/jake/miniconda3/lib
-lgfortran -o sourceCpp_2.so norm_laplacian.o
-L/home/jake/miniconda3/lib/R/lib -lRlapack
-L/home/jake/miniconda3/lib/R/lib -lRblas -lgfortran -lm -lquadmath
-L/home/jake/miniconda3/lib/R/lib -lR
R version 3.3.2 (2016-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.10

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] stats graphics  grDevices utils datasets  base

other attached packages:
[1] Rcpp_0.12.8

loaded via a namespace (and not attached):
[1] tools_3.3.2   RcppArmadillo_0.7.600.1.0

$ g++ --version|head -n1
g++ (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
*

So running the simplified code did not produce a segfault and suggested
that the problem was in SC3::norm_laplacian(). And indeed, running valgrind
with SC3::norm_laplacian(matrix(runif(100), nrow = 10)) did catch the error:

*
$ R -d valgrind -f norm_laplacian.R
==7046== Memcheck, a memory error detector
==7046== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==7046== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright
info
==7046== Command: /home/jake/miniconda3/lib/R/bin/exec/R -f norm_laplacian.R
==7046==

R version 3.3.2 (2016-10-31) -- "Sincere Pumpkin Patch"
Copyright (C) 2016 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

> library(Rcpp)
> sourceCpp("norm_laplacian.cpp", showOutput=TRUE)
/home/jake/miniconda3/lib/R/bin/R CMD SHLIB -o 'sourceCpp_2.so'
 'norm_laplacian.cpp'
g++ -I/home/jake/miniconda3/lib/R/include -DNDEBUG
 -I/home/jake/miniconda3/include
 -I"/home/jake/R/x86_64-pc-linux-gnu-library/3.3/Rcpp/include"
-I"/home/jake/R/x86_64-pc-linux-gnu-library/3.3/RcppArmadillo/include"
-I"/home/jake/Documents"   -fpic  -I/home/jake/miniconda3/include  -c
norm_laplacian.cpp -o norm_laplacian.o
g++ -shared -L/home/jake/miniconda3/lib/R/lib -L/home/jake/miniconda3/lib
-lgfortran -o sourceCpp_2.so norm_laplacian.o
-L/home/jake/miniconda3/lib/R/lib -lRlapack
-L/home/jake/miniconda3/lib/R/lib -lRblas -lgfortran -lm -lquadmath
-L/home/jake/miniconda3/lib/R/lib -lR
> xx <- norm_laplacian(matrix(runif(100), nrow = 10))
> SC3::norm_laplacian(matrix(runif(100), nrow = 10))
==7046== Use of uninitialised value of size 8
==7046==at 0x213645B8: direct_max (op_max_meat.hpp:362)
==7046==by 0x213645B8: max (Mat_meat.hpp:6801)
==7046==by 0x213645B8: norm_laplacian(arma::Mat)
(cppFunctions.cpp:87)
==7046==by 0x21360E8C: SC3_norm_laplacian (RcppExports.cpp:49)
==7046==by 0x521DE81: R_doDotCall (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x522BD99: do_dotcall (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x5267AAC: Rf_eval (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x526B0A7: do_begin (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x526789E: Rf_eval (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x5268B8C: Rf_applyClosure (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x5267BBF: Rf_eval (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x52A6C1E: Rf_ReplIteration (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x52A6DD1: R_ReplConsole (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x52A8758: run_Rmainloop (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==
==7046== Invalid read of size 8
==7046==at 0x213645B8: direct_max (op_max_meat.hpp:362)
==7046==by 0x213645B8: max (Mat_meat.hpp:6801)
==7046==by 0x213645B8: norm_laplacian(arma::Mat)
(cppFunctions.cpp:87)
==7046==by 0x21360E8C: SC3_norm_laplacian (RcppExports.cpp:49)
==7046==by 0x521DE81: R_doDotCall (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x522BD99: do_dotcall (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x5267AAC: Rf_eval (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x526B0A7: do_begin (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x526789E: Rf_eval (in
/home/jake/miniconda3/lib/R/lib/libR.so)
==7046==by 0x5268B8C: Rf_applyClosure (in

Re: [Bioc-devel] R version-dependent segfault

[Martin Morgan]

On 01/05/2017 06:41 AM, Vladimir Kiselev wrote:

My package (SC3 - http://bioconductor.org/packages/3.4/bioc/html/SC3.html)
has a function that causes R version/platform-dependent seqfault. Here is
the function (it's in C++ using RccpArmadillo):

arma::mat norm_laplacian(arma::mat A) {
A = exp(-A/A.max());
arma::rowvec D_row = pow(sum(A), -0.5);
A.each_row() %= D_row;
colvec D_col = conv_to< colvec >::from(D_row);
A.each_col() %= D_col;
arma::mat res = eye(A.n_cols, A.n_cols) - A;
return(res);
}

The test code that provides a segfault on some R versions/platforms:
SC3::norm_laplacian(matrix(runif(100), nrow = 10))


The first line of attack is to simplify the problem as much as possible. 
I did this by writing a C++ file norm_laplacian.cpp


#include 

using namespace arma;

// [[Rcpp::depends(RcppArmadillo)]]

// [[Rcpp::export]]
arma::mat norm_laplacian(arma::mat A) {
A = exp(-A/A.max());
arma::rowvec D_row = pow(sum(A), -0.5);
A.each_row() %= D_row;
colvec D_col = conv_to< colvec >::from(D_row);
A.each_col() %= D_col;
arma::mat res = eye(A.n_cols, A.n_cols) - A;
return(res);
}

and then in R, e.g., norm_laplacian.R

library(Rcpp)
sourceCpp("norm_laplacian.cpp", showOutput=TRUE)
xx <- norm_laplacian(matrix(runif(100), nrow = 10))
sessionInfo()

It would be helpful to use set.seed() to make the example more 
reproducible. One would hope that


R -f norm_laplacian.R

would produce a segfault. Unfortunately not for me. My next step was to 
run this code under valgrind to look for invalid memory access


R -d valgrind -f norm_laplacian.R

again hoping for a report of 'invalid write' or 'invalid read', but 
again no luck for me.


You could see if your collaborators are able to generate segfaults with 
this simpler code. If R -f norm_laplacian.R is sufficient, the next step 
would be to run it under a C-level debugger like gdb, with some hints at 
http://bioconductor.org/developers/how-to/c-debugging/


Here's my output; it's also useful to know information about the 
compiler, and to pay attention to the compiler options (especially 
optimization level -O0 for me)


$ g++ --version|head -n1
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609

$ R --vanilla -f norm_laplacian.R
> library(Rcpp)
> sourceCpp("norm_laplacian.cpp", showOutput=TRUE)
/home/mtmorgan/bin/R-devel/bin/R CMD SHLIB -o 'sourceCpp_2.so' 
'norm_laplacian.cpp'
g++  -I/home/mtmorgan/bin/R-devel/include -DNDEBUG  -I/usr/local/include 

-I"/home/mtmorgan/R/x86_64-pc-linux-gnu-library/3.4-Bioc-3.5/Rcpp/include" 
-I"/home/mtmorgan/R/x86_64-pc-linux-gnu-library/3.4-Bioc-3.5/RcppArmadillo/include" 
-I"/tmp"   -fpic  -g -O0 -c norm_laplacian.cpp -o norm_laplacian.o
g++ -shared -L/home/mtmorgan/bin/R-devel/lib -L/usr/local/lib -o 
sourceCpp_2.so norm_laplacian.o -L/home/mtmorgan/bin/R-devel/lib 
-lRlapack -L/home/mtmorgan/bin/R-devel/lib -lRblas -lgfortran -lm 
-lquadmath -L/home/mtmorgan/bin/R-devel/lib -lR

> xx <- norm_laplacian(matrix(runif(100), nrow = 10))
> sessionInfo()
R Under development (unstable) (2016-12-20 r71827)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04.1 LTS

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] stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] Rcpp_0.12.8.3

loaded via a namespace (and not attached):
[1] compiler_3.4.0tools_3.4.0
[3] RcppArmadillo_0.7.600.1.0
>


if the segfault does not occur with the simpler code, then one could try 
gdb / valgrind with SC3::norm_laplacian(matrix(runif(100), nrow = 10))


Martin



The segfault usually looks like this:
*** caught segfault ***
address 0x7ffdc981e000, cause 'memory not mapped'

(where address can be a different sequence)

So far by a collaborative effort (me and some users of the package) we
figured out configurations that cause or do not cause a segfault:

* Configurations causing a segfault:

R version 3.3.2 (2016-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Arch Linux

R version 3.3.2 (2016-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.10

* Configurations causing no segfault:

R version 3.3.2 (2016-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04.1 LTS

R version 3.3.1 (2016-06-21)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.5 LTS

R version 3.3.0 (2016-05-03)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu precise (12.04.5 LTS)

R Under development (unstable) (2016-10-20 r71540)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: OS X Yosemite 10.10.5

More details on our discussion can be found here:

[Bioc-devel] R version-dependent segfault

[Vladimir Kiselev]

My package (SC3 - http://bioconductor.org/packages/3.4/bioc/html/SC3.html)
has a function that causes R version/platform-dependent seqfault. Here is
the function (it's in C++ using RccpArmadillo):

arma::mat norm_laplacian(arma::mat A) {
A = exp(-A/A.max());
arma::rowvec D_row = pow(sum(A), -0.5);
A.each_row() %= D_row;
colvec D_col = conv_to< colvec >::from(D_row);
A.each_col() %= D_col;
arma::mat res = eye(A.n_cols, A.n_cols) - A;
return(res);
}

The test code that provides a segfault on some R versions/platforms:
SC3::norm_laplacian(matrix(runif(100), nrow = 10))

The segfault usually looks like this:
*** caught segfault ***
address 0x7ffdc981e000, cause 'memory not mapped'

(where address can be a different sequence)

So far by a collaborative effort (me and some users of the package) we
figured out configurations that cause or do not cause a segfault:

* Configurations causing a segfault:

R version 3.3.2 (2016-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Arch Linux

R version 3.3.2 (2016-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.10

* Configurations causing no segfault:

R version 3.3.2 (2016-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04.1 LTS

R version 3.3.1 (2016-06-21)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.5 LTS

R version 3.3.0 (2016-05-03)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu precise (12.04.5 LTS)

R Under development (unstable) (2016-10-20 r71540)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: OS X Yosemite 10.10.5

More details on our discussion can be found here:
https://github.com/hemberg-lab/SC3/issues/33

Has anybody had a similar issue? Do you have any suggestions on how to fix
this, except rewriting the function in R? Or maybe there already exists a
normalised Laplacian function written in C++?

Many thanks,
Cheers,
Vladimir
-- 
http://genat.uk

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] R-version

[Martin Morgan]

On 09/15/2013 07:12 AM, Wolfgang Huber wrote:

Dear Julian
thanks.

Since this has come up here and elsewhere, and since the next Bioc release is coming up, 
let's remind ourselves that we should make development against 3.0.1 Patched (2013-09-03 
r63824) -- Good Sport.

Martin - should this be noted on 
http://www.bioconductor.org/developers/release-schedule ?
Not sure what relevance this has in practice, but it seems wise to eliminate 
unnecessary variables.



Thanks, the release notes have been updated. A short post to Bioc-devel with 
some additional pertinent information is forthcoming.


Martin


Best wishes
Wolfgang


On Sep 15, 2013, at 4:01 pm, Julian Gehring julian.gehr...@embl.de wrote:


Hi,

calling 'head' or 'tail' on a 'RangedData' objects fail with the lastest builds 
(R: 2013-09-14 r63932, IRanges: 1.19.35).  The cause seems to be that there is 
no 'extractROWS' method that can be found for the signature 'RangedData'.  As 
an example, see:

'''
library(IRanges)

## generate the data
ranges - IRanges(c(1,2,3),c(4,5,6))
rd = RangedData(ranges)

## this fails
head(rd)
'''

The last command returns: Error in (function (classes, fdef, mtable)  : unable to find an 
inherited method for function ‘extractROWS’ for signature ‘RangedData’

Best wishes
Julian

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


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




--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M1 B861
Phone: (206) 667-2793

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

Re: [Bioc-devel] R version in Bioc packages (was Re: [BioC] Package \'jmosaics\' not found)

[Dan Tenenbaum]

Hi Steffen,



On Tue, May 21, 2013 at 12:40 PM, Steffen Neumann sneum...@ipb-halle.de wrote:
 Hi,

 On Tue, 2013-05-21 at 11:47 -0400, James W. MacDonald wrote:
 Not that I can recall. But I do agree that it is at minimum redundant
 and probably just wrong to have R-version requirements for BioC packages.

 I'd like to disagree. BioC *promises* that stuff works together
 at a certain point in time, simply because that stuff was green
 at the build farm at that time.


No, it's more than that. We *intend* that all packages in a given BioC
version will work with all other packages in that version. Conversely,
we pretty much guarantee problems if you start mixing and matching.



 But what should keep me as a developer from promising
 that my stuff also works on older releases ?
 (For the fun of it, I once bisected R versions to find
  a minimal R version for xcms ...).


For one thing, dependeing on when your package was introduced, there
is an older version of it already available that will work with the
older R version. Of course it may not have the coolest new features
but it is there.
For example, xcms was introduced in BioC 1.6, a long time ago. And so
anyone running R 2.1 or earlier can simply
source(http://bioconductor.org/biocLite.R;)
biocLite(xcms)
and the appropriate version of xcms (and all its dependencies) for
that version of BioC will be installed.



 So why shouldn't I declare that xcms still runs on R-2.14.0 ?
 I can R CMD check it there, and if someone knows what he does,
 he can bypass biocLite() and install the latest from SVN manually.


Sureone can do a lot of things but that doesn't mean they are the
right things to do.

Dan



 If I *know* xcms won't work reliably with R-2.13 and older,
 then omitting Depends: R (= 2.14.0) means that someone
 with an old cluster (which oftentimes receives fewer upgrades
 than your average laptop) with venerable R-2.10.0 fill fail
 *at some time* rather than on install time.

 Just my 2c.

 Yours,
 Steffen

 --
 IPB HalleAG Massenspektrometrie  Bioinformatik
 Dr. Steffen Neumann  http://www.IPB-Halle.DE
 Weinberg 3   http://msbi.bic-gh.de
 06120 Halle  Tel. +49 (0) 345 5582 - 1470
   +49 (0) 345 5582 - 0
 sneumann(at)IPB-Halle.DE Fax. +49 (0) 345 5582 - 1409

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

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

Re: [Bioc-devel] R version in Bioc packages (was Re: [BioC] Package \'jmosaics\' not found)

[Dan Tenenbaum]

On Tue, May 21, 2013 at 1:01 PM, Dan Tenenbaum dtene...@fhcrc.org wrote:
 Hi Steffen,



 On Tue, May 21, 2013 at 12:40 PM, Steffen Neumann sneum...@ipb-halle.de 
 wrote:
 Hi,

 On Tue, 2013-05-21 at 11:47 -0400, James W. MacDonald wrote:
 Not that I can recall. But I do agree that it is at minimum redundant
 and probably just wrong to have R-version requirements for BioC packages.

 I'd like to disagree. BioC *promises* that stuff works together
 at a certain point in time, simply because that stuff was green
 at the build farm at that time.


 No, it's more than that. We *intend* that all packages in a given BioC
 version will work with all other packages in that version. Conversely,
 we pretty much guarantee problems if you start mixing and matching.



 But what should keep me as a developer from promising
 that my stuff also works on older releases ?
 (For the fun of it, I once bisected R versions to find
  a minimal R version for xcms ...).


 For one thing, dependeing on when your package was introduced, there
 is an older version of it already available that will work with the
 older R version. Of course it may not have the coolest new features
 but it is there.
 For example, xcms was introduced in BioC 1.6, a long time ago. And so
 anyone running R 2.1 or earlier can simply

er, 2.1 or *later*



 source(http://bioconductor.org/biocLite.R;)
 biocLite(xcms)
 and the appropriate version of xcms (and all its dependencies) for
 that version of BioC will be installed.



 So why shouldn't I declare that xcms still runs on R-2.14.0 ?
 I can R CMD check it there, and if someone knows what he does,
 he can bypass biocLite() and install the latest from SVN manually.


 Sureone can do a lot of things but that doesn't mean they are the
 right things to do.

 Dan



 If I *know* xcms won't work reliably with R-2.13 and older,
 then omitting Depends: R (= 2.14.0) means that someone
 with an old cluster (which oftentimes receives fewer upgrades
 than your average laptop) with venerable R-2.10.0 fill fail
 *at some time* rather than on install time.

 Just my 2c.

 Yours,
 Steffen

 --
 IPB HalleAG Massenspektrometrie  Bioinformatik
 Dr. Steffen Neumann  http://www.IPB-Halle.DE
 Weinberg 3   http://msbi.bic-gh.de
 06120 Halle  Tel. +49 (0) 345 5582 - 1470
   +49 (0) 345 5582 - 0
 sneumann(at)IPB-Halle.DE Fax. +49 (0) 345 5582 - 1409

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

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