similar to: Retrieve an index of nested lists | Changing name delimiter in 'unlist()'

Dear list, I hope this is the right place to post a feature request. If there's exists a more formal channel (e.g. as for bug reports), I'd appreciate a pointer. I work a lot with named nested lists with arbitrary degrees of "nestedness". In order to retrieve the names and/or values of "bottom layer/bottom tier", I love the functionality of 'unlist()', or

Dear list, I came up with a two functions that flatten arbitrary deeply nested lists (as long as they're named; not tested for unnamed) and environments (see attachment; 'flatten_examples.txt' contains some examples). The paradigm is somewhat similar to that implemented in 'unlist()', yet extends it. I would have very much liked to build upon the superfast functionality

Dear list, I'm looking for a suitable way to sort of "one-line-pretty-print" an arbitrary R object in some of my log outputs. Consider this: cat(paste("The object/value is: ", x, ".", sep=""), sep="\n") No problem if x is of class: - character (length=1) - numeric (length=1) - logical (length=1) For lengths > 1 I can get

unlist(recursive=FALSE) returns NULL elements when passed a nested pairlist containing non-NULL data: x <- pairlist(pairlist(1:2)) unlist(x, recursive=FALSE) ## [[1]] ## NULL version 2.7.2 RC (2008-08-18 r46382) under linux I'm unaware of any motivation for constructing the above data structure, but if unlist is going to operate on it without error I would be surprised if that is the

Dear list, a while ago I posted this at r-devel but got no answers. Hope it?s okay to give it a shot again by cross-posting it here. TIA for any comments, Janko Von: Janko Thyson [mailto:janko.thyson.rstuff at googlemail.com] Gesendet: Montag, 21. Februar 2011 00:58 An: r-devel at r-project. org (r-devel at r-project.org) Betreff: Reference classes: error with missing arguments in method calls

I think I understand what you're saying now, but I'm still kind of missing the benefit from the approach. As far as I can tell just giving foo formals for the arguments you want it to catch gives you the end result you want, doesn't it? And if the generic has ... in it, you can (if you're very careful) add formals to specific methods that would capture arguments not meant for

Dear List, consider the following scenario: setClass(Class = "A", representation = representation(B = "B", C = "C")) setClass(Class = "B", representation = representation(C = "C")) setClass(Class = "C", representation = representation(something = "character")) Obviously, the collation for sourcing these defs needs to be: C,

Dear List, I'm trying to figure out some best practice way with respect to the naming conventions when building own packages. I'd like to minimize the risk of choosing function names that might interfere with those of other packages (both available ones and those yet to come). I came up with following alternatives 1. Prefixing the actual names (e.g. myPkgfoo() instead of foo()): pretty

Dear list, I'm a bit puzzled by an ambiguity with respect to the representation of micro-/milliseconds when using 'POSIXlt' objects. It seems that the last digit of the 'sec' attribute sometimes seems to differ from the digits shown when printing the 'POSIXlt' object. You'll find a little SO post with some example code here:

Well, the benefit lies in the ability to pass along arguments via `...` to more than one recipient that use *identical argument names* and/or when these recipients are not necessarily located on the same calling stack layer. I'm *not* after a *general* change in the way arguments are dispatched/functions are called as I'm actually a big friend of keepings things quite explicit (thus

Dear list, I came across a behavior that IMHO is somewhat undesired when calling '$field()': If the field name whose value you're trying to get is *not* a valid field of the Reference Class, then R doesn't stop there with an error, but scans through all enclosing environments/frames. The result is something similar to calling '|get(<objname>, inherits=TRUE)|'

Dear List, just out of pure curiosity: is it possible to define a function via 'substitute()' such that the function's formal arguments are specified by a "wildcard" that is substituted when the expression is evaluated? Simple example: x.args <- formals("data.frame") x.body <- expression( out <- myArg + 100, return(out) ) expr <-

Here is a description and a proposed solution for a bug in unlist(). I've used version 2.7.2 RC (2008-08-18 r46382) to look at this, under linux. unlist(recursive=TRUE) incorrectly returns a factor with zero levels when passed either a nested list of factors, or a data frame containing only factor columns. You can't print() the result. x <- list(list(v=factor("a")))

Janko, I'm not entirely sure I understand your proposal. Are you suggesting methods be dispatched based on the *contents* of ... (ie which arguments are in there)? This seems like it would be pretty different from how dispatch behaves now, which is entirely class based. Even the dispatching based on ... via dots methods is class based, having nothing to do AFAIK with the argument names. From

Hi Gabriel, and thanks for answering. I'm basically just trying to find a way to use the power of `...` in more complex scenarios and I'm well aware that this might not be the best approach ;-) Regarding your actual question: "Are you suggesting methods be dispatched based on the *contents* of ... [...]?" Yes, I guess currently I kind of do - but not on the argument *names*

Dear list, today I stumbled across the function ?nsl()? for the first time in order to perform a hostname lookup. According to the R Reference Index (Version 2.9.1, page 1522), the function should be part of the "utils" package. However, I cannot find it in the utils package of my installation(s). I've tried the R-versions 2.8.1, 2.9.0 and 2.9.1. I'd be very thankful if

Dear list, I was wondering if you could help me out in clarifying something: Is it possible to use class "ANY" in slots/fields of formal classes if you a) do not want to restrict valid classes of that field and b) if you are making explicit use of class inheritance? It seems to work in simple scenarios but produces errors when class inheritance comes into play. So I was

Dear list, I'm experimenting with setting up custom 'lib' and 'destdir' directories for my R packages. It seems to me that 'library()' does handle a custom 'lib.loc' argument the way it should for an arbitrary package but NOT for its dependencies on other packages. The latter are looked for in the default lib path (~/R/R-2.x.x/library) and NOT in the custom

Janko and I have been in touch. This is, I believe, a Windows specific issue and a compilation issue. I could be wrong, but that is my impression from other reports. When I have time (?! :-)), I will deal with it. Hopefully this will be very soon. Thanks Janko. D. On 12/14/14, 7:54 PM, Jeroen Ooms wrote: > On Thu, Dec 11, 2014 at 12:13 PM, Janko Thyson > <janko.thyson at gmail.com

It also does the same thing if the factor is not on the first level of the list, which seems to be due to the fact that the islistfactor is recursive, but if a list is a list-factor, the first level lists are coerced into character strings. > x <- list(list(factor(LETTERS[1]))) > unlist(x) Error in as.character.factor(x) : malformed factor However, if one of the factors is at the top