Do you legally agree to license terms that are not published yet ? no ?
Then, do not put a """version 2/3 or more""" in your license text. Doing so means that you agree that all future version of this license that may be created can be chosen when using what you distribute. even if the license became something completly different than what you did agree on at the license choosing time.
That's it i finally released my first haskell module.
it's a wrapper for git, that provides lowlevel operations and some highlevel ones too. It's not the best haskell code ever, specially since this is one of my first piece of useful haskell code, and i'm going to improve it slowly over time.
it's available here http://github.com/vincenthz/hs-libgit
Liferea is a news aggregator that i've been using for quite a while. The interface is simple, and it was fast enough. but lately its behavior became more erratic, so I start looking at the reason of that behavior.
First things first, the feed's data are all stuffed in a sqlite3 database. unfortunately it seems that the caching policy is just mirroring everything locally. couple of weeks ago the database was already a whopping 120Mb, now it just reach 195Mb. I didn't add any new feeds since that last time, so obviously something is really wrong. does liferea delete any things in its database ?
Over looking at the database with the sqlite3 command line utility indicate that the items table is taking the most space, followed by the itemsets table.
It's also got this annoying behavior that everything that is copy and pasted in the liferea windows is considered as a new news feed. For people reading with mouse selection, which is something i'm trying to quit, this is really annoying. specially since sometimes it can create multiples (20 was my top score) news feed subscription with some random text selection which are obviously not web links. Worst things, you can't do multiples selection in the feed selection view, so removing bad feeds is a one by one process.
Looking at liferea-1.6.3 source, with 54086 lines in .c and .h files, the task of patching it seems daunting. I did a hack to disable copy and paste completly, but changing the way liferea stores data, seems a too long project.
So i've decided to take the matter in my own hand, and make a small and fast news aggregator. one that has a storage well designed, so that reading a new items in a feed doesn't make the system crawl for IO to the always-growing database. It will be probably similar to some of those rss2imap projects, except it will be in haskell and it won't sucks.
Dear Web Developpers,
when you are setting web page colors, please set also input related object background colors. Because you set usually set text color, through the * CSS object, to be black without setting the input background to be light, people with black themes end up with a black on black text which is quite impractical.
setting input colors is not really hard, so please do. OK ? Thanks Bye !
There's a bunch of different haskell projects that implements some cryptohashes (sha1, md5, ..). However they are very differently constructed, with unconsistent interface overall. Also most of them has poor performance, and expose only the high level operation: hash data in one go, giving back a digest.
Also most of them implement really common cryptohashes like sha1, sha2 and md5, but it's hard to find anything out there for less common cryptohashes (md2, md4, ripemd comes to mind).
To rectify this problem, here come the hs-cryptohash package; it's a bundle of 9 differents algorithms implementing all common cryptohash (sha1, sha2 family, md5), but also some less common one (md2, md4, ripemd160). Each interfaces of thoses modules are completely similar, which make it simple to replace one hash algorithm by another.
Under the hood, all thoses algorithms are implemented in C, with a relatively well optimized for most of them. Some of them come close to openssl, one of the fastest library for cryptohash, whereas most of them are around the same ball park as the sum programs available in GNU coreutils.
Over the hood, everything is pure despite having IO related calls because of the C FFI. There's 2 mains interfaces exposed: the one-go interface, and the incremental interface.
The one-go interface exposes 2 calls hash and hashlazy, that takes a strict bytestring and lazy bytestring respectively, and gives back a digest bytestring
The incremental interface exposes 3 calls: init, update and finalize. This is on par with what most cryptohash algorithm exposes as interface. This is very useful to use thoses calls when data comes through multiples chunks and you don't want to "store" all the chunks before hashing. This interface is slighly slower than the one-go one, for the simple reason that to expose a pure interface, the context cannot be updated in place.
Here's goes some numbers comparing debian coreutils digest binaries (sha1sum, sha256sum ..) with openssl and then with new haskell cryptohash modules in incremental and then one pass mode. each run is processing a 500mb random file, then averaged on 4 trials.
coreutils cryptohash(op) cryptohash(in) openssl sha1 2.97500 2.65250 3.64250 1.90250 sha224 5.36000 5.78250 6.78250 4.30500 sha256 5.33500 5.76000 6.77750 4.26750 sha384 3.65500 3.65750 4.69000 2.78500 sha512 3.66000 3.66500 4.70750 2.79750 md5 1.65750 1.75750 2.70750 1.50250 ripemd N/A 3.80000 4.77000 3.83
And now some numbers with some other hackage library (digesting a 500mb file):
SHA PureMD5 cryptohash speedup sha1 23.1s N/A 2.65s x 8.7 sha256 44.8s N/A 5.76s x 7.7 sha512 25.4s N/A 3.55s x 7.1 md5 N/A 9.42 1.76s x 5.3
