[Rd] IDE for R C++ package writing ?
Dear all, I have to develop a (hopefully) small package for R in C++. I didn't code in C++ for some years, and i'm now searching for an adequate IDE for this task. Some of my criterions : not proprietary, not too heavy, open to linux, not java gasworks, still maintained, etc After looking on several places http://en.wikipedia.org/wiki/List_of_C%2B%2B_compilers_and_integrated_development_environments http://www.freeprogrammingresources.com/cppide.html + R docs I was thinking on code::blocks, and emacs (and perhaps vim) Emacs seems used by some R developers as an R editor. So i did think on emacs because it could perhaps be interesting to have the same editor for R code and C++ code. However, when looking at the last emacs windows version, it seems to date from january 2004 ... (dead end ?) ftp://ftp.gnu.org/pub/gnu/emacs/windows/ I will be grateful for all advices on this tool topic. Better choosing emacs ? or code::blocks ? or another idea ? Does somebody have an idea about the most used IDEs for R C++ package writing ? Thanks Vincent __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] IDE for R C++ package writing ?
Thanks for those first answers. Indeed i forgot to precise that i'm currently working on windows (but would like to be able to evolve to linux). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] IDE for R C++ package writing ?
First, great thanks to all for all the answers. I confess i was a bit scared about (re)learning a possible tomorrow obsolete tool. I'm however quite astonished nobody proposes another tool. Do 100% R package developers use emacs ? Anyway, given the answers, it seems i'll go on emacs or xemacs. Thanks for the guidance. Vincent __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] printf capture
printf capture
Dear All,
I'm running R-2.4.1 on WindowsXP.
I wrote a small C++ DLL using Rprintf() and all works fine
dyn.load(), is.loaded('f1'), Rprintf(), .C(), all is ok.
Now, the worry :
I use also a 3rd party piece of C++ program which was not designed
for R and uses printf().
I though on sink(...) before .C('f1'), but it doesn't work.
I call sink(file="res.txt") and only the Rprintf() are catched
Is there any way to however capture those printf() outputs ?
Thanks for any hint/pointer (... and i apologize
if i missed something obvious !).
Vincent
(for what may be worth, a "minimal" stuff is at www.khi.fr/IB/rp2)
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] printf capture
Prof Brian Ripley a écrit : > If you are using Rgui (it should work under rterm) yes indeed, it works under rterm > there is no C-level 'stdout' file stream (the normal state > for Windows GUI programs), so no way to capture it inside R. Aie ! (I feared this answer). Thanks however for the explanation. I was looking at pipe(), scan() etc. So, no hope from this side. > If you have the program, can you not edit it before compiling it? > Adding > #define printf Rprintf > will probably do the trick. yes thanks, I already though on that, and it works. But i would have preferred not touching this 3rd party code. = There is another little annoyance (always on WindowsXP + R-2.4.1) When including both and #include #include There is a #define ERROR redefinition #define ERROR ),error(R_problem_buf);} // this one in Rs.h #define ERROR 0// in MinGW/.../wingdi.h It's only a warning, but i would prefer to avoid it and i'm searching how to avoid it. Thanks for any idea. PS : compilation details : g++ -IJ:/softs/R-2.4.1/include -c f1.cpp -o f1.o In file included from J:/softs/R-2.4.1/include/R.h:49, from f1.cpp:11: J:/softs/R-2.4.1/include/R_ext/RS.h:40:1: warning: "ERROR" redefined In file included from f:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/windows.h:52, from f1.cpp:10: f:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/wingdi.h:313:1: warning: this is the location of the previous definition __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] printf capture
Prof Brian Ripley a écrit :
> You can always link in a wrapper that defined printf and passes the
> arguments to Rprintf.
I apologize but confess i didn't completely understand
this suggestion.
> It's documented in 'Writing R Extensions'.
> The defines used for compatibility with @Sl{} sometimes causes
> conflicts (notably with Windows headers), and the known
> problematic defines can be removed by defining @code{STRICT_R_HEADERS}.
Yes, i added
#define STRICT_R_HEADERS
in my cpp code, and the redefinition warning vanishes indeed.
Many thanks for your precise tips and my apologies for the late answer.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] printf capture
Simon Urbanek a écrit :
> The wrapper:
>
> #include
>
> int printf(const char *format, ...) {
> va_list (ap);
> va_start(ap, format);
> Rvprintf((char*)format, ap);
> va_end(ap);
> return 0;
> }
>
> If you link this in your project (simply create a separate object file
> with this), the project will be using Rprintf via this wrapper instead
> of printf from libc. Note that you shouldn't be relying on the return
> value literally, otherwise you're in trouble ;).
>
> Cheers,
> Simon
Thanks for the code.
The idea seems indeed interesting/appropriate for my needs.
I didn't remember at all that one could redefine
functions such as printf().
seems i need a good C/C++ brush up !
Thanks
Vincent
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible changes to connections
Prof Brian Ripley a écrit :
> When I originally implemented connections in R 1.2.0, I followed the model
> in the 'Green Book' closely. There were a number of features that forced
> a particular implementation, and one was getConnection() that allows one
> to recreate a connection object from a number.
I'm currently using connections (socketConnection(), etc)
and I first want to *thank you* for this nice work.
(imho, it's so much simpler than the underlying C/C++ stuff.)
> I am wondering if anyone makes use of this, and if so for what?
I use getConnection().
In the context in which I use it, the number of the connection is
known a priori.
So getConnection() is an easy way to access to the connection
for the functions which need to.
I do not however pretend this is the best way to proceed.
> It would seem closer to the R philosophy to have connection objects that
> get garbage collected when no R object refers to them. This would allow
> for example
> ... readLines(con <- gzfile("foo.gz")); close(con)
> which is a little awkward but more importantly seems little understood.
There could be/was the same debate in C/C++.
That's may be just a matter of education about not forgetting
to close previously opened doors !
> What I suspect is that very few users are aware of the Green Book
> description and so we have freedom to make some substantial changes
> to the implementation. Both issues suggest that connection objects should
> be based on external pointers (which did not exist way back in 1.2.0).
I'm not skilled enough for any advice here, but from a simple user
point of view, I just hope it could continue to be as simple and
practical as today.
And I renew my thanks for the existing tool (and also the rest !).
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible changes to connections
Prof Brian Ripley a écrit : >> I use getConnection(). >> In the context in which I use it, the number of the connection is >> known a priori. > > I don't see how you can know it 'a priori': it is an implementation detail > (and since R itself uses connections, those details could easily change). (disclaimer : I don't claim its the best way to proceed) Before launching my app, the connections context is : > showConnections(all=TRUE) description class mode text isopen can read can write 0 "stdin" "terminal" "r" "text" "opened" "yes""no" 1 "stdout""terminal" "w" "text" "opened" "no" "yes" 2 "stderr""terminal" "w" "text" "opened" "no" "yes" So, the call to socketConnections() creates always (at least for all my experiments) a connection with number 3. Btw, if (socketConnections(...) != 3) the application simply don't launch. So, if the application runs, it's sure that this is with a connection number==3. That's why I say that "the number of the connection is known a priori". Of course, the connection number could also be retrieved eg using the description field. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Matrix multiplication in a C code
Mathieu Ribatet a écrit : > Dear list members, > > I've got a small question on matrix multiplications in a C code. Because > of a really cpu demanding likelihood, I had to use a C code within an R > function wrapper. I'm pretty sure that there is already one good code > for matrix multiplication in C - maybe in the R source code itself - but > I wasn't able to find it. > > Anyone as an idea on how to handle matrix multiplications? fwiw : from a post on Rd on 4/4/2007 : Just-in-time compiler for R http://www.milbo.users.sonic.net/ra/index.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] matrix name
Hello, Presently, we are able to add additionnal info to a matrix thanks to the nice comment() and attr() functions. Maybe I miss some other functions ? Since there is a always a little remaining place on the top left when one print a matrix, I was wondering if it won't be interesting to offer the possibility to show some information here, I'm thinking on something like : > attr(M, 'topleft') = 'city\prms'; > M city\prms abc seattle135 vancouver 246 I don't know if it's easily feasible and even if it seems interesting enough ... so sorry if it is a silly idea. All the best Vincent __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] matrix name
Martin Maechler a écrit : Well, dimnames can be named : Thanks Martin and Gabor for the trick. And apologies for not thinking on it. Thanks Vincent __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Thanks for R-2.8.0 still on W2000
Hello, This little post is just to thank Prof. Ripley and the R team for still maintaining R runable on Windows 2000. I installed R-2.8.0 on Windows 2000 and used it for several computation hours and everything seems to work fine. Many thanks Vincent __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
