Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows

[Martin Maechler]

> Wincent  
> on Wed, 4 May 2011 13:46:13 +0800 writes:

> I also prefer to keep the old versions.  Sometimes, I have
> spent time to set up the system with older version and
> don't want to update to the latest (e.g. the new RGtk2
> needs updated GTk2 as well) because the older still works
> and I don't need the new features.

Well  Thomas gave good reasons to keep old versions of R
*IN ADDITION* to the latest R version.
Exactly *because* that is so easy, it makes very much sense to
update to the newest version:

Use the latest R, and if you really have doubts, quickly run the
same R code in the older R version that is still available.

Note to Yihui Xie:  I agree 100% with the other R core members 
(Duncan, Simon, Thomas) who already explained why it is *GOOD*
to install R in version-named directories by default.

BTW: If you use ESS (Emacs Speaks Statistics) on Windows,
it now automatically(*) finds all versions of R
(* well, less generally, probably than Gabor's batch files; IIRC,
 we assume that the R versions were installed in the default place),
and provides them, both the 32bit and 64bit versions, in the ESS
menu, or via 
  M-x R- [Tab completion]
Very nice, very useful in my eyes.

Martin 

> Regards Ronggui

> On 4 May 2011 13:26, Thomas Lumley  wrote:
>> On Wed, May 4, 2011 at 3:25 PM, Yihui Xie
>>  wrote:
>>> 1. "Few Windows users use these commands" does not imply
>>> they are not useful, and I have no idea how many Windows
>>> users really use them. How do you run "R CMD build" when
>>> you build R packages under Windows? You don't write
>>> "C:/Program Files/R/R-2.13.0/bin/i386/R.exe CMD build",
>>> do you?
>>> 
>>> I think the reason we have to mess with the PATH
>>> variable for each single software package is that
>>> Windows is Not Unix, so you may hate Windows instead of
>>> a package that modifies your PATH variable.
>>> 
>>> For the choice of i386 and x64, you can let the user
>>> decide which bin path to use. I believe the number of
>>> users who frequently switch back and forth is fairly
>>> small.
>>> 
>>> 2. Under most circumstances I just keep the latest
>>> version of R. To maintain R code with old R versions
>>> will be more and more difficult with new features and
>>> changes coming in. Disk space is cheap, but time is not.
>>> 
>> 
> I keep old versions for basically the same reasons you don't
>> -- that is, I have analyses that ran under the old
>> versions, and I can be sure they will give the same
>> answer a year later if I keep the old versions. This
>> isn't so much because of changes in R as because of
>> changes in packages.
>> 
>>   -thomas
>> 
>> --
>> Thomas Lumley Professor of Biostatistics University of
>> Auckland
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 



-- 
Wincent Ronggui HUANG
> Sociology Department of Fudan University PhD of City
> University of Hong Kong
> http://asrr.r-forge.r-project.org/rghuang.html

> __
> 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 CMD check and Suggests Packages

[Martin Maechler]

> Dario Strbenac 
> on Wed, 4 May 2011 10:00:07 +1000 writes:

> Hello,
>> If Dario really uses R 2.13.0 (or newer),
>> and he gets the above error message for a package that is not
>> required but only suggested,
>> I think we'd need a clear, ideally simple,
>> reproducible example, here.

> I was able to reproduce it. I made a new package with package.skeleton(), 
then added Suggests: RepitoolsExamples to the DESCRIPTION file, and the result 
of check was :

> * using log directory /home/darstr/testPackage.Rcheck
> * using R version 2.13.0 (2011-04-13)
> * using platform: x86_64-unknown-linux-gnu (64-bit)
> * using session charset: UTF-8
> * checking for file testPackage/DESCRIPTION ... OK
> * checking extension type ... Package
> * this is package testPackage version 1.0
> * checking package dependencies ... ERROR
> Package required but not available: RepitoolsExamples

Thank you, Dario.

For exactly this, I get the correct

* checking package dependencies ... NOTE
Vorgeschlagenes, aber nicht zur Überprüfung verfügbares Paket: 
aPackageNotFoundTypically

(I changed the line in 'DESCRIPTION' to

Suggests: aPackageNotFoundTypically


which is exactly the 'de' translation for
the one I mentioned earlier in this thread:
  c(gettextf("Package suggested but not available for checking: %s", bad),

I'm appending the slightly modified version of your testPackage.tar.gz
which only gives one 'NOTE' (see above) and no warning in  
'R CMD check'...
..
aah .. but when I rerun it as "Joe Average" user, instead of
myself, I get your

* checking package dependencies ... ERROR
Package required but not available: aPackageNotFoundTypically

 dig dig...

I see, it's because in a file I source in ~/.bashrc I have
   export _R_CHECK_FORCE_SUGGESTS_=false
which of course is what Brian and Simon alluded to when they
told you you could turn off the behavior ...

Ok, so we have finally converged

I think I agree with Hervé: If a user has not set the
magic environment variable he should get an ERROR instead of a NOTE
but the error *message* should be the correct one.

Ok, so thanks to Dario and Herve for persevering...
Martin

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

Re: [Rd] R CMD check and Suggests Packages

[Dario Strbenac]

 Original message 
>Date: Wed, 4 May 2011 09:44:14 +0200
>From: Martin Maechler   
>Subject: Re: [Rd] R CMD check and Suggests Packages  
>To: 
>Cc: Martin Maechler , Hervé Pagès 
>, 

>   export _R_CHECK_FORCE_SUGGESTS_=false

Curiously, that option isn't found in the current R-exts manual, but is clearly 
described in a search engine result to a page of the archived 2.5.0 
(2007-04-23) version of the R-exts manual 
(http://pinard.progiciels-bpi.ca/libR/doc/manual/R-exts.html).
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows

[Duncan Murdoch]

On 11-05-03 11:25 PM, Yihui Xie wrote:

1. "Few Windows users use these commands" does not imply they are not
useful, and I have no idea how many Windows users really use them. How
do you run "R CMD build" when you build R packages under Windows? You
don't write "C:/Program Files/R/R-2.13.0/bin/i386/R.exe CMD build", do
you?


I have unusual needs, because I use 2 or 3 different versions of R every 
day.  But if you're interested, the way I do it is to set up shell 
commands that reset the PATH appropriate to the version of R I want to 
use.


A more usual user who always wants to use just one version from the 
command line could modify the PATH appropriately.  I don't object to 
that, I just object to having R do it to unsuspecting users, because as 
Simon said, messing with the PATH can cause problems, and it's difficult 
for the R installer to know if messing with yours will cause trouble for 
you.


In another message you asked about using Sweave.  I almost never use 
Sweave() in R or "R CMD Sweave" at the command line; I have an 
appropriate command configured into my editors, and I run it from there. 
 The PATH does not need to be involved.




I think the reason we have to mess with the PATH variable for each
single software package is that Windows is Not Unix, so you may hate
Windows instead of a package that modifies your PATH variable.

For the choice of i386 and x64, you can let the user decide which bin
path to use. I believe the number of users who frequently switch back
and forth is fairly small.


I already pointed out why that is inappropriate for a lot of users.

Duncan Murdoch



2. Under most circumstances I just keep the latest version of R. To
maintain R code with old R versions will be more and more difficult
with new features and changes coming in. Disk space is cheap, but time
is not.

I'm talking about the default installation directory here and I'm only
wishing that the version string could be removed by default.

Anyway, I think I will go to the batch files approach if these
suggestions are going to be turned down. I just don't want to tell
other people to run Rscript.bat under Windows and Rscript under *nix.
I hope they can be consistent.

Regards,
Yihui
--
Yihui Xie
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA



On Tue, May 3, 2011 at 8:14 PM, Duncan Murdoch  wrote:

On 03/05/2011 7:44 PM, Yihui Xie wrote:


Hi,

I guess this issue must have been brought forward long time ago, but I
still hope you can consider under Windows (during installation):

1. put R's bin path in the PATH variable of the system so that we can
use the commands "R" and "Rscript" more easily;


Few Windows users use those commands.  The ones who do are generally exactly
the ones who know how to edit the PATH variable themselves.

For most users (the ones who start R from the shortcut), there's no need to
mess with the PATH variable.  Personally, I hate programs that do that.  And
with R, it's now complicated, because there are 2 different directories
holding executables:  bin/i386 and bin/x64.  (The bin directory also holds
some, but that's just for back  compatibility.)
How could the installer know which of those to put in the PATH?  At
installation time, a user isn't going to know which one he/she needs.


2. remove the version string like R-2.13.0 in the default installation
directory, e.g. only use a directory like C:/Program Files/R/ instead
of C:/Program Files/R/R-2.13.0/; I know many people just follow the
default setting when installing R, and this version string will often
lead to many (unnecessary) copies of R in the system and brings
difficulty to the first issue (several possible bin directories);


Multiple installs give you the possibility of reproducing things that don't
work in the latest R version.  I think it's a good practice to keep multiple
installs on your system if you have the space, and since disk space is cheap
these days, that's not so uncommon.

Duncan Murdoch



I'm aware of some existing efforts in overcoming the difficulty of
calling R under Windows like the R batch files project
(http://code.google.com/p/batchfiles/), but I believe this is better
to be solved in R directly.

Thanks!

Regards,
Yihui
--
Yihui Xie
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA

__
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] Recursive objects

[Hadley Wickham]

Hi all,

Does anyone have a comprehensive list of recursive-type objects in R?
is.recursive defines them as by exclusion: "most types of objects are
regarded as recursive, except for  vector types, ‘NULL’ and symbols
(as given by ‘as.name’)."  I think this that means recursive objects
are:

 * lists
 * pairlists
 * calls
 * expressions

Did I miss anything?

Hadley

-- 
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

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

[Rd] proposal for package that creates the isomarginal family of two-way contingency tables

[Frank Technow]

Hello,

I developed R code to create the isomarginal family of two-way 
contingency tables.
The isomarginal family are all possible tables given fixed margins. It 
is needed for computing exact test statistics for two-way contingency 
tables in frequentist statistics. I need it for computing a 
normalization constant in a Bayesian model.


I think my code can be useful for others as well so I would like to 
publish it as a package, but only if it is not implemented yet. I know 
that there is the function "r2dtable" in "base", but it creates the 
tables randomly, so that some members of the family appear many times, 
some others not at all (exept n is extremely large). Then there is the 
function "permatfull" in package "vegan", but it apparently just uses 
"r2dtable" (from the documentation).



Currently my code covers only the case where the number of rows is fixed 
to two (with arbitrary number of columns). This makes the implementation 
allot easier, but is of course a limitation.


However, most two-way table problems have a structure with multiple 
categories in one margin but a binary variable in the other. For example 
survival yes or no, sex female or male, or in my field, plant genomics, 
where most of the data is from homozygous lines, genotype AA or BB.


To state my question: Is the code worth publishing?


My code is based on the algorithm in:

Greslin (2003)
Counting and enumerating frequency tables with given margins
Statistica & Applicazioni


I would also be interested in suggestions on how to test it.

For now I used:

unique(r2dtable(n,r,c))

as a reference, but to create the whole family in this way requires a 
huge "n", even for tables of modest dimensions and counts. For example: 
the family of a table with dimensions 2x5,
"r = c(8,100)" and "c = c(1,2,2,98,5)", "r" and "c" being the row and 
column margins, has 103 members (from my code). Trying to find it with:


unique(r2dtable(n,r,c))

eats up more than 16Gb of memory!

Thanks in advance,

Frank











--
Frank Technow
University of Hohenheim
350 Institute of Plant Breeding, Seed Sciences, and Population Genetics
70593 Stuttgart/Germany
Phone: 0049 711 459 23544
e-mail: frank.tech...@uni-hohenheim.de or frank.tech...@gmx.net

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

[Rd] Error in .Fortran Call

[vioravis]

I have the following FORTRAN code converted to a DLL:

! my_xmean.f90
!
! FUNCTIONS/SUBROUTINES exported from my_function.dll:
! my_function - subroutine
!
subroutine my_xmean(X,N,XMEAN) 

! Expose subroutine my_function to users of this DLL
!
!DEC$ ATTRIBUTES DLLEXPORT,C,REFERENCE,ALIAS:'my_xmean_'::my_xmean 

! Body of my_function

DOUBLE PRECISION X(N)

XMEAN=0D0
DO J=1,N
XMEAN=XMEAN+X(J)
END DO
XMEAN=XMEAN/N
RETURN 
end subroutine my_xmean



When I call this DLL from R, it gets loaded properly but the values of XMEAN
calcualted are way off:


x <- 1:6

> .Fortran("my_xmean",as.double(X),as.integer(length(X)),double(1))

[[1]]
[1] 1 2 3 4 5 6

[[2]]
[1] 6

$xmean
[1] 5.336073e-315

Can someone please let me what is causing this huge difference??? Thank you.

Ravi



--
View this message in context: 
http://r.789695.n4.nabble.com/Error-in-Fortran-Call-tp3495319p3495319.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] Recursive objects

[Kenn Konstabel]

On Wed, May 4, 2011 at 3:26 PM, Hadley Wickham  wrote:
> Hi all,
>
> Does anyone have a comprehensive list of recursive-type objects in R?
> is.recursive defines them as by exclusion: "most types of objects are
> regarded as recursive, except for  vector types, ‘NULL’ and symbols
> (as given by ‘as.name’)."  I think this that means recursive objects
> are:
>
>  * lists
>  * pairlists
>  * calls
>  * expressions

is.recursive(environment())
# [1] TRUE

>
> Did I miss anything?
>
> Hadley
>
> --
> Assistant Professor / Dobelman Family Junior Chair
> Department of Statistics / Rice University
> http://had.co.nz/
>
> __
> 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] Capturing the complete unevaluated expression corresponding to function (body + formals)

[Hadley Wickham]

Hi all,

Is there any way to capture the complete unevaluated expression
corresponding to a function?  I want the equivalent of

x <- quote(function(x) x = 3)

But captured after the function is created.  Body and formals each
captures a part, but is there a built in way to get the whole thing?

f <- function(x) x = 3
y <- call("function", formals(f), body(f), attr(f, "source"))
identical(x, y)

Hadley

-- 
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

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

Re: [Rd] Recursive objects

[peter dalgaard]

On May 4, 2011, at 14:35 , Kenn Konstabel wrote:

> On Wed, May 4, 2011 at 3:26 PM, Hadley Wickham  wrote:
>> Hi all,
>> 
>> Does anyone have a comprehensive list of recursive-type objects in R?
>> is.recursive defines them as by exclusion: "most types of objects are
>> regarded as recursive, except for  vector types, ‘NULL’ and symbols
>> (as given by ‘as.name’)."  I think this that means recursive objects
>> are:
>> 
>>  * lists
>>  * pairlists
>>  * calls
>>  * expressions
> 
> is.recursive(environment())
> # [1] TRUE


Closures:

> is.recursive(ls)
[1] TRUE


> 
>> 
>> Did I miss anything?
>> 
>> Hadley
>> 
>> --
>> Assistant Professor / Dobelman Family Junior Chair
>> Department of Statistics / Rice University
>> http://had.co.nz/
>> 
>> __
>> 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

-- 
Peter Dalgaard
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [Rd] Recursive objects

[Hadley Wickham]

Thanks to you both for reminding me about those important recursive objects!
Hadley

On Wed, May 4, 2011 at 7:49 AM, peter dalgaard  wrote:
>
> On May 4, 2011, at 14:35 , Kenn Konstabel wrote:
>
>> On Wed, May 4, 2011 at 3:26 PM, Hadley Wickham  wrote:
>>> Hi all,
>>>
>>> Does anyone have a comprehensive list of recursive-type objects in R?
>>> is.recursive defines them as by exclusion: "most types of objects are
>>> regarded as recursive, except for  vector types, ‘NULL’ and symbols
>>> (as given by ‘as.name’)."  I think this that means recursive objects
>>> are:
>>>
>>>  * lists
>>>  * pairlists
>>>  * calls
>>>  * expressions
>>
>> is.recursive(environment())
>> # [1] TRUE
>
>
> Closures:
>
>> is.recursive(ls)
> [1] TRUE
>
>
>>
>>>
>>> Did I miss anything?
>>>
>>> Hadley
>>>
>>> --
>>> Assistant Professor / Dobelman Family Junior Chair
>>> Department of Statistics / Rice University
>>> http://had.co.nz/
>>>
>>> __
>>> 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
>
> --
> Peter Dalgaard
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Email: pd@cbs.dk  Priv: pda...@gmail.com
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

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

Re: [Rd] Error in .Fortran Call

[Duncan Murdoch]

On 04/05/2011 8:26 AM, vioravis wrote:

I have the following FORTRAN code converted to a DLL:

! my_xmean.f90
!
! FUNCTIONS/SUBROUTINES exported from my_function.dll:
! my_function - subroutine
!
subroutine my_xmean(X,N,XMEAN)

! Expose subroutine my_function to users of this DLL
!
!DEC$ ATTRIBUTES DLLEXPORT,C,REFERENCE,ALIAS:'my_xmean_'::my_xmean

! Body of my_function

DOUBLE PRECISION X(N)

XMEAN=0D0
DO J=1,N
XMEAN=XMEAN+X(J)
END DO
XMEAN=XMEAN/N
RETURN
end subroutine my_xmean



When I call this DLL from R, it gets loaded properly but the values of XMEAN
calcualted are way off:


x<- 1:6

>  .Fortran("my_xmean",as.double(X),as.integer(length(X)),double(1))

[[1]]
[1] 1 2 3 4 5 6

[[2]]
[1] 6

$xmean
[1] 5.336073e-315

Can someone please let me what is causing this huge difference??? Thank you.


I don't see a declaration of its type in the Fortran code, so it 
probably defaulted to REAL, not DOUBLE PRECISION.


Duncan Murdoch

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

Re: [Rd] Error in .Fortran Call

[Simone Giannerini]

add

IMPLICIT NONE
DOUBLE PRECISION X(N),XMEAN
INTEGER N,J

to your subroutine.

Ciao

Simone

P.S. It is best to include IMPLICIT NONE in all of your subroutines and to
avoid underscores in subroutines' names.



On Wed, May 4, 2011 at 2:26 PM, vioravis  wrote:

> I have the following FORTRAN code converted to a DLL:
>
> ! my_xmean.f90
> !
> ! FUNCTIONS/SUBROUTINES exported from my_function.dll:
> ! my_function - subroutine
> !
> subroutine my_xmean(X,N,XMEAN)
>
> ! Expose subroutine my_function to users of this DLL
> !
> !DEC$ ATTRIBUTES DLLEXPORT,C,REFERENCE,ALIAS:'my_xmean_'::my_xmean
>
> ! Body of my_function
>
> DOUBLE PRECISION X(N)
>
> XMEAN=0D0
> DO J=1,N
> XMEAN=XMEAN+X(J)
> END DO
> XMEAN=XMEAN/N
> RETURN
> end subroutine my_xmean
>
>
>
> When I call this DLL from R, it gets loaded properly but the values of
> XMEAN
> calcualted are way off:
>
>
> x <- 1:6
>
> > .Fortran("my_xmean",as.double(X),as.integer(length(X)),double(1))
>
> [[1]]
> [1] 1 2 3 4 5 6
>
> [[2]]
> [1] 6
>
> $xmean
> [1] 5.336073e-315
>
> Can someone please let me what is causing this huge difference??? Thank
> you.
>
> Ravi
>
>
>
> --
> View this message in context:
> http://r.789695.n4.nabble.com/Error-in-Fortran-Call-tp3495319p3495319.html
> Sent from the R devel mailing list archive at Nabble.com.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
__

Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126  Bologna,  ITALY
Tel: +39 051 2098262  Fax: +39 051 232153
http://www2.stat.unibo.it/giannerini/
__

[[alternative HTML version deleted]]

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

Re: [Rd] Recursive objects

[luke-tierney]

I never use is.recursive/is.atomic because the definition they use for
an object to be recursive doesn't usually coincide with what I am
interested in. (If you want to know what that definition is you can
look at the source code, coerce.c:1790.) In computing on the language I
would want one notion where pretty much only calls are recursive in
the sense of having componets that need to be recursed into (you can
see how that is handled in the byte code compiler which is in the
sources as a noweb file). At the internal level, for example in the
GC, _every_ object is recursive in the sence of needing to be checked
for pointers to other objects, because of the attribute field.

There have been discussions of this previeously -- you might search
the archive.

Best,

luke

On Wed, 4 May 2011, Hadley Wickham wrote:


Hi all,

Does anyone have a comprehensive list of recursive-type objects in R?
is.recursive defines them as by exclusion: "most types of objects are
regarded as recursive, except for  vector types, ‘NULL’ and symbols
(as given by ‘as.name’)."  I think this that means recursive objects
are:

* lists
* pairlists
* calls
* expressions

Did I miss anything?

Hadley




--
Luke Tierney
Statistics and Actuarial Science
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:  l...@stat.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] Capturing the complete unevaluated expression corresponding to function (body + formals)

[Duncan Murdoch]

On 04/05/2011 8:38 AM, Hadley Wickham wrote:

Hi all,

Is there any way to capture the complete unevaluated expression
corresponding to a function?  I want the equivalent of

x<- quote(function(x) x = 3)

But captured after the function is created.  Body and formals each
captures a part, but is there a built in way to get the whole thing?


Internally, "function" is a function that produces a closure object.  
After you call it and the function is created, the inputs are gone, all 
you have is the result.  But you can reconstruct it as you did below, 
because "function" basically just glues the parts together (and adds an 
environment as well).


Duncan Murdoch

f<- function(x) x = 3
y<- call("function", formals(f), body(f), attr(f, "source"))
identical(x, y)

Hadley



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

[Rd] General "nil" reference class object

[Jon Clayden]

Dear John and others,

I've been wondering about whether there's any way to indicate a "nil"
reference class object, which will represent "no value", and be tested
for, but not fail the internal type checking. NULL is the obvious
choice (or seems so to me), but can only be used if an explicit class
union is created:

> Foo <- setRefClass("Foo")
> Bar <- setRefClass("Bar", fields=list(foo="Foo"))
> Bar$new(foo=NULL)
Error in as(value, "Foo") :
  no method or default for coercing "NULL" to "Foo"
> setClassUnion("FooOrNull", c("Foo","NULL"))
[1] "FooOrNull"
> Bar <- setRefClass("Bar", fields=list(foo="FooOrNull"))
> Bar$new(foo=NULL)
An object of class "Bar"

> is.null(Bar$new(foo=NULL)$foo)
[1] TRUE

Other languages allow things like "MyClass object = null", and it
seems to me that it would be helpful to have a value which will always
give TRUE for "is(object,)", but will
specifically indicate a nil reference. One possible ad-hoc solution is
to define the "empty" object of a base class to be "nil" (see below),
but it seems like it would be better to have a value specifically
designed for this purpose.

> nilObject <- Foo$new()
> is.nilObject <- function (x) identical(x,nilObject)
> Bar <- setRefClass("Bar", fields=list(foo="Foo"), methods=list(
+ initialize=function (foo=nilObject) { initFields(foo=foo) }))
> is.nilObject(Bar$new()$foo)
[1] TRUE

Is there already something like this that I'm not aware of? If not,
would it be possible and generally desirable to create it?

All the best,
Jon


--
Jonathan D Clayden, PhD
Lecturer in Neuroimaging and Biophysics
Imaging and Biophysics Unit
UCL Institute of Child Health
30 Guilford Street
LONDON  WC1N 1EH
United Kingdom

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

Re: [Rd] Recursive objects

[Hadley Wickham]

> I never use is.recursive/is.atomic because the definition they use for
> an object to be recursive doesn't usually coincide with what I am
> interested in. (If you want to know what that definition is you can
> look at the source code, coerce.c:1790.) In computing on the language I
> would want one notion where pretty much only calls are recursive in
> the sense of having componets that need to be recursed into (you can
> see how that is handled in the byte code compiler which is in the
> sources as a noweb file). At the internal level, for example in the
> GC, _every_ object is recursive in the sence of needing to be checked
> for pointers to other objects, because of the attribute field.

Thanks Luke, I'll check those references out.

> There have been discussions of this previeously -- you might search
> the archive.

Any hints as to what to search for?

Hadley

-- 
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

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

Re: [Rd] Recursive objects

[Barry Rowlingson]

On Wed, May 4, 2011 at 2:21 PM, Hadley Wickham  wrote:

> Any hints as to what to search for?

 For recursive objects, search for recursive objects.

Barry

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

Re: [Rd] Capturing the complete unevaluated expression corresponding to function (body + formals)

[Hadley Wickham]

On Wed, May 4, 2011 at 8:07 AM, Duncan Murdoch  wrote:
> On 04/05/2011 8:38 AM, Hadley Wickham wrote:
>>
>> Hi all,
>>
>> Is there any way to capture the complete unevaluated expression
>> corresponding to a function?  I want the equivalent of
>>
>> x<- quote(function(x) x = 3)
>>
>> But captured after the function is created.  Body and formals each
>> captures a part, but is there a built in way to get the whole thing?
>
> Internally, "function" is a function that produces a closure object.  After
> you call it and the function is created, the inputs are gone, all you have
> is the result.  But you can reconstruct it as you did below, because
> "function" basically just glues the parts together (and adds an environment
> as well).

Ok, I was getting confused because it looks like deparse and print(f,
useSource = F) can print the whole thing. But looking at the source, I
see that they reconstruct the function from the formals and the body
too.

Hadley

-- 
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

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

Re: [Rd] Recursive objects

[Hadley Wickham]

On Wed, May 4, 2011 at 8:24 AM, Barry Rowlingson
 wrote:
> On Wed, May 4, 2011 at 2:21 PM, Hadley Wickham  wrote:
>
>> Any hints as to what to search for?
>
>  For recursive objects, search for recursive objects.

Well, I was hoping Luke was meaning discussions about computing on the
language more generally...

Searching for recursive objects (with an admittedly quick skimming on
titles), didn't seem to find anything relevant, except that it was me
who suggested the wording "Most types of objects are regarded as
recursive, except for atomic vector types, ‘NULL’ and symbols (as
given by ‘as.name’)"

Hadley


-- 
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

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

Re: [Rd] R CMD check and Suggests Packages

[Simon Urbanek]

In current R it is described in R-ints instead:

http://r.research.att.com/man/R-ints.html#Tools

But don't ask me about the rationale. That said, you can search all manuals in 
Google by simply using

foo site:http://r.research.att.com/man/

where "foo" is your query

Cheers,
S




On May 4, 2011, at 4:00 AM, Dario Strbenac wrote:

>  Original message 
>> Date: Wed, 4 May 2011 09:44:14 +0200
>> From: Martin Maechler   
>> Subject: Re: [Rd] R CMD check and Suggests Packages  
>> To: 
>> Cc: Martin Maechler , Hervé Pagès 
>> , 
> 
>>  export _R_CHECK_FORCE_SUGGESTS_=false
> 
> Curiously, that option isn't found in the current R-exts manual, but is 
> clearly described in a search engine result to a page of the archived 2.5.0 
> (2007-04-23) version of the R-exts manual 
> (http://pinard.progiciels-bpi.ca/libR/doc/manual/R-exts.html).
> __
> 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] Curry: proposed new functional programming, er, function.

[Hadley Wickham]

I thought I might bring this up again - it now seems like Curry would
be a natural fit with Reduce, Filter, Find, Map, Negate and Position.
Any chance we might see this in a future version of R?

Hadley

On Thu, Nov 1, 2007 at 2:00 PM, Byron Ellis  wrote:
> Hi all (especially R-core) I suppose,
>
> With the introduction of the new functional programming functions into
> base I thought I'd ask for a Curry() function. I use a simple one that
> looks this:
>
> Curry = function(FUN,...) { .orig = list(...);function(...)
> do.call(FUN,c(.orig,list(...))) }
>
> This comes in really handy when using say, heatmap():
>
> heatmap(mydata,hclustfun=Curry(hclust,method="average"))
>
> or other functions where there are ... arguments, but it's not clear
> where they should end up.
>
> --
> Byron Ellis (byron.el...@gmail.com)
> "Oook" -- The Librarian
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

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

Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows

[Gabor Grothendieck]

On Wed, May 4, 2011 at 8:11 AM, Duncan Murdoch  wrote:
> On 11-05-03 11:25 PM, Yihui Xie wrote:
>>
>> 1. "Few Windows users use these commands" does not imply they are not
>> useful, and I have no idea how many Windows users really use them. How
>> do you run "R CMD build" when you build R packages under Windows? You
>> don't write "C:/Program Files/R/R-2.13.0/bin/i386/R.exe CMD build", do
>> you?
>
> I have unusual needs, because I use 2 or 3 different versions of R every
> day.  But if you're interested, the way I do it is to set up shell commands
> that reset the PATH appropriate to the version of R I want to use.
>
> A more usual user who always wants to use just one version from the command
> line could modify the PATH appropriately.  I don't object to that, I just
> object to having R do it to unsuspecting users, because as Simon said,
> messing with the PATH can cause problems, and it's difficult for the R
> installer to know if messing with yours will cause trouble for you.
>
> In another message you asked about using Sweave.  I almost never use
> Sweave() in R or "R CMD Sweave" at the command line; I have an appropriate
> command configured into my editors, and I run it from there.  The PATH does
> not need to be involved.
>
>
>> I think the reason we have to mess with the PATH variable for each
>> single software package is that Windows is Not Unix, so you may hate
>> Windows instead of a package that modifies your PATH variable.
>>
>> For the choice of i386 and x64, you can let the user decide which bin
>> path to use. I believe the number of users who frequently switch back
>> and forth is fairly small.
>
> I already pointed out why that is inappropriate for a lot of users.

The batchfiles handle this using Rversions.bat.  Without arguments it
lists the available R versions and with an argument it makes that the
current version of R so that Rgui.bat, R.bat, invoke that version.
Rversions.bat works by running the appropriate RSetReg.exe utility
(which is a utility that is included in every R distribution).

Of course if you just want to run a specific version of Rgui each
version has a separate icon on the desktop so one can select the
version of interest that way too.

I personally keep about half a dozen back versions of R for the
reasons others have mentioned and these would include one R-13.x
version, one R-12.x version, etc.  I literally use x in the name since
only the most recent version in any such series is stored. That is,
when a new R-2.13.x comes out I just install it over the existing
R-2.13.x:

 Directory of C:\Program Files\R

31/03/2010  02:37 PM  R-2.10.x
01/06/2010  01:03 PM  R-2.11.x
22/03/2011  03:25 PM  R-2.12.x
26/04/2011  01:45 PM  R-2.13.x



-- 
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com

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

Re: [Rd] Curry: proposed new functional programming, er, function.

[Ravi Varadhan]

I too would like this (being an Indian!).

Here is an example that came up just yesterday with regards to solving a 
quadrature problem using the "cubature" package.  The adaptIntegrate function 
does not allow additional arguments via ...

Uwe suggested a work around, but `Curry' would solve it nicely (and it also 
tastes better!):

Curry = function(FUN,...) { 
.orig = list(...)
function(...) do.call(FUN,c(.orig, list(...))) 
}

require(cubature)

f <- function(x, a) cos(2*pi*x*a)  # a simple test function

# this works
a <- 0.2
adaptIntegrate(function(x, argA=a) f(x, a=argA), lower=0, upper=2)

# but this doesn't work
rm(a)
adaptIntegrate(function(x, argA=a) f(x, a=argA), lower=0, upper=2, a=0.2)


# Use of Curry
adaptIntegrate(Curry(f, a=0.2), lower=0, upper=2)

Best,
Ravi.

---
Ravi Varadhan, Ph.D.
Assistant Professor,
Division of Geriatric Medicine and Gerontology School of Medicine Johns Hopkins 
University

Ph. (410) 502-2619
email: rvarad...@jhmi.edu


-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On 
Behalf Of Hadley Wickham
Sent: Wednesday, May 04, 2011 10:29 AM
To: Byron Ellis
Cc: R Development Mailing List
Subject: Re: [Rd] Curry: proposed new functional programming, er, function.

I thought I might bring this up again - it now seems like Curry would
be a natural fit with Reduce, Filter, Find, Map, Negate and Position.
Any chance we might see this in a future version of R?

Hadley

On Thu, Nov 1, 2007 at 2:00 PM, Byron Ellis  wrote:
> Hi all (especially R-core) I suppose,
>
> With the introduction of the new functional programming functions into
> base I thought I'd ask for a Curry() function. I use a simple one that
> looks this:
>
> Curry = function(FUN,...) { .orig = list(...);function(...)
> do.call(FUN,c(.orig,list(...))) }
>
> This comes in really handy when using say, heatmap():
>
> heatmap(mydata,hclustfun=Curry(hclust,method="average"))
>
> or other functions where there are ... arguments, but it's not clear
> where they should end up.
>
> --
> Byron Ellis (byron.el...@gmail.com)
> "Oook" -- The Librarian
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

__
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] Recursive objects

[Michael Sumner]

Fortune!

On Wed, May 4, 2011 at 11:24 PM, Barry Rowlingson <
b.rowling...@lancaster.ac.uk> wrote:

> On Wed, May 4, 2011 at 2:21 PM, Hadley Wickham  wrote:
>
> > Any hints as to what to search for?
>
>  For recursive objects, search for recursive objects.
>
> Barry
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Michael Sumner
Institute for Marine and Antarctic Studies, University of Tasmania
Hobart, Australia
e-mail: mdsum...@gmail.com

[[alternative HTML version deleted]]

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

Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows

[Ted Byers]

> -Original Message-
> From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r-
> project.org] On Behalf Of Gabor Grothendieck
> Sent: May-04-11 10:35 AM
> To: Duncan Murdoch
> Cc: R-devel
> Subject: Re: [Rd] Wishlist: write R's bin path to the PATH variable and
remove
> the version string in the installation dir under Windows
> 
> [snip]
> I personally keep about half a dozen back versions of R for the reasons
> others have mentioned and these would include one R-13.x version, one R-
> 12.x version, etc.  I literally use x in the name since only the most
recent
> version in any such series is stored. That is, when a new R-2.13.x comes
out I
> just install it over the existing
> R-2.13.x:
> 
>  Directory of C:\Program Files\R
> 
> 31/03/2010  02:37 PM  R-2.10.x
> 01/06/2010  01:03 PM  R-2.11.x
> 22/03/2011  03:25 PM  R-2.12.x
> 26/04/2011  01:45 PM  R-2.13.x
> 
> 
Do you keep  the RTools version specific to each version of R installed too?
If so, how do you manage that so that each version of R finds the right
version of RTools when it needs it?  

I don't use RTools much, but I need it to install some fo the packages I use
from source since there are no binary distributions for them (for 64 bit
Windows).  I don't typically keep any more than two versions of R on my
machine at any one time, but I don't remove an older version until I have
verified that my R scripts work fine in the latest release.  So usually
there is only one version on my machine, but there will be two for a short
while after a new release.  But, my normal practice, as I describe here,
would be disrupted if R's installer wrote R's bin path to my system path (in
fact, I hate that for any software I use, even though in some cases there's
no way to avoid it).

Thanks

Ted

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

Re: [Rd] Curry: proposed new functional programming, er, function.

[Duncan Murdoch]

On 04/05/2011 10:40 AM, Ravi Varadhan wrote:

I too would like this (being an Indian!).

Here is an example that came up just yesterday with regards to solving a quadrature 
problem using the "cubature" package.  The adaptIntegrate function does not 
allow additional arguments via ...

Uwe suggested a work around, but `Curry' would solve it nicely (and it also 
tastes better!):

Curry = function(FUN,...) {
.orig = list(...)
function(...) do.call(FUN,c(.orig, list(...)))
}

require(cubature)

f<- function(x, a) cos(2*pi*x*a)  # a simple test function

# this works
a<- 0.2
adaptIntegrate(function(x, argA=a) f(x, a=argA), lower=0, upper=2)

# but this doesn't work
rm(a)
adaptIntegrate(function(x, argA=a) f(x, a=argA), lower=0, upper=2, a=0.2)


# Use of Curry
adaptIntegrate(Curry(f, a=0.2), lower=0, upper=2)


Two objections:

1.  I don't see how that is preferable to

adaptIntegrate(function(x) f(x, a=0.2), lower=0, upper=2)

2.  There seems to be confusion about what currying means.  The 
Wikipedia page  indicates that 
the function Curry() defined above is really doing "partial function 
application", not currying.  I'm in no position to judge whether Byron 
got it right or Wikipedia did, but this suggests to me that the name 
"Curry" is inappropriate, since at least some people who know what 
currying is would not guess that it does what it does.


Duncan Murdoch


Best,
Ravi.

---
Ravi Varadhan, Ph.D.
Assistant Professor,
Division of Geriatric Medicine and Gerontology School of Medicine Johns Hopkins 
University

Ph. (410) 502-2619
email: rvarad...@jhmi.edu


-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On 
Behalf Of Hadley Wickham
Sent: Wednesday, May 04, 2011 10:29 AM
To: Byron Ellis
Cc: R Development Mailing List
Subject: Re: [Rd] Curry: proposed new functional programming, er, function.

I thought I might bring this up again - it now seems like Curry would
be a natural fit with Reduce, Filter, Find, Map, Negate and Position.
Any chance we might see this in a future version of R?

Hadley

On Thu, Nov 1, 2007 at 2:00 PM, Byron Ellis  wrote:
>  Hi all (especially R-core) I suppose,
>
>  With the introduction of the new functional programming functions into
>  base I thought I'd ask for a Curry() function. I use a simple one that
>  looks this:
>
>  Curry = function(FUN,...) { .orig = list(...);function(...)
>  do.call(FUN,c(.orig,list(...))) }
>
>  This comes in really handy when using say, heatmap():
>
>  heatmap(mydata,hclustfun=Curry(hclust,method="average"))
>
>  or other functions where there are ... arguments, but it's not clear
>  where they should end up.
>
>  --
>  Byron Ellis (byron.el...@gmail.com)
>  "Oook" -- The Librarian
>
>  __
>  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] Curry: proposed new functional programming, er, function.

[Gabor Grothendieck]

On Wed, May 4, 2011 at 10:40 AM, Ravi Varadhan  wrote:
> I too would like this (being an Indian!).
>
> Here is an example that came up just yesterday with regards to solving a 
> quadrature problem using the "cubature" package.  The adaptIntegrate function 
> does not allow additional arguments via ...
>
> Uwe suggested a work around, but `Curry' would solve it nicely (and it also 
> tastes better!):
>
> Curry = function(FUN,...) {
> .orig = list(...)
> function(...) do.call(FUN,c(.orig, list(...)))
> }
>
> require(cubature)
>
> f <- function(x, a) cos(2*pi*x*a)  # a simple test function
>
> # this works
> a <- 0.2
> adaptIntegrate(function(x, argA=a) f(x, a=argA), lower=0, upper=2)
>
> # but this doesn't work
> rm(a)
> adaptIntegrate(function(x, argA=a) f(x, a=argA), lower=0, upper=2, a=0.2)
>
>
> # Use of Curry
> adaptIntegrate(Curry(f, a=0.2), lower=0, upper=2)
>

Here is another approach. If we preface any function with gsubfn's fn$
then it will turn formulas (subject to certain rules to determine
which to pay attention to) into functions.

1. Here it is applied to the cubature example

> library(cubature)
> library(gsubfn)
Loading required package: proto
>
> fn$adaptIntegrate(~ f(x, 0.2), lower=0, upper=2)
$integral
[1] 0.4677446

$error
[1] 1.247382e-14

$functionEvaluations
[1] 15

$returnCode
[1] 0


2. and here is the heatmap example redone.  The example line is to
compute x so that the code is self contained:

library(gsubfn)
example(heatmap)

fn$heatmap(x, hclustfun = ~ hclust(x, method="average"))

-- 
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com

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

Re: [Rd] Curry: proposed new functional programming, er, function.

[luke-tierney]

On Wed, 4 May 2011, Ravi Varadhan wrote:


I too would like this (being an Indian!).


I would not.


Here is an example that came up just yesterday with regards to solving a quadrature 
problem using the "cubature" package.  The adaptIntegrate function does not 
allow additional arguments via ...

Uwe suggested a work around, but `Curry' would solve it nicely (and it also 
tastes better!):

Curry = function(FUN,...) {
.orig = list(...)
function(...) do.call(FUN,c(.orig, list(...)))
}


This has quite different behavior with respect to evaluation/lazy
evaluation than an analogous anonymous function. In addition, do.call
has some fairly strange aspect so it with respect to how it intereacts
with sys.xyz functions, and does not do what you want in many cases I
care about when quote = FALSE, as is the default.  Adding this would
create more problems than is solves.


require(cubature)

f <- function(x, a) cos(2*pi*x*a)  # a simple test function

# this works
a <- 0.2
adaptIntegrate(function(x, argA=a) f(x, a=argA), lower=0, upper=2)


Yes -- as do a number of other variations.


# but this doesn't work
rm(a)
adaptIntegrate(function(x, argA=a) f(x, a=argA), lower=0, upper=2, a=0.2)


Of course not -- why would anyone think it would?




# Use of Curry
adaptIntegrate(Curry(f, a=0.2), lower=0, upper=2)


The _concept_ of currying is useful, and maybe more can be done to
provide guidance and education on how to do it, but adding a function
that sometimes works and somesimes does surprising things is not the
way to go.

Best,

luke



Best,
Ravi.

---
Ravi Varadhan, Ph.D.
Assistant Professor,
Division of Geriatric Medicine and Gerontology School of Medicine Johns Hopkins 
University

Ph. (410) 502-2619
email: rvarad...@jhmi.edu


-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On 
Behalf Of Hadley Wickham
Sent: Wednesday, May 04, 2011 10:29 AM
To: Byron Ellis
Cc: R Development Mailing List
Subject: Re: [Rd] Curry: proposed new functional programming, er, function.

I thought I might bring this up again - it now seems like Curry would
be a natural fit with Reduce, Filter, Find, Map, Negate and Position.
Any chance we might see this in a future version of R?

Hadley

On Thu, Nov 1, 2007 at 2:00 PM, Byron Ellis  wrote:

Hi all (especially R-core) I suppose,

With the introduction of the new functional programming functions into
base I thought I'd ask for a Curry() function. I use a simple one that
looks this:

Curry = function(FUN,...) { .orig = list(...);function(...)
do.call(FUN,c(.orig,list(...))) }

This comes in really handy when using say, heatmap():

heatmap(mydata,hclustfun=Curry(hclust,method="average"))

or other functions where there are ... arguments, but it's not clear
where they should end up.

--
Byron Ellis (byron.el...@gmail.com)
"Oook" -- The Librarian

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








--
Luke Tierney
Statistics and Actuarial Science
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:  l...@stat.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] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows

[Yihui Xie]

If I am already able to open R, there is no need to post the request
here. I want to be able to run R without knowing where it is from
another software package. Your batch files fit in this purpose, and
the only problem is it is a little bit slower since it takes time to
look for R in the system via several approaches.

Regards,
Yihui
--
Yihui Xie 
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA



On Wed, May 4, 2011 at 12:28 AM, Gabor Grothendieck
 wrote:
> On Wed, May 4, 2011 at 1:04 AM, Yihui Xie  wrote:
>> Thanks! But I'm sorry this is not what I wanted. I just hope we can
>> call R as a command like we do under *nix -- this will make it easier
>> for *other* software packages to find R.
>
> You asked for an R program that gives the ability to run R.exe,
> Rscript.exe, etc. from the command line and that indeed is what it
> enables in the spawned session.
>
> --
> Statistics & Software Consulting
> GKX Group, GKX Associates Inc.
> tel: 1-877-GKX-GROUP
> email: ggrothendieck at gmail.com
>

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

Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows

[Gabor Grothendieck]

On Wed, May 4, 2011 at 11:15 AM, Yihui Xie  wrote:
> If I am already able to open R, there is no need to post the request
> here. I want to be able to run R without knowing where it is from
> another software package. Your batch files fit in this purpose, and
> the only problem is it is a little bit slower since it takes time to
> look for R in the system via several approaches.
>

Not on my laptop (which is not particularly powerful).   Rgui.bat
brings up R nearly instantaneously.

-- 
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com

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

Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows

[Gabor Grothendieck]

On Wed, May 4, 2011 at 10:53 AM, Ted Byers  wrote:
>> -Original Message-
>> From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r-
>> project.org] On Behalf Of Gabor Grothendieck
>> Sent: May-04-11 10:35 AM
>> To: Duncan Murdoch
>> Cc: R-devel
>> Subject: Re: [Rd] Wishlist: write R's bin path to the PATH variable and
> remove
>> the version string in the installation dir under Windows
>>
>> [snip]
>> I personally keep about half a dozen back versions of R for the reasons
>> others have mentioned and these would include one R-13.x version, one R-
>> 12.x version, etc.  I literally use x in the name since only the most
> recent
>> version in any such series is stored. That is, when a new R-2.13.x comes
> out I
>> just install it over the existing
>> R-2.13.x:
>>
>>  Directory of C:\Program Files\R
>>
>> 31/03/2010 02:37 PM              R-2.10.x
>> 01/06/2010  01:03 PM              R-2.11.x
>> 22/03/2011  03:25 PM              R-2.12.x
>> 26/04/2011 01:45 PM              R-2.13.x
>>
>>
> Do you keep  the RTools version specific to each version of R installed too?
> If so, how do you manage that so that each version of R finds the right
> version of RTools when it needs it?
>
> I don't use RTools much, but I need it to install some fo the packages I use
> from source since there are no binary distributions for them (for 64 bit
> Windows).  I don't typically keep any more than two versions of R on my
> machine at any one time, but I don't remove an older version until I have
> verified that my R scripts work fine in the latest release.  So usually
> there is only one version on my machine, but there will be two for a short
> while after a new release.  But, my normal practice, as I describe here,
> would be disrupted if R's installer wrote R's bin path to my system path (in
> fact, I hate that for any software I use, even though in some cases there's
> no way to avoid it).
>
> Thanks
>
> Ted
>
>

Typically I do my development on the latest version of R so I only
need one version of Rtools.  The older versions of R are just for
checking older software.  There is a program RtoolsVersion.bat in the
batchfiles that will tell you which  version of Rtools you have (which
it finds by first looking in the registry and if not found there looks
for an R_TOOLS environment variable and if still not found looks for
C:\Rtools):

C:\tmp2>RtoolsVersion
RtoolsVersion.bat: Rtools found at: c:\Rtools
Rtools version 2.13.0.1901

(There is also Rtools.bat that will temporarily add Rtools to your
path (although if you use Rcmd.bat, R.bat, etc. then they can find
Rtools without it being on the path so mostly one does not need to use
Rtools.bat).

If people wanted to have multiple versions of Rtools, Rtools would
ideally have a tool similar to R's own RSetReg.exe .  Another
possibility would be to turn Rtools into an R package so that R's
library mechanism handled the versioning.

Regarding permanently putting R on the path, I agree that it would be
annoying having R permanently there and for that reason the batchfiles
do not do that.

-- 
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com

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

Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows

[Yihui Xie]

In terms of a personal use, that is absolutely fine. From the
perspective of a developer, you cannot stop a user from upgrading to
newer versions. Perhaps it is a matter of personal taste; I'm worried
more about adapting to latest versions than maintaining old versions.
If the new versions works fine, I will remove all the old versions. I
have never run into troubles in which I have no choice but to use the
old version of R.

Regards,
Yihui
--
Yihui Xie 
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA



On Wed, May 4, 2011 at 12:46 AM, Wincent  wrote:
> I also prefer to keep the old versions.
>
> Sometimes, I have spent time to set up the system with older version
> and don't want to update to the latest (e.g. the new RGtk2 needs
> updated GTk2 as well) because the older still works and I don't need
> the new features.
>
> Regards
> Ronggui
>

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

[Rd] tkrplot not working in R 2.13.0

[Greg Snow]

The tkrplot package is not working in version 2.13.0 for windows.  I contacted 
the maintainer who unfortunately does not have easy access to a windows 
computer and says that it is working on the other platforms.

I traced the problem down to the line in the .First.lib function:

.Tcl(paste("load", file, "Rplot"))

With file being "C:/Program 
Files/R/R-2.13.0/library/tkrplot/libs/i386/tkrplot.dll" on my system.  I did 
check that the file exists and it can even be loaded using dyn.load, but when 
running the .Tcl command by hand it produces the following error:

Error in structure(.External("dotTcl", ..., PACKAGE = "tcltk"), class = 
"tclObj") : 
  [tcl] could not find interpreter "Rplot".

It works in previous versions of R, so I am guessing that this is due to some 
change in R, or the tcl with R 2.13.0, or how tkrplot was compiled under the 
new R, or possibly something else.

Does anyone else have any insights?



> sessionInfo()
R version 2.13.0 (2011-04-13)
Platform: i386-pc-mingw32/i386 (32-bit)

locale:
[1] LC_COLLATE=English_United States.1252 
[2] LC_CTYPE=English_United States.1252   
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C  
[5] LC_TIME=English_United States.1252

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

other attached packages:
[1] TeachingDemos_2.7 tkrplot_0.0-19   

loaded via a namespace (and not attached):
[1] tools_2.13.0

Thanks,

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111

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

Re: [Rd] Curry: proposed new functional programming, er, function.

[Hadley Wickham]

>> # Use of Curry
>> adaptIntegrate(Curry(f, a=0.2), lower=0, upper=2)
>
> The _concept_ of currying is useful, and maybe more can be done to
> provide guidance and education on how to do it, but adding a function
> that sometimes works and somesimes does surprising things is not the
> way to go.

What about an alternative approach?

Curry <- function(FUN, ...) {
  args <- match.call(expand.dots = FALSE)$...
  args$... <- as.name("...")

  curry_call <- as.call(c(list(as.name("FUN")), args))
  function(...) {
eval(curry_call)
  }
}

Or maybe

Curry <- function(FUN, ...) {
  args <- match.call(expand.dots = FALSE)$...
  args$... <- as.name("...")

  curry_call <- as.call(c(list(as.name("FUN")), args))
  eval(bquote(function(...) .(curry_call)))
}


I think this is pretty close to what you'd get if you made an
anonymous function (but I'm probably missing something)

Hadley

-- 
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

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

Re: [Rd] Curry: proposed new functional programming, er, function.

[Hadley Wickham]

>> # Use of Curry
>> adaptIntegrate(Curry(f, a=0.2), lower=0, upper=2)
>
> Two objections:
>
> 1.  I don't see how that is preferable to
>
> adaptIntegrate(function(x) f(x, a=0.2), lower=0, upper=2)

It's less typing?

A more helpful use is when you have a list of functions:

funs <- list(
  sum = sum,
  mean = mean,
  median = median
)

with Curry function you can do :

funs2 <- lapply(funs, Curry, na.rm = TRUE)

as opposed to

funs2 <- list(
  sum = function(x, ...) sum(x, ..., na.rm = TRUE),
  mean = function(x, ...) mean(x, ..., na.rm = TRUE),
  median = function(x, ...) median(x, ..., na.rm = TRUE)
)

> 2.  There seems to be confusion about what currying means.  The Wikipedia
> page  indicates that the function
> Curry() defined above is really doing "partial function application", not
> currying.  I'm in no position to judge whether Byron got it right or
> Wikipedia did, but this suggests to me that the name "Curry" is
> inappropriate, since at least some people who know what currying is would
> not guess that it does what it does.

I'm not completely sure that discussion is canonical: wikipedia citing
a blog post does not a precedent make.  I agree the distinction is
sensible, but I think the partial function application sense of
currying is standard enough that it would cause much confusion. We are
not claiming that R has low-level currying, we're creating a function
to simulate a useful property of currying.

Hadley

-- 
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

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

Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows

[Yihui Xie]

My suggestion was to mimic *nix systems: put the executable binaries
in the same place *by default* (e.g. /usr/bin/ or /usr/local/bin). Why
isn't the default bin path for R under *nix something like
/usr/bin/R-2.13.0/? If the users want to install multiple versions,
they still have the choice to install them elsewhere. I'm not denying
the possible necessity of having multiple versions in a system. In my
opinion, the default values should be set according to probabilities:
is it more likely for a user to use multiple versions or a single
version of R? Of course, all of you are developers and the former
probability might be higher, but I don't think many users will run the
script A with R 2.12.1 and script B with R 2.13.0. The most typical
situation I have seen is, (Windows) people install R and will forget
to update it forever. I often have to urge our IT admin to update R in
our department from a version released long long ago. You may argue my
samples are not representative. Anyway, I can accept the default
version string if nobody agrees with me.

I do use Emacs every day. It's nice, I totally agree.

Regards,
Yihui
--
Yihui Xie 
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA



On Wed, May 4, 2011 at 2:02 AM, Martin Maechler
 wrote:
> Note to Yihui Xie:  I agree 100% with the other R core members
> (Duncan, Simon, Thomas) who already explained why it is *GOOD*
> to install R in version-named directories by default.
>
> BTW: If you use ESS (Emacs Speaks Statistics) on Windows,
> it now automatically(*) finds all versions of R
> (* well, less generally, probably than Gabor's batch files; IIRC,
>  we assume that the R versions were installed in the default place),
> and provides them, both the 32bit and 64bit versions, in the ESS
> menu, or via
>  M-x R- [Tab completion]
> Very nice, very useful in my eyes.
>
> Martin
>

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

Re: [Rd] Reference Classes: Accessing methods via [[...]], bug?

[John Chambers]

On 5/3/11 2:39 PM, Hadley Wickham wrote:

Part of the motivation for the reference classes was to bring a general OOP
view to R.  One can start from some essential concepts of objects and their
properties, inheritance and class definition, as have evolved over a very
long time.

Next, there is a fundamental choice of paradigm between "encapsulated" OOP
as the rest of the world knows it, and "functional" OOP as practiced by S
and R, and a few other languages.  While the two paradigms are quite
different, there is no need to view them as opposed.  They provide different
advantages and tend to suit different goals--very roughly, functional object
creation and reproducible results versus persistent objects whose properties
one would like to have evolve over time using their encapsulated methods.


My biggest worry with the introduction of reference classes is that
many people will just stick to the style of OOP that they're familiar
with, and not bother to learn the strengths of the generic function
approach.


Well, that says that presenting the choices well is important.  Agreed.

But the alternative is (and has been) for people from the "other" OOP 
background to hack something using the functional S4/S3 paradigm and 
then complain when it doesn't behave as expected. Not really preferable.





As these remarks may suggest, I'm trying to write up this perspective in
some detail.  To be continued 


Are you familiar with "Concepts, Techniques, and Models of Computer
Programming" by van Roy and Haridi?  That's what really helped me to
understand the strengths and weaknesses of the various styles of
programming.


Thanks, I wasn't.  Yes, interesting similar distinction between 
functional and "type" decomposition.  An important associated aspect for 
us is the distinction between reference objects and "ordinary" R 
objects, not AFAICS conveyed by their more abstract treatment.


John


Hadley



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

Re: [Rd] Curry: proposed new functional programming, er, function.

[Hadley Wickham]

> Or maybe
>
>    Curry <- function(FUN, ...) {
>      args <- match.call(expand.dots = FALSE)$...
>      args$... <- as.name("...")
>
>      curry_call <- as.call(c(list(as.name("FUN")), args))
>      eval(bquote(function(...) .(curry_call)))
>    }

Or one more approach:

Curry <- function(FUN, ...) {
  args <- match.call(expand.dots = FALSE)$...
  args$... <- as.name("...")

  curry_call <- as.call(c(list(as.name("FUN")), args))
  eval(call("function", as.pairlist(alist(... = )), curry_call))
}

I'm not sure if there's a canonical way of programmatically creating functions.

Hadley


-- 
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

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

Re: [Rd] Reference Classes: Accessing methods via [[...]], bug?

[Hadley Wickham]

>> Are you familiar with "Concepts, Techniques, and Models of Computer
>> Programming" by van Roy and Haridi?  That's what really helped me to
>> understand the strengths and weaknesses of the various styles of
>> programming.
>
> Thanks, I wasn't.  Yes, interesting similar distinction between functional
> and "type" decomposition.  An important associated aspect for us is the
> distinction between reference objects and "ordinary" R objects, not AFAICS
> conveyed by their more abstract treatment.

Another discussion I found useful was in SICP:
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-17.html#%_sec_2.4.3

I really like the metaphor of method dispatch as a table with types in
the columns and operations in the rows - then you can think of generic
functions oo as being row-based, and class based oo as column-based.

Hadley

-- 
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

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

Re: [Rd] General "nil" reference class object

[John Chambers]

Interesting idea.

One approach would be to test against the _environment_ of the prototype 
object in the class definition.  Since the initialize method for a 
reference class must call new.env(), one knows that a real object from 
the class has a different environment.  Using that fact one could have 
functions

  nullObject(Class)
to get the null, and
  isNullObject(x)
to test.

My feeling is that this approach is better for R than having one single 
nil object, because nullObject(Class) would still be a valid object from 
the class.


Something to mull over.
  John


On 5/4/11 6:09 AM, Jon Clayden wrote:

Dear John and others,

I've been wondering about whether there's any way to indicate a "nil"
reference class object, which will represent "no value", and be tested
for, but not fail the internal type checking. NULL is the obvious
choice (or seems so to me), but can only be used if an explicit class
union is created:


Foo<- setRefClass("Foo")
Bar<- setRefClass("Bar", fields=list(foo="Foo"))
Bar$new(foo=NULL)

Error in as(value, "Foo") :
   no method or default for coercing "NULL" to "Foo"

setClassUnion("FooOrNull", c("Foo","NULL"))

[1] "FooOrNull"

Bar<- setRefClass("Bar", fields=list(foo="FooOrNull"))
Bar$new(foo=NULL)

An object of class "Bar"


is.null(Bar$new(foo=NULL)$foo)

[1] TRUE

Other languages allow things like "MyClass object = null", and it
seems to me that it would be helpful to have a value which will always
give TRUE for "is(object,)", but will
specifically indicate a nil reference. One possible ad-hoc solution is
to define the "empty" object of a base class to be "nil" (see below),
but it seems like it would be better to have a value specifically
designed for this purpose.


nilObject<- Foo$new()
is.nilObject<- function (x) identical(x,nilObject)
Bar<- setRefClass("Bar", fields=list(foo="Foo"), methods=list(

+ initialize=function (foo=nilObject) { initFields(foo=foo) }))

is.nilObject(Bar$new()$foo)

[1] TRUE

Is there already something like this that I'm not aware of? If not,
would it be possible and generally desirable to create it?

All the best,
Jon


--
Jonathan D Clayden, PhD
Lecturer in Neuroimaging and Biophysics
Imaging and Biophysics Unit
UCL Institute of Child Health
30 Guilford Street
LONDON  WC1N 1EH
United Kingdom

__
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] Reference Classes: (Was: Accessing methods via [[...]], bug?)

[John Chambers]

On 5/4/11 9:24 AM, Hadley Wickham wrote:

Are you familiar with "Concepts, Techniques, and Models of Computer
Programming" by van Roy and Haridi?  That's what really helped me to
understand the strengths and weaknesses of the various styles of
programming.


Thanks, I wasn't.  Yes, interesting similar distinction between functional
and "type" decomposition.  An important associated aspect for us is the
distinction between reference objects and "ordinary" R objects, not AFAICS
conveyed by their more abstract treatment.


Another discussion I found useful was in SICP:
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-17.html#%_sec_2.4.3

I really like the metaphor of method dispatch as a table with types in
the columns and operations in the rows - then you can think of generic
functions oo as being row-based, and class based oo as column-based.


Except that functional method dispatch with multiple dispatch is 
dispatched on a K-tple of classes if the generic function has K 
arguments in its signature.


This is not a trivial distinction because it means that a method can 
depend on more than one class definition, so it's not just a matter of 
distributing the same information in different ways, but a fundamentally 
more complicated structure for functional OOP (for better and/or for worse).


John



Hadley



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

Re: [Rd] tkrplot not working in R 2.13.0

[Prof Brian Ripley]

What example are you trying? The code in ?trkplot works for me.

However, it looks to me like that piece of advice in the rw-FAQ about 
no spaces in your path has come back to bite you (I of course do not 
have such spaces).  I think this should be


.Tcl(paste("load", shQuote(file), "Rplot"))

or some such.

On Wed, 4 May 2011, Greg Snow wrote:


The tkrplot package is not working in version 2.13.0 for windows.  I contacted 
the maintainer who unfortunately does not have easy access to a windows 
computer and says that it is working on the other platforms.

I traced the problem down to the line in the .First.lib function:

.Tcl(paste("load", file, "Rplot"))

With file being "C:/Program 
Files/R/R-2.13.0/library/tkrplot/libs/i386/tkrplot.dll" on my system.  I did check 
that the file exists and it can even be loaded using dyn.load, but when running the .Tcl 
command by hand it produces the following error:

Error in structure(.External("dotTcl", ..., PACKAGE = "tcltk"), class = 
"tclObj") :
 [tcl] could not find interpreter "Rplot".

It works in previous versions of R, so I am guessing that this is 
due to some change in R, or the tcl with R 2.13.0, or how tkrplot 
was compiled under the new R, or possibly something else.


Does anyone else have any insights?




sessionInfo()

R version 2.13.0 (2011-04-13)
Platform: i386-pc-mingw32/i386 (32-bit)

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

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

other attached packages:
[1] TeachingDemos_2.7 tkrplot_0.0-19

loaded via a namespace (and not attached):
[1] tools_2.13.0

Thanks,

--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111

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



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

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

Re: [Rd] tkrplot not working in R 2.13.0

[Uwe Ligges]

On 04.05.2011 17:46, Greg Snow wrote:

The tkrplot package is not working in version 2.13.0 for windows.  I contacted 
the maintainer who unfortunately does not have easy access to a windows 
computer and says that it is working on the other platforms.


Greg,

if he had access (like I do) he'd said it works for him. At least it 
does for me (under Windows Server 2008 and XP) and it also passes the 
CRAN checks under Windows, see e.g.

http://www.r-project.org/nosvn/R.check/r-release-windows-ix86+x86_64/tkrplot-00check.html

You may want to elaborate why you think it does not work and provide us 
with what you typed in R and what the actual error message is.


Uwe Ligges





I traced the problem down to the line in the .First.lib function:

.Tcl(paste("load", file, "Rplot"))

With file being "C:/Program 
Files/R/R-2.13.0/library/tkrplot/libs/i386/tkrplot.dll" on my system.  I did check 
that the file exists and it can even be loaded using dyn.load, but when running the .Tcl 
command by hand it produces the following error:

Error in structure(.External("dotTcl", ..., PACKAGE = "tcltk"), class = 
"tclObj") :
   [tcl] could not find interpreter "Rplot".

It works in previous versions of R, so I am guessing that this is due to some 
change in R, or the tcl with R 2.13.0, or how tkrplot was compiled under the 
new R, or possibly something else.

Does anyone else have any insights?




sessionInfo()

R version 2.13.0 (2011-04-13)
Platform: i386-pc-mingw32/i386 (32-bit)

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

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

other attached packages:
[1] TeachingDemos_2.7 tkrplot_0.0-19

loaded via a namespace (and not attached):
[1] tools_2.13.0

Thanks,



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

Re: [Rd] Reference Classes: (Was: Accessing methods via [[...]], bug?)

[Hadley Wickham]

On Wed, May 4, 2011 at 11:35 AM, John Chambers  wrote:
> On 5/4/11 9:24 AM, Hadley Wickham wrote:

 Are you familiar with "Concepts, Techniques, and Models of Computer
 Programming" by van Roy and Haridi?  That's what really helped me to
 understand the strengths and weaknesses of the various styles of
 programming.
>>>
>>> Thanks, I wasn't.  Yes, interesting similar distinction between
>>> functional
>>> and "type" decomposition.  An important associated aspect for us is the
>>> distinction between reference objects and "ordinary" R objects, not
>>> AFAICS
>>> conveyed by their more abstract treatment.
>>
>> Another discussion I found useful was in SICP:
>> http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-17.html#%_sec_2.4.3
>>
>> I really like the metaphor of method dispatch as a table with types in
>> the columns and operations in the rows - then you can think of generic
>> functions oo as being row-based, and class based oo as column-based.
>
> Except that functional method dispatch with multiple dispatch is dispatched
> on a K-tple of classes if the generic function has K arguments in its
> signature.
>
> This is not a trivial distinction because it means that a method can depend
> on more than one class definition, so it's not just a matter of distributing
> the same information in different ways, but a fundamentally more complicated
> structure for functional OOP (for better and/or for worse).

Yes, the metaphor breaks down fairly quickly, but it really helped me
to understand the types of problems where generic functions are
useful, and how methods are used in fundamentally different ways in
the different styles.

Hadley

-- 
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

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

Re: [Rd] Curry: proposed new functional programming, er, function.

[Sharpie]

Byron Ellis-2 wrote:
> 
> Hi all (especially R-core) I suppose,
> 
> With the introduction of the new functional programming functions into
> base I thought I'd ask for a Curry() function. I use a simple one that
> looks this:
> 
> Curry = function(FUN,...) { .orig = list(...);function(...)
> do.call(FUN,c(.orig,list(...))) }
> 
> ...
> 
> 

I would like to see this as well---it is one of the functional programming
constructs I really miss in R after playing with languages like Haskell.

Currently, the only Curry implementation I know of is in the roxygen package
which is kind of a weird dependency to install just for this one function.

-Charlie

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
--
View this message in context: 
http://r.789695.n4.nabble.com/Curry-proposed-new-functional-programming-er-function-tp917654p3496226.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] Curry: proposed new functional programming, er, function.

[Gabor Grothendieck]

On Wed, May 4, 2011 at 1:11 PM, Sharpie  wrote:
> Currently, the only Curry implementation I know of is in the roxygen package
> which is kind of a weird dependency to install just for this one function.
>

Not entirely comparable but the proto package supports currying of
proto arguments. For example, p$ls returns an
"instantiatedProtoMethod" which is an S3 subclass of "function" that
is like the original method but with the first argument filled in:

> library(proto)
> p <- proto(x = 1)
> p$ls()
[1] "x"


-- 
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com

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

Re: [Rd] tkrplot not working in R 2.13.0

[Greg Snow]

It looks like the spaces in the path is the problem, when I run the line below 
with shQuote then everything starts working and all is right with the world 
again.

Thanks,

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


> -Original Message-
> From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk]
> Sent: Wednesday, May 04, 2011 10:35 AM
> To: Greg Snow
> Cc: R Devel List
> Subject: Re: [Rd] tkrplot not working in R 2.13.0
> 
> What example are you trying? The code in ?trkplot works for me.
> 
> However, it looks to me like that piece of advice in the rw-FAQ about
> no spaces in your path has come back to bite you (I of course do not
> have such spaces).  I think this should be
> 
> .Tcl(paste("load", shQuote(file), "Rplot"))
> 
> or some such.
> 
> On Wed, 4 May 2011, Greg Snow wrote:
> 
> > The tkrplot package is not working in version 2.13.0 for windows.  I
> contacted the maintainer who unfortunately does not have easy access to
> a windows computer and says that it is working on the other platforms.
> >
> > I traced the problem down to the line in the .First.lib function:
> >
> > .Tcl(paste("load", file, "Rplot"))
> >
> > With file being "C:/Program Files/R/R-
> 2.13.0/library/tkrplot/libs/i386/tkrplot.dll" on my system.  I did
> check that the file exists and it can even be loaded using dyn.load,
> but when running the .Tcl command by hand it produces the following
> error:
> >
> > Error in structure(.External("dotTcl", ..., PACKAGE = "tcltk"), class
> = "tclObj") :
> >  [tcl] could not find interpreter "Rplot".
> >
> > It works in previous versions of R, so I am guessing that this is
> > due to some change in R, or the tcl with R 2.13.0, or how tkrplot
> > was compiled under the new R, or possibly something else.
> >
> > Does anyone else have any insights?
> >
> >
> >
> >> sessionInfo()
> > R version 2.13.0 (2011-04-13)
> > Platform: i386-pc-mingw32/i386 (32-bit)
> >
> > locale:
> > [1] LC_COLLATE=English_United States.1252
> > [2] LC_CTYPE=English_United States.1252
> > [3] LC_MONETARY=English_United States.1252
> > [4] LC_NUMERIC=C
> > [5] LC_TIME=English_United States.1252
> >
> > attached base packages:
> > [1] tcltk stats graphics  grDevices utils datasets
> methods
> > [8] base
> >
> > other attached packages:
> > [1] TeachingDemos_2.7 tkrplot_0.0-19
> >
> > loaded via a namespace (and not attached):
> > [1] tools_2.13.0
> >
> > Thanks,
> >
> > --
> > Gregory (Greg) L. Snow Ph.D.
> > Statistical Data Center
> > Intermountain Healthcare
> > greg.s...@imail.org
> > 801.408.8111
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> 
> --
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel:  +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax:  +44 1865 272595

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

Re: [Rd] tkrplot not working in R 2.13.0

[peter dalgaard]

On May 4, 2011, at 19:26 , Greg Snow wrote:

> It looks like the spaces in the path is the problem, when I run the line 
> below with shQuote then everything starts working and all is right with the 
> world again.

Just for fun, see if it also works with

tcl("load", file, "Rplot")

(.Tcl(paste()) is just *so* turn of the millennium, and particularly 
vulnerable to "quoting hell" effects.)


> 
> Thanks,
> 
> -- 
> Gregory (Greg) L. Snow Ph.D.
> Statistical Data Center
> Intermountain Healthcare
> greg.s...@imail.org
> 801.408.8111
> 
> 
>> -Original Message-
>> From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk]
>> Sent: Wednesday, May 04, 2011 10:35 AM
>> To: Greg Snow
>> Cc: R Devel List
>> Subject: Re: [Rd] tkrplot not working in R 2.13.0
>> 
>> What example are you trying? The code in ?trkplot works for me.
>> 
>> However, it looks to me like that piece of advice in the rw-FAQ about
>> no spaces in your path has come back to bite you (I of course do not
>> have such spaces).  I think this should be
>> 
>> .Tcl(paste("load", shQuote(file), "Rplot"))
>> 
>> or some such.
>> 
>> On Wed, 4 May 2011, Greg Snow wrote:
>> 
>>> The tkrplot package is not working in version 2.13.0 for windows.  I
>> contacted the maintainer who unfortunately does not have easy access to
>> a windows computer and says that it is working on the other platforms.
>>> 
>>> I traced the problem down to the line in the .First.lib function:
>>> 
>>> .Tcl(paste("load", file, "Rplot"))
>>> 
>>> With file being "C:/Program Files/R/R-
>> 2.13.0/library/tkrplot/libs/i386/tkrplot.dll" on my system.  I did
>> check that the file exists and it can even be loaded using dyn.load,
>> but when running the .Tcl command by hand it produces the following
>> error:
>>> 
>>> Error in structure(.External("dotTcl", ..., PACKAGE = "tcltk"), class
>> = "tclObj") :
>>> [tcl] could not find interpreter "Rplot".
>>> 
>>> It works in previous versions of R, so I am guessing that this is
>>> due to some change in R, or the tcl with R 2.13.0, or how tkrplot
>>> was compiled under the new R, or possibly something else.
>>> 
>>> Does anyone else have any insights?
>>> 
>>> 
>>> 
 sessionInfo()
>>> R version 2.13.0 (2011-04-13)
>>> Platform: i386-pc-mingw32/i386 (32-bit)
>>> 
>>> locale:
>>> [1] LC_COLLATE=English_United States.1252
>>> [2] LC_CTYPE=English_United States.1252
>>> [3] LC_MONETARY=English_United States.1252
>>> [4] LC_NUMERIC=C
>>> [5] LC_TIME=English_United States.1252
>>> 
>>> attached base packages:
>>> [1] tcltk stats graphics  grDevices utils datasets
>> methods
>>> [8] base
>>> 
>>> other attached packages:
>>> [1] TeachingDemos_2.7 tkrplot_0.0-19
>>> 
>>> loaded via a namespace (and not attached):
>>> [1] tools_2.13.0
>>> 
>>> Thanks,
>>> 
>>> --
>>> Gregory (Greg) L. Snow Ph.D.
>>> Statistical Data Center
>>> Intermountain Healthcare
>>> greg.s...@imail.org
>>> 801.408.8111
>>> 
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>> 
>> 
>> --
>> Brian D. Ripley,  rip...@stats.ox.ac.uk
>> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
>> University of Oxford, Tel:  +44 1865 272861 (self)
>> 1 South Parks Road, +44 1865 272866 (PA)
>> Oxford OX1 3TG, UKFax:  +44 1865 272595
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Peter Dalgaard
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows

[Simon Urbanek]

On May 4, 2011, at 12:00 PM, Yihui Xie wrote:

> My suggestion was to mimic *nix systems: put the executable binaries in the 
> same place *by default* (e.g. /usr/bin/ or /usr/local/bin).

Except that there is not such thing on Windows! The closest to that is the 
"system" folder which is off limits for applications.


> Why isn't the default bin path for R under *nix something like 
> /usr/bin/R-2.13.0/?

It is on some unices (and most system-wide installations in practice) - but 
that's beside the point. Unix has a well-defined FHS so regardless where you 
install R you can always put a symlink into /usr/bin or /usr/local/bin. Windows 
has no such conventions so Gabor's solution is pretty much what you claim to 
want (and note that in unix you're exactly running a batch script with its 
rhome embedded to start R!). Even on unix you don't mess with PATH to select 
the R version to use.


> If the users want to install multiple versions,
> they still have the choice to install them elsewhere. I'm not denying
> the possible necessity of having multiple versions in a system. In my
> opinion, the default values should be set according to probabilities:
> is it more likely for a user to use multiple versions or a single
> version of R? Of course, all of you are developers and the former
> probability might be higher, but I don't think many users will run the
> script A with R 2.12.1 and script B with R 2.13.0. The most typical
> situation I have seen is, (Windows) people install R and will forget
> to update it forever. I often have to urge our IT admin to update R in
> our department from a version released long long ago. You may argue my
> samples are not representative. Anyway, I can accept the default
> version string if nobody agrees with me.
> 

Cheers,
S


> I do use Emacs every day. It's nice, I totally agree.
> 
> Regards,
> Yihui
> --
> Yihui Xie 
> Phone: 515-294-2465 Web: http://yihui.name
> Department of Statistics, Iowa State University
> 2215 Snedecor Hall, Ames, IA
> 
> 
> 
> On Wed, May 4, 2011 at 2:02 AM, Martin Maechler
>  wrote:
>> Note to Yihui Xie:  I agree 100% with the other R core members
>> (Duncan, Simon, Thomas) who already explained why it is *GOOD*
>> to install R in version-named directories by default.
>> 
>> BTW: If you use ESS (Emacs Speaks Statistics) on Windows,
>> it now automatically(*) finds all versions of R
>> (* well, less generally, probably than Gabor's batch files; IIRC,
>>  we assume that the R versions were installed in the default place),
>> and provides them, both the 32bit and 64bit versions, in the ESS
>> menu, or via
>>  M-x R- [Tab completion]
>> Very nice, very useful in my eyes.
>> 
>> Martin
>> 
> 
> __
> 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] tkrplot not working in R 2.13.0

[Greg Snow]

That works as well, I will suggest it to Luke for the package to use.

Thanks,

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


> -Original Message-
> From: peter dalgaard [mailto:pda...@gmail.com]
> Sent: Wednesday, May 04, 2011 11:43 AM
> To: Greg Snow
> Cc: Prof Brian Ripley; R Devel List
> Subject: Re: [Rd] tkrplot not working in R 2.13.0
> 
> 
> On May 4, 2011, at 19:26 , Greg Snow wrote:
> 
> > It looks like the spaces in the path is the problem, when I run the
> line below with shQuote then everything starts working and all is right
> with the world again.
> 
> Just for fun, see if it also works with
> 
> tcl("load", file, "Rplot")
> 
> (.Tcl(paste()) is just *so* turn of the millennium, and
> particularly vulnerable to "quoting hell" effects.)
> 
> 
> >
> > Thanks,
> >
> > --
> > Gregory (Greg) L. Snow Ph.D.
> > Statistical Data Center
> > Intermountain Healthcare
> > greg.s...@imail.org
> > 801.408.8111
> >
> >
> >> -Original Message-
> >> From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk]
> >> Sent: Wednesday, May 04, 2011 10:35 AM
> >> To: Greg Snow
> >> Cc: R Devel List
> >> Subject: Re: [Rd] tkrplot not working in R 2.13.0
> >>
> >> What example are you trying? The code in ?trkplot works for me.
> >>
> >> However, it looks to me like that piece of advice in the rw-FAQ
> about
> >> no spaces in your path has come back to bite you (I of course do not
> >> have such spaces).  I think this should be
> >>
> >> .Tcl(paste("load", shQuote(file), "Rplot"))
> >>
> >> or some such.
> >>
> >> On Wed, 4 May 2011, Greg Snow wrote:
> >>
> >>> The tkrplot package is not working in version 2.13.0 for windows.
> I
> >> contacted the maintainer who unfortunately does not have easy access
> to
> >> a windows computer and says that it is working on the other
> platforms.
> >>>
> >>> I traced the problem down to the line in the .First.lib function:
> >>>
> >>> .Tcl(paste("load", file, "Rplot"))
> >>>
> >>> With file being "C:/Program Files/R/R-
> >> 2.13.0/library/tkrplot/libs/i386/tkrplot.dll" on my system.  I did
> >> check that the file exists and it can even be loaded using dyn.load,
> >> but when running the .Tcl command by hand it produces the following
> >> error:
> >>>
> >>> Error in structure(.External("dotTcl", ..., PACKAGE = "tcltk"),
> class
> >> = "tclObj") :
> >>> [tcl] could not find interpreter "Rplot".
> >>>
> >>> It works in previous versions of R, so I am guessing that this is
> >>> due to some change in R, or the tcl with R 2.13.0, or how tkrplot
> >>> was compiled under the new R, or possibly something else.
> >>>
> >>> Does anyone else have any insights?
> >>>
> >>>
> >>>
>  sessionInfo()
> >>> R version 2.13.0 (2011-04-13)
> >>> Platform: i386-pc-mingw32/i386 (32-bit)
> >>>
> >>> locale:
> >>> [1] LC_COLLATE=English_United States.1252
> >>> [2] LC_CTYPE=English_United States.1252
> >>> [3] LC_MONETARY=English_United States.1252
> >>> [4] LC_NUMERIC=C
> >>> [5] LC_TIME=English_United States.1252
> >>>
> >>> attached base packages:
> >>> [1] tcltk stats graphics  grDevices utils datasets
> >> methods
> >>> [8] base
> >>>
> >>> other attached packages:
> >>> [1] TeachingDemos_2.7 tkrplot_0.0-19
> >>>
> >>> loaded via a namespace (and not attached):
> >>> [1] tools_2.13.0
> >>>
> >>> Thanks,
> >>>
> >>> --
> >>> Gregory (Greg) L. Snow Ph.D.
> >>> Statistical Data Center
> >>> Intermountain Healthcare
> >>> greg.s...@imail.org
> >>> 801.408.8111
> >>>
> >>> __
> >>> R-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>>
> >>
> >> --
> >> Brian D. Ripley,  rip...@stats.ox.ac.uk
> >> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> >> University of Oxford, Tel:  +44 1865 272861 (self)
> >> 1 South Parks Road, +44 1865 272866 (PA)
> >> Oxford OX1 3TG, UKFax:  +44 1865 272595
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> --
> Peter Dalgaard
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows

[Kevin R. Coombes]

There are plenty of good reasons for non-developers to run different 
versions of R.  For instance, I care a lot about reproducibility. With 
every new release of R, lots of things change.  With every new release 
of the packages I use, lots of things change.  All of my analyses are 
performed using Sweave, and every report includes a call to sessionInfo 
so that the versions are recorded in the final report.  If I have to go 
back and tweak something in a report (say, to regenerate a figure in a 
format more suitable for publication), I do not want the rest of the 
analysis to change.  So I have to run the correct (possibly older) 
version of R.  All of the stat analysts that we train follow the same 
practice.


As a result, I am strongly opposed to an installation that automatically 
mucks with the path to R.


Kevin

On 5/4/2011 11:00 AM, Yihui Xie wrote:

My suggestion was to mimic *nix systems: put the executable binaries
in the same place *by default* (e.g. /usr/bin/ or /usr/local/bin). Why
isn't the default bin path for R under *nix something like
/usr/bin/R-2.13.0/? If the users want to install multiple versions,
they still have the choice to install them elsewhere. I'm not denying
the possible necessity of having multiple versions in a system. In my
opinion, the default values should be set according to probabilities:
is it more likely for a user to use multiple versions or a single
version of R? Of course, all of you are developers and the former
probability might be higher, but I don't think many users will run the
script A with R 2.12.1 and script B with R 2.13.0. The most typical
situation I have seen is, (Windows) people install R and will forget
to update it forever. I often have to urge our IT admin to update R in
our department from a version released long long ago. You may argue my
samples are not representative. Anyway, I can accept the default
version string if nobody agrees with me.

I do use Emacs every day. It's nice, I totally agree.

Regards,
Yihui
--
Yihui Xie
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


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

Re: [Rd] Error in .Fortran Call

[vioravis]

Thanks a lot. I will try the recommended changes.

Ravi

--
View this message in context: 
http://r.789695.n4.nabble.com/Error-in-Fortran-Call-tp3495319p3495777.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] R CMD check and Suggests Packages

[Hervé Pagès]

On 11-05-03 12:43 AM, Martin Maechler wrote:

Hervé Pagès
 on Mon, 02 May 2011 11:55:08 -0700 writes:


 >  Hi, On 11-04-28 07:00 PM, Dario Strbenac wrote:
 >>  Hello,
 >>
 >>  In my description file, I have an example data package in
 >>  Suggests: that I've deleted from my library to test what
 >>  the user who doesn't have it will experience.
 >>
 >>  However, R CMD check won't even pass my package :
 >>
 >>  * checking package dependencies ... ERROR
 >>  Package required but not available: RepitoolsExamples
 >    confusing!

 >  Wouldn't a message like

 > Package required for full checking but not available:
 >  RepitoolsExamples

 >  be more appropriate and avoid a confusion that we've seen
 >  for a very long time now?

Sure.  But such messages are already produced in current
versions of R,


Not for me. For example, picking up a CRAN package with a
Suggests field:

  http://cran.fhcrc.org/web/packages/AICcmodavg/index.html

Then, after downloading the source tarball:

  hpages@latitude:~/Downloads$ R-2.13 CMD check AICcmodavg_1.15.tar.gz
  * using log directory ‘/home/hpages/Downloads/AICcmodavg.Rcheck’
  * using R version 2.13.0 (2011-04-13)
  * using platform: x86_64-unknown-linux-gnu (64-bit)
  * using session charset: UTF-8
  * checking for file ‘AICcmodavg/DESCRIPTION’ ... OK
  * checking extension type ... Package
  * this is package ‘AICcmodavg’ version ‘1.15’
  * checking package dependencies ... ERROR
  Package required but not available: lme4

  See the information on DESCRIPTION files in the chapter 'Creating R
  packages' of the 'Writing R Extensions' manual.

Cheers,
H.



.. at least they are there in the package checking
source, see
format.check_package_depends()  in
src/library/tools/R/QC.R
which has e.g.,

   if(length(bad<- x$suggests_but_not_installed)>  1L) {
   c(gettext("Packages suggested but not available for checking:"),
 

and similar for 'Enhances' in lieu of 'Suggests'.

If Dario really uses R 2.13.0 (or newer),
and he gets the above error message for a package that is not
required but only suggested,
I think we'd need a clear, ideally simple,
reproducible example, here.

Martin




--
Hervé Pagès

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

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

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

Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows

[Sharpie]

Yihui Xie-2 wrote:
> 
> Hi,
> 
> I guess this issue must have been brought forward long time ago, but I
> still hope you can consider under Windows (during installation):
> 
> 1. put R's bin path in the PATH variable of the system so that we can
> use the commands "R" and "Rscript" more easily;
> 

On one hand it certainly would be nice to have this as an option similar to
what the RTools installer does. For the 32/64 bit decision, perhaps
RHOME/bin could be placed on the PATH and bin/R.exe turned into a bin/R.bat
that calls bin/i386/R.exe, bin/x64/R.exe depending on the Windows
architecture.

On the other hand, the grizzled developer in me is saying "this is a
teaching moment. If someone is using a programming language they should know
what an environment variable is and how to set it".  Admittingly, setting
environment variables is a PITA on Windows compared to UNIX. Here's a great
freeware tool I have found that makes it so much easier:

  http://www.rapidee.com

Another issue is that many Windows machines are locked down in such a way
that environment variables cannot be set permanently. To deal with this, I
carry a USB stick that has R installed on it and a batch script that
`setx`es environment variables for me. Combined with an `autorun.inf`
script, this basically lets me plug my USB stick into a Windows machine and
get to work without worrying about how careful the sysadmin was when they
set up the tools I like to use (or if they even bothered to include the
tools I like to use).

A good video tutorial for setting up autorun.inf from Tinkernut.com:

  http://www.youtube.com/watch?v=lFlgddjOPpw

Some of the things in that video are outdated and the overall goal is to
show how they could be used for nefarious purposes, but the part about
converting a `.bat` script to a `.exe` binary and setting up an autorun.inf
to execute the result is solid. Combine with MikTeX Portable and you should
be able to Sweave from anywhere.



Yihui Xie-2 wrote:
> 
> 2. remove the version string like R-2.13.0 in the default installation
> directory, e.g. only use a directory like C:/Program Files/R/ instead
> of C:/Program Files/R/R-2.13.0/; I know many people just follow the
> default setting when installing R, and this version string will often
> lead to many (unnecessary) copies of R in the system and brings
> difficulty to the first issue (several possible bin directories);
> 
> I'm aware of some existing efforts in overcoming the difficulty of
> calling R under Windows like the R batch files project
> (http://code.google.com/p/batchfiles/), but I believe this is better
> to be solved in R directly.
> 

As a package developer I rather like this---I can have multiple versions of
R installed and easily set up my testsuite such that it loops through each
one and executes the tests.

-Charlie


-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
--
View this message in context: 
http://r.789695.n4.nabble.com/Wishlist-write-R-s-bin-path-to-the-PATH-variable-and-remove-the-version-string-in-the-installation-ds-tp3493922p3496533.html
Sent from the R devel mailing list archive at Nabble.com.

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

[Rd] Reference Classes: replacing '.self' with an .Rda image of '.self' from within a method? (was replacing '.self' with an .Rda image of '.self' from within a method?)

[Janko Thyson]

Sorry guys,

but I chose a really stupid name before (no "reference classes").

Hope it's okay to re-post.

Cheers,
Janko

>>> ORIGINAL MESSAGE <<<

Dear list,

Is it possible to update or reassign '.self' with an image of '.self' 
(e.g. a locally stored .Rda file) from within a method?


I know that this might sound akward, but here's the use case:
1) Ref Class Definition
setRefClass(Class="Test",
fields=list(A="character", B="character"),
methods=list(importImage=function(path){
variable <- load(path)
expr <- paste("assign('", variable, "',", variable, ", 
envir=.self)", sep="")

eval(parse(text=expr))
}
)
2) Initialize Method Definition
setMethod(
f="initialize",
signature=signature(.Object="Test"),
definition=function(
.Object,
path=NULL
){
obj <- callNextMethod(.Object)
if(!is.null(path){
obj$importImage(path=path)
}
return(obj)
}
3) Intended and "Extended" Use
Method 'importImage' was originally intended to read either an 
object of name 'A' or 'B' from a respective path and overwrite the 
respective fields in an obj of class 'Test'.
Now I wondered how I could "reassign"/update the object of class 
'Test' itself by reading a respective .Rda image of an object of class 
'Test' from within 'obj$importImage()'.
The way I've written 'importImage()', it did not work. Yet I wonder 
if it's possible.

4) My Workaround (but I'm looking for something more elegantly)
In the class definition:
[...]
methods=list(importImage=function(path){
variable <- load(path)
if(variable != ".self"){
expr <- paste("assign('", variable, "',", variable, ", 
envir=.self)", sep="")

eval(parse(text=expr))
return(TRUE)
} else {
return(.self)
}
})
[...]

In the initialize method:
setMethod(
f="initialize",
signature=signature(.Object="Test"),
definition=function(
.Object,
path=NULL
){
obj <- callNextMethod(.Object)
if(!is.null(path){
rslt <- obj$importImage(path=path)
if(!is.logical(rslt)){
obj <- rslt
}
}
return(obj)
}

Thanks for any comments,
Janko

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

Re: [Rd] How to create vignette.pdf for R-2.13.0?

[cstrato]

Dear Simon,

I did not complain about the R doing something wrong. I only wanted to 
know why, after all these years, R CMD check does suddenly no longer 
build the pdf-files of the vignettes. I also think that this is a legal 
question.


Let me compare the times spent:

1, the "official" development cycle:
- R CMD build:   5 minutes
- R CMD INSTALL: 3 minutes
- R CMD check:   6 minutes

2, my own development cycle:
- manual tarring: 2 seconds
- R CMD check:6 minutes

This means spending 14 minutes vs 6 minutes. If I assume that in one 
evening I have to make 10 corrections this would mean 140 minutes vs 60 
minutes, i.e. the official development cycle would take 1 hr and 20 min 
longer than my own development cycle. This is time I do not have.


Best regards
Christian


On 5/4/11 12:13 AM, Simon Urbanek wrote:

On May 3, 2011, at 5:15 PM, cstrato wrote:


No, I simply do "tar czf xps_1.13.1.tar.gz xps".



Well, that's your problem then, not R's. Source packages are created using R 
CMD build, not by manual tarring (you can do the latter if you know what you're 
doing, but then you can't complain about the R doing something wrong).

Cheers,
S




On 5/3/11 11:11 PM, Simon Urbanek wrote:

On May 3, 2011, at 4:48 PM, cstrato   wrote:


Dear Uwe,

Thank you, however since I use "R CMD INSTALL xps.tar.gz" my source code is not 
polluted.



But then you already used build to create the tar ball so the vignette has been 
built. So what is your point?

Cheers,
S



Furthermore, I forgot to mention that finally I upload the source code only to 
the BioC svn repository. The rest is done by the BioC servers, including 
building the pdf-files for the vignettes.

Best regards
Christian


On 5/3/11 10:13 PM, Uwe Ligges wrote:



On 03.05.2011 21:14, cstrato wrote:

Dear Uwe,

This is my development cycle:

First, I run R CMD check until there are no more warnings/errors. Since
years it was very convenient that R CMD check builds the pdf-files of
the vignettes, too, since this allowed me to correct errors in the
manual files and the vignette files at the same time!

Afterwards I run R CMD INSTALL to install my package and do more tests
until everything works.

As you see I do not use R CMD build, since every run takes about 5
minutes, it overwrites my zipped source code, and I would need to unzip
it to get access to the vignette pdf-files.



Then this is the main problem here. The *recommended* development cycle
from the manuals is to run

1. R CMD build in order to get a valid source tarball and clean the sources
2. R CMD INSTALL to check if your package can be installed
3. R CMD check in order to finally check your package

Running R CMD INSTALL on your source directory may pollute it, hence
this is not recommended at all.


Best,
UWe







Best regards
Christian


On 5/3/11 1:07 PM, Uwe Ligges wrote:



On 02.05.2011 21:24, cstrato wrote:

Dear Prof. Ripley,

Thank you for your confirmation and explanation, I understand the
reason
for cleaning things up to save memory. However, it was very convenient
to have this feature in earlier versions of R. It would be really
helpful to have an additional option to R CMD check, e.g.
"--no-clean-vignettes".

FYI, I did not claim "..create the vignettes *ininst/doc*",
instead my words were:
One interesting observation is that xps.Rcheck from R-2.12.2 contains
the subdirectory "inst/doc" with the vignettes while xps.Rcheck from
R-2.13.0 does not contain "inst".



But you do not need it. I do not know how often I have to mention that
vignettes are produced by R CMD build! They are already build when
running R CMD check. And please do not tell us about tzhe PDF version
oif manuals which are *unrelated* to vignettes, because they are not
built in advance and need to be checked, since they should be produced
at user level while vignettes are built at developer level already.

Uwe Ligges



Best regards
Christian
_._._._._._._._._._._._._._._._._._
C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a
V.i.e.n.n.a A.u.s.t.r.i.a
e.m.a.i.l: cstrato at aon.at
_._._._._._._._._._._._._._._._._._


On 5/2/11 7:08 AM, Prof Brian Ripley wrote:

On Sun, 1 May 2011, Duncan Murdoch wrote:


On 11-05-01 4:10 PM, cstrato wrote:

Dear Duncan, dear Uwe,

Since I have installed both WinXP and OpenSUSE 11.3 on my Mac in a
virtual machine, I have now done the following tests on all three
architectures:

1, R CMD build xps:
This creates "xps_1.13.1.tar.gz" which DOES contain all vignettes as
pdf-file. Thus R CMD build is ok.

2, R CMD check xps:
This does NOT build the vignettes as pdf-files on all three
architectures. Or to be more precise, R-2.13.0 does no longer build
the
vignettes since with R-2.12.2 and earlier versions R did create the
vignettes as pdf-files.

Thus the question is:
Why does R CMD check no longer create the vignettes?


Probably the answer is simply "because it doesn't". For a truly
reliable check, you should build the package, then check the tar.gz
file. Anything else is, and always has bee

Re: [Rd] tkrplot not working in R 2.13.0

[luke-tierney]

Thanks -- new version on its way to CRAN.

luke

On Wed, 4 May 2011, Greg Snow wrote:


That works as well, I will suggest it to Luke for the package to use.

Thanks,




--
Luke Tierney
Statistics and Actuarial Science
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:  l...@stat.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] Curry: proposed new functional programming, er, function.

[Ravi Varadhan]

Thanks, Hadley.  This (i.e., different ways to prepare curry) is quite 
instructive to me.

Best,
Ravi.

---
Ravi Varadhan, Ph.D.
Assistant Professor,
Division of Geriatric Medicine and Gerontology School of Medicine Johns Hopkins 
University

Ph. (410) 502-2619
email: rvarad...@jhmi.edu


-Original Message-
From: h.wick...@gmail.com [mailto:h.wick...@gmail.com] On Behalf Of Hadley 
Wickham
Sent: Wednesday, May 04, 2011 12:01 PM
To: Duncan Murdoch
Cc: Ravi Varadhan; Byron Ellis; R Development Mailing List
Subject: Re: [Rd] Curry: proposed new functional programming, er, function.

>> # Use of Curry
>> adaptIntegrate(Curry(f, a=0.2), lower=0, upper=2)
>
> Two objections:
>
> 1.  I don't see how that is preferable to
>
> adaptIntegrate(function(x) f(x, a=0.2), lower=0, upper=2)

It's less typing?

A more helpful use is when you have a list of functions:

funs <- list(
  sum = sum,
  mean = mean,
  median = median
)

with Curry function you can do :

funs2 <- lapply(funs, Curry, na.rm = TRUE)

as opposed to

funs2 <- list(
  sum = function(x, ...) sum(x, ..., na.rm = TRUE),
  mean = function(x, ...) mean(x, ..., na.rm = TRUE),
  median = function(x, ...) median(x, ..., na.rm = TRUE)
)

> 2.  There seems to be confusion about what currying means.  The Wikipedia
> page  indicates that the function
> Curry() defined above is really doing "partial function application", not
> currying.  I'm in no position to judge whether Byron got it right or
> Wikipedia did, but this suggests to me that the name "Curry" is
> inappropriate, since at least some people who know what currying is would
> not guess that it does what it does.

I'm not completely sure that discussion is canonical: wikipedia citing
a blog post does not a precedent make.  I agree the distinction is
sensible, but I think the partial function application sense of
currying is standard enough that it would cause much confusion. We are
not claiming that R has low-level currying, we're creating a function
to simulate a useful property of currying.

Hadley

-- 
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

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

Re: [Rd] Reference Classes: replacing '.self' with an .Rda image of '.self' from within a method? (was replacing '.self' with an .Rda image of '.self' from within a method?)

[John Chambers]

It makes no sense to replace the .self field:  that field is initialized 
to be a reference to the object.  If you change it, it's no longer that 
reference.


There are many things wrong with your example, so it's better to take a 
very simple version:


> mkTest <- setRefClass("test",fields = list(a = "numeric"))
> x <- mkTest$new(a=1:10)

Now suppose we replace the .self field with another one:
> y <- mkTest$new(a = 11:20)
> x$.self <- y$.self

At this point x is messed up and does not correspond to the .self field:

> x$a
 [1]  1  2  3  4  5  6  7  8  9 10
> x$.self$a
 [1] 11 12 13 14 15 16 17 18 19 20

The same problem results no matter how you change the field.  The only 
difference with a method is that you do get a warning message.


> pseudoSelf <- as.environment(list(a = 5))
> x$.self <- pseudoSelf
> x$a
 [1]  1  2  3  4  5  6  7  8  9 10
> x$.self$a
[1] 5
> mkTest$methods(screwup = function(newSelf) .self <<- newSelf)
Warning message:
In .checkFieldsInMethod(def, fieldNames, allMethods) :
  Non-local assignment to non-field names (possibly misspelled?)
.self <<- newSelf
( in method "screwup" for class "test")
> x <- mkTest$new(a=1:10)
> x$screwup(pseudoSelf)
> x$a
 [1]  1  2  3  4  5  6  7  8  9 10
> x$.self$a
[1] 5

We need to make the .self field read-only.


On 5/4/11 12:39 PM, Janko Thyson wrote:

Sorry guys,

but I chose a really stupid name before (no "reference classes").

Hope it's okay to re-post.

Cheers,
Janko

 >>> ORIGINAL MESSAGE <<<

Dear list,

Is it possible to update or reassign '.self' with an image of '.self'
(e.g. a locally stored .Rda file) from within a method?

I know that this might sound akward, but here's the use case:
1) Ref Class Definition
setRefClass(Class="Test",
fields=list(A="character", B="character"),
methods=list(importImage=function(path){
variable <- load(path)
expr <- paste("assign('", variable, "',", variable, ", envir=.self)",
sep="")
eval(parse(text=expr))
}
)
2) Initialize Method Definition
setMethod(
f="initialize",
signature=signature(.Object="Test"),
definition=function(
.Object,
path=NULL
){
obj <- callNextMethod(.Object)
if(!is.null(path){
obj$importImage(path=path)
}
return(obj)
}
3) Intended and "Extended" Use
Method 'importImage' was originally intended to read either an object of
name 'A' or 'B' from a respective path and overwrite the respective
fields in an obj of class 'Test'.
Now I wondered how I could "reassign"/update the object of class 'Test'
itself by reading a respective .Rda image of an object of class 'Test'
from within 'obj$importImage()'.
The way I've written 'importImage()', it did not work. Yet I wonder if
it's possible.
4) My Workaround (but I'm looking for something more elegantly)
In the class definition:
[...]
methods=list(importImage=function(path){
variable <- load(path)
if(variable != ".self"){
expr <- paste("assign('", variable, "',", variable, ", envir=.self)",
sep="")
eval(parse(text=expr))
return(TRUE)
} else {
return(.self)
}
})
[...]

In the initialize method:
setMethod(
f="initialize",
signature=signature(.Object="Test"),
definition=function(
.Object,
path=NULL
){
obj <- callNextMethod(.Object)
if(!is.null(path){
rslt <- obj$importImage(path=path)
if(!is.logical(rslt)){
obj <- rslt
}
}
return(obj)
}

Thanks for any comments,
Janko

__
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] Curry: proposed new functional programming, er, function.

[baptiste auguie]

Hi,

On 5 May 2011 02:56, Duncan Murdoch  wrote:
> On 04/05/2011 10:40 AM, Ravi Varadhan wrote:
>>
>> I too would like this (being an Indian!).
>>
>> Here is an example that came up just yesterday with regards to solving a
>> quadrature problem using the "cubature" package.  The adaptIntegrate
>> function does not allow additional arguments via ...
>>
>> Uwe suggested a work around, but `Curry' would solve it nicely (and it
>> also tastes better!):
>>
>> Curry = function(FUN,...) {
>> .orig = list(...)
>> function(...) do.call(FUN,c(.orig, list(...)))
>> }
>>
>> require(cubature)
>>
>> f<- function(x, a) cos(2*pi*x*a)  # a simple test function
>>
>> # this works
>> a<- 0.2
>> adaptIntegrate(function(x, argA=a) f(x, a=argA), lower=0, upper=2)
>>
>> # but this doesn't work
>> rm(a)
>> adaptIntegrate(function(x, argA=a) f(x, a=argA), lower=0, upper=2, a=0.2)
>>
>>
>> # Use of Curry
>> adaptIntegrate(Curry(f, a=0.2), lower=0, upper=2)
>
> Two objections:
>
> 1.  I don't see how that is preferable to
>
> adaptIntegrate(function(x) f(x, a=0.2), lower=0, upper=2)

In this particular case I don't think it is. The reason I proposed it
yesterday for the cubature example was that in some cases it can make
the code more concise and clearer in my opinion. This is the case when
you override a considerable number of arguments in a function.

Consider this,

read.table2 = Curry(read.table, header = TRUE, na.strings = "",
colClasses = "numeric", nrows = 23)

vs

read.table2 = function(..., header = TRUE, na.strings = "",
colClasses = "numeric", nrows = 23)
{
 read.table(header = header, na.strings = na.strings,
   colClasses = colClasses, nrows = nrows, ...)
}

Whether or not this should be called curry, I have no idea. In any
case it seems like a useful function to have in a base package,
regardless of its implementation details.

baptiste


>
> 2.  There seems to be confusion about what currying means.  The Wikipedia
> page  indicates that the function
> Curry() defined above is really doing "partial function application", not
> currying.  I'm in no position to judge whether Byron got it right or
> Wikipedia did, but this suggests to me that the name "Curry" is
> inappropriate, since at least some people who know what currying is would
> not guess that it does what it does.
>
> Duncan Murdoch
>
>> Best,
>> Ravi.
>>
>> ---
>> Ravi Varadhan, Ph.D.
>> Assistant Professor,
>> Division of Geriatric Medicine and Gerontology School of Medicine Johns
>> Hopkins University
>>
>> Ph. (410) 502-2619
>> email: rvarad...@jhmi.edu
>>
>>
>> -Original Message-
>> From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org]
>> On Behalf Of Hadley Wickham
>> Sent: Wednesday, May 04, 2011 10:29 AM
>> To: Byron Ellis
>> Cc: R Development Mailing List
>> Subject: Re: [Rd] Curry: proposed new functional programming, er,
>> function.
>>
>> I thought I might bring this up again - it now seems like Curry would
>> be a natural fit with Reduce, Filter, Find, Map, Negate and Position.
>> Any chance we might see this in a future version of R?
>>
>> Hadley
>>
>> On Thu, Nov 1, 2007 at 2:00 PM, Byron Ellis  wrote:
>> >  Hi all (especially R-core) I suppose,
>> >
>> >  With the introduction of the new functional programming functions into
>> >  base I thought I'd ask for a Curry() function. I use a simple one that
>> >  looks this:
>> >
>> >  Curry = function(FUN,...) { .orig = list(...);function(...)
>> >  do.call(FUN,c(.orig,list(...))) }
>> >
>> >  This comes in really handy when using say, heatmap():
>> >
>> >  heatmap(mydata,hclustfun=Curry(hclust,method="average"))
>> >
>> >  or other functions where there are ... arguments, but it's not clear
>> >  where they should end up.
>> >
>> >  --
>> >  Byron Ellis (byron.el...@gmail.com)
>> >  "Oook" -- The Librarian
>> >
>> >  __
>> >  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
>

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

Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows

[Yihui Xie]

First, you are still able to install multiple versions of R to any
places that you want -- I was suggesting a default place to install R
under Windows. If you remember the process of installing R under
Windows, there is a step in which you can choose where to install R.

Second, to modify the PATH variable won't affect reproducibility. It
seems people have got a wrong impression that after the PATH variable
is modified, we are forced to use the single version of R under the
PATH. You are still free to use any versions of R. The only effect is
that if you run R as a command, it will be the version which is under
the PATH. Do you run your Sweave documents via "R CMD Sweave"? If not,
this will not affect you.

If people are really uncomfortable with the PATH variable being
modified, we can make this *optional* just like what Rtools does. If
we are so worried about all these kinds of problems, do we need to
worry about Rtools as well?

Regards,
Yihui
--
Yihui Xie 
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA



On Wed, May 4, 2011 at 1:33 PM, Kevin R. Coombes
 wrote:
> There are plenty of good reasons for non-developers to run different
> versions of R.  For instance, I care a lot about reproducibility. With every
> new release of R, lots of things change.  With every new release of the
> packages I use, lots of things change.  All of my analyses are performed
> using Sweave, and every report includes a call to sessionInfo so that the
> versions are recorded in the final report.  If I have to go back and tweak
> something in a report (say, to regenerate a figure in a format more suitable
> for publication), I do not want the rest of the analysis to change.  So I
> have to run the correct (possibly older) version of R.  All of the stat
> analysts that we train follow the same practice.
>
> As a result, I am strongly opposed to an installation that automatically
> mucks with the path to R.
>
>    Kevin
>
> On 5/4/2011 11:00 AM, Yihui Xie wrote:
>>
>> My suggestion was to mimic *nix systems: put the executable binaries
>> in the same place *by default* (e.g. /usr/bin/ or /usr/local/bin). Why
>> isn't the default bin path for R under *nix something like
>> /usr/bin/R-2.13.0/? If the users want to install multiple versions,
>> they still have the choice to install them elsewhere. I'm not denying
>> the possible necessity of having multiple versions in a system. In my
>> opinion, the default values should be set according to probabilities:
>> is it more likely for a user to use multiple versions or a single
>> version of R? Of course, all of you are developers and the former
>> probability might be higher, but I don't think many users will run the
>> script A with R 2.12.1 and script B with R 2.13.0. The most typical
>> situation I have seen is, (Windows) people install R and will forget
>> to update it forever. I often have to urge our IT admin to update R in
>> our department from a version released long long ago. You may argue my
>> samples are not representative. Anyway, I can accept the default
>> version string if nobody agrees with me.
>>
>> I do use Emacs every day. It's nice, I totally agree.
>>
>> Regards,
>> Yihui
>> --
>> Yihui Xie
>> Phone: 515-294-2465 Web: http://yihui.name
>> Department of Statistics, Iowa State University
>> 2215 Snedecor Hall, Ames, IA
>

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

Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows

[Yihui Xie]

1. I know there is not such a thing; that why I said "mimic" and "the
same place" ("***/R/bin" instead of "***/R/R-x.x.x/bin").

2. Yes, I never mess with the PATH variable under *nix, because R is
installed to /usr/local/bin/ (or /usr/bin/) *by default*, which is
already in the PATH variable. Otherwise extra efforts will be required
to run R as a single letter R -- this is what I wish we were able to
do under Windows.

Regards,
Yihui
--
Yihui Xie 
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA



On Wed, May 4, 2011 at 12:55 PM, Simon Urbanek
 wrote:
> On May 4, 2011, at 12:00 PM, Yihui Xie wrote:
>
>> My suggestion was to mimic *nix systems: put the executable binaries in the 
>> same place *by default* (e.g. /usr/bin/ or /usr/local/bin).
>
> Except that there is not such thing on Windows! The closest to that is the 
> "system" folder which is off limits for applications.
>
>
>> Why isn't the default bin path for R under *nix something like 
>> /usr/bin/R-2.13.0/?
>
> It is on some unices (and most system-wide installations in practice) - but 
> that's beside the point. Unix has a well-defined FHS so regardless where you 
> install R you can always put a symlink into /usr/bin or /usr/local/bin. 
> Windows has no such conventions so Gabor's solution is pretty much what you 
> claim to want (and note that in unix you're exactly running a batch script 
> with its rhome embedded to start R!). Even on unix you don't mess with PATH 
> to select the R version to use.
>

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