[Rd] [rfc] Package to access the internal zlib library.

[Duncan Murdoch]

On 1/30/2008 4:20 AM, Prof Brian Ripley wrote:
> On Wed, 30 Jan 2008, jason at acm.org 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.
>