Re: [Rd] New lazyload rdx key type: list(eagerKey=, lazyKeys=)
On 8/31/19 12:35 AM, William Dunlap via R-devel wrote: Prior to R-3.6.0 the keys in the lazyload key files, e.g. pkg/data/Rdata.rdx or pkg/R/pkg.rdx, seemed to all be 2-long integer vectors. Now they can be lists. The ones I have seen have two components, "eagerKey" is a 2-long integer vector and "lazyKeys" is a named list of 2-long integer vectors. rdx <- readRDS(system.file(package="survival", "data", "Rdata.rdx")) str(Filter(is.list, rdx$references)) List of 2 $ env::1:List of 2 ..$ eagerKey: int [1:2] 273691 183 ..$ lazyKeys:List of 1 .. ..$ lines: int [1:2] 273874 284 $ env::2:List of 2 ..$ eagerKey: int [1:2] 473142 166 ..$ lazyKeys:List of 1 .. ..$ lines: int [1:2] 473308 310 or rdx <- readRDS(system.file(package="lambda.r", "R", "lambda.r.rdx")) length(Filter(is.integer, rdx$references)) [1] 4 str(Filter(Negate(is.integer), rdx$references)) List of 5 $ env::5:List of 2 ..$ eagerKey: int [1:2] 28278 328 ..$ lazyKeys:List of 2 .. ..$ lines: int [1:2] 28606 80 .. ..$ parseData: int [1:2] 28686 389 $ env::6:List of 2 ..$ eagerKey: int [1:2] 29075 327 ..$ lazyKeys:List of 2 .. ..$ lines: int [1:2] 29402 71 .. ..$ parseData: int [1:2] 29473 321 $ env::7:List of 2 ..$ eagerKey: int [1:2] 29794 325 ..$ lazyKeys:List of 2 .. ..$ lines: int [1:2] 30119 117 .. ..$ parseData: int [1:2] 30236 752 ... many more ... All the ones I've seen involve the environment in srcref attributes and most packages do not keep that. Will these be used for more sorts of environments in the future? The new mechanism allows to load lazily selected bindings from an environment - previously only the bindings from the package/namespace environment were loaded lazily. The mechanism is currently used only for "lines" and "parseData" bindings of "srcfile" environments. Packages that include parse data will benefit from the latter and all packages that include source references will benefit from both. This change made it feasible to run package checks with source references enabled, so now one can get more useful error traces with execution time overhead reasonable for check runs. The format of the lazy loading database is specific to R release, it can change at any time. Specifically this mechanism could be used for more environments, but I am not aware of any that would benefit at the moment. What is the meaning of the lazyKeys? Are these stored as promises until needed or is there some special option to never or always load them? Bindings listed in lazyKeys are treated the same way as bindings in the package/namespace environment, so they become promises after loading the environment. Those promises load the individual objects for the bindings when forced (details in makeLazyLoad.R and lazyLoad.R and now also explicitly in R-ints). Best Tomas Bill Dunlap TIBCO Software wdunlap tibco.com [[alternative HTML version deleted]] __ 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
[Rd] rbind returns a zero row data frame when binding zero column data frames
Dear all, `rbind()` returns a zero row data frame when binding zero column data frames, see example below: ``` r # a data frame with 1 row and 0 column x <- data.frame(row.names=1) x #> data frame with 0 columns and 1 row rbind(x,x) #> data frame with 0 columns and 0 rows ``` I would have expected in that case `data frame with 0 columns and 2 rows`. `cbind()` on the other hand acts as I would expect, returning a 2 column data frame from 2 one column data frames even if they have no row. ``` r # a data frame with 0 row and 1 column y <- data.frame(A = numeric(0)) y #> [1] A #> <0 rows> (or 0-length row.names) cbind(y,y) #> [1] A A #> <0 rows> (or 0-length row.names) ``` [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ?Syntax wrong about `?`'s precedence ?
> From: William Dunlap [mailto:wdun...@tibco.com] > Precedence is a property of the parser and has nothing to do with the > semantics assigned to various symbols. Yes, but output depends on evaluation as well as precedence. Seeing different things wasn't an immediate surprise. Your own parse() examples are much clearer; thanks for that. S *** This email and any attachments are confidential. Any use, copying or disclosure other than by the intended recipient is unauthorised. If you have received this message in error, please notify the sender immediately via +44(0)20 8943 7000 or notify postmas...@lgcgroup.com and delete this message and any copies from your computer and network. LGC Limited. Registered in England 2991879. Registered office: Queens Road, Teddington, Middlesex, TW11 0LY, UK __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Feature request: non-dropping regmatches/strextract
I think that's a good reason for not including this in regmatches; you're right, its name is somewhat suggestive of yielding matches. Also, that sounds like a great design for strcapture with an atomic prototype. Best, CG __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Feature request: non-dropping regmatches/strextract
After some discussion within R core, we decided that a "nomatch" argument on regmatches() may be a good initial step. We might add a new function later that combines the regexpr() and regmatches() steps. The gregexpr() and regexec() inputs are both lists so it's not clear whether a "nomatch" value would be relevant (the elements are empty) in those cases. On Mon, Sep 2, 2019 at 11:38 AM Cyclic Group Z_1 wrote: > > I think that's a good reason for not including this in regmatches; you're > right, its name is somewhat suggestive of yielding matches. Also, that sounds > like a great design for strcapture with an atomic prototype. > > Best, > CG -- Michael Lawrence Scientist, Bioinformatics and Computational Biology Genentech, A Member of the Roche Group Office +1 (650) 225-7760 micha...@gene.com Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Feature request: non-dropping regmatches/strextract
That sounds great! Thank you for your consideration. Best, CG __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
