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?
