Hi KC,
> I’d like to use Irmin RW store to implement a simple timestamp based
> last-writer-wins register. While the type of Irmin.AO_MAKER = functor (K :
> Irmin.Hash.S) (V : Tc.S0) -> … is understandable, the type of Irmin.RW_MAKER
> = (K : Irmin.Hum.S) (V : Irmin.Hash.S) -> … is not intuitive. Why is the type
> of K and V not the same as in AO_MAKER? Why should the type of value be a
> Hash.S?
In a AO (append-only) store, you need to compute keys from values in a
deterministic way[1], so you need a hashable keys. The type of V should be
Hum.S in RW though, it was just more convenient to keep it this way in few
places (because usually the RW store is the one associating branch names to
commit hashes). I've created [2] to keep track of that.
[1] http://mirage.github.io/irmin/Irmin.AO.html#Valadd
<http://mirage.github.io/irmin/Irmin.AO.html#Valadd>
[2] https://github.com/mirage/irmin/issues/158
<https://github.com/mirage/irmin/issues/158>
> I also witness surprising behaviour for any non-string keys with Git memory
> backend. See the code below. Are there any restrictions with the use of RW
> stores?
That's a bug[3] in the Git RW backend, it tries to re-use the full backend in a
not-so-clever way, which tries to read the master branch. I need to fix this.
In the meantime, you can use the other backends:
replace:
module Git = Irmin_git.RW(Git.Memory)
by either:
module Git = Irmin_mem.RW (* in-memory store *)
module Git = Irmin_unix.Irmin_fs.RW (* on-disk with custom binary format *)
and your test program will work.
[3] https://github.com/mirage/irmin/issues/159
<https://github.com/mirage/irmin/issues/159>
Thanks,
Thomas
_______________________________________________
MirageOS-devel mailing list
[email protected]
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
