Irc discussions from #mirage on 02-08-2017

Written by amirmc
Classified under: irclog
Published: 2017-08-04 (last updated: 2017-08-04)

You can see whitequark's irclogs for a better formatted version of the logs over at https://irclog.whitequark.org/mirage/2017-08-02

The logs below are copied over from there, without formatting.


15:00 * djs55 waves 15:00 hi all 15:01 hi! 15:01 I see the clock's turned over, so it must be meeting time! 15:02 . 15:02 o/ 15:02 mort___: Hola! 15:03 The agenda's over at https://github.com/mirage/mirage-www/wiki/Call-Agenda#2nd-august-2017 , please feel free to add stuff :) 15:03 hi all! 15:03 mato bon dia :) 15:03 hello! 15:03 o/ 15:05 I'd put an item on the agenda that's first - releases of mirage and functoria would be great, but mirage needs a few more bugfixes to deal with package renaming first 15:05 the new release of functoria is now merged in opam-repo 15:05 oh awesome!! 15:06 that's great news, so in that case we just need to fix names in the mirage front-end tool and then we can release that with a constraint requiring latest functoria, right? 15:06 so the only thing blocking the next release of mirage is deciding when to stop I guess :-) 15:06 so yes, I agree that we should just fix the constraints and ship it 15:06 We need a bugfix release badly, the tool is not really usable with the current opam universe 15:07 thomasga: OK, sounds good. Thanks for your work on it :) 15:07 I am still a bit uncomfortable about adding upper bounds everywhere, but I guess there is no other solution 15:07 I don't like that solution much either, but as I understand it opam2 will fix this problem? 15:08 I am not sure — upper bounds usually add a new class of problems. But I guess these are better than the current set of problems we have :-) 15:08 Would this be a good time to introduce some breaking changes on the Solo5 front, or is that something better left for a future release? 15:08 (and yes we should release a new version of mirage to unblock all our users lost in dependency management hell) 15:09 mato: I think that should be a 3.1 or something, not wrapped up in this 15:09 mato: probably best to wait a bit 15:09 +1 for a 3.1 with this 15:09 yomimono: Ok, sounds good. Some of the changes are not baked yet, so I agree. 15:10 I have some time today so I'll try to get the rename patches PR'd for mirage, rather than complaining about it any more :) 15:11 mato: We've discussed a 3.1 very vaguely before, but if you think the solo5 work is getting close enough to push for it shortly, we should write out what needs doing there 15:11 ...actually, you've already done that, haven't you? 15:11 yomimono: Not enough -- there are a bunch of things that are not clear yet (eg. renaming ukvm to something w/o "kvm" in it) 15:12 yomimono: Which would be the most user-visible change, but still need to spend some time thinking about it so as not to have to go through >1 user-visible rename... 15:12 mato: Seems wise. 15:13 mato: there was an issue for that naming thing, right? 15:14 amirmc: There is, but needs updating with recent oob discussions. #172 15:14 can we propose names? 15:14 maybe not right now ;) 15:15 a public vote? 15:15 sounds like thomasga is eager to put in a candidate :) 15:15 thomasga: Feel free in the issue. We need several names, one for the unikernel "monitor" (ukvm) and one for the code in kernel/. 15:15 thomasga: I have a strawman which was "ubase" (kernel) and "umon" (monitor). 15:15 right, I will propose silly names in https://github.com/Solo5/solo5/issues/172 :-) 15:16 haha, I wanted to say 'umon' ;-) 15:16 Please do. I'll also try to update the issue with some background. Been distracted with the arm64 stuff, which is progressing nicely. 15:17 (As of now if you pin solo5-kernel-ukvm, ocaml-freestanding and mirage-solo5 master you can build anything which does not need mirage-entropy or nocrypto) 15:18 Moving on, unless there are objections... 15:18 samoht wanted to bring attention back to https://github.com/mirage/mirage-www/pull/562 , which I got distracted reading just now (sorry!) 15:19 yes the idea is to try to improve the general quality of the ecosystem 15:19 * yomimono looks frantically for LIKE button 15:19 the last proposal is to try to defines some sort of "levels" 15:20 e.g. level 1 is you have the basic files (CHANGES, LICENSE, README) + basic CI + everything set-up for odig to be happy 15:20 (Does that includes cool achievement-like badges ?) 15:20 then you have tests, use ocp-indent, use a code linter, follow good practice, etc 15:20 Drup: yes!! 15:20 Nice 15:21 I will try to come up with a first strawman for the levels before the end of the week, and having more feedback would be useful (I already got plenty, but the more I have the more I am happy :p) 15:22 (and level 10 would be to formally verify the library of course) 15:22 anyway, that's it for me :-) 15:23 Sounds good, I'll read the PR and will give feedback. 15:24 Same here. Thanks for bringing our attention to it, samoht :) 15:24 I haven't added all the feedback I got in the PR yet, I'll do it in the next days 15:24 Having just spent the best part of the day dealing with npm insanity (for Solo5 ARM64 CI), I'm all for quality packages! 15:25 (so read also the comments in the PR, not only the doc) 15:25 Objections to moving on? 15:25 thomasga: Which reminds me, one of the metrics I think we want is "Does not (unnecessarily) {depend on, vendor} C code" 15:26 I think that, along with some more general "write nice code" guidelines in the document, are better stated as goals than properties that a codebase has or doesn't have 15:26 "unnecessarily" is subjective 15:27 that particular can of worms is probably best opened in the PR, though 15:27 Agreed. 15:28 In that case, moving on -- 15:28 talex5, got some updates on capnp? 15:29 I've created a thread on discuss to track it now: https://discuss.ocaml.org/t/mirage-capn-proto-rpc-library/658 15:29 Mainly, I've been trying to improve the API a bit. That's resulted in lots of internal changes, but it's mostly done now. 15:30 I'm currently working on getting the compiler changes into a state where they can be upstreamed. 15:30 Then I'll make a new release of the compiler, and then a first release of the RPC library. 15:30 (that's it from me) 15:32 that looks great :-) I already said it on the mailing list, but I really like capn-proto 15:32 Cool, thanks talex5 :) 15:32 especially that you can easily pass functions/callbacks around 15:33 Yeah, thanks for the feedback! 15:33 Hopefully there's slightly less boilerplate now. 15:33 talex5: does the multiple agents RPC thing works? 15:33 Hum, I should take a look at the pipelining 15:34 Is it automatic ? 15:34 thomasga: 3rd-party hand-off? No that will require crypto support first. For now, it just relays messages in that case. 15:34 Drup: yes. 15:34 talex: "Level 3: Three-way interactions" 15:34 talex5: could you point to the part of the API that enforces that ? 15:34 I guess we don't have this yet :-) 15:35 There's an example at https://github.com/mirage/capnp-rpc#pipelining 15:35 A capability promise is a bit like an Lwt promise, but if it knows that the answer is coming from a remote site then it forwards all queries there, since that will be the first to know the answer. 15:36 If you don't want that, you have to tell it to wait explicitly. 15:36 So it is indeed similar to staging 15:37 (Callback beings your explicit antiquotation) 15:37 Not sure I follow that. 15:37 eliom also does this form of automatic pipelining, hence my curiosity 15:38 Everything here is runtime. 15:38 The schema compiler is just for type safety. 15:38 Well, yes and now, you have two "run times", before sending the message and after receiving it 15:39 staging ≠ code generation 15:39 anyway, that's off topic, I was just curious, I should take a closer look 15:40 there is one more item on the agenda: amirmc was curious about the state of our call recording 15:40 sorry, by "call recording" I mean IRC logs 15:40 Unless something changed while I was on holiday, we have nothing beyond whitequark's logger. 15:41 What happened to the unpurecamelbot that used to do the job? 15:41 The imaginaryfriend + canopy setup is in some bitrotted state I think, but I don't know the details 15:41 avsm and engil, I think, have keys to it and can probably say what's wrong 15:41 The logs on http://canopy.mirage.io/irclogs seem to stop in June (and the ordering is wrong). 15:42 Presumably whitequark's logger is running and someone can update the logs on canopy manually? 15:42 (By cut-n-paste) 15:42 yes, there's an outdated issue calling for folks to do that at https://github.com/mirage/canopy-data/issues/16 , but there are more dates needed now 15:43 Right, so that issue is just a case of "doing the cut-n-paste". Unclear what needs to be done to make the automated stuff work again. 15:43 Correct. 15:44 Neither avsm nor engil are here it seems. 15:45 So, amirmc, if you have the time to do the cut-n-paste, that would be awesome. canopy should be running (I run it now :)) 15:45 https://github.com/mirage/canopy-data/issues/22 15:45 I've created a "revive imaginary friend" issue and tagged avsm and engil there 15:45 Sounds good. 15:46 If there's isn't much (any) massaging needed, I can take a look at copy/pasting the July calls. 15:46 I'll have some time tomorrow to look at it. 15:46 That'd be great, amirmc :) thanks! 15:46 we have nothing else on the agenda. any other business? 15:47 We should try and fix the bot though or just switch to the Debian MeetBot. 15:49 amirmc: do you have time to investigate meetbot? 15:50 I've poked around before so I'll do that again and describe what needs to happen to get it set up. That's not a promise to set anything up btw :P 15:50 Thanks :) 15:51 I'll summarise in an issue on mirage/mirage-www 15:51 Sounds like that's all for us! 15:51 Thanks, everyone! 15:52 * mato 's laptop battery is at 10%, I think that means "go jump in the lake" 15:52 yomimono: Thanks for leading. 15:52 mato: have fun!!