Trf
Trf , by Andreas Kupries, is a Tcl extension based upon the principle of stacked channels.
Attributes
- latest release
- 2.1.4
- release time
- 2009-10-26
Obtaining
Trf is part of the ActiveTcl Batteries Included distribution.
Description
DKF 2006-05-18: There has been considerable effort in Tcl 8.5 to make the major feature of Trf (i.e. stacked channels) available at the Tcl-script level. See the chan command for details.
Trf provides reflected channels that perform the following transformations:
- base64 encoding and decoding
- error correction
- message digests (SHA, MD5)
- quoted printable conversion
- zlib/bzlib compression, SHA, MD5
Trf may be useful, for example, to handle mime-Mail. An add-on, Trfcrypt, provides Encryption and Decryption algorithms.
There may be political reasons not to mirror TrfCrypt on ftp/http sites or include in CD-ROM products in any country where there are laws regarding possession or distribution of crypto-related software.
Some of the other things that make use of Trf include:
Usage
Pat Thoyts provides some example manipulations:
32 % package require Trf
2.1
33 % set chk [crc-zlib {Hello, World!}]
<funny chars>
34 % binary scan $chk i chksum
1
35 % format 0x%x $chksum
0xec4ac3d0Note that hex can be used to perform the same conversions. Here is the example from above recast to use hex:
32 % package require Trf
2.1
33 % set chk [crc-zlib {Hello, World!}]
<funny chars>
34 % set chkx [hex -mode encode -- $chk]
D0C34AECPT: If you look carefully you can't really use hex. crc and crc-zlib return the bytes of a long integer. hex encodes each byte in turn. What we really need is binary scan $result i val. However the crc32 will wrap this up transparently now.
Building
Any tips for how to get this thing built on Microsoft Windows (preferably using MinGW)?
Any binaries available without the obsolete 2.1px style versioning?
jmn 2006-02-25: I've given up trying to build Trf on windows.. I found the easiest way to move forward and use Trf with recent CVS checkouts of Tcl 8.5 (which is stricter on version numbers) was to use a binary editor to directly change the number in the dll from 2.1p1 to 2.1.1. Dodgy - but it works. Presumably if TIP #230 (Tcl Channel Transformation Reflection API) is approved then there'll be less need for the Trf extension anyway.
There is also giot which is supposed to be the channel transformation part of Trf on its own.. but the 'transform' arguments are slightly different and I've found that it pretty reliably crashes my threaded 8.5 interps.
WK: Trf can be built using mingw+cygwin. Latest DQkit sources include code to compile both trf and trfcrypt, this is static, but can be easily used to manually build a dynamic version.
LV: I'd love to hear from someone who has successfully convinced Trf's build environment to build a 64 bit version...
AK: Which build environment ? The TEA configure in the top level directory, or the old unix/configure ? I am building Trf on linux/amd64, linux/itanium, hpux/itanium, solaris/sparcv9 without trouble. All the builds use the toplevel TEA configure.
LV: SPARC Solaris. When I use the unix directory, a 32 bit version of Trf is created. When I use the top level directory, the Makefile doesn't compile the C code - it goes directly to the link step. This is, however, the cvs snapshot from 2005... Is there a newer version available anywhere? This one is missing, for instance, trf_compile.html
Never mind - the problem was that I forgot to do a make distclean in the unix directory, and the Makefile was looking there for the binaries!
FPX: Using Trf 2.1.3, cross-building on Linux/x86_64 for Linux/PPC, I found that I had to hack generic/zlib.c and force Z_LIB_NAME to "libz.so" because I was getting the following error at run-time:
inflate error: cannot open libz: libz.sl: cannot open shared object file: No such file or directory
I have no idea where the ".sl" extension comes in. At compile time, the file was getting -DLIBZ_DEFAULTNAME=\"libz\" from the Makefile, and Tcl thinks its info sharedlibextension is ".so" as expected.