On 1/30/2008 4:20 AM, Prof Brian Ripley wrote: > On Wed, 30 Jan 2008, [EMAIL PROTECTED] wrote: > >> To make R.matlab's readMat work for me[1] I needed access to zlib's >> uncompress function. R already links with zlib, and sometime last > > Not so: R can be linked to the system's zlib, and otherwise uses its own > copy which is not intended for use by packages. > > Please check what 'Writing R Extensions' says about using undocumented > entry points in R. Ideally none of zlib would be visible, but some > packages have been making use of undocumented entry points and we took > pity on them.
rgl is one of those packages. Over the last couple of days, I've been looking at linking it to freetype as well, to allow fonts to be specified in the displays. This is taking me some time, because although freetype has lots of support for being built in diverse environments, the environment Rtools provides on Windows is different from all of those, and I'm not that familiar with debugging complicated GNU Makefiles. Now it seems to me that some other package might want to make use of freetype. Eventually they'll be able to copy what we do in rgl, but it would make more sense for me to wrap up freetype as an R package, so they can concentrate on whatever it is that interests them. This package would have no R entry points, it would just package the headers libs and source in a standard way, so that other packages could choose to statically or dynamically link to it. On platforms that provide freetype as a system library the package might build nothing at all, or a user might choose to install it (to get a particular version for static linking, for example.) So would it be feasible to put together another R package type, that is essentially just a wrapper for a library like freetype or zlib? (rgl also links to pnglib in R on Windows, also through undocumented methods.) > Your package will not work as it does not include the header zlib.h, and > e.g. Windows does not have it. Expecting the system's zlib.h to work with > R's internal copy is unsafe. If we did have this new package type, then a zlib package could be part of base R, and other packages would have a well defined way to link to it. Duncan Murdoch > > The *only* safe thing to do is to include your own copy of zlib, and > compile it into the package (optionally linking instead to the system copy > if it exists). > > >> year I hobbled together a quick package to get at a few functions. >> It's my first package, so I would love feedback both on the package >> and its purpose. >> >> I've dropped a temporary copy at >> http://jriedy.users.sonic.net/internalzlib_0.1.tar.gz >> >> Could someone with Windows and knowledge of how to decypher Windows >> problems test if it works for them? I still need to try AIX as well. > > Please note that Uwe Ligges provides a Windows testing service: see > 'Writing R Extensions' and the R-admin manual. You don't need to ask > others to do this for you. > >> >> Jason >> >> Footnotes: >> [1] I'm cleaning patches to send to the author shortly. I think >> I have readMat working for compressed data, UTF-*, and sparse >> matrices now. > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
