[Rd] Unexpected behaviour initializing S4 class
Hello all!
I am not sure if this is known or even intended, but please consider the
following simple example code:
# set up a simple S4 class with single slot
setClass("b", representation = representation(x = "numeric"))
# provide initialize method
setMethod("initialize",
signature(.Object = "b"),
function(.Object,...) b.initialize(.Object,...)
)
# actual implementation of initialize method external
b.initialize <- function(kl, x = numeric(),...) {
k...@x <- x
kl
}
# this gives an error in R-2.9.2
test <- new("b", x = 1:2, k = 3, y = 2)
What apparently happens is that the k=3 part in ... for b.initialize is
assigned to kl while the initial "b" object that should be assigned to
kl ends up in "..." of b.initialize.
I assume this is due to the naming similarity of k and kl, probably
confusing the matching algorithm: if another first argument for
b.initialize is used (not starting with k), everything is fine.
Other workarounds:
- in setMethod write "kl = .Object" instead of simply ".Object"
- this does not happen if the contents of b.initialize are directly
moved to the setMethod call, even if k is renamed to, say, .O
This happened to me in a case where b is a subclass of another class
which has a slot named k, so the "offending" k = 3 is not artificial here.
I hope some dev here can look into the switching effect: this cannot
possibly be intended?
Here my sessioninfo():
> sessionInfo()
R version 2.9.2 (2009-08-24)
i686-pc-linux-gnu
locale:
LC_CTYPE=de_DE.UTF-8;LC_NUMERIC=C;LC_TIME=de_DE.UTF-8;LC_COLLATE=de_DE.UTF-8;LC_MONETARY=C;LC_MESSAGES=de_DE.UTF-8;LC_PAPER=de_DE.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=de_DE.UTF-8;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Best
Kruno
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unexpected behaviour initializing S4 class
Hi Kruno --
Krunoslav Sever wrote:
> Hello all!
>
> I am not sure if this is known or even intended, but please consider the
> following simple example code:
>
> # set up a simple S4 class with single slot
> setClass("b", representation = representation(x = "numeric"))
>
> # provide initialize method
> setMethod("initialize",
> signature(.Object = "b"),
> function(.Object,...) b.initialize(.Object,...)
> )
>
> # actual implementation of initialize method external
> b.initialize <- function(kl, x = numeric(),...) {
> k...@x <- x
> kl
> }
>
> # this gives an error in R-2.9.2
> test <- new("b", x = 1:2, k = 3, y = 2)
>
> What apparently happens is that the k=3 part in ... for b.initialize is
> assigned to kl while the initial "b" object that should be assigned to
> kl ends up in "..." of b.initialize.
This is R argument matching at work
> f <- function(.Object, ...) g(.Object, ...)
> g <- function(kl, x, ...) match.call()
> f(1, x=2, k=3)
g(kl = 3, x = 2, .Object)
specifically partial matching of named arguments taking precedence of
positional matching of unnamed arguments.
> I assume this is due to the naming similarity of k and kl, probably
> confusing the matching algorithm: if another first argument for
> b.initialize is used (not starting with k), everything is fine.
>
> Other workarounds:
> - in setMethod write "kl = .Object" instead of simply ".Object"
yes, this avoids mixing matching by name and by position.
Martin Morgan
> - this does not happen if the contents of b.initialize are directly
> moved to the setMethod call, even if k is renamed to, say, .O
> This happened to me in a case where b is a subclass of another class
> which has a slot named k, so the "offending" k = 3 is not artificial here.
>
> I hope some dev here can look into the switching effect: this cannot
> possibly be intended?
>
> Here my sessioninfo():
>> sessionInfo()
> R version 2.9.2 (2009-08-24)
> i686-pc-linux-gnu
>
> locale:
> LC_CTYPE=de_DE.UTF-8;LC_NUMERIC=C;LC_TIME=de_DE.UTF-8;LC_COLLATE=de_DE.UTF-8;LC_MONETARY=C;LC_MESSAGES=de_DE.UTF-8;LC_PAPER=de_DE.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=de_DE.UTF-8;LC_IDENTIFICATION=C
>
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> Best
> Kruno
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R devel repository tarball naming issue
Hi, we noticed that since some time after Aug 24th the daily snapshots provided on ftp://ftp.stat.math.ethz.ch/Software/R/ no longer have their default tarball file name but dropped the date stamp, i.e. R-devel_.tar.bz2 Same for R-patched snapshots. Could one of the maintainers please take a look. We rely on the default naming convention for automatic builds. Regards, Matthias -- Matthias Burger Project Manager/ Biostatistician Epigenomics AGKleine Praesidentenstr. 110178 Berlin, Germany phone:+49-30-24345-0fax:+49-30-24345-555 http://www.epigenomics.com matthias.bur...@epigenomics.com -- Epigenomics AG Berlin Amtsgericht Charlottenburg HRB 75861 Vorstand: Geert Nygaard (CEO/Vorsitzender) Oliver Schacht PhD (CFO) Aufsichtsrat: Prof. Dr. Dr. hc. Rolf Krebs (Chairman/Vorsitzender) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Including a binary Python Interpreter into a binary R-package for MS Windows
2009/8/30 Uwe Ligges : [snip] > Guido van Steen wrote: [snip] >> Something that interests me too: What about R's policy with respect to >> including binary files? I saw that developers should include a file [snip] > Please do not include binary files and carefully watch for licenses of those > files (e.g. if GPL'ed, you need to ship sources!). If pyhthon is required, I > highly suggest to state it in the SystemDependencies and be fine with it - > users can learn to install phython themselves, I'm pretty sure. Hi Uwe, Note: I will send this email cc. to the R-devel list, which I joined today. I think it may be of interest to other people as well. Thank you for your answer, although it disappointed me a bit. I had already spent quite some time building a stand-alone windows binary of a new package "write2xls". This package provides the same R interface to Python as the other package "dataframes2xls". As you know it enable users to create xls files. The special thing about "write2xls" is that it does not have any dependencies at all. It is so-to-speak a turn-key solution. Of course I should have read a bit more before I started. Only after your mail I read the pdf-file "Writing R Extensions". It says "A source package if possible should not contain binary executable files: they are not portable, and a security risk if they are of the appropriate architecture. R CMD check will warn about them unless they are listed (one filepath per line) in a file 'BinaryFiles' at the top level of the package or bundle. Note that CRAN will no longer accept submissions containing binary files even if they are listed." So, yes, you are right. I was actually hoping that CRAN could make some exceptions, but after some thinking I fully understand that many people would object to this for good reasons: R code depending on a C compiler will not work without a C Compiler either. For security reasons we cannot allow packages to install a binary C compiler. So, yes, I understand the reasons but still it is a pity. The current situation is that many MS Windows users can not easily use "dataframes2xls". There are a few reasons: * Most users of MS Windows will be unfamiliar with Python, which will make them reluctant to install Python. * Installing Python will be impossible on many MS Windows platforms due to limited user rights. * Downloading a standard Python installer takes about 15 Megabytes. My newly created "write2xls" package just contains 1.3 MB. So only few R users can benefit from "dataframes2xls". An alternative to "dataframes2xls" is "write.xls". "dataframes2xls" is technically superior, as it allows the specification of proper formatting and fonts. "dataframes2xls" also exists longer. However, "write.xls" is available to many more R users because it depends on Perl, which is installed as a part of the R-tools. So, I think it would be a pity not to provide "write2xls", since I have it readily available now. Therefore, I will probably be hosting "write2xls" on a different repository, as long as no Python Interpreter is included in the R-tools. Does anyone know of a alternative repository, which does accept "trustworthy" R packages with a binary Python Interpreter. Thanks! Best wishes, Guido van Steen P.S. For those who are interested or who would like to test it, at the moment "write2xls" can be downloaded as "http://www.heppel.net/write2xls_0.4.4.9.zip";. The "source" package is available as "http://www.heppel.net/write2xls_0.4.4.9.tar.gz";. P.P.S. I think that on MS Windows the combination of R and the R tools is just as much a potential security risk as allowing to include a Python Interpreter in a binary package. The R website should pay more serious attention to this. P.P.P.S. Uwe also brings up the issue of licensing. However, this is not a problem at all. The Python license is one of the most permissive licenses around. For the Python Interpreter that I included in the "write2xls" package, I used pyMingW, which is distributed under an MIT license. It is a version of Python compiled by the MinGW compiler. Thanks to this pyMingW distribution I also avoid the need of any Microsoft-owned dlls. "dataframes2xls" and "write2xls" are also distributed under a MIT license. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Including a binary Python Interpreter into a binary R-package for MS Windows
On Tue, Sep 1, 2009 at 5:41 PM, wrote: > 2009/8/30 Uwe Ligges : > [snip] >> Guido van Steen wrote: > [snip] >>> Something that interests me too: What about R's policy with respect to >>> including binary files? I saw that developers should include a file > [snip] >> Please do not include binary files and carefully watch for licenses of those >> files (e.g. if GPL'ed, you need to ship sources!). If pyhthon is required, I >> highly suggest to state it in the SystemDependencies and be fine with it - >> users can learn to install phython themselves, I'm pretty sure. > > Hi Uwe, > > Note: I will send this email cc. to the R-devel list, which I joined today. I > think it may be of interest to other people as well. > > Thank you for your answer, although it disappointed me a bit. I had already > spent quite some time building a stand-alone windows binary of a new package > "write2xls". This package provides the same R interface to Python as the > other package "dataframes2xls". As you know it enable users to create xls > files. The special thing about "write2xls" is that it does not have any > dependencies at all. It is so-to-speak a turn-key solution. > > Of course I should have read a bit more before I started. Only after your > mail I read the pdf-file "Writing R Extensions". It says "A source package if > possible should not contain binary executable files: they are not portable, > and a security risk if they are of the appropriate architecture. R CMD check > will warn about them unless they are listed (one filepath per line) in a file > 'BinaryFiles' at the top level of the package or bundle. Note that CRAN will > no longer accept submissions containing binary files even if they are listed." > > So, yes, you are right. I was actually hoping that CRAN could make some > exceptions, but after some thinking I fully understand that many people would > object to this for good reasons: R code depending on a C compiler will not > work without a C Compiler either. For security reasons we cannot allow > packages to install a binary C compiler. So, yes, I understand the reasons > but still it is a pity. > > The current situation is that many MS Windows users can not easily use > "dataframes2xls". There are a few reasons: > > * Most users of MS Windows will be unfamiliar with Python, which will make > them reluctant to install Python. > > * Installing Python will be impossible on many MS Windows platforms due to > limited user rights. > > * Downloading a standard Python installer takes about 15 Megabytes. My newly > created "write2xls" package just contains 1.3 MB. > Note that the rSymPy package has an entire Jython interpreter in it and provided your software is only R and pure python you should be able to run it off that. Of course this just trades one dependency for another, i.e. it does not require python since that's included but it does require java; however, most people have java installed already since a lot of the free software out there requires java. See: http://rsympy.googlecode.com Note that since java jar files are source files and since java itself is not included it was possible to do that without any binaries. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Including a binary Python Interpreter into a binary R-package for MS Windows
Hi Gabor, Thank you very much! That is an excelent idea! I had not thought about Jython at all. Moreover, I always had the impression that the latest Jython distribution was based on Python 2.2. But I just saw that they upgraded to 2.5 a few months ago. This is quite fortunate because both "dataframes2xls" and "write2xls" depend on Python 2.4 or better. An R user will not notice much of a 15 MB download. And for most MS Windows users Java is an even more common thing than Perl. I will definitely check this out! Thanks a lot!!! Best wishes, Guido --- On Wed, 9/2/09, Gabor Grothendieck wrote: > From: Gabor Grothendieck > Subject: Re: [Rd] Including a binary Python Interpreter into a binary > R-package for MS Windows > To: gvst...@yahoo.com > Cc: uwe.lig...@r-project.org, r-devel@r-project.org > Date: Wednesday, September 2, 2009, 12:06 AM > On Tue, Sep 1, 2009 at 5:41 PM, > > wrote: > > 2009/8/30 Uwe Ligges : > > [snip] > >> Guido van Steen wrote: > > [snip] > >>> Something that interests me too: What about > R's policy with respect to > >>> including binary files? I saw that developers > should include a file > > [snip] > >> Please do not include binary files and carefully > watch for licenses of those > >> files (e.g. if GPL'ed, you need to ship sources!). > If pyhthon is required, I > >> highly suggest to state it in the > SystemDependencies and be fine with it - > >> users can learn to install phython themselves, I'm > pretty sure. > > > > Hi Uwe, > > > > Note: I will send this email cc. to the R-devel list, > which I joined today. I think it may be of interest to other > people as well. > > > > Thank you for your answer, although it disappointed me > a bit. I had already spent quite some time building a > stand-alone windows binary of a new package "write2xls". > This package provides the same R interface to Python as the > other package "dataframes2xls". As you know it enable users > to create xls files. The special thing about "write2xls" is > that it does not have any dependencies at all. It is > so-to-speak a turn-key solution. > > > > Of course I should have read a bit more before I > started. Only after your mail I read the pdf-file "Writing R > Extensions". It says "A source package if possible should > not contain binary executable files: they are not portable, > and a security risk if they are of the appropriate > architecture. R CMD check will warn about them unless they > are listed (one filepath per line) in a file 'BinaryFiles' > at the top level of the package or bundle. Note that CRAN > will no longer accept submissions containing binary files > even if they are listed." > > > > So, yes, you are right. I was actually hoping that > CRAN could make some exceptions, but after some thinking I > fully understand that many people would object to this for > good reasons: R code depending on a C compiler will not work > without a C Compiler either. For security reasons we cannot > allow packages to install a binary C compiler. So, yes, I > understand the reasons but still it is a pity. > > > > The current situation is that many MS Windows users > can not easily use "dataframes2xls". There are a few > reasons: > > > > * Most users of MS Windows will be unfamiliar with > Python, which will make them reluctant to install Python. > > > > * Installing Python will be impossible on many MS > Windows platforms due to limited user rights. > > > > * Downloading a standard Python installer takes about > 15 Megabytes. My newly created "write2xls" package just > contains 1.3 MB. > > > > Note that the rSymPy package has an entire Jython > interpreter > in it and provided your software is only R and pure python > you > should be able to run it off that. > > Of course this just trades one dependency for another, i.e. > it > does not require python since that's included but it does > require > java; however, most people have java installed already > since a lot > of the free software out there requires java. See: > http://rsympy.googlecode.com > > Note that since java jar files are source files and since > java itself > is not included it was possible to do that without any > binaries. > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Installing rJava RJDBC bad interpreter: Permission denied
Trying to install the above two packages via the
"install.packages("package_name")" command and
the "R CMD INSTALL file.tar.gz".
I receive the following error either way "sh: ./configure: /bin/sh: bad
interpreter: Permission denied".
I have tried to chmod and chown permissions and also ran dos2unix in hopes that
there is a CRLF
in some of the tar.gz files, but that doesn't seem to fix the problem. I'm
looking for any help
I can get. I have tried the r-help and r-packages list. I have tried this
with the compiled
version of R and the RPM version of R.
* Installing *source* package ârJavaâ ...
sh: ./configure: /bin/sh: bad interpreter: Permission denied
ERROR: configuration failed for package ârJavaâ
* Removing â/usr/lib64/R/library/rJavaâ
* Installing *source* package âRJDBCâ ...
** R
** preparing package for lazy loading
Error : package 'rJava' required by 'RJDBC' could not be found
ERROR: lazy loading failed for package âRJDBCâ
* Removing â/usr/lib64/R/library/RJDBCâ
I'm using the rpm version of R found here
http://cran.cnr.berkeley.edu/bin/linux/redhat/el5/x86_64
I ran the "R CMD javareconf" as root and set the JAVA_HOME environment variable.
Here is my system configuration:
OS: CentOS 5.2 x86_64
JDK: java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode)
R: 2.9.1
rJava: rJava_0.7-0.tar.gz
RJDBC: RJDBC_0.1-5.tar.gz
Thanks for your time and knowledge.
Best,
Matt
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] License of Port3 library for R
I developed some code that called subroutines from the Port3 Library (http://www-out.bell-labs.com/project/PORT/). I¹m thinking about making it available as an R package. But I¹m not sure if their NON-EXCLUSIVE SOURCE CODE LICENSE AGREEMENT ( http://www-out.bell-labs.com/topic/swdist/licenses/nesource.txt ) permits this. I tried contacting the contact person listed on the website. Not surprisingly, the recipient doesn't exist at Lucent anymore. Any advice on this will be appreciated. Pin Ng Associate Professor of Economics The W. A. Franke College of Business Northern Arizona University P.O. Box 15066 Flagstaff, AZ 86011-5066 (Phone) 928-523-8726 (Fax) 928-523-7331 (Email) pin...@nau.edu (URL) http://www.cba.nau.edu/pin-ng __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Dependencies of packages' CHECK....
I'm working to automate the building of RPM packages for CRAN &c. In the process, I'm trying to get a sense of the correct dependencies. It's my sense that R CMD CHECK is the Right Way to check to see if a package is built properly. But according to Writing R Extensions, I could reasonably expect anything in Suggests or Imports to be used by CHECK. In RPM parlance, this turns all of those packages into a 'build requires'. In other words, to check properly, I need to treat Suggests and Imports as Depends. This is a short road to -lots- of installed packages. :) ggplot2, which was the initial itch I was trying to scratch, 'Depends' only on R. But if I have to recursively expand according to these 'build requires', I need 63 packages. And more painfully, I have to leave CRAN and go grok Bioconductor. Yow. So: does this seem silly, or is that just The Way It is? - Allen S. Rout __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
