Ross Berteig wrote: > On 9/4/2013 2:40 PM, Stephan Beal wrote: [...] >> As before, i find it really cool, if even if only for its conversational >> value. i can actually imagine that i'd use it (but won't really know >> that until trying it out). i will certainly be forking this into >> libfossil in some form or other. You've already done the sqlite3 >> binding, leaving me with little left to port :)
It was impressively straightforward --- the hardest part was figuring out how the db init stuff works (which I have rationalised a bit, see earlier bug report). Sqlite's nice and easy to bind to. >> If this can be >> "flavored" by clients (custom word lists), i'd probably spend way to >> much time playing with it. Theoretically yes, but in practice it's liable to be way too hard --- the dictionary is huge, 1626 words (plus seven special words for overflow), and there's a fair amount of subtlety to the design. For example, no word is a prefix of another word; all words are unique when truncated to five letters; all words sound reasonably different... there's lots of information here: http://web.archive.org/web/20090918202746/http://tothink.com/mnemonic/wordlist.html Ideally the dictionary should go into the repository somewhere, which should make it trivially modifiable, but I don't know how to do that. I assume that adding 1673 named configuration variables is antisocial? [...] > While thinking in the blue sky, it would also be neat if it did the > prefix-match trick that fossil does now for hex ids. That is, if > [TOAST], [TOAST MOZART], and [TOAST MOZART TULIP] all matched > [74a95e62cf]; and naturally supporting even longer phrases to > disambiguate past the first eight digits. Given the mapping of three > words to 32 bits, however, there is some subtlety to address there so it > may not be as trivial as just decoding what you got and shifting. Each word represents 10.7 bits. So one word encodes one byte; two words encode two bytes; three words encode *either* three or four bytes depending on the last word. (There are seven special words used to encode the leftover three bits when encoding three bytes.) So theoretically it's possible... however, playing with the encoder I see that: 12345678 = CRASH CHAPTER CASINO 123456 = ROVER TRIBAL EGO 1234 = JAMES ACTIVE 12 = ALCOHOL This looks suspiciously like I'm encoding stuff in little-endian order rather than big-endian order. I'll have a look at that. Incidentally, the full ticket hash encodes to TOAST MOZART TULIP TOTAL PERFECT CLONE MORPH SIZE BETTY ATLAS ARENA TRADE PLUME REMARK CORNER. Which is still a mouthful, but I bet I can read that over the phone faster than you can read the hex! ... Out of interest, when do people using Fossil actually use hashes to refer to things? It's fairly common to use the hash in git to refer to a specific checkin, for example, but I've never found an urge to do that in Fossil. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ "USER'S MANUAL VERSION 1.0: The information presented in this │ publication has been carefully for reliability." --- anonymous │ computer hardware manual
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
