Re: [Rd] broken link to new features in R-devel: no NEWS file
Please report problems with websites to the webmaster: no one else can handle them. I believe that for CRAN the appropriate address is cran-ad...@r-project.org. On Wed, 21 Jul 2010, mark.braving...@csiro.au wrote: Hi The link from CRAN to new features in R-devel hasn't been working for a few days. Specifically, there is no NEWS file in https://svn.r-project.org/R/trunk/, though there is an ONEWS. The link is in the Source code for all platforms subwindow, where it says: Daily snapshots of current patched and development versions are available here. Please read about new features and bug fixes before filing corresponding feature requests or bug reports. Mark -- Mark Bravington CSIRO Mathematical Information Sciences Marine Laboratory Castray Esplanade Hobart 7001 TAS ph (+61) 3 6232 5118 fax (+61) 3 6232 5012 mob (+61) 438 315 623 __ 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] Package RPostgreSQL_0.1-6.tar.gz has been checked and built
AFAIK, you simply need to put the path to the correct pg_config first in your path -- depending how the PostgreSQL installation was done you may also need to ensure that its libraries are in your LD_LIBRARY_PATH. Given that this is the third query you have sent to the R lists about contributed packages, I think you should consider if you really need 64-bit R. 32-bit R is simpler to get working on most platforms, including Solaris, especially with external software. I am presuming (from the 'bin/amd64') that this is an Opteron/Xeon system, and there 64-bit software is problematic simply because gcc does not seem to work well. (Most often the 'particular errors' are not with Solaris but with non-standard conformant code written assuming gcc extensions or laxities -- for which the fix is often to use gcc.) And BTW, you keep on saying 'Solaris 10u7 X64' and I've no idea what that is. The 'at a minimum' information asked for in the posting guide will give a correct description. Solaris has come for many years as a 32/64-bit OS, and there is i386 Solaris and Sparc Solaris. On Wed, 21 Jul 2010, Amber wrote: Hi Dirk I think there are problems with pg_config, the configure script of RPostgreSQL checks for pg_config and got ??checking for pg_config... /usr/bin/pg_config??. In Solaris 10u7 X64, three versions of PostgreSQL are installed, there are in /usr/postgres/8.2(8.2.9) and /usr/postgres/8.3(8.3.3), the corresponding bin files are in /usr/postgres/version/bin and /usr/postgres/version/bin/amd64, and the libraries in /usr/bin is 8.1.11 and it seems a 32bit one, and I can??t find the 64bit version bins for 8.1.11. I'll try uninstall 8.1.11 and install 8.2.9, and my question is how to let RPostgreSQL configure script find the 64bit pg_config. Xiaobo Gu On Tue, Jul 20, 2010 at 10:32 PM, ?? guxiaobo1...@gmail.com wrote: Hi Dirk, I think this discussion should help : http://stackoverflow.com/questions/1836333/how-can-i-compile-64-bit-postgres-bindings-for-perl-on-solaris, are there environment variables I can set to point to 64bit libraries, or I can set the 64bit libraries path /usr/local/psql/lib before /usr/lib, I'll let you know the results tomorrow. Xiaobo.Gu -Original Message- From: Dirk Eddelbuettel [mailto:e...@debian.org] Sent: Tuesday, July 20, 2010 7:11 PM To: Amber Cc: Dirk Eddelbuettel; Uwe Ligges Subject: Re: Package RPostgreSQL_0.1-6.tar.gz has been checked and built Hi Amber, I'm at the useR conference with imperfect connectivity adn can't help much. I also noticed that Solaris often comes up with particular errors -- see Prof Ripley's response to your Rattle query. RPostgresql may be easy to get built, but you may have to adapt configure.in. On 20 July 2010 at 14:08, Amber wrote: | Hi Dirk, | There are problems building RPostgreSQL on 64bit solaris, | The server has preinstalled PostgreSQL 8.1 client and server binaries , and | we also installed Greenplum SNE 3.3.5.0 server and client installed, but the | postgres user, which I used to build R and RPostgreSQL can't see Greenplum | binaries, the error messages are: | | -bash-3.00$ R CMD INSTALL RPostgreSQL | * installing to library '/opt/R/R2-11-1/lib/R/library' | * installing *source* package 'RPostgreSQL' ... | checking for gcc... /opt/sunstudio12.1/bin/cc -m64 | checking for C compiler default output file name... a.out | checking whether the C compiler works... yes | checking whether we are cross compiling... no | checking for suffix of executables... | checking for suffix of object files... o | checking whether we are using the GNU C compiler... no | checking whether /opt/sunstudio12.1/bin/cc -m64 accepts -g... yes | checking for /opt/sunstudio12.1/bin/cc -m64 option to accept ISO C89... none | needed | checking for pg_config... /usr/bin/pg_config | checking for /usr/include/pgsql/libpq-fe.h... yes Good! | configure: creating ./config.status | config.status: creating src/Makevars | ** libs | /opt/sunstudio12.1/bin/cc -m64 -xc99=all -G -L/opt/R/R2-11-1/lib | -L/usr/sfw/lib/amd64 -L/usr/lib/amd64 -L/opt/sfw/lib -o RPostgreSQL.so | RS-DBI.o RS-PostgreSQL.o -L/usr/lib -lpq | ld: fatal: file /usr/lib/libpq.so: wrong ELF class: ELFCLASS32 | ld: fatal: File processing errors. No output written to RPostgreSQL.so The linker complained about bad objkect files. Looks like you have a wrong or mismatched Pg library. We'd have to fix that first before RPostgreSQL can be built. Also ask Greenplum if they can help. At least they get paid for this :) Dirk | *** Error code 1 | The following command caused the error: | if test zRS-DBI.o RS-PostgreSQL.o != z; then \ | echo /opt/sunstudio12.1/bin/cc -m64 -xc99=all -G -L/opt/R/R2-11-1/lib | -L/usr/sfw/lib/amd64 -L/usr/lib/amd64 -L/opt/sfw/lib -o RPostgreSQL.so | RS-DBI.o RS-PostgreSQL.o -L/usr/lib -lpq ; \ | /opt/sunstudio12.1/bin/cc -m64 -xc99=all -G -L/opt/R/R2-11-1/lib | -L/usr/sfw/lib/amd64 -L/usr/lib/amd64 -L/opt/sfw/lib -o RPostgreSQL.so
[Rd] Possible reasons for segmentation fault
Hi, I have a written a C code for R and used R CMD SHLIB to compile it. However, it returns segmentation fault on some 64 bits machines. What are some of the potential reasons for this? Thanks for the help/advice on the matter. Best regards, stan [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible reasons for segmentation fault
On Tue, 20 Jul 2010, Chuen Tan wrote: Hi, I have a written a C code for R and used R CMD SHLIB to compile it. However, it returns segmentation fault on some 64 bits machines. What is 'it'? I presume you may mean trying to use the compiled code in R, but what you wrote suggests SHLIB segfaulted -- this almost always indicates a compiler bug. What are some of the potential reasons for this? User error - the scope is vast. Thanks for the help/advice on the matter. Read the posting guide (as you sent HTML, we know you haven't -- and if you had you would know that we need to know what platform you use) and then 'Writing R Extensions' chapter 4. Best regards, stan [[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] Package RPostgreSQL_0.1-6.tar.gz has been checked and built
Thanks Professor Brain Ripley and Dirk, I have successfully INSTALLED RPostgreSQL on Solaris 10 update 7 i386 64bit version. The detailed procedure is as following: 1. Delete the preinstalled 8.1.11 packagegs, which are all 32 bit. 2. Add /usr/postgres/8.3/bin/amd64 to PATH so that configure can find the 64bit pg_config 3. Add /usr/postgres/8.3/lib/amd64 to LD_LIBRARY_PATH as you mentioned. Now I can connect to Greenplum SNE 3.3.5.0 backend and use dbGetQuery fetching data. Xiaobo Gu On Wed, Jul 21, 2010 at 3:04 PM, Prof Brian Ripley rip...@stats.ox.ac.ukwrote: AFAIK, you simply need to put the path to the correct pg_config first in your path -- depending how the PostgreSQL installation was done you may also need to ensure that its libraries are in your LD_LIBRARY_PATH. Given that this is the third query you have sent to the R lists about contributed packages, I think you should consider if you really need 64-bit R. 32-bit R is simpler to get working on most platforms, including Solaris, especially with external software. I am presuming (from the 'bin/amd64') that this is an Opteron/Xeon system, and there 64-bit software is problematic simply because gcc does not seem to work well. (Most often the 'particular errors' are not with Solaris but with non-standard conformant code written assuming gcc extensions or laxities -- for which the fix is often to use gcc.) And BTW, you keep on saying 'Solaris 10u7 X64' and I've no idea what that is. The 'at a minimum' information asked for in the posting guide will give a correct description. Solaris has come for many years as a 32/64-bit OS, and there is i386 Solaris and Sparc Solaris. On Wed, 21 Jul 2010, Amber wrote: Hi Dirk I think there are problems with pg_config, the configure script of RPostgreSQL checks for pg_config and got ??checking for pg_config... /usr/bin/pg_config??. In Solaris 10u7 X64, three versions of PostgreSQL are installed, there are in /usr/postgres/8.2(8.2.9) and /usr/postgres/8.3(8.3.3), the corresponding bin files are in /usr/postgres/version/bin and /usr/postgres/version/bin/amd64, and the libraries in /usr/bin is 8.1.11 and it seems a 32bit one, and I can??t find the 64bit version bins for 8.1.11. I'll try uninstall 8.1.11 and install 8.2.9, and my question is how to let RPostgreSQL configure script find the 64bit pg_config. Xiaobo Gu On Tue, Jul 20, 2010 at 10:32 PM, ?? guxiaobo1...@gmail.com wrote: Hi Dirk, I think this discussion should help : http://stackoverflow.com/questions/1836333/how-can-i-compile-64-bit-postgres-bindings-for-perl-on-solaris , are there environment variables I can set to point to 64bit libraries, or I can set the 64bit libraries path /usr/local/psql/lib before /usr/lib, I'll let you know the results tomorrow. Xiaobo.Gu -Original Message- From: Dirk Eddelbuettel [mailto:e...@debian.org] Sent: Tuesday, July 20, 2010 7:11 PM To: Amber Cc: Dirk Eddelbuettel; Uwe Ligges Subject: Re: Package RPostgreSQL_0.1-6.tar.gz has been checked and built Hi Amber, I'm at the useR conference with imperfect connectivity adn can't help much. I also noticed that Solaris often comes up with particular errors -- see Prof Ripley's response to your Rattle query. RPostgresql may be easy to get built, but you may have to adapt configure.in. On 20 July 2010 at 14:08, Amber wrote: | Hi Dirk, | There are problems building RPostgreSQL on 64bit solaris, | The server has preinstalled PostgreSQL 8.1 client and server binaries , and | we also installed Greenplum SNE 3.3.5.0 server and client installed, but the | postgres user, which I used to build R and RPostgreSQL can't see Greenplum | binaries, the error messages are: | | -bash-3.00$ R CMD INSTALL RPostgreSQL | * installing to library '/opt/R/R2-11-1/lib/R/library' | * installing *source* package 'RPostgreSQL' ... | checking for gcc... /opt/sunstudio12.1/bin/cc -m64 | checking for C compiler default output file name... a.out | checking whether the C compiler works... yes | checking whether we are cross compiling... no | checking for suffix of executables... | checking for suffix of object files... o | checking whether we are using the GNU C compiler... no | checking whether /opt/sunstudio12.1/bin/cc -m64 accepts -g... yes | checking for /opt/sunstudio12.1/bin/cc -m64 option to accept ISO C89... none | needed | checking for pg_config... /usr/bin/pg_config | checking for /usr/include/pgsql/libpq-fe.h... yes Good! | configure: creating ./config.status | config.status: creating src/Makevars | ** libs | /opt/sunstudio12.1/bin/cc -m64 -xc99=all -G -L/opt/R/R2-11-1/lib | -L/usr/sfw/lib/amd64 -L/usr/lib/amd64 -L/opt/sfw/lib -o RPostgreSQL.so | RS-DBI.o RS-PostgreSQL.o -L/usr/lib -lpq | ld: fatal: file /usr/lib/libpq.so: wrong ELF class: ELFCLASS32 | ld: fatal: File processing errors. No output written to RPostgreSQL.so The linker complained about bad
[Rd] Bug: broken exception handling in S4 methods
Hi all:
we have noticed for quite a while that certain errors cannot be handled
by R try, tryCatch etc blocks, but it was fairly difficult to understand
what were the conditions for this incorrect behaviour. Finally I stabbed
across a very understandable case, which is outlined in the (runnable)
example below.
The main message is: wrapping an S4 method call in a try block will not
help if an error occurs in evaluating an argument to such a call; this
works just fine for function calls (as opposed to S4 methods)
The particular example is a result of trying to write a unit test for a
constructor of a class object which should fail under certain
conditions. This failure obviously need to be caught for the unit test
to proceed. However, it is a general problem with handling some
exceptions in R.
# Consider a simple class MyClassA, which is derived from numeric and
for which
# we define a constructor (in form of a method). On its own this class
works nicely
# and so does exception handling of it:
setClass(MyClassA,
contains = numeric,
validity = function(object)
{
stopifnot(object[1] == object[2])
TRUE
}
)
setGeneric(MyClassA, function(x) standardGeneric(MyClassA))
setMethod(MyClassA,
signature(x = numeric),
function(x)
{
new(MyClassA, x)
}
)
## OK
er = try({ MyClassA(c(1,2)) })
## OK (error in constructor)
er = try({ MyClassA(c(1,2)) })
## OK (error evaluating argument to a function)
er = try({ sin(MyClassA(c(1,2))) })
# Now consider we define MyClassB that has MyClassA in a slot
# and we define a constructor that takes such objects:
setClassUnion(MyClassAOrNULL, c(MyClassA, NULL))
setClass(MyClassB,
representation(
ca = MyClassAOrNULL
),
prototype(ca = NULL)
)
setGeneric(MyClassB, function(x) standardGeneric(MyClassB))
setMethod(MyClassB,
signature(x = MyClassA),
function(x)
{
new(MyClassB, ca = x)
}
)
## OK
b = MyClassB(MyClassA(c(1,1)))
## FAILS (error evaluating argument to a method)
er = try({ MyClassB(MyClassA(c(1,2))) })
# As you see the last error cannot be handled
# Moreover. If we define a function and a method as function(x) x then
# the function can be handled by try, yet the method cannot:
f = function(x) x
setGeneric(g, function(x) standardGeneric(g))
setMethod(g, MyClassA, function(x) x)
## OK (error evaluating argument to a function)
er = try({ f(MyClassA(c(1,2))) })
## FAILS (error evaluating argument to a method)
er = try({ g(MyClassA(c(1,2))) })
sessionInfo()
R version 2.11.0 Patched (2010-05-05 r51914)
x86_64-unknown-linux-gnu
locale:
[1] LC_CTYPE=en_GB LC_NUMERIC=C LC_TIME=en_GB
LC_COLLATE=en_GB
[5] LC_MONETARY=CLC_MESSAGES=en_GBLC_PAPER=en_GB
LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C LC_MEASUREMENT=en_GB
LC_IDENTIFICATION=C
attached base packages:
[1] splines stats graphics utils datasets grDevices methods
base
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3803
oskl...@ahl.com
**
Please consider the environment before printing this email or its attachments.
The contents of this email are for the named addressees ...{{dropped:19}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Table vs unique
A bug in the survival routines was reported to me today. The root cause is a difference between table, unique, and sort. temp - rep(c(1, sqrt(2)^2, 2), 1:3) unique(temp) [1] 1 2 2 table(temp) temp 1 2 1 5 I'm using 2.10 on Linux, the user reported from 2.9 on Windows. 1. Minor issue: I think the root rounding occurs in factor. I didn't see any discussion of this in the help page, perhaps something should be added. 2. The error popped up in summary.survfit but the root cause is an inconsistent survfit object. The survfit routine uses sort and unique to create the unique survival times and most of the output, but table to count them for another component. Lumping the two versions of 2. together is the preferable output. I think the best solution will be to preprocess the time variable so that the three operators are consistent. as.numeric(as.character(as.factor(time))) ? Rather ugly. But most importantly what is a guarranteed construct that would ensure consistency? Should we use a rounding level that is more or less equivalent to all.equal()? The solution will have to be incorporated into survfit, coxph, ... perhaps a dozen places in the survival suite so I'd like to get it right the first time. Terry T __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Use of ‘.C’ for C++ is now deprecate d and will be removed in R 2.12.0
Please don't pick things out of context. It does not say .C() is deprecated and it is not talking about R code: it says There are default variables and rules for this (determined when R is configured and recorded in R_HOME/etcR_ARCH/Makeconf), providing support for C, C++, FORTRAN 77, Fortran 9x, Objective C and Objective C++ with associated extensions .c, .cc or .cpp, .f, .f90 or .f95, .m, and .mm or .M, respectively. We recommend using .h for headers, also for C++ or Fortran 9x include files. (Use of .C for C++ is now deprecated and will be removed in R 2.12.0.) You missed 'associated extensions', and that the NEWS file says o Use of file extension .C for C++ code in packages is now deprecated: it has caused problems for some 'make's on case-insensitive file systems (although it currently works with the recommended toolkits). On Wed, 21 Jul 2010, Florian Breitwieser wrote: Hi, I am writing a R package and having a bit of trouble to have the C++ code working. I was planing using the .C interface function, however I found the comment (Use of ‘.C’ for C++ is now deprecated and will be removed in R 2.12.0.) in the R-exts manual. So this interface function should not be used anymore - .Call() or Rcpp instead? What is the reason for the deprecation? Thanks, Florian __ 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] Table vs unique
I believe this is a misdiagnosis: the 'rounding' is done by as.character (as the help for argument 'levels' in ?factor does say) and ?as.character has a full explanation (and is linked from the relevant part of ?factor). as.numeric(as.character()) should do the trick. On Wed, 21 Jul 2010, Terry Therneau wrote: A bug in the survival routines was reported to me today. The root cause is a difference between table, unique, and sort. temp - rep(c(1, sqrt(2)^2, 2), 1:3) unique(temp) [1] 1 2 2 table(temp) temp 1 2 1 5 I'm using 2.10 on Linux, the user reported from 2.9 on Windows. 1. Minor issue: I think the root rounding occurs in factor. I didn't see any discussion of this in the help page, perhaps something should be added. 2. The error popped up in summary.survfit but the root cause is an inconsistent survfit object. The survfit routine uses sort and unique to create the unique survival times and most of the output, but table to count them for another component. Lumping the two versions of 2. together is the preferable output. I think the best solution will be to preprocess the time variable so that the three operators are consistent. as.numeric(as.character(as.factor(time))) ? Rather ugly. But most importantly what is a guarranteed construct that would ensure consistency? Should we use a rounding level that is more or less equivalent to all.equal()? The solution will have to be incorporated into survfit, coxph, ... perhaps a dozen places in the survival suite so I'd like to get it right the first time. Terry T __ 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
[Rd] tcltk resizing when using tkgrid for layout
I've been able to figure out on my own how to do what I need in the largely undocumented tcltk package, but I've finally hit a wall. I can't even think of any sufficiently specific search terms to use for this. I'm trying to make the widgets in my tk window resize when the window is resized by clicking and dragging on its corners or edges. Instead they stay exactly where they are, and parts of them get cut off when the window is made smaller and reveal large empty spaces when the windows is made bigger. Looks terrible. I've tried doing tkconfig(mywidget,sticky='news') and all that does is stretch the widget out to the original window dimensions, but this doesn't help at all when the window is resized. From reading the TclTK documentation, it seems like the 'rowconfigure' and 'columnconfigure' methods of the grid are supposed to solve this problem by setting the 'weight' grid option. There exists a tkgrid.rowconfigure() command and the following invocation did not produce any errors... tkgrid.rowconfigure(mywidget,0,weight=1) ...but it didn't make the widget dynamically resize with the parent window either. Either I'm invoking it incorrectly, or it doesn't actually do what I think it does. Rather than posting my lengthy and complicated code, I'll post this example instead from bioinf.wehi.edu.au/~wettenhall/RTclTkExamples/ (a very helpful site without which I would never have been able to use the tcltk package at all). require(tcltk) tt- tktoplevel() xscr- tkscrollbar(tt, repeatinterval=5,orient=horizontal, command=function(...)tkxview(txt,...)) yscr- tkscrollbar(tt, repeatinterval=5, command=function(...)tkyview(txt,...)) txt- tktext(tt,bg=white,font=courier, xscrollcommand=function(...)tkset(xscr,...),yscrollcommand=function(...)tkset(yscr,...), wrap=none) tkgrid(txt,yscr) tkgrid(xscr) tkgrid.configure(yscr,sticky=ns) tkgrid.configure(xscr,sticky=ew) for (i in (1:100)) tkinsert(txt,end,paste(i,^ 2 =,i*i,, )) tkconfigure(txt, state=disabled) tkfocus(txt) This creates a scrollable text window, and it suffers from exactly the problem I described above. My question is: what needs to be changed in order to make the tktext widget and its scrollbars automatically resize with the parent window? Thank you. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Plot window does not update in embedded code
Dear list,
I am trying to embed R into a C++ program. After some tinkering,
reading the documentation and browsing the source code I have this
more or less working. A very very condensed and very simplified
version of the code is included below.
The program can create plots. However, after the plot is initially
drawn it is no longer updated. When scaling or updating the plot the
window becomes blank, and the window also doesn't want to close. I
suspect that my R_ReadConsole routine is the problem. This routine
waits for user input and returns this (which I thought it should). It
seems that this causes the event loop that updates the windows to also
be on hold. I did have a look at 'Rstd_ReadConsole' in
'src/unix/sys-std.c', but I can't figure out what exactly happens in
this routine.
How do I ensure that the windows keep being updated?
Presently I am working under Linux. However, I also want to be able to
run my code under windows, so I hope there is a cross-platform
solution. Thanks in advance.
Regards,
Jan van der Laan
= The example code =
#include iostream
#include iomanip
#include string
static void R_WriteConsoleEx (const char *buf, int buflen, int otype) {
std::string output(buf, buflen);
std::cout output;
}
static void R_WriteConsole (const char *buf, int buflen) {
R_WriteConsoleEx(buf, buflen, 0);
}
static int R_ReadConsole (const char *prompt, unsigned char *buf, int
buflen, int hist) {
std::cout prompt;
std::string input;
std::cin input;
for (unsigned int i = 0; i input.length(); ++i) {
buf[i] = input[i];
buf[i+1] = '\n';
buf[i+2] = '\0';
if ((int)i = buflen-3) break;
}
return input.length();
}
extern C {
#define R_INTERFACE_PTRS
#include Rinterface.h
int Rf_initialize_R(int ac, char **av); /* in ../unix/system.c */
extern int R_running_as_main_program; /* in ../unix/system.c */
}
int main(int ac, char **av)
{
R_running_as_main_program = 1;
Rf_initialize_R(ac, av);
ptr_R_WriteConsoleEx = R_WriteConsoleEx;
ptr_R_WriteConsole = R_WriteConsole;
ptr_R_ReadConsole = R_ReadConsole;
R_Outputfile = NULL;
R_Consolefile = NULL;
Rf_mainloop(); /* does not return */
return 0;
}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tcltk resizing when using tkgrid for layout
On 07/21/2010 09:36 AM, Alex Bokov wrote: I've been able to figure out on my own how to do what I need in the largely undocumented tcltk package, but I've finally hit a wall. I can't even think of any sufficiently specific search terms to use for this. Oops. Murphy's Law-- the answer only comes to you after you already send off an email to the experts. Sorry to bother you, I figured it out already. Here's how to make the code example I posted earlier... require(tcltk) tt- tktoplevel() xscr- tkscrollbar(tt, repeatinterval=5,orient=horizontal, command=function(...)tkxview(txt,...)) yscr- tkscrollbar(tt, repeatinterval=5, command=function(...)tkyview(txt,...)) txt- tktext(tt,bg=white,font=courier, xscrollcommand=function(...)tkset(xscr,...),yscrollcommand=function(...)tkset(yscr,...), wrap=none) tkgrid(txt,yscr) tkgrid(xscr) tkgrid.configure(yscr,sticky=ns) tkgrid.configure(xscr,sticky=ew) for (i in (1:100)) tkinsert(txt,end,paste(i,^ 2 =,i*i,, )) tkconfigure(txt, state=disabled) tkfocus(txt) ...resize dynamically. All I had to do was add the following lines to the end of it: tkgrid.columnconfigure(tt,0,weight=1) tkgrid.rowconfigure(tt,0,weight=1) tkgrid.rowconfigure(txt,0,weight=1) tkgrid.columnconfigure(txt,0,weight=1) tkgrid.configure(txt,sticky='nswe') I had been so close before, I just didn't realize that if you have a complicated frame structure enclosing the widget, then the weight needs to be set on every enclosing frame, not just the widget itself. The hard part is figuring out which row and column a column-spanning widget really belongs to-- so far it seems to belong to the left-most and top-most one. Anyway, thanks to anybody who was going to answer this, hopefully I'm sending this soon enough to save you the effort of composing a reply. Have a great day! [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Extract callNextMethod array calls matrix?
There does indeed seem to be a bug in the C code that implements callNextMethod, with the effect of adding a spurious index to calls to the primitive `[` code with more than 2 subscripts. The message incorrect number of dimensions is telling the truth, the primitive code gets 4 subscripts instead of 3 (note the x[i = i, j = j, NULL, ...] in the error message). Given the time of year, meetings, and the obscurity of this piece of code, the bug won't likely be fixed soon, so any workaround that avoids the use of callNextMethod on `[` with 3 or more subscripts is a good idea. On 7/20/10 1:41 PM, Daniel Murphy wrote: I have a class that extends array and my method for [ stops with an error: setClass(A, contains=array) [1] A setMethod([, A, function(x, i, j, ..., drop = TRUE) new(A, callNextMethod())) [1] [ a-new(A,array(1:12,c(4,3,1))) a An object of class A , , 1 [,1] [,2] [,3] [1,]159 [2,]26 10 [3,]37 11 [4,]48 12 a[1:2,2:3,1] Error in x[i = i, j = j, NULL, ...] : incorrect number of dimensions Error in callNextMethod() : error in evaluating a 'primitive' next method A similar error does not occur when extending a matrix: setClass(M, contains=matrix) [1] M setMethod([, M, function(x, i, j, ..., drop = TRUE) new(M, callNextMethod())) [1] [ a-new(M,matrix(1:12,4,3)) a[1:2,2:3] An object of class M [,1] [,2] [1,]59 [2,]6 10 Is there a problem with my method definition for the array-extending class? My work-around is as follows: setMethod([, A, function(x, i, j, ..., drop = TRUE) new(A, `[`(as(x,array), i=i, j=j, ..., drop=drop))) [1] [ a[1:2,2:3,1] An object of class A [,1] [,2] [1,]59 [2,]6 10 Cheers, Dan [[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] Extract callNextMethod array calls matrix?
Thanks, John. Enjoy Gaithersburg! On Wed, Jul 21, 2010 at 8:58 AM, John Chambers j...@r-project.org wrote: There does indeed seem to be a bug in the C code that implements callNextMethod, with the effect of adding a spurious index to calls to the primitive `[` code with more than 2 subscripts. The message incorrect number of dimensions is telling the truth, the primitive code gets 4 subscripts instead of 3 (note the x[i = i, j = j, NULL, ...] in the error message). Given the time of year, meetings, and the obscurity of this piece of code, the bug won't likely be fixed soon, so any workaround that avoids the use of callNextMethod on `[` with 3 or more subscripts is a good idea. On 7/20/10 1:41 PM, Daniel Murphy wrote: I have a class that extends array and my method for [ stops with an error: setClass(A, contains=array) [1] A setMethod([, A, function(x, i, j, ..., drop = TRUE) new(A, callNextMethod())) [1] [ a-new(A,array(1:12,c(4,3,1))) a An object of class A , , 1 [,1] [,2] [,3] [1,]159 [2,]26 10 [3,]37 11 [4,]48 12 a[1:2,2:3,1] Error in x[i = i, j = j, NULL, ...] : incorrect number of dimensions Error in callNextMethod() : error in evaluating a 'primitive' next method A similar error does not occur when extending a matrix: setClass(M, contains=matrix) [1] M setMethod([, M, function(x, i, j, ..., drop = TRUE) new(M, callNextMethod())) [1] [ a-new(M,matrix(1:12,4,3)) a[1:2,2:3] An object of class M [,1] [,2] [1,]59 [2,]6 10 Is there a problem with my method definition for the array-extending class? My work-around is as follows: setMethod([, A, function(x, i, j, ..., drop = TRUE) new(A, `[`(as(x,array), i=i, j=j, ..., drop=drop))) [1] [ a[1:2,2:3,1] An object of class A [,1] [,2] [1,]59 [2,]6 10 Cheers, Dan [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Plot window does not update in embedded code
Hi,
On Wednesday 21 July 2010, Jan van der Laan wrote:
How do I ensure that the windows keep being updated?
in RKWard we run the following periodically during idle phases:
// this basically copied from R's unix/sys-std.c (Rstd_ReadConsole)
#ifndef Q_WS_WIN
for (;;) {
fd_set *what;
what = R_checkActivityEx(R_wait_usec 0 ? R_wait_usec : 50, 1,
Rf_onintr);
R_runHandlers(R_InputHandlers, what);
if (what == NULL) break;
}
/* This seems to be needed to make Rcmdr react to events. Has this
always
been the case? It was commented out for a long time, without anybody noticing.
*/
R_PolledEvents ();
#else
R_ProcessEvents();
#endif
Regards
Thomas
signature.asc
Description: This is a digitally signed message part.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Plot window does not update in embedded code
Use
R_CheckUserInterrupt()
The code below is very fragile and unix-specific.
Cheers,
Simon
On Jul 21, 2010, at 3:45 PM, Thomas Friedrichsmeier wrote:
Hi,
On Wednesday 21 July 2010, Jan van der Laan wrote:
How do I ensure that the windows keep being updated?
in RKWard we run the following periodically during idle phases:
// this basically copied from R's unix/sys-std.c (Rstd_ReadConsole)
#ifndef Q_WS_WIN
for (;;) {
fd_set *what;
what = R_checkActivityEx(R_wait_usec 0 ? R_wait_usec : 50, 1,
Rf_onintr);
R_runHandlers(R_InputHandlers, what);
if (what == NULL) break;
}
/* This seems to be needed to make Rcmdr react to events. Has this
always
been the case? It was commented out for a long time, without anybody
noticing.
*/
R_PolledEvents ();
#else
R_ProcessEvents();
#endif
Regards
Thomas
__
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] Plot window does not update in embedded code
On Jul 21, 2010, at 4:28 PM, Simon Urbanek wrote:
Use
R_CheckUserInterrupt()
Actually, the above is true but assumes that you're running R's REPL and not
your own R_ReadConsole (it will work even in your ReadConsole but unix handlers
are not run in that case so only some events will work).
The code below is very fragile and unix-specific.
That is true, too, but even after R_ProcessEvenrts refactorization the handlers
are still-unix specific so I stand corrected and you still have to run handlers
manually (note that you don't need PolledEvents anymore since they are part of
the handlers).
Cheers,
Simon
On Wednesday 21 July 2010, Jan van der Laan wrote:
How do I ensure that the windows keep being updated?
in RKWard we run the following periodically during idle phases:
// this basically copied from R's unix/sys-std.c (Rstd_ReadConsole)
#ifndef Q_WS_WIN
for (;;) {
fd_set *what;
what = R_checkActivityEx(R_wait_usec 0 ? R_wait_usec : 50, 1,
Rf_onintr);
R_runHandlers(R_InputHandlers, what);
if (what == NULL) break;
}
/* This seems to be needed to make Rcmdr react to events. Has this
always
been the case? It was commented out for a long time, without anybody
noticing.
*/
R_PolledEvents ();
#else
R_ProcessEvents();
#endif
Regards
Thomas
__
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] broken link to new features in R-devel: no NEWS file
Prof Brian Ripley rip...@stats.ox.ac.uk on Wed, 21 Jul 2010 07:27:58 +0100 (BST) writes: Please report problems with websites to the webmaster: no one else can handle them. I believe that for CRAN the appropriate address is cran-ad...@r-project.org. In addition, please let me note that one of the very oldest websites for R *developement* has been http://stat.ethz.ch/R-manual/ (used to be called R-alpha) it contains manuals of both R patched and R manual *and* direct links to the NEWS of both. One reason, I have not advertized this very long-living (and daily updated) web page is that it's really about *NON RELEASED* versions of R. Martin Maechler, ETH ZUrich On Wed, 21 Jul 2010, mark.braving...@csiro.au wrote: Hi The link from CRAN to new features in R-devel hasn't been working for a few days. Specifically, there is no NEWS file in https://svn.r-project.org/R/trunk/, though there is an ONEWS. The link is in the Source code for all platforms subwindow, where it says: Daily snapshots of current patched and development versions are available here. Please read about new features and bug fixes before filing corresponding feature requests or bug reports. Mark -- Mark Bravington CSIRO Mathematical Information Sciences Marine Laboratory Castray Esplanade Hobart 7001 TAS ph (+61) 3 6232 5118 fax (+61) 3 6232 5012 mob (+61) 438 315 623 __ 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, 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
Re: [Rd] Bug: broken exception handling in S4 methods
The problem in this example is (plausibly) that the argument evaluation
code in method selection itself uses an internal C-level version of
try(), overriding the user's setting.
If this is the bug, I'll have to defer to more expert advice on whether,
and if so how, the code can adjust for the current exception handling.
(There don't seem to be many uses of this R_try() mechanism.)
On 7/21/10 2:36 AM, Sklyar, Oleg (London) wrote:
Hi all:
we have noticed for quite a while that certain errors cannot be handled
by R try, tryCatch etc blocks, but it was fairly difficult to understand
what were the conditions for this incorrect behaviour. Finally I stabbed
across a very understandable case, which is outlined in the (runnable)
example below.
The main message is: wrapping an S4 method call in a try block will not
help if an error occurs in evaluating an argument to such a call; this
works just fine for function calls (as opposed to S4 methods)
The particular example is a result of trying to write a unit test for a
constructor of a class object which should fail under certain
conditions. This failure obviously need to be caught for the unit test
to proceed. However, it is a general problem with handling some
exceptions in R.
# Consider a simple class MyClassA, which is derived from numeric and
for which
# we define a constructor (in form of a method). On its own this class
works nicely
# and so does exception handling of it:
setClass(MyClassA,
contains = numeric,
validity = function(object)
{
stopifnot(object[1] == object[2])
TRUE
}
)
setGeneric(MyClassA, function(x) standardGeneric(MyClassA))
setMethod(MyClassA,
signature(x = numeric),
function(x)
{
new(MyClassA, x)
}
)
## OK
er = try({ MyClassA(c(1,2)) })
## OK (error in constructor)
er = try({ MyClassA(c(1,2)) })
## OK (error evaluating argument to a function)
er = try({ sin(MyClassA(c(1,2))) })
# Now consider we define MyClassB that has MyClassA in a slot
# and we define a constructor that takes such objects:
setClassUnion(MyClassAOrNULL, c(MyClassA, NULL))
setClass(MyClassB,
representation(
ca = MyClassAOrNULL
),
prototype(ca = NULL)
)
setGeneric(MyClassB, function(x) standardGeneric(MyClassB))
setMethod(MyClassB,
signature(x = MyClassA),
function(x)
{
new(MyClassB, ca = x)
}
)
## OK
b = MyClassB(MyClassA(c(1,1)))
## FAILS (error evaluating argument to a method)
er = try({ MyClassB(MyClassA(c(1,2))) })
# As you see the last error cannot be handled
# Moreover. If we define a function and a method as function(x) x then
# the function can be handled by try, yet the method cannot:
f = function(x) x
setGeneric(g, function(x) standardGeneric(g))
setMethod(g, MyClassA, function(x) x)
## OK (error evaluating argument to a function)
er = try({ f(MyClassA(c(1,2))) })
## FAILS (error evaluating argument to a method)
er = try({ g(MyClassA(c(1,2))) })
sessionInfo()
R version 2.11.0 Patched (2010-05-05 r51914)
x86_64-unknown-linux-gnu
locale:
[1] LC_CTYPE=en_GB LC_NUMERIC=C LC_TIME=en_GB
LC_COLLATE=en_GB
[5] LC_MONETARY=CLC_MESSAGES=en_GBLC_PAPER=en_GB
LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C LC_MEASUREMENT=en_GB
LC_IDENTIFICATION=C
attached base packages:
[1] splines stats graphics utils datasets grDevices methods
base
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3803
oskl...@ahl.com
**
Please consider the environment before printing this email or its attachments.
The contents of this email are for the named addressees ...{{dropped:19}}
__
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] broken link to new features in R-devel: no NEWS file
Prof Brian Ripley rip...@stats.ox.ac.uk on Wed, 21 Jul 2010 07:27:58 +0100 (BST) writes: Please report problems with websites to the webmaster: no one else can handle them. I believe that for CRAN the appropriate address is cran-ad...@r-project.org. In addition, please let me note that one of the very oldest websites for R *developement* has been http://stat.ethz.ch/R-manual/ (used to be called R-alpha) it contains manuals of both R patched and R manual *and* direct links to the NEWS of both. Original problem now fixed on CRAN. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Use of ‘.C’ for C++ is now depreca ted and will be removed in R 2.12.0
Hi Florian, You could try the Rcpp package for the interface. It works pretty well for me. Cheers, Yi On Wed, Jul 21, 2010 at 10:24 PM, Florian Breitwieser florian...@gmail.comwrote: Hi, I am writing a R package and having a bit of trouble to have the C++ code working. I was planing using the .C interface function, however I found the comment (Use of .C for C++ is now deprecated and will be removed in R 2.12.0.) in the R-exts manual. So this interface function should not be used anymore - .Call() or Rcpp instead? What is the reason for the deprecation? Thanks, Florian __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
