That sounds like your C function is smashing some of the header
information in a chunk of memory somewhere past res2 so that cleanup
during quit fails.
On Dec 9, 2005, at 4:28 PM, Izmirlian, Grant (NIH/NCI) [E] wrote:
> Jim:
>
> This reminds me of problems I've had before, but usually they oc
Jim:
This reminds me of problems I've had before, but usually they occur when I quit
R
i.e. q(), because when testing and developing I can't remember actually
detaching
a package. I can however think of countless times I get a segmentation fault
upon
quiting R. Usually this boils down to a hid
use a C finalizer...
void MyObject_finalize(SEXP opaque) {
MyObject *obj = (MyObject*)R_ExternalPtrAddr(opaque);
if(NULL != obj) delete obj;
}
and in your setup code...
PROTECT(p = R_MakeExternalPtr(...));
R_RegisterCFinalizer(p,MyObject_finalize);
On Dec 9, 2005, at 3:04 P
I have some C data I want to pass back to R opaquely, and then back to
C. I understand external pointers are the way to do so.
I'm trying to find how they interact with garbage collection and object
lifetime, and what I need to do so that the memory lives until the
calling R process ends.
Could
It would probably be more polite to give a warning
in 'nls' that the 'weights' argument is ignored. Something
like the following should do:
if(missing(weights)) warning("weights are not currently implemented")
> version
_
platform i386-pc-mingw32
a
Hello R-devel:
This is an update on my R package, "woods" that does bagged classification trees
using data structures in C. Most of the comments of my earlier post still
apply, with some additions (noted *)
(i) fits a single classification tree to dataset (R function CT)
(ii) basic functio
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Jim,
Can you send me a copy of the package and an R script
that causes the problem and I'll take a look at it.
D.
James Bullard wrote:
> Hello, first off, thanks for all of the previous help; hopefully someone
> will have some insight on this
Hello, first off, thanks for all of the previous help; hopefully someone
will have some insight on this question. I am attempting to track down a
segmentation fault which occurs only after a detach(2) is called in the
code (I have replaced the detach(2) with detach(package:DSA) and that
fails a
I believe Gabor was referring to this:
http://tolstoy.newcastle.edu.au/R/devel/05/05/0837.html
Andy
From: Hin-Tak Leung
>
> Gabor Grothendieck wrote:
> > There was nothing attached in the copy that came through
> > to me.
>
> I like to see that patch also.
>
> > By the way, there was some dis
Gabor Grothendieck wrote:
> There was nothing attached in the copy that came through
> to me.
I like to see that patch also.
> By the way, there was some discussion earlier this year
> on a light-weight data.frame class but I don't think anyone
> ever posted any code.
It may have been me. I am w
There was nothing attached in the copy that came through
to me.
By the way, there was some discussion earlier this year
on a light-weight data.frame class but I don't think anyone
ever posted any code.
On 12/9/05, Matthew Dowle <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Please see below for post on r
On Dec 9, 2005, at 10:05 AM, Luke Tierney wrote:
> On Thu, 8 Dec 2005, Peter Dalgaard wrote:
>
>> roger koenker <[EMAIL PROTECTED]> writes:
>>
>>> I was experimenting yesterday with a binomial make.link option
>>> for estimating student t binary response models, tentatively
>>> called gossit, and
Hi,
Please see below for post on r-help regarding data.frame() and the
possibility of dropping rownames, for space and time reasons.
I've made some changes, attached, and it seems to be working well. I see the
expected space (90% saved) and time (10 times faster) savings. There are no
doubt some
On Thu, 8 Dec 2005, Peter Dalgaard wrote:
> roger koenker <[EMAIL PROTECTED]> writes:
>
>> I was experimenting yesterday with a binomial make.link option
>> for estimating student t binary response models, tentatively
>> called gossit, and I noticed eventually that the R qt function doesn't
>> lik
On 12/9/2005 9:48 AM, Dimitris Rizopoulos wrote:
> maybe
>
> Sys.info()["nodename"]
>
> could be helpfull in Windows.
Thanks to all who replied. This seems like the most portable solution.
(The code will be running on all sorts of machines, and this isn't
guaranteed to work, but I think it'
How about something as trivial as
>system('hostname')? Is this for the Winds system?
Janusz.
On Fri, 9 Dec 2005, Duncan Murdoch wrote:
> Does R have a function to obtain a name of the machine that it is
> running on? I'm going to be writing results to a database from several
> different mac
On 9 Dec 2005, [EMAIL PROTECTED] wrote:
> Does R have a function to obtain a name of the machine that it is
> running on? I'm going to be writing results to a database from
> several different machines, and I'd like to be able to identify
> where they came from.
Sys.info has nodename which shoul
maybe
Sys.info()["nodename"]
could be helpfull in Windows.
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)16/336899
Fax: +32/(0)16/337015
Web: http://www.
Not an R function, per se, but
> system("uname -n", intern = TRUE)
returns my computer's network node hostname on both Windows and Linux.
You can use 'uname -a' for more information.
-Original Message-
From: Duncan Murdoch [mailto:[EMAIL PROTECTED]
Sent: Friday, December 09, 2005 9:31 AM
Does R have a function to obtain a name of the machine that it is
running on? I'm going to be writing results to a database from several
different machines, and I'd like to be able to identify where they came
from.
Duncan Murdoch
__
R-devel@r-projec
On Fri, 9 Dec 2005, Bjørn-Helge Mevik wrote:
Dear developeRs,
What is the preferred way to implement package-specific options?
Should one simply use options() -- e.g. options(myoption = myvalue)?
(And how should one document such options?)
You can, but documentation is the problem. It is po
Dear developeRs,
What is the preferred way to implement package-specific options?
Should one simply use options() -- e.g. options(myoption = myvalue)?
(And how should one document such options?)
Or is it better to implement a separate mechanismn, perhaps something
like ps.options()?
--
Bjørn-
Thanks for that rapid reply!
In the fourth approach, I have compiled the functions R_proxy_init(),
R_proxy_evaluate_noreturn(), R_proxy_term() and the callback functions
defined in Baiers code directly into my application (I got them from the R
source distribution and commented out the other fu
You are not calling R, but rproxy.dll, part of a (D)COM interface. Try
calling R itself (via R.dll).
On Fri, 9 Dec 2005, Simon Knapp wrote:
> Hi all,
>
> I am trying to make calls to R from an MFC application running on XP
> and am having problems blocking the application while the call
> execu
Hi all,
I am trying to make calls to R from an MFC application running on XP
and am having problems blocking the application while the call
executes.
I have tried the following approaches to using R from the application
(note that I set a wait cursor while R is executing).
1) call rcmd in BATCH
Dear all,
There really seem to be many exciting issues in spelling and in
detecting spelling errors. However, a more disturbing feature in
'eurodist' to me is that the distances seem to be wrong. There are
several cases where the triangle inequality is violated so that a trip
from A to B is shorte
26 matches
Mail list logo
