On 07/09/13 23:43, David Given wrote:
> OTOH, thinking about the actual use case for these, I'm not sure there's
> going to be that many situations where someone needs to remember an
> entire unambiguous hash. The main use case I'm thinking of here, which
> is where someone from work comes over to
On 05/09/13 22:41, David Given wrote:
[...]
> I think, without a mathematical proof, that maintaining the ability to
> take prefixes of an encoded name will require us to use a dictionary
> that fits into a precise number of bits. Truncating the dictionary to
> 2^10 entries would be the simplest ap
On 2013-09-06 20:11, Ross Berteig wrote:
> ba-ba-ba-ba
> 12345678di-ku-poo-wa
> 74a95e62vu-che-roo-si
>
> da39a3ee5e6b4b0d3255bfef95601890afd80709
> ghi-le-clo-phoo-roo-to-no-cy-ki-py-frau-
> phau-bly-sa-fa-bla-chau-gha-bau-ce
I like this, but...
At le
Thus said David Given on Wed, 04 Sep 2013 22:07:32 +0100:
> Based on various conversations in the past I have been working on a
> semi-interesting features: using mnemonic encoding to turn ticket
> hashes into something that humans can remember.
What about using the ICAO alphabet? It be e
On 2013-09-06 20:11, Ross Berteig wrote:
ba-ba-ba-ba
12345678di-ku-poo-wa
74a95e62vu-che-roo-si
da39a3ee5e6b4b0d3255bfef95601890afd80709
ghi-le-clo-phoo-roo-to-no-cy-ki-py-frau-
phau-bly-sa-fa-bla-cha
On 9/5/2013 11:32 PM, Edward Berner wrote:
On 9/5/2013 1:39 PM, Doug Franklin wrote:
These are going to get long, fast, as someone else already noted.
However, in the past I've seen algorithms to generate "random" "words"
that are still pronounceable, one character at a time. The trouble
here is
On 5 September 2013 17:41, David Given wrote:
> (The alternative is a 2^11 word dictionary, which means coming up with
> another 422 suitable words from somewhere, which I don't think is
> feasible. The author claims the current dictionary took 300 hours to
> compile.)
There's an 7776 common word
On 9/5/2013 2:41 PM, David Given wrote:
> I think, without a mathematical proof, that maintaining the ability to
> take prefixes of an encoded name will require us to use a dictionary
> that fits into a precise number of bits. Truncating the dictionary to
> 2^10 entries would be the simplest approa
On 9/5/2013 2:41 PM, David Given wrote:
I think, without a mathematical proof, that maintaining the ability to
take prefixes of an encoded name will require us to use a dictionary
that fits into a precise number of bits. Truncating the dictionary to
2^10 entries would be the simplest approach, bu
On 9/5/2013 1:39 PM, Doug Franklin wrote:
These are going to get long, fast, as someone else already noted.
However, in the past I've seen algorithms to generate "random" "words"
that are still pronounceable, one character at a time. The trouble
here is likely to be the comparative lack of vowe
On Thu, Sep 5, 2013 at 7:43 PM, Ross Berteig wrote:
> One way to do that (again, blue sky, from someone not intimate with the
> insides of fossil) would be to cache the memorable names in a table where
> they can be located by SQL just as the prefix of a hash is now.
>
FWIW: that part is simple.
On Thu, Sep 5, 2013 at 11:41 PM, David Given wrote:
> I don't think seven hex characters is unique enough, based on the stats
> other people have figured out. Could someone do the collision check on
> the NetBSD repository, if they have a copy? (It's not worth checking
> out, as it's kind of huge
On 05/09/13 15:21, David Given wrote:
> Richard Hipp wrote:
[...]
>> HHH -> WORD -> HH
>> HH ->WORD-WORD -> H
>> -> WORD-WORD-WORD ->
[...]
> I'll have a go tonight and see what happens --- the encoder/decoder is
> wrong and needs to be rewritten any
On 2013-09-05 13:43, Ross Berteig wrote:
First off, as you mentioned a few posts ago, you've got to get it
examining the bits in the same order and chunks regardless of the
"endianness" of the host. At that point, it seems like prefixing ought
to start working as expected.
I'm not convince
On Thu, Sep 5, 2013 at 11:52 AM, Matt Welland wrote:
> Can tickets be tagged? A quick browse of the tickets page and I conclude
> the answer is probably no. If tickets could be tagged similar to the
> timeline then tags could be used to give tickets a sync friendly short name
> which could be use
On Thu, Sep 5, 2013 at 10:39 PM, Doug Franklin
wrote:
> These are going to get long, fast, as someone else already noted. However,
> in the past I've seen algorithms to generate "random" "words" that are
> still pronounceable, one character at a time. The trouble here is likely
> to be the compar
On 9/5/2013 11:18 AM, Stephan Beal wrote:
i'm not 100% sure my query is right (i'm no SQL guru), but in the mail
fossil repo we seem to have only 14 collisions (across 21k blobs) at 6
digits:
So ran this query over my current project's repo, which has only 2254
blobs, for a range of pref
On 9/5/2013 6:55 AM, Richard Hipp wrote:
On Thu, Sep 5, 2013 at 6:27 AM, David Given mailto:d...@cowlark.com>> wrote:
playing with the encoder I see that:
12345678 = CRASH CHAPTER CASINO
123456 = ROVER TRIBAL EGO
1234 = JAMES ACTIVE
12 = ALCOHOL
I think the a
On Thu, Sep 5, 2013 at 5:52 PM, Matt Welland wrote:
> Can tickets be tagged? A quick browse of the tickets page and I conclude
> the answer is probably no. If tickets could be tagged similar to the
> timeline then tags could be used to give tickets a sync friendly short name
> which could be used
On 9/5/2013 3:27 AM, David Given wrote:
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.
Personally I use them almost ent
On Thu, Sep 5, 2013 at 7:59 PM, Ross Berteig wrote:
> Mitigating the long hex problem for me is the fact that none of my
> projects have lasted long enough to grow to the point were using more than
> 4 to 6 digits of hash prefix feels dangerous.
>
i'm not 100% sure my query is right (i'm no SQL
Can tickets be tagged? A quick browse of the tickets page and I conclude
the answer is probably no. If tickets could be tagged similar to the
timeline then tags could be used to give tickets a sync friendly short name
which could be used in the ticket listings and when discussing the tickets.
The
Richard Hipp wrote:
[...]
> I think the above doesn't really work for an application like Fossil. I
> think that a prefix of the SHA1 hash should encode to a prefix of the
> mnemonic, and the other way arround too - a prefix of the mnemonic
> should decode back to a prefix of the original hash.
[.
On Thu, Sep 5, 2013 at 6:27 AM, David Given wrote:
> playing with the encoder I see that:
>
> 12345678 = CRASH CHAPTER CASINO
> 123456 = ROVER TRIBAL EGO
> 1234 = JAMES ACTIVE
> 12 = ALCOHOL
>
I think the above doesn't really work for an application like Fossil. I
think that a pref
On Thu, Sep 5, 2013 at 12:27 PM, David Given wrote:
> 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.
>
i think we
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 i
On 9/4/2013 2:40 PM, Stephan Beal wrote:
On Wed, Sep 4, 2013 at 11:07 PM, David Given wrote:
I'd appreciate any comments --- including any suggestions as to whether
this is actually a useful feature. I, personally, find these things
vastly easier to handle than 8-character hex string
On Wed, Sep 4, 2013 at 11:07 PM, David Given wrote:
> I'd appreciate any comments --- including any suggestions as to whether
> this is actually a useful feature. I, personally, find these things
> vastly easier to handle than 8-character hex strings. However I hear
> rumours that other peoples'
Based on various conversations in the past I have been working on a
semi-interesting features: using mnemonic encoding to turn ticket hashes
into something that humans can remember.
This uses a built-in dictionary to convert a hex hash (e.g. '74a95e62')
into a series of words ('TOAST MOZART TULIP'
29 matches
Mail list logo
