[Rd] Package Installation on networked disk (was: Package Installation in RGui (PR#7262))
Hi again! I would just like to add that this surely must be a problem with network disks. As I reported yesterady in, https://stat.ethz.ch/pipermail/r-devel/2005-March/032431.html I have problems with installing packages on network drive (where I have R installed), marked N: install.packages(gap) trying URL `http://cran.r-project.org/bin/windows/contrib/2.0/PACKAGES' Content type `text/plain; charset=iso-8859-1' length 26936 bytes opened URL downloaded 26Kb trying URL `http://cran.r-project.org/bin/windows/contrib/2.0/gap_0.8-3.zip' Content type `application/zip' length 437644 bytes opened URL downloaded 427Kb package 'gap' successfully unpacked and MD5 sums checked Delete downloaded files (y/N)? y updating HTML package descriptions Warning message: unable to move temp installation 'N:/Ovce/Programi/R/rw2001/library\file4821/gap' to 'N:/Ovce/Programi/R/rw2001/library/gap' library(gap) Error in library(gap) : There is no package called 'gap' But if I try to install package on local disk, marked C: install.packages(gap, lib=C:/Programs/R/library) install.packages(gap, lib=C:/Programs/R/library) trying URL `http://cran.r-project.org/bin/windows/contrib/2.0/PACKAGES' Content type `text/plain; charset=iso-8859-1' length 26936 bytes opened URL downloaded 26Kb trying URL `http://cran.r-project.org/bin/windows/contrib/2.0/gap_0.8-3.zip' Content type `application/zip' length 437644 bytes opened URL downloaded 427Kb package 'gap' successfully unpacked and MD5 sums checked Delete downloaded files (y/N)? y updating HTML package descriptions library(gap) Error in library(gap) : There is no package called 'gap' library(gap, lib.loc=C:/Programs/R/library) ?hwe.hardy I also reported yesterday that this is not 100% reproducible. I tried to install today bundle 'gregmisc' and the installation failed only partly, due to failure of moving temporary installation directory for 'gplots', while others packages passed OK. Strange. Look below: install.packages(gregmisc) trying URL `http://cran.r-project.org/bin/windows/contrib/2.0/PACKAGES' Content type `text/plain; charset=iso-8859-1' length 26936 bytes opened URL downloaded 26Kb trying URL `http://cran.r-project.org/bin/windows/contrib/2.0/gregmisc_2.0.3.zip' Content type `application/zip' length 821874 bytes opened URL downloaded 802Kb bundle 'gregmisc' successfully unpacked and MD5 sums checked Delete downloaded files (y/N)? y updating HTML package descriptions Warning message: unable to move temp installation 'N:/Ovce/Programi/R/rw2001/library\file1347/gplots' to 'N:/Ovce/Programi/R/rw2001/library/gplots' library(gdata) Loading required package: gtools library(gplots) Error in library(gplots) : There is no package called 'gplots' Can someone try this with local and networked installation of package to confirm my thoughts. Local system: Windows XP SP1 R 2.0.1 Administrator rights Network system (host of disk): Sorry I don't have this information. -- Lep pozdrav / With regards, Gregor GORJANC University of Ljubljana Biotechnical Faculty URI: http://www.bfro.uni-lj.si/MR/ggorjan Zootechnical Departmentemail: gregor.gorjanc at bfro.uni-lj.si Groblje 3 tel: +386 (0)1 72 17 861 SI-1230 Domzalefax: +386 (0)1 72 17 888 Slovenia __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Small suggestion for stripchart help
Thank you, Kevin.
I've just committed your improvement (to
/src/library/graphics/man/stripchart.Rd).
Martin
KevinW == Kevin Wright [EMAIL PROTECTED]
on Mon, 14 Mar 2005 12:39:50 -0800 (PST) writes:
KevinW I needed to look up information about the 'jitter'
KevinW argument of stripchart. When I opened the help page
KevinW for jitter I found:
KevinW jitter when jittering is used, jitter gives the amount of
jittering applied.
KevinW which is slightly confusing/self-referential if you
KevinW are lazy and don't read the entire page.
KevinW It might be clearer to say
KevinW jitter when \code{method=jitter} is used, jitter
KevinW gives the amount of jittering applied.
KevinW Just my opinion. Thanks for listening.
KevinW Kevin Wright
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Lemon drops
On Tue, 2005-03-15 at 18:05 +0100, Peter Dalgaard wrote: I bumped into the following situation: Browse[1] coef deg0NA deg4NA deg8NA deg0NP deg4NP deg8NP (Intercept)462510528492660762 Browse[1] coef[,1] [1] 462 Browse[1] coef[,1,drop=F] deg0NA (Intercept)462 where I really wanted neither, but (Intercept) 462 Anyone happen to know a neat way out of the conundrum? I can think of rowSums(coef[,1,drop=F]) or of course val - coef[,1] names(val) - rownames(x)) but the first one is sneaky and the second gets a bit tedious... Peter, How about something like this: x deg0NA deg4NA deg8NA deg0NP deg4NP deg8NP (Intercept)462510528492660762 IV1 1 2 3 4 5 6 x[1] (Intercept) 462 str(x[1]) Named num 462 - attr(*, names)= chr (Intercept) Does that work or am I missing something? Marc Schwartz __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Lemon drops
Marc Schwartz [EMAIL PROTECTED] writes: On Tue, 2005-03-15 at 18:05 +0100, Peter Dalgaard wrote: I bumped into the following situation: Browse[1] coef deg0NA deg4NA deg8NA deg0NP deg4NP deg8NP (Intercept)462510528492660762 Browse[1] coef[,1] [1] 462 Browse[1] coef[,1,drop=F] deg0NA (Intercept)462 where I really wanted neither, but (Intercept) 462 Anyone happen to know a neat way out of the conundrum? I can think of rowSums(coef[,1,drop=F]) or of course val - coef[,1] names(val) - rownames(x)) but the first one is sneaky and the second gets a bit tedious... Peter, How about something like this: x deg0NA deg4NA deg8NA deg0NP deg4NP deg8NP (Intercept)462510528492660762 IV1 1 2 3 4 5 6 x[1] (Intercept) 462 str(x[1]) Named num 462 - attr(*, names)= chr (Intercept) Does that work or am I missing something? You're missing the context. What I really need is something that will extract a column of a matrix as a vector in the usual way, but will not get confused if there is only one row. -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Lemon drops
On Tue, 2005-03-15 at 18:26 +0100, Peter Dalgaard wrote: Marc Schwartz [EMAIL PROTECTED] writes: On Tue, 2005-03-15 at 18:05 +0100, Peter Dalgaard wrote: I bumped into the following situation: Browse[1] coef deg0NA deg4NA deg8NA deg0NP deg4NP deg8NP (Intercept)462510528492660762 Browse[1] coef[,1] [1] 462 Browse[1] coef[,1,drop=F] deg0NA (Intercept)462 where I really wanted neither, but (Intercept) 462 Anyone happen to know a neat way out of the conundrum? I can think of rowSums(coef[,1,drop=F]) or of course val - coef[,1] names(val) - rownames(x)) but the first one is sneaky and the second gets a bit tedious... Peter, How about something like this: x deg0NA deg4NA deg8NA deg0NP deg4NP deg8NP (Intercept)462510528492660762 IV1 1 2 3 4 5 6 x[1] (Intercept) 462 str(x[1]) Named num 462 - attr(*, names)= chr (Intercept) Does that work or am I missing something? You're missing the context. What I really need is something that will extract a column of a matrix as a vector in the usual way, but will not get confused if there is only one row. OK. scratching head. Well, thinking that there was an approach using t(), it works, but retains a 2 dim structure which is not what you want. It also retains the colname from the original structure as the rowname for the new construct. I don't have another idea at this point for you, but I'll keep thinking... :-) Marc __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Lemon drops
On 15 Mar 2005 18:26:46 +0100 Peter Dalgaard wrote: Marc Schwartz [EMAIL PROTECTED] writes: On Tue, 2005-03-15 at 18:05 +0100, Peter Dalgaard wrote: I bumped into the following situation: Browse[1] coef deg0NA deg4NA deg8NA deg0NP deg4NP deg8NP (Intercept)462510528492660762 Browse[1] coef[,1] [1] 462 Browse[1] coef[,1,drop=F] deg0NA (Intercept)462 where I really wanted neither, but (Intercept) 462 Anyone happen to know a neat way out of the conundrum? I can think of rowSums(coef[,1,drop=F]) or of course val - coef[,1] names(val) - rownames(x)) but the first one is sneaky and the second gets a bit tedious... Peter, How about something like this: x deg0NA deg4NA deg8NA deg0NP deg4NP deg8NP (Intercept)462510528492660762 IV1 1 2 3 4 5 6 x[1] (Intercept) 462 str(x[1]) Named num 462 - attr(*, names)= chr (Intercept) Does that work or am I missing something? You're missing the context. What I really need is something that will extract a column of a matrix as a vector in the usual way, but will not get confused if there is only one row. Maybe: coef[,1,drop=FALSE][1:nrow(coef)] ? Z -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] syntax error in memory.c when building R-devel on AIX
OK, this is really a new one for me. Just thought I'd try building R-devel (2005-03-15) on our AIX power machines and see if there are any problems. I used the settings in the Appendix B of R-admin, using the set of variables that Tim Hoar used (i.e., trying to build 64-bit R using native compilers). configure ran fine, but `gmake' gave me a syntax error when compiling src/main/memory.c. The offending line seems to be: Rboolean success = FALSE; Can anyone provide pointers? (Just to make sure, I tried building it on our SLES9-x86_64 box, and that passes make check.) TIA! Andy __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Lemon drops
On Tue, 2005-03-15 at 20:05 +0100, Achim Zeileis wrote: On 15 Mar 2005 18:26:46 +0100 Peter Dalgaard wrote: Marc Schwartz [EMAIL PROTECTED] writes: On Tue, 2005-03-15 at 18:05 +0100, Peter Dalgaard wrote: I bumped into the following situation: Browse[1] coef deg0NA deg4NA deg8NA deg0NP deg4NP deg8NP (Intercept)462510528492660762 Browse[1] coef[,1] [1] 462 Browse[1] coef[,1,drop=F] deg0NA (Intercept)462 where I really wanted neither, but (Intercept) 462 Anyone happen to know a neat way out of the conundrum? I can think of rowSums(coef[,1,drop=F]) or of course val - coef[,1] names(val) - rownames(x)) but the first one is sneaky and the second gets a bit tedious... Peter, How about something like this: x deg0NA deg4NA deg8NA deg0NP deg4NP deg8NP (Intercept)462510528492660762 IV1 1 2 3 4 5 6 x[1] (Intercept) 462 str(x[1]) Named num 462 - attr(*, names)= chr (Intercept) Does that work or am I missing something? You're missing the context. What I really need is something that will extract a column of a matrix as a vector in the usual way, but will not get confused if there is only one row. Maybe: coef[,1,drop=FALSE][1:nrow(coef)] ? Z Hinteresting. At the risk of this degenerating into an obfuscated R contest, Achim's post just gave me an idea to build on my original thought: # With one row: x deg0NA deg4NA deg8NA deg0NP deg4NP deg8NP (Intercept)462510528492660762 apply(t(x)[1, , drop = FALSE], 2, FUN = [) (Intercept) 462 # Now with two rows: x2 deg0NA deg4NA deg8NA deg0NP deg4NP deg8NP (Intercept)462510528492660762 IV1 1 2 3 4 5 6 apply(t(x2)[1, , drop = FALSE], 2, FUN = [) (Intercept) IV1 462 1 Marc __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] syntax error in memory.c when building R-devel on AIX
That statement was added yesterday (not by me) and needed moving up a line. Which version do you have? The current one has Rboolean success = FALSE; s = NULL; /* initialize to suppress warning */ and passes all my tests. The previous one had those two lines reversed and worked on gcc (with a warning) but failed on Solaris' cc (and was not legal ISO C90). On Tue, 15 Mar 2005, Liaw, Andy wrote: OK, this is really a new one for me. Just thought I'd try building R-devel (2005-03-15) on our AIX power machines and see if there are any problems. I used the settings in the Appendix B of R-admin, using the set of variables that Tim Hoar used (i.e., trying to build 64-bit R using native compilers). configure ran fine, but `gmake' gave me a syntax error when compiling src/main/memory.c. The offending line seems to be: Rboolean success = FALSE; Can anyone provide pointers? (Just to make sure, I tried building it on our SLES9-x86_64 box, and that passes make check.) -- Brian D. Ripley, [EMAIL PROTECTED] 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@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Lemon drops
Peter Dalgaard p.dalgaard at biostat.ku.dk writes: : : I bumped into the following situation: : : Browse[1] coef : deg0NA deg4NA deg8NA deg0NP deg4NP deg8NP : (Intercept)462510528492660762 : Browse[1] coef[,1] : [1] 462 : Browse[1] coef[,1,drop=F] : deg0NA : (Intercept)462 : : where I really wanted neither, but : : (Intercept) : 462 : : Anyone happen to know a neat way out of the conundrum? : : I can think of : : rowSums(coef[,1,drop=F]) : : or of course : : val - coef[,1] : names(val) - rownames(x)) : : but the first one is sneaky and the second gets a bit tedious... : If by tedious you mean its not a single expression then the basic idea of your solution #2 can be preserved while doing it in a single expression like this: structure(coef[,1], .Names = rownames(x)) __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Trigonometric functions (PR#7728)
Full_Name: Stijn Ruiter Version: 2.0.1 OS: Linux Submission from: (NULL) (195.169.225.10) Why does asin(1) result in: 1.570796 and x-sqrt(2) asin(x^2-1) result in: NaN __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Trigonometric functions (PR#7728)
Thomas Lumley schreef op de 15e dag van de lentemaand van het jaar 2005: x-sqrt(2) asin(x^2-1) result in: NaN Because you can't take the arcsin of 2^2-1=3. Wrong answer. Why is this a bug report? -- Peter Kleiweg http://www.let.rug.nl/~kleiweg/ __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Trigonometric functions (PR#7728)
On Wed, 16 Mar 2005, Peter Kleiweg wrote: Thomas Lumley schreef op de 15e dag van de lentemaand van het jaar 2005: x-sqrt(2) asin(x^2-1) result in: NaN Because you can't take the arcsin of 2^2-1=3. Wrong answer. You're right. It's actually because you can't take the arcsin of 1+4.4e-16. Same problem, just less extreme. x-sqrt(2) x^2-1==1 [1] FALSE x^2-11 [1] TRUE x^2-1-1 [1] 4.440892e-16 -thomas __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] How to store void* on 64 bit machines
Hi, I have an R class which represents a file stream (this is my custom implementation of R I/O and has nothing to do with the standard R connections). The class has a slot, called id, which is essentially a void* pointer to a C++ stream object. Up until now I worked on 32-bit machines and the id slot was an integer, so one could cast back and forth between int and void*. However, on 64-bits void* is castable to 'long int', but not int, which poses a couple of problems: a) since there is no R arrays of 'long int' type what other built-in type can I use to store void*. For example double is big enough to accommodate void*, but I am not sure whether casting will work both ways. b) assuming that a) is solvable, is there a solution which is portable between 64 and 32 bit machines? Thanks, Vadim [[alternative HTML version deleted]] __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] returning NULL from .Call call
Dear R developers,
I've just encountered one feature of R-C extensions. If it is known, I
would be thankful for any hints why it works this way (I found the way
around, which is also mentioned here, but maybe it is not the best one).
If it is however unknown, it might be considered for a wish list.
Consider a simple aka C function (the original implementation loads
complex data structures and there could be other causes of trouble apart
from non-existing files):
SEXP loadData(SEXP fileName) {
int* data = NULL;
try {
// try to open the file and read the data into 'data'
} catch(...) {
std::cout Load failed (ANY REASON) - returning NULL
std::endl;
return NULL;
}
// operation successful, but the size of data can be nil
if(data == NULL)
return NULL;
SEXP result = allocVector(INTSXP, numOfDataPoints);
PROTECT(result);
// copy data from 'data' into 'result'
delete[] data;
UNPROTECT(1);
return result;
}
This function will nicely return a data array if no load problems occur
and data is more than nil. If it is not the case I would be happy to
receive a NULL as indication that the function didn't succeed, which I
can then check with is.nul(...). I would consider it logical for SEXP,
which is a pointer (in this case to a non-existing structure). However,
trying to return NULL causes 'Segmentation Fault' without any further
message and R-session closes. The question is, what would be a working
way to return anything like NULL, something to check with is.null(...)?
Now the way around (just in case it might be of interest), slightly
modified function returning numeric(0) on fail:
SEXP loadData(SEXP fileName) {
// prerecreate and protect a non-NULL return value: numeric(0)
SEXP result = allocVector(INTSXP, 0);
PROTECT(result);
int* data = NULL;
try {
// try to open the file and read the data into 'data'
} catch(...) {
std::cout Load failed (ANY REASON) - returning NULL
std::endl;
// unprotect and return numeric(0)
UNPROTECT(1);
return result;
}
// operation successful, but the size of data can be nil
// unprotect old value to enable garbage collector to kill it sooner
or later
UNPROTECT(1);
if(data == NULL)
return result;
// recreate and protect the return value
result = allocVector(INTSXP, numOfDataPoints);
PROTECT(result);
// copy data from 'data' into 'result'
delete[] data;
UNPROTECT(1);
return result;
}
This function always has something to return and it works, but not
really elegantly and returning wrong data when fails.
Thanks in advance for any comments.
Regards
Oleg
--
Dr Oleg Sklyar
European Bioinformatics Institute
Wellcome Trust Genome Campus
Hinxton, Cambridge, CB10 1SD
England
phone/fax +44(0)1223 49 4478/4468
e-mail [EMAIL PROTECTED]
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to store void* on 64 bit machines
On Tue, 15 Mar 2005, Vadim Ogranovich wrote: I have an R class which represents a file stream (this is my custom implementation of R I/O and has nothing to do with the standard R connections). The class has a slot, called id, which is essentially a void* pointer to a C++ stream object. Up until now I worked on 32-bit machines and the id slot was an integer, If by `slot' you mean the slot in an S4 class, that is not correct. R has integer vectors, not integer scalars. so one could cast back and forth between int and void*. However, on 64-bits void* is castable to 'long int', but not int, which poses a couple of problems: a) since there is no R arrays of 'long int' type what other built-in type can I use to store void*. For example double is big enough to accommodate void*, but I am not sure whether casting will work both ways. b) assuming that a) is solvable, is there a solution which is portable between 64 and 32 bit machines? The raw type can store anything: your pointer is just a stream of bytes. It could also be stored as one or two integers. -- Brian D. Ripley, [EMAIL PROTECTED] 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@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] returning NULL from .Call call
On Tue, 15 Mar 2005, Oleg Sklyar wrote:
Dear R developers,
I've just encountered one feature of R-C extensions.
What feature is that? (It really is not clear from your description.)
NULL in R is expressed as R_NilValue in C. What did you do when `trying
to return NULL'? NULL in C is not a valid value for a SEXP pointer, of
course.
This is documented in `Writing R Extensions', and there are many examples
of it around.
If it is known, I would be thankful for any hints why it works this way
(I found the way around, which is also mentioned here, but maybe it is
not the best one). If it is however unknown, it might be considered for
a wish list.
Consider a simple aka C function (the original implementation loads complex
data structures and there could be other causes of trouble apart from
non-existing files):
SEXP loadData(SEXP fileName) {
int* data = NULL;
try {
// try to open the file and read the data into 'data'
} catch(...) {
std::cout Load failed (ANY REASON) - returning NULL std::endl;
return NULL;
}
// operation successful, but the size of data can be nil
if(data == NULL)
return NULL;
SEXP result = allocVector(INTSXP, numOfDataPoints);
PROTECT(result);
// copy data from 'data' into 'result'
delete[] data;
UNPROTECT(1);
return result;
}
This function will nicely return a data array if no load problems occur and
data is more than nil. If it is not the case I would be happy to receive a
NULL as indication that the function didn't succeed, which I can then check
with is.nul(...). I would consider it logical for SEXP, which is a pointer
(in this case to a non-existing structure). However, trying to return NULL
causes 'Segmentation Fault' without any further message and R-session closes.
The question is, what would be a working way to return anything like NULL,
something to check with is.null(...)?
Now the way around (just in case it might be of interest), slightly modified
function returning numeric(0) on fail:
SEXP loadData(SEXP fileName) {
// prerecreate and protect a non-NULL return value: numeric(0)
SEXP result = allocVector(INTSXP, 0);
PROTECT(result);
int* data = NULL;
try {
// try to open the file and read the data into 'data'
} catch(...) {
std::cout Load failed (ANY REASON) - returning NULL std::endl;
// unprotect and return numeric(0)
UNPROTECT(1);
return result;
}
// operation successful, but the size of data can be nil
// unprotect old value to enable garbage collector to kill it sooner or
later
UNPROTECT(1);
if(data == NULL)
return result;
// recreate and protect the return value
result = allocVector(INTSXP, numOfDataPoints);
PROTECT(result);
// copy data from 'data' into 'result'
delete[] data;
UNPROTECT(1);
return result;
}
This function always has something to return and it works, but not really
elegantly and returning wrong data when fails.
Thanks in advance for any comments.
Regards
Oleg
--
Dr Oleg Sklyar
European Bioinformatics Institute
Wellcome Trust Genome Campus
Hinxton, Cambridge, CB10 1SD
England
phone/fax +44(0)1223 49 4478/4468
e-mail [EMAIL PROTECTED]
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, [EMAIL PROTECTED]
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@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to store void* on 64 bit machines
On Tue, 15 Mar 2005, Prof Brian Ripley wrote: On Tue, 15 Mar 2005, Vadim Ogranovich wrote: I have an R class which represents a file stream (this is my custom implementation of R I/O and has nothing to do with the standard R connections). The class has a slot, called id, which is essentially a void* pointer to a C++ stream object. Up until now I worked on 32-bit machines and the id slot was an integer, If by `slot' you mean the slot in an S4 class, that is not correct. R has integer vectors, not integer scalars. so one could cast back and forth between int and void*. However, on 64-bits void* is castable to 'long int', but not int, which poses a couple of problems: a) since there is no R arrays of 'long int' type what other built-in type can I use to store void*. For example double is big enough to accommodate void*, but I am not sure whether casting will work both ways. b) assuming that a) is solvable, is there a solution which is portable between 64 and 32 bit machines? The raw type can store anything: your pointer is just a stream of bytes. It could also be stored as one or two integers. Depending what you want to do with this pointer and if there is only one of them, the externalptr type might be an even better match -- be careful about the non-copy-on-change semantics of that type. -- Brian D. Ripley, [EMAIL PROTECTED] 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@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] function-like macros undefined
Hi, Somehow function-like macros from Rinternals.h are not defined when I include the file. foo.c ## #include R.h #include Rinternals.h #ifndef NILSXP #error(NILSXP) #endif #ifndef INTEGER #error(INTEGER) #endif ### When compiled: vor/src% gcc -I/usr/local/lib/R/include -g -O2 -c foo.c -o foo.o foo.c:11:2: #error (INTEGER) Note that NILSXP is defined. This is true for some other function-like macros, e.g. RAW() Did anyone come across such a problem? version _ platform x86_64-unknown-linux-gnu arch x86_64 os linux-gnu system x86_64, linux-gnu status major2 minor0.1 year 2004 month11 day 15 language R OS: suse.9.2_64 Note also that R doesn't recognize this is Suse, it says x86_64-unknown-linux-gnu. Hope this is not a problem. Thanks, Vadim [[alternative HTML version deleted]] __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
