After the recent discussion about future direction of the Mac OS X port, I was toying with the idea to make R a proper Mac OS X framework. There are several advantages: OS X locates frameworks automatically, therefore any program wishing to link against R has only to specify "-framework R" at link time. Furthermore versioning is supported, i.e. if a program is linked against R 1.7.1 and you install 1.9.0 later, then the program will still get the correct 1.7.1 version (if we define the 1.9.0 not to be compatible with 1.7.1), but any new program will link against the most recent R. The granularity is up the framework creator. It is possible to easily create a R Framework just with the current R as follows: configure your favorite R (I'll use 1.8.1 for illustration) but use the following prefix: --prefix=/Library/Frameworks/R.framework/Versions/1.8.1/Resources you should also add --enable-R-shlib (if you want to use --enable-aqua, read on first!) after make / make install run the following script as root (you may want to edit it if you didin't use 1.8.1 or if you want to install an user-private framework): http://stats.math.uni-augsburg.de/misc/Rframework.sh This will create a proper framework from what the R installer created - and you're all set! You can use such framework for any program - just like Apple's system frameworks. It's really great what you can do with Xcode then (code completion of R stuff, zero-linking etc ;)). For a screenshot of Xcode using R framework, see: http://stats.math.uni-augsburg.de/misc/Rframework.png You can even make a symlink from /Library/Frameworks/R.framework/Resources/bin/R to /usr/binR and you will have the most recent R always at your fingertips. The nice thing is that you can use ~/Library/Frameworks instead of the above /Library/Frameworks if you want. There is no difference from system's point of view. You could event supply the R framework inside you application's bundle, but I guess that'd be an overkill ;) Now for some issues that need to be solved: The current R needs R_HOME to be set before using it even in its embedded form. Now this defeats the idea of location independence of the framework. The application doesn't have to care whether the framework is in /Library/Frameworks, ~/Library/Frameworks or any user-defined framework location. Therefore it would be nice to have a tiny function in the R shlib, that would tell me where the shlib lives (either by using system's API to determine its own location, or at least the path used on installation). BTW: This is not Mac specific - I was fighting this on Windows (and unix for that matter) as well - it is possible to run an .exe linked to R.dll from anywhere, if R.dll is in the PATH. But then, one has to determine R_HOME somehow (yes, there is the registry, but that's not really safe if more R versions are installed). The second issue is a rather minor one which will be solved if RAqua uses the framework. If you used --enable-aqua then configure overrides the dylib location, which is bad for our framework: configure.ac @ 1050: if test "x${want_aqua}" = xyes; then LIBR_LDFLAGS="-dynamiclib -install_name /Applications/StartR.app/RAqua.app/Contents/Frameworks/libR.dylib" else LIBR_LDFLAGS="-dynamiclib -install_name \$(Rexeclibdir)/libR.dylib" fi You'll need to remove the aqua part of it, otherwise the libR.dylib is not expected inside the framework. Finally, in order to take advantage of the versioning, we should add version information to the dylib. This can be done by adding -dylib_compatibility_version and -dylib_current_version to the LIBR_LDFLAGS (e.g. for R-1.8.1 probably 1.8.0 to compatibility and 1.8.1 to current). BTW: A side note - if the host application runs a proper event loop (like my Rgui runs the standard Cocoa event loop) then the Quartz device works flawlessly even without RAqua! Good job, Stefano! There is still room for improvement - I started this more as a proof of concept and was surprised how smoothly it went. Someone interested might look into issues like using Tcl/Tk, placing libraries conveniently (in ~/Library/Application Support/R/library ?) etc. --- Simon Urbanek Department of computer oriented statistics and data analysis Universit?tsstr. 14 86135 Augsburg Germany Tel: +49-821-598-2236 Fax: +49-821-598-2280 Simon.Urbanek@Math.Uni-Augsburg.de http://simon.urbanek.info
R as OS X Framework
3 messages · Simon Urbanek, Jan de Leeuw
This is a major step in the right direction. I know that Duncan has at least the beginning of an R bridge to the Cocoa toolkits, which would be the second major step. It will make it possible to write stand-alone R based applications with a Cocoa GUI, of which R.app will just be a major example, but of which Rglm.app or Rcluster.app could be other examples (with problem specific menus and graphics). And these could all be developed nicely by having a Xcode plugin for R. These steps emphasize the strengths of OS X (as the quartz device already does) and do not just give another boring shell around the command line interpreter. Getting away from Carbon in this way is important, and you don't have to learn Objective C to program in Cocoa. By the way, as another example, the quartz device works fine from Rpy running in one of the Python or wxPython GUI's (which have decent eventloops). See the desktops at gifi.stat.ucla.edu/pub.
On Nov 29, 2003, at 16:45, Simon Urbanek wrote:
After the recent discussion about future direction of the Mac OS X port, I was toying with the idea to make R a proper Mac OS X framework. There are several advantages: OS X locates frameworks automatically, therefore any program wishing to link against R has only to specify "-framework R" at link time. Furthermore versioning is supported, i.e. if a program is linked against R 1.7.1 and you install 1.9.0 later, then the program will still get the correct 1.7.1 version (if we define the 1.9.0 not to be compatible with 1.7.1), but any new program will link against the most recent R. The granularity is up the framework creator. It is possible to easily create a R Framework just with the current R as follows: configure your favorite R (I'll use 1.8.1 for illustration) but use the following prefix: --prefix=/Library/Frameworks/R.framework/Versions/1.8.1/Resources you should also add --enable-R-shlib (if you want to use --enable-aqua, read on first!) after make / make install run the following script as root (you may want to edit it if you didin't use 1.8.1 or if you want to install an user-private framework): http://stats.math.uni-augsburg.de/misc/Rframework.sh This will create a proper framework from what the R installer created - and you're all set! You can use such framework for any program - just like Apple's system frameworks. It's really great what you can do with Xcode then (code completion of R stuff, zero-linking etc ;)). For a screenshot of Xcode using R framework, see: http://stats.math.uni-augsburg.de/misc/Rframework.png You can even make a symlink from /Library/Frameworks/R.framework/Resources/bin/R to /usr/binR and you will have the most recent R always at your fingertips. The nice thing is that you can use ~/Library/Frameworks instead of the above /Library/Frameworks if you want. There is no difference from system's point of view. You could event supply the R framework inside you application's bundle, but I guess that'd be an overkill ;) Now for some issues that need to be solved: The current R needs R_HOME to be set before using it even in its embedded form. Now this defeats the idea of location independence of the framework. The application doesn't have to care whether the framework is in /Library/Frameworks, ~/Library/Frameworks or any user-defined framework location. Therefore it would be nice to have a tiny function in the R shlib, that would tell me where the shlib lives (either by using system's API to determine its own location, or at least the path used on installation). BTW: This is not Mac specific - I was fighting this on Windows (and unix for that matter) as well - it is possible to run an .exe linked to R.dll from anywhere, if R.dll is in the PATH. But then, one has to determine R_HOME somehow (yes, there is the registry, but that's not really safe if more R versions are installed). The second issue is a rather minor one which will be solved if RAqua uses the framework. If you used --enable-aqua then configure overrides the dylib location, which is bad for our framework: configure.ac @ 1050: if test "x${want_aqua}" = xyes; then LIBR_LDFLAGS="-dynamiclib -install_name /Applications/StartR.app/RAqua.app/Contents/Frameworks/libR.dylib" else LIBR_LDFLAGS="-dynamiclib -install_name \$(Rexeclibdir)/libR.dylib" fi You'll need to remove the aqua part of it, otherwise the libR.dylib is not expected inside the framework. Finally, in order to take advantage of the versioning, we should add version information to the dylib. This can be done by adding -dylib_compatibility_version and -dylib_current_version to the LIBR_LDFLAGS (e.g. for R-1.8.1 probably 1.8.0 to compatibility and 1.8.1 to current). BTW: A side note - if the host application runs a proper event loop (like my Rgui runs the standard Cocoa event loop) then the Quartz device works flawlessly even without RAqua! Good job, Stefano! There is still room for improvement - I started this more as a proof of concept and was surprised how smoothly it went. Someone interested might look into issues like using Tcl/Tk, placing libraries conveniently (in ~/Library/Application Support/R/library ?) etc. --- Simon Urbanek Department of computer oriented statistics and data analysis Universit?tsstr. 14 86135 Augsburg Germany Tel: +49-821-598-2236 Fax: +49-821-598-2280 Simon.Urbanek@Math.Uni-Augsburg.de http://simon.urbanek.info
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://www.stat.math.ethz.ch/mailman/listinfo/r-sig-mac
=== Jan de Leeuw; Professor and Chair, UCLA Department of Statistics; Editor: Journal of Multivariate Analysis, Journal of Statistical Software US mail: 8130 Math Sciences Bldg, Box 951554, Los Angeles, CA 90095-1554 phone (310)-825-9550; fax (310)-206-5658; email: deleeuw@stat.ucla.edu homepage: http://gifi.stat.ucla.edu ------------------------------------------------------------------------ ------------------------- No matter where you go, there you are. --- Buckaroo Banzai http://gifi.stat.ucla.edu/sounds/nomatter.au
On Nov 29, 2003, at 7:32 PM, Jan de Leeuw wrote:
This is a major step in the right direction. I know that Duncan has at least the beginning of an R bridge to the Cocoa toolkits, which would be the
Does he? I was toying with a Cocoa package for R (Cocoa windows/widgets in R; quite interesting how to tell R package installation system to handle Obj-C sources ...). I thought about using parts of Rserve to put together something like JRclient but for Obj-C, plus a class that would encapsulate R services like the parser and the evaluator. Duncan could probably use his OH stuff for that - it might work. I'd be interested to lear more about his progress.
second major step. It will make it possible to write stand-alone R based applications with a Cocoa GUI, of which R.app will just be a major example, but of which Rglm.app or Rcluster.app could be other examples (with problem specific menus and graphics). And these could all be developed nicely by having a Xcode plugin for R.
Definitely - I was thinking along these lines - with proper Obj-C classes encapsulating R functionality now exposed by R.framework an application could be "written" (though it's not the proper word any more ;)) with the Cocoa controller layer just by using drag&drop. That would be awesome...
These steps emphasize the strengths of OS X (as the quartz device already does) and do not just give another boring shell around the command line interpreter. Getting away from Carbon in this way is important, and you don't have to learn Objective C to program in Cocoa.
I guess that Quartz in Carbon is ok for now, because it actually doesn't use almost anything from Carbon except for the window creation routines ;). Everything else (especially widgets & co) could be Cocoa. Simon --- Simon Urbanek Department of computer oriented statistics and data analysis Universit?tsstr. 14 86135 Augsburg Germany Tel: +49-821-598-2236 Fax: +49-821-598-2280 Simon.Urbanek@Math.Uni-Augsburg.de http://simon.urbanek.info