Re: [Bioc-devel] Contradicting descriptions of "Enhances"
> Dan Tenenbaum > on Sun, 3 Aug 2014 22:59:52 -0700 writes: > - Original Message - >> From: "Jonathan Rosenblatt" To: >> bioc-devel@r-project.org Sent: Sunday, August 3, 2014 >> 10:39:57 PM Subject: [Bioc-devel] Contradicting >> descriptions of "Enhances" >> >> At the time of writing: >> >> *Writing R Extensions:* "...the ‘Enhances’ field lists >> packages “enhanced” by the package at hand..." > This is backwards, maybe just a grammar fail? IMO it > should say "the 'Enhances' field lists packages which > 'enhance' the package at hand, if they are present." I don't think so! Dan, what you describe is basically 'Suggests'. 'Enhances' is used more rarely, and indeed meant for what it says in WRE. Otherwise, please bring this to the R-devel m.list. >> *Bioconductor:* "Enhances: is for packages such as Rmpi >> or parallel that enhance the performance of the current >> package, but are not strictly needed for its >> functionality." and the above is not correct, IMO. Martin >> Have these definitions been resolved? >> > IMO R-exts should be corrected along the lines I suggest > above (and R-devel is the appropriate place for such a > suggestion); however, the text on the bioc site is also > probably less than ideal (will confer with bioc core as to > how to rewrite it). Rmpi and parallel are not _always_ > "take it or leave it" packages. Other than the grammar > blooper, R-exts goes on to give more detailed and correct > information, the most important bit of which is that all > invocations of packages in enhances should be wrapped in > if (require(somePkg)). > Dan >> >> >> -- >> -- >> Jonathan Rosenblatt Postdoctoral Researcher Faculty of >> Mathematics and CS Weizmann Institute of Science >> www.john-ros.com >> >> [[alternative HTML version deleted]] >> >> >> ___ >> 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 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Latest R-devel revision breaks flowCore and other flow packages
>>>>> Mike
>>>>> on Tue, 20 Jan 2015 17:16:37 -0800 writes:
> I don't think it has been addressed yet in the later commits of R-devel.
> And that piece of code in flowCore package was written long time ago and
> there is nothing wrong with it as far as I can see.
You are right.
I thought Michael Lawrence (member of R Core since last summer!)
was also reading Bioc-devel, so wonder why he has not yet
replied --> CC'ing him
The changes to R-devel also did break the Matrix package in
exactly the same way. You said
> > Here is the |initialize|method for |parameterFilter| which causes the
> > various errors from flow package vignettes.
> >
> > |setMethod("initialize",
> >signature=signature(.Object="parameterFilter"),
> >definition=function(.Object, parameters,...)
> >{
> > if (!missing(parameters))
> >parameters(.Object) <- parameters
> > callNextMethod()
> >})
> > |
and I also had a _no argument_ call
callNextMethod()
inside an initialize method.
I'm pretty sure that if you change (the same as I)
callNextMethod()
to
callNextMethod(.Object, ...)
you'll have a version of the code that works both in current R 3.1.2
(and older versions) *and* in the R-devel version.
Michael L and I were not sure how many other packages or R code this
would influence and he was expecting very very few.
Best regards,
Martin Maechler, ETH Zurich
> On 01/20/2015 05:06 PM, Dan Tenenbaum wrote:
>> I'm not sure if you were implying that this has already been fixed in
R-devel. Note that the devel build machines currently have r67501 installed,
which is later than all the commits you cite above, yet the flow packages are
still broken.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] [Rd] For integer vectors, `as(x, "numeric")` has no effect.
>>>>> Martin Maechler
>>>>> on Tue, 8 Dec 2015 15:25:21 +0100 writes:
>>>>> John Chambers
>>>>> on Mon, 7 Dec 2015 16:05:59 -0800 writes:
>> We do need an explicit method here, I think.
>> The issue is that as() uses methods for the generic function coerce()
but cannot use inheritance in the usual way (if it did, you would be
immediately back with no change, since "integer" inherits from "numeric").
>> Copying in the general method for coercing to "numeric" as an explicit
method for "integer" gives the expected result:
>>> setMethod("coerce", c("integer", "numeric"), getMethod("coerce",
c("ANY", "numeric")))
>> [1] "coerce"
>>> typeof(as(1L, "numeric"))
>> [1] "double"
>> Seems like a reasonable addition to the code, unless someone sees a
problem.
>> John
> I guess that that some package checks (in CRAN + Bioc + ... -
> land) will break,
> but I still think we should add such a coercion to R.
> Martin
Hmm... I've tried to add the above to R
and do notice that there are consequences that may be larger than
anticipated:
Here is example code:
myN <- setClass("myN", contains="numeric")
myNid <- setClass("myNid", contains="numeric",
representation(id="character"))
NN <-setClass("NN", representation(x="numeric"))
(m1 <- myN (1:3))
(m2 <- myNid(1:3, id = "i3"))
tools::assertError(NN (1:3))# in all R versions
## # current R | new R
## # ---|--
class(getDataPart(m1)) # integer| numeric
class(getDataPart(m2)) # integer| numeric
In other words, with the above setting, the traditional
gentleperson's agreement in S and R,
__ "numeric" sometimes conveniently means "integer" or "double" __
will be slightly less often used ... which of course may be a
very good thing.
However, it breaks strict back compatibility also in cases where
the previous behavior may have been preferable:
After all integer vectors need only have the space of doubles.
Shall we still go ahead and do apply this change to R-devel
and then all package others will be willing to update where necessary?
As this may affect the many hundreds of bioconductor packages
using S4 classes, I am -- exceptionally -- cross posting to the
bioc-devel list.
Martin Maechler
>> On Dec 7, 2015, at 3:37 PM, Benjamin Tyner wrote:
>>> Perhaps it is not that surprising, given that
>>>
>>> > mode(1L)
>>> [1] "numeric"
>>>
>>> and
>>>
>>> > is.numeric(1L)
>>> [1] TRUE
>>>
>>> On the other hand, this is curious, to say the least:
>>>
>>> > is.double(as(1L, "double"))
>>> [1] FALSE
>>>
>>>> Here's the surprising behavior:
>>>>
>>>> x <- 1L
>>>> xx <- as(x, "numeric")
>>>> class(xx)
>>>> ## [1] "integer"
>>>>
>>>> It occurs because the call to `as(x, "numeric")` dispatches the coerce
>>>> S4 method for the signature `c("integer", "numeric")`, whose body is
>>>> copied in below.
>>>>
>>>> function (from, to = "numeric", strict = TRUE)
>>>> if (strict) {
>>>> class(from) <- "numeric"
>>>> from
>>>> } else from
>>>>
>>>> This in turn does nothing, even when strict=TRUE, because that
>>>> assignment to class "numeric" has no effect:
>>>>
>>>> x <- 10L
>>>> class(x) <- "numeric"
>>>> class(x)
>>>> [1] "integer"
>>>>
>>>> Is this the desired behavior for `as(x, "numeric")`?
>>>
>>> __
>>> r-de...@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> __
>> r-de...@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> __
> r-de...@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] [Rd] For integer vectors, `as(x, "numeric")` has no effect.
>>>>> John Chambers
>>>>> on Fri, 11 Dec 2015 10:11:05 -0800 writes:
> Somehow, the most obvious fixes are always back-incompatible these days.
> The example intrigued me, so I looked into it a bit (should have been
doing something else, but )
> You're right that this is the proverbial thin-edge-of-the-wedge.
> The problem is in setDataPart(), which will be called whenever a class
extends one of the vector types.
> It does
> as(value, dataClass)
> The key point is that the third argument to as(), strict=TRUE by default.
So, yes, the change will cause all integer vectors to become double when the
class extends "numeric". Generally, strict=TRUE makes sense here and of course
changing THAT would open up yet more incompatibilities.
> For back compatibility, one would have to have some special code in
setDataPart() for the case of integer/numeric.
> John
> (Historically, the original sin was probably not making a distinction
between "numeric" as a virtual class and "double" as a type/class.)
Yes, indeed. In the mean time, I've seen more cases where
"the change will cause all integer vectors to become double when the class
extends "numeric".
seems detrimental.
OTOH, I still think we could go in the right direction ---
hopefully along the wishes of bioconductor S4 development, see
Martin Morgan's e-mail:
[This is all S4 - only; should not much affect base R / S3]
Currently, "integer" is a subclass of "numeric" and so the
"integer become double" part seems unwanted to me.
OTOH, it would really make sense to more formally
have the basic subclasses of "numeric" to be "integer" and "double",
and to let as(*, "double") to become different to as(*, "numeric")
[Again, this is just for the S4 classes and as() coercions, *not* e.g.
for as.numeric() / as.double() !]
In the DEPRECATED part of the NEWS for R 2.7.0 (April 2008) we
have had
o The S4 pseudo-classes "single" and double have been removed.
(The S4 class for a REALSXP is "numeric": for back-compatibility
as(x, "double") coerces to "numeric".)
I think the removal of "single" was fine, but in hindsight,
maybe the removal of "double" -- which was partly broken then --
possibly could rather have been a fixup of "double" along the
following
Current "thought experiment proposal" :
1) "numeric" := {"integer", "double"} { class - subclasses }
2) as(1L, "numeric") continues to return 1L .. since integer is
one case of "numeric"
3) as(1L, "double") newly returns 1.0 {and in fact would be
"equivalent" to as.double(1L)}
After the above change, S4 as(*, "double") would correspond to S3 as.double
but as(*, "numeric") would continue to differ from
as.numeric(*), the former *not* changing integers to double.
Martin
> On Dec 11, 2015, at 1:25 AM, Martin Maechler
wrote:
>>>>>>> Martin Maechler
>>>>>>> on Tue, 8 Dec 2015 15:25:21 +0100 writes:
>>
>>>>>>> John Chambers
>>>>>>> on Mon, 7 Dec 2015 16:05:59 -0800 writes:
>>
>>>> We do need an explicit method here, I think.
>>>> The issue is that as() uses methods for the generic function coerce()
but cannot use inheritance in the usual way (if it did, you would be
immediately back with no change, since "integer" inherits from "numeric").
>>
>>>> Copying in the general method for coercing to "numeric" as an explicit
method for "integer" gives the expected result:
>>
>>>>> setMethod("coerce", c("integer", "numeric"), getMethod("coerce",
c("ANY", "numeric")))
>>>> [1] "coerce"
>>>>> typeof(as(1L, "numeric"))
>>>> [1] "double"
>>
>>>> Seems like a reasonable addition to the code, unless someone sees a
problem.
>>>> John
>>
>>> I guess that that some package checks (in CRAN + Bioc + ... -
>>> land) will break,
>>> but I still think we should add such a coercion to R.
>>
>>> Martin
>>
>> Hmm... I've tried to add the above to R
>> and do notice that there are consequences that may be larger than
>>
Re: [Bioc-devel] [Rd] For integer vectors, `as(x, "numeric")` has no effect.
>>>>> Martin Maechler
>>>>> on Sat, 12 Dec 2015 10:32:51 +0100 writes:
>>>>> John Chambers
>>>>> on Fri, 11 Dec 2015 10:11:05 -0800 writes:
>> Somehow, the most obvious fixes are always back-incompatible these days.
>> The example intrigued me, so I looked into it a bit (should have been
doing something else, but )
>> You're right that this is the proverbial thin-edge-of-the-wedge.
>> The problem is in setDataPart(), which will be called whenever a class
extends one of the vector types.
>> It does
>> as(value, dataClass)
>> The key point is that the third argument to as(), strict=TRUE by
default. So, yes, the change will cause all integer vectors to become double
when the class extends "numeric". Generally, strict=TRUE makes sense here and
of course changing THAT would open up yet more incompatibilities.
>> For back compatibility, one would have to have some special code in
setDataPart() for the case of integer/numeric.
>> John
>> (Historically, the original sin was probably not making a distinction
between "numeric" as a virtual class and "double" as a type/class.)
> Yes, indeed. In the mean time, I've seen more cases where
> "the change will cause all integer vectors to become double when the
class extends "numeric".
> seems detrimental.
> OTOH, I still think we could go in the right direction ---
> hopefully along the wishes of bioconductor S4 development, see
> Martin Morgan's e-mail:
> [This is all S4 - only; should not much affect base R / S3]
> Currently, "integer" is a subclass of "numeric" and so the
> "integer become double" part seems unwanted to me.
> OTOH, it would really make sense to more formally
> have the basic subclasses of "numeric" to be "integer" and "double",
> and to let as(*, "double") to become different to as(*, "numeric")
> [Again, this is just for the S4 classes and as() coercions, *not* e.g.
> for as.numeric() / as.double() !]
> In the DEPRECATED part of the NEWS for R 2.7.0 (April 2008) we
> have had
> o The S4 pseudo-classes "single" and double have been removed.
> (The S4 class for a REALSXP is "numeric": for back-compatibility
> as(x, "double") coerces to "numeric".)
> I think the removal of "single" was fine, but in hindsight,
> maybe the removal of "double" -- which was partly broken then --
> possibly could rather have been a fixup of "double" along the
> following
> Current "thought experiment proposal" :
> 1) "numeric" := {"integer", "double"} { class - subclasses }
> 2) as(1L, "numeric") continues to return 1L .. since integer is
> one case of "numeric"
> 3) as(1L, "double") newly returns 1.0 {and in fact would be
> "equivalent" to as.double(1L)}
> After the above change, S4 as(*, "double") would correspond to S3
as.double
> but as(*, "numeric") would continue to differ from
> as.numeric(*), the former *not* changing integers to double.
> Martin
Also note that e.g.
class(pi)would return "double" instead of "numeric"
and this will break all the bad programming style usages of
if(class(x) == "numeric")
which I tend to see in gazillions of user and even package codes
This bad (aka error prone !) because "correct" usage would be
if(inherits(x, "numeric"))
and that of course would *not* break after the change above.
- - - -
A week later, I'm still pretty convinced it would be worth going
in the direction proposed above.
But I was actually hoping for some encouragement or "mental support"...
or then to hear why you think the proposition is not good or not
viable ...
>> On Dec 11, 2015, at 1:25 AM, Martin Maechler
wrote:
>>>>>>>> Martin Maechler
>>>>>>>> on Tue, 8 Dec 2015 15:25:21 +0100 writes:
>>>
>>>>>>>> John Chambers
>>>>>>>> on Mon, 7 Dec 2015 16:05:59 -0800 writes:
>>>
>>>>> We do need an explicit method here, I think.
>>>>> The issue is that as() uses methods for the generic function coerce()
but cannot use inheritance in the usual way (if it did, you would be
immediately back with no change, since "integer" inh
Re: [Bioc-devel] \donttest and the "80% of man pages documenting exported objects must have runnable examples" rule
>>>>> Martin Morgan
>>>>> on Sun, 15 May 2016 14:25:01 -0400 writes:
> On 05/15/2016 02:20 PM, Dan Tenenbaum wrote:
>>
>>
>> - Original Message -
>>> From: "Richard Cotton" To:
>>> "bioc-devel" Sent: Sunday,
>>> May 15, 2016 4:45:09 AM Subject: [Bioc-devel] \donttest
>>> and the "80% of man pages documenting exported objects
>>> must have runnable examples" rule
>>
>>> I have a package with a lot of examples in exported
>>> functions marked as \donttest.
>>>
>>> BiocCheck doesn't count these functions towards the
>>> target of having 80% of exported objects with runnable
>>> examples. I do have more than 80% runnable examples;
>>> it's just that BiocCheck can't see them. (For
>>> background, the package is mostly about file import, and
>>> it takes a second or two to import the sample files
>>> included in the package. Having examples that run for a
>>> couple of seconds is fine for users, but makes package
>>> testing very slow (once dozens of the example are run).
>>>
>>> This check is considered REQUIRED to be solved, so I'd
>>> like to know if it's OK to include an explanation about
>>> the use of \donttest during submission, or if my pacakge
>>> will just get rejected outright.
>>>
>>
>>
>> Ultimately, humans make all decisions about package
>> inclusion. So you will have a chance to discuss your
>> package with someone.
> Examples traditionally have dual roles in illustrating
> functionality and testing code. It would be particularly
> favorable if you could point to other parts of your
> package where the code was tested -- unit tests via RUnit
> or testthat being a natural place, see
> http://bioconductor.org/developers/how-to/unitTesting-guidelines/
> -- and it's use illustrated -- vignettes or other
> examples.
> Martin
I also wonder *why* you use \donttest{} so extensively.
It's clearly better than \dontrun{} (which really distresses
me, if used more than occasionally).
I was involved 20 years ago ensuring that in R, almost all
help pages have examples *and* that all examples ran, and you
could use example(<..>) to let them run, get quickly some
example objects into your R session, etc, etc, etc.
Hence, I've recently felt chagrined repeatedly, seeing package
authors providing whole packages with no runnable examples..
the other Martin M
(Martin Maechler, ETH Zurich)
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] The story of tracing a derfinder bug on OSX that sometimes popped up, sometimes it didn't. Related to IRanges/S4Vectors '$<-'
> Andrzej Oleś
> on Wed, 22 Mar 2017 10:29:57 +0100 writes:
> Just for the record, on R-3.3.2 Herve's code fails with the following
error:
> Error in x[TRUE] <- new("A") :
> incompatible types (from S4 to logical) in subassignment type fix
yes, (of course) and I would be interested in a small
reproducible example which uses _valid_ code.
We have seen such examples with something (more complicated
than, but basically like)
df <- data.frame(x=1:5, y=5:1, m=matrix(-pi*1:30, 5,6))
M <- Matrix::Matrix(exp(0:3),2)
df[1:2,1:2] <- M
which actually calls `[<-`, and then `[<-.data.frame` and
always works for me but does seg.fault (in the CRAN checks of
package FastImputation (on 3 of the dozen platforms,
https://cran.r-project.org/web/checks/check_results_FastImputation.html
one of them is
https://www.r-project.org/nosvn/R.check/r-devel-macos-x86_64-clang/FastImputation-00check.html
I strongly suspect this is the same bug as yours, but for a case
where the correct behavior is *not* giving an error.
I have also written and shown Herve's example to the R-core team.
Unfortunately, I have no platform where I can trigger the bug.
Martin
> Cheers,
> Andrzej
> On Wed, Mar 22, 2017 at 1:28 AM, Martin Morgan <
> martin.mor...@roswellpark.org> wrote:
>> On 03/21/2017 08:21 PM, Hervé Pagès wrote:
>>
>>> Hi Leonardo,
>>>
>>> Thanks for hunting down and isolating that bug! I tried to simplify
>>> your code even more and was able to get a segfault with just:
>>>
>>> setClass("A", representation(stuff="numeric"))
>>> x <- logical(10)
>>> x[TRUE] <- new("A")
>>>
>>> I get the segfault about 50% of the time on a fresh R session on Mac.
>>> I tried this with R 3.3.3 on Mavericks, and with R devel (r72372)
>>> on El Capitan. I get the segfault on both.
>>>
>>> So it looks like a bug in the `[<-` primitive to me (subassignment).
>>>
>>
>> Any insight from
>>
>> R -d valgrind -f herve.R
>>
>> where herve.R contains the code above?
>>
>> Martin
>>
>>
>>
>>> Cheers,
>>> H.
>>>
>>> On 03/21/2017 03:06 PM, Leonardo Collado Torres wrote:
>>>
Hi bioc-devel,
This is a story about a bug that took me a long time to trace. The
behaviour was really weird, so I'm sharing the story in case this
helps others in the future. I was originally writing it to request
help, but then I was able to find the issue ^^. The story ends right
now with code that will reproduce the problem with '$<-' from
IRanges/S4Vectors.
During this Bioc cycle, frequently my package derfinder has failed to
pass R CMD check in OSX. The error is always the same when it appears
and sometimes it shows up in release, but not devel and viceversa.
Right now (3/21/2017) it's visible in both
https://urldefense.proofpoint.com/v2/url?u=http-3A__biocondu
ctor.org_checkResults_release_bioc-2DLATEST_derfinder_
morelia-2Dchecksrc.html&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfh
Q&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=Bw-1Kqy-M_
t4kmpYWTpYkt5bvj_eTpxriUM3UvtOIzQ&s=RS-lsygPtDdgWKAhjA2BcSLk
Vy9RxxshXWAJaBZa_Yc&e=
and
https://urldefense.proofpoint.com/v2/url?u=http-3A__biocondu
ctor.org_checkResults_devel_bioc-2DLATEST_derfinder_toluca
2-2Dchecksrc.html&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3X
eAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=Bw-1Kqy-M_
t4kmpYWTpYkt5bvj_eTpxriUM3UvtOIzQ&s=a_K-yK7w2LEV72lpHrpp0UoK
Rru_7Aad74T5Uk0R-Fo&e=
.
The end of "test-all.Rout.fail" looks like this:
Loading required package: foreach
Loading required package: iterators
Loading required package: locfit
locfit 1.5-9.1 2013-03-22
getSegments: segmenting
getSegments: splitting
2017-03-20 02:36:52 findRegions: smoothing
2017-03-20 02:36:52 findRegions: identifying potential segments
2017-03-20 02:36:52 findRegions: segmenting information
2017-03-20 02:36:52 .getSegmentsRle: segmenting with cutoff(s)
16.3681899295041
2017-03-20 02:36:52 findRegions: identifying candidate regions
2017-03-20 02:36:52 findRegions: identifying region clusters
2017-03-20 02:36:52 findRegions: smoothing
2017-03-20 02:36:52 findRegions: identifying potential segments
2017-03-20 02:36:52 findRegions: segmenting information
2017-03-20 02:36:52 .getSegmentsRle: segmenting with cutoff(s)
19.7936614060235
2017-03-20 02:36:52 findRegions: identifying candidate regions
2017-03-20 02:36:52 findRegions: identifying region clusters
2017-03-20 02:36:52 findRegion
Re: [Bioc-devel] any interest in a BiocMatrix core package?
>>>>> "ML" == Michael Lawrence >>>>> on Wed, 1 Nov 2017 14:13:54 -0700 writes: > Probably way easier to add the generics to the Matrix > package and everyone just depends on that. Yes! It is 'Recommended' and comes with every R installation, and has had many such matrix S4 methods in place for > 10 years, notably for dealing with (large) sparse matrices. Honestly, I (as co-maintainer of Matrix, principal maintainer for several years now) had been a bit surprised and frustrated that the 'matrixStats' initiative had started w/o any contact with the Matrix package maintainers and initially has not ever tried to use Matrix package classes or functionality (and this is still the case now AFAICS). I'm happy to coordinate with maintainers of bioc packages about which generics (and classes !) to use and export, etc. Best, Martin Maechler ETH Zurich (and R core team) > On Wed, Nov 1, 2017 at 1:59 PM, Hervé Pagès > wrote: >> That's probably a good idea but a clean solution would >> need to involve all players, including the Matrix >> package. Right now there are conflicts for some S4 >> generics defined in Matrix and in BiocGenerics >> (e.g. rowSums). I'm not sure that moving rowSums from >> BiocGenerics to a new MatrixGenerics package would >> address this. Unless MatrixGenerics is on CRAN and >> Matrix depends on it ;-) >> >> How likely is this to happen? >> >> H. >> >> [] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] any interest in a BiocMatrix core package?
>>>>> Martin Morgan
>>>>> on Thu, 2 Nov 2017 06:17:19 -0400 writes:
> On 11/02/2017 05:00 AM, Martin Maechler wrote:
>>>>>>> "ML" == Michael Lawrence
>>>>>>> on Wed, 1 Nov 2017 14:13:54 -0700 writes:
>>
>> > Probably way easier to add the generics to the Matrix >
>> package and everyone just depends on that.
>>
>> Yes! It is 'Recommended' and comes with every R
>> installation, and has had many such matrix S4 methods in
>> place for > 10 years, notably for dealing with (large)
>> sparse matrices.
>>
>> Honestly, I (as co-maintainer of Matrix, principal
>> maintainer for several years now) had been a bit
>> surprised and frustrated that the 'matrixStats'
>> initiative had started w/o any contact with the Matrix
>> package maintainers and initially has not ever tried to
>> use Matrix package classes or functionality (and this is
>> still the case now AFAICS).
>>
>> I'm happy to coordinate with maintainers of bioc packages
>> about which generics (and classes !) to use and export,
>> etc.
> One issue is that Matrix is a relatively large package
> (well, I wonder if that's a reasonable statement, given
> the Bioc dependencies and data involved, but perhaps in
> general...) and hence 'overkill' to obtain a collection of
> generics. Is there any prospect for factoring out the
> definition of the generics from implementation of the
> methods? Re-purposing stats4 ?
> Martin Morgan
Hmm.. we have quite a few setGenericImplicit() statements in
the methods package already, notably for 'colSums' and friends,
and so other decent citizen packages do *NOT* setGeneric() at
all on these ... and of course, Matrix _is_ a decent citizen in
the R package universe.
Instead of to stats4, I'm pretty sure we should only consider
what functions should be added to the implicit generics already
provided by the 'methods' package itself.
Could it be that (some of) you are not properly aware of
implicit generics?
If you start 'R --vanilla' you can say
> implicitGeneric("colSums")
standardGeneric for "colSums" defined from package "base"
function (x, na.rm = FALSE, dims = 1, ...)
standardGeneric("colSums")
Methods may be defined for arguments: x, na.rm, dims
Use showMethods("colSums") for currently available ones.
-
so I think it is clear how *any* decent package has to define
methods for colSums(), and if they do, there should not be any conflicts.
I think the problem is with S3 methods, not with S4 ones, where
the implicit generics I understand where made for dealing with
several packages writing methods for the same generic without
one of the packages taking precedence.
Martin Mächler
>>
>> Best, Martin Maechler ETH Zurich (and R core team)
>>
>>
>>
>> > On Wed, Nov 1, 2017 at 1:59 PM, Hervé Pagès >
>> wrote:
>>
>> >> That's probably a good idea but a clean solution would
>> >> need to involve all players, including the Matrix >>
>> package. Right now there are conflicts for some S4 >>
>> generics defined in Matrix and in BiocGenerics >>
>> (e.g. rowSums). I'm not sure that moving rowSums from >>
>> BiocGenerics to a new MatrixGenerics package would >>
>> address this. Unless MatrixGenerics is on CRAN and >>
>> Matrix depends on it ;-)
>> >>
>> >> How likely is this to happen?
>> >>
>> >> H.
>> >>
>> >>
>> []
>>
>> ___
>> 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
Re: [Bioc-devel] BioC 3.7 Windows check warning "file link zz in package yy does not exist "
> Ramon Diaz-Uriarte
> on Mon, 9 Apr 2018 16:51:38 +0200 writes:
> Dear Martin,
> On Fri, 06-April-2018, at 18:59:00, Martin Morgan
> wrote:
>> On 04/06/2018 10:44 AM, Lluís Revilla wrote:
>>> I have recently faced a similar warning. This is when a
>>> link to a help page of another package is broken (there
>>> is not such help page). Although those could be false
>>> positives: mclapply help page does exists in parallel
>>> package. as.MAList does exists in devel limma
>>
>> when \link-ing to another package, from
>> RShowDoc("R-exts") section 2.5 the [] has to name the
>> html help page, not the name of the function. For
>> instance, `mclapply` is documented on a man page called
>> mcdummies.Rd (!), so '\link[parallel:mcdummies]{nearest}
>> would presumably not
> I am confused here: as far as I can tell, there is an
> mclapply.html file:
> http://stat.ethz.ch/R-manual/R-devel/library/parallel/html/mclapply.html
> In addition, when I use the \link[parallel:mcdummies] I
> get a warning when testing under Linux.
> On rereading section 2.5, I think \link[pkg]{foo} should
> work too (if there is a foo.html file.)
> Nevertheless, section 2.5 indicates that \link[pkg]{foo}
> and \link[pkg:bar]{foo} are rarely needed, so I'll try to
> remove them (except in those cases, covered in section
> 2.5, where "more than one package offers help on a topic")
Only on Windows, indeed,
mclapply() is just a dummy function, calling lapply() IIRC.
It is unfortunate that given the above you would be lead to use
different \link{}s if you are on Windows than on non-Win...
This would be a good question on the R-package-devel mailing
list.
Martin
>> generate the warning. Similarly
>> \link[limma:asmalist]{as.MAList}.
>>
>> There are several things that still need exploration.
>>
>> - platform-specific (I have a vague understanding that
>> Windows is special, but that might be outdated... [at
>> least in this context...])
>>
> I am only getting the warnings under Windows (which lead
> me to think it was windows misbehaving).
>> - recent. I have to admit to changing the text of the
>> warning with this commit
>>
>>
>>
https://github.com/wch/r-source/commit/cbd7ca1b1aedf0405e11ee2440fbde891cba524e
>>
>> but what I was intending to do was to change what it
>> says, from the warning in release ('missing file link')
>> to what it says, correctly, in devel 'file link ... does
>> not exist and so has been treated as a topic'. The old
>> text appears in release, and the new in devel, as
>> anticipated. If I messed up somehow please let me
>> know...
>>
>> - even with the warning, the link isn't broken in the
>> dynamic help system (it might have been broken prior to
>> my commit...).
> OK, thanks.
> Best,
> R.
>>
>> Martin
>>
>>>
>>> HTH
>>>
>>> On 6 April 2018 at 16:35, Vincent Carey
>>> wrote:
>>>
ive seen this too apropos bigrquery on windows
On Fri, Apr 6, 2018 at 10:22 AM Ramon Diaz-Uriarte
wrote:
>
> Dear All,
>
> Two packages I maintain are showing, in Windows, a
> warning during check with messages like
>
> Rd warning:
>
C:/Users/biocbuild/bbs-3.7-bioc/tmpdir/Rtmp21WlQD/R.INSTALL23343f935731/
OncoSimulR/man/oncoSimulIndiv.Rd:570:
> file link 'mclapply' in package 'parallel' does not
> exist and so has been treated as a topic
>
> or
>
> Rd warning:
> C:/Users/biocbuild/bbs-3.7-bioc/tmpdir/RtmpQfQaA1/R.
INSTALL1ec81d5b6233/ADaCGH2/man/inputToADaCGH.Rd:45:
> file link 'as.MAList' in package 'limma' does not
> exist and so has been treated as a topic
>
>
>
> that I cannot reproduce under Linux and that I think
> are false positives. Is there a way to avoid this
> warning? As far as I can tell, those links really
> exist.
>
> Best,
>
>
> R.
>
> --
> Ramon Diaz-Uriarte Department of Biochemistry, Lab
> B-25 Facultad de Medicina Universidad Autónoma de
> Madrid Arzobispo Morcillo, 4 28029 Madrid Spain
>
> Phone: +34-91-497-2412
>
> Email: rdia...@gmail.com ramon.d...@iib.uam.es
>
> http://ligarto.org/rdiaz
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
[[alternative HTML version deleted]]
___
Bioc-
Re: [Bioc-devel] Pushing towards a better home for matrix generics
> Michael Lawrence
> on Mon, 28 Jan 2019 19:00:59 -0800 writes:
> I agree (2) is a good compromise. CC'ing Martin for his
> perspective. Michael
Hmm there's quite a bit more it, really:
I'd not be unwilling to do so myself, but in the long history of
Matrix development -- most of which has happened quite a few
years ago,
I had come to the pretty strong conclusion that you should *NOT*
do setGeneric() for functions in base R, but rather use
*implicit* generics in the methods package, and then in Matrix
only do setMethod() on those..
E.g., this commit to R's sources of the methods package:
r49869 | maechler | 2009-09-29 10:34:48 +0200 (Tue, 29 Sep 2009) | 1 line
make chol2inv, rcond, (col|row)(Means|Sums) implicit Generics
had made rowSums etc into implicit generic,
to be used in Matrix but in other packages as well,
the whole idea being that this would be "the best way", at least
according to knowledge back then, including advice from John
Chambers, unless my memory is wrong.
Having many "base R" functions be implicit generics via the
methods package has been *the* approach to achieve most
interoperability between different R package and been strongly
recommended by John Chambers, e.g., at the time.
In "vanilla" R, only standard packages loaded, including
'methods' of course, calling implicitGeneric("colSums") gives
> implicitGeneric("colSums")
standardGeneric for "colSums" defined from package "base"
function (x, na.rm = FALSE, dims = 1, ...)
standardGeneric("colSums")
Methods may be defined for arguments: x, na.rm, dims
Use showMethods("colSums") for currently available ones.
>
And it seems you would want to limit dispatch to 'x' and hence
have the following line in the above be changed from
Methods may be defined for arguments: x, na.rm, dims
to
Methods may be defined for arguments: x
We should probably move this to R-devel -- as it indeed it
concerns code more in R than in Matrix, I think.
Martin
> On Mon, Jan 28, 2019 at 6:58 PM Pages, Herve
> wrote:
>>
>> Hi Aaron,
>>
>> The 4 matrix summarization generics currently defined in
>> BiocGenerics are defined as followed:
>>
>> setGeneric("rowSums", signature="x")
>> setGeneric("colSums", signature="x")
>> setGeneric("rowMeans", signature="x")
>> setGeneric("colMeans", signature="x")
>>
>> The only reason for having these definitions in
>> BiocGenerics is to restrict dispatch the first
>> argument. This is cleaner than what we would get with the
>> implicit generics where dispatch is on all arguments (it
>> doesn't really make sense to dispatch on toggles like
>> 'na.rm' or 'dims'). Sticking to simple dispatch when
>> possible makes life easier for the developer (especially
>> in times of troubleshooting) and for the user (methods
>> are easier to discover and their man pages easier to
>> access).
>>
>> However, the 4 statements above create new generics that
>> mask the implicit generics defined in the Matrix package
>> (Matrix doesn't contain any setGeneric statements for
>> these generics, only setMethod statements). This is a
>> very unsatisfying situation and it has hit me repeatedly
>> over the last couple of years.
>>
>> We have basically 3 ways to go. From simpler to more
>> complicated:
>>
>> 1) Give up on single dispatch for these generics. That
>> is, we remove the 4 statements above from
>> BiocGenerics. Then we use setMethod() in package code
>> like Matrix does.
>>
>> 2) Convince the Matrix folks to put the 4 statements
>> above in Matrix. Then any BioC package that needs to
>> define methods for these generics would just need to
>> import them from the Matrix package. Maybe we could even
>> push this one step further by having BiocGenerics import
>> and re-export these generics. This would make them
>> "available" in BioC as soon as the BiocGenerics is loaded
>> (and any package that needs to define methods on them
>> would just need to import them from BiocGenerics).
>>
>> 3) Put the 4 statements above in a MatrixGenerics
>> package. Then convince the Matrix folks to define methods
>> on the generics defined in MatrixGenerics. Very unlikely
>> to happen!
>>
>> IMO 2) is the best compromise. Want to give it a shot?
>>
>> H.
>>
>>
>> On 1/27/19 13:45, Aaron Lun wrote: > This is a
>> resurrection of some old threads:
>> >
>> >
>>
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_pipermail_bioc-2Ddevel_2017-2DNovember_012273.html&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=O21AQgvbUp3XRwM4jf0WeZA2ePj9yT3fc2
Re: [Bioc-devel] Pushing towards a better home for matrix generics
> Michael Lawrence
> on Mon, 28 Jan 2019 20:47:58 -0800 writes:
> That will have some consequences; for example,
> documentation aliases will need to change. Not sure how
> many packages will need to be fixed outside of Matrix, but
> it's not an isolated change. Martin might comment on the
> rationale for the full signature, since he defined those
> generics.
> On Mon, Jan 28, 2019 at 7:21 PM Pages, Herve
> wrote:
>>
>> Actually there is a 4th solution which is to modify the
>> definition of the implicit generics in the methods
>> package (file makeBasicFunsList.R) to make them dispatch
>> on their 1st arg only. Should be easy. Then no package
>> will need to use a setGeneric statement
>> anymore. Everybody will automatically get a clean
>> implicit generic. Including the Matrix package which
>> shouldn't need to be touched (except maybe for some
>> aliases in its man page that might need to be changed
>> from \alias{colSums,dgCMatrix,ANY,ANY-method} to
>> \alias{colSums,dgCMatrix-method}).
>>
>> Anybody wants to try to make a patch for this?
>> H.
I've already replied without having read the above two messages.
In my reply I had indeed more or less argued as Hervé does above.
Michael, Hervé, .. : Why is it really so much better to disallow
dispatch for the other compulsory arguments?
Dispatch there allows to use methods for class "missing" which
is nicer in my eyes than the traditional default argument + missing() "tricks".
Is it mainly speed you are concerned about. If yes, do we have
data (and data analysis) about performance here?
Martin
>>
>> On 1/28/19 19:00, Michael Lawrence wrote: > I agree (2)
>> is a good compromise. CC'ing Martin for his perspective.
>> >
>> > Michael
>> >
>> > On Mon, Jan 28, 2019 at 6:58 PM Pages, Herve
>> wrote: >> Hi Aaron,
>> >>
>> >> The 4 matrix summarization generics currently defined
>> in BiocGenerics >> are defined as followed:
>> >>
>> >> setGeneric("rowSums", signature="x") >>
>> setGeneric("colSums", signature="x") >>
>> setGeneric("rowMeans", signature="x") >>
>> setGeneric("colMeans", signature="x")
>> >>
>> >> The only reason for having these definitions in
>> BiocGenerics is to >> restrict dispatch the first
>> argument. This is cleaner than what we would >> get with
>> the implicit generics where dispatch is on all arguments
>> (it >> doesn't really make sense to dispatch on toggles
>> like 'na.rm' or >> 'dims'). Sticking to simple dispatch
>> when possible makes life easier for >> the developer
>> (especially in times of troubleshooting) and for the user
>> >> (methods are easier to discover and their man pages
>> easier to access).
>> >>
>> >> However, the 4 statements above create new generics
>> that mask the >> implicit generics defined in the Matrix
>> package (Matrix doesn't contain >> any setGeneric
>> statements for these generics, only setMethod >>
>> statements). This is a very unsatisfying situation and it
>> has hit me >> repeatedly over the last couple of years.
>> >>
>> >> We have basically 3 ways to go. From simpler to more
>> complicated:
>> >>
>> >> 1) Give up on single dispatch for these generics. That
>> is, we remove the >> 4 statements above from
>> BiocGenerics. Then we use setMethod() in package >> code
>> like Matrix does.
>> >>
>> >> 2) Convince the Matrix folks to put the 4 statements
>> above in Matrix. >> Then any BioC package that needs to
>> define methods for these generics >> would just need to
>> import them from the Matrix package. Maybe we could >>
>> even push this one step further by having BiocGenerics
>> import and >> re-export these generics. This would make
>> them "available" in BioC as >> soon as the BiocGenerics
>> is loaded (and any package that needs to define >>
>> methods on them would just need to import them from
>> BiocGenerics).
>> >>
>> >> 3) Put the 4 statements above in a MatrixGenerics
>> package. Then convince >> the Matrix folks to define
>> methods on the generics defined in >>
>> MatrixGenerics. Very unlikely to happen!
>> >>
>> >> IMO 2) is the best compromise. Want to give it a shot?
>> >>
>> >> H.
>> >>
>> >>
>> >> On 1/27/19 13:45, Aaron Lun wrote: >>> This is a
>> resurrection of some old threads:
>> >>>
>> >>>
>>
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_pipermail_bioc-2Ddevel_2017-2DNovember_012273.html&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=O21AQgvbUp3XRwM4jf0WeZA2ePj9yT3fc2X5hOsKNJk&s=pcpUyjpkQe6U79lZ_n2SANNp6Zj_s6i1Sq2yZx2NSjw&e=
>> >>>
>> >>>
>>
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Bioconductor_
Re: [Bioc-devel] Pushing towards a better home for matrix generics
>>>>> Pages, Herve
>>>>> on Tue, 29 Jan 2019 16:44:47 + writes:
> Hi Martin. Speed is not the concern: I just did some
> quick benchmarking and didn't observe any significant
> difference in method dispatch performance after doing
> setGeneric("toto", function(x, a=0, b=0, c=0)
> standardGeneric("toto")) vs doing setGeneric("toto",
> signature="x", function(x, a=0, b=0, c=0)
> standardGeneric("toto")).
> Here is the real concern to me:
> Aliases of the form
> \alias{colSums,dgCMatrix,ANY,ANY-method} are a real pain
> to maintain. It's also a pain for the end user to have to
> do ?`colSums,dgCMatrix,ANY,ANY-method` to access the man
> page for a particular method. I know Matrix uses "short"
> aliases i.e. aliases of the form
> \alias{colSums,dgCMatrix-method} so the user only needs to
> do ?`colSums,dgCMatrix-method` but there is a lot of
> fragility to the situation.
> Here is why: The exact form that needs to be used for
> these aliases can change anytime depending on what happens
> in one of the upstream packages (not a concern for the
> Matrix package because no upstream package defines colSums
> methods). More precisely: If all the colSums methods
> defined in the upstream packages and in my own package are
> defined with setMethod statements of the form:
> setMethod("colSums", signature(x="SomeClass"), ...)
> then the aliases in the man pages must be of the form
> \alias{colSums,SomeClass-method} and the end user can just
> do ?`colSums,SomeClass-method`, which is good. But if
> **one** upstream package decides to use a setMethod
> statement of the form:
> setMethod("colSums", signature(x="SomeClass",
> na.rm="ANY", dims="ANY"), ...)
> then the aliases for **all** the colSums methods in
> **all** the downstream packages now must be of the form
> \alias{colSums,SomeOtherClass,ANY,ANY-method}, even if the
> method for SomeOtherClass is defined with
> signature(x="SomeOtherClass").
Hmm... but to me, the behavior you describe in the above paragraph
seems rather an implementation "infelicity" in R's help / documentation system,
than an intrinsic necessity. Or have you thought more about
this and discussed it with other S4 experts (John Chambers,
Michael L., Martin Morgan, ...) and came to a different conclusion?
Very generally:
Just because the documentation (help system)
rules are implemented as they are should *NOT* influence "the
best way" to program things in R.
and particularly for something such as S4 which has been adapted
and tuned for a long time ...
So, rather the documentation "setup" should adapt to what seems
best from an R coding point of view.
More specifically, if we are allowed to use short signatures in R code, i.e.,
signature(x=)
short for
signature(x=, na.m="ANY", dims="ANY")
then the documentation \alias{} should allow to use the same
principle, as the documentation / help "keys" which \alias{.} constructs
will be similarly uniquely determined
(at least as long as other packages do not describe methods for
"my" )
So, the help / documentation (and "R CMD check" checks) should
have been changed long ago, if you had sent patches to do so,
n'est-ce pas? :-) ;-) [[yes, half jokingly]].
Martin
> Also, as a consequence, now
> the end user has to use the long syntax to access the man
> pages for these methods. And if later the author of the
> upstream package decides to switch back to the
> setMethod("colSums", signature(x="SomeClass"), ...) form,
> then I have to switch back all the aliases in all my
> downstream packages to the short form again!
> This fragility of the alias syntax was one of the
> motivations for me to put many setGeneric statements of
> the form setGeneric("someGeneric", signature="x") in
> BiocGenerics over the years. So I don't have many dozens
> of aliases that suddenly break for mysterious reasons ('R
> CMD check' would suddenly starts reporting warnings for
> these aliases despite no changes in my package or in R).
> Best,
> H.
> On 1/29/19 03:16, Martin Maechler wrote:
>>>>>>> Michael Lawrence on Mon, 28 Jan 2019 20:47:58 -0800
>>>>>>> writes:
>> > That will have some consequences; for example, >
>> documentation aliases will need to change. Not
Re: [Bioc-devel] use -Wa, -mbig-obj -O3 when building package under Windows
>>>>> Kasper Daniel Hansen >>>>> on Fri, 24 May 2019 10:31:31 -0400 writes: > [ This is a crazy bug where you have to increase optimization. ] > I some to add here. I am involved in at least two packages which requires > overriding the optimization switch to downgrade optimization. You have an > additional problem where you need to add additional flags. > The solution in affxparser (see the source) is a custom compiler call where > we place -O0 before the system/package compiler flags. This is not a great > solution as it assumes that the compiler knows about -O notation (which is > true for GCC but not a true assumption everywhere). > In Rgraphviz I have the same problem (but not solved yet because of ... > time). The issue here is that recent GCCs (v8 and higher) cannot be used > with -O3 but needs -O2. I have started to think about a better solution > than affxparser, to be used by the community, but have been a bit stumped. > Preferably I would like to use autoconf macro for detecting GCC, but when > we compile a package we are using the compiler encoded in R (aka $CC). So > somehow I want to run autoconf "detect which compiler is used" but for a > specific compiler. This is probably possible, but I don't know how right > now. > Then, conditional on GCC I plan to do a regex which replaces -O3 with -O2. > This is not perfect either because the different -O3 optimizations can be > supplied as individual flags, and I don't know which flag it is which > breaks GCC. But it is must closer to the right solution. I don't know if > regex/sed'ing is better than overriding by changing the order as in > affxparser, but having the ability to do a conditional in Makevars would be > good. Of course, the autoconf route does not address Windows, but I think > we can assume / count on the fact that the RTools pipeline is used (aka, it > is always GCC). > I would be happy to communicate more on this, to get this sorted out. It > has been a todo list item for me, for a while, and I should really try to > resolve it. > But for a quick fix, look at affxparser. > Best, > Kasper Dear Kasper, maybe you could ask about this "over at" the R-devel (or R-package-devel ?) mailing list? These problems are relevant to many R package authors not just bioconductor ones, and so it may worth to expose this to even more experts than here ... (I'm interested myself, as you may remember, because of our need for a working 'Rgraphviz' ...) Best, Martin -- Martin Maechler ETH Zurich and R Core Team ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Reference manual as HTML
>>>>> Martin Morgan
>>>>> on Wed, 25 Sep 2019 21:10:24 + writes:
> Our recollection is that there is no 'flag' in R CMD build to create HTML
rather than PDF vignettes; without that it would be non-trivial to create html
output, e.g., links across pages. (I *think* the installed package html help
pages are generated on the fly...)
Yes, by default.
But you may (or not) remember that for R itself, I (and my
university, ETH Zurich) have provided static HTML help pages and
manuals since "forever" -> https://stat.ethz.ch/R-manual/
and my cron job that creates (and daily updates) them "starts
with"
../R/configure --with-prebuilt-html
As it does provide static html help pages for all "base R" +
Recommended packages,
see, e.g., https://stat.ethz.ch/R-manual/R-devel/doc/html/packages.html
it should not be hard to have it do the same for all other
packages in principle.
"The other R Core" Martin
Martin Maechler
ETH Zurich
> What is your experience with pkgdown?
> Martin
> On 9/25/19, 9:44 AM, "Bioc-devel on behalf of Laurent Gatto"
wrote:
> I think this would be very useful. This is one of the reasons I create
pkgdown sites for my packages: manual pages, news and html vignettes are
readily available for all (including me) to browse.
> Best wishes,
> Laurent
>
> From: Bioc-devel on behalf of Ludwig
Geistlinger
> Sent: 25 September 2019 13:31
> To: bioc-devel@r-project.org
> Subject: [Bioc-devel] Reference manual as HTML
> Dear Bioc-Team,
> I repeatedly wondered whether it would be possible to display the
reference manual
> as HTML instead of PDF on a package's landing page. This is already
possible for vignettes.
> HTML reference manuals have at least two advantages:
> 1. links to functions of other package in the man pages of my package
would
> actually work. Links to functions / classes of other packages of the form
> \code{\link{p.adjust}}
> or
> \code{\linkS4class{SummarizedExperiment}}
> within the pdf reference manual currently point nowhere (bring me back to
the
> first page of the pdf). Within the html reference manual
> help(package="myPackage", help_type="html")
> these links work as expected, ie bring me to the help pages of functions
/ classes
> of other packages.
> 2. I could easily refer users to the documentation link of a specific
function
> (without them having to search through the pdf) such as "check the
documentation of
> the DESeq function here: https://rdrr.io/bioc/DESeq2/man/DESeq.html";.
> (where the link would be preferably:
bioconductor.org/packages/DESeq2/man/DESeq.html).
> Thank you,
> Ludwig
> [[alternative HTML version deleted]]
> ___
> 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
> ___
> 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] Compatibility of S4 and tidyverse
> Michael Lawrence via Bioc-devel
> on Wed, 5 Feb 2020 20:52:52 -0800 writes:
> Yep that about sums it up.
:-) ;-)
Thank you, Michael !!
I haven't laughed as much from reading e-mails in a long while !!
Martin
> On Wed, Feb 5, 2020 at 8:37 PM Stefano Mangiola
> wrote:
{an empty message}
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
> --
> Michael Lawrence
> Senior Scientist, Bioinformatics and Computational Biology
> Genentech, A Member of the Roche Group
> Office +1 (650) 225-7760
> micha...@gene.com
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Subscription to the list problem
>>>>> ELENI ADAM >>>>> on Tue, 9 Jun 2020 17:24:49 -0400 writes: > Hello, I have tried multiple times to subscribe to the > bioc-devel list by filling out the web form > (https://stat.ethz.ch/mailman/listinfo/bioc-devel) but I > have never received a confirmation email (I have checked > the Spam folder as well). After checking again, I am still > not in the list. > I am not sure what the problem is. Could you please help > me? Is there another way of subscribing to the list? Did you also fill the 'Captcha' ? This had been an important addition for security; as we had spammers (auto-) subscribing to some of the R mailing lists, and then spamming whoever *posted* to the list (and reusing their subject and other tricks as to pass any spam filters). Last but not least: You *are* subscribed to the list now. Best regards, Martin > Thank you, Eleni > [[alternative HTML version deleted]] Martin Maechler ETH Zurich and R Core Team ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] S4 Methods Documentation Convention Triggers Warnings
> Michael Lawrence \(MICHAFLA\) via Bioc-devel
> on Mon, 28 Nov 2022 12:11:00 -0800 writes:
> It may be worth revisiting why we arrived at this convention in the first
> place and see whether the Rd system can be enhanced somehow so that we can
> achieve the same effect with a more natural syntax.
> Michael
Yes, I agree.
It may be that in the distant past, Henrik's suggestion
(a version of which I am using myself a lot in *.Rd -- mostly
*not* related to S4)
did not work correctly, but I know it has worked for years now,
as I use it "all the time".
and not just I.
If I grep in R's *base* package alone,
inside ./R/src/library/base/man/
grep --color -nH --null -e '\\item{\\code{' *.Rd
starts with
agrep.Rd 42: \item{\code{cost}:}{maximum number/fraction of match cost
agrep.Rd 44: \item{\code{all}:}{maximal number/fraction of \emph{all}
agrep.Rd 46: \item{\code{insertions}:}{maximum number/fraction of
insertions}
gives *many* matches for the base/man/options.Rd page
and (in Emacs where I use the very powerful M-x grep ) end saying
Grep finished with 265 matches found at Wed Nov 30 12:25:01
Martin
> On Mon, Nov 28, 2022 at 11:25 AM Deepayan Sarkar
> wrote:
>> On Sun, Nov 27, 2022 at 12:30 PM Dario Strbenac via Bioc-devel <
>> bioc-devel@r-project.org> wrote:
>>
>> > Good day,
>> >
>> > For a long time, it has been a convention to document S4 methods in the
>> > format:
>> >
>> > \section{Displaying}{
>> > In the code snippets below, \code{x} is a GRanges object.
>> > \describe{
>> > \item{}{
>> > \code{show(x)}:
>> > Displays the first five and last five elements.
>> > }
>> > }
>> > }
>> >
>> > In R Under Development, this is now a warning:
>> >
>> > * checking Rd files ... WARNING
>> > checkRd: (5) GRanges-class.Rd:115-165: \item in \describe must have
>> > non-empty label.
>> >
>>
>> > This affects my own package as well as the core Bioconductor packages
>> > which I used as inspiration for designing my pacakge documentation
seven
>> > years ago. What should the new convention be? Or could R developers be
>> > convinced to get rid of this check before this prototype is released?
>> >
>>
>> The warning is primarily meant for \items inside \arguments, as in HTML
>> output these now have an id that can be used to link to specific
arguments.
>> The code is shared with \describe, which is why the warning is showing up
>> here.
>>
>> So I guess it might be possible to fine-tune the warning to accept this
>> kind of usage inside \describe. But I think this is a horrible
>> "convention", and unless this is really widespread that wouldn't be my
>> first choice.
>>
>> An alternative to Henrik's suggestion is to just use \itemize instead of
>> \describe and drop the first {} after \item.
>>
>> Best,
>> -Deepayan
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] BiocManager::install
>>>>> Wolfgang Huber
>>>>> on Sun, 7 May 2023 14:29:37 +0200 writes:
> Hi Martin As you correctly point out, Bioconductor package
> developers are probably not those with the most relevant
> use cases. I think there are use cases for everyone
> else—anyone who decides to write code on R-devel, for
> whatever reason, and just wants to use a Bioconductor
> package between mid-April to mid-October (they could
> develop for CRAN, or just be a user and write scripts and
> packages for a private project). There are many useful
> packages on Bioconductor that are of general interest,
> even for people whose work does not center around
> Bioconductor or biology (say, ggtree, rhdf5,
> sparseMatrixStats, EBImage, …)
> I added these ponderings also to
> https://github.com/Bioconductor/pkgrevdocs/issues/108
> Thanks and best wishes Wolfgang
As the older ones among you know, I've been a BioC developer
only many years ago ('hexbin' e.g.), but as an R package
maintainer and co-maintainer and R Core team member,
I really like to chime in here, declaring that it *has* been
quite painful for me over the years to test CRAN packages which
depend on BioC packages - with R-devel -- which is my primary R
version for testing, notably also for testing potential changes in R
across many packages, etc.
Notably during this half of the year where there is no
"official" way how to correctly install current Bioconductor packages
(in their own package library, as I always do) under R-devel.
If I'd be able to sum up the time lost over this issue for the last say 10
years, it would add to a full working day at least. ...
(and I have added a comment also in the above issue #108)
> (PS in my particular case yesterday, it was just that my
> R-devel is better maintained (built from source etc) and
> has in its library some (non-BioC) packages with complex
> systems dependencies that I need for a workflow I am
> working on, packages that currently elude me on my binary
> installation of R4.3. And then in addition I just wanted
> to *use* a package from Bioconductor and didn’t like how
> clumsy that experience was.)
My other experience is that I always have to help people in my
group to install our pcalg CRAN package because it depends
e.g. on Bioc packages 'graph' and 'Rgraphviz' .. and on their
laptops they somehow don't have the correct getOption("repos")
or there are other reasons why install.packages('pcalg')
does not find its Bioc dependencies.
On our Linux desktop+server environment, I do setup
options(repos = )
such that everything works .. but alas, also *not* when in
R-devel but when you develop a package for CRAN / or only just
follow the more wide recommendation to also check your package
with current R-devel, then non-expert package developers need a
lot of stamina if their package depends (directly or
recursively) on a Bioc package
which is really unfortunate and tends to put the Bioconductor
project in a shady light it really has not deserved at all!
Martin
--
Martin Maechler
ETH Zurich and R Core team
>> Il giorno 06.05.2023, alle ore 16:45, Martin Morgan
>> ha scritto:
>>
>> I opened two issues for further discussion of the
>> technical aspects.
>> https://github.com/Bioconductor/BiocManager/issues/165
>> https://github.com/Bioconductor/pkgrevdocs/issues/108
>> Just to be clear, as noted at the end of the second issue
>> and on the web page you mention, a Bioconductor package
>> developer wishing to use 'Bioc-devel' should, during the
>> mid-April to mid-October release cycle, be using the
>> **release** version of R. This combination of R and
>> Bioconductor is supported by BiocManager. Similarly, in
>> the mid-October to mid-April release cycle, the
>> Bioconductor developer should be R-devel, and BoicManager
>> supports this, too. There are scenarios where a
>> developer might wish to combine R-devel and Bioc-devel in
>> the mid-May, to mid-October time frame, e.g., when
>> developing a CRAN package with Bioconductor dependencies,
>> or when conscientiously testing CRAN packages that depend
>> on Bioconductor packages. One may also just want to be on
>> the bleeding edge, so using R-devel and living with any
>> consequence that arise from R / Bioconductor version
>> mismatches. Are these less-common scenarios the one that
>> you are engaged in? Martin From: Bioc-devel
>> on behalf of Wolfgang
>> Huber Date: Saturday, May 6,
>> 2023 at
Re: [Bioc-devel] issue with .local() hack used in S4 methods
> Hervé Pagès
> on Fri, 19 May 2023 11:43:50 -0700 writes:
> Hi,
> Just ran across this:
> foo <- function(x, ..., z=22) z
> setMethod("foo", "character", function(x, y=-5, z=22) y)
> # Creating a generic function from function ‘foo’ in the global
> environment
> Then:
> foo("a")
> # [1] 22
> Should return -5, not 22.
> That's because the call to .local() used internally by the foo() method
> does not name the arguments placed after the ellipsis:
>> selectMethod("foo", "character")
> Method Definition:
> function (x, ..., z = 22)
> {
> .local <- function (x, y = 5, z = 22)
> y
> .local(x, ..., z) <--- should be .local(x, ..., z=z)
> }
> Thanks,
> H.
>> sessionInfo()
> R version 4.3.0 (2023-04-21)
[...]
I can confirm this *bug* (also in R 4.2.z, R 4.1.z, R 3.6.3).
One might be tempted to say this falls into the
"Doctor, it hurts when I do this --- then, don't do that!"
category.
Maybe a simple way to fix the would be to forbid the '...'
in S4 generics and methods apart from at the end,
or then make sure that after the ... in the .local() call, all
argument must be named {{as you suggest above}}.
Could you file a bug at R's bugzilla?
{I know we have too many open bugs there, notably related to S4,
but still you'd do a service to the R community.}
Best,
Martin
> --
> Hervé Pagès
> Bioconductor Core Team
> hpages.on.git...@gmail.com
> ___
> 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] [Rd] is.atomic(NULL) will become FALSE
I've sent a longish post to the R-devel mailing list with this topic here: https://stat.ethz.ch/pipermail/r-devel/2023-September/082892.html In the mean time, the plan is to effectuate the change in R-devel (the in-development version of R) on Sep.28, ~ 9:30 CEST ( =UTC+2) AFAIK, this will only affect bioconductor packages *after* the upcoming release of BioC ... when they will all begin to run / be tested "against R-devel". But if you use CI / R-bug / rocker / ... tests for your packages using the development version of R, this may affect some of your bioconductor packages already sooner. Best regards, Martin -- Martin Maechler ETH Zurich and R Core team ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] "R CMD check" and par(mfrow=…) in vignettes
>>>>> Martin Morgan
>>>>> on Wed, 7 Aug 2013 05:14:35 -0700 writes:
> On 08/06/2013 05:25 AM, Wolfgang Huber wrote:
>> Hi
>>
>> one of my packages [1] has several places in its vignette where
multi-panel figures are generated via the likes of "par(mfrow=c(4,2))" within
<> code chunks. The package builds fine with 'R CMD build', and the
vignette builds fine when calling Sweave manually. However, 'R CMD check' fails
with
>> * checking running R code from vignettes ...
>> ‘Hiiragi2013.Rnw’ ... failed
>> ERROR
>> Errors in running code in vignettes:
>> [..snip..]
>> When sourcing ‘Hiiragi2013.R’:
>> Error: figure margins too large
>>
>> I believe this is because R CMD check calls Stangle on the .Rnw and then
sources the .R file disregarding any device size settings. I can think of
several ways to work around this, but this seems like a rather basic deficiency
of the current system that asks for a more generic answer. Does anybody have
any insight here?
>>
> I guess these qualify as work-arounds
> 1. From ?RweaveLatex, \setkeys{Gin}{width=\textwidth} though this doesn't
> actually help much
> 2. par(mfrow=c(7,5), mar=par("mar")/2)
> 3. output to pdf and then include separately
> <>=
> pdf("foo.pdf", ...)
> ...
> dev.off()
> @
> \includgegraphics{foo}
Ok though
I'd find '3.' extremely ugly; '1.' is what I'd use anyway, but
as you say, it may not be sufficient.
I'm indirectly using a better version of '2.', namely
I extensively use
sfsmisc::mult.fig()
instead of any par(mfrow= .) or par(mfcol= .)
but than I'm the author of that utility function...
What I really recommend is taking this to R-devel,
in spite of *some* people there, and their vitriolic way of
e-talking..
Martin Maechler
> Not sure what you had in mind for a generic solution?
> Martin
>> Best wishes
>> Wolfgang
>>
>> PS I am sorry if this has been discussed elsewhere, but digging in the
R-exts manual and in Google did not turn up a solution for me.
>>
>> [1] https://hedgehog.fhcrc.org/bioc-data/trunk/experiment/pkg/Hiiragi2013
>> ___
>> 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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Struggles with correct import .....
> Kasper Daniel Hansen
> on Wed, 20 Nov 2013 15:37:00 -0500 writes:
> Ok, I analyzed the package using codetoolsBioC and there
> were a number of missing imports, including what Leonardo
> has described. I have fixed those in bumphunter 1.3.3
> Kasper
Impressing and interesting. I don't see 'codetoolsBioC' to be
available via biocLite().
What's the recommended way to have it among the bioconductor
packages ?
Martin
> On Wed, Nov 20, 2013 at 3:28 PM, Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com> wrote:
>> I'll have a look.
>>
>> Basically, issues such as this is never the end-users
>> problem and is likely to either be caused by bumphunter
>> not importing correctly (most likely) or IRanges not
>> exporting correctly.
>>
>> Kasper
>>
>>
>> On Wed, Nov 20, 2013 at 3:02 PM, Leonardo Collado Torres
>> < lcoll...@jhsph.edu> wrote:
>>
>>> Hello,
>>>
>>> Found how to solve this. Basically, the NAMESPACE of the
>>> bumphunter package is not complete (I think).
>>>
>>> I downloaded
>>>
>>>
http://bioconductor.org/packages/release/bioc/src/contrib/bumphunter_1.2.0.tar.gz
>>> , changed the version to 1.2.1 and added/modified the
>>> following lines to the NAMESPACE:
>>>
>>> importFrom(IRanges, IRanges, distance,
>>> distanceToNearest, subjectHits)
>>> importMethodsFrom(GenomicRanges, seqnames, sort, strand,
>>> elementMetadata)
>>>
>>> Once bumphunter was importing IRanges::distance, I got
>>> past the error I reported. Then I found other errors
>>> related to bumphunter not importing the GenomicRanges
>>> strand and elementMetadata functions, as well as the
>>> IRanges distanceToNearest, IRanges and subjectHits
>>> functions.
>>>
>>> Best, Leo
>>>
>>>
>>>
>>>
>>> On Wed, Nov 20, 2013 at 2:46 PM, Leonardo Collado Torres
>>> < lcoll...@jhsph.edu > wrote:
>>>
>>> > Hi Harris,
>>> >
>>> > Answering your question from your first email, I do
>>> not think that it > would help if bumphunter exported
>>> matchGenes() or .matchGenes().
>>> >
>>> > Currently by just importing annotateNearest(), R is
>>> correctly able to use > annotateNearest(), then
>>> .matchGenes(), and also nearestgene(). The problem > is
>>> that nearestgene() uses IRanges::distance() but that
>>> function is not > being found even after importing it.
>>> >
>>> > So as far as I understand, everything should be
>>> working since the > NAMESPACE<
>>> https://github.com/lcolladotor/derfinder/blob/v0.0.34/NAMESPACE>has:
>>> >
>>> > importFrom(bumphunter,annotateNearest) >
>>> importMethodsFrom(IRanges,distance) >
>>> importFrom(IRanges,distance)
>>> >
>>> > That is why I am confused and do not know what is the
>>> cause of the problem.
>>> >
>>> >
>>> > One possible explanation could be that bumphunter's
>>> NAMESPACE
>>> >
>>>
https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/bumphunter/NAMESPACEdoesn't
>>> > import the IRanges::distance method.
>>> >
>>> >
>>> >
>>> > Regarding your second email (quoted below), I do not
>>> import the > IRanges::nearest method, but it doesn't
>>> seem to be causing problems. That > could be because
>>> bumphunter does import the IRanges::nearest method
>>> >
>>> > If I comment out line 147 of >
>>> https://github.com/lcolladotor/derfinder/blob/v0.0.34/R/analyzeChr.R,
>>> > aka, comment out library("bumphunter") the example for
>>> analyzeChr() fails > with:
>>> >
>>> > Error in withCallingHandlers(expr, warning =
>>> function(w) > invokeRestart("muffleWarning")) : > could
>>> not find function "distance"
>>> >
>>> > So yes, I get the same error in real life and not only
>>> in CMD check.
>>> >
>>> >
>>> > Adding to the NAMESPACE the following line doesn't
>>> help either.
>>> >
>>> > importMethodsFrom(IRanges,nearest)
>>> >
>>> >
>>> >
>>> >
>>> > Best, > Leo
>>> >
>>> >
>>> >
>>> > On Wed, Nov 20, 2013 at 2:06 PM, Harris A. Jaffee
>>> wrote:
>>> >
>>> >> In nearestgene(), before the call to distance, there
>>> is a call to nearest. >> How is that getting resolved?
>>> Did you import nearest from IRanges? Can >> you run
>>> nearestgene under debug and step through it, seeing how
>>> nearest is >> resolved? Do you only get an error from
>>> CMD check and not in real life?
>>> >>
>>> >>
>>> >> On Nov 20, 2013, at 12:16 PM, Leonardo Collado Torres
>>> wrote:
>>> >>
>>> >> > Dear BioC-devel list,
>>> >> >
>>> >> > I have what I hope is a simple problem. Basically,
>>> a function in my >> package uses
>>> bumphunter::annotateNearest. This function i
Re: [Bioc-devel] Struggles with correct import .....
>>>>> Kasper Daniel Hansen >>>>> on Tue, 3 Dec 2013 18:57:51 -0500 writes: > It is super super super useful for NAMESPACE issues. I > don't really use the other stuff. > Kasper Thank you, both, Dan and Kasper. As the package is not so large, and it really is not related in any way to Bioconductor apart from its authorship, I wonder if "one" should not rather consider donating most of the functions to the 'codetools' package (whose maintainer is Luke Tierney). The 'Author' entry in all the (new) help pages could still remain there... BTW: If you "fix" it: Consider rewriting many usages of ulapply() with the more efficient and "robust" vapply(). And just in case my 'suggestion's above don't sound enough grateful: Thank you very much, once more! Martin > On Tue, Dec 3, 2013 at 11:34 AM, Dan Tenenbaum > wrote: >> >> >> - Original Message - > From: "Martin Maechler" >> > To: "Kasper Daniel Hansen" >> > Cc: >> bioc-devel@r-project.org > Sent: Tuesday, December 3, >> 2013 8:13:55 AM > Subject: Re: [Bioc-devel] Struggles >> with correct import . >> > >> > >>>>> Kasper Daniel Hansen >> > >>>>> on Wed, 20 Nov >> 2013 15:37:00 -0500 writes: >> > >> > > Ok, I analyzed the package using codetoolsBioC and >> there > > were a number of missing imports, including >> what Leonardo > > has described. I have fixed those in >> bumphunter 1.3.3 >> > >> > > Kasper >> > >> > Impressing and interesting. I don't see >> 'codetoolsBioC' to be > available via biocLite(). >> > >> > What's the recommended way to have it among the >> bioconductor > packages ? >> > >> >> >> Check it out from svn: >> >> https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/codetoolsBioC/ >> >> (username/password: readonly) >> >> The package has some issues and needs some attention; >> this is why it has not been released. It's still useful >> though. >> >> Dan >> >> >> > Martin >> > >> > > On Wed, Nov 20, 2013 at 3:28 PM, Kasper Daniel Hansen >> < > > kasperdanielhan...@gmail.com> wrote: >> > >> > >> I'll have a look. >> > >> >> > >> Basically, issues such as this is never the >> end-users > >> problem and is likely to either be caused >> by bumphunter > >> not importing correctly (most likely) >> or IRanges not > >> exporting correctly. >> > >> >> > >> Kasper >> > >> >> > >> >> > >> On Wed, Nov 20, 2013 at 3:02 PM, Leonardo Collado >> Torres > >> < lcoll...@jhsph.edu> wrote: >> > >> >> > >>> Hello, >> > >>> >> > >>> Found how to solve this. Basically, the NAMESPACE >> of the > >>> bumphunter package is not complete (I >> think). >> > >>> >> > >>> I downloaded >> > >>> >> > >>> >> http://bioconductor.org/packages/release/bioc/src/contrib/bumphunter_1.2.0.tar.gz >> > >>> , changed the version to 1.2.1 and added/modified >> the > >>> following lines to the NAMESPACE: >> > >>> >> > >>> importFrom(IRanges, IRanges, distance, > >>> >> distanceToNearest, subjectHits) > >>> >> importMethodsFrom(GenomicRanges, seqnames, sort, strand, >> > >>> elementMetadata) >> > >>> >> > >>> Once bumphunter was importing IRanges::distance, I >> got > >>> past the error I reported. Then I found other >> errors > >>> related to bumphunter not importing the >> GenomicRanges > >>> strand and elementMetadata functions, >> as well as the > >>> IRanges distanceToNearest, IRanges >> and subjectHits > >>> functions. >> > >>> >> > >>> Best
