Re: [Rd] Does anybody successfully built latest R on AIX 5.3?
We successfully built R on AIX 6.1 but the following instructions should also work for 5.3. We mainly used the software from OSS4AIX but also from the AIX Toolbox for Linux Applications obtainable directly from IBM. Attached you'll find our list of installed rpms. This and the instructions provided in the R Installation and Administration manual should be all you need to build R on AIX systems. hth, st cdrecord-1.9-7 mkisofs-1.13-4 libtiff-3.6.1-4 bash-3.0-1 bash-doc-3.0-1 less-382-1 vim-enhanced-6.3-1 vim-common-6.3-1 screen-3.9.10-2 wget-1.9.1-1 rsync-2.6.2-1 emacs-nox-21.3-1 emacs-leim-21.3-1 expat-2.0.1-1 neon-0.28.2-1 openssl-0.9.8h-1 sqlite-3.6.1-1 readline-5.2-1 gdbm-1.8.3-2 info-4.6-1 emacs-el-21.3-1 apr-1.3.2-1 apr-util-1.3.2-1 gmp-4.2.3-1 readline-devel-5.2-1 zlib-1.2.3-6 emacs-21.3-1 subversion-1.4.6-2 tar-1.14-2 mpfr-2.3.1-1 mpfr-devel-2.3.1-1 xft-2.1.6-5 libstdc++-4.2.4-1 python-2.3.4-4 joe-3.5-1 libXpm-3.5.7-2 gmp-devel-4.2.3-1 m4-1.4.11-1 gcc-cpp-4.2.4-2 freetype2-2.3.7-1 libgomp-4.2.4-2 gcc-c++-4.2.4-2 zlib-devel-1.2.3-6 gdb-6.8-1 libgcc-4.2.4-2 libxml2-2.6.32-1 gcc-4.2.4-2 gcc-gfortran-4.2.4-2 make-3.80-1 pkg-config-0.19-6 t1lib-5.1.2-1 nano-2.0.7-1 cairo-1.0.2-6 popt-1.7-2 unzip-6.0-1 lynx-2.8.4-2 tightvnc-1.3.10-1 urw-fonts-2.0-1 xpdf-3.02-3 atk-1.10.3-2 fontconfig-2.5.0-2 glib2-2.8.1-3 libjpeg-6b-7 libpng-1.2.30-1 pango-1.10.0-2 xcursor-1.1.7-2 xrender-0.9.1-2 AIX-rpm-6.1.0.0-2 gtk2-2.8.3-9 libxml2-devel-2.6.32-1 sudo-1.6.9p17-1 gd-2.0.35-4 gd-devel-2.0.35-4 fontconfig-devel-2.5.0-2 freetype2-devel-2.3.7-1 expat-devel-2.0.1-1 libpng-devel-1.2.30-1 libjpeg-devel-6b-7 libXpm-devel-3.5.7-2 librsvg2-2.4.0-1 librsvg2-devel-2.4.0-1 glib2-devel-2.8.1-3 pango-devel-1.10.0-2 cairo-devel-1.0.2-6 gtk2-devel-2.8.3-9 atk-devel-1.10.3-2 libart_lgpl-2.3.20-1 libart_lgpl-devel-2.3.20-1 tightvnc-server-1.3.10-1 gettext-0.17-1 coreutils-6.12-1 libstdc++-devel-4.2.4-2 lapack-3.1.1-1 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] warning: assignment discards qualifiers from pointer target type
On Tue, 7 Jun 2011, Duncan Murdoch wrote:
On 07/06/2011 9:08 AM, oliver wrote:
Hello,
following an advice here from the list I looked into sources of other
packages (xts) and found the TYPEOF() macro/function, which really is
helpful.
It is documented, of course, but actually better alternatives are
described in 'Writing R Extensions'.
We would urge you to study the R sources rather than copy bad habits
from randomly chosen package sources.
I iused the follwong code snippet:
switch( TYPEOF( filename_sexp ) )
{
case STRSXP: filename = CHAR( STRING_ELT(filename_sexp, 0) );
break;
default: error(filename argument must be a string);
break;
}
Here, filename is of type char*
and one function opens a file with that name.
So it is purely intended to just grab out the char* from the
String-Expression.
Am I doing something wrong here, or is it ok, but I have somehow
to say the extracting macros/functions, that it is really intended
to throw away information and that a warning is not necessary?
The result of calling CHAR should be a const char *. You are not allowed
to touch the string it points to.
Note too that isString() exists for this purpose, and there is no
check in that code that LENGTH(filename_sexp) 0 (or == 1). In the R
sources you will often see things like
if(!isString(sfile) || LENGTH(sfile) 1)
error(invalid '%s' argument, description);
Then, reading on,
file = translateChar(STRING_ELT(sfile, 0));
for you cannot (in general) assume that the character vector passed is
in the native encoding.
--
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] Does anybody successfully built latest R on AIX 5.3?
On 06/08/2011 02:02 PM, XiaoboGu wrote: Hi Stefan, Thanks for replying! I have just managed to installed gcc 4.2.4.2 on AIX this evening, and will try to install gfortran tomorrow, there are a few more questions great. 1. Are you running R 2.13.0 Currently we are running 2.12.0 (works with both GNU and IBM compilers). I was not able to compile 2.13 with GNU compilers yet, IBM compilers work though (are preferable anyway, since performance is higher): R version 2.13.0 Patched (2011-06-08 r56086) Copyright (C) 2011 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: powerpc-ibm-aix6.1.0.0 (64-bit) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type 'license()' or 'licence()' for distribution details. R is a collaborative project with many contributors. Type 'contributors()' for more information and 'citation()' on how to cite R or R packages in publications. Type 'demo()' for some demos, 'help()' for on-line help, or 'help.start()' for an HTML browser interface to help. Type 'q()' to quit R. sessionInfo() R version 2.13.0 Patched (2011-06-08 r56086) Platform: powerpc-ibm-aix6.1.0.0 (64-bit) locale: [1] EN_US.UTF-8 EN_US.UTF-8 C C EN_US.UTF-8 EN_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base However recommended package Matrix gives an error upon loading. 2. Can you share all the environment variables we have to set before running the configure script. See the manual and https://r-forge.r-project.org/scm/viewvc.php/install_scripts/install_R_AIX.sh?view=markuproot=aix You may download this script (and patches), modify the paths accordingly, run it (e.g., ./install_R_AIX.sh --ibm for 2.13) and R should build fine. There are a couple of notes and patches provided in the R/AIX repository on R-Forge (e.g., how to get IBM BLAS linked etc., missing third-party libs installed, etc.). 3. Can you share the full command line of configure script. see above. 4. According to your experience, is there a huge performance lift compared to X86 CPUS, what's the clock speed of you Power CPU? No there isn't. One can use the IBM BLAS library (ESSL), then one will observe a significant speedup for linear algebra tasks. Note however, ESSL does not incorporate the full BLAS specification (thus the patch). In general, R runs slower on the power architecture than on x86. We have a Power 6 8core CPU @ 3.5 GHz. Actually, we use our system mainly for memory-demanding applications (=128GB RAM). Best, st Regards, Xiaobo Gu -Original Message- From: Stefan Theussl [mailto:stefan.theu...@wu.ac.at] Sent: Wednesday, June 08, 2011 7:07 PM To: guxiaobo1...@gmail.com Cc: r-devel@r-project.org Subject: Re: [Rd] Does anybody successfully built latest R on AIX 5.3? We successfully built R on AIX 6.1 but the following instructions should also work for 5.3. We mainly used the software from OSS4AIX but also from the AIX Toolbox for Linux Applications obtainable directly from IBM. Attached you'll find our list of installed rpms. This and the instructions provided in the R Installation and Administration manual should be all you need to build R on AIX systems. hth, st __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Does anybody successfully built latest R on AIX 5.3?
Hi Stefan, Thanks for replying! I have just managed to installed gcc 4.2.4.2 on AIX this evening, and will try to install gfortran tomorrow, there are a few more questions 1. Are you running R 2.13.0 2. Can you share all the environment variables we have to set before running the configure script. 3. Can you share the full command line of configure script. 4. According to your experience, is there a huge performance lift compared to X86 CPUS, what's the clock speed of you Power CPU? Regards, Xiaobo Gu -Original Message- From: Stefan Theussl [mailto:stefan.theu...@wu.ac.at] Sent: Wednesday, June 08, 2011 7:07 PM To: guxiaobo1...@gmail.com Cc: r-devel@r-project.org Subject: Re: [Rd] Does anybody successfully built latest R on AIX 5.3? We successfully built R on AIX 6.1 but the following instructions should also work for 5.3. We mainly used the software from OSS4AIX but also from the AIX Toolbox for Linux Applications obtainable directly from IBM. Attached you'll find our list of installed rpms. This and the instructions provided in the R Installation and Administration manual should be all you need to build R on AIX systems. hth, st __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Does anybody successfully built latest R on AIX 5.3?
-Original Message- From: Stefan Theussl [mailto:stefan.theu...@wu.ac.at] Sent: Wednesday, June 08, 2011 8:40 PM To: XiaoboGu Cc: r-devel@r-project.org Subject: Re: [Rd] Does anybody successfully built latest R on AIX 5.3? On 06/08/2011 02:02 PM, XiaoboGu wrote: Hi Stefan, Thanks for replying! I have just managed to installed gcc 4.2.4.2 on AIX this evening, and will try to install gfortran tomorrow, there are a few more questions great. 1. Are you running R 2.13.0 Currently we are running 2.12.0 (works with both GNU and IBM compilers). I was not able to compile 2.13 with GNU compilers yet, IBM compilers work though (are preferable anyway, since performance is higher): R version 2.13.0 Patched (2011-06-08 r56086) Copyright (C) 2011 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: powerpc-ibm-aix6.1.0.0 (64-bit) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type 'license()' or 'licence()' for distribution details. R is a collaborative project with many contributors. Type 'contributors()' for more information and 'citation()' on how to cite R or R packages in publications. Type 'demo()' for some demos, 'help()' for on-line help, or 'help.start()' for an HTML browser interface to help. Type 'q()' to quit R. sessionInfo() R version 2.13.0 Patched (2011-06-08 r56086) Platform: powerpc-ibm-aix6.1.0.0 (64-bit) locale: [1] EN_US.UTF-8 EN_US.UTF-8 C C EN_US.UTF-8 EN_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base However recommended package Matrix gives an error upon loading. 2. Can you share all the environment variables we have to set before running the configure script. See the manual and https://r-forge.r-project.org/scm/viewvc.php/install_scripts/install_R_AIX.sh?view=markup root=aix You may download this script (and patches), modify the paths accordingly, run it (e.g., ./install_R_AIX.sh --ibm for 2.13) and R should build fine. There are a couple of notes and patches provided in the R/AIX repository on R-Forge (e.g., how to get IBM BLAS linked etc., missing third-party libs installed, etc.). 3. Can you share the full command line of configure script. see above. 4. According to your experience, is there a huge performance lift compared to X86 CPUS, what's the clock speed of you Power CPU? No there isn't. One can use the IBM BLAS library (ESSL), then one will observe a significant speedup for linear algebra tasks. Note however, ESSL does not incorporate the full BLAS specification (thus the patch). In general, R runs slower on the power architecture than on x86. This is strange, we are hoping to improve R performance through high clock speed Power CPU(4.0 GHz above), Now I think we should take more considerations, RAM is also cheaper for X86 than Power :) We have a Power 6 8core CPU @ 3.5 GHz. Actually, we use our system mainly for memory-demanding applications (=128GB RAM). Best, st Regards, Xiaobo Gu -Original Message- From: Stefan Theussl [mailto:stefan.theu...@wu.ac.at] Sent: Wednesday, June 08, 2011 7:07 PM To: guxiaobo1...@gmail.com Cc: r-devel@r-project.org Subject: Re: [Rd] Does anybody successfully built latest R on AIX 5.3? We successfully built R on AIX 6.1 but the following instructions should also work for 5.3. We mainly used the software from OSS4AIX but also from the AIX Toolbox for Linux Applications obtainable directly from IBM. Attached you'll find our list of installed rpms. This and the instructions provided in the R Installation and Administration manual should be all you need to build R on AIX systems. hth, st __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] warning: assignment discards qualifiers from pointer target type
On Wed, Jun 08, 2011 at 12:22:10PM +0100, Prof Brian Ripley wrote:
On Tue, 7 Jun 2011, Duncan Murdoch wrote:
On 07/06/2011 9:08 AM, oliver wrote:
Hello,
following an advice here from the list I looked into sources of other
packages (xts) and found the TYPEOF() macro/function, which really is
helpful.
It is documented, of course, but actually better alternatives are
described in 'Writing R Extensions'.
We would urge you to study the R sources rather than copy bad habits
from randomly chosen package sources.
[...]
Hmhh, it was not randomly chosen, it was, what I got as a hint here on the list.
I iused the follwong code snippet:
switch( TYPEOF( filename_sexp ) )
{
case STRSXP: filename = CHAR( STRING_ELT(filename_sexp, 0) );
break;
default: error(filename argument must be a string);
break;
}
Here, filename is of type char*
and one function opens a file with that name.
So it is purely intended to just grab out the char* from the
String-Expression.
Am I doing something wrong here, or is it ok, but I have somehow
to say the extracting macros/functions, that it is really intended
to throw away information and that a warning is not necessary?
The result of calling CHAR should be a const char *. You are
not allowed to touch the string it points to.
Note too that isString() exists for this purpose,
[...]
OK, I also sometimes used that (maybe I threw it out or used it in other
modules).
and there is no
check in that code that LENGTH(filename_sexp) 0 (or == 1). In the
R sources you will often see things like
if(!isString(sfile) || LENGTH(sfile) 1)
error(invalid '%s' argument, description);
[...]
If it's a vector, I can just pic the first element.
Or does LENGTH(sfile) give the length of the string itself
(like strlen(3))?
If the latter, then my file-opeing operation would faile with an error.
Of course I check if my fopen() gibves back NULL.
Then, reading on,
file = translateChar(STRING_ELT(sfile, 0));
translateChar is explained on page 120 of the extension writing do.
I'm not in this point of the documentation.
And I often need to look around, when I want to find a function,
as they are documented/explained somewhere during the flow of the text.
Something like a API description that is brief would help.
For example something like in the manuals of the OCaml language:
http://caml.inria.fr/pub/docs/manual-ocaml/libref/Pervasives.html
That's very brief.
Chapter 6 of the Writing R Extensions is rather in this style
and gives a good overview.
Something like that for the macros would be helpful.
for you cannot (in general) assume that the character vector passed
is in the native encoding.
I try to do some coercions (e.g. as.integer())
when I need integer in the C-code and then
in the C-part rigidly check on integer.
About the char-encodings I have not thought much.
Ciao,
Oliver
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Overloading S4 methods
The bug should be fixed in r-devel and 2.13 patched, as of svn rev. 56090.
John
On 6/7/11 12:42 AM, Iago Mosqueira wrote:
On Mon, Jun 6, 2011 at 11:28 PM, John Chambersj...@r-project.org wrote:
This is a bug, medium-subtle, but also raises an interesting software design
point.
The Bug:
Nothing specific about ANY and missing, but the issue is whether the
method was inherited (the ANY case) or defined directly (the missing
case).
Generic functions keep a cached table of dispatched methods, to save
determining inherited methods repeatedly for calls with the same signature.
When pkg B is loaded, the inherited methods are reset, but apparently the
directly defined ones were not (but should have been if pkg B overrides the
method).
It's interesting that this bug seems not to have been reported before, which
leads to:
The Software Design Point:
When a package (B) extends the class/method software in another package (A),
typically B adds new classes and perhaps new generic functions with methods
for previous classes in A as well as classes in B. It might also extend the
behavior for classes in A to other generic functions.
What is less usual is to directly override an existing method for a class
that belongs to A. Notice that there can be side-effects, such as behavior
of examples or tests in package A depending on whether B has been loaded or
not. And objects created entirely from A could have their computations
change after B was loaded.
Nothing at all illegal here, and we'll make it work. But a more predictable
implementation for most applications would, say, define a new class in B
that extended the class in A. In your example (very helpful, by the way)
one might have a class mynumB, perhaps with the same slots as mynum but
with modified behavior.
If you want to keep the current implementation, though, a workaround until
the bug is fixed would be something like:
setMethod(plot, c(mynum, missing), getMethod(plot, c(mynum,
missing)))
executed after B is attached (I think it could be in the .onLoad function
for B, but have not tested that).
John
Many thanks for the very complete explanation. We are using this
mechanism to provide ggplot2-based plot for some classes, to
substitute the initial lattice-based ones, so the effects are limited
to visual output and not results of computation, but it is good you
reminded me of the possible side effects of this strategy. Is maybe a
warning during R CMD check appropriate here?
Adding the call to setMethod(..., getMethod()) did not work if placed
inside .onLoad, and in fact had the effect of getMethod() now
returning the Apkg method after Bpkg was loaded.
Running the line after Bpkg has loaded did sort it out. What would
then be the best way of adding this command to the pkg loading
process? I have also tried adding it to a zzz.R file on iuts own but
that did not work, I still need to re-run it after loading has
finished.
Many thanks,
Iago
On 6/6/11 4:11 AM, Iago Mosqueira wrote:
On Wed, Jun 1, 2011 at 6:04 PM, Martin Morganmtmor...@fhcrc.orgwrote:
On 06/01/2011 04:39 AM, Iago Mosqueira wrote:
Dear all,
I am experiencing some problems with S4 method overloading. I have
defined a generic for graphics:plot, using
setGeneric(plot, useAsDefault = plot)
and with
importFrom('graphics', 'plot') and
exportMethods('plot') in the NAMESPACE file of pkg A.
I'd guess you were creating two generics (explicitly in pkgA, implicitly
in
pkgB). Maybe
export(plot)
in NAMESPACE of pkg A,
importFrom('pkgA', plot)
exportMethods(plot)
in pkg B. Feel free to post to the list if that's helpful.
Martin
I then proceed to define a method for signature c('myS4class',
'missing'). This works as expected: selectMethod('plot',
c('myS4class', 'missing')) returns the newly defined method, and the
method gets called when invoked.
Another pkg, B, wishes to overload this and redefines the method for
the same signature. A method is defined for c('myS4class', 'missing'),
and exported on the NAMESPACE. The new method is shown by
selectMethod() after pkg B has been loaded, but a call to
plot(anobjectofmyS4class)
comes up with the result of running the first method, from pkg A. I
have tried importing 'plot' in B's NAMESPACE from both graphics or A,
but the end result is the same.
Package B does the same thing for a method created by pkg A, myMethod,
and that works fine.
Any pointers or where this might be going wrong? How is it that a
different method than the one shown by selectMethod() is being run?
Something to do with the 'missing' part of the signature?
Many thanks,
Iago Mosqueira
Dear all,
I have tried Martin's suggestion, but the problem persists. It seems
to be related to having 'missing' in the signature, as doing the same
kind of overloading for c('myclass', 'ANY') work as expected.
I am attaching 2 simple packages where I attempt this repeated
overloading of plot for the same class. Script below, also found in
Re: [Rd] warning: assignment discards qualifiers from pointer target type
On Jun 8, 2011, at 12:08 PM, oliver wrote:
On Wed, Jun 08, 2011 at 12:22:10PM +0100, Prof Brian Ripley wrote:
On Tue, 7 Jun 2011, Duncan Murdoch wrote:
On 07/06/2011 9:08 AM, oliver wrote:
Hello,
following an advice here from the list I looked into sources of other
packages (xts) and found the TYPEOF() macro/function, which really is
helpful.
It is documented, of course, but actually better alternatives are
described in 'Writing R Extensions'.
We would urge you to study the R sources rather than copy bad habits
from randomly chosen package sources.
[...]
Hmhh, it was not randomly chosen, it was, what I got as a hint here on the
list.
It was not provided to you to look at how it checks arguments. For basic usage
it's better to look at the R code. The coding styles vary a lot in packages
(and so does the quality of packages) - some of them are really bad, but you
have to remember that most people write packages in their free time and are not
programmers...
I iused the follwong code snippet:
switch( TYPEOF( filename_sexp ) )
{
case STRSXP: filename = CHAR( STRING_ELT(filename_sexp, 0) );
break;
default: error(filename argument must be a string);
break;
}
Here, filename is of type char*
and one function opens a file with that name.
So it is purely intended to just grab out the char* from the
String-Expression.
Am I doing something wrong here, or is it ok, but I have somehow
to say the extracting macros/functions, that it is really intended
to throw away information and that a warning is not necessary?
The result of calling CHAR should be a const char *. You are
not allowed to touch the string it points to.
Note too that isString() exists for this purpose,
[...]
OK, I also sometimes used that (maybe I threw it out or used it in other
modules).
and there is no
check in that code that LENGTH(filename_sexp) 0 (or == 1). In the
R sources you will often see things like
if(!isString(sfile) || LENGTH(sfile) 1)
error(invalid '%s' argument, description);
[...]
If it's a vector, I can just pic the first element.
Yes, but only if it's not a vector of length zero - hence the necessary check.
Or does LENGTH(sfile) give the length of the string itself
(like strlen(3))?
No.
If the latter, then my file-opeing operation would faile with an error.
Of course I check if my fopen() gibves back NULL.
Then, reading on,
file = translateChar(STRING_ELT(sfile, 0));
translateChar is explained on page 120 of the extension writing do.
I'm not in this point of the documentation.
And I often need to look around, when I want to find a function,
as they are documented/explained somewhere during the flow of the text.
Something like a API description that is brief would help.
For example something like in the manuals of the OCaml language:
http://caml.inria.fr/pub/docs/manual-ocaml/libref/Pervasives.html
That's very brief.
Chapter 6 of the Writing R Extensions is rather in this style
and gives a good overview.
Something like that for the macros would be helpful.
for you cannot (in general) assume that the character vector passed
is in the native encoding.
I try to do some coercions (e.g. as.integer())
when I need integer in the C-code and then
in the C-part rigidly check on integer.
It's usually more efficient to use coerceVector() on the C side since that
guarantees no copy is made for matching types (this matters for passing data,
not so much for passing arguments). You can do either - check on R side or
check on C side, usually you don't need both (but you certainly can).
Cheers,
Simon
About the char-encodings I have not thought much.
Ciao,
Oliver
__
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] Reference Class error message: may be caused by lazy evaluation?
Dear All,
I came across an error message recently when constructing a reference class,
an example is attached below, it looks like only if I call a specific method
in advance, otherwise it cannot be found in defined method without using
.self, this make it difficulty that sometimes in my initialize method, I
need to call other method defined in the same reference class, the
workaround for this is add .sef to it.
### example begin
setRefClass(testclass, fields = list(a = numeric),
methods = list(
addOne = function(){
a - a+1
print(a)
},
add = function(){
addOne()
},
show = function(){
print(addOne)
},
showself = function(){
print(.self$addOne)
}
))
obj - new(testclass, a = 1)
obj$show() #
Error in print(addOne) : object 'addOne' not found
obj$addOne() #
return 2, works
obj$show() #
after calling addOne(), show() works
## works if use .self$...
obj2 - new(testclass, a = 1)
obj2$showself()
## works when call the method directly within another method
obj3 - new(testclass, a = 1)
obj3$add()
end ##
I am still learning this new technique, if I made any mistake I didn't
notice before, please let me know, I will really appreciate that.
Thanks a lot!
Tengfei
--
Tengfei Yin
MCDB PhD student
1620 Howe Hall, 2274,
Iowa State University
Ames, IA,50011-2274
Homepage: www.tengfei.name
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Ctrl-C of functions that allocated mem
Hello, what happens, when a function (R-extension in C), that allocated memory (strdup(), malloc()/calloc() and so on), and is used in interactive mode, then will be stopped via Ctrl-C? I would assume that there remains allocated memory, which is not usable and also not accessable (hence no way to free it). Are there any mechanisms in R that could help in rolling back the allocation? Normally in an interactive session some memory might not be a problem, because it will be run shortly; but I prefer clean solutions. And also, if it's much mem, which is allocated each time, and one does many trials and Ctr-C's, even an interactive session might eat a lot of mem. So I would be interested in a solution to this (potential) problem. Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] warning: assignment discards qualifiers from pointer target type
On Wed, Jun 08, 2011 at 02:23:29PM -0400, Simon Urbanek wrote: On Jun 8, 2011, at 12:08 PM, oliver wrote: On Wed, Jun 08, 2011 at 12:22:10PM +0100, Prof Brian Ripley wrote: On Tue, 7 Jun 2011, Duncan Murdoch wrote: On 07/06/2011 9:08 AM, oliver wrote: Hello, following an advice here from the list I looked into sources of other packages (xts) and found the TYPEOF() macro/function, which really is helpful. It is documented, of course, but actually better alternatives are described in 'Writing R Extensions'. We would urge you to study the R sources rather than copy bad habits from randomly chosen package sources. [...] Hmhh, it was not randomly chosen, it was, what I got as a hint here on the list. It was not provided to you to look at how it checks arguments. For basic usage it's better to look at the R code. The coding styles vary a lot in packages (and so does the quality of packages) - some of them are really bad, but you have to remember that most people write packages in their free time and are not programmers... OK, I see. [...] and there is no check in that code that LENGTH(filename_sexp) 0 (or == 1). In the R sources you will often see things like if(!isString(sfile) || LENGTH(sfile) 1) error(invalid '%s' argument, description); [...] If it's a vector, I can just pic the first element. Yes, but only if it's not a vector of length zero - hence the necessary check. Or does LENGTH(sfile) give the length of the string itself (like strlen(3))? No. [...] OK, I looked at this now. LENGTH() checks the length of the vector. Good to know this. So the problem of a vector of length 0 can be with any arguments of type SEXP, hence I will need to check ANY arg on it's length. This is vital to stability under any situation. Thanks for this valuable hint! I will add checks for all my SEXP-args. Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] warning: assignment discards qualifiers from pointer target type
On Thu, Jun 09, 2011 at 02:17:31AM +0200, oliver wrote: [...] OK, I looked at this now. LENGTH() checks the length of the vector. Good to know this. So the problem of a vector of length 0 can be with any arguments of type SEXP, hence I will need to check ANY arg on it's length. This is vital to stability under any situation. Thanks for this valuable hint! I will add checks for all my SEXP-args. [...] Hey, LENGTH() does not work with String-vectors! :( Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] warning: assignment discards qualifiers from pointer target type
On Jun 8, 2011, at 8:32 PM, oliver wrote: On Thu, Jun 09, 2011 at 02:17:31AM +0200, oliver wrote: [...] OK, I looked at this now. LENGTH() checks the length of the vector. Good to know this. So the problem of a vector of length 0 can be with any arguments of type SEXP, hence I will need to check ANY arg on it's length. This is vital to stability under any situation. Thanks for this valuable hint! I will add checks for all my SEXP-args. [...] Hey, LENGTH() does not work with String-vectors! :( Of course it does ... __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] warning: assignment discards qualifiers from pointer target type
On Wed, Jun 8, 2011 at 7:17 PM, oliver oli...@first.in-berlin.de wrote: On Wed, Jun 08, 2011 at 02:23:29PM -0400, Simon Urbanek wrote: On Jun 8, 2011, at 12:08 PM, oliver wrote: On Wed, Jun 08, 2011 at 12:22:10PM +0100, Prof Brian Ripley wrote: On Tue, 7 Jun 2011, Duncan Murdoch wrote: On 07/06/2011 9:08 AM, oliver wrote: Hello, following an advice here from the list I looked into sources of other packages (xts) and found the TYPEOF() macro/function, which really is helpful. It is documented, of course, but actually better alternatives are described in 'Writing R Extensions'. We would urge you to study the R sources rather than copy bad habits from randomly chosen package sources. [...] Hmhh, it was not randomly chosen, it was, what I got as a hint here on the list. It was not provided to you to look at how it checks arguments. For basic usage it's better to look at the R code. The coding styles vary a lot in packages (and so does the quality of packages) - some of them are really bad, but you have to remember that most people write packages in their free time and are not programmers... OK, I see. Of course - most of R core aren't programmers either - whatever that means. Statisticians, mathematicians, etc... ;-) Most contributed packages aren't meant to be case studies in a comp-sci class either, they are meant to solve real world problems - problems that many of us work on daily. That said, I'd also say look to R sources first, but since many things in R core aren't available in the API - you aren't really able to copy the 'best practices' alluded to. And sometimes you've got to bootstrap solutions when the list is otherwise silent. Another reason that you should look outside of R sources in addition to inside of them is that the community code is far more abundant that the core code. Sort of like theory vs. practice - they only teach so much in school. For reference, TYPEOF is straight from R source (of course): http://svn.r-project.org/R/trunk/src/main/subset.c Cheers, Jeff [...] and there is no check in that code that LENGTH(filename_sexp) 0 (or == 1). In the R sources you will often see things like if(!isString(sfile) || LENGTH(sfile) 1) error(invalid '%s' argument, description); [...] If it's a vector, I can just pic the first element. Yes, but only if it's not a vector of length zero - hence the necessary check. Or does LENGTH(sfile) give the length of the string itself (like strlen(3))? No. [...] OK, I looked at this now. LENGTH() checks the length of the vector. Good to know this. So the problem of a vector of length 0 can be with any arguments of type SEXP, hence I will need to check ANY arg on it's length. This is vital to stability under any situation. Thanks for this valuable hint! I will add checks for all my SEXP-args. Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
