Refactors errors and split signatures into their own opam packages #743
Conversation
I got the same warning, also think it is harmless (maybe just put This PR looks good to me! Thanks! |
| `Invalid_console str -> pf pp "invalid console %s" str | ||
|
||
let unspecified pp m = pf pp "unspecified error - %s" m | ||
let pp_device_error pp = function |
hannesm
Dec 20, 2016
Member
while you're at it, maybe drop the pp
? Mirage_pp.pp_device_error
vs Mirage_pp.device_error
..
while you're at it, maybe drop the pp
? Mirage_pp.pp_device_error
vs Mirage_pp.device_error
..
samoht
Dec 20, 2016
Author
Member
Yes, good point.
Yes, good point.
avsm
Dec 20, 2016
Member
I'd prefer the pp functions to follow the convention if possible, as they're much more recognisable when cross-referenced in documentation etc. Modules can be opened...
I'd prefer the pp functions to follow the convention if possible, as they're much more recognisable when cross-referenced in documentation etc. Modules can be opened...
samoht
Dec 20, 2016
Author
Member
The _pp.pp_
is indeed pretty annoying. Two options:
- I can move the function to
Mirage_runtime
- I can just drop the
pp_
prefix, and tell people to not open Mirage_pp
.
I tend towards the later, but both options seems ok.
The _pp.pp_
is indeed pretty annoying. Two options:
- I can move the function to
Mirage_runtime
- I can just drop the
pp_
prefix, and tell people to not openMirage_pp
.
I tend towards the later, but both options seems ok.
hannesm
Dec 20, 2016
Member
I prefer the latter as well.
I prefer the latter as well.
@@ -1,79 +1,47 @@ | |||
open Result | |||
open V1 | |||
let pf pp = Format.fprintf pp |
avsm
Dec 20, 2016
Member
We could just put a dependency on Fmt
here, as it defines the same function.
We could just put a dependency on Fmt
here, as it defines the same function.
samoht
Dec 20, 2016
Author
Member
yup, this needs some cleanup.
yup, this needs some cleanup.
@@ -48,10 +48,23 @@ open Result | |||
{e Release %%VERSION%% } *) | |||
|
|||
(** {1 Abstract devices} | |||
type 'a pp = Format.formatter -> 'a -> unit |
avsm
Dec 20, 2016
Member
and likewise here, this is Fmt.t
-- while we are trying to minimise dependencies here, Fmt is standalone and has a number of other useful functions to sensibly compose formatters. I'm not against this patch either though, just a suggestion.
and likewise here, this is Fmt.t
-- while we are trying to minimise dependencies here, Fmt is standalone and has a number of other useful functions to sensibly compose formatters. I'm not against this patch either though, just a suggestion.
samoht
Dec 20, 2016
Author
Member
Today mirage-types
does not have any dependency.
Today mirage-types
does not have any dependency.
hannesm
Dec 20, 2016
Member
I do appreciate mirage-types not having any dependency (since we require 4.03+, result must be present in any case)
I do appreciate mirage-types not having any dependency (since we require 4.03+, result must be present in any case)
avsm
Dec 20, 2016
Member
Fine by me.
Fine by me.
avsm
Dec 20, 2016
Member
One thing that would help beginners (as a documentation pass) is some tips on where to find functions that use the defined types -- for example, a pointer to Ptime for the time functions, Fmt for the pretty printers, Rresult for result combinators. This can be be done later once the code compiles :)
One thing that would help beginners (as a documentation pass) is some tips on where to find functions that use the defined types -- for example, a pointer to Ptime for the time functions, Fmt for the pretty printers, Rresult for result combinators. This can be be done later once the code compiles :)
|
@avsm all the reverse builds are broken because I haven't done the work yet :-) I'm doing that next. |
Finally after discussing with @yomimono and @avsm I am going to the full ride: split up This is a rather large change, but I suspect that it's possible to do it in a few days (and I'm very motivated to do it :p) so I started to do here (it's not strictly speaking part of this PR, but this is somehow related). So far I have:
I'll move out the other signatures packages tomorrow, and I hope to have something mergeable before the end of the week. |
While |
@dbuenzli any suggestion where should I should put it? |
Wherever your run loop abstraction is defined. Also |
It's already duplicated on every platform and tests:
Which IMHO seems to indicate that we have to either remove it (and assume an ambient |
I often want my sleeps to depend on a clock, rather than on the run loop, for unit tests (e.g. mirage-clock-test) . It seems reasonable that a clock might want to offer a way to get a notification at a certain time, or after some period of time has elapsed according to that clock. |
@MagnusS just pointed me to https://github.com/MagnusS/mirage-event-clock/blob/master/lib/event_clock.ml#L74 so we have use-cases where |
It seems you rather want to configure which clock you use for your run loop.
While a clock could provide you this under the form of interrupts, you wouldn't want cooperative programs to use this directly. Rather a run loop would use this with a priority queue to implement a cooperative |
@samoht I feel like this would be simpler if you had all the packages in the same repository (still as separate packages). |
as discussed several times, I'd be happy when the whole mirage-os-shim would just be there, no need to functorise over basic OS functionality which should be there exactly once (or is anyone seriously interested in running two clocks at different speed in the same unikernel?) -- and I still think if you use but I'm too tired to discuss this again. |
Let's say that this won't be resolved for Mirage3 :p My current goal is just to split the types in separate repos, while keeping the signatures as similar as possible as what we have today in |
I agree with splitting up the types into separate OPAM packages, but is there any reason not to keep them in the same Git repo with multiple .opam files in the repo? We would avoid a preponderance of repositories and make future name refactoring easier. |
e58559e
to
0ade9c8
A quick update: I have made some progress and I am able to compile a few examples in My goal is to make all the examples compile in |
See mirage/mirage-skeleton#213 for the changes needed to mirage-skeleton to compile all of the example on the unix backend. Polishing up all the patches/PRs now. One thing that maybe went wrong is that I notice that the TCP/IP stack seems a bit slow on OSX (using vmnetd). ICMP packets seems to get lost pretty often, and the HTTP request takes |
I'm working on the later: yes, this dates back to #643. |
I have updated the issue body with all the current PRs. My plan is to continue fixing the last few remaining issues, and do a merge tomorrow. The second-half of splitting the Mirage signature could (and probably should) be done separately. I plan to look at that next week. |
V1 signatures are now split into: - V1.DEVICE is Mirage_device.S in mirage/mirage-device - V1.TIME is Mirage_time.S in mirage/mirage-time - V1.MCLOCK and V1.PCLOCK are Mirage_clock.{MCLOCK, PCLOCK} in mirage/mirage-clock - V1.RANDOM is Mirage_random.S in mirage/mirage-random - V1.FLOW is Mirage_flow.S in mirage/mirage-flow - V1.CONSOLE is Mirage_console.S in mirage/mirage-console - V1.BLOCK is Mirage_block.S in mirage/mirage-block And similar changes for V1_LWT, with the following convention: - V1_LWT.FOO is Mirage_foo_lwt.S For now V1 is kept unchanged and define aliases to the new signatures.
Rebased, with hopefully more green ticks this time. |
mirage-skeleton is green on unix, xen and solo5. Most of the individual PRs are green too. I'll start to merge everything, expect a little bit of breakage for a few hours... |
Following the discussions we had with @talex5, @yallop and @hannesm last week, I implemented the new error scheme using private rows. After finding 2 bugs in the compiler, I finally managed to get something working. Here is the full set of patches:
new repos with new signatures
move V1 signatures in existing repo:
Use the new split sigs only
Adapt to the new error scheme + use the new split sigs
Fix pre-existing errors
Meta
Add new constraints