Re: [Rd] as.character() crashes R 2.11 on Win2008 x64 and Win7 64
On 30/04/2010 6:23 PM, Nicholas Hirschey wrote: Dear List, I have a Date vector, and converting to character causes R 2.11 to crash on one machine running Win2008 x64 and another running Win7 x64. The code runs fine on R 2.10. For example, x <- as.Date(rep(1:15000, 10), '1970-01-01') y <- as.character(x) At this point, Rgui crashes. I get this using both the 32 and 64 bit 2.11.0 R builds. I'd appreciate any suggestions for how to eliminate these crashes (particularly with the x64 version). Use R-patched. Duncan Murdoch Thanks, Nick The windows error log and session information is pasted below: > sessionInfo() R version 2.11.0 (2010-04-22) i386-pc-mingw32 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] stats graphics grDevices utils datasets methods base Log Name: Application Source:Application Error Date: 4/28/2010 3:00:23 PM Event ID: 1000 Task Category: (100) Level: Error Keywords: Classic User: N/A Computer: Description: Faulting application name: Rgui.exe, version: 2.110.51801.0, time stamp: 0x4bd040ca Faulting module name: msvcrt.dll, version: 7.0.7600.16385, time stamp: 0x4a5bda6f Exception code: 0xc0fd Fault offset: 0xa514 Faulting process id: 0x29cc Faulting application start time: 0x01cae704e41e3609 Faulting application path: C:\Users\hirschen\Documents\R\R-2.11.0\bin\Rgui.exe Faulting module path: C:\Windows\syswow64\msvcrt.dll Report Id: 4c17218f-52f8-11df-9214-0026b95eb365 Event Xml:; [[alternative HTML version deleted]] __ 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-devel1000 2 100 0x80 3586 Application Rgui.exe 2.110.51801.0 4bd040ca msvcrt.dll 7.0.7600.16385 4a5bda6f c0fd a514 29cc 01cae704e41e3609 C:\Users\hirschen\Documents\R\R-2.11.0\bin\Rgui.exe C:\Windows\syswow64\msvcrt.dll 4c17218f-52f8-11df-9214-0026b95eb365
[Rd] na.action(lmObject) -> NULL instead of lmObject$na.action
I think the following three calls to na.action() should return the same thing, but the last returns NULL. > d <- data.frame(x=c(1,2,NA,NA,5), y=log(1:5), row.names=LETTERS[1:5]) > na.action(na.exclude(d)) C D 3 4 attr(,"class") [1] "exclude" > na.action(model.frame(y~x, data=d, na.action=na.exclude)) C D 3 4 attr(,"class") [1] "exclude" > na.action(fit <- lm(y~x, data=d, na.action=na.exclude)) NULL lm() returns a list component called "na.action" while na.exclude() and model.frame() return the same thing as an attribute called "na.action". > fit$na.action C D 3 4 attr(,"class") [1] "exclude" Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] as.character() crashes R 2.11 on Win2008 x64 and Win7 64
Dear List, I have a Date vector, and converting to character causes R 2.11 to crash on one machine running Win2008 x64 and another running Win7 x64. The code runs fine on R 2.10. For example, x <- as.Date(rep(1:15000, 10), '1970-01-01') y <- as.character(x) At this point, Rgui crashes. I get this using both the 32 and 64 bit 2.11.0 R builds. I'd appreciate any suggestions for how to eliminate these crashes (particularly with the x64 version). Thanks, Nick The windows error log and session information is pasted below: > sessionInfo() R version 2.11.0 (2010-04-22) i386-pc-mingw32 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] stats graphics grDevices utils datasets methods base Log Name: Application Source:Application Error Date: 4/28/2010 3:00:23 PM Event ID: 1000 Task Category: (100) Level: Error Keywords: Classic User: N/A Computer: Description: Faulting application name: Rgui.exe, version: 2.110.51801.0, time stamp: 0x4bd040ca Faulting module name: msvcrt.dll, version: 7.0.7600.16385, time stamp: 0x4a5bda6f Exception code: 0xc0fd Fault offset: 0xa514 Faulting process id: 0x29cc Faulting application start time: 0x01cae704e41e3609 Faulting application path: C:\Users\hirschen\Documents\R\R-2.11.0\bin\Rgui.exe Faulting module path: C:\Windows\syswow64\msvcrt.dll Report Id: 4c17218f-52f8-11df-9214-0026b95eb365 Event Xml:; [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel1000 2 100 0x80 3586 Application Rgui.exe 2.110.51801.0 4bd040ca msvcrt.dll 7.0.7600.16385 4a5bda6f c0fd a514 29cc 01cae704e41e3609 C:\Users\hirschen\Documents\R\R-2.11.0\bin\Rgui.exe C:\Windows\syswow64\msvcrt.dll 4c17218f-52f8-11df-9214-0026b95eb365
Re: [Rd] Memory allocation in C/C++ vs R?
> Indeed. As I said, using heap objects (explicit initialization) does solve
> that issue, but you have to be again wary of other libraries which may still
> use static initializers.
I just did a little test and found, in the case of gcc/g++, that a
main C main program linked with a C++ library
that has static intializers works just fine. The sequence of commands was:
g++ -fpic -c mylib.cpp
g++ -shared -o foo.so mylib.o
gcc mylibtest foo.so
It appears that the runtime system / shared library loading process
makes sure that the static initializers for
classes defined in mylib.so are run before the C program defined in
mylibtest.c is started.
Of course, we knew this already ("it works when it works"), but this
shows, at least in the case of gcc/g++,
what is going on. But as you have pointed out, the whole process is
OS-dependent and may not work
as smoothly on other platforms.
Dominnick
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Memory allocation in C/C++ vs R?
Dominick,
On Apr 30, 2010, at 2:51 PM, Dominick Samperi wrote:
> Thanks for the clarification Simon,
>
> I think it is safe (R-safe?) to say that if there are no exceptions or errors
> on either side, then it is highly likely that everything is fine.
>
I think so - at least on the exceptions topic.
> When there are errors or exceptions, it is probably NOT safe to try to
> recover. Better to terminate the R session, insert some debug print statements
> (or breakpoints), and try to figure out what caused the problem.
>
At the minimalistic level, yes. You can do better e.g. by tracking your
objects, allocating only on the heap and so on, but the above will make sure
there is no unexpected memory corruption or leakage (the hard way ;)).
> In other words, it works when it works.
>
> This does not address the static initializer issue.
>
Indeed. As I said, using heap objects (explicit initialization) does solve that
issue, but you have to be again wary of other libraries which may still use
static initializers.
> The good news is that R with C++/STL seems to work most of the
> time, on all of the architectures for which CRAN builds a binary.
>
I would expect that as far as you can separate the setup part (creating output
R objects etc.) from the C++ work (which won't callback into R and will catch
all its exceptions) you should be safe. The danger is that in theory STL may
create some object to keep beyond the scope of the call but hopefully it won't.
Cheers,
Simon
>
>
> On Fri, Apr 30, 2010 at 2:12 PM, Simon Urbanek
> wrote:
>> Dominick,
>>
>> On Apr 30, 2010, at 1:40 PM, Dominick Samperi wrote:
>>
>>> Just to be sure that I understand, are you suggesting that the R-safe way
>>> to do things is to not use STL, and to not use C++ memory management and
>>> exception handling? How can you leave a function in an irregular way
>>> without triggering a seg fault or something like that, in which case there
>>> is no chance for recovery anyway?
>>>
>>> In my experience the C++ exception stack seems to unwind properly before
>>> returning to R when there is an exception, and memory that is allocated by
>>> C++ functions seems to maintain its integrity and does not interfere with
>>> R's memory management.
>>>
>>> It would be helpful if you could specify what kind of interference you are
>>> referring to here between C++ exception handling and R's error handling,
>>> and why STL is dangerous and best avoided in R. I have used STL with R for
>>> a long time and have experienced no problems.
>>>
>>
>> There are essentially two issues here that I had in mind.
>>
>> 1) C++ exception handling and R exceptions handling both use setjmp/longjmp
>> with the assumption that no one else does the same. That assumption is
>> voided when both are used so interleaving them will cause problems (you're
>> fine if you can guarantee that they always stack but that's not always easy
>> to achieve yet easy to miss).
>>
>> 2) C++ compilers assume that you cannot leave the context of a function in
>> unusual ways. But you can, namely if an R error is raised. This affects
>> (among others) locally allocated objects.
>>
>>
>> On 1:
>>
>> You cannot interleave R error handling and C++ exceptions. For example if
>> there is a chance of a C++ exception you must guarantee that the exception
>> won't leave the R context that you are in. This is easily demonstrated
>> because R check the consistency (see ex.1). Vice versa the consequences are
>> not easily visible, because C++ provides no tracking, but is equally fatal.
>> If you raise R exception from C++ it does not clean up whatever C++
>> exception context you were it and bypasses it. But there are even more grave
>> consequences:
>>
>> On 2:
>>
>> If you any R error from within C++ code you'll break the assumption of C++
>> that it has control over the entry/exit point of a function. Take a really
>> trivial example:
>>
>> void foo() {
>> Object o;
>> // some other code
>> error("blah")
>>
>> normally, the life of o is controlled by C++ and it will correctly execute
>> its destructor when you leave the function. However, the error call in R
>> will cause it to bypass that, the object won't be destroyed even though it
>> was allocated on the stack. Although it's obvious in the example above,
>> pretty much all R API function can raise errors so the same applies to any R
>> API call - direct or indirect. As a consequence you pretty much cannot call
>> R API function from C++ unless you are very, very careful (don't forget that
>> C++ does a lot of things behind your back such as initializing objects,
>> exception contexts etc. which you technically have no control over).
>>
>>
>> As I said in my post, you can write safe C++ code, but you have to be very
>> careful. But the point about libraries is that you have no control over what
>> they do, so you cannot know whether they will interact in a bad way with R
>
Re: [Rd] Memory allocation in C/C++ vs R?
Thanks for the clarification Simon,
I think it is safe (R-safe?) to say that if there are no exceptions or errors
on either side, then it is highly likely that everything is fine.
When there are errors or exceptions, it is probably NOT safe to try to
recover. Better to terminate the R session, insert some debug print statements
(or breakpoints), and try to figure out what caused the problem.
In other words, it works when it works.
This does not address the static initializer issue.
The good news is that R with C++/STL seems to work most of the
time, on all of the architectures for which CRAN builds a binary.
Thanks again,
Dominick
On Fri, Apr 30, 2010 at 2:12 PM, Simon Urbanek
wrote:
> Dominick,
>
> On Apr 30, 2010, at 1:40 PM, Dominick Samperi wrote:
>
>> Just to be sure that I understand, are you suggesting that the R-safe way to
>> do things is to not use STL, and to not use C++ memory management and
>> exception handling? How can you leave a function in an irregular way without
>> triggering a seg fault or something like that, in which case there is no
>> chance for recovery anyway?
>>
>> In my experience the C++ exception stack seems to unwind properly before
>> returning to R when there is an exception, and memory that is allocated by
>> C++ functions seems to maintain its integrity and does not interfere with
>> R's memory management.
>>
>> It would be helpful if you could specify what kind of interference you are
>> referring to here between C++ exception handling and R's error handling, and
>> why STL is dangerous and best avoided in R. I have used STL with R for a
>> long time and have experienced no problems.
>>
>
> There are essentially two issues here that I had in mind.
>
> 1) C++ exception handling and R exceptions handling both use setjmp/longjmp
> with the assumption that no one else does the same. That assumption is voided
> when both are used so interleaving them will cause problems (you're fine if
> you can guarantee that they always stack but that's not always easy to
> achieve yet easy to miss).
>
> 2) C++ compilers assume that you cannot leave the context of a function in
> unusual ways. But you can, namely if an R error is raised. This affects
> (among others) locally allocated objects.
>
>
> On 1:
>
> You cannot interleave R error handling and C++ exceptions. For example if
> there is a chance of a C++ exception you must guarantee that the exception
> won't leave the R context that you are in. This is easily demonstrated
> because R check the consistency (see ex.1). Vice versa the consequences are
> not easily visible, because C++ provides no tracking, but is equally fatal.
> If you raise R exception from C++ it does not clean up whatever C++ exception
> context you were it and bypasses it. But there are even more grave
> consequences:
>
> On 2:
>
> If you any R error from within C++ code you'll break the assumption of C++
> that it has control over the entry/exit point of a function. Take a really
> trivial example:
>
> void foo() {
> Object o;
> // some other code
> error("blah")
>
> normally, the life of o is controlled by C++ and it will correctly execute
> its destructor when you leave the function. However, the error call in R will
> cause it to bypass that, the object won't be destroyed even though it was
> allocated on the stack. Although it's obvious in the example above, pretty
> much all R API function can raise errors so the same applies to any R API
> call - direct or indirect. As a consequence you pretty much cannot call R API
> function from C++ unless you are very, very careful (don't forget that C++
> does a lot of things behind your back such as initializing objects, exception
> contexts etc. which you technically have no control over).
>
>
> As I said in my post, you can write safe C++ code, but you have to be very
> careful. But the point about libraries is that you have no control over what
> they do, so you cannot know whether they will interact in a bad way with R or
> not. STL is an example where only the interface is defined, the
> implementations are not and vary by OS, compiler etc. This makes it pretty
> much impossible to use it reliably since the fact that it will work on one
> implementation doesn't mean that it will work on another since it is the
> implementation details that will bite you. (I know that we had reports of
> things breaking due to STL but I don't remember what implementation/OS it was)
>
> [The above issue are only the ones I was pointing out, there may be others
> that are not covered here].
>
> Cheers,
> Simon
>
>
>
>
> R context vs C++ exception example
>
>
>> dyn.load("stl.so")
>> .Call("bar")
> something went wrong somewhere in C++...
> Warning: stack imbalance in '.Call', 2 then 4
> NULL
>
> -- what happens is that this really corrupts the R call stack since the C++
> exception mechanism bypassed R's call stack so R is now is an inconsistent
> state. The same can be i
Re: [Rd] Most recent R manuals [Was: Likely disruption to R-devel builds on Windows]
On 30/04/2010 2:11 PM, Gabor Grothendieck wrote: On Fri, Apr 30, 2010 at 11:01 AM, Duncan Murdoch wrote: > On 30/04/2010 10:48 AM, Gabor Grothendieck wrote: >> >> On Fri, Apr 30, 2010 at 10:39 AM, Duncan Murdoch >> wrote: >> > On 30/04/2010 10:22 AM, hadley wickham wrote: >> >> >> >> Maybe Duncan could apply the same script that's being used for RNEWS >> >> to the manuals? An RSS feed of changes to the manuals would be really >> >> useful. >> >> >> > >> > My script is very NEWS specific. The manuals would be harder. You >> > could >> > get the diffs from svn pretty easily, but displaying them would be >> > trickier: >> > do you display the diffs in the .texi source, or convert to HTML and >> > display the diffs there, or what? How much context around them? Not >> > impossible, but not trivial. If you could mirror the manuals to googlecode you would automatically get an HTML interface to the diffs. e.g. http://code.google.com/p/sqldf/source/list Go for it. You've got more experience with googlecode than I do. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Most recent R manuals [Was: Likely disruption to R-devel builds on Windows]
On Fri, Apr 30, 2010 at 11:01 AM, Duncan Murdoch wrote: > On 30/04/2010 10:48 AM, Gabor Grothendieck wrote: >> >> On Fri, Apr 30, 2010 at 10:39 AM, Duncan Murdoch >> wrote: >> > On 30/04/2010 10:22 AM, hadley wickham wrote: >> >> >> >> Maybe Duncan could apply the same script that's being used for RNEWS >> >> to the manuals? An RSS feed of changes to the manuals would be really >> >> useful. >> >> >> > >> > My script is very NEWS specific. The manuals would be harder. You >> > could >> > get the diffs from svn pretty easily, but displaying them would be >> > trickier: >> > do you display the diffs in the .texi source, or convert to HTML and >> > display the diffs there, or what? How much context around them? Not >> > impossible, but not trivial. If you could mirror the manuals to googlecode you would automatically get an HTML interface to the diffs. e.g. http://code.google.com/p/sqldf/source/list __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Memory allocation in C/C++ vs R?
Dominick,
On Apr 30, 2010, at 1:40 PM, Dominick Samperi wrote:
> Just to be sure that I understand, are you suggesting that the R-safe way to
> do things is to not use STL, and to not use C++ memory management and
> exception handling? How can you leave a function in an irregular way without
> triggering a seg fault or something like that, in which case there is no
> chance for recovery anyway?
>
> In my experience the C++ exception stack seems to unwind properly before
> returning to R when there is an exception, and memory that is allocated by
> C++ functions seems to maintain its integrity and does not interfere with R's
> memory management.
>
> It would be helpful if you could specify what kind of interference you are
> referring to here between C++ exception handling and R's error handling, and
> why STL is dangerous and best avoided in R. I have used STL with R for a long
> time and have experienced no problems.
>
There are essentially two issues here that I had in mind.
1) C++ exception handling and R exceptions handling both use setjmp/longjmp
with the assumption that no one else does the same. That assumption is voided
when both are used so interleaving them will cause problems (you're fine if you
can guarantee that they always stack but that's not always easy to achieve yet
easy to miss).
2) C++ compilers assume that you cannot leave the context of a function in
unusual ways. But you can, namely if an R error is raised. This affects (among
others) locally allocated objects.
On 1:
You cannot interleave R error handling and C++ exceptions. For example if there
is a chance of a C++ exception you must guarantee that the exception won't
leave the R context that you are in. This is easily demonstrated because R
check the consistency (see ex.1). Vice versa the consequences are not easily
visible, because C++ provides no tracking, but is equally fatal. If you raise R
exception from C++ it does not clean up whatever C++ exception context you were
it and bypasses it. But there are even more grave consequences:
On 2:
If you any R error from within C++ code you'll break the assumption of C++ that
it has control over the entry/exit point of a function. Take a really trivial
example:
void foo() {
Object o;
// some other code
error("blah")
normally, the life of o is controlled by C++ and it will correctly execute its
destructor when you leave the function. However, the error call in R will cause
it to bypass that, the object won't be destroyed even though it was allocated
on the stack. Although it's obvious in the example above, pretty much all R API
function can raise errors so the same applies to any R API call - direct or
indirect. As a consequence you pretty much cannot call R API function from C++
unless you are very, very careful (don't forget that C++ does a lot of things
behind your back such as initializing objects, exception contexts etc. which
you technically have no control over).
As I said in my post, you can write safe C++ code, but you have to be very
careful. But the point about libraries is that you have no control over what
they do, so you cannot know whether they will interact in a bad way with R or
not. STL is an example where only the interface is defined, the implementations
are not and vary by OS, compiler etc. This makes it pretty much impossible to
use it reliably since the fact that it will work on one implementation doesn't
mean that it will work on another since it is the implementation details that
will bite you. (I know that we had reports of things breaking due to STL but I
don't remember what implementation/OS it was)
[The above issue are only the ones I was pointing out, there may be others that
are not covered here].
Cheers,
Simon
R context vs C++ exception example
> dyn.load("stl.so")
> .Call("bar")
something went wrong somewhere in C++...
Warning: stack imbalance in '.Call', 2 then 4
NULL
-- what happens is that this really corrupts the R call stack since the C++
exception mechanism bypassed R's call stack so R is now is an inconsistent
state. The same can be invoked vice-versa (and is more common - using error in
C++ will do it) but that's harder to show because you would have to track C++
allocations to see that you're leaking objects all over the place. That is also
the reason why it's hard to find unless it's too late (and things may *appear*
to work for some time while they are not).
stl.cc:
#include
#include
using namespace std;
extern "C" SEXP foo() {
vector a;
a.resize(-1);
return R_NilValue;
}
extern "C" SEXP bar() {
try {
// lots of other C++ code here ...
eval(lang2(install(".Call"),mkString("foo")), R_GlobalEnv);
} catch (...) {
REprintf("something went wrong somewhere in C++...\n");
}
return R_NilValue;
}
> The fact that R has a C main may be problematic because C++ static
> initializers may not be called prop
Re: [Rd] Memory allocation in C/C++ vs R?
Simon, Just to be sure that I understand, are you suggesting that the R-safe way to do things is to not use STL, and to not use C++ memory management and exception handling? How can you leave a function in an irregular way without triggering a seg fault or something like that, in which case there is no chance for recovery anyway? In my experience the C++ exception stack seems to unwind properly before returning to R when there is an exception, and memory that is allocated by C++ functions seems to maintain its integrity and does not interfere with R's memory management. It would be helpful if you could specify what kind of interference you are referring to here between C++ exception handling and R's error handling, and why STL is dangerous and best avoided in R. I have used STL with R for a long time and have experienced no problems. The fact that R has a C main may be problematic because C++ static initializers may not be called properly, but the fact that packages are usually loaded dynamically complicates this picture. The dynamic library itself may take care of calling the static initializers (I'm not sure about this, and this is probably OS-dependent). One possible work-around would be to compile the first few lines (a stub) of R main using the C++ compiler, leaving everything else as is and compiled using the C compiler (at least until CXXR is widely available). Since C++ (and STL) are very popular it would be helpful for developers to have a better idea of the benefits and risks of using these tools with R. Thanks, Dominick On Fri, Apr 30, 2010 at 9:00 AM, Simon Urbanek wrote: > Brian's answer was pretty exhaustive - just one more note that is indirectly > related to memory management: C++ exception handling does interfere with R's > error handling (and vice versa) so in general STL is very dangerous and best > avoided in R. In addition, remember that regular local object rules are > broken because you are not guaranteed to leave a function the regular way so > there is a high danger of leaks and inconsistencies when using C++ memory > management unless you specifically account for that. That said, I have > written C++ code that works in R but you have to be very, very careful and > think twice about using any complex C++ libraries since they are unlikely > written in R-safe way. > > Cheers, > Simon > > > On Apr 30, 2010, at 1:03 AM, Dominick Samperi wrote: > >> The R docs say that there are two methods that the C programmer can >> allocate memory, one where R automatically frees the memory on >> return from .C/.Call, and the other where the user takes responsibility >> for freeing the storage. Both methods involve using R-provided >> functions. >> >> What happens when the user uses the standard "new" allocator? >> What about when a C++ application uses STL and that library >> allocates memory? In both of these cases the R-provided functions >> are not used (to my knowledge), yet I have not seen any problems. >> >> How is the memory that R manages and garbage collects kept >> separate from the memory that is allocated on the C++ side >> quite independently of what R is doing? >> >> Thanks, >> Dominick >> >> [[alternative HTML version deleted]] >> >> __ >> 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] RInside & child threads
Hi Folks, I am creating a multi-threaded C++ application that initializes RInside in one of the child thread. I would also like to access support interfaces like Rcpp::Environment in the remaining child threads, so that I could access any "R" function associated with the environment initialized. When I run my program, I always get "C Stack limit too huge" errors. I looked at the "Writing R Extensions" manual, and it pointed to initializing the R_CStackLimit variable to "-1", and that this initialization need to be made after the RInside constructor is called. I did that, but it still does not work. Can you please let me know how do we accomplish this task? Thanks very much, Jai [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Request - adding recycled "lwd" parameter to polygon
Hello dear members of R-devel mailing list and Kevin Buhr (the author of
the polygon function),
After some private e-mails, I was informed this is the place to post this
feature request. I hope I am correct.
I would like to use a command like this:
plot(c(1,8), 1:2, type="n")
polygon(1:7, c(2,1,2,NA,2,1,2),
col=c("red", "blue"),
# border=c("green", "yellow"),
border=c(1,10),
lwd=c(1:10))
To create two triangles, with different line widths.
But the polygon command doesn't seem to recycle the "lwd" parameter as it
does for the col, lty, and the border parameters.
I would like the resulting plot to look like what the following code will
produce:
plot(c(1,8), 1:2, type="n")
polygon(1:3, c(2,1,2),
col=c("red"),
# border=c("green", "yellow"),
border=c(1,10),
lwd=c(1))
polygon(5:7, c(2,1,2),
col=c( "blue"),
# border=c("green", "yellow"),
border=c(1,10),
lwd=c(10))
I opened up the polygon code to add the lwd parameter so to be used as the
lty is used.
For some reason it didn't work (I am wondering if it is because of some way
.Internal(polygon(xy$x, xy$y, col, border, lty, lwd,...)) doesn't accept
lwd...)
Here is the updates code I wrote (which, for some reason, doesn't work):
polygon2 <- function (x, y = NULL, density = NULL, angle = 45, border =
NULL,
col = NA, lty = par("lty"), lwd
=par("lwd") ,..., fillOddEven = FALSE)
{
..debug.hatch <- FALSE
xy <- xy.coords(x, y)
if (is.numeric(density) && all(is.na(density) | density <
0))
density <- NULL
if (!is.null(angle) && !is.null(density)) {
polygon.onehatch <- function(x, y, x0, y0, xd, yd, ..debug.hatch =
FALSE,
...) {
if (..debug.hatch) {
points(x0, y0)
arrows(x0, y0, x0 + xd, y0 + yd)
}
halfplane <- as.integer(xd * (y - y0) - yd * (x -
x0) <= 0)
cross <- halfplane[-1L] - halfplane[-length(halfplane)]
does.cross <- cross != 0
if (!any(does.cross))
return()
x1 <- x[-length(x)][does.cross]
y1 <- y[-length(y)][does.cross]
x2 <- x[-1L][does.cross]
y2 <- y[-1L][does.cross]
t <- (((x1 - x0) * (y2 - y1) - (y1 - y0) * (x2 -
x1))/(xd * (y2 - y1) - yd * (x2 - x1)))
o <- order(t)
tsort <- t[o]
crossings <- cumsum(cross[does.cross][o])
if (fillOddEven)
crossings <- crossings%%2
drawline <- crossings != 0
lx <- x0 + xd * tsort
ly <- y0 + yd * tsort
lx1 <- lx[-length(lx)][drawline]
ly1 <- ly[-length(ly)][drawline]
lx2 <- lx[-1L][drawline]
ly2 <- ly[-1L][drawline]
segments(lx1, ly1, lx2, ly2, ...)
}
polygon.fullhatch <- function(x, y, density, angle, ..debug.hatch =
FALSE,
...) {
x <- c(x, x[1L])
y <- c(y, y[1L])
angle <- angle%%180
if (par("xlog") || par("ylog")) {
warning("cannot hatch with logarithmic scale active")
return()
}
usr <- par("usr")
pin <- par("pin")
upi <- c(usr[2L] - usr[1L], usr[4L] - usr[3L])/pin
if (upi[1L] < 0)
angle <- 180 - angle
if (upi[2L] < 0)
angle <- 180 - angle
upi <- abs(upi)
xd <- cos(angle/180 * pi) * upi[1L]
yd <- sin(angle/180 * pi) * upi[2L]
if (angle < 45 || angle > 135) {
if (angle < 45) {
first.x <- max(x)
last.x <- min(x)
}
else {
first.x <- min(x)
last.x <- max(x)
}
y.shift <- upi[2L]/density/abs(cos(angle/180 *
pi))
x0 <- 0
y0 <- floor((min(y) - first.x * yd/xd)/y.shift) *
y.shift
y.end <- max(y) - last.x * yd/xd
while (y0 < y.end) {
polygon.onehatch(x, y, x0, y0, xd, yd, ..debug.hatch =
..debug.hatch,
...)
y0 <- y0 + y.shift
}
}
else {
if (angle < 90) {
first.y <- max(y)
last.y <- min(y)
}
else {
first.y <- min(y)
last.y <- max(y)
}
x.shift <- upi[1L]/density/abs(sin(angle/180 *
pi))
x0 <- floor((min(x) - first.y * xd/yd)/x.shift) *
x.shift
y0 <- 0
x.end <- max(x) - last.y * xd/yd
Re: [Rd] Most recent R manuals [Was: Likely disruption to R-devel builds on Windows]
On 30/04/2010 10:48 AM, Gabor Grothendieck wrote:
On Fri, Apr 30, 2010 at 10:39 AM, Duncan Murdoch wrote:
> On 30/04/2010 10:22 AM, hadley wickham wrote:
>>
>> Maybe Duncan could apply the same script that's being used for RNEWS
>> to the manuals? An RSS feed of changes to the manuals would be really
>> useful.
>>
>
> My script is very NEWS specific. The manuals would be harder. You could
> get the diffs from svn pretty easily, but displaying them would be trickier:
> do you display the diffs in the .texi source, or convert to HTML and
> display the diffs there, or what? How much context around them? Not
> impossible, but not trivial.
>
Just making the source diffs easily accessible would be sufficient IMHO.
That's already available, but not too pretty. E.g.
svn log -v https://svn.r-project.org/R/trunk/doc/manual | less
will show something like
r51865 | ripley | 2010-04-30 00:56:00 -0400 (Fri, 30 Apr 2010) | 1 line
Changed paths:
M /trunk/doc/manual/R-admin.texi
M /trunk/src/gnuwin32/CHANGES
M /trunk/src/library/tools/R/install.R
tests starssrc/library/tools/R/install.R
r51858 | ripley | 2010-04-29 00:51:01 -0400 (Thu, 29 Apr 2010) | 1 line
Changed paths:
M /trunk/doc/manual/R-exts.texi
tweak wording
r51854 | ripley | 2010-04-28 10:41:26 -0400 (Wed, 28 Apr 2010) | 1 line
Changed paths:
M /trunk/doc/manual/R-exts.texi
more on portability
(etc.)
and for particular details, you can do something like
svn diff -c 51858 https://svn.r-project.org/R/trunk/doc/manual
which will give
Index: R-exts.texi
===
--- R-exts.texi (revision 51857)
+++ R-exts.texi (revision 51858)
@@ -10813,10 +10813,10 @@
The @R{} for Windows installers have for a long time allowed the value
of @code{R_HOME} to be recorded in the Windows Registry: this is
-optional but the default. Where is it is recorded has changed over the
-years to allow for multiple versions of @R{} to be installed at once,
-and as from @R{} 2.11.0, to allow 32- and 64-bit versions of @R{} to be
-installed on the same machine.
+optional but selected by default. @emph{Where} is it is recorded has
+changed over the years to allow for multiple versions of @R{} to be
+installed at once, and as from @R{} 2.11.0, to allow 32- and 64-bit
+versions of @R{} to be installed on the same machine.
The basic Registry location is @code{Software\R-core\R}. For an
administrative install this is under @code{HKEY_LOCAL_MACHINE} and on a
The non-trivial part is converting it into a nice display like what you
pointed out in the Wiki.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Most recent R manuals [Was: Likely disruption to R-devel builds on Windows]
> My script is very NEWS specific. The manuals would be harder. You could > get the diffs from svn pretty easily, but displaying them would be trickier: > do you display the diffs in the .texi source, or convert to HTML and > display the diffs there, or what? How much context around them? Not > impossible, but not trivial. I suspect the best combination of ease and quality of output would be to output the texi to plain text, and then diff that. I really like the existing RNEWS format, but I guess you split the news into individual entries and only display those with any changes. It would be a bit harder to do with general output, although maybe splitting into paragraphs would be sufficient. 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] Most recent R manuals [Was: Likely disruption to R-devel builds on Windows]
On Fri, Apr 30, 2010 at 10:39 AM, Duncan Murdoch wrote: > On 30/04/2010 10:22 AM, hadley wickham wrote: >> >> Maybe Duncan could apply the same script that's being used for RNEWS >> to the manuals? An RSS feed of changes to the manuals would be really >> useful. >> > > My script is very NEWS specific. The manuals would be harder. You could > get the diffs from svn pretty easily, but displaying them would be trickier: > do you display the diffs in the .texi source, or convert to HTML and > display the diffs there, or what? How much context around them? Not > impossible, but not trivial. > Just making the source diffs easily accessible would be sufficient IMHO. For example, go to this page: http://rwiki.sciviews.org/doku.php?do=recent and click on any of the eyeglass symbols. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Most recent R manuals [Was: Likely disruption to R-devel builds on Windows]
On 30/04/2010 10:22 AM, hadley wickham wrote: Maybe Duncan could apply the same script that's being used for RNEWS to the manuals? An RSS feed of changes to the manuals would be really useful. My script is very NEWS specific. The manuals would be harder. You could get the diffs from svn pretty easily, but displaying them would be trickier: do you display the diffs in the .texi source, or convert to HTML and display the diffs there, or what? How much context around them? Not impossible, but not trivial. Duncan Hadley On Fri, Apr 30, 2010 at 8:16 AM, Gabor Grothendieck wrote: > Some easy way to find out what has changed would be desirable here. > > On Fri, Apr 30, 2010 at 9:03 AM, Simon Urbanek > wrote: >> >> On Apr 30, 2010, at 4:20 AM, Prof Brian Ripley wrote: >> >>> We are planning to phase in some major changes to the R build process on Windows shortly, so expect problems and temporary unavailability of binary builds of R and of packages, and if you are building from sources, check out the latest version of the R-admin manual (in the sources) for the current state. >>> >> >> To make sure no one has an excuse for not reading the current manuals - they are available (built nightly) at >> >> http://r.research.att.com/man/ >> >> Cheers, >> Simon >> >> >>> The planned changes are >>> >>> - to move the 32-bit builds to MinGW's recent release of gcc 4.5.0 (but with static linking of the Fortran and C++ runtimes: dynamic linking of C++ in packages crashes R). >>> >>> - to merge the 32-bit and 64-bit builds into a single installer and (for at least 98% of CRAN) a single binary for each package. >>> >>> NB: R-devel is not due for release until ca October and changes such as this are done early in the development cycle to allow plenty of time for them to be bedded down. Please do take seriously the description as >>> >>> R version 2.12.0 Under development (unstable) (2010-04-29 r51864) >>> >>> >>> -- >>> 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 >>> >>> >> >> __ >> 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] Most recent R manuals [Was: Likely disruption to R-devel builds on Windows]
Maybe Duncan could apply the same script that's being used for RNEWS to the manuals? An RSS feed of changes to the manuals would be really useful. Hadley On Fri, Apr 30, 2010 at 8:16 AM, Gabor Grothendieck wrote: > Some easy way to find out what has changed would be desirable here. > > On Fri, Apr 30, 2010 at 9:03 AM, Simon Urbanek > wrote: >> >> On Apr 30, 2010, at 4:20 AM, Prof Brian Ripley wrote: >> >>> We are planning to phase in some major changes to the R build process on >>> Windows shortly, so expect problems and temporary unavailability of binary >>> builds of R and of packages, and if you are building from sources, check >>> out the latest version of the R-admin manual (in the sources) for the >>> current state. >>> >> >> To make sure no one has an excuse for not reading the current manuals - they >> are available (built nightly) at >> >> http://r.research.att.com/man/ >> >> Cheers, >> Simon >> >> >>> The planned changes are >>> >>> - to move the 32-bit builds to MinGW's recent release of gcc 4.5.0 (but >>> with static linking of the Fortran and C++ runtimes: dynamic linking of C++ >>> in packages crashes R). >>> >>> - to merge the 32-bit and 64-bit builds into a single installer and (for at >>> least 98% of CRAN) a single binary for each package. >>> >>> NB: R-devel is not due for release until ca October and changes such as >>> this are done early in the development cycle to allow plenty of time for >>> them to be bedded down. Please do take seriously the description as >>> >>> R version 2.12.0 Under development (unstable) (2010-04-29 r51864) >>> >>> >>> -- >>> 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, UK Fax: +44 1865 272595 >>> >>> __ >>> 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 > -- 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] Most recent R manuals [Was: Likely disruption to R-devel builds on Windows]
Some easy way to find out what has changed would be desirable here. On Fri, Apr 30, 2010 at 9:03 AM, Simon Urbanek wrote: > > On Apr 30, 2010, at 4:20 AM, Prof Brian Ripley wrote: > >> We are planning to phase in some major changes to the R build process on >> Windows shortly, so expect problems and temporary unavailability of binary >> builds of R and of packages, and if you are building from sources, check out >> the latest version of the R-admin manual (in the sources) for the current >> state. >> > > To make sure no one has an excuse for not reading the current manuals - they > are available (built nightly) at > > http://r.research.att.com/man/ > > Cheers, > Simon > > >> The planned changes are >> >> - to move the 32-bit builds to MinGW's recent release of gcc 4.5.0 (but with >> static linking of the Fortran and C++ runtimes: dynamic linking of C++ in >> packages crashes R). >> >> - to merge the 32-bit and 64-bit builds into a single installer and (for at >> least 98% of CRAN) a single binary for each package. >> >> NB: R-devel is not due for release until ca October and changes such as this >> are done early in the development cycle to allow plenty of time for them to >> be bedded down. Please do take seriously the description as >> >> R version 2.12.0 Under development (unstable) (2010-04-29 r51864) >> >> >> -- >> 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, UK Fax: +44 1865 272595 >> >> __ >> 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
[Rd] Most recent R manuals [Was: Likely disruption to R-devel builds on Windows]
On Apr 30, 2010, at 4:20 AM, Prof Brian Ripley wrote: > We are planning to phase in some major changes to the R build process on > Windows shortly, so expect problems and temporary unavailability of binary > builds of R and of packages, and if you are building from sources, check out > the latest version of the R-admin manual (in the sources) for the current > state. > To make sure no one has an excuse for not reading the current manuals - they are available (built nightly) at http://r.research.att.com/man/ Cheers, Simon > The planned changes are > > - to move the 32-bit builds to MinGW's recent release of gcc 4.5.0 (but with > static linking of the Fortran and C++ runtimes: dynamic linking of C++ in > packages crashes R). > > - to merge the 32-bit and 64-bit builds into a single installer and (for at > least 98% of CRAN) a single binary for each package. > > NB: R-devel is not due for release until ca October and changes such as this > are done early in the development cycle to allow plenty of time for them to > be bedded down. Please do take seriously the description as > > R version 2.12.0 Under development (unstable) (2010-04-29 r51864) > > > -- > 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 > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Memory allocation in C/C++ vs R?
Brian's answer was pretty exhaustive - just one more note that is indirectly related to memory management: C++ exception handling does interfere with R's error handling (and vice versa) so in general STL is very dangerous and best avoided in R. In addition, remember that regular local object rules are broken because you are not guaranteed to leave a function the regular way so there is a high danger of leaks and inconsistencies when using C++ memory management unless you specifically account for that. That said, I have written C++ code that works in R but you have to be very, very careful and think twice about using any complex C++ libraries since they are unlikely written in R-safe way. Cheers, Simon On Apr 30, 2010, at 1:03 AM, Dominick Samperi wrote: > The R docs say that there are two methods that the C programmer can > allocate memory, one where R automatically frees the memory on > return from .C/.Call, and the other where the user takes responsibility > for freeing the storage. Both methods involve using R-provided > functions. > > What happens when the user uses the standard "new" allocator? > What about when a C++ application uses STL and that library > allocates memory? In both of these cases the R-provided functions > are not used (to my knowledge), yet I have not seen any problems. > > How is the memory that R manages and garbage collects kept > separate from the memory that is allocated on the C++ side > quite independently of what R is doing? > > Thanks, > Dominick > > [[alternative HTML version deleted]] > > __ > 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 Error after R CMD build for R-2.11.0
I'm really sorry that I had to disturb you (for nothing) because everything looks fine now ( why ??). After I build again the package with search() in the "Rsq.2.array" examples, I didn't get any Error. The only things that I changed it's the directory where is build the package. The package directory path is located on a different drive (USB KEY) from where it was build (HARDRIVE).This return the Error. Now I build the package on the same drive (both in the USB KEY). I try it with the last stable version R-2.11.0 and the patched version Patched (2010-04-28 r51857) /media/HAMID$ ~/Desktop/R-2.11.0/bin/R CMD build eqtl/ * checking for file 'eqtl/DESCRIPTION' ... OK * preparing 'eqtl': * checking DESCRIPTION meta-information ... OK * removing junk files * checking for LF line-endings in source and make files * checking for empty or unneeded directories * building 'eqtl_1.1.tar.gz' /media/HAMID$ ~/Desktop/R-2.11.0/bin/R CMD check eqtl_1.1.tar.gz * checking for working pdflatex ... OK * using log directory '/media/HAMID/eqtl.Rcheck' * using R version 2.11.0 (2010-04-22) * using session charset: UTF-8 * checking for file 'eqtl/DESCRIPTION' ... OK * checking extension type ... Package * this is package 'eqtl' version '1.1' * checking package dependencies ... OK * checking if this is a source package ... OK * checking for executable files ... OK * checking whether package 'eqtl' can be installed ... OK * checking package directory ... OK * checking for portable file names ... OK * checking for sufficient/correct file permissions ... OK * checking DESCRIPTION meta-information ... OK * checking top-level files ... OK * checking index information ... OK * checking package subdirectories ... OK * checking R files for non-ASCII characters ... OK * checking R files for syntax errors ... OK * checking whether the package can be loaded ... OK * checking whether the package can be loaded with stated dependencies ... OK * checking whether the package can be unloaded cleanly ... OK * checking for unstated dependencies in R code ... OK * checking S3 generic/method consistency ... OK * checking replacement functions ... OK * checking foreign function calls ... OK * checking R code for possible problems ... OK * checking Rd files ... OK * checking Rd metadata ... OK * checking Rd cross-references ... OK * checking for missing documentation entries ... OK * checking for code/documentation mismatches ... OK * checking Rd \usage sections ... OK * checking Rd contents ... OK * checking data for non-ASCII characters ... OK * checking examples ... OK * checking PDF version of manual ... OK It doesn't really look to be a user autorisation problems. Do you think it's a problem related only to my computer or should I report it as a bug ? thks a lot, __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Likely disruption to R-devel builds on Windows
We are planning to phase in some major changes to the R build process on Windows shortly, so expect problems and temporary unavailability of binary builds of R and of packages, and if you are building from sources, check out the latest version of the R-admin manual (in the sources) for the current state. The planned changes are - to move the 32-bit builds to MinGW's recent release of gcc 4.5.0 (but with static linking of the Fortran and C++ runtimes: dynamic linking of C++ in packages crashes R). - to merge the 32-bit and 64-bit builds into a single installer and (for at least 98% of CRAN) a single binary for each package. NB: R-devel is not due for release until ca October and changes such as this are done early in the development cycle to allow plenty of time for them to be bedded down. Please do take seriously the description as R version 2.12.0 Under development (unstable) (2010-04-29 r51864) -- 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] S4 method execution time
On Fri, 30 Apr 2010, Daniel Murphy wrote:
Hello:
I have written some an elementary S4 classes around a matrix to strengthen
control of some key attributes. When I run a fairly elementary function
("f") on the matrix outside the class it runs instantaneously (elapsed
system.time = 0) but when I setMethod "f" on myClass -- returning an
instance of myClass -- it runs perceptibly slower (elapsed system.time =
.06). I suspect my initialization and/or validity functions are
inefficiently written. I thought I read in this list of a function that will
trace the execution time of each of the functions called during the
evaluation of an R expression, but now I can't find that message. Is there
such a function, or was I mistaken?
Maybe Rprof? That is certainly the tool I would use, and it is
described in 'Writing R Extensions'.
But we do know that S4 methods do have a significant overhead: OTOH
there is caching going on and so a lot of this overhead is on first
use. So you may find that your 'toy' test does not scale to a real
problem (surely you have difficulty perceiving 60ms, literally the
blink of an eye?).
Thank you.
Dan Murphy
[[alternative HTML version deleted]]
__
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] Memory allocation in C/C++ vs R?
On Fri, 30 Apr 2010, Dominick Samperi wrote: The R docs say that there are two methods that the C programmer can allocate memory, one where R automatically frees the memory on return from .C/.Call, and the other where the user takes responsibility for freeing the storage. Both methods involve using R-provided functions. What happens when the user uses the standard "new" allocator? Standard in C++, not C, that is. What about when a C++ application uses STL and that library allocates memory? In both of these cases the R-provided functions are not used (to my knowledge), yet I have not seen any problems. Then you have been fortunate, maybe because you work on a very limited range of compilers and OSes? I have been plagued by this on modern Windows toolchains where it seems that dynamically linked C++ code only works if called from a C++ main program (and R is a C main program). How is the memory that R manages and garbage collects kept separate from the memory that is allocated on the C++ side quite independently of what R is doing? R does not use C++. So the 'C++ side' is entirely in the packages which choose to use it, and they manage their own memory usage via the C++ runtime they are linked to. Basically R mallocs all the memory it uses, and the hope is that the C++ runtime does not interfere with malloc (and of course it is in practice also obtaining memory by malloc or its equivalent). Thanks, Dominick [[alternative HTML version deleted]] [Please do note that what the posting guide asked you NOT to do.] -- 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
[Rd] S4 method execution time
Hello:
I have written some an elementary S4 classes around a matrix to strengthen
control of some key attributes. When I run a fairly elementary function
("f") on the matrix outside the class it runs instantaneously (elapsed
system.time = 0) but when I setMethod "f" on myClass -- returning an
instance of myClass -- it runs perceptibly slower (elapsed system.time =
.06). I suspect my initialization and/or validity functions are
inefficiently written. I thought I read in this list of a function that will
trace the execution time of each of the functions called during the
evaluation of an R expression, but now I can't find that message. Is there
such a function, or was I mistaken?
Thank you.
Dan Murphy
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
