Re: [Rd] :: and ::: as .Primitives?
Hi, On 01/23/2015 07:01 AM, luke-tier...@uiowa.edu wrote: On Thu, 22 Jan 2015, Michael Lawrence wrote: On Thu, Jan 22, 2015 at 11:44 AM, luke-tier...@uiowa.edu wrote: For default methods there ought to be a way to create those so the default method is computed at creation or load time and stored in an environment. We had considered that, but we thought the definition of the function would be easier to interpret if it explicitly specified the namespace, instead of using tricks with environments. The same applies for memoizing the lookup in front of a loop. interpret in what sense (human reader or R interpreter)? In either case I'm not convinced. From a developer perspective, especially when debugging, when we do selectMethod(match, ...) and it turns out that this returns the default method, it's good to see: Method Definition (Class derivedDefaultMethod): function (x, table, nomatch = NA_integer_, incomparables = NULL, ...) base::match(x, table, nomatch = nomatch, incomparables = incomparables, ...) environment: namespace:BiocGenerics Signatures: x table target DataFrame ANY defined ANY ANY rather than some obscure/uninformative body. I hope we can keep that. The implementation of these functions is almost simpler in C than it is in R, so there is relatively little risk to this change. But I agree the benefits are also somewhat minor. I don't disagree, but it remains that even calling the C version has costs that should not need to be paid. But maybe we can leave that to the compiler/byte code engine. Optimizing references to symbols resolved statically to name spaces and imports is on the to do list, and with a little care that mechanism should work for foo::bar uses as well. That would be great. Thanks! H. Best, luke For other cases if I want to use foo::bar many times, say in a loop, I would do foo_bar - foo::bar and use foo_bar, or something along those lines. When :: and ::: were introduce they were intended primarily for reflection and debugging, so speed was not an issue. ::: is still really only reliably usable that way, and making it faster may just encourage bad practice. :: is different and there are good arguments for using it in code, but I'm not yet seeing good arguments for use in ways that would be performance-critical, but I'm happy to be convinced otherwise. If there is a need for a faster :: then going to a SPECIALSXP is fine; it would also be good to make the byte code compiler aware of it, and possibly to work on ways to improve the performance further e.g. through cacheing. Best, luke On Thu, 22 Jan 2015, Peter Haverty wrote: Hi all, When S4 methods are defined on base function (say, match), the function becomes a method with the body base::match(x,y). A call to such a function often spends more time doing :: than in the function itself. I always assumed that :: was a very low-level thing, but it turns out to be a plain old function defined in base/R/namespace.R. What would you all think about making :: and ::: .Primitives? I have submitted some examples, timings, and a patch to the R bug tracker (https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16134). I'd be very interested to hear your thoughts on the matter. Regards, Pete Peter M. Haverty, Ph.D. Genentech, Inc. phave...@gene.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Luke Tierney Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: luke-tier...@uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] speedbump in library
Thanks Winston,
Yes, your version of that part is more direct. I guess it would need a
! is.null() too. I think we should use .getNamespace.
It It also occurred to me that this %in% check (which happens in a few
places) is kind of roundabout. It equates to
foo %in% ls(.Internal(getNamespaceRegistry()), all.names = TRUE)
We lack and R-level accessor for the namespace registry, but if we had
one we could do
getNamespaceRegistry()[[foo]]
, which is just a hash lookup.
I'm getting a bit off topic here, but ...
foo %in% vector is a common pattern and reads well, but
any(vector == foo)
is less work and much faster. I wonder if there is room for a fast
path there ...
Pete
Peter M. Haverty, Ph.D.
Genentech, Inc.
phave...@gene.com
On Fri, Jan 23, 2015 at 8:15 AM, Winston Chang winstoncha...@gmail.com wrote:
I think you can simplify a little by replacing this:
pkg %in% loadedNamespaces()
with this:
.getNamespace(pkg)
Whereas getNamespace(pkg) will load the package if it's not already
loaded, calling .getNamespace(pkg) (note the leading dot) won't load
the package.
I can't speak to whether there are any pitfalls in changing the
library path searching, though.
-Winston
On Thu, Jan 22, 2015 at 12:25 PM, Peter Haverty haverty.pe...@gene.com
wrote:
Hi all,
Profiling turned up a bit of a speedbump in the library function. I
submitted a patch to the R bug tracker as bug 16168 and I've also
included it below. The alternate code is simpler and easier to
read/maintain, I believe. Any thoughts on other ways to write this?
Index: src/library/base/R/library.R
===
--- src/library/base/R/library.R(revision 67578)
+++ src/library/base/R/library.R(working copy)
@@ -688,18 +688,8 @@
out - character()
for(pkg in package) {
-paths - character()
-for(lib in lib.loc) {
-dirs - list.files(lib,
- pattern = paste0(^, pkg, $),
- full.names = TRUE)
-## Note that we cannot use tools::file_test() here, as
-## cyclic namespace dependencies are not supported. Argh.
-paths - c(paths,
- dirs[dir.exists(dirs)
-file.exists(file.path(dirs,
- DESCRIPTION))])
-}
+paths - file.path(lib.loc, pkg)
+paths - paths[ file.exists(file.path(paths, DESCRIPTION)) ]
if(use_loaded pkg %in% loadedNamespaces()) {
dir - if (pkg == base) system.file()
else getNamespaceInfo(pkg, path)
Pete
Peter M. Haverty, Ph.D.
Genentech, Inc.
phave...@gene.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] :: and ::: as .Primitives?
I tend to use this (in my own internal code *only*):
exported - function (pkg) {
if (pkg == base) {
function (fun) {
fun - as.character(substitute(fun))
res - .BaseNamespaceEnv[[fun]]
if (is.null(res))
stop(fun, is not found in package base)
res
}
} else {
ns - getNamespace(pkg)
exports - getNamespaceInfo(ns, exports)
function (obj) {
obj - as.character(substitute(obj))
exportedObj - exports[[obj]]
if (is.null(exportedObj)) {
if (is.null(ns[[obj]])) {
stop(obj, does not exists in package
, pkg)
} else {
stop(obj, is not exported from
package , pkg)
}
}
ns[[exportedObj]]
}
}
}
stats - exported(stats)
stats(acf)
stats([.acf)
stats(inexistant)
exported(base)(ls)
exported(base)(inexistant)
## Performance tests for what it’s worth
microbenchmark::microbenchmark(stats::acf, (stats - exported(stats))(acf),
stats(acf))
microbenchmark::microbenchmark(base::ls, (base - exported(base))(ls),
base(ls), .BaseNamespaceEnv$ls)
So, `::` is slow and I can get better speed results thanks to binding both the
namespace and the exports environments in the `stats` closure. Unless I miss
something, this is not much a problem for base package that is never unloaded.
Yet, .BaseNamespaceEnv$xxx, or baseenv()$xxx does the job faster and simpler.
However, there is a vicious problem with my exported() function, which is, to
say the least, dangerous under the hand of unaware users. Indeed:
stats - exported(“stats”)
creates a new binding to both the namespace and the exports environments of the
stats package. So, if I do:
detach(“package:stats”, unload = TRUE), then library(“stats”), I got two
versions of the package in memory, and my `stats`closure refers to an outdated
version of the package. This is particularly problematic if the package was
recompiled in between (in the context of debugging).
Conclusion: much of the lost of performance in `::` is due to not caching the
environments. This is fully justified to keep the dynamism of the language at
full power and to avoid a messy state of R as described here above… Regarding
dynamism, even `stats::acf`remains discutable.
Moreover, it is possible to do many other crazy things with these environments,
once one got a grip on them. So, even getNamespace() and getNamespaceInfo() are
dangerous. Perhaps this should be emphasised in the ?getNamespace man page?
This is also why the code above is not released in the wild… Well, now it is :-(
Best,
Philippe
..°}))
) ) ) ) )
( ( ( ( (Prof. Philippe Grosjean
) ) ) ) )
( ( ( ( (Numerical Ecology of Aquatic Systems
) ) ) ) ) Mons University, Belgium
( ( ( ( (
..
On 23 Jan 2015, at 16:01, luke-tier...@uiowa.edu wrote:
On Thu, 22 Jan 2015, Michael Lawrence wrote:
On Thu, Jan 22, 2015 at 11:44 AM, luke-tier...@uiowa.edu wrote:
For default methods there ought to be a way to create those so the
default method is computed at creation or load time and stored in an
environment.
We had considered that, but we thought the definition of the function
would be easier to interpret if it explicitly specified the namespace,
instead of using tricks with environments. The same applies for
memoizing the lookup in front of a loop.
interpret in what sense (human reader or R interpreter)? In either
case I'm not convinced.
The implementation of these functions is almost simpler in C than it
is in R, so there is relatively little risk to this change. But I
agree the benefits are also somewhat minor.
I don't disagree, but it remains that even calling the C version has
costs that should not need to be paid. But maybe we can leave that to
the compiler/byte code engine. Optimizing references to symbols
resolved statically to name spaces and imports is on the to do list,
and with a little care that mechanism should work for foo::bar uses as
well.
Best,
luke
For other cases if I want to use foo::bar many times, say
in a loop, I would do
foo_bar - foo::bar
and use foo_bar, or something along those lines.
When :: and ::: were introduce they were intended primarily for
reflection and debugging, so speed was not an issue. ::: is still
really only reliably usable that way, and making it faster may just
encourage bad practice. :: is different and there are good arguments
for using it in code, but I'm not yet seeing good arguments
Re: [Rd] Programming Tools CTV
On 23 January 2015 at 05:55, Hadley Wickham wrote: | I'd strongly second the notion of using github. The biggest advantage | is that others can easily contribute changes through pull requests | which lifts much of the burden from your shoulders. That's The Theory. The Practice for eight weeks having the High-Performance Computing and Finance Task Views there (in source and a rendered markdown, see [1]) is a single pull request fixing a one-char typo. So the jury may still be out on that one. Dirk [1] As already shown in the email thread: https://github.com/eddelbuettel/ctv-hpc https://github.com/eddelbuettel/ctv-finance -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] Package submission with library requirement
On 01/21/2015 11:16 AM, avinash sahu wrote: Both the libraries are not thread safe. Although boost random genrator in limited situation can be thread safe. I have tried them earlier they were failing with multi-threading. One way out might be, if I include the source code of ransampl with package source code. There license allows this, I can also mail ask the developer of Ransampl about the permission. Will this be acceptable to bioconductor folks? yes, provided the license of the library allows for it, it is a good solution. There is guidance in RShowDoc(R-exts) on acknowledging this in the DESCRIPTION (and possibly LICENSE) file. Martin thanks avi On Wed, Jan 21, 2015 at 7:57 PM, Steve Lianoglou lianoglou.st...@gene.com mailto:lianoglou.st...@gene.com wrote: Does the boost RNGs qualify? He's a vignette showing how to use them through R/Rcpp http://gallery.rcpp.org/articles/timing-normal-rngs/ Boost headers are provided via the BH library: https://github.com/eddelbuettel/bh -steve On Wed, Jan 21, 2015 at 10:48 AM, avinash sahu avinash.s...@gmail.com mailto:avinash.s...@gmail.com wrote: Yes. I tried R internal libraries for random number generator also those provided by Rcpp but they are were not thread safe so it with multi-threading. I can try using other libraries, if anyone know random generator that are thread safe and not slow. thanks avi On Wed, Jan 21, 2015 at 7:38 PM, Martin Morgan mtmor...@fredhutch.org mailto:mtmor...@fredhutch.org wrote: On 01/21/2015 10:17 AM, avinash sahu wrote: Hi Dan, Thanks for the reply and quick support. I am sorry for so many issues, I am somewhat novice in bioconductor. I am replying to your comments inline. On Wed, Jan 21, 2015 at 6:55 PM, Dan Tenenbaum dtene...@fredhutch.org mailto:dtene...@fredhutch.org wrote: See my comments below. - Original Message - From: avinash sahu avinash.s...@gmail.com mailto:avinash.s...@gmail.com To: Karim Mezhoud kmezh...@gmail.com mailto:kmezh...@gmail.com Cc: bioc-devel@r-project.org mailto:bioc-devel@r-project.org Sent: Wednesday, January 21, 2015 7:50:38 AM Subject: Re: [Bioc-devel] Package submission with library requirement Thanks for mail Karim. I have GOAL staisfies all guidelines. However, GOAL is not compiling in windows and because of its heavy computational requirement its cannot be used with Windows. Can you please be very specific about why the package cannot be used with windows? Wherever possible we want packages to run on all the platforms we support. Have you attempted to compile it under windows and if so, what is the problem you ran into? Little bit of background first. GOAL is package, that will be a accompanying software for the manuscript that we are submitting to nature methods, so I would like to be as user friendly as possible. I spend couple of days to compile the package in Windows, however it is getting stuck because it uses Rcpp libraries along with third party libraries from other packages. I tried to get help from Windows regular user but it need someone expert in Windows OS to make it work. And I am no longer user of Windows so completely novice in it. have you thought carefully about the need for third-party libraries? For instance, R has extensive random number facilities, and these are available at the C level. This is documented in section 6 of RShowDoc(R-exts) Martin Regarding third party code, bioconductor website mentions (i.e. ransampl): In cases where the external library is complex the author may need to supply pre-built binary versions for some platforms. How to provide such binaries for linux and Mac to bioconductor. I'm not sure you need to provide binaries for ransampl. However, can you clarify the type of dependency that your package has on ransampl and GSL? Is the dependency build-time only? If that is the case, then users on Mac and Windows will not need to have ransampl and GSL installed, but they will if they need them at runtime. I clarified in my dependencies that it requires ransampl and GSL. In addition I added details in README about installation instruction of those libraries. thanks avi On Wed, Jan 21, 2015 at 2:39 PM, Karim Mezhoud kmezh...@gmail.com mailto:kmezh...@gmail.com wrote: Hi, Before you submit your package, please make sure that it satisfies all our guidelines
Re: [Bioc-devel] Latest R-devel revision breaks flowCore and other flow packages
That's right.
On Fri, Jan 23, 2015 at 12:22 PM, Mike wjia...@fhcrc.org wrote:
Sorry, I just want to clarify some more on this.(maybe useful for others as
well)
What you actually mean is callNextMethod() used to drop both ... and the
other arguments explicitly supplied from the parent call (in my case,
parameters argument).
And now after your fix, both gets passed on and that’s why I should
explicitly select the argument for callNextMethod?
Thanks.
Mike
On 01/23/2015 11:30 AM, Michael Lawrence wrote:
The bug has existed forever. The commit log may be confusing. The
actual bug (or at least a very undesirable behavior) was in
match.call(), not callNextMethod().
I think it's still true that callNextMethod() is the natural
invocation. When adding arguments to initialize that you do not want
to pass on (and thus set as slots), it's necessary to use explicit
args. There are other cases where callNextMethod() is exactly what you
want. Like the case in rtracklayer that motivated this fix.
On Fri, Jan 23, 2015 at 11:23 AM, Mike wjia...@fhcrc.org wrote:
Michael,
Thanks for the confirmation of the issue. I see you were trying to tackle it
in the latest commits r67467:67472 which apparently haven’t fixed the bug
yet (instead it triggers the error of the existing legacy code in other R
packages like flowCore). I can certainly change the code to explicitly pass
on all the arguments to callNextMethod as you and Martin suggested. I just
wonder if the documentation should drop the sentence of Calling with no
arguments is often the natural way to use callNextMethod and change the
example code (at least before the bug is eventually fixed.) so that users
won’t be misusing it.
Mike
On 01/23/2015 10:55 AM, Martin Morgan wrote:
On 01/23/2015 10:52 AM, Michael Lawrence wrote:
First let me apologize for my failure to read emails. There was a
long-standing bug in the methods package where arguments passed as
... to a method would be dropped by callNextMethod(). It turns out
that in all known cases this affects calls to initialize(), probably
because there are many initialize() methods, and new() calls
initialize with
This case is a very typical one, and Martin's fix is the right one,
according to the (unchanged) documentation of callNextMethod().
It's in general impossible to detect these cases from static analysis,
since we do not know how the user is calling a method. But catching
them in initialize() should be easy, with some false positives. Just
look for callNextMethod().
Is it OK for me to checkout all of Bioconductor so that I can perform
that analysis, or will that stress the servers too much? I have a
package that embeds GNU Global to index and search
CRAN/Bioconductor-size repositories for these cases.
Hi Michael -- there is no problem checking out all
(https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks presumably) of
Bioc.
Thanks! Martin
Michael
On Thu, Jan 22, 2015 at 6:15 AM, Martin Morgan mtmor...@fredhutch.org
wrote:
On 01/22/2015 12:26 AM, Martin Maechler wrote:
Mike wjia...@fhcrc.org
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.
I also pinged Michael??
What's a precise statement of the problem -- no-argument callNextMethod()
inside initialize? Any suggestions on ways to discover these without relying
on package break during build / check / install?
Martin Morgan
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
Re: [Bioc-devel] Latest R-devel revision breaks flowCore and other flow packages
On 01/23/2015 10:52 AM, Michael Lawrence wrote:
First let me apologize for my failure to read emails. There was a
long-standing bug in the methods package where arguments passed as
... to a method would be dropped by callNextMethod(). It turns out
that in all known cases this affects calls to initialize(), probably
because there are many initialize() methods, and new() calls
initialize with
This case is a very typical one, and Martin's fix is the right one,
according to the (unchanged) documentation of callNextMethod().
It's in general impossible to detect these cases from static analysis,
since we do not know how the user is calling a method. But catching
them in initialize() should be easy, with some false positives. Just
look for callNextMethod().
Is it OK for me to checkout all of Bioconductor so that I can perform
that analysis, or will that stress the servers too much? I have a
package that embeds GNU Global to index and search
CRAN/Bioconductor-size repositories for these cases.
Hi Michael -- there is no problem checking out all
(https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks presumably) of Bioc.
Thanks! Martin
Michael
On Thu, Jan 22, 2015 at 6:15 AM, Martin Morgan mtmor...@fredhutch.org wrote:
On 01/22/2015 12:26 AM, Martin Maechler wrote:
Mike wjia...@fhcrc.org
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.
I also pinged Michael??
What's a precise statement of the problem -- no-argument callNextMethod()
inside initialize? Any suggestions on ways to discover these without relying
on package break during build / check / install?
Martin Morgan
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
--
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
--
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] Latest R-devel revision breaks flowCore and other flow packages
Sorry, I just want to clarify some more on this.(maybe useful for others
as well)
What you actually mean is callNextMethod() used to drop both |...| and
the other arguments explicitly supplied from the parent call (in my
case, |parameters| argument).
And now after your fix, both gets passed on and that’s why I should
explicitly select the argument for callNextMethod?
Thanks.
Mike
On 01/23/2015 11:30 AM, Michael Lawrence wrote:
The bug has existed forever. The commit log may be confusing. The
actual bug (or at least a very undesirable behavior) was in
match.call(), not callNextMethod().
I think it's still true that callNextMethod() is the natural
invocation. When adding arguments to initialize that you do not want
to pass on (and thus set as slots), it's necessary to use explicit
args. There are other cases where callNextMethod() is exactly what you
want. Like the case in rtracklayer that motivated this fix.
On Fri, Jan 23, 2015 at 11:23 AM, Mike wjia...@fhcrc.org wrote:
Michael,
Thanks for the confirmation of the issue. I see you were trying to tackle it
in the latest commits r67467:67472 which apparently haven’t fixed the bug
yet (instead it triggers the error of the existing legacy code in other R
packages like flowCore). I can certainly change the code to explicitly pass
on all the arguments to callNextMethod as you and Martin suggested. I just
wonder if the documentation should drop the sentence of Calling with no
arguments is often the natural way to use callNextMethod and change the
example code (at least before the bug is eventually fixed.) so that users
won’t be misusing it.
Mike
On 01/23/2015 10:55 AM, Martin Morgan wrote:
On 01/23/2015 10:52 AM, Michael Lawrence wrote:
First let me apologize for my failure to read emails. There was a
long-standing bug in the methods package where arguments passed as
... to a method would be dropped by callNextMethod(). It turns out
that in all known cases this affects calls to initialize(), probably
because there are many initialize() methods, and new() calls
initialize with
This case is a very typical one, and Martin's fix is the right one,
according to the (unchanged) documentation of callNextMethod().
It's in general impossible to detect these cases from static analysis,
since we do not know how the user is calling a method. But catching
them in initialize() should be easy, with some false positives. Just
look for callNextMethod().
Is it OK for me to checkout all of Bioconductor so that I can perform
that analysis, or will that stress the servers too much? I have a
package that embeds GNU Global to index and search
CRAN/Bioconductor-size repositories for these cases.
Hi Michael -- there is no problem checking out all
(https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks presumably) of
Bioc.
Thanks! Martin
Michael
On Thu, Jan 22, 2015 at 6:15 AM, Martin Morgan mtmor...@fredhutch.org
wrote:
On 01/22/2015 12:26 AM, Martin Maechler wrote:
Mike wjia...@fhcrc.org
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.
I also pinged Michael??
What's a precise statement of the problem -- no-argument callNextMethod()
inside initialize? Any suggestions on ways to discover these without relying
on package break during build / check / install?
Martin Morgan
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
Re: [Bioc-devel] Package submission with library requirement
On Fri, Jan 23, 2015 at 1:58 PM, Dan Tenenbaum dtene...@fredhutch.org wrote: However, you should consider using Rlecuyer as it has no external dependencies (see Levi's post to this thread). Then your package should build on windows. I think so too - it's also a standard solution in R, implemented natively in r-core's parallel library and suggested by the snow library. I used it in my pensim library before transitioning to parallel, and have tested its streams on hyperthreaded CPUs and clusters. -- Levi Waldron Assistant Professor of Biostatistics City University of New York School of Public Health, Hunter College 2180 3rd Ave Rm 538 New York NY 10035-4003 phone: 212-396-7747 www.waldronlab.org ___ 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
First let me apologize for my failure to read emails. There was a
long-standing bug in the methods package where arguments passed as
... to a method would be dropped by callNextMethod(). It turns out
that in all known cases this affects calls to initialize(), probably
because there are many initialize() methods, and new() calls
initialize with
This case is a very typical one, and Martin's fix is the right one,
according to the (unchanged) documentation of callNextMethod().
It's in general impossible to detect these cases from static analysis,
since we do not know how the user is calling a method. But catching
them in initialize() should be easy, with some false positives. Just
look for callNextMethod().
Is it OK for me to checkout all of Bioconductor so that I can perform
that analysis, or will that stress the servers too much? I have a
package that embeds GNU Global to index and search
CRAN/Bioconductor-size repositories for these cases.
Michael
On Thu, Jan 22, 2015 at 6:15 AM, Martin Morgan mtmor...@fredhutch.org wrote:
On 01/22/2015 12:26 AM, Martin Maechler wrote:
Mike wjia...@fhcrc.org
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.
I also pinged Michael??
What's a precise statement of the problem -- no-argument callNextMethod()
inside initialize? Any suggestions on ways to discover these without relying
on package break during build / check / install?
Martin Morgan
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
--
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] Package submission with library requirement
- Original Message - From: Martin Morgan mtmor...@fredhutch.org To: avinash sahu avinash.s...@gmail.com, Steve Lianoglou lianoglou.st...@gene.com Cc: bioc-devel@r-project.org Sent: Friday, January 23, 2015 10:52:32 AM Subject: Re: [Bioc-devel] Package submission with library requirement On 01/21/2015 11:16 AM, avinash sahu wrote: Both the libraries are not thread safe. Although boost random genrator in limited situation can be thread safe. I have tried them earlier they were failing with multi-threading. One way out might be, if I include the source code of ransampl with package source code. There license allows this, I can also mail ask the developer of Ransampl about the permission. Will this be acceptable to bioconductor folks? yes, provided the license of the library allows for it, it is a good solution. There is guidance in RShowDoc(R-exts) on acknowledging this in the DESCRIPTION (and possibly LICENSE) file. However, you should consider using Rlecuyer as it has no external dependencies (see Levi's post to this thread). Then your package should build on windows. Dan Martin thanks avi On Wed, Jan 21, 2015 at 7:57 PM, Steve Lianoglou lianoglou.st...@gene.com mailto:lianoglou.st...@gene.com wrote: Does the boost RNGs qualify? He's a vignette showing how to use them through R/Rcpp http://gallery.rcpp.org/articles/timing-normal-rngs/ Boost headers are provided via the BH library: https://github.com/eddelbuettel/bh -steve On Wed, Jan 21, 2015 at 10:48 AM, avinash sahu avinash.s...@gmail.com mailto:avinash.s...@gmail.com wrote: Yes. I tried R internal libraries for random number generator also those provided by Rcpp but they are were not thread safe so it with multi-threading. I can try using other libraries, if anyone know random generator that are thread safe and not slow. thanks avi On Wed, Jan 21, 2015 at 7:38 PM, Martin Morgan mtmor...@fredhutch.org mailto:mtmor...@fredhutch.org wrote: On 01/21/2015 10:17 AM, avinash sahu wrote: Hi Dan, Thanks for the reply and quick support. I am sorry for so many issues, I am somewhat novice in bioconductor. I am replying to your comments inline. On Wed, Jan 21, 2015 at 6:55 PM, Dan Tenenbaum dtene...@fredhutch.org mailto:dtene...@fredhutch.org wrote: See my comments below. - Original Message - From: avinash sahu avinash.s...@gmail.com mailto:avinash.s...@gmail.com To: Karim Mezhoud kmezh...@gmail.com mailto:kmezh...@gmail.com Cc: bioc-devel@r-project.org mailto:bioc-devel@r-project.org Sent: Wednesday, January 21, 2015 7:50:38 AM Subject: Re: [Bioc-devel] Package submission with library requirement Thanks for mail Karim. I have GOAL staisfies all guidelines. However, GOAL is not compiling in windows and because of its heavy computational requirement its cannot be used with Windows. Can you please be very specific about why the package cannot be used with windows? Wherever possible we want packages to run on all the platforms we support. Have you attempted to compile it under windows and if so, what is the problem you ran into? Little bit of background first. GOAL is package, that will be a accompanying software for the manuscript that we are submitting to nature methods, so I would like to be as user friendly as possible. I spend couple of days to compile the package in Windows, however it is getting stuck because it uses Rcpp libraries along with third party libraries from other packages. I tried to get help from Windows regular user but it need someone expert in Windows OS to make it work. And I am no longer user of Windows so completely novice in it. have you thought carefully about the need for third-party libraries? For instance, R has extensive random number facilities, and these are available at the C level. This is documented in section 6 of RShowDoc(R-exts) Martin Regarding third party code, bioconductor website mentions (i.e. ransampl): In cases where the external library is complex the author may need to supply pre-built binary versions for some platforms. How to provide such
Re: [Bioc-devel] Latest R-devel revision breaks flowCore and other flow packages
The bug has existed forever. The commit log may be confusing. The
actual bug (or at least a very undesirable behavior) was in
match.call(), not callNextMethod().
I think it's still true that callNextMethod() is the natural
invocation. When adding arguments to initialize that you do not want
to pass on (and thus set as slots), it's necessary to use explicit
args. There are other cases where callNextMethod() is exactly what you
want. Like the case in rtracklayer that motivated this fix.
On Fri, Jan 23, 2015 at 11:23 AM, Mike wjia...@fhcrc.org wrote:
Michael,
Thanks for the confirmation of the issue. I see you were trying to tackle it
in the latest commits r67467:67472 which apparently haven’t fixed the bug
yet (instead it triggers the error of the existing legacy code in other R
packages like flowCore). I can certainly change the code to explicitly pass
on all the arguments to callNextMethod as you and Martin suggested. I just
wonder if the documentation should drop the sentence of Calling with no
arguments is often the natural way to use callNextMethod and change the
example code (at least before the bug is eventually fixed.) so that users
won’t be misusing it.
Mike
On 01/23/2015 10:55 AM, Martin Morgan wrote:
On 01/23/2015 10:52 AM, Michael Lawrence wrote:
First let me apologize for my failure to read emails. There was a
long-standing bug in the methods package where arguments passed as
... to a method would be dropped by callNextMethod(). It turns out
that in all known cases this affects calls to initialize(), probably
because there are many initialize() methods, and new() calls
initialize with
This case is a very typical one, and Martin's fix is the right one,
according to the (unchanged) documentation of callNextMethod().
It's in general impossible to detect these cases from static analysis,
since we do not know how the user is calling a method. But catching
them in initialize() should be easy, with some false positives. Just
look for callNextMethod().
Is it OK for me to checkout all of Bioconductor so that I can perform
that analysis, or will that stress the servers too much? I have a
package that embeds GNU Global to index and search
CRAN/Bioconductor-size repositories for these cases.
Hi Michael -- there is no problem checking out all
(https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks presumably) of
Bioc.
Thanks! Martin
Michael
On Thu, Jan 22, 2015 at 6:15 AM, Martin Morgan mtmor...@fredhutch.org
wrote:
On 01/22/2015 12:26 AM, Martin Maechler wrote:
Mike wjia...@fhcrc.org
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.
I also pinged Michael??
What's a precise statement of the problem -- no-argument callNextMethod()
inside initialize? Any suggestions on ways to discover these without relying
on package break during build / check / install?
Martin Morgan
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
--
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
Re: [Rd] :: and ::: as .Primitives?
On 22/01/2015 4:06 PM, Peter Haverty wrote: Hi all, I use Luke's :: hoisting trick often. I think it would be fantastic if the JIT just did that for you. The main trouble, for me, is in code I don't own. When common Bioconductor packages are loaded many, many base functions are saddled with this substantial dispatch and :: overhead. While we have the hood up, the parser could help out a bit here too. It already has special cases for :: and :::. Currently you get the symbols pkg and name and have to go fishing in the calling environment for the associated values. I don't think the parser should do this, but it does seem like a reasonable optimization for the compiler to do. It would be nice to have the parser or JIT rewrite base::match as doubleColon(base,match) or directly provide the symbols base and match to the subsequent code. Currently the parser provides the expression `::`(base, match), and the `::` function converts those symbols to character strings base and match. While the parser could have saved it some work by giving the expression `::`(base, match), I think it's a bad idea to start messing with things that way. After all, a user could have defined their own `::` function, and they should get what they typed. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] :: and ::: as .Primitives?
On Fri, Jan 23, 2015 at 10:11 AM, Hervé Pagès hpa...@fredhutch.org wrote: Hi, On 01/23/2015 07:01 AM, luke-tier...@uiowa.edu wrote: On Thu, 22 Jan 2015, Michael Lawrence wrote: On Thu, Jan 22, 2015 at 11:44 AM, luke-tier...@uiowa.edu wrote: For default methods there ought to be a way to create those so the default method is computed at creation or load time and stored in an environment. We had considered that, but we thought the definition of the function would be easier to interpret if it explicitly specified the namespace, instead of using tricks with environments. The same applies for memoizing the lookup in front of a loop. interpret in what sense (human reader or R interpreter)? In either case I'm not convinced. From a developer perspective, especially when debugging, when we do selectMethod(match, ...) and it turns out that this returns the default method, it's good to see: Method Definition (Class derivedDefaultMethod): function (x, table, nomatch = NA_integer_, incomparables = NULL, ...) base::match(x, table, nomatch = nomatch, incomparables = incomparables, ...) environment: namespace:BiocGenerics Signatures: x table target DataFrame ANY defined ANY ANY rather than some obscure/uninformative body. I hope we can keep that. That was the goal of this patch. We want to keep that, and make match() ~25% faster when falling back to the default method (for small inputs). Right now, loading BiocGenerics, IRanges, etc, slows many functions down by roughly that amount. The implementation of these functions is almost simpler in C than it is in R, so there is relatively little risk to this change. But I agree the benefits are also somewhat minor. I don't disagree, but it remains that even calling the C version has costs that should not need to be paid. But maybe we can leave that to the compiler/byte code engine. Optimizing references to symbols resolved statically to name spaces and imports is on the to do list, and with a little care that mechanism should work for foo::bar uses as well. That would be great. Thanks! H. Best, luke For other cases if I want to use foo::bar many times, say in a loop, I would do foo_bar - foo::bar and use foo_bar, or something along those lines. When :: and ::: were introduce they were intended primarily for reflection and debugging, so speed was not an issue. ::: is still really only reliably usable that way, and making it faster may just encourage bad practice. :: is different and there are good arguments for using it in code, but I'm not yet seeing good arguments for use in ways that would be performance-critical, but I'm happy to be convinced otherwise. If there is a need for a faster :: then going to a SPECIALSXP is fine; it would also be good to make the byte code compiler aware of it, and possibly to work on ways to improve the performance further e.g. through cacheing. Best, luke On Thu, 22 Jan 2015, Peter Haverty wrote: Hi all, When S4 methods are defined on base function (say, match), the function becomes a method with the body base::match(x,y). A call to such a function often spends more time doing :: than in the function itself. I always assumed that :: was a very low-level thing, but it turns out to be a plain old function defined in base/R/namespace.R. What would you all think about making :: and ::: .Primitives? I have submitted some examples, timings, and a patch to the R bug tracker (https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16134). I'd be very interested to hear your thoughts on the matter. Regards, Pete Peter M. Haverty, Ph.D. Genentech, Inc. phave...@gene.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Luke Tierney Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: luke-tier...@uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Programming Tools CTV
Dear Willem I maintain the MetaAnalysis CTV. I have found it quite practicable to do this without special tools. I use an editor for the XML. I use CRANberries to catch updates and I usually email people to check I have understood a new package. People also kindly email me occasionally with news about major changes. On the other hand since it is the programming tools CTV I imagine you will want to try out the latest all-singing, all-dancing technology. And why not. Michael On 23/01/2015 13:05, Christophe Dutang wrote: Dear Willem, Personally, I use the R-forge project for the distribution CTV : https://r-forge.r-project.org/projects/ctv/ It’s an alternative option to github. Regards, Christophe --- Christophe Dutang LMM, UdM, Le Mans, France web: http://dutangc.free.fr Le 23 janv. 2015 à 12:49, Luca Braglia lbrag...@gmail.com a écrit : Hi Willem thanks for volounteering. To the best of my knowledge (regarding the machinery side), if you're planning to use github (and maybe even if you don't) you can stole ideas from https://github.com/ropensci/webservices https://github.com/lbraglia/PackageDevelopmentTaskView (minor modifications from webservices) https://github.com/eddelbuettel/ctv-finance or https://github.com/eddelbuettel/ctv-hpc HTH, Luca 2015-01-23 11:13 GMT+01:00 Willem Ligtenberg willem.ligtenb...@openanalytics.eu: Hi all, Sorry if this doesn't end up in the thread. Tobias Verbeke forwarded that e-mail to me, because he thought I would be interested in maintaining the Programming Tools CTV. I wasn't subscribed to R-devel yet, but I would indeed like to volunteer to maintain the Programming Tools CTV. It will be my first time creating a CTV, so some guidance on getting it setup will be appreciated. I myself am very interested in better/easier ways to develop faster and nicer code. Kind regards, Willem __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel - No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.5645 / Virus Database: 4260/8981 - Release Date: 01/23/15 -- Michael http://www.dewey.myzen.co.uk __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Programming Tools CTV
I'd strongly second the notion of using github. The biggest advantage is that others can easily contribute changes through pull requests which lifts much of the burden from your shoulders. Hadley On Fri, Jan 23, 2015 at 3:49 AM, Luca Braglia lbrag...@gmail.com wrote: Hi Willem thanks for volounteering. To the best of my knowledge (regarding the machinery side), if you're planning to use github (and maybe even if you don't) you can stole ideas from https://github.com/ropensci/webservices https://github.com/lbraglia/PackageDevelopmentTaskView (minor modifications from webservices) https://github.com/eddelbuettel/ctv-finance or https://github.com/eddelbuettel/ctv-hpc HTH, Luca 2015-01-23 11:13 GMT+01:00 Willem Ligtenberg willem.ligtenb...@openanalytics.eu: Hi all, Sorry if this doesn't end up in the thread. Tobias Verbeke forwarded that e-mail to me, because he thought I would be interested in maintaining the Programming Tools CTV. I wasn't subscribed to R-devel yet, but I would indeed like to volunteer to maintain the Programming Tools CTV. It will be my first time creating a CTV, so some guidance on getting it setup will be appreciated. I myself am very interested in better/easier ways to develop faster and nicer code. Kind regards, Willem __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Bioc-devel] portable make syntax
Dear all,
I have been using the following in various vignettes/Makefile
ifeq (${R_HOME},)
R_HOME= $(shell R RHOME)
endif
This syntax is GNU specific and now results in warnings when checking
the package:
* checking for GNU extensions in Makefiles ... WARNING
Found the following file(s) containing GNU extensions:
vignettes/Makefile
Portable Makefiles do not use GNU extensions such as +=, :=, $(shell),
$(wildcard), ifeq ... endif. See section ‘Writing portable packages’ in
the ‘Writing R Extensions’ manual.
I couldn't find anything in R-exts; does anyone know a more portable
syntax?
Alternatively, I could add
SystemRequirements: GNU make
to my DESCRIPTION file, which however does not seem ideal.
Any suggestions?
Thank you very much in advance.
Laurent
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] portable make syntax
On Fri, Jan 23, 2015 at 5:18 PM, Dan Tenenbaum dtene...@fredhutch.org wrote:
- Original Message -
From: Kevin Ushey kevinus...@gmail.com
To: Laurent Gatto lg...@cam.ac.uk
Cc: bioc-devel bioc-de...@stat.math.ethz.ch
Sent: Friday, January 23, 2015 4:58:40 PM
Subject: Re: [Bioc-devel] portable make syntax
If I understand correctly, all versions of `make` on the BioC build
systems will support GNU extensions to Makefiles, and so it's
probably
not worth your time to make this 'portable' -- just add the
SystemRequirements bit.
BTW, the warning was added in recent versions of R-devel and I don't know why
it was added.
It could be that GNU extensions may not be supported in future versions of
Rtools (the windows
toolchain maintained by Duncan Murdoch). I really have no idea. But since a
warning was added, it's probably a good idea to find out why rather than to
ignore it. So it might be worth a note to R-devel asking about the intention
of that warning.
Dan
Very unlikely -- I am really not sure of what the motivation is,
beyond R wanting to support platforms with versions of make that do
not support GNU extensions (whichever those might be... BSD make? ATT
make on Solaris? See:
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT51)
I am guessing that the Windows toolchain will continue to be based off
of MinGW + GCC for the foreseeable future, and hence will continue to
allow GNU extensions. In fact, R-exts specifically prescribes GNU
extensions for Windows makefiles -- from R-exts,
Since the only viable make for Windows is GNU make, it is
permissible to use GNU extensions in files Makevars.win or
Makefile.win.
so I really doubt Windows would ever foresake GNU extensions.
Kevin
However, you could work around this by (following R-exts at
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Writing-portable-packages)
wrapping your shell command in backticks, e.g.
R_HOME=`if test -z ${R_HOME}; then ...; else ...; fi`
or something to that effect.
On Fri, Jan 23, 2015 at 4:05 PM, Laurent Gatto lg...@cam.ac.uk
wrote:
Dear all,
I have been using the following in various vignettes/Makefile
ifeq (${R_HOME},)
R_HOME= $(shell R RHOME)
endif
This syntax is GNU specific and now results in warnings when
checking
the package:
* checking for GNU extensions in Makefiles ... WARNING
Found the following file(s) containing GNU extensions:
vignettes/Makefile
Portable Makefiles do not use GNU extensions such as +=, :=,
$(shell),
$(wildcard), ifeq ... endif. See section ‘Writing portable
packages’ in
the ‘Writing R Extensions’ manual.
I couldn't find anything in R-exts; does anyone know a more
portable
syntax?
Alternatively, I could add
SystemRequirements: GNU make
to my DESCRIPTION file, which however does not seem ideal.
Any suggestions?
Thank you very much in advance.
Laurent
___
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] portable make syntax
On 01/23/2015 06:22 PM, Michael Lawrence wrote:
Here is a quote from Brian's email to CRAN maintainers:
The set of make programs in use for R is shifting (BSD make seems to
be no longer in use by Apple or FreeBSD; dmake and pmake variants are
appearing) and we have taken the POSIX standard as the baseline for
portability.
It sounds like this is a CRAN-specific requirement. Bioc of course is
left to make its own decision on make support.
I think that most make files can be made to conform easily to POSIX standards,
which seems in general like a good idea (Linux flavored packages build from
source, so the compilers on the Bioc build machines are a poor guide to those
encountered in the wild).
If we absolutely need GNU Make, we can add this to DESCRIPTION:
SystemRequirements: GNU make
...remembering that this merely quietens the note, and we would rather address
the issue.
I haven't looked at the build reports, but the it looks like the following
(including several apparently following poorly worded instructions in Rsamtools;
aargh) can be easily brought into conformance through use of ` rather than $(shell).
$ ls */src/Makevars|xargs grep -l shell
ArrayExpressHTS/src/Makevars
ChemmineR/src/Makevars
DiffBind/src/Makevars
eiR/src/Makevars
flipflop/src/Makevars
mosaics/src/Makevars
qrqc/src/Makevars
QuasR/src/Makevars
VariantAnnotation/src/Makevars
Martin
On Fri, Jan 23, 2015 at 6:13 PM, Kevin Ushey kevinus...@gmail.com wrote:
On Fri, Jan 23, 2015 at 5:18 PM, Dan Tenenbaum dtene...@fredhutch.org wrote:
- Original Message -
From: Kevin Ushey kevinus...@gmail.com
To: Laurent Gatto lg...@cam.ac.uk
Cc: bioc-devel bioc-de...@stat.math.ethz.ch
Sent: Friday, January 23, 2015 4:58:40 PM
Subject: Re: [Bioc-devel] portable make syntax
If I understand correctly, all versions of `make` on the BioC build
systems will support GNU extensions to Makefiles, and so it's
probably
not worth your time to make this 'portable' -- just add the
SystemRequirements bit.
BTW, the warning was added in recent versions of R-devel and I don't know why
it was added.
It could be that GNU extensions may not be supported in future versions of
Rtools (the windows
toolchain maintained by Duncan Murdoch). I really have no idea. But since a
warning was added, it's probably a good idea to find out why rather than to
ignore it. So it might be worth a note to R-devel asking about the intention of
that warning.
Dan
Very unlikely -- I am really not sure of what the motivation is,
beyond R wanting to support platforms with versions of make that do
not support GNU extensions (whichever those might be... BSD make? ATT
make on Solaris? See:
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT51)
I am guessing that the Windows toolchain will continue to be based off
of MinGW + GCC for the foreseeable future, and hence will continue to
allow GNU extensions. In fact, R-exts specifically prescribes GNU
extensions for Windows makefiles -- from R-exts,
Since the only viable make for Windows is GNU make, it is
permissible to use GNU extensions in files Makevars.win or
Makefile.win.
so I really doubt Windows would ever foresake GNU extensions.
Kevin
However, you could work around this by (following R-exts at
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Writing-portable-packages)
wrapping your shell command in backticks, e.g.
R_HOME=`if test -z ${R_HOME}; then ...; else ...; fi`
or something to that effect.
On Fri, Jan 23, 2015 at 4:05 PM, Laurent Gatto lg...@cam.ac.uk
wrote:
Dear all,
I have been using the following in various vignettes/Makefile
ifeq (${R_HOME},)
R_HOME= $(shell R RHOME)
endif
This syntax is GNU specific and now results in warnings when
checking
the package:
* checking for GNU extensions in Makefiles ... WARNING
Found the following file(s) containing GNU extensions:
vignettes/Makefile
Portable Makefiles do not use GNU extensions such as +=, :=,
$(shell),
$(wildcard), ifeq ... endif. See section ‘Writing portable
packages’ in
the ‘Writing R Extensions’ manual.
I couldn't find anything in R-exts; does anyone know a more
portable
syntax?
Alternatively, I could add
SystemRequirements: GNU make
to my DESCRIPTION file, which however does not seem ideal.
Any suggestions?
Thank you very much in advance.
Laurent
___
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
--
Computational Biology / Fred Hutchinson Cancer Research Center
Re: [Bioc-devel] portable make syntax
- Original Message -
From: Kevin Ushey kevinus...@gmail.com
To: Laurent Gatto lg...@cam.ac.uk
Cc: bioc-devel bioc-de...@stat.math.ethz.ch
Sent: Friday, January 23, 2015 4:58:40 PM
Subject: Re: [Bioc-devel] portable make syntax
If I understand correctly, all versions of `make` on the BioC build
systems will support GNU extensions to Makefiles, and so it's
probably
not worth your time to make this 'portable' -- just add the
SystemRequirements bit.
BTW, the warning was added in recent versions of R-devel and I don't know why
it was added.
It could be that GNU extensions may not be supported in future versions of
Rtools (the windows
toolchain maintained by Duncan Murdoch). I really have no idea. But since a
warning was added, it's probably a good idea to find out why rather than to
ignore it. So it might be worth a note to R-devel asking about the intention of
that warning.
Dan
However, you could work around this by (following R-exts at
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Writing-portable-packages)
wrapping your shell command in backticks, e.g.
R_HOME=`if test -z ${R_HOME}; then ...; else ...; fi`
or something to that effect.
On Fri, Jan 23, 2015 at 4:05 PM, Laurent Gatto lg...@cam.ac.uk
wrote:
Dear all,
I have been using the following in various vignettes/Makefile
ifeq (${R_HOME},)
R_HOME= $(shell R RHOME)
endif
This syntax is GNU specific and now results in warnings when
checking
the package:
* checking for GNU extensions in Makefiles ... WARNING
Found the following file(s) containing GNU extensions:
vignettes/Makefile
Portable Makefiles do not use GNU extensions such as +=, :=,
$(shell),
$(wildcard), ifeq ... endif. See section ‘Writing portable
packages’ in
the ‘Writing R Extensions’ manual.
I couldn't find anything in R-exts; does anyone know a more
portable
syntax?
Alternatively, I could add
SystemRequirements: GNU make
to my DESCRIPTION file, which however does not seem ideal.
Any suggestions?
Thank you very much in advance.
Laurent
___
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
I have found and fixed the affected initialize cases and will begin
checking in fixes.
Affected packages: RDAVIDWebService, flowCore (as we know), Gviz,
ChIPseqR, Pviz, VanillaICE, flowFit.
As an aside, in all of these cases, initialize is implementing logic
that really belongs in a constructor function. Treating new() as a
high-level constructor should be discouraged in my opinion. Has
nothing to do with this bug though.
I have also begun looking through cases outside of initialize. There
are only about 300 cases of callNextMethod() in the codebase. Great
majority seem OK so far.
On Fri, Jan 23, 2015 at 12:46 PM, Michael Lawrence micha...@gene.com wrote:
That's right.
On Fri, Jan 23, 2015 at 12:22 PM, Mike wjia...@fhcrc.org wrote:
Sorry, I just want to clarify some more on this.(maybe useful for others as
well)
What you actually mean is callNextMethod() used to drop both ... and the
other arguments explicitly supplied from the parent call (in my case,
parameters argument).
And now after your fix, both gets passed on and that’s why I should
explicitly select the argument for callNextMethod?
Thanks.
Mike
On 01/23/2015 11:30 AM, Michael Lawrence wrote:
The bug has existed forever. The commit log may be confusing. The
actual bug (or at least a very undesirable behavior) was in
match.call(), not callNextMethod().
I think it's still true that callNextMethod() is the natural
invocation. When adding arguments to initialize that you do not want
to pass on (and thus set as slots), it's necessary to use explicit
args. There are other cases where callNextMethod() is exactly what you
want. Like the case in rtracklayer that motivated this fix.
On Fri, Jan 23, 2015 at 11:23 AM, Mike wjia...@fhcrc.org wrote:
Michael,
Thanks for the confirmation of the issue. I see you were trying to tackle it
in the latest commits r67467:67472 which apparently haven’t fixed the bug
yet (instead it triggers the error of the existing legacy code in other R
packages like flowCore). I can certainly change the code to explicitly pass
on all the arguments to callNextMethod as you and Martin suggested. I just
wonder if the documentation should drop the sentence of Calling with no
arguments is often the natural way to use callNextMethod and change the
example code (at least before the bug is eventually fixed.) so that users
won’t be misusing it.
Mike
On 01/23/2015 10:55 AM, Martin Morgan wrote:
On 01/23/2015 10:52 AM, Michael Lawrence wrote:
First let me apologize for my failure to read emails. There was a
long-standing bug in the methods package where arguments passed as
... to a method would be dropped by callNextMethod(). It turns out
that in all known cases this affects calls to initialize(), probably
because there are many initialize() methods, and new() calls
initialize with
This case is a very typical one, and Martin's fix is the right one,
according to the (unchanged) documentation of callNextMethod().
It's in general impossible to detect these cases from static analysis,
since we do not know how the user is calling a method. But catching
them in initialize() should be easy, with some false positives. Just
look for callNextMethod().
Is it OK for me to checkout all of Bioconductor so that I can perform
that analysis, or will that stress the servers too much? I have a
package that embeds GNU Global to index and search
CRAN/Bioconductor-size repositories for these cases.
Hi Michael -- there is no problem checking out all
(https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks presumably) of
Bioc.
Thanks! Martin
Michael
On Thu, Jan 22, 2015 at 6:15 AM, Martin Morgan mtmor...@fredhutch.org
wrote:
On 01/22/2015 12:26 AM, Martin Maechler wrote:
Mike wjia...@fhcrc.org
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, ...)
Re: [Bioc-devel] portable make syntax
Here is a quote from Brian's email to CRAN maintainers:
The set of make programs in use for R is shifting (BSD make seems to
be no longer in use by Apple or FreeBSD; dmake and pmake variants are
appearing) and we have taken the POSIX standard as the baseline for
portability.
It sounds like this is a CRAN-specific requirement. Bioc of course is
left to make its own decision on make support.
If we absolutely need GNU Make, we can add this to DESCRIPTION:
SystemRequirements: GNU make
On Fri, Jan 23, 2015 at 6:13 PM, Kevin Ushey kevinus...@gmail.com wrote:
On Fri, Jan 23, 2015 at 5:18 PM, Dan Tenenbaum dtene...@fredhutch.org wrote:
- Original Message -
From: Kevin Ushey kevinus...@gmail.com
To: Laurent Gatto lg...@cam.ac.uk
Cc: bioc-devel bioc-de...@stat.math.ethz.ch
Sent: Friday, January 23, 2015 4:58:40 PM
Subject: Re: [Bioc-devel] portable make syntax
If I understand correctly, all versions of `make` on the BioC build
systems will support GNU extensions to Makefiles, and so it's
probably
not worth your time to make this 'portable' -- just add the
SystemRequirements bit.
BTW, the warning was added in recent versions of R-devel and I don't know
why it was added.
It could be that GNU extensions may not be supported in future versions of
Rtools (the windows
toolchain maintained by Duncan Murdoch). I really have no idea. But since a
warning was added, it's probably a good idea to find out why rather than to
ignore it. So it might be worth a note to R-devel asking about the intention
of that warning.
Dan
Very unlikely -- I am really not sure of what the motivation is,
beyond R wanting to support platforms with versions of make that do
not support GNU extensions (whichever those might be... BSD make? ATT
make on Solaris? See:
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT51)
I am guessing that the Windows toolchain will continue to be based off
of MinGW + GCC for the foreseeable future, and hence will continue to
allow GNU extensions. In fact, R-exts specifically prescribes GNU
extensions for Windows makefiles -- from R-exts,
Since the only viable make for Windows is GNU make, it is
permissible to use GNU extensions in files Makevars.win or
Makefile.win.
so I really doubt Windows would ever foresake GNU extensions.
Kevin
However, you could work around this by (following R-exts at
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Writing-portable-packages)
wrapping your shell command in backticks, e.g.
R_HOME=`if test -z ${R_HOME}; then ...; else ...; fi`
or something to that effect.
On Fri, Jan 23, 2015 at 4:05 PM, Laurent Gatto lg...@cam.ac.uk
wrote:
Dear all,
I have been using the following in various vignettes/Makefile
ifeq (${R_HOME},)
R_HOME= $(shell R RHOME)
endif
This syntax is GNU specific and now results in warnings when
checking
the package:
* checking for GNU extensions in Makefiles ... WARNING
Found the following file(s) containing GNU extensions:
vignettes/Makefile
Portable Makefiles do not use GNU extensions such as +=, :=,
$(shell),
$(wildcard), ifeq ... endif. See section ‘Writing portable
packages’ in
the ‘Writing R Extensions’ manual.
I couldn't find anything in R-exts; does anyone know a more
portable
syntax?
Alternatively, I could add
SystemRequirements: GNU make
to my DESCRIPTION file, which however does not seem ideal.
Any suggestions?
Thank you very much in advance.
Laurent
___
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: [Rd] Programming Tools CTV
Willem, thanks for volunteering! Sorry if this doesn't end up in the thread. Tobias Verbeke forwarded that e-mail to me, because he thought I would be interested in maintaining the Programming Tools CTV. I wasn't subscribed to R-devel yet, but I would indeed like to volunteer to maintain the Programming Tools CTV. As discussed in the other thread: A programming tools task view would be too broad and Max suggested splitting it up into sharper and more manageable portions. Maybe you want to pick up one of these sub-topics? It will be my first time creating a CTV, so some guidance on getting it setup will be appreciated. I myself am very interested in better/easier ways to develop faster and nicer code. The process is usually the following: - Someone proposes to set up a certain task view - often here in the list or in a direct e-mail to me. - If the topic is deemed feasible for a task view, then the maintainer-to-be compiles a .ctv file following the advice in vignette(ctv, package = ctv) and first sends it to me. - If the maintainer-to-be and myself are satisfied with the result so far, we typically try to get some more feedback from the mailing list and then release it to CRAN. As for version control: The ctv package and all task view reside on R-Forge. All maintainers are invited to join the R-Forge project and thus get access to the SVN repository so that they can change their .ctv file directly. Most maintainers do so but a few maintainers have chose to either use no version control themselves or use some separate system (e.g., Github). In the latter cases, updates are sent by e-mail to me. Best, Z Kind regards, Willem __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] :: and ::: as .Primitives?
On Thu, 22 Jan 2015, Henrik Bengtsson wrote: On Thu, Jan 22, 2015 at 11:44 AM, luke-tier...@uiowa.edu wrote: I'm not convinced that how to make :: faster is the right question. If you are finding foo::bar being called often enough to matter to your overall performance then to me the question is: why are you calling foo::bar more than once? Making :: a bit faster by making it a primitive will remove some overhead, but your are still left with a lot of work that shouldn't need to happen more than once. For default methods there ought to be a way to create those so the default method is computed at creation or load time and stored in an environment. For other cases if I want to use foo::bar many times, say in a loop, I would do foo_bar - foo::bar and use foo_bar, or something along those lines. While you're on the line: Do you think this is an optimization that the 'compiler' package and it's cmpfun() byte compiler will be able to do in the future? Most likely, at least at reasonable optimization levels. Best, luke /Henrik When :: and ::: were introduce they were intended primarily for reflection and debugging, so speed was not an issue. ::: is still really only reliably usable that way, and making it faster may just encourage bad practice. :: is different and there are good arguments for using it in code, but I'm not yet seeing good arguments for use in ways that would be performance-critical, but I'm happy to be convinced otherwise. If there is a need for a faster :: then going to a SPECIALSXP is fine; it would also be good to make the byte code compiler aware of it, and possibly to work on ways to improve the performance further e.g. through cacheing. Best, luke On Thu, 22 Jan 2015, Peter Haverty wrote: Hi all, When S4 methods are defined on base function (say, match), the function becomes a method with the body base::match(x,y). A call to such a function often spends more time doing :: than in the function itself. I always assumed that :: was a very low-level thing, but it turns out to be a plain old function defined in base/R/namespace.R. What would you all think about making :: and ::: .Primitives? I have submitted some examples, timings, and a patch to the R bug tracker (https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16134). I'd be very interested to hear your thoughts on the matter. Regards, Pete Peter M. Haverty, Ph.D. Genentech, Inc. phave...@gene.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Luke Tierney Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: luke-tier...@uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Luke Tierney Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: luke-tier...@uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] :: and ::: as .Primitives?
On Thu, 22 Jan 2015, Michael Lawrence wrote: On Thu, Jan 22, 2015 at 11:44 AM, luke-tier...@uiowa.edu wrote: For default methods there ought to be a way to create those so the default method is computed at creation or load time and stored in an environment. We had considered that, but we thought the definition of the function would be easier to interpret if it explicitly specified the namespace, instead of using tricks with environments. The same applies for memoizing the lookup in front of a loop. interpret in what sense (human reader or R interpreter)? In either case I'm not convinced. The implementation of these functions is almost simpler in C than it is in R, so there is relatively little risk to this change. But I agree the benefits are also somewhat minor. I don't disagree, but it remains that even calling the C version has costs that should not need to be paid. But maybe we can leave that to the compiler/byte code engine. Optimizing references to symbols resolved statically to name spaces and imports is on the to do list, and with a little care that mechanism should work for foo::bar uses as well. Best, luke For other cases if I want to use foo::bar many times, say in a loop, I would do foo_bar - foo::bar and use foo_bar, or something along those lines. When :: and ::: were introduce they were intended primarily for reflection and debugging, so speed was not an issue. ::: is still really only reliably usable that way, and making it faster may just encourage bad practice. :: is different and there are good arguments for using it in code, but I'm not yet seeing good arguments for use in ways that would be performance-critical, but I'm happy to be convinced otherwise. If there is a need for a faster :: then going to a SPECIALSXP is fine; it would also be good to make the byte code compiler aware of it, and possibly to work on ways to improve the performance further e.g. through cacheing. Best, luke On Thu, 22 Jan 2015, Peter Haverty wrote: Hi all, When S4 methods are defined on base function (say, match), the function becomes a method with the body base::match(x,y). A call to such a function often spends more time doing :: than in the function itself. I always assumed that :: was a very low-level thing, but it turns out to be a plain old function defined in base/R/namespace.R. What would you all think about making :: and ::: .Primitives? I have submitted some examples, timings, and a patch to the R bug tracker (https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16134). I'd be very interested to hear your thoughts on the matter. Regards, Pete Peter M. Haverty, Ph.D. Genentech, Inc. phave...@gene.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Luke Tierney Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: luke-tier...@uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Luke Tierney Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: luke-tier...@uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Programming Tools CTV
Dear Willem, Personally, I use the R-forge project for the distribution CTV : https://r-forge.r-project.org/projects/ctv/ It’s an alternative option to github. Regards, Christophe --- Christophe Dutang LMM, UdM, Le Mans, France web: http://dutangc.free.fr Le 23 janv. 2015 à 12:49, Luca Braglia lbrag...@gmail.com a écrit : Hi Willem thanks for volounteering. To the best of my knowledge (regarding the machinery side), if you're planning to use github (and maybe even if you don't) you can stole ideas from https://github.com/ropensci/webservices https://github.com/lbraglia/PackageDevelopmentTaskView (minor modifications from webservices) https://github.com/eddelbuettel/ctv-finance or https://github.com/eddelbuettel/ctv-hpc HTH, Luca 2015-01-23 11:13 GMT+01:00 Willem Ligtenberg willem.ligtenb...@openanalytics.eu: Hi all, Sorry if this doesn't end up in the thread. Tobias Verbeke forwarded that e-mail to me, because he thought I would be interested in maintaining the Programming Tools CTV. I wasn't subscribed to R-devel yet, but I would indeed like to volunteer to maintain the Programming Tools CTV. It will be my first time creating a CTV, so some guidance on getting it setup will be appreciated. I myself am very interested in better/easier ways to develop faster and nicer code. Kind regards, Willem __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] speedbump in library
I think you can simplify a little by replacing this:
pkg %in% loadedNamespaces()
with this:
.getNamespace(pkg)
Whereas getNamespace(pkg) will load the package if it's not already
loaded, calling .getNamespace(pkg) (note the leading dot) won't load
the package.
I can't speak to whether there are any pitfalls in changing the
library path searching, though.
-Winston
On Thu, Jan 22, 2015 at 12:25 PM, Peter Haverty haverty.pe...@gene.com wrote:
Hi all,
Profiling turned up a bit of a speedbump in the library function. I
submitted a patch to the R bug tracker as bug 16168 and I've also
included it below. The alternate code is simpler and easier to
read/maintain, I believe. Any thoughts on other ways to write this?
Index: src/library/base/R/library.R
===
--- src/library/base/R/library.R(revision 67578)
+++ src/library/base/R/library.R(working copy)
@@ -688,18 +688,8 @@
out - character()
for(pkg in package) {
-paths - character()
-for(lib in lib.loc) {
-dirs - list.files(lib,
- pattern = paste0(^, pkg, $),
- full.names = TRUE)
-## Note that we cannot use tools::file_test() here, as
-## cyclic namespace dependencies are not supported. Argh.
-paths - c(paths,
- dirs[dir.exists(dirs)
-file.exists(file.path(dirs,
- DESCRIPTION))])
-}
+paths - file.path(lib.loc, pkg)
+paths - paths[ file.exists(file.path(paths, DESCRIPTION)) ]
if(use_loaded pkg %in% loadedNamespaces()) {
dir - if (pkg == base) system.file()
else getNamespaceInfo(pkg, path)
Pete
Peter M. Haverty, Ph.D.
Genentech, Inc.
phave...@gene.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
