similar to: 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

>>>>> Winston Chang <winstonchang1 at gmail.com> >>>>> on Fri, 23 Jan 2015 10:15:53 -0600 writes: > I think you can simplify a little by replacing this: > pkg %in% loadedNamespaces() > with this: > .getNamespace(pkg) almost: It would be !is.null(.getNamespace(pkg)) > Whereas getNamespace(pkg) will load the

>>>>> Michael Lawrence <lawrence.michael at gene.com> >>>>> on Mon, 26 Jan 2015 05:12:55 -0800 writes: > A isNamespaceLoaded() function would be a useful thing to > have in general if we are interested in readable code. An > efficient implementation would be just a bonus. Good point (readability), and thank you for the support! Note

On Thu, Jan 22, 2015 at 11:44 AM, <luke-tierney at 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

Thanks Winston! I'm amazed that "[[" beats calling the .Internal directly. I guess the difference between .Primitive vs. .Internal is pretty significant for things on this time scale. NULL meaning NULL and NULL meaning undefined would lead to the same path for much of my code. I'll be swapping out many exists and get calls later today. Thanks! I do still think it would be

In the documentation the closed thing I see to an explanation of this is that ?detach says "Unloading some namespaces has undesirable side effects" Can anyone explain why unloading tseries will load zoo? I don't think this behavior is specific to tseries, it's just an example. I realize one would not usually unload something that is not loaded, but I would expect it to do

A isNamespaceLoaded() function would be a useful thing to have in general if we are interested in readable code. An efficient implementation would be just a bonus. On Mon, Jan 26, 2015 at 3:36 AM, Martin Maechler <maechler at lynne.stat.math.ethz.ch> wrote: >>>>>> Winston Chang <winstonchang1 at gmail.com> >>>>>> on Fri, 23 Jan 2015 10:15:53

isLoadedNamespace() sounds fine to me.. Thanks for addressing this, Michael On Mon, Jan 26, 2015 at 5:51 AM, Martin Maechler < maechler at lynne.stat.math.ethz.ch> wrote: > >>>>> Michael Lawrence <lawrence.michael at gene.com> > >>>>> on Mon, 26 Jan 2015 05:12:55 -0800 writes: > > > A isNamespaceLoaded() function would be a useful

Hi All, I've been looking into speeding up the loading of packages that use a lot of S4. After profiling I noticed the "exists" function accounts for a surprising fraction of the time. I have some thoughts about speeding up exists (below). More to the point of this post, Martin M?chler noted that 'exists' and 'get' are often used in conjunction. Both functions are

Doing it like this: genericForPrimitive <- function(f, where = topenv(parent.frame()), mustFind = TRUE) { ans = .BasicFunsList[[f]] ## this element may not exist (yet, during loading), dom't test null if(mustFind && identical(ans, FALSE)) stop(gettextf("methods may not be defined for primitive function %s in this version of R",

I think ls(, sort=FALSE) would be more explicit and thus clearer. There is much precedent for having arguments that request less work to be done e.g. unlist(use.names=FALSE). Yes, the extra typing is a bit painful, but there is no intuitive reason why names() would be unsorted, while ls() would be sorted. While it is tempting to use an existing function for this, the word "names" is

Since the contract of ls() is to sort, there is nothing wrong with programmers depending on it. And there are many functions that could be made 60X faster, but is it worth it? But I did notice that as.list.environment has a sorted=FALSE argument already, so I guess identical(names(x), names(as.list(x))) could be made to be TRUE, assuming the order is at least persistent, if undefined, so that is a

How about unique them both and compare the lengths? It's less work, especially allocation. Pete ____________________ Peter M. Haverty, Ph.D. Genentech, Inc. phaverty at gene.com On Thu, Jan 8, 2015 at 1:30 PM, peter dalgaard <pdalgd at gmail.com> wrote: > If you look at the definition of %in%, you'll find that it is implemented > using match, so if we did as you suggest,

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

Hi all, The function call series genericForPrimitive -> .findBasicFuns -> .findAll happens 4400 times while the GenomicRanges package is loading. Each time .findAll follows a chain of environments to determine that the methods namespace is the only one that holds a variable called .BasicFunsList. This accounts for ~10% of package loading time. I'm sure there is some history to that

Hi all, The "ls" function wears two hats. It allows users to inspect an environment interactively and also serves deeper in code as the accessor for an environment's names/keys. I propose that we separate these two conflicting goals, keeping ls for interactive use and adding names for a quick listing of the hash keys. This involves adding two lines to do_names in attrib.c. The

On Thu, Jan 22, 2015 at 11:44 AM, <luke-tierney at 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

>>>>> Martin Maechler <maechler at stat.math.ethz.ch> >>>>> on Fri, 9 Jan 2015 14:00:38 +0100 writes: >>>>> Michael Lawrence <lawrence.michael at gene.com> >>>>> on Thu, 8 Jan 2015 14:02:26 -0800 writes: >> On Thu, Jan 8, 2015 at 11:57 AM, <luke-tierney at uiowa.edu> wrote: >>> On Thu, 8

Hi, On 01/23/2015 07:01 AM, luke-tierney at uiowa.edu wrote: > On Thu, 22 Jan 2015, Michael Lawrence wrote: > >> On Thu, Jan 22, 2015 at 11:44 AM, <luke-tierney at 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 >>>

Thanks for all your great answers. The app I?m working on is indeed an exploratory data analysis tool for gene expression, which requires a bunch of bioconductor packages. I guess for now, my best solution is to divide my app into modules and load/unload packages as the user switch from one module to another. This brought me another question: it seems that unload package with the