Re: [Bioc-devel] banocc: Bioconductor BUILD error

[George Weingart]

Hello Lori,

Done !

I removed the two references to c++11 from the package,  ran a BUILD and a
CHECK and they were clean.
Pushed the changes.

Below,  the log of the push.

Let me know what you find in the BiocCheck space pertaining the Sweave
error.

Thank you !
Best regards,
George Weingart PhD
Huttenhower Lab
Harvard School of Public Health

LOG OF PUSH

Tanias-MacBook-Air:Harvard georgeweingart$ cd banocc

Tanias-MacBook-Air:banocc georgeweingart$ git status

On branch master

Your branch is up to date with 'origin/master'.

Changes not staged for commit:

  (use "git add ..." to update what will be committed)

  (use "git checkout -- ..." to discard changes in working directory)

modified:   DESCRIPTION

modified:   vignettes/banocc-vignette.Rmd

no changes added to commit (use "git add" and/or "git commit -a")

Tanias-MacBook-Air:banocc georgeweingart$ git add DESCRIPTION

Tanias-MacBook-Air:banocc georgeweingart$ git add
vignettes/banocc-vignette.Rmd

Tanias-MacBook-Air:banocc georgeweingart$ git status

On branch master

Your branch is up to date with 'origin/master'.

Changes to be committed:

  (use "git reset HEAD ..." to unstage)

modified:   DESCRIPTION

modified:   vignettes/banocc-vignette.Rmd

Tanias-MacBook-Air:banocc georgeweingart$ git commit -m "Removed c++11
references that are making BUILD fail in R3.6.0"

[master d145287] Removed c++11 references that are making BUILD fail in
R3.6.0

 2 files changed, 2 insertions(+), 4 deletions(-)

Tanias-MacBook-Air:banocc georgeweingart$ git push

Enumerating objects: 9, done.

Counting objects: 100% (9/9), done.

Delta compression using up to 4 threads

Compressing objects: 100% (5/5), done.

Writing objects: 100% (5/5), 481 bytes | 481.00 KiB/s, done.

Total 5 (delta 4), reused 0 (delta 0)

To git.bioconductor.org:packages/banocc

   5aefed9..d145287  master -> master


On Mon, Jul 15, 2019 at 11:35 AM George Weingart 
wrote:

> Thanks Lori!
>
> Will do.
>
> Let me know about BiocCheck.
>
> Thanks!
> George Weingart
>
> On Mon, Jul 15, 2019 at 10:26 AM Shepherd, Lori <
> lori.sheph...@roswellpark.org> wrote:
>
>> I can look into the BiocCheck ERROR for future development. It would be
>> good to figure out why this is happening.  But in the meantime,  if your
>> solution passes R CMD build and R CMD check please continue with pushing to
>> the git.bioconductor.org server  as BiocCheck is not run on the nightly
>> builds.
>>
>>
>> Cheers,
>>
>>
>> Lori Shepherd
>>
>> Bioconductor Core Team
>>
>> Roswell Park Cancer Institute
>>
>> Department of Biostatistics & Bioinformatics
>>
>> Elm & Carlton Streets
>>
>> Buffalo, New York 14263
>> --
>> *From:* George Weingart 
>> *Sent:* Monday, July 15, 2019 1:03:28 PM
>> *To:* st...@channing.harvard.edu; Shepherd, Lori
>> *Cc:* Bioc-devel; Lauren McIver; Huttenhower, Curtis; Eric Franzosa
>> *Subject:* banocc: Bioconductor BUILD error
>>
>>
>> Hello Lori and Vincent,
>>
>> I am looking at the Bioconductor problem building banocc.
>>
>> Can I trouble you to look into that?
>>
>> If you cannot figure it out,   can you advise me what would be the
>> correct forum / helpdesk to request assistance to resolve the issue?
>>
>> I am posting the following logs:
>>
>>1.
>>
>>Failed Build
>>2.
>>
>>Successful BUILD after removing c++11 references
>>3.
>>
>>Successful R CMD CHECK
>>4.
>>
>>Failed BiocCheck
>>
>>
>> Thank you!
>>
>> George Weingart PhD
>>
>> Huttenhower Lab
>>
>> Harvard School of Public Health
>>
>>
>> Summary of the problem:
>>
>>1.
>>
>>Banocc has been in Bioconductor for a while
>>2.
>>
>>Around April this year we started getting messages that the Build was
>>failing
>>3.
>>
>>We have not changed anything in banocc
>>4.
>>
>>Build succeeds in R3.5.1
>>5.
>>
>>Recreated the problem on my Mac - Build fails in R3.6.0 with the
>>following message:
>>
>> Error: processing vignette 'banocc-vignette.Rmd' failed with diagnostics:
>>
>> invalid connection
>>
>> --- failed re-building ‘banocc-vignette.Rmd’
>>
>>1.
>>
>>Solved the Build problem by removing 2 references to c++11
>>
>> Removed from DESCRIPTION:
>>
>> SystemRequirements: C++11
>>
>> Removed from vignettes/banocc-vignette.Rmd:
>>
>> Sys.setenv("PKG_CXXFLAGS"="-std=c++11")
>>
>>
>>1.
>>
>>R CMD CHECK works fine
>>2.
>>
>>BiocCheck fails with a message about SweaveParseOptions
>>
>>
>> * Checking coding practice...
>>
>> * NOTE: Avoid 1:...; use seq_len() or seq_along()
>>
>>   Found in files:
>>
>> stan-output-make_samples_list.R (line 59, column 51)
>>
>> Error in SweaveParseOptions(chunkopts, drobj$options, driver$checkopts) :
>>
>>   parse error or empty option in
>>
>> fit-model, cache=TRUE, dependson=c('compile-stan-model',
>> 'generate-data'), echo=FALSE
>>
>>
>>1.
>>
>>I don’t understand why are we getting a Sweave error under BiocCheck
>>as we are using knitr and could not find a 

Re: [Rd] [External] Potential bug with data.frame replacement

[Tierney, Luke]

Thanks for the report. The buffer overflow should be fixed in
R-patched and R-devel.

Best,

luke

On Sun, 14 Jul 2019, Benjamin Jean-Marie Tremblay wrote:

> Dear R-devel,
>
> I have encountered a crash-inducing scenario and would like to enquire as to
> whether this would be considered a bug. To reproduce the crash:
>
> X <- sample(letters, 3000, TRUE)
> D <- data.frame(X, 1:3000, X, X, X, X, X)
> D$X1.3000 <- paste0("GSM", D)
>
> The reason why I'm not sure if this would be considered a bug is because I
> typed this by accident, when what I meant was:
>
> D$X1.3000 <- paste0("GSM", D$X1.3000)
>
> I can never image a scenario where I would intentionally perform the former.
>
> This issue seems to have something to do with the size of the data.frame, as
> smaller examples will work fine:
>
> D <- data.frame(A = 1:10, B = letters[1:10])
> D$A <- paste0("A", D)
>
> Also just doing the paste0 part without trying to replace a data.frame column
> not crash R for me.
>
> I can submit this on Bugzilla should this be deemed sufficiently buggy.
>
> I am running 3.6.0 on macOS (x86_64-apple-darwin15.6.0).
>
> Sincerely,
>
> B.T.
>
> __
> 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] Convert STRSXP or INTSXP to factor

[Gabriel Becker]

Hi Morgan,

So if the goal  is output  identical to  calling factor, one thing youc an
do is construct  and evaluate a call to the R-level factor function. That
would work and  be guaranteed to meet your  requirement.

The factor function is implemented with R code,  without even any direct
calls down to C code, so there isn't any C level functionality already
there that you could try to hit directly.

If you really really needed to write it using only C (and not hitting the R
evaluator), I suppose you could. You'd need to do the following, I think:


   1. Loop through the values to determine the array of levels vector,
   equivalent to a call to unique(x) at the R level. I don't know if there
   are any public API functions that will do this for you, a quick grep
   through the header files  suggests there are not.
   2. Allocate the ouptut INTSXP and determine the underlying integer value
   for each factor element.  Equivalent to a match(x,  levels) in R (x has
   already been converted to character at this point in the R function).
   Getting this to be performant would probably be annoying but is doable
   (e.g., via a hash table or some such)
   3. Do classgets on the the output vector to make it a factor (this will
   set the object bit so you don't need to do that separate)
   4. do setAttrib on the output vector to set the levels attribute (which
   now needs to be  a STRSXP  rather than, e.g., an array of  const char*)
   5. Return the output vector

Personally, unless there was a really compelling reason not to, I'd just do
the  create and evaluate an R-level call thing instead.

Best,
~G




On Mon, Jul 15, 2019 at 3:25 AM Morgan Morgan 
wrote:

> Hi,
>
> Using the R C PAI, is there a way to convert to convert STRSXP or INTSXP to
> factor.
>
> The idea would be to do in C something similar to the "factor" function
> (example below):
>
> > letters[1:5]
> # [1] "a" "b" "c" "d" "e"
>
> > factor(letters[1:5])
> # [1] a b c d e
> # Levels: a b c d e
>
> There is the function setAttrib the levels of a SXP however when returned
> to R the object is of type character not factor. Ideally what i would like
> to return from the C function is the same output as above when the input is
> of type character.
>
> Please let me if you need more informations.
> Thank you
> Best regards
> Morgan
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

[Bioc-devel] Bioconductor Technical Advisory Board nominations

[Martin Morgan]

Nominations for the [Bioconductor Technical Advisory][1] Board are now open.

Nominate candidates, including yourself, by completing this [short form][2].

Questions? Visit the #tech-advisory-board slack channel (sign up for the 
[community-bioc slack][3]).


  [1]: https://support.bioconductor.org/p/121130/
  [2]: https://forms.gle/zTZLZJQrHL4ZGEGq9
  [3]: https://bioc-community.herokuapp.com/

Martin Morgan
Bioconductor

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

Re: [Bioc-devel] banocc: Bioconductor BUILD error

[George Weingart]

Thanks Lori!

Will do.

Let me know about BiocCheck.

Thanks!
George Weingart

On Mon, Jul 15, 2019 at 10:26 AM Shepherd, Lori <
lori.sheph...@roswellpark.org> wrote:

> I can look into the BiocCheck ERROR for future development. It would be
> good to figure out why this is happening.  But in the meantime,  if your
> solution passes R CMD build and R CMD check please continue with pushing to
> the git.bioconductor.org server  as BiocCheck is not run on the nightly
> builds.
>
>
> Cheers,
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Cancer Institute
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
> --
> *From:* George Weingart 
> *Sent:* Monday, July 15, 2019 1:03:28 PM
> *To:* st...@channing.harvard.edu; Shepherd, Lori
> *Cc:* Bioc-devel; Lauren McIver; Huttenhower, Curtis; Eric Franzosa
> *Subject:* banocc: Bioconductor BUILD error
>
>
> Hello Lori and Vincent,
>
> I am looking at the Bioconductor problem building banocc.
>
> Can I trouble you to look into that?
>
> If you cannot figure it out,   can you advise me what would be the correct
> forum / helpdesk to request assistance to resolve the issue?
>
> I am posting the following logs:
>
>1.
>
>Failed Build
>2.
>
>Successful BUILD after removing c++11 references
>3.
>
>Successful R CMD CHECK
>4.
>
>Failed BiocCheck
>
>
> Thank you!
>
> George Weingart PhD
>
> Huttenhower Lab
>
> Harvard School of Public Health
>
>
> Summary of the problem:
>
>1.
>
>Banocc has been in Bioconductor for a while
>2.
>
>Around April this year we started getting messages that the Build was
>failing
>3.
>
>We have not changed anything in banocc
>4.
>
>Build succeeds in R3.5.1
>5.
>
>Recreated the problem on my Mac - Build fails in R3.6.0 with the
>following message:
>
> Error: processing vignette 'banocc-vignette.Rmd' failed with diagnostics:
>
> invalid connection
>
> --- failed re-building ‘banocc-vignette.Rmd’
>
>1.
>
>Solved the Build problem by removing 2 references to c++11
>
> Removed from DESCRIPTION:
>
> SystemRequirements: C++11
>
> Removed from vignettes/banocc-vignette.Rmd:
>
> Sys.setenv("PKG_CXXFLAGS"="-std=c++11")
>
>
>1.
>
>R CMD CHECK works fine
>2.
>
>BiocCheck fails with a message about SweaveParseOptions
>
>
> * Checking coding practice...
>
> * NOTE: Avoid 1:...; use seq_len() or seq_along()
>
>   Found in files:
>
> stan-output-make_samples_list.R (line 59, column 51)
>
> Error in SweaveParseOptions(chunkopts, drobj$options, driver$checkopts) :
>
>   parse error or empty option in
>
> fit-model, cache=TRUE, dependson=c('compile-stan-model', 'generate-data'),
> echo=FALSE
>
>
>1.
>
>I don’t understand why are we getting a Sweave error under BiocCheck
>as we are using knitr and could not find a good reference for the rror.
>
>
>
> Log #1: Recreation of error: Failed BUILD in R3.6.0
>
> $ R CMD BUILD banocc
>
> * checking for file ‘banocc/DESCRIPTION’ ... OK
>
> * preparing ‘banocc’:
>
> * checking DESCRIPTION meta-information ... OK
>
> * installing the package to build vignettes
>
> * creating vignettes ... ERROR
>
> --- re-building ‘banocc-vignette.Rmd’ using rmarkdown
>
> Quitting from lines 138-143 (banocc-vignette.Rmd)
>
> Quitting from lines 138-143 (banocc-vignette.Rmd)
>
> Error: processing vignette 'banocc-vignette.Rmd' failed with diagnostics:
>
> invalid connection
>
> --- failed re-building ‘banocc-vignette.Rmd’
>
> SUMMARY: processing the following file failed:
>
>   ‘banocc-vignette.Rmd’
>
> Error: Vignette re-building failed.
>
> Execution halted
>
>
> Log #2: Successful build after removing references to c++11
>
> Removed from DESCRIPTION:
>
> SystemRequirements: C++11
>
> Removed from vignettes/banocc-vignette.Rmd:
>
> Sys.setenv("PKG_CXXFLAGS"="-std=c++11")
>
>
> Tanias-MacBook-Air:Harvard georgeweingart$ R CMD BUILD banocc
>
> * checking for file ‘banocc/DESCRIPTION’ ... OK
>
> * preparing ‘banocc’:
>
> * checking DESCRIPTION meta-information ... OK
>
> * installing the package to build vignettes
>
> * creating vignettes ... OK
>
> Warning: ‘inst/doc’ files
>
> ‘banocc-vignette.Rmd’, ‘banocc-vignette.html’, ‘banocc-vignette.R’
>
>   ignored as vignettes have been rebuilt.
>
>   Run R CMD build with --no-build-vignettes to prevent rebuilding.
>
> * checking for LF line-endings in source and make files and shell scripts
>
> * checking for empty or unneeded directories
>
> * looking to see if a ‘data/datalist’ file should be added
>
> * building ‘banocc_1.8.0.tar.gz’
>
> Log #3 Successful R CMD CHECK
>
> Tanias-MacBook-Air:Harvard georgeweingart$ R CMD BUILD banocc
>
> * checking for file ‘banocc/DESCRIPTION’ ... OK
>
> * preparing ‘banocc’:
>
> * checking DESCRIPTION meta-information ... OK
>
> * installing the package to build vignettes
>
> * creating vignettes ... OK
>
> Warning: ‘inst/doc’ files
>
> 

Re: [Rd] GitHub passwords in .git/config?

[Spencer Graves]

Thanks, Marcel:


  That did it.


  My next challenge is to replicate it on a Windows 10 machine.


  Spencer


On 2019-07-15 12:54, Marcel Ramos wrote:

Hi Spencer,

The first line in the `[remote "origin"]` section should read:

```

url = 
g...@github.com:sbgraves237/Ecdat.git

```

Generally, I add these configs by doing a clone on the command line such as:


git clone 
g...@github.com:sbgraves237/Ecdat.git

so that I don't have to mess with the config file.


Best,

Marcel

On 7/15/19 1:48 PM, Spencer Graves wrote:
I'm diverging:  Now I get:



git pull

ssh: Could not resolve hostname github.com:sbgraves237: nodename nor servname 
provided, or not known
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


   ** With .git/config as follows:


[core]
 repositoryformatversion = 0
 filemode = true
 bare = false
 logallrefupdates = true
 ignorecase = true
 precomposeunicode = true
[remote "origin"]
 url = 
ssh://g...@github.com:sbgraves237/Ecdat.git
 fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
 remote = origin
 merge = refs/heads/master


   I have an SSH key on my GitHub account, which says it was "Added on Jul 3, 
2019 Last used within the last 2 weeks — Read/write".


   Should I delete my current local copies and clone them fresh from GitHub?
   Spencer


On 2019-07-15 12:01, Brian G. Peterson wrote:
it would be:

ssh://g...@github.com:sbgraves237/Ecdat.git


On Mon, 2019-07-15 at 11:41 -0500, Spencer Graves wrote:
On 2019-07-15 10:56, Dirk Eddelbuettel wrote:



Don't write passwords down like this. Your error is likely in
expecting _ssh_
authentication over _https_ -- when it works only over ssh. Use the
alternate
form for a remote e.g. one that looks like 
g...@github.com:emacs-
ess/ESS.git
 I'm confused.  I changed that line to:


   url =
https://g...@github.com:sbgraves237/sbgraves237/Ecdat


 Then when I did "git pull" I got:


fatal: unable to access
'https://g...@github.com:sbgraves237/sbgraves237/Ecdat/':
 Port number
ended with 's'


 ???
 Thanks,
 Spencer

Hth, Dirk

__
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


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[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

Re: [Rd] GitHub passwords in .git/config?

[Marcel Ramos]

Hi Spencer,

The first line in the `[remote "origin"]` section should read:

```

url = 
g...@github.com:sbgraves237/Ecdat.git

```

Generally, I add these configs by doing a clone on the command line such as:

> git clone 
> g...@github.com:sbgraves237/Ecdat.git

so that I don't have to mess with the config file.


Best,

Marcel

On 7/15/19 1:48 PM, Spencer Graves wrote:
I'm diverging:  Now I get:


>>> git pull
ssh: Could not resolve hostname github.com:sbgraves237: nodename nor servname 
provided, or not known
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


  ** With .git/config as follows:


[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
precomposeunicode = true
[remote "origin"]
url = 
ssh://g...@github.com:sbgraves237/Ecdat.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master


  I have an SSH key on my GitHub account, which says it was "Added on Jul 
3, 2019 Last used within the last 2 weeks — Read/write".


  Should I delete my current local copies and clone them fresh from GitHub?
  Spencer


On 2019-07-15 12:01, Brian G. Peterson wrote:
it would be:

ssh://g...@github.com:sbgraves237/Ecdat.git


On Mon, 2019-07-15 at 11:41 -0500, Spencer Graves wrote:
On 2019-07-15 10:56, Dirk Eddelbuettel wrote:



Don't write passwords down like this. Your error is likely in
expecting _ssh_
authentication over _https_ -- when it works only over ssh. Use the
alternate
form for a remote e.g. one that looks like 
g...@github.com:emacs-
ess/ESS.git
I'm confused.  I changed that line to:


  url =
https://g...@github.com:sbgraves237/sbgraves237/Ecdat


Then when I did "git pull" I got:


fatal: unable to access
'https://g...@github.com:sbgraves237/sbgraves237/Ecdat/':
 Port number
ended with 's'


???
Thanks,
Spencer

Hth, Dirk

__
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


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

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

Re: [Rd] GitHub passwords in .git/config?

[Spencer Graves]

I'm diverging:  Now I get:


>>> git pull
ssh: Could not resolve hostname github.com:sbgraves237: nodename nor 
servname provided, or not known

fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


  ** With .git/config as follows:


[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
    precomposeunicode = true
[remote "origin"]
    url = ssh://g...@github.com:sbgraves237/Ecdat.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
    remote = origin
    merge = refs/heads/master


  I have an SSH key on my GitHub account, which says it was "Added 
on Jul 3, 2019 Last used within the last 2 weeks — Read/write".



  Should I delete my current local copies and clone them fresh from 
GitHub?

  Spencer


On 2019-07-15 12:01, Brian G. Peterson wrote:

it would be:

ssh://g...@github.com:sbgraves237/Ecdat.git


On Mon, 2019-07-15 at 11:41 -0500, Spencer Graves wrote:

On 2019-07-15 10:56, Dirk Eddelbuettel wrote:




Don't write passwords down like this. Your error is likely in
expecting _ssh_
authentication over _https_ -- when it works only over ssh. Use the
alternate
form for a remote e.g. one that looks like g...@github.com:emacs-
ess/ESS.git

I'm confused.  I changed that line to:


  url =
https://g...@github.com:sbgraves237/sbgraves237/Ecdat


Then when I did "git pull" I got:


fatal: unable to access
'https://g...@github.com:sbgraves237/sbgraves237/Ecdat/': Port number
ended with 's'


???
Thanks,
Spencer


Hth, Dirk


__
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] Potential bug with data.frame replacement

[Iñaki Ucar]

On Mon, 15 Jul 2019 at 18:55, William Dunlap via R-devel
 wrote:
>
> This may be related to the size of the deparsed call in the error message
> that Brodie and Luke were discussing recently on R-devel (" Mitigating
> Stalls Caused by Call Deparse on Error").   I don't get a crash, but the
> error message itself doesn't show up after the deparsed call.

The example crashes with a buffer overflow in systems with
FORTIFY_SOURCE=2 (i.e., official R package in most Linux
distributions).

Iñaki

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

Re: [Rd] Unexpected behaviour when comparing (==) long quoted expressions

[Clark Fitzgerald]

Hi Dan,

I wouldn't expect that behavior out of `==` on language objects either.

On a related note, working with R's language objects directly can be
clumsy. That was one of the motivations for Nick Ulle to develop the
rstatic package. https://github.com/nick-ulle/rstatic It lets me write code
that's easier to read and reason about, compared to using the standard
language objects. It behaves as you hoped here:

> s <-
quote(f(x123456789012345678901234567890123456789012345678901234567890, 1))
> u <-
quote(f(x123456789012345678901234567890123456789012345678901234567890, 2))
> s == u
[1] TRUE
> s1 = rstatic::to_ast(s)
> u1 = rstatic::to_ast(u)
> s1 == u1
[1] FALSE

Best,
Clark

On Mon, Jul 15, 2019 at 3:25 AM Daniel Chen  wrote:

> Hi everyone:
>
> I’m one of the interns at RStudio this summer working on a project that
> helps teachers grade student code. I found an unexpected behaviour with
> the |==| operator when comparing |quote|d expressions.
>
> Example 1:
>
> |u <- quote(tidyr::gather(key = key, value = value,
> new_sp_m014:newrel_f65, na.rm = TRUE)) s <- quote(tidyr::gather(key =
> key, value = value, new_sp_m014:newrel_f65, na.rm = FALSE)) u == s #
> TRUE u <- quote(tidyr::gather(key = key, value = value, na.rm = TRUE)) s
> <- quote(tidyr::gather(key = key, value = value, na.rm = FALSE)) u == s
> # FALSE |
>
> Example 2:
>
> |u <-
> quote(f(x123456789012345678901234567890123456789012345678901234567890,
> 1)) s <-
> quote(f(x123456789012345678901234567890123456789012345678901234567890,
> 2)) u == s #> [1] TRUE |
>
> Winston Chang pointed out in the help page for |==|:
>
> Language objects such as symbols and calls are deparsed to character
> strings before comparison.
>
> and in the source code that does the comparison [1] shows that It
> deparses each language object and then only extracts the first element
> from the resulting character vector:
>
> |SET_STRING_ELT(tmp, 0, (iS) ? PRINTNAME(x) : STRING_ELT(deparse1(x, 0,
> DEFAULTDEPARSE), 0)); |
>
> Is this a fix that needs to happen within the |==| documentation? or an
> actual bug with the operator?
>
> For more context the original issue we had is here:
> https://github.com/rstudio-education/grader/issues/28
>
> Workaround:
>
> You can get around this issue by using |all.equal| or |identical|
>
> |u <- quote(tidyr::gather(key = key, value = value,
> new_sp_m014:newrel_f65, na.rm = TRUE)) s <- quote(tidyr::gather(key =
> key, value = value, new_sp_m014:newrel_f65, na.rm = FALSE)) u == s #
> TRUE all.equal(u, s) # "target, current do not match when deparsed"
> identical(u, s) # FALSE |
>
> Thanks,
>
> Dan
>
> [1]
>
> https://github.com/wch/r-source/blob/e647f78cb85282263f88ea30c6337b77a30743d9/src/main/relop.c#L140-L155
>
> ​
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] banocc: Bioconductor BUILD error

[Shepherd, Lori]

I can look into the BiocCheck ERROR for future development. It would be good to 
figure out why this is happening.  But in the meantime,  if your solution 
passes R CMD build and R CMD check please continue with pushing to the 
git.bioconductor.org server  as BiocCheck is not run on the nightly builds.


Cheers,


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: George Weingart 
Sent: Monday, July 15, 2019 1:03:28 PM
To: st...@channing.harvard.edu; Shepherd, Lori
Cc: Bioc-devel; Lauren McIver; Huttenhower, Curtis; Eric Franzosa
Subject: banocc: Bioconductor BUILD error


Hello Lori and Vincent,


I am looking at the Bioconductor problem building banocc.


Can I trouble you to look into that?

If you cannot figure it out,   can you advise me what would be the correct 
forum / helpdesk to request assistance to resolve the issue?


I am posting the following logs:

  1.  Failed Build

  2.  Successful BUILD after removing c++11 references

  3.  Successful R CMD CHECK

  4.  Failed BiocCheck


Thank you!


George Weingart PhD

Huttenhower Lab

Harvard School of Public Health


Summary of the problem:


  1.  Banocc has been in Bioconductor for a while

  2.  Around April this year we started getting messages that the Build was 
failing

  3.  We have not changed anything in banocc

  4.  Build succeeds in R3.5.1

  5.  Recreated the problem on my Mac - Build fails in R3.6.0 with the 
following message:

Error: processing vignette 'banocc-vignette.Rmd' failed with diagnostics:

invalid connection

--- failed re-building �banocc-vignette.Rmd�

  1.  Solved the Build problem by removing 2 references to c++11

Removed from DESCRIPTION:

SystemRequirements: C++11

Removed from vignettes/banocc-vignette.Rmd:

Sys.setenv("PKG_CXXFLAGS"="-std=c++11")


  1.  R CMD CHECK works fine

  2.  BiocCheck fails with a message about SweaveParseOptions


* Checking coding practice...

* NOTE: Avoid 1:...; use seq_len() or seq_along()

  Found in files:

stan-output-make_samples_list.R (line 59, column 51)

Error in SweaveParseOptions(chunkopts, drobj$options, driver$checkopts) :

  parse error or empty option in

fit-model, cache=TRUE, dependson=c('compile-stan-model', 'generate-data'), 
echo=FALSE


  1.  I don�t understand why are we getting a Sweave error under BiocCheck  as 
we are using knitr and could not find a good reference for the rror.


Log #1: Recreation of error: Failed BUILD in R3.6.0


$ R CMD BUILD banocc

* checking for file �banocc/DESCRIPTION� ... OK

* preparing �banocc�:

* checking DESCRIPTION meta-information ... OK

* installing the package to build vignettes

* creating vignettes ... ERROR

--- re-building �banocc-vignette.Rmd� using rmarkdown

Quitting from lines 138-143 (banocc-vignette.Rmd)

Quitting from lines 138-143 (banocc-vignette.Rmd)

Error: processing vignette 'banocc-vignette.Rmd' failed with diagnostics:

invalid connection

--- failed re-building �banocc-vignette.Rmd�


SUMMARY: processing the following file failed:

  �banocc-vignette.Rmd�


Error: Vignette re-building failed.

Execution halted


Log #2: Successful build after removing references to c++11


Removed from DESCRIPTION:

SystemRequirements: C++11

Removed from vignettes/banocc-vignette.Rmd:

Sys.setenv("PKG_CXXFLAGS"="-std=c++11")



Tanias-MacBook-Air:Harvard georgeweingart$ R CMD BUILD banocc

* checking for file �banocc/DESCRIPTION� ... OK

* preparing �banocc�:

* checking DESCRIPTION meta-information ... OK

* installing the package to build vignettes

* creating vignettes ... OK

Warning: �inst/doc� files

�banocc-vignette.Rmd�, �banocc-vignette.html�, �banocc-vignette.R�

  ignored as vignettes have been rebuilt.

  Run R CMD build with --no-build-vignettes to prevent rebuilding.

* checking for LF line-endings in source and make files and shell scripts

* checking for empty or unneeded directories

* looking to see if a �data/datalist� file should be added

* building �banocc_1.8.0.tar.gz�

Log #3 Successful R CMD CHECK


Tanias-MacBook-Air:Harvard georgeweingart$ R CMD BUILD banocc

* checking for file �banocc/DESCRIPTION� ... OK

* preparing �banocc�:

* checking DESCRIPTION meta-information ... OK

* installing the package to build vignettes

* creating vignettes ... OK

Warning: �inst/doc� files

�banocc-vignette.Rmd�, �banocc-vignette.html�, �banocc-vignette.R�

  ignored as vignettes have been rebuilt.

  Run R CMD build with --no-build-vignettes to prevent rebuilding.

* checking for LF line-endings in source and make files and shell scripts

* checking for empty or unneeded directories

* looking to see if a �data/datalist� file should be added

* building �banocc_1.8.0.tar.gz�


Tanias-MacBook-Air:Harvard georgeweingart$  R CMD CHECK "banocc_1.8.0.tar.gz"

* using log directory 

[Bioc-devel] banocc: Bioconductor BUILD error

[George Weingart]

Hello Lori and Vincent,

I am looking at the Bioconductor problem building banocc.

Can I trouble you to look into that?

If you cannot figure it out,   can you advise me what would be the correct
forum / helpdesk to request assistance to resolve the issue?

I am posting the following logs:

   1.

   Failed Build
   2.

   Successful BUILD after removing c++11 references
   3.

   Successful R CMD CHECK
   4.

   Failed BiocCheck


Thank you!

George Weingart PhD

Huttenhower Lab

Harvard School of Public Health


Summary of the problem:

   1.

   Banocc has been in Bioconductor for a while
   2.

   Around April this year we started getting messages that the Build was
   failing
   3.

   We have not changed anything in banocc
   4.

   Build succeeds in R3.5.1
   5.

   Recreated the problem on my Mac - Build fails in R3.6.0 with the
   following message:

Error: processing vignette 'banocc-vignette.Rmd' failed with diagnostics:

invalid connection

--- failed re-building ‘banocc-vignette.Rmd’

   1.

   Solved the Build problem by removing 2 references to c++11

Removed from DESCRIPTION:

SystemRequirements: C++11

Removed from vignettes/banocc-vignette.Rmd:

Sys.setenv("PKG_CXXFLAGS"="-std=c++11")


   1.

   R CMD CHECK works fine
   2.

   BiocCheck fails with a message about SweaveParseOptions


* Checking coding practice...

* NOTE: Avoid 1:...; use seq_len() or seq_along()

  Found in files:

stan-output-make_samples_list.R (line 59, column 51)

Error in SweaveParseOptions(chunkopts, drobj$options, driver$checkopts) :

  parse error or empty option in

fit-model, cache=TRUE, dependson=c('compile-stan-model', 'generate-data'),
echo=FALSE


   1.

   I don’t understand why are we getting a Sweave error under BiocCheck  as
   we are using knitr and could not find a good reference for the rror.



Log #1: Recreation of error: Failed BUILD in R3.6.0

$ R CMD BUILD banocc

* checking for file ‘banocc/DESCRIPTION’ ... OK

* preparing ‘banocc’:

* checking DESCRIPTION meta-information ... OK

* installing the package to build vignettes

* creating vignettes ... ERROR

--- re-building ‘banocc-vignette.Rmd’ using rmarkdown

Quitting from lines 138-143 (banocc-vignette.Rmd)

Quitting from lines 138-143 (banocc-vignette.Rmd)

Error: processing vignette 'banocc-vignette.Rmd' failed with diagnostics:

invalid connection

--- failed re-building ‘banocc-vignette.Rmd’

SUMMARY: processing the following file failed:

  ‘banocc-vignette.Rmd’

Error: Vignette re-building failed.

Execution halted


Log #2: Successful build after removing references to c++11

Removed from DESCRIPTION:

SystemRequirements: C++11

Removed from vignettes/banocc-vignette.Rmd:

Sys.setenv("PKG_CXXFLAGS"="-std=c++11")


Tanias-MacBook-Air:Harvard georgeweingart$ R CMD BUILD banocc

* checking for file ‘banocc/DESCRIPTION’ ... OK

* preparing ‘banocc’:

* checking DESCRIPTION meta-information ... OK

* installing the package to build vignettes

* creating vignettes ... OK

Warning: ‘inst/doc’ files

‘banocc-vignette.Rmd’, ‘banocc-vignette.html’, ‘banocc-vignette.R’

  ignored as vignettes have been rebuilt.

  Run R CMD build with --no-build-vignettes to prevent rebuilding.

* checking for LF line-endings in source and make files and shell scripts

* checking for empty or unneeded directories

* looking to see if a ‘data/datalist’ file should be added

* building ‘banocc_1.8.0.tar.gz’

Log #3 Successful R CMD CHECK

Tanias-MacBook-Air:Harvard georgeweingart$ R CMD BUILD banocc

* checking for file ‘banocc/DESCRIPTION’ ... OK

* preparing ‘banocc’:

* checking DESCRIPTION meta-information ... OK

* installing the package to build vignettes

* creating vignettes ... OK

Warning: ‘inst/doc’ files

‘banocc-vignette.Rmd’, ‘banocc-vignette.html’, ‘banocc-vignette.R’

  ignored as vignettes have been rebuilt.

  Run R CMD build with --no-build-vignettes to prevent rebuilding.

* checking for LF line-endings in source and make files and shell scripts

* checking for empty or unneeded directories

* looking to see if a ‘data/datalist’ file should be added

* building ‘banocc_1.8.0.tar.gz’

Tanias-MacBook-Air:Harvard georgeweingart$  R CMD CHECK
"banocc_1.8.0.tar.gz"

* using log directory
‘/Users/georgeweingart/Documents/Harvard/banocc.Rcheck’

* using R version 3.6.1 (2019-07-05)

* using platform: x86_64-apple-darwin15.6.0 (64-bit)

* using session charset: UTF-8

* checking for file ‘banocc/DESCRIPTION’ ... OK

* checking extension type ... Package

* this is package ‘banocc’ version ‘1.8.0’

* checking package namespace information ... OK

* checking package dependencies ... OK

* checking if this is a source package ... OK

* checking if there is a namespace ... OK

* checking for executable files ... OK

* checking for hidden files and directories ... OK

* checking for portable file names ... OK

* checking for sufficient/correct file permissions ... OK

* checking whether package ‘banocc’ can be installed ... OK

* 

Re: [Rd] GitHub passwords in .git/config?

[Brian G. Peterson]

it would be:

ssh://g...@github.com:sbgraves237/Ecdat.git


On Mon, 2019-07-15 at 11:41 -0500, Spencer Graves wrote:
> 
> On 2019-07-15 10:56, Dirk Eddelbuettel wrote:
> > 
> > 
> > 
> > Don't write passwords down like this. Your error is likely in
> > expecting _ssh_
> > authentication over _https_ -- when it works only over ssh. Use the
> > alternate
> > form for a remote e.g. one that looks like g...@github.com:emacs-
> > ess/ESS.git
> 
>I'm confused.  I changed that line to:
> 
> 
>  url = 
> https://g...@github.com:sbgraves237/sbgraves237/Ecdat
> 
> 
>Then when I did "git pull" I got:
> 
> 
> fatal: unable to access 
> 'https://g...@github.com:sbgraves237/sbgraves237/Ecdat/': Port number 
> ended with 's'
> 
> 
>???
>Thanks,
>Spencer
> 
> > Hth, Dirk
> > 
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
-- 
Brian G. Peterson
ph: +1.773.459.4973
im: bgpbraverock

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

Re: [Rd] Potential bug with data.frame replacement

[William Dunlap via R-devel]

This may be related to the size of the deparsed call in the error message
that Brodie and Luke were discussing recently on R-devel (" Mitigating
Stalls Caused by Call Deparse on Error").   I don't get a crash, but the
error message itself doesn't show up after the deparsed call.

> X <- sample(letters, 3000, TRUE)
> D <- data.frame(X, 1:3000, X, X, X, X, X)
> D$X1.3000 <- paste0("GSM", D)
Error in `$<-.data.frame`(`*tmp*`, X1.3000, value = c("GSMc(16, 6, 11, 1,
13, 7,
... many lines elided ...
 24, 24, 9, 7, 10, 17, 17, 6, 26, 26, 19, 11, 15, \n12, 9, 25, 17, 21, 24,
12, 14, 21, 23, 11, 7, 8, 11, 7, 10,
> # Note the message part of the error message was not printed
> # Use tryCatch to get the details
> e <- tryCatch(D$X1.3000 <- paste0("GSM", D), error=function(e)e)
> str(e)
List of 2
 $ message: chr "replacement has 7 rows, data has 3000"
 $ call   : language `$<-.data.frame`(`*tmp*`, X1.3000, value = c("GSMc(23,
10, 2, 9, 4, 3, 16, 12, 21, 26, 3, 17, 6, 25, 8, 1, 17, 10| __truncated__
...
 - attr(*, "class")= chr [1:3] "simpleError" "error" "condition"
> nchar(deparse(e$call))
[1] 11068 11036 11023 11023 11023 11021 2


Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Mon, Jul 15, 2019 at 3:25 AM Benjamin Jean-Marie Tremblay <
b2tremb...@uwaterloo.ca> wrote:
>
> Dear R-devel,
>
> I have encountered a crash-inducing scenario and would like to enquire as
to
> whether this would be considered a bug. To reproduce the crash:
>
> X <- sample(letters, 3000, TRUE)
> D <- data.frame(X, 1:3000, X, X, X, X, X)
> D$X1.3000 <- paste0("GSM", D)
>
> The reason why I'm not sure if this would be considered a bug is because I
> typed this by accident, when what I meant was:
>
> D$X1.3000 <- paste0("GSM", D$X1.3000)
>
> I can never image a scenario where I would intentionally perform the
former.
>
> This issue seems to have something to do with the size of the data.frame,
as
> smaller examples will work fine:
>
> D <- data.frame(A = 1:10, B = letters[1:10])
> D$A <- paste0("A", D)
>
> Also just doing the paste0 part without trying to replace a data.frame
column
> not crash R for me.
>
> I can submit this on Bugzilla should this be deemed sufficiently buggy.
>
> I am running 3.6.0 on macOS (x86_64-apple-darwin15.6.0).
>
> Sincerely,
>
> B.T.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

[[alternative HTML version deleted]]

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

Re: [Rd] GitHub passwords in .git/config?

[Dirk Eddelbuettel]

On 15 July 2019 at 11:41, Spencer Graves wrote:
| On 2019-07-15 10:56, Dirk Eddelbuettel wrote:
| >
| > Don't write passwords down like this. Your error is likely in expecting 
_ssh_
| > authentication over _https_ -- when it works only over ssh. Use the 
alternate
| > form for a remote e.g. one that looks like g...@github.com:emacs-ess/ESS.git
| 
| 
|    I'm confused.  I changed that line to:
| 
| 
|              url = https://g...@github.com:sbgraves237/sbgraves237/Ecdat
| 
| 
|    Then when I did "git pull" I got:
| 
| 
| fatal: unable to access 
| 'https://g...@github.com:sbgraves237/sbgraves237/Ecdat/': Port number 
| ended with 's'

Briefly:

 - Go to your repo.
 - Click the green 'Clone or Download' button.
 - If it shows https, select 'use ssh' in top right.
 - Copy the url:  g...@github.com:sbgraves237/Ecfun.git
 - Use it instead of:   https://github.com/sbgraves237/Ecfun.git
 - Don't improvise a new form.  Use theirs.

Hth, Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

[Bioc-devel] Please add my email to the Bioconductor server

[Theodore Killian]

Dear sir or madam,


I am the maintainer of the depmap package. I would would like this email, 
theodore.kill...@uclouvain.be added to the Bioconductor server so I can further 
maintain this package.


Warm regards,


Theo Killian

[[alternative HTML version deleted]]

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

[Rd] GitHub passwords in .git/config?

[Spencer Graves]

On 2019-07-15 10:56, Dirk Eddelbuettel wrote:




Don't write passwords down like this. Your error is likely in expecting _ssh_
authentication over _https_ -- when it works only over ssh. Use the alternate
form for a remote e.g. one that looks like g...@github.com:emacs-ess/ESS.git



  I'm confused.  I changed that line to:


            url = https://g...@github.com:sbgraves237/sbgraves237/Ecdat


  Then when I did "git pull" I got:


fatal: unable to access 
'https://g...@github.com:sbgraves237/sbgraves237/Ecdat/': Port number 
ended with 's'



      ???
      Thanks,
      Spencer


Hth, Dirk



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

Re: [Rd] Possible bug in `class<-` when a class-specific '[[.' method is defined

[Kevin Ushey]

When RStudio builds the Environment pane, it will evaluate some R code
on objects in your global environment (as you have seen). In
particular, for better or worse, it calls `str()` on objects in the
global environment, to get a short text summary of the object.

So, to reproduce what you're seeing in a plain R session, you can check:

> counttt
[1] 0
> str(df)
Classes 'MYCLASS' and 'data.frame': 5 obs. of  4 variables:
 $ V1: int  1 2 3 4 5
 $ V2: int  6 7 8 9 10
 $ V3: int  11 12 13 14 15
 $ V4: int  16 17 18 19 20
> counttt
[1] 9

Newer versions will allow you to disable the Environment pane if you
so desire, since calling `str()` can have these kinds of undesirable
side effects in some cases.

In general though, if you're reporting a bug in R (as opposed to
RStudio) it's best to verify that you can reproduce the issue in a
'plain' R session (e.g. in the terminal) to be absolutely sure you're
seeing an R issue as opposed to an RStudio issue, as I imagine the
last thing R Core wants to do is spend time tracking down an issue
only to find it was in RStudio rather than R itself...

If you want to follow up further with the RStudio team I'd recommend
making a post at https://community.rstudio.com/c/rstudio-ide.

Thanks,
Kevin

On Mon, Jul 15, 2019 at 7:59 AM Rui Barradas  wrote:
>
> Hello,
>
> Inline.
>
> Às 14:26 de 15/07/19, Duncan Murdoch escreveu:
> > On 15/07/2019 8:57 a.m., Rui Barradas wrote:
> >> Hello,
> >>
> >> Clean R 3.6.1 session on Ubuntu 19.04, RStudio 1.1.453. sessionInfo() at
> >> the end.
> >
> > That's not what I'd call a "clean session" with all those packages loaded:
>
> You are right, but when I wrote that it *was* clean. Then, for some
> reason I don't understand, RStudio loaded them all. Guess I'll have to
> check what is going on here.
>
> >
> >> loaded via a namespace (and not attached):
> >> [1] sos_2.0-0   nlme_3.1-140matrixStats_0.54.0
> >> [4] fs_1.2.7xts_0.11-2  usethis_1.5.0
> >> [7] lubridate_1.7.4 devtools_2.0.2  RColorBrewer_1.1-2
> >>[10] rprojroot_1.3-2 rbenchmark_1.0.0tools_3.6.1
> >>[13] backports_1.1.4 R6_2.4.0rpart_4.1-15
> >>[16] Hmisc_4.2-0 lazyeval_0.2.2  colorspace_1.4-1
> >>[19] nnet_7.3-12 npsurv_0.4-0withr_2.1.2
> >>[22] tidyselect_0.2.5gridExtra_2.3   prettyunits_1.0.2
> >>[25] processx_3.3.0  curl_3.3compiler_3.6.1
> >>[28] cli_1.1.0   htmlTable_1.13.1randomNames_1.4-0.0
> >>[31] dvmisc_1.1.3desc_1.2.0  tseries_0.10-46
> >>[34] scales_1.0.0checkmate_1.9.1 lmtest_0.9-36
> >>[37] fracdiff_1.4-2  mvtnorm_1.0-10  quadprog_1.5-6
> >>[40] callr_3.2.0 stringr_1.4.0   digest_0.6.18
> >>[43] foreign_0.8-71  rio_0.5.16  base64enc_0.1-3
> >>[46] stocks_1.1.4pkgconfig_2.0.2 htmltools_0.3.6
> >>[49] sessioninfo_1.1.1   readxl_1.3.1htmlwidgets_1.3
> >>[52] rlang_0.3.4 TTR_0.23-4  rstudioapi_0.10
> >>[55] quantmod_0.4-14 MLmetrics_1.1.1 zoo_1.8-5
> >>[58] zip_2.0.1   acepack_1.4.1   dplyr_0.8.0.1
> >>[61] car_3.0-2   magrittr_1.5Formula_1.2-3
> >>[64] Matrix_1.2-17   Rcpp_1.0.1  munsell_0.5.0
> >>[67] abind_1.4-5 stringi_1.4.3   forecast_8.6
> >>[70] yaml_2.2.0  carData_3.0-2   MASS_7.3-51.3
> >>[73] pkgbuild_1.0.3  plyr_1.8.4  grid_3.6.1
> >>[76] parallel_3.6.1  forcats_0.4.0   crayon_1.3.4
> >>[79] lattice_0.20-38 haven_2.1.0 splines_3.6.1
> >>[82] hms_0.4.2   knitr_1.22  ps_1.3.0
> >>[85] pillar_1.4.0pkgload_1.0.2   urca_1.3-0
> >>[88] glue_1.3.1  lsei_1.2-0  babynames_1.0.0
> >>[91] latticeExtra_0.6-28 data.table_1.12.2   remotes_2.0.4
> >>[94] cellranger_1.1.0testthat_2.1.0  gtable_0.3.0
> >>[97] purrr_0.3.2 assertthat_0.2.1ggplot2_3.1.1
> >> [100] openxlsx_4.1.0  xfun_0.6survey_3.35-1
> >> [103] survival_2.44-1.1   timeDate_3043.102   tibble_2.1.1
> >> [106] memoise_1.1.0   cluster_2.0.8   toOrdinal_1.1-0.0
> >> [109] fitdistrplus_1.0-14 brew_1.0-6
> >>
> >>
> >
> > However, even when I load almost all of those, I don't see the problem.
> > I've got the same R version, and a newer Rstudio version (mine is
> > 1.2.1335 on a Mac).  I couldn't load ] "latticeExtradata.table" and
> > "fitdistrplusbrew", and I didn't check my package versions against yours.
> >
> > I'd suspect the issue is with RStudio somehow, because it needs to do a
> > lot to maintain its environment view.  Do you see this when running R
> > from the command line?
> >
> > Duncan Murdoch
> >
>
> It's a RStudio thing.
> Tested with
>
> Rscript --vanilla test.R
>
>
> the result is the expected one.
> (test.R has the obvious contents.)
>
>
> Rui Barradas
>
> 

Re: [Rd] R-Forge > GitHub?

[Dirk Eddelbuettel]

On 14 July 2019 at 13:08, Spencer Graves wrote:
| for that.  I lost the history in doing so, but I can live without that 
| history.

Well many of us imported svn repos into git repos. And my favourite example
is still ESS as it has history back to 1997 (!!) thanks to cvs2svn
pre-filling its svn history which became the git history.

| https://github.com/sbgraves237/Ecdat".  I changed that line to read "url 
| = https://sbgraves237:passw...@github.com/sbgraves237/Ecdat; (where 
| "password" is my GitHub password, which I had to change to make it work 

Don't write passwords down like this. Your error is likely in expecting _ssh_
authentication over _https_ -- when it works only over ssh. Use the alternate
form for a remote e.g. one that looks like g...@github.com:emacs-ess/ESS.git

Hth, Dirk

-- 
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] Failing to get updated version of the package on Bioconductor

[Hamed Haseli]

Sure, thanks.

I will double check the entire process again and update you if the problem
persists.

Many thanks.
Hamed.

On Mon, 15 Jul 2019, 15:45 Shepherd, Lori, 
wrote:

> Please direct further questions to the bioc-devel@r-project.org mailing
> list/ use "reply all" so it remains in the thread
>
>
> The Bioconductor git repository has been updated and I'm unsure what you
> mean that you do not see the changes when using the R command.
>
>
> When I BiocManager::install("PhenStat")  the version that is installed is 
> 2.21.2
> as expected.
>
>
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Cancer Institute
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
> --
> *From:* Hamed Haseli 
> *Sent:* Monday, July 15, 2019 10:23:37 AM
> *To:* Shepherd, Lori
> *Subject:* Re: [Bioc-devel] Failing to get updated version of the package
> on Bioconductor
>
> Sorry for not being specific Lori.
>
> The package is PhenStat. I use PC and a piece of software called
> TortoiseGit for git operations https://tortoisegit.org/
>
> I just noticed that the package is here
> http://bioconductor.org/packages/3.10/bioc/html/PhenStat.html
>
> Still, I cannot see the changes when I use the command below in R:
>
> if (!requireNamespace("BiocManager", quietly = TRUE))
> install.packages("BiocManager")
>
> # The following initializes usage of Bioc devel
> BiocManager::install(version='devel')
>
> BiocManager::install("PhenStat")
>
> however, I see the changes if I clone rep from
> https://git.bioconductor.org/packages/PhenStat
>
> From the command line I get:
>
>  git remote -v
> origin  g...@git.bioconductor.org:packages/PhenStat (fetch)
> origin  g...@git.bioconductor.org:packages/PhenStat (push)
>
> Thanks Lori.
>
> Regards,
> Hamed,
>
>
> Hamed Haseli.M
>
>
>
> 
> | Hamed Haseli.M, PhD (Statistics)
> | Data Scientist, Mouse Informatics
> | E: hame...@ebi.ac.uk
> | P:  +44(0) 1223 494 451
> | M: +44(0) 7902 824 097
> | W: hamedhaseli.webs.com
> | European Bioinformatics Institute,
> | Wellcome Trust Genome Campus, Hinxton, Cambridge, UK. CB10 1SD
>
> ---
>
>
> On Mon, 15 Jul 2019 at 14:21, Shepherd, Lori <
> lori.sheph...@roswellpark.org> wrote:
>
> We will need more information in order to help you properly.
>
>
> Could you please inform us of the package that you are referring to?
>
>
> When you push make sure you are pushing to the git.bioconductor.org. This
> involves your remotes to be properly set up and that you are pushing to the
> right location.
>
>
> Please also show the results of
>
>
> git remote -v
>
>
> and the actual git push command you use.
>
>
> Thank you.
>
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Cancer Institute
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
> --
> *From:* Bioc-devel  on behalf of Hamed
> Haseli 
> *Sent:* Monday, July 15, 2019 9:17:02 AM
> *To:* bioc-devel@r-project.org
> *Subject:* [Bioc-devel] Failing to get updated version of the package on
> Bioconductor
>
> Dear All,
>
> I have always problems with updating the R package on Bioconductor and
> installing the updated version of the package fro the repository.
>
> The workflow that I follow is like:
>
>1. Make changes into the source code
>2. Increase the subversion x.y.z to x.y.(z+1)
>3. Push the changes to the repository
>4. Waiting for a day or more for the package to be compiled by
>Bioconductor
>
> Doing the workflow above, I do not see the changes when I install the
> package from Bioconductor. Please can you help?
>
>
> Regards,
> Hamed.
>
>
> Hamed Haseli.M
>
>
>
>
> 
> | Hamed Haseli.M, PhD (Statistics)
> | Data Scientist, Mouse Informatics
> | E: hame...@ebi.ac.uk
> | P:  +44(0) 1223 494 451
> | M: +44(0) 7902 824 097
> | W: hamedhaseli.webs.com
> | European Bioinformatics Institute,
> | Wellcome Trust Genome Campus, Hinxton, Cambridge, UK. CB10 1SD
>
>
> ---
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> This email message may contain legally privileged and/or confidential
> information. If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited. If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email 

Re: [Rd] strange increase in the reference number

[King Jiefei]

Hi Duncan, Gabriel, and Brodie

Thanks for the explanations and references. Brodie's blog talks about
exactly the same problem without involving too many technical details. I
would recommend to read it if anyone is interested in it. I really
appreciate all of you guys' answers.


Best,
Jiefei

On Sat, Jul 13, 2019 at 2:19 PM brodie gaslam via R-devel <
r-devel@r-project.org> wrote:

> Re ENSURE_NAMEDMAX, I am unsure but think this happens in (src/eval.c@492
> ):
>  static SEXP forcePromise(SEXP e)
> {
> if (PRVALUE(e) == R_UnboundValue) {
> /* ... SNIP ...*/
> val = eval(PRCODE(e), PRENV(e));
> /* ... SNIP ...*/
> SET_PRSEEN(e, 0);
> SET_PRVALUE(e, val);
> ENSURE_NAMEDMAX(val); <<< HERE
> SET_PRENV(e, R_NilValue);
> }
> return PRVALUE(e);
> }
>
> as part of the evaluations of the closure.  `forcePromise` is called
> ineval (src/eval.c@656).  It's been a while since I've looked at the
> mechanicsof how the native version of `eval` works so I could be completely
> wrong.
>
> B.
>
> PS: line references are in r-devel@76287.
>
>
> On Friday, July 12, 2019, 4:38:06 PM EDT, Gabriel Becker <
> gabembec...@gmail.com> wrote:
>
>
>
>
>
> Hi Jiefei and Duncan,
>
> I suspect what is likely happening is that one of  ENSURE_NAMEDMAX or
> MARK_NOT_MUTABLE are being hit for x. These used to set named to 3, but now
> set it to 7 (ie the previous and current NAMEDMAX  value, respectively).
>
> Because these are macros rather than C functions, its not easy to figure
> out why one of them is being invoked from do_isvector  (a cursory
> exploration didn't reveal what was going on, at least to me) and I don't
> have the time to dig super deeply into this right now,  but perhaps Luke or
> Tomas know why this is happening of the top of their head.
>
> Sorry I can't be of more help.
>
> ~G
>
>
>
> On Fri, Jul 12, 2019 at 11:47 AM Duncan Murdoch 
> wrote:
>
> > On 12/07/2019 1:22 p.m., King Jiefei wrote:
> > > Hi,
> > >
> > > I just found a strange increase in the reference number and I'm
> wondering
> > > if there is any reason for it, here is the code.
> > >
> > >> a=c(1,2,3)
> > >> .Internal(inspect(a))
> > > @0x1bf0b9b0 14 REALSXP g0c3 [NAM(1)] (len=3, tl=0) 1,2,3
> > >> is.vector(a)
> > > [1] TRUE
> > >> .Internal(inspect(a))
> > > @0x1bf0b9b0 14 REALSXP g0c3 [NAM(7)] (len=3, tl=0) 1,2,3
> > >
> > > The variable *a* initially has one reference number, after calling
> > > *is.vector* function, the reference number goes to 7, which I believe
> is
> > > the highest number that is allowed in R.  I also tried the other R
> > > functions, *is.atomic, is.integer* and *is.numeric* do not increase the
> > > reference number, but *typeof *will do. Is it intentional?
> >
> > is.vector() is a closure that calls .Internal.  is.atomic(),
> > is.integer() and is.numeric() are all primitives.
> >
> > Generally speaking closures that call .Internal are easier to implement
> > (e.g. is.vector can use the regular mechanism to set a default for its
> > second argument), but less efficient in CPU time.  From it's help page,
> > it appears that the logic for is.vector() is a lot more complex than for
> > the others, so that implementation does make sense.
> >
> > So why does NAMED go to 7?  Initially, the vector is bound to a.  Within
> > is.vector, it is bound to the local variable x.  At this point there are
> > two names bound to the same object, so it has to be considered
> > immutable.  There's really no difference between any of the values of 2
> > or more in the memory manager.  (But see
> > http://developer.r-project.org/Refcnt.html for some plans.  That
> > document is from about 5 years ago; I don't know the current state.)
> >
> > Duncan Murdoch
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> [[alternative HTML version deleted]]
>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] Possible bug in `class<-` when a class-specific '[[.' method is defined

[Rui Barradas]

Hello,

Inline.

Às 14:26 de 15/07/19, Duncan Murdoch escreveu:

On 15/07/2019 8:57 a.m., Rui Barradas wrote:

Hello,

Clean R 3.6.1 session on Ubuntu 19.04, RStudio 1.1.453. sessionInfo() at
the end.


That's not what I'd call a "clean session" with all those packages loaded:


You are right, but when I wrote that it *was* clean. Then, for some 
reason I don't understand, RStudio loaded them all. Guess I'll have to 
check what is going on here.





loaded via a namespace (and not attached):
    [1] sos_2.0-0   nlme_3.1-140    matrixStats_0.54.0
    [4] fs_1.2.7    xts_0.11-2  usethis_1.5.0
    [7] lubridate_1.7.4 devtools_2.0.2  RColorBrewer_1.1-2
   [10] rprojroot_1.3-2 rbenchmark_1.0.0    tools_3.6.1
   [13] backports_1.1.4 R6_2.4.0    rpart_4.1-15
   [16] Hmisc_4.2-0 lazyeval_0.2.2  colorspace_1.4-1
   [19] nnet_7.3-12 npsurv_0.4-0    withr_2.1.2
   [22] tidyselect_0.2.5    gridExtra_2.3   prettyunits_1.0.2
   [25] processx_3.3.0  curl_3.3    compiler_3.6.1
   [28] cli_1.1.0   htmlTable_1.13.1    randomNames_1.4-0.0
   [31] dvmisc_1.1.3    desc_1.2.0  tseries_0.10-46
   [34] scales_1.0.0    checkmate_1.9.1 lmtest_0.9-36
   [37] fracdiff_1.4-2  mvtnorm_1.0-10  quadprog_1.5-6
   [40] callr_3.2.0 stringr_1.4.0   digest_0.6.18
   [43] foreign_0.8-71  rio_0.5.16  base64enc_0.1-3
   [46] stocks_1.1.4    pkgconfig_2.0.2 htmltools_0.3.6
   [49] sessioninfo_1.1.1   readxl_1.3.1    htmlwidgets_1.3
   [52] rlang_0.3.4 TTR_0.23-4  rstudioapi_0.10
   [55] quantmod_0.4-14 MLmetrics_1.1.1 zoo_1.8-5
   [58] zip_2.0.1   acepack_1.4.1   dplyr_0.8.0.1
   [61] car_3.0-2   magrittr_1.5    Formula_1.2-3
   [64] Matrix_1.2-17   Rcpp_1.0.1  munsell_0.5.0
   [67] abind_1.4-5 stringi_1.4.3   forecast_8.6
   [70] yaml_2.2.0  carData_3.0-2   MASS_7.3-51.3
   [73] pkgbuild_1.0.3  plyr_1.8.4  grid_3.6.1
   [76] parallel_3.6.1  forcats_0.4.0   crayon_1.3.4
   [79] lattice_0.20-38 haven_2.1.0 splines_3.6.1
   [82] hms_0.4.2   knitr_1.22  ps_1.3.0
   [85] pillar_1.4.0    pkgload_1.0.2   urca_1.3-0
   [88] glue_1.3.1  lsei_1.2-0  babynames_1.0.0
   [91] latticeExtra_0.6-28 data.table_1.12.2   remotes_2.0.4
   [94] cellranger_1.1.0    testthat_2.1.0  gtable_0.3.0
   [97] purrr_0.3.2 assertthat_0.2.1    ggplot2_3.1.1
[100] openxlsx_4.1.0  xfun_0.6    survey_3.35-1
[103] survival_2.44-1.1   timeDate_3043.102   tibble_2.1.1
[106] memoise_1.1.0   cluster_2.0.8   toOrdinal_1.1-0.0
[109] fitdistrplus_1.0-14 brew_1.0-6




However, even when I load almost all of those, I don't see the problem. 
I've got the same R version, and a newer Rstudio version (mine is 
1.2.1335 on a Mac).  I couldn't load ] "latticeExtradata.table" and 
"fitdistrplusbrew", and I didn't check my package versions against yours.


I'd suspect the issue is with RStudio somehow, because it needs to do a 
lot to maintain its environment view.  Do you see this when running R 
from the command line?


Duncan Murdoch



It's a RStudio thing.
Tested with

Rscript --vanilla test.R


the result is the expected one.
(test.R has the obvious contents.)


Rui Barradas

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

Re: [Bioc-devel] Failing to get updated version of the package on Bioconductor

[Shepherd, Lori]

Please direct further questions to the bioc-devel@r-project.org mailing list/ 
use "reply all" so it remains in the thread


The Bioconductor git repository has been updated and I'm unsure what you mean 
that you do not see the changes when using the R command.


When I BiocManager::install("PhenStat")  the version that is installed is 
2.21.2  as expected.




Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Hamed Haseli 
Sent: Monday, July 15, 2019 10:23:37 AM
To: Shepherd, Lori
Subject: Re: [Bioc-devel] Failing to get updated version of the package on 
Bioconductor

Sorry for not being specific Lori.

The package is PhenStat. I use PC and a piece of software called TortoiseGit 
for git operations https://tortoisegit.org/

I just noticed that the package is here 
http://bioconductor.org/packages/3.10/bioc/html/PhenStat.html

Still, I cannot see the changes when I use the command below in R:


if (!requireNamespace("BiocManager", quietly = TRUE))
install.packages("BiocManager")

# The following initializes usage of Bioc devel
BiocManager::install(version='devel')

BiocManager::install("PhenStat")

however, I see the changes if I clone rep from 
https://git.bioconductor.org/packages/PhenStat

>From the command line I get:

 git remote -v
origin  g...@git.bioconductor.org:packages/PhenStat (fetch)
origin  g...@git.bioconductor.org:packages/PhenStat (push)

Thanks Lori.

Regards,
Hamed,



Hamed Haseli.M


  
| Hamed Haseli.M, PhD (Statistics)
| Data Scientist, Mouse Informatics
| E: hame...@ebi.ac.uk
| P:  +44(0) 1223 494 451
| M: +44(0) 7902 824 097
| W: hamedhaseli.webs.com
| European Bioinformatics Institute,
| Wellcome Trust Genome Campus, Hinxton, Cambridge, UK. CB10 1SD
  
---


On Mon, 15 Jul 2019 at 14:21, Shepherd, Lori 
mailto:lori.sheph...@roswellpark.org>> wrote:

We will need more information in order to help you properly.


Could you please inform us of the package that you are referring to?


When you push make sure you are pushing to the 
git.bioconductor.org. This involves your remotes 
to be properly set up and that you are pushing to the right location.


Please also show the results of


git remote -v


and the actual git push command you use.


Thank you.



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel 
mailto:bioc-devel-boun...@r-project.org>> on 
behalf of Hamed Haseli mailto:hame...@ebi.ac.uk>>
Sent: Monday, July 15, 2019 9:17:02 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Failing to get updated version of the package on 
Bioconductor

Dear All,

I have always problems with updating the R package on Bioconductor and
installing the updated version of the package fro the repository.

The workflow that I follow is like:

   1. Make changes into the source code
   2. Increase the subversion x.y.z to x.y.(z+1)
   3. Push the changes to the repository
   4. Waiting for a day or more for the package to be compiled by
   Bioconductor

Doing the workflow above, I do not see the changes when I install the
package from Bioconductor. Please can you help?


Regards,
Hamed.


Hamed Haseli.M




| Hamed Haseli.M, PhD (Statistics)
| Data Scientist, Mouse Informatics
| E: hame...@ebi.ac.uk
| P:  +44(0) 1223 494 451
| M: +44(0) 7902 824 097
| W: hamedhaseli.webs.com
| European Bioinformatics Institute,
| Wellcome Trust Genome Campus, Hinxton, Cambridge, UK. CB10 1SD

---

[[alternative HTML version deleted]]

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

This email message may contain legally privileged and/or confidential 
information. If you are not the intended recipient(s), or the employee or agent 
responsible for the delivery of this message to the intended recipient(s), you 
are hereby notified that any disclosure, copying, distribution, or use of this 
email message is prohibited. If you have received this message in error, please 
notify the sender immediately by e-mail and delete this email message from your 
computer. Thank you.


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or 

Re: [Rd] [External] Mitigating Stalls Caused by Call Deparse on Error

[Tierney, Luke]

Better to add this to the wishlist item. This all needs to be looked
at together, and nothing is likely to happen until after
vacation/conference season.  It will disappear from everyone's radar
if it is just in R_devel.

Best,

luke

On Sun, 14 Jul 2019, brodie gaslam wrote:

> Luke, thanks for considering the issue.  I would like to
> try to separate the problem into two parts, as I _think_
> your comments address primarily part 2 below:
>
> 1. How can we avoid significant and possibly crippling
>    stalls on error with these non-standard calls.
> 2. What is the best way to view these non-standard calls.
>
> I agree that issue 2. requires further thought and
> discussion under a wishlist issue ([on bugzilla now][1]). 
> While I did raise issue 2., the patch itself makes no
> attempt to resolve it.
>
> The proposed patch resolves issue 1., which is a big
> usability problem.  Right now if you have the misfortune of
> using `do.call` with a big object and trigger an error, you
> have the choice of waiting a possibly long time for
> the deparse to complete, or killing your entire R session
> externally.
>
> It seems a shame to allow a big usability issue for `do.call`
> to remain when there is a simple solution at hand, especially
> since the complete deparse of large objects likely serves no
> purpose in this case. Obviously, if storing the actual calls
> instead of their deparsed equivalents in .Traceback causes
> problems I'm not anticipating, then that's different. 
> Is that the case?
>
> Best,
>
> Brodie.
>
> [1]: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17580
>
> On Sunday, July 14, 2019, 8:52:45 AM EDT, Tierney, Luke 
>  wrote:
>
>
>
>
>
> This is probably best viewed in the context of other issue with
> displaying calls, such as issues arising from calls constructed in
> non-standard evaluation contexts. Might be good to move to a wishlist
> item in bugzilla.
>
> Best,
>
> luke
>
> On Sat, 13 Jul 2019, brodie gaslam via R-devel wrote:
>
>> When large calls cause errors R may stall for extended periods.  This
>> is particularly likely to happen with `do.call`, as in this example
>> with a 24 second stall:
>>
>>     x <- runif(1e7)
>>     system.time(do.call(paste0, list(abs, x)))  # intentional error
>>     ## Error in (function (..., collapse = NULL)  :
>>     ##   cannot coerce type 'builtin' to vector of type 'character'
>>     ## Calls: system.time -> do.call -> 
>>     ## Timing stopped at: 23.81 0.149 24.04
>>
>>     str(.Traceback)
>>     ## Dotted pair list of 3
>>     ##  $ : chr [1:2500488] "(function (..., collapse = NULL) " 
>> ".Internal(paste0(list(...), collapse)))(.Primitive(\"abs\"), 
>> c(0.718117154669017, " "0.494785501621664, 0.1453434410505, 
>> 0.635028422810137, 0.0353180423844606, " "0.688418723642826, 
>> 0.889682895969599, 0.728154224809259, 0.292572240810841, " ...
>>     ##  $ : chr "do.call(paste0, list(abs, x))"
>>     ##  $ : chr "system.time(do.call(paste0, list(abs, x)))"
>>
>> The first time I noticed this I thought my session had frozen/crashed
>> as the standard interrupt ^C does not work during the deparse.  The
>> stall happens when on error the call stack is deparsed prior to being
>> saved to `.Traceback`.  The deparsing is done by `deparse1m` in native
>> code, with the value of `getOption('deparse.max.lines')` which
>> defaults to all lines.
>>
>> Since there is little value to seeing millions of lines of deparsed
>> objects in `traceback()`, a simple work-around is to change the
>> `deparse.max.lines` value:
>>
>>     options(deparse.max.lines=1)
>>     system.time(do.call(paste0, list(abs, x)))
>>     ## Error in (function (..., collapse = NULL)  :
>>     ##   cannot coerce type 'builtin' to vector of type 'character'
>>     ## Calls: system.time -> do.call -> 
>>     ## Timing stopped at: 0 0 0
>>
>> Unfortunately this will affect all `deparse` calls, and it seems
>> undesirable to pre-emptively enable it just for calls that might cause
>> large deparses on error.
>>
>> An alternative is to store the actual calls instead of their deparsed
>> character equivalents in `.Traceback`.  This defers the deparsing to
>> when `traceback()` is used.  As per `?traceback`, it should be
>> relatively safe to modify `.Traceback` in this way:
>>
>>> It is undocumented where .Traceback is stored nor that it is
>>> visible, and this is subject to change.
>>
>> Deferring the deparsing to `traceback()` will give us the 
>> opportunity to use a different `max.lines` setting as we do here
>> with the patch applied:
>>
>>     system.time(do.call(paste0, list(abs, x)))
>>     ## Error in (function (..., collapse = NULL)  :
>>     ##   cannot coerce type 'builtin' to vector of type 'character'
>>     ## Timing stopped at: 0.028 0 0.029
>>
>>     system.time(traceback(max.lines=3))
>>     ## 3: (function (..., collapse = NULL)
>>     ##    .Internal(paste0(list(...), collapse)))(.Primitive("abs"), 
>> c(0.535468587651849,
>>     ##    0.0540027911774814, 

Re: [Bioc-devel] Failing to get updated version of the package on Bioconductor

[Martin Morgan]

also remember that you are making changes to the _devel_ version of 
Bioconductor, so must look for changes in the devel branch of the repository; 

  http://bioconductor.org/developers/how-to/useDevel/

Martin

On 7/15/19, 9:28 AM, "Bioc-devel on behalf of Shepherd, Lori" 
 
wrote:

We will need more information in order to help you properly.


Could you please inform us of the package that you are referring to?


When you push make sure you are pushing to the git.bioconductor.org. This 
involves your remotes to be properly set up and that you are pushing to the 
right location.


Please also show the results of


git remote -v


and the actual git push command you use.


Thank you.



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Hamed 
Haseli 
Sent: Monday, July 15, 2019 9:17:02 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Failing to get updated version of the package on 
Bioconductor

Dear All,

I have always problems with updating the R package on Bioconductor and
installing the updated version of the package fro the repository.

The workflow that I follow is like:

   1. Make changes into the source code
   2. Increase the subversion x.y.z to x.y.(z+1)
   3. Push the changes to the repository
   4. Waiting for a day or more for the package to be compiled by
   Bioconductor

Doing the workflow above, I do not see the changes when I install the
package from Bioconductor. Please can you help?


Regards,
Hamed.


Hamed Haseli.M




| Hamed Haseli.M, PhD (Statistics)
| Data Scientist, Mouse Informatics
| E: hame...@ebi.ac.uk
| P:  +44(0) 1223 494 451
| M: +44(0) 7902 824 097
| W: hamedhaseli.webs.com
| European Bioinformatics Institute,
| Wellcome Trust Genome Campus, Hinxton, Cambridge, UK. CB10 1SD


---

[[alternative HTML version deleted]]

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


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
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] [External] Re: Possible bug in `class<-` when a class-specific '[[.' method is defined

[Duncan Murdoch]

On 15/07/2019 9:24 a.m., Tierney, Luke wrote:

Pasting the entire example into RStudio and hitting return to evaluate
does not show this. Evaluating the finall line to print counttt
separately does.

Looks like RStudio is calling `[[` on your object when examining the
environment for the Environment panel. If this concerns you then you
should contact RStudio.


Now I see it!

Duncan Murdoch

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

Re: [Bioc-devel] Failing to get updated version of the package on Bioconductor

[Shepherd, Lori]

We will need more information in order to help you properly.


Could you please inform us of the package that you are referring to?


When you push make sure you are pushing to the git.bioconductor.org. This 
involves your remotes to be properly set up and that you are pushing to the 
right location.


Please also show the results of


git remote -v


and the actual git push command you use.


Thank you.



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Hamed Haseli 

Sent: Monday, July 15, 2019 9:17:02 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Failing to get updated version of the package on 
Bioconductor

Dear All,

I have always problems with updating the R package on Bioconductor and
installing the updated version of the package fro the repository.

The workflow that I follow is like:

   1. Make changes into the source code
   2. Increase the subversion x.y.z to x.y.(z+1)
   3. Push the changes to the repository
   4. Waiting for a day or more for the package to be compiled by
   Bioconductor

Doing the workflow above, I do not see the changes when I install the
package from Bioconductor. Please can you help?


Regards,
Hamed.


Hamed Haseli.M




| Hamed Haseli.M, PhD (Statistics)
| Data Scientist, Mouse Informatics
| E: hame...@ebi.ac.uk
| P:  +44(0) 1223 494 451
| M: +44(0) 7902 824 097
| W: hamedhaseli.webs.com
| European Bioinformatics Institute,
| Wellcome Trust Genome Campus, Hinxton, Cambridge, UK. CB10 1SD

---

[[alternative HTML version deleted]]

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


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

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

Re: [Rd] Possible bug in `class<-` when a class-specific '[[.' method is defined

[Duncan Murdoch]

On 15/07/2019 8:57 a.m., Rui Barradas wrote:

Hello,

Clean R 3.6.1 session on Ubuntu 19.04, RStudio 1.1.453. sessionInfo() at
the end.


That's not what I'd call a "clean session" with all those packages loaded:


loaded via a namespace (and not attached):
[1] sos_2.0-0   nlme_3.1-140matrixStats_0.54.0
[4] fs_1.2.7xts_0.11-2  usethis_1.5.0
[7] lubridate_1.7.4 devtools_2.0.2  RColorBrewer_1.1-2
   [10] rprojroot_1.3-2 rbenchmark_1.0.0tools_3.6.1
   [13] backports_1.1.4 R6_2.4.0rpart_4.1-15
   [16] Hmisc_4.2-0 lazyeval_0.2.2  colorspace_1.4-1
   [19] nnet_7.3-12 npsurv_0.4-0withr_2.1.2
   [22] tidyselect_0.2.5gridExtra_2.3   prettyunits_1.0.2
   [25] processx_3.3.0  curl_3.3compiler_3.6.1
   [28] cli_1.1.0   htmlTable_1.13.1randomNames_1.4-0.0
   [31] dvmisc_1.1.3desc_1.2.0  tseries_0.10-46
   [34] scales_1.0.0checkmate_1.9.1 lmtest_0.9-36
   [37] fracdiff_1.4-2  mvtnorm_1.0-10  quadprog_1.5-6
   [40] callr_3.2.0 stringr_1.4.0   digest_0.6.18
   [43] foreign_0.8-71  rio_0.5.16  base64enc_0.1-3
   [46] stocks_1.1.4pkgconfig_2.0.2 htmltools_0.3.6
   [49] sessioninfo_1.1.1   readxl_1.3.1htmlwidgets_1.3
   [52] rlang_0.3.4 TTR_0.23-4  rstudioapi_0.10
   [55] quantmod_0.4-14 MLmetrics_1.1.1 zoo_1.8-5
   [58] zip_2.0.1   acepack_1.4.1   dplyr_0.8.0.1
   [61] car_3.0-2   magrittr_1.5Formula_1.2-3
   [64] Matrix_1.2-17   Rcpp_1.0.1  munsell_0.5.0
   [67] abind_1.4-5 stringi_1.4.3   forecast_8.6
   [70] yaml_2.2.0  carData_3.0-2   MASS_7.3-51.3
   [73] pkgbuild_1.0.3  plyr_1.8.4  grid_3.6.1
   [76] parallel_3.6.1  forcats_0.4.0   crayon_1.3.4
   [79] lattice_0.20-38 haven_2.1.0 splines_3.6.1
   [82] hms_0.4.2   knitr_1.22  ps_1.3.0
   [85] pillar_1.4.0pkgload_1.0.2   urca_1.3-0
   [88] glue_1.3.1  lsei_1.2-0  babynames_1.0.0
   [91] latticeExtra_0.6-28 data.table_1.12.2   remotes_2.0.4
   [94] cellranger_1.1.0testthat_2.1.0  gtable_0.3.0
   [97] purrr_0.3.2 assertthat_0.2.1ggplot2_3.1.1
[100] openxlsx_4.1.0  xfun_0.6survey_3.35-1
[103] survival_2.44-1.1   timeDate_3043.102   tibble_2.1.1
[106] memoise_1.1.0   cluster_2.0.8   toOrdinal_1.1-0.0
[109] fitdistrplus_1.0-14 brew_1.0-6




However, even when I load almost all of those, I don't see the problem. 
I've got the same R version, and a newer Rstudio version (mine is 
1.2.1335 on a Mac).  I couldn't load ] "latticeExtradata.table" and 
"fitdistrplusbrew", and I didn't check my package versions against yours.


I'd suspect the issue is with RStudio somehow, because it needs to do a 
lot to maintain its environment view.  Do you see this when running R 
from the command line?


Duncan Murdoch

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

Re: [Rd] [External] Re: Possible bug in `class<-` when a class-specific '[[.' method is defined

[Tierney, Luke]

Pasting the entire example into RStudio and hitting return to evaluate
does not show this. Evaluating the finall line to print counttt
separately does.

Looks like RStudio is calling `[[` on your object when examining the
environment for the Environment panel. If this concerns you then you
should contact RStudio.

Best,

luke

On Mon, 15 Jul 2019, Rui Barradas wrote:

> Hello,
>
> Clean R 3.6.1 session on Ubuntu 19.04, RStudio 1.1.453. sessionInfo() at the 
> end.
>
> I can reproduce this.
>
> counttt <- 0
>
> `[[.MYCLASS` = function(x, ...) {
>  counttt <<- counttt + 1
>  # browser()
>  x = NextMethod()
>  return(x)
> }
>
> df <- as.data.frame(matrix(1:20, nrow=5))
> class(df) <- c("MYCLASS","data.frame")
> counttt
> #[1] 9
>
>
> But there's more. I tried to print the values of x in the method and got 
> really strange results
>
> counttt <- 0
>
> `[[.MYCLASS` = function(x, ...) {
>  counttt <<- counttt + 1
>  print(x)
>  # browser()
>  x = NextMethod()
>  return(x)
> }
>
> df <- as.data.frame(matrix(1:20, nrow=5))
> class(df) <- c("MYCLASS","data.frame")
> counttt
> #[1] 151
>
>
> If I change print to print.data.frame it goes up to
>
> counttt
> #[1] 176
>
> With print.default back to 9. What is the print method called in the second 
> example?
>
>
> sessionInfo()
> R version 3.6.1 (2019-07-05)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 19.04
>
> Matrix products: default
> BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.8.0
> LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.8.0
>
> locale:
> [1] LC_CTYPE=pt_PT.UTF-8   LC_NUMERIC=C
> [3] LC_TIME=pt_PT.UTF-8LC_COLLATE=pt_PT.UTF-8
> [5] LC_MONETARY=pt_PT.UTF-8LC_MESSAGES=pt_PT.UTF-8
> [7] LC_PAPER=pt_PT.UTF-8   LC_NAME=C
> [9] LC_ADDRESS=C   LC_TELEPHONE=C
> [11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods
> [7] base
>
> loaded via a namespace (and not attached):
>  [1] sos_2.0-0   nlme_3.1-140matrixStats_0.54.0
>  [4] fs_1.2.7xts_0.11-2  usethis_1.5.0
>  [7] lubridate_1.7.4 devtools_2.0.2  RColorBrewer_1.1-2
> [10] rprojroot_1.3-2 rbenchmark_1.0.0tools_3.6.1
> [13] backports_1.1.4 R6_2.4.0rpart_4.1-15
> [16] Hmisc_4.2-0 lazyeval_0.2.2  colorspace_1.4-1
> [19] nnet_7.3-12 npsurv_0.4-0withr_2.1.2
> [22] tidyselect_0.2.5gridExtra_2.3   prettyunits_1.0.2
> [25] processx_3.3.0  curl_3.3compiler_3.6.1
> [28] cli_1.1.0   htmlTable_1.13.1randomNames_1.4-0.0
> [31] dvmisc_1.1.3desc_1.2.0  tseries_0.10-46
> [34] scales_1.0.0checkmate_1.9.1 lmtest_0.9-36
> [37] fracdiff_1.4-2  mvtnorm_1.0-10  quadprog_1.5-6
> [40] callr_3.2.0 stringr_1.4.0   digest_0.6.18
> [43] foreign_0.8-71  rio_0.5.16  base64enc_0.1-3
> [46] stocks_1.1.4pkgconfig_2.0.2 htmltools_0.3.6
> [49] sessioninfo_1.1.1   readxl_1.3.1htmlwidgets_1.3
> [52] rlang_0.3.4 TTR_0.23-4  rstudioapi_0.10
> [55] quantmod_0.4-14 MLmetrics_1.1.1 zoo_1.8-5
> [58] zip_2.0.1   acepack_1.4.1   dplyr_0.8.0.1
> [61] car_3.0-2   magrittr_1.5Formula_1.2-3
> [64] Matrix_1.2-17   Rcpp_1.0.1  munsell_0.5.0
> [67] abind_1.4-5 stringi_1.4.3   forecast_8.6
> [70] yaml_2.2.0  carData_3.0-2   MASS_7.3-51.3
> [73] pkgbuild_1.0.3  plyr_1.8.4  grid_3.6.1
> [76] parallel_3.6.1  forcats_0.4.0   crayon_1.3.4
> [79] lattice_0.20-38 haven_2.1.0 splines_3.6.1
> [82] hms_0.4.2   knitr_1.22  ps_1.3.0
> [85] pillar_1.4.0pkgload_1.0.2   urca_1.3-0
> [88] glue_1.3.1  lsei_1.2-0  babynames_1.0.0
> [91] latticeExtra_0.6-28 data.table_1.12.2   remotes_2.0.4
> [94] cellranger_1.1.0testthat_2.1.0  gtable_0.3.0
> [97] purrr_0.3.2 assertthat_0.2.1ggplot2_3.1.1
> [100] openxlsx_4.1.0  xfun_0.6survey_3.35-1
> [103] survival_2.44-1.1   timeDate_3043.102   tibble_2.1.1
> [106] memoise_1.1.0   cluster_2.0.8   toOrdinal_1.1-0.0
> [109] fitdistrplus_1.0-14 brew_1.0-6
>
>
>
> Hope this helps,
>
> Rui Barradas
>
>
> Às 13:16 de 15/07/19, Duncan Murdoch escreveu:
>> On 07/07/2019 11:49 a.m., Ghiggi Gionata wrote:
>>> Hi all !
>>> 
>>> I noticed a strange behaviour of the function `class<-` when a 
>>> class-specific '[[.' method is defined.
>>> 
>>> Here below a reproducible example :
>>> 
>>> 
>>> #---.
>>> 
>>> counttt <- 0
>>> 
>>> `[[.MYCLASS` = function(x, ...) {
>>>    counttt <<- counttt + 1
>>>    # browser()
>>>    x = NextMethod()
>>>    return(x)
>>> }
>>> 
>>> df <- as.data.frame(matrix(1:20, nrow=5))
>>> class(df) <- c("MYCLASS","data.frame")
>>> counttt
>>> 
>>> # The same occurs when using structure(, class=) or 

[Bioc-devel] Failing to get updated version of the package on Bioconductor

[Hamed Haseli]

Dear All,

I have always problems with updating the R package on Bioconductor and
installing the updated version of the package fro the repository.

The workflow that I follow is like:

   1. Make changes into the source code
   2. Increase the subversion x.y.z to x.y.(z+1)
   3. Push the changes to the repository
   4. Waiting for a day or more for the package to be compiled by
   Bioconductor

Doing the workflow above, I do not see the changes when I install the
package from Bioconductor. Please can you help?


Regards,
Hamed.


Hamed Haseli.M




| Hamed Haseli.M, PhD (Statistics)
| Data Scientist, Mouse Informatics
| E: hame...@ebi.ac.uk
| P:  +44(0) 1223 494 451
| M: +44(0) 7902 824 097
| W: hamedhaseli.webs.com
| European Bioinformatics Institute,
| Wellcome Trust Genome Campus, Hinxton, Cambridge, UK. CB10 1SD

---

[[alternative HTML version deleted]]

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

Re: [Rd] Possible bug in `class<-` when a class-specific '[[.' method is defined

[Rui Barradas]

Hello,

Clean R 3.6.1 session on Ubuntu 19.04, RStudio 1.1.453. sessionInfo() at 
the end.


I can reproduce this.

counttt <- 0

`[[.MYCLASS` = function(x, ...) {
  counttt <<- counttt + 1
  # browser()
  x = NextMethod()
  return(x)
}

df <- as.data.frame(matrix(1:20, nrow=5))
class(df) <- c("MYCLASS","data.frame")
counttt
#[1] 9


But there's more. I tried to print the values of x in the method and got 
really strange results


counttt <- 0

`[[.MYCLASS` = function(x, ...) {
  counttt <<- counttt + 1
  print(x)
  # browser()
  x = NextMethod()
  return(x)
}

df <- as.data.frame(matrix(1:20, nrow=5))
class(df) <- c("MYCLASS","data.frame")
counttt
#[1] 151


If I change print to print.data.frame it goes up to

counttt
#[1] 176

With print.default back to 9. What is the print method called in the 
second example?



sessionInfo()
R version 3.6.1 (2019-07-05)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 19.04

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.8.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.8.0

locale:
 [1] LC_CTYPE=pt_PT.UTF-8   LC_NUMERIC=C
 [3] LC_TIME=pt_PT.UTF-8LC_COLLATE=pt_PT.UTF-8
 [5] LC_MONETARY=pt_PT.UTF-8LC_MESSAGES=pt_PT.UTF-8
 [7] LC_PAPER=pt_PT.UTF-8   LC_NAME=C
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods
[7] base

loaded via a namespace (and not attached):
  [1] sos_2.0-0   nlme_3.1-140matrixStats_0.54.0
  [4] fs_1.2.7xts_0.11-2  usethis_1.5.0
  [7] lubridate_1.7.4 devtools_2.0.2  RColorBrewer_1.1-2
 [10] rprojroot_1.3-2 rbenchmark_1.0.0tools_3.6.1
 [13] backports_1.1.4 R6_2.4.0rpart_4.1-15
 [16] Hmisc_4.2-0 lazyeval_0.2.2  colorspace_1.4-1
 [19] nnet_7.3-12 npsurv_0.4-0withr_2.1.2
 [22] tidyselect_0.2.5gridExtra_2.3   prettyunits_1.0.2
 [25] processx_3.3.0  curl_3.3compiler_3.6.1
 [28] cli_1.1.0   htmlTable_1.13.1randomNames_1.4-0.0
 [31] dvmisc_1.1.3desc_1.2.0  tseries_0.10-46
 [34] scales_1.0.0checkmate_1.9.1 lmtest_0.9-36
 [37] fracdiff_1.4-2  mvtnorm_1.0-10  quadprog_1.5-6
 [40] callr_3.2.0 stringr_1.4.0   digest_0.6.18
 [43] foreign_0.8-71  rio_0.5.16  base64enc_0.1-3
 [46] stocks_1.1.4pkgconfig_2.0.2 htmltools_0.3.6
 [49] sessioninfo_1.1.1   readxl_1.3.1htmlwidgets_1.3
 [52] rlang_0.3.4 TTR_0.23-4  rstudioapi_0.10
 [55] quantmod_0.4-14 MLmetrics_1.1.1 zoo_1.8-5
 [58] zip_2.0.1   acepack_1.4.1   dplyr_0.8.0.1
 [61] car_3.0-2   magrittr_1.5Formula_1.2-3
 [64] Matrix_1.2-17   Rcpp_1.0.1  munsell_0.5.0
 [67] abind_1.4-5 stringi_1.4.3   forecast_8.6
 [70] yaml_2.2.0  carData_3.0-2   MASS_7.3-51.3
 [73] pkgbuild_1.0.3  plyr_1.8.4  grid_3.6.1
 [76] parallel_3.6.1  forcats_0.4.0   crayon_1.3.4
 [79] lattice_0.20-38 haven_2.1.0 splines_3.6.1
 [82] hms_0.4.2   knitr_1.22  ps_1.3.0
 [85] pillar_1.4.0pkgload_1.0.2   urca_1.3-0
 [88] glue_1.3.1  lsei_1.2-0  babynames_1.0.0
 [91] latticeExtra_0.6-28 data.table_1.12.2   remotes_2.0.4
 [94] cellranger_1.1.0testthat_2.1.0  gtable_0.3.0
 [97] purrr_0.3.2 assertthat_0.2.1ggplot2_3.1.1
[100] openxlsx_4.1.0  xfun_0.6survey_3.35-1
[103] survival_2.44-1.1   timeDate_3043.102   tibble_2.1.1
[106] memoise_1.1.0   cluster_2.0.8   toOrdinal_1.1-0.0
[109] fitdistrplus_1.0-14 brew_1.0-6



Hope this helps,

Rui Barradas


Às 13:16 de 15/07/19, Duncan Murdoch escreveu:

On 07/07/2019 11:49 a.m., Ghiggi Gionata wrote:

Hi all !

I noticed a strange behaviour of the function `class<-` when a 
class-specific '[[.' method is defined.


Here below a reproducible example :


#---.

counttt <- 0

`[[.MYCLASS` = function(x, ...) {
   counttt <<- counttt + 1
   # browser()
   x = NextMethod()
   return(x)
}

df <- as.data.frame(matrix(1:20, nrow=5))
class(df) <- c("MYCLASS","data.frame")
counttt

# The same occurs when using structure(, class=) or attr(,"class")<-
df <- as.data.frame(matrix(1:20, nrow=5))
df <- structure(df, class=c("MYCLASS","data.frame"))
attr(df, "class") <- c("MYCLASS","data.frame")

#---.

Why in this example `class<-` is calling  `[[.MYCLASS` 9 times ?

Is there a way to avoid `class<-` to call `[[.MYCLASS` ?


Thank you in advance for your help and suggestions.


This is what I see:


 > counttt <- 0
 >
 > `[[.MYCLASS` = function(x, ...) {
+   counttt <<- counttt + 1
+   # browser()
+   x = NextMethod()
+   return(x)
+ }
 >
 > df <- as.data.frame(matrix(1:20, nrow=5))
 > class(df) 

Re: [Rd] Possible bug in `class<-` when a class-specific '[[.' method is defined

[Duncan Murdoch]

On 07/07/2019 11:49 a.m., Ghiggi Gionata wrote:

Hi all !

I noticed a strange behaviour of the function `class<-` when a class-specific 
'[[.' method is defined.

Here below a reproducible example :


#---.

counttt <- 0

`[[.MYCLASS` = function(x, ...) {
   counttt <<- counttt + 1
   # browser()
   x = NextMethod()
   return(x)
}

df <- as.data.frame(matrix(1:20, nrow=5))
class(df) <- c("MYCLASS","data.frame")
counttt

# The same occurs when using structure(, class=) or attr(,"class")<-
df <- as.data.frame(matrix(1:20, nrow=5))
df <- structure(df, class=c("MYCLASS","data.frame"))
attr(df, "class") <- c("MYCLASS","data.frame")

#---.

Why in this example `class<-` is calling  `[[.MYCLASS` 9 times ?

Is there a way to avoid `class<-` to call `[[.MYCLASS` ?


Thank you in advance for your help and suggestions.


This is what I see:


> counttt <- 0
>
> `[[.MYCLASS` = function(x, ...) {
+   counttt <<- counttt + 1
+   # browser()
+   x = NextMethod()
+   return(x)
+ }
>
> df <- as.data.frame(matrix(1:20, nrow=5))
> class(df) <- c("MYCLASS","data.frame")
> counttt
[1] 0

So there's something else going on in your system.  Maybe post 
sessionInfo()?


Duncan Murdoch

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

Re: [Rd] Possible bug in `class<-` when a class-specific '[[.' method is defined

[Michael Lawrence via R-devel]

I'm unable to reproduce this with R 3.6.1. Which version are you
using? Is this a fresh session?

On Mon, Jul 15, 2019 at 3:25 AM Ghiggi Gionata  wrote:
>
> Hi all !
>
> I noticed a strange behaviour of the function `class<-` when a class-specific 
> '[[.' method is defined.
>
> Here below a reproducible example :
>
>
> #---.
>
> counttt <- 0
>
> `[[.MYCLASS` = function(x, ...) {
>   counttt <<- counttt + 1
>   # browser()
>   x = NextMethod()
>   return(x)
> }
>
> df <- as.data.frame(matrix(1:20, nrow=5))
> class(df) <- c("MYCLASS","data.frame")
> counttt
>
> # The same occurs when using structure(, class=) or attr(,"class")<-
> df <- as.data.frame(matrix(1:20, nrow=5))
> df <- structure(df, class=c("MYCLASS","data.frame"))
> attr(df, "class") <- c("MYCLASS","data.frame")
>
> #---.
>
> Why in this example `class<-` is calling  `[[.MYCLASS` 9 times ?
>
> Is there a way to avoid `class<-` to call `[[.MYCLASS` ?
>
>
> Thank you in advance for your help and suggestions.
>
> Gionata
>
>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
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: [R-pkg-devel] Fwd: package submission: parallel problem

[Iñaki Ucar]

On Mon, 15 Jul 2019 at 12:24, Ronan GRIOT  wrote:
>
> Dear R developpers,
> I submitted a package involving some parallel functions.
>
> I received this error message:
>
> Error in .check_ncores(length(names)) : 30 simultaneous processes spawned
>
> I read that CRAN only pass the test if 2 cores are used.
> However, in my function, I use this command line:
>
> parallel::makeCluster(parallel::detectCores() - 2)
>
> I try to fit the power of each computer by allowing all the cores except 2
> (to keep other software running).
>
> My question is: What I have to do? Limiting the number of cores at 2 to
> pass the CRAN requirements? Or let "detectCores() - 2" to allow for more
> cores for multi-cores computer but add a restriction to pass the tests?

By *default*, the number of cores should be 2 at most, as you said.
But this doesn't mean that you cannot allow the user to change that
option to increase them.

See, e.g., what parallel::makeForkCluster does:

function (nnodes = getOption("mc.cores", 2L), ...)

Iñaki

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

[Rd] Potential bug with data.frame replacement

[Benjamin Jean-Marie Tremblay]

Dear R-devel,

I have encountered a crash-inducing scenario and would like to enquire as to
whether this would be considered a bug. To reproduce the crash:

X <- sample(letters, 3000, TRUE)
D <- data.frame(X, 1:3000, X, X, X, X, X)
D$X1.3000 <- paste0("GSM", D)

The reason why I'm not sure if this would be considered a bug is because I
typed this by accident, when what I meant was:

D$X1.3000 <- paste0("GSM", D$X1.3000)

I can never image a scenario where I would intentionally perform the former.

This issue seems to have something to do with the size of the data.frame, as
smaller examples will work fine:

D <- data.frame(A = 1:10, B = letters[1:10])
D$A <- paste0("A", D)

Also just doing the paste0 part without trying to replace a data.frame column
not crash R for me.

I can submit this on Bugzilla should this be deemed sufficiently buggy.

I am running 3.6.0 on macOS (x86_64-apple-darwin15.6.0).

Sincerely,

B.T.

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

[Rd] Convert STRSXP or INTSXP to factor

[Morgan Morgan]

Hi,

Using the R C PAI, is there a way to convert to convert STRSXP or INTSXP to
factor.

The idea would be to do in C something similar to the "factor" function
(example below):

> letters[1:5]
# [1] "a" "b" "c" "d" "e"

> factor(letters[1:5])
# [1] a b c d e
# Levels: a b c d e

There is the function setAttrib the levels of a SXP however when returned
to R the object is of type character not factor. Ideally what i would like
to return from the C function is the same output as above when the input is
of type character.

Please let me if you need more informations.
Thank you
Best regards
Morgan

[[alternative HTML version deleted]]

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

[Rd] Unexpected behaviour when comparing (==) long quoted expressions

[Daniel Chen]

Hi everyone:

I’m one of the interns at RStudio this summer working on a project that 
helps teachers grade student code. I found an unexpected behaviour with 
the |==| operator when comparing |quote|d expressions.

Example 1:

|u <- quote(tidyr::gather(key = key, value = value, 
new_sp_m014:newrel_f65, na.rm = TRUE)) s <- quote(tidyr::gather(key = 
key, value = value, new_sp_m014:newrel_f65, na.rm = FALSE)) u == s # 
TRUE u <- quote(tidyr::gather(key = key, value = value, na.rm = TRUE)) s 
<- quote(tidyr::gather(key = key, value = value, na.rm = FALSE)) u == s 
# FALSE |

Example 2:

|u <- 
quote(f(x123456789012345678901234567890123456789012345678901234567890, 
1)) s <- 
quote(f(x123456789012345678901234567890123456789012345678901234567890, 
2)) u == s #> [1] TRUE |

Winston Chang pointed out in the help page for |==|:

Language objects such as symbols and calls are deparsed to character
strings before comparison.

and in the source code that does the comparison [1] shows that It 
deparses each language object and then only extracts the first element 
from the resulting character vector:

|SET_STRING_ELT(tmp, 0, (iS) ? PRINTNAME(x) : STRING_ELT(deparse1(x, 0, 
DEFAULTDEPARSE), 0)); |

Is this a fix that needs to happen within the |==| documentation? or an 
actual bug with the operator?

For more context the original issue we had is here: 
https://github.com/rstudio-education/grader/issues/28

Workaround:

You can get around this issue by using |all.equal| or |identical|

|u <- quote(tidyr::gather(key = key, value = value, 
new_sp_m014:newrel_f65, na.rm = TRUE)) s <- quote(tidyr::gather(key = 
key, value = value, new_sp_m014:newrel_f65, na.rm = FALSE)) u == s # 
TRUE all.equal(u, s) # "target, current do not match when deparsed" 
identical(u, s) # FALSE |

Thanks,

Dan

[1] 
https://github.com/wch/r-source/blob/e647f78cb85282263f88ea30c6337b77a30743d9/src/main/relop.c#L140-L155

​

[[alternative HTML version deleted]]

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

[Rd] Possible bug in `class<-` when a class-specific '[[.' method is defined

[Ghiggi Gionata]

Hi all !

I noticed a strange behaviour of the function `class<-` when a class-specific 
'[[.' method is defined.

Here below a reproducible example :


#---.

counttt <- 0

`[[.MYCLASS` = function(x, ...) {
  counttt <<- counttt + 1
  # browser()
  x = NextMethod()
  return(x)
}

df <- as.data.frame(matrix(1:20, nrow=5))
class(df) <- c("MYCLASS","data.frame")
counttt

# The same occurs when using structure(, class=) or attr(,"class")<-
df <- as.data.frame(matrix(1:20, nrow=5))
df <- structure(df, class=c("MYCLASS","data.frame"))
attr(df, "class") <- c("MYCLASS","data.frame")

#---.

Why in this example `class<-` is calling  `[[.MYCLASS` 9 times ?

Is there a way to avoid `class<-` to call `[[.MYCLASS` ?


Thank you in advance for your help and suggestions.

Gionata



[[alternative HTML version deleted]]

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

Re: [Rd] MacOS parallel::makeCluster fails

[Dominik Leutnant]

Hi Thomas,

thanks for your reply (and thanks for your patience...).
I am now  using the following minimal reprex:

> library(parallel)
> cl <- makeCluster(2L)

I freshly started the machine and did not open any other app. Just R.app 
(3.6.1).

After executing the second line of code, R seems to hang infinitely and does 
not respond.
The R process itself uses almost no CPU.

Unfortunately, I do not have any experience with neither "Sock_listen"  nor 
"dtruss".
Is there an example somewhere available?

Best
Dominik




Am 05.06.19, 10:18 schrieb "Tomas Kalibera" :

Hi Dominik,

from the output, the master process could not "listen" on the port where 
it expects a connection from the worker. We need to find out why. I'd 
recommend first to create a minimal reproducible example (and one that 
does not use future, only parallel, and a minimal number of threads, 
ideally just 2). Then I'd recommend to check if the problem still exists 
with R-devel. Then I'd check if the problem happens in all invocations, 
even after reboots, on a clean system, without many running applications 
- if it does, this is good news. Then you could post such example and we 
could help more - if we can reproduce on our system indeed we could 
debug, if not there could at least be more directed advice on how to 
debug on your side. What I'd do myself if I could reproduce on my system 
would be instrument R around Sock_listen in internet module to see 
exactly what has failed with which error. Maybe dtruss would help too, 
but instrumenting may be easier. The earlier problem you mention has 
never been diagnosed (it was only intermittent on the reporter's 
machine, we could not reproduce on our systems, and despite a lot of 
effort on our side and on the reporter's, we could not reliably 
diagnose). In principle, it could be some race condition in R (one has 
been fixed since the previous report), but especially if it is 
deterministic it would more likely be some OS limit on your system. You 
could of course try playing with OS limits, on the number of open files, 
etc, with changing the port number (port= option), etc, but I would 
recommend the systematic approach of debugging the cause.

Best
Tomas

On 6/4/19 10:45 AM, Dominik Leutnant wrote:
> Hi all,
>
> The call parallel::makeCluster(1L) hangs infinitely on my MacOS machine 
which seems to be already reported by some people (e.g., 
https://stat.ethz.ch/pipermail/r-devel/2018-February/075565.html).
> However, the solutions posted on SO, GH or R-devel do not work in my case.
>
> So far, I unsuccessfully tested …
>
>1.  Couple of reboots
>2.  Adding 192.0.0.1 to /etc/hosts
>3.  Using R.app instead of RStudio.app
>4.  Turn off the firewall
>
> Following Hendriks advice, “cl <- future::makeClusterPSOCK(1L, verbose = 
TRUE, timeout = 60)” gives (note: without adding the timeout parameter, R just 
hangs):
>> Sys.setenv(LANGUAGE='en')
>> cl <- future::makeClusterPSOCK(1L, verbose = TRUE, timeout = 60)
> [local output] Workers: [n = 1] ‘localhost’
> [local output] Base port: 11867
> [local output] Creating node 1 of 1 ...
> [local output] - setting up node
> Testing if worker's PID can be inferred: 
‘'/Library/Frameworks/R.framework/Resources/bin/Rscript' -e 
'try(cat(Sys.getpid(),file="/var/folders/5s/kgm05t2s0_52gz1s445mnlgwgn/T//RtmpZp1RX6/future.parent=835.3434fe0c5c6.pid"),
 silent = TRUE)' -e 
"file.exists('/var/folders/5s/kgm05t2s0_52gz1s445mnlgwgn/T//RtmpZp1RX6/future.parent=835.3434fe0c5c6.pid')"’
> - Possible to infer worker's PID: TRUE
> [local output] Starting worker #1 on ‘localhost’: 
'/Library/Frameworks/R.framework/Resources/bin/Rscript' 
--default-packages=datasets,utils,grDevices,graphics,stats,methods -e 
'try(cat(Sys.getpid(),file="/var/folders/5s/kgm05t2s0_52gz1s445mnlgwgn/T//RtmpZp1RX6/future.parent=835.3434fe0c5c6.pid"),
 silent = TRUE)' -e 'parallel:::.slaveRSOCK()' MASTER=localhost PORT=11867 
OUT=/dev/null TIMEOUT=60 XDR=TRUE
> [local output] - Exit code of system() call: 0
> [local output] Waiting for worker #1 on ‘localhost’ to connect back
> [local output] Detected a warning from socketConnection(): ‘problem in 
listening on this socket’
> Killing worker process (PID 903) if still alive
> Worker (PID 903) was successfully killed: TRUE
> Error in socketConnection("localhost", port = port, server = TRUE, 
blocking = TRUE,  :
>Failed to launch and connect to R worker on local machine ‘localhost’ 
from local machine ‘Dominiks-MBP.local’.
> * The error produced by socketConnection() was: ‘cannot open the 
connection’
> * In addition, socketConnection() produced 1 warning(s):
> - Warning #1: ‘problem in listening on this socket’
> * The localhost socket connection that failed to 

Re: [Rd] Addition of a meta viewport tag to HTML manuals

[Martin Maechler]

> Bob Rudis 
> on Tue, 9 Jul 2019 14:24:24 -0400 writes:

> The addition of a single line:
> 

> at in the  of the R HTML generated manuals would make them much 
easier to read on mobile devices.

> texi2any (which generates the HTML files) is based on long-working Perl 
code that includes many modern HTML elements but does not include this one.

> A Perl one-liner in the install-html: Makefile directive in Makefile.in:

> install-html: installdirs
> @for f in $(OBJECTS_HTML); do \
> if test -f $${f} ; then \
> $(INSTALL_DATA) $${f} "$(DESTDIR)$(rdocdir)/manual"; \
> perl -pi -e 's/\\n fi \
> done

> would insert this (I still need to read Makefile.win to see where it 
should go there) and I'd be glad to create a PR unless folks do not think 
better accessibility on mobile is a good idea.

To the contrary.
Thank you very much, Bob, for bringing this up, here!

> $(PERL) does not seem to be defined but Perl itself is a requirement for 
texi2any so it is definitely something that would work in the current 
installation process. 

> -Bob

Hmm,.. a very long time ago,  perl was an absolute requirement
for building R from the sources, but in the mean time, it's not
been required anymore strictly *).  AFAIK, there are alternative versions
of versions/alternatives to texi2any  (say on Windoze .. or
bizarre Linux distros or non-linux unices), and I'm almost sure
we do not want to require perl explicitly.

We are using R itself in many places for installation things,
but here, it should be possible to use smaller unix tools (such
as 'sed' and 'grep' say) instead.

If you (or someone else) provided a small patch for using those
instead of perl, I don't see a reason not to be grateful and
apply it to the sources.

Thank you once more
Martin


--
*)  perl is mentioned twice in the "R Administration and
Installation" manual:
1. maybe needed for 'install-info'  *if* there's no
  'install-info' command on the system [but on my Fedora and
   probably most "math-y" Linux dist there is a binary]

2. On Windoze, the texinfo 5.x package needs perl

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

Re: [Rd] Format printing inside a matrix

[Martin Maechler]

> Pages, Herve 
> on Mon, 8 Jul 2019 04:32:29 + writes:

> On 7/7/19 17:41, Jialin Ma wrote:
>> Hi Abby,
>> 
>> Thanks a lot for your paraphrasing and your suggestion!
>> 
>> The problem of wrapping the list into a S3/S4 object, i.e. subclassing 
array
>> or matrix, is that one also has to define a bunch of methods for 
subsetting,
>> joining, etc, in order to make it behave like a list array. The reason 
is that
>> most R functions for subsetting, joining, etc. do not preserve class
>> attributes of the input, which is possibly by design.

> Is it? One could argue that a more sensible behavior would be that
> things like `[`(..., drop=FALSE), rbind(), cbind(), etc... preserve
> the class attribute.

> Interestingly t() does that:

> m <- matrix(1:6, nrow=2)
> class(m) <- "foo"

> m
> #  [,1] [,2] [,3]
> # [1,]135
> # [2,]246
> # attr(,"class")
> # [1] "foo"

> t(m)
> #  [,1] [,2]
> # [1,]12
> # [2,]34
> # [3,]56
> # attr(,"class")
> # [1] "foo"

> but not aperm() (which in this case would be expected to be
> equivalent to t()):

> aperm(m, 2:1)
> #  [,1] [,2]
> # [1,]12
> # [2,]34
> # [3,]56

> Reshaping also preserves the class:

> dim(m) <- c(6, 1)
> m
> #  [,1]
> # [1,]1
> # [2,]2
> # [3,]3
> # [4,]4
> # [5,]5
> # [6,]6
> # attr(,"class")
> # [1] "foo"

> So if it makes sense for t() and reshaping, it's not clear why it
> wouldn't for [, aperm(), cbind(), etc...?

> H.

I think I definitely tend to agree for aperm(); all others are
(slightly or much) more dubious to me however :

- `[`: yes probably, but only if drop=FALSE is used, so,
  e.g. dim & dimnames attributes will be kept {modified to the
  new dimensions of course}

- cbind(), rbind():  
Here we are talking about an arbitrary number of arguments,
each potentially with different and partly conflicting
attributes, notably 'class'.
 
Of course there are -- sometimes quite sophisticated -- S3
and S4 methods that may apply here typically ((notably for
specialized matrices, "my" Matrix and Rmpfr packages being
mentioned)).

  For the (internal C code based) default method, a point could
  be made for trying to keep some attributes of the first
  argument; but I'm not convinced really yet that it would be
  wise to change behavior of the (base internal) default method
  for the cbind() / rbind() twin.


>> It is not desirable if a
>> simple matrix subsetting will remove the class attributes of the object.

The sentence above in its generality is wrong, sorry.
Think e.g. of the class  "symmetricMatrix", or imagine "covarianceMatrix"
or similar:  Almost all subsetting will change the most
important "property" of the class and keeping the class
attribute would be clearly internally inconsistent and wrong.
{and also consider that subsetting in R can be with repeated
 indices, say  m[c(1:10, 1:20, 20:1) , ] }


>> There are also many other common functions that are meant to drop the
>> attributes of the input, e.g. lapply, apply -- they are not generics and 
it is
>> not wise to override them.
>> 
>> Overall, introducing a new S3/S4 class often brings some extra price in 
order
>> to maintain the correct behavior,

that is correct

>> which is why I tend to avoid them unless it is necessary.

well, it is never absolutely necessary, I'd say.
{ you could tell your users that your objects must only be
   accessed in one of a few possible ways and all other "access", i.e., 
   function calls with them as arguments is "forbidden" / "undefined" ...

   .. but your users will not follow what you told them, e.g., if
   your objects look closely like other R objects they already
   know very well ...
}

So, I'm convinced good programmers should
 pay the extra price _once_
 for the benefit of their package useRs and often themselves  _forever_
 (after that initial price has been paid).

Martin

>> Best regards,
>> Jialin
>> 
>> On Sunday, July 7, 2019 4:43:59 PM PDT Abby Spurdle wrote:
>>> contains an array of question marks, which
>>> isn't helpful.
>>> 
>>> Would it be possible for the print method for both matrices and arrays
>>> (conditional on having a list type), call the format method for each
>>> object, possibly creating a character matrix?
>>> Presumably there are other approaches, but the main thing is that the
>>> output is useful and it's easy for R users to control the way objects 
(in
>>> matrices and arrays) are printed.
>>> 
 Or is there any other place that I can override without introducing a 
new
>>> 
>>> S3 class?
>>> 
>>> In theory, the simplest approach is to redefine 

Re: [Bioc-devel] Problems with MACPET package

[Ioannis Vardaxis]

My seesionInfo:
> sessionInfo()
R Under development (unstable) (2019-07-11 r76823)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS Mojave 10.14.5

And
> BiocManager::install("stringdist")
Bioconductor version 3.10 (BiocManager 1.30.4), R Under development (unstable) 
(2019-07-11 r76823)
Installing package(s) 'stringdist'
Warning: unable to access index for repository 
https://bioconductor.org/packages/3.10/data/annotation/bin/macosx/el-capitan/contrib/3.7:
  cannot open URL 
'https://bioconductor.org/packages/3.10/data/annotation/bin/macosx/el-capitan/contrib/3.7/PACKAGES'
Warning: unable to access index for repository 
https://bioconductor.org/packages/3.10/data/experiment/bin/macosx/el-capitan/contrib/3.7:
  cannot open URL 
'https://bioconductor.org/packages/3.10/data/experiment/bin/macosx/el-capitan/contrib/3.7/PACKAGES'
Warning: unable to access index for repository 
https://cran.rstudio.com/bin/macosx/el-capitan/contrib/3.7:
  cannot open URL 
'https://cran.rstudio.com/bin/macosx/el-capitan/contrib/3.7/PACKAGES'
Package which is only available in source form, and may need compilation of 
C/C++/Fortran: ‘stringdist’
Do you want to attempt to install these from sources? (Yes/no/cancel) Yes


Also, I cannot such to RELEASE_3_10 because I get error:

$git checkout RELEASE_3_10
error: pathspec 'RELEASE_3_10' did not match any file(s) known to git





12. jul. 2019 kl. 16:20 skrev Vincent Carey 
mailto:st...@channing.harvard.edu>>:

It should be possible to get stringdist as a binary package for mac.  provide 
your sessionInfo().

> BiocManager::install("stringdist")
Bioconductor version 3.10 (BiocManager 1.30.4), R 3.6.0 Patched (2019-05-06
  r76460)
Installing package(s) 'stringdist'
trying URL 
'https://cran.rstudio.com/bin/macosx/el-capitan/contrib/3.6/stringdist_0.9.5.2.tgz'
Content type 'application/x-gzip' length 567740 bytes (554 KB)
==
downloaded 554 KB

On Fri, Jul 12, 2019 at 10:13 AM Ioannis Vardaxis 
mailto:ioannis.varda...@ntnu.no>> wrote:
I have changed the S4methods now and the Rcheck is working fine locally on my 
machine.

I cannot run BiocCheck because I cannot install it on my Mac anymore. It 
depends on a package named stringdist, which cannot be installed in my Mac. I 
get an error:
clang: error: unsupported option '-fopenmp'

However I have pushed the changes to the repository now and we will see if the 
devel version gets fixed.

Best,
Ioannis


> 8. jul. 2019 kl. 11:20 skrev Martin Morgan 
> mailto:mtmorgan.b...@gmail.com>>:
>
> Under bioc-devel, I ran
>
>  MACPET/vignettes$ R CMD Stangle MACPET.Rmd
>
> and then in R
>
>  source("MACPET.R", echo = TRUE)
>
> where the problem manifests as
>
>> summary(MACPET_pintraData,heatmap=TRUE)
>  Error in .Vector_summary(object, ...) : unused argument (heatmap = TRUE)
>
> You have the S4 class
>
>> getClass(class(MACPET_pintraData))
> Class "PIntra" [package "MACPET"]
>
> Slots:
>
> Name:anchor1   anchor2   regions NAMES
> Class:   integer   integer   GRanges character_OR_NULL
>
> Name:elementMetadata  metadata
> Class: DataFrame  list
>
> Extends:
> Class "GInteractions", directly
> Class "Vector", by class "GInteractions", distance 2
> Class "Annotated", by class "GInteractions", distance 3
> Class "vector_OR_Vector", by class "GInteractions", distance 3
>
> that extends 'Vector'.
>
> You have an S3 generic summary.PIntra, but I guess recently S4Vectors 
> introduced an S4 method summary,Vector-method. Probably the dispatch system 
> sees the inherited S4 method before your S3 method, and the solution is to 
> change your S3 method to S4. Best practice would do this for all S3 methods 
> defined on S4 classes.
>
> Martin
>
> On 7/8/19, 10:46 AM, "Bioc-devel on behalf of Ioannis Vardaxis" 
> mailto:bioc-devel-boun...@r-project.org> on 
> behalf of ioannis.varda...@ntnu.no> wrote:
>
>Hey,
>
>My package (MACPET) has been crashing lately. The error I get is from the 
> vignette:
>
>
>Error in .Vector_summary(object, ...) : unused argument (heatmap = TRUE)
>Calls:  ... withCallingHandlers -> withVisible -> eval -> eval 
> -> summary -> summary
>Execution halted
>
>When I call the summary function which is specified on one of my classes.
>
>I realised that for some reason all the methods that I had created and 
> worked fine for every class, they just don’t work anymore.
>
>I have no idea what causes the error..
>
>
>Best,
>
>Ioannis
>
>   [[alternative HTML version deleted]]
>
>___
>Bioc-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

___
Bioc-devel@r-project.org mailing list

Re: [R-pkg-devel] Warning about "serialize/load".

[Tomas Kalibera]

On 7/15/19 2:06 AM, Travers Ching wrote:

I think the major change was saving of alt-rep objects efficiently.
Example save(1:1e8, file=...) is very efficient.

I'm not sure if that is all that changed it, but I couldn't find
documentation on the differences.


Yes, format version 3 provides custom serialization for altrep objects, 
so that it can e.g. serialize efficiently integer sequences. In 
addition, it keeps record of the current native encoding when 
serializing strings, so that it can convert strings with unflagged 
encoding when de-serializing them with different native encoding. So for 
example if a string with current native encoding X (not being latin1, 
and indeed not UTF-8) on Windows gets serialized, and then de-serialized 
on Linux running UTF-8 as current native encoding, it would be converted 
to UTF-8. In previous versions, it would be misinterpreted.


Best
Tomas



For maximum compatibility in a package, personally I would use version 2.


On Sun, Jul 14, 2019 at 4:52 PM Rolf Turner  wrote:


In a package (say "clyde") that I am building I save a number of
datasets in clyde/data via something like:

save(melvin,file="~//clyde/data/melvin.rda")

When I build "clyde" I now get warnings like unto:


uWARNING: Added dependency on R >= 3.5.0 because serialized objects in
serialize/load version 3 cannot be read in older versions of R.
File(s) containing such objects: 'clyde/data/melvin.rda'

If I put the argument "version=2" into my save() call, the warnings go
away.

What are the implications of this?

What are the consequences/what is the downside of setting version=2?

What are the consequences/what is the downside of adding the dependency
on R >= 3.5.0 into my DESCRIPTION file?

Who gets shafted by each of these two possibilities?

Which is recommended?

Grateful for any pearls of wisdom.

cheers,

Rolf Turner

--
Honorary Research Fellow
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276

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


[[alternative HTML version deleted]]

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


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