From mirageos-devel-bounces@lists.xenproject.org Sun Mar 01 11:41:09 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 01 Mar 2015 11:41:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YS2F2-0001fd-Mf; Sun, 01 Mar 2015 11:41:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YS2F2-0001dW-77 for mirageos-devel@lists.xenproject.org; Sun, 01 Mar 2015 11:41:00 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id 12/7F-02995-BCAF2F45; Sun, 01 Mar 2015 11:40:59 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-2.tower-31.messagelabs.com!1425210058!11954986!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23765 invoked from network); 1 Mar 2015 11:40:58 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Mar 2015 11:40:58 -0000 Received: from [192.168.1.69] (cpc7-cmbg14-2-0-cust238.5-4.cable.virginm.net [86.30.244.239]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id dff85ff2; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Sun, 1 Mar 2015 11:40:57 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Anil Madhavapeddy In-Reply-To: Date: Sun, 1 Mar 2015 11:40:56 +0000 Message-Id: <65272965-FCF5-456A-A2A4-DBDBDA1CF5B4@recoil.org> References: To: Trevor Smith X-Mailer: Apple Mail (2.2070.6) Cc: mirageos-devel@lists.xenproject.org Subject: Re: [MirageOS-devel] ocaml-cohttp, async and https X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 28 Feb 2015, at 14:19, Trevor Smith wrote: > > Hello, > > I am not sure if this is the right mailing list for this. > > I am looking to use ocaml cohttp with async and https in a production setting. I could not find any examples online that demonstrate this. Could someone please point me to some examples? I am happy to contribute my findings back into the ocaml-cohttp codebase as an example. Hi Trevor, The example webserver in cohttp/bin/cohttp_server_async.ml doesn't currently support SSL, but adding support for it is pretty straightforward. You just need to pass a ~mode argument to the Server.create with something of this type: | `OpenSSL of [ `Crt_file_path of string ] * [ `Key_file_path of string ] | `TCP It currently defaults to TCP, so just extend the command line parsing to add a key/crt option, and the SSL serving should just work. Patches very welcome, or if you can't do this then feel free to create an issue on https://github.com/mirage/ocaml-cohttp/issues. cheers, Anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sun Mar 01 11:41:09 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 01 Mar 2015 11:41:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YS2F2-0001fd-Mf; Sun, 01 Mar 2015 11:41:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YS2F2-0001dW-77 for mirageos-devel@lists.xenproject.org; Sun, 01 Mar 2015 11:41:00 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id 12/7F-02995-BCAF2F45; Sun, 01 Mar 2015 11:40:59 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-2.tower-31.messagelabs.com!1425210058!11954986!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23765 invoked from network); 1 Mar 2015 11:40:58 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Mar 2015 11:40:58 -0000 Received: from [192.168.1.69] (cpc7-cmbg14-2-0-cust238.5-4.cable.virginm.net [86.30.244.239]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id dff85ff2; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Sun, 1 Mar 2015 11:40:57 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Anil Madhavapeddy In-Reply-To: Date: Sun, 1 Mar 2015 11:40:56 +0000 Message-Id: <65272965-FCF5-456A-A2A4-DBDBDA1CF5B4@recoil.org> References: To: Trevor Smith X-Mailer: Apple Mail (2.2070.6) Cc: mirageos-devel@lists.xenproject.org Subject: Re: [MirageOS-devel] ocaml-cohttp, async and https X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 28 Feb 2015, at 14:19, Trevor Smith wrote: > > Hello, > > I am not sure if this is the right mailing list for this. > > I am looking to use ocaml cohttp with async and https in a production setting. I could not find any examples online that demonstrate this. Could someone please point me to some examples? I am happy to contribute my findings back into the ocaml-cohttp codebase as an example. Hi Trevor, The example webserver in cohttp/bin/cohttp_server_async.ml doesn't currently support SSL, but adding support for it is pretty straightforward. You just need to pass a ~mode argument to the Server.create with something of this type: | `OpenSSL of [ `Crt_file_path of string ] * [ `Key_file_path of string ] | `TCP It currently defaults to TCP, so just extend the command line parsing to add a key/crt option, and the SSL serving should just work. Patches very welcome, or if you can't do this then feel free to create an issue on https://github.com/mirage/ocaml-cohttp/issues. cheers, Anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sun Mar 01 14:46:57 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 01 Mar 2015 14:46:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YS58q-0001yp-En; Sun, 01 Mar 2015 14:46:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YS58p-0001yk-D0 for mirageos-devel@lists.xenproject.org; Sun, 01 Mar 2015 14:46:47 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id FB/C2-02995-65623F45; Sun, 01 Mar 2015 14:46:46 +0000 X-Env-Sender: trevorsummerssmith@gmail.com X-Msg-Ref: server-6.tower-31.messagelabs.com!1425221204!7540754!1 X-Originating-IP: [209.85.216.179] X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3600 invoked from network); 1 Mar 2015 14:46:45 -0000 Received: from mail-qc0-f179.google.com (HELO mail-qc0-f179.google.com) (209.85.216.179) by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 1 Mar 2015 14:46:45 -0000 Received: by qcxr5 with SMTP id r5so20895430qcx.13 for ; Sun, 01 Mar 2015 06:46:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=uWEftygWVEBlbI8+YkEwWR4qEUQl6azPuIgKxH+kHj4=; b=n5NKJV2vE4w3g/197bCeBxyTED9stxUGfDQZOHUQI8E9CY1EBnxdVHUxXj4pCJm3qM V+salstst7DkS4mHZ+g8i01AHBajg1hwSAYnZdDfsxH+Q8GrK7DuqRk99GJQCW7O/9ro Nl6+XTwVt/XM15s0H+vh5ZkORw+OS3/zWPogOXDQsSgqCMOmTe6oiK19AwO9NkuPh0Zp etNPvScZs+tNPEhcfXd2V5DctmgEn/N4TPDJ9jvi2QIrhiw31X0UC3TZAYcL10TDEiMF JmFADn4dgrmMvD/LEcLXyxtqWfUtCdoqvzWWdV54QoyfdDEbDy924x0/Zgz48BTzLbj6 78kw== X-Received: by 10.140.96.139 with SMTP id k11mr42246784qge.102.1425221204078; Sun, 01 Mar 2015 06:46:44 -0800 (PST) MIME-Version: 1.0 From: Trevor Smith Date: Sun, 01 Mar 2015 14:46:43 +0000 Message-ID: To: "mirageos-devel@lists.xenproject.org" , Zachary Newman Subject: [MirageOS-devel] Help us with OCaml Libuv X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5346655508844905291==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============5346655508844905291== Content-Type: multipart/alternative; boundary=001a113a5a7c98749d05103b2bc5 --001a113a5a7c98749d05103b2bc5 Content-Type: text/plain; charset=UTF-8 Hello, A while back on the OCaml mailing list Anil mentioned that it would be useful to have a "a Ctypes binding to libuv, since that could provide the basis for an excellent platform-independent I/O library as an alternative to the Unix". Zack and I have done the initial legwork required to get this off the ground. We are at a point now where we need some user input. We currently have the file system module working (tested for our unit tests and some basic example code). We're looking for anyone who would like to try this code on. Once we get some feedback, and if this work seems useful to the community, we will implement the rest of the functionality provided by libuv. We had targeted the initial work towards "framework users" -- that is, fiber, mirage, async, lwt, so the api is meant to be straightforward. Libuv homepage: https://github.com/libuv/libuv Our port: https://github.com/trevorsummerssmith/ocaml-libuv Please reach out with questions and if you are interested in using this work. Thank you. Trevor --001a113a5a7c98749d05103b2bc5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

A while back on the OCaml mailin= g list Anil mentioned that it would be useful to have a "a Ctypes b= inding to libuv, since that could provide the basis for an=C2=A0exc= ellent platform-independent I/O library as an alternative to the Unix"= .

Zack and I have done the initial legwork required to get this= off the ground.

= We are at a point now where we need some user input. We currently have the = file system module working (tested for our unit tests and some basic exampl= e code). We're looking for anyone who would like to try this code on. O= nce we get some feedback, and if this work seems useful to the community, w= e will implement the rest of the functionality provided by libuv. We had ta= rgeted the initial work towards "framework users" -- that is, fib= er, mirage, async, lwt, so the api is meant to be straightforward.

Libuv homepage:=C2=A0https://github.com/libuv/libuv

Please reach out with questions and if you are i= nterested in using this work.

Thank you.

Trevor
--001a113a5a7c98749d05103b2bc5-- --===============5346655508844905291== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============5346655508844905291==-- From mirageos-devel-bounces@lists.xenproject.org Sun Mar 01 14:46:57 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 01 Mar 2015 14:46:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YS58q-0001yp-En; Sun, 01 Mar 2015 14:46:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YS58p-0001yk-D0 for mirageos-devel@lists.xenproject.org; Sun, 01 Mar 2015 14:46:47 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id FB/C2-02995-65623F45; Sun, 01 Mar 2015 14:46:46 +0000 X-Env-Sender: trevorsummerssmith@gmail.com X-Msg-Ref: server-6.tower-31.messagelabs.com!1425221204!7540754!1 X-Originating-IP: [209.85.216.179] X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3600 invoked from network); 1 Mar 2015 14:46:45 -0000 Received: from mail-qc0-f179.google.com (HELO mail-qc0-f179.google.com) (209.85.216.179) by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 1 Mar 2015 14:46:45 -0000 Received: by qcxr5 with SMTP id r5so20895430qcx.13 for ; Sun, 01 Mar 2015 06:46:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=uWEftygWVEBlbI8+YkEwWR4qEUQl6azPuIgKxH+kHj4=; b=n5NKJV2vE4w3g/197bCeBxyTED9stxUGfDQZOHUQI8E9CY1EBnxdVHUxXj4pCJm3qM V+salstst7DkS4mHZ+g8i01AHBajg1hwSAYnZdDfsxH+Q8GrK7DuqRk99GJQCW7O/9ro Nl6+XTwVt/XM15s0H+vh5ZkORw+OS3/zWPogOXDQsSgqCMOmTe6oiK19AwO9NkuPh0Zp etNPvScZs+tNPEhcfXd2V5DctmgEn/N4TPDJ9jvi2QIrhiw31X0UC3TZAYcL10TDEiMF JmFADn4dgrmMvD/LEcLXyxtqWfUtCdoqvzWWdV54QoyfdDEbDy924x0/Zgz48BTzLbj6 78kw== X-Received: by 10.140.96.139 with SMTP id k11mr42246784qge.102.1425221204078; Sun, 01 Mar 2015 06:46:44 -0800 (PST) MIME-Version: 1.0 From: Trevor Smith Date: Sun, 01 Mar 2015 14:46:43 +0000 Message-ID: To: "mirageos-devel@lists.xenproject.org" , Zachary Newman Subject: [MirageOS-devel] Help us with OCaml Libuv X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5346655508844905291==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============5346655508844905291== Content-Type: multipart/alternative; boundary=001a113a5a7c98749d05103b2bc5 --001a113a5a7c98749d05103b2bc5 Content-Type: text/plain; charset=UTF-8 Hello, A while back on the OCaml mailing list Anil mentioned that it would be useful to have a "a Ctypes binding to libuv, since that could provide the basis for an excellent platform-independent I/O library as an alternative to the Unix". Zack and I have done the initial legwork required to get this off the ground. We are at a point now where we need some user input. We currently have the file system module working (tested for our unit tests and some basic example code). We're looking for anyone who would like to try this code on. Once we get some feedback, and if this work seems useful to the community, we will implement the rest of the functionality provided by libuv. We had targeted the initial work towards "framework users" -- that is, fiber, mirage, async, lwt, so the api is meant to be straightforward. Libuv homepage: https://github.com/libuv/libuv Our port: https://github.com/trevorsummerssmith/ocaml-libuv Please reach out with questions and if you are interested in using this work. Thank you. Trevor --001a113a5a7c98749d05103b2bc5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

A while back on the OCaml mailin= g list Anil mentioned that it would be useful to have a "a Ctypes b= inding to libuv, since that could provide the basis for an=C2=A0exc= ellent platform-independent I/O library as an alternative to the Unix"= .

Zack and I have done the initial legwork required to get this= off the ground.

= We are at a point now where we need some user input. We currently have the = file system module working (tested for our unit tests and some basic exampl= e code). We're looking for anyone who would like to try this code on. O= nce we get some feedback, and if this work seems useful to the community, w= e will implement the rest of the functionality provided by libuv. We had ta= rgeted the initial work towards "framework users" -- that is, fib= er, mirage, async, lwt, so the api is meant to be straightforward.

Libuv homepage:=C2=A0https://github.com/libuv/libuv

Please reach out with questions and if you are i= nterested in using this work.

Thank you.

Trevor
--001a113a5a7c98749d05103b2bc5-- --===============5346655508844905291== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============5346655508844905291==-- From mirageos-devel-bounces@lists.xenproject.org Sun Mar 01 18:47:50 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 01 Mar 2015 18:47:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YS8u0-0004jH-Po; Sun, 01 Mar 2015 18:47:44 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YS8tz-0004jA-4C for mirageos-devel@lists.xenproject.org; Sun, 01 Mar 2015 18:47:43 +0000 Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id 2A/12-03164-ECE53F45; Sun, 01 Mar 2015 18:47:42 +0000 X-Env-Sender: trevorsummerssmith@gmail.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1425235660!13726994!1 X-Originating-IP: [209.85.192.42] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4316 invoked from network); 1 Mar 2015 18:47:40 -0000 Received: from mail-qg0-f42.google.com (HELO mail-qg0-f42.google.com) (209.85.192.42) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Mar 2015 18:47:40 -0000 Received: by mail-qg0-f42.google.com with SMTP id z60so3120902qgd.1 for ; Sun, 01 Mar 2015 10:47:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C+duExL0pm5k9IOss3Ds/I6xZ8FEbx65D7EibDN82qI=; b=T1P2Mw6U+om13vz8Lgg3HaoGsu1cY/YS1kSMcFC/+0kGHpg0//9ymR3B+R8aGmrpa1 7AlALORFMlc0mnZH0NMCdXPgAZXgtQ9Wu6NaNUXIb7npj2aRN6/hLsFWEKYJCKVqzgFg EGUa8abEVIamm4PFf2w5rva7sh7ih0rbsRDtCvS4CrnJLMIDkRQ6EvqquEWsWgoxIeS1 oWQyxokP0kRFdvuQ/M9EoTni6xp/6E36DCuGL8m1s+YcM6uA4tLf2CGiq/4LcrRvhUZn N7jKz+BMdndEwj4W0+A687xVTJxxZnlQF/vHazhPL19OuzRtPtceYgZQiqzR2XeI9aby mafQ== MIME-Version: 1.0 X-Received: by 10.140.235.65 with SMTP id g62mr46384433qhc.30.1425235659838; Sun, 01 Mar 2015 10:47:39 -0800 (PST) Received: by 10.229.240.68 with HTTP; Sun, 1 Mar 2015 10:47:39 -0800 (PST) In-Reply-To: <65272965-FCF5-456A-A2A4-DBDBDA1CF5B4@recoil.org> References: <65272965-FCF5-456A-A2A4-DBDBDA1CF5B4@recoil.org> Date: Sun, 1 Mar 2015 13:47:39 -0500 Message-ID: From: Trevor Smith To: Anil Madhavapeddy Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] ocaml-cohttp, async and https X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3801342419855165983==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============3801342419855165983== Content-Type: multipart/alternative; boundary=001a11355fd239f49f05103e891b --001a11355fd239f49f05103e891b Content-Type: text/plain; charset=UTF-8 Thanks Anil! On Sun, Mar 1, 2015 at 6:40 AM, Anil Madhavapeddy wrote: > On 28 Feb 2015, at 14:19, Trevor Smith > wrote: > > > > Hello, > > > > I am not sure if this is the right mailing list for this. > > > > I am looking to use ocaml cohttp with async and https in a production > setting. I could not find any examples online that demonstrate this. Could > someone please point me to some examples? I am happy to contribute my > findings back into the ocaml-cohttp codebase as an example. > > Hi Trevor, > > The example webserver in cohttp/bin/cohttp_server_async.ml doesn't > currently support SSL, but adding support for it is pretty > straightforward. You just need to pass a ~mode argument to the > Server.create with something of this type: > > | `OpenSSL of > [ `Crt_file_path of string ] * > [ `Key_file_path of string ] > | `TCP > > It currently defaults to TCP, so just extend the command line parsing to > add a key/crt option, and the SSL serving should just work. Patches very > welcome, or if you can't do this then feel free to create an issue on > https://github.com/mirage/ocaml-cohttp/issues. > > cheers, > Anil --001a11355fd239f49f05103e891b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Anil!

On Sun, Mar 1, 2015 at 6:40 AM, Anil Madhavapeddy <anil@re= coil.org> wrote:
On 28 Feb 2015, at 14:19, Trevor Smith <trevorsummerssmith@gmail.com> wrote:
>
> Hello,
>
> I am not sure if this is the right mailing list for this.
>
> I am looking to use ocaml cohttp with async and https in a production = setting. I could not find any examples online that demonstrate this. Could = someone please point me to some examples? I am happy to contribute my findi= ngs back into the ocaml-cohttp codebase as an example.

Hi Trevor,

The example webserver in cohttp/bin/cohttp_server_async.ml doesn't currently suppo= rt SSL, but adding support for it is pretty straightforward.=C2=A0 You just= need to pass a ~mode argument to the Server.create with something of this = type:

=C2=A0 | `OpenSSL of
=C2=A0 =C2=A0 [ `Crt_file_path of string ] *
=C2=A0 =C2=A0 [ `Key_file_path of string ]
=C2=A0 | `TCP

It currently defaults to TCP, so just extend the command line parsing to ad= d a key/crt option, and the SSL serving should just work.=C2=A0 Patches ver= y welcome, or if you can't do this then feel free to create an issue on= https://github.com/mirage/ocaml-cohttp/issues.

cheers,
Anil

--001a11355fd239f49f05103e891b-- --===============3801342419855165983== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============3801342419855165983==-- From mirageos-devel-bounces@lists.xenproject.org Sun Mar 01 18:47:50 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 01 Mar 2015 18:47:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YS8u0-0004jH-Po; Sun, 01 Mar 2015 18:47:44 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YS8tz-0004jA-4C for mirageos-devel@lists.xenproject.org; Sun, 01 Mar 2015 18:47:43 +0000 Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id 2A/12-03164-ECE53F45; Sun, 01 Mar 2015 18:47:42 +0000 X-Env-Sender: trevorsummerssmith@gmail.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1425235660!13726994!1 X-Originating-IP: [209.85.192.42] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4316 invoked from network); 1 Mar 2015 18:47:40 -0000 Received: from mail-qg0-f42.google.com (HELO mail-qg0-f42.google.com) (209.85.192.42) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Mar 2015 18:47:40 -0000 Received: by mail-qg0-f42.google.com with SMTP id z60so3120902qgd.1 for ; Sun, 01 Mar 2015 10:47:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C+duExL0pm5k9IOss3Ds/I6xZ8FEbx65D7EibDN82qI=; b=T1P2Mw6U+om13vz8Lgg3HaoGsu1cY/YS1kSMcFC/+0kGHpg0//9ymR3B+R8aGmrpa1 7AlALORFMlc0mnZH0NMCdXPgAZXgtQ9Wu6NaNUXIb7npj2aRN6/hLsFWEKYJCKVqzgFg EGUa8abEVIamm4PFf2w5rva7sh7ih0rbsRDtCvS4CrnJLMIDkRQ6EvqquEWsWgoxIeS1 oWQyxokP0kRFdvuQ/M9EoTni6xp/6E36DCuGL8m1s+YcM6uA4tLf2CGiq/4LcrRvhUZn N7jKz+BMdndEwj4W0+A687xVTJxxZnlQF/vHazhPL19OuzRtPtceYgZQiqzR2XeI9aby mafQ== MIME-Version: 1.0 X-Received: by 10.140.235.65 with SMTP id g62mr46384433qhc.30.1425235659838; Sun, 01 Mar 2015 10:47:39 -0800 (PST) Received: by 10.229.240.68 with HTTP; Sun, 1 Mar 2015 10:47:39 -0800 (PST) In-Reply-To: <65272965-FCF5-456A-A2A4-DBDBDA1CF5B4@recoil.org> References: <65272965-FCF5-456A-A2A4-DBDBDA1CF5B4@recoil.org> Date: Sun, 1 Mar 2015 13:47:39 -0500 Message-ID: From: Trevor Smith To: Anil Madhavapeddy Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] ocaml-cohttp, async and https X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3801342419855165983==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============3801342419855165983== Content-Type: multipart/alternative; boundary=001a11355fd239f49f05103e891b --001a11355fd239f49f05103e891b Content-Type: text/plain; charset=UTF-8 Thanks Anil! On Sun, Mar 1, 2015 at 6:40 AM, Anil Madhavapeddy wrote: > On 28 Feb 2015, at 14:19, Trevor Smith > wrote: > > > > Hello, > > > > I am not sure if this is the right mailing list for this. > > > > I am looking to use ocaml cohttp with async and https in a production > setting. I could not find any examples online that demonstrate this. Could > someone please point me to some examples? I am happy to contribute my > findings back into the ocaml-cohttp codebase as an example. > > Hi Trevor, > > The example webserver in cohttp/bin/cohttp_server_async.ml doesn't > currently support SSL, but adding support for it is pretty > straightforward. You just need to pass a ~mode argument to the > Server.create with something of this type: > > | `OpenSSL of > [ `Crt_file_path of string ] * > [ `Key_file_path of string ] > | `TCP > > It currently defaults to TCP, so just extend the command line parsing to > add a key/crt option, and the SSL serving should just work. Patches very > welcome, or if you can't do this then feel free to create an issue on > https://github.com/mirage/ocaml-cohttp/issues. > > cheers, > Anil --001a11355fd239f49f05103e891b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Anil!

On Sun, Mar 1, 2015 at 6:40 AM, Anil Madhavapeddy <anil@re= coil.org> wrote:
On 28 Feb 2015, at 14:19, Trevor Smith <trevorsummerssmith@gmail.com> wrote:
>
> Hello,
>
> I am not sure if this is the right mailing list for this.
>
> I am looking to use ocaml cohttp with async and https in a production = setting. I could not find any examples online that demonstrate this. Could = someone please point me to some examples? I am happy to contribute my findi= ngs back into the ocaml-cohttp codebase as an example.

Hi Trevor,

The example webserver in cohttp/bin/cohttp_server_async.ml doesn't currently suppo= rt SSL, but adding support for it is pretty straightforward.=C2=A0 You just= need to pass a ~mode argument to the Server.create with something of this = type:

=C2=A0 | `OpenSSL of
=C2=A0 =C2=A0 [ `Crt_file_path of string ] *
=C2=A0 =C2=A0 [ `Key_file_path of string ]
=C2=A0 | `TCP

It currently defaults to TCP, so just extend the command line parsing to ad= d a key/crt option, and the SSL serving should just work.=C2=A0 Patches ver= y welcome, or if you can't do this then feel free to create an issue on= https://github.com/mirage/ocaml-cohttp/issues.

cheers,
Anil

--001a11355fd239f49f05103e891b-- --===============3801342419855165983== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============3801342419855165983==-- From mirageos-devel-bounces@lists.xenproject.org Mon Mar 02 02:07:24 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 02 Mar 2015 02:07:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YSFlP-0004sZ-0d; Mon, 02 Mar 2015 02:07:19 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YSFlN-0004sU-MR for mirageos-devel@lists.xenproject.org; Mon, 02 Mar 2015 02:07:17 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id EF/88-03172-4D5C3F45; Mon, 02 Mar 2015 02:07:16 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-3.tower-27.messagelabs.com!1425262035!13677790!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22888 invoked from network); 2 Mar 2015 02:07:16 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-3.tower-27.messagelabs.com with SMTP; 2 Mar 2015 02:07:16 -0000 Received: from [172.20.10.2] (254.235.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch [178.197.235.254]) by smtp.webfaction.com (Postfix) with ESMTP id D012A20D6BA3 for ; Mon, 2 Mar 2015 02:07:14 +0000 (UTC) Date: Mon, 2 Mar 2015 03:07:11 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: "mirageos-devel@lists.xenproject.org" Message-ID: <2A0347CF598A4081B45318903375F7A9@erratique.ch> In-Reply-To: <87lhk4csew.fsf@study.localdomain> References: <20150202.014549.1883720051237442569.Christophe.Troestler@umons.ac.be> <20150204.001614.26478837567139584.Christophe.Troestler@umons.ac.be> <87oap97rvw.fsf@study.localdomain> <87lhk4csew.fsf@study.localdomain> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [MirageOS-devel] Error handling in Mirage - request for comments! X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Since I have been devising error handling combinators initially for assemblage and that I'm now using them in other projects, it seems in the end that having a basic result package maybe useful. I have devised one here: http://erratique.ch/software/result Comments on the interface are welcome (use the github bt). Example of use can be seen here [1]. One thing that may change is that the type Result.result will maybe switch to a regular variant. Best, Daniel [1] https://github.com/dbuenzli/bos/blob/97ae720554cba69d77005365f2a619db82f9670d/src/bos_os.ml _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Mar 02 02:07:24 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 02 Mar 2015 02:07:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YSFlP-0004sZ-0d; Mon, 02 Mar 2015 02:07:19 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YSFlN-0004sU-MR for mirageos-devel@lists.xenproject.org; Mon, 02 Mar 2015 02:07:17 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id EF/88-03172-4D5C3F45; Mon, 02 Mar 2015 02:07:16 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-3.tower-27.messagelabs.com!1425262035!13677790!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22888 invoked from network); 2 Mar 2015 02:07:16 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-3.tower-27.messagelabs.com with SMTP; 2 Mar 2015 02:07:16 -0000 Received: from [172.20.10.2] (254.235.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch [178.197.235.254]) by smtp.webfaction.com (Postfix) with ESMTP id D012A20D6BA3 for ; Mon, 2 Mar 2015 02:07:14 +0000 (UTC) Date: Mon, 2 Mar 2015 03:07:11 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: "mirageos-devel@lists.xenproject.org" Message-ID: <2A0347CF598A4081B45318903375F7A9@erratique.ch> In-Reply-To: <87lhk4csew.fsf@study.localdomain> References: <20150202.014549.1883720051237442569.Christophe.Troestler@umons.ac.be> <20150204.001614.26478837567139584.Christophe.Troestler@umons.ac.be> <87oap97rvw.fsf@study.localdomain> <87lhk4csew.fsf@study.localdomain> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [MirageOS-devel] Error handling in Mirage - request for comments! X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Since I have been devising error handling combinators initially for assemblage and that I'm now using them in other projects, it seems in the end that having a basic result package maybe useful. I have devised one here: http://erratique.ch/software/result Comments on the interface are welcome (use the github bt). Example of use can be seen here [1]. One thing that may change is that the type Result.result will maybe switch to a regular variant. Best, Daniel [1] https://github.com/dbuenzli/bos/blob/97ae720554cba69d77005365f2a619db82f9670d/src/bos_os.ml _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Mar 03 15:06:15 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 03 Mar 2015 15:06:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YSoOf-0003Iv-Iy; Tue, 03 Mar 2015 15:06:09 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YSoOe-0003Iq-Ft for mirageos-devel@lists.xenproject.org; Tue, 03 Mar 2015 15:06:08 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id 91/ED-03170-FDDC5F45; Tue, 03 Mar 2015 15:06:07 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-14.tower-27.messagelabs.com!1425395166!14317546!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5252 invoked from network); 3 Mar 2015 15:06:06 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-14.tower-27.messagelabs.com with SMTP; 3 Mar 2015 15:06:06 -0000 Received: from [172.20.10.2] (102.234.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch [178.197.234.102]) by smtp.webfaction.com (Postfix) with ESMTP id 8682E20D11F7 for ; Tue, 3 Mar 2015 15:06:05 +0000 (UTC) Date: Tue, 3 Mar 2015 16:06:01 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: mirageos-devel Message-ID: In-Reply-To: <2A0347CF598A4081B45318903375F7A9@erratique.ch> References: <20150202.014549.1883720051237442569.Christophe.Troestler@umons.ac.be> <20150204.001614.26478837567139584.Christophe.Troestler@umons.ac.be> <87oap97rvw.fsf@study.localdomain> <87lhk4csew.fsf@study.localdomain> <2A0347CF598A4081B45318903375F7A9@erratique.ch> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [MirageOS-devel] Error handling in Mirage - request for comments! X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org TGUgbHVuZGksIDIgbWFycyAyMDE1IMOgIDAzOjA3LCBEYW5pZWwgQsO8bnpsaSBhIMOpY3JpdCA6 Cj4gT25lIHRoaW5nIHRoYXQgbWF5IGNoYW5nZSBpcyB0aGF0IHRoZSB0eXBlIFJlc3VsdC5yZXN1 bHQgd2lsbCBtYXliZSBzd2l0Y2ggdG8gYSByZWd1bGFyIHZhcmlhbnQuCgpUaGlzIGhhcyBub3cg YmVlbiBkb25lIHNpbmNlIGl0IHNlZW1zIHBsYXVzaWJsZSB3ZSdsbCBnZXQgc3VjaCBhIHJlc3Vs dCB0eXBlIGluIHBlcnZhc2l2ZXMgaW4gdGhlIGZ1dHVyZSAoY29udmVyc2lvbiBmdW5jdGlvbnMg dG8gcG9seXZhciByZXN1bHRzIGFyZSBwcm92aWRlZCkuICAKCkFuZCB0aGUgcGFja2FnZSBpcyBu b3cgbmFtZWQgcmVzdWx0diB0byBhdm9pZCBzcXVhdHRpbmcgYSBwb3NzaWJseSBjb3ZldGVkIHRv cGxldmVsIG5hbWUuICAKCmh0dHA6Ly9lcnJhdGlxdWUuY2gvc29mdHdhcmUvcmVzdWx0dgoKQmVz dCwKCkRhbmllbAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpNaXJhZ2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlzdHMueGVu cHJvamVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9s aXN0aW5mby9taXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Tue Mar 03 15:06:15 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 03 Mar 2015 15:06:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YSoOf-0003Iv-Iy; Tue, 03 Mar 2015 15:06:09 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YSoOe-0003Iq-Ft for mirageos-devel@lists.xenproject.org; Tue, 03 Mar 2015 15:06:08 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id 91/ED-03170-FDDC5F45; Tue, 03 Mar 2015 15:06:07 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-14.tower-27.messagelabs.com!1425395166!14317546!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5252 invoked from network); 3 Mar 2015 15:06:06 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-14.tower-27.messagelabs.com with SMTP; 3 Mar 2015 15:06:06 -0000 Received: from [172.20.10.2] (102.234.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch [178.197.234.102]) by smtp.webfaction.com (Postfix) with ESMTP id 8682E20D11F7 for ; Tue, 3 Mar 2015 15:06:05 +0000 (UTC) Date: Tue, 3 Mar 2015 16:06:01 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: mirageos-devel Message-ID: In-Reply-To: <2A0347CF598A4081B45318903375F7A9@erratique.ch> References: <20150202.014549.1883720051237442569.Christophe.Troestler@umons.ac.be> <20150204.001614.26478837567139584.Christophe.Troestler@umons.ac.be> <87oap97rvw.fsf@study.localdomain> <87lhk4csew.fsf@study.localdomain> <2A0347CF598A4081B45318903375F7A9@erratique.ch> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [MirageOS-devel] Error handling in Mirage - request for comments! X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org TGUgbHVuZGksIDIgbWFycyAyMDE1IMOgIDAzOjA3LCBEYW5pZWwgQsO8bnpsaSBhIMOpY3JpdCA6 Cj4gT25lIHRoaW5nIHRoYXQgbWF5IGNoYW5nZSBpcyB0aGF0IHRoZSB0eXBlIFJlc3VsdC5yZXN1 bHQgd2lsbCBtYXliZSBzd2l0Y2ggdG8gYSByZWd1bGFyIHZhcmlhbnQuCgpUaGlzIGhhcyBub3cg YmVlbiBkb25lIHNpbmNlIGl0IHNlZW1zIHBsYXVzaWJsZSB3ZSdsbCBnZXQgc3VjaCBhIHJlc3Vs dCB0eXBlIGluIHBlcnZhc2l2ZXMgaW4gdGhlIGZ1dHVyZSAoY29udmVyc2lvbiBmdW5jdGlvbnMg dG8gcG9seXZhciByZXN1bHRzIGFyZSBwcm92aWRlZCkuICAKCkFuZCB0aGUgcGFja2FnZSBpcyBu b3cgbmFtZWQgcmVzdWx0diB0byBhdm9pZCBzcXVhdHRpbmcgYSBwb3NzaWJseSBjb3ZldGVkIHRv cGxldmVsIG5hbWUuICAKCmh0dHA6Ly9lcnJhdGlxdWUuY2gvc29mdHdhcmUvcmVzdWx0dgoKQmVz dCwKCkRhbmllbAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpNaXJhZ2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlzdHMueGVu cHJvamVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9s aXN0aW5mby9taXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Tue Mar 03 22:32:04 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 03 Mar 2015 22:32:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YSvM5-00076Q-Na; Tue, 03 Mar 2015 22:31:57 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YSvM3-00075c-M0 for MirageOS-devel@lists.xenproject.org; Tue, 03 Mar 2015 22:31:56 +0000 Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id 0B/C0-02601-A5636F45; Tue, 03 Mar 2015 22:31:54 +0000 X-Env-Sender: agarwal1975@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1425421913!14393955!1 X-Originating-IP: [209.85.212.171] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 339 invoked from network); 3 Mar 2015 22:31:53 -0000 Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com) (209.85.212.171) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Mar 2015 22:31:53 -0000 Received: by wivz2 with SMTP id z2so7112009wiv.0 for ; Tue, 03 Mar 2015 14:31:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=228Cmi9utldMpumosytj9ibtz4TZSf7ccDzuUsUmU8w=; b=SECwm9CNeWVOs0wYgmgESslv2MWGqeCHZr6yB//HmFDIT2rDvpJVmT+hAKQceF1y8W NE24BxmKg1zw4kFnKypBC/BVSxnnQAIO/HolKLPXjD/35w3qQh0JXTDciCtbgvGCL/5M ZYLD0GqNHw5iGcfk25FDJAbkUM5rdiQmpWa6N8ALl2cvJXMGupqb6lhTqB5uGMfR/VkN czrJqDH5AGUGiS/cP0Nd24GR1OE5QkB45WTzhb0r3QiR8EYuJe9pxvn1pN66oBBLMmL5 0d05Bf2jpTyGRiBhmPn/vzVhdOVY2nTiG9X5LWkhIMShoPEGds831rSZgtlRMxW1/R94 vaww== X-Received: by 10.180.97.106 with SMTP id dz10mr6838872wib.33.1425421913270; Tue, 03 Mar 2015 14:31:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.15.72 with HTTP; Tue, 3 Mar 2015 14:31:33 -0800 (PST) In-Reply-To: References: <073A0B5C-531B-4B7B-ABA3-1D8A0EC4C4BA@recoil.org> From: Ashish Agarwal Date: Tue, 3 Mar 2015 17:31:33 -0500 Message-ID: To: Anand Patil Cc: Thomas Gazagnaire , "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] COW XML questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3788926253680919216==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============3788926253680919216== Content-Type: multipart/alternative; boundary=f46d0442712ecbb35b051069e699 --f46d0442712ecbb35b051069e699 Content-Type: text/plain; charset=UTF-8 Hi Anand. Any progress on this? Is your repo public? Thanks. On Tue, Jan 6, 2015 at 1:32 PM, Anand Patil wrote: > Hi Anil and Thomas, thanks for the pointers. I'll keep plugging away > at this and will let you know how I get on. > > Anand > > On Tue, Jan 6, 2015 at 7:43 AM, Anil Madhavapeddy wrote: > > On 5 Jan 2015, at 05:56, Anand Patil > wrote: > > > >> In order to learn OCaml and thence Mirage, I've been working a little > >> bit on an automatically generated, complete AWS client along the lines > >> of https://github.com/stripe/aws-go using camlp4. I've got the types > >> generated, and now need to generate to/from XML functions for each > >> record type. > >> > > > > Incidentally, this would be awesomely useful to have. You might also > > want to look at Jyotsna Prakash's (manually written) bindings for > > helper functions that might come in useful: > > > > https://github.com/moonlightdrive/ocaml-ec2 > > > > Feel free to ask here if you run into any blockers. > > > > -anil > > > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > --f46d0442712ecbb35b051069e699 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Anand. Any progress on this? Is your repo public? Thank= s.


On Tue, Jan 6, 2015 at 1:32 PM, Anand Patil <anand.pra= bhakar.patil@gmail.com> wrote:
Hi Anil and Thomas, thanks for the pointers. I'll keep plugging awa= y
at this and will let you know how I get on.

Anand

On Tue, Jan 6, 2015 at 7:43 AM, Anil Madhavapeddy <anil@recoil.org> wrote:
> On 5 Jan 2015, at 05:56, Anand Patil <anand.prabhakar.patil@gmail.com> wrote:
>
>> In order to learn OCaml and thence Mirage, I've been working a= little
>> bit on an automatically generated, complete AWS client along the l= ines
>> of = https://github.com/stripe/aws-go using camlp4. I've got the types >> generated, and now need to generate to/from XML functions for each=
>> record type.
>>
>
> Incidentally, this would be awesomely useful to have.=C2=A0 You might = also
> want to look at Jyotsna Prakash's (manually written) bindings for<= br> > helper functions that might come in useful:
>
> https://github.com/moonlightdrive/ocaml-ec2
>
> Feel free to ask here if you run into any blockers.
>
> -anil
>

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel

--f46d0442712ecbb35b051069e699-- --===============3788926253680919216== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============3788926253680919216==-- From mirageos-devel-bounces@lists.xenproject.org Tue Mar 03 22:32:04 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 03 Mar 2015 22:32:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YSvM5-00076Q-Na; Tue, 03 Mar 2015 22:31:57 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YSvM3-00075c-M0 for MirageOS-devel@lists.xenproject.org; Tue, 03 Mar 2015 22:31:56 +0000 Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id 0B/C0-02601-A5636F45; Tue, 03 Mar 2015 22:31:54 +0000 X-Env-Sender: agarwal1975@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1425421913!14393955!1 X-Originating-IP: [209.85.212.171] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 339 invoked from network); 3 Mar 2015 22:31:53 -0000 Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com) (209.85.212.171) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Mar 2015 22:31:53 -0000 Received: by wivz2 with SMTP id z2so7112009wiv.0 for ; Tue, 03 Mar 2015 14:31:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=228Cmi9utldMpumosytj9ibtz4TZSf7ccDzuUsUmU8w=; b=SECwm9CNeWVOs0wYgmgESslv2MWGqeCHZr6yB//HmFDIT2rDvpJVmT+hAKQceF1y8W NE24BxmKg1zw4kFnKypBC/BVSxnnQAIO/HolKLPXjD/35w3qQh0JXTDciCtbgvGCL/5M ZYLD0GqNHw5iGcfk25FDJAbkUM5rdiQmpWa6N8ALl2cvJXMGupqb6lhTqB5uGMfR/VkN czrJqDH5AGUGiS/cP0Nd24GR1OE5QkB45WTzhb0r3QiR8EYuJe9pxvn1pN66oBBLMmL5 0d05Bf2jpTyGRiBhmPn/vzVhdOVY2nTiG9X5LWkhIMShoPEGds831rSZgtlRMxW1/R94 vaww== X-Received: by 10.180.97.106 with SMTP id dz10mr6838872wib.33.1425421913270; Tue, 03 Mar 2015 14:31:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.15.72 with HTTP; Tue, 3 Mar 2015 14:31:33 -0800 (PST) In-Reply-To: References: <073A0B5C-531B-4B7B-ABA3-1D8A0EC4C4BA@recoil.org> From: Ashish Agarwal Date: Tue, 3 Mar 2015 17:31:33 -0500 Message-ID: To: Anand Patil Cc: Thomas Gazagnaire , "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] COW XML questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3788926253680919216==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============3788926253680919216== Content-Type: multipart/alternative; boundary=f46d0442712ecbb35b051069e699 --f46d0442712ecbb35b051069e699 Content-Type: text/plain; charset=UTF-8 Hi Anand. Any progress on this? Is your repo public? Thanks. On Tue, Jan 6, 2015 at 1:32 PM, Anand Patil wrote: > Hi Anil and Thomas, thanks for the pointers. I'll keep plugging away > at this and will let you know how I get on. > > Anand > > On Tue, Jan 6, 2015 at 7:43 AM, Anil Madhavapeddy wrote: > > On 5 Jan 2015, at 05:56, Anand Patil > wrote: > > > >> In order to learn OCaml and thence Mirage, I've been working a little > >> bit on an automatically generated, complete AWS client along the lines > >> of https://github.com/stripe/aws-go using camlp4. I've got the types > >> generated, and now need to generate to/from XML functions for each > >> record type. > >> > > > > Incidentally, this would be awesomely useful to have. You might also > > want to look at Jyotsna Prakash's (manually written) bindings for > > helper functions that might come in useful: > > > > https://github.com/moonlightdrive/ocaml-ec2 > > > > Feel free to ask here if you run into any blockers. > > > > -anil > > > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > --f46d0442712ecbb35b051069e699 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Anand. Any progress on this? Is your repo public? Thank= s.


On Tue, Jan 6, 2015 at 1:32 PM, Anand Patil <anand.pra= bhakar.patil@gmail.com> wrote:
Hi Anil and Thomas, thanks for the pointers. I'll keep plugging awa= y
at this and will let you know how I get on.

Anand

On Tue, Jan 6, 2015 at 7:43 AM, Anil Madhavapeddy <anil@recoil.org> wrote:
> On 5 Jan 2015, at 05:56, Anand Patil <anand.prabhakar.patil@gmail.com> wrote:
>
>> In order to learn OCaml and thence Mirage, I've been working a= little
>> bit on an automatically generated, complete AWS client along the l= ines
>> of = https://github.com/stripe/aws-go using camlp4. I've got the types >> generated, and now need to generate to/from XML functions for each=
>> record type.
>>
>
> Incidentally, this would be awesomely useful to have.=C2=A0 You might = also
> want to look at Jyotsna Prakash's (manually written) bindings for<= br> > helper functions that might come in useful:
>
> https://github.com/moonlightdrive/ocaml-ec2
>
> Feel free to ask here if you run into any blockers.
>
> -anil
>

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel

--f46d0442712ecbb35b051069e699-- --===============3788926253680919216== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============3788926253680919216==-- From mirageos-devel-bounces@lists.xenproject.org Wed Mar 04 00:02:03 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 04 Mar 2015 00:02:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YSwlA-0004pr-V4; Wed, 04 Mar 2015 00:01:56 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YSwl9-0004lz-D4 for MirageOS-devel@lists.xenproject.org; Wed, 04 Mar 2015 00:01:55 +0000 Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id 72/A3-02896-17B46F45; Wed, 04 Mar 2015 00:01:53 +0000 X-Env-Sender: anand.prabhakar.patil@gmail.com X-Msg-Ref: server-4.tower-31.messagelabs.com!1425427312!12732704!1 X-Originating-IP: [209.85.215.46] X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26493 invoked from network); 4 Mar 2015 00:01:53 -0000 Received: from mail-la0-f46.google.com (HELO mail-la0-f46.google.com) (209.85.215.46) by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2015 00:01:53 -0000 Received: by labgq15 with SMTP id gq15so41111883lab.6 for ; Tue, 03 Mar 2015 16:01:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=I5dsWgDMGe2ilxk/4eV6ohN1bmbxAS3nrXGxl3Q6qtI=; b=mX6J1ideIXcbAN3SV72Aq7M9LGqzmXqPunDJt455dbsPlwF/pyDfZc+VLEaNsPJaut twfH7OClp49qKlpNxOMPaKQ4hW44bvNXLjINs2aaJ5cHkg62GMClA1mH+nTgspe/x4Vo XEG8geQ48oKMbHA/Lx9e4J/GUE1+xSIXKbWria/ManC16ny3xHfbZ3gaA3RIvcNrE6// GDSureoCptyv6h3XrfcBMHdc6yjWOX0HLl6ZCT2fzOOqrV+w44vPi0u9VnutKDV6wa2x xyaRs+19lKQa1xlo8yVj6BR/Pm0ZK8G2PqrTSh9LFu8hZBmlOSxmPbZPmKUBoisfBaYY SpyQ== X-Received: by 10.112.150.73 with SMTP id ug9mr1108708lbb.31.1425427312239; Tue, 03 Mar 2015 16:01:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.84.38 with HTTP; Tue, 3 Mar 2015 16:01:30 -0800 (PST) In-Reply-To: References: <073A0B5C-531B-4B7B-ABA3-1D8A0EC4C4BA@recoil.org> From: Anand Patil Date: Tue, 3 Mar 2015 16:01:30 -0800 Message-ID: To: Ashish Agarwal Cc: Thomas Gazagnaire , "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] COW XML questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi Ashish, I knew this day would come. :) I'm still making progress, but haven't had too much time available for hobby projects lately, so it's slow. The current state is at https://github.com/apatil/auto-aws . It would be fun to work together with someone on this, either from what I have or from scratch. Anand On Tue, Mar 3, 2015 at 2:31 PM, Ashish Agarwal wrote: > Hi Anand. Any progress on this? Is your repo public? Thanks. > > > On Tue, Jan 6, 2015 at 1:32 PM, Anand Patil > wrote: >> >> Hi Anil and Thomas, thanks for the pointers. I'll keep plugging away >> at this and will let you know how I get on. >> >> Anand >> >> On Tue, Jan 6, 2015 at 7:43 AM, Anil Madhavapeddy wrote: >> > On 5 Jan 2015, at 05:56, Anand Patil >> > wrote: >> > >> >> In order to learn OCaml and thence Mirage, I've been working a little >> >> bit on an automatically generated, complete AWS client along the lines >> >> of https://github.com/stripe/aws-go using camlp4. I've got the types >> >> generated, and now need to generate to/from XML functions for each >> >> record type. >> >> >> > >> > Incidentally, this would be awesomely useful to have. You might also >> > want to look at Jyotsna Prakash's (manually written) bindings for >> > helper functions that might come in useful: >> > >> > https://github.com/moonlightdrive/ocaml-ec2 >> > >> > Feel free to ask here if you run into any blockers. >> > >> > -anil >> > >> >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Mar 04 00:02:03 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 04 Mar 2015 00:02:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YSwlA-0004pr-V4; Wed, 04 Mar 2015 00:01:56 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YSwl9-0004lz-D4 for MirageOS-devel@lists.xenproject.org; Wed, 04 Mar 2015 00:01:55 +0000 Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id 72/A3-02896-17B46F45; Wed, 04 Mar 2015 00:01:53 +0000 X-Env-Sender: anand.prabhakar.patil@gmail.com X-Msg-Ref: server-4.tower-31.messagelabs.com!1425427312!12732704!1 X-Originating-IP: [209.85.215.46] X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26493 invoked from network); 4 Mar 2015 00:01:53 -0000 Received: from mail-la0-f46.google.com (HELO mail-la0-f46.google.com) (209.85.215.46) by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2015 00:01:53 -0000 Received: by labgq15 with SMTP id gq15so41111883lab.6 for ; Tue, 03 Mar 2015 16:01:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=I5dsWgDMGe2ilxk/4eV6ohN1bmbxAS3nrXGxl3Q6qtI=; b=mX6J1ideIXcbAN3SV72Aq7M9LGqzmXqPunDJt455dbsPlwF/pyDfZc+VLEaNsPJaut twfH7OClp49qKlpNxOMPaKQ4hW44bvNXLjINs2aaJ5cHkg62GMClA1mH+nTgspe/x4Vo XEG8geQ48oKMbHA/Lx9e4J/GUE1+xSIXKbWria/ManC16ny3xHfbZ3gaA3RIvcNrE6// GDSureoCptyv6h3XrfcBMHdc6yjWOX0HLl6ZCT2fzOOqrV+w44vPi0u9VnutKDV6wa2x xyaRs+19lKQa1xlo8yVj6BR/Pm0ZK8G2PqrTSh9LFu8hZBmlOSxmPbZPmKUBoisfBaYY SpyQ== X-Received: by 10.112.150.73 with SMTP id ug9mr1108708lbb.31.1425427312239; Tue, 03 Mar 2015 16:01:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.84.38 with HTTP; Tue, 3 Mar 2015 16:01:30 -0800 (PST) In-Reply-To: References: <073A0B5C-531B-4B7B-ABA3-1D8A0EC4C4BA@recoil.org> From: Anand Patil Date: Tue, 3 Mar 2015 16:01:30 -0800 Message-ID: To: Ashish Agarwal Cc: Thomas Gazagnaire , "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] COW XML questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi Ashish, I knew this day would come. :) I'm still making progress, but haven't had too much time available for hobby projects lately, so it's slow. The current state is at https://github.com/apatil/auto-aws . It would be fun to work together with someone on this, either from what I have or from scratch. Anand On Tue, Mar 3, 2015 at 2:31 PM, Ashish Agarwal wrote: > Hi Anand. Any progress on this? Is your repo public? Thanks. > > > On Tue, Jan 6, 2015 at 1:32 PM, Anand Patil > wrote: >> >> Hi Anil and Thomas, thanks for the pointers. I'll keep plugging away >> at this and will let you know how I get on. >> >> Anand >> >> On Tue, Jan 6, 2015 at 7:43 AM, Anil Madhavapeddy wrote: >> > On 5 Jan 2015, at 05:56, Anand Patil >> > wrote: >> > >> >> In order to learn OCaml and thence Mirage, I've been working a little >> >> bit on an automatically generated, complete AWS client along the lines >> >> of https://github.com/stripe/aws-go using camlp4. I've got the types >> >> generated, and now need to generate to/from XML functions for each >> >> record type. >> >> >> > >> > Incidentally, this would be awesomely useful to have. You might also >> > want to look at Jyotsna Prakash's (manually written) bindings for >> > helper functions that might come in useful: >> > >> > https://github.com/moonlightdrive/ocaml-ec2 >> > >> > Feel free to ask here if you run into any blockers. >> > >> > -anil >> > >> >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Mar 04 15:12:43 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 04 Mar 2015 15:12:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTAyR-0005dI-Um; Wed, 04 Mar 2015 15:12:35 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTAyQ-0005dD-FF for mirageos-devel@lists.xenproject.org; Wed, 04 Mar 2015 15:12:34 +0000 Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id 9B/FB-03168-1E027F45; Wed, 04 Mar 2015 15:12:33 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1425481949!14672025!1 X-Originating-IP: [209.85.217.170] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30638 invoked from network); 4 Mar 2015 15:12:30 -0000 Received: from mail-lb0-f170.google.com (HELO mail-lb0-f170.google.com) (209.85.217.170) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2015 15:12:30 -0000 Received: by lbiz12 with SMTP id z12so21995028lbi.5 for ; Wed, 04 Mar 2015 07:12:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=RoVWChLSaJleH3ZoHYGjOxhW+ftSKzOlKizwg1bVYBM=; b=0AHXQbZuGeQx+HS0zY3O32TChSCXwgc0tt37QpZYJDNWb/a6aiC/OZLJTWTS+tdk0f /YDXkehGOlnRcMPbq4RWPNsiGutE65cOfkms3h2Xrc+BQaabM7isMHiDUQRZkRQ4tSNq ER0b+k6k08RHYwf8LyeqoFUuPdgd/BQNOjqsrtZRQZ9PkvvU5lmVSdhRJjBLEFWjUogF /23pXxGhuXZqcAIiVTomxFasTh/mdpJ1AhTe0l9VcBGpVWrDqGcSiBhBaV+4SSv9ON8E 5kuj5u2lRb1wib+RCfJZxZVHI/GYvH5+5oS+/DkQEcnzaonjS75M2gLUMRL8YOYgB2U/ RI/Q== MIME-Version: 1.0 X-Received: by 10.112.147.66 with SMTP id ti2mr3987479lbb.124.1425481949294; Wed, 04 Mar 2015 07:12:29 -0800 (PST) Received: by 10.25.207.17 with HTTP; Wed, 4 Mar 2015 07:12:29 -0800 (PST) In-Reply-To: References: <8CEDB416-6238-4888-BA4B-B7305FDDE2D9@gazagnaire.org> <9349273A-0BB4-40C4-BF06-4307085AA90C@recoil.org> <47D39FA3-050E-46E6-89D2-4253484E24A8@gazagnaire.org> Date: Wed, 4 Mar 2015 15:12:29 +0000 Message-ID: From: Thomas Leonard To: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Irmin API newbie questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org T24gMjQgRmVicnVhcnkgMjAxNSBhdCAxMzozNywgVGhvbWFzIExlb25hcmQgPHRhbGV4NUBnbWFp bC5jb20+IHdyb3RlOgo+IE9uIDI0IEZlYnJ1YXJ5IDIwMTUgYXQgMTM6MzQsIE5pY2sgQmV0dGVy aWRnZSA8YnV6emhlYXZ5eWVhckBob3RtYWlsLmNvbT4gd3JvdGU6Cj4+Cj4+Pgo+Pj4gTm90ZTog aXQncyBwcm9iYWJseSB3b3J0aCByZW1vdmluZyAiSXJtaW4gaW5zaWRlIHRoZSBicm93c2VyIiBm cm9tIHRoZQo+Pj4gUGlvbmVlciBQcm9qZWN0cyBsaXN0IG5vdy4gSXQncyB3b3JraW5nIGZpbmUg KHdpdGggSFRNTDUgc3RvcmFnZSkuCj4+PiBHZXR0aW5nIGl0IHRvIHdvcmsgaXMganVzdCBhIGNh c2Ugb2YgbW9kaWZ5aW5nIElybWluIHRvIHVzZSBEYW5pZWwKPj4+IELDvG56bGkncyBwdXJlLU9D YW1sIGltcGxlbWVudGF0aW9uIG9mIFNIQS0xIGFuZCBpbXBsZW1lbnRpbmcgYSBmZXcgSlMKPj4+ IGhlbHBlcnMgZm9yIGJsaXR0aW5nIHdpdGggYmlnYXJyYXlzLgo+Pj4KPj4KPj4gSXMgdGhpcyB2 aWV3YWJsZSBhbnl3aGVyZT8gSXQgd291bGQgYmUgZ3JlYXQgdG8gaGF2ZSB0aGlzIGZ1bmN0aW9u YWxpdHkKPj4gYnVpbHQgaW50byBJcm1pbiArIGV4dGVuc2lvbi4KPgo+IFllcywgYWx0aG91Z2gg SSdtIHBsYW5uaW5nIG9uIGRvaW5nIG1vcmUgdGVzdGluZyBiZWZvcmUgdXBzdHJlYW1pbmcuCj4g SG93ZXZlciwgZm9yIHRoZSBjdXJpb3VzIHRoZSBjdXJyZW50IHZlcnNpb25zIGNhbiBiZSBmb3Vu ZCBoZXJlOgo+Cj4gSFRNTCA1IHN0b3JhZ2UgYmFja2VuZCBmb3IgSXJtaW46Cj4KPiBodHRwczov L2dpdGh1Yi5jb20vdGFsZXg1L2N1ZWtlZXBlci9ibG9iL21hc3Rlci9odG1sX3N0b3JhZ2UubWwK CkkndmUgbm93IGV4dGVuZGVkIHRoaXMgdG8gc3VwcG9ydCBldmVudHMsIHNvIGlmIHRoZSB1c2Vy IGhhcyB0aGUgcGFnZQpvcGVuIGluIHR3byB0YWJzIHRoZXkgc3RheSBpbiBzeW5jLiBIb3dldmVy LCB0aGVyZSdzIHN0aWxsIHRoZSBwcm9ibGVtCnRoYXQgeW91IGNhbid0IHJlbW92ZSBhIHdhdGNo LCBzbyBvbmNlIHlvdSBzdGFydCB3YXRjaGluZyB5b3UgaGF2ZSB0bwprZWVwIG9uIGRvaW5nIHNv LiBOb3QgYSBwcm9ibGVtIGZvciBteSBhcHAgKEkganVzdCB3YXRjaCB0aGUgbWFzdGVyCmJyYW5j aCkgYnV0IG1pZ2h0IGJlIGEgcHJvYmxlbSBpbiBnZW5lcmFsLgoKSSd2ZSBhbHNvIG5vdyBtYWRl IG15IGFwcCBkbyBtZXJnZXM6IGV2ZXJ5IGl0ZW0gZGlzcGxheWVkIG9uIHRoZQpzY3JlZW4gcmVj b3JkcyB0aGUgSXJtaW4gY29tbWl0IGZyb20gd2hpY2ggaXQgY2FtZS4gVXN1YWxseSB0aGlzIGlz CnRoZSBsYXRlc3QgdmVyc2lvbiwgYnV0IGlmIHlvdSdyZSBlLmcuIGVkaXRpbmcgYSBmb3JtIHRo ZW4gaXQncyB0aGUKdmVyc2lvbiB3aGVuIHlvdSBzdGFydGVkIHRoZSBlZGl0LiBXaGVuIHlvdSBz dWJtaXQgYSBjaGFuZ2UsIGl0CmNvbW1pdHMgYWdhaW5zdCB0aGF0IHJldmlzaW9uIGFuZCB0aGVu IG1lcmdlcyB0aGUgcmVzdWx0IGJhY2sgdG8KbWFzdGVyLiBUaGlzIG1lYW5zIHRoYXQgaWYgeW91 IG1ha2UgdHdvIGRpZmZlcmVudCBlZGl0cyB0byBzb21ldGhpbmcKaW4gdHdvIHRhYnMsIHRoZSBj b25mbGljdCB3aWxsIGJlIGRldGVjdGVkIGluc3RlYWQgb2Ygc2lsZW50bHkKZGlzY2FyZGluZyB0 aGUgZmlyc3QgY2hhbmdlLiAoSWRlYWxseSBJIHdhbnQgdG8gcmVzb2x2ZSB0aGUgY29uZmxpY3Rz LApidXQgZm9yIG5vdyBpdCBqdXN0IGRpc2NhcmRzIHRoZSBzZWNvbmQgY2hhbmdlIGFuZCByZXBv cnRzIHRoZSBlcnJvcgp0byB0aGUgdXNlcikuCgpJJ20gbm90IHN1cmUgSSdtIHVzaW5nIHRoZSBB UEkgY29ycmVjdGx5IHRob3VnaC4gSGVyZSdzIG15IGNvZGUgZm9yCm1vbml0b3JpbmcgdGhlIG1h c3RlciBicmFuY2ggYW5kIHVwZGF0aW5nIHRoZSBkaXNwbGF5IHdoZW4gaXQgY2hhbmdlczoKCmh0 dHBzOi8vZ2l0aHViLmNvbS90YWxleDUvY3Vla2VlcGVyL2Jsb2IvODNhNWUzYzE0NmYyNDA2Yjg0 OTFiMWM5OTE1Y2I3ZmVmNjc1Mzg2OS9ja191cGRhdGUubWwjTDMwCgogIGxldCBtYWtlIH5vbl91 cGRhdGUgYnJhbmNoID0KICAgIGxldCB3YXRjaF90YWdzID0gSS53YXRjaF90YWdzIChicmFuY2gg IldhdGNoIG1hc3RlciIpIGluCiAgICBnZXRfaGVhZF9jb21taXQgYnJhbmNoID4+PSBmdW4gaW5p dGlhbF9oZWFkIC0+CiAgICBsZXQgbXV0ZXggPSBMd3RfbXV0ZXguY3JlYXRlICgpIGluCiAgICBt YXRjaCBJLmJyYW5jaCAoYnJhbmNoICJHZXQgYnJhbmNoIG5hbWUiKSB3aXRoCiAgICB8IGBIZWFk IF8gLT4gZmFpbHdpdGggIk5vdCBhIHRhZyEiCiAgICB8IGBUYWcgYnJhbmNoX25hbWUgLT4KICAg IGxldCB0ID0gewogICAgICBicmFuY2g7CiAgICAgIGhlYWQgPSBpbml0aWFsX2hlYWQ7CiAgICAg IHVwZGF0ZWQgPSBMd3RfY29uZGl0aW9uLmNyZWF0ZSAoKTsKICAgICAgbXV0ZXg7CiAgICB9IGlu CiAgICBhc3luYyAoZnVuICgpIC0+CiAgICAgIG9uX3VwZGF0ZSA+Pj0gZnVuIG9uX3VwZGF0ZSAt PgogICAgICB3YXRjaF90YWdzIHw+IEx3dF9zdHJlYW0uaXRlcl9zIChmdW5jdGlvbgogICAgICAg IHwgKG4sIFNvbWUgX2NvbW1pdCkgd2hlbiBuID0gYnJhbmNoX25hbWUgLT4KICAgICAgICAgICAg KCogKGlnbm9yZSB0aGUgY29tbWl0IElEIGluIHRoZSB1cGRhdGUgbWVzc2FnZTsgd2Ugd2FudAp0 aGUgbGF0ZXN0KSAqKQogICAgICAgICAgICBMd3RfbXV0ZXgud2l0aF9sb2NrIHQubXV0ZXggKGZ1 biAoKSAtPgogICAgICAgICAgICAgIEkuaGVhZCAoYnJhbmNoICJHZXQgbGF0ZXN0IGNvbW1pdCIp ID4+PSBmdW5jdGlvbgogICAgICAgICAgICAgIHwgTm9uZSAtPiBDa191dGlscy5lcnJvciAiQnJh bmNoICclcycgaGFzIGRpc2FwcGVhcmVkISIKYnJhbmNoX25hbWUKICAgICAgICAgICAgICB8IFNv bWUgaGVhZCAtPgogICAgICAgICAgICAgICAgICBpZiBoZWFkIDw+IHQuaGVhZCB0aGVuICgKICAg ICAgICAgICAgICAgICAgICB0LmhlYWQgPC0gaGVhZDsKICAgICAgICAgICAgICAgICAgICBvbl91 cGRhdGUgaGVhZCA+Pj0gZnVuICgpIC0+CiAgICAgICAgICAgICAgICAgICAgTHd0X2NvbmRpdGlv bi5icm9hZGNhc3QgdC51cGRhdGVkICgpOwogICAgICAgICAgICAgICAgICAgIHJldHVybiAoKQog ICAgICAgICAgICAgICAgICApIGVsc2UgKAogICAgICAgICAgICAgICAgICAgIHJldHVybiAoKQog ICAgICAgICAgICAgICAgICApCiAgICAgICAgICAgICkKICAgICAgICB8IF8gLT4gcmV0dXJuICgp CiAgICAgICkKICAgICk7CiAgICByZXR1cm4gdAoKU29tZSBwb2ludHMgeW91IGhhdmUgdG8gd29y cnkgYWJvdXQgaGVyZToKCi0gSXJtaW4gbWFrZXMgaXQgZWFzeSB0byByZWFkIGRhdGEgZGlyZWN0 bHkgZnJvbSBhIGJyYW5jaCAodGFnKSwgYnV0CnRoaXMgaXMgdXN1YWxseSB1bnNhZmUsIHNpbmNl IGEgdGFnIGNhbiB1cGRhdGUgd2hpbGUgeW91J3JlIHJlYWRpbmcKaXQuIFRoZXJlZm9yZSwgSSB0 aGluayBJIGFsd2F5cyBoYXZlIHRvIGZpcnN0IGdldCB0aGUgaGVhZCBjb21taXQsCnRoZW4gY3Jl YXRlIGEgbmV3IHN0b3JlIGZvciB0aGF0IHJldmlzaW9uLCB0aGVuIHJlYWQgZnJvbSB0aGF0LiBJ dAptaWdodCBiZSBzYWZlciBpZiBhIGJyYW5jaCBqdXN0IHByb3ZpZGVkIGEgd2F5IHRvIGdldCBh IGNvbW1pdCwgYW5kCnJlYWRzIGhhZCB0byBiZSBkb25lIGZyb20gYSBmaXhlZCBjb21taXQuCgot IEkgb25seSBuZWVkIHRvIGJlIG5vdGlmaWVkIG9uY2UgYWZ0ZXIgYSBzZXJpZXMgb2YgY2hhbmdl cy4gSSBkaXNjYXJkCnRoZSBjb21taXQgaW4gdGhlIHdhdGNoIG5vdGlmaWNhdGlvbiBhbmQgYWx3 YXlzIHJlYWQgdGhlIGxhdGVzdC4KT3RoZXJ3aXNlLCBJIG1pZ2h0IHVwZGF0ZSB0aGUgR1VJIHRv IHNob3cgc3RhbGUgZGF0YS4gU2luY2UgYSBtZXJnZQpjYW4gYWRkIG1hbnkgY29tbWl0cyBhdCBv bmNlLCB0aGUgc3RyZWFtIEFQSSBkb2Vzbid0IHNlZW0gdXNlZnVsIChpdApzdGlsbCBkb2Vzbid0 IGVuc3VyZSB5b3Ugc2VlIGVhY2ggY29tbWl0IGluZGl2aWR1YWxseSwgaWYgdGhhdCdzIHdoYXQK eW91IHdhbnRlZCkuCgotIFRoZSBmdW5jdGlvbnMgdGhhdCB1cGRhdGUgdGhlIHN0b3JlIHNob3Vs ZG4ndCByZXR1cm4gdW50aWwgdGhlCnVwZGF0ZSBoYXMgYmVlbiBzZWUgYnkgdGhlIG1vZGVsICgi b25fdXBkYXRlIiBoYXMgYmVlbiBjYWxsZWQpLiBJCnRoZXJlZm9yZSBjcmVhdGUgYSBtdXRleCBh bmQgYSBMd3RfY29uZGl0aW9uIHNvIHRoYXQgdGhlIGNvbW1pdApmdW5jdGlvbnMgY2FuIGJlIHN1 cmUgdGhlaXIgY2hhbmdlIGhhcyBiZWVuIHNlZW4uCgotIEkgd2FzIHVzaW5nIFJlYWN0IHRvIHRy YWNrIHRoaW5ncywgYnV0IGl0cyB1c2Ugb2Ygd2Vha3JlZnMgY2F1c2VkIGEKbG90IG9mIHByb2Js ZW1zLCBzbyBJJ3ZlIGdvbmUgYmFjayB0byBpbXBlcmF0aXZlIGNvZGUgYW5kIGNhbGxiYWNrcwpm b3Igbm93LgoKCkFsbCB0aGUgY29kZSBmb3IgY2hhbmdpbmcgdGhlIG1vZGVsIGdvZXMgdmlhICJt ZXJnZV90b19tYXN0ZXIiLiBUaGlzCnRha2VzIGEgImJhc2UiIGFyZ3VtZW50ICh0aGUgY29tbWl0 IHdoaWNoIHRoZSB1c2VyIG1hZGUgdGhlIGNoYW5nZQpmcm9tKSwgY3JlYXRlcyBhIHZpZXcgKHRl bXBvcmFyeSBicmFuY2gpLCBydW5zICJmbiIgdG8gbWFrZSB0aGUKcmVxdWVzdGVkIGNoYW5nZSAo d2hpY2ggc2hvdWxkIGFsd2F5cyBzdWNjZWVkKSwgbWVyZ2VzIHRoZSB0ZW1wb3JhcnkKYnJhbmNo IGJhY2sgdG8gbWFzdGVyLCBhbmQgd2FpdHMgZm9yIHRoZSBvbl91cGRhdGUgdG8gbm90aWNlIGl0 OgoKICBsZXQgbWVyZ2VfdG9fbWFzdGVyIHQgfmJhc2Ugfm1zZyBmbiA9CiAgICBsZXQgcGF0aCA9 IEkuS2V5LmVtcHR5IGluCiAgICBSLm1ha2VfdmlldyBiYXNlID4+PSBmdW4gdmlldyAtPgogICAg Zm4gdmlldyA+Pj0gZnVuIHJlc3VsdCAtPgogICAgTHd0X211dGV4LndpdGhfbG9jayB0Lm11dGV4 IChmdW4gKCkgLT4KICAgICAgKCogQXQgdGhpcyBwb2ludCwgaGVhZCBjYW5ub3QgY29udGFpbiBv dXIgY29tbWl0IGJlY2F1c2Ugd2UKaGF2ZW4ndCBtYWRlIGl0IHlldCwKICAgICAgICogYW5kIG5v IHVwZGF0ZXMgY2FuIGhhcHBlbiB3aGlsZSB3ZSBob2xkIHRoZSBsb2NrLiAqKQogICAgICBsZXQg b2xkX2hlYWQgPSB0LmhlYWQgaW4KICAgICAgbGV0IHVwZGF0ZWQgPSBMd3RfY29uZGl0aW9uLndh aXQgdC51cGRhdGVkIGluCiAgICAgIFIuVi5tZXJnZV9wYXRoICh0LmJyYW5jaCBtc2cpIHBhdGgg dmlldyA+Pj0gZnVuY3Rpb24KICAgICAgfCBgQ29uZmxpY3QgbXNnIC0+IENrX3V0aWxzLmVycm9y ICJDb25mbGljdCBkdXJpbmcgbWVyZ2U6ICVzCihkaXNjYXJkaW5nIGNoYW5nZSkiIG1zZwogICAg ICB8IGBPayAoKSAtPgogICAgICBJLmhlYWQgKHQuYnJhbmNoICJHZXQgbGF0ZXN0IGNvbW1pdCIp ID58PSBmdW5jdGlvbgogICAgICB8IFNvbWUgbmV3X2hlYWQgd2hlbiBuZXdfaGVhZCA8PiBvbGRf aGVhZCAtPgogICAgICAgICAgKCogW3VwZGF0ZWRdIGNhbm5vdCBoYXZlIGZpcmVkIHlldCBiZWNh dXNlIHdlIHN0aWxsIGhvbGQgdGhlCmxvY2suIFdoZW4gaXQgZG9lcwogICAgICAgICAgICogZmly ZSBuZXh0LCBpdCBtdXN0IGNvbnRhaW4gb3VyIHVwZGF0ZS4gSXQgbXVzdCBmaXJlIHNvb24sCmFz IGhlYWQgaGFzIGNoYW5nZWQuICopCiAgICAgICAgICB1cGRhdGVkCiAgICAgIHwgXyAtPgogICAg ICAgICAgKCogT3VyIGNoYW5nZSBoYWQgbm8gZWZmZWN0LCBzbyBkb24ndCB3YWl0IGZvciBoZWFk IHRvIG1vdmUuCiAgICAgICAgICAgKiBPciwgdGhlIGJyYW5jaCB3YXMgZGVsZXRlZCAtIG5vIHBv aW50IHdhaXRpbmcgdGhlbiBlaXRoZXIuICopCiAgICAgICAgICByZXR1cm4gKCkKICAgICkgPj49 IGZ1biB1cGRhdGVkIC0+ICAgICgqIENoYW5nZXMgaGF2ZSBiZWVuIGNvbW1pdHRlZC4gKikKICAg IHVwZGF0ZWQgPj49IGZ1biAoKSAtPiAgICgqIFtvbl91cGRhdGVdIGhhcyBiZWVuIGNhbGxlZC4g KikKICAgIHJldHVybiByZXN1bHQKCkRvZXMgdGhpcyBhcHByb2FjaCBzZWVtIHNlbnNpYmxlPyBJ IGZlZWwgbGlrZSB0aGUgQVBJIHBlcmhhcHMgd2Fzbid0CmludGVuZGVkIHRvIGJlIHVzZWQgdGhp cyB3YXkuLi4KCkknbSBzdGlsbCB3b3JyaWVkIGFib3V0IGxvc2luZyBkYXRhIGR1ZSB0byByYWNl cy4gSmF2YVNjcmlwdCAoSSB0aGluaykKZW5zdXJlcyB0aGF0IGFjY2VzcyB0byBsb2NhbCBzdG9y YWdlIGZyb20gZGlmZmVyZW50IHRocmVhZHMgZG9lc24ndApnZXQgaW50ZXJsZWF2ZWQsIGJ1dCBz aW5jZSBJcm1pbiB1c2VzIEx3dCB3ZSBkb24ndCBiZW5lZml0IGZyb20gdGhpcy4KSSBzdXNwZWN0 IHRoYXQgaWYgdHdvIHRhYnMgdHJ5IHRvIG1lcmdlIGF0IG9uY2UgdGhlbiBvbmUncyBjb21taXQg d2lsbApiZSBzaWxlbnRseSBkaXNjYXJkZWQuIFByb2JhYmx5IHRoZSBiYWNrLWVuZCB1cGRhdGUg ZnVuY3Rpb24gc2hvdWxkCnRha2UgdGhlIGV4cGVjdGVkIG9sZCB2YWx1ZSBhcyBhbiBhcmd1bWVu dCBzbyBpdCBjYW4gYWJvcnQgaWYgdGhlCnN0YXRlIGhhcyBjaGFuZ2VkIHNpbmNlIHRoZW4uCgpJ dCB3b3VsZCBhbHNvIGJlIHVzZWZ1bCB0byBnZXQgdGhlIGNvbW1pdCBvYmplY3QgZnJvbSB0aGUg bWVyZ2UgYmVmb3JlCnVwZGF0aW5nIHRoZSBicmFuY2guIFRoYXQgd2F5LCBJIGNvdWxkIHRyeSBs b2FkaW5nIGl0IGFzIGEgc2FuaXR5CmNoZWNrIChhbmQgdGh1cyByZWplY3QgYW55IHVwZGF0ZSB0 aGF0IHdvdWxkIHJlc3VsdCBpbiBhbiB1bnJlYWRhYmxlCnN0YXRlKS4gSSBndWVzcyBJIG5lZWQg dG8gY3JlYXRlIGFub3RoZXIgdGVtcG9yYXJ5IGJyYW5jaCwgbWVyZ2UgdG8KdGhhdCwgdGhlbiBm b3JjZS11cGRhdGUgbWFzdGVyIHRvIGl0LiBTZWVtcyBsaWtlIGEgbG90IG9mIHdvcmssCnRob3Vn aC4KCkFueXdheSwgZGVzcGl0ZSB0aGVzZSBtaW5vciBpc3N1ZXMsIElybWluIGlzIHdvcmtpbmcg Z3JlYXQgc28gZmFyIQoKCi0tIApEciBUaG9tYXMgTGVvbmFyZCAgICAgICAgaHR0cDovLzBpbnN0 YWxsLm5ldC8KR1BHOiA5MjQyIDk4MDcgQzk4NSAzQzA3IDQ0QTYgIDhCOUEgQUUwNyA4MjgwIDU5 QTUgM0NDMQpHUEc6IERBOTggMjVBRSBDQUQwIDg5NzUgN0NEQSAgQkQ4RSAwNzEzIDNGOTYgQ0E3 NCBEOEJBCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpN aXJhZ2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlzdHMueGVucHJvamVj dC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5m by9taXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Wed Mar 04 15:12:43 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 04 Mar 2015 15:12:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTAyR-0005dI-Um; Wed, 04 Mar 2015 15:12:35 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTAyQ-0005dD-FF for mirageos-devel@lists.xenproject.org; Wed, 04 Mar 2015 15:12:34 +0000 Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id 9B/FB-03168-1E027F45; Wed, 04 Mar 2015 15:12:33 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1425481949!14672025!1 X-Originating-IP: [209.85.217.170] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30638 invoked from network); 4 Mar 2015 15:12:30 -0000 Received: from mail-lb0-f170.google.com (HELO mail-lb0-f170.google.com) (209.85.217.170) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2015 15:12:30 -0000 Received: by lbiz12 with SMTP id z12so21995028lbi.5 for ; Wed, 04 Mar 2015 07:12:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=RoVWChLSaJleH3ZoHYGjOxhW+ftSKzOlKizwg1bVYBM=; b=0AHXQbZuGeQx+HS0zY3O32TChSCXwgc0tt37QpZYJDNWb/a6aiC/OZLJTWTS+tdk0f /YDXkehGOlnRcMPbq4RWPNsiGutE65cOfkms3h2Xrc+BQaabM7isMHiDUQRZkRQ4tSNq ER0b+k6k08RHYwf8LyeqoFUuPdgd/BQNOjqsrtZRQZ9PkvvU5lmVSdhRJjBLEFWjUogF /23pXxGhuXZqcAIiVTomxFasTh/mdpJ1AhTe0l9VcBGpVWrDqGcSiBhBaV+4SSv9ON8E 5kuj5u2lRb1wib+RCfJZxZVHI/GYvH5+5oS+/DkQEcnzaonjS75M2gLUMRL8YOYgB2U/ RI/Q== MIME-Version: 1.0 X-Received: by 10.112.147.66 with SMTP id ti2mr3987479lbb.124.1425481949294; Wed, 04 Mar 2015 07:12:29 -0800 (PST) Received: by 10.25.207.17 with HTTP; Wed, 4 Mar 2015 07:12:29 -0800 (PST) In-Reply-To: References: <8CEDB416-6238-4888-BA4B-B7305FDDE2D9@gazagnaire.org> <9349273A-0BB4-40C4-BF06-4307085AA90C@recoil.org> <47D39FA3-050E-46E6-89D2-4253484E24A8@gazagnaire.org> Date: Wed, 4 Mar 2015 15:12:29 +0000 Message-ID: From: Thomas Leonard To: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Irmin API newbie questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org T24gMjQgRmVicnVhcnkgMjAxNSBhdCAxMzozNywgVGhvbWFzIExlb25hcmQgPHRhbGV4NUBnbWFp bC5jb20+IHdyb3RlOgo+IE9uIDI0IEZlYnJ1YXJ5IDIwMTUgYXQgMTM6MzQsIE5pY2sgQmV0dGVy aWRnZSA8YnV6emhlYXZ5eWVhckBob3RtYWlsLmNvbT4gd3JvdGU6Cj4+Cj4+Pgo+Pj4gTm90ZTog aXQncyBwcm9iYWJseSB3b3J0aCByZW1vdmluZyAiSXJtaW4gaW5zaWRlIHRoZSBicm93c2VyIiBm cm9tIHRoZQo+Pj4gUGlvbmVlciBQcm9qZWN0cyBsaXN0IG5vdy4gSXQncyB3b3JraW5nIGZpbmUg KHdpdGggSFRNTDUgc3RvcmFnZSkuCj4+PiBHZXR0aW5nIGl0IHRvIHdvcmsgaXMganVzdCBhIGNh c2Ugb2YgbW9kaWZ5aW5nIElybWluIHRvIHVzZSBEYW5pZWwKPj4+IELDvG56bGkncyBwdXJlLU9D YW1sIGltcGxlbWVudGF0aW9uIG9mIFNIQS0xIGFuZCBpbXBsZW1lbnRpbmcgYSBmZXcgSlMKPj4+ IGhlbHBlcnMgZm9yIGJsaXR0aW5nIHdpdGggYmlnYXJyYXlzLgo+Pj4KPj4KPj4gSXMgdGhpcyB2 aWV3YWJsZSBhbnl3aGVyZT8gSXQgd291bGQgYmUgZ3JlYXQgdG8gaGF2ZSB0aGlzIGZ1bmN0aW9u YWxpdHkKPj4gYnVpbHQgaW50byBJcm1pbiArIGV4dGVuc2lvbi4KPgo+IFllcywgYWx0aG91Z2gg SSdtIHBsYW5uaW5nIG9uIGRvaW5nIG1vcmUgdGVzdGluZyBiZWZvcmUgdXBzdHJlYW1pbmcuCj4g SG93ZXZlciwgZm9yIHRoZSBjdXJpb3VzIHRoZSBjdXJyZW50IHZlcnNpb25zIGNhbiBiZSBmb3Vu ZCBoZXJlOgo+Cj4gSFRNTCA1IHN0b3JhZ2UgYmFja2VuZCBmb3IgSXJtaW46Cj4KPiBodHRwczov L2dpdGh1Yi5jb20vdGFsZXg1L2N1ZWtlZXBlci9ibG9iL21hc3Rlci9odG1sX3N0b3JhZ2UubWwK CkkndmUgbm93IGV4dGVuZGVkIHRoaXMgdG8gc3VwcG9ydCBldmVudHMsIHNvIGlmIHRoZSB1c2Vy IGhhcyB0aGUgcGFnZQpvcGVuIGluIHR3byB0YWJzIHRoZXkgc3RheSBpbiBzeW5jLiBIb3dldmVy LCB0aGVyZSdzIHN0aWxsIHRoZSBwcm9ibGVtCnRoYXQgeW91IGNhbid0IHJlbW92ZSBhIHdhdGNo LCBzbyBvbmNlIHlvdSBzdGFydCB3YXRjaGluZyB5b3UgaGF2ZSB0bwprZWVwIG9uIGRvaW5nIHNv LiBOb3QgYSBwcm9ibGVtIGZvciBteSBhcHAgKEkganVzdCB3YXRjaCB0aGUgbWFzdGVyCmJyYW5j aCkgYnV0IG1pZ2h0IGJlIGEgcHJvYmxlbSBpbiBnZW5lcmFsLgoKSSd2ZSBhbHNvIG5vdyBtYWRl IG15IGFwcCBkbyBtZXJnZXM6IGV2ZXJ5IGl0ZW0gZGlzcGxheWVkIG9uIHRoZQpzY3JlZW4gcmVj b3JkcyB0aGUgSXJtaW4gY29tbWl0IGZyb20gd2hpY2ggaXQgY2FtZS4gVXN1YWxseSB0aGlzIGlz CnRoZSBsYXRlc3QgdmVyc2lvbiwgYnV0IGlmIHlvdSdyZSBlLmcuIGVkaXRpbmcgYSBmb3JtIHRo ZW4gaXQncyB0aGUKdmVyc2lvbiB3aGVuIHlvdSBzdGFydGVkIHRoZSBlZGl0LiBXaGVuIHlvdSBz dWJtaXQgYSBjaGFuZ2UsIGl0CmNvbW1pdHMgYWdhaW5zdCB0aGF0IHJldmlzaW9uIGFuZCB0aGVu IG1lcmdlcyB0aGUgcmVzdWx0IGJhY2sgdG8KbWFzdGVyLiBUaGlzIG1lYW5zIHRoYXQgaWYgeW91 IG1ha2UgdHdvIGRpZmZlcmVudCBlZGl0cyB0byBzb21ldGhpbmcKaW4gdHdvIHRhYnMsIHRoZSBj b25mbGljdCB3aWxsIGJlIGRldGVjdGVkIGluc3RlYWQgb2Ygc2lsZW50bHkKZGlzY2FyZGluZyB0 aGUgZmlyc3QgY2hhbmdlLiAoSWRlYWxseSBJIHdhbnQgdG8gcmVzb2x2ZSB0aGUgY29uZmxpY3Rz LApidXQgZm9yIG5vdyBpdCBqdXN0IGRpc2NhcmRzIHRoZSBzZWNvbmQgY2hhbmdlIGFuZCByZXBv cnRzIHRoZSBlcnJvcgp0byB0aGUgdXNlcikuCgpJJ20gbm90IHN1cmUgSSdtIHVzaW5nIHRoZSBB UEkgY29ycmVjdGx5IHRob3VnaC4gSGVyZSdzIG15IGNvZGUgZm9yCm1vbml0b3JpbmcgdGhlIG1h c3RlciBicmFuY2ggYW5kIHVwZGF0aW5nIHRoZSBkaXNwbGF5IHdoZW4gaXQgY2hhbmdlczoKCmh0 dHBzOi8vZ2l0aHViLmNvbS90YWxleDUvY3Vla2VlcGVyL2Jsb2IvODNhNWUzYzE0NmYyNDA2Yjg0 OTFiMWM5OTE1Y2I3ZmVmNjc1Mzg2OS9ja191cGRhdGUubWwjTDMwCgogIGxldCBtYWtlIH5vbl91 cGRhdGUgYnJhbmNoID0KICAgIGxldCB3YXRjaF90YWdzID0gSS53YXRjaF90YWdzIChicmFuY2gg IldhdGNoIG1hc3RlciIpIGluCiAgICBnZXRfaGVhZF9jb21taXQgYnJhbmNoID4+PSBmdW4gaW5p dGlhbF9oZWFkIC0+CiAgICBsZXQgbXV0ZXggPSBMd3RfbXV0ZXguY3JlYXRlICgpIGluCiAgICBt YXRjaCBJLmJyYW5jaCAoYnJhbmNoICJHZXQgYnJhbmNoIG5hbWUiKSB3aXRoCiAgICB8IGBIZWFk IF8gLT4gZmFpbHdpdGggIk5vdCBhIHRhZyEiCiAgICB8IGBUYWcgYnJhbmNoX25hbWUgLT4KICAg IGxldCB0ID0gewogICAgICBicmFuY2g7CiAgICAgIGhlYWQgPSBpbml0aWFsX2hlYWQ7CiAgICAg IHVwZGF0ZWQgPSBMd3RfY29uZGl0aW9uLmNyZWF0ZSAoKTsKICAgICAgbXV0ZXg7CiAgICB9IGlu CiAgICBhc3luYyAoZnVuICgpIC0+CiAgICAgIG9uX3VwZGF0ZSA+Pj0gZnVuIG9uX3VwZGF0ZSAt PgogICAgICB3YXRjaF90YWdzIHw+IEx3dF9zdHJlYW0uaXRlcl9zIChmdW5jdGlvbgogICAgICAg IHwgKG4sIFNvbWUgX2NvbW1pdCkgd2hlbiBuID0gYnJhbmNoX25hbWUgLT4KICAgICAgICAgICAg KCogKGlnbm9yZSB0aGUgY29tbWl0IElEIGluIHRoZSB1cGRhdGUgbWVzc2FnZTsgd2Ugd2FudAp0 aGUgbGF0ZXN0KSAqKQogICAgICAgICAgICBMd3RfbXV0ZXgud2l0aF9sb2NrIHQubXV0ZXggKGZ1 biAoKSAtPgogICAgICAgICAgICAgIEkuaGVhZCAoYnJhbmNoICJHZXQgbGF0ZXN0IGNvbW1pdCIp ID4+PSBmdW5jdGlvbgogICAgICAgICAgICAgIHwgTm9uZSAtPiBDa191dGlscy5lcnJvciAiQnJh bmNoICclcycgaGFzIGRpc2FwcGVhcmVkISIKYnJhbmNoX25hbWUKICAgICAgICAgICAgICB8IFNv bWUgaGVhZCAtPgogICAgICAgICAgICAgICAgICBpZiBoZWFkIDw+IHQuaGVhZCB0aGVuICgKICAg ICAgICAgICAgICAgICAgICB0LmhlYWQgPC0gaGVhZDsKICAgICAgICAgICAgICAgICAgICBvbl91 cGRhdGUgaGVhZCA+Pj0gZnVuICgpIC0+CiAgICAgICAgICAgICAgICAgICAgTHd0X2NvbmRpdGlv bi5icm9hZGNhc3QgdC51cGRhdGVkICgpOwogICAgICAgICAgICAgICAgICAgIHJldHVybiAoKQog ICAgICAgICAgICAgICAgICApIGVsc2UgKAogICAgICAgICAgICAgICAgICAgIHJldHVybiAoKQog ICAgICAgICAgICAgICAgICApCiAgICAgICAgICAgICkKICAgICAgICB8IF8gLT4gcmV0dXJuICgp CiAgICAgICkKICAgICk7CiAgICByZXR1cm4gdAoKU29tZSBwb2ludHMgeW91IGhhdmUgdG8gd29y cnkgYWJvdXQgaGVyZToKCi0gSXJtaW4gbWFrZXMgaXQgZWFzeSB0byByZWFkIGRhdGEgZGlyZWN0 bHkgZnJvbSBhIGJyYW5jaCAodGFnKSwgYnV0CnRoaXMgaXMgdXN1YWxseSB1bnNhZmUsIHNpbmNl IGEgdGFnIGNhbiB1cGRhdGUgd2hpbGUgeW91J3JlIHJlYWRpbmcKaXQuIFRoZXJlZm9yZSwgSSB0 aGluayBJIGFsd2F5cyBoYXZlIHRvIGZpcnN0IGdldCB0aGUgaGVhZCBjb21taXQsCnRoZW4gY3Jl YXRlIGEgbmV3IHN0b3JlIGZvciB0aGF0IHJldmlzaW9uLCB0aGVuIHJlYWQgZnJvbSB0aGF0LiBJ dAptaWdodCBiZSBzYWZlciBpZiBhIGJyYW5jaCBqdXN0IHByb3ZpZGVkIGEgd2F5IHRvIGdldCBh IGNvbW1pdCwgYW5kCnJlYWRzIGhhZCB0byBiZSBkb25lIGZyb20gYSBmaXhlZCBjb21taXQuCgot IEkgb25seSBuZWVkIHRvIGJlIG5vdGlmaWVkIG9uY2UgYWZ0ZXIgYSBzZXJpZXMgb2YgY2hhbmdl cy4gSSBkaXNjYXJkCnRoZSBjb21taXQgaW4gdGhlIHdhdGNoIG5vdGlmaWNhdGlvbiBhbmQgYWx3 YXlzIHJlYWQgdGhlIGxhdGVzdC4KT3RoZXJ3aXNlLCBJIG1pZ2h0IHVwZGF0ZSB0aGUgR1VJIHRv IHNob3cgc3RhbGUgZGF0YS4gU2luY2UgYSBtZXJnZQpjYW4gYWRkIG1hbnkgY29tbWl0cyBhdCBv bmNlLCB0aGUgc3RyZWFtIEFQSSBkb2Vzbid0IHNlZW0gdXNlZnVsIChpdApzdGlsbCBkb2Vzbid0 IGVuc3VyZSB5b3Ugc2VlIGVhY2ggY29tbWl0IGluZGl2aWR1YWxseSwgaWYgdGhhdCdzIHdoYXQK eW91IHdhbnRlZCkuCgotIFRoZSBmdW5jdGlvbnMgdGhhdCB1cGRhdGUgdGhlIHN0b3JlIHNob3Vs ZG4ndCByZXR1cm4gdW50aWwgdGhlCnVwZGF0ZSBoYXMgYmVlbiBzZWUgYnkgdGhlIG1vZGVsICgi b25fdXBkYXRlIiBoYXMgYmVlbiBjYWxsZWQpLiBJCnRoZXJlZm9yZSBjcmVhdGUgYSBtdXRleCBh bmQgYSBMd3RfY29uZGl0aW9uIHNvIHRoYXQgdGhlIGNvbW1pdApmdW5jdGlvbnMgY2FuIGJlIHN1 cmUgdGhlaXIgY2hhbmdlIGhhcyBiZWVuIHNlZW4uCgotIEkgd2FzIHVzaW5nIFJlYWN0IHRvIHRy YWNrIHRoaW5ncywgYnV0IGl0cyB1c2Ugb2Ygd2Vha3JlZnMgY2F1c2VkIGEKbG90IG9mIHByb2Js ZW1zLCBzbyBJJ3ZlIGdvbmUgYmFjayB0byBpbXBlcmF0aXZlIGNvZGUgYW5kIGNhbGxiYWNrcwpm b3Igbm93LgoKCkFsbCB0aGUgY29kZSBmb3IgY2hhbmdpbmcgdGhlIG1vZGVsIGdvZXMgdmlhICJt ZXJnZV90b19tYXN0ZXIiLiBUaGlzCnRha2VzIGEgImJhc2UiIGFyZ3VtZW50ICh0aGUgY29tbWl0 IHdoaWNoIHRoZSB1c2VyIG1hZGUgdGhlIGNoYW5nZQpmcm9tKSwgY3JlYXRlcyBhIHZpZXcgKHRl bXBvcmFyeSBicmFuY2gpLCBydW5zICJmbiIgdG8gbWFrZSB0aGUKcmVxdWVzdGVkIGNoYW5nZSAo d2hpY2ggc2hvdWxkIGFsd2F5cyBzdWNjZWVkKSwgbWVyZ2VzIHRoZSB0ZW1wb3JhcnkKYnJhbmNo IGJhY2sgdG8gbWFzdGVyLCBhbmQgd2FpdHMgZm9yIHRoZSBvbl91cGRhdGUgdG8gbm90aWNlIGl0 OgoKICBsZXQgbWVyZ2VfdG9fbWFzdGVyIHQgfmJhc2Ugfm1zZyBmbiA9CiAgICBsZXQgcGF0aCA9 IEkuS2V5LmVtcHR5IGluCiAgICBSLm1ha2VfdmlldyBiYXNlID4+PSBmdW4gdmlldyAtPgogICAg Zm4gdmlldyA+Pj0gZnVuIHJlc3VsdCAtPgogICAgTHd0X211dGV4LndpdGhfbG9jayB0Lm11dGV4 IChmdW4gKCkgLT4KICAgICAgKCogQXQgdGhpcyBwb2ludCwgaGVhZCBjYW5ub3QgY29udGFpbiBv dXIgY29tbWl0IGJlY2F1c2Ugd2UKaGF2ZW4ndCBtYWRlIGl0IHlldCwKICAgICAgICogYW5kIG5v IHVwZGF0ZXMgY2FuIGhhcHBlbiB3aGlsZSB3ZSBob2xkIHRoZSBsb2NrLiAqKQogICAgICBsZXQg b2xkX2hlYWQgPSB0LmhlYWQgaW4KICAgICAgbGV0IHVwZGF0ZWQgPSBMd3RfY29uZGl0aW9uLndh aXQgdC51cGRhdGVkIGluCiAgICAgIFIuVi5tZXJnZV9wYXRoICh0LmJyYW5jaCBtc2cpIHBhdGgg dmlldyA+Pj0gZnVuY3Rpb24KICAgICAgfCBgQ29uZmxpY3QgbXNnIC0+IENrX3V0aWxzLmVycm9y ICJDb25mbGljdCBkdXJpbmcgbWVyZ2U6ICVzCihkaXNjYXJkaW5nIGNoYW5nZSkiIG1zZwogICAg ICB8IGBPayAoKSAtPgogICAgICBJLmhlYWQgKHQuYnJhbmNoICJHZXQgbGF0ZXN0IGNvbW1pdCIp ID58PSBmdW5jdGlvbgogICAgICB8IFNvbWUgbmV3X2hlYWQgd2hlbiBuZXdfaGVhZCA8PiBvbGRf aGVhZCAtPgogICAgICAgICAgKCogW3VwZGF0ZWRdIGNhbm5vdCBoYXZlIGZpcmVkIHlldCBiZWNh dXNlIHdlIHN0aWxsIGhvbGQgdGhlCmxvY2suIFdoZW4gaXQgZG9lcwogICAgICAgICAgICogZmly ZSBuZXh0LCBpdCBtdXN0IGNvbnRhaW4gb3VyIHVwZGF0ZS4gSXQgbXVzdCBmaXJlIHNvb24sCmFz IGhlYWQgaGFzIGNoYW5nZWQuICopCiAgICAgICAgICB1cGRhdGVkCiAgICAgIHwgXyAtPgogICAg ICAgICAgKCogT3VyIGNoYW5nZSBoYWQgbm8gZWZmZWN0LCBzbyBkb24ndCB3YWl0IGZvciBoZWFk IHRvIG1vdmUuCiAgICAgICAgICAgKiBPciwgdGhlIGJyYW5jaCB3YXMgZGVsZXRlZCAtIG5vIHBv aW50IHdhaXRpbmcgdGhlbiBlaXRoZXIuICopCiAgICAgICAgICByZXR1cm4gKCkKICAgICkgPj49 IGZ1biB1cGRhdGVkIC0+ICAgICgqIENoYW5nZXMgaGF2ZSBiZWVuIGNvbW1pdHRlZC4gKikKICAg IHVwZGF0ZWQgPj49IGZ1biAoKSAtPiAgICgqIFtvbl91cGRhdGVdIGhhcyBiZWVuIGNhbGxlZC4g KikKICAgIHJldHVybiByZXN1bHQKCkRvZXMgdGhpcyBhcHByb2FjaCBzZWVtIHNlbnNpYmxlPyBJ IGZlZWwgbGlrZSB0aGUgQVBJIHBlcmhhcHMgd2Fzbid0CmludGVuZGVkIHRvIGJlIHVzZWQgdGhp cyB3YXkuLi4KCkknbSBzdGlsbCB3b3JyaWVkIGFib3V0IGxvc2luZyBkYXRhIGR1ZSB0byByYWNl cy4gSmF2YVNjcmlwdCAoSSB0aGluaykKZW5zdXJlcyB0aGF0IGFjY2VzcyB0byBsb2NhbCBzdG9y YWdlIGZyb20gZGlmZmVyZW50IHRocmVhZHMgZG9lc24ndApnZXQgaW50ZXJsZWF2ZWQsIGJ1dCBz aW5jZSBJcm1pbiB1c2VzIEx3dCB3ZSBkb24ndCBiZW5lZml0IGZyb20gdGhpcy4KSSBzdXNwZWN0 IHRoYXQgaWYgdHdvIHRhYnMgdHJ5IHRvIG1lcmdlIGF0IG9uY2UgdGhlbiBvbmUncyBjb21taXQg d2lsbApiZSBzaWxlbnRseSBkaXNjYXJkZWQuIFByb2JhYmx5IHRoZSBiYWNrLWVuZCB1cGRhdGUg ZnVuY3Rpb24gc2hvdWxkCnRha2UgdGhlIGV4cGVjdGVkIG9sZCB2YWx1ZSBhcyBhbiBhcmd1bWVu dCBzbyBpdCBjYW4gYWJvcnQgaWYgdGhlCnN0YXRlIGhhcyBjaGFuZ2VkIHNpbmNlIHRoZW4uCgpJ dCB3b3VsZCBhbHNvIGJlIHVzZWZ1bCB0byBnZXQgdGhlIGNvbW1pdCBvYmplY3QgZnJvbSB0aGUg bWVyZ2UgYmVmb3JlCnVwZGF0aW5nIHRoZSBicmFuY2guIFRoYXQgd2F5LCBJIGNvdWxkIHRyeSBs b2FkaW5nIGl0IGFzIGEgc2FuaXR5CmNoZWNrIChhbmQgdGh1cyByZWplY3QgYW55IHVwZGF0ZSB0 aGF0IHdvdWxkIHJlc3VsdCBpbiBhbiB1bnJlYWRhYmxlCnN0YXRlKS4gSSBndWVzcyBJIG5lZWQg dG8gY3JlYXRlIGFub3RoZXIgdGVtcG9yYXJ5IGJyYW5jaCwgbWVyZ2UgdG8KdGhhdCwgdGhlbiBm b3JjZS11cGRhdGUgbWFzdGVyIHRvIGl0LiBTZWVtcyBsaWtlIGEgbG90IG9mIHdvcmssCnRob3Vn aC4KCkFueXdheSwgZGVzcGl0ZSB0aGVzZSBtaW5vciBpc3N1ZXMsIElybWluIGlzIHdvcmtpbmcg Z3JlYXQgc28gZmFyIQoKCi0tIApEciBUaG9tYXMgTGVvbmFyZCAgICAgICAgaHR0cDovLzBpbnN0 YWxsLm5ldC8KR1BHOiA5MjQyIDk4MDcgQzk4NSAzQzA3IDQ0QTYgIDhCOUEgQUUwNyA4MjgwIDU5 QTUgM0NDMQpHUEc6IERBOTggMjVBRSBDQUQwIDg5NzUgN0NEQSAgQkQ4RSAwNzEzIDNGOTYgQ0E3 NCBEOEJBCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpN aXJhZ2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlzdHMueGVucHJvamVj dC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5m by9taXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Wed Mar 04 16:37:08 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 04 Mar 2015 16:37:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTCID-0003hf-KG; Wed, 04 Mar 2015 16:37:05 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTCIC-0003hY-85 for MirageOS-devel@lists.xenproject.org; Wed, 04 Mar 2015 16:37:04 +0000 Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id B9/24-02745-FA437F45; Wed, 04 Mar 2015 16:37:03 +0000 X-Env-Sender: pszmk1@nottingham.ac.uk X-Msg-Ref: server-3.tower-31.messagelabs.com!1425487021!13141634!1 X-Originating-IP: [128.243.43.125] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19620 invoked from network); 4 Mar 2015 16:37:01 -0000 Received: from uidappmx02.nottingham.ac.uk (HELO uidappmx02.nottingham.ac.uk) (128.243.43.125) by server-3.tower-31.messagelabs.com with SMTP; 4 Mar 2015 16:37:01 -0000 Received: from uidappmx02.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id C27552E86A6_4F734ACB; Wed, 4 Mar 2015 16:37:00 +0000 (GMT) Received: from smtp3.nottingham.ac.uk (smtp3.nottingham.ac.uk [128.243.44.55]) by uidappmx02.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id 7618C2E8652_4F734ACF; Wed, 4 Mar 2015 16:37:00 +0000 (GMT) Received: from cirrus.cs.nott.ac.uk ([128.243.23.185]) by smtp3.nottingham.ac.uk with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YTCI7-0007Iw-Gu; Wed, 04 Mar 2015 16:37:00 +0000 Message-ID: <54F734A7.90405@nottingham.ac.uk> Date: Wed, 04 Mar 2015 16:36:55 +0000 From: Masoud Koleini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Richard Mortier , David Scott References: <9C6275D4-2397-45E7-B18A-81A47C317545@recoil.org> In-Reply-To: X-Spam-Score: -1.0 (-) X-Spam-Report: Spam detection software, running on the system "smtp3.nottingham.ac.uk", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi all, We have now created `mirage-perf` repository that provides a simple Mirage performance regression test on XenServer: https://github.com/mirage/mirage-perf [...] Content analysis details: (-1.0 points, 4.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP Cc: mirageos-devel , Anil Madhavapeddy Subject: Re: [MirageOS-devel] performance regression tests X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi all, We have now created `mirage-perf` repository that provides a simple Mirage performance regression test on XenServer: https://github.com/mirage/mirage-perf This version is much simpler than previous one we announced (https://github.com/koleini/mirage-perf), and so far uses one single unikernel--based on Balraj's iperf--that sends tcp traffic from one interface to the second one at highest possible rate, and retrieves statistics. The previous version of mirage-perf runs on Xen Dom0, creates a linux-based vm (traffic generator) and a Mirage unikernel, and installs off-the-shelf tools to generate and monitor traffic focusing on customised performance regression testing of mirage-net-xen. Please send us any feedback or suggestion for the tests that you thing would be useful to add. Thanks. On 15/02/15 12:50, Richard Mortier wrote: > yes, it's still the 2014/15 academic year :p > > i suspect i know the answer to this but just in case: i presume by > "bare metal" you really do mean bare metal? ie., inside a virtualbox > is not going to work? > > masoud-- if that's the case, i'll pick this up with you offline. > there's a server in nottingham that you should be able to get access > to and do what you want with. i originally put xen on it by hand and > used the xm/xl tools, but it sounds like it might be time to wipe it > and start again with xenserver. > > > On 15 February 2015 at 12:18, David Scott wrote: >> >> On Sun, Feb 15, 2015 at 11:52 AM, Richard Mortier >> wrote: >>> On 15 February 2015 at 11:28, Anil Madhavapeddy wrote: >>>> On 15 Feb 2015, at 11:19, Richard Mortier >>>> wrote: >>>>> On 15 February 2015 at 11:15, Anil Madhavapeddy >>>>> wrote: >>>>>> This is great to see -- thanks for working on this Masoud! >>>>>> >>>>>> In particular, having even a simple iperf test would let us test >>>>>> several interesting combinations straight away: >>>>>> >>>>>> - vary OCaml version (4.01 vs 4.02 is now supported), and there >>>>>> is an experimental inlining branch in 4.03dev that could directly >>>>>> be tested using this infrastructure. >>>>> ok-- so i guess that needs a switch/env var to specify the `opam >>>>> switch` to use? >>>> Yeah. Although from the performance scripts' perspective, it's better >>>> if they just assume that there is a working OPAM environment. It would >>>> be easier to control these parameters from outside, and keep the perf >>>> scripts as easy to run as possible. >>> ah-- original thinking was to make `mir-perf.sh` a harness that might >>> be fired by `git-bisect`. >>> >>> if it's just to be a script to run a single experiment (parameter set) >>> in a pre-configured environment, then that's a lot simpler. >>> >>>> A couple of other things that might help: >>>> >>>> - Luke Dunstan has a rather comprehensive acceptance test suite for >>>> MDNS: >>>> https://github.com/infidel/ocaml-mdns/tree/master/lib_test/acceptance >>>> >>>> - OCamlPro has a benchmarking system for core OCaml here that may have >>>> some useful libraries: https://github.com/OCamlPro/operf-macro >>>> >>>> - Performance tests could be wrapped using Core_bench, which >>>> does linear regression across runs. >>>> >>>> https://realworldocaml.org/v1/en/html/understanding-the-garbage-collector.html#the-mutable-write-barrier >>>> >>> cool, ta. >>> >>>>>> - evaluate the impact of some features incoming such as the open >>>>>> RFC for checksum offload. >>>>> how are they specified -- as a PR? >>>>> in which case, masoud-- i guess that >>>>> https://help.github.com/articles/checking-out-pull-requests-locally/ >>>>> is a starting point for how to specify a particular PR rather than >>>>> simply a commit rev. >>>> Yes, although again this would be better done outside the performance >>>> harness as an OPAM pin for the local environment. Just having the >>>> ability to quickly run a performance test would be invaluable at this >>>> stage. >>> so the caller of the script will >>> >>> + select their opam switch >>> + pin any libraries, whether to PRs or particular commit-revs >>> + record the environment configuration >>> >>> + then run the script, specifying the test to run, which will >>> + start the unikernel-under-test >>> + start any testing-unikernels (eg., iperf-client, iperf-server) >>> + collect and record test results >>> >>> ...right? >>> >>> ultimately i was thinking to have the recorded test results put in a >>> repo somewhere too, so that they could be visualised, compared to a >>> benchmark, etc. >>> >>>>> just to be clear -- you mean does iperf via unikernels, ie., all the >>>>> tests that are executed should also be unikernels rather than standard >>>>> tools so that we don't take dependencies on an underlying platform >>>>> like the dom0? >>>> Yes -- Xen unikernels would be the primary target. >>> cool. less shell hacking, more unikernel hacking :) >>> >>>> Starting and stopping VMs in open source Xen can be bit of a pain, so >>>> it would be ok if the test harness used XenServer (which the ARM SDcard >>>> images now include). Jon or Dave could comment on the state of the >>>> XMLRPC >>>> OCaml bindings to XenServer... >>> that would be useful. is it easy to get xenserver installed on x86 as >>> well? (that's the platform masoud is mostly working on.) >> >> x86 as well? What is this, 2014? :-) Your options are: >> >> 1. install the latest 6.5 release of xenserver on bare metal >> >> Pros: this is well tested and will work very well as a virtualisation >> platform >> Cons: it takes over a whole machine. To do unikernel development you'll need >> to install a dev VM i.e. you can't do it in dom0. It's good practice to >> leave dom0 alone anyway. Think of it like a black box which can run VMs. >> >> 2. build the latest version from source and install on a CentOS 6/7 or maybe >> Ubuntu box >> >> Pros: you can do whatever you want with dom0 >> Cons: some aspect of running VMs/ managing networks / managing storage is >> bound to not work and you'll need to debug it. There is little automated >> testing of this configuration, I (also Euan, Jon) try to fix bugs when I/we >> encounter them on a best-effort basis. >> >> If you want to focus on unikernel dev and test, I recommend option 1. If you >> want a new hobby of debugging VM hosting software, then try option 2. >> >> In the long run ... we'll converge option 1 and option 2... but I wouldn't >> wait. >> >> Cheers, >> Dave >> >>> >>>>> cool... (one day i must learn about the cambridge infrastructure >>>>> machines :) >>>> Be careful what you wish for :) >>> now i'm genuinely curious... :) >>> >>> -- >>> Richard Mortier >>> richard.mortier@cl.cam.ac.uk >>> >>> _______________________________________________ >>> MirageOS-devel mailing list >>> MirageOS-devel@lists.xenproject.org >>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >> >> >> >> -- >> Dave Scott > > -- Research Fellow School of Computer Science University of Nottingham Nottingham NG8 1BB This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Mar 04 16:37:08 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 04 Mar 2015 16:37:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTCID-0003hf-KG; Wed, 04 Mar 2015 16:37:05 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTCIC-0003hY-85 for MirageOS-devel@lists.xenproject.org; Wed, 04 Mar 2015 16:37:04 +0000 Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id B9/24-02745-FA437F45; Wed, 04 Mar 2015 16:37:03 +0000 X-Env-Sender: pszmk1@nottingham.ac.uk X-Msg-Ref: server-3.tower-31.messagelabs.com!1425487021!13141634!1 X-Originating-IP: [128.243.43.125] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19620 invoked from network); 4 Mar 2015 16:37:01 -0000 Received: from uidappmx02.nottingham.ac.uk (HELO uidappmx02.nottingham.ac.uk) (128.243.43.125) by server-3.tower-31.messagelabs.com with SMTP; 4 Mar 2015 16:37:01 -0000 Received: from uidappmx02.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id C27552E86A6_4F734ACB; Wed, 4 Mar 2015 16:37:00 +0000 (GMT) Received: from smtp3.nottingham.ac.uk (smtp3.nottingham.ac.uk [128.243.44.55]) by uidappmx02.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id 7618C2E8652_4F734ACF; Wed, 4 Mar 2015 16:37:00 +0000 (GMT) Received: from cirrus.cs.nott.ac.uk ([128.243.23.185]) by smtp3.nottingham.ac.uk with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YTCI7-0007Iw-Gu; Wed, 04 Mar 2015 16:37:00 +0000 Message-ID: <54F734A7.90405@nottingham.ac.uk> Date: Wed, 04 Mar 2015 16:36:55 +0000 From: Masoud Koleini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Richard Mortier , David Scott References: <9C6275D4-2397-45E7-B18A-81A47C317545@recoil.org> In-Reply-To: X-Spam-Score: -1.0 (-) X-Spam-Report: Spam detection software, running on the system "smtp3.nottingham.ac.uk", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi all, We have now created `mirage-perf` repository that provides a simple Mirage performance regression test on XenServer: https://github.com/mirage/mirage-perf [...] Content analysis details: (-1.0 points, 4.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP Cc: mirageos-devel , Anil Madhavapeddy Subject: Re: [MirageOS-devel] performance regression tests X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi all, We have now created `mirage-perf` repository that provides a simple Mirage performance regression test on XenServer: https://github.com/mirage/mirage-perf This version is much simpler than previous one we announced (https://github.com/koleini/mirage-perf), and so far uses one single unikernel--based on Balraj's iperf--that sends tcp traffic from one interface to the second one at highest possible rate, and retrieves statistics. The previous version of mirage-perf runs on Xen Dom0, creates a linux-based vm (traffic generator) and a Mirage unikernel, and installs off-the-shelf tools to generate and monitor traffic focusing on customised performance regression testing of mirage-net-xen. Please send us any feedback or suggestion for the tests that you thing would be useful to add. Thanks. On 15/02/15 12:50, Richard Mortier wrote: > yes, it's still the 2014/15 academic year :p > > i suspect i know the answer to this but just in case: i presume by > "bare metal" you really do mean bare metal? ie., inside a virtualbox > is not going to work? > > masoud-- if that's the case, i'll pick this up with you offline. > there's a server in nottingham that you should be able to get access > to and do what you want with. i originally put xen on it by hand and > used the xm/xl tools, but it sounds like it might be time to wipe it > and start again with xenserver. > > > On 15 February 2015 at 12:18, David Scott wrote: >> >> On Sun, Feb 15, 2015 at 11:52 AM, Richard Mortier >> wrote: >>> On 15 February 2015 at 11:28, Anil Madhavapeddy wrote: >>>> On 15 Feb 2015, at 11:19, Richard Mortier >>>> wrote: >>>>> On 15 February 2015 at 11:15, Anil Madhavapeddy >>>>> wrote: >>>>>> This is great to see -- thanks for working on this Masoud! >>>>>> >>>>>> In particular, having even a simple iperf test would let us test >>>>>> several interesting combinations straight away: >>>>>> >>>>>> - vary OCaml version (4.01 vs 4.02 is now supported), and there >>>>>> is an experimental inlining branch in 4.03dev that could directly >>>>>> be tested using this infrastructure. >>>>> ok-- so i guess that needs a switch/env var to specify the `opam >>>>> switch` to use? >>>> Yeah. Although from the performance scripts' perspective, it's better >>>> if they just assume that there is a working OPAM environment. It would >>>> be easier to control these parameters from outside, and keep the perf >>>> scripts as easy to run as possible. >>> ah-- original thinking was to make `mir-perf.sh` a harness that might >>> be fired by `git-bisect`. >>> >>> if it's just to be a script to run a single experiment (parameter set) >>> in a pre-configured environment, then that's a lot simpler. >>> >>>> A couple of other things that might help: >>>> >>>> - Luke Dunstan has a rather comprehensive acceptance test suite for >>>> MDNS: >>>> https://github.com/infidel/ocaml-mdns/tree/master/lib_test/acceptance >>>> >>>> - OCamlPro has a benchmarking system for core OCaml here that may have >>>> some useful libraries: https://github.com/OCamlPro/operf-macro >>>> >>>> - Performance tests could be wrapped using Core_bench, which >>>> does linear regression across runs. >>>> >>>> https://realworldocaml.org/v1/en/html/understanding-the-garbage-collector.html#the-mutable-write-barrier >>>> >>> cool, ta. >>> >>>>>> - evaluate the impact of some features incoming such as the open >>>>>> RFC for checksum offload. >>>>> how are they specified -- as a PR? >>>>> in which case, masoud-- i guess that >>>>> https://help.github.com/articles/checking-out-pull-requests-locally/ >>>>> is a starting point for how to specify a particular PR rather than >>>>> simply a commit rev. >>>> Yes, although again this would be better done outside the performance >>>> harness as an OPAM pin for the local environment. Just having the >>>> ability to quickly run a performance test would be invaluable at this >>>> stage. >>> so the caller of the script will >>> >>> + select their opam switch >>> + pin any libraries, whether to PRs or particular commit-revs >>> + record the environment configuration >>> >>> + then run the script, specifying the test to run, which will >>> + start the unikernel-under-test >>> + start any testing-unikernels (eg., iperf-client, iperf-server) >>> + collect and record test results >>> >>> ...right? >>> >>> ultimately i was thinking to have the recorded test results put in a >>> repo somewhere too, so that they could be visualised, compared to a >>> benchmark, etc. >>> >>>>> just to be clear -- you mean does iperf via unikernels, ie., all the >>>>> tests that are executed should also be unikernels rather than standard >>>>> tools so that we don't take dependencies on an underlying platform >>>>> like the dom0? >>>> Yes -- Xen unikernels would be the primary target. >>> cool. less shell hacking, more unikernel hacking :) >>> >>>> Starting and stopping VMs in open source Xen can be bit of a pain, so >>>> it would be ok if the test harness used XenServer (which the ARM SDcard >>>> images now include). Jon or Dave could comment on the state of the >>>> XMLRPC >>>> OCaml bindings to XenServer... >>> that would be useful. is it easy to get xenserver installed on x86 as >>> well? (that's the platform masoud is mostly working on.) >> >> x86 as well? What is this, 2014? :-) Your options are: >> >> 1. install the latest 6.5 release of xenserver on bare metal >> >> Pros: this is well tested and will work very well as a virtualisation >> platform >> Cons: it takes over a whole machine. To do unikernel development you'll need >> to install a dev VM i.e. you can't do it in dom0. It's good practice to >> leave dom0 alone anyway. Think of it like a black box which can run VMs. >> >> 2. build the latest version from source and install on a CentOS 6/7 or maybe >> Ubuntu box >> >> Pros: you can do whatever you want with dom0 >> Cons: some aspect of running VMs/ managing networks / managing storage is >> bound to not work and you'll need to debug it. There is little automated >> testing of this configuration, I (also Euan, Jon) try to fix bugs when I/we >> encounter them on a best-effort basis. >> >> If you want to focus on unikernel dev and test, I recommend option 1. If you >> want a new hobby of debugging VM hosting software, then try option 2. >> >> In the long run ... we'll converge option 1 and option 2... but I wouldn't >> wait. >> >> Cheers, >> Dave >> >>> >>>>> cool... (one day i must learn about the cambridge infrastructure >>>>> machines :) >>>> Be careful what you wish for :) >>> now i'm genuinely curious... :) >>> >>> -- >>> Richard Mortier >>> richard.mortier@cl.cam.ac.uk >>> >>> _______________________________________________ >>> MirageOS-devel mailing list >>> MirageOS-devel@lists.xenproject.org >>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >> >> >> >> -- >> Dave Scott > > -- Research Fellow School of Computer Science University of Nottingham Nottingham NG8 1BB This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Mar 04 16:40:29 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 04 Mar 2015 16:40:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTCLU-0003kL-V0; Wed, 04 Mar 2015 16:40:28 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTCLU-0003kG-6f for mirageos-devel@lists.xenproject.org; Wed, 04 Mar 2015 16:40:28 +0000 Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id 82/84-03710-B7537F45; Wed, 04 Mar 2015 16:40:27 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-15.tower-31.messagelabs.com!1425487226!12953424!1 X-Originating-IP: [209.85.212.171] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8918 invoked from network); 4 Mar 2015 16:40:26 -0000 Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com) (209.85.212.171) by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2015 16:40:26 -0000 Received: by wibbs8 with SMTP id bs8so661139wib.0 for ; Wed, 04 Mar 2015 08:40:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=quGumeU1YDymyUMdWKHU+kf2FfPUnuKA25nsF1vO9RQ=; b=WPW8KGFb1fpkVMt0QSFPOXajg6MmmXIpcQb9ipgvqs2a4vxzrsJHoxbXKxuoawqA/f lt0qymWKvml3Fz0U6dOl4OSWqe+j+wg18pAqMiYXZnclOcS/EncRlTTWPFZi5K25we9q iI8mr4lZtzFV11mV1Q6zI5MdfS1SzZ/52X1uhvU4cIdhGJQ8IId1X+FO3i0Dl6htmGp8 0Q7qIw2tb6989IWqaXwPqpK5gePTFUsZseiy6lgoUQAHkyhNrnC7qAfFyJHdV+Cwvo2h gAh8UYwarCU5dr5ZYOri00yTAuRK92DwWGRCuXfn9RiAaUsA0PmRFpmhAULquFKwZ/7/ H0jw== X-Received: by 10.180.206.83 with SMTP id lm19mr14491557wic.41.1425487225574; Wed, 04 Mar 2015 08:40:25 -0800 (PST) Received: from ?IPv6:2001:630:212:248:f057:44fe:2888:9b7? ([2001:630:212:248:f057:44fe:2888:9b7]) by mx.google.com with ESMTPSA id p1sm7803006wib.23.2015.03.04.08.40.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Mar 2015 08:40:24 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Thomas Gazagnaire In-Reply-To: Date: Wed, 4 Mar 2015 16:40:24 +0000 Message-Id: References: <8CEDB416-6238-4888-BA4B-B7305FDDE2D9@gazagnaire.org> <9349273A-0BB4-40C4-BF06-4307085AA90C@recoil.org> <47D39FA3-050E-46E6-89D2-4253484E24A8@gazagnaire.org> To: Thomas Leonard X-Mailer: Apple Mail (2.2070.6) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Irmin API newbie questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org > I've now extended this to support events, so if the user has the page > open in two tabs they stay in sync. However, there's still the problem > that you can't remove a watch, so once you start watching you have to > keep on doing so. Not a problem for my app (I just watch the master > branch) but might be a problem in general. Currently, if you do not use an event stream anymore, the stream reader should be GCed automatically which will cause the stream writer (Irmin) to be clean-up on the next write. However I'm not totally sure the readers are properly GCed, so I need to check that before the release[1]. Did you notice some leaks there? But yes, you as don't control when the GC happen it might be better to leave the watch deallocation to the user. I need to think about that. [1] https://github.com/mirage/irmin/issues/124 > I've also now made my app do merges: every item displayed on the > screen records the Irmin commit from which it came. Usually this is > the latest version, but if you're e.g. editing a form then it's the > version when you started the edit. When you submit a change, it > commits against that revision and then merges the result back to > master. This means that if you make two different edits to something > in two tabs, the conflict will be detected instead of silently > discarding the first change. (Ideally I want to resolve the conflicts, > but for now it just discards the second change and reports the error > to the user). > > I'm not sure I'm using the API correctly though. Here's my code for > monitoring the master branch and updating the display when it changes: > > https://github.com/talex5/cuekeeper/blob/83a5e3c146f2406b8491b1c9915cb7fef6753869/ck_update.ml#L30 > > let make ~on_update branch = > let watch_tags = I.watch_tags (branch "Watch master") in > get_head_commit branch >>= fun initial_head -> > let mutex = Lwt_mutex.create () in > match I.branch (branch "Get branch name") with > | `Head _ -> failwith "Not a tag!" > | `Tag branch_name -> > let t = { > branch; > head = initial_head; > updated = Lwt_condition.create (); > mutex; > } in > async (fun () -> > on_update >>= fun on_update -> > watch_tags |> Lwt_stream.iter_s (function > | (n, Some _commit) when n = branch_name -> > (* (ignore the commit ID in the update message; we want > the latest) *) > Lwt_mutex.with_lock t.mutex (fun () -> > I.head (branch "Get latest commit") >>= function > | None -> Ck_utils.error "Branch '%s' has disappeared!" > branch_name > | Some head -> > if head <> t.head then ( > t.head <- head; > on_update head >>= fun () -> > Lwt_condition.broadcast t.updated (); > return () > ) else ( > return () > ) > ) > | _ -> return () > ) > ); > return t Hum, this clearly demonstrates that I need to improve the watch API ... I completely agree that getting the initial head is important: we need something similar to test_and_set at this level I think. I'm happy to move away from Lwt streams and use a more conventional callback API, where it's easier to control the scheduling (ie. hide the stream and expose only your "make" function directly in Irmin). I need to check with Dave what he needs exactly for Xenstore watches... > Some points you have to worry about here: > > - Irmin makes it easy to read data directly from a branch (tag), but > this is usually unsafe, since a tag can update while you're reading > it. Therefore, I think I always have to first get the head commit, > then create a new store for that revision, then read from that. It > might be safer if a branch just provided a way to get a commit, and > reads had to be done from a fixed commit. Hum, reading a tag should not be unsafe as the RW backend should ensure that updates are atomic. See Get_unix.with_write_file[2] for example where we use the fact that "rename" is the only operation guaranteed to be atomic on POSIX filesystem. Not sure which guarantee do you have for HTML5 local storage though ... I'm afraid you don't have many[3]. [2] https://github.com/mirage/ocaml-git/blob/master/lib/unix/git_unix.ml#L300 [3] http://balpha.de/2012/03/javascript-concurrency-and-locking-the-html5-localstorage/ > - I only need to be notified once after a series of changes. I discard > the commit in the watch notification and always read the latest. > Otherwise, I might update the GUI to show stale data. Since a merge > can add many commits at once, the stream API doesn't seem useful (it > still doesn't ensure you see each commit individually, if that's what > you wanted). In some cases this might be useful (if you store incremental updates that you want to replay) but I agree that this is not terribly useful in the main case. > - The functions that update the store shouldn't return until the > update has been see by the model ("on_update" has been called). I > therefore create a mutex and a Lwt_condition so that the commit > functions can be sure their change has been seen. agreed and I think that's a good property to move into the watch API. > All the code for changing the model goes via "merge_to_master". This > takes a "base" argument (the commit which the user made the change > from), creates a view (temporary branch), runs "fn" to make the > requested change (which should always succeed), merges the temporary > branch back to master, and waits for the on_update to notice it: > > let merge_to_master t ~base ~msg fn = > let path = I.Key.empty in > R.make_view base >>= fun view -> > fn view >>= fun result -> > Lwt_mutex.with_lock t.mutex (fun () -> > (* At this point, head cannot contain our commit because we > haven't made it yet, > * and no updates can happen while we hold the lock. *) > let old_head = t.head in > let updated = Lwt_condition.wait t.updated in > R.V.merge_path (t.branch msg) path view >>= function > | `Conflict msg -> Ck_utils.error "Conflict during merge: %s > (discarding change)" msg > | `Ok () -> > I.head (t.branch "Get latest commit") >|= function > | Some new_head when new_head <> old_head -> > (* [updated] cannot have fired yet because we still hold the > lock. When it does > * fire next, it must contain our update. It must fire soon, > as head has changed. *) > updated > | _ -> > (* Our change had no effect, so don't wait for head to move. > * Or, the branch was deleted - no point waiting then either. *) > return () > ) >>= fun updated -> (* Changes have been committed. *) > updated >>= fun () -> (* [on_update] has been called. *) > return result > > Does this approach seem sensible? I feel like the API perhaps wasn't > intended to be used this way... I can see why you are doing all of this, and this is certainly not optimal for an API point of view. One think I can do to help is to add an invariant to all the high-level updates (such as merge) functions to only perform the whole update only if the head didn't change since the beginning of the operations. It's an easy check to add and it will help a lot to reason on what happens during concurrent updates. The only reason I didn't do it before is that I was worried about starvation issues and other concurrency scheduling related issues - but I guess they are better than data loss ... and we could just picky bag on Lwt_mutex / Lwt_condition properties. [4] https://github.com/mirage/irmin/issues/157 > I'm still worried about losing data due to races. JavaScript (I think) > ensures that access to local storage from different threads doesn't > get interleaved, but since Irmin uses Lwt we don't benefit from this. > I suspect that if two tabs try to merge at once then one's commit will > be silently discarded. Probably the back-end update function should > take the expected old value as an argument so it can abort if the > state has changed since then. Not sure to understand what Lwt exactly changes there. I'm happy to modify the signature of the backends to add more checks, but modifying the "RW.update" signature to take an optional current value to test would mean modifying the "Irmin.update" signature as well. Not sure that's exactly what we want. Could add a new "RW.test_and_set" function though.[4] I'll think about it. [5] https://github.com/mirage/irmin/issues/155 > It would also be useful to get the commit object from the merge before > updating the branch. That way, I could try loading it as a sanity > check (and thus reject any update that would result in an unreadable > state). I guess I need to create another temporary branch, merge to > that, then force-update master to it. Seems like a lot of work, > though. I think it's easy to add a "try_merge" function which do not update the head. The current way to do that is indeed to create a temporary branch. [6] https://github.com/mirage/irmin/issues/156 > Anyway, despite these minor issues, Irmin is working great so far! As usual, thanks for the very useful feedback! That'll definitely help improving the watch API and the overhaul usability. Thomas _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Mar 04 16:40:29 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 04 Mar 2015 16:40:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTCLU-0003kL-V0; Wed, 04 Mar 2015 16:40:28 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTCLU-0003kG-6f for mirageos-devel@lists.xenproject.org; Wed, 04 Mar 2015 16:40:28 +0000 Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id 82/84-03710-B7537F45; Wed, 04 Mar 2015 16:40:27 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-15.tower-31.messagelabs.com!1425487226!12953424!1 X-Originating-IP: [209.85.212.171] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8918 invoked from network); 4 Mar 2015 16:40:26 -0000 Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com) (209.85.212.171) by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2015 16:40:26 -0000 Received: by wibbs8 with SMTP id bs8so661139wib.0 for ; Wed, 04 Mar 2015 08:40:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=quGumeU1YDymyUMdWKHU+kf2FfPUnuKA25nsF1vO9RQ=; b=WPW8KGFb1fpkVMt0QSFPOXajg6MmmXIpcQb9ipgvqs2a4vxzrsJHoxbXKxuoawqA/f lt0qymWKvml3Fz0U6dOl4OSWqe+j+wg18pAqMiYXZnclOcS/EncRlTTWPFZi5K25we9q iI8mr4lZtzFV11mV1Q6zI5MdfS1SzZ/52X1uhvU4cIdhGJQ8IId1X+FO3i0Dl6htmGp8 0Q7qIw2tb6989IWqaXwPqpK5gePTFUsZseiy6lgoUQAHkyhNrnC7qAfFyJHdV+Cwvo2h gAh8UYwarCU5dr5ZYOri00yTAuRK92DwWGRCuXfn9RiAaUsA0PmRFpmhAULquFKwZ/7/ H0jw== X-Received: by 10.180.206.83 with SMTP id lm19mr14491557wic.41.1425487225574; Wed, 04 Mar 2015 08:40:25 -0800 (PST) Received: from ?IPv6:2001:630:212:248:f057:44fe:2888:9b7? ([2001:630:212:248:f057:44fe:2888:9b7]) by mx.google.com with ESMTPSA id p1sm7803006wib.23.2015.03.04.08.40.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Mar 2015 08:40:24 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Thomas Gazagnaire In-Reply-To: Date: Wed, 4 Mar 2015 16:40:24 +0000 Message-Id: References: <8CEDB416-6238-4888-BA4B-B7305FDDE2D9@gazagnaire.org> <9349273A-0BB4-40C4-BF06-4307085AA90C@recoil.org> <47D39FA3-050E-46E6-89D2-4253484E24A8@gazagnaire.org> To: Thomas Leonard X-Mailer: Apple Mail (2.2070.6) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Irmin API newbie questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org > I've now extended this to support events, so if the user has the page > open in two tabs they stay in sync. However, there's still the problem > that you can't remove a watch, so once you start watching you have to > keep on doing so. Not a problem for my app (I just watch the master > branch) but might be a problem in general. Currently, if you do not use an event stream anymore, the stream reader should be GCed automatically which will cause the stream writer (Irmin) to be clean-up on the next write. However I'm not totally sure the readers are properly GCed, so I need to check that before the release[1]. Did you notice some leaks there? But yes, you as don't control when the GC happen it might be better to leave the watch deallocation to the user. I need to think about that. [1] https://github.com/mirage/irmin/issues/124 > I've also now made my app do merges: every item displayed on the > screen records the Irmin commit from which it came. Usually this is > the latest version, but if you're e.g. editing a form then it's the > version when you started the edit. When you submit a change, it > commits against that revision and then merges the result back to > master. This means that if you make two different edits to something > in two tabs, the conflict will be detected instead of silently > discarding the first change. (Ideally I want to resolve the conflicts, > but for now it just discards the second change and reports the error > to the user). > > I'm not sure I'm using the API correctly though. Here's my code for > monitoring the master branch and updating the display when it changes: > > https://github.com/talex5/cuekeeper/blob/83a5e3c146f2406b8491b1c9915cb7fef6753869/ck_update.ml#L30 > > let make ~on_update branch = > let watch_tags = I.watch_tags (branch "Watch master") in > get_head_commit branch >>= fun initial_head -> > let mutex = Lwt_mutex.create () in > match I.branch (branch "Get branch name") with > | `Head _ -> failwith "Not a tag!" > | `Tag branch_name -> > let t = { > branch; > head = initial_head; > updated = Lwt_condition.create (); > mutex; > } in > async (fun () -> > on_update >>= fun on_update -> > watch_tags |> Lwt_stream.iter_s (function > | (n, Some _commit) when n = branch_name -> > (* (ignore the commit ID in the update message; we want > the latest) *) > Lwt_mutex.with_lock t.mutex (fun () -> > I.head (branch "Get latest commit") >>= function > | None -> Ck_utils.error "Branch '%s' has disappeared!" > branch_name > | Some head -> > if head <> t.head then ( > t.head <- head; > on_update head >>= fun () -> > Lwt_condition.broadcast t.updated (); > return () > ) else ( > return () > ) > ) > | _ -> return () > ) > ); > return t Hum, this clearly demonstrates that I need to improve the watch API ... I completely agree that getting the initial head is important: we need something similar to test_and_set at this level I think. I'm happy to move away from Lwt streams and use a more conventional callback API, where it's easier to control the scheduling (ie. hide the stream and expose only your "make" function directly in Irmin). I need to check with Dave what he needs exactly for Xenstore watches... > Some points you have to worry about here: > > - Irmin makes it easy to read data directly from a branch (tag), but > this is usually unsafe, since a tag can update while you're reading > it. Therefore, I think I always have to first get the head commit, > then create a new store for that revision, then read from that. It > might be safer if a branch just provided a way to get a commit, and > reads had to be done from a fixed commit. Hum, reading a tag should not be unsafe as the RW backend should ensure that updates are atomic. See Get_unix.with_write_file[2] for example where we use the fact that "rename" is the only operation guaranteed to be atomic on POSIX filesystem. Not sure which guarantee do you have for HTML5 local storage though ... I'm afraid you don't have many[3]. [2] https://github.com/mirage/ocaml-git/blob/master/lib/unix/git_unix.ml#L300 [3] http://balpha.de/2012/03/javascript-concurrency-and-locking-the-html5-localstorage/ > - I only need to be notified once after a series of changes. I discard > the commit in the watch notification and always read the latest. > Otherwise, I might update the GUI to show stale data. Since a merge > can add many commits at once, the stream API doesn't seem useful (it > still doesn't ensure you see each commit individually, if that's what > you wanted). In some cases this might be useful (if you store incremental updates that you want to replay) but I agree that this is not terribly useful in the main case. > - The functions that update the store shouldn't return until the > update has been see by the model ("on_update" has been called). I > therefore create a mutex and a Lwt_condition so that the commit > functions can be sure their change has been seen. agreed and I think that's a good property to move into the watch API. > All the code for changing the model goes via "merge_to_master". This > takes a "base" argument (the commit which the user made the change > from), creates a view (temporary branch), runs "fn" to make the > requested change (which should always succeed), merges the temporary > branch back to master, and waits for the on_update to notice it: > > let merge_to_master t ~base ~msg fn = > let path = I.Key.empty in > R.make_view base >>= fun view -> > fn view >>= fun result -> > Lwt_mutex.with_lock t.mutex (fun () -> > (* At this point, head cannot contain our commit because we > haven't made it yet, > * and no updates can happen while we hold the lock. *) > let old_head = t.head in > let updated = Lwt_condition.wait t.updated in > R.V.merge_path (t.branch msg) path view >>= function > | `Conflict msg -> Ck_utils.error "Conflict during merge: %s > (discarding change)" msg > | `Ok () -> > I.head (t.branch "Get latest commit") >|= function > | Some new_head when new_head <> old_head -> > (* [updated] cannot have fired yet because we still hold the > lock. When it does > * fire next, it must contain our update. It must fire soon, > as head has changed. *) > updated > | _ -> > (* Our change had no effect, so don't wait for head to move. > * Or, the branch was deleted - no point waiting then either. *) > return () > ) >>= fun updated -> (* Changes have been committed. *) > updated >>= fun () -> (* [on_update] has been called. *) > return result > > Does this approach seem sensible? I feel like the API perhaps wasn't > intended to be used this way... I can see why you are doing all of this, and this is certainly not optimal for an API point of view. One think I can do to help is to add an invariant to all the high-level updates (such as merge) functions to only perform the whole update only if the head didn't change since the beginning of the operations. It's an easy check to add and it will help a lot to reason on what happens during concurrent updates. The only reason I didn't do it before is that I was worried about starvation issues and other concurrency scheduling related issues - but I guess they are better than data loss ... and we could just picky bag on Lwt_mutex / Lwt_condition properties. [4] https://github.com/mirage/irmin/issues/157 > I'm still worried about losing data due to races. JavaScript (I think) > ensures that access to local storage from different threads doesn't > get interleaved, but since Irmin uses Lwt we don't benefit from this. > I suspect that if two tabs try to merge at once then one's commit will > be silently discarded. Probably the back-end update function should > take the expected old value as an argument so it can abort if the > state has changed since then. Not sure to understand what Lwt exactly changes there. I'm happy to modify the signature of the backends to add more checks, but modifying the "RW.update" signature to take an optional current value to test would mean modifying the "Irmin.update" signature as well. Not sure that's exactly what we want. Could add a new "RW.test_and_set" function though.[4] I'll think about it. [5] https://github.com/mirage/irmin/issues/155 > It would also be useful to get the commit object from the merge before > updating the branch. That way, I could try loading it as a sanity > check (and thus reject any update that would result in an unreadable > state). I guess I need to create another temporary branch, merge to > that, then force-update master to it. Seems like a lot of work, > though. I think it's easy to add a "try_merge" function which do not update the head. The current way to do that is indeed to create a temporary branch. [6] https://github.com/mirage/irmin/issues/156 > Anyway, despite these minor issues, Irmin is working great so far! As usual, thanks for the very useful feedback! That'll definitely help improving the watch API and the overhaul usability. Thomas _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Mar 04 17:31:37 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 04 Mar 2015 17:31:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTD8w-0003u8-Dn; Wed, 04 Mar 2015 17:31:34 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTD8u-0003o2-HX; Wed, 04 Mar 2015 17:31:32 +0000 Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id 73/CE-02885-37147F45; Wed, 04 Mar 2015 17:31:31 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-9.tower-31.messagelabs.com!1425490288!9366651!1 X-Originating-IP: [74.125.82.182] X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17322 invoked from network); 4 Mar 2015 17:31:28 -0000 Received: from mail-we0-f182.google.com (HELO mail-we0-f182.google.com) (74.125.82.182) by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2015 17:31:28 -0000 Received: by wesq59 with SMTP id q59so47892021wes.1; Wed, 04 Mar 2015 09:31:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version; bh=t49/7hxrjK3pwdvsWyfwKkQOQhHjgOx1RsyUHkYerd0=; b=pZ5uJKTpYbrRwLCYZ9PZON1pGrtqKdCVCHw7Lxg4AXMks1+42C2dZ+Xl5Ez4LOWptL 1JdUx+Cw4sT063tHymI4WkyHA7ECgAZ10LxnCCxySy6Ez6TaON2SWsULakWcnyddZzKy 4TFMuSk/SMqCIzWpeTCCCkaIKC5leQMIbxRKULFvvWHW34O+Y3Xr20mjSUL9AraaX3u3 ZBcnPJkyNjL3h9fSSpDRpS9l/0nEnNQcatwlQPttZwjvgLGgsxHnftW74mwqp1HKH2h0 THzI2Cj+B3ey3nx5iMhY0KX4iP42416jK+ThVz47KPhFf8gKa9Hu+P5/TRigzKreM0vm i0Qg== X-Received: by 10.194.205.138 with SMTP id lg10mr9870324wjc.130.1425490288129; Wed, 04 Mar 2015 09:31:28 -0800 (PST) Received: from [192.168.0.8] (97e3cd44.skybroadband.com. [151.227.205.68]) by mx.google.com with ESMTPSA id gf11sm7995380wic.18.2015.03.04.09.31.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Mar 2015 09:31:26 -0800 (PST) From: Lars Kurth Date: Wed, 4 Mar 2015 17:31:18 +0000 Message-Id: <44A7E990-9056-405D-B619-6695B2204E33@gmail.com> To: xen-devel , xen-api@lists.xenproject.org, mirageos-devel , embedded-pv-devel@lists.xenproject.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: advisory-board@lists.xenproject.org, Russ Pavlicek Subject: [MirageOS-devel] GSoC 2015 - Not accepted ... but some mentoring organisations which have several Xen related projects in them are X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6399232535864710881==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============6399232535864710881== Content-Type: multipart/alternative; boundary="Apple-Mail=_AE147FE4-C337-4AA2-BAB2-AE4136222F15" --Apple-Mail=_AE147FE4-C337-4AA2-BAB2-AE4136222F15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi folks, just a quick note to let you know that we were not accepted for GSoC = this year. Do note that the Linux Foundation, OpenStack Foundation and = many of the other usual suspects have not been accepted this year. We = will find out more why on Friday. However, there are at least 4 Xen = related projects that are managed by other =20 I made a note at the top of = http://wiki.xenproject.org/wiki/Archived/GSoC_2015 = to point applicants = to some of those projects. I have found 5 so far (which may bot be a = complete list): Xen based Hypervisor in a Box @ Centos=C2=A0 = Xen guest support for OpenBSD @ Open BSD Foundation=C2=A0 = 3 Xen related projects @ Ganeti = Other projects which were accepted are QEMU = : note = that there are no Xen related projects, but given that Xen has good = relationships with the QEMU community we may be able to get one or two = projects onto the list if someone steps up and is willing to mentor Best Regards Lars= --Apple-Mail=_AE147FE4-C337-4AA2-BAB2-AE4136222F15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi folks,

just = a quick note to let you know that we were not accepted for GSoC this = year. Do note that the Linux Foundation, OpenStack Foundation and many = of the other usual suspects have not been accepted this year. We will = find out more why on Friday. However, there are at least 4 Xen related = projects that are managed by other
 
I made a note at the top of http://wiki.xenproject.org/wiki/Archived/GSoC_2015 to = point applicants to some of those projects. I have found 5 so far (which = may bot be a complete list):
Other projects which were accepted are QEMU: note that there are no Xen related projects, but = given that Xen has good relationships with the QEMU community we may be = able to get one or two projects onto the list if someone steps up and is = willing to mentor

Best Regards
Lars
= --Apple-Mail=_AE147FE4-C337-4AA2-BAB2-AE4136222F15-- --===============6399232535864710881== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============6399232535864710881==-- From mirageos-devel-bounces@lists.xenproject.org Wed Mar 04 17:31:37 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 04 Mar 2015 17:31:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTD8w-0003u8-Dn; Wed, 04 Mar 2015 17:31:34 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTD8u-0003o2-HX; Wed, 04 Mar 2015 17:31:32 +0000 Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id 73/CE-02885-37147F45; Wed, 04 Mar 2015 17:31:31 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-9.tower-31.messagelabs.com!1425490288!9366651!1 X-Originating-IP: [74.125.82.182] X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17322 invoked from network); 4 Mar 2015 17:31:28 -0000 Received: from mail-we0-f182.google.com (HELO mail-we0-f182.google.com) (74.125.82.182) by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2015 17:31:28 -0000 Received: by wesq59 with SMTP id q59so47892021wes.1; Wed, 04 Mar 2015 09:31:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version; bh=t49/7hxrjK3pwdvsWyfwKkQOQhHjgOx1RsyUHkYerd0=; b=pZ5uJKTpYbrRwLCYZ9PZON1pGrtqKdCVCHw7Lxg4AXMks1+42C2dZ+Xl5Ez4LOWptL 1JdUx+Cw4sT063tHymI4WkyHA7ECgAZ10LxnCCxySy6Ez6TaON2SWsULakWcnyddZzKy 4TFMuSk/SMqCIzWpeTCCCkaIKC5leQMIbxRKULFvvWHW34O+Y3Xr20mjSUL9AraaX3u3 ZBcnPJkyNjL3h9fSSpDRpS9l/0nEnNQcatwlQPttZwjvgLGgsxHnftW74mwqp1HKH2h0 THzI2Cj+B3ey3nx5iMhY0KX4iP42416jK+ThVz47KPhFf8gKa9Hu+P5/TRigzKreM0vm i0Qg== X-Received: by 10.194.205.138 with SMTP id lg10mr9870324wjc.130.1425490288129; Wed, 04 Mar 2015 09:31:28 -0800 (PST) Received: from [192.168.0.8] (97e3cd44.skybroadband.com. [151.227.205.68]) by mx.google.com with ESMTPSA id gf11sm7995380wic.18.2015.03.04.09.31.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Mar 2015 09:31:26 -0800 (PST) From: Lars Kurth Date: Wed, 4 Mar 2015 17:31:18 +0000 Message-Id: <44A7E990-9056-405D-B619-6695B2204E33@gmail.com> To: xen-devel , xen-api@lists.xenproject.org, mirageos-devel , embedded-pv-devel@lists.xenproject.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: advisory-board@lists.xenproject.org, Russ Pavlicek Subject: [MirageOS-devel] GSoC 2015 - Not accepted ... but some mentoring organisations which have several Xen related projects in them are X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6399232535864710881==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============6399232535864710881== Content-Type: multipart/alternative; boundary="Apple-Mail=_AE147FE4-C337-4AA2-BAB2-AE4136222F15" --Apple-Mail=_AE147FE4-C337-4AA2-BAB2-AE4136222F15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi folks, just a quick note to let you know that we were not accepted for GSoC = this year. Do note that the Linux Foundation, OpenStack Foundation and = many of the other usual suspects have not been accepted this year. We = will find out more why on Friday. However, there are at least 4 Xen = related projects that are managed by other =20 I made a note at the top of = http://wiki.xenproject.org/wiki/Archived/GSoC_2015 = to point applicants = to some of those projects. I have found 5 so far (which may bot be a = complete list): Xen based Hypervisor in a Box @ Centos=C2=A0 = Xen guest support for OpenBSD @ Open BSD Foundation=C2=A0 = 3 Xen related projects @ Ganeti = Other projects which were accepted are QEMU = : note = that there are no Xen related projects, but given that Xen has good = relationships with the QEMU community we may be able to get one or two = projects onto the list if someone steps up and is willing to mentor Best Regards Lars= --Apple-Mail=_AE147FE4-C337-4AA2-BAB2-AE4136222F15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi folks,

just = a quick note to let you know that we were not accepted for GSoC this = year. Do note that the Linux Foundation, OpenStack Foundation and many = of the other usual suspects have not been accepted this year. We will = find out more why on Friday. However, there are at least 4 Xen related = projects that are managed by other
 
I made a note at the top of http://wiki.xenproject.org/wiki/Archived/GSoC_2015 to = point applicants to some of those projects. I have found 5 so far (which = may bot be a complete list):
Other projects which were accepted are QEMU: note that there are no Xen related projects, but = given that Xen has good relationships with the QEMU community we may be = able to get one or two projects onto the list if someone steps up and is = willing to mentor

Best Regards
Lars
= --Apple-Mail=_AE147FE4-C337-4AA2-BAB2-AE4136222F15-- --===============6399232535864710881== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============6399232535864710881==-- From mirageos-devel-bounces@lists.xenproject.org Wed Mar 04 17:40:42 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 04 Mar 2015 17:40:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTDHj-0004wS-PU; Wed, 04 Mar 2015 17:40:39 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTDHi-0004w5-Pl; Wed, 04 Mar 2015 17:40:38 +0000 Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id 9A/8A-03185-59347F45; Wed, 04 Mar 2015 17:40:37 +0000 X-Env-Sender: amc79@cam.ac.uk X-Msg-Ref: server-3.tower-31.messagelabs.com!1425490836!13161956!1 X-Originating-IP: [131.111.8.151] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MSA9PiAxNDE4OTU=\n X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30335 invoked from network); 4 Mar 2015 17:40:37 -0000 Received: from ppsw-51.csi.cam.ac.uk (HELO ppsw-51.csi.cam.ac.uk) (131.111.8.151) by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Mar 2015 17:40:37 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from host81-149-102-120.in-addr.btopenworld.com ([81.149.102.120]:62968 helo=[10.0.0.31]) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587) with esmtpsa (PLAIN:amc79) (TLSv1:AES128-SHA:128) id 1YTDHg-00036d-Wt (Exim 4.82_3-c0e5623) (return-path ); Wed, 04 Mar 2015 17:40:36 +0000 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Amir Chaudhry In-Reply-To: <44A7E990-9056-405D-B619-6695B2204E33@gmail.com> Date: Wed, 4 Mar 2015 17:40:31 +0000 Message-Id: References: <44A7E990-9056-405D-B619-6695B2204E33@gmail.com> To: Lars Kurth X-Mailer: Apple Mail (2.1510) Cc: xen-api@lists.xenproject.org, advisory-board@lists.xenproject.org, Russ Pavlicek , embedded-pv-devel@lists.xenproject.org, mirageos-devel , xen-devel Subject: Re: [MirageOS-devel] GSoC 2015 - Not accepted ... but some mentoring organisations which have several Xen related projects in them are X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org I noticed this the other day and had a quick scout around. "Mozilla not accepted for Google Summer of Code 2015" http://blog.queze.net/post/2015/03/03/Mozilla-not-accepted-for-Google-Summe= r-of-Code-2015 "Google=92s program is enormously popular, and over-subscribed, meaning Goo= gle has had to rotate organisation membership" http://news.open-bio.org/news/2015/03/sadly-obf-not-accepted-for-gsoc-2015/ Very unfortunate as we've had interest in the MirageOS projects. I wondere= d about talking to relevant accepted orgs about adding some MirageOS projec= ts but haven't really had a chance to look into this. Best wishes, Amir On 4 Mar 2015, at 17:31, Lars Kurth wrote: > Hi folks, > = > just a quick note to let you know that we were not accepted for GSoC this= year. Do note that the Linux Foundation, OpenStack Foundation and many of = the other usual suspects have not been accepted this year. We will find out= more why on Friday. However, there are at least 4 Xen related projects tha= t are managed by other > = > I made a note at the top of http://wiki.xenproject.org/wiki/Archived/GSoC= _2015 to point applicants to some of those projects. I have found 5 so far = (which may bot be a complete list): > =95 Xen based Hypervisor in a Box @ Centos = > =95 Xen guest support for OpenBSD @ Open BSD Foundation = > =95 3 Xen related projects @ Ganeti > Other projects which were accepted are QEMU: note that there are no Xen r= elated projects, but given that Xen has good relationships with the QEMU co= mmunity we may be able to get one or two projects onto the list if someone = steps up and is willing to mentor > = > Best Regards > Lars > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Mar 04 17:40:42 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 04 Mar 2015 17:40:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTDHj-0004wS-PU; Wed, 04 Mar 2015 17:40:39 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTDHi-0004w5-Pl; Wed, 04 Mar 2015 17:40:38 +0000 Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id 9A/8A-03185-59347F45; Wed, 04 Mar 2015 17:40:37 +0000 X-Env-Sender: amc79@cam.ac.uk X-Msg-Ref: server-3.tower-31.messagelabs.com!1425490836!13161956!1 X-Originating-IP: [131.111.8.151] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MSA9PiAxNDE4OTU=\n X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30335 invoked from network); 4 Mar 2015 17:40:37 -0000 Received: from ppsw-51.csi.cam.ac.uk (HELO ppsw-51.csi.cam.ac.uk) (131.111.8.151) by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Mar 2015 17:40:37 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from host81-149-102-120.in-addr.btopenworld.com ([81.149.102.120]:62968 helo=[10.0.0.31]) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587) with esmtpsa (PLAIN:amc79) (TLSv1:AES128-SHA:128) id 1YTDHg-00036d-Wt (Exim 4.82_3-c0e5623) (return-path ); Wed, 04 Mar 2015 17:40:36 +0000 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Amir Chaudhry In-Reply-To: <44A7E990-9056-405D-B619-6695B2204E33@gmail.com> Date: Wed, 4 Mar 2015 17:40:31 +0000 Message-Id: References: <44A7E990-9056-405D-B619-6695B2204E33@gmail.com> To: Lars Kurth X-Mailer: Apple Mail (2.1510) Cc: xen-api@lists.xenproject.org, advisory-board@lists.xenproject.org, Russ Pavlicek , embedded-pv-devel@lists.xenproject.org, mirageos-devel , xen-devel Subject: Re: [MirageOS-devel] GSoC 2015 - Not accepted ... but some mentoring organisations which have several Xen related projects in them are X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org I noticed this the other day and had a quick scout around. "Mozilla not accepted for Google Summer of Code 2015" http://blog.queze.net/post/2015/03/03/Mozilla-not-accepted-for-Google-Summe= r-of-Code-2015 "Google=92s program is enormously popular, and over-subscribed, meaning Goo= gle has had to rotate organisation membership" http://news.open-bio.org/news/2015/03/sadly-obf-not-accepted-for-gsoc-2015/ Very unfortunate as we've had interest in the MirageOS projects. I wondere= d about talking to relevant accepted orgs about adding some MirageOS projec= ts but haven't really had a chance to look into this. Best wishes, Amir On 4 Mar 2015, at 17:31, Lars Kurth wrote: > Hi folks, > = > just a quick note to let you know that we were not accepted for GSoC this= year. Do note that the Linux Foundation, OpenStack Foundation and many of = the other usual suspects have not been accepted this year. We will find out= more why on Friday. However, there are at least 4 Xen related projects tha= t are managed by other > = > I made a note at the top of http://wiki.xenproject.org/wiki/Archived/GSoC= _2015 to point applicants to some of those projects. I have found 5 so far = (which may bot be a complete list): > =95 Xen based Hypervisor in a Box @ Centos = > =95 Xen guest support for OpenBSD @ Open BSD Foundation = > =95 3 Xen related projects @ Ganeti > Other projects which were accepted are QEMU: note that there are no Xen r= elated projects, but given that Xen has good relationships with the QEMU co= mmunity we may be able to get one or two projects onto the list if someone = steps up and is willing to mentor > = > Best Regards > Lars > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Mar 04 18:03:51 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 04 Mar 2015 18:03:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTDe9-0000ge-2s; Wed, 04 Mar 2015 18:03:49 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTDe8-0000gF-2K; Wed, 04 Mar 2015 18:03:48 +0000 Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id 36/05-31919-20947F45; Wed, 04 Mar 2015 18:03:46 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1425492226!14701372!1 X-Originating-IP: [209.85.212.179] X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26186 invoked from network); 4 Mar 2015 18:03:46 -0000 Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com) (209.85.212.179) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2015 18:03:46 -0000 Received: by wiwh11 with SMTP id h11so32857730wiw.3; Wed, 04 Mar 2015 10:03:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IEZd/R06ZDu9+aGfpFDFSp4wdUz0X9PtXEsPh6J4bCA=; b=YlrEz0JWcmXu5fs78lreDA7waEhBSdEcYMcha3RZGlFV+4+w/XLZdnqAKRuEiT/V4/ 4La8MeLZZ1ZPGeWVLyaGj5L2hirGuW0dLBWuzuSeKac5O5mdJClPksPWGLR58O7d/nTr QYR7vMi65Z4Vbn3ly7cTdyRzRgxrOnDQzfND5pqNcUCgJ8v680FtRTOt2u0y5PdhvSOP V15iJEuLCju83qT4Svt49C2h8/qzCKaDTCnP1xIVi47OH3B49uP5AiIliRkeznafyC0V AiITEUWMJYQ/7rngoJuzsuPFyICnW2OBGpT/zHvKjY9u74btoF6cKQ/+iNpW3cZ0RRLp zXBQ== X-Received: by 10.194.122.196 with SMTP id lu4mr10488430wjb.154.1425492225957; Wed, 04 Mar 2015 10:03:45 -0800 (PST) Received: from [192.168.0.8] (97e3cd44.skybroadband.com. [151.227.205.68]) by mx.google.com with ESMTPSA id lx10sm6984496wjb.17.2015.03.04.10.03.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Mar 2015 10:03:45 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Lars Kurth In-Reply-To: Date: Wed, 4 Mar 2015 18:03:43 +0000 Message-Id: <1D0B399F-4839-4B68-B8E6-F387D27F5C88@gmail.com> References: <44A7E990-9056-405D-B619-6695B2204E33@gmail.com> To: Amir Chaudhry X-Mailer: Apple Mail (2.2070.6) Cc: xen-api@lists.xenproject.org, advisory-board@lists.xenproject.org, Russ Pavlicek , embedded-pv-devel@lists.xenproject.org, mirageos-devel , xen-devel Subject: Re: [MirageOS-devel] GSoC 2015 - Not accepted ... but some mentoring organisations which have several Xen related projects in them are X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org > On 4 Mar 2015, at 17:40, Amir Chaudhry wrote: > = > I noticed this the other day and had a quick scout around. > = > "Mozilla not accepted for Google Summer of Code 2015" > http://blog.queze.net/post/2015/03/03/Mozilla-not-accepted-for-Google-Sum= mer-of-Code-2015 > = > "Google=92s program is enormously popular, and over-subscribed, meaning G= oogle has had to rotate organisation membership" > http://news.open-bio.org/news/2015/03/sadly-obf-not-accepted-for-gsoc-201= 5/ I am not particularly surprised. The number of projects is growing, so is c= ompetition. = > Very unfortunate as we've had interest in the MirageOS projects. I wonde= red about talking to relevant accepted orgs about adding some MirageOS proj= ects but haven't really had a chance to look into this. Please go ahead. Of course we will again participate in OPW. I am still one= Advisory Board vote short for approval. Regards Lars _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Mar 04 18:03:51 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 04 Mar 2015 18:03:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTDe9-0000ge-2s; Wed, 04 Mar 2015 18:03:49 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTDe8-0000gF-2K; Wed, 04 Mar 2015 18:03:48 +0000 Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id 36/05-31919-20947F45; Wed, 04 Mar 2015 18:03:46 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1425492226!14701372!1 X-Originating-IP: [209.85.212.179] X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26186 invoked from network); 4 Mar 2015 18:03:46 -0000 Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com) (209.85.212.179) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2015 18:03:46 -0000 Received: by wiwh11 with SMTP id h11so32857730wiw.3; Wed, 04 Mar 2015 10:03:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IEZd/R06ZDu9+aGfpFDFSp4wdUz0X9PtXEsPh6J4bCA=; b=YlrEz0JWcmXu5fs78lreDA7waEhBSdEcYMcha3RZGlFV+4+w/XLZdnqAKRuEiT/V4/ 4La8MeLZZ1ZPGeWVLyaGj5L2hirGuW0dLBWuzuSeKac5O5mdJClPksPWGLR58O7d/nTr QYR7vMi65Z4Vbn3ly7cTdyRzRgxrOnDQzfND5pqNcUCgJ8v680FtRTOt2u0y5PdhvSOP V15iJEuLCju83qT4Svt49C2h8/qzCKaDTCnP1xIVi47OH3B49uP5AiIliRkeznafyC0V AiITEUWMJYQ/7rngoJuzsuPFyICnW2OBGpT/zHvKjY9u74btoF6cKQ/+iNpW3cZ0RRLp zXBQ== X-Received: by 10.194.122.196 with SMTP id lu4mr10488430wjb.154.1425492225957; Wed, 04 Mar 2015 10:03:45 -0800 (PST) Received: from [192.168.0.8] (97e3cd44.skybroadband.com. [151.227.205.68]) by mx.google.com with ESMTPSA id lx10sm6984496wjb.17.2015.03.04.10.03.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Mar 2015 10:03:45 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Lars Kurth In-Reply-To: Date: Wed, 4 Mar 2015 18:03:43 +0000 Message-Id: <1D0B399F-4839-4B68-B8E6-F387D27F5C88@gmail.com> References: <44A7E990-9056-405D-B619-6695B2204E33@gmail.com> To: Amir Chaudhry X-Mailer: Apple Mail (2.2070.6) Cc: xen-api@lists.xenproject.org, advisory-board@lists.xenproject.org, Russ Pavlicek , embedded-pv-devel@lists.xenproject.org, mirageos-devel , xen-devel Subject: Re: [MirageOS-devel] GSoC 2015 - Not accepted ... but some mentoring organisations which have several Xen related projects in them are X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org > On 4 Mar 2015, at 17:40, Amir Chaudhry wrote: > = > I noticed this the other day and had a quick scout around. > = > "Mozilla not accepted for Google Summer of Code 2015" > http://blog.queze.net/post/2015/03/03/Mozilla-not-accepted-for-Google-Sum= mer-of-Code-2015 > = > "Google=92s program is enormously popular, and over-subscribed, meaning G= oogle has had to rotate organisation membership" > http://news.open-bio.org/news/2015/03/sadly-obf-not-accepted-for-gsoc-201= 5/ I am not particularly surprised. The number of projects is growing, so is c= ompetition. = > Very unfortunate as we've had interest in the MirageOS projects. I wonde= red about talking to relevant accepted orgs about adding some MirageOS proj= ects but haven't really had a chance to look into this. Please go ahead. Of course we will again participate in OPW. I am still one= Advisory Board vote short for approval. Regards Lars _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Mar 05 11:08:55 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 05 Mar 2015 11:08:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTTe5-00048v-VZ; Thu, 05 Mar 2015 11:08:49 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTTe3-00048q-QI for mirageos-devel@lists.xenproject.org; Thu, 05 Mar 2015 11:08:49 +0000 Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id 9A/EB-02745-F3938F45; Thu, 05 Mar 2015 11:08:47 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-11.tower-31.messagelabs.com!1425553722!13344122!1 X-Originating-IP: [209.85.215.41] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24569 invoked from network); 5 Mar 2015 11:08:42 -0000 Received: from mail-la0-f41.google.com (HELO mail-la0-f41.google.com) (209.85.215.41) by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2015 11:08:42 -0000 Received: by lams18 with SMTP id s18so50605719lam.11 for ; Thu, 05 Mar 2015 03:08:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LLjWQ3VY2LFE0gf3OerRTognMFray4oQFhC1ZrnNV7I=; b=Giv/GTvb/93uhkdBj+RXgvlD2rxzmcNQlHPgoTdGO/T5BHiCPKEULXt1vaeet8FaYp PZdAybudtpTMqH6aiE56O8O+MnnQZkYuogWHjtL+scd6WS3LjDDhHSTDIC8/E/yUf8uz TUl1N/puHy3uj6neSxQdwnYhjhwEYxvPPEG95yiamcW6jVwY9vosMmVv212ga/j44Cu+ yXi+3A7oBeyyklA9tDVX7iYr9I5M4w8JrIjlu8Lfo1x7drR86sjhmV14zCh4L6/HjLsU vENgbKnPOwaE2nYgAlzRxMR8ftvuu9oGOk+fjyD1NMDkDFoYZUmAOiiO1t1ajiEhpMLu jWGQ== MIME-Version: 1.0 X-Received: by 10.153.4.44 with SMTP id cb12mr7402510lad.26.1425553722037; Thu, 05 Mar 2015 03:08:42 -0800 (PST) Received: by 10.25.207.17 with HTTP; Thu, 5 Mar 2015 03:08:41 -0800 (PST) In-Reply-To: References: <8CEDB416-6238-4888-BA4B-B7305FDDE2D9@gazagnaire.org> <9349273A-0BB4-40C4-BF06-4307085AA90C@recoil.org> <47D39FA3-050E-46E6-89D2-4253484E24A8@gazagnaire.org> Date: Thu, 5 Mar 2015 11:08:41 +0000 Message-ID: From: Thomas Leonard To: Thomas Gazagnaire Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Irmin API newbie questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 4 March 2015 at 16:40, Thomas Gazagnaire wrote: >> I've now extended this to support events, so if the user has the page >> open in two tabs they stay in sync. However, there's still the problem >> that you can't remove a watch, so once you start watching you have to >> keep on doing so. Not a problem for my app (I just watch the master >> branch) but might be a problem in general. > > Currently, if you do not use an event stream anymore, the stream reader should be GCed automatically which will cause the stream writer (Irmin) to be clean-up on the next write. However I'm not totally sure the readers are properly GCed, so I need to check that before the release[1]. Did you notice some leaks there? But yes, you as don't control when the GC happen it might be better to leave the watch deallocation to the user. I need to think about that. > > [1] https://github.com/mirage/irmin/issues/124 Sorry, I meant in the back-end. I have: let watch_all t = ignore (Lazy.force (t.listener)); W.watch_all t.w https://github.com/talex5/cuekeeper/blob/354a71805c3fc701b511d0d753524ac49430320b/html_storage.ml#L194 Forcing t.listener does "Dom.addEventListener Dom_html.window Storage.event", which starts sending things to W.notify. However, I have no way to know when events aren't needed any more so I can disable the listener. It's lazy so that only stores that have been watched at some point create a listener (Irmin seems to create stores frequently - it looks like every branch creates a new instance of the back-end, which seems unnecessary). >> I've also now made my app do merges: every item displayed on the >> screen records the Irmin commit from which it came. Usually this is >> the latest version, but if you're e.g. editing a form then it's the >> version when you started the edit. When you submit a change, it >> commits against that revision and then merges the result back to >> master. This means that if you make two different edits to something >> in two tabs, the conflict will be detected instead of silently >> discarding the first change. (Ideally I want to resolve the conflicts, >> but for now it just discards the second change and reports the error >> to the user). >> >> I'm not sure I'm using the API correctly though. Here's my code for >> monitoring the master branch and updating the display when it changes: >> >> https://github.com/talex5/cuekeeper/blob/83a5e3c146f2406b8491b1c9915cb7fef6753869/ck_update.ml#L30 >> >> let make ~on_update branch = >> let watch_tags = I.watch_tags (branch "Watch master") in >> get_head_commit branch >>= fun initial_head -> >> let mutex = Lwt_mutex.create () in >> match I.branch (branch "Get branch name") with >> | `Head _ -> failwith "Not a tag!" >> | `Tag branch_name -> >> let t = { >> branch; >> head = initial_head; >> updated = Lwt_condition.create (); >> mutex; >> } in >> async (fun () -> >> on_update >>= fun on_update -> >> watch_tags |> Lwt_stream.iter_s (function >> | (n, Some _commit) when n = branch_name -> >> (* (ignore the commit ID in the update message; we want >> the latest) *) >> Lwt_mutex.with_lock t.mutex (fun () -> >> I.head (branch "Get latest commit") >>= function >> | None -> Ck_utils.error "Branch '%s' has disappeared!" >> branch_name >> | Some head -> >> if head <> t.head then ( >> t.head <- head; >> on_update head >>= fun () -> >> Lwt_condition.broadcast t.updated (); >> return () >> ) else ( >> return () >> ) >> ) >> | _ -> return () >> ) >> ); >> return t > > Hum, this clearly demonstrates that I need to improve the watch API ... I completely agree that getting the initial head is important: we need something similar to test_and_set at this level I think. I'm happy to move away from Lwt streams and use a more conventional callback API, where it's easier to control the scheduling (ie. hide the stream and expose only your "make" function directly in Irmin). I need to check with Dave what he needs exactly for Xenstore watches... > >> Some points you have to worry about here: >> >> - Irmin makes it easy to read data directly from a branch (tag), but >> this is usually unsafe, since a tag can update while you're reading >> it. Therefore, I think I always have to first get the head commit, >> then create a new store for that revision, then read from that. It >> might be safer if a branch just provided a way to get a commit, and >> reads had to be done from a fixed commit. > > Hum, reading a tag should not be unsafe as the RW backend should ensure that updates are atomic. See Get_unix.with_write_file[2] for example where we use the fact that "rename" is the only operation guaranteed to be atomic on POSIX filesystem. That's OK if you're only reading a single key, but usually you'll want a consistent set of values, all from the same commit. e.g. if I do I.read t "key1" >>= fun value1 -> I.read t "key2" >>= fun value2 -> then value1 and value2 will usually but not always be from the same commit, which is an easy mistake to make. This would be safer: Branch.head_commit t >>= fun c -> I.read c "key1" >>= fun value1 -> I.read c "key2" >>= fun value2 -> > Not sure which guarantee do you have for HTML5 local storage though ... I'm afraid you don't have many[3]. > [2] https://github.com/mirage/ocaml-git/blob/master/lib/unix/git_unix.ml#L300 > [3] http://balpha.de/2012/03/javascript-concurrency-and-locking-the-html5-localstorage/ I think that only matters when the read and write happen in different event loop turns. The spec says: http://www.w3.org/TR/webstorage/#threads "Because of the use of the storage mutex, multiple browsing contexts will be able to access the local storage areas simultaneously in such a manner that scripts cannot detect any concurrent script execution." So I think I can do an atomic test-and-set, but I can't hold a lock while waiting for an async event. I'd be happy to have something like: let rec merge master view = Branch.head master >>= fun old_head -> let merged = merge old_head view in Branch.update_tag master ~from:old_head merged >>= function | `Ok -> () | `Out_of_date -> merge master view >> - I only need to be notified once after a series of changes. I discard >> the commit in the watch notification and always read the latest. >> Otherwise, I might update the GUI to show stale data. Since a merge >> can add many commits at once, the stream API doesn't seem useful (it >> still doesn't ensure you see each commit individually, if that's what >> you wanted). > > In some cases this might be useful (if you store incremental updates that you want to replay) but I agree that this is not terribly useful in the main case. > >> - The functions that update the store shouldn't return until the >> update has been see by the model ("on_update" has been called). I >> therefore create a mutex and a Lwt_condition so that the commit >> functions can be sure their change has been seen. > > agreed and I think that's a good property to move into the watch API. I'm not sure this bit should be moved to the main library. In many cases you wouldn't care about waiting for the updates to be seen. But we could have a wrapper for the branch API that provides this (operations that set the branch pointer don't return until the notification callback has run, or isn't going to run if the head didn't move). >> All the code for changing the model goes via "merge_to_master". This >> takes a "base" argument (the commit which the user made the change >> from), creates a view (temporary branch), runs "fn" to make the >> requested change (which should always succeed), merges the temporary >> branch back to master, and waits for the on_update to notice it: >> >> let merge_to_master t ~base ~msg fn = >> let path = I.Key.empty in >> R.make_view base >>= fun view -> >> fn view >>= fun result -> >> Lwt_mutex.with_lock t.mutex (fun () -> >> (* At this point, head cannot contain our commit because we >> haven't made it yet, >> * and no updates can happen while we hold the lock. *) >> let old_head = t.head in >> let updated = Lwt_condition.wait t.updated in >> R.V.merge_path (t.branch msg) path view >>= function >> | `Conflict msg -> Ck_utils.error "Conflict during merge: %s >> (discarding change)" msg >> | `Ok () -> >> I.head (t.branch "Get latest commit") >|= function >> | Some new_head when new_head <> old_head -> >> (* [updated] cannot have fired yet because we still hold the >> lock. When it does >> * fire next, it must contain our update. It must fire soon, >> as head has changed. *) >> updated >> | _ -> >> (* Our change had no effect, so don't wait for head to move. >> * Or, the branch was deleted - no point waiting then either. *) >> return () >> ) >>= fun updated -> (* Changes have been committed. *) >> updated >>= fun () -> (* [on_update] has been called. *) >> return result >> >> Does this approach seem sensible? I feel like the API perhaps wasn't >> intended to be used this way... > > I can see why you are doing all of this, and this is certainly not optimal for an API point of view. One think I can do to help is to add an invariant to all the high-level updates (such as merge) functions to only perform the whole update only if the head didn't change since the beginning of the operations. It's an easy check to add and it will help a lot to reason on what happens during concurrent updates. The only reason I didn't do it before is that I was worried about starvation issues and other concurrency scheduling related issues - but I guess they are better than data loss ... and we could just picky bag on Lwt_mutex / Lwt_condition properties. > > [4] https://github.com/mirage/irmin/issues/157 > >> I'm still worried about losing data due to races. JavaScript (I think) >> ensures that access to local storage from different threads doesn't >> get interleaved, but since Irmin uses Lwt we don't benefit from this. >> I suspect that if two tabs try to merge at once then one's commit will >> be silently discarded. Probably the back-end update function should >> take the expected old value as an argument so it can abort if the >> state has changed since then. > > Not sure to understand what Lwt exactly changes there. I'm happy to modify the signature of the backends to add more checks, but modifying the "RW.update" signature to take an optional current value to test would mean modifying the "Irmin.update" signature as well. Not sure that's exactly what we want. Could add a new "RW.test_and_set" function though.[4] I'll think about it. That would be good. > [5] https://github.com/mirage/irmin/issues/155 > >> It would also be useful to get the commit object from the merge before >> updating the branch. That way, I could try loading it as a sanity >> check (and thus reject any update that would result in an unreadable >> state). I guess I need to create another temporary branch, merge to >> that, then force-update master to it. Seems like a lot of work, >> though. > > I think it's easy to add a "try_merge" function which do not update the head. The current way to do that is indeed to create a temporary branch. > > [6] https://github.com/mirage/irmin/issues/156 > >> Anyway, despite these minor issues, Irmin is working great so far! > > As usual, thanks for the very useful feedback! That'll definitely help improving the watch API and the overhaul usability. Thanks! -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Mar 05 11:08:55 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 05 Mar 2015 11:08:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTTe5-00048v-VZ; Thu, 05 Mar 2015 11:08:49 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTTe3-00048q-QI for mirageos-devel@lists.xenproject.org; Thu, 05 Mar 2015 11:08:49 +0000 Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id 9A/EB-02745-F3938F45; Thu, 05 Mar 2015 11:08:47 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-11.tower-31.messagelabs.com!1425553722!13344122!1 X-Originating-IP: [209.85.215.41] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24569 invoked from network); 5 Mar 2015 11:08:42 -0000 Received: from mail-la0-f41.google.com (HELO mail-la0-f41.google.com) (209.85.215.41) by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2015 11:08:42 -0000 Received: by lams18 with SMTP id s18so50605719lam.11 for ; Thu, 05 Mar 2015 03:08:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LLjWQ3VY2LFE0gf3OerRTognMFray4oQFhC1ZrnNV7I=; b=Giv/GTvb/93uhkdBj+RXgvlD2rxzmcNQlHPgoTdGO/T5BHiCPKEULXt1vaeet8FaYp PZdAybudtpTMqH6aiE56O8O+MnnQZkYuogWHjtL+scd6WS3LjDDhHSTDIC8/E/yUf8uz TUl1N/puHy3uj6neSxQdwnYhjhwEYxvPPEG95yiamcW6jVwY9vosMmVv212ga/j44Cu+ yXi+3A7oBeyyklA9tDVX7iYr9I5M4w8JrIjlu8Lfo1x7drR86sjhmV14zCh4L6/HjLsU vENgbKnPOwaE2nYgAlzRxMR8ftvuu9oGOk+fjyD1NMDkDFoYZUmAOiiO1t1ajiEhpMLu jWGQ== MIME-Version: 1.0 X-Received: by 10.153.4.44 with SMTP id cb12mr7402510lad.26.1425553722037; Thu, 05 Mar 2015 03:08:42 -0800 (PST) Received: by 10.25.207.17 with HTTP; Thu, 5 Mar 2015 03:08:41 -0800 (PST) In-Reply-To: References: <8CEDB416-6238-4888-BA4B-B7305FDDE2D9@gazagnaire.org> <9349273A-0BB4-40C4-BF06-4307085AA90C@recoil.org> <47D39FA3-050E-46E6-89D2-4253484E24A8@gazagnaire.org> Date: Thu, 5 Mar 2015 11:08:41 +0000 Message-ID: From: Thomas Leonard To: Thomas Gazagnaire Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Irmin API newbie questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 4 March 2015 at 16:40, Thomas Gazagnaire wrote: >> I've now extended this to support events, so if the user has the page >> open in two tabs they stay in sync. However, there's still the problem >> that you can't remove a watch, so once you start watching you have to >> keep on doing so. Not a problem for my app (I just watch the master >> branch) but might be a problem in general. > > Currently, if you do not use an event stream anymore, the stream reader should be GCed automatically which will cause the stream writer (Irmin) to be clean-up on the next write. However I'm not totally sure the readers are properly GCed, so I need to check that before the release[1]. Did you notice some leaks there? But yes, you as don't control when the GC happen it might be better to leave the watch deallocation to the user. I need to think about that. > > [1] https://github.com/mirage/irmin/issues/124 Sorry, I meant in the back-end. I have: let watch_all t = ignore (Lazy.force (t.listener)); W.watch_all t.w https://github.com/talex5/cuekeeper/blob/354a71805c3fc701b511d0d753524ac49430320b/html_storage.ml#L194 Forcing t.listener does "Dom.addEventListener Dom_html.window Storage.event", which starts sending things to W.notify. However, I have no way to know when events aren't needed any more so I can disable the listener. It's lazy so that only stores that have been watched at some point create a listener (Irmin seems to create stores frequently - it looks like every branch creates a new instance of the back-end, which seems unnecessary). >> I've also now made my app do merges: every item displayed on the >> screen records the Irmin commit from which it came. Usually this is >> the latest version, but if you're e.g. editing a form then it's the >> version when you started the edit. When you submit a change, it >> commits against that revision and then merges the result back to >> master. This means that if you make two different edits to something >> in two tabs, the conflict will be detected instead of silently >> discarding the first change. (Ideally I want to resolve the conflicts, >> but for now it just discards the second change and reports the error >> to the user). >> >> I'm not sure I'm using the API correctly though. Here's my code for >> monitoring the master branch and updating the display when it changes: >> >> https://github.com/talex5/cuekeeper/blob/83a5e3c146f2406b8491b1c9915cb7fef6753869/ck_update.ml#L30 >> >> let make ~on_update branch = >> let watch_tags = I.watch_tags (branch "Watch master") in >> get_head_commit branch >>= fun initial_head -> >> let mutex = Lwt_mutex.create () in >> match I.branch (branch "Get branch name") with >> | `Head _ -> failwith "Not a tag!" >> | `Tag branch_name -> >> let t = { >> branch; >> head = initial_head; >> updated = Lwt_condition.create (); >> mutex; >> } in >> async (fun () -> >> on_update >>= fun on_update -> >> watch_tags |> Lwt_stream.iter_s (function >> | (n, Some _commit) when n = branch_name -> >> (* (ignore the commit ID in the update message; we want >> the latest) *) >> Lwt_mutex.with_lock t.mutex (fun () -> >> I.head (branch "Get latest commit") >>= function >> | None -> Ck_utils.error "Branch '%s' has disappeared!" >> branch_name >> | Some head -> >> if head <> t.head then ( >> t.head <- head; >> on_update head >>= fun () -> >> Lwt_condition.broadcast t.updated (); >> return () >> ) else ( >> return () >> ) >> ) >> | _ -> return () >> ) >> ); >> return t > > Hum, this clearly demonstrates that I need to improve the watch API ... I completely agree that getting the initial head is important: we need something similar to test_and_set at this level I think. I'm happy to move away from Lwt streams and use a more conventional callback API, where it's easier to control the scheduling (ie. hide the stream and expose only your "make" function directly in Irmin). I need to check with Dave what he needs exactly for Xenstore watches... > >> Some points you have to worry about here: >> >> - Irmin makes it easy to read data directly from a branch (tag), but >> this is usually unsafe, since a tag can update while you're reading >> it. Therefore, I think I always have to first get the head commit, >> then create a new store for that revision, then read from that. It >> might be safer if a branch just provided a way to get a commit, and >> reads had to be done from a fixed commit. > > Hum, reading a tag should not be unsafe as the RW backend should ensure that updates are atomic. See Get_unix.with_write_file[2] for example where we use the fact that "rename" is the only operation guaranteed to be atomic on POSIX filesystem. That's OK if you're only reading a single key, but usually you'll want a consistent set of values, all from the same commit. e.g. if I do I.read t "key1" >>= fun value1 -> I.read t "key2" >>= fun value2 -> then value1 and value2 will usually but not always be from the same commit, which is an easy mistake to make. This would be safer: Branch.head_commit t >>= fun c -> I.read c "key1" >>= fun value1 -> I.read c "key2" >>= fun value2 -> > Not sure which guarantee do you have for HTML5 local storage though ... I'm afraid you don't have many[3]. > [2] https://github.com/mirage/ocaml-git/blob/master/lib/unix/git_unix.ml#L300 > [3] http://balpha.de/2012/03/javascript-concurrency-and-locking-the-html5-localstorage/ I think that only matters when the read and write happen in different event loop turns. The spec says: http://www.w3.org/TR/webstorage/#threads "Because of the use of the storage mutex, multiple browsing contexts will be able to access the local storage areas simultaneously in such a manner that scripts cannot detect any concurrent script execution." So I think I can do an atomic test-and-set, but I can't hold a lock while waiting for an async event. I'd be happy to have something like: let rec merge master view = Branch.head master >>= fun old_head -> let merged = merge old_head view in Branch.update_tag master ~from:old_head merged >>= function | `Ok -> () | `Out_of_date -> merge master view >> - I only need to be notified once after a series of changes. I discard >> the commit in the watch notification and always read the latest. >> Otherwise, I might update the GUI to show stale data. Since a merge >> can add many commits at once, the stream API doesn't seem useful (it >> still doesn't ensure you see each commit individually, if that's what >> you wanted). > > In some cases this might be useful (if you store incremental updates that you want to replay) but I agree that this is not terribly useful in the main case. > >> - The functions that update the store shouldn't return until the >> update has been see by the model ("on_update" has been called). I >> therefore create a mutex and a Lwt_condition so that the commit >> functions can be sure their change has been seen. > > agreed and I think that's a good property to move into the watch API. I'm not sure this bit should be moved to the main library. In many cases you wouldn't care about waiting for the updates to be seen. But we could have a wrapper for the branch API that provides this (operations that set the branch pointer don't return until the notification callback has run, or isn't going to run if the head didn't move). >> All the code for changing the model goes via "merge_to_master". This >> takes a "base" argument (the commit which the user made the change >> from), creates a view (temporary branch), runs "fn" to make the >> requested change (which should always succeed), merges the temporary >> branch back to master, and waits for the on_update to notice it: >> >> let merge_to_master t ~base ~msg fn = >> let path = I.Key.empty in >> R.make_view base >>= fun view -> >> fn view >>= fun result -> >> Lwt_mutex.with_lock t.mutex (fun () -> >> (* At this point, head cannot contain our commit because we >> haven't made it yet, >> * and no updates can happen while we hold the lock. *) >> let old_head = t.head in >> let updated = Lwt_condition.wait t.updated in >> R.V.merge_path (t.branch msg) path view >>= function >> | `Conflict msg -> Ck_utils.error "Conflict during merge: %s >> (discarding change)" msg >> | `Ok () -> >> I.head (t.branch "Get latest commit") >|= function >> | Some new_head when new_head <> old_head -> >> (* [updated] cannot have fired yet because we still hold the >> lock. When it does >> * fire next, it must contain our update. It must fire soon, >> as head has changed. *) >> updated >> | _ -> >> (* Our change had no effect, so don't wait for head to move. >> * Or, the branch was deleted - no point waiting then either. *) >> return () >> ) >>= fun updated -> (* Changes have been committed. *) >> updated >>= fun () -> (* [on_update] has been called. *) >> return result >> >> Does this approach seem sensible? I feel like the API perhaps wasn't >> intended to be used this way... > > I can see why you are doing all of this, and this is certainly not optimal for an API point of view. One think I can do to help is to add an invariant to all the high-level updates (such as merge) functions to only perform the whole update only if the head didn't change since the beginning of the operations. It's an easy check to add and it will help a lot to reason on what happens during concurrent updates. The only reason I didn't do it before is that I was worried about starvation issues and other concurrency scheduling related issues - but I guess they are better than data loss ... and we could just picky bag on Lwt_mutex / Lwt_condition properties. > > [4] https://github.com/mirage/irmin/issues/157 > >> I'm still worried about losing data due to races. JavaScript (I think) >> ensures that access to local storage from different threads doesn't >> get interleaved, but since Irmin uses Lwt we don't benefit from this. >> I suspect that if two tabs try to merge at once then one's commit will >> be silently discarded. Probably the back-end update function should >> take the expected old value as an argument so it can abort if the >> state has changed since then. > > Not sure to understand what Lwt exactly changes there. I'm happy to modify the signature of the backends to add more checks, but modifying the "RW.update" signature to take an optional current value to test would mean modifying the "Irmin.update" signature as well. Not sure that's exactly what we want. Could add a new "RW.test_and_set" function though.[4] I'll think about it. That would be good. > [5] https://github.com/mirage/irmin/issues/155 > >> It would also be useful to get the commit object from the merge before >> updating the branch. That way, I could try loading it as a sanity >> check (and thus reject any update that would result in an unreadable >> state). I guess I need to create another temporary branch, merge to >> that, then force-update master to it. Seems like a lot of work, >> though. > > I think it's easy to add a "try_merge" function which do not update the head. The current way to do that is indeed to create a temporary branch. > > [6] https://github.com/mirage/irmin/issues/156 > >> Anyway, despite these minor issues, Irmin is working great so far! > > As usual, thanks for the very useful feedback! That'll definitely help improving the watch API and the overhaul usability. Thanks! -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Mar 05 11:56:22 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 05 Mar 2015 11:56:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTUO5-0004f7-EZ; Thu, 05 Mar 2015 11:56:21 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTUO4-0004ev-I2 for mirageos-devel@lists.xenproject.org; Thu, 05 Mar 2015 11:56:20 +0000 Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id 8F/AE-02770-36448F45; Thu, 05 Mar 2015 11:56:19 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1425556578!14916079!1 X-Originating-IP: [209.85.212.170] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14900 invoked from network); 5 Mar 2015 11:56:18 -0000 Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com) (209.85.212.170) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2015 11:56:18 -0000 Received: by widem10 with SMTP id em10so37764645wid.5 for ; Thu, 05 Mar 2015 03:56:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=toI1izTGjBhMHRsGtsXWn1J3jeIDXDYmc5aMrNTsTgk=; b=FD9YXDdIarONdcL59isrrEUKc1b1QzSxOMb7B0lSIExi7h8m42NFkqjq+uQPRaNWsN mhzETyk5U7cyaSNCjK2yUX4C51pq8CIbiWR6a3q8DS9prru7IogOkpngRAJ1IwBMv+Ca OVdAjafcGsCOOP285l3Rwv454RLxItMd0w6t5Nsmj1eqvlpyfB7MNjeP/TF12r4u0Ncw 3oAhuvGSJaV4nWjrhDHVJmeV120llFoejsVPO3XhAqEOyMNAJBdgt0MhKg0hofjAiS/L YOM8qLT1lVo5B2e3RWyNDNrxPJSeyURJAbQMXZSUMsqZV6wVfnHsDktdOQ81JkHI2478 SWmA== X-Received: by 10.180.189.35 with SMTP id gf3mr21729430wic.5.1425556578594; Thu, 05 Mar 2015 03:56:18 -0800 (PST) Received: from piana.mac.cl.cam.ac.uk (piana.mac.cl.cam.ac.uk. [128.232.56.38]) by mx.google.com with ESMTPSA id nb18sm11335819wic.3.2015.03.05.03.56.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 03:56:17 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Thomas Gazagnaire In-Reply-To: Date: Thu, 5 Mar 2015 11:56:18 +0000 Message-Id: References: <8CEDB416-6238-4888-BA4B-B7305FDDE2D9@gazagnaire.org> <9349273A-0BB4-40C4-BF06-4307085AA90C@recoil.org> <47D39FA3-050E-46E6-89D2-4253484E24A8@gazagnaire.org> To: Thomas Leonard X-Mailer: Apple Mail (2.2070.6) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Irmin API newbie questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org >>> - Irmin makes it easy to read data directly from a branch (tag), but >>> this is usually unsafe, since a tag can update while you're reading >>> it. Therefore, I think I always have to first get the head commit, >>> then create a new store for that revision, then read from that. It >>> might be safer if a branch just provided a way to get a commit, and >>> reads had to be done from a fixed commit. >> >> Hum, reading a tag should not be unsafe as the RW backend should ensure that updates are atomic. See Get_unix.with_write_file[2] for example where we use the fact that "rename" is the only operation guaranteed to be atomic on POSIX filesystem. > > That's OK if you're only reading a single key, but usually you'll want > a consistent set of values, all from the same commit. e.g. if I do > > I.read t "key1" >>= fun value1 -> > I.read t "key2" >>= fun value2 -> > > then value1 and value2 will usually but not always be from the same > commit, which is an easy mistake to make. This would be safer: > > Branch.head_commit t >>= fun c -> > I.read c "key1" >>= fun value1 -> > I.read c "key2" >>= fun value2 -> Ha I see, that you want is a transactional sequence of operations. In that case you might want to use views [1]. All the read/write done on that view are guaranteed to be isolated. I still need to ensure that merging back in the store is really atomic (same issue as with all the other high-level operations). Thomas [1] http://mirage.github.io/irmin/Irmin.html#VALwith_hrw_view _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Mar 05 11:56:22 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 05 Mar 2015 11:56:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTUO5-0004f7-EZ; Thu, 05 Mar 2015 11:56:21 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTUO4-0004ev-I2 for mirageos-devel@lists.xenproject.org; Thu, 05 Mar 2015 11:56:20 +0000 Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id 8F/AE-02770-36448F45; Thu, 05 Mar 2015 11:56:19 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1425556578!14916079!1 X-Originating-IP: [209.85.212.170] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14900 invoked from network); 5 Mar 2015 11:56:18 -0000 Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com) (209.85.212.170) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2015 11:56:18 -0000 Received: by widem10 with SMTP id em10so37764645wid.5 for ; Thu, 05 Mar 2015 03:56:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=toI1izTGjBhMHRsGtsXWn1J3jeIDXDYmc5aMrNTsTgk=; b=FD9YXDdIarONdcL59isrrEUKc1b1QzSxOMb7B0lSIExi7h8m42NFkqjq+uQPRaNWsN mhzETyk5U7cyaSNCjK2yUX4C51pq8CIbiWR6a3q8DS9prru7IogOkpngRAJ1IwBMv+Ca OVdAjafcGsCOOP285l3Rwv454RLxItMd0w6t5Nsmj1eqvlpyfB7MNjeP/TF12r4u0Ncw 3oAhuvGSJaV4nWjrhDHVJmeV120llFoejsVPO3XhAqEOyMNAJBdgt0MhKg0hofjAiS/L YOM8qLT1lVo5B2e3RWyNDNrxPJSeyURJAbQMXZSUMsqZV6wVfnHsDktdOQ81JkHI2478 SWmA== X-Received: by 10.180.189.35 with SMTP id gf3mr21729430wic.5.1425556578594; Thu, 05 Mar 2015 03:56:18 -0800 (PST) Received: from piana.mac.cl.cam.ac.uk (piana.mac.cl.cam.ac.uk. [128.232.56.38]) by mx.google.com with ESMTPSA id nb18sm11335819wic.3.2015.03.05.03.56.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 03:56:17 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Thomas Gazagnaire In-Reply-To: Date: Thu, 5 Mar 2015 11:56:18 +0000 Message-Id: References: <8CEDB416-6238-4888-BA4B-B7305FDDE2D9@gazagnaire.org> <9349273A-0BB4-40C4-BF06-4307085AA90C@recoil.org> <47D39FA3-050E-46E6-89D2-4253484E24A8@gazagnaire.org> To: Thomas Leonard X-Mailer: Apple Mail (2.2070.6) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Irmin API newbie questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org >>> - Irmin makes it easy to read data directly from a branch (tag), but >>> this is usually unsafe, since a tag can update while you're reading >>> it. Therefore, I think I always have to first get the head commit, >>> then create a new store for that revision, then read from that. It >>> might be safer if a branch just provided a way to get a commit, and >>> reads had to be done from a fixed commit. >> >> Hum, reading a tag should not be unsafe as the RW backend should ensure that updates are atomic. See Get_unix.with_write_file[2] for example where we use the fact that "rename" is the only operation guaranteed to be atomic on POSIX filesystem. > > That's OK if you're only reading a single key, but usually you'll want > a consistent set of values, all from the same commit. e.g. if I do > > I.read t "key1" >>= fun value1 -> > I.read t "key2" >>= fun value2 -> > > then value1 and value2 will usually but not always be from the same > commit, which is an easy mistake to make. This would be safer: > > Branch.head_commit t >>= fun c -> > I.read c "key1" >>= fun value1 -> > I.read c "key2" >>= fun value2 -> Ha I see, that you want is a transactional sequence of operations. In that case you might want to use views [1]. All the read/write done on that view are guaranteed to be isolated. I still need to ensure that merging back in the store is really atomic (same issue as with all the other high-level operations). Thomas [1] http://mirage.github.io/irmin/Irmin.html#VALwith_hrw_view _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Mar 05 12:13:06 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 05 Mar 2015 12:13:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTUeF-0008Lf-PN; Thu, 05 Mar 2015 12:13:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTUeE-0008La-Cv for mirageos-devel@lists.xenproject.org; Thu, 05 Mar 2015 12:13:02 +0000 Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id CF/E5-03132-D4848F45; Thu, 05 Mar 2015 12:13:01 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1425557580!13226711!1 X-Originating-IP: [209.85.215.54] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25351 invoked from network); 5 Mar 2015 12:13:00 -0000 Received: from mail-la0-f54.google.com (HELO mail-la0-f54.google.com) (209.85.215.54) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2015 12:13:00 -0000 Received: by labge10 with SMTP id ge10so50902649lab.12 for ; Thu, 05 Mar 2015 04:12:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JSpM9WYW2j3isLqrmURk2tnuS8V/OQSAMMF8KbiBJqM=; b=QGa0cQAlbAh6CWZEgYG/4oT6Fn0mRmVxmy7nsGHLXR+ivGMmFylV2r7kldksvMLAQR tGFvy6R2+icM35y3v4tDZX2jBdI7+T7c59/lIf/ElEoqGSKrGFyMqiuePVy7kiSjy2zI +UiVDe5BVJAZ9Tz8OvqpiD9K6ZjlnVN9IT2E0/mU30DPqLZlV1AoQRoyVGSBbVqinb9Z h9By6PvmjN9CV+kX3cJnLMFiR0eux1Bhlhe2J1rR/JAOlBvY84ObZVGxodWDS8lwQFTu Vt3Y8tkbwR+w47WgHhV2lq1uuyNe1wBmkJ16n522pbalrNElVuZNgdM+lho2HJzrnuDb tNww== MIME-Version: 1.0 X-Received: by 10.112.72.35 with SMTP id a3mr7747816lbv.20.1425557579700; Thu, 05 Mar 2015 04:12:59 -0800 (PST) Received: by 10.25.207.17 with HTTP; Thu, 5 Mar 2015 04:12:59 -0800 (PST) In-Reply-To: References: <8CEDB416-6238-4888-BA4B-B7305FDDE2D9@gazagnaire.org> <9349273A-0BB4-40C4-BF06-4307085AA90C@recoil.org> <47D39FA3-050E-46E6-89D2-4253484E24A8@gazagnaire.org> Date: Thu, 5 Mar 2015 12:12:59 +0000 Message-ID: From: Thomas Leonard To: Thomas Gazagnaire Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Irmin API newbie questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 5 March 2015 at 11:56, Thomas Gazagnaire wrote: >>>> - Irmin makes it easy to read data directly from a branch (tag), but >>>> this is usually unsafe, since a tag can update while you're reading >>>> it. Therefore, I think I always have to first get the head commit, >>>> then create a new store for that revision, then read from that. It >>>> might be safer if a branch just provided a way to get a commit, and >>>> reads had to be done from a fixed commit. >>> >>> Hum, reading a tag should not be unsafe as the RW backend should ensure that updates are atomic. See Get_unix.with_write_file[2] for example where we use the fact that "rename" is the only operation guaranteed to be atomic on POSIX filesystem. >> >> That's OK if you're only reading a single key, but usually you'll want >> a consistent set of values, all from the same commit. e.g. if I do >> >> I.read t "key1" >>= fun value1 -> >> I.read t "key2" >>= fun value2 -> >> >> then value1 and value2 will usually but not always be from the same >> commit, which is an easy mistake to make. This would be safer: >> >> Branch.head_commit t >>= fun c -> >> I.read c "key1" >>= fun value1 -> >> I.read c "key2" >>= fun value2 -> > > Ha I see, that you want is a transactional sequence of operations. In that case you might want to use views [1]. All the read/write done on that view are guaranteed to be isolated. Currently, my main code reads a single revision like this: I.of_head repo task_maker head >>= R.make And R.make does: let make store = match I.branch (store "Get commit ID") with | `Tag _ -> failwith "Error: store is not fixed (use of_head)!" | `Head commit -> Should I make a view here instead? It looks like View.of_path does a load of copying. What I want is something that I can be sure will never change. Neither views nor stores can ensure this I think (both can be written to). Possibly I should do the "I.of_head" inside R.make, but then I'd have to give it the repo (config) and task_maker objects too, which is also ugly. It seems strange, since the underlying Git model already provides immutable data structures (blobs, trees, commits), but Irmin seems to force me to treat everything as mutable. > I still need to ensure that merging back in the store is really atomic (same issue as with all the other high-level operations). BTW, I read more of the storage spec and found: "The use of the storage mutex to avoid race conditions is currently considered by certain implementors to be too high a performance burden, to the point where allowing data corruption is considered preferable." So some locking will be needed anyway. It would be good to implement this only in the backend though, and have the rest of Irmin automatically be safe. > Thomas > > [1] http://mirage.github.io/irmin/Irmin.html#VALwith_hrw_view -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Mar 05 12:13:06 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 05 Mar 2015 12:13:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTUeF-0008Lf-PN; Thu, 05 Mar 2015 12:13:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTUeE-0008La-Cv for mirageos-devel@lists.xenproject.org; Thu, 05 Mar 2015 12:13:02 +0000 Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id CF/E5-03132-D4848F45; Thu, 05 Mar 2015 12:13:01 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1425557580!13226711!1 X-Originating-IP: [209.85.215.54] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25351 invoked from network); 5 Mar 2015 12:13:00 -0000 Received: from mail-la0-f54.google.com (HELO mail-la0-f54.google.com) (209.85.215.54) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2015 12:13:00 -0000 Received: by labge10 with SMTP id ge10so50902649lab.12 for ; Thu, 05 Mar 2015 04:12:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JSpM9WYW2j3isLqrmURk2tnuS8V/OQSAMMF8KbiBJqM=; b=QGa0cQAlbAh6CWZEgYG/4oT6Fn0mRmVxmy7nsGHLXR+ivGMmFylV2r7kldksvMLAQR tGFvy6R2+icM35y3v4tDZX2jBdI7+T7c59/lIf/ElEoqGSKrGFyMqiuePVy7kiSjy2zI +UiVDe5BVJAZ9Tz8OvqpiD9K6ZjlnVN9IT2E0/mU30DPqLZlV1AoQRoyVGSBbVqinb9Z h9By6PvmjN9CV+kX3cJnLMFiR0eux1Bhlhe2J1rR/JAOlBvY84ObZVGxodWDS8lwQFTu Vt3Y8tkbwR+w47WgHhV2lq1uuyNe1wBmkJ16n522pbalrNElVuZNgdM+lho2HJzrnuDb tNww== MIME-Version: 1.0 X-Received: by 10.112.72.35 with SMTP id a3mr7747816lbv.20.1425557579700; Thu, 05 Mar 2015 04:12:59 -0800 (PST) Received: by 10.25.207.17 with HTTP; Thu, 5 Mar 2015 04:12:59 -0800 (PST) In-Reply-To: References: <8CEDB416-6238-4888-BA4B-B7305FDDE2D9@gazagnaire.org> <9349273A-0BB4-40C4-BF06-4307085AA90C@recoil.org> <47D39FA3-050E-46E6-89D2-4253484E24A8@gazagnaire.org> Date: Thu, 5 Mar 2015 12:12:59 +0000 Message-ID: From: Thomas Leonard To: Thomas Gazagnaire Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Irmin API newbie questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 5 March 2015 at 11:56, Thomas Gazagnaire wrote: >>>> - Irmin makes it easy to read data directly from a branch (tag), but >>>> this is usually unsafe, since a tag can update while you're reading >>>> it. Therefore, I think I always have to first get the head commit, >>>> then create a new store for that revision, then read from that. It >>>> might be safer if a branch just provided a way to get a commit, and >>>> reads had to be done from a fixed commit. >>> >>> Hum, reading a tag should not be unsafe as the RW backend should ensure that updates are atomic. See Get_unix.with_write_file[2] for example where we use the fact that "rename" is the only operation guaranteed to be atomic on POSIX filesystem. >> >> That's OK if you're only reading a single key, but usually you'll want >> a consistent set of values, all from the same commit. e.g. if I do >> >> I.read t "key1" >>= fun value1 -> >> I.read t "key2" >>= fun value2 -> >> >> then value1 and value2 will usually but not always be from the same >> commit, which is an easy mistake to make. This would be safer: >> >> Branch.head_commit t >>= fun c -> >> I.read c "key1" >>= fun value1 -> >> I.read c "key2" >>= fun value2 -> > > Ha I see, that you want is a transactional sequence of operations. In that case you might want to use views [1]. All the read/write done on that view are guaranteed to be isolated. Currently, my main code reads a single revision like this: I.of_head repo task_maker head >>= R.make And R.make does: let make store = match I.branch (store "Get commit ID") with | `Tag _ -> failwith "Error: store is not fixed (use of_head)!" | `Head commit -> Should I make a view here instead? It looks like View.of_path does a load of copying. What I want is something that I can be sure will never change. Neither views nor stores can ensure this I think (both can be written to). Possibly I should do the "I.of_head" inside R.make, but then I'd have to give it the repo (config) and task_maker objects too, which is also ugly. It seems strange, since the underlying Git model already provides immutable data structures (blobs, trees, commits), but Irmin seems to force me to treat everything as mutable. > I still need to ensure that merging back in the store is really atomic (same issue as with all the other high-level operations). BTW, I read more of the storage spec and found: "The use of the storage mutex to avoid race conditions is currently considered by certain implementors to be too high a performance burden, to the point where allowing data corruption is considered preferable." So some locking will be needed anyway. It would be good to implement this only in the backend though, and have the rest of Irmin automatically be safe. > Thomas > > [1] http://mirage.github.io/irmin/Irmin.html#VALwith_hrw_view -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Mar 05 14:15:48 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 05 Mar 2015 14:15:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTWYw-00054X-B9; Thu, 05 Mar 2015 14:15:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTWYv-00054S-Rg for mirageos-devel@lists.xenproject.org; Thu, 05 Mar 2015 14:15:41 +0000 Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id 99/8B-25903-D0568F45; Thu, 05 Mar 2015 14:15:41 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1425564940!13269914!1 X-Originating-IP: [74.125.82.43] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17777 invoked from network); 5 Mar 2015 14:15:40 -0000 Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com) (74.125.82.43) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2015 14:15:40 -0000 Received: by wghk14 with SMTP id k14so9862370wgh.7 for ; Thu, 05 Mar 2015 06:15:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j1GbbKqTOqXWoyf1N8iS/3gu1D6Oas0Z58+IWEG4wl8=; b=ym6rgV5mJkdU/faNlcQMw8qeiTeiOO9Q8d36O1hZVA8QL/9WAi7gR5JdKbDbyKNeg6 N/4gdDJ0RODCELT3WchdMJzlk1G3/JDhpGKy0gM/DPMU4Rc0tRVaaKUR2VS2hiId5uVM dLeMlmuviSbr3ZZxaQFenvSfCOwRZVjr8OSFTskoQmu5j8bs7dh9aJQb45AZz2pDogbs FbbFLDFuc76gx/gTo1OcvwWJhA48OnlquTmjXGO0IJhh0KNgBH6t8nsbP62bvghsKqJF SbWCTUEl0y45ANFAdHRwgh99KoOfr5OEnESYxyegt1rBTiGyu0Y3qUZWS4RN1OecqjXO Q9dg== X-Received: by 10.194.172.9 with SMTP id ay9mr19139309wjc.2.1425564939684; Thu, 05 Mar 2015 06:15:39 -0800 (PST) Received: from ?IPv6:2001:630:212:248:204c:a7cd:6ac4:c570? ([2001:630:212:248:204c:a7cd:6ac4:c570]) by mx.google.com with ESMTPSA id ub1sm10696910wjc.43.2015.03.05.06.15.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 06:15:38 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Thomas Gazagnaire In-Reply-To: Date: Thu, 5 Mar 2015 14:15:36 +0000 Message-Id: References: <8CEDB416-6238-4888-BA4B-B7305FDDE2D9@gazagnaire.org> <9349273A-0BB4-40C4-BF06-4307085AA90C@recoil.org> <47D39FA3-050E-46E6-89D2-4253484E24A8@gazagnaire.org> To: Thomas Leonard X-Mailer: Apple Mail (2.2070.6) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Irmin API newbie questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org > Should I make a view here instead? It looks like View.of_path does a > load of copying. What I want is something that I can be sure will > never change. When you build a view, initially it just reads the head commit. Later, when you read elements from it, it lazily fetch and cache the sub-node needed, relatively to this commit. If you never write on the view, all the reads will be relative to the head commit at the time you created the view. Views are designed for this kind of short-lived, non-persistent and isolated sequence of computations. > Neither views nor stores can ensure this I think (both > can be written to). Possibly I should do the "I.of_head" inside > R.make, but then I'd have to give it the repo (config) and task_maker > objects too, which is also ugly. would be very easy to add a RO view if you think that's useful. > It seems strange, since the underlying Git model already provides > immutable data structures (blobs, trees, commits), but Irmin seems to > force me to treat everything as mutable. well, if you want to persist things you need to mutate something anyway. Exposing an immutable API to Git would be a bit cheating as pure function would need to have side-effects to create new objects in the backends (when you add an element to a tree, you need to create the intermediate sub-node in the storage substrates). But others have already expressed some interest on having immutable views (see [1]), so I'll see what I can do. Thomas [1] https://github.com/mirage/irmin/issues/109 > >> I still need to ensure that merging back in the store is really atomic (same issue as with all the other high-level operations). > > BTW, I read more of the storage spec and found: > > "The use of the storage mutex to avoid race conditions is currently > considered by certain implementors to be too high a performance > burden, to the point where allowing data corruption is considered > preferable." > > So some locking will be needed anyway. It would be good to implement > this only in the backend though, and have the rest of Irmin > automatically be safe. > >> Thomas >> >> [1] http://mirage.github.io/irmin/Irmin.html#VALwith_hrw_view > > > -- > Dr Thomas Leonard http://0install.net/ > GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 > GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Mar 05 14:15:48 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 05 Mar 2015 14:15:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTWYw-00054X-B9; Thu, 05 Mar 2015 14:15:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTWYv-00054S-Rg for mirageos-devel@lists.xenproject.org; Thu, 05 Mar 2015 14:15:41 +0000 Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id 99/8B-25903-D0568F45; Thu, 05 Mar 2015 14:15:41 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1425564940!13269914!1 X-Originating-IP: [74.125.82.43] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17777 invoked from network); 5 Mar 2015 14:15:40 -0000 Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com) (74.125.82.43) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2015 14:15:40 -0000 Received: by wghk14 with SMTP id k14so9862370wgh.7 for ; Thu, 05 Mar 2015 06:15:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j1GbbKqTOqXWoyf1N8iS/3gu1D6Oas0Z58+IWEG4wl8=; b=ym6rgV5mJkdU/faNlcQMw8qeiTeiOO9Q8d36O1hZVA8QL/9WAi7gR5JdKbDbyKNeg6 N/4gdDJ0RODCELT3WchdMJzlk1G3/JDhpGKy0gM/DPMU4Rc0tRVaaKUR2VS2hiId5uVM dLeMlmuviSbr3ZZxaQFenvSfCOwRZVjr8OSFTskoQmu5j8bs7dh9aJQb45AZz2pDogbs FbbFLDFuc76gx/gTo1OcvwWJhA48OnlquTmjXGO0IJhh0KNgBH6t8nsbP62bvghsKqJF SbWCTUEl0y45ANFAdHRwgh99KoOfr5OEnESYxyegt1rBTiGyu0Y3qUZWS4RN1OecqjXO Q9dg== X-Received: by 10.194.172.9 with SMTP id ay9mr19139309wjc.2.1425564939684; Thu, 05 Mar 2015 06:15:39 -0800 (PST) Received: from ?IPv6:2001:630:212:248:204c:a7cd:6ac4:c570? ([2001:630:212:248:204c:a7cd:6ac4:c570]) by mx.google.com with ESMTPSA id ub1sm10696910wjc.43.2015.03.05.06.15.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 06:15:38 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Thomas Gazagnaire In-Reply-To: Date: Thu, 5 Mar 2015 14:15:36 +0000 Message-Id: References: <8CEDB416-6238-4888-BA4B-B7305FDDE2D9@gazagnaire.org> <9349273A-0BB4-40C4-BF06-4307085AA90C@recoil.org> <47D39FA3-050E-46E6-89D2-4253484E24A8@gazagnaire.org> To: Thomas Leonard X-Mailer: Apple Mail (2.2070.6) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Irmin API newbie questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org > Should I make a view here instead? It looks like View.of_path does a > load of copying. What I want is something that I can be sure will > never change. When you build a view, initially it just reads the head commit. Later, when you read elements from it, it lazily fetch and cache the sub-node needed, relatively to this commit. If you never write on the view, all the reads will be relative to the head commit at the time you created the view. Views are designed for this kind of short-lived, non-persistent and isolated sequence of computations. > Neither views nor stores can ensure this I think (both > can be written to). Possibly I should do the "I.of_head" inside > R.make, but then I'd have to give it the repo (config) and task_maker > objects too, which is also ugly. would be very easy to add a RO view if you think that's useful. > It seems strange, since the underlying Git model already provides > immutable data structures (blobs, trees, commits), but Irmin seems to > force me to treat everything as mutable. well, if you want to persist things you need to mutate something anyway. Exposing an immutable API to Git would be a bit cheating as pure function would need to have side-effects to create new objects in the backends (when you add an element to a tree, you need to create the intermediate sub-node in the storage substrates). But others have already expressed some interest on having immutable views (see [1]), so I'll see what I can do. Thomas [1] https://github.com/mirage/irmin/issues/109 > >> I still need to ensure that merging back in the store is really atomic (same issue as with all the other high-level operations). > > BTW, I read more of the storage spec and found: > > "The use of the storage mutex to avoid race conditions is currently > considered by certain implementors to be too high a performance > burden, to the point where allowing data corruption is considered > preferable." > > So some locking will be needed anyway. It would be good to implement > this only in the backend though, and have the rest of Irmin > automatically be safe. > >> Thomas >> >> [1] http://mirage.github.io/irmin/Irmin.html#VALwith_hrw_view > > > -- > Dr Thomas Leonard http://0install.net/ > GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 > GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Fri Mar 06 17:33:25 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 06 Mar 2015 17:33:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTw7j-0000tH-Hd; Fri, 06 Mar 2015 17:33:19 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTw7i-0000sZ-I9; Fri, 06 Mar 2015 17:33:18 +0000 Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id 13/7B-25903-DD4E9F45; Fri, 06 Mar 2015 17:33:17 +0000 X-Env-Sender: russell.pavlicek@citrix.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1425663193!6048827!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18886 invoked from network); 6 Mar 2015 17:33:16 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2015 17:33:16 -0000 X-IronPort-AV: E=Sophos;i="5.11,354,1422921600"; d="scan'208,217";a="242554733" From: Russell Pavlicek To: Lars Kurth , xen-devel , "xen-api@lists.xenproject.org" , mirageos-devel , "embedded-pv-devel@lists.xenproject.org" Thread-Topic: [Xen-devel] GSoC 2015 - Not accepted ... but some mentoring organisations which have several Xen related projects in them are Thread-Index: AQHQWDN0yLBVQRkuaUmt9oendKk+9A== Date: Fri, 6 Mar 2015 17:32:36 +0000 Message-ID: <55E78A57290FB64FA0D3CF672F9F3DA2051B3404@SJCPEX01CL03.citrite.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 Cc: "advisory-board@lists.xenproject.org" Subject: Re: [MirageOS-devel] [Xen-devel] GSoC 2015 - Not accepted ... but some mentoring organisations which have several Xen related projects in them are X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4607566091618244829==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============4607566091618244829== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_55E78A57290FB64FA0D3CF672F9F3DA2051B3404SJCPEX01CL03cit_" --_000_55E78A57290FB64FA0D3CF672F9F3DA2051B3404SJCPEX01CL03cit_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I reached out to the GSoC people to get information on why we were not acce= pted. The response is not surprising: Carol writes: "We had to make a lot of hard decisions with our GSoC organizations this ye= ar, and unfortunately yours was one of them. We focused a lot on trying to = make space and accept new, small organizations who have never participated = before, and we felt it wouldn't be an extreme hardship for your organizatio= n to take a year off from the program. I hope you all will apply again in a= future year, and good luck with everything this year!" Russ Pavlicek Xen Project Evangelist, Citrix Systems Home Office: +1-301-829-5327 Mobile: +1-301-814-1143 UK VoIP: +44 1223 852 894 ________________________________ From: xen-devel-bounces@lists.xen.org [xen-devel-bounces@lists.xen.org] on = behalf of Lars Kurth [lars.kurth.xen@gmail.com] Sent: Wednesday, March 04, 2015 12:31 PM To: xen-devel; xen-api@lists.xenproject.org; mirageos-devel; embedded-pv-de= vel@lists.xenproject.org Cc: advisory-board@lists.xenproject.org; Russ Pavlicek Subject: [Xen-devel] GSoC 2015 - Not accepted ... but some mentoring organi= sations which have several Xen related projects in them are Hi folks, just a quick note to let you know that we were not accepted for GSoC this y= ear. Do note that the Linux Foundation, OpenStack Foundation and many of th= e other usual suspects have not been accepted this year. We will find out m= ore why on Friday. However, there are at least 4 Xen related projects that = are managed by other I made a note at the top of http://wiki.xenproject.org/wiki/Archived/GSoC_2= 015 to point applicants to some of those projects. I have found 5 so far (w= hich may bot be a complete list): * Xen based Hypervisor in a Box @ Centos * Xen guest support for OpenBSD @ Open BSD Foundation * 3 Xen related projects @ Ganeti Other projects which were accepted are QEMU: note that there are no Xen related project= s, but given that Xen has good relationships with the QEMU community we may= be able to get one or two projects onto the list if someone steps up and i= s willing to mentor Best Regards Lars --_000_55E78A57290FB64FA0D3CF672F9F3DA2051B3404SJCPEX01CL03cit_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I reached out to the GSoC people to get information on why we were n= ot accepted.  The response is not surprising:

Carol writes:
"We had to make a lot of hard decisions with our GSo= C organizations this year, and unfortunately yours was one of them. We focu= sed a lot on trying to make space and accept new, small organizations who h= ave never participated before, and we felt it wouldn't be an extreme hardship for your organization to take a year of= f from the program. I hope you all will apply again in a future year, and g= ood luck with everything this year!"

Russ Pavlicek
Xen Project Evangelist, Citrix Systems
Home Office: +1-301-829-5327
Mobile: +1-301-814-1143
UK VoIP: +44 1223 852 894
From: xen-devel-bounces@lists.xen.org [xe= n-devel-bounces@lists.xen.org] on behalf of Lars Kurth [lars.kurth.xen@gmai= l.com]
Sent: Wednesday, March 04, 2015 12:31 PM
To: xen-devel; xen-api@lists.xenproject.org; mirageos-devel; embedde= d-pv-devel@lists.xenproject.org
Cc: advisory-board@lists.xenproject.org; Russ Pavlicek
Subject: [Xen-devel] GSoC 2015 - Not accepted ... but some mentoring= organisations which have several Xen related projects in them are

Hi folks,

just a quick note to let you know that we were not accepted= for GSoC this year. Do note that the Linux Foundation, OpenStack Foundatio= n and many of the other usual suspects have not been accepted this year. We= will find out more why on Friday. However, there are at least 4 Xen related projects that are managed by oth= er
 
I made a note at the top of http://wiki.xenproject.org/wiki/Archived/GSoC_2015 to point applic= ants to some of those projects. I have found 5 so far (which may bot be a c= omplete list):
Other projects which were accepted are QEMU: note that there are no Xen related projects, but giv= en that Xen has good relationships with the QEMU community we may be able to get one or two projects onto the list if someo= ne steps up and is willing to mentor

Best Regards
Lars
--_000_55E78A57290FB64FA0D3CF672F9F3DA2051B3404SJCPEX01CL03cit_-- --===============4607566091618244829== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============4607566091618244829==-- From mirageos-devel-bounces@lists.xenproject.org Fri Mar 06 17:33:25 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 06 Mar 2015 17:33:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTw7j-0000tH-Hd; Fri, 06 Mar 2015 17:33:19 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTw7i-0000sZ-I9; Fri, 06 Mar 2015 17:33:18 +0000 Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id 13/7B-25903-DD4E9F45; Fri, 06 Mar 2015 17:33:17 +0000 X-Env-Sender: russell.pavlicek@citrix.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1425663193!6048827!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18886 invoked from network); 6 Mar 2015 17:33:16 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2015 17:33:16 -0000 X-IronPort-AV: E=Sophos;i="5.11,354,1422921600"; d="scan'208,217";a="242554733" From: Russell Pavlicek To: Lars Kurth , xen-devel , "xen-api@lists.xenproject.org" , mirageos-devel , "embedded-pv-devel@lists.xenproject.org" Thread-Topic: [Xen-devel] GSoC 2015 - Not accepted ... but some mentoring organisations which have several Xen related projects in them are Thread-Index: AQHQWDN0yLBVQRkuaUmt9oendKk+9A== Date: Fri, 6 Mar 2015 17:32:36 +0000 Message-ID: <55E78A57290FB64FA0D3CF672F9F3DA2051B3404@SJCPEX01CL03.citrite.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 Cc: "advisory-board@lists.xenproject.org" Subject: Re: [MirageOS-devel] [Xen-devel] GSoC 2015 - Not accepted ... but some mentoring organisations which have several Xen related projects in them are X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4607566091618244829==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============4607566091618244829== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_55E78A57290FB64FA0D3CF672F9F3DA2051B3404SJCPEX01CL03cit_" --_000_55E78A57290FB64FA0D3CF672F9F3DA2051B3404SJCPEX01CL03cit_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I reached out to the GSoC people to get information on why we were not acce= pted. The response is not surprising: Carol writes: "We had to make a lot of hard decisions with our GSoC organizations this ye= ar, and unfortunately yours was one of them. We focused a lot on trying to = make space and accept new, small organizations who have never participated = before, and we felt it wouldn't be an extreme hardship for your organizatio= n to take a year off from the program. I hope you all will apply again in a= future year, and good luck with everything this year!" Russ Pavlicek Xen Project Evangelist, Citrix Systems Home Office: +1-301-829-5327 Mobile: +1-301-814-1143 UK VoIP: +44 1223 852 894 ________________________________ From: xen-devel-bounces@lists.xen.org [xen-devel-bounces@lists.xen.org] on = behalf of Lars Kurth [lars.kurth.xen@gmail.com] Sent: Wednesday, March 04, 2015 12:31 PM To: xen-devel; xen-api@lists.xenproject.org; mirageos-devel; embedded-pv-de= vel@lists.xenproject.org Cc: advisory-board@lists.xenproject.org; Russ Pavlicek Subject: [Xen-devel] GSoC 2015 - Not accepted ... but some mentoring organi= sations which have several Xen related projects in them are Hi folks, just a quick note to let you know that we were not accepted for GSoC this y= ear. Do note that the Linux Foundation, OpenStack Foundation and many of th= e other usual suspects have not been accepted this year. We will find out m= ore why on Friday. However, there are at least 4 Xen related projects that = are managed by other I made a note at the top of http://wiki.xenproject.org/wiki/Archived/GSoC_2= 015 to point applicants to some of those projects. I have found 5 so far (w= hich may bot be a complete list): * Xen based Hypervisor in a Box @ Centos * Xen guest support for OpenBSD @ Open BSD Foundation * 3 Xen related projects @ Ganeti Other projects which were accepted are QEMU: note that there are no Xen related project= s, but given that Xen has good relationships with the QEMU community we may= be able to get one or two projects onto the list if someone steps up and i= s willing to mentor Best Regards Lars --_000_55E78A57290FB64FA0D3CF672F9F3DA2051B3404SJCPEX01CL03cit_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I reached out to the GSoC people to get information on why we were n= ot accepted.  The response is not surprising:

Carol writes:
"We had to make a lot of hard decisions with our GSo= C organizations this year, and unfortunately yours was one of them. We focu= sed a lot on trying to make space and accept new, small organizations who h= ave never participated before, and we felt it wouldn't be an extreme hardship for your organization to take a year of= f from the program. I hope you all will apply again in a future year, and g= ood luck with everything this year!"

Russ Pavlicek
Xen Project Evangelist, Citrix Systems
Home Office: +1-301-829-5327
Mobile: +1-301-814-1143
UK VoIP: +44 1223 852 894
From: xen-devel-bounces@lists.xen.org [xe= n-devel-bounces@lists.xen.org] on behalf of Lars Kurth [lars.kurth.xen@gmai= l.com]
Sent: Wednesday, March 04, 2015 12:31 PM
To: xen-devel; xen-api@lists.xenproject.org; mirageos-devel; embedde= d-pv-devel@lists.xenproject.org
Cc: advisory-board@lists.xenproject.org; Russ Pavlicek
Subject: [Xen-devel] GSoC 2015 - Not accepted ... but some mentoring= organisations which have several Xen related projects in them are

Hi folks,

just a quick note to let you know that we were not accepted= for GSoC this year. Do note that the Linux Foundation, OpenStack Foundatio= n and many of the other usual suspects have not been accepted this year. We= will find out more why on Friday. However, there are at least 4 Xen related projects that are managed by oth= er
 
I made a note at the top of http://wiki.xenproject.org/wiki/Archived/GSoC_2015 to point applic= ants to some of those projects. I have found 5 so far (which may bot be a c= omplete list):
Other projects which were accepted are QEMU: note that there are no Xen related projects, but giv= en that Xen has good relationships with the QEMU community we may be able to get one or two projects onto the list if someo= ne steps up and is willing to mentor

Best Regards
Lars
--_000_55E78A57290FB64FA0D3CF672F9F3DA2051B3404SJCPEX01CL03cit_-- --===============4607566091618244829== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============4607566091618244829==-- From mirageos-devel-bounces@lists.xenproject.org Fri Mar 06 17:59:53 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 06 Mar 2015 17:59:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTwXR-0005AK-3B; Fri, 06 Mar 2015 17:59:53 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTwXP-0005A2-E7 for mirageos-devel@lists.xenproject.org; Fri, 06 Mar 2015 17:59:51 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id 83/A5-02995-61BE9F45; Fri, 06 Mar 2015 17:59:50 +0000 X-Env-Sender: sk826@hermes.cam.ac.uk X-Msg-Ref: server-5.tower-31.messagelabs.com!1425664789!13908577!1 X-Originating-IP: [131.111.8.150] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MCA9PiAxNDk0MDU=\n X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17267 invoked from network); 6 Mar 2015 17:59:50 -0000 Received: from ppsw-50.csi.cam.ac.uk (HELO ppsw-50.csi.cam.ac.uk) (131.111.8.150) by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Mar 2015 17:59:50 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from dhcp-172-17-155-187.eduroam.wireless.private.cam.ac.uk ([172.17.155.187]:53491) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:587) with esmtpsa (PLAIN:sk826) (TLSv1:AES128-SHA:128) id 1YTwXN-0002m5-rc (Exim 4.82_3-c0e5623) for mirageos-devel@lists.xenproject.org (return-path ); Fri, 06 Mar 2015 17:59:49 +0000 From: KC Sivaramakrishnan Message-Id: <22BF96EB-3259-439C-A8CE-F48D5145A056@cl.cam.ac.uk> Date: Fri, 6 Mar 2015 17:59:46 +0000 To: mirageos-devel@lists.xenproject.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Subject: [MirageOS-devel] Irmin RW store questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8438277886596011031==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============8438277886596011031== Content-Type: multipart/alternative; boundary="Apple-Mail=_8B73DCCA-1091-435E-B87B-74A697C314C5" --Apple-Mail=_8B73DCCA-1091-435E-B87B-74A697C314C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I=92d like to use Irmin RW store to implement a simple timestamp based = last-writer-wins register. While the type of Irmin.AO_MAKER =3D functor = (K : Irmin.Hash.S) (V : Tc.S0) -> =85 is understandable, the type of = Irmin.RW_MAKER =3D (K : Irmin.Hum.S) (V : Irmin.Hash.S) -> =85 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? 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? (* Build with * ocamlfind ocamlc -linkpkg -package irmin.git,irmin.unix,git -o = rw_test rw_test.ml *) let (>>=3D) =3D Lwt.bind module Git =3D Irmin_git.RW(Git.Memory) module HumInt =3D struct include Tc.Int let of_hum s =3D=20 (* Following line prints =93master" *) print_string @@ s^"\n"; int_of_string s let to_hum =3D string_of_int end module HumString =3D struct include Tc.String let of_hum s =3D s=20 let to_hum s =3D s=20 end = (*************************************************************************= ****) (* Following Fails *) module Hum =3D HumInt let key =3D 0=20 (* Following works *) (* module Hum =3D HumString let key =3D "0" *) = (*************************************************************************= ****) module S =3D Git(Hum)(Irmin.Hash.SHA1) module SHA1 =3D Irmin.Hash.SHA1 let conf =3D Irmin_git.config () let task =3D Irmin_unix.task let main =3D S.create conf task >>=3D fun store -> S.update (store "update") key=20 (SHA1.of_hum "2fd4e1c67a2d28fced849ee1bb76e7391b93eb12") >>=3D fun _ -> S.read_exn (store "read") key=20 >>=3D fun res -> SHA1.to_hum res |> print_string; Lwt.return () let () =3D Lwt_main.run main Thanks KC= --Apple-Mail=_8B73DCCA-1091-435E-B87B-74A697C314C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I=92d = like to use Irmin RW store to implement a simple timestamp based = last-writer-wins register. While the type of Irmin.AO_MAKER = =3D functor (K : Irmin.Hash.S) (V : Tc.S0) -> =85 is = understandable, the type of Irmin.RW_MAKER =3D (K : Irmin.Hum.S) (V = : Irmin.Hash.S) -> =85 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?

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?

(* Build = with
 * ocamlfind ocamlc = -linkpkg -package irmin.git,irmin.unix,git -o rw_test = rw_test.ml
 *)

let = (>>=3D) =3D Lwt.bind

module Git = =3D Irmin_git.RW(Git.Memory)

module = HumInt =3D struct
  include = Tc.Int
  let of_hum s = =3D 
    (* = Following line prints =93master" *)
    print_string @@ = s^"\n";
    = int_of_string s
  let = to_hum =3D string_of_int
end

module = HumString =3D struct
  = include Tc.String
  let = of_hum s =3D s 
  let = to_hum s =3D s 
end

(********************************************************= *********************)

(* = Following Fails *)
module Hum =3D = HumInt
let key =3D = 0 


(* = Following works *)
(*
module Hum =3D= HumString
let key =3D = "0"
*)

(********************************************************= *********************)

module S =3D= Git(Hum)(Irmin.Hash.SHA1)
module = SHA1 =3D Irmin.Hash.SHA1

let conf =3D= Irmin_git.config ()
let task =3D = Irmin_unix.task

let main = =3D
  S.create conf = task
  >>=3D fun = store ->
      = S.update (store "update") key 
      (SHA1.of_hum = "2fd4e1c67a2d28fced849ee1bb76e7391b93eb12")
  >>=3D fun _ -> S.read_exn (store = "read") key 
  = >>=3D fun res ->
  =       SHA1.to_hum res |> = print_string;
    =     Lwt.return ()

let () =3D = Lwt_main.run main

Thanks
KC
= --Apple-Mail=_8B73DCCA-1091-435E-B87B-74A697C314C5-- --===============8438277886596011031== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============8438277886596011031==-- From mirageos-devel-bounces@lists.xenproject.org Fri Mar 06 17:59:53 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 06 Mar 2015 17:59:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTwXR-0005AK-3B; Fri, 06 Mar 2015 17:59:53 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YTwXP-0005A2-E7 for mirageos-devel@lists.xenproject.org; Fri, 06 Mar 2015 17:59:51 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id 83/A5-02995-61BE9F45; Fri, 06 Mar 2015 17:59:50 +0000 X-Env-Sender: sk826@hermes.cam.ac.uk X-Msg-Ref: server-5.tower-31.messagelabs.com!1425664789!13908577!1 X-Originating-IP: [131.111.8.150] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MCA9PiAxNDk0MDU=\n X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17267 invoked from network); 6 Mar 2015 17:59:50 -0000 Received: from ppsw-50.csi.cam.ac.uk (HELO ppsw-50.csi.cam.ac.uk) (131.111.8.150) by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Mar 2015 17:59:50 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from dhcp-172-17-155-187.eduroam.wireless.private.cam.ac.uk ([172.17.155.187]:53491) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:587) with esmtpsa (PLAIN:sk826) (TLSv1:AES128-SHA:128) id 1YTwXN-0002m5-rc (Exim 4.82_3-c0e5623) for mirageos-devel@lists.xenproject.org (return-path ); Fri, 06 Mar 2015 17:59:49 +0000 From: KC Sivaramakrishnan Message-Id: <22BF96EB-3259-439C-A8CE-F48D5145A056@cl.cam.ac.uk> Date: Fri, 6 Mar 2015 17:59:46 +0000 To: mirageos-devel@lists.xenproject.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Subject: [MirageOS-devel] Irmin RW store questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8438277886596011031==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============8438277886596011031== Content-Type: multipart/alternative; boundary="Apple-Mail=_8B73DCCA-1091-435E-B87B-74A697C314C5" --Apple-Mail=_8B73DCCA-1091-435E-B87B-74A697C314C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I=92d like to use Irmin RW store to implement a simple timestamp based = last-writer-wins register. While the type of Irmin.AO_MAKER =3D functor = (K : Irmin.Hash.S) (V : Tc.S0) -> =85 is understandable, the type of = Irmin.RW_MAKER =3D (K : Irmin.Hum.S) (V : Irmin.Hash.S) -> =85 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? 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? (* Build with * ocamlfind ocamlc -linkpkg -package irmin.git,irmin.unix,git -o = rw_test rw_test.ml *) let (>>=3D) =3D Lwt.bind module Git =3D Irmin_git.RW(Git.Memory) module HumInt =3D struct include Tc.Int let of_hum s =3D=20 (* Following line prints =93master" *) print_string @@ s^"\n"; int_of_string s let to_hum =3D string_of_int end module HumString =3D struct include Tc.String let of_hum s =3D s=20 let to_hum s =3D s=20 end = (*************************************************************************= ****) (* Following Fails *) module Hum =3D HumInt let key =3D 0=20 (* Following works *) (* module Hum =3D HumString let key =3D "0" *) = (*************************************************************************= ****) module S =3D Git(Hum)(Irmin.Hash.SHA1) module SHA1 =3D Irmin.Hash.SHA1 let conf =3D Irmin_git.config () let task =3D Irmin_unix.task let main =3D S.create conf task >>=3D fun store -> S.update (store "update") key=20 (SHA1.of_hum "2fd4e1c67a2d28fced849ee1bb76e7391b93eb12") >>=3D fun _ -> S.read_exn (store "read") key=20 >>=3D fun res -> SHA1.to_hum res |> print_string; Lwt.return () let () =3D Lwt_main.run main Thanks KC= --Apple-Mail=_8B73DCCA-1091-435E-B87B-74A697C314C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I=92d = like to use Irmin RW store to implement a simple timestamp based = last-writer-wins register. While the type of Irmin.AO_MAKER = =3D functor (K : Irmin.Hash.S) (V : Tc.S0) -> =85 is = understandable, the type of Irmin.RW_MAKER =3D (K : Irmin.Hum.S) (V = : Irmin.Hash.S) -> =85 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?

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?

(* Build = with
 * ocamlfind ocamlc = -linkpkg -package irmin.git,irmin.unix,git -o rw_test = rw_test.ml
 *)

let = (>>=3D) =3D Lwt.bind

module Git = =3D Irmin_git.RW(Git.Memory)

module = HumInt =3D struct
  include = Tc.Int
  let of_hum s = =3D 
    (* = Following line prints =93master" *)
    print_string @@ = s^"\n";
    = int_of_string s
  let = to_hum =3D string_of_int
end

module = HumString =3D struct
  = include Tc.String
  let = of_hum s =3D s 
  let = to_hum s =3D s 
end

(********************************************************= *********************)

(* = Following Fails *)
module Hum =3D = HumInt
let key =3D = 0 


(* = Following works *)
(*
module Hum =3D= HumString
let key =3D = "0"
*)

(********************************************************= *********************)

module S =3D= Git(Hum)(Irmin.Hash.SHA1)
module = SHA1 =3D Irmin.Hash.SHA1

let conf =3D= Irmin_git.config ()
let task =3D = Irmin_unix.task

let main = =3D
  S.create conf = task
  >>=3D fun = store ->
      = S.update (store "update") key 
      (SHA1.of_hum = "2fd4e1c67a2d28fced849ee1bb76e7391b93eb12")
  >>=3D fun _ -> S.read_exn (store = "read") key 
  = >>=3D fun res ->
  =       SHA1.to_hum res |> = print_string;
    =     Lwt.return ()

let () =3D = Lwt_main.run main

Thanks
KC
= --Apple-Mail=_8B73DCCA-1091-435E-B87B-74A697C314C5-- --===============8438277886596011031== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============8438277886596011031==-- From mirageos-devel-bounces@lists.xenproject.org Sat Mar 07 03:55:30 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 07 Mar 2015 03:55:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YU5pj-0002qK-78; Sat, 07 Mar 2015 03:55:23 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YU5pi-0002q3-6W; Sat, 07 Mar 2015 03:55:22 +0000 Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id 5B/61-03164-9A67AF45; Sat, 07 Mar 2015 03:55:21 +0000 X-Env-Sender: russell.pavlicek.xen@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1425700520!15453616!1 X-Originating-IP: [209.85.217.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11034 invoked from network); 7 Mar 2015 03:55:20 -0000 Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com) (209.85.217.173) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2015 03:55:20 -0000 Received: by lbiz11 with SMTP id z11so35448692lbi.3; Fri, 06 Mar 2015 19:55:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=BggZUbGeJ2sI+HGX5yGBdj97ufdLdWkFpPWASD/ZtFw=; b=LRkcdUzrUkn2LFZj1X/3IsnAleKU7JldxSNKi8dQHMHMPfCLKqNbc2aqre1f5SiHXk XwYhv6PAhFZClJLgwVuItWSzmfZMiPFXQYD3afzZUUZEebcl94nEYmzlxJNsLS9Y4dzH EtZzam88JbdZB1i9kec2CYKQyWwK2mIXIA60fxlFPjfiBq5PhTLAjBA+/mRuEy8Le5la QIjMejcHXBPo+gyN2c2UFF0m0S04mNDpqUyxxU0IptYju0ys+wSp7CuKDkS2ACaD2iuq /oupOZxgHq3URHdfQToRM7F6zUjeiVtFhwAXklCRp8VvK1i69lNwl6NpdI1CrvblIexk 4RCQ== MIME-Version: 1.0 X-Received: by 10.152.36.138 with SMTP id q10mr15466028laj.113.1425700519654; Fri, 06 Mar 2015 19:55:19 -0800 (PST) Received: by 10.112.25.37 with HTTP; Fri, 6 Mar 2015 19:55:19 -0800 (PST) Date: Fri, 6 Mar 2015 22:55:19 -0500 X-Google-Sender-Auth: i8EbG3SGV25Oonj4gK0HtuPXGgE Message-ID: From: Russ Pavlicek To: xen-devel , mirageos-devel@lists.xenproject.org, xen-api@lists.xen.org, xs-devel@lists.xenserver.org Subject: [MirageOS-devel] Outreachy (OPW) Mentors: Please update your project ideas X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Xen Project has two slots in the upcoming Round 10 of Outreachy (the new name for OPW). All prospective mentors need to update their project ideas soon on the page: http://wiki.xenproject.org/wiki/Outreach_Program_Projects Applicants have to create initial patches and file their applications by March 24, so please try to update your project ideas during the next week, if at all possible. You can read about the latest round of Outreachy here: http://wiki.xenproject.org/wiki/Outreachy/Round10 Until Lars returns from vacation on March 11, please direct any questions or issues to me and I will do my best to move things forward. Thanks, Russ _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Mar 07 03:55:30 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 07 Mar 2015 03:55:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YU5pj-0002qK-78; Sat, 07 Mar 2015 03:55:23 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YU5pi-0002q3-6W; Sat, 07 Mar 2015 03:55:22 +0000 Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id 5B/61-03164-9A67AF45; Sat, 07 Mar 2015 03:55:21 +0000 X-Env-Sender: russell.pavlicek.xen@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1425700520!15453616!1 X-Originating-IP: [209.85.217.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11034 invoked from network); 7 Mar 2015 03:55:20 -0000 Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com) (209.85.217.173) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2015 03:55:20 -0000 Received: by lbiz11 with SMTP id z11so35448692lbi.3; Fri, 06 Mar 2015 19:55:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=BggZUbGeJ2sI+HGX5yGBdj97ufdLdWkFpPWASD/ZtFw=; b=LRkcdUzrUkn2LFZj1X/3IsnAleKU7JldxSNKi8dQHMHMPfCLKqNbc2aqre1f5SiHXk XwYhv6PAhFZClJLgwVuItWSzmfZMiPFXQYD3afzZUUZEebcl94nEYmzlxJNsLS9Y4dzH EtZzam88JbdZB1i9kec2CYKQyWwK2mIXIA60fxlFPjfiBq5PhTLAjBA+/mRuEy8Le5la QIjMejcHXBPo+gyN2c2UFF0m0S04mNDpqUyxxU0IptYju0ys+wSp7CuKDkS2ACaD2iuq /oupOZxgHq3URHdfQToRM7F6zUjeiVtFhwAXklCRp8VvK1i69lNwl6NpdI1CrvblIexk 4RCQ== MIME-Version: 1.0 X-Received: by 10.152.36.138 with SMTP id q10mr15466028laj.113.1425700519654; Fri, 06 Mar 2015 19:55:19 -0800 (PST) Received: by 10.112.25.37 with HTTP; Fri, 6 Mar 2015 19:55:19 -0800 (PST) Date: Fri, 6 Mar 2015 22:55:19 -0500 X-Google-Sender-Auth: i8EbG3SGV25Oonj4gK0HtuPXGgE Message-ID: From: Russ Pavlicek To: xen-devel , mirageos-devel@lists.xenproject.org, xen-api@lists.xen.org, xs-devel@lists.xenserver.org Subject: [MirageOS-devel] Outreachy (OPW) Mentors: Please update your project ideas X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Xen Project has two slots in the upcoming Round 10 of Outreachy (the new name for OPW). All prospective mentors need to update their project ideas soon on the page: http://wiki.xenproject.org/wiki/Outreach_Program_Projects Applicants have to create initial patches and file their applications by March 24, so please try to update your project ideas during the next week, if at all possible. You can read about the latest round of Outreachy here: http://wiki.xenproject.org/wiki/Outreachy/Round10 Until Lars returns from vacation on March 11, please direct any questions or issues to me and I will do my best to move things forward. Thanks, Russ _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Mar 07 10:18:52 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 07 Mar 2015 10:18:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YUBoj-00060A-VY; Sat, 07 Mar 2015 10:18:45 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YUBoi-000605-No for mirageos-devel@lists.xenproject.org; Sat, 07 Mar 2015 10:18:44 +0000 Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id 85/9D-03163-380DAF45; Sat, 07 Mar 2015 10:18:43 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-14.tower-31.messagelabs.com!1425723522!11538502!1 X-Originating-IP: [74.125.82.43] X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12436 invoked from network); 7 Mar 2015 10:18:42 -0000 Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com) (74.125.82.43) by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2015 10:18:42 -0000 Received: by wghk14 with SMTP id k14so14127558wgh.3 for ; Sat, 07 Mar 2015 02:18:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=9LocKOOWmtr1F1W1mdx4T20D+ze7OnW1vNJNa+HCa5s=; b=dMxzj5cPueZGqVA3HLGyiVx4S2lwvniLkIMK2STBjoL28H2cwueATlEB1TyasgUWL7 zv/ju9/uLVVff7vHM1jZ5458KPxgnYX6snJSYgfO1c5Z2kUszLeqBgZSnKkilOPP7KCJ x8G/treytOHSTaGb5l5Y1HNBwu7o71k/RJNo//y+mXVS9Wgh9qw3gK4LOAnLjbvzt4SV bCMdCOVqvJsBbB+tX3ReobXQhe6b9FyJjQhTL8RAMjIg7qg766n+orSS4b83Y3XHp29T Blrnxrp9jT9w6INXOVxbOAIYth4EIjm4SYbKo2BdN8+5oL8AzDr8uQ52xHx37unUKgcr nz5w== X-Received: by 10.180.8.136 with SMTP id r8mr70734245wia.42.1425723522211; Sat, 07 Mar 2015 02:18:42 -0800 (PST) Received: from [192.168.1.44] (car06-8-83-155-104-81.fbx.proxad.net. [83.155.104.81]) by mx.google.com with ESMTPSA id bf8sm17118432wjb.37.2015.03.07.02.18.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Mar 2015 02:18:40 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Thomas Gazagnaire In-Reply-To: <22BF96EB-3259-439C-A8CE-F48D5145A056@cl.cam.ac.uk> Date: Sat, 7 Mar 2015 11:18:40 +0100 Message-Id: References: <22BF96EB-3259-439C-A8CE-F48D5145A056@cl.cam.ac.uk> To: KC Sivaramakrishnan X-Mailer: Apple Mail (2.2070.6) Cc: mirageos-devel@lists.xenproject.org Subject: Re: [MirageOS-devel] Irmin RW store questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3716660690172822864==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============3716660690172822864== Content-Type: multipart/alternative; boundary="Apple-Mail=_E5696DA6-9B3D-401E-9A74-33798D84C163" --Apple-Mail=_E5696DA6-9B3D-401E-9A74-33798D84C163 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi KC, > I=92d like to use Irmin RW store to implement a simple timestamp based = last-writer-wins register. While the type of Irmin.AO_MAKER =3D functor = (K : Irmin.Hash.S) (V : Tc.S0) -> =85 is understandable, the type of = Irmin.RW_MAKER =3D (K : Irmin.Hum.S) (V : Irmin.Hash.S) -> =85 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 = [2] 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:=20 module Git =3D Irmin_git.RW(Git.Memory) by either: module Git =3D Irmin_mem.RW (* in-memory store *) module Git =3D 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 = Thanks, Thomas= --Apple-Mail=_E5696DA6-9B3D-401E-9A74-33798D84C163 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi KC,

I=92d like to use = Irmin RW store to implement a simple timestamp based last-writer-wins = register. While the type of Irmin.AO_MAKER =3D functor (K : = Irmin.Hash.S) (V : Tc.S0) -> =85 is understandable, the type of = Irmin.RW_MAKER =3D (K : Irmin.Hum.S) (V : Irmin.Hash.S) -> =85 = 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.

[2] 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 =3D = Irmin_git.RW(Git.Memory)
by either:
module Git =3D = Irmin_mem.RW (* in-memory store *)
module Git =3D = Irmin_unix.Irmin_fs.RW (* on-disk with custom binary format = *)

and your test program will = work.


Thanks,
Thomas
= --Apple-Mail=_E5696DA6-9B3D-401E-9A74-33798D84C163-- --===============3716660690172822864== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============3716660690172822864==-- From mirageos-devel-bounces@lists.xenproject.org Sat Mar 07 10:18:52 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 07 Mar 2015 10:18:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YUBoj-00060A-VY; Sat, 07 Mar 2015 10:18:45 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YUBoi-000605-No for mirageos-devel@lists.xenproject.org; Sat, 07 Mar 2015 10:18:44 +0000 Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id 85/9D-03163-380DAF45; Sat, 07 Mar 2015 10:18:43 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-14.tower-31.messagelabs.com!1425723522!11538502!1 X-Originating-IP: [74.125.82.43] X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12436 invoked from network); 7 Mar 2015 10:18:42 -0000 Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com) (74.125.82.43) by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2015 10:18:42 -0000 Received: by wghk14 with SMTP id k14so14127558wgh.3 for ; Sat, 07 Mar 2015 02:18:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=9LocKOOWmtr1F1W1mdx4T20D+ze7OnW1vNJNa+HCa5s=; b=dMxzj5cPueZGqVA3HLGyiVx4S2lwvniLkIMK2STBjoL28H2cwueATlEB1TyasgUWL7 zv/ju9/uLVVff7vHM1jZ5458KPxgnYX6snJSYgfO1c5Z2kUszLeqBgZSnKkilOPP7KCJ x8G/treytOHSTaGb5l5Y1HNBwu7o71k/RJNo//y+mXVS9Wgh9qw3gK4LOAnLjbvzt4SV bCMdCOVqvJsBbB+tX3ReobXQhe6b9FyJjQhTL8RAMjIg7qg766n+orSS4b83Y3XHp29T Blrnxrp9jT9w6INXOVxbOAIYth4EIjm4SYbKo2BdN8+5oL8AzDr8uQ52xHx37unUKgcr nz5w== X-Received: by 10.180.8.136 with SMTP id r8mr70734245wia.42.1425723522211; Sat, 07 Mar 2015 02:18:42 -0800 (PST) Received: from [192.168.1.44] (car06-8-83-155-104-81.fbx.proxad.net. [83.155.104.81]) by mx.google.com with ESMTPSA id bf8sm17118432wjb.37.2015.03.07.02.18.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Mar 2015 02:18:40 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Thomas Gazagnaire In-Reply-To: <22BF96EB-3259-439C-A8CE-F48D5145A056@cl.cam.ac.uk> Date: Sat, 7 Mar 2015 11:18:40 +0100 Message-Id: References: <22BF96EB-3259-439C-A8CE-F48D5145A056@cl.cam.ac.uk> To: KC Sivaramakrishnan X-Mailer: Apple Mail (2.2070.6) Cc: mirageos-devel@lists.xenproject.org Subject: Re: [MirageOS-devel] Irmin RW store questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3716660690172822864==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============3716660690172822864== Content-Type: multipart/alternative; boundary="Apple-Mail=_E5696DA6-9B3D-401E-9A74-33798D84C163" --Apple-Mail=_E5696DA6-9B3D-401E-9A74-33798D84C163 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi KC, > I=92d like to use Irmin RW store to implement a simple timestamp based = last-writer-wins register. While the type of Irmin.AO_MAKER =3D functor = (K : Irmin.Hash.S) (V : Tc.S0) -> =85 is understandable, the type of = Irmin.RW_MAKER =3D (K : Irmin.Hum.S) (V : Irmin.Hash.S) -> =85 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 = [2] 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:=20 module Git =3D Irmin_git.RW(Git.Memory) by either: module Git =3D Irmin_mem.RW (* in-memory store *) module Git =3D 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 = Thanks, Thomas= --Apple-Mail=_E5696DA6-9B3D-401E-9A74-33798D84C163 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi KC,

I=92d like to use = Irmin RW store to implement a simple timestamp based last-writer-wins = register. While the type of Irmin.AO_MAKER =3D functor (K : = Irmin.Hash.S) (V : Tc.S0) -> =85 is understandable, the type of = Irmin.RW_MAKER =3D (K : Irmin.Hum.S) (V : Irmin.Hash.S) -> =85 = 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.

[2] 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 =3D = Irmin_git.RW(Git.Memory)
by either:
module Git =3D = Irmin_mem.RW (* in-memory store *)
module Git =3D = Irmin_unix.Irmin_fs.RW (* on-disk with custom binary format = *)

and your test program will = work.


Thanks,
Thomas
= --Apple-Mail=_E5696DA6-9B3D-401E-9A74-33798D84C163-- --===============3716660690172822864== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============3716660690172822864==-- From mirageos-devel-bounces@lists.xenproject.org Sat Mar 07 10:49:47 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 07 Mar 2015 10:49:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YUCIi-0002D0-6F; Sat, 07 Mar 2015 10:49:44 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YUCIg-0002Ct-VR for mirageos-devel@lists.xenproject.org; Sat, 07 Mar 2015 10:49:43 +0000 Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id F4/CC-02757-5C7DAF45; Sat, 07 Mar 2015 10:49:41 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1425725380!6140636!1 X-Originating-IP: [209.85.215.48] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12417 invoked from network); 7 Mar 2015 10:49:40 -0000 Received: from mail-la0-f48.google.com (HELO mail-la0-f48.google.com) (209.85.215.48) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2015 10:49:40 -0000 Received: by labgd6 with SMTP id gd6so15303702lab.3 for ; Sat, 07 Mar 2015 02:49:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=28eVtISOjKR4SBlovzokHzmUJgcWPdY7X8EFdQW0OIg=; b=r7VJuZtTWhDKu23BHlYe6y47pNhXLkq9ddpp82zI7s+Omd1dps8W2uikiK7ovOso6S Y4p/meo6NCGNinS+qoyPIXDY+2/49mOLZ66g+UbFHuDfh3Pfvq+I/p4GbI9xl3nRgqoT 7oNoYBd67k8ec8yrppQi+WMQkm+q0zJ98WcSK3hh4Fn7DZQx62S0/N9wY4mmTYFZO2N6 GUnX5RZ4CQ8Avt7/YJxFxENMzM5thYJcjC4R62Uyfj7bwSV4pXZ5JoOEzgQXnpyXEH0m TQVwwnCJWknatW6wR44L+PfAmMeYJSIO5aPZ++u9QXP/sqbd/74pDNPjLSqhwk/EEd01 vlEw== MIME-Version: 1.0 X-Received: by 10.152.115.169 with SMTP id jp9mr16863946lab.121.1425725380169; Sat, 07 Mar 2015 02:49:40 -0800 (PST) Received: by 10.25.207.17 with HTTP; Sat, 7 Mar 2015 02:49:40 -0800 (PST) In-Reply-To: References: <8CEDB416-6238-4888-BA4B-B7305FDDE2D9@gazagnaire.org> <9349273A-0BB4-40C4-BF06-4307085AA90C@recoil.org> <47D39FA3-050E-46E6-89D2-4253484E24A8@gazagnaire.org> Date: Sat, 7 Mar 2015 10:49:40 +0000 Message-ID: From: Thomas Leonard To: Thomas Gazagnaire Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Irmin API newbie questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 5 March 2015 at 14:15, Thomas Gazagnaire wrote: >> Should I make a view here instead? It looks like View.of_path does a >> load of copying. What I want is something that I can be sure will >> never change. > > When you build a view, initially it just reads the head commit. Later, when you read elements from it, it lazily fetch and cache the sub-node needed, relatively to this commit. If you never write on the view, all the reads will be relative to the head commit at the time you created the view. Views are designed for this kind of short-lived, non-persistent and isolated sequence of computations. How do I find out what commit the view was based on? It looks like it just reads whatever is current for the store, which could have changed since I checked it. >> Neither views nor stores can ensure this I think (both >> can be written to). Possibly I should do the "I.of_head" inside >> R.make, but then I'd have to give it the repo (config) and task_maker >> objects too, which is also ugly. > > would be very easy to add a RO view if you think that's useful. > >> It seems strange, since the underlying Git model already provides >> immutable data structures (blobs, trees, commits), but Irmin seems to >> force me to treat everything as mutable. > > well, if you want to persist things you need to mutate something anyway. Exposing an immutable API to Git would be a bit cheating as pure function would need to have side-effects to create new objects in the backends (when you add an element to a tree, you need to create the intermediate sub-node in the storage substrates). But others have already expressed some interest on having immutable views (see [1]), so I'll see what I can do. > > Thomas > [1] https://github.com/mirage/irmin/issues/109 That would be very useful! Even pure functions are allowed to allocate data (which can later be GC'd), so I don't see a problem with allocating objects in the store in the same way. >>> I still need to ensure that merging back in the store is really atomic (same issue as with all the other high-level operations). >> >> BTW, I read more of the storage spec and found: >> >> "The use of the storage mutex to avoid race conditions is currently >> considered by certain implementors to be too high a performance >> burden, to the point where allowing data corruption is considered >> preferable." >> >> So some locking will be needed anyway. It would be good to implement >> this only in the backend though, and have the rest of Irmin >> automatically be safe. >> >>> Thomas >>> >>> [1] http://mirage.github.io/irmin/Irmin.html#VALwith_hrw_view >> >> >> -- >> Dr Thomas Leonard http://0install.net/ >> GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 >> GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA > -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Mar 07 10:49:47 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 07 Mar 2015 10:49:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YUCIi-0002D0-6F; Sat, 07 Mar 2015 10:49:44 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YUCIg-0002Ct-VR for mirageos-devel@lists.xenproject.org; Sat, 07 Mar 2015 10:49:43 +0000 Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id F4/CC-02757-5C7DAF45; Sat, 07 Mar 2015 10:49:41 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1425725380!6140636!1 X-Originating-IP: [209.85.215.48] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12417 invoked from network); 7 Mar 2015 10:49:40 -0000 Received: from mail-la0-f48.google.com (HELO mail-la0-f48.google.com) (209.85.215.48) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2015 10:49:40 -0000 Received: by labgd6 with SMTP id gd6so15303702lab.3 for ; Sat, 07 Mar 2015 02:49:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=28eVtISOjKR4SBlovzokHzmUJgcWPdY7X8EFdQW0OIg=; b=r7VJuZtTWhDKu23BHlYe6y47pNhXLkq9ddpp82zI7s+Omd1dps8W2uikiK7ovOso6S Y4p/meo6NCGNinS+qoyPIXDY+2/49mOLZ66g+UbFHuDfh3Pfvq+I/p4GbI9xl3nRgqoT 7oNoYBd67k8ec8yrppQi+WMQkm+q0zJ98WcSK3hh4Fn7DZQx62S0/N9wY4mmTYFZO2N6 GUnX5RZ4CQ8Avt7/YJxFxENMzM5thYJcjC4R62Uyfj7bwSV4pXZ5JoOEzgQXnpyXEH0m TQVwwnCJWknatW6wR44L+PfAmMeYJSIO5aPZ++u9QXP/sqbd/74pDNPjLSqhwk/EEd01 vlEw== MIME-Version: 1.0 X-Received: by 10.152.115.169 with SMTP id jp9mr16863946lab.121.1425725380169; Sat, 07 Mar 2015 02:49:40 -0800 (PST) Received: by 10.25.207.17 with HTTP; Sat, 7 Mar 2015 02:49:40 -0800 (PST) In-Reply-To: References: <8CEDB416-6238-4888-BA4B-B7305FDDE2D9@gazagnaire.org> <9349273A-0BB4-40C4-BF06-4307085AA90C@recoil.org> <47D39FA3-050E-46E6-89D2-4253484E24A8@gazagnaire.org> Date: Sat, 7 Mar 2015 10:49:40 +0000 Message-ID: From: Thomas Leonard To: Thomas Gazagnaire Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Irmin API newbie questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 5 March 2015 at 14:15, Thomas Gazagnaire wrote: >> Should I make a view here instead? It looks like View.of_path does a >> load of copying. What I want is something that I can be sure will >> never change. > > When you build a view, initially it just reads the head commit. Later, when you read elements from it, it lazily fetch and cache the sub-node needed, relatively to this commit. If you never write on the view, all the reads will be relative to the head commit at the time you created the view. Views are designed for this kind of short-lived, non-persistent and isolated sequence of computations. How do I find out what commit the view was based on? It looks like it just reads whatever is current for the store, which could have changed since I checked it. >> Neither views nor stores can ensure this I think (both >> can be written to). Possibly I should do the "I.of_head" inside >> R.make, but then I'd have to give it the repo (config) and task_maker >> objects too, which is also ugly. > > would be very easy to add a RO view if you think that's useful. > >> It seems strange, since the underlying Git model already provides >> immutable data structures (blobs, trees, commits), but Irmin seems to >> force me to treat everything as mutable. > > well, if you want to persist things you need to mutate something anyway. Exposing an immutable API to Git would be a bit cheating as pure function would need to have side-effects to create new objects in the backends (when you add an element to a tree, you need to create the intermediate sub-node in the storage substrates). But others have already expressed some interest on having immutable views (see [1]), so I'll see what I can do. > > Thomas > [1] https://github.com/mirage/irmin/issues/109 That would be very useful! Even pure functions are allowed to allocate data (which can later be GC'd), so I don't see a problem with allocating objects in the store in the same way. >>> I still need to ensure that merging back in the store is really atomic (same issue as with all the other high-level operations). >> >> BTW, I read more of the storage spec and found: >> >> "The use of the storage mutex to avoid race conditions is currently >> considered by certain implementors to be too high a performance >> burden, to the point where allowing data corruption is considered >> preferable." >> >> So some locking will be needed anyway. It would be good to implement >> this only in the backend though, and have the rest of Irmin >> automatically be safe. >> >>> Thomas >>> >>> [1] http://mirage.github.io/irmin/Irmin.html#VALwith_hrw_view >> >> >> -- >> Dr Thomas Leonard http://0install.net/ >> GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 >> GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA > -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sun Mar 08 15:20:16 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 08 Mar 2015 15:20:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YUczv-00015m-8Q; Sun, 08 Mar 2015 15:20:07 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YUczu-00015h-1m for mirageos-devel@lists.xenproject.org; Sun, 08 Mar 2015 15:20:06 +0000 Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id 00/CC-03165-5A86CF45; Sun, 08 Mar 2015 15:20:05 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-9.tower-206.messagelabs.com!1425828004!13833354!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28093 invoked from network); 8 Mar 2015 15:20:04 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-9.tower-206.messagelabs.com with SMTP; 8 Mar 2015 15:20:04 -0000 Received: from [172.20.10.2] (198.234.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch [178.197.234.198]) by smtp.webfaction.com (Postfix) with ESMTP id 268F459A40EA for ; Sun, 8 Mar 2015 15:20:02 +0000 (UTC) Date: Sun, 8 Mar 2015 16:20:00 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: mirageos-devel Message-ID: In-Reply-To: References: <20150202.014549.1883720051237442569.Christophe.Troestler@umons.ac.be> <20150204.001614.26478837567139584.Christophe.Troestler@umons.ac.be> <87oap97rvw.fsf@study.localdomain> <87lhk4csew.fsf@study.localdomain> <2A0347CF598A4081B45318903375F7A9@erratique.ch> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [MirageOS-devel] Error handling in Mirage - request for comments! X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org I found resultv to be visually hard to parse, so the package name changed again to a *final* rresult (with an alveolar trill). http://erratique.ch/software/rresult I have tentatively added design guidelines for using the type: http://erratique.ch/software/rresult/doc/Rresult.html#usage Best, Daniel _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sun Mar 08 15:20:16 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 08 Mar 2015 15:20:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YUczv-00015m-8Q; Sun, 08 Mar 2015 15:20:07 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YUczu-00015h-1m for mirageos-devel@lists.xenproject.org; Sun, 08 Mar 2015 15:20:06 +0000 Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id 00/CC-03165-5A86CF45; Sun, 08 Mar 2015 15:20:05 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-9.tower-206.messagelabs.com!1425828004!13833354!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28093 invoked from network); 8 Mar 2015 15:20:04 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-9.tower-206.messagelabs.com with SMTP; 8 Mar 2015 15:20:04 -0000 Received: from [172.20.10.2] (198.234.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch [178.197.234.198]) by smtp.webfaction.com (Postfix) with ESMTP id 268F459A40EA for ; Sun, 8 Mar 2015 15:20:02 +0000 (UTC) Date: Sun, 8 Mar 2015 16:20:00 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: mirageos-devel Message-ID: In-Reply-To: References: <20150202.014549.1883720051237442569.Christophe.Troestler@umons.ac.be> <20150204.001614.26478837567139584.Christophe.Troestler@umons.ac.be> <87oap97rvw.fsf@study.localdomain> <87lhk4csew.fsf@study.localdomain> <2A0347CF598A4081B45318903375F7A9@erratique.ch> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [MirageOS-devel] Error handling in Mirage - request for comments! X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org I found resultv to be visually hard to parse, so the package name changed again to a *final* rresult (with an alveolar trill). http://erratique.ch/software/rresult I have tentatively added design guidelines for using the type: http://erratique.ch/software/rresult/doc/Rresult.html#usage Best, Daniel _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Mar 09 10:37:07 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 09 Mar 2015 10:37:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YUv3W-0007oe-P5; Mon, 09 Mar 2015 10:37:02 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YUv3V-0007oV-HV for mirageos-devel@lists.xenproject.org; Mon, 09 Mar 2015 10:37:01 +0000 Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id 33/1E-03168-CC77DF45; Mon, 09 Mar 2015 10:37:00 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1425897418!15773418!1 X-Originating-IP: [209.85.215.54] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25025 invoked from network); 9 Mar 2015 10:36:58 -0000 Received: from mail-la0-f54.google.com (HELO mail-la0-f54.google.com) (209.85.215.54) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 Mar 2015 10:36:58 -0000 Received: by labgf13 with SMTP id gf13so45325827lab.5 for ; Mon, 09 Mar 2015 03:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=U1R1mlJ7aTdYnVBKTKFj2kDv4TBn6DwF4dfNHJYAP6I=; b=eVqoArvq+VJICWzxn8dadQ8b/Lpm5BflcCJuJK1GRklGt2lPHv2thBgbSf4uH8BITI 4OsVgwwmmyNBn40CM0gT1IVZXo+kQb7JUrLEnF5AkMyUkR2BrpKu9qfwWQe+JOsbq74g aljZOAnvk+xGqEPcnCMcdbJU2zHhKOVqPKoWy0XzUMe0TB50Lz5oBF05uVS+y64Kg5Hd 4ZhGGF3+ELQUdduHyjo/dsXP1/DNbScpxGmcCvsGnAlXyBybsR6qHIRJ/oNoH0WKV192 neAq7F0Ou0AHRRw0iJEYNC73EaYHAI0RoEeMPUtdUvK6XVBsHGaD7essaf8wC2bOVEGR BzRg== MIME-Version: 1.0 X-Received: by 10.152.20.201 with SMTP id p9mr24829186lae.50.1425897417904; Mon, 09 Mar 2015 03:36:57 -0700 (PDT) Received: by 10.25.207.17 with HTTP; Mon, 9 Mar 2015 03:36:57 -0700 (PDT) In-Reply-To: References: <8CEDB416-6238-4888-BA4B-B7305FDDE2D9@gazagnaire.org> <9349273A-0BB4-40C4-BF06-4307085AA90C@recoil.org> <47D39FA3-050E-46E6-89D2-4253484E24A8@gazagnaire.org> Date: Mon, 9 Mar 2015 10:36:57 +0000 Message-ID: From: Thomas Leonard To: Thomas Gazagnaire Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Irmin API newbie questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 7 March 2015 at 10:49, Thomas Leonard wrote: > On 5 March 2015 at 14:15, Thomas Gazagnaire wrote: >>> Should I make a view here instead? It looks like View.of_path does a >>> load of copying. What I want is something that I can be sure will >>> never change. >> >> When you build a view, initially it just reads the head commit. Later, when you read elements from it, it lazily fetch and cache the sub-node needed, relatively to this commit. If you never write on the view, all the reads will be relative to the head commit at the time you created the view. Views are designed for this kind of short-lived, non-persistent and isolated sequence of computations. > > How do I find out what commit the view was based on? It looks like it > just reads whatever is current for the store, which could have changed > since I checked it. > >>> Neither views nor stores can ensure this I think (both >>> can be written to). Possibly I should do the "I.of_head" inside >>> R.make, but then I'd have to give it the repo (config) and task_maker >>> objects too, which is also ugly. >> >> would be very easy to add a RO view if you think that's useful. >> >>> It seems strange, since the underlying Git model already provides >>> immutable data structures (blobs, trees, commits), but Irmin seems to >>> force me to treat everything as mutable. >> >> well, if you want to persist things you need to mutate something anyway. Exposing an immutable API to Git would be a bit cheating as pure function would need to have side-effects to create new objects in the backends (when you add an element to a tree, you need to create the intermediate sub-node in the storage substrates). But others have already expressed some interest on having immutable views (see [1]), so I'll see what I can do. >> >> Thomas >> [1] https://github.com/mirage/irmin/issues/109 > > That would be very useful! > > Even pure functions are allowed to allocate data (which can later be > GC'd), so I don't see a problem with allocating objects in the store > in the same way. I've added a somewhat functional Irmin abstraction to CueKeeper now to try this out. Here's the interface I made: https://github.com/talex5/cuekeeper/blob/master/git_storage_s.mli This doesn't provide access to all Irmin's features of course, but it shows everything I'm using and it's probably easier for beginners. The main differences are: - It uses Git terminology (repository, branch, staging area, etc) so it should be easier to understand for people used to Git. - It provides more type safey. For example, you can't try to read from a branch (which could change at any time) - you have to dereference it first to get a commit. - Branch X will always be branch X. A branch can't be switched or detached - you must create a new one instead. - The only way to update a branch is with Branch.fast_forward_to. - You make a commit by writing to a staging area, committing to get a Commit.t, then updating the branch to point to the commit. - The current branch head is provided as a signal. Hopefully some of this can go upstream. The main limitations I found (marked with XXX in the implementation) are: - The LCA calculation is slow (https://github.com/mirage/irmin/issues/160) so I used Thomas's suggestions of limiting the number of common ancestors to 1. However, this could give the wrong answer in some cases. I think Irmin just needs to be smarter about pruning the search when it finds a common node. - I couldn't find a way to make a commit without a parent without using a named branch. The special-case initialisation code could go away if Irmin allowed that. - fast_forward_to checks that the update is a fast-forward to avoid data-loss, but it's not quite atomic. Ideally, Irmin would provide this function itself and lock the backend. (Also, my history API isn't very good. I want someone with a commit to be able to look at the parents, but I didn't see a way to map a graph's nodes from commit IDs to commits. Therefore, I currently turn the history into a flat list of log entries.) -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Mar 09 10:37:07 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 09 Mar 2015 10:37:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YUv3W-0007oe-P5; Mon, 09 Mar 2015 10:37:02 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YUv3V-0007oV-HV for mirageos-devel@lists.xenproject.org; Mon, 09 Mar 2015 10:37:01 +0000 Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id 33/1E-03168-CC77DF45; Mon, 09 Mar 2015 10:37:00 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1425897418!15773418!1 X-Originating-IP: [209.85.215.54] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25025 invoked from network); 9 Mar 2015 10:36:58 -0000 Received: from mail-la0-f54.google.com (HELO mail-la0-f54.google.com) (209.85.215.54) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 Mar 2015 10:36:58 -0000 Received: by labgf13 with SMTP id gf13so45325827lab.5 for ; Mon, 09 Mar 2015 03:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=U1R1mlJ7aTdYnVBKTKFj2kDv4TBn6DwF4dfNHJYAP6I=; b=eVqoArvq+VJICWzxn8dadQ8b/Lpm5BflcCJuJK1GRklGt2lPHv2thBgbSf4uH8BITI 4OsVgwwmmyNBn40CM0gT1IVZXo+kQb7JUrLEnF5AkMyUkR2BrpKu9qfwWQe+JOsbq74g aljZOAnvk+xGqEPcnCMcdbJU2zHhKOVqPKoWy0XzUMe0TB50Lz5oBF05uVS+y64Kg5Hd 4ZhGGF3+ELQUdduHyjo/dsXP1/DNbScpxGmcCvsGnAlXyBybsR6qHIRJ/oNoH0WKV192 neAq7F0Ou0AHRRw0iJEYNC73EaYHAI0RoEeMPUtdUvK6XVBsHGaD7essaf8wC2bOVEGR BzRg== MIME-Version: 1.0 X-Received: by 10.152.20.201 with SMTP id p9mr24829186lae.50.1425897417904; Mon, 09 Mar 2015 03:36:57 -0700 (PDT) Received: by 10.25.207.17 with HTTP; Mon, 9 Mar 2015 03:36:57 -0700 (PDT) In-Reply-To: References: <8CEDB416-6238-4888-BA4B-B7305FDDE2D9@gazagnaire.org> <9349273A-0BB4-40C4-BF06-4307085AA90C@recoil.org> <47D39FA3-050E-46E6-89D2-4253484E24A8@gazagnaire.org> Date: Mon, 9 Mar 2015 10:36:57 +0000 Message-ID: From: Thomas Leonard To: Thomas Gazagnaire Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Irmin API newbie questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 7 March 2015 at 10:49, Thomas Leonard wrote: > On 5 March 2015 at 14:15, Thomas Gazagnaire wrote: >>> Should I make a view here instead? It looks like View.of_path does a >>> load of copying. What I want is something that I can be sure will >>> never change. >> >> When you build a view, initially it just reads the head commit. Later, when you read elements from it, it lazily fetch and cache the sub-node needed, relatively to this commit. If you never write on the view, all the reads will be relative to the head commit at the time you created the view. Views are designed for this kind of short-lived, non-persistent and isolated sequence of computations. > > How do I find out what commit the view was based on? It looks like it > just reads whatever is current for the store, which could have changed > since I checked it. > >>> Neither views nor stores can ensure this I think (both >>> can be written to). Possibly I should do the "I.of_head" inside >>> R.make, but then I'd have to give it the repo (config) and task_maker >>> objects too, which is also ugly. >> >> would be very easy to add a RO view if you think that's useful. >> >>> It seems strange, since the underlying Git model already provides >>> immutable data structures (blobs, trees, commits), but Irmin seems to >>> force me to treat everything as mutable. >> >> well, if you want to persist things you need to mutate something anyway. Exposing an immutable API to Git would be a bit cheating as pure function would need to have side-effects to create new objects in the backends (when you add an element to a tree, you need to create the intermediate sub-node in the storage substrates). But others have already expressed some interest on having immutable views (see [1]), so I'll see what I can do. >> >> Thomas >> [1] https://github.com/mirage/irmin/issues/109 > > That would be very useful! > > Even pure functions are allowed to allocate data (which can later be > GC'd), so I don't see a problem with allocating objects in the store > in the same way. I've added a somewhat functional Irmin abstraction to CueKeeper now to try this out. Here's the interface I made: https://github.com/talex5/cuekeeper/blob/master/git_storage_s.mli This doesn't provide access to all Irmin's features of course, but it shows everything I'm using and it's probably easier for beginners. The main differences are: - It uses Git terminology (repository, branch, staging area, etc) so it should be easier to understand for people used to Git. - It provides more type safey. For example, you can't try to read from a branch (which could change at any time) - you have to dereference it first to get a commit. - Branch X will always be branch X. A branch can't be switched or detached - you must create a new one instead. - The only way to update a branch is with Branch.fast_forward_to. - You make a commit by writing to a staging area, committing to get a Commit.t, then updating the branch to point to the commit. - The current branch head is provided as a signal. Hopefully some of this can go upstream. The main limitations I found (marked with XXX in the implementation) are: - The LCA calculation is slow (https://github.com/mirage/irmin/issues/160) so I used Thomas's suggestions of limiting the number of common ancestors to 1. However, this could give the wrong answer in some cases. I think Irmin just needs to be smarter about pruning the search when it finds a common node. - I couldn't find a way to make a commit without a parent without using a named branch. The special-case initialisation code could go away if Irmin allowed that. - fast_forward_to checks that the update is a fast-forward to avoid data-loss, but it's not quite atomic. Ideally, Irmin would provide this function itself and lock the backend. (Also, my history API isn't very good. I want someone with a commit to be able to look at the parents, but I didn't see a way to map a graph's nodes from commit IDs to commits. Therefore, I currently turn the history into a flat list of log entries.) -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Mar 09 12:06:13 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 09 Mar 2015 12:06:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YUwRk-0003vA-Iq; Mon, 09 Mar 2015 12:06:08 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YUwRj-0003v1-Dg for mirageos-devel@lists.xenproject.org; Mon, 09 Mar 2015 12:06:07 +0000 Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id 5D/CF-02898-EAC8DF45; Mon, 09 Mar 2015 12:06:06 +0000 X-Env-Sender: eireann.leverett@cantab.net X-Msg-Ref: server-7.tower-31.messagelabs.com!1425902765!14362536!1 X-Originating-IP: [72.9.247.210] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzIuOS4yNDcuMjEwID0+IDg5NTg=\n X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24889 invoked from network); 9 Mar 2015 12:06:06 -0000 Received: from jackal.aluminati.org (HELO jackal.aluminati.org) (72.9.247.210) by server-7.tower-31.messagelabs.com with SMTP; 9 Mar 2015 12:06:06 -0000 Received: from localhost (localhost [127.0.0.1]) by jackal.aluminati.org (Postfix) with ESMTP id 77239CDA5E4 for ; Mon, 9 Mar 2015 12:06:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cantab.net; h= content-transfer-encoding:in-reply-to:references:subject:subject :mime-version:user-agent:from:from:date:date:message-id:received :received; s=postfix; t=1425902765; bh=dLk05S5T+kf0LlD5A6Euhlm4f SiQKnMIc8IMWNiKBqY=; b=kpBEP7aZv7v3igmch8FhtD/NtPlsKojnSZ1BmjKXV x5BoS+B1T+o8/Otw2MnyyGcu1thWeiujUoYmIlFqy+aqTwyyhH2kSmWyDQMSMvT2 +aXPAJdrtfS3ACMKovGgrynmYDMhQ8V8Acd17YmVqReImWp+rGnOLjh8vEOmYxWh ps= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at serval.aluminati.org X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-9999 required=6.31 tests=[ALL_TRUSTED=-1, BAYES_40=-0.001] autolearn=no Received: from jackal.aluminati.org ([127.0.0.1]) by localhost (jackal.aluminati.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iAYsdDP4wtU4 for ; Mon, 9 Mar 2015 12:06:05 +0000 (GMT) Received: from [10.0.0.24] (mink.aluminati.org [10.0.7.180]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by jackal.aluminati.org (Postfix) with ESMTPSA id B2924CDA5E8 for ; Mon, 9 Mar 2015 12:05:58 +0000 (GMT) Message-ID: <54FD8CA3.7010603@cantab.net> Date: Mon, 09 Mar 2015 12:05:55 +0000 From: Eireann Leverett User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: mirageos-devel@lists.xenproject.org References: In-Reply-To: Subject: [MirageOS-devel] Anyone available to show off MirageOS tomorrow afternoon? X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am speaking to BP's security team tomorrow at and near the CL. I have a speaking slot in the afternoon if someone would like to come show them some MirageOS projects. Eireann Please reply off-list if you are interested in showing them some clean-slate thinking. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU/YyiAAoJEG6rIcA40Ve4bg8H/3iFOZOCqGJPkS0+KnTwMd+d 9vrJXVfM4roQTfuNLeIF/A4Z4VdyT6AuccEXAlPvLBoDsH7d4O3iwsBHyUD/SHAN HELLb7+hY8UVA0bry1A37lN+Mas2JRScPhIo8TIC2THAXRQrU9mQYyLes6ozyPTK jDcpx93stS+anwxI6WgkVElwviVx7MWR3XvgTxXeKQbR0zbWrgA7M/hk41pWfKy2 oskQ8luJuHC9xf//nZRQgpdFq7W+dZNoeaSnylKdmSqINw1caiQy+Nfgwx5xper1 ln4qIv/vz9GsdB/KuDCWkU1uc+lbrdQb9l3oMAjkUV3FMdwe4GVlLxFY5lWPOes= =Gq3m -----END PGP SIGNATURE----- _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Mar 09 12:06:13 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 09 Mar 2015 12:06:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YUwRk-0003vA-Iq; Mon, 09 Mar 2015 12:06:08 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YUwRj-0003v1-Dg for mirageos-devel@lists.xenproject.org; Mon, 09 Mar 2015 12:06:07 +0000 Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id 5D/CF-02898-EAC8DF45; Mon, 09 Mar 2015 12:06:06 +0000 X-Env-Sender: eireann.leverett@cantab.net X-Msg-Ref: server-7.tower-31.messagelabs.com!1425902765!14362536!1 X-Originating-IP: [72.9.247.210] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzIuOS4yNDcuMjEwID0+IDg5NTg=\n X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24889 invoked from network); 9 Mar 2015 12:06:06 -0000 Received: from jackal.aluminati.org (HELO jackal.aluminati.org) (72.9.247.210) by server-7.tower-31.messagelabs.com with SMTP; 9 Mar 2015 12:06:06 -0000 Received: from localhost (localhost [127.0.0.1]) by jackal.aluminati.org (Postfix) with ESMTP id 77239CDA5E4 for ; Mon, 9 Mar 2015 12:06:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cantab.net; h= content-transfer-encoding:in-reply-to:references:subject:subject :mime-version:user-agent:from:from:date:date:message-id:received :received; s=postfix; t=1425902765; bh=dLk05S5T+kf0LlD5A6Euhlm4f SiQKnMIc8IMWNiKBqY=; b=kpBEP7aZv7v3igmch8FhtD/NtPlsKojnSZ1BmjKXV x5BoS+B1T+o8/Otw2MnyyGcu1thWeiujUoYmIlFqy+aqTwyyhH2kSmWyDQMSMvT2 +aXPAJdrtfS3ACMKovGgrynmYDMhQ8V8Acd17YmVqReImWp+rGnOLjh8vEOmYxWh ps= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at serval.aluminati.org X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-9999 required=6.31 tests=[ALL_TRUSTED=-1, BAYES_40=-0.001] autolearn=no Received: from jackal.aluminati.org ([127.0.0.1]) by localhost (jackal.aluminati.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iAYsdDP4wtU4 for ; Mon, 9 Mar 2015 12:06:05 +0000 (GMT) Received: from [10.0.0.24] (mink.aluminati.org [10.0.7.180]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by jackal.aluminati.org (Postfix) with ESMTPSA id B2924CDA5E8 for ; Mon, 9 Mar 2015 12:05:58 +0000 (GMT) Message-ID: <54FD8CA3.7010603@cantab.net> Date: Mon, 09 Mar 2015 12:05:55 +0000 From: Eireann Leverett User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: mirageos-devel@lists.xenproject.org References: In-Reply-To: Subject: [MirageOS-devel] Anyone available to show off MirageOS tomorrow afternoon? X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am speaking to BP's security team tomorrow at and near the CL. I have a speaking slot in the afternoon if someone would like to come show them some MirageOS projects. Eireann Please reply off-list if you are interested in showing them some clean-slate thinking. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU/YyiAAoJEG6rIcA40Ve4bg8H/3iFOZOCqGJPkS0+KnTwMd+d 9vrJXVfM4roQTfuNLeIF/A4Z4VdyT6AuccEXAlPvLBoDsH7d4O3iwsBHyUD/SHAN HELLb7+hY8UVA0bry1A37lN+Mas2JRScPhIo8TIC2THAXRQrU9mQYyLes6ozyPTK jDcpx93stS+anwxI6WgkVElwviVx7MWR3XvgTxXeKQbR0zbWrgA7M/hk41pWfKy2 oskQ8luJuHC9xf//nZRQgpdFq7W+dZNoeaSnylKdmSqINw1caiQy+Nfgwx5xper1 ln4qIv/vz9GsdB/KuDCWkU1uc+lbrdQb9l3oMAjkUV3FMdwe4GVlLxFY5lWPOes= =Gq3m -----END PGP SIGNATURE----- _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Mar 09 18:49:19 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 09 Mar 2015 18:49:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YV2jo-0003XT-PZ; Mon, 09 Mar 2015 18:49:12 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YV2jn-0003Wp-7L for mirageos-devel@lists.xenproject.org; Mon, 09 Mar 2015 18:49:11 +0000 Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id B9/98-02994-62BEDF45; Mon, 09 Mar 2015 18:49:10 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1425926949!11323126!1 X-Originating-IP: [74.125.82.170] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8090 invoked from network); 9 Mar 2015 18:49:09 -0000 Received: from mail-we0-f170.google.com (HELO mail-we0-f170.google.com) (74.125.82.170) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 Mar 2015 18:49:09 -0000 Received: by wesw62 with SMTP id w62so14635873wes.0 for ; Mon, 09 Mar 2015 11:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=bhuHiZY+NF9y/vobhCqM57GflSIc91lEAp4C7lT/f1g=; b=R1yEEB3SjszzDonIby9MwFZml6+Oy3/nu9eCyutaQTHE3RDp0eddh7dlUYioC7c8RP 2hWX8Vx9bB+CUaINuZONQdmN6uy8Cpg92Iygo7VD2MgIbVfMxPHRSdb2d+c+cHXERG9B oyzJS3fglLoVvgYIZRDA2cUBxErlFzGYIwMsrabPlmFsmoJoqjBZ4lZy9D/CYpxvXrc2 3/Mn8EqXeipwjZQ7JdaNHSXJLv/L9wPPlR+tuDCtvixxDWHdcRvVQJGx46EPD060YQEB g0C99pNrLM8Hhi39G8BZOJVMrH2ZHl8+ftbgNzym8TSFrQw44a4BTYdQi3f/jfuKrTYa cixg== X-Received: by 10.194.48.12 with SMTP id h12mr62305932wjn.74.1425926948823; Mon, 09 Mar 2015 11:49:08 -0700 (PDT) Received: from ?IPv6:2001:630:212:248:b4a4:15d2:13ff:f570? ([2001:630:212:248:b4a4:15d2:13ff:f570]) by mx.google.com with ESMTPSA id uc18sm395288wib.0.2015.03.09.11.49.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Mar 2015 11:49:07 -0700 (PDT) From: Thomas Gazagnaire Message-Id: <2D96F8FE-7C90-4D8C-ACD0-75E131BE0E80@gazagnaire.org> Date: Mon, 9 Mar 2015 18:49:06 +0000 To: mirageos-devel Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Subject: [MirageOS-devel] irmin updates X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi all, Just a quick update on Irmin: I've created https://github.com/mirage/irmin/wiki/Roadmap to keep track of the missing bits before the 1.0 release. I'll use that to document progress on Irmin, and use it to structure my next updates on the list. A summary of what happened in the last weeks: ## Portability Summary: both Javascript and Xen ports are making good progress (basically they both have forks which works fine). Need upstreaming efforts now. - Javascript: Thomas Leonard managed to get a simple Irmin backend working on HTML5 local storage[1]. Need to make the SHA1 computation and the zlib compression a bit more modular in ocaml-git to be able to switch to pure OCaml implementation when available. - Xen: I managed to "git clone" from a Mirage unikernel[2]. Few patches to upstream in conduit and cohttp, should be done hopefully soon. - I've started a preliminary work on implementing of pure version of zlib in OCaml: I've played with Huffman codes[3] and LZ77[4]. These are needed for the related pioneer project[5] which is still looking for a volunteer (I don't plan to work much more on that on the next couple of weeks). This could help both the Javascript and the Xen port (but this is not in the critical path). ## Applications - I've updated the merge-queues[6] to the new API. Was not as easy at it should be, because of some missing functors in mirage-tc for Either. ## API Now that I have a very rough end-to-end demonstration of irmin+mirage, my current focus are (i) to upstream the changes to make it easier to deploy Irmin on top of Mirage and (ii) to fix the bugs that ThomasL found out while developing his application and improve parts of the API related to notification and high-level concurrency. Best, Thomas [1] https://github.com/talex5/cuekeeper [2] https://github.com/samoht/mirmin [3] https://github.com/samoht/ocaml-huffman-code [4] https://github.com/samoht/ocaml-lz77 [5] https://github.com/mirage/mirage-www/wiki/Pioneer-Projects#deflate-zlib-in-pure-ocaml [6] https://github.com/mirage/merge-queues/pull/5 _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Mar 09 18:49:19 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 09 Mar 2015 18:49:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YV2jo-0003XT-PZ; Mon, 09 Mar 2015 18:49:12 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YV2jn-0003Wp-7L for mirageos-devel@lists.xenproject.org; Mon, 09 Mar 2015 18:49:11 +0000 Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id B9/98-02994-62BEDF45; Mon, 09 Mar 2015 18:49:10 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1425926949!11323126!1 X-Originating-IP: [74.125.82.170] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8090 invoked from network); 9 Mar 2015 18:49:09 -0000 Received: from mail-we0-f170.google.com (HELO mail-we0-f170.google.com) (74.125.82.170) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 Mar 2015 18:49:09 -0000 Received: by wesw62 with SMTP id w62so14635873wes.0 for ; Mon, 09 Mar 2015 11:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=bhuHiZY+NF9y/vobhCqM57GflSIc91lEAp4C7lT/f1g=; b=R1yEEB3SjszzDonIby9MwFZml6+Oy3/nu9eCyutaQTHE3RDp0eddh7dlUYioC7c8RP 2hWX8Vx9bB+CUaINuZONQdmN6uy8Cpg92Iygo7VD2MgIbVfMxPHRSdb2d+c+cHXERG9B oyzJS3fglLoVvgYIZRDA2cUBxErlFzGYIwMsrabPlmFsmoJoqjBZ4lZy9D/CYpxvXrc2 3/Mn8EqXeipwjZQ7JdaNHSXJLv/L9wPPlR+tuDCtvixxDWHdcRvVQJGx46EPD060YQEB g0C99pNrLM8Hhi39G8BZOJVMrH2ZHl8+ftbgNzym8TSFrQw44a4BTYdQi3f/jfuKrTYa cixg== X-Received: by 10.194.48.12 with SMTP id h12mr62305932wjn.74.1425926948823; Mon, 09 Mar 2015 11:49:08 -0700 (PDT) Received: from ?IPv6:2001:630:212:248:b4a4:15d2:13ff:f570? ([2001:630:212:248:b4a4:15d2:13ff:f570]) by mx.google.com with ESMTPSA id uc18sm395288wib.0.2015.03.09.11.49.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Mar 2015 11:49:07 -0700 (PDT) From: Thomas Gazagnaire Message-Id: <2D96F8FE-7C90-4D8C-ACD0-75E131BE0E80@gazagnaire.org> Date: Mon, 9 Mar 2015 18:49:06 +0000 To: mirageos-devel Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Subject: [MirageOS-devel] irmin updates X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi all, Just a quick update on Irmin: I've created https://github.com/mirage/irmin/wiki/Roadmap to keep track of the missing bits before the 1.0 release. I'll use that to document progress on Irmin, and use it to structure my next updates on the list. A summary of what happened in the last weeks: ## Portability Summary: both Javascript and Xen ports are making good progress (basically they both have forks which works fine). Need upstreaming efforts now. - Javascript: Thomas Leonard managed to get a simple Irmin backend working on HTML5 local storage[1]. Need to make the SHA1 computation and the zlib compression a bit more modular in ocaml-git to be able to switch to pure OCaml implementation when available. - Xen: I managed to "git clone" from a Mirage unikernel[2]. Few patches to upstream in conduit and cohttp, should be done hopefully soon. - I've started a preliminary work on implementing of pure version of zlib in OCaml: I've played with Huffman codes[3] and LZ77[4]. These are needed for the related pioneer project[5] which is still looking for a volunteer (I don't plan to work much more on that on the next couple of weeks). This could help both the Javascript and the Xen port (but this is not in the critical path). ## Applications - I've updated the merge-queues[6] to the new API. Was not as easy at it should be, because of some missing functors in mirage-tc for Either. ## API Now that I have a very rough end-to-end demonstration of irmin+mirage, my current focus are (i) to upstream the changes to make it easier to deploy Irmin on top of Mirage and (ii) to fix the bugs that ThomasL found out while developing his application and improve parts of the API related to notification and high-level concurrency. Best, Thomas [1] https://github.com/talex5/cuekeeper [2] https://github.com/samoht/mirmin [3] https://github.com/samoht/ocaml-huffman-code [4] https://github.com/samoht/ocaml-lz77 [5] https://github.com/mirage/mirage-www/wiki/Pioneer-Projects#deflate-zlib-in-pure-ocaml [6] https://github.com/mirage/merge-queues/pull/5 _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Mar 09 23:44:34 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 09 Mar 2015 23:44:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YV7LY-0005UF-HJ; Mon, 09 Mar 2015 23:44:28 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YV7LW-0005UA-UJ for mirageos-devel@lists.xenproject.org; Mon, 09 Mar 2015 23:44:27 +0000 Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id 5B/FC-02745-9503EF45; Mon, 09 Mar 2015 23:44:25 +0000 X-Env-Sender: amc79@cam.ac.uk X-Msg-Ref: server-14.tower-31.messagelabs.com!1425944665!12132806!1 X-Originating-IP: [131.111.8.152] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MiA9PiA4MDU1Mw==\n X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15524 invoked from network); 9 Mar 2015 23:44:25 -0000 Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk) (131.111.8.152) by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Mar 2015 23:44:25 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cpc17-cmbg14-2-0-cust360.5-4.cable.virginm.net ([86.6.155.105]:64830 helo=[192.168.0.23]) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587) with esmtpsa (PLAIN:amc79) (TLSv1:AES128-SHA:128) id 1YV7LV-0001xG-D8 (Exim 4.82_3-c0e5623) for mirageos-devel@lists.xenproject.org (return-path ); Mon, 09 Mar 2015 23:44:25 +0000 From: Amir Chaudhry Message-Id: <66CC2001-AAB4-4922-B816-4489FD891B96@cam.ac.uk> Date: Mon, 9 Mar 2015 23:44:24 +0000 To: mirageos-devel Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [MirageOS-devel] blobs.openmirage.org is down X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org http://blobs.openmirage.org is down. Not sure if it's related to the recent openmirage.org issues. I happen to have an old image I can be getting on with, though I see that the new ones should have Xapi (I don't have Ubuntu or Dabian machines handy so can't use xen-arm-builder [1] directly) [1] https://github.com/mirage/xen-arm-builder Amir _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Mar 09 23:44:34 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 09 Mar 2015 23:44:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YV7LY-0005UF-HJ; Mon, 09 Mar 2015 23:44:28 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YV7LW-0005UA-UJ for mirageos-devel@lists.xenproject.org; Mon, 09 Mar 2015 23:44:27 +0000 Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id 5B/FC-02745-9503EF45; Mon, 09 Mar 2015 23:44:25 +0000 X-Env-Sender: amc79@cam.ac.uk X-Msg-Ref: server-14.tower-31.messagelabs.com!1425944665!12132806!1 X-Originating-IP: [131.111.8.152] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MiA9PiA4MDU1Mw==\n X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15524 invoked from network); 9 Mar 2015 23:44:25 -0000 Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk) (131.111.8.152) by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Mar 2015 23:44:25 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cpc17-cmbg14-2-0-cust360.5-4.cable.virginm.net ([86.6.155.105]:64830 helo=[192.168.0.23]) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587) with esmtpsa (PLAIN:amc79) (TLSv1:AES128-SHA:128) id 1YV7LV-0001xG-D8 (Exim 4.82_3-c0e5623) for mirageos-devel@lists.xenproject.org (return-path ); Mon, 09 Mar 2015 23:44:25 +0000 From: Amir Chaudhry Message-Id: <66CC2001-AAB4-4922-B816-4489FD891B96@cam.ac.uk> Date: Mon, 9 Mar 2015 23:44:24 +0000 To: mirageos-devel Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [MirageOS-devel] blobs.openmirage.org is down X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org http://blobs.openmirage.org is down. Not sure if it's related to the recent openmirage.org issues. I happen to have an old image I can be getting on with, though I see that the new ones should have Xapi (I don't have Ubuntu or Dabian machines handy so can't use xen-arm-builder [1] directly) [1] https://github.com/mirage/xen-arm-builder Amir _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Mar 10 11:01:24 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 10 Mar 2015 11:01:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVHuW-00074c-Nn; Tue, 10 Mar 2015 11:01:16 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVHuV-00074X-63 for mirageos-devel@lists.xenproject.org; Tue, 10 Mar 2015 11:01:15 +0000 Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id E9/A0-03168-9FECEF45; Tue, 10 Mar 2015 11:01:13 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1425985271!16131917!1 X-Originating-IP: [209.85.217.172] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25452 invoked from network); 10 Mar 2015 11:01:11 -0000 Received: from mail-lb0-f172.google.com (HELO mail-lb0-f172.google.com) (209.85.217.172) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 Mar 2015 11:01:11 -0000 Received: by lbvn10 with SMTP id n10so836041lbv.1 for ; Tue, 10 Mar 2015 04:01:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=j11/Gc4nHNQ52Ecarz6+CkgeXZbdYU4GV/8Tg+O81iY=; b=DzN3ErY8BeI8jcr6MekhsY57wE/vB3MWrzZodJbfkcOc38zh0wET+dXtpsJGzf7xxC zluafwFGg+s2BH0RLNnMNtDcBhChr8K07qcbeuEoAHJUIa++yrv2r95SLCHF1DuQQ9i3 je0ukOQdWGUWmAy8GLdcFhQESCrSy6bfH8oCbMFw8vVxd/lsef+JBXzLMi4OIVuQVm4j KpgPvI/mvI15J0rxGpJEjXFggW6hnRQarVArAndHOQU7fhAQ8Cb5Q0BP04aMyXuj45BR L4FNtNhc4PPeby5EXKqMq60bg7gMmJ5fAexlxBQbhOua52dsWBVKiNVqV0mrsNLK9F39 5LEA== MIME-Version: 1.0 X-Received: by 10.152.88.1 with SMTP id bc1mr1577629lab.20.1425985270567; Tue, 10 Mar 2015 04:01:10 -0700 (PDT) Received: by 10.25.207.17 with HTTP; Tue, 10 Mar 2015 04:01:10 -0700 (PDT) Date: Tue, 10 Mar 2015 11:01:10 +0000 Message-ID: From: Thomas Leonard To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] Merging in Irmin X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Irmin lets me provide a merge function for individual keys: val merge: Path.t -> t option Merge.t Is there any way to merge whole commits? Each of my commits is a collection of files, but files can refer to each other. For example, I might start with a single file representing a project: - Test CueKeeper On one branch, I delete this. On another, I add an action so that I have two files: - Test CueKeeper - Test on IE (parent: Test CueKeeper) When merged, the result needs to include the parent, even though it was deleted in one branch and not touched in the other. Can I do this? -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Mar 10 11:01:24 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 10 Mar 2015 11:01:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVHuW-00074c-Nn; Tue, 10 Mar 2015 11:01:16 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVHuV-00074X-63 for mirageos-devel@lists.xenproject.org; Tue, 10 Mar 2015 11:01:15 +0000 Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id E9/A0-03168-9FECEF45; Tue, 10 Mar 2015 11:01:13 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1425985271!16131917!1 X-Originating-IP: [209.85.217.172] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25452 invoked from network); 10 Mar 2015 11:01:11 -0000 Received: from mail-lb0-f172.google.com (HELO mail-lb0-f172.google.com) (209.85.217.172) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 Mar 2015 11:01:11 -0000 Received: by lbvn10 with SMTP id n10so836041lbv.1 for ; Tue, 10 Mar 2015 04:01:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=j11/Gc4nHNQ52Ecarz6+CkgeXZbdYU4GV/8Tg+O81iY=; b=DzN3ErY8BeI8jcr6MekhsY57wE/vB3MWrzZodJbfkcOc38zh0wET+dXtpsJGzf7xxC zluafwFGg+s2BH0RLNnMNtDcBhChr8K07qcbeuEoAHJUIa++yrv2r95SLCHF1DuQQ9i3 je0ukOQdWGUWmAy8GLdcFhQESCrSy6bfH8oCbMFw8vVxd/lsef+JBXzLMi4OIVuQVm4j KpgPvI/mvI15J0rxGpJEjXFggW6hnRQarVArAndHOQU7fhAQ8Cb5Q0BP04aMyXuj45BR L4FNtNhc4PPeby5EXKqMq60bg7gMmJ5fAexlxBQbhOua52dsWBVKiNVqV0mrsNLK9F39 5LEA== MIME-Version: 1.0 X-Received: by 10.152.88.1 with SMTP id bc1mr1577629lab.20.1425985270567; Tue, 10 Mar 2015 04:01:10 -0700 (PDT) Received: by 10.25.207.17 with HTTP; Tue, 10 Mar 2015 04:01:10 -0700 (PDT) Date: Tue, 10 Mar 2015 11:01:10 +0000 Message-ID: From: Thomas Leonard To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] Merging in Irmin X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Irmin lets me provide a merge function for individual keys: val merge: Path.t -> t option Merge.t Is there any way to merge whole commits? Each of my commits is a collection of files, but files can refer to each other. For example, I might start with a single file representing a project: - Test CueKeeper On one branch, I delete this. On another, I add an action so that I have two files: - Test CueKeeper - Test on IE (parent: Test CueKeeper) When merged, the result needs to include the parent, even though it was deleted in one branch and not touched in the other. Can I do this? -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Mar 10 11:52:09 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 10 Mar 2015 11:52:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVIhj-0004ew-N8; Tue, 10 Mar 2015 11:52:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVIhi-0004er-Dm for mirageos-devel@lists.xenproject.org; Tue, 10 Mar 2015 11:52:06 +0000 Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id 12/EC-03163-5EADEF45; Tue, 10 Mar 2015 11:52:05 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-3.tower-31.messagelabs.com!1425988324!14778794!1 X-Originating-IP: [209.85.212.176] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21827 invoked from network); 10 Mar 2015 11:52:04 -0000 Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com) (209.85.212.176) by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 10 Mar 2015 11:52:04 -0000 Received: by widem10 with SMTP id em10so14729565wid.2 for ; Tue, 10 Mar 2015 04:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BV9KFVyoerVZY8BmXc99gTZntiVnogTIeJIQbHvdeu8=; b=zrv1LRh2xkMBz7kz+b4NL/VLIJsw0eOY14nHNJpgFJdRBv9zxrl2QVDOvS06tGwUzw nCK35V18GmXkbGeUEVeNwXPpkWBmcefIEspqby5Siij78XhpkQtnWRpcE5a2N0HrP2N8 lwn+fJsHuPlfoEYzUX24FOoCONGvmYpcIs/o603oCtDN49Fkypzy7Z01RVzTO14pzh6H YPfJxEq2Qf0KfhEJsj4U9RcgBlhutJXRihTCoEvq7wK+d6UJoZGzsg1QmQaYvts6cjHO 6oyawqFaSOtfQOrWEpj/JnrtM1ozelhrRGflhxrPZeFmQqoOUvfOjFBF0Zl3hgFa5HWe KIGQ== X-Received: by 10.180.77.166 with SMTP id t6mr7345352wiw.52.1425988322881; Tue, 10 Mar 2015 04:52:02 -0700 (PDT) Received: from [192.168.0.2] (cpc25-cmbg14-2-0-cust121.5-4.cable.virginm.net. [213.106.112.122]) by mx.google.com with ESMTPSA id dm6sm1218327wib.22.2015.03.10.04.52.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Mar 2015 04:52:02 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Thomas Gazagnaire In-Reply-To: Date: Tue, 10 Mar 2015 11:52:00 +0000 Message-Id: <53DA75E3-EE46-4107-8CDC-EEBFE5D51F45@gazagnaire.org> References: To: Thomas Leonard X-Mailer: Apple Mail (2.2070.6) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Merging in Irmin X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org > When merged, the result needs to include the parent, even though it > was deleted in one branch and not touched in the other. Can I do this? Do you mean you want to control which are the parents of a commit you are creating, even if the respective contents are not related? You can manually create a commit by using Irmin.Private.Commit.create[1] and save it in the (private) block store with S.Private.Commit.add[2] Not sure how to expose that nicely to the user though... maybe allowing to specify a "parent" optional argument to merge/update/rebase. Thomas [1] http://mirage.github.io/irmin/Irmin.Private.Commit.S.html#VALcreate [2] http://mirage.github.io/irmin/Irmin.Private.S.html > > > -- > Dr Thomas Leonard http://0install.net/ > GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 > GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Mar 10 11:52:09 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 10 Mar 2015 11:52:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVIhj-0004ew-N8; Tue, 10 Mar 2015 11:52:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVIhi-0004er-Dm for mirageos-devel@lists.xenproject.org; Tue, 10 Mar 2015 11:52:06 +0000 Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id 12/EC-03163-5EADEF45; Tue, 10 Mar 2015 11:52:05 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-3.tower-31.messagelabs.com!1425988324!14778794!1 X-Originating-IP: [209.85.212.176] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21827 invoked from network); 10 Mar 2015 11:52:04 -0000 Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com) (209.85.212.176) by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 10 Mar 2015 11:52:04 -0000 Received: by widem10 with SMTP id em10so14729565wid.2 for ; Tue, 10 Mar 2015 04:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BV9KFVyoerVZY8BmXc99gTZntiVnogTIeJIQbHvdeu8=; b=zrv1LRh2xkMBz7kz+b4NL/VLIJsw0eOY14nHNJpgFJdRBv9zxrl2QVDOvS06tGwUzw nCK35V18GmXkbGeUEVeNwXPpkWBmcefIEspqby5Siij78XhpkQtnWRpcE5a2N0HrP2N8 lwn+fJsHuPlfoEYzUX24FOoCONGvmYpcIs/o603oCtDN49Fkypzy7Z01RVzTO14pzh6H YPfJxEq2Qf0KfhEJsj4U9RcgBlhutJXRihTCoEvq7wK+d6UJoZGzsg1QmQaYvts6cjHO 6oyawqFaSOtfQOrWEpj/JnrtM1ozelhrRGflhxrPZeFmQqoOUvfOjFBF0Zl3hgFa5HWe KIGQ== X-Received: by 10.180.77.166 with SMTP id t6mr7345352wiw.52.1425988322881; Tue, 10 Mar 2015 04:52:02 -0700 (PDT) Received: from [192.168.0.2] (cpc25-cmbg14-2-0-cust121.5-4.cable.virginm.net. [213.106.112.122]) by mx.google.com with ESMTPSA id dm6sm1218327wib.22.2015.03.10.04.52.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Mar 2015 04:52:02 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Thomas Gazagnaire In-Reply-To: Date: Tue, 10 Mar 2015 11:52:00 +0000 Message-Id: <53DA75E3-EE46-4107-8CDC-EEBFE5D51F45@gazagnaire.org> References: To: Thomas Leonard X-Mailer: Apple Mail (2.2070.6) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Merging in Irmin X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org > When merged, the result needs to include the parent, even though it > was deleted in one branch and not touched in the other. Can I do this? Do you mean you want to control which are the parents of a commit you are creating, even if the respective contents are not related? You can manually create a commit by using Irmin.Private.Commit.create[1] and save it in the (private) block store with S.Private.Commit.add[2] Not sure how to expose that nicely to the user though... maybe allowing to specify a "parent" optional argument to merge/update/rebase. Thomas [1] http://mirage.github.io/irmin/Irmin.Private.Commit.S.html#VALcreate [2] http://mirage.github.io/irmin/Irmin.Private.S.html > > > -- > Dr Thomas Leonard http://0install.net/ > GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 > GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Mar 10 12:07:26 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 10 Mar 2015 12:07:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVIwT-0007nk-Lx; Tue, 10 Mar 2015 12:07:21 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVIwR-0007nL-Nc for mirageos-devel@lists.xenproject.org; Tue, 10 Mar 2015 12:07:19 +0000 Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id 93/1D-31919-67EDEF45; Tue, 10 Mar 2015 12:07:18 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1425989237!16119449!1 X-Originating-IP: [74.125.82.182] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4829 invoked from network); 10 Mar 2015 12:07:17 -0000 Received: from mail-we0-f182.google.com (HELO mail-we0-f182.google.com) (74.125.82.182) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 Mar 2015 12:07:17 -0000 Received: by wevl61 with SMTP id l61so1273217wev.6 for ; Tue, 10 Mar 2015 05:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q3W47aXYvYzn7udwHyHUc/LOHtG0lHY+FbbCKX6uPl0=; b=LErtsVgg1pYao8CI6NM4PAn2/J+FiUB2pT1awOMAHoJij5QSAKjwoF4Pq9k2p/9n2B /lKJD6DkbZCsaiGw9mWWIOMZ8fyKKgUVuPcFLKEBOOr0nZDGczmt4ta0/Ye15sK64JYu MtlEzcXJ8VwrkmuPejQKEVM0s0QXxGqo/Fn8FVDcYb1SQjT++GpNstv7AUZJSM5L1cC/ DzG3RCq9lmPWYubdHeU+4GbFUmwTS/9wUryoWITrUBEhmUZWmzv1guUrEXULm98fV30X mG04NP1QuSEelPYeVTvulRSA/MhwdbXkIAByapekEiwjeSD/FqaYncWOnL1TDsZebkIU 5sMA== X-Received: by 10.194.200.166 with SMTP id jt6mr23612411wjc.66.1425989233804; Tue, 10 Mar 2015 05:07:13 -0700 (PDT) Received: from [192.168.0.2] (cpc25-cmbg14-2-0-cust121.5-4.cable.virginm.net. [213.106.112.122]) by mx.google.com with ESMTPSA id 17sm554552wjt.45.2015.03.10.05.07.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Mar 2015 05:07:13 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Thomas Gazagnaire In-Reply-To: Date: Tue, 10 Mar 2015 12:07:11 +0000 Message-Id: <1C9E611F-D1EB-4865-9961-7C5042D8AA76@gazagnaire.org> References: <8CEDB416-6238-4888-BA4B-B7305FDDE2D9@gazagnaire.org> <9349273A-0BB4-40C4-BF06-4307085AA90C@recoil.org> <47D39FA3-050E-46E6-89D2-4253484E24A8@gazagnaire.org> To: Thomas Leonard X-Mailer: Apple Mail (2.2070.6) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Irmin API newbie questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org > I've added a somewhat functional Irmin abstraction to CueKeeper now to > try this out. Here's the interface I made: > > https://github.com/talex5/cuekeeper/blob/master/git_storage_s.mli > > This doesn't provide access to all Irmin's features of course, but it > shows everything I'm using and it's probably easier for beginners. The > main differences are: Very interesting. I'm wondering which part of the Irmin public API is already too complex to expose to the user, and what should be refactor to look much like your Git-like interface. I'll think about it. I quite like your simplified interface ... > - The LCA calculation is slow > (https://github.com/mirage/irmin/issues/160) so I used Thomas's > suggestions of limiting the number of common ancestors to 1. However, > this could give the wrong answer in some cases. I think Irmin just > needs to be smarter about pruning the search when it finds a common > node. my plan is to add a way 1) to detect fast-forward and stop the exploration much more quicker in that case and 2) use timestamps to guide the explorations (or even provide a timestamp optional flag to guide the exploration only using the timestamps as Git is doing -- this would break in some cases so it would not be the default). > - I couldn't find a way to make a commit without a parent without > using a named branch. The special-case initialisation code could go > away if Irmin allowed that. I'll fix that.[1] > - fast_forward_to checks that the update is a fast-forward to avoid > data-loss, but it's not quite atomic. Ideally, Irmin would provide > this function itself and lock the backend. I guess you don't need this function if `merge` is doing the right job. I'm fixing this. > (Also, my history API isn't very good. I want someone with a commit to > be able to look at the parents, but I didn't see a way to map a > graph's nodes from commit IDs to commits. Therefore, I currently turn > the history into a flat list of log entries.) This history graph gives you a graph of commits ID. You can then use Imrin.History.pred[2] (in the OCamlGraph API) to get the predecessors (the parents) of a node. Best, Thomas [1] https://github.com/mirage/irmin/issues/161 [2] http://ocamlgraph.lri.fr/doc/Sig.G.html#VALpred > > > -- > Dr Thomas Leonard http://0install.net/ > GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 > GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Mar 10 12:07:26 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 10 Mar 2015 12:07:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVIwT-0007nk-Lx; Tue, 10 Mar 2015 12:07:21 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVIwR-0007nL-Nc for mirageos-devel@lists.xenproject.org; Tue, 10 Mar 2015 12:07:19 +0000 Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id 93/1D-31919-67EDEF45; Tue, 10 Mar 2015 12:07:18 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1425989237!16119449!1 X-Originating-IP: [74.125.82.182] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4829 invoked from network); 10 Mar 2015 12:07:17 -0000 Received: from mail-we0-f182.google.com (HELO mail-we0-f182.google.com) (74.125.82.182) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 Mar 2015 12:07:17 -0000 Received: by wevl61 with SMTP id l61so1273217wev.6 for ; Tue, 10 Mar 2015 05:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q3W47aXYvYzn7udwHyHUc/LOHtG0lHY+FbbCKX6uPl0=; b=LErtsVgg1pYao8CI6NM4PAn2/J+FiUB2pT1awOMAHoJij5QSAKjwoF4Pq9k2p/9n2B /lKJD6DkbZCsaiGw9mWWIOMZ8fyKKgUVuPcFLKEBOOr0nZDGczmt4ta0/Ye15sK64JYu MtlEzcXJ8VwrkmuPejQKEVM0s0QXxGqo/Fn8FVDcYb1SQjT++GpNstv7AUZJSM5L1cC/ DzG3RCq9lmPWYubdHeU+4GbFUmwTS/9wUryoWITrUBEhmUZWmzv1guUrEXULm98fV30X mG04NP1QuSEelPYeVTvulRSA/MhwdbXkIAByapekEiwjeSD/FqaYncWOnL1TDsZebkIU 5sMA== X-Received: by 10.194.200.166 with SMTP id jt6mr23612411wjc.66.1425989233804; Tue, 10 Mar 2015 05:07:13 -0700 (PDT) Received: from [192.168.0.2] (cpc25-cmbg14-2-0-cust121.5-4.cable.virginm.net. [213.106.112.122]) by mx.google.com with ESMTPSA id 17sm554552wjt.45.2015.03.10.05.07.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Mar 2015 05:07:13 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Thomas Gazagnaire In-Reply-To: Date: Tue, 10 Mar 2015 12:07:11 +0000 Message-Id: <1C9E611F-D1EB-4865-9961-7C5042D8AA76@gazagnaire.org> References: <8CEDB416-6238-4888-BA4B-B7305FDDE2D9@gazagnaire.org> <9349273A-0BB4-40C4-BF06-4307085AA90C@recoil.org> <47D39FA3-050E-46E6-89D2-4253484E24A8@gazagnaire.org> To: Thomas Leonard X-Mailer: Apple Mail (2.2070.6) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Irmin API newbie questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org > I've added a somewhat functional Irmin abstraction to CueKeeper now to > try this out. Here's the interface I made: > > https://github.com/talex5/cuekeeper/blob/master/git_storage_s.mli > > This doesn't provide access to all Irmin's features of course, but it > shows everything I'm using and it's probably easier for beginners. The > main differences are: Very interesting. I'm wondering which part of the Irmin public API is already too complex to expose to the user, and what should be refactor to look much like your Git-like interface. I'll think about it. I quite like your simplified interface ... > - The LCA calculation is slow > (https://github.com/mirage/irmin/issues/160) so I used Thomas's > suggestions of limiting the number of common ancestors to 1. However, > this could give the wrong answer in some cases. I think Irmin just > needs to be smarter about pruning the search when it finds a common > node. my plan is to add a way 1) to detect fast-forward and stop the exploration much more quicker in that case and 2) use timestamps to guide the explorations (or even provide a timestamp optional flag to guide the exploration only using the timestamps as Git is doing -- this would break in some cases so it would not be the default). > - I couldn't find a way to make a commit without a parent without > using a named branch. The special-case initialisation code could go > away if Irmin allowed that. I'll fix that.[1] > - fast_forward_to checks that the update is a fast-forward to avoid > data-loss, but it's not quite atomic. Ideally, Irmin would provide > this function itself and lock the backend. I guess you don't need this function if `merge` is doing the right job. I'm fixing this. > (Also, my history API isn't very good. I want someone with a commit to > be able to look at the parents, but I didn't see a way to map a > graph's nodes from commit IDs to commits. Therefore, I currently turn > the history into a flat list of log entries.) This history graph gives you a graph of commits ID. You can then use Imrin.History.pred[2] (in the OCamlGraph API) to get the predecessors (the parents) of a node. Best, Thomas [1] https://github.com/mirage/irmin/issues/161 [2] http://ocamlgraph.lri.fr/doc/Sig.G.html#VALpred > > > -- > Dr Thomas Leonard http://0install.net/ > GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 > GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Mar 10 12:14:53 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 10 Mar 2015 12:14:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVJ3j-0000pi-MQ; Tue, 10 Mar 2015 12:14:51 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVJ3i-0000pS-9z for mirageos-devel@lists.xenproject.org; Tue, 10 Mar 2015 12:14:50 +0000 Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id BB/9D-02753-930EEF45; Tue, 10 Mar 2015 12:14:49 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1425989686!16051167!1 X-Originating-IP: [74.125.82.172] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25476 invoked from network); 10 Mar 2015 12:14:47 -0000 Received: from mail-we0-f172.google.com (HELO mail-we0-f172.google.com) (74.125.82.172) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 Mar 2015 12:14:47 -0000 Received: by wevl61 with SMTP id l61so1319794wev.6 for ; Tue, 10 Mar 2015 05:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pq1EJvRtiE8uz//Lfiv6eks/MosotrdiVW+W83mx/UM=; b=MC9HZjLnCIN5ZWqVsJGEWebyidSkyXaz6qNVkUA8lV2zVlR2DsyeSUQj0aU3Vn7xOW f+0VqIq7Jj18yW9DIxHtMvIVnz/A7fs7wAaZRkqP3MVj0MtO4LchwRtr3I9NNCtySKmI DdnTMf87RnSAAN/gQqMdJjQ2RBzKcsRcsGzdp1yT4HRE/tvzlv6LkdjESuM5+sgtlZN6 pwLWo82ZiDZv2sFOvE/vGMISfXWvy1oer6cOc/k4jynj9HS+8N9xuosk/1s9+JM8udGj 5GkFoCcKw2y4dFszXqIoIEI2dGnQacALhpt6QV0UI9pQK16a+t4rR7XyCRxxiT/pBH/B WttA== X-Received: by 10.194.108.9 with SMTP id hg9mr69012219wjb.68.1425989686588; Tue, 10 Mar 2015 05:14:46 -0700 (PDT) Received: from [192.168.0.2] (cpc25-cmbg14-2-0-cust121.5-4.cable.virginm.net. [213.106.112.122]) by mx.google.com with ESMTPSA id bx3sm634782wjc.21.2015.03.10.05.14.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Mar 2015 05:14:45 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Thomas Gazagnaire In-Reply-To: <53DA75E3-EE46-4107-8CDC-EEBFE5D51F45@gazagnaire.org> Date: Tue, 10 Mar 2015 12:14:43 +0000 Message-Id: <400A4287-9E91-4587-990C-2E00335162CF@gazagnaire.org> References: <53DA75E3-EE46-4107-8CDC-EEBFE5D51F45@gazagnaire.org> To: Thomas Leonard X-Mailer: Apple Mail (2.2070.6) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Merging in Irmin X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org >> When merged, the result needs to include the parent, even though it >> was deleted in one branch and not touched in the other. Can I do this? > > Do you mean you want to control which are the parents of a commit you are creating, even if the respective contents are not related? > > You can manually create a commit by using Irmin.Private.Commit.create[1] and save it in the (private) block store with S.Private.Commit.add[2] > > Not sure how to expose that nicely to the user though... maybe allowing to specify a "parent" optional argument to merge/update/rebase. You can only create a view from one store and apply it in the other: the history of commit will be kept as expected. See: https://github.com/samoht/dog/blob/master/lib/dog.ml#L247 You can try to use that to merge views from different branches, not sure how practical this is though. Thomas > > Thomas > > [1] http://mirage.github.io/irmin/Irmin.Private.Commit.S.html#VALcreate > [2] http://mirage.github.io/irmin/Irmin.Private.S.html > > > > >> >> >> -- >> Dr Thomas Leonard http://0install.net/ >> GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 >> GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA >> >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Mar 10 12:14:53 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 10 Mar 2015 12:14:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVJ3j-0000pi-MQ; Tue, 10 Mar 2015 12:14:51 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVJ3i-0000pS-9z for mirageos-devel@lists.xenproject.org; Tue, 10 Mar 2015 12:14:50 +0000 Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id BB/9D-02753-930EEF45; Tue, 10 Mar 2015 12:14:49 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1425989686!16051167!1 X-Originating-IP: [74.125.82.172] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25476 invoked from network); 10 Mar 2015 12:14:47 -0000 Received: from mail-we0-f172.google.com (HELO mail-we0-f172.google.com) (74.125.82.172) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 Mar 2015 12:14:47 -0000 Received: by wevl61 with SMTP id l61so1319794wev.6 for ; Tue, 10 Mar 2015 05:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pq1EJvRtiE8uz//Lfiv6eks/MosotrdiVW+W83mx/UM=; b=MC9HZjLnCIN5ZWqVsJGEWebyidSkyXaz6qNVkUA8lV2zVlR2DsyeSUQj0aU3Vn7xOW f+0VqIq7Jj18yW9DIxHtMvIVnz/A7fs7wAaZRkqP3MVj0MtO4LchwRtr3I9NNCtySKmI DdnTMf87RnSAAN/gQqMdJjQ2RBzKcsRcsGzdp1yT4HRE/tvzlv6LkdjESuM5+sgtlZN6 pwLWo82ZiDZv2sFOvE/vGMISfXWvy1oer6cOc/k4jynj9HS+8N9xuosk/1s9+JM8udGj 5GkFoCcKw2y4dFszXqIoIEI2dGnQacALhpt6QV0UI9pQK16a+t4rR7XyCRxxiT/pBH/B WttA== X-Received: by 10.194.108.9 with SMTP id hg9mr69012219wjb.68.1425989686588; Tue, 10 Mar 2015 05:14:46 -0700 (PDT) Received: from [192.168.0.2] (cpc25-cmbg14-2-0-cust121.5-4.cable.virginm.net. [213.106.112.122]) by mx.google.com with ESMTPSA id bx3sm634782wjc.21.2015.03.10.05.14.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Mar 2015 05:14:45 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Thomas Gazagnaire In-Reply-To: <53DA75E3-EE46-4107-8CDC-EEBFE5D51F45@gazagnaire.org> Date: Tue, 10 Mar 2015 12:14:43 +0000 Message-Id: <400A4287-9E91-4587-990C-2E00335162CF@gazagnaire.org> References: <53DA75E3-EE46-4107-8CDC-EEBFE5D51F45@gazagnaire.org> To: Thomas Leonard X-Mailer: Apple Mail (2.2070.6) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Merging in Irmin X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org >> When merged, the result needs to include the parent, even though it >> was deleted in one branch and not touched in the other. Can I do this? > > Do you mean you want to control which are the parents of a commit you are creating, even if the respective contents are not related? > > You can manually create a commit by using Irmin.Private.Commit.create[1] and save it in the (private) block store with S.Private.Commit.add[2] > > Not sure how to expose that nicely to the user though... maybe allowing to specify a "parent" optional argument to merge/update/rebase. You can only create a view from one store and apply it in the other: the history of commit will be kept as expected. See: https://github.com/samoht/dog/blob/master/lib/dog.ml#L247 You can try to use that to merge views from different branches, not sure how practical this is though. Thomas > > Thomas > > [1] http://mirage.github.io/irmin/Irmin.Private.Commit.S.html#VALcreate > [2] http://mirage.github.io/irmin/Irmin.Private.S.html > > > > >> >> >> -- >> Dr Thomas Leonard http://0install.net/ >> GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 >> GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA >> >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Mar 10 12:35:58 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 10 Mar 2015 12:35:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVJO9-0003JI-Kp; Tue, 10 Mar 2015 12:35:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVJO9-0003JD-1j for mirageos-devel@lists.xenproject.org; Tue, 10 Mar 2015 12:35:57 +0000 Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id D7/97-03164-C25EEF45; Tue, 10 Mar 2015 12:35:56 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-3.tower-31.messagelabs.com!1425990954!14798991!1 X-Originating-IP: [209.85.215.49] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30402 invoked from network); 10 Mar 2015 12:35:54 -0000 Received: from mail-la0-f49.google.com (HELO mail-la0-f49.google.com) (209.85.215.49) by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 10 Mar 2015 12:35:54 -0000 Received: by lams18 with SMTP id s18so1288467lam.9 for ; Tue, 10 Mar 2015 05:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yJFQh8UjEifS/gXyFzodtFY5OJosIu9/oobYG3180oY=; b=iwb970/XxLzqZE9EqO3kc+z0ZWEivqqVSyvg6wlWbvxGaRsmcv3yaixXH5VDxz8Nw0 itXiW3m4Iy5anGG4iYdYsjhKHmoT/1mnsXNqtecuvs9Hg53ZYE85Ykm2sU/kS/TrZbui fLbHBge6+UZPgO8f3m9EX+FGL6QaD3CvOcXsyqQ4SmDgrznLAdh/T2cFAj2zBLG7yfAo Af4BKKpSq1ndLvKb3lp6bq5kUhAvkrDFh4gQPOBXgT9ytsSE44Ww0z+1vkjekb0rnxod lJ0DY9jWSuytPPP6QFVEr+e4f2qjXSiKVNWhnkcdjEVEQ3Kr7fX0oUTsF9awWjSi89Jo AMKw== MIME-Version: 1.0 X-Received: by 10.112.62.167 with SMTP id z7mr1256001lbr.115.1425990953795; Tue, 10 Mar 2015 05:35:53 -0700 (PDT) Received: by 10.25.207.17 with HTTP; Tue, 10 Mar 2015 05:35:53 -0700 (PDT) In-Reply-To: <400A4287-9E91-4587-990C-2E00335162CF@gazagnaire.org> References: <53DA75E3-EE46-4107-8CDC-EEBFE5D51F45@gazagnaire.org> <400A4287-9E91-4587-990C-2E00335162CF@gazagnaire.org> Date: Tue, 10 Mar 2015 12:35:53 +0000 Message-ID: From: Thomas Leonard To: Thomas Gazagnaire Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Merging in Irmin X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 10 March 2015 at 12:14, Thomas Gazagnaire wrote: >>> When merged, the result needs to include the parent, even though it >>> was deleted in one branch and not touched in the other. Can I do this? >> >> Do you mean you want to control which are the parents of a commit you are creating, even if the respective contents are not related? >> >> You can manually create a commit by using Irmin.Private.Commit.create[1] and save it in the (private) block store with S.Private.Commit.add[2] >> >> Not sure how to expose that nicely to the user though... maybe allowing to specify a "parent" optional argument to merge/update/rebase. That would be useful. I've been avoiding the "Private" API so far, but maybe I should start using it. > You can only create a view from one store and apply it in the other: the history of commit will be kept as expected. See: > > https://github.com/samoht/dog/blob/master/lib/dog.ml#L247 > > You can try to use that to merge views from different branches, not sure how practical this is though. The basic logic I have is roughly: 1. git checkout base 2. (apply modification) 3. UPDATE=$(git commit-tree -p base) 4. git checkout master 5. git-merge -s custom $UPDATE Where "custom" should be my app-specific merge logic that works on whole trees rather than individual files. Currently, I merge to create a new commit, test it, and then do a fast-forward to update the branch to include the merge if the test passes. But if I can use custom merge code, then it would be OK to merge directly to the branch when my merge code returns, since it will already have had a chance to test it. -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Mar 10 12:35:58 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 10 Mar 2015 12:35:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVJO9-0003JI-Kp; Tue, 10 Mar 2015 12:35:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVJO9-0003JD-1j for mirageos-devel@lists.xenproject.org; Tue, 10 Mar 2015 12:35:57 +0000 Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id D7/97-03164-C25EEF45; Tue, 10 Mar 2015 12:35:56 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-3.tower-31.messagelabs.com!1425990954!14798991!1 X-Originating-IP: [209.85.215.49] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30402 invoked from network); 10 Mar 2015 12:35:54 -0000 Received: from mail-la0-f49.google.com (HELO mail-la0-f49.google.com) (209.85.215.49) by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 10 Mar 2015 12:35:54 -0000 Received: by lams18 with SMTP id s18so1288467lam.9 for ; Tue, 10 Mar 2015 05:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yJFQh8UjEifS/gXyFzodtFY5OJosIu9/oobYG3180oY=; b=iwb970/XxLzqZE9EqO3kc+z0ZWEivqqVSyvg6wlWbvxGaRsmcv3yaixXH5VDxz8Nw0 itXiW3m4Iy5anGG4iYdYsjhKHmoT/1mnsXNqtecuvs9Hg53ZYE85Ykm2sU/kS/TrZbui fLbHBge6+UZPgO8f3m9EX+FGL6QaD3CvOcXsyqQ4SmDgrznLAdh/T2cFAj2zBLG7yfAo Af4BKKpSq1ndLvKb3lp6bq5kUhAvkrDFh4gQPOBXgT9ytsSE44Ww0z+1vkjekb0rnxod lJ0DY9jWSuytPPP6QFVEr+e4f2qjXSiKVNWhnkcdjEVEQ3Kr7fX0oUTsF9awWjSi89Jo AMKw== MIME-Version: 1.0 X-Received: by 10.112.62.167 with SMTP id z7mr1256001lbr.115.1425990953795; Tue, 10 Mar 2015 05:35:53 -0700 (PDT) Received: by 10.25.207.17 with HTTP; Tue, 10 Mar 2015 05:35:53 -0700 (PDT) In-Reply-To: <400A4287-9E91-4587-990C-2E00335162CF@gazagnaire.org> References: <53DA75E3-EE46-4107-8CDC-EEBFE5D51F45@gazagnaire.org> <400A4287-9E91-4587-990C-2E00335162CF@gazagnaire.org> Date: Tue, 10 Mar 2015 12:35:53 +0000 Message-ID: From: Thomas Leonard To: Thomas Gazagnaire Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Merging in Irmin X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 10 March 2015 at 12:14, Thomas Gazagnaire wrote: >>> When merged, the result needs to include the parent, even though it >>> was deleted in one branch and not touched in the other. Can I do this? >> >> Do you mean you want to control which are the parents of a commit you are creating, even if the respective contents are not related? >> >> You can manually create a commit by using Irmin.Private.Commit.create[1] and save it in the (private) block store with S.Private.Commit.add[2] >> >> Not sure how to expose that nicely to the user though... maybe allowing to specify a "parent" optional argument to merge/update/rebase. That would be useful. I've been avoiding the "Private" API so far, but maybe I should start using it. > You can only create a view from one store and apply it in the other: the history of commit will be kept as expected. See: > > https://github.com/samoht/dog/blob/master/lib/dog.ml#L247 > > You can try to use that to merge views from different branches, not sure how practical this is though. The basic logic I have is roughly: 1. git checkout base 2. (apply modification) 3. UPDATE=$(git commit-tree -p base) 4. git checkout master 5. git-merge -s custom $UPDATE Where "custom" should be my app-specific merge logic that works on whole trees rather than individual files. Currently, I merge to create a new commit, test it, and then do a fast-forward to update the branch to include the merge if the test passes. But if I can use custom merge code, then it would be OK to merge directly to the branch when my merge code returns, since it will already have had a chance to test it. -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Mar 10 13:47:10 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 10 Mar 2015 13:47:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVKV1-0004i3-F5; Tue, 10 Mar 2015 13:47:07 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVKUz-0004hw-O8 for mirageos-devel@lists.xenproject.org; Tue, 10 Mar 2015 13:47:05 +0000 Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id 0B/72-03164-8D5FEF45; Tue, 10 Mar 2015 13:47:04 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-2.tower-27.messagelabs.com!1425995220!16165950!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30557 invoked from network); 10 Mar 2015 13:47:00 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Mar 2015 13:47:00 -0000 Received: from dhcp-172-17-154-211.eduroam.wireless.private.cam.ac.uk (global-1-26.nat.csx.cam.ac.uk [131.111.184.26]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 438a3401; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; for ; Tue, 10 Mar 2015 13:47:00 +0000 (GMT) From: Anil Madhavapeddy Message-Id: <727D7526-88DA-46F2-894A-F5CC7A68BEBF@recoil.org> Date: Tue, 10 Mar 2015 13:46:59 +0000 To: mirageos-devel Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Subject: [MirageOS-devel] ANN: mirage.2.3.0 released X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org I've just released Mirage 2.3.0 to OPAM. This is a point release with several important cleanups in the interfaces: https://github.com/mirage/mirage/releases/tag/v2.3.0 * Remove the `IO_PAGE` module type from `V1`. This has now moved into the `io-page` pacakge (#356) * Remove `DEVICE.connect` from the `V1` module types. When a module is functorised over a `DEVICE` it should only have the ability to *use* devices it is given, not to connect to new ones. (#150) * Add `FLOW.error_message` to the `V1` module types to allow for generic handling of errors. (#346) * Add `IP.uipaddr` as a universal IP address type. (#361) * Support the `entropy` version 0.2+ interfaces. (#359) * Check that the `opam` command is at least version 1.2.0 (#355) * Don't put '-classic-display' in the generated Makefiles. (#364) Although this is a short changelog, the main changes that matter are the IO_PAGE and Device connect changes, which required revisions across a significant number of packages. Many thanks to Thomas Leonard who did a lot of the legwork to propagate the required changes: https://github.com/mirage/mirage/pull/350 The full set of libraries that have changed are up at: http://openmirage.org/releases/ Next target: merging the TLS interface changes for out-of-the-box TLS unikernels. -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Mar 10 13:47:10 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 10 Mar 2015 13:47:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVKV1-0004i3-F5; Tue, 10 Mar 2015 13:47:07 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVKUz-0004hw-O8 for mirageos-devel@lists.xenproject.org; Tue, 10 Mar 2015 13:47:05 +0000 Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id 0B/72-03164-8D5FEF45; Tue, 10 Mar 2015 13:47:04 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-2.tower-27.messagelabs.com!1425995220!16165950!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30557 invoked from network); 10 Mar 2015 13:47:00 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Mar 2015 13:47:00 -0000 Received: from dhcp-172-17-154-211.eduroam.wireless.private.cam.ac.uk (global-1-26.nat.csx.cam.ac.uk [131.111.184.26]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 438a3401; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; for ; Tue, 10 Mar 2015 13:47:00 +0000 (GMT) From: Anil Madhavapeddy Message-Id: <727D7526-88DA-46F2-894A-F5CC7A68BEBF@recoil.org> Date: Tue, 10 Mar 2015 13:46:59 +0000 To: mirageos-devel Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Subject: [MirageOS-devel] ANN: mirage.2.3.0 released X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org I've just released Mirage 2.3.0 to OPAM. This is a point release with several important cleanups in the interfaces: https://github.com/mirage/mirage/releases/tag/v2.3.0 * Remove the `IO_PAGE` module type from `V1`. This has now moved into the `io-page` pacakge (#356) * Remove `DEVICE.connect` from the `V1` module types. When a module is functorised over a `DEVICE` it should only have the ability to *use* devices it is given, not to connect to new ones. (#150) * Add `FLOW.error_message` to the `V1` module types to allow for generic handling of errors. (#346) * Add `IP.uipaddr` as a universal IP address type. (#361) * Support the `entropy` version 0.2+ interfaces. (#359) * Check that the `opam` command is at least version 1.2.0 (#355) * Don't put '-classic-display' in the generated Makefiles. (#364) Although this is a short changelog, the main changes that matter are the IO_PAGE and Device connect changes, which required revisions across a significant number of packages. Many thanks to Thomas Leonard who did a lot of the legwork to propagate the required changes: https://github.com/mirage/mirage/pull/350 The full set of libraries that have changed are up at: http://openmirage.org/releases/ Next target: merging the TLS interface changes for out-of-the-box TLS unikernels. -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Mar 10 14:01:14 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 10 Mar 2015 14:01:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVKif-0006Xi-O6; Tue, 10 Mar 2015 14:01:13 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVKie-0006Xa-Vg for mirageos-devel@lists.xenproject.org; Tue, 10 Mar 2015 14:01:13 +0000 Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id DF/47-02753-829FEF45; Tue, 10 Mar 2015 14:01:12 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1425996069!16225957!1 X-Originating-IP: [209.85.215.50] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23219 invoked from network); 10 Mar 2015 14:01:09 -0000 Received: from mail-la0-f50.google.com (HELO mail-la0-f50.google.com) (209.85.215.50) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 Mar 2015 14:01:09 -0000 Received: by labge10 with SMTP id ge10so1862657lab.7 for ; Tue, 10 Mar 2015 07:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iUxEVDNErq5bhkrjVkUqQeCKViugJSEcklvQf8U6M7Q=; b=xVKQOeu7mNHfqu2lSXAnC44wWKFtyC4/8sa4RyeL9QQFu/4AKLSZFM0ta6+ghq1MY2 R9MJbWQDafrj1Ax7FZyjExkEffWbMcIkkkJ0fjM3wiABJ1K0nBiM2wvAIydZ/d4EUKcm B2KWzrz0SMYKNf8LUHI03lfuVOFUbbQToLkU4zGq1p5gBu48x7GYiq85y3ifYj8iORfW YSUNjnCwUwp79R9UluVV8GR1e9mdfhVwiAmTZJkwBaqKQpnCVx8cgVfB6K1cK3FwUKCb F56/jDegPNvpt+N2EkcCROM9iQDqyIjxO1kTDLBIB9VFTFr9ASUXPCeFQiTaLMGcOVT7 Q/6w== MIME-Version: 1.0 X-Received: by 10.112.91.165 with SMTP id cf5mr6605176lbb.121.1425996068524; Tue, 10 Mar 2015 07:01:08 -0700 (PDT) Received: by 10.25.207.17 with HTTP; Tue, 10 Mar 2015 07:01:08 -0700 (PDT) In-Reply-To: <727D7526-88DA-46F2-894A-F5CC7A68BEBF@recoil.org> References: <727D7526-88DA-46F2-894A-F5CC7A68BEBF@recoil.org> Date: Tue, 10 Mar 2015 14:01:08 +0000 Message-ID: From: Thomas Leonard To: Anil Madhavapeddy Cc: mirageos-devel Subject: Re: [MirageOS-devel] ANN: mirage.2.3.0 released X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 10 March 2015 at 13:46, Anil Madhavapeddy wrote: > I've just released Mirage 2.3.0 to OPAM. This is a point release > with several important cleanups in the interfaces: > https://github.com/mirage/mirage/releases/tag/v2.3.0 > > * Remove the `IO_PAGE` module type from `V1`. This has now moved > into the `io-page` pacakge (#356) > * Remove `DEVICE.connect` from the `V1` module types. When a module is > functorised over a `DEVICE` it should only have the ability to > *use* devices it is given, not to connect to new ones. (#150) > * Add `FLOW.error_message` to the `V1` module types to allow for > generic handling of errors. (#346) > * Add `IP.uipaddr` as a universal IP address type. (#361) > * Support the `entropy` version 0.2+ interfaces. (#359) > * Check that the `opam` command is at least version 1.2.0 (#355) > * Don't put '-classic-display' in the generated Makefiles. (#364) > > Although this is a short changelog, the main changes that matter > are the IO_PAGE and Device connect changes, which required > revisions across a significant number of packages. Many thanks to > Thomas Leonard who did a lot of the legwork to propagate the > required changes: https://github.com/mirage/mirage/pull/350 Great! > The full set of libraries that have changed are up at: > http://openmirage.org/releases/ openmirage.org isn't responding for me (even to pings). > Next target: merging the TLS interface changes for out-of-the-box > TLS unikernels. -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Mar 10 14:01:14 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 10 Mar 2015 14:01:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVKif-0006Xi-O6; Tue, 10 Mar 2015 14:01:13 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVKie-0006Xa-Vg for mirageos-devel@lists.xenproject.org; Tue, 10 Mar 2015 14:01:13 +0000 Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id DF/47-02753-829FEF45; Tue, 10 Mar 2015 14:01:12 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1425996069!16225957!1 X-Originating-IP: [209.85.215.50] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23219 invoked from network); 10 Mar 2015 14:01:09 -0000 Received: from mail-la0-f50.google.com (HELO mail-la0-f50.google.com) (209.85.215.50) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 Mar 2015 14:01:09 -0000 Received: by labge10 with SMTP id ge10so1862657lab.7 for ; Tue, 10 Mar 2015 07:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iUxEVDNErq5bhkrjVkUqQeCKViugJSEcklvQf8U6M7Q=; b=xVKQOeu7mNHfqu2lSXAnC44wWKFtyC4/8sa4RyeL9QQFu/4AKLSZFM0ta6+ghq1MY2 R9MJbWQDafrj1Ax7FZyjExkEffWbMcIkkkJ0fjM3wiABJ1K0nBiM2wvAIydZ/d4EUKcm B2KWzrz0SMYKNf8LUHI03lfuVOFUbbQToLkU4zGq1p5gBu48x7GYiq85y3ifYj8iORfW YSUNjnCwUwp79R9UluVV8GR1e9mdfhVwiAmTZJkwBaqKQpnCVx8cgVfB6K1cK3FwUKCb F56/jDegPNvpt+N2EkcCROM9iQDqyIjxO1kTDLBIB9VFTFr9ASUXPCeFQiTaLMGcOVT7 Q/6w== MIME-Version: 1.0 X-Received: by 10.112.91.165 with SMTP id cf5mr6605176lbb.121.1425996068524; Tue, 10 Mar 2015 07:01:08 -0700 (PDT) Received: by 10.25.207.17 with HTTP; Tue, 10 Mar 2015 07:01:08 -0700 (PDT) In-Reply-To: <727D7526-88DA-46F2-894A-F5CC7A68BEBF@recoil.org> References: <727D7526-88DA-46F2-894A-F5CC7A68BEBF@recoil.org> Date: Tue, 10 Mar 2015 14:01:08 +0000 Message-ID: From: Thomas Leonard To: Anil Madhavapeddy Cc: mirageos-devel Subject: Re: [MirageOS-devel] ANN: mirage.2.3.0 released X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 10 March 2015 at 13:46, Anil Madhavapeddy wrote: > I've just released Mirage 2.3.0 to OPAM. This is a point release > with several important cleanups in the interfaces: > https://github.com/mirage/mirage/releases/tag/v2.3.0 > > * Remove the `IO_PAGE` module type from `V1`. This has now moved > into the `io-page` pacakge (#356) > * Remove `DEVICE.connect` from the `V1` module types. When a module is > functorised over a `DEVICE` it should only have the ability to > *use* devices it is given, not to connect to new ones. (#150) > * Add `FLOW.error_message` to the `V1` module types to allow for > generic handling of errors. (#346) > * Add `IP.uipaddr` as a universal IP address type. (#361) > * Support the `entropy` version 0.2+ interfaces. (#359) > * Check that the `opam` command is at least version 1.2.0 (#355) > * Don't put '-classic-display' in the generated Makefiles. (#364) > > Although this is a short changelog, the main changes that matter > are the IO_PAGE and Device connect changes, which required > revisions across a significant number of packages. Many thanks to > Thomas Leonard who did a lot of the legwork to propagate the > required changes: https://github.com/mirage/mirage/pull/350 Great! > The full set of libraries that have changed are up at: > http://openmirage.org/releases/ openmirage.org isn't responding for me (even to pings). > Next target: merging the TLS interface changes for out-of-the-box > TLS unikernels. -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Mar 10 14:17:58 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 10 Mar 2015 14:17:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVKys-0000H6-Hm; Tue, 10 Mar 2015 14:17:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVKyr-0000Gw-5E for mirageos-devel@lists.xenproject.org; Tue, 10 Mar 2015 14:17:57 +0000 Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id EC/D9-02884-41DFEF45; Tue, 10 Mar 2015 14:17:56 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-14.tower-31.messagelabs.com!1425997074!12382136!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11386 invoked from network); 10 Mar 2015 14:17:54 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Mar 2015 14:17:54 -0000 Received: from dhcp-172-17-154-211.eduroam.wireless.private.cam.ac.uk (global-1-26.nat.csx.cam.ac.uk [131.111.184.26]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 93b896fd; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 10 Mar 2015 14:17:53 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Anil Madhavapeddy In-Reply-To: Date: Tue, 10 Mar 2015 14:17:51 +0000 Message-Id: References: <727D7526-88DA-46F2-894A-F5CC7A68BEBF@recoil.org> To: Thomas Leonard X-Mailer: Apple Mail (2.2070.6) Cc: mirageos-devel Subject: Re: [MirageOS-devel] ANN: mirage.2.3.0 released X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 10 Mar 2015, at 14:01, Thomas Leonard wrote: > > On 10 March 2015 at 13:46, Anil Madhavapeddy wrote: >> I've just released Mirage 2.3.0 to OPAM. This is a point release >> with several important cleanups in the interfaces: >> https://github.com/mirage/mirage/releases/tag/v2.3.0 >> >> * Remove the `IO_PAGE` module type from `V1`. This has now moved >> into the `io-page` pacakge (#356) >> * Remove `DEVICE.connect` from the `V1` module types. When a module is >> functorised over a `DEVICE` it should only have the ability to >> *use* devices it is given, not to connect to new ones. (#150) >> * Add `FLOW.error_message` to the `V1` module types to allow for >> generic handling of errors. (#346) >> * Add `IP.uipaddr` as a universal IP address type. (#361) >> * Support the `entropy` version 0.2+ interfaces. (#359) >> * Check that the `opam` command is at least version 1.2.0 (#355) >> * Don't put '-classic-display' in the generated Makefiles. (#364) >> >> Although this is a short changelog, the main changes that matter >> are the IO_PAGE and Device connect changes, which required >> revisions across a significant number of packages. Many thanks to >> Thomas Leonard who did a lot of the legwork to propagate the >> required changes: https://github.com/mirage/mirage/pull/350 > > Great! > >> The full set of libraries that have changed are up at: >> http://openmirage.org/releases/ > > openmirage.org isn't responding for me (even to pings). Interesting -- we've uncovered a race condition in the Xen netback bringup with the new release. Putting in a very small sleep in the Netfront initialisation is causing the dom0 bridge to unwedge and then work. I'm investigating it, although I may need your assistance with this one Dave... -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Mar 10 14:17:58 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 10 Mar 2015 14:17:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVKys-0000H6-Hm; Tue, 10 Mar 2015 14:17:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVKyr-0000Gw-5E for mirageos-devel@lists.xenproject.org; Tue, 10 Mar 2015 14:17:57 +0000 Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id EC/D9-02884-41DFEF45; Tue, 10 Mar 2015 14:17:56 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-14.tower-31.messagelabs.com!1425997074!12382136!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11386 invoked from network); 10 Mar 2015 14:17:54 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Mar 2015 14:17:54 -0000 Received: from dhcp-172-17-154-211.eduroam.wireless.private.cam.ac.uk (global-1-26.nat.csx.cam.ac.uk [131.111.184.26]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 93b896fd; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 10 Mar 2015 14:17:53 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Anil Madhavapeddy In-Reply-To: Date: Tue, 10 Mar 2015 14:17:51 +0000 Message-Id: References: <727D7526-88DA-46F2-894A-F5CC7A68BEBF@recoil.org> To: Thomas Leonard X-Mailer: Apple Mail (2.2070.6) Cc: mirageos-devel Subject: Re: [MirageOS-devel] ANN: mirage.2.3.0 released X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 10 Mar 2015, at 14:01, Thomas Leonard wrote: > > On 10 March 2015 at 13:46, Anil Madhavapeddy wrote: >> I've just released Mirage 2.3.0 to OPAM. This is a point release >> with several important cleanups in the interfaces: >> https://github.com/mirage/mirage/releases/tag/v2.3.0 >> >> * Remove the `IO_PAGE` module type from `V1`. This has now moved >> into the `io-page` pacakge (#356) >> * Remove `DEVICE.connect` from the `V1` module types. When a module is >> functorised over a `DEVICE` it should only have the ability to >> *use* devices it is given, not to connect to new ones. (#150) >> * Add `FLOW.error_message` to the `V1` module types to allow for >> generic handling of errors. (#346) >> * Add `IP.uipaddr` as a universal IP address type. (#361) >> * Support the `entropy` version 0.2+ interfaces. (#359) >> * Check that the `opam` command is at least version 1.2.0 (#355) >> * Don't put '-classic-display' in the generated Makefiles. (#364) >> >> Although this is a short changelog, the main changes that matter >> are the IO_PAGE and Device connect changes, which required >> revisions across a significant number of packages. Many thanks to >> Thomas Leonard who did a lot of the legwork to propagate the >> required changes: https://github.com/mirage/mirage/pull/350 > > Great! > >> The full set of libraries that have changed are up at: >> http://openmirage.org/releases/ > > openmirage.org isn't responding for me (even to pings). Interesting -- we've uncovered a race condition in the Xen netback bringup with the new release. Putting in a very small sleep in the Netfront initialisation is causing the dom0 bridge to unwedge and then work. I'm investigating it, although I may need your assistance with this one Dave... -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Mar 10 14:42:02 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 10 Mar 2015 14:42:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVLM9-0003pq-0f; Tue, 10 Mar 2015 14:42:01 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVLM8-0003pl-3b for mirageos-devel@lists.xenproject.org; Tue, 10 Mar 2015 14:42:00 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id F0/BA-19682-7B20FF45; Tue, 10 Mar 2015 14:41:59 +0000 X-Env-Sender: Dave.Scott@citrix.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1425998512!14424560!1 X-Originating-IP: [185.25.65.24] X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15329 invoked from network); 10 Mar 2015 14:41:56 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24) by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 10 Mar 2015 14:41:56 -0000 X-IronPort-AV: E=Sophos;i="5.11,375,1422921600"; d="scan'208";a="32776094" From: Dave Scott To: Anil Madhavapeddy Thread-Topic: [MirageOS-devel] ANN: mirage.2.3.0 released Thread-Index: AQHQWzi3ChBS8cIP+EOt/hU2T+qBfJ0VrhsAgAAEq4CAAAazgA== Date: Tue, 10 Mar 2015 14:41:51 +0000 Message-ID: References: <727D7526-88DA-46F2-894A-F5CC7A68BEBF@recoil.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-ID: <55C5BCB23BC0D44F886CD8F75FA2163D@citrix.com> MIME-Version: 1.0 X-DLP: AMS1 Cc: mirageos-devel Subject: Re: [MirageOS-devel] ANN: mirage.2.3.0 released X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org DQo+IE9uIDEwIE1hciAyMDE1LCBhdCAxNDoxNywgQW5pbCBNYWRoYXZhcGVkZHkgPGFuaWxAcmVj b2lsLm9yZz4gd3JvdGU6DQo+IA0KPiBPbiAxMCBNYXIgMjAxNSwgYXQgMTQ6MDEsIFRob21hcyBM ZW9uYXJkIDx0YWxleDVAZ21haWwuY29tPiB3cm90ZToNCj4+IA0KPj4gT24gMTAgTWFyY2ggMjAx NSBhdCAxMzo0NiwgQW5pbCBNYWRoYXZhcGVkZHkgPGFuaWxAcmVjb2lsLm9yZz4gd3JvdGU6DQo+ Pj4gSSd2ZSBqdXN0IHJlbGVhc2VkIE1pcmFnZSAyLjMuMCB0byBPUEFNLiAgVGhpcyBpcyBhIHBv aW50IHJlbGVhc2UNCj4+PiB3aXRoIHNldmVyYWwgaW1wb3J0YW50IGNsZWFudXBzIGluIHRoZSBp bnRlcmZhY2VzOg0KPj4+IGh0dHBzOi8vZ2l0aHViLmNvbS9taXJhZ2UvbWlyYWdlL3JlbGVhc2Vz L3RhZy92Mi4zLjANCj4+PiANCj4+PiAqIFJlbW92ZSB0aGUgYElPX1BBR0VgIG1vZHVsZSB0eXBl IGZyb20gYFYxYC4gVGhpcyBoYXMgbm93IG1vdmVkDQo+Pj4gaW50byB0aGUgYGlvLXBhZ2VgIHBh Y2FrZ2UgKCMzNTYpDQo+Pj4gKiBSZW1vdmUgYERFVklDRS5jb25uZWN0YCBmcm9tIHRoZSBgVjFg IG1vZHVsZSB0eXBlcy4gIFdoZW4gYSBtb2R1bGUgaXMNCj4+PiBmdW5jdG9yaXNlZCBvdmVyIGEg YERFVklDRWAgaXQgc2hvdWxkIG9ubHkgaGF2ZSB0aGUgYWJpbGl0eSB0bw0KPj4+ICp1c2UqIGRl dmljZXMgaXQgaXMgZ2l2ZW4sIG5vdCB0byBjb25uZWN0IHRvIG5ldyBvbmVzLiAoIzE1MCkNCj4+ PiAqIEFkZCBgRkxPVy5lcnJvcl9tZXNzYWdlYCB0byB0aGUgYFYxYCBtb2R1bGUgdHlwZXMgdG8g YWxsb3cgZm9yDQo+Pj4gZ2VuZXJpYyBoYW5kbGluZyBvZiBlcnJvcnMuICgjMzQ2KQ0KPj4+ICog QWRkIGBJUC51aXBhZGRyYCBhcyBhIHVuaXZlcnNhbCBJUCBhZGRyZXNzIHR5cGUuICgjMzYxKQ0K Pj4+ICogU3VwcG9ydCB0aGUgYGVudHJvcHlgIHZlcnNpb24gMC4yKyBpbnRlcmZhY2VzLiAoIzM1 OSkNCj4+PiAqIENoZWNrIHRoYXQgdGhlIGBvcGFtYCBjb21tYW5kIGlzIGF0IGxlYXN0IHZlcnNp b24gMS4yLjAgKCMzNTUpDQo+Pj4gKiBEb24ndCBwdXQgJy1jbGFzc2ljLWRpc3BsYXknIGluIHRo ZSBnZW5lcmF0ZWQgTWFrZWZpbGVzLiAoIzM2NCkNCj4+PiANCj4+PiBBbHRob3VnaCB0aGlzIGlz IGEgc2hvcnQgY2hhbmdlbG9nLCB0aGUgbWFpbiBjaGFuZ2VzIHRoYXQgbWF0dGVyDQo+Pj4gYXJl IHRoZSBJT19QQUdFIGFuZCBEZXZpY2UgY29ubmVjdCBjaGFuZ2VzLCB3aGljaCByZXF1aXJlZA0K Pj4+IHJldmlzaW9ucyBhY3Jvc3MgYSBzaWduaWZpY2FudCBudW1iZXIgb2YgcGFja2FnZXMuICBN YW55IHRoYW5rcyB0bw0KPj4+IFRob21hcyBMZW9uYXJkIHdobyBkaWQgYSBsb3Qgb2YgdGhlIGxl Z3dvcmsgdG8gcHJvcGFnYXRlIHRoZQ0KPj4+IHJlcXVpcmVkIGNoYW5nZXM6IGh0dHBzOi8vZ2l0 aHViLmNvbS9taXJhZ2UvbWlyYWdlL3B1bGwvMzUwDQo+PiANCj4+IEdyZWF0IQ0KPj4gDQo+Pj4g VGhlIGZ1bGwgc2V0IG9mIGxpYnJhcmllcyB0aGF0IGhhdmUgY2hhbmdlZCBhcmUgdXAgYXQ6DQo+ Pj4gaHR0cDovL29wZW5taXJhZ2Uub3JnL3JlbGVhc2VzLw0KPj4gDQo+PiBvcGVubWlyYWdlLm9y ZyBpc24ndCByZXNwb25kaW5nIGZvciBtZSAoZXZlbiB0byBwaW5ncykuDQo+IA0KPiBJbnRlcmVz dGluZyAtLSB3ZSd2ZSB1bmNvdmVyZWQgYSByYWNlIGNvbmRpdGlvbiBpbiB0aGUgWGVuIG5ldGJh Y2sNCj4gYnJpbmd1cCB3aXRoIHRoZSBuZXcgcmVsZWFzZS4gIFB1dHRpbmcgaW4gYSB2ZXJ5IHNt YWxsIHNsZWVwIGluDQo+IHRoZSBOZXRmcm9udCBpbml0aWFsaXNhdGlvbiBpcyBjYXVzaW5nIHRo ZSBkb20wIGJyaWRnZSB0byB1bndlZGdlDQo+IGFuZCB0aGVuIHdvcmsuICBJJ20gaW52ZXN0aWdh dGluZyBpdCwgYWx0aG91Z2ggSSBtYXkgbmVlZCB5b3VyDQo+IGFzc2lzdGFuY2Ugd2l0aCB0aGlz IG9uZSBEYXZl4oCmDQoNClVoLW9oISBEb2VzIHRoZSBicmlkZ2UgZGV2aWNlIGFuZCB0aGUgdmlm IGRldmljZSBpbiBkb20wIGxvb2sgb2ssIGFuZA0KZG8gdGhlIHhlbnN0b3JlIGJhY2tlbmQgYW5k IGZyb250ZW5kIGRpcmVjdG9yaWVzIGJvdGggaGF2ZSDigJxzdGF0ZSA9IDTigJ0/DQrigJQgSSBh c3N1bWUgdGhleSBhbGwgbG9vayByaWdodCBhbmQgdGhlIGJ1ZyBpcyBtb3JlIG9mIGEgcmFjZSBi ZXR3ZWVuDQp0aGUgYmFja2VuZCBhbmQgZnJvbnRlbmQgaW5pdCBjb2RlLg0KDQpJZiBJIGhhZCB0 byBndWVzcyBJIHdvdWxkIHRyeSBpbnNlcnRpbmcgYSB4ZW5zdG9yZSB3YWl0IGhlcmU6DQoNCmh0 dHBzOi8vZ2l0aHViLmNvbS9taXJhZ2UvbWlyYWdlLW5ldC14ZW4vYmxvYi82MzY5YWJkODA5MDRj YTk4MTk0YWJjMDdlNjc2ZWNkYjBhMzcxYjNjL2xpYi9uZXRpZi5tbCNMMzAwDQoNCnRvIHdhaXQg Zm9yIHRoZSBiYWNrZW5kIHRvIGVudGVyIOKAnHN0YXRlID0gNOKAnSBiZWZvcmUgd3JpdGluZyBk YXRhIHRvIHRoZQ0KcmluZyBhbmQgc2lnbmFsbGluZyB0aGUgZXZlbnQgY2hhbm5lbC4gUGVyaGFw cyBpdOKAmXMgd2VkZ2VkIGJlY2F1c2UgdGhlDQpldmVudCB3YXMgaWdub3JlZC4gQSB3YWl0IGxv b3Agd291bGQgbG9vayBsaWtlIHRoaXMgb25lOg0KDQpodHRwczovL2dpdGh1Yi5jb20vbWlyYWdl L21pcmFnZS1ibG9jay14ZW4vYmxvYi9hNjRkMTUyNTg2YzdlYmMxZDIzYzVhZGFhNGRkZDQ0MGI0 NWEzYTgzL2xpYi9ibGtiYWNrLm1sI0wzODgNCg0Kb25seSB3aXRoIHRoZSBjb25kaXRpb24gYmVp bmcg4oCYc3RhdGUgPSBEZXZpY2Vfc3RhdGUuKHRvX3N0cmluZyBDb25uZWN0ZWQpIg0KDQpPZiBj b3Vyc2UgYSB4ZW5zdG9yZSB3YWl0IG1pZ2h0IGp1c3QgYmUgYSB3b3JrYXJvdW5kIGJ5IGNhdXNp bmcgYSBkZWxheS4NClBlcmhhcHMgd2Ugc2hvdWxkIHJlYWQgdGhlIExpbnV4IG5ldGJhY2sgY29k ZSB0byBzZWUgd2hhdCBpdOKAmXMgZG9pbmcuDQoNCkNoZWVycywNCkRhdmUNCg0KDQo+IA0KPiAt YW5pbA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gTWlyYWdlT1MtZGV2ZWwgbWFpbGluZyBsaXN0DQo+IE1pcmFnZU9TLWRldmVsQGxpc3Rz LnhlbnByb2plY3Qub3JnDQo+IGh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmluL21h aWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2ZWwNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2ZWwgbWFpbGluZyBsaXN0Ck1pcmFn ZU9TLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9y Zy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Tue Mar 10 14:42:02 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 10 Mar 2015 14:42:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVLM9-0003pq-0f; Tue, 10 Mar 2015 14:42:01 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVLM8-0003pl-3b for mirageos-devel@lists.xenproject.org; Tue, 10 Mar 2015 14:42:00 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id F0/BA-19682-7B20FF45; Tue, 10 Mar 2015 14:41:59 +0000 X-Env-Sender: Dave.Scott@citrix.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1425998512!14424560!1 X-Originating-IP: [185.25.65.24] X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15329 invoked from network); 10 Mar 2015 14:41:56 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24) by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 10 Mar 2015 14:41:56 -0000 X-IronPort-AV: E=Sophos;i="5.11,375,1422921600"; d="scan'208";a="32776094" From: Dave Scott To: Anil Madhavapeddy Thread-Topic: [MirageOS-devel] ANN: mirage.2.3.0 released Thread-Index: AQHQWzi3ChBS8cIP+EOt/hU2T+qBfJ0VrhsAgAAEq4CAAAazgA== Date: Tue, 10 Mar 2015 14:41:51 +0000 Message-ID: References: <727D7526-88DA-46F2-894A-F5CC7A68BEBF@recoil.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-ID: <55C5BCB23BC0D44F886CD8F75FA2163D@citrix.com> MIME-Version: 1.0 X-DLP: AMS1 Cc: mirageos-devel Subject: Re: [MirageOS-devel] ANN: mirage.2.3.0 released X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org DQo+IE9uIDEwIE1hciAyMDE1LCBhdCAxNDoxNywgQW5pbCBNYWRoYXZhcGVkZHkgPGFuaWxAcmVj b2lsLm9yZz4gd3JvdGU6DQo+IA0KPiBPbiAxMCBNYXIgMjAxNSwgYXQgMTQ6MDEsIFRob21hcyBM ZW9uYXJkIDx0YWxleDVAZ21haWwuY29tPiB3cm90ZToNCj4+IA0KPj4gT24gMTAgTWFyY2ggMjAx NSBhdCAxMzo0NiwgQW5pbCBNYWRoYXZhcGVkZHkgPGFuaWxAcmVjb2lsLm9yZz4gd3JvdGU6DQo+ Pj4gSSd2ZSBqdXN0IHJlbGVhc2VkIE1pcmFnZSAyLjMuMCB0byBPUEFNLiAgVGhpcyBpcyBhIHBv aW50IHJlbGVhc2UNCj4+PiB3aXRoIHNldmVyYWwgaW1wb3J0YW50IGNsZWFudXBzIGluIHRoZSBp bnRlcmZhY2VzOg0KPj4+IGh0dHBzOi8vZ2l0aHViLmNvbS9taXJhZ2UvbWlyYWdlL3JlbGVhc2Vz L3RhZy92Mi4zLjANCj4+PiANCj4+PiAqIFJlbW92ZSB0aGUgYElPX1BBR0VgIG1vZHVsZSB0eXBl IGZyb20gYFYxYC4gVGhpcyBoYXMgbm93IG1vdmVkDQo+Pj4gaW50byB0aGUgYGlvLXBhZ2VgIHBh Y2FrZ2UgKCMzNTYpDQo+Pj4gKiBSZW1vdmUgYERFVklDRS5jb25uZWN0YCBmcm9tIHRoZSBgVjFg IG1vZHVsZSB0eXBlcy4gIFdoZW4gYSBtb2R1bGUgaXMNCj4+PiBmdW5jdG9yaXNlZCBvdmVyIGEg YERFVklDRWAgaXQgc2hvdWxkIG9ubHkgaGF2ZSB0aGUgYWJpbGl0eSB0bw0KPj4+ICp1c2UqIGRl dmljZXMgaXQgaXMgZ2l2ZW4sIG5vdCB0byBjb25uZWN0IHRvIG5ldyBvbmVzLiAoIzE1MCkNCj4+ PiAqIEFkZCBgRkxPVy5lcnJvcl9tZXNzYWdlYCB0byB0aGUgYFYxYCBtb2R1bGUgdHlwZXMgdG8g YWxsb3cgZm9yDQo+Pj4gZ2VuZXJpYyBoYW5kbGluZyBvZiBlcnJvcnMuICgjMzQ2KQ0KPj4+ICog QWRkIGBJUC51aXBhZGRyYCBhcyBhIHVuaXZlcnNhbCBJUCBhZGRyZXNzIHR5cGUuICgjMzYxKQ0K Pj4+ICogU3VwcG9ydCB0aGUgYGVudHJvcHlgIHZlcnNpb24gMC4yKyBpbnRlcmZhY2VzLiAoIzM1 OSkNCj4+PiAqIENoZWNrIHRoYXQgdGhlIGBvcGFtYCBjb21tYW5kIGlzIGF0IGxlYXN0IHZlcnNp b24gMS4yLjAgKCMzNTUpDQo+Pj4gKiBEb24ndCBwdXQgJy1jbGFzc2ljLWRpc3BsYXknIGluIHRo ZSBnZW5lcmF0ZWQgTWFrZWZpbGVzLiAoIzM2NCkNCj4+PiANCj4+PiBBbHRob3VnaCB0aGlzIGlz IGEgc2hvcnQgY2hhbmdlbG9nLCB0aGUgbWFpbiBjaGFuZ2VzIHRoYXQgbWF0dGVyDQo+Pj4gYXJl IHRoZSBJT19QQUdFIGFuZCBEZXZpY2UgY29ubmVjdCBjaGFuZ2VzLCB3aGljaCByZXF1aXJlZA0K Pj4+IHJldmlzaW9ucyBhY3Jvc3MgYSBzaWduaWZpY2FudCBudW1iZXIgb2YgcGFja2FnZXMuICBN YW55IHRoYW5rcyB0bw0KPj4+IFRob21hcyBMZW9uYXJkIHdobyBkaWQgYSBsb3Qgb2YgdGhlIGxl Z3dvcmsgdG8gcHJvcGFnYXRlIHRoZQ0KPj4+IHJlcXVpcmVkIGNoYW5nZXM6IGh0dHBzOi8vZ2l0 aHViLmNvbS9taXJhZ2UvbWlyYWdlL3B1bGwvMzUwDQo+PiANCj4+IEdyZWF0IQ0KPj4gDQo+Pj4g VGhlIGZ1bGwgc2V0IG9mIGxpYnJhcmllcyB0aGF0IGhhdmUgY2hhbmdlZCBhcmUgdXAgYXQ6DQo+ Pj4gaHR0cDovL29wZW5taXJhZ2Uub3JnL3JlbGVhc2VzLw0KPj4gDQo+PiBvcGVubWlyYWdlLm9y ZyBpc24ndCByZXNwb25kaW5nIGZvciBtZSAoZXZlbiB0byBwaW5ncykuDQo+IA0KPiBJbnRlcmVz dGluZyAtLSB3ZSd2ZSB1bmNvdmVyZWQgYSByYWNlIGNvbmRpdGlvbiBpbiB0aGUgWGVuIG5ldGJh Y2sNCj4gYnJpbmd1cCB3aXRoIHRoZSBuZXcgcmVsZWFzZS4gIFB1dHRpbmcgaW4gYSB2ZXJ5IHNt YWxsIHNsZWVwIGluDQo+IHRoZSBOZXRmcm9udCBpbml0aWFsaXNhdGlvbiBpcyBjYXVzaW5nIHRo ZSBkb20wIGJyaWRnZSB0byB1bndlZGdlDQo+IGFuZCB0aGVuIHdvcmsuICBJJ20gaW52ZXN0aWdh dGluZyBpdCwgYWx0aG91Z2ggSSBtYXkgbmVlZCB5b3VyDQo+IGFzc2lzdGFuY2Ugd2l0aCB0aGlz IG9uZSBEYXZl4oCmDQoNClVoLW9oISBEb2VzIHRoZSBicmlkZ2UgZGV2aWNlIGFuZCB0aGUgdmlm IGRldmljZSBpbiBkb20wIGxvb2sgb2ssIGFuZA0KZG8gdGhlIHhlbnN0b3JlIGJhY2tlbmQgYW5k IGZyb250ZW5kIGRpcmVjdG9yaWVzIGJvdGggaGF2ZSDigJxzdGF0ZSA9IDTigJ0/DQrigJQgSSBh c3N1bWUgdGhleSBhbGwgbG9vayByaWdodCBhbmQgdGhlIGJ1ZyBpcyBtb3JlIG9mIGEgcmFjZSBi ZXR3ZWVuDQp0aGUgYmFja2VuZCBhbmQgZnJvbnRlbmQgaW5pdCBjb2RlLg0KDQpJZiBJIGhhZCB0 byBndWVzcyBJIHdvdWxkIHRyeSBpbnNlcnRpbmcgYSB4ZW5zdG9yZSB3YWl0IGhlcmU6DQoNCmh0 dHBzOi8vZ2l0aHViLmNvbS9taXJhZ2UvbWlyYWdlLW5ldC14ZW4vYmxvYi82MzY5YWJkODA5MDRj YTk4MTk0YWJjMDdlNjc2ZWNkYjBhMzcxYjNjL2xpYi9uZXRpZi5tbCNMMzAwDQoNCnRvIHdhaXQg Zm9yIHRoZSBiYWNrZW5kIHRvIGVudGVyIOKAnHN0YXRlID0gNOKAnSBiZWZvcmUgd3JpdGluZyBk YXRhIHRvIHRoZQ0KcmluZyBhbmQgc2lnbmFsbGluZyB0aGUgZXZlbnQgY2hhbm5lbC4gUGVyaGFw cyBpdOKAmXMgd2VkZ2VkIGJlY2F1c2UgdGhlDQpldmVudCB3YXMgaWdub3JlZC4gQSB3YWl0IGxv b3Agd291bGQgbG9vayBsaWtlIHRoaXMgb25lOg0KDQpodHRwczovL2dpdGh1Yi5jb20vbWlyYWdl L21pcmFnZS1ibG9jay14ZW4vYmxvYi9hNjRkMTUyNTg2YzdlYmMxZDIzYzVhZGFhNGRkZDQ0MGI0 NWEzYTgzL2xpYi9ibGtiYWNrLm1sI0wzODgNCg0Kb25seSB3aXRoIHRoZSBjb25kaXRpb24gYmVp bmcg4oCYc3RhdGUgPSBEZXZpY2Vfc3RhdGUuKHRvX3N0cmluZyBDb25uZWN0ZWQpIg0KDQpPZiBj b3Vyc2UgYSB4ZW5zdG9yZSB3YWl0IG1pZ2h0IGp1c3QgYmUgYSB3b3JrYXJvdW5kIGJ5IGNhdXNp bmcgYSBkZWxheS4NClBlcmhhcHMgd2Ugc2hvdWxkIHJlYWQgdGhlIExpbnV4IG5ldGJhY2sgY29k ZSB0byBzZWUgd2hhdCBpdOKAmXMgZG9pbmcuDQoNCkNoZWVycywNCkRhdmUNCg0KDQo+IA0KPiAt YW5pbA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gTWlyYWdlT1MtZGV2ZWwgbWFpbGluZyBsaXN0DQo+IE1pcmFnZU9TLWRldmVsQGxpc3Rz LnhlbnByb2plY3Qub3JnDQo+IGh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmluL21h aWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2ZWwNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2ZWwgbWFpbGluZyBsaXN0Ck1pcmFn ZU9TLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9y Zy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Tue Mar 10 15:42:01 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 10 Mar 2015 15:42:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVMI7-0001U4-Vk; Tue, 10 Mar 2015 15:41:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVMI6-0001Tz-2Y for mirageos-devel@lists.xenproject.org; Tue, 10 Mar 2015 15:41:54 +0000 Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id 34/19-22941-1C01FF45; Tue, 10 Mar 2015 15:41:53 +0000 X-Env-Sender: amc79@cam.ac.uk X-Msg-Ref: server-2.tower-206.messagelabs.com!1426002112!14394099!1 X-Originating-IP: [131.111.8.140] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19182 invoked from network); 10 Mar 2015 15:41:52 -0000 Received: from ppsw-40.csi.cam.ac.uk (HELO ppsw-40.csi.cam.ac.uk) (131.111.8.140) by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Mar 2015 15:41:52 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from dhcp-172-17-235-57.eduroam.wireless.private.cam.ac.uk ([172.17.235.57]:54604) by ppsw-40.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:587) with esmtpsa (PLAIN:amc79) (TLSv1:AES128-SHA:128) id 1YVMI4-0002Cr-k5 (Exim 4.82_3-c0e5623) for mirageos-devel@lists.xenproject.org (return-path ); Tue, 10 Mar 2015 15:41:52 +0000 From: Amir Chaudhry Message-Id: Date: Tue, 10 Mar 2015 15:41:51 +0000 To: mirageos-devel Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [MirageOS-devel] Mirage fortnightly call - Wednesday 11th at 4pm GMT X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi folks, The next Mirage call will take place this Wednesday afternoon at 4pm GMT an= d is open to all. Note that the GoToMeeting details have been updated below. If there are any hiccups/delays then I'll switch to a public Google Hangout= . If that happens, I'll post the link here and also in the IRC channel (#m= irage on freenode). Minutes from last call are up at http://openmirage.org/wiki/weekly-2015-02-= 25 The agenda for this week is currently as follows: =95 Quality and Test =95 Networking stack =95 Outstanding Merges (TLS and DEVICE) =95 GitHub Org cleanup =95 Improve documentation If you have things to add/edit, please do so at https://github.com/mirage/m= irage-www/wiki/Call-Agenda Join us at 4pm GMT on Wednesday! =95 Join the meeting from your computer, tablet or smartphone. https://global.gotomeeting.com/join/250442077 =95 You can also dial in using your phone. UK: +44 (0) 330 221 0088 US: +1 (646) 749-3129 Access Code: 250-442-077 = More phone numbers: https://global.gotomeeting.com/250442077/numbersdisplay= .html Best wishes, Amir _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Mar 10 15:42:01 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 10 Mar 2015 15:42:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVMI7-0001U4-Vk; Tue, 10 Mar 2015 15:41:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVMI6-0001Tz-2Y for mirageos-devel@lists.xenproject.org; Tue, 10 Mar 2015 15:41:54 +0000 Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id 34/19-22941-1C01FF45; Tue, 10 Mar 2015 15:41:53 +0000 X-Env-Sender: amc79@cam.ac.uk X-Msg-Ref: server-2.tower-206.messagelabs.com!1426002112!14394099!1 X-Originating-IP: [131.111.8.140] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19182 invoked from network); 10 Mar 2015 15:41:52 -0000 Received: from ppsw-40.csi.cam.ac.uk (HELO ppsw-40.csi.cam.ac.uk) (131.111.8.140) by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Mar 2015 15:41:52 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from dhcp-172-17-235-57.eduroam.wireless.private.cam.ac.uk ([172.17.235.57]:54604) by ppsw-40.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:587) with esmtpsa (PLAIN:amc79) (TLSv1:AES128-SHA:128) id 1YVMI4-0002Cr-k5 (Exim 4.82_3-c0e5623) for mirageos-devel@lists.xenproject.org (return-path ); Tue, 10 Mar 2015 15:41:52 +0000 From: Amir Chaudhry Message-Id: Date: Tue, 10 Mar 2015 15:41:51 +0000 To: mirageos-devel Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [MirageOS-devel] Mirage fortnightly call - Wednesday 11th at 4pm GMT X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi folks, The next Mirage call will take place this Wednesday afternoon at 4pm GMT an= d is open to all. Note that the GoToMeeting details have been updated below. If there are any hiccups/delays then I'll switch to a public Google Hangout= . If that happens, I'll post the link here and also in the IRC channel (#m= irage on freenode). Minutes from last call are up at http://openmirage.org/wiki/weekly-2015-02-= 25 The agenda for this week is currently as follows: =95 Quality and Test =95 Networking stack =95 Outstanding Merges (TLS and DEVICE) =95 GitHub Org cleanup =95 Improve documentation If you have things to add/edit, please do so at https://github.com/mirage/m= irage-www/wiki/Call-Agenda Join us at 4pm GMT on Wednesday! =95 Join the meeting from your computer, tablet or smartphone. https://global.gotomeeting.com/join/250442077 =95 You can also dial in using your phone. UK: +44 (0) 330 221 0088 US: +1 (646) 749-3129 Access Code: 250-442-077 = More phone numbers: https://global.gotomeeting.com/250442077/numbersdisplay= .html Best wishes, Amir _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Mar 10 18:38:52 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 10 Mar 2015 18:38:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVP3G-00085a-Ij; Tue, 10 Mar 2015 18:38:46 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVP3E-00085T-LN for MirageOS-devel@lists.xenproject.org; Tue, 10 Mar 2015 18:38:44 +0000 Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id 9B/E4-03164-33A3FF45; Tue, 10 Mar 2015 18:38:43 +0000 X-Env-Sender: agarwal1975@gmail.com X-Msg-Ref: server-10.tower-31.messagelabs.com!1426012722!10758044!1 X-Originating-IP: [74.125.82.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_40_50,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14741 invoked from network); 10 Mar 2015 18:38:42 -0000 Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com) (74.125.82.173) by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 10 Mar 2015 18:38:42 -0000 Received: by wevk48 with SMTP id k48so3845699wev.7 for ; Tue, 10 Mar 2015 11:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PvVcaajLZzZRdcoUJt0exxSbfuIREErHqmRoTD7lums=; b=pR20fLqKWnGQtwfbFDziQHmVXW+AQ2SuVWAAYhj31kcKrjG1rFdzqL6Ar86aTpcmpq Cw2gJdkzJ9hwD2Z+THTEAIkIaXQTxZTI89lYNLO+gkuWDtfYxEutGS24M5ieswT3rnts /0kFLWS+fY7iFKgepHlcI/3IZiM5b3Q7g7yMERb2z0aSc0QX650r5xyyDT0WtkQr+V8d k1hsBbmtWiCoo6r5TtQfjfn69P3NKiucgpd2StucgpG8gFB7WPOhTCYdMP0El3ZPQVVF MGCSjXJRurcv2yr94kpXf71WXcXRoV1lCRTTGXkm72NzOSSRfgN2c0moQLMRkt6zf2y4 kXmw== X-Received: by 10.181.27.201 with SMTP id ji9mr84748053wid.20.1426012721864; Tue, 10 Mar 2015 11:38:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.15.72 with HTTP; Tue, 10 Mar 2015 11:38:21 -0700 (PDT) In-Reply-To: References: <073A0B5C-531B-4B7B-ABA3-1D8A0EC4C4BA@recoil.org> From: Ashish Agarwal Date: Tue, 10 Mar 2015 14:38:21 -0400 Message-ID: To: Anand Patil Cc: Thomas Gazagnaire , "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] COW XML questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8044040900257368301==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============8044040900257368301== Content-Type: multipart/alternative; boundary=001a11c3476abb67860510f3752e --001a11c3476abb67860510f3752e Content-Type: text/plain; charset=UTF-8 Thanks Anand. I took a look and will let you know if I do any work worth merging. Also, I'm unsure of your choice of camlp4. The community is moving away from that in favor of ppx. You might take a look at ppx_tools . On Tue, Mar 3, 2015 at 7:01 PM, Anand Patil wrote: > Hi Ashish, > > I knew this day would come. :) I'm still making progress, but haven't > had too much time available for hobby projects lately, so it's slow. > The current state is at https://github.com/apatil/auto-aws . > > It would be fun to work together with someone on this, either from > what I have or from scratch. > > Anand > > On Tue, Mar 3, 2015 at 2:31 PM, Ashish Agarwal > wrote: > > Hi Anand. Any progress on this? Is your repo public? Thanks. > > > > > > On Tue, Jan 6, 2015 at 1:32 PM, Anand Patil > > wrote: > >> > >> Hi Anil and Thomas, thanks for the pointers. I'll keep plugging away > >> at this and will let you know how I get on. > >> > >> Anand > >> > >> On Tue, Jan 6, 2015 at 7:43 AM, Anil Madhavapeddy > wrote: > >> > On 5 Jan 2015, at 05:56, Anand Patil > > >> > wrote: > >> > > >> >> In order to learn OCaml and thence Mirage, I've been working a little > >> >> bit on an automatically generated, complete AWS client along the > lines > >> >> of https://github.com/stripe/aws-go using camlp4. I've got the types > >> >> generated, and now need to generate to/from XML functions for each > >> >> record type. > >> >> > >> > > >> > Incidentally, this would be awesomely useful to have. You might also > >> > want to look at Jyotsna Prakash's (manually written) bindings for > >> > helper functions that might come in useful: > >> > > >> > https://github.com/moonlightdrive/ocaml-ec2 > >> > > >> > Feel free to ask here if you run into any blockers. > >> > > >> > -anil > >> > > >> > >> _______________________________________________ > >> MirageOS-devel mailing list > >> MirageOS-devel@lists.xenproject.org > >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > > > > --001a11c3476abb67860510f3752e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Anand. I took a look and will let you know if I do = any work worth merging. Also, I'm unsure of your choice of camlp4. The = community is moving away from that in favor of ppx. You might take a look a= t ppx_tools.
=

On Tue, Mar 3, 20= 15 at 7:01 PM, Anand Patil <anand.prabhakar.patil@gmail.com<= /a>> wrote:
Hi Ashish,

I knew this day would come. :) I'm still making progress, but haven'= ;t
had too much time available for hobby projects lately, so it's slow. The current state is at https://github.com/apatil/auto-aws .

It would be fun to work together with someone on this, either from
what I have or from scratch.

Anand

On Tue, Mar 3, 2015 at 2:31 PM, Ashish Agarwal <agarwal1975@gmail.com> wrote:
> Hi Anand. Any progress on this? Is your repo public? Thanks.
>
>
> On Tue, Jan 6, 2015 at 1:32 PM, Anand Patil
> <anand.prabhakar= .patil@gmail.com> wrote:
>>
>> Hi Anil and Thomas, thanks for the pointers. I'll keep pluggin= g away
>> at this and will let you know how I get on.
>>
>> Anand
>>
>> On Tue, Jan 6, 2015 at 7:43 AM, Anil Madhavapeddy <anil@recoil.org> wrote:
>> > On 5 Jan 2015, at 05:56, Anand Patil <anand.prabhakar.patil@gmail.com>
>> > wrote:
>> >
>> >> In order to learn OCaml and thence Mirage, I've been = working a little
>> >> bit on an automatically generated, complete AWS client al= ong the lines
>> >> of https://github.com/stripe/aws-go using camlp4. I've got th= e types
>> >> generated, and now need to generate to/from XML functions= for each
>> >> record type.
>> >>
>> >
>> > Incidentally, this would be awesomely useful to have.=C2=A0 Y= ou might also
>> > want to look at Jyotsna Prakash's (manually written) bind= ings for
>> > helper functions that might come in useful:
>> >
>> > https://github.com/moonlightdrive/ocaml-ec2
>> >
>> > Feel free to ask here if you run into any blockers.
>> >
>> > -anil
>> >
>>
>> _______________________________________________
>> MirageOS-devel mailing list
>> MirageOS-de= vel@lists.xenproject.org
>> http://lists.xenproject.org/cgi-bin/mailman= /listinfo/mirageos-devel
>
>

--001a11c3476abb67860510f3752e-- --===============8044040900257368301== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============8044040900257368301==-- From mirageos-devel-bounces@lists.xenproject.org Tue Mar 10 18:38:52 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 10 Mar 2015 18:38:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVP3G-00085a-Ij; Tue, 10 Mar 2015 18:38:46 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVP3E-00085T-LN for MirageOS-devel@lists.xenproject.org; Tue, 10 Mar 2015 18:38:44 +0000 Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id 9B/E4-03164-33A3FF45; Tue, 10 Mar 2015 18:38:43 +0000 X-Env-Sender: agarwal1975@gmail.com X-Msg-Ref: server-10.tower-31.messagelabs.com!1426012722!10758044!1 X-Originating-IP: [74.125.82.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_40_50,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14741 invoked from network); 10 Mar 2015 18:38:42 -0000 Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com) (74.125.82.173) by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 10 Mar 2015 18:38:42 -0000 Received: by wevk48 with SMTP id k48so3845699wev.7 for ; Tue, 10 Mar 2015 11:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PvVcaajLZzZRdcoUJt0exxSbfuIREErHqmRoTD7lums=; b=pR20fLqKWnGQtwfbFDziQHmVXW+AQ2SuVWAAYhj31kcKrjG1rFdzqL6Ar86aTpcmpq Cw2gJdkzJ9hwD2Z+THTEAIkIaXQTxZTI89lYNLO+gkuWDtfYxEutGS24M5ieswT3rnts /0kFLWS+fY7iFKgepHlcI/3IZiM5b3Q7g7yMERb2z0aSc0QX650r5xyyDT0WtkQr+V8d k1hsBbmtWiCoo6r5TtQfjfn69P3NKiucgpd2StucgpG8gFB7WPOhTCYdMP0El3ZPQVVF MGCSjXJRurcv2yr94kpXf71WXcXRoV1lCRTTGXkm72NzOSSRfgN2c0moQLMRkt6zf2y4 kXmw== X-Received: by 10.181.27.201 with SMTP id ji9mr84748053wid.20.1426012721864; Tue, 10 Mar 2015 11:38:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.15.72 with HTTP; Tue, 10 Mar 2015 11:38:21 -0700 (PDT) In-Reply-To: References: <073A0B5C-531B-4B7B-ABA3-1D8A0EC4C4BA@recoil.org> From: Ashish Agarwal Date: Tue, 10 Mar 2015 14:38:21 -0400 Message-ID: To: Anand Patil Cc: Thomas Gazagnaire , "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] COW XML questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8044040900257368301==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============8044040900257368301== Content-Type: multipart/alternative; boundary=001a11c3476abb67860510f3752e --001a11c3476abb67860510f3752e Content-Type: text/plain; charset=UTF-8 Thanks Anand. I took a look and will let you know if I do any work worth merging. Also, I'm unsure of your choice of camlp4. The community is moving away from that in favor of ppx. You might take a look at ppx_tools . On Tue, Mar 3, 2015 at 7:01 PM, Anand Patil wrote: > Hi Ashish, > > I knew this day would come. :) I'm still making progress, but haven't > had too much time available for hobby projects lately, so it's slow. > The current state is at https://github.com/apatil/auto-aws . > > It would be fun to work together with someone on this, either from > what I have or from scratch. > > Anand > > On Tue, Mar 3, 2015 at 2:31 PM, Ashish Agarwal > wrote: > > Hi Anand. Any progress on this? Is your repo public? Thanks. > > > > > > On Tue, Jan 6, 2015 at 1:32 PM, Anand Patil > > wrote: > >> > >> Hi Anil and Thomas, thanks for the pointers. I'll keep plugging away > >> at this and will let you know how I get on. > >> > >> Anand > >> > >> On Tue, Jan 6, 2015 at 7:43 AM, Anil Madhavapeddy > wrote: > >> > On 5 Jan 2015, at 05:56, Anand Patil > > >> > wrote: > >> > > >> >> In order to learn OCaml and thence Mirage, I've been working a little > >> >> bit on an automatically generated, complete AWS client along the > lines > >> >> of https://github.com/stripe/aws-go using camlp4. I've got the types > >> >> generated, and now need to generate to/from XML functions for each > >> >> record type. > >> >> > >> > > >> > Incidentally, this would be awesomely useful to have. You might also > >> > want to look at Jyotsna Prakash's (manually written) bindings for > >> > helper functions that might come in useful: > >> > > >> > https://github.com/moonlightdrive/ocaml-ec2 > >> > > >> > Feel free to ask here if you run into any blockers. > >> > > >> > -anil > >> > > >> > >> _______________________________________________ > >> MirageOS-devel mailing list > >> MirageOS-devel@lists.xenproject.org > >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > > > > --001a11c3476abb67860510f3752e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Anand. I took a look and will let you know if I do = any work worth merging. Also, I'm unsure of your choice of camlp4. The = community is moving away from that in favor of ppx. You might take a look a= t ppx_tools.
=

On Tue, Mar 3, 20= 15 at 7:01 PM, Anand Patil <anand.prabhakar.patil@gmail.com<= /a>> wrote:
Hi Ashish,

I knew this day would come. :) I'm still making progress, but haven'= ;t
had too much time available for hobby projects lately, so it's slow. The current state is at https://github.com/apatil/auto-aws .

It would be fun to work together with someone on this, either from
what I have or from scratch.

Anand

On Tue, Mar 3, 2015 at 2:31 PM, Ashish Agarwal <agarwal1975@gmail.com> wrote:
> Hi Anand. Any progress on this? Is your repo public? Thanks.
>
>
> On Tue, Jan 6, 2015 at 1:32 PM, Anand Patil
> <anand.prabhakar= .patil@gmail.com> wrote:
>>
>> Hi Anil and Thomas, thanks for the pointers. I'll keep pluggin= g away
>> at this and will let you know how I get on.
>>
>> Anand
>>
>> On Tue, Jan 6, 2015 at 7:43 AM, Anil Madhavapeddy <anil@recoil.org> wrote:
>> > On 5 Jan 2015, at 05:56, Anand Patil <anand.prabhakar.patil@gmail.com>
>> > wrote:
>> >
>> >> In order to learn OCaml and thence Mirage, I've been = working a little
>> >> bit on an automatically generated, complete AWS client al= ong the lines
>> >> of https://github.com/stripe/aws-go using camlp4. I've got th= e types
>> >> generated, and now need to generate to/from XML functions= for each
>> >> record type.
>> >>
>> >
>> > Incidentally, this would be awesomely useful to have.=C2=A0 Y= ou might also
>> > want to look at Jyotsna Prakash's (manually written) bind= ings for
>> > helper functions that might come in useful:
>> >
>> > https://github.com/moonlightdrive/ocaml-ec2
>> >
>> > Feel free to ask here if you run into any blockers.
>> >
>> > -anil
>> >
>>
>> _______________________________________________
>> MirageOS-devel mailing list
>> MirageOS-de= vel@lists.xenproject.org
>> http://lists.xenproject.org/cgi-bin/mailman= /listinfo/mirageos-devel
>
>

--001a11c3476abb67860510f3752e-- --===============8044040900257368301== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============8044040900257368301==-- From mirageos-devel-bounces@lists.xenproject.org Wed Mar 11 23:33:21 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 11 Mar 2015 23:33:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVq7k-0000hr-Fd; Wed, 11 Mar 2015 23:33:12 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVq7j-0000hN-65 for mirageos-devel@lists.xenproject.org; Wed, 11 Mar 2015 23:33:11 +0000 Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id BD/8A-02753-6B0D0055; Wed, 11 Mar 2015 23:33:10 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-13.tower-27.messagelabs.com!1426116788!12115739!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31925 invoked from network); 11 Mar 2015 23:33:09 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-13.tower-27.messagelabs.com with SMTP; 11 Mar 2015 23:33:09 -0000 Received: from [172.20.10.2] (75.234.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch [178.197.234.75]) by smtp.webfaction.com (Postfix) with ESMTP id DF43F2079898 for ; Wed, 11 Mar 2015 23:33:07 +0000 (UTC) Date: Thu, 12 Mar 2015 00:33:05 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: mirageos-devel Message-ID: In-Reply-To: References: <20150202.014549.1883720051237442569.Christophe.Troestler@umons.ac.be> <20150204.001614.26478837567139584.Christophe.Troestler@umons.ac.be> <87oap97rvw.fsf@study.localdomain> <87lhk4csew.fsf@study.localdomain> <2A0347CF598A4081B45318903375F7A9@erratique.ch> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [MirageOS-devel] Error handling in Mirage - request for comments! X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Just to counter the claim that if each function returns an error code, programmers will simply ignore them I would like to point to this program that I wrote with rresult and bos (http://erratique.ch/software/bos the OS interaction library that was hiding in assemblage): https://gist.github.com/dbuenzli/b5f7dd42ecd7f3f0765a This program folds over a file hierarchy to find modifications that may have occurred between two runs of the program. It will correctly report any kind of error that may happen (e.g. inexistant cwd, timestamp database file read/write, permission errors, dangling symlinks, etc.) and yet the final programmer hadn't anything to do except insert error logging statements at the right place. While its error messages could certainly be further improved this already brings a very usable program for the final user (no exceptions thrown in the face, no silencing of errors) *and* remains non-painful to write for the programmer. Everybody wins. It relies on OS interaction functions returning result types and an error-wise carefully designed file hierarchy folding combinator with appropriate defaults [1]. Using Sys (i.e. exceptions) to write the same program with the same level of attention to error reporting would have been much more painful and hence tempting the lazy programmer (who isn't ?) to eschew the idea of writing a usable program. Let's make MirageOS an *exception*ally usable system from the ground up. Best, Daniel [1] http://erratique.ch/software/bos/doc/Bos.OS.Path.html#VALfold _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Mar 11 23:33:21 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 11 Mar 2015 23:33:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVq7k-0000hr-Fd; Wed, 11 Mar 2015 23:33:12 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVq7j-0000hN-65 for mirageos-devel@lists.xenproject.org; Wed, 11 Mar 2015 23:33:11 +0000 Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id BD/8A-02753-6B0D0055; Wed, 11 Mar 2015 23:33:10 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-13.tower-27.messagelabs.com!1426116788!12115739!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31925 invoked from network); 11 Mar 2015 23:33:09 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-13.tower-27.messagelabs.com with SMTP; 11 Mar 2015 23:33:09 -0000 Received: from [172.20.10.2] (75.234.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch [178.197.234.75]) by smtp.webfaction.com (Postfix) with ESMTP id DF43F2079898 for ; Wed, 11 Mar 2015 23:33:07 +0000 (UTC) Date: Thu, 12 Mar 2015 00:33:05 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: mirageos-devel Message-ID: In-Reply-To: References: <20150202.014549.1883720051237442569.Christophe.Troestler@umons.ac.be> <20150204.001614.26478837567139584.Christophe.Troestler@umons.ac.be> <87oap97rvw.fsf@study.localdomain> <87lhk4csew.fsf@study.localdomain> <2A0347CF598A4081B45318903375F7A9@erratique.ch> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [MirageOS-devel] Error handling in Mirage - request for comments! X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Just to counter the claim that if each function returns an error code, programmers will simply ignore them I would like to point to this program that I wrote with rresult and bos (http://erratique.ch/software/bos the OS interaction library that was hiding in assemblage): https://gist.github.com/dbuenzli/b5f7dd42ecd7f3f0765a This program folds over a file hierarchy to find modifications that may have occurred between two runs of the program. It will correctly report any kind of error that may happen (e.g. inexistant cwd, timestamp database file read/write, permission errors, dangling symlinks, etc.) and yet the final programmer hadn't anything to do except insert error logging statements at the right place. While its error messages could certainly be further improved this already brings a very usable program for the final user (no exceptions thrown in the face, no silencing of errors) *and* remains non-painful to write for the programmer. Everybody wins. It relies on OS interaction functions returning result types and an error-wise carefully designed file hierarchy folding combinator with appropriate defaults [1]. Using Sys (i.e. exceptions) to write the same program with the same level of attention to error reporting would have been much more painful and hence tempting the lazy programmer (who isn't ?) to eschew the idea of writing a usable program. Let's make MirageOS an *exception*ally usable system from the ground up. Best, Daniel [1] http://erratique.ch/software/bos/doc/Bos.OS.Path.html#VALfold _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Mar 12 09:35:05 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 12 Mar 2015 09:35:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVzW6-0000ej-73; Thu, 12 Mar 2015 09:34:58 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVzW5-0000ee-4R for mirageos-devel@lists.xenproject.org; Thu, 12 Mar 2015 09:34:57 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id FB/7C-30124-0CD51055; Thu, 12 Mar 2015 09:34:56 +0000 X-Env-Sender: scott.dj@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1426152893!12221902!1 X-Originating-IP: [209.85.192.171] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28554 invoked from network); 12 Mar 2015 09:34:54 -0000 Received: from mail-pd0-f171.google.com (HELO mail-pd0-f171.google.com) (209.85.192.171) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2015 09:34:54 -0000 Received: by pdev10 with SMTP id v10so18817649pde.0 for ; Thu, 12 Mar 2015 02:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=G64GKaO2fViBHKcBflOpkCtYGZxQFBUTti/bG03fY1I=; b=J8RCKlEU9St5C0WathkapJnqPVA3lkpqwTeSHpkFCGJEFO8YNCkw+WXl8aIZ/SkQ/J WmsiAURbDoOmESv9P2x9vbt8+i5TtThBGAsb3pzFnLqiv5uW+4r+PwaNzYSIPjyuRoze p7Ta1NdT2+7vX4UwcLJET7zRAzfinBq0BdN08IZOUO4pJwM9+68hsbvw+hbxnD5NXHVi iQXFZ7rKGPJ9dkB3bf50ZWES0pQK7A7P3DQnB7gHZjGjalqKJ8JANMeDAwEVsNpINrvN bXxCXo6Lf5TFkxn7EAPMIJD7qZuEqDQRxf1oXh4M3K57gDZ4XZrF39/0Gnu/ndrBWe2N DWVQ== MIME-Version: 1.0 X-Received: by 10.66.221.8 with SMTP id qa8mr67410177pac.62.1426152891969; Thu, 12 Mar 2015 02:34:51 -0700 (PDT) Received: by 10.70.102.39 with HTTP; Thu, 12 Mar 2015 02:34:51 -0700 (PDT) Date: Thu, 12 Mar 2015 09:34:51 +0000 Message-ID: From: David Scott To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] code coverage testing with Bisect X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7276012608643339844==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============7276012608643339844== Content-Type: multipart/alternative; boundary=047d7b5d959d85759a051114189e --047d7b5d959d85759a051114189e Content-Type: text/plain; charset=UTF-8 Hi, I've been having a lot of fun with bisect[1] recently-- I've been using it to see which parts of the mirage-block-volume[2] and shared-block-ring[3] libraries are completely untouched by their unit tests. I found the following game to be quite addictive: 1. "make coverage", and load result in web-browser 2. spot a big chunk of obvious red (danger, danger, danger) 3. (thinking carefully about what could go wrong) devise an interesting test to stress the red bits (obviously you could cover it with a 'noddy' test but there is probably no point) 4. "make coverage", reload in browser and see the red go green! I've hooked it up with coveralls.io (admittedly in a bit of a hacky way[4]) such that the master branch is firmly in "development" mode, linking against bisect, and without checking in the oasis autogen rubbish. The .travis.yml runs both the travisci-skeleton script and then invokes ocveralls[5] to upload the results. I've added a separate "make release" step which removes bisect and checks in the autogen (presumably into a release branch). Perhaps eventually this could make a github pull request (with the "hub" tool?) and make an opam package? I think the game is made even more addictive when the coveralls badge changes colour, see: https://coveralls.io/r/mirage/mirage-block-volume?branch=master Here's an example bisect report (the code is a work-in-progress): http://dave.recoil.org/tmp/report/file0000.html If you haven't given bisect a go -- I recommend playing with it. Also, if you can think of a nicer way to integrate this -- I admit using 'sed' on the _oasis file is a bit of a hack -- please let me know! Cheers, Dave [1] http://bisect.x9c.fr [2] https://github.com/mirage/mirage-block-volume [3] https://github.com/mirage/shared-block-ring [4] https://github.com/mirage/shared-block-ring/commit/67b9f3100be8e4e9732dd79b7c1cc5352a61d478 [5] https://github.com/sagotch/ocveralls --047d7b5d959d85759a051114189e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I've been having a l= ot of fun with bisect[1] recently-- I've been using it to see which par= ts of the mirage-block-volume[2] and shared-block-ring[3] libraries are com= pletely untouched by their unit tests. I found the following game to be qui= te addictive:

1. "make coverage", and lo= ad result in web-browser
2. spot a big chunk of obvious red (dang= er, danger, danger)
3. (thinking carefully about what could go wr= ong) devise an interesting test to stress the red bits (obviously you could= cover it with a 'noddy' test but there is probably no point)
=
4. "make coverage", reload in browser and see the red go gre= en!

I've hooked it up with coveralls.io (admittedly in a bit of a hacky way[4]) such = that the master branch is firmly in "development" mode, linking a= gainst bisect, and without checking in the oasis autogen rubbish. The .trav= is.yml runs both the travisci-skeleton script and then invokes ocveralls[5]= to upload the results.

I've added a separate = "make release" step which removes bisect and checks in the autoge= n (presumably into a release branch). Perhaps eventually this could make a = github pull request (with the "hub" tool?) and make an opam packa= ge?

I think the game is made even more addictive w= hen the coveralls badge changes colour, see:

--047d7b5d959d85759a051114189e-- --===============7276012608643339844== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============7276012608643339844==-- From mirageos-devel-bounces@lists.xenproject.org Thu Mar 12 09:35:05 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 12 Mar 2015 09:35:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVzW6-0000ej-73; Thu, 12 Mar 2015 09:34:58 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVzW5-0000ee-4R for mirageos-devel@lists.xenproject.org; Thu, 12 Mar 2015 09:34:57 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id FB/7C-30124-0CD51055; Thu, 12 Mar 2015 09:34:56 +0000 X-Env-Sender: scott.dj@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1426152893!12221902!1 X-Originating-IP: [209.85.192.171] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28554 invoked from network); 12 Mar 2015 09:34:54 -0000 Received: from mail-pd0-f171.google.com (HELO mail-pd0-f171.google.com) (209.85.192.171) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2015 09:34:54 -0000 Received: by pdev10 with SMTP id v10so18817649pde.0 for ; Thu, 12 Mar 2015 02:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=G64GKaO2fViBHKcBflOpkCtYGZxQFBUTti/bG03fY1I=; b=J8RCKlEU9St5C0WathkapJnqPVA3lkpqwTeSHpkFCGJEFO8YNCkw+WXl8aIZ/SkQ/J WmsiAURbDoOmESv9P2x9vbt8+i5TtThBGAsb3pzFnLqiv5uW+4r+PwaNzYSIPjyuRoze p7Ta1NdT2+7vX4UwcLJET7zRAzfinBq0BdN08IZOUO4pJwM9+68hsbvw+hbxnD5NXHVi iQXFZ7rKGPJ9dkB3bf50ZWES0pQK7A7P3DQnB7gHZjGjalqKJ8JANMeDAwEVsNpINrvN bXxCXo6Lf5TFkxn7EAPMIJD7qZuEqDQRxf1oXh4M3K57gDZ4XZrF39/0Gnu/ndrBWe2N DWVQ== MIME-Version: 1.0 X-Received: by 10.66.221.8 with SMTP id qa8mr67410177pac.62.1426152891969; Thu, 12 Mar 2015 02:34:51 -0700 (PDT) Received: by 10.70.102.39 with HTTP; Thu, 12 Mar 2015 02:34:51 -0700 (PDT) Date: Thu, 12 Mar 2015 09:34:51 +0000 Message-ID: From: David Scott To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] code coverage testing with Bisect X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7276012608643339844==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============7276012608643339844== Content-Type: multipart/alternative; boundary=047d7b5d959d85759a051114189e --047d7b5d959d85759a051114189e Content-Type: text/plain; charset=UTF-8 Hi, I've been having a lot of fun with bisect[1] recently-- I've been using it to see which parts of the mirage-block-volume[2] and shared-block-ring[3] libraries are completely untouched by their unit tests. I found the following game to be quite addictive: 1. "make coverage", and load result in web-browser 2. spot a big chunk of obvious red (danger, danger, danger) 3. (thinking carefully about what could go wrong) devise an interesting test to stress the red bits (obviously you could cover it with a 'noddy' test but there is probably no point) 4. "make coverage", reload in browser and see the red go green! I've hooked it up with coveralls.io (admittedly in a bit of a hacky way[4]) such that the master branch is firmly in "development" mode, linking against bisect, and without checking in the oasis autogen rubbish. The .travis.yml runs both the travisci-skeleton script and then invokes ocveralls[5] to upload the results. I've added a separate "make release" step which removes bisect and checks in the autogen (presumably into a release branch). Perhaps eventually this could make a github pull request (with the "hub" tool?) and make an opam package? I think the game is made even more addictive when the coveralls badge changes colour, see: https://coveralls.io/r/mirage/mirage-block-volume?branch=master Here's an example bisect report (the code is a work-in-progress): http://dave.recoil.org/tmp/report/file0000.html If you haven't given bisect a go -- I recommend playing with it. Also, if you can think of a nicer way to integrate this -- I admit using 'sed' on the _oasis file is a bit of a hack -- please let me know! Cheers, Dave [1] http://bisect.x9c.fr [2] https://github.com/mirage/mirage-block-volume [3] https://github.com/mirage/shared-block-ring [4] https://github.com/mirage/shared-block-ring/commit/67b9f3100be8e4e9732dd79b7c1cc5352a61d478 [5] https://github.com/sagotch/ocveralls --047d7b5d959d85759a051114189e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I've been having a l= ot of fun with bisect[1] recently-- I've been using it to see which par= ts of the mirage-block-volume[2] and shared-block-ring[3] libraries are com= pletely untouched by their unit tests. I found the following game to be qui= te addictive:

1. "make coverage", and lo= ad result in web-browser
2. spot a big chunk of obvious red (dang= er, danger, danger)
3. (thinking carefully about what could go wr= ong) devise an interesting test to stress the red bits (obviously you could= cover it with a 'noddy' test but there is probably no point)
=
4. "make coverage", reload in browser and see the red go gre= en!

I've hooked it up with coveralls.io (admittedly in a bit of a hacky way[4]) such = that the master branch is firmly in "development" mode, linking a= gainst bisect, and without checking in the oasis autogen rubbish. The .trav= is.yml runs both the travisci-skeleton script and then invokes ocveralls[5]= to upload the results.

I've added a separate = "make release" step which removes bisect and checks in the autoge= n (presumably into a release branch). Perhaps eventually this could make a = github pull request (with the "hub" tool?) and make an opam packa= ge?

I think the game is made even more addictive w= hen the coveralls badge changes colour, see:

--047d7b5d959d85759a051114189e-- --===============7276012608643339844== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============7276012608643339844==-- From mirageos-devel-bounces@lists.xenproject.org Thu Mar 12 09:47:13 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 12 Mar 2015 09:47:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVzhw-0002Ll-A4; Thu, 12 Mar 2015 09:47:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVzhu-0002Lf-Pt for mirageos-devel@lists.xenproject.org; Thu, 12 Mar 2015 09:47:11 +0000 Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id E5/2D-28920-D9061055; Thu, 12 Mar 2015 09:47:09 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-12.tower-31.messagelabs.com!1426153628!11262811!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9771 invoked from network); 12 Mar 2015 09:47:08 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Mar 2015 09:47:08 -0000 Received: from dhcp-172-17-156-164.eduroam.wireless.private.cam.ac.uk (global-1-26.nat.csx.cam.ac.uk [131.111.184.26]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 5d35d90d; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Thu, 12 Mar 2015 09:47:07 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Anil Madhavapeddy In-Reply-To: Date: Thu, 12 Mar 2015 09:47:10 +0000 Message-Id: References: <20150202.014549.1883720051237442569.Christophe.Troestler@umons.ac.be> <20150204.001614.26478837567139584.Christophe.Troestler@umons.ac.be> <87oap97rvw.fsf@study.localdomain> <87lhk4csew.fsf@study.localdomain> <2A0347CF598A4081B45318903375F7A9@erratique.ch> To: =?utf-8?Q?Daniel_B=C3=BCnzli?= X-Mailer: Apple Mail (2.2070.6) Cc: mirageos-devel Subject: Re: [MirageOS-devel] Error handling in Mirage - request for comments! X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org T24gMTEgTWFyIDIwMTUsIGF0IDIzOjMzLCBEYW5pZWwgQsO8bnpsaSA8ZGFuaWVsLmJ1ZW56bGlA ZXJyYXRpcXVlLmNoPiB3cm90ZToKPiAKPiBKdXN0IHRvIGNvdW50ZXIgdGhlIGNsYWltIHRoYXQg aWYgZWFjaCBmdW5jdGlvbiByZXR1cm5zIGFuIGVycm9yIGNvZGUsIHByb2dyYW1tZXJzIHdpbGwg c2ltcGx5IGlnbm9yZSB0aGVtIEkgd291bGQgbGlrZSB0byBwb2ludCB0byB0aGlzIHByb2dyYW0g dGhhdCBJIHdyb3RlIHdpdGggcnJlc3VsdCBhbmQgYm9zIChodHRwOi8vZXJyYXRpcXVlLmNoL3Nv ZnR3YXJlL2JvcyB0aGUgT1MgaW50ZXJhY3Rpb24gbGlicmFyeSB0aGF0IHdhcyBoaWRpbmcgaW4g YXNzZW1ibGFnZSk6Cj4gCj4gaHR0cHM6Ly9naXN0LmdpdGh1Yi5jb20vZGJ1ZW56bGkvYjVmN2Rk NDJlY2Q3ZjNmMDc2NWEKPiAKPiBUaGlzIHByb2dyYW0gZm9sZHMgb3ZlciBhIGZpbGUgaGllcmFy Y2h5IHRvIGZpbmQgbW9kaWZpY2F0aW9ucyB0aGF0IG1heSBoYXZlIG9jY3VycmVkIGJldHdlZW4g dHdvIHJ1bnMgb2YgdGhlIHByb2dyYW0uIEl0IHdpbGwgY29ycmVjdGx5IHJlcG9ydCBhbnkga2lu ZCBvZiBlcnJvciB0aGF0IG1heSBoYXBwZW4gKGUuZy4gaW5leGlzdGFudCBjd2QsIHRpbWVzdGFt cCBkYXRhYmFzZSBmaWxlIHJlYWQvd3JpdGUsIHBlcm1pc3Npb24gZXJyb3JzLCBkYW5nbGluZyBz eW1saW5rcywgZXRjLikgYW5kIHlldCB0aGUgZmluYWwgcHJvZ3JhbW1lciBoYWRuJ3QgYW55dGhp bmcgdG8gZG8gZXhjZXB0IGluc2VydCBlcnJvciBsb2dnaW5nIHN0YXRlbWVudHMgYXQgdGhlIHJp Z2h0IHBsYWNlLiAKPiAKPiBXaGlsZSBpdHMgZXJyb3IgbWVzc2FnZXMgY291bGQgY2VydGFpbmx5 IGJlIGZ1cnRoZXIgaW1wcm92ZWQgdGhpcyBhbHJlYWR5IGJyaW5ncyBhIHZlcnkgdXNhYmxlIHBy b2dyYW0gZm9yIHRoZSBmaW5hbCB1c2VyIChubyBleGNlcHRpb25zIHRocm93biBpbiB0aGUgZmFj ZSwgbm8gc2lsZW5jaW5nIG9mIGVycm9ycykgKmFuZCogcmVtYWlucyBub24tcGFpbmZ1bCB0byB3 cml0ZSBmb3IgdGhlIHByb2dyYW1tZXIuIEV2ZXJ5Ym9keSB3aW5zLiAKPiAKPiBJdCByZWxpZXMg b24gT1MgaW50ZXJhY3Rpb24gZnVuY3Rpb25zIHJldHVybmluZyByZXN1bHQgdHlwZXMgYW5kIGFu IGVycm9yLXdpc2UgY2FyZWZ1bGx5IGRlc2lnbmVkIGZpbGUgaGllcmFyY2h5IGZvbGRpbmcgY29t YmluYXRvciB3aXRoIGFwcHJvcHJpYXRlIGRlZmF1bHRzIFsxXS4gVXNpbmcgU3lzIChpLmUuIGV4 Y2VwdGlvbnMpIHRvIHdyaXRlIHRoZSBzYW1lIHByb2dyYW0gd2l0aCB0aGUgc2FtZSBsZXZlbCBv ZiBhdHRlbnRpb24gdG8gZXJyb3IgcmVwb3J0aW5nIHdvdWxkIGhhdmUgYmVlbiBtdWNoIG1vcmUg cGFpbmZ1bCBhbmQgaGVuY2UgdGVtcHRpbmcgdGhlIGxhenkgcHJvZ3JhbW1lciAod2hvIGlzbid0 ID8pIHRvIGVzY2hldyB0aGUgaWRlYSBvZiB3cml0aW5nIGEgdXNhYmxlIHByb2dyYW0uCj4gCj4g TGV0J3MgbWFrZSBNaXJhZ2VPUyBhbiAqZXhjZXB0aW9uKmFsbHkgdXNhYmxlIHN5c3RlbSBmcm9t IHRoZSBncm91bmQgdXAuIAoKQXQgYSBxdWljayByZWFkIHRocm91Z2ggb2YgdGhlIEFQSXMsIHRo aXMgaXMgZXh0cmVtZWx5IGNvbXBlbGxpbmcuICBJIHBhcnRpY3VsYXJseSBsaWtlIHRoZSBpZGVh IG9mIHJlcGxhY2luZyBvdXIgKGV4dHJlbWVseSB2ZXN0aWdpYWwpIE9TIG1vZHVsZSB3aXRoIHRo ZSBwbGF0Zm9ybS1pbmRlcGVuZGVudCBCb3MuICBJdCBwcm92aWRlcyBzZXZlcmFsIG1pc3Npbmcg ZWxlbWVudHMgdGhhdCB3ZSBzb3JlbHkgbmVlZCwgc3VjaCBhcyBsb2dnaW5nIGZvcm1hdHRlcnMg YW5kIGNvbWJpbmF0b3JzLCBpbiBhZGRpdGlvbiB0byB0aGUgbG92ZWx5IGVycm9yIGhhbmRsaW5n LgoKSSB0aGluayBpdCBjb3VsZCBiZSBkb25lIHdpdGhvdXQgdG9vIG11Y2ggY29kZSBjaHVybiBq dXN0IGJ5IGludHJvZHVjaW5nIEJvcyBpbnN0ZWFkIG9mIE9TIGluIHNldmVyYWwgdXNlIHBvaW50 cywgYnV0IGl0IHdvdWxkIG5lZWQgYSBzZW1pLXN0YWJsZSBCb3MgcmVsZWFzZSBjdXQgYmVmb3Jl IHRoYXQuLi4KCi1hbmlsCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCk1pcmFnZU9TLWRldmVsIG1haWxpbmcgbGlzdApNaXJhZ2VPUy1kZXZlbEBsaXN0cy54 ZW5wcm9qZWN0Lm9yZwpodHRwOi8vbGlzdHMueGVucHJvamVjdC5vcmcvY2dpLWJpbi9tYWlsbWFu L2xpc3RpbmZvL21pcmFnZW9zLWRldmVsCg== From mirageos-devel-bounces@lists.xenproject.org Thu Mar 12 09:47:13 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 12 Mar 2015 09:47:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVzhw-0002Ll-A4; Thu, 12 Mar 2015 09:47:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVzhu-0002Lf-Pt for mirageos-devel@lists.xenproject.org; Thu, 12 Mar 2015 09:47:11 +0000 Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id E5/2D-28920-D9061055; Thu, 12 Mar 2015 09:47:09 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-12.tower-31.messagelabs.com!1426153628!11262811!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9771 invoked from network); 12 Mar 2015 09:47:08 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Mar 2015 09:47:08 -0000 Received: from dhcp-172-17-156-164.eduroam.wireless.private.cam.ac.uk (global-1-26.nat.csx.cam.ac.uk [131.111.184.26]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 5d35d90d; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Thu, 12 Mar 2015 09:47:07 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Anil Madhavapeddy In-Reply-To: Date: Thu, 12 Mar 2015 09:47:10 +0000 Message-Id: References: <20150202.014549.1883720051237442569.Christophe.Troestler@umons.ac.be> <20150204.001614.26478837567139584.Christophe.Troestler@umons.ac.be> <87oap97rvw.fsf@study.localdomain> <87lhk4csew.fsf@study.localdomain> <2A0347CF598A4081B45318903375F7A9@erratique.ch> To: =?utf-8?Q?Daniel_B=C3=BCnzli?= X-Mailer: Apple Mail (2.2070.6) Cc: mirageos-devel Subject: Re: [MirageOS-devel] Error handling in Mirage - request for comments! X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org T24gMTEgTWFyIDIwMTUsIGF0IDIzOjMzLCBEYW5pZWwgQsO8bnpsaSA8ZGFuaWVsLmJ1ZW56bGlA ZXJyYXRpcXVlLmNoPiB3cm90ZToKPiAKPiBKdXN0IHRvIGNvdW50ZXIgdGhlIGNsYWltIHRoYXQg aWYgZWFjaCBmdW5jdGlvbiByZXR1cm5zIGFuIGVycm9yIGNvZGUsIHByb2dyYW1tZXJzIHdpbGwg c2ltcGx5IGlnbm9yZSB0aGVtIEkgd291bGQgbGlrZSB0byBwb2ludCB0byB0aGlzIHByb2dyYW0g dGhhdCBJIHdyb3RlIHdpdGggcnJlc3VsdCBhbmQgYm9zIChodHRwOi8vZXJyYXRpcXVlLmNoL3Nv ZnR3YXJlL2JvcyB0aGUgT1MgaW50ZXJhY3Rpb24gbGlicmFyeSB0aGF0IHdhcyBoaWRpbmcgaW4g YXNzZW1ibGFnZSk6Cj4gCj4gaHR0cHM6Ly9naXN0LmdpdGh1Yi5jb20vZGJ1ZW56bGkvYjVmN2Rk NDJlY2Q3ZjNmMDc2NWEKPiAKPiBUaGlzIHByb2dyYW0gZm9sZHMgb3ZlciBhIGZpbGUgaGllcmFy Y2h5IHRvIGZpbmQgbW9kaWZpY2F0aW9ucyB0aGF0IG1heSBoYXZlIG9jY3VycmVkIGJldHdlZW4g dHdvIHJ1bnMgb2YgdGhlIHByb2dyYW0uIEl0IHdpbGwgY29ycmVjdGx5IHJlcG9ydCBhbnkga2lu ZCBvZiBlcnJvciB0aGF0IG1heSBoYXBwZW4gKGUuZy4gaW5leGlzdGFudCBjd2QsIHRpbWVzdGFt cCBkYXRhYmFzZSBmaWxlIHJlYWQvd3JpdGUsIHBlcm1pc3Npb24gZXJyb3JzLCBkYW5nbGluZyBz eW1saW5rcywgZXRjLikgYW5kIHlldCB0aGUgZmluYWwgcHJvZ3JhbW1lciBoYWRuJ3QgYW55dGhp bmcgdG8gZG8gZXhjZXB0IGluc2VydCBlcnJvciBsb2dnaW5nIHN0YXRlbWVudHMgYXQgdGhlIHJp Z2h0IHBsYWNlLiAKPiAKPiBXaGlsZSBpdHMgZXJyb3IgbWVzc2FnZXMgY291bGQgY2VydGFpbmx5 IGJlIGZ1cnRoZXIgaW1wcm92ZWQgdGhpcyBhbHJlYWR5IGJyaW5ncyBhIHZlcnkgdXNhYmxlIHBy b2dyYW0gZm9yIHRoZSBmaW5hbCB1c2VyIChubyBleGNlcHRpb25zIHRocm93biBpbiB0aGUgZmFj ZSwgbm8gc2lsZW5jaW5nIG9mIGVycm9ycykgKmFuZCogcmVtYWlucyBub24tcGFpbmZ1bCB0byB3 cml0ZSBmb3IgdGhlIHByb2dyYW1tZXIuIEV2ZXJ5Ym9keSB3aW5zLiAKPiAKPiBJdCByZWxpZXMg b24gT1MgaW50ZXJhY3Rpb24gZnVuY3Rpb25zIHJldHVybmluZyByZXN1bHQgdHlwZXMgYW5kIGFu IGVycm9yLXdpc2UgY2FyZWZ1bGx5IGRlc2lnbmVkIGZpbGUgaGllcmFyY2h5IGZvbGRpbmcgY29t YmluYXRvciB3aXRoIGFwcHJvcHJpYXRlIGRlZmF1bHRzIFsxXS4gVXNpbmcgU3lzIChpLmUuIGV4 Y2VwdGlvbnMpIHRvIHdyaXRlIHRoZSBzYW1lIHByb2dyYW0gd2l0aCB0aGUgc2FtZSBsZXZlbCBv ZiBhdHRlbnRpb24gdG8gZXJyb3IgcmVwb3J0aW5nIHdvdWxkIGhhdmUgYmVlbiBtdWNoIG1vcmUg cGFpbmZ1bCBhbmQgaGVuY2UgdGVtcHRpbmcgdGhlIGxhenkgcHJvZ3JhbW1lciAod2hvIGlzbid0 ID8pIHRvIGVzY2hldyB0aGUgaWRlYSBvZiB3cml0aW5nIGEgdXNhYmxlIHByb2dyYW0uCj4gCj4g TGV0J3MgbWFrZSBNaXJhZ2VPUyBhbiAqZXhjZXB0aW9uKmFsbHkgdXNhYmxlIHN5c3RlbSBmcm9t IHRoZSBncm91bmQgdXAuIAoKQXQgYSBxdWljayByZWFkIHRocm91Z2ggb2YgdGhlIEFQSXMsIHRo aXMgaXMgZXh0cmVtZWx5IGNvbXBlbGxpbmcuICBJIHBhcnRpY3VsYXJseSBsaWtlIHRoZSBpZGVh IG9mIHJlcGxhY2luZyBvdXIgKGV4dHJlbWVseSB2ZXN0aWdpYWwpIE9TIG1vZHVsZSB3aXRoIHRo ZSBwbGF0Zm9ybS1pbmRlcGVuZGVudCBCb3MuICBJdCBwcm92aWRlcyBzZXZlcmFsIG1pc3Npbmcg ZWxlbWVudHMgdGhhdCB3ZSBzb3JlbHkgbmVlZCwgc3VjaCBhcyBsb2dnaW5nIGZvcm1hdHRlcnMg YW5kIGNvbWJpbmF0b3JzLCBpbiBhZGRpdGlvbiB0byB0aGUgbG92ZWx5IGVycm9yIGhhbmRsaW5n LgoKSSB0aGluayBpdCBjb3VsZCBiZSBkb25lIHdpdGhvdXQgdG9vIG11Y2ggY29kZSBjaHVybiBq dXN0IGJ5IGludHJvZHVjaW5nIEJvcyBpbnN0ZWFkIG9mIE9TIGluIHNldmVyYWwgdXNlIHBvaW50 cywgYnV0IGl0IHdvdWxkIG5lZWQgYSBzZW1pLXN0YWJsZSBCb3MgcmVsZWFzZSBjdXQgYmVmb3Jl IHRoYXQuLi4KCi1hbmlsCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCk1pcmFnZU9TLWRldmVsIG1haWxpbmcgbGlzdApNaXJhZ2VPUy1kZXZlbEBsaXN0cy54 ZW5wcm9qZWN0Lm9yZwpodHRwOi8vbGlzdHMueGVucHJvamVjdC5vcmcvY2dpLWJpbi9tYWlsbWFu L2xpc3RpbmZvL21pcmFnZW9zLWRldmVsCg== From mirageos-devel-bounces@lists.xenproject.org Thu Mar 12 12:11:57 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 12 Mar 2015 12:11:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW1xv-0002q8-4j; Thu, 12 Mar 2015 12:11:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW1xt-0002pr-CJ for mirageos-devel@lists.xenproject.org; Thu, 12 Mar 2015 12:11:49 +0000 Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id A2/85-23575-48281055; Thu, 12 Mar 2015 12:11:48 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-12.tower-206.messagelabs.com!1426162307!11278081!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2087 invoked from network); 12 Mar 2015 12:11:48 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-12.tower-206.messagelabs.com with SMTP; 12 Mar 2015 12:11:48 -0000 Received: from [172.20.10.2] (75.234.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch [178.197.234.75]) by smtp.webfaction.com (Postfix) with ESMTP id D9FBD20D3584; Thu, 12 Mar 2015 12:11:46 +0000 (UTC) Date: Thu, 12 Mar 2015 13:11:44 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Anil Madhavapeddy Message-ID: <86799A0B521741AF857AE07208F4BAC3@erratique.ch> In-Reply-To: References: <20150202.014549.1883720051237442569.Christophe.Troestler@umons.ac.be> <20150204.001614.26478837567139584.Christophe.Troestler@umons.ac.be> <87oap97rvw.fsf@study.localdomain> <87lhk4csew.fsf@study.localdomain> <2A0347CF598A4081B45318903375F7A9@erratique.ch> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Cc: mirageos-devel Subject: Re: [MirageOS-devel] Error handling in Mirage - request for comments! X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org TGUgamV1ZGksIDEyIG1hcnMgMjAxNSDDoCAxMDo0NywgQW5pbCBNYWRoYXZhcGVkZHkgYSDDqWNy aXQgOgo+IEF0IGEgcXVpY2sgcmVhZCB0aHJvdWdoIG9mIHRoZSBBUElzLCB0aGlzIGlzIGV4dHJl bWVseSBjb21wZWxsaW5nLiBJIHBhcnRpY3VsYXJseSBsaWtlIHRoZSBpZGVhIG9mIHJlcGxhY2lu ZyBvdXIgKGV4dHJlbWVseSB2ZXN0aWdpYWwpIE9TIG1vZHVsZSB3aXRoIHRoZSBwbGF0Zm9ybS1p bmRlcGVuZGVudCBCb3MuCgpDb3VsZCB5b3UgcG9pbnQgbWUgdG8gdGhlIGludGVyZmFjZSBvZiB0 aGlzIE9TIG1vZHVsZSA/IEkgd2FzIG9ibGl2aW91cyBvZiBpdHMgZXhpc3RlbmNlLgogIAo+IEkg dGhpbmsgaXQgY291bGQgYmUgZG9uZSB3aXRob3V0IHRvbyBtdWNoIGNvZGUgY2h1cm4ganVzdCBi eSBpbnRyb2R1Y2luZyBCb3MgaW5zdGVhZCBvZiBPUyBpbiBzZXZlcmFsIHVzZSBwb2ludHMsIGJ1 dCBpdCB3b3VsZCBuZWVkIGEgc2VtaS1zdGFibGUgQm9zIHJlbGVhc2UgY3V0IGJlZm9yZSB0aGF0 Li4uCgpJdCBpcyBjbGVhcmx5IG5vdCBmaW5pc2hlZCBhbmQgd29uJ3QgZ2V0IG11Y2ggd29yayBv biBpdCBiZWZvcmUgdGhpcyBzdW1tZXIgKGl0IHdpbGwgZGV2ZWxvcCBmdXJ0aGVyIHRvZ2V0aGVy IHdpdGggYXNzZW1ibGFnZSkuIFRoZXJlIGFyZSB0aGluZ3MgdGhhdCBuZWVkIGNhcmVmdWwgcmV2 aWV3IGFuZCBmdXJ0aGVyIGRldmVsb3BtZW50IChlLmcuIHBhdGggYW5kIHBhdHRlcm4gaGFuZGxp bmcpLiBJZiB5b3Ugd2lzaCBzbyBJJ20gd2lsbGluZyB0byBtYWtlIGEgc2lsZW50IHJlbGVhc2Ug d2l0aCB0aGUgY3VycmVudCBzdGF0ZSwgYnV0IGRvbid0IGJsYW1lIG1lIGlmIHlvdXIgY29kZSBi cmVha3Mgb24gdGhlIG5leHQgcmVsZWFzZSBldmVuIG9uIHRyaXZpYWxpdGllcyAoaGludHMgYXQg YnJlYWtpbmcgY2hhbmdlcyBjYW4gYWxyZWFkeSBiZSBmb3VuZCBpbiB0aGUgYnQpLiAgCgpCZXN0 LAoKRGFuaWVsCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwpNaXJhZ2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlzdHMueGVucHJv amVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0 aW5mby9taXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Thu Mar 12 12:11:57 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 12 Mar 2015 12:11:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW1xv-0002q8-4j; Thu, 12 Mar 2015 12:11:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW1xt-0002pr-CJ for mirageos-devel@lists.xenproject.org; Thu, 12 Mar 2015 12:11:49 +0000 Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id A2/85-23575-48281055; Thu, 12 Mar 2015 12:11:48 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-12.tower-206.messagelabs.com!1426162307!11278081!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2087 invoked from network); 12 Mar 2015 12:11:48 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-12.tower-206.messagelabs.com with SMTP; 12 Mar 2015 12:11:48 -0000 Received: from [172.20.10.2] (75.234.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch [178.197.234.75]) by smtp.webfaction.com (Postfix) with ESMTP id D9FBD20D3584; Thu, 12 Mar 2015 12:11:46 +0000 (UTC) Date: Thu, 12 Mar 2015 13:11:44 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Anil Madhavapeddy Message-ID: <86799A0B521741AF857AE07208F4BAC3@erratique.ch> In-Reply-To: References: <20150202.014549.1883720051237442569.Christophe.Troestler@umons.ac.be> <20150204.001614.26478837567139584.Christophe.Troestler@umons.ac.be> <87oap97rvw.fsf@study.localdomain> <87lhk4csew.fsf@study.localdomain> <2A0347CF598A4081B45318903375F7A9@erratique.ch> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Cc: mirageos-devel Subject: Re: [MirageOS-devel] Error handling in Mirage - request for comments! X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org TGUgamV1ZGksIDEyIG1hcnMgMjAxNSDDoCAxMDo0NywgQW5pbCBNYWRoYXZhcGVkZHkgYSDDqWNy aXQgOgo+IEF0IGEgcXVpY2sgcmVhZCB0aHJvdWdoIG9mIHRoZSBBUElzLCB0aGlzIGlzIGV4dHJl bWVseSBjb21wZWxsaW5nLiBJIHBhcnRpY3VsYXJseSBsaWtlIHRoZSBpZGVhIG9mIHJlcGxhY2lu ZyBvdXIgKGV4dHJlbWVseSB2ZXN0aWdpYWwpIE9TIG1vZHVsZSB3aXRoIHRoZSBwbGF0Zm9ybS1p bmRlcGVuZGVudCBCb3MuCgpDb3VsZCB5b3UgcG9pbnQgbWUgdG8gdGhlIGludGVyZmFjZSBvZiB0 aGlzIE9TIG1vZHVsZSA/IEkgd2FzIG9ibGl2aW91cyBvZiBpdHMgZXhpc3RlbmNlLgogIAo+IEkg dGhpbmsgaXQgY291bGQgYmUgZG9uZSB3aXRob3V0IHRvbyBtdWNoIGNvZGUgY2h1cm4ganVzdCBi eSBpbnRyb2R1Y2luZyBCb3MgaW5zdGVhZCBvZiBPUyBpbiBzZXZlcmFsIHVzZSBwb2ludHMsIGJ1 dCBpdCB3b3VsZCBuZWVkIGEgc2VtaS1zdGFibGUgQm9zIHJlbGVhc2UgY3V0IGJlZm9yZSB0aGF0 Li4uCgpJdCBpcyBjbGVhcmx5IG5vdCBmaW5pc2hlZCBhbmQgd29uJ3QgZ2V0IG11Y2ggd29yayBv biBpdCBiZWZvcmUgdGhpcyBzdW1tZXIgKGl0IHdpbGwgZGV2ZWxvcCBmdXJ0aGVyIHRvZ2V0aGVy IHdpdGggYXNzZW1ibGFnZSkuIFRoZXJlIGFyZSB0aGluZ3MgdGhhdCBuZWVkIGNhcmVmdWwgcmV2 aWV3IGFuZCBmdXJ0aGVyIGRldmVsb3BtZW50IChlLmcuIHBhdGggYW5kIHBhdHRlcm4gaGFuZGxp bmcpLiBJZiB5b3Ugd2lzaCBzbyBJJ20gd2lsbGluZyB0byBtYWtlIGEgc2lsZW50IHJlbGVhc2Ug d2l0aCB0aGUgY3VycmVudCBzdGF0ZSwgYnV0IGRvbid0IGJsYW1lIG1lIGlmIHlvdXIgY29kZSBi cmVha3Mgb24gdGhlIG5leHQgcmVsZWFzZSBldmVuIG9uIHRyaXZpYWxpdGllcyAoaGludHMgYXQg YnJlYWtpbmcgY2hhbmdlcyBjYW4gYWxyZWFkeSBiZSBmb3VuZCBpbiB0aGUgYnQpLiAgCgpCZXN0 LAoKRGFuaWVsCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwpNaXJhZ2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlzdHMueGVucHJv amVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0 aW5mby9taXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Thu Mar 12 12:51:53 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 12 Mar 2015 12:51:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW2ad-000108-Uq; Thu, 12 Mar 2015 12:51:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW2ac-0000zu-7r for mirageos-devel@lists.xenproject.org; Thu, 12 Mar 2015 12:51:50 +0000 Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id C7/DE-09376-5EB81055; Thu, 12 Mar 2015 12:51:49 +0000 X-Env-Sender: lukedunstan81@gmail.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1426164707!8414129!1 X-Originating-IP: [209.85.217.182] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32453 invoked from network); 12 Mar 2015 12:51:47 -0000 Received: from mail-lb0-f182.google.com (HELO mail-lb0-f182.google.com) (209.85.217.182) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2015 12:51:47 -0000 Received: by lbiz11 with SMTP id z11so15693062lbi.3 for ; Thu, 12 Mar 2015 05:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PBXh9u2mVwYcUBioxQO+qWxriMAsHEvMzzj7Zv+SKQA=; b=Ig+B3htqzF7ZvNhTAjZ9o40UwRnOz2iJGyCP8rAgfs3NsavP32yduAcPvptKu0xD7k H3uj2gqirm71c7HkyR9LljzMkSm8VMHX9N07CwJplP9iBkmm/cL8LvbqnltJaAwkSUUR YGyUr47qp74mYfDZH+GhoZMHUJX2qa/y+l7qmw6zUFV8pCNcMSZm8y1FGp6wVgRoWIiw YiQHXYgYWWe2JP6Fws2sYItwuzMhJD3ryB/+4nrR+qtpyCf1xQsfm/RjM8G0u6YDiilD qcAzxukzlGw/2TCdO/eWpWoknHXlF7qfd0hHeVPmJOg2wg+/+rusWqmUS6a/PkWdwkCC P/Jw== MIME-Version: 1.0 X-Received: by 10.112.29.211 with SMTP id m19mr39378420lbh.100.1426164706686; Thu, 12 Mar 2015 05:51:46 -0700 (PDT) Received: by 10.112.163.134 with HTTP; Thu, 12 Mar 2015 05:51:46 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Mar 2015 20:51:46 +0800 Message-ID: From: Luke Dunstan To: David Scott Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] code coverage testing with Bisect X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4828581171787476099==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============4828581171787476099== Content-Type: multipart/alternative; boundary=001a1133fc36bbbf18051116d8d1 --001a1133fc36bbbf18051116d8d1 Content-Type: text/plain; charset=UTF-8 I had the same idea with sed on _oasis, and coveralls: https://github.com/mirage/ocaml-dns/issues/33 Then I read this article that Anil tweeted: http://www.hammerlab.org/2015/03/04/creating-ocaml-code-coverage-reports-for-ketrew/ Based on a modified version of that "myocamlbuild.ml", I got it working without sed: https://github.com/infidel/ocaml-mdns/blob/master/myocamlbuild.ml Luke On 12 March 2015 at 17:34, David Scott wrote: > Hi, > > I've been having a lot of fun with bisect[1] recently-- I've been using it > to see which parts of the mirage-block-volume[2] and shared-block-ring[3] > libraries are completely untouched by their unit tests. I found the > following game to be quite addictive: > > 1. "make coverage", and load result in web-browser > 2. spot a big chunk of obvious red (danger, danger, danger) > 3. (thinking carefully about what could go wrong) devise an interesting > test to stress the red bits (obviously you could cover it with a 'noddy' > test but there is probably no point) > 4. "make coverage", reload in browser and see the red go green! > > I've hooked it up with coveralls.io (admittedly in a bit of a hacky > way[4]) such that the master branch is firmly in "development" mode, > linking against bisect, and without checking in the oasis autogen rubbish. > The .travis.yml runs both the travisci-skeleton script and then invokes > ocveralls[5] to upload the results. > > I've added a separate "make release" step which removes bisect and checks > in the autogen (presumably into a release branch). Perhaps eventually this > could make a github pull request (with the "hub" tool?) and make an opam > package? > > I think the game is made even more addictive when the coveralls badge > changes colour, see: > > https://coveralls.io/r/mirage/mirage-block-volume?branch=master > > Here's an example bisect report (the code is a work-in-progress): > > http://dave.recoil.org/tmp/report/file0000.html > > If you haven't given bisect a go -- I recommend playing with it. > > Also, if you can think of a nicer way to integrate this -- I admit using > 'sed' on the _oasis file is a bit of a hack -- please let me know! > > Cheers, > Dave > > [1] http://bisect.x9c.fr > [2] https://github.com/mirage/mirage-block-volume > [3] https://github.com/mirage/shared-block-ring > [4] > https://github.com/mirage/shared-block-ring/commit/67b9f3100be8e4e9732dd79b7c1cc5352a61d478 > [5] https://github.com/sagotch/ocveralls > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > --001a1133fc36bbbf18051116d8d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I had the same idea with sed on _oasis, and coveralls:=C2= =A0https://github= .com/mirage/ocaml-dns/issues/33

=
Based on a modified version of that "myocamlbuild.ml", I got it working without sed:= =C2=A0https://github.com/infidel/ocaml-mdns/blob/master/myocamlbuild.ml<= /a>




On= 12 March 2015 at 17:34, David Scott <scott.dj@gmail.com> w= rote:
Hi,

I've been having a lot of fun with bisect[1] recently--= I've been using it to see which parts of the mirage-block-volume[2] an= d shared-block-ring[3] libraries are completely untouched by their unit tes= ts. I found the following game to be quite addictive:

<= div>1. "make coverage", and load result in web-browser
= 2. spot a big chunk of obvious red (danger, danger, danger)
3. (t= hinking carefully about what could go wrong) devise an interesting test to = stress the red bits (obviously you could cover it with a 'noddy' te= st but there is probably no point)
4. "make coverage", = reload in browser and see the red go green!

I'= ve hooked it up with cove= ralls.io (admittedly in a bit of a hacky way[4]) such that the master b= ranch is firmly in "development" mode, linking against bisect, an= d without checking in the oasis autogen rubbish. The .travis.yml runs both = the travisci-skeleton script and then invokes ocveralls[5] to upload the re= sults.

I've added a separate "make releas= e" step which removes bisect and checks in the autogen (presumably int= o a release branch). Perhaps eventually this could make a github pull reque= st (with the "hub" tool?) and make an opam package?
I think the game is made even more addictive when the coveralls= badge changes colour, see:

h= ttps://coveralls.io/r/mirage/mirage-block-volume?branch=3Dmaster

Here's an example bisect report (the code is a w= ork-in-progress):


If you haven't give= n bisect a go -- I recommend playing with it.

Also= , if you can think of a nicer way to integrate this -- I admit using 's= ed' on the _oasis file is a bit of a hack -- please let me know!
<= div>
Cheers,
Dave


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel


--001a1133fc36bbbf18051116d8d1-- --===============4828581171787476099== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============4828581171787476099==-- From mirageos-devel-bounces@lists.xenproject.org Thu Mar 12 12:51:53 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 12 Mar 2015 12:51:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW2ad-000108-Uq; Thu, 12 Mar 2015 12:51:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW2ac-0000zu-7r for mirageos-devel@lists.xenproject.org; Thu, 12 Mar 2015 12:51:50 +0000 Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id C7/DE-09376-5EB81055; Thu, 12 Mar 2015 12:51:49 +0000 X-Env-Sender: lukedunstan81@gmail.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1426164707!8414129!1 X-Originating-IP: [209.85.217.182] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32453 invoked from network); 12 Mar 2015 12:51:47 -0000 Received: from mail-lb0-f182.google.com (HELO mail-lb0-f182.google.com) (209.85.217.182) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2015 12:51:47 -0000 Received: by lbiz11 with SMTP id z11so15693062lbi.3 for ; Thu, 12 Mar 2015 05:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PBXh9u2mVwYcUBioxQO+qWxriMAsHEvMzzj7Zv+SKQA=; b=Ig+B3htqzF7ZvNhTAjZ9o40UwRnOz2iJGyCP8rAgfs3NsavP32yduAcPvptKu0xD7k H3uj2gqirm71c7HkyR9LljzMkSm8VMHX9N07CwJplP9iBkmm/cL8LvbqnltJaAwkSUUR YGyUr47qp74mYfDZH+GhoZMHUJX2qa/y+l7qmw6zUFV8pCNcMSZm8y1FGp6wVgRoWIiw YiQHXYgYWWe2JP6Fws2sYItwuzMhJD3ryB/+4nrR+qtpyCf1xQsfm/RjM8G0u6YDiilD qcAzxukzlGw/2TCdO/eWpWoknHXlF7qfd0hHeVPmJOg2wg+/+rusWqmUS6a/PkWdwkCC P/Jw== MIME-Version: 1.0 X-Received: by 10.112.29.211 with SMTP id m19mr39378420lbh.100.1426164706686; Thu, 12 Mar 2015 05:51:46 -0700 (PDT) Received: by 10.112.163.134 with HTTP; Thu, 12 Mar 2015 05:51:46 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Mar 2015 20:51:46 +0800 Message-ID: From: Luke Dunstan To: David Scott Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] code coverage testing with Bisect X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4828581171787476099==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============4828581171787476099== Content-Type: multipart/alternative; boundary=001a1133fc36bbbf18051116d8d1 --001a1133fc36bbbf18051116d8d1 Content-Type: text/plain; charset=UTF-8 I had the same idea with sed on _oasis, and coveralls: https://github.com/mirage/ocaml-dns/issues/33 Then I read this article that Anil tweeted: http://www.hammerlab.org/2015/03/04/creating-ocaml-code-coverage-reports-for-ketrew/ Based on a modified version of that "myocamlbuild.ml", I got it working without sed: https://github.com/infidel/ocaml-mdns/blob/master/myocamlbuild.ml Luke On 12 March 2015 at 17:34, David Scott wrote: > Hi, > > I've been having a lot of fun with bisect[1] recently-- I've been using it > to see which parts of the mirage-block-volume[2] and shared-block-ring[3] > libraries are completely untouched by their unit tests. I found the > following game to be quite addictive: > > 1. "make coverage", and load result in web-browser > 2. spot a big chunk of obvious red (danger, danger, danger) > 3. (thinking carefully about what could go wrong) devise an interesting > test to stress the red bits (obviously you could cover it with a 'noddy' > test but there is probably no point) > 4. "make coverage", reload in browser and see the red go green! > > I've hooked it up with coveralls.io (admittedly in a bit of a hacky > way[4]) such that the master branch is firmly in "development" mode, > linking against bisect, and without checking in the oasis autogen rubbish. > The .travis.yml runs both the travisci-skeleton script and then invokes > ocveralls[5] to upload the results. > > I've added a separate "make release" step which removes bisect and checks > in the autogen (presumably into a release branch). Perhaps eventually this > could make a github pull request (with the "hub" tool?) and make an opam > package? > > I think the game is made even more addictive when the coveralls badge > changes colour, see: > > https://coveralls.io/r/mirage/mirage-block-volume?branch=master > > Here's an example bisect report (the code is a work-in-progress): > > http://dave.recoil.org/tmp/report/file0000.html > > If you haven't given bisect a go -- I recommend playing with it. > > Also, if you can think of a nicer way to integrate this -- I admit using > 'sed' on the _oasis file is a bit of a hack -- please let me know! > > Cheers, > Dave > > [1] http://bisect.x9c.fr > [2] https://github.com/mirage/mirage-block-volume > [3] https://github.com/mirage/shared-block-ring > [4] > https://github.com/mirage/shared-block-ring/commit/67b9f3100be8e4e9732dd79b7c1cc5352a61d478 > [5] https://github.com/sagotch/ocveralls > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > --001a1133fc36bbbf18051116d8d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I had the same idea with sed on _oasis, and coveralls:=C2= =A0https://github= .com/mirage/ocaml-dns/issues/33

=
Based on a modified version of that "myocamlbuild.ml", I got it working without sed:= =C2=A0https://github.com/infidel/ocaml-mdns/blob/master/myocamlbuild.ml<= /a>




On= 12 March 2015 at 17:34, David Scott <scott.dj@gmail.com> w= rote:
Hi,

I've been having a lot of fun with bisect[1] recently--= I've been using it to see which parts of the mirage-block-volume[2] an= d shared-block-ring[3] libraries are completely untouched by their unit tes= ts. I found the following game to be quite addictive:

<= div>1. "make coverage", and load result in web-browser
= 2. spot a big chunk of obvious red (danger, danger, danger)
3. (t= hinking carefully about what could go wrong) devise an interesting test to = stress the red bits (obviously you could cover it with a 'noddy' te= st but there is probably no point)
4. "make coverage", = reload in browser and see the red go green!

I'= ve hooked it up with cove= ralls.io (admittedly in a bit of a hacky way[4]) such that the master b= ranch is firmly in "development" mode, linking against bisect, an= d without checking in the oasis autogen rubbish. The .travis.yml runs both = the travisci-skeleton script and then invokes ocveralls[5] to upload the re= sults.

I've added a separate "make releas= e" step which removes bisect and checks in the autogen (presumably int= o a release branch). Perhaps eventually this could make a github pull reque= st (with the "hub" tool?) and make an opam package?
I think the game is made even more addictive when the coveralls= badge changes colour, see:

h= ttps://coveralls.io/r/mirage/mirage-block-volume?branch=3Dmaster

Here's an example bisect report (the code is a w= ork-in-progress):


If you haven't give= n bisect a go -- I recommend playing with it.

Also= , if you can think of a nicer way to integrate this -- I admit using 's= ed' on the _oasis file is a bit of a hack -- please let me know!
<= div>
Cheers,
Dave


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel


--001a1133fc36bbbf18051116d8d1-- --===============4828581171787476099== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============4828581171787476099==-- From mirageos-devel-bounces@lists.xenproject.org Thu Mar 12 12:54:36 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 12 Mar 2015 12:54:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW2dI-0001pX-QJ; Thu, 12 Mar 2015 12:54:36 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW2dH-0001pE-Rj for mirageos-devel@lists.xenproject.org; Thu, 12 Mar 2015 12:54:35 +0000 Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id 2F/43-09646-B8C81055; Thu, 12 Mar 2015 12:54:35 +0000 X-Env-Sender: mindy@somerandomidiot.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1426164871!12269148!1 X-Originating-IP: [217.70.183.196] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTYgPT4gMzk1MTY=\n X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27361 invoked from network); 12 Mar 2015 12:54:31 -0000 Received: from relay4-d.mail.gandi.net (HELO relay4-d.mail.gandi.net) (217.70.183.196) by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Mar 2015 12:54:31 -0000 Received: from mfilter3-d.gandi.net (mfilter3-d.gandi.net [217.70.178.133]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 567E0172074 for ; Thu, 12 Mar 2015 13:54:31 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter3-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter3-d.gandi.net (mfilter3-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id qPkjC-LjwRfi for ; Thu, 12 Mar 2015 13:54:30 +0100 (CET) X-Originating-IP: 131.111.184.18 Received: from [172.17.25.233] (global-1-18.nat.csx.cam.ac.uk [131.111.184.18]) (Authenticated sender: guybrush@somerandomidiot.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id D345A172055 for ; Thu, 12 Mar 2015 13:54:29 +0100 (CET) Message-ID: <55018C89.9020905@somerandomidiot.com> Date: Thu, 12 Mar 2015 12:54:33 +0000 From: Mindy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] netif that reads from pcap / hoards writes X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi all, I've just made public `mirage-net-pcap`, a module that satisfies V1.NETWORK by supplying packets from a prerecorded pcap file (via crunch) and keeping written packets in memory for later examination. You can see it at https://github.com/yomimono/mirage-net-pcap , and there's an example unikernel using it under `arp_tester` in my example-unikernels repository at https://github.com/yomimono/example-unikernels . `mirage-net-pcap` works with both unix and xen backends, although the example code works only with Unix because of its use of oUnit. Right now there isn't facility for saving writes to persistent storage (i.e., writing to a pcap). I started writing this and then realized it was generally the opposite of what I actually wanted when writing testing code that used `mirage-net-pcap`, but I do plan on adding this in a later release. I don't have a fork of the mirage frontend tool that nicely sets up a netif in `config.ml` for the user currently, but stacks can be built on top of one in the normal way (i.e., as in `mirage-skeleton/ethifv4`). Bad, horrible, okay, other? -Mindy _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Mar 12 12:54:36 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 12 Mar 2015 12:54:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW2dI-0001pX-QJ; Thu, 12 Mar 2015 12:54:36 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW2dH-0001pE-Rj for mirageos-devel@lists.xenproject.org; Thu, 12 Mar 2015 12:54:35 +0000 Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id 2F/43-09646-B8C81055; Thu, 12 Mar 2015 12:54:35 +0000 X-Env-Sender: mindy@somerandomidiot.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1426164871!12269148!1 X-Originating-IP: [217.70.183.196] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTYgPT4gMzk1MTY=\n X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27361 invoked from network); 12 Mar 2015 12:54:31 -0000 Received: from relay4-d.mail.gandi.net (HELO relay4-d.mail.gandi.net) (217.70.183.196) by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Mar 2015 12:54:31 -0000 Received: from mfilter3-d.gandi.net (mfilter3-d.gandi.net [217.70.178.133]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 567E0172074 for ; Thu, 12 Mar 2015 13:54:31 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter3-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter3-d.gandi.net (mfilter3-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id qPkjC-LjwRfi for ; Thu, 12 Mar 2015 13:54:30 +0100 (CET) X-Originating-IP: 131.111.184.18 Received: from [172.17.25.233] (global-1-18.nat.csx.cam.ac.uk [131.111.184.18]) (Authenticated sender: guybrush@somerandomidiot.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id D345A172055 for ; Thu, 12 Mar 2015 13:54:29 +0100 (CET) Message-ID: <55018C89.9020905@somerandomidiot.com> Date: Thu, 12 Mar 2015 12:54:33 +0000 From: Mindy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] netif that reads from pcap / hoards writes X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi all, I've just made public `mirage-net-pcap`, a module that satisfies V1.NETWORK by supplying packets from a prerecorded pcap file (via crunch) and keeping written packets in memory for later examination. You can see it at https://github.com/yomimono/mirage-net-pcap , and there's an example unikernel using it under `arp_tester` in my example-unikernels repository at https://github.com/yomimono/example-unikernels . `mirage-net-pcap` works with both unix and xen backends, although the example code works only with Unix because of its use of oUnit. Right now there isn't facility for saving writes to persistent storage (i.e., writing to a pcap). I started writing this and then realized it was generally the opposite of what I actually wanted when writing testing code that used `mirage-net-pcap`, but I do plan on adding this in a later release. I don't have a fork of the mirage frontend tool that nicely sets up a netif in `config.ml` for the user currently, but stacks can be built on top of one in the normal way (i.e., as in `mirage-skeleton/ethifv4`). Bad, horrible, okay, other? -Mindy _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Mar 12 13:10:57 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 12 Mar 2015 13:10:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW2t5-00056j-Ri; Thu, 12 Mar 2015 13:10:55 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW2t3-00056e-U7 for mirageos-devel@lists.xenproject.org; Thu, 12 Mar 2015 13:10:54 +0000 Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id 11/A6-00594-C5091055; Thu, 12 Mar 2015 13:10:52 +0000 X-Env-Sender: lukedunstan81@gmail.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1426165850!7663382!1 X-Originating-IP: [209.85.217.173] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13123 invoked from network); 12 Mar 2015 13:10:51 -0000 Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com) (209.85.217.173) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2015 13:10:51 -0000 Received: by lbvp9 with SMTP id p9so15754486lbv.10 for ; Thu, 12 Mar 2015 06:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JjaAMBXDCstKdfKhjr9KHcPzUJ/nzvSkKlv7P//Sn3c=; b=KxRUFzIfJBNm/KL7k9l4NoG9FxVNrTrE/f37hNzkEwVF7lhBhdwagg0oz/JR7no3Gp xRgtSR4qDGFXOOtYKqbG0TIyweCThBvo/FOBpLxCjaXRo2NgDyp5wurqVAKkAWyf65e9 lcyTlvdTfUGyY3hB3ECJVsB8Yzw0t8sMAnYOyHlQGFDEOMOJSEACQFMZBtnWk05rOJxZ b5/LngI11IqYEmsV0RLzoPZIcoO9zEt1yGvt0kTf4CbTqOl6wVyB6yNKHrEoII7IYlGo uQTGBVys5mLkDOkjqju97Ni0u3HLcCpNrEq1wOqo8DujAIkJU90kt2gxjti4HvRL2TH8 vxnw== MIME-Version: 1.0 X-Received: by 10.152.7.132 with SMTP id j4mr39429646laa.100.1426165850224; Thu, 12 Mar 2015 06:10:50 -0700 (PDT) Received: by 10.112.163.134 with HTTP; Thu, 12 Mar 2015 06:10:50 -0700 (PDT) In-Reply-To: <86799A0B521741AF857AE07208F4BAC3@erratique.ch> References: <20150202.014549.1883720051237442569.Christophe.Troestler@umons.ac.be> <20150204.001614.26478837567139584.Christophe.Troestler@umons.ac.be> <87oap97rvw.fsf@study.localdomain> <87lhk4csew.fsf@study.localdomain> <2A0347CF598A4081B45318903375F7A9@erratique.ch> <86799A0B521741AF857AE07208F4BAC3@erratique.ch> Date: Thu, 12 Mar 2015 21:10:50 +0800 Message-ID: From: Luke Dunstan To: =?UTF-8?Q?Daniel_B=C3=BCnzli?= Cc: mirageos-devel , Anil Madhavapeddy Subject: Re: [MirageOS-devel] Error handling in Mirage - request for comments! X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5473533177516498741==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============5473533177516498741== Content-Type: multipart/alternative; boundary=001a11c239cce4c0600511171cd8 --001a11c239cce4c0600511171cd8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12 March 2015 at 20:11, Daniel B=C3=BCnzli wrote: > Le jeudi, 12 mars 2015 =C3=A0 10:47, Anil Madhavapeddy a =C3=A9crit : > > At a quick read through of the APIs, this is extremely compelling. I > particularly like the idea of replacing our (extremely vestigial) OS modu= le > with the platform-independent Bos. > > Could you point me to the interface of this OS module ? I was oblivious o= f > its existence. > https://github.com/mirage/mirage-platform/tree/master/xen/lib or https://github.com/mirage/mirage-platform/tree/master/unix Best regards, Luke > > > I think it could be done without too much code churn just by introducin= g > Bos instead of OS in several use points, but it would need a semi-stable > Bos release cut before that... > > It is clearly not finished and won't get much work on it before this > summer (it will develop further together with assemblage). There are thin= gs > that need careful review and further development (e.g. path and pattern > handling). If you wish so I'm willing to make a silent release with the > current state, but don't blame me if your code breaks on the next release > even on trivialities (hints at breaking changes can already be found in t= he > bt). > > Best, > > Daniel > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > --001a11c239cce4c0600511171cd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 12 March 2015 at 20:11, Daniel B=C3=BCnzli <daniel.buenzli@er= ratique.ch> wrote:
Le jeudi, 12 mars 2015= =C3=A0 10:47, Anil Madhavapeddy a =C3=A9crit :
> At a quick read through of the APIs, this is extremel= y compelling. I particularly like the idea of replacing our (extremely vest= igial) OS module with the platform-independent Bos.

Could you point me to the interface of this OS module ? I was oblivi= ous of its existence.


or https://github.com/mirage/mirage-platform/tree/master/unix
<= br>

Best regards,
Luke

=C2=A0

> I think it could be done without too much code churn just by introduci= ng Bos instead of OS in several use points, but it would need a semi-stable= Bos release cut before that...

It is clearly not finished and won't get much work on it before = this summer (it will develop further together with assemblage). There are t= hings that need careful review and further development (e.g. path and patte= rn handling). If you wish so I'm willing to make a silent release with = the current state, but don't blame me if your code breaks on the next r= elease even on trivialities (hints at breaking changes can already be found= in the bt).

Best,

Daniel

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel

--001a11c239cce4c0600511171cd8-- --===============5473533177516498741== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============5473533177516498741==-- From mirageos-devel-bounces@lists.xenproject.org Thu Mar 12 13:10:57 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 12 Mar 2015 13:10:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW2t5-00056j-Ri; Thu, 12 Mar 2015 13:10:55 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW2t3-00056e-U7 for mirageos-devel@lists.xenproject.org; Thu, 12 Mar 2015 13:10:54 +0000 Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id 11/A6-00594-C5091055; Thu, 12 Mar 2015 13:10:52 +0000 X-Env-Sender: lukedunstan81@gmail.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1426165850!7663382!1 X-Originating-IP: [209.85.217.173] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13123 invoked from network); 12 Mar 2015 13:10:51 -0000 Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com) (209.85.217.173) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2015 13:10:51 -0000 Received: by lbvp9 with SMTP id p9so15754486lbv.10 for ; Thu, 12 Mar 2015 06:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JjaAMBXDCstKdfKhjr9KHcPzUJ/nzvSkKlv7P//Sn3c=; b=KxRUFzIfJBNm/KL7k9l4NoG9FxVNrTrE/f37hNzkEwVF7lhBhdwagg0oz/JR7no3Gp xRgtSR4qDGFXOOtYKqbG0TIyweCThBvo/FOBpLxCjaXRo2NgDyp5wurqVAKkAWyf65e9 lcyTlvdTfUGyY3hB3ECJVsB8Yzw0t8sMAnYOyHlQGFDEOMOJSEACQFMZBtnWk05rOJxZ b5/LngI11IqYEmsV0RLzoPZIcoO9zEt1yGvt0kTf4CbTqOl6wVyB6yNKHrEoII7IYlGo uQTGBVys5mLkDOkjqju97Ni0u3HLcCpNrEq1wOqo8DujAIkJU90kt2gxjti4HvRL2TH8 vxnw== MIME-Version: 1.0 X-Received: by 10.152.7.132 with SMTP id j4mr39429646laa.100.1426165850224; Thu, 12 Mar 2015 06:10:50 -0700 (PDT) Received: by 10.112.163.134 with HTTP; Thu, 12 Mar 2015 06:10:50 -0700 (PDT) In-Reply-To: <86799A0B521741AF857AE07208F4BAC3@erratique.ch> References: <20150202.014549.1883720051237442569.Christophe.Troestler@umons.ac.be> <20150204.001614.26478837567139584.Christophe.Troestler@umons.ac.be> <87oap97rvw.fsf@study.localdomain> <87lhk4csew.fsf@study.localdomain> <2A0347CF598A4081B45318903375F7A9@erratique.ch> <86799A0B521741AF857AE07208F4BAC3@erratique.ch> Date: Thu, 12 Mar 2015 21:10:50 +0800 Message-ID: From: Luke Dunstan To: =?UTF-8?Q?Daniel_B=C3=BCnzli?= Cc: mirageos-devel , Anil Madhavapeddy Subject: Re: [MirageOS-devel] Error handling in Mirage - request for comments! X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5473533177516498741==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============5473533177516498741== Content-Type: multipart/alternative; boundary=001a11c239cce4c0600511171cd8 --001a11c239cce4c0600511171cd8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12 March 2015 at 20:11, Daniel B=C3=BCnzli wrote: > Le jeudi, 12 mars 2015 =C3=A0 10:47, Anil Madhavapeddy a =C3=A9crit : > > At a quick read through of the APIs, this is extremely compelling. I > particularly like the idea of replacing our (extremely vestigial) OS modu= le > with the platform-independent Bos. > > Could you point me to the interface of this OS module ? I was oblivious o= f > its existence. > https://github.com/mirage/mirage-platform/tree/master/xen/lib or https://github.com/mirage/mirage-platform/tree/master/unix Best regards, Luke > > > I think it could be done without too much code churn just by introducin= g > Bos instead of OS in several use points, but it would need a semi-stable > Bos release cut before that... > > It is clearly not finished and won't get much work on it before this > summer (it will develop further together with assemblage). There are thin= gs > that need careful review and further development (e.g. path and pattern > handling). If you wish so I'm willing to make a silent release with the > current state, but don't blame me if your code breaks on the next release > even on trivialities (hints at breaking changes can already be found in t= he > bt). > > Best, > > Daniel > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > --001a11c239cce4c0600511171cd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 12 March 2015 at 20:11, Daniel B=C3=BCnzli <daniel.buenzli@er= ratique.ch> wrote:
Le jeudi, 12 mars 2015= =C3=A0 10:47, Anil Madhavapeddy a =C3=A9crit :
> At a quick read through of the APIs, this is extremel= y compelling. I particularly like the idea of replacing our (extremely vest= igial) OS module with the platform-independent Bos.

Could you point me to the interface of this OS module ? I was oblivi= ous of its existence.


or https://github.com/mirage/mirage-platform/tree/master/unix
<= br>

Best regards,
Luke

=C2=A0

> I think it could be done without too much code churn just by introduci= ng Bos instead of OS in several use points, but it would need a semi-stable= Bos release cut before that...

It is clearly not finished and won't get much work on it before = this summer (it will develop further together with assemblage). There are t= hings that need careful review and further development (e.g. path and patte= rn handling). If you wish so I'm willing to make a silent release with = the current state, but don't blame me if your code breaks on the next r= elease even on trivialities (hints at breaking changes can already be found= in the bt).

Best,

Daniel

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel

--001a11c239cce4c0600511171cd8-- --===============5473533177516498741== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============5473533177516498741==-- From mirageos-devel-bounces@lists.xenproject.org Thu Mar 12 14:12:17 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 12 Mar 2015 14:12:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW3qN-0001U2-RA; Thu, 12 Mar 2015 14:12:11 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW3qN-0001TG-0T for mirageos-devel@lists.xenproject.org; Thu, 12 Mar 2015 14:12:11 +0000 Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id 98/F6-08971-ABE91055; Thu, 12 Mar 2015 14:12:10 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-15.tower-27.messagelabs.com!1426169527!12321422!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11677 invoked from network); 12 Mar 2015 14:12:08 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Mar 2015 14:12:08 -0000 Received: from dhcp-172-17-152-33.eduroam.wireless.private.cam.ac.uk (global-1-26.nat.csx.cam.ac.uk [131.111.184.26]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id c112c719; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Thu, 12 Mar 2015 14:12:05 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Anil Madhavapeddy In-Reply-To: Date: Thu, 12 Mar 2015 14:12:08 +0000 Message-Id: <4585B3C5-3E11-4C0D-B74E-ADAD9A627A3E@recoil.org> References: <727D7526-88DA-46F2-894A-F5CC7A68BEBF@recoil.org> To: David Scott X-Mailer: Apple Mail (2.2070.6) Cc: mirageos-devel Subject: Re: [MirageOS-devel] ANN: mirage.2.3.0 released X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Cj4gT24gMTAgTWFyIDIwMTUsIGF0IDE0OjQxLCBEYXZlIFNjb3R0IDxEYXZlLlNjb3R0QGNpdHJp eC5jb20+IHdyb3RlOgo+IAo+IAo+PiBPbiAxMCBNYXIgMjAxNSwgYXQgMTQ6MTcsIEFuaWwgTWFk aGF2YXBlZGR5IDxhbmlsQHJlY29pbC5vcmc+IHdyb3RlOgo+PiAKPj4gT24gMTAgTWFyIDIwMTUs IGF0IDE0OjAxLCBUaG9tYXMgTGVvbmFyZCA8dGFsZXg1QGdtYWlsLmNvbT4gd3JvdGU6Cj4+PiAK Pj4+IE9uIDEwIE1hcmNoIDIwMTUgYXQgMTM6NDYsIEFuaWwgTWFkaGF2YXBlZGR5IDxhbmlsQHJl Y29pbC5vcmc+IHdyb3RlOgo+Pj4+IEkndmUganVzdCByZWxlYXNlZCBNaXJhZ2UgMi4zLjAgdG8g T1BBTS4gIFRoaXMgaXMgYSBwb2ludCByZWxlYXNlCj4+Pj4gd2l0aCBzZXZlcmFsIGltcG9ydGFu dCBjbGVhbnVwcyBpbiB0aGUgaW50ZXJmYWNlczoKPj4+PiBodHRwczovL2dpdGh1Yi5jb20vbWly YWdlL21pcmFnZS9yZWxlYXNlcy90YWcvdjIuMy4wCj4+Pj4gCj4+Pj4gKiBSZW1vdmUgdGhlIGBJ T19QQUdFYCBtb2R1bGUgdHlwZSBmcm9tIGBWMWAuIFRoaXMgaGFzIG5vdyBtb3ZlZAo+Pj4+IGlu dG8gdGhlIGBpby1wYWdlYCBwYWNha2dlICgjMzU2KQo+Pj4+ICogUmVtb3ZlIGBERVZJQ0UuY29u bmVjdGAgZnJvbSB0aGUgYFYxYCBtb2R1bGUgdHlwZXMuICBXaGVuIGEgbW9kdWxlIGlzCj4+Pj4g ZnVuY3RvcmlzZWQgb3ZlciBhIGBERVZJQ0VgIGl0IHNob3VsZCBvbmx5IGhhdmUgdGhlIGFiaWxp dHkgdG8KPj4+PiAqdXNlKiBkZXZpY2VzIGl0IGlzIGdpdmVuLCBub3QgdG8gY29ubmVjdCB0byBu ZXcgb25lcy4gKCMxNTApCj4+Pj4gKiBBZGQgYEZMT1cuZXJyb3JfbWVzc2FnZWAgdG8gdGhlIGBW MWAgbW9kdWxlIHR5cGVzIHRvIGFsbG93IGZvcgo+Pj4+IGdlbmVyaWMgaGFuZGxpbmcgb2YgZXJy b3JzLiAoIzM0NikKPj4+PiAqIEFkZCBgSVAudWlwYWRkcmAgYXMgYSB1bml2ZXJzYWwgSVAgYWRk cmVzcyB0eXBlLiAoIzM2MSkKPj4+PiAqIFN1cHBvcnQgdGhlIGBlbnRyb3B5YCB2ZXJzaW9uIDAu MisgaW50ZXJmYWNlcy4gKCMzNTkpCj4+Pj4gKiBDaGVjayB0aGF0IHRoZSBgb3BhbWAgY29tbWFu ZCBpcyBhdCBsZWFzdCB2ZXJzaW9uIDEuMi4wICgjMzU1KQo+Pj4+ICogRG9uJ3QgcHV0ICctY2xh c3NpYy1kaXNwbGF5JyBpbiB0aGUgZ2VuZXJhdGVkIE1ha2VmaWxlcy4gKCMzNjQpCj4+Pj4gCj4+ Pj4gQWx0aG91Z2ggdGhpcyBpcyBhIHNob3J0IGNoYW5nZWxvZywgdGhlIG1haW4gY2hhbmdlcyB0 aGF0IG1hdHRlcgo+Pj4+IGFyZSB0aGUgSU9fUEFHRSBhbmQgRGV2aWNlIGNvbm5lY3QgY2hhbmdl cywgd2hpY2ggcmVxdWlyZWQKPj4+PiByZXZpc2lvbnMgYWNyb3NzIGEgc2lnbmlmaWNhbnQgbnVt YmVyIG9mIHBhY2thZ2VzLiAgTWFueSB0aGFua3MgdG8KPj4+PiBUaG9tYXMgTGVvbmFyZCB3aG8g ZGlkIGEgbG90IG9mIHRoZSBsZWd3b3JrIHRvIHByb3BhZ2F0ZSB0aGUKPj4+PiByZXF1aXJlZCBj aGFuZ2VzOiBodHRwczovL2dpdGh1Yi5jb20vbWlyYWdlL21pcmFnZS9wdWxsLzM1MAo+Pj4gCj4+ PiBHcmVhdCEKPj4+IAo+Pj4+IFRoZSBmdWxsIHNldCBvZiBsaWJyYXJpZXMgdGhhdCBoYXZlIGNo YW5nZWQgYXJlIHVwIGF0Ogo+Pj4+IGh0dHA6Ly9vcGVubWlyYWdlLm9yZy9yZWxlYXNlcy8KPj4+ IAo+Pj4gb3Blbm1pcmFnZS5vcmcgaXNuJ3QgcmVzcG9uZGluZyBmb3IgbWUgKGV2ZW4gdG8gcGlu Z3MpLgo+PiAKPj4gSW50ZXJlc3RpbmcgLS0gd2UndmUgdW5jb3ZlcmVkIGEgcmFjZSBjb25kaXRp b24gaW4gdGhlIFhlbiBuZXRiYWNrCj4+IGJyaW5ndXAgd2l0aCB0aGUgbmV3IHJlbGVhc2UuICBQ dXR0aW5nIGluIGEgdmVyeSBzbWFsbCBzbGVlcCBpbgo+PiB0aGUgTmV0ZnJvbnQgaW5pdGlhbGlz YXRpb24gaXMgY2F1c2luZyB0aGUgZG9tMCBicmlkZ2UgdG8gdW53ZWRnZQo+PiBhbmQgdGhlbiB3 b3JrLiAgSSdtIGludmVzdGlnYXRpbmcgaXQsIGFsdGhvdWdoIEkgbWF5IG5lZWQgeW91cgo+PiBh c3Npc3RhbmNlIHdpdGggdGhpcyBvbmUgRGF2ZeKApgo+IAo+IFVoLW9oISBEb2VzIHRoZSBicmlk Z2UgZGV2aWNlIGFuZCB0aGUgdmlmIGRldmljZSBpbiBkb20wIGxvb2sgb2ssIGFuZAo+IGRvIHRo ZSB4ZW5zdG9yZSBiYWNrZW5kIGFuZCBmcm9udGVuZCBkaXJlY3RvcmllcyBib3RoIGhhdmUg4oCc c3RhdGUgPSA04oCdPwo+IOKAlCBJIGFzc3VtZSB0aGV5IGFsbCBsb29rIHJpZ2h0IGFuZCB0aGUg YnVnIGlzIG1vcmUgb2YgYSByYWNlIGJldHdlZW4KPiB0aGUgYmFja2VuZCBhbmQgZnJvbnRlbmQg aW5pdCBjb2RlLgo+IAo+IElmIEkgaGFkIHRvIGd1ZXNzIEkgd291bGQgdHJ5IGluc2VydGluZyBh IHhlbnN0b3JlIHdhaXQgaGVyZToKPiAKPiBodHRwczovL2dpdGh1Yi5jb20vbWlyYWdlL21pcmFn ZS1uZXQteGVuL2Jsb2IvNjM2OWFiZDgwOTA0Y2E5ODE5NGFiYzA3ZTY3NmVjZGIwYTM3MWIzYy9s aWIvbmV0aWYubWwjTDMwMAo+IAo+IHRvIHdhaXQgZm9yIHRoZSBiYWNrZW5kIHRvIGVudGVyIOKA nHN0YXRlID0gNOKAnSBiZWZvcmUgd3JpdGluZyBkYXRhIHRvIHRoZQo+IHJpbmcgYW5kIHNpZ25h bGxpbmcgdGhlIGV2ZW50IGNoYW5uZWwuIFBlcmhhcHMgaXTigJlzIHdlZGdlZCBiZWNhdXNlIHRo ZQo+IGV2ZW50IHdhcyBpZ25vcmVkLiBBIHdhaXQgbG9vcCB3b3VsZCBsb29rIGxpa2UgdGhpcyBv bmU6Cj4gCj4gaHR0cHM6Ly9naXRodWIuY29tL21pcmFnZS9taXJhZ2UtYmxvY2steGVuL2Jsb2Iv YTY0ZDE1MjU4NmM3ZWJjMWQyM2M1YWRhYTRkZGQ0NDBiNDVhM2E4My9saWIvYmxrYmFjay5tbCNM Mzg4Cj4gCj4gb25seSB3aXRoIHRoZSBjb25kaXRpb24gYmVpbmcg4oCYc3RhdGUgPSBEZXZpY2Vf c3RhdGUuKHRvX3N0cmluZyBDb25uZWN0ZWQpIgo+IAo+IE9mIGNvdXJzZSBhIHhlbnN0b3JlIHdh aXQgbWlnaHQganVzdCBiZSBhIHdvcmthcm91bmQgYnkgY2F1c2luZyBhIGRlbGF5Lgo+IFBlcmhh cHMgd2Ugc2hvdWxkIHJlYWQgdGhlIExpbnV4IG5ldGJhY2sgY29kZSB0byBzZWUgd2hhdCBpdOKA mXMgZG9pbmcuCj4gCgpJbmRlZWQsIERhdmUgdHJhY2tlZCB0aGlzIG9uZSBkb3duIHRvIHRoZSBt aXJhZ2UtbmV0LXhlbiBkcml2ZXIgbm90CndhaXRpbmcgZm9yIHRoZSBiYWNrZW5kIHRvIGJlIGZ1 bGx5IHJlYWR5LiAgSSd2ZSBtZXJnZWQgYW5kIHJlbGVhc2VkCnRoZSBmaXggaW4gaHR0cHM6Ly9n aXRodWIuY29tL29jYW1sL29wYW0tcmVwb3NpdG9yeS9wdWxsLzM3MDkuCgpUaGUgbGl2ZSBzaXRl IGlzIG5vdyBydW5uaW5nIHRoaXMsIHNvIHBsZWFzZSBkbyBsZXQgdXMga25vdyBpZiBhbnlvbmUK c2VlcyBhbnkgc3RhcnQtb2YtZGF5IHBhY2tldCBsb3NzIHdpdGggdGhpcyB2ZXJzaW9uIG9mIHRo ZSBkcml2ZXIuCgotYW5pbApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwpNaXJhZ2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlzdHMu eGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1h bi9saXN0aW5mby9taXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Thu Mar 12 14:12:17 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 12 Mar 2015 14:12:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW3qN-0001U2-RA; Thu, 12 Mar 2015 14:12:11 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW3qN-0001TG-0T for mirageos-devel@lists.xenproject.org; Thu, 12 Mar 2015 14:12:11 +0000 Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id 98/F6-08971-ABE91055; Thu, 12 Mar 2015 14:12:10 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-15.tower-27.messagelabs.com!1426169527!12321422!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11677 invoked from network); 12 Mar 2015 14:12:08 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Mar 2015 14:12:08 -0000 Received: from dhcp-172-17-152-33.eduroam.wireless.private.cam.ac.uk (global-1-26.nat.csx.cam.ac.uk [131.111.184.26]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id c112c719; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Thu, 12 Mar 2015 14:12:05 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Anil Madhavapeddy In-Reply-To: Date: Thu, 12 Mar 2015 14:12:08 +0000 Message-Id: <4585B3C5-3E11-4C0D-B74E-ADAD9A627A3E@recoil.org> References: <727D7526-88DA-46F2-894A-F5CC7A68BEBF@recoil.org> To: David Scott X-Mailer: Apple Mail (2.2070.6) Cc: mirageos-devel Subject: Re: [MirageOS-devel] ANN: mirage.2.3.0 released X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Cj4gT24gMTAgTWFyIDIwMTUsIGF0IDE0OjQxLCBEYXZlIFNjb3R0IDxEYXZlLlNjb3R0QGNpdHJp eC5jb20+IHdyb3RlOgo+IAo+IAo+PiBPbiAxMCBNYXIgMjAxNSwgYXQgMTQ6MTcsIEFuaWwgTWFk aGF2YXBlZGR5IDxhbmlsQHJlY29pbC5vcmc+IHdyb3RlOgo+PiAKPj4gT24gMTAgTWFyIDIwMTUs IGF0IDE0OjAxLCBUaG9tYXMgTGVvbmFyZCA8dGFsZXg1QGdtYWlsLmNvbT4gd3JvdGU6Cj4+PiAK Pj4+IE9uIDEwIE1hcmNoIDIwMTUgYXQgMTM6NDYsIEFuaWwgTWFkaGF2YXBlZGR5IDxhbmlsQHJl Y29pbC5vcmc+IHdyb3RlOgo+Pj4+IEkndmUganVzdCByZWxlYXNlZCBNaXJhZ2UgMi4zLjAgdG8g T1BBTS4gIFRoaXMgaXMgYSBwb2ludCByZWxlYXNlCj4+Pj4gd2l0aCBzZXZlcmFsIGltcG9ydGFu dCBjbGVhbnVwcyBpbiB0aGUgaW50ZXJmYWNlczoKPj4+PiBodHRwczovL2dpdGh1Yi5jb20vbWly YWdlL21pcmFnZS9yZWxlYXNlcy90YWcvdjIuMy4wCj4+Pj4gCj4+Pj4gKiBSZW1vdmUgdGhlIGBJ T19QQUdFYCBtb2R1bGUgdHlwZSBmcm9tIGBWMWAuIFRoaXMgaGFzIG5vdyBtb3ZlZAo+Pj4+IGlu dG8gdGhlIGBpby1wYWdlYCBwYWNha2dlICgjMzU2KQo+Pj4+ICogUmVtb3ZlIGBERVZJQ0UuY29u bmVjdGAgZnJvbSB0aGUgYFYxYCBtb2R1bGUgdHlwZXMuICBXaGVuIGEgbW9kdWxlIGlzCj4+Pj4g ZnVuY3RvcmlzZWQgb3ZlciBhIGBERVZJQ0VgIGl0IHNob3VsZCBvbmx5IGhhdmUgdGhlIGFiaWxp dHkgdG8KPj4+PiAqdXNlKiBkZXZpY2VzIGl0IGlzIGdpdmVuLCBub3QgdG8gY29ubmVjdCB0byBu ZXcgb25lcy4gKCMxNTApCj4+Pj4gKiBBZGQgYEZMT1cuZXJyb3JfbWVzc2FnZWAgdG8gdGhlIGBW MWAgbW9kdWxlIHR5cGVzIHRvIGFsbG93IGZvcgo+Pj4+IGdlbmVyaWMgaGFuZGxpbmcgb2YgZXJy b3JzLiAoIzM0NikKPj4+PiAqIEFkZCBgSVAudWlwYWRkcmAgYXMgYSB1bml2ZXJzYWwgSVAgYWRk cmVzcyB0eXBlLiAoIzM2MSkKPj4+PiAqIFN1cHBvcnQgdGhlIGBlbnRyb3B5YCB2ZXJzaW9uIDAu MisgaW50ZXJmYWNlcy4gKCMzNTkpCj4+Pj4gKiBDaGVjayB0aGF0IHRoZSBgb3BhbWAgY29tbWFu ZCBpcyBhdCBsZWFzdCB2ZXJzaW9uIDEuMi4wICgjMzU1KQo+Pj4+ICogRG9uJ3QgcHV0ICctY2xh c3NpYy1kaXNwbGF5JyBpbiB0aGUgZ2VuZXJhdGVkIE1ha2VmaWxlcy4gKCMzNjQpCj4+Pj4gCj4+ Pj4gQWx0aG91Z2ggdGhpcyBpcyBhIHNob3J0IGNoYW5nZWxvZywgdGhlIG1haW4gY2hhbmdlcyB0 aGF0IG1hdHRlcgo+Pj4+IGFyZSB0aGUgSU9fUEFHRSBhbmQgRGV2aWNlIGNvbm5lY3QgY2hhbmdl cywgd2hpY2ggcmVxdWlyZWQKPj4+PiByZXZpc2lvbnMgYWNyb3NzIGEgc2lnbmlmaWNhbnQgbnVt YmVyIG9mIHBhY2thZ2VzLiAgTWFueSB0aGFua3MgdG8KPj4+PiBUaG9tYXMgTGVvbmFyZCB3aG8g ZGlkIGEgbG90IG9mIHRoZSBsZWd3b3JrIHRvIHByb3BhZ2F0ZSB0aGUKPj4+PiByZXF1aXJlZCBj aGFuZ2VzOiBodHRwczovL2dpdGh1Yi5jb20vbWlyYWdlL21pcmFnZS9wdWxsLzM1MAo+Pj4gCj4+ PiBHcmVhdCEKPj4+IAo+Pj4+IFRoZSBmdWxsIHNldCBvZiBsaWJyYXJpZXMgdGhhdCBoYXZlIGNo YW5nZWQgYXJlIHVwIGF0Ogo+Pj4+IGh0dHA6Ly9vcGVubWlyYWdlLm9yZy9yZWxlYXNlcy8KPj4+ IAo+Pj4gb3Blbm1pcmFnZS5vcmcgaXNuJ3QgcmVzcG9uZGluZyBmb3IgbWUgKGV2ZW4gdG8gcGlu Z3MpLgo+PiAKPj4gSW50ZXJlc3RpbmcgLS0gd2UndmUgdW5jb3ZlcmVkIGEgcmFjZSBjb25kaXRp b24gaW4gdGhlIFhlbiBuZXRiYWNrCj4+IGJyaW5ndXAgd2l0aCB0aGUgbmV3IHJlbGVhc2UuICBQ dXR0aW5nIGluIGEgdmVyeSBzbWFsbCBzbGVlcCBpbgo+PiB0aGUgTmV0ZnJvbnQgaW5pdGlhbGlz YXRpb24gaXMgY2F1c2luZyB0aGUgZG9tMCBicmlkZ2UgdG8gdW53ZWRnZQo+PiBhbmQgdGhlbiB3 b3JrLiAgSSdtIGludmVzdGlnYXRpbmcgaXQsIGFsdGhvdWdoIEkgbWF5IG5lZWQgeW91cgo+PiBh c3Npc3RhbmNlIHdpdGggdGhpcyBvbmUgRGF2ZeKApgo+IAo+IFVoLW9oISBEb2VzIHRoZSBicmlk Z2UgZGV2aWNlIGFuZCB0aGUgdmlmIGRldmljZSBpbiBkb20wIGxvb2sgb2ssIGFuZAo+IGRvIHRo ZSB4ZW5zdG9yZSBiYWNrZW5kIGFuZCBmcm9udGVuZCBkaXJlY3RvcmllcyBib3RoIGhhdmUg4oCc c3RhdGUgPSA04oCdPwo+IOKAlCBJIGFzc3VtZSB0aGV5IGFsbCBsb29rIHJpZ2h0IGFuZCB0aGUg YnVnIGlzIG1vcmUgb2YgYSByYWNlIGJldHdlZW4KPiB0aGUgYmFja2VuZCBhbmQgZnJvbnRlbmQg aW5pdCBjb2RlLgo+IAo+IElmIEkgaGFkIHRvIGd1ZXNzIEkgd291bGQgdHJ5IGluc2VydGluZyBh IHhlbnN0b3JlIHdhaXQgaGVyZToKPiAKPiBodHRwczovL2dpdGh1Yi5jb20vbWlyYWdlL21pcmFn ZS1uZXQteGVuL2Jsb2IvNjM2OWFiZDgwOTA0Y2E5ODE5NGFiYzA3ZTY3NmVjZGIwYTM3MWIzYy9s aWIvbmV0aWYubWwjTDMwMAo+IAo+IHRvIHdhaXQgZm9yIHRoZSBiYWNrZW5kIHRvIGVudGVyIOKA nHN0YXRlID0gNOKAnSBiZWZvcmUgd3JpdGluZyBkYXRhIHRvIHRoZQo+IHJpbmcgYW5kIHNpZ25h bGxpbmcgdGhlIGV2ZW50IGNoYW5uZWwuIFBlcmhhcHMgaXTigJlzIHdlZGdlZCBiZWNhdXNlIHRo ZQo+IGV2ZW50IHdhcyBpZ25vcmVkLiBBIHdhaXQgbG9vcCB3b3VsZCBsb29rIGxpa2UgdGhpcyBv bmU6Cj4gCj4gaHR0cHM6Ly9naXRodWIuY29tL21pcmFnZS9taXJhZ2UtYmxvY2steGVuL2Jsb2Iv YTY0ZDE1MjU4NmM3ZWJjMWQyM2M1YWRhYTRkZGQ0NDBiNDVhM2E4My9saWIvYmxrYmFjay5tbCNM Mzg4Cj4gCj4gb25seSB3aXRoIHRoZSBjb25kaXRpb24gYmVpbmcg4oCYc3RhdGUgPSBEZXZpY2Vf c3RhdGUuKHRvX3N0cmluZyBDb25uZWN0ZWQpIgo+IAo+IE9mIGNvdXJzZSBhIHhlbnN0b3JlIHdh aXQgbWlnaHQganVzdCBiZSBhIHdvcmthcm91bmQgYnkgY2F1c2luZyBhIGRlbGF5Lgo+IFBlcmhh cHMgd2Ugc2hvdWxkIHJlYWQgdGhlIExpbnV4IG5ldGJhY2sgY29kZSB0byBzZWUgd2hhdCBpdOKA mXMgZG9pbmcuCj4gCgpJbmRlZWQsIERhdmUgdHJhY2tlZCB0aGlzIG9uZSBkb3duIHRvIHRoZSBt aXJhZ2UtbmV0LXhlbiBkcml2ZXIgbm90CndhaXRpbmcgZm9yIHRoZSBiYWNrZW5kIHRvIGJlIGZ1 bGx5IHJlYWR5LiAgSSd2ZSBtZXJnZWQgYW5kIHJlbGVhc2VkCnRoZSBmaXggaW4gaHR0cHM6Ly9n aXRodWIuY29tL29jYW1sL29wYW0tcmVwb3NpdG9yeS9wdWxsLzM3MDkuCgpUaGUgbGl2ZSBzaXRl IGlzIG5vdyBydW5uaW5nIHRoaXMsIHNvIHBsZWFzZSBkbyBsZXQgdXMga25vdyBpZiBhbnlvbmUK c2VlcyBhbnkgc3RhcnQtb2YtZGF5IHBhY2tldCBsb3NzIHdpdGggdGhpcyB2ZXJzaW9uIG9mIHRo ZSBkcml2ZXIuCgotYW5pbApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwpNaXJhZ2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlzdHMu eGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1h bi9saXN0aW5mby9taXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Thu Mar 12 15:59:06 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 12 Mar 2015 15:59:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW5Vm-0006ue-KG; Thu, 12 Mar 2015 15:59:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW5Vk-0006uU-Tn for mirageos-devel@lists.xenproject.org; Thu, 12 Mar 2015 15:59:01 +0000 Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id 34/20-09376-4C7B1055; Thu, 12 Mar 2015 15:59:00 +0000 X-Env-Sender: lukedunstan81@gmail.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1426175938!5951944!1 X-Originating-IP: [209.85.217.172] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16456 invoked from network); 12 Mar 2015 15:58:58 -0000 Received: from mail-lb0-f172.google.com (HELO mail-lb0-f172.google.com) (209.85.217.172) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2015 15:58:58 -0000 Received: by lbdu10 with SMTP id u10so16935673lbd.4 for ; Thu, 12 Mar 2015 08:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a4fjIpVl5gbZATECKocZCRvp9S4/T5/fdInX1qrGe8w=; b=l9hVD6GgD4B4cok5x5A2vd2o2a+pebtPvfPPMZuILmrRxRgZget57zsJXkqKXxk5ZF uyPx/rVx02ebZ9qOC2yDRLL3StlK4Xbaiq0IbD+OCoVnZ8/PDn6FSr5AT+2rGgWj/L3C lRgCR12PyydMT26TFvtviMZoLZvAuc9bbrM6MtdbLbbXIgifylqPSp+NOoxKfa+DjvMu i73dzrAvzKlCnip0RCturzDG16Pp6DWG9HjSpIG3z9SgIIA4/QzAJXxud5cpGUENya1w BadflT33ZhutKq5HRomPUBy2tHBQN4rF7FQ7FCfgAkem8OKlaiszDYS946NFXdmTHda0 da+Q== MIME-Version: 1.0 X-Received: by 10.152.7.132 with SMTP id j4mr40091703laa.100.1426175938121; Thu, 12 Mar 2015 08:58:58 -0700 (PDT) Received: by 10.112.163.134 with HTTP; Thu, 12 Mar 2015 08:58:58 -0700 (PDT) In-Reply-To: <55018C89.9020905@somerandomidiot.com> References: <55018C89.9020905@somerandomidiot.com> Date: Thu, 12 Mar 2015 23:58:58 +0800 Message-ID: From: Luke Dunstan To: Mindy Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] netif that reads from pcap / hoards writes X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1825287433847634897==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============1825287433847634897== Content-Type: multipart/alternative; boundary=001a11c239cc2e83270511197655 --001a11c239cc2e83270511197655 Content-Type: text/plain; charset=UTF-8 Cool idea. For most tests I think it would be an advantage to use a stub implementation of OS.Time.sleep so that the tests would run almost instantly, regardless of time-outs. When you need to verify that the unit under test is sleeping for the correct amount of time then you'd need to record the calls to sleep, or something similar. The ARP test fails for me on test_queries_retried (extra debug messages added): ARP: sending gratuitous from 192.168.2.222 ARP: updating 192.168.2.7 -> 00:16:3e:7b:2b:4d ARP: transmitting probe -> 192.168.2.4 # written: 2 ff ff ff ff ff ff ff ff ff ff ff ff 08 06 00 01 08 00 06 04 00 01 ff ff ff ff ff ff c0 a8 02 de ff ff ff ff ff ff c0 a8 02 04 ff ff ff ff ff ff ff ff ff ff ff ff 08 06 00 01 08 00 06 04 00 02 ff ff ff ff ff ff c0 a8 02 de ff ff ff ff ff ff 00 00 00 00 Fatal error: exception OUnitTest.OUnit_failure("expected: Success but got: Last 3 sent packets weren't ARP probes") Raised at file "src/core/lwt.ml", line 894, characters 22-23 Called from file "src/unix/lwt_main.ml", line 34, characters 8-18 Called from file "main.ml", line 36, characters 2-28 Looks like the second packet is a gratuitous ARP. Luke On 12 March 2015 at 20:54, Mindy wrote: > Hi all, > > I've just made public `mirage-net-pcap`, a module that satisfies > V1.NETWORK by supplying packets from a prerecorded pcap file (via crunch) > and keeping written packets in memory for later examination. You can see > it at https://github.com/yomimono/mirage-net-pcap , and there's an > example unikernel using it under `arp_tester` in my example-unikernels > repository at https://github.com/yomimono/example-unikernels . > `mirage-net-pcap` works with both unix and xen backends, although the > example code works only with Unix because of its use of oUnit. > > Right now there isn't facility for saving writes to persistent storage > (i.e., writing to a pcap). I started writing this and then realized it was > generally the opposite of what I actually wanted when writing testing code > that used `mirage-net-pcap`, but I do plan on adding this in a later > release. > > I don't have a fork of the mirage frontend tool that nicely sets up a > netif in `config.ml` for the user currently, but stacks can be built on > top of one in the normal way (i.e., as in `mirage-skeleton/ethifv4`). > > Bad, horrible, okay, other? > > -Mindy > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > --001a11c239cc2e83270511197655 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Cool idea.

For most tests I think it wo= uld be an advantage to use a stub implementation of OS.Time.sleep so that t= he tests would run almost instantly, regardless of time-outs. When you need= to verify that the unit under test is sleeping for the correct amount of t= ime then you'd need to record the calls to sleep, or something similar.=

The ARP test fails for me on=C2=A0test_queries_retried = (extra debug messages added):

ARP: sending gratuitous from 192.168.2.222
= ARP: updating 192.168.2.7 -> 00:16:3= e:7b:2b:4d
ARP: transm= itting probe -> 192.168.2.4
# written: 2
=
ff ff ff ff ff ff= ff ff ff ff ff ff 08 06 00 01=C2=A0
08 00 06 04 00 01 ff ff ff ff ff ff c0 a8 02 de=C2=A0=
ff ff ff ff ff ff c0 a8 02 0= 4=C2=A0

ff ff ff ff ff ff ff ff ff ff f= f ff 08 06 00 01=C2=A0
08 00 06 04 00 02 ff ff ff ff ff ff c0 a8 02 de=C2=A0
ff ff ff ff ff ff 00 00 00 00=C2=A0=
Fatal error: exception OUnit= Test.OUnit_failure("expected: Success but got: Last 3 sent packets wer= en't ARP probes")
Raised at file "src/core/lwt.ml&quo= t;, line 894, characters 22-23
Called from file "src/unix/lwt= _main.ml", line 34, characters 8-18
Called from file "ma= in.ml", line 36, characters 2-28

=
Looks like the second packet is a gratuitous ARP.
=

Luke


On 12 March 2015 at 20:54, = Mindy <mindy@somerandomidiot.com> wrote:
Hi all,

I've just made public `mirage-net-pcap`, a module that satisfies V1.NET= WORK by supplying packets from a prerecorded pcap file (via crunch) and kee= ping written packets in memory for later examination.=C2=A0 You can see it = at https://github.com/yomimono/mirage-net-pcap , and there's = an example unikernel using it under `arp_tester` in my example-unikernels r= epository at https://github.com/yomimono/example-unikernels . = `mirage-net-pcap` works with both unix and xen backends, although the examp= le code works only with Unix because of its use of oUnit.

Right now there isn't facility for saving writes to persistent storage = (i.e., writing to a pcap).=C2=A0 I started writing this and then realized i= t was generally the opposite of what I actually wanted when writing testing= code that used `mirage-net-pcap`, but I do plan on adding this in a later = release.

I don't have a fork of the mirage frontend tool that nicely sets up a n= etif in `config.ml` for = the user currently, but stacks can be built on top of one in the normal way= (i.e., as in `mirage-skeleton/ethifv4`).

Bad, horrible, okay, other?

-Mindy

_______________________________________________
MirageOS-devel mailing list
Mi= rageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/l= istinfo/mirageos-devel

--001a11c239cc2e83270511197655-- --===============1825287433847634897== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============1825287433847634897==-- From mirageos-devel-bounces@lists.xenproject.org Thu Mar 12 15:59:06 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 12 Mar 2015 15:59:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW5Vm-0006ue-KG; Thu, 12 Mar 2015 15:59:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW5Vk-0006uU-Tn for mirageos-devel@lists.xenproject.org; Thu, 12 Mar 2015 15:59:01 +0000 Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id 34/20-09376-4C7B1055; Thu, 12 Mar 2015 15:59:00 +0000 X-Env-Sender: lukedunstan81@gmail.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1426175938!5951944!1 X-Originating-IP: [209.85.217.172] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16456 invoked from network); 12 Mar 2015 15:58:58 -0000 Received: from mail-lb0-f172.google.com (HELO mail-lb0-f172.google.com) (209.85.217.172) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2015 15:58:58 -0000 Received: by lbdu10 with SMTP id u10so16935673lbd.4 for ; Thu, 12 Mar 2015 08:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a4fjIpVl5gbZATECKocZCRvp9S4/T5/fdInX1qrGe8w=; b=l9hVD6GgD4B4cok5x5A2vd2o2a+pebtPvfPPMZuILmrRxRgZget57zsJXkqKXxk5ZF uyPx/rVx02ebZ9qOC2yDRLL3StlK4Xbaiq0IbD+OCoVnZ8/PDn6FSr5AT+2rGgWj/L3C lRgCR12PyydMT26TFvtviMZoLZvAuc9bbrM6MtdbLbbXIgifylqPSp+NOoxKfa+DjvMu i73dzrAvzKlCnip0RCturzDG16Pp6DWG9HjSpIG3z9SgIIA4/QzAJXxud5cpGUENya1w BadflT33ZhutKq5HRomPUBy2tHBQN4rF7FQ7FCfgAkem8OKlaiszDYS946NFXdmTHda0 da+Q== MIME-Version: 1.0 X-Received: by 10.152.7.132 with SMTP id j4mr40091703laa.100.1426175938121; Thu, 12 Mar 2015 08:58:58 -0700 (PDT) Received: by 10.112.163.134 with HTTP; Thu, 12 Mar 2015 08:58:58 -0700 (PDT) In-Reply-To: <55018C89.9020905@somerandomidiot.com> References: <55018C89.9020905@somerandomidiot.com> Date: Thu, 12 Mar 2015 23:58:58 +0800 Message-ID: From: Luke Dunstan To: Mindy Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] netif that reads from pcap / hoards writes X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1825287433847634897==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============1825287433847634897== Content-Type: multipart/alternative; boundary=001a11c239cc2e83270511197655 --001a11c239cc2e83270511197655 Content-Type: text/plain; charset=UTF-8 Cool idea. For most tests I think it would be an advantage to use a stub implementation of OS.Time.sleep so that the tests would run almost instantly, regardless of time-outs. When you need to verify that the unit under test is sleeping for the correct amount of time then you'd need to record the calls to sleep, or something similar. The ARP test fails for me on test_queries_retried (extra debug messages added): ARP: sending gratuitous from 192.168.2.222 ARP: updating 192.168.2.7 -> 00:16:3e:7b:2b:4d ARP: transmitting probe -> 192.168.2.4 # written: 2 ff ff ff ff ff ff ff ff ff ff ff ff 08 06 00 01 08 00 06 04 00 01 ff ff ff ff ff ff c0 a8 02 de ff ff ff ff ff ff c0 a8 02 04 ff ff ff ff ff ff ff ff ff ff ff ff 08 06 00 01 08 00 06 04 00 02 ff ff ff ff ff ff c0 a8 02 de ff ff ff ff ff ff 00 00 00 00 Fatal error: exception OUnitTest.OUnit_failure("expected: Success but got: Last 3 sent packets weren't ARP probes") Raised at file "src/core/lwt.ml", line 894, characters 22-23 Called from file "src/unix/lwt_main.ml", line 34, characters 8-18 Called from file "main.ml", line 36, characters 2-28 Looks like the second packet is a gratuitous ARP. Luke On 12 March 2015 at 20:54, Mindy wrote: > Hi all, > > I've just made public `mirage-net-pcap`, a module that satisfies > V1.NETWORK by supplying packets from a prerecorded pcap file (via crunch) > and keeping written packets in memory for later examination. You can see > it at https://github.com/yomimono/mirage-net-pcap , and there's an > example unikernel using it under `arp_tester` in my example-unikernels > repository at https://github.com/yomimono/example-unikernels . > `mirage-net-pcap` works with both unix and xen backends, although the > example code works only with Unix because of its use of oUnit. > > Right now there isn't facility for saving writes to persistent storage > (i.e., writing to a pcap). I started writing this and then realized it was > generally the opposite of what I actually wanted when writing testing code > that used `mirage-net-pcap`, but I do plan on adding this in a later > release. > > I don't have a fork of the mirage frontend tool that nicely sets up a > netif in `config.ml` for the user currently, but stacks can be built on > top of one in the normal way (i.e., as in `mirage-skeleton/ethifv4`). > > Bad, horrible, okay, other? > > -Mindy > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > --001a11c239cc2e83270511197655 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Cool idea.

For most tests I think it wo= uld be an advantage to use a stub implementation of OS.Time.sleep so that t= he tests would run almost instantly, regardless of time-outs. When you need= to verify that the unit under test is sleeping for the correct amount of t= ime then you'd need to record the calls to sleep, or something similar.=

The ARP test fails for me on=C2=A0test_queries_retried = (extra debug messages added):

ARP: sending gratuitous from 192.168.2.222
= ARP: updating 192.168.2.7 -> 00:16:3= e:7b:2b:4d
ARP: transm= itting probe -> 192.168.2.4
# written: 2
=
ff ff ff ff ff ff= ff ff ff ff ff ff 08 06 00 01=C2=A0
08 00 06 04 00 01 ff ff ff ff ff ff c0 a8 02 de=C2=A0=
ff ff ff ff ff ff c0 a8 02 0= 4=C2=A0

ff ff ff ff ff ff ff ff ff ff f= f ff 08 06 00 01=C2=A0
08 00 06 04 00 02 ff ff ff ff ff ff c0 a8 02 de=C2=A0
ff ff ff ff ff ff 00 00 00 00=C2=A0=
Fatal error: exception OUnit= Test.OUnit_failure("expected: Success but got: Last 3 sent packets wer= en't ARP probes")
Raised at file "src/core/lwt.ml&quo= t;, line 894, characters 22-23
Called from file "src/unix/lwt= _main.ml", line 34, characters 8-18
Called from file "ma= in.ml", line 36, characters 2-28

=
Looks like the second packet is a gratuitous ARP.
=

Luke


On 12 March 2015 at 20:54, = Mindy <mindy@somerandomidiot.com> wrote:
Hi all,

I've just made public `mirage-net-pcap`, a module that satisfies V1.NET= WORK by supplying packets from a prerecorded pcap file (via crunch) and kee= ping written packets in memory for later examination.=C2=A0 You can see it = at https://github.com/yomimono/mirage-net-pcap , and there's = an example unikernel using it under `arp_tester` in my example-unikernels r= epository at https://github.com/yomimono/example-unikernels . = `mirage-net-pcap` works with both unix and xen backends, although the examp= le code works only with Unix because of its use of oUnit.

Right now there isn't facility for saving writes to persistent storage = (i.e., writing to a pcap).=C2=A0 I started writing this and then realized i= t was generally the opposite of what I actually wanted when writing testing= code that used `mirage-net-pcap`, but I do plan on adding this in a later = release.

I don't have a fork of the mirage frontend tool that nicely sets up a n= etif in `config.ml` for = the user currently, but stacks can be built on top of one in the normal way= (i.e., as in `mirage-skeleton/ethifv4`).

Bad, horrible, okay, other?

-Mindy

_______________________________________________
MirageOS-devel mailing list
Mi= rageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/l= istinfo/mirageos-devel

--001a11c239cc2e83270511197655-- --===============1825287433847634897== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============1825287433847634897==-- From mirageos-devel-bounces@lists.xenproject.org Thu Mar 12 16:06:15 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 12 Mar 2015 16:06:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW5cj-0008EQ-TB; Thu, 12 Mar 2015 16:06:13 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW5ci-0008DJ-KK for mirageos-devel@lists.xenproject.org; Thu, 12 Mar 2015 16:06:12 +0000 Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id 7D/1A-28243-379B1055; Thu, 12 Mar 2015 16:06:11 +0000 X-Env-Sender: mindy@somerandomidiot.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1426176370!12327028!1 X-Originating-IP: [217.70.183.196] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTYgPT4gMzk1MTY=\n X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24996 invoked from network); 12 Mar 2015 16:06:10 -0000 Received: from relay4-d.mail.gandi.net (HELO relay4-d.mail.gandi.net) (217.70.183.196) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Mar 2015 16:06:10 -0000 Received: from mfilter27-d.gandi.net (mfilter27-d.gandi.net [217.70.178.155]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 03B1F1720BF; Thu, 12 Mar 2015 17:06:10 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter27-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter27-d.gandi.net (mfilter27-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 3Plqhtze-nb3; Thu, 12 Mar 2015 17:06:08 +0100 (CET) X-Originating-IP: 131.111.184.18 Received: from [172.17.25.233] (global-1-18.nat.csx.cam.ac.uk [131.111.184.18]) (Authenticated sender: guybrush@somerandomidiot.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 9A4361720A1; Thu, 12 Mar 2015 17:06:06 +0100 (CET) Message-ID: <5501B96C.1060200@somerandomidiot.com> Date: Thu, 12 Mar 2015 16:06:04 +0000 From: Mindy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Luke Dunstan References: <55018C89.9020905@somerandomidiot.com> In-Reply-To: Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] netif that reads from pcap / hoards writes X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2764600792117324223==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org This is a multi-part message in MIME format. --===============2764600792117324223== Content-Type: multipart/alternative; boundary="------------060104040701010505020807" This is a multi-part message in MIME format. --------------060104040701010505020807 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Luke, Ah, I'd thought of regulating the delays in the playback, but not of supplying other stuff in the stack with a stubbed-out OS.Time.sleep. That's a good idea. The ARP test correctly fails on the current tcpip -- my motivation for writing this particular test was to be able to make some claims about a pull request I made some time ago to mirage-tcpip. I'm currently using it to test whether my attempts to make a better patch for ARP are, in fact, actually better. I should probably add something to the README to that effect. -Mindy On 03/12/2015 03:58 PM, Luke Dunstan wrote: > Cool idea. > > For most tests I think it would be an advantage to use a stub > implementation of OS.Time.sleep so that the tests would run almost > instantly, regardless of time-outs. When you need to verify that the > unit under test is sleeping for the correct amount of time then you'd > need to record the calls to sleep, or something similar. > > The ARP test fails for me on test_queries_retried (extra debug > messages added): > > ARP: sending gratuitous from 192.168.2.222 > ARP: updating 192.168.2.7 -> 00:16:3e:7b:2b:4d > ARP: transmitting probe -> 192.168.2.4 > # written: 2 > > ff ff ff ff ff ff ff ff ff ff ff ff 08 06 00 01 > 08 00 06 04 00 01 ff ff ff ff ff ff c0 a8 02 de > ff ff ff ff ff ff c0 a8 02 04 > > ff ff ff ff ff ff ff ff ff ff ff ff 08 06 00 01 > 08 00 06 04 00 02 ff ff ff ff ff ff c0 a8 02 de > ff ff ff ff ff ff 00 00 00 00 > Fatal error: exception OUnitTest.OUnit_failure("expected: Success but > got: Last 3 sent packets weren't ARP probes") > Raised at file "src/core/lwt.ml ", line 894, characters > 22-23 > Called from file "src/unix/lwt_main.ml ", line 34, > characters 8-18 > Called from file "main.ml ", line 36, characters 2-28 > > Looks like the second packet is a gratuitous ARP. > > Luke > > > On 12 March 2015 at 20:54, Mindy > wrote: > > Hi all, > > I've just made public `mirage-net-pcap`, a module that satisfies > V1.NETWORK by supplying packets from a prerecorded pcap file (via > crunch) and keeping written packets in memory for later > examination. You can see it at > https://github.com/yomimono/mirage-net-pcap , and there's an > example unikernel using it under `arp_tester` in my > example-unikernels repository at > https://github.com/yomimono/example-unikernels . `mirage-net-pcap` > works with both unix and xen backends, although the example code > works only with Unix because of its use of oUnit. > > Right now there isn't facility for saving writes to persistent > storage (i.e., writing to a pcap). I started writing this and > then realized it was generally the opposite of what I actually > wanted when writing testing code that used `mirage-net-pcap`, but > I do plan on adding this in a later release. > > I don't have a fork of the mirage frontend tool that nicely sets > up a netif in `config.ml ` for the user > currently, but stacks can be built on top of one in the normal way > (i.e., as in `mirage-skeleton/ethifv4`). > > Bad, horrible, okay, other? > > -Mindy > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > --------------060104040701010505020807 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Luke,

Ah, I'd thought of regulating the delays in the playback, but not of supplying other stuff in the stack with a stubbed-out OS.Time.sleep.=C2=A0 That's a good idea.

The ARP test correctly fails on the current tcpip -- my motivation for writing this particular test was to be able to make some claims about a pull request I made some time ago to mirage-tcpip.=C2=A0 I'm currently using it to test whether my attempts to make a better patch for ARP are, in fact, actually better.=C2=A0 I should probably = add something to the README to that effect.

-Mindy

On 03/12/2015 03:58 PM, Luke Dunstan wrote:
Cool idea.

For most tests I think it would be an advantage to use a stub implementation of OS.Time.sleep so that the tests would run almost instantly, regardless of time-outs. When you need to verify that the unit under test is sleeping for the correct amount of time then you'd need to record the calls to sleep, or something similar.

The ARP test fails for me on=C2=A0test_queries_retried (ex= tra debug messages added):

ARP: sending gratuitous from 192.168.2.222
ARP: updating 192.168.2.7 -> 00:16:3e:7b:2b:4d
ARP: transmitting probe -> 192.168.2.4
# written: 2

ff ff ff ff ff ff ff ff ff ff ff ff 08 06 00 01=C2=A0
08 00 06 04 00 01 ff ff ff ff ff ff c0 a8 02 de=C2=A0
ff ff ff ff ff ff c0 a8 02 04=C2=A0

ff ff ff ff ff ff ff ff ff ff ff ff 08 06 00 01=C2=A0
08 00 06 04 00 02 ff ff ff ff ff ff c0 a8 02 de=C2=A0
ff ff ff ff ff ff 00 00 00 00=C2=A0
Fatal error: exception OUnitTest.OUnit_failure("expected: Success but got: Last 3 sent packets weren't ARP probes")
Raised at file "src/core/lwt.ml", line 894, characters 22-23
Called from file "src/unix/lwt_main.ml", line 34= , characters 8-18
Called from file "= main= .ml", line 36, characters 2-28

Looks like the second packet is a gratuitous ARP.

Luke


On 12 March 2015 at 20:54, Mindy <mindy@somerandomidiot.com> wrote:
Hi all,

I've just made public `mirage-net-pcap`, a module that satisfies V1.NETWORK by supplying packets from a prerecorded pcap file (via crunch) and keeping written packets in memory for later examination.=C2=A0 You can see it at https://github.com/yomimono/mirage-net-pc= ap , and there's an example unikernel using it under `arp_tester` in my example-unikernels repository at https://github.com/yomimono/example-unike= rnels . `mirage-net-pcap` works with both unix and xen backends, although the example code works only with Unix because of its use of oUnit.

Right now there isn't facility for saving writes to persistent storage (i.e., writing to a pcap).=C2=A0 I started writing this and then realized it was generally the opposite of what I actually wanted when writing testing code that used `mirage-net-pcap`, but I do plan on adding this in a later release.

I don't have a fork of the mirage frontend tool that nicely sets up a netif in `config.ml` = for the user currently, but stacks can be built on top of one in the normal way (i.e., as in `mirage-skeleton/ethifv4`).

Bad, horrible, okay, other?

-Mindy

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailm= an/listinfo/mirageos-devel


--------------060104040701010505020807-- --===============2764600792117324223== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============2764600792117324223==-- From mirageos-devel-bounces@lists.xenproject.org Thu Mar 12 16:06:15 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 12 Mar 2015 16:06:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW5cj-0008EQ-TB; Thu, 12 Mar 2015 16:06:13 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YW5ci-0008DJ-KK for mirageos-devel@lists.xenproject.org; Thu, 12 Mar 2015 16:06:12 +0000 Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id 7D/1A-28243-379B1055; Thu, 12 Mar 2015 16:06:11 +0000 X-Env-Sender: mindy@somerandomidiot.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1426176370!12327028!1 X-Originating-IP: [217.70.183.196] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTYgPT4gMzk1MTY=\n X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24996 invoked from network); 12 Mar 2015 16:06:10 -0000 Received: from relay4-d.mail.gandi.net (HELO relay4-d.mail.gandi.net) (217.70.183.196) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Mar 2015 16:06:10 -0000 Received: from mfilter27-d.gandi.net (mfilter27-d.gandi.net [217.70.178.155]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 03B1F1720BF; Thu, 12 Mar 2015 17:06:10 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter27-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter27-d.gandi.net (mfilter27-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 3Plqhtze-nb3; Thu, 12 Mar 2015 17:06:08 +0100 (CET) X-Originating-IP: 131.111.184.18 Received: from [172.17.25.233] (global-1-18.nat.csx.cam.ac.uk [131.111.184.18]) (Authenticated sender: guybrush@somerandomidiot.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 9A4361720A1; Thu, 12 Mar 2015 17:06:06 +0100 (CET) Message-ID: <5501B96C.1060200@somerandomidiot.com> Date: Thu, 12 Mar 2015 16:06:04 +0000 From: Mindy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Luke Dunstan References: <55018C89.9020905@somerandomidiot.com> In-Reply-To: Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] netif that reads from pcap / hoards writes X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2764600792117324223==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org This is a multi-part message in MIME format. --===============2764600792117324223== Content-Type: multipart/alternative; boundary="------------060104040701010505020807" This is a multi-part message in MIME format. --------------060104040701010505020807 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Luke, Ah, I'd thought of regulating the delays in the playback, but not of supplying other stuff in the stack with a stubbed-out OS.Time.sleep. That's a good idea. The ARP test correctly fails on the current tcpip -- my motivation for writing this particular test was to be able to make some claims about a pull request I made some time ago to mirage-tcpip. I'm currently using it to test whether my attempts to make a better patch for ARP are, in fact, actually better. I should probably add something to the README to that effect. -Mindy On 03/12/2015 03:58 PM, Luke Dunstan wrote: > Cool idea. > > For most tests I think it would be an advantage to use a stub > implementation of OS.Time.sleep so that the tests would run almost > instantly, regardless of time-outs. When you need to verify that the > unit under test is sleeping for the correct amount of time then you'd > need to record the calls to sleep, or something similar. > > The ARP test fails for me on test_queries_retried (extra debug > messages added): > > ARP: sending gratuitous from 192.168.2.222 > ARP: updating 192.168.2.7 -> 00:16:3e:7b:2b:4d > ARP: transmitting probe -> 192.168.2.4 > # written: 2 > > ff ff ff ff ff ff ff ff ff ff ff ff 08 06 00 01 > 08 00 06 04 00 01 ff ff ff ff ff ff c0 a8 02 de > ff ff ff ff ff ff c0 a8 02 04 > > ff ff ff ff ff ff ff ff ff ff ff ff 08 06 00 01 > 08 00 06 04 00 02 ff ff ff ff ff ff c0 a8 02 de > ff ff ff ff ff ff 00 00 00 00 > Fatal error: exception OUnitTest.OUnit_failure("expected: Success but > got: Last 3 sent packets weren't ARP probes") > Raised at file "src/core/lwt.ml ", line 894, characters > 22-23 > Called from file "src/unix/lwt_main.ml ", line 34, > characters 8-18 > Called from file "main.ml ", line 36, characters 2-28 > > Looks like the second packet is a gratuitous ARP. > > Luke > > > On 12 March 2015 at 20:54, Mindy > wrote: > > Hi all, > > I've just made public `mirage-net-pcap`, a module that satisfies > V1.NETWORK by supplying packets from a prerecorded pcap file (via > crunch) and keeping written packets in memory for later > examination. You can see it at > https://github.com/yomimono/mirage-net-pcap , and there's an > example unikernel using it under `arp_tester` in my > example-unikernels repository at > https://github.com/yomimono/example-unikernels . `mirage-net-pcap` > works with both unix and xen backends, although the example code > works only with Unix because of its use of oUnit. > > Right now there isn't facility for saving writes to persistent > storage (i.e., writing to a pcap). I started writing this and > then realized it was generally the opposite of what I actually > wanted when writing testing code that used `mirage-net-pcap`, but > I do plan on adding this in a later release. > > I don't have a fork of the mirage frontend tool that nicely sets > up a netif in `config.ml ` for the user > currently, but stacks can be built on top of one in the normal way > (i.e., as in `mirage-skeleton/ethifv4`). > > Bad, horrible, okay, other? > > -Mindy > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > --------------060104040701010505020807 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Luke,

Ah, I'd thought of regulating the delays in the playback, but not of supplying other stuff in the stack with a stubbed-out OS.Time.sleep.=C2=A0 That's a good idea.

The ARP test correctly fails on the current tcpip -- my motivation for writing this particular test was to be able to make some claims about a pull request I made some time ago to mirage-tcpip.=C2=A0 I'm currently using it to test whether my attempts to make a better patch for ARP are, in fact, actually better.=C2=A0 I should probably = add something to the README to that effect.

-Mindy

On 03/12/2015 03:58 PM, Luke Dunstan wrote:
Cool idea.

For most tests I think it would be an advantage to use a stub implementation of OS.Time.sleep so that the tests would run almost instantly, regardless of time-outs. When you need to verify that the unit under test is sleeping for the correct amount of time then you'd need to record the calls to sleep, or something similar.

The ARP test fails for me on=C2=A0test_queries_retried (ex= tra debug messages added):

ARP: sending gratuitous from 192.168.2.222
ARP: updating 192.168.2.7 -> 00:16:3e:7b:2b:4d
ARP: transmitting probe -> 192.168.2.4
# written: 2

ff ff ff ff ff ff ff ff ff ff ff ff 08 06 00 01=C2=A0
08 00 06 04 00 01 ff ff ff ff ff ff c0 a8 02 de=C2=A0
ff ff ff ff ff ff c0 a8 02 04=C2=A0

ff ff ff ff ff ff ff ff ff ff ff ff 08 06 00 01=C2=A0
08 00 06 04 00 02 ff ff ff ff ff ff c0 a8 02 de=C2=A0
ff ff ff ff ff ff 00 00 00 00=C2=A0
Fatal error: exception OUnitTest.OUnit_failure("expected: Success but got: Last 3 sent packets weren't ARP probes")
Raised at file "src/core/lwt.ml", line 894, characters 22-23
Called from file "src/unix/lwt_main.ml", line 34= , characters 8-18
Called from file "= main= .ml", line 36, characters 2-28

Looks like the second packet is a gratuitous ARP.

Luke


On 12 March 2015 at 20:54, Mindy <mindy@somerandomidiot.com> wrote:
Hi all,

I've just made public `mirage-net-pcap`, a module that satisfies V1.NETWORK by supplying packets from a prerecorded pcap file (via crunch) and keeping written packets in memory for later examination.=C2=A0 You can see it at https://github.com/yomimono/mirage-net-pc= ap , and there's an example unikernel using it under `arp_tester` in my example-unikernels repository at https://github.com/yomimono/example-unike= rnels . `mirage-net-pcap` works with both unix and xen backends, although the example code works only with Unix because of its use of oUnit.

Right now there isn't facility for saving writes to persistent storage (i.e., writing to a pcap).=C2=A0 I started writing this and then realized it was generally the opposite of what I actually wanted when writing testing code that used `mirage-net-pcap`, but I do plan on adding this in a later release.

I don't have a fork of the mirage frontend tool that nicely sets up a netif in `config.ml` = for the user currently, but stacks can be built on top of one in the normal way (i.e., as in `mirage-skeleton/ethifv4`).

Bad, horrible, okay, other?

-Mindy

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailm= an/listinfo/mirageos-devel


--------------060104040701010505020807-- --===============2764600792117324223== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============2764600792117324223==-- From mirageos-devel-bounces@lists.xenproject.org Fri Mar 13 23:17:11 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 13 Mar 2015 23:17:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YWYpD-0000Dw-On; Fri, 13 Mar 2015 23:17:03 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YWYpC-0000Dl-V0 for MirageOS-devel@lists.xenproject.org; Fri, 13 Mar 2015 23:17:03 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id AE/A7-00925-EEF63055; Fri, 13 Mar 2015 23:17:02 +0000 X-Env-Sender: anand.prabhakar.patil@gmail.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1426288620!11934756!1 X-Originating-IP: [209.85.215.52] X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2730 invoked from network); 13 Mar 2015 23:17:01 -0000 Received: from mail-la0-f52.google.com (HELO mail-la0-f52.google.com) (209.85.215.52) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2015 23:17:01 -0000 Received: by lamx15 with SMTP id x15so1047990lam.3 for ; Fri, 13 Mar 2015 16:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=pYZDGjDufxvP2ST5S3Nk/2qp0IdNPMPaJZT6xnnMlNo=; b=B9/iYMpcRe5G5dp6fgLXOpD7dYUXOYCkHmTVFC5Sz1hwbKu1jFEiXWVeILQWsIp8j+ Kr/DfHPY3EaxYs/hxRbVWMSn729ud3n4+soxBzr/oGUscpdaO559LwYMgVax8ewrsvVH S6xQtstyU8t5ih+8EPzux90uCurcV++YpVCKBXdELoyKun/JSUwgzdswdXCRuWUMUJL4 3c6VxAf0AbNsi7jNuCcvH++Ue0kequCD/xGFkuyWmldPO3eL7Siyh6HLYS9Jm4ovD/zd V7fPJhYSV6YXi4Wf3fj2o2VXYWWBvAnYyboDS6TekNe5gntH7TyOlizLWPiTZXXWiklN k8rA== X-Received: by 10.112.219.135 with SMTP id po7mr44712920lbc.111.1426288620288; Fri, 13 Mar 2015 16:17:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.84.38 with HTTP; Fri, 13 Mar 2015 16:16:39 -0700 (PDT) In-Reply-To: References: <073A0B5C-531B-4B7B-ABA3-1D8A0EC4C4BA@recoil.org> From: Anand Patil Date: Fri, 13 Mar 2015 16:16:39 -0700 Message-ID: To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] Fwd: COW XML questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi Ashish, Great, thanks for the ppx_tools tip, I'll check it out and think about moving over to it when I next have time to look at this. Anand On Tue, Mar 10, 2015 at 11:38 AM, Ashish Agarwal wrote: > Thanks Anand. I took a look and will let you know if I do any work worth > merging. Also, I'm unsure of your choice of camlp4. The community is moving > away from that in favor of ppx. You might take a look at ppx_tools. > > On Tue, Mar 3, 2015 at 7:01 PM, Anand Patil > wrote: >> >> Hi Ashish, >> >> I knew this day would come. :) I'm still making progress, but haven't >> had too much time available for hobby projects lately, so it's slow. >> The current state is at https://github.com/apatil/auto-aws . >> >> It would be fun to work together with someone on this, either from >> what I have or from scratch. >> >> Anand >> >> On Tue, Mar 3, 2015 at 2:31 PM, Ashish Agarwal >> wrote: >> > Hi Anand. Any progress on this? Is your repo public? Thanks. >> > >> > >> > On Tue, Jan 6, 2015 at 1:32 PM, Anand Patil >> > wrote: >> >> >> >> Hi Anil and Thomas, thanks for the pointers. I'll keep plugging away >> >> at this and will let you know how I get on. >> >> >> >> Anand >> >> >> >> On Tue, Jan 6, 2015 at 7:43 AM, Anil Madhavapeddy >> >> wrote: >> >> > On 5 Jan 2015, at 05:56, Anand Patil >> >> > >> >> > wrote: >> >> > >> >> >> In order to learn OCaml and thence Mirage, I've been working a >> >> >> little >> >> >> bit on an automatically generated, complete AWS client along the >> >> >> lines >> >> >> of https://github.com/stripe/aws-go using camlp4. I've got the types >> >> >> generated, and now need to generate to/from XML functions for each >> >> >> record type. >> >> >> >> >> > >> >> > Incidentally, this would be awesomely useful to have. You might also >> >> > want to look at Jyotsna Prakash's (manually written) bindings for >> >> > helper functions that might come in useful: >> >> > >> >> > https://github.com/moonlightdrive/ocaml-ec2 >> >> > >> >> > Feel free to ask here if you run into any blockers. >> >> > >> >> > -anil >> >> > >> >> >> >> _______________________________________________ >> >> MirageOS-devel mailing list >> >> MirageOS-devel@lists.xenproject.org >> >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >> > >> > > > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Fri Mar 13 23:17:11 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 13 Mar 2015 23:17:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YWYpD-0000Dw-On; Fri, 13 Mar 2015 23:17:03 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YWYpC-0000Dl-V0 for MirageOS-devel@lists.xenproject.org; Fri, 13 Mar 2015 23:17:03 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id AE/A7-00925-EEF63055; Fri, 13 Mar 2015 23:17:02 +0000 X-Env-Sender: anand.prabhakar.patil@gmail.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1426288620!11934756!1 X-Originating-IP: [209.85.215.52] X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2730 invoked from network); 13 Mar 2015 23:17:01 -0000 Received: from mail-la0-f52.google.com (HELO mail-la0-f52.google.com) (209.85.215.52) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2015 23:17:01 -0000 Received: by lamx15 with SMTP id x15so1047990lam.3 for ; Fri, 13 Mar 2015 16:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=pYZDGjDufxvP2ST5S3Nk/2qp0IdNPMPaJZT6xnnMlNo=; b=B9/iYMpcRe5G5dp6fgLXOpD7dYUXOYCkHmTVFC5Sz1hwbKu1jFEiXWVeILQWsIp8j+ Kr/DfHPY3EaxYs/hxRbVWMSn729ud3n4+soxBzr/oGUscpdaO559LwYMgVax8ewrsvVH S6xQtstyU8t5ih+8EPzux90uCurcV++YpVCKBXdELoyKun/JSUwgzdswdXCRuWUMUJL4 3c6VxAf0AbNsi7jNuCcvH++Ue0kequCD/xGFkuyWmldPO3eL7Siyh6HLYS9Jm4ovD/zd V7fPJhYSV6YXi4Wf3fj2o2VXYWWBvAnYyboDS6TekNe5gntH7TyOlizLWPiTZXXWiklN k8rA== X-Received: by 10.112.219.135 with SMTP id po7mr44712920lbc.111.1426288620288; Fri, 13 Mar 2015 16:17:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.84.38 with HTTP; Fri, 13 Mar 2015 16:16:39 -0700 (PDT) In-Reply-To: References: <073A0B5C-531B-4B7B-ABA3-1D8A0EC4C4BA@recoil.org> From: Anand Patil Date: Fri, 13 Mar 2015 16:16:39 -0700 Message-ID: To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] Fwd: COW XML questions X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi Ashish, Great, thanks for the ppx_tools tip, I'll check it out and think about moving over to it when I next have time to look at this. Anand On Tue, Mar 10, 2015 at 11:38 AM, Ashish Agarwal wrote: > Thanks Anand. I took a look and will let you know if I do any work worth > merging. Also, I'm unsure of your choice of camlp4. The community is moving > away from that in favor of ppx. You might take a look at ppx_tools. > > On Tue, Mar 3, 2015 at 7:01 PM, Anand Patil > wrote: >> >> Hi Ashish, >> >> I knew this day would come. :) I'm still making progress, but haven't >> had too much time available for hobby projects lately, so it's slow. >> The current state is at https://github.com/apatil/auto-aws . >> >> It would be fun to work together with someone on this, either from >> what I have or from scratch. >> >> Anand >> >> On Tue, Mar 3, 2015 at 2:31 PM, Ashish Agarwal >> wrote: >> > Hi Anand. Any progress on this? Is your repo public? Thanks. >> > >> > >> > On Tue, Jan 6, 2015 at 1:32 PM, Anand Patil >> > wrote: >> >> >> >> Hi Anil and Thomas, thanks for the pointers. I'll keep plugging away >> >> at this and will let you know how I get on. >> >> >> >> Anand >> >> >> >> On Tue, Jan 6, 2015 at 7:43 AM, Anil Madhavapeddy >> >> wrote: >> >> > On 5 Jan 2015, at 05:56, Anand Patil >> >> > >> >> > wrote: >> >> > >> >> >> In order to learn OCaml and thence Mirage, I've been working a >> >> >> little >> >> >> bit on an automatically generated, complete AWS client along the >> >> >> lines >> >> >> of https://github.com/stripe/aws-go using camlp4. I've got the types >> >> >> generated, and now need to generate to/from XML functions for each >> >> >> record type. >> >> >> >> >> > >> >> > Incidentally, this would be awesomely useful to have. You might also >> >> > want to look at Jyotsna Prakash's (manually written) bindings for >> >> > helper functions that might come in useful: >> >> > >> >> > https://github.com/moonlightdrive/ocaml-ec2 >> >> > >> >> > Feel free to ask here if you run into any blockers. >> >> > >> >> > -anil >> >> > >> >> >> >> _______________________________________________ >> >> MirageOS-devel mailing list >> >> MirageOS-devel@lists.xenproject.org >> >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >> > >> > > > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Mar 14 21:13:53 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 14 Mar 2015 21:13:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YWtNQ-0002Qv-47; Sat, 14 Mar 2015 21:13:44 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YWtNO-0002Qo-S0 for mirageos-devel@lists.xenproject.org; Sat, 14 Mar 2015 21:13:43 +0000 Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id 70/25-28920-584A4055; Sat, 14 Mar 2015 21:13:41 +0000 X-Env-Sender: trevorsummerssmith@gmail.com X-Msg-Ref: server-11.tower-31.messagelabs.com!1426367620!12133830!1 X-Originating-IP: [209.85.192.52] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17635 invoked from network); 14 Mar 2015 21:13:41 -0000 Received: from mail-qg0-f52.google.com (HELO mail-qg0-f52.google.com) (209.85.192.52) by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2015 21:13:41 -0000 Received: by qgfa8 with SMTP id a8so12980766qgf.0 for ; Sat, 14 Mar 2015 14:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=6XboHS9tyfs7G0lnW6vOyLiJQWdze4ofegxCDm4P3B4=; b=GnQuCG7CkCktkc5m2sF4tYJcDuiOzvgOZo/6Xx+M6DFDNLGgL3K81zm1bDeuTNr2Jd SbIxSaXYa9K7s3z0GMZhLhQ9OGhKBQ8lUWyWLnNZ7NhbR0OTnlK9GWsokixC3Iench4P JzQZuSdoF4vQaF51vv50s7Le/YIwgq1F9xc3zjgaCEpAwjBFtyZHC0D83zkWXNnUDvMb 9/lz2bwdy/PWjHjz1Jp/AnssnfrhpzccVUM7+gXxWJvxyqvFCKE2eGSDcvXkJAhaLRry vpkS6jGQRzJ3QIB0jo/WIT0BQiGLq/60Z1BIqWNtzOgSpVpcWQ4oJANQpCBvDWb9JZmB RUow== MIME-Version: 1.0 X-Received: by 10.140.29.74 with SMTP id a68mr65975396qga.106.1426367620033; Sat, 14 Mar 2015 14:13:40 -0700 (PDT) Received: by 10.229.240.68 with HTTP; Sat, 14 Mar 2015 14:13:39 -0700 (PDT) Date: Sat, 14 Mar 2015 17:13:39 -0400 Message-ID: From: Trevor Smith To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] CoHTTP Design: Polymorphic Variants X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2954305540335959178==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============2954305540335959178== Content-Type: multipart/alternative; boundary=001a113a413e4fb23705114617cf --001a113a413e4fb23705114617cf Content-Type: text/plain; charset=UTF-8 Hello, I am curious to hear the design tradeoffs that were considered in choosing polymorphic variants vs variants in the code.mli types. I haven't really wrapped my head around why that decision was made, and am eager to learn more about real world use of polymorphic variants. Thank you. Trevor --001a113a413e4fb23705114617cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I am curious to hear the design = tradeoffs that were considered in choosing polymorphic variants vs variants= in the code.mli types. I haven't really wrapped my head around why tha= t decision was made, and am eager to learn more about real world use of pol= ymorphic variants.

Thank you.

=
Trevor
--001a113a413e4fb23705114617cf-- --===============2954305540335959178== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============2954305540335959178==-- From mirageos-devel-bounces@lists.xenproject.org Sat Mar 14 21:13:53 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 14 Mar 2015 21:13:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YWtNQ-0002Qv-47; Sat, 14 Mar 2015 21:13:44 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YWtNO-0002Qo-S0 for mirageos-devel@lists.xenproject.org; Sat, 14 Mar 2015 21:13:43 +0000 Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id 70/25-28920-584A4055; Sat, 14 Mar 2015 21:13:41 +0000 X-Env-Sender: trevorsummerssmith@gmail.com X-Msg-Ref: server-11.tower-31.messagelabs.com!1426367620!12133830!1 X-Originating-IP: [209.85.192.52] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17635 invoked from network); 14 Mar 2015 21:13:41 -0000 Received: from mail-qg0-f52.google.com (HELO mail-qg0-f52.google.com) (209.85.192.52) by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2015 21:13:41 -0000 Received: by qgfa8 with SMTP id a8so12980766qgf.0 for ; Sat, 14 Mar 2015 14:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=6XboHS9tyfs7G0lnW6vOyLiJQWdze4ofegxCDm4P3B4=; b=GnQuCG7CkCktkc5m2sF4tYJcDuiOzvgOZo/6Xx+M6DFDNLGgL3K81zm1bDeuTNr2Jd SbIxSaXYa9K7s3z0GMZhLhQ9OGhKBQ8lUWyWLnNZ7NhbR0OTnlK9GWsokixC3Iench4P JzQZuSdoF4vQaF51vv50s7Le/YIwgq1F9xc3zjgaCEpAwjBFtyZHC0D83zkWXNnUDvMb 9/lz2bwdy/PWjHjz1Jp/AnssnfrhpzccVUM7+gXxWJvxyqvFCKE2eGSDcvXkJAhaLRry vpkS6jGQRzJ3QIB0jo/WIT0BQiGLq/60Z1BIqWNtzOgSpVpcWQ4oJANQpCBvDWb9JZmB RUow== MIME-Version: 1.0 X-Received: by 10.140.29.74 with SMTP id a68mr65975396qga.106.1426367620033; Sat, 14 Mar 2015 14:13:40 -0700 (PDT) Received: by 10.229.240.68 with HTTP; Sat, 14 Mar 2015 14:13:39 -0700 (PDT) Date: Sat, 14 Mar 2015 17:13:39 -0400 Message-ID: From: Trevor Smith To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] CoHTTP Design: Polymorphic Variants X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2954305540335959178==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============2954305540335959178== Content-Type: multipart/alternative; boundary=001a113a413e4fb23705114617cf --001a113a413e4fb23705114617cf Content-Type: text/plain; charset=UTF-8 Hello, I am curious to hear the design tradeoffs that were considered in choosing polymorphic variants vs variants in the code.mli types. I haven't really wrapped my head around why that decision was made, and am eager to learn more about real world use of polymorphic variants. Thank you. Trevor --001a113a413e4fb23705114617cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I am curious to hear the design = tradeoffs that were considered in choosing polymorphic variants vs variants= in the code.mli types. I haven't really wrapped my head around why tha= t decision was made, and am eager to learn more about real world use of pol= ymorphic variants.

Thank you.

=
Trevor
--001a113a413e4fb23705114617cf-- --===============2954305540335959178== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============2954305540335959178==-- From mirageos-devel-bounces@lists.xenproject.org Sat Mar 14 21:17:42 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 14 Mar 2015 21:17:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YWtRG-0002Sy-GK; Sat, 14 Mar 2015 21:17:42 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YWtRF-0002St-DZ for mirageos-devel@lists.xenproject.org; Sat, 14 Mar 2015 21:17:41 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id 6D/DA-08273-475A4055; Sat, 14 Mar 2015 21:17:40 +0000 X-Env-Sender: rudi.grinberg@gmail.com X-Msg-Ref: server-11.tower-31.messagelabs.com!1426367858!12134245!1 X-Originating-IP: [209.85.213.181] X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24316 invoked from network); 14 Mar 2015 21:17:39 -0000 Received: from mail-ig0-f181.google.com (HELO mail-ig0-f181.google.com) (209.85.213.181) by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2015 21:17:39 -0000 Received: by igbue6 with SMTP id ue6so10302523igb.1 for ; Sat, 14 Mar 2015 14:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type; bh=vpnYDy4ln+vXJHH4ucK868KplwZVg2683XFjt2GU28E=; b=N2+u5Axcar1PrYQXItO5xNQFkj4JnJzht/MQNLD+yOLqk+njqLX22ZPbaR10wBWc0G f9pIcmHt/QBTYsu6udG8yUgq/6teDFKrzaicg73+dnARlr9iKqwKtsOme4YSyz+e8LEM ucpZGZoM4Nm/SAIhyI87neztR+m6oboL9+7XWeDbdyMYG311KpjG47Iw+Lv/rmtyrFGr 8xjZV/T9u6RUgqdp9n6GjrQXA+h1TiSPGhnvzPUOhCfdEwZxQFbwShorhDF/PlQ44JSq xN6WneOGs8C5K70qDmdMYo60dN8vAE15l+Ug+emHBKakKeKEyBNHoqPBxIStj+uy7dBr ae3g== X-Received: by 10.50.28.8 with SMTP id x8mr95581839igg.19.1426367858240; Sat, 14 Mar 2015 14:17:38 -0700 (PDT) Received: from Rudis-MacBook-Pro.local ([66.49.218.159]) by mx.google.com with ESMTPSA id f32sm3859672iod.30.2015.03.14.14.17.37 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Mar 2015 14:17:37 -0700 (PDT) Date: Sat, 14 Mar 2015 17:20:41 -0400 From: Rudi Grinberg To: "=?utf-8?Q?mirageos-devel=40lists.xenproject.org?=" , Trevor Smith Message-ID: In-Reply-To: References: X-Mailer: Airmail Beta (297) MIME-Version: 1.0 Subject: Re: [MirageOS-devel] CoHTTP Design: Polymorphic Variants X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8527805374084610694==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============8527805374084610694== Content-Type: multipart/alternative; boundary="5504a629_66334873_16d" --5504a629_66334873_16d Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Trevor, This is the standard reference I usually refer people when they ask this:= =C2=A0http://stackoverflow.com/questions/9367181/variants-or-polymorphic-= variants In cohttp=E2=80=99s case I think the benefits listed in 2, 3, and 4 apply= . Thanks, Rudi. On March 14, 2015 at 5:14:10 PM, Trevor Smith (trevorsummerssmith=40gmail= .com) wrote: I am curious to hear the design tradeoffs that were considered in choosin= g polymorphic variants vs variants in the code.mli types. I haven't reall= y wrapped my head around why that decision was made, and am eager to lear= n more about real world use of polymorphic variants. --5504a629_66334873_16d Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline