[Rd] What changed in the R Windows interface from v2.6.2 to v2.7.0?

2009-07-30 Thread Mark Thyer
Dear R-devel, I would like to launch the Rgui.exe from a Fortran console application (we will call this FortranCon.exe), that I have written myself. To do this, I send the command line "C:\Program Files\R\R-X.X.X\Rgui.exe" (where X.X.X is the version number) as an argument to the Windows API fu

Re: [Rd] update.formula and backticked colons

2009-07-30 Thread Sundar Dorai-Raj
On Thu, Jul 30, 2009 at 2:28 PM, Sundar Dorai-Raj wrote: > I just noticed the following in update.formula and I'm wondering if > this behavior is the intention of the developers. Here's an example: > > update(`a: b` ~ x, ~ . + y) > > Note now that the response has no backticks and is interpreted as

[Rd] update.formula and backticked colons

2009-07-30 Thread Sundar Dorai-Raj
I just noticed the following in update.formula and I'm wondering if this behavior is the intention of the developers. Here's an example: update(`a: b` ~ x, ~ . + y) Note now that the response has no backticks and is interpreted as a:b (i.e. ":" is now an operator). This is because in update.formu

[Rd] rowSums, rowMean and rowCumSums?

2009-07-30 Thread Christophe Dutang
Dear list, Don't you think it could be useful to have in R base a function rowCumSums, that compute cumulative sums for each row of a matrix? My implementation of rowCumSums is rowCumSums <- function(x) t(mapply(function(row)cumsum(x[row,]), 1:NROW(x))) I'm sure it can be improved to have o

Re: [Rd] user supplied random number generators

2009-07-30 Thread William Dunlap
src/arithmetic.c will not compile if ints are not 32 bits and I suspect that there is other code that will not work correctly if ints are not 32 bits src/arithmetic.c: 574 #ifndef INT_32_BITS 575 /* configure checks whether int is 32 bits. If not this code will 576need to be rew

Re: [Rd] Checking package on Windows (and seemingly irreproducible errors in CRAN checks)

2009-07-30 Thread Carlos J. Gil Bellosta
Hello, The issue is no longer an issue concerning my package as I have changed the part that drives the error (for unrelated reasons). It is true that I might have done a greater effort to make the package fully cross-platform. I did R-CMD-checks on Unbuntu and CentOS but never on Windows. But I

Re: [Rd] RFC: methods() and showMethods() {was "debug"}

2009-07-30 Thread Martin Morgan
Martin Maechler writes: >(a new thread, on purpose) > >> "RobG" == Robert Gentleman >> on Mon, 27 Jul 2009 16:55:50 -0700 writes: > > RobG> Hi, I just committed a change to R-devel so that if > RobG> debug is called on an S3 generic function, all methods > RobG> w

Re: [Rd] user supplied random number generators

2009-07-30 Thread Ross Boylan
On Thu, 2009-07-30 at 12:32 +0200, Christophe Dutang wrote: > > This suggests that the type of user_unif_seedloc is Int32*, not int > *. > > It also suggests that user_unif_nseed should return the number of > 32 > > bit > > integers. The code for PutRNGstate(), for example, uses them in > just >

Re: [Rd] Checking package on Windows (and seemingly irreproducible errors in CRAN checks)

2009-07-30 Thread Simon Urbanek
On Jul 30, 2009, at 7:33 , Carlos J. Gil Bellosta wrote: Dear Uwe, The thing that I find funny is that the check of the package on Windows for R 2.10.x works on r-forge as you can see here: http://r-forge.r-project.org/R/?group_id=426&log=check_x86_32_windows&pkg=colbycol&flavor=devel May I

Re: [Rd] Checking package on Windows (and seemingly irreproducible

2009-07-30 Thread Uwe Ligges
Carlos J. Gil Bellosta wrote: Dear Uwe, The thing that I find funny is that the check of the package on Windows for R 2.10.x works on r-forge as you can see here: http://r-forge.r-project.org/R/?group_id=426&log=check_x86_32_windows&pkg=colbycol&flavor=devel May I be facing some kind of Wind

Re: [Rd] Checking package on Windows (and seemingly irreproducible errors in CRAN checks)

2009-07-30 Thread Carlos J. Gil Bellosta
Dear Uwe, The thing that I find funny is that the check of the package on Windows for R 2.10.x works on r-forge as you can see here: http://r-forge.r-project.org/R/?group_id=426&log=check_x86_32_windows&pkg=colbycol&flavor=devel May I be facing some kind of Windows configuration specific issue h

Re: [Rd] R --vanilla for install/remove/shlib(Re: R 2.8->2.9 change that breaks some upgrade scenarios)

2009-07-30 Thread Uwe Ligges
Hin-Tak Leung wrote: --- On Thu, 30/7/09, Martin Maechler wrote: "HL" == Hin-Tak Leung on Thu, 30 Jul 2009 08:59:01 + (GMT) writes: HL> --- On Thu, 30/7/09, Martin Maechler wrote: >> I'm not sure this addresses all the problems that your >> patch >> tried to fix

Re: [Rd] R --vanilla for install/remove/shlib(Re: R 2.8->2.9 change that breaks some upgrade scenarios)

2009-07-30 Thread Hin-Tak Leung
--- On Thu, 30/7/09, Martin Maechler wrote: > > "HL" == Hin-Tak > Leung > > on Thu, 30 Jul > 2009 08:59:01 + (GMT) writes: > > HL> --- On Thu, 30/7/09, Martin Maechler > > wrote: > >> I'm not sure this addresses all the > problems that your > >> patch > >> tried

Re: [Rd] R --vanilla for install/remove/shlib(Re: R 2.8->2.9 change that breaks some upgrade scenarios)

2009-07-30 Thread Martin Maechler
> "HL" == Hin-Tak Leung > on Thu, 30 Jul 2009 08:59:01 + (GMT) writes: HL> --- On Thu, 30/7/09, Martin Maechler wrote: >> I'm not sure this addresses all the problems that your >> patch >> tried to fix, >> but in any case, your patch re-installing the --vanill

Re: [Rd] user supplied random number generators

2009-07-30 Thread Christophe Dutang
Hello, Le 30 juil. 09 à 08:21, Ross Boylan a écrit : ?Random.user says (in svn trunk) Optionally, functions \code{user_unif_nseed} and \code{user_unif_seedloc} can be supplied which are called with no arguments and should return pointers to the number of seeds and to an integer array of

Re: [Rd] R --vanilla for install/remove/shlib(Re: R 2.8->2.9 change that breaks some upgrade scenarios)

2009-07-30 Thread Hin-Tak Leung
--- On Thu, 30/7/09, Martin Maechler wrote: > I'm not sure this addresses all the problems that your > patch > tried to fix, > but in any case, your patch re-installing the --vanilla > behavior > unconditionally (without the .libPaths()[1] detection) was > not > suffificient. But I think .libPa

Re: [Rd] Strange Interaction Between Promises and Closures (PR#13861)

2009-07-30 Thread Peter Dalgaard
kb...@andrew.cmu.edu wrote: Full_Name: Keith Bare Version: 2.7.1 OS: Linux Submission from: (NULL) (128.2.134.48) I observed unexpected behavior attempting to use lapply to vary parameters in generated closures. All the generated closures ran with the last parameter value in the list. Here's

Re: [Rd] R --vanilla for install/remove/shlib(Re: R 2.8->2.9 change that breaks some upgrade scenarios)

2009-07-30 Thread Martin Maechler
> "HL" == Hin-Tak Leung > on Tue, 28 Jul 2009 21:38:46 + (GMT) writes: HL> This is the change I suggested earlier - it should just disable more of user/site customization during package installation/removal, and getting more of R 2.8-like behavior back. Attached and inlined

[Rd] Strange Interaction Between Promises and Closures (PR#13861)

2009-07-30 Thread kbare
Full_Name: Keith Bare Version: 2.7.1 OS: Linux Submission from: (NULL) (128.2.134.48) I observed unexpected behavior attempting to use lapply to vary parameters in generated closures. All the generated closures ran with the last parameter value in the list. Here's a simple example: > funcs <-