Re: [Bioc-devel] Question about BiocGeneric::order

[Hervé Pagès]

On 05/11/2017 06:44 PM, Hervé Pagès wrote:

Hi Michael,

On 05/11/2017 03:27 PM, Michael Lawrence wrote:

There is a bug in S4Vectors, but thanks to an R 3.4 bug in the methods
package (recently fixed in devel), the bug is masked. So, we should
fix S4Vectors. The problem is that order,Rle has a default for the
'method' argument that differs from that of the generic. Since R 3.3,
base::order() is smart enough to basically do the same thing as
order,Rle(). I'll go ahead and remove the method.


Note that base::order() is much slower than the method for Rle objects:


Forgot to copy/paste this:

  library(S4Vectors)
  x <- Rle(sample(25L, 50L, replace=TRUE) - 8L,
   sample(13L, 50L, replace=TRUE))




system.time(oo1 <- order(x))

   user  system elapsed
  0.018   0.000   0.018


system.time(oo2 <- base::order(x))

   user  system elapsed
  1.089   0.000   1.103


identical(oo1, oo2)

[1] TRUE

Looks like by default, base::order() does not pick up the fastest
method (radix):


system.time(oo2 <- base::order(x, method="radix"))

   user  system elapsed
  0.020   0.000   0.019


and to provide my sessionInfo():

> sessionInfo()
R version 3.4.0 Patched (2017-04-26 r72630)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.5 LTS

Matrix products: default
BLAS: /home/hpages/R/R-3.4.r72630/lib/libRblas.so
LAPACK: /home/hpages/R/R-3.4.r72630/lib/libRlapack.so

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

attached base packages:
[1] parallel  stats4stats graphics  grDevices utils datasets
[8] methods   base

other attached packages:
[1] S4Vectors_0.15.2BiocGenerics_0.23.0

loaded via a namespace (and not attached):
[1] compiler_3.4.0 tools_3.4.0

H.



H.



Michael

On Thu, May 11, 2017 at 1:29 PM, Ou, Jianhong
 wrote:

Thank you Hervé,

I got that. Good to know that BioC 3.6 require R 3.4.0.

Yours Sincerely,

Jianhong Ou

TEL: 508-856-5379
LRB 608
Bioinformatician of Bioinformatics core at
Department of Molecular, Cell and Cancer Biology
UMASS Medical School
364 Plantation Street Worcester,
MA 01605

Confidentiality Notice:
This e-mail message, including any attachments, is for the sole use
of the intended recipient(s) and may contain confidential,
proprietary and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender immediately and destroy or
permanently delete all copies of the original message.





On 5/11/17, 4:25 PM, "Hervé Pagès"  wrote:

Hi Jianhong,

I can't reproduce this but I'm using R 3.4.0.
You seem to be using Bioc devel (aka BioC 3.6) with R devel.
This is not supported. Both, BioC 3.5 (current release) and
BioC 3.6 require R 3.4.0.

Cheers,
H.


On 05/11/2017 01:11 PM, Ou, Jianhong wrote:
> I got error when I try order for Rle object by following codes:
>
> library("BiocGenerics")
> library(XVector)
> order(Rle(1))
> ## Error in match.arg(method) : 'arg' must be of length 1
>
>> sessionInfo()
> R Under development (unstable) (2017-05-10 r72667)
> Platform: x86_64-apple-darwin16.5.0 (64-bit)
> Running under: macOS Sierra 10.12.4
>
> Matrix products: default
> BLAS:
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.dylib

> LAPACK:
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib

>
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>
> attached base packages:
> [1] stats4parallel  stats graphics  grDevices utils
datasets
> [8] methods   base
>
> other attached packages:
> [1] XVector_0.17.0  IRanges_2.11.2  S4Vectors_0.15.1
> [4] BiocGenerics_0.23.0
>
> loaded via a namespace (and not attached):
> [1] zlibbioc_1.23.0 compiler_3.5.0
>
> Is this a bug? Or I should always add method argument?
>
> Yours Sincerely,
>
> Jianhong Ou
>
> TEL: 508-856-5379
> LRB 608
> Bioinformatician of Bioinformatics core at
> Department of Molecular, Cell and Cancer Biology
> UMASS Medical School
> 364 Plantation Street Worcester,
> MA 01605
>
> Confidentiality Notice:
> This e-mail message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential,
proprietary and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender immediately and destroy or
permanently delete all copies of the original message.
>
>

Re: [Bioc-devel] Question about BiocGeneric::order

[Hervé Pagès]

Hi Michael,

On 05/11/2017 03:27 PM, Michael Lawrence wrote:

There is a bug in S4Vectors, but thanks to an R 3.4 bug in the methods
package (recently fixed in devel), the bug is masked. So, we should
fix S4Vectors. The problem is that order,Rle has a default for the
'method' argument that differs from that of the generic. Since R 3.3,
base::order() is smart enough to basically do the same thing as
order,Rle(). I'll go ahead and remove the method.


Note that base::order() is much slower than the method for Rle objects:

> system.time(oo1 <- order(x))
   user  system elapsed
  0.018   0.000   0.018

> system.time(oo2 <- base::order(x))
   user  system elapsed
  1.089   0.000   1.103

> identical(oo1, oo2)
[1] TRUE

Looks like by default, base::order() does not pick up the fastest
method (radix):

> system.time(oo2 <- base::order(x, method="radix"))
   user  system elapsed
  0.020   0.000   0.019

H.



Michael

On Thu, May 11, 2017 at 1:29 PM, Ou, Jianhong  wrote:

Thank you Hervé,

I got that. Good to know that BioC 3.6 require R 3.4.0.

Yours Sincerely,

Jianhong Ou

TEL: 508-856-5379
LRB 608
Bioinformatician of Bioinformatics core at
Department of Molecular, Cell and Cancer Biology
UMASS Medical School
364 Plantation Street Worcester,
MA 01605

Confidentiality Notice:
This e-mail message, including any attachments, is for the sole use of the 
intended recipient(s) and may contain confidential, proprietary and privileged 
information. Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender 
immediately and destroy or permanently delete all copies of the original 
message.





On 5/11/17, 4:25 PM, "Hervé Pagès"  wrote:

Hi Jianhong,

I can't reproduce this but I'm using R 3.4.0.
You seem to be using Bioc devel (aka BioC 3.6) with R devel.
This is not supported. Both, BioC 3.5 (current release) and
BioC 3.6 require R 3.4.0.

Cheers,
H.


On 05/11/2017 01:11 PM, Ou, Jianhong wrote:
> I got error when I try order for Rle object by following codes:
>
> library("BiocGenerics")
> library(XVector)
> order(Rle(1))
> ## Error in match.arg(method) : 'arg' must be of length 1
>
>> sessionInfo()
> R Under development (unstable) (2017-05-10 r72667)
> Platform: x86_64-apple-darwin16.5.0 (64-bit)
> Running under: macOS Sierra 10.12.4
>
> Matrix products: default
> BLAS: 
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.dylib
> LAPACK: 
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib
>
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>
> attached base packages:
> [1] stats4parallel  stats graphics  grDevices utils datasets
> [8] methods   base
>
> other attached packages:
> [1] XVector_0.17.0  IRanges_2.11.2  S4Vectors_0.15.1
> [4] BiocGenerics_0.23.0
>
> loaded via a namespace (and not attached):
> [1] zlibbioc_1.23.0 compiler_3.5.0
>
> Is this a bug? Or I should always add method argument?
>
> Yours Sincerely,
>
> Jianhong Ou
>
> TEL: 508-856-5379
> LRB 608
> Bioinformatician of Bioinformatics core at
> Department of Molecular, Cell and Cancer Biology
> UMASS Medical School
> 364 Plantation Street Worcester,
> MA 01605
>
> Confidentiality Notice:
> This e-mail message, including any attachments, is for the sole use of 
the intended recipient(s) and may contain confidential, proprietary and privileged 
information. Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender 
immediately and destroy or permanently delete all copies of the original message.
>
>
>
>   [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FhYaKPjNM3nCK5wrqNrek8IgmU7YlJH8B77AMM77j7U=N1wtJXFb6nsvQncKFe8tgzi_q8NunVLhu-gJoQA_Co8=
>

--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319


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

Re: [Bioc-devel] Question about BiocGeneric::order

[Michael Lawrence]

There is a bug in S4Vectors, but thanks to an R 3.4 bug in the methods
package (recently fixed in devel), the bug is masked. So, we should
fix S4Vectors. The problem is that order,Rle has a default for the
'method' argument that differs from that of the generic. Since R 3.3,
base::order() is smart enough to basically do the same thing as
order,Rle(). I'll go ahead and remove the method.

Michael

On Thu, May 11, 2017 at 1:29 PM, Ou, Jianhong  wrote:
> Thank you Hervé,
>
> I got that. Good to know that BioC 3.6 require R 3.4.0.
>
> Yours Sincerely,
>
> Jianhong Ou
>
> TEL: 508-856-5379
> LRB 608
> Bioinformatician of Bioinformatics core at
> Department of Molecular, Cell and Cancer Biology
> UMASS Medical School
> 364 Plantation Street Worcester,
> MA 01605
>
> Confidentiality Notice:
> This e-mail message, including any attachments, is for the sole use of the 
> intended recipient(s) and may contain confidential, proprietary and 
> privileged information. Any unauthorized review, use, disclosure or 
> distribution is prohibited. If you are not the intended recipient, please 
> contact the sender immediately and destroy or permanently delete all copies 
> of the original message.
>
>
>
>
>
> On 5/11/17, 4:25 PM, "Hervé Pagès"  wrote:
>
> Hi Jianhong,
>
> I can't reproduce this but I'm using R 3.4.0.
> You seem to be using Bioc devel (aka BioC 3.6) with R devel.
> This is not supported. Both, BioC 3.5 (current release) and
> BioC 3.6 require R 3.4.0.
>
> Cheers,
> H.
>
>
> On 05/11/2017 01:11 PM, Ou, Jianhong wrote:
> > I got error when I try order for Rle object by following codes:
> >
> > library("BiocGenerics")
> > library(XVector)
> > order(Rle(1))
> > ## Error in match.arg(method) : 'arg' must be of length 1
> >
> >> sessionInfo()
> > R Under development (unstable) (2017-05-10 r72667)
> > Platform: x86_64-apple-darwin16.5.0 (64-bit)
> > Running under: macOS Sierra 10.12.4
> >
> > Matrix products: default
> > BLAS: 
> /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.dylib
> > LAPACK: 
> /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib
> >
> > locale:
> > [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
> >
> > attached base packages:
> > [1] stats4parallel  stats graphics  grDevices utils datasets
> > [8] methods   base
> >
> > other attached packages:
> > [1] XVector_0.17.0  IRanges_2.11.2  S4Vectors_0.15.1
> > [4] BiocGenerics_0.23.0
> >
> > loaded via a namespace (and not attached):
> > [1] zlibbioc_1.23.0 compiler_3.5.0
> >
> > Is this a bug? Or I should always add method argument?
> >
> > Yours Sincerely,
> >
> > Jianhong Ou
> >
> > TEL: 508-856-5379
> > LRB 608
> > Bioinformatician of Bioinformatics core at
> > Department of Molecular, Cell and Cancer Biology
> > UMASS Medical School
> > 364 Plantation Street Worcester,
> > MA 01605
> >
> > Confidentiality Notice:
> > This e-mail message, including any attachments, is for the sole use of 
> the intended recipient(s) and may contain confidential, proprietary and 
> privileged information. Any unauthorized review, use, disclosure or 
> distribution is prohibited. If you are not the intended recipient, please 
> contact the sender immediately and destroy or permanently delete all copies 
> of the original message.
> >
> >
> >
> >   [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FhYaKPjNM3nCK5wrqNrek8IgmU7YlJH8B77AMM77j7U=N1wtJXFb6nsvQncKFe8tgzi_q8NunVLhu-gJoQA_Co8=
> >
>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpa...@fredhutch.org
> Phone:  (206) 667-5791
> Fax:(206) 667-1319
>
>
> ___
> 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: [Bioc-devel] Question about BiocGeneric::order

[Ou, Jianhong]

Thank you Hervé,

I got that. Good to know that BioC 3.6 require R 3.4.0.

Yours Sincerely,

Jianhong Ou

TEL: 508-856-5379
LRB 608
Bioinformatician of Bioinformatics core at
Department of Molecular, Cell and Cancer Biology
UMASS Medical School
364 Plantation Street Worcester,
MA 01605
 
Confidentiality Notice:
This e-mail message, including any attachments, is for the sole use of the 
intended recipient(s) and may contain confidential, proprietary and privileged 
information. Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender 
immediately and destroy or permanently delete all copies of the original 
message.





On 5/11/17, 4:25 PM, "Hervé Pagès"  wrote:

Hi Jianhong,

I can't reproduce this but I'm using R 3.4.0.
You seem to be using Bioc devel (aka BioC 3.6) with R devel.
This is not supported. Both, BioC 3.5 (current release) and
BioC 3.6 require R 3.4.0.

Cheers,
H.


On 05/11/2017 01:11 PM, Ou, Jianhong wrote:
> I got error when I try order for Rle object by following codes:
>
> library("BiocGenerics")
> library(XVector)
> order(Rle(1))
> ## Error in match.arg(method) : 'arg' must be of length 1
>
>> sessionInfo()
> R Under development (unstable) (2017-05-10 r72667)
> Platform: x86_64-apple-darwin16.5.0 (64-bit)
> Running under: macOS Sierra 10.12.4
>
> Matrix products: default
> BLAS: 
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.dylib
> LAPACK: 
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib
>
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>
> attached base packages:
> [1] stats4parallel  stats graphics  grDevices utils datasets
> [8] methods   base
>
> other attached packages:
> [1] XVector_0.17.0  IRanges_2.11.2  S4Vectors_0.15.1
> [4] BiocGenerics_0.23.0
>
> loaded via a namespace (and not attached):
> [1] zlibbioc_1.23.0 compiler_3.5.0
>
> Is this a bug? Or I should always add method argument?
>
> Yours Sincerely,
>
> Jianhong Ou
>
> TEL: 508-856-5379
> LRB 608
> Bioinformatician of Bioinformatics core at
> Department of Molecular, Cell and Cancer Biology
> UMASS Medical School
> 364 Plantation Street Worcester,
> MA 01605
>
> Confidentiality Notice:
> This e-mail message, including any attachments, is for the sole use of 
the intended recipient(s) and may contain confidential, proprietary and 
privileged information. Any unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended recipient, please 
contact the sender immediately and destroy or permanently delete all copies of 
the original message.
>
>
>
>   [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FhYaKPjNM3nCK5wrqNrek8IgmU7YlJH8B77AMM77j7U=N1wtJXFb6nsvQncKFe8tgzi_q8NunVLhu-gJoQA_Co8=
>

-- 
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319


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

Re: [Bioc-devel] Question about BiocGeneric::order

[Hervé Pagès]

Hi Jianhong,

I can't reproduce this but I'm using R 3.4.0.
You seem to be using Bioc devel (aka BioC 3.6) with R devel.
This is not supported. Both, BioC 3.5 (current release) and
BioC 3.6 require R 3.4.0.

Cheers,
H.


On 05/11/2017 01:11 PM, Ou, Jianhong wrote:

I got error when I try order for Rle object by following codes:

library("BiocGenerics")
library(XVector)
order(Rle(1))
## Error in match.arg(method) : 'arg' must be of length 1


sessionInfo()

R Under development (unstable) (2017-05-10 r72667)
Platform: x86_64-apple-darwin16.5.0 (64-bit)
Running under: macOS Sierra 10.12.4

Matrix products: default
BLAS: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.dylib
LAPACK: 
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

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

other attached packages:
[1] XVector_0.17.0  IRanges_2.11.2  S4Vectors_0.15.1
[4] BiocGenerics_0.23.0

loaded via a namespace (and not attached):
[1] zlibbioc_1.23.0 compiler_3.5.0

Is this a bug? Or I should always add method argument?

Yours Sincerely,

Jianhong Ou

TEL: 508-856-5379
LRB 608
Bioinformatician of Bioinformatics core at
Department of Molecular, Cell and Cancer Biology
UMASS Medical School
364 Plantation Street Worcester,
MA 01605

Confidentiality Notice:
This e-mail message, including any attachments, is for the sole use of the 
intended recipient(s) and may contain confidential, proprietary and privileged 
information. Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender 
immediately and destroy or permanently delete all copies of the original 
message.



[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FhYaKPjNM3nCK5wrqNrek8IgmU7YlJH8B77AMM77j7U=N1wtJXFb6nsvQncKFe8tgzi_q8NunVLhu-gJoQA_Co8=



--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

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

[Bioc-devel] Question about BiocGeneric::order

[Ou, Jianhong]

I got error when I try order for Rle object by following codes:

library("BiocGenerics")
library(XVector)
order(Rle(1))
## Error in match.arg(method) : 'arg' must be of length 1

> sessionInfo()
R Under development (unstable) (2017-05-10 r72667)
Platform: x86_64-apple-darwin16.5.0 (64-bit)
Running under: macOS Sierra 10.12.4

Matrix products: default
BLAS: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.dylib
LAPACK: 
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

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

other attached packages:
[1] XVector_0.17.0  IRanges_2.11.2  S4Vectors_0.15.1
[4] BiocGenerics_0.23.0

loaded via a namespace (and not attached):
[1] zlibbioc_1.23.0 compiler_3.5.0

Is this a bug? Or I should always add method argument?

Yours Sincerely,

Jianhong Ou

TEL: 508-856-5379
LRB 608
Bioinformatician of Bioinformatics core at
Department of Molecular, Cell and Cancer Biology
UMASS Medical School
364 Plantation Street Worcester,
MA 01605

Confidentiality Notice:
This e-mail message, including any attachments, is for the sole use of the 
intended recipient(s) and may contain confidential, proprietary and privileged 
information. Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender 
immediately and destroy or permanently delete all copies of the original 
message.



[[alternative HTML version deleted]]

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

Re: [Rd] bug report: nlme model-fitting crashes with R 3.4.0

[Martyn Plummer]

On Thu, 2017-05-11 at 12:23 +, Martyn Plummer wrote:
> On Thu, 2017-05-11 at 06:37 -0500, Dirk Eddelbuettel wrote:
> > On 11 May 2017 at 10:17, Erwan Le Pennec wrote:
> > >  Dear all,
> > > 
> > >  I've stumbled a similar issue with the package cluster when 
> > > compiling the 3.4.0 version with the settings of Fedora RPM
> > > specs. 
> > > Compiling R with the default setting of configure yields a
> > > version
> > > that 
> > > works for cluster... and nlme.
> > > 
> > >  I did not find the exact option that was the cause of this
> > > issue 
> > > but I'm willing to help.
> > > 
> > >  Erwan
> > > 
> > > PS: This is the reason why R is still at version 3.3.3 on the
> > > Fedora 
> > > distribution.
> > > 
> > > On 10/05/17 22:59, Langbehn, Douglas wrote:
> > > > lme() and gls() models from the nlme package are all crashing
> > > > with R.3.4.0. Identical code ran correctly, without error in R
> > > > 3.3.3 and earlier versions.  The behavior is easily
> > > > demonstrated
> > > > using one of the examples form the lme() help file, along with
> > > > two simple variants. I have commented the errors generated by
> > > > these calls, as well as the lines of code generating them, in
> > > > the
> > > > code example below.
> > > > 
> > > > As of today, this bug had not been reported on the R Bugzilla
> > > > page. I could not submit this report directly to the page
> > > > because
> > > > I am not a member, and , as explained in the "Reporting Bugs"
> > > > link from the  R home page, membership has now been closed due
> > > > to
> > > > spamming problems..
> > > > 
> > > > ###
> > > > ##
> > > > ###
> > > > library(nlme)
> > > > #Using version 3.1-131
> > > > #Windows 7 64-bit operating system
> > > > 
> > > > fm2 <- lme(distance ~ age + Sex, data = Orthodont, random = ~
> > > > 1)
> > > > 
> > > > # Error in array(c(rep(1, p), .C(inner_perc_table,
> > > > as.double(X),
> > > > as.integer(unlist(grps)),  :
> > > > # object 'inner_perc_table' not found
> > 
> > That is a known issue with R 3.4.0 -- see NEWS.
> > 
> > Packages using .C and .Fortran _must_ be recompiled for R 3.4.0. If
> > and when
> > you do, the example will work again.
> > 
> > Dirk
> 
> However, the issue raised by Erwan on Fedora is a real bug which
> affects at least two recommended packages. I know the cause of the
> problem and am trying to find out how many packages are affected.

Sorry for the false alarm. Dirk is right and the problem is the binary
incompatibility between 3.4.0 and 3.3.3.

If you try building the R source RPM with R 3.4.0 *without using a
chroot* then you get interference from the installed version of R (i.e.
3.3.3) when the %check section of the spec file is run. This is not a
bug in the spec file because you are not supposed to build an SRPM this
way.

If you build the SRPM *using mock* (the chroot tool used by Red Hat)
then the build fails for a completely different reason. The chroot is
not set up with time zone information and this triggers one of the
regression tests.

I'm filing a bug report with Red Hat. So hopefully we will see RPMs of
R 3.4.0 for Fedora soon.

Martyn



> Martyn
> __
> 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] R-3.3.3/R-3.4.0 change in sys.call(sys.parent())

[William Dunlap via R-devel]

Here is a case where the current scheme fails:

  > with(datasets::mtcars, xyplot(mpg~wt|gear)$call)
  xyplot(substitute(expr), data, enclos = parent.frame())


Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Thu, May 11, 2017 at 1:09 AM, Deepayan Sarkar 
wrote:

> On Wed, May 10, 2017 at 2:36 AM, William Dunlap via R-devel
>  wrote:
> > Some formula methods for S3 generic functions use the idiom
> > returnValue$call <- sys.call(sys.parent())
> > to show how to recreate the returned object or to use as a label on a
> > plot.  It is often followed by
> >  returnValue$call[[1]] <- quote(myName)
> > E.g., I see it in packages "latticeExtra" and "leaps", and I suspect it
> > used in "lattice" as well.
> >
> > This idiom has not done good things for quite a while (ever?) but I
> noticed
> > while running tests that it acts differently in R-3.4.0 than in R-3.3.3.
> > Neither the old or new behavior is nice.  E.g., in R-3.3.3 we get
> >
> >> parseEval <- function(text, envir) eval(parse(text=text), envir=envir)
> >> parseEval('lattice::xyplot(mpg~hp, data=datasets::mtcars)$call',
> > envir=new.env())
> > xyplot(expr, envir, enclos)
> >
> > and
> >
> >> evalInEnvir <- function(call, envir) eval(call, envir=envir)
> >> evalInEnvir(quote(lattice::xyplot(mpg~hp, data=datasets::mtcars)$call),
> > envir=new.env())
> > xyplot(expr, envir, enclos)
> >
> > while in R-3.4.0 we get
> >> parseEval <- function(text, envir) eval(parse(text=text), envir=envir)
> >> parseEval('lattice::xyplot(mpg~hp, data=datasets::mtcars)$call',
> > envir=new.env())
> > xyplot(parse(text = text), envir = envir)
> >
> > and
> >
> >> evalInEnvir <- function(call, envir) eval(call, envir=envir)
> >> evalInEnvir(quote(lattice::xyplot(mpg~hp, data=datasets::mtcars)$call),
> > envir=new.env())
> > xyplot(call, envir = envir)
> >
> > Should these packages be be fixed up to use just sys.call()?
>
> I admit to not understanding these things very well, but I'll try to
> explain why I ended up with the usage I have. The main use of the
> $call component within lattice is to use it in the summary method, as
> in:
>
> > summary(xyplot(mpg~hp, data=mtcars))
>
> Call:
> xyplot(mpg ~ hp, data = mtcars)
>
> Number of observations:
> [1] 32
>
> Here is a minimal approximation to what I need: Here foo() and bar()
> are generics producing objects of class "foobar", bar() calls foo()
> with one argument changed, and the print() method for "foobar" is just
> supposed to print the call that produced it:
>
> 
>
> foo <- function(x, ...) UseMethod("foo")
> bar <- function(x, ...) UseMethod("bar")
> print.foobar <- function(x, ...) print(x$call)
>
> ## Using plain sys.call():
>
> foo.formula <- function(x, ...)
> {
> ans <- structure(list(), class = "foobar")
> ans$call <- sys.call()
> ans
> }
>
> bar.formula <- function(x, ..., panel)
> {
> foo.formula(x, ..., panel = panel.bar)
> }
>
> foo.table <- function(x, ...)
> {
> ans <- foo.formula(Freq ~ Var1,
>as.data.frame.table(x), ...)
> ans
> }
>
> ## I would get
>
> foo(y ~ x)
> # foo.formula(y ~ x)
>
> bar(y ~ x)
> # foo.formula(x, ..., panel = panel.bar)
>
> foo(as.table(1:10))
> # foo.formula(Freq ~ Var1, as.data.frame.table(x), ...)
>
> ## The last two are improved by
>
> foo.formula <- function(x, ...)
> {
> ans <- structure(list(), class = "foobar")
> ans$call <- sys.call(sys.parent())
> ans
> }
>
> bar(y ~ x)
> ## bar.formula(y ~ x)
>
> foo(as.table(1:10))
> ## foo.table(as.table(1:10))
>
> 
>
> Adding
>
> ans$call[[1]] <- quote(foo)
>
> (or quote(bar) in bar.formula) is needed to replace the unexported
> method name (foo.formula) with the generic name (foo), but that's
> probably not the problem.
>
> With this approach in lattice,
>
> p <- some.function(...)
> eval(p$call)
>
> usually works, but not always, if I remember correctly.
>
> I'm happy to consider more robust solutions. Maybe I just need to have a
>
> ...$call <- sys.call()
>
> statement in every method?
>
> -Deepayan
>

[[alternative HTML version deleted]]

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

[Bioc-devel] unable to push local changes to bioconductor svn repository

[Xu, Zongli (NIH/NIEHS) [E]]

Hi,



I got a new Linux computer, cloned my package from github, made some changes. I 
am able to update the changes to github, but can not push it to Bioconductor 
svn repository. Can someone help me to solve the problem.



The following is what I did:



git svn clone https://github.com/xuz1/ENmix

cd ENmix

bash ../update_remotes.sh



#push to github

git checkout master

git add -A .

git commit -a -s -m "commit made by Xu"

git remote -v

git push origin master



#push to Bioconductor svn

git checkout devel



I am good up to here, but when I run the following command

git svn rebase --username  z.xu



It showed the following error message:



Data from a previous version of git-svn exists, but

.git/svn

(required for this version (1.7.1) of git-svn) does not exist.

Done migrating from a git-svn v1 layout

Unable to determine upstream SVN information from working tree history



Can anyone guide me what should I do to solve this problem.



Thanks,

Zongli

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Re-creating vignettes after update of data or different mechanism to create reports?

[Rainer Krug]

> On 11 May 2017, at 15:49, Duncan Murdoch  wrote:
> 
> On 11/05/2017 8:31 AM, Rainer Krug wrote:
>> Hi
>> 
>> I am building two packages:
>> 
>> - a data package which contains the data and function to extract it (several 
>> datasets, linked, like an sql database) and
>> - an analysis package which contains functions to analyse the data in the 
>> data package and depends on the data package.
>> 
>> The data package is updated often as the data is updated regularly, while 
>> the analysis package will (hopefully) be more static.
>> 
>> Now I created a report which I put in the vignette of the analysis package, 
>> which works nicely and the report is created when the analysis package is 
>> installed, but when the data package is updated, the user has to re-install 
>> the analysis package to re-create the report (vignette) of the updated 
>> dataset.
>> 
>> I know that I am abusing the vignette, but it works nicely.
>> 
>> My question:  Is there a way of re-creating the vignette by a user after 
>> they installed a newer version of the data package, or is there a better way 
>> of creating the report(s)?
> 
> 1.  No, if the analysis package isn't changed, it won't automatically update.

Yes - but can I initiate a rebuild by issuing a command in R like

rebuild_vignette()

to enable the user to rebuild the vignette?

> 
> 2.  Why not put the vignette in the data package?  Then it will be consistent 
> with the data in that package.

The vignette (which is a report) depends on functions in the Analysis package - 
so I would have circular dependencies - but I could actually invert the 
dependencies...

> 
> Duncan Murdoch
> 

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

University of Zürich

Cell:   +41 (0)78 630 66 57

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug



signature.asc
Description: Message signed with OpenPGP
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Guidance on importind multiple text files for @example

[ujjwal anand]

Hi,
I am creating a function ftsc(x)
where x is given by:
x<-cname <- file.path("C:/Users/anand/Desktop/Internship", "dataftc")
In the dataftc folder I have stored all the text files to be clustered by
my function.
So, while creating the package I have to include an example and that is my
problem.
I am not able to define a path for data folder in @example.
So, please let me know if you have some ideas about it.

Thanks & regards,
Ujjwal

On Thu, May 11, 2017 at 3:47 PM, Duncan Murdoch 
wrote:

> On 11/05/2017 6:42 AM, ujjwal anand wrote:
>
>> Hello Sir/Ma'am,
>>
>> I am trying to build a package on R. But my function, which takes a folder
>> full of text files as an argument.
>> So, could you please share some ideas on how to import a folder (which
>> contains multiple text files) for "@example".
>>
>
> Not sure what you mean by "import".  What are you starting with?  What do
> you want to end up with?
>
> Duncan Murdoch
>
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Guidance on importind multiple text files for @example

[Duncan Murdoch]

On 11/05/2017 6:42 AM, ujjwal anand wrote:

Hello Sir/Ma'am,

I am trying to build a package on R. But my function, which takes a folder
full of text files as an argument.
So, could you please share some ideas on how to import a folder (which
contains multiple text files) for "@example".


Not sure what you mean by "import".  What are you starting with?  What 
do you want to end up with?


Duncan Murdoch

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

Re: [R-pkg-devel] Fwd: Re-creating vignettes after update of data or different mechanism to create reports?

[Rainer Krug]

> On 11 May 2017, at 14:59, Holger Hoefling  wrote:
> 
> Hi Rainer,
> 
> thanks for the explanation.

No problem.

> You probably already considered this - but you could version-bump the 
> analysis package with every data package update (and make the latest data 
> package the minimum requirement). Given how large the data package is - the 
> overhead of an analysis package version bum seems small. Then people would 
> update the analysis package - which would trigger the data package update and 
> the vignette would be built correctly.

That would certainly work. Considering the main distribution channel at the 
moment, which is source Packages as .tar.gz, this would not be as elegant.
Given possible distribution channels (GitHub likely), I think a different 
solution might be better. Also, I don’t know if CRAN would be to happy to have 
regular version bumps just to re-create the vignette…

Thanks,

Rainer

> 
> That being said - how exactly this would work may also depend on how you plan 
> to host this large package (CRAN would likely not accept it). Bioconductor on 
> the other hand requires version bumps for every package for every release 
> anyway - so this concurs with my suggestion.
> 
> Best
> 
> Holger
> 
> On Thu, May 11, 2017 at 2:43 PM, Rainer Krug  > wrote:
> Sorry - forgot to cc the list
> 
> > Begin forwarded message:
> >
> > From: Rainer Krug >
> > Subject: Re: [R-pkg-devel] Re-creating vignettes after update of data or 
> > different mechanism to create reports?
> > Date: 11 May 2017 at 14:41:03 GMT+2
> > To: Holger Hoefling >
> >
> >
> >> On 11 May 2017, at 14:35, Holger Hoefling  >>   >> >> wrote:
> >>
> >> Hi Rainer,
> >>
> >> could you elaborate a little more on why you split this into two packages 
> >> in the first place? If you all kept it in one, you would have to update 
> >> this package regularly - but rebuilding the vignette would not be a 
> >> problem.
> >>
> >> As you designed it with 2 packages - you also have to update the data 
> >> package regularly.
> >>
> >> I guess I just don't understand what you gain by splitting the packages.
> >
> > I am aware that I wouldn’t have this problem with a single package, but 
> > there are some reasons why I would like to keep them separate (see below):
> >
> > 1) The dataset will be huge. So combining it with the analysis package is 
> > not a good idea in case that the analysis package needs to be updated and 
> > the data package stays the same.
> >
> > 2) I like the separation between data package and analysis package - it is 
> > cleaner
> >
> > 3) The data is not (but will hopefully be sometime later) public. So we can 
> > have two versions of the data package: one for internal usage, and one 
> > witch dummy data which can be made publicly available, as we want to make 
> > the code of the analysis public.
> >
> > Hope this explains why I want to keep them separate,
> >
> > Rainer
> >
> >>
> >> Best
> >>
> >> Holger
> >>
> >> On Thu, May 11, 2017 at 2:31 PM, Rainer Krug  >>   >> >> wrote:
> >> Hi
> >>
> >> I am building two packages:
> >>
> >> - a data package which contains the data and function to extract it 
> >> (several datasets, linked, like an sql database) and
> >> - an analysis package which contains functions to analyse the data in the 
> >> data package and depends on the data package.
> >>
> >> The data package is updated often as the data is updated regularly, while 
> >> the analysis package will (hopefully) be more static.
> >>
> >> Now I created a report which I put in the vignette of the analysis 
> >> package, which works nicely and the report is created when the analysis 
> >> package is installed, but when the data package is updated, the user has 
> >> to re-install the analysis package to re-create the report (vignette) of 
> >> the updated dataset.
> >>
> >> I know that I am abusing the vignette, but it works nicely.
> >>
> >> My question:  Is there a way of re-creating the vignette by a user after 
> >> they installed a newer version of the data package, or is there a better 
> >> way of creating the report(s)?
> >>
> >> Thanks,
> >>
> >> Rainer
> >>
> >> --
> >> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation 
> >> Biology, UCT), Dipl. Phys. (Germany)
> >>
> >> University of Zürich
> >>
> >> Cell:   +41 (0)78 630 66 57  
> >> 
> >>
> >> Fax (D):+49 - (0)3 21 21 25 22 44 
> >>  
> >> 
> >>
> >> email:  rai...@krugs.de  
> >> 

Re: [R-pkg-devel] Fwd: Re-creating vignettes after update of data or different mechanism to create reports?

[Holger Hoefling]

Hi Rainer,

thanks for the explanation. You probably already considered this - but you
could version-bump the analysis package with every data package update (and
make the latest data package the minimum requirement). Given how large the
data package is - the overhead of an analysis package version bum seems
small. Then people would update the analysis package - which would trigger
the data package update and the vignette would be built correctly.

That being said - how exactly this would work may also depend on how you
plan to host this large package (CRAN would likely not accept it).
Bioconductor on the other hand requires version bumps for every package for
every release anyway - so this concurs with my suggestion.

Best

Holger

On Thu, May 11, 2017 at 2:43 PM, Rainer Krug  wrote:

> Sorry - forgot to cc the list
>
> > Begin forwarded message:
> >
> > From: Rainer Krug 
> > Subject: Re: [R-pkg-devel] Re-creating vignettes after update of data or
> different mechanism to create reports?
> > Date: 11 May 2017 at 14:41:03 GMT+2
> > To: Holger Hoefling 
> >
> >
> >> On 11 May 2017, at 14:35, Holger Hoefling > wrote:
> >>
> >> Hi Rainer,
> >>
> >> could you elaborate a little more on why you split this into two
> packages in the first place? If you all kept it in one, you would have to
> update this package regularly - but rebuilding the vignette would not be a
> problem.
> >>
> >> As you designed it with 2 packages - you also have to update the data
> package regularly.
> >>
> >> I guess I just don't understand what you gain by splitting the packages.
> >
> > I am aware that I wouldn’t have this problem with a single package, but
> there are some reasons why I would like to keep them separate (see below):
> >
> > 1) The dataset will be huge. So combining it with the analysis package
> is not a good idea in case that the analysis package needs to be updated
> and the data package stays the same.
> >
> > 2) I like the separation between data package and analysis package - it
> is cleaner
> >
> > 3) The data is not (but will hopefully be sometime later) public. So we
> can have two versions of the data package: one for internal usage, and one
> witch dummy data which can be made publicly available, as we want to make
> the code of the analysis public.
> >
> > Hope this explains why I want to keep them separate,
> >
> > Rainer
> >
> >>
> >> Best
> >>
> >> Holger
> >>
> >> On Thu, May 11, 2017 at 2:31 PM, Rainer Krug > wrote:
> >> Hi
> >>
> >> I am building two packages:
> >>
> >> - a data package which contains the data and function to extract it
> (several datasets, linked, like an sql database) and
> >> - an analysis package which contains functions to analyse the data in
> the data package and depends on the data package.
> >>
> >> The data package is updated often as the data is updated regularly,
> while the analysis package will (hopefully) be more static.
> >>
> >> Now I created a report which I put in the vignette of the analysis
> package, which works nicely and the report is created when the analysis
> package is installed, but when the data package is updated, the user has to
> re-install the analysis package to re-create the report (vignette) of the
> updated dataset.
> >>
> >> I know that I am abusing the vignette, but it works nicely.
> >>
> >> My question:  Is there a way of re-creating the vignette by a user
> after they installed a newer version of the data package, or is there a
> better way of creating the report(s)?
> >>
> >> Thanks,
> >>
> >> Rainer
> >>
> >> --
> >> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
> Biology, UCT), Dipl. Phys. (Germany)
> >>
> >> University of Zürich
> >>
> >> Cell:   +41 (0)78 630 66 57 
> >>
> >> Fax (D):+49 - (0)3 21 21 25 22 44  2021%2021%2025%2022%2044>
> >>
> >> email:  rai...@krugs.de 
> >>
> >> Skype:  RMkrug
> >>
> >>
> >> __
> >> R-package-devel@r-project.org 
> mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-package-devel <
> https://stat.ethz.ch/mailman/listinfo/r-package-devel>
> >>
> >
> > --
> > Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
> Biology, UCT), Dipl. Phys. (Germany)
> >
> > University of Zürich
> >
> > Cell:   +41 (0)78 630 66 57
> >
> > Fax (D):+49 - (0)3 21 21 25 22 44
> >
> > email:  rai...@krugs.de 
> >
> > Skype:  RMkrug
> >
>
> --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
> Biology, UCT), Dipl. Phys. (Germany)
>
> University of Zürich
>
> Cell:   +41 (0)78 630 66 57
>
> Fax (D):+49 - (0)3 21 21 25 22 44
>
> email:  rai...@krugs.de
>
> Skype:  RMkrug
>
>
> 

[R-pkg-devel] Fwd: Re-creating vignettes after update of data or different mechanism to create reports?

[Rainer Krug]

Sorry - forgot to cc the list

> Begin forwarded message:
> 
> From: Rainer Krug 
> Subject: Re: [R-pkg-devel] Re-creating vignettes after update of data or 
> different mechanism to create reports?
> Date: 11 May 2017 at 14:41:03 GMT+2
> To: Holger Hoefling 
> 
> 
>> On 11 May 2017, at 14:35, Holger Hoefling > > wrote:
>> 
>> Hi Rainer,
>> 
>> could you elaborate a little more on why you split this into two packages in 
>> the first place? If you all kept it in one, you would have to update this 
>> package regularly - but rebuilding the vignette would not be a problem.
>> 
>> As you designed it with 2 packages - you also have to update the data 
>> package regularly.
>> 
>> I guess I just don't understand what you gain by splitting the packages.
> 
> I am aware that I wouldn’t have this problem with a single package, but there 
> are some reasons why I would like to keep them separate (see below):
> 
> 1) The dataset will be huge. So combining it with the analysis package is not 
> a good idea in case that the analysis package needs to be updated and the 
> data package stays the same.
> 
> 2) I like the separation between data package and analysis package - it is 
> cleaner
> 
> 3) The data is not (but will hopefully be sometime later) public. So we can 
> have two versions of the data package: one for internal usage, and one witch 
> dummy data which can be made publicly available, as we want to make the code 
> of the analysis public.
> 
> Hope this explains why I want to keep them separate,
> 
> Rainer
> 
>> 
>> Best
>> 
>> Holger
>> 
>> On Thu, May 11, 2017 at 2:31 PM, Rainer Krug > > wrote:
>> Hi
>> 
>> I am building two packages:
>> 
>> - a data package which contains the data and function to extract it (several 
>> datasets, linked, like an sql database) and
>> - an analysis package which contains functions to analyse the data in the 
>> data package and depends on the data package.
>> 
>> The data package is updated often as the data is updated regularly, while 
>> the analysis package will (hopefully) be more static.
>> 
>> Now I created a report which I put in the vignette of the analysis package, 
>> which works nicely and the report is created when the analysis package is 
>> installed, but when the data package is updated, the user has to re-install 
>> the analysis package to re-create the report (vignette) of the updated 
>> dataset.
>> 
>> I know that I am abusing the vignette, but it works nicely.
>> 
>> My question:  Is there a way of re-creating the vignette by a user after 
>> they installed a newer version of the data package, or is there a better way 
>> of creating the report(s)?
>> 
>> Thanks,
>> 
>> Rainer
>> 
>> --
>> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
>> UCT), Dipl. Phys. (Germany)
>> 
>> University of Zürich
>> 
>> Cell:   +41 (0)78 630 66 57 
>> 
>> Fax (D):+49 - (0)3 21 21 25 22 44 
>> 
>> 
>> email:  rai...@krugs.de 
>> 
>> Skype:  RMkrug
>> 
>> 
>> __
>> R-package-devel@r-project.org  mailing 
>> list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel 
>> 
>> 
> 
> --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
> UCT), Dipl. Phys. (Germany)
> 
> University of Zürich
> 
> Cell:   +41 (0)78 630 66 57
> 
> Fax (D):+49 - (0)3 21 21 25 22 44
> 
> email:  rai...@krugs.de 
> 
> Skype:  RMkrug
> 

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

University of Zürich

Cell:   +41 (0)78 630 66 57

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug



signature.asc
Description: Message signed with OpenPGP
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Re-creating vignettes after update of data or different mechanism to create reports?

[Rainer Krug]

Hi

I am building two packages:

- a data package which contains the data and function to extract it (several 
datasets, linked, like an sql database) and
- an analysis package which contains functions to analyse the data in the data 
package and depends on the data package.

The data package is updated often as the data is updated regularly, while the 
analysis package will (hopefully) be more static.

Now I created a report which I put in the vignette of the analysis package, 
which works nicely and the report is created when the analysis package is 
installed, but when the data package is updated, the user has to re-install the 
analysis package to re-create the report (vignette) of the updated dataset.

I know that I am abusing the vignette, but it works nicely.

My question:  Is there a way of re-creating the vignette by a user after they 
installed a newer version of the data package, or is there a better way of 
creating the report(s)?

Thanks,

Rainer

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

University of Zürich

Cell:   +41 (0)78 630 66 57

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug



signature.asc
Description: Message signed with OpenPGP
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] bug report: nlme model-fitting crashes with R 3.4.0

[Martyn Plummer]

On Thu, 2017-05-11 at 06:37 -0500, Dirk Eddelbuettel wrote:
> On 11 May 2017 at 10:17, Erwan Le Pennec wrote:
> >  Dear all,
> > 
> >  I've stumbled a similar issue with the package cluster when 
> > compiling the 3.4.0 version with the settings of Fedora RPM specs. 
> > Compiling R with the default setting of configure yields a version
> > that 
> > works for cluster... and nlme.
> > 
> >  I did not find the exact option that was the cause of this
> > issue 
> > but I'm willing to help.
> > 
> >  Erwan
> > 
> > PS: This is the reason why R is still at version 3.3.3 on the
> > Fedora 
> > distribution.
> > 
> > On 10/05/17 22:59, Langbehn, Douglas wrote:
> > > lme() and gls() models from the nlme package are all crashing
> > > with R.3.4.0. Identical code ran correctly, without error in R
> > > 3.3.3 and earlier versions.  The behavior is easily demonstrated
> > > using one of the examples form the lme() help file, along with
> > > two simple variants. I have commented the errors generated by
> > > these calls, as well as the lines of code generating them, in the
> > > code example below.
> > > 
> > > As of today, this bug had not been reported on the R Bugzilla
> > > page. I could not submit this report directly to the page because
> > > I am not a member, and , as explained in the "Reporting Bugs"
> > > link from the  R home page, membership has now been closed due to
> > > spamming problems..
> > > 
> > > #
> > > ###
> > > library(nlme)
> > > #Using version 3.1-131
> > > #Windows 7 64-bit operating system
> > > 
> > > fm2 <- lme(distance ~ age + Sex, data = Orthodont, random = ~ 1)
> > > 
> > > # Error in array(c(rep(1, p), .C(inner_perc_table, as.double(X),
> > > as.integer(unlist(grps)),  :
> > > # object 'inner_perc_table' not found
> 
> That is a known issue with R 3.4.0 -- see NEWS.
> 
> Packages using .C and .Fortran _must_ be recompiled for R 3.4.0. If
> and when
> you do, the example will work again.
> 
> Dirk

However, the issue raised by Erwan on Fedora is a real bug which
affects at least two recommended packages. I know the cause of the
problem and am trying to find out how many packages are affected.

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

Re: [Rd] bug report: nlme model-fitting crashes with R 3.4.0

[Dirk Eddelbuettel]

On 11 May 2017 at 10:17, Erwan Le Pennec wrote:
|  Dear all,
| 
|  I've stumbled a similar issue with the package cluster when 
| compiling the 3.4.0 version with the settings of Fedora RPM specs. 
| Compiling R with the default setting of configure yields a version that 
| works for cluster... and nlme.
| 
|  I did not find the exact option that was the cause of this issue 
| but I'm willing to help.
| 
|  Erwan
| 
| PS: This is the reason why R is still at version 3.3.3 on the Fedora 
| distribution.
| 
| On 10/05/17 22:59, Langbehn, Douglas wrote:
| > lme() and gls() models from the nlme package are all crashing with R.3.4.0. 
Identical code ran correctly, without error in R 3.3.3 and earlier versions.  
The behavior is easily demonstrated using one of the examples form the lme() 
help file, along with two simple variants. I have commented the errors 
generated by these calls, as well as the lines of code generating them, in the 
code example below.
| >
| > As of today, this bug had not been reported on the R Bugzilla page. I could 
not submit this report directly to the page because I am not a member, and , as 
explained in the "Reporting Bugs" link from the  R home page, membership has 
now been closed due to spamming problems..
| >
| > 
| > library(nlme)
| > #Using version 3.1-131
| > #Windows 7 64-bit operating system
| >
| > fm2 <- lme(distance ~ age + Sex, data = Orthodont, random = ~ 1)
| >
| > # Error in array(c(rep(1, p), .C(inner_perc_table, as.double(X), 
as.integer(unlist(grps)),  :
| > # object 'inner_perc_table' not found

That is a known issue with R 3.4.0 -- see NEWS.

Packages using .C and .Fortran _must_ be recompiled for R 3.4.0. If and when
you do, the example will work again.

Dirk

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

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

[R-pkg-devel] Guidance on importind multiple text files for @example

[ujjwal anand]

Hello Sir/Ma'am,

I am trying to build a package on R. But my function, which takes a folder
full of text files as an argument.
So, could you please share some ideas on how to import a folder (which
contains multiple text files) for "@example".

Thanks,
Ujjwal Anand

[[alternative HTML version deleted]]

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

Re: [Rd] xrealloc namespace conflict

[Dirk Eddelbuettel]

On 11 May 2017 at 12:16, Patrick Perry wrote:
| I've done a bit more investigation into this issue. Here is my current 
| understanding of the situation:
| 
| 1. I have a package on CRAN (corpus-0.3.1) that passes tests on all 
| platforms except for Linux.
| 2. My package defines a C function, "xrealloc", for internal use.
| 3. The libreadline library that R links to defines a different version 
| of "xrealloc".
| 4. On Linux, when I load my package, references to "xrealloc" get linked 
| to the libreadline version of that function.
| 5. This causes one of my tests to fail, calling exit(2), because the 
| libreadline version of xrealloc does not allow calls of the form 
| "xrealloc(ptr, 0)".
| 
| I can work around this issue pretty easily, by either renaming my 
| version of xrealloc to something else, or by avoiding calls of the form 
| "xrealloc(ptr, 0)". So, this is not a major issue, but it's a little 
| unsettling to see this behavior when my package does not explicitly link 
| to or use anything from libreadline.
| 
| Is there a reason this behavior is only manifesting on Linux? Is there 
| something wrong with the way I'm compiling my package on that platform? 
| Is this just some quirk about the way R is loading dynamic libraries on 
| Linux? I'd appreciate any insight into the issue.

It may just be the flat namespace and linking order. AFAIK there is nothing
in C preventing so maybe you 'just got lucky' on the other platforms. See eg
http://stackoverflow.com/questions/7998770/

But then I don't use pure C that after anymore ... and in C++ you could just
wrap a namespace around your code, avoiding the issue.


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: [Rd] xrealloc namespace conflict

[Patrick Perry]

I've done a bit more investigation into this issue. Here is my current 
understanding of the situation:

1. I have a package on CRAN (corpus-0.3.1) that passes tests on all 
platforms except for Linux.
2. My package defines a C function, "xrealloc", for internal use.
3. The libreadline library that R links to defines a different version 
of "xrealloc".
4. On Linux, when I load my package, references to "xrealloc" get linked 
to the libreadline version of that function.
5. This causes one of my tests to fail, calling exit(2), because the 
libreadline version of xrealloc does not allow calls of the form 
"xrealloc(ptr, 0)".

I can work around this issue pretty easily, by either renaming my 
version of xrealloc to something else, or by avoiding calls of the form 
"xrealloc(ptr, 0)". So, this is not a major issue, but it's a little 
unsettling to see this behavior when my package does not explicitly link 
to or use anything from libreadline.

Is there a reason this behavior is only manifesting on Linux? Is there 
something wrong with the way I'm compiling my package on that platform? 
Is this just some quirk about the way R is loading dynamic libraries on 
Linux? I'd appreciate any insight into the issue.


Patrick

p.s. Here are some references:

My package Makevars are at 
https://github.com/patperry/r-corpus/blob/master/src/Makevars ; my 
version of "xrealloc" is in corpus/src/xalloc.c

You can see the source for the libreadline xrealloc at 
https://github.com/JuliaLang/readline/blob/master/xmalloc.c#L67


Patrick Perry wrote:
>
> I have a package on CRAN now (corpus-0.3.1) that is currently failing
> tests on Linux, but passing on all other architectures:
>
> https://cran.r-project.org/web/checks/check_results_corpus.html
>
> I believe that the issue arrises from a namespace class between
> "xrealloc", which my package provides for internal use, but which R
> also seems to provide (possibly as part of TRE in
> src/extra/tre/xmalloc.c). It looks like my package is not picking up
> my custom xrealloc, but using an xrealloc provided by R.
>
> Besides the fact that I am linking to the wrong xrealloc, I think my
> tests are failing for the same reason that the following code
> segfaults on Linux (Debian, with R 3.4.0):
>
> test <- inline::cfunction(language='C',
> otherdefs='void *xmalloc(size_t); void *xrealloc(void *, size_t);',
> body = 'void *ptr = xmalloc(256); xrealloc(ptr, 0); return
> R_NilValue;')
> test()
> ## xrealloc: out of virtual memory
>
> It seems that the R xrealloc doesn't like being given a size of 0,
> even though this behavior is well-defined for realloc (it should free
> the memory). Based on my failing CRAN tests, it looks like this is a
> Linux-specific issue.
>
> Is there a way to modify my Makevars to force the linker to choose my
> version of xrealloc for my package-specific code? My current Makevars
> are at https://github.com/patperry/r-corpus/blob/master/src/Makevars
>
> Thanks in advance for any help.
>
>
> Patrick


> Patrick Perry 
> May 6, 2017 at 5:36 PM
> I have a package on CRAN now (corpus-0.3.1) that is currently failing 
> tests on Linux, but passing on all other architectures:
>
> https://cran.r-project.org/web/checks/check_results_corpus.html
>
> I believe that the issue arrises from a namespace class between 
> "xrealloc", which my package provides for internal use, but which R 
> also seems to provide (possibly as part of TRE in 
> src/extra/tre/xmalloc.c). It looks like my package is not picking up 
> my custom xrealloc, but using an xrealloc provided by R.
>
> Besides the fact that I am linking to the wrong xrealloc, I think my 
> tests are failing for the same reason that the following code 
> segfaults on Linux (Debian, with R 3.4.0):
>
> test <- inline::cfunction(language='C',
> otherdefs='void *xmalloc(size_t); void *xrealloc(void *, size_t);',
> body = 'void *ptr = xmalloc(256); xrealloc(ptr, 0); return 
> R_NilValue;')
> test()
> ## xrealloc: out of virtual memory
>
> It seems that the R xrealloc doesn't like being given a size of 0, 
> even though this behavior is well-defined for realloc (it should free 
> the memory). Based on my failing CRAN tests, it looks like this is a 
> Linux-specific issue.
>
> Is there a way to modify my Makevars to force the linker to choose my 
> version of xrealloc for my package-specific code? My current Makevars 
> are at https://github.com/patperry/r-corpus/blob/master/src/Makevars
>
> Thanks in advance for any help.
>
>
> Patrick
>


[[alternative HTML version deleted]]

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

Re: [Rd] bug report: nlme model-fitting crashes with R 3.4.0

[Erwan Le Pennec]

Dear all,

I've stumbled a similar issue with the package cluster when 
compiling the 3.4.0 version with the settings of Fedora RPM specs. 
Compiling R with the default setting of configure yields a version that 
works for cluster... and nlme.


I did not find the exact option that was the cause of this issue 
but I'm willing to help.


Erwan

PS: This is the reason why R is still at version 3.3.3 on the Fedora 
distribution.


On 10/05/17 22:59, Langbehn, Douglas wrote:

lme() and gls() models from the nlme package are all crashing with R.3.4.0. 
Identical code ran correctly, without error in R 3.3.3 and earlier versions.  
The behavior is easily demonstrated using one of the examples form the lme() 
help file, along with two simple variants. I have commented the errors 
generated by these calls, as well as the lines of code generating them, in the 
code example below.

As of today, this bug had not been reported on the R Bugzilla page. I could not submit 
this report directly to the page because I am not a member, and , as explained in the 
"Reporting Bugs" link from the  R home page, membership has now been closed due 
to spamming problems..


library(nlme)
#Using version 3.1-131
#Windows 7 64-bit operating system

fm2 <- lme(distance ~ age + Sex, data = Orthodont, random = ~ 1)

# Error in array(c(rep(1, p), .C(inner_perc_table, as.double(X), 
as.integer(unlist(grps)),  :
# object 'inner_perc_table' not found
#
#Upon debugging, this error is thrown with line 135 of lme.formula() code.
#
#fixDF <- getFixDF(X, grps, attr(lmeSt, "conLin")$dims$ngrps,

lme(distance ~ age + Sex, data = Orthodont, random = ~ 1|Subject)

# Error in array(c(rep(1, p), .C(inner_perc_table, as.double(X), 
as.integer(unlist(grps)),  :
# object 'inner_perc_table' not found

gls(distance ~ age + Sex, data = Orthodont,
 correlation = corCompSymm( form = ~ 1 | Subject))

# Error in corMatrix.corCompSymm(object) :
# object 'compSymm_matList' not found
#
#Upon debugging, the error is thrown by line 60 of gls code
#
#glsSt <- Initialize(glsSt, dataMod, glsEstControl)

R.version

# _
# platform   x86_64-w64-mingw32
# arch   x86_64
# os mingw32
# system x86_64, mingw32
# status
# major  3
# minor  4.0
# year   2017
# month  04
# day21
# svn rev72570
# language   R
# version.string R version 3.4.0 (2017-04-21)
# nickname   You Stupid Darkness


Douglas R Langbehn MD, PhD
Professor
Dept. of Psychiatry and Biostatistics (secondary)
University of Iowa Carver College of Medicine
douglas-langb...@uiowa.edu




Notice: This UI Health Care e-mail (including attachments) is covered by the 
Electronic Communications Privacy Act, 18 U.S.C. 2510-2521 and is intended only 
for the use of the individual or entity to which it is addressed, and may 
contain information that is privileged, confidential, and exempt from 
disclosure under applicable law. If you are not the intended recipient, any 
dissemination, distribution or copying of this communication is strictly 
prohibited. If you have received this communication in error, please notify the 
sender immediately and delete or destroy all copies of the original message and 
attachments thereto. Email sent to or from UI Health Care may be retained as 
required by law or regulation. 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] R-3.3.3/R-3.4.0 change in sys.call(sys.parent())

[Deepayan Sarkar]

On Wed, May 10, 2017 at 2:36 AM, William Dunlap via R-devel
 wrote:
> Some formula methods for S3 generic functions use the idiom
> returnValue$call <- sys.call(sys.parent())
> to show how to recreate the returned object or to use as a label on a
> plot.  It is often followed by
>  returnValue$call[[1]] <- quote(myName)
> E.g., I see it in packages "latticeExtra" and "leaps", and I suspect it
> used in "lattice" as well.
>
> This idiom has not done good things for quite a while (ever?) but I noticed
> while running tests that it acts differently in R-3.4.0 than in R-3.3.3.
> Neither the old or new behavior is nice.  E.g., in R-3.3.3 we get
>
>> parseEval <- function(text, envir) eval(parse(text=text), envir=envir)
>> parseEval('lattice::xyplot(mpg~hp, data=datasets::mtcars)$call',
> envir=new.env())
> xyplot(expr, envir, enclos)
>
> and
>
>> evalInEnvir <- function(call, envir) eval(call, envir=envir)
>> evalInEnvir(quote(lattice::xyplot(mpg~hp, data=datasets::mtcars)$call),
> envir=new.env())
> xyplot(expr, envir, enclos)
>
> while in R-3.4.0 we get
>> parseEval <- function(text, envir) eval(parse(text=text), envir=envir)
>> parseEval('lattice::xyplot(mpg~hp, data=datasets::mtcars)$call',
> envir=new.env())
> xyplot(parse(text = text), envir = envir)
>
> and
>
>> evalInEnvir <- function(call, envir) eval(call, envir=envir)
>> evalInEnvir(quote(lattice::xyplot(mpg~hp, data=datasets::mtcars)$call),
> envir=new.env())
> xyplot(call, envir = envir)
>
> Should these packages be be fixed up to use just sys.call()?

I admit to not understanding these things very well, but I'll try to
explain why I ended up with the usage I have. The main use of the
$call component within lattice is to use it in the summary method, as
in:

> summary(xyplot(mpg~hp, data=mtcars))

Call:
xyplot(mpg ~ hp, data = mtcars)

Number of observations:
[1] 32

Here is a minimal approximation to what I need: Here foo() and bar()
are generics producing objects of class "foobar", bar() calls foo()
with one argument changed, and the print() method for "foobar" is just
supposed to print the call that produced it:



foo <- function(x, ...) UseMethod("foo")
bar <- function(x, ...) UseMethod("bar")
print.foobar <- function(x, ...) print(x$call)

## Using plain sys.call():

foo.formula <- function(x, ...)
{
ans <- structure(list(), class = "foobar")
ans$call <- sys.call()
ans
}

bar.formula <- function(x, ..., panel)
{
foo.formula(x, ..., panel = panel.bar)
}

foo.table <- function(x, ...)
{
ans <- foo.formula(Freq ~ Var1,
   as.data.frame.table(x), ...)
ans
}

## I would get

foo(y ~ x)
# foo.formula(y ~ x)

bar(y ~ x)
# foo.formula(x, ..., panel = panel.bar)

foo(as.table(1:10))
# foo.formula(Freq ~ Var1, as.data.frame.table(x), ...)

## The last two are improved by

foo.formula <- function(x, ...)
{
ans <- structure(list(), class = "foobar")
ans$call <- sys.call(sys.parent())
ans
}

bar(y ~ x)
## bar.formula(y ~ x)

foo(as.table(1:10))
## foo.table(as.table(1:10))



Adding

ans$call[[1]] <- quote(foo)

(or quote(bar) in bar.formula) is needed to replace the unexported
method name (foo.formula) with the generic name (foo), but that's
probably not the problem.

With this approach in lattice,

p <- some.function(...)
eval(p$call)

usually works, but not always, if I remember correctly.

I'm happy to consider more robust solutions. Maybe I just need to have a

...$call <- sys.call()

statement in every method?

-Deepayan

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