I am unclear what you actually did, but it may be a judicious gc() is
all that was needed: otherwise the issues should be the same in the
first and the subsequent run. That's not to say that when the trigger
gets near the total address space we could not do better: and perhaps we
should not le
Luke Tierney <[EMAIL PROTECTED]> writes:
> For this specific case though, I _think_ the semantics we want is this:
>
> eapply1 <- function(env, FUN, ..., all.names = FALSE) {
> FUN <- match.fun(FUN)
> lapply(.Internal(env2list(env, all.names)), FUN, ...)
> }
>
> Not passing
I am not the expert here (the author, Luke Tierney, is probably
listening), but I understood you to have done a gc() immediately before
your second run: you presented statistics from it. If so, then I don't
understand in detail. Probably Luke does.
That's good general advice: clear out result
On Sat, 19 Feb 2005, Nawaaz Ahmed wrote:
Thanks Brian. I looked at the code (memory.c) after I sent out the first
email and noticed the malloc() call that you mention in your reply.
Looking into this code suggested a possible scenario where R would fail in
malloc() even if it had enough free heap
Thanks Brian. I looked at the code (memory.c) after I sent out the first
email and noticed the malloc() call that you mention in your reply.
Looking into this code suggested a possible scenario where R would fail
in malloc() even if it had enough free heap address space.
I noticed that if there
I have just finished translating R.pot to pt_BR and now I'll
start the process of revision and will merge it with the latest SVN
version (33261), as I started the translation on 02/06 (SVN 33048).
There are some observations I'd like to make regarding the
translation process:
Dear Brian,
Whenever I disagree with you, I wonder what error I made, and almost always
discover that there was something I missed.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Prof
> Brian Ripley
> Sent: Saturday, February 19, 2005 1:09 AM
> T
