[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] Question: Diff between 2 commits in Irmin

On 12 November 2016 at 07:29, Gabriel Jaldon <gjaldon85@xxxxxxxxx> wrote:
> Thanks a lot for the great example! I was able to follow it and use most of
> it for the feature I want to implement in Canopy. Was recently wondering
> about whether OCaml had  a `Show` typeclass like in Haskell and saw
> Mirage-TC and TC being used all over Irmin but didn't really get how to
> print types/values for debugging. `of_hum` and `to_hum` look like exactly
> the ones I need!

Unlike in Haskell, OCaml doesn't automatically work out which printer
to use, so you have to tell it. `to_hum` just returns a string that
you can print as normal. Another common pattern is to use the %a
format and provide a formatting function, e.g.

let x = Thing.make () in
Format.printf "x=%a@." Thing.pp x

https://github.com/whitequark/ppx_deriving provides a syntax extension
to create printers automatically.

http://erratique.ch/software/fmt provides a much nicer API to the
standard Format module.

>  About diffs, how do I access the contents of View.value in the diff ``Added
> value`?

It's just a value of the store. e.g. if your store stores strings,
then the type `value` is `string`.
If you take a VIEW as an argument, you might need to specify that you
depend on value having some particular type (e.g. `module VIEW with
type value = string`).

> Also, where does `task` come from in the line `S.of_commit_id task c
> repo >>= fun t ->`? `task` there is not an argument and doesn't look like a
> function (is it?).

Task is a function, and it's the first argument to `of_commit_id`.
Irmin_unix.task is a common choice (it adds Unix timestamps to

> The datakit project looks really interesting. I've looked at it several
> times already since I first read it in this blog post by Anil
> https://blog.docker.com/2016/05/docker-unikernels-open-source/ months ago.
> (Btw, I've used Docker for Mac since it was in beta and it was great to be
> able to use Docker without having to use docker-machine.) Would love to dive
> into datakit source some more and get familiar with it eventually. What
> makes it ideal to build CI using Datakit?

For example, the results of a build are usually most naturally
expressed as a tree of files, which can be committed to a Git branch.
Each results branch has a history, which can be used to see previous
builds if you do a rebuild.
The results repository can be sync'd to GitHub and cloned by other
people for analysis.

> On Fri, Nov 11, 2016 at 7:04 AM, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx>
> wrote:
>> Hi,
>> >
>> > I'm trying to generate a list of 10-20 most recent events in Canopy.
>> > These events would be changes done to Articles (modifications, deletions,
>> > additions). I'd like to get the changes introduced by each commit from
>> > latest to the earliest. How do I do that in Irmin?
>> >
>> > Will `Irmin.View.diff` help me do the above? If so, how do I get a type
>> > `t` that it expects as its first 2 arguments? What is `t` in that context?
>> > https://github.com/mirage/irmin/blob/master/lib/ir_view.mli#L42
>> The online API doc is probably better to read that the (internal) mli
>> file:
>> http://mirage.github.io/irmin/Irmin.View.html
>> Here a (simple?) example on how to use that API:
>> ```diff.ml
>> open Lwt.Infix
>> open Irmin_unix
>> module S =
>>   Irmin_git.FS(Irmin.Contents.String)(Irmin.Ref.String)(Irmin.Hash.SHA1)
>> module V = Irmin.View(S)
>> let view_of_commit repo c =
>>   S.of_commit_id task c repo >>= fun t ->
>>   V.of_path (t "view") []
>> let diff repo c1 c2 =
>>   view_of_commit repo c1 >>= fun v1 ->
>>   view_of_commit repo c2 >>= fun v2 ->
>>   V.diff v1 v2 >|= fun diff ->
>>   List.iter (function
>>       | k, `Added _   -> Printf.printf "+ %s\n%!" (S.Key.to_hum k)
>>       | k, `Updated _ -> Printf.printf "* %s\n%!" (S.Key.to_hum k)
>>       | k, `Removed _ -> Printf.printf "- %s\n%!" (S.Key.to_hum k)
>>     ) diff
>> let () =
>>   let c1 = S.Hash.of_hum Sys.argv.(1) in
>>   let c2 = S.Hash.of_hum Sys.argv.(2) in
>>   Lwt_main.run begin
>>     S.Repo.create (Irmin_git.config ~root:"." ()) >>= fun repo ->
>>     diff repo c1 c2
>>   end
>> ```
>> compile it with:
>> $ ocamlfind ocamlopt -package irmin.unix diff.ml -o diff -linkpkg
>> And then, you can use it in a Git repo:
>> $ git init
>> $ touch a && git add a && git commit -a -m "add a"
>> 167602309fffb440bd44e51cdba2e465df799f23
>> $ touch b && git add b && git commit -a -m "add b"
>> be3c9d683d26e861e32c93b6fa7d17a70f61ee86
>> $ ./diff be3c9d683d26e861e32c93b6fa7d17a70f61ee86
>> 167602309fffb440bd44e51cdba2e465df799f23
>> ./foo be3c9d683d26e861e32c93b6fa7d17a70f61ee86
>> 167602309fffb440bd44e51cdba2e465df799f23
>> + /b
>> > Btw, what are open-source projects that are great examples of how to use
>> > Irmin?
>> At Docker, we use Irmin in datakit at Docker:
>> https://github.com/docker/datakit
>> Datakit is an in-memory VFS which can be mounted as a normal filesystem
>> (currently we only support 9p, but it should be doable to use fuse too) and
>> which uses Irmin to persist data. We use it in Docker for Mac and Docker for
>> Windows[1] to exposes configuration data stored in a Git repository on the
>> host (Window or OSX) into a FS mount in a Linux VM (running the Docker
>> daemon)[2]. We also use it for our internal CI to coordinate build
>> pipelines[3] -- we plan to use it to test MirageOS too[4].
>> Best,
>> Thomas
>> [1]: https://www.docker.com/products/docker#/mac
>> [2]: https://github.com/docker/hyperkit
>> [3]: https://github.com/docker/datakit/tree/master/ci
>> [4]: https://github.com/avsm/mirage-ci
> --
> Gabe Jaldon
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

talex5 (GitHub/Twitter)        http://roscidus.com/blog/
GPG: 5DD5 8D70 899C 454A 966D  6A51 7513 3C8F 94F6 E0CC
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.