> Project Team Roles {#roles-local}
> --
>
> +Sub-projects or teams are driven by the people who volunteer for the job.
> This
> +functions well for most cases. This section lists the main roles which
> projects
> +use. This section lists the default roles, which are based o
On Fri, Sep 23, 2016 at 07:55:27PM +0100, Lars Kurth wrote:
> Contains items that at some point need to be addressed.
> The items do not directly affect governance.pandoc
>
> Signed-off-by: Lars Kurth
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> governance.todo | 23 +++
> 1
On Fri, Sep 23, 2016 at 07:55:26PM +0100, Lars Kurth wrote:
> Added TOC
> Re-arranged sections compared to previous version of document
> Added new anchors where needed
> Split Roles section into two sections
>
> The actual content was not changed (with the exception of minor
> typos that I spotte
On 10/14/2016 11:03 AM, Ashish Agarwal wrote:
Using polymorphic variants for the error type poses some challenges.
Here are some things to think about. (The following code assumes `open
Async.Std` because it already has the necessary combinators).
Error Unification
# let x = return (Error `Ba
Using polymorphic variants for the error type poses some challenges. Here
are some things to think about. (The following code assumes `open
Async.Std` because it already has the necessary combinators).
Error Unification
# let x = return (Error `Bad);;
val x : ('a, [> `Bad ]) Result.t Deferred.t =
On 14/10/2016 15:44, Anil Madhavapeddy wrote:
> On 14 Oct 2016, at 15:36, David Scott wrote:
>>
>> Looks like we have a number of different conventions for the binds. Do we
>> want to have the same set of operators with and without Lwt support (and
>> open the Infix module locally as needed) or
On 14 October 2016 at 15:36, David Scott wrote:
>> Looks like we have a number of different conventions for the binds. Do we
>> want to have the same set of operators with and without Lwt support (and
>> open the Infix module locally as needed) or separate operators that be used
>> alongside each
On 14 Oct 2016, at 15:36, David Scott wrote:
>
> Looks like we have a number of different conventions for the binds. Do we
> want to have the same set of operators with and without Lwt support (and open
> the Infix module locally as needed) or separate operators that be used
> alongside each
> On 14 Oct 2016, at 15:31, Hannes Mehnert wrote:
>
> [again raising the issue: could some mailing list admin please set the
> reply-to to the list -- there's no need to send the message to the
> individual and to the list!]
>
> On 14/10/2016 15:23, Anil Madhavapeddy wrote:
>> On 14 Oct 2016, a
On Fri, Oct 14, 2016 at 3:23 PM, Anil Madhavapeddy wrote:
> On 14 Oct 2016, at 15:11, Hannes Mehnert wrote:
> >
> > On 14/10/2016 15:08, Anil Madhavapeddy wrote:
> >> Yeah, once we agree on the conventions :-) Once we have everything
> using Result.t, we also need to find the right set of combi
On Friday 14 October 2016 at 16:18, Anil Madhavapeddy wrote:
> This is largely within libraries, so the impact wouldn't be too bad. I do
> notice that PCLOCK, MCLOCK and IP types do use option to signify failure
> though, which would be mirage-types churn...
PCLOCK and MCLOCK do not use options
[again raising the issue: could some mailing list admin please set the
reply-to to the list -- there's no need to send the message to the
individual and to the list!]
On 14/10/2016 15:23, Anil Madhavapeddy wrote:
> On 14 Oct 2016, at 15:11, Hannes Mehnert wrote:
>>
>> On 14/10/2016 15:08, Anil Ma
On 10/14/2016 09:08 AM, Richard Mortier wrote:
On 14 October 2016 at 14:51, Anil Madhavapeddy wrote:
Should we take the Mirage3 opportunity to port libraries like Ipaddr to using
the Result type instead
I think that would be a good thing-- only concern would be how much it
would delay the re
On 14 Oct 2016, at 15:11, Hannes Mehnert wrote:
>
> On 14/10/2016 15:08, Anil Madhavapeddy wrote:
>> Yeah, once we agree on the conventions :-) Once we have everything using
>> Result.t, we also need to find the right set of combinators.
>>
>> - There is Rresult for basic Result.t handling:
>
On 14/10/2016 15:18, Anil Madhavapeddy wrote:
> This is largely within libraries, so the impact wouldn't be too bad. I do
> notice that PCLOCK, MCLOCK and IP types do use option to signify failure
> though, which would be mirage-types churn...
Well, in mirage-types we use (sometimes) `unit Lwt.
On 14/10/2016 15:08, Anil Madhavapeddy wrote:
>
>> On 14 Oct 2016, at 15:05, David Scott wrote:
>>
>>
>> On Fri, Oct 14, 2016 at 2:51 PM, Anil Madhavapeddy wrote:
>>> We have quite a few base libraries that use the pattern of
>>>
>>> val foo_exn : ... -> 'a
>>> @raises
>>>
>>> val foo: ... -> 'a
On 14 Oct 2016, at 15:08, Richard Mortier wrote:
>
> On 14 October 2016 at 14:51, Anil Madhavapeddy wrote:
>> Should we take the Mirage3 opportunity to port libraries like Ipaddr to
>> using the Result type instead
>
> I think that would be a good thing-- only concern would be how much it
> wo
> On 14 Oct 2016, at 15:08, Richard Mortier
> wrote:
>
> On 14 October 2016 at 14:51, Anil Madhavapeddy wrote:
>> Should we take the Mirage3 opportunity to port libraries like Ipaddr to
>> using the Result type instead
>
> I think that would be a good thing-- only concern would be how much i
On 14 October 2016 at 14:51, Anil Madhavapeddy wrote:
> Should we take the Mirage3 opportunity to port libraries like Ipaddr to using
> the Result type instead
I think that would be a good thing-- only concern would be how much it
would delay the release?
(Do we have a timeline for that in fact
> On 14 Oct 2016, at 15:05, David Scott wrote:
>
>
> On Fri, Oct 14, 2016 at 2:51 PM, Anil Madhavapeddy wrote:
>> We have quite a few base libraries that use the pattern of
>>
>> val foo_exn : ... -> 'a
>> @raises
>>
>> val foo: ... -> 'a option
>> Gobbles the exception and returns Some/None
On Fri, Oct 14, 2016 at 2:51 PM, Anil Madhavapeddy wrote:
> We have quite a few base libraries that use the pattern of
>
> val foo_exn : ... -> 'a
> @raises
>
> val foo: ... -> 'a option
> Gobbles the exception and returns Some/None
>
> Should we take the Mirage3 opportunity to port libraries lik
We have quite a few base libraries that use the pattern of
val foo_exn : ... -> 'a
@raises
val foo: ... -> 'a option
Gobbles the exception and returns Some/None
Should we take the Mirage3 opportunity to port libraries like Ipaddr to using
the Result type instead, so it would be
val foo : ... -
On 14 Oct 2016, at 13:13, Hannes Mehnert wrote:
>
> On 14/10/2016 11:29, Anil Madhavapeddy wrote:
>> Good news everyone! The experimental documentation repository at
>> http://docs.mirage.io now builds again, and has been refreshed to the latest
>> set of libraries assembled from the MirageOS3
On 14 Oct 2016, at 11:59, Amir Chaudhry wrote:
>
>
>> On 14 Oct 2016, at 11:29, Anil Madhavapeddy wrote:
>>
>> As this setup stabilises, I will merge the TROVE links currently held in
>> mirage-www with this version (which uses OPAM package names rather than
>> repositories, which is more us
On 14 Oct 2016, at 11:34, Mindy wrote:
>
>
> On 10/14/2016 05:29 AM, Anil Madhavapeddy wrote:
>> Good news everyone! The experimental documentation repository at
>> http://docs.mirage.io now builds again, and has been refreshed to the latest
>> set of libraries assembled from the MirageOS3 dev
On 14/10/2016 11:29, Anil Madhavapeddy wrote:
> Good news everyone! The experimental documentation repository at
> http://docs.mirage.io now builds again, and has been refreshed to the latest
> set of libraries assembled from the MirageOS3 dev remote at
> https://github.com/mirage/mirage-dev
Ya
> On 14 Oct 2016, at 11:29, Anil Madhavapeddy wrote:
>
> As this setup stabilises, I will merge the TROVE links currently held in
> mirage-www with this version (which uses OPAM package names rather than
> repositories, which is more useful I think).
This is definitely more useful. We’ve pre
On 10/14/2016 05:29 AM, Anil Madhavapeddy wrote:
Good news everyone! The experimental documentation repository at
http://docs.mirage.io now builds again, and has been refreshed to the latest
set of libraries assembled from the MirageOS3 dev remote at
https://github.com/mirage/mirage-dev
Thi
Good news everyone! The experimental documentation repository at
http://docs.mirage.io now builds again, and has been refreshed to the latest
set of libraries assembled from the MirageOS3 dev remote at
https://github.com/mirage/mirage-dev
As a reminder, this has become the unofficial "trove" si
29 matches
Mail list logo
