[Rd] MinGW-w64 build of 64-bit R for Windows
A few days ago Gong Yu alerted this list to the possibility of building a 64-bit R for Windows under a recent MinGW-w64 toolchain, something we had failed to make work in 2007, 2008 and Feb 2009. We've now completed the port in the R-devel (SVN trunk) sources and are able to successfully complete 'make check-all'. An experimental installer based on this version is available at http://www.stats.ox.ac.uk/pub/RWin/Win64/R-2.11.0dev-win64.exe but people who want to experiment may prefer to build from the R-devel sources, and all users should read the new 'Building R for 64-bit Windows' section in the R-admin manual in R-devel. Some notes: - The tcltk support is a stub. We have been able to build Tcl/Tk with MinGW-w64, but just as with a 32-bit MinGW build, it is liable to crash (which is why we use Tcl/Tk built under VC++6). It ought to be possible to build Tcl/Tk under the Platform SDK, but that is left for an interested party (it does not work out-of-the-box). - There is no support for binary packages and the default package type is "source". For packages without compiled code the 32-bit binary packages will work (but such packages can also simply be installed from their sources). For compiled code you will need to adjust etc/Makeconf unless you are using the mingw-w64-bin_i686-mingw cross-compiler (running under 32-bit Windows) mentioned in the R-admin manual. That compiler uses dynamic libraries, and C++ users (and perhaps others) will need to have the toolchain's bin/ directory in their path or copy the DLLs to RHOME/bin. (Other toolchains can be used, including building MinGW-w64 from the sources with static libraries.) - We found this build to be as fast as, and sometimes a bit faster than, the 32-bit CRAN windows build. - There is no commitment to support this other than in the sources, and in part we are making experimental builds available to judge interest and attract support. We see this as only being of interest to Windows users with a 64-bit OS and substantially more than 4GB of RAM who only use a few relatively simple packages (and there are other options from R redistributors). - Feedback and offers of support to r-wind...@r-project.org, please. At this stage we are looking for serious testers who are able to compile from the sources and submit patches, and offers to e.g. resolve the Tcl/Tk issues. - Thanks to Gong Yu and especially Kai Tietz (the MinGW-w64 lead developer) for help along the way. Brian Ripley -- 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] PROTECT and OCaml GC.
On 01/09/2010 02:04 AM, Guillaume Yziquel wrote: Guillaume Yziquel a écrit : Simon Urbanek a écrit : If you have suggestions for extending the API, feel free to post them with exact explanations how in general that extensions could be useful (general is the key word here - I think so far it was rather to hack around your way of implementing it). [And FWIW tryEval *is* part of the API]. Concerning tryEval, I had a look at context.c, and it says: /* R_tryEval is in Rinternals.h (so public), but not in the API. */ And concerning tryEval, there's one feature I miss: there is error handling capabilities, but to my knowledge, it provides a boolean status back. True or false. Is it possible to get a full error message back, so that it can be analysed and translated to OCaml exceptions? Not to my knowledge, what we do in Rcpp is to to bring the expression to the R side, evaluate it within a tryCatch and then grab either the result if successfull, or the error. The R side of this is in : http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/pkg/R/exceptions.R?rev=249&root=rcpp&view=markup and the C++ class is the Evaluator class: http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/pkg/src/Evaluator.cpp?rev=260&root=rcpp&view=markup It smells the "it works but ..." pattern. tryEval is just a thin wrapper around R_ToplevelExec (in context.c), what you need (and we need also in Rcpp) is a somewhat improved version of R_ToplevelExec which would modify the context. This would remove the need for a round trip to the R side... I once tried to factor R_ToplevelExec out of R into a package, but failed. When I get a better understanding of contexts, I might propose something. Now, here's a feature I'd like to implement with the API: In OCaml, there's a library called Lwt. It's a library implementing lightweight, or green, threads. What I want to do is to be able to launch some R code, and have it multithread with other OCaml code, within one single real thread. Therefore I have to implement the commutation context somewhere in the evaluation mechanism of R itself. The API doesn't support that, I guess. -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |- http://tr.im/JOlc : External pointers with Rcpp |- http://tr.im/JFqa : R Journal, Volume 1/2, December 2009 `- http://tr.im/IW9B : C++ exceptions at the R level __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Is nested namespace supported?
Could somebody let me know if there is nested name space supported? For example, is it possible to define a function in the name space 'nested_namespace' which is nested in the name space 'some_namespace'? some_namespace:::nested_namespace:::a_function() I checked Section 1.6 of R-exts.pdf. It seems that nested namespace is not supported, right? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Is nested namespace supported?
On 01/09/2010 09:53 PM, Peng Yu wrote: Could somebody let me know if there is nested name space supported? For example, is it possible to define a function in the name space 'nested_namespace' which is nested in the name space 'some_namespace'? some_namespace:::nested_namespace:::a_function() I checked Section 1.6 of R-exts.pdf. It seems that nested namespace is not supported, right? It is not even grammatically valid: > parse( text = "foo::bar::foobar" ) Error in parse(text = "foo::bar::foobar") : unexpected '::' in "foo::bar::" > parse( text = "foo:::bar:::foobar" ) Error in parse(text = "foo:::bar:::foobar") : unexpected ':::' in "foo:::bar:::" Romain -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |- http://tr.im/JOlc : External pointers with Rcpp |- http://tr.im/JFqa : R Journal, Volume 1/2, December 2009 `- http://tr.im/IW9B : C++ exceptions at the R level __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Is nested namespace supported?
On Sat, Jan 9, 2010 at 3:03 PM, Romain Francois wrote: > On 01/09/2010 09:53 PM, Peng Yu wrote: >> >> Could somebody let me know if there is nested name space supported? >> For example, is it possible to define a function in the name space >> 'nested_namespace' which is nested in the name space 'some_namespace'? >> >> some_namespace:::nested_namespace:::a_function() >> >> I checked Section 1.6 of R-exts.pdf. It seems that nested namespace is >> not supported, right? > > It is not even grammatically valid: > >> parse( text = "foo::bar::foobar" ) > Error in parse(text = "foo::bar::foobar") : > unexpected '::' in "foo::bar::" > >> parse( text = "foo:::bar:::foobar" ) > Error in parse(text = "foo:::bar:::foobar") : > unexpected ':::' in "foo:::bar:::" Do you mean nested namespace is not supported in R? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
