I started playing with FFI and got the hashing streams working. They require OpenSSL's libcrypto, which should be available on any reasonably recent Unix and OSX. The VW version also has interface to native Windows bcrypt.dll (available on Vista and later) but I haven't done that part yet. Anyway the hashing streams seem to work and performance isn't bad either. Hashing 100MB of ones
[ (([ 1 ] reading limiting: 100000000) hashing: 'md5') -= 0; close; digest ] timeToRun
takes little over 5 seconds on not particularly fast machine. The above expression runs about 2.5 times faster on VW on the same machine, but that's probably due to the time spent in the block based terminal. Profile on VW says that only about 15% of the time is spent in the hashing layer. Hashing the 21M pharo image is pretty much instant:
((FileDirectory default / 'pharo.image') reading hashing: 'md5') -= 0; close; digest
The code is in Xtreams-Xtras and Xtreams-XtrasTests (note that you'll have to load FFI!). I tested it on Pharo 1.2 beta with both cog vm and standard vm. There are few test failures with file terminals that don't seem to like to be closed twice. Should be an easy fix.
Enjoy,
Martin
P.S.: If any resident FFI experts find the time and interest to look over my C bindings and find something wrong, please let me know. In particular I have't quite figured out how to work with struct fields that contain arrays (e.g. 'unsigned char [128]'). I figured out that I can declare the actual size of the field as a third parameter in the #fields declaration, but the accessors generated for the field are not right. I suspect they need to be some form of ExternalData but I don't quite grok how that should be created (see e.g. HMAC_CTX>>key).
Also it seems that there isn't a type definition for 'int' so I'm replacing all references to that with 'long'. Is that how it's done?