On Tue, 2007-04-03 at 03:33 -0400, Wojciech Gryc wrote: > Hi, > > Using the current Java and Python based tools for R (JRI and RPy > respectively) already provides one with a starting point in terms of a > framework.
Actually, the preferred approach (when all things are equal) would be to consider C++ first for the cleanest integration, then other languages if the C++ approach is proven too difficult, or otherwise not workable. This page http://developer.r-project.org/embedded.html suggests that it is possible to dynamically load libR.so at run-time in C/C++ program, so this approach should not be discounted from the start. Java and Python could be used indeed, but there is a slight run-time performance penalty for that (and not so slight startup performance penalty) simply because of the dependency on external interpreters. This may not matter for simple'ish functionality, but as the functionality of R-interface grows, the performance penalty may become obvious and we may be forced to rewrite it in C++ later on. Numerically intensive code with a lot of loops is more susceptible to such run-time performance loss. Not that this (re-writing) will happen for sure, but just to give some insight from one developer's own experience. ;-) > I'd love to get other developers' opinions on this. My understanding is that > there is both Java and Python support within OpenOffice, so I don't see any > major changes as necessary. Again, this ignores the issue of licensing and > IP rights -- something I need to look into more myself, though I welcome any > comments, especially since it was mentioned on the Summer of Code wiki. > Would this be a big challenge to overcome? The restriction we need to be aware of is: 1) we can't dynamically link against R library because R is released under GPL. Only GPL'ed program can dynamically link against a library that is under GPL. And, 2) we can't redistribute GPL-ed code with non-GPL'ed program, which OO.o is not. But at least the following should be allowed 1) Dynamically loading the library at run-time into host program's address space. The host program in this case is OO.o. The page I provided above suggests that this may be doable. 2) Executing R as a separate process using process fork. This is a common technique for integrating executables (which R is). Just my 2 cents, 2 euros, 2 yens (whatever ;-) Kohei -- Kohei Yoshida - OpenOffice.org Engineer - Novell, Inc. <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
