Re: [Rd] Feature request: non-dropping regmatches/strextract

2019-09-02 Thread Cyclic Group Z_1 via R-devel
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


Re: [Rd] Feature request: non-dropping regmatches/strextract

2019-09-02 Thread Michael Lawrence via R-devel
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

2019-09-02 Thread Cyclic Group Z_1 via R-devel
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] ?Syntax wrong about `?`'s precedence ?

2019-09-02 Thread Stephen Ellison
> 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


[Bioc-devel] Build error due to TensorFlow installation

2019-09-02 Thread Simon Dirmeier
Dear all,

since I replaced some old C++ code with TensorFlow I am getting some
build errors on merida1 and tokay1 regarding installation (even though I
install TF and TF Probability during /.onLoad/)

http://bioconductor.org/checkResults/devel/bioc-LATEST/netReg/merida1-buildsrc.html

Does anyone know how I can fix this or did anyone use TF with
Bioconductor so far?

Many thanks in advance.

Best,

Simon





[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


[Rd] rbind returns a zero row data frame when binding zero column data frames

2019-09-02 Thread Ant F
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: [R-pkg-devel] URL of a frame (or a vignette)?

2019-09-02 Thread Georgi Boshnakov
I personally would not link to rdocumentation. They update packages rather 
erratically and the information can be months or even years old, without any 
indication. The drop down list "Other versions" at the top of the package page 
is a misnomer, it should be "Older versions".

My main objection though is that, in my opinion, they blatantly disrespect the 
GPL license. Their pages are like a trap, with all their links 
pointing back to their site. They do not put even a link to CRAN, the place 
where they take the files from. Even the authors' names are linked them! The 
only way to ensure a prominent link to CRAN is to have a badge or link at the 
top of the README file, which they show. This is one of the reasons a put a 
CRAN badge at the top of my README file, even though it looks strange on CRAN. 

I alerted them about this a couple of years ago in their 'Comments' area but 
they did not respond. 


Georgi Boshnakov
 

-Original Message-
From: Spencer Graves [mailto:spencer.gra...@effectivedefense.org] 
Sent: 01 September 2019 20:19
To: Duncan Murdoch; Georgi Boshnakov; Jeff Newmiller; 
r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] URL of a frame (or a vignette)?

   I just learned that finding the package on "rdocumentation.org", 
then clicking on the vignette I want at the end of the page, "bssm.Rmd", 
gave me a URL that is portable, at least for the moment:


https://www.rdocumentation.org/packages/bssm/versions/0.1.7/vignettes/bssm.Rmd


   This seems less likely to be trapped by CRAN checks unless it 
actually stops working ;-)


   Thanks to all who replied to my question.
   Spencer


On 2019-09-01 10:49, Duncan Murdoch wrote:
> On 01/09/2019 11:33 a.m., Spencer Graves wrote:
>>     What's the difference between
>>
>>
>> https://cran.r-project.org/package=bssm/vignettes/bssm.pdf
>>
>>
>>     and
>>
>>
>> https://cran.r-project.org/web/packages/bssm/vignettes/bssm.pdf
>>
>>
>>     When I tried the former, it automatically changed to the latter.
>> Is the former considered to be more stable?
>
> CRAN puts this on every package page:
>
> "Please use the canonical form https://CRAN.R-project.org/package= 
> to link to this page."
>
> I think one of the checks will complain if it notices you give the 
> link in a different form.  I forget which URLs it checks.
>
> Duncan Murdoch
>

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


Re: [Rd] New lazyload rdx key type: list(eagerKey=, lazyKeys=)

2019-09-02 Thread Tomas Kalibera

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