Just thought y'all might like to know that the cause of my trouble
was that the openssl libraries currently in fink (for MacOS X on
Intel) seem to be broken. Using the system supplied openssl libraries
to build svn seems to fix the problem.
Thanks and sorry for the noise.
Cyrus
On Mar 7,
Okay, here's my effort based on Deepayan's and Charles' ideas. The
newArgs function is not what I'd call transparent, but I like the way
the wrapper looks.
> newArgs <- function(..., Params) {
+ f <- function(...) list(...)
+ formals(f) <- c(Params, formals(f))
+ b <- as.list(body(f))
+
From: Dirk Eddelbuettel
>
> On 7 March 2006 at 10:55, Hin-Tak Leung wrote:
> | I have given up on "R" with any topic on Google quite some time ago
> | (because bits from fragmented postscript/pdf files show up, for
> | example) - but using "r-devel" with topic normally gives me enough.
> | YMMV
On 7 March 2006 at 10:55, Hin-Tak Leung wrote:
| I have given up on "R" with any topic on Google quite some time
| ago (because bits from fragmented postscript/pdf files show up,
| for example) - but using "r-devel" with topic normally gives me
| enough. YMMV.
Nobody seems to have mentioned the R
On 3/7/2006 2:00 PM, Deepayan Sarkar wrote:
>
> On 3/7/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
>> I'm writing wrappers for some functions that change some of the default
>> arguments. I'd rather not list all of the arguments for the low level
>> functions because there are about a dozen w
Cyrus Harmon <[EMAIL PROTECTED]> writes:
> Dear r-devel,
>
> Sorry to trouble the list with this, but I've been beating my head
> against the wall trying to figure out what's wrong. When I try to
> connect to the R SVN server, I get the following message:
>
> ([EMAIL PROTECTED]):~/src/R$ svn c
Dear r-devel,
Sorry to trouble the list with this, but I've been beating my head
against the wall trying to figure out what's wrong. When I try to
connect to the R SVN server, I get the following message:
([EMAIL PROTECTED]):~/src/R$ svn co https://svn.r-project.org/R/trunk r-devel
svn: PROP
> "JMC" == John Chambers <[EMAIL PROTECTED]>
> on Tue, 07 Mar 2006 16:33:59 -0500 writes:
JMC> Martin Morgan wrote:
>> Thanks John for the reply and explanation. I sometimes
>> use validObject interactively, and in those circumstances
>> it might be nice to be able to r
Martin Morgan wrote:
>Thanks John for the reply and explanation. I sometimes use validObject
>interactively, and in those circumstances it might be nice to be able
>to require recursive validity checking, e.g., with an optional
>argument.
>
>
Sounds reasonable. After some complicated replaceme
Hi all,
Just noted this behavior in the past couple of days, where if R is
started in a shell script such as:
gnome-terminal [-e][-x] R
or in ESS (version 5.2.12 with Emacs or XEmacs), the LD_LIBRARY_PATH
environment variable is not properly appended to, resulting in the loss
of the pre-start
On 3/7/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> I'm writing wrappers for some functions that change some of the default
> arguments. I'd rather not list all of the arguments for the low level
> functions because there are about a dozen wrapper functions, and about
> 20 arguments to low
On 3/7/2006 12:08 PM, Charles Dupont wrote:
> Duncan Murdoch wrote:
>> I'm writing wrappers for some functions that change some of the default
>> arguments. I'd rather not list all of the arguments for the low level
>> functions because there are about a dozen wrapper functions, and about
>> 20
Seth Falcon wrote:
> Uwe Ligges <[EMAIL PROTECTED]> writes:
>
>>>Point taken, but is the behavior of as.character correct?
>>>as.character(list(NULL))
>>>as.character(NULL)
>>
>>
>>I thought about it quite a while. I think the current bahaviour is
>>quite OK. What should as.character do in the fo
Uwe Ligges <[EMAIL PROTECTED]> writes:
>> Point taken, but is the behavior of as.character correct?
>> as.character(list(NULL))
>> as.character(NULL)
>
>
> I thought about it quite a while. I think the current bahaviour is
> quite OK. What should as.character do in the follwing case:
>as.charac
Here's a slightly different approach:
lowlevel <- function(longname = 1, ...) {
cat("longname = ", longname, "\n")
}
wrapper <- function(...) {
newargs <- defaults(list(...), list(longname = 2))
do.call("lowlevel", newargs)
}
defaults <- function(x, defaults) {
if (length(x) == 0)
Seth Falcon wrote:
> Uwe Ligges <[EMAIL PROTECTED]> writes:
>
>>These are all dangerous, hence use the "safe" ways:
>>
>>sapply(a, is.null)
>>sapply(a, identical, "NULL")
>>sapply(a, is.na)
>>sapply(a, identical, "NA")
>
>
> Point taken, but is the behavior of as.character correct?
>
> as.char
Duncan Murdoch wrote:
> I'm writing wrappers for some functions that change some of the default
> arguments. I'd rather not list all of the arguments for the low level
> functions because there are about a dozen wrapper functions, and about
> 20 arguments to lowlevel. Instead I'm trying someth
Uwe Ligges wrote:
> Seth Falcon wrote:
>
>
>>Uwe Ligges <[EMAIL PROTECTED]> writes:
>>
>>
>>
>>>Charles Dupont wrote:
>>>
>>>
>>>
I was messing around with R and I found an example R behaving oddly:
a <- alist(NULL, "bob", c(3,6,2,3))
a
a == 'NULL'
a == "NULL"
a == 'c
Uwe Ligges <[EMAIL PROTECTED]> writes:
> These are all dangerous, hence use the "safe" ways:
>
> sapply(a, is.null)
> sapply(a, identical, "NULL")
> sapply(a, is.na)
> sapply(a, identical, "NA")
Point taken, but is the behavior of as.character correct?
as.character(list(NULL))
as.character(NULL)
Thanks John for the reply and explanation. I sometimes use validObject
interactively, and in those circumstances it might be nice to be able
to require recursive validity checking, e.g., with an optional
argument.
Martin
John Chambers <[EMAIL PROTECTED]> writes:
> The problem is over-ambitious d
Seth Falcon wrote:
> Uwe Ligges <[EMAIL PROTECTED]> writes:
>
>
>>Charles Dupont wrote:
>>
>>
>>>I was messing around with R and I found an example R behaving oddly:
>>>
>>>a <- alist(NULL, "bob", c(3,6,2,3))
>>>a
>>>a == 'NULL'
>>>a == "NULL"
>>>a == 'cat'
>>>
>>
>>
>>Always use is.null() to te
I think it'd be more appropriate to use:
sapply(a, "==", "NULL")
or
sapply(a, "==", "NA")
for this case.
Best,
Dimitris
Dimitris Rizopoulos
Ph.D. Student
Biostatistical Centre
School of Public Health
Catholic University of Leuven
Address: Kapucijnenvoer 35, Leuven, Belgium
Tel: +32/(0)1
Uwe Ligges <[EMAIL PROTECTED]> writes:
> Charles Dupont wrote:
>
>> I was messing around with R and I found an example R behaving oddly:
>>
>> a <- alist(NULL, "bob", c(3,6,2,3))
>> a
>> a == 'NULL'
>> a == "NULL"
>> a == 'cat'
>>
>
>
> Always use is.null() to test on NULL, as in:
What should I
The original code was not intended to be fully finished.
It was just to give the idea so I left out the error checking.
Adding such a check is just a matter of adding an if
statement to check the pmatch for NA:
wrapper <- function(...) {
args <- list(...)
if (length(args)) {
nf <- names(f
On 3/7/2006 9:42 AM, Gabor Grothendieck wrote:
> Try this:
>
>
> wrapper <- function(...) {
> args <- list(...)
> if (length(args)) {
> nf <- names(formals(lowlevel))
> nams <- nf[pmatch(names(args), nf)]
> args <- replace(list(longname = 2), nams, args)
> }
> do.c
Charles Dupont wrote:
> I was messing around with R and I found an example R behaving oddly:
>
> a <- alist(NULL, "bob", c(3,6,2,3))
> a
> a == 'NULL'
> a == "NULL"
> a == 'cat'
>
Always use is.null() to test on NULL, as in:
sapply(a, is.null)
Uwe Ligges
> If I create a list with a NUL
Try this:
wrapper <- function(...) {
args <- list(...)
if (length(args)) {
nf <- names(formals(lowlevel))
nams <- nf[pmatch(names(args), nf)]
args <- replace(list(longname = 2), nams, args)
}
do.call("lowlevel", args)
}
Here is a test:
> wrapper()
longname
I was messing around with R and I found an example R behaving oddly:
a <- alist(NULL, "bob", c(3,6,2,3))
a
a == 'NULL'
a == "NULL"
a == 'cat'
If I create a list with a NULL value
>a <- alist(NULL, "bob", c(3,6,2,3))
>a
[[1]]
NULL
[[2]]
[1] "bob"
[[3]]
c(3, 6, 2, 3)
and run some tests on '
I'm writing wrappers for some functions that change some of the default
arguments. I'd rather not list all of the arguments for the low level
functions because there are about a dozen wrapper functions, and about
20 arguments to lowlevel. Instead I'm trying something like this:
lowlevel <- fu
Dear prof. Ripley,
many thanks for the clarification, now I have good elements for
managing the purchase.
kind regards,
Simone Giannerini
On 3/7/06, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> On Tue, 7 Mar 2006, Simone Giannerini wrote:
>
> > Ok thanks, I am wondering whether running multip
Please don't do malloc inside C code like this - it won't interact too
well with the garbage collector in R, and your program probably will
either leak or crash or both... and when are you going to do your
free()?
What you want is do is to delete that malloc line and do the
allocation on the R s
Hello,
I'm having some difficulty to understand how I could
take the proper result from the following listing:
-- cut ---
#include
#include
#include
void retMat ( double **y, int *n, int *m, double *a,
double *b) {
int i, j;
y = malloc( (*n) * sizeof( double ) );
for (
Hi,
I have given up on "R" with any topic on Google quite some time
ago (because bits from fragmented postscript/pdf files show up,
for example) - but using "r-devel" with topic normally gives me
enough. YMMV.
HTL
Tim Brown wrote:
> Hi everyone,
>
> I know this is a long shot but I just wanted
On Tue, 7 Mar 2006, Simone Giannerini wrote:
> Ok thanks, I am wondering whether running multiple instances of R
> would be possible without problems in presence of compiled code
> (shared libraries).
> Intuitively, while there can be multiple instances of R, all of them
> would be using the same
Ok thanks, I am wondering whether running multiple instances of R
would be possible without problems in presence of compiled code
(shared libraries).
Intuitively, while there can be multiple instances of R, all of them
would be using the same library, but I am just guessing, I might do a
check on t
> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]>
> on Mon, 06 Mar 2006 19:21:50 -0500 writes:
Duncan> On 3/6/2006 4:09 PM, Tim Brown wrote:
>> Hi everyone,
>>
>> I know this is a long shot but I just wanted to throw it
>> out there. I have lately been using R a lo
36 matches
Mail list logo
