<yomimono>
I don't see our friendly camel logger, so we'll depend on _whitelogger for logs for the catchup.
<avsm>
Sounds good! I am currently compiling up the self-hosted infra on a brand new packet.net machine :-)
<djwillia>
hi all
<avsm>
I will paste the logs into canopy-data
<avsm>
hi djwillia!
<yomimono>
thanks avsm! :D
<yomimono>
Last meeting's call for a summarizer is still open -- if you're here and you want to write up a summary of what we've discussed and decided, that would be very welcome!
<yomimono>
If you do so, let everyone know on mirageos-devel.
<avsm>
I'll send a complementary camel bubblegum sweet to any volunteers
<yomimono>
:D
<avsm>
they are delicious
<amirmc>
Even a few short paragraphs would be helpful. No need for it to be extensive prose :)
<mort___1>
always wondered why camels are always chewing. now i know.
<yomimono>
Seeing nothing that's been added before the first agenda item...
<yomimono>
the first thing we have is "MirageOS 3 beta - it's so great and extant!"
<hannes>
(I have evidence that camels are delicious, indeed)
<yomimono>
instructions on trying it out are in the README
<yomimono>
several user libraries (irmin, nbd, etc) are not yet accounted for there, but the libraries that get used by code generated by `mirage configure` should be all good to go.
<yomimono>
Please try it out!
<mato>
Should those instructions also recommend to remove any mirage-dev remote?
<avsm>
I've been following it and working well so far. Only minor fail was I used a 4.02.3 installation and got a slightly cryptic failure
<yomimono>
Good catch - yes, mato, they should, since the versions there will be above the actual release versions referenced in the beta repo
<avsm>
Should we put a hard 4.03.0 restriction on mirage.3.0.0 so that attempting to use the CLI from OCaml 4.02.3 will fail?
<reynir>
o/
<mort___1>
58
<mort___1>
(sww)
<avsm>
There are also presently bad checksums for nocrypto in the staging tree so that will fail
<yomimono>
avsm: that should already be in place, if not yes
<thomasga>
(I would love to be able to continue to use my libraries on 4.02.3 if possible)
<yomimono>
thomasga: restricting the mirage frontend to 4.03.0 and above shouldn't stop you from doing that, though
<thomasga>
so I'm fine with the restriction then :p
<yomimono>
yay :D
<amirmc>
So with all those PRs now merged, are we officially in beta mode?
<yomimono>
yes, once the checksum for nocrypto is fixed I'll send a mail to the list
<amirmc>
Fabulous!
<avsm>
amirmc: codewise yes, I am still working hard on the new website and hope to have something to show around more widely by Friday
<avsm>
(it's a fairly simple Jekyll-based effort, so the main change is that deployment is far simpler, via the stock static_website mirage-skeleton example)
<avsm>
that's a fairly ridiculous number of new packages. Great effort tagging and getting all those staged!
<thomasga>
I concur, this is an epic release :-)
<avsm>
One thing to test is upgrades from mirage2 to mirage3 -- in particular, root packages installed in the old world may render mirage3 not installed without a specific version. We should possibly recommend `opam install mirage.3.0.0`
<yomimono>
huge thanks to all of you :)
<avsm>
and to you for your release management epicness, yomimono!
<mato>
^^^ +100
<amirmc>
Most important from that list (for the beta phase) are some kind of migration docs … but that's an agenda item so we'll get to it.
<hannes>
we'll need a new pcap-format release (since older versions had depopts on mirage-net-0.X, and now are conflicting with the new mirage-net packages) -- I prepared https://github.com/mirage/ocaml-pcap/pull/23 in case someone has strong feelings about the print and mirage subdirs, please say so
<mort___1>
hannes: thanks, looking at that, will get to it this afternoon
<mort___1>
i doubt i have strong feelings though :)
<avsm>
and thanks for the DNS PR hannes. I'm not sure it's a good idea to migrate ocamlfind package names in the same release as a topkg migration, but I guess we can fix up upper bounds in one go.
<hannes>
avsm: I confused myself within 4 hours several times over dns-lwt (the lwt-unix stuff) and dns-lwt-core (the actual core, independent of unix).. and there are few reverse dependencies, thus I decided it is worth doing
<avsm>
hannes: yeah might as well be consistent
<thomasga>
(please keep consistent names — e.g. same names for packages and libraries :p)
<yomimono>
any other TODOs or questions?
<avsm>
I'm good -- have progressed through to figuring out how to configure static IP and bridging for the infrastructure
<hannes>
will there be a release party?
<avsm>
(got past nocrypto with a pin)
noddy has joined #mirage
<yomimono>
hannes: I'll be holding a party in Madison WI, all are welcome to attend :P
<avsm>
hannes: yes, we must have one! perhaps morocco is the right place :-)
<amirmc>
Shall we move on to the next item? Or did we cover that already? "Revisions to introductory materials (@yomimono with thanks to @mor1)"
<yomimono>
not yet! I just wanted to mention that I'm working on tutorial rewrites as discussed by me, drup, and mor1
<yomimono>
I'm also carving the mirage-skeleton repository into tutorial stuff, device usage examples, and higher-level applications
<mato>
By the way, there's still the rather annoying user-visible issue of "mirage --help" and "mirage <command> --help" dying with a cryptic error. hannes, I believe you had some fixes for that?
<yomimono>
I've removed a bunch of stuff that I thought was redundant -- you can see my branch at https://github.com/mirage/mirage-skeleton, branch split-examples-from-tutorial
<mort___1>
yomimono: as i'm clearly a bit rubbish at keeping up — point me at the next bit it would be useful to re/write, and i will
<yomimono>
mort___1: awesome, i'm merging your prose changes in right now :D
<avsm>
yomimono: mort___1: I've created (but not yet documented) a new skeleton website at https://github.com/mirage/mirage-bushel-www. It's easy to port mirage-www changes over to it, but we should sync up on thursday evening or so I expect
<yomimono>
well, not *right* now, right now I'm dinking around in IRC
<mort___1>
@mato: +1 was typing that exact same comment just now :)
<avsm>
the --help thing is getting me all the time. I never use `cmd help`, and support the -f removal
<mort___1>
+1
<yomimono>
I think I'm the only one who's got a :( about removing -f, so merging 101 is probably the right thing to do
<hannes>
yomimono: great (reviving tutorial, updating mirage-skeleton): there are also examples in tcp/examples and https://github.com/cfcs/mirage-examples which may be worth looking into
<thomasga>
(bouhouhou about `-f`)
<yomimono>
hannes: yes! I'd like to have a reasonable home for the things that are just "here's how you use X", and have there be more of those, in addition to the list of application examples you've said would be nice
<mort___1>
(sorry, to clarify: i don't have strong opinions on `-f` — it's a nice but not necssary — but `—help` breaking is very unacceptable)
<thomasga>
(but I see the merit of simplifying that bit of code which was quite hackish)
<thomasga>
I am fine to re-add `-f` later if life becomes too hard without it
<avsm>
if anyone gets a chance to try the new opam2 local build functionality, then `opam build` should "just work" locally on the mirage3 unikernels
<avsm>
once `mirage configure` has been run
<thomasga>
avsm: that's excelent!
<thomasga>
it's a pretty nice side-effect of both independent features :p
<avsm>
(Louis requests feedback on it, so now's a good time)
<yomimono>
I'll retroactively add an agenda item noting that :P
<yomimono>
avsm, did you have more to say on migration docs, our next item?
<avsm>
Only that I'm documenting my migration process on the live infrastructure, and intend to serialise it into a document
<avsm>
Current progress is: 1) new jekyll-based static html website (ongoing, should be 2 more days to show off on list for wider feedback/contribs) 2) Travis/DataKit deplotyment support via static_website
<avsm>
and 3) figure out all the packet.net runes for deploying the static ip website (bridging setup etc)
<amirmc>
Thanks. That'll be useful for folks who'll be coming at this cold. I know the folks at Ericsson will find it useful.
<avsm>
all seems fairly straightforward, will just take a couple of days to settle down.
<avsm>
amirmc: excellent, i'll put it up as soon as I have something working.
<yomimono>
other items?
<avsm>
How's the hackathon prep going?
<amirmc>
Anyone fancy writing some blog posts? I think GemmaG might have been chatting to people. :)
<yomimono>
that's twopoint718 who's often here, although I don't see him atm
<avsm>
wow, can't wait to read that
<hannes>
it's like a rollercoaster... days where I get up to 5 mails with some people dropping out, others joining.. I'd guess we'll have a stable participation of more than 30 people!
<hannes>
apart from that I try to stay away from organising too much -- there is still code which needs to be written
<thomasga>
we definitely need more books on MirageOS :-)
<yomimono>
+1
<yomimono>
The Littlest Functor
<amirmc>
Maybe after this round of breaking changes has settled ;)
<hannes>
amirmc: I'd like to (at least contribute) to a post on 'how MirageOS3 got smaller and more dumb' -- taking a look at generated main.ml, and generated binaries (they are smaller, aren't they? ;)
<thomasga>
"The Unikernel which does Nothing"
<amirmc>
hannes: That sounds great! thomasga: That sounds like one of talex5's posts :P
<yomimono>
inspiration for the `noop` example which mor1 wrote into the tutorial already!
<mort___1>
looks like a default build of the noop unierkenel in teh new skeleton comes out at 2.7MB for me
<yomimono>
so perhaps we're already a lot of the way to that book :D
<thomasga>
yea I remember! That would make a pretty cool book title :p
<mort___1>
(targeting unix on osx)
<avsm>
it may or may not be a coincidence, but the latest member of OCaml Labs is 4 hours old today, so we have multiple releases
<yomimono>
:D :D :D :D :D :D :D
<yomimono>
is it legal to hire babies in the UK?
<mort___1>
not yet
<avsm>
gotta teach them good programming practise early
<mort___1>
afaik
<hannes>
:D
<avsm>
especially garbage collection
<yomimono>
hannes: should we add that blog post to the list of things to do on #592?
<avsm>
Alright, I can report a successful solo5 and xen build with the beta branches, for mirage-skeleton. wooop :-) not live yet but as soon as I get static ipv4 addresses...
<avsm>
mort___1: would be good to strip the debug symbols and compress and see how it looks
<hannes>
yomimono: sure
<mort___1>
`strip main.native` —> 2.08MB
<thomasga>
with flamba?
<mort___1>
bzip2 -v9 —> 584kB
<hannes>
sounds pretty big too me... is the lto branch still active? ;)
<mort___1>
ocaml 4.04.0
<mort___1>
(system compiler on osx currently)
<avsm>
So we will probably have a couple of weeks to look for issues with the release, update website/etc, and then announce the release. amirmc is coordinating that with the Linux Foundation -- any ideas on dates yet?
<hannes>
LF + xen + docker? + IBM + Ericsson ?? or who's involved in the announcement?
<avsm>
hannes: yes we should be able to experiment much more easily with the lto and flambda branches now. Takayuki's performance harness is making excellent progress. It just needs solo5 support for mirage-profiling...
<amirmc>
No feedback on dates yet. Waiting to find options that work for all parties, which seems to be rticky.
<mort___1>
yomimono: i have an aob / mirage3 item i just remembered for the agenda — shoudl i add to wiki or just bring it up at the end?
<avsm>
now's probably fine...
<yomimono>
we're out of agenda items, so go for it
<mort___1>
is a question more than anything — where does talex5 tracing/profiling stuff sit with mirage3 currently?
<mort___1>
fully supported? untested?
<mort___1>
somewhere between?
<amirmc>
hannes: First thing to do is figure out possible dates. LF is handling the release (though we'll write/rewrite), and Docker is also involved.
<yomimono>
talex5 got the fork building again a couple of weeks ago. I've been building with it occasionally for unix/xen
<yomimono>
no tracing for solo5 as yet.
<talex5>
It's mostly not specific to Mirage anyway.
<yomimono>
related to that, I'd like to make a more compelling example for its use - right now the unikernel in "tracing" in mirage-skeleton is not super interesting
<yomimono>
needs more threads!
<mort___1>
ok— are there up-to-date instructions anywhere for how to use?
<mort___1>
context is: i have a masters student who's project is to use the (mirage) tracing stuff to build magpie-like tools
<yomimono>
no change to usage instructions since some time ago, but I can make sure that the most discoverable ones are easy to find and accurate
<mort___1>
and now he's getting going i'd like him to turn to mirage3 rather than mirage2 if at all possible
<mato>
Tracing for Solo5 needs (afaik) figuring out a shm interface to the profile data. Could be done with a ukvm module. Probably not doable/worth doing for the virtio target.
<mort___1>
ok— if having a more interesting example using tracing is useful, i can point him at that (i just told him to go and build himself an example anyway)
<yomimono>
excellent!
<mort___1>
i shall bear ukvm/solo5 in mind when it comes to looking at how to span the gap bewteen unikenrel and host — @mato may come asking for help at that point :)
<avsm>
mato: takayuki could really use a ukvm tracing backend to compare xen and solo5, vs unix.
<djwillia>
also ricardo and I would be happy to spend time on a ukvm module to assist with tracing if we can better learn how it works
<mort___1>
finally — is there a list of libs anywhere that utilise tracing particualrly?
<avsm>
mort___1: good question -- only from the dependency graph (they would depend on mirage-profile)
<yomimono>
tcpip has a lot of labeled stuff in it
<mort___1>
cool, i was hoping you'd say that :)
<mort___1>
what about cohttp (or http/af??)
<avsm>
nothing in there right now
<thomasga>
takayuki has a lot of tracing graphs
<mort___1>
(or taka's perf harness maybe?)
<mort___1>
yes, maybe i should point him at those tools first
<mort___1>
thanks all
<yomimono>
thanks mort! look forward to seeing what your student puts together :D
<talex5>
mirage-logs also forwards Logs debug to the trace buffer, so anything using that will produce some annotations.
<mort___1>
me too … ;)
<mort___1>
ah! thanks @talex5 that's useful to know
<yomimono>
feel free to direct them my way for whatever you think I can be helpful with :)
<avsm>
talex5: ah very good point. Cohttp should definitely use more Logs
<hannes>
speaking of Logs.. there are also some libraries not being safe-string aware.. just sayin' ;)
<avsm>
the long tail of porting continues...
<hannes>
(and yes, more wide use of Logs, e.g. in tls, would be great)
<yomimono>
anything else?
<hannes>
thomasga: could you make git+irmin releases for MirageOS3? then I could build canopy out of the box :)
<thomasga>
hannes: I need to merge my big PR first
<thomasga>
I have some feedback from @talex5 that I want to integrate
<hannes>
c'est la vie
<thomasga>
And some docs to add. I hope to do that before the end of the week (but more probable merging date is next week)
<thomasga>
so please pin it to #mirage-dev for now on :-)
<thomasga>
I have a minor API change to do in ocaml-git too, before the release
<thomasga>
but everything is on track, not very far from the 1.0 release or Irmin (yay)
<hannes>
\o/ \o/
<yomimono>
yaaaaaaay
<yomimono>
it being 55 minutes after the start time of our catchup, and having discussed several additional items, I pronounce our catchup complete
<yomimono>
we seem quite caught up now
GemmaG has left #mirage [#mirage]
<avsm>
And logs pushed. Thanks everyone!
<demonimin>
hannes: sorry, I'll try to push it tomorrow. It's in an early state, and I need to write a README
<hannes>
demonimin: :D
amirmc has quit [Quit: Leaving.]
talex5 has quit [Quit: Leaving]
balduin has quit [Ping timeout: 255 seconds]
brson has joined #mirage
fgimenez has quit []
thomasga has quit [Quit: Leaving.]
djs55 has joined #mirage
philtor has joined #mirage
avsm has quit [Ping timeout: 260 seconds]
<mort___1>
yomimono: any objections if i go ahead and merge pqwy nocrypto hash PR?
<yomimono>
none! please go ahead, sorry I missed it
djwillia has quit [Ping timeout: 260 seconds]
<mort___1>
done :)
<yomimono>
someone handed me a nice coffee at the exact right moment to distract me from that
<mort___1>
nice coffee is a nice thing
<yomimono>
:D
<mort___1>
great, nocryprto pin no longer required
<mort___1>
avsm ^^
noddy has quit [Ping timeout: 260 seconds]
balduin has joined #mirage
copy` has joined #mirage
<tg>
anything mirage/ocaml related going on at fosdem?
<yomimono>
hm, good question -- I don't know of anything, but I'm not attending fosdem myself
<tg>
me going there this time, haven't been in ages..
<yomimono>
was there in 2015, amir did some demos at the Xen booth but I think he's not attending this year either
<yomimono>
might be worth asking on mirageos-devel :)
<mort___1>
i'm not aware of anything either
balduin has quit [Ping timeout: 264 seconds]
mort___1 has quit [Excess Flood]
mort___ has joined #mirage
noddy has joined #mirage
djs55 has quit [Quit: Leaving.]
<mort___>
anyone here know about .cmx vs .cmi or .cmti files?
<mort___>
…because mirage-types (having no implementation) provides only .cmti, but module aliasing and merlin both seem to want something else, possibly a .cmx file
<def`>
mort___: merlin uses cmi for completion and type-checking
<def`>
cmti for locate
<def`>
cmx don't contain type information, it's the ocaml view of a code object (.o)
<mort___>
then i'm just confused
<mort___>
:)
<def`>
mirage-types should provide cmi
<mort___>
if i try to "module M = Mirage_types" and "module Mlwt = Mirage_types_lwt" because I'm lazy and like to reduce typing, the compilation phases whines at me and refuses to compile
<def`>
cmi is a compiled interface
<mort___>
ok
<mort___>
mirage-types does provide cmti, yes
<def`>
cmti or cmi?
<mort___>
just a sec
<mort___>
```
<mort___>
: mort@greyjay:mirage-3$; ls -l .opam/system/lib/mirage-types
<mort___>
-rw-r--r-- 1 mort staff 17333 Feb 1 17:31 mirage_types.cmti
<mort___>
drwxrwxr-x 4 mort staff 136 Feb 1 18:15 _build/
<mort___>
-rw-r--r-- 1 mort staff 271 Feb 1 17:31 META
<mort___>
total 72
<mort___>
-rw-r--r-- 1 mort staff 4192 Feb 1 17:31 mirage_types.mli
<mort___>
-rw-r--r-- 1 mort staff 1053 Feb 1 17:31 opam
<mort___>
-rw-rw-r-- 1 mort staff 0 Feb 1 17:31 opam.config
<mort___>
but if i add the line "module M = Mirage_types" to my otherwise-working unikernel, then "make" triggers
<mort___>
File "unikernel.ml", line 28, characters 11-23:
<hannes>
mort___: you built manually? in my ~/.opam/4.04.0/lib/mirage-types I have both cmi and cmti -- in case you built manually, please ocaml pkg/pkg.ml build -n mirage-types and -n mirage-types-lwt as well!
<mort___>
oh, at one point i did try manual bulid (though i thought only local — i didn't tell anything to install, or so i thought)
<mort___>
let me reinstall from opam
<def`>
(note that because of a slightly broken compilation model, aliases to modules without implementation won't compose, but the error message will be different)
<mort___>
install from opam has cmi there too
<def`>
so that's good :P
<def`>
you didn't have cmi previously
<mort___>
yes, sorry, looks like trying to build mirage-types by hand also installed it without me realising
<def`>
I am getting confused too, is problem solved?
<mort___>
no, the error i get now is the one i had prior to trying to build mirage-types by hand:
<mort___>
Mirage_types referenced from unikernel.cmx
<mort___>
Error: No implementations provided for the following modules:
<mort___>
File "_none_", line 1:
<mort___>
…but based on what you say above, maybe that's expected?
<def`>
ah yes, that's what I mentioned above
<mort___>
as Mirage_types has no implementation
<mort___>
ok. is there a workaround for this? (provide some kind of dummy implementation?)
<def`>
it's ugly
<mort___>
or do we just have to not alias it?
<def`>
workaround 1:
<def`>
pass -no-alias-deps
<def`>
this will cause the compiler to not generate dependency for aliases in Unikernel
<def`>
but the risk is pushing the error just one step later: users of Unikernel touching the alias will generate a dependency, and unless they also pass -no-alias-deps, it will fail at this point
<mort___>
users of Unikernel?
<def`>
if another module was to use the "Unikernel.M" module, linking this module will fail
<mort___>
this is just for use in building a mirage unikernel — the only reference to it will be in the associated config.ml file i think
<mort___>
ah
<mort___>
i doubt that would ever happen
<def`>
workaround 2:
<hannes>
I'd just open Mirage_types_lwt.. you never ever need Mirage_types in your unikernel (with Mirage3 at least, might change once new backends are there)
<def`>
generate a dummy implementation, (something like : module type Mirage_types = struct include module type of Mirage_types end module rec Mirage_types : Mirage_types = Mirage_types)
<def`>
solution 1: don't use .mli only, even if there are only types write them in a .ml
<def`>
solution 2: open an issue on Mantis, this behavior is insane :P
<mort___>
hannes: ah ok— at one point i was using (because i thought i had to but maybe i was wrong) Mirage_types.PCLOCK
<hannes>
mort___: there's now a Mirage_types_lwt.PCLOCK :D
<mort___>
def`: workaround 1 sounds plausible but would require change to mirage tool i think (and given what hannes says, not worth it)
<mort___>
def`: rel solution 2 — happy to do so, but i doubt i'd get the terminology right :)
<mort___>
hannes: ack, i'll just open module then. though the ex-python programmer in me abhors polluting a global namespace… :p
<mort___>
`from foo import *` how ugly...
<mort___>
def`: should merlin be able to find Mirage_types_lwt etc? it's showing red for me in emacs and i think i'm referencing it correctly in the .merlin file
<hannes>
mort___: sure, it used to be mirage-types DOT lwt, now it is mirage-types DASH lwt...
<mort___>
tried that, doesn't seem to help
<hannes>
M-x merlin-restart-process
<mort___>
yeah, tried that too. hm. maybe an environemnt thing.
<mort___>
ah yeah, likely to be. never mind
<mort___>
fwiw: i'm trying out mirage-3 in a local OPAMROOT (=$(pwd -P)/.opam)
<mort___>
any chance merlin might be able to pick up it's paths from the .merlin rather than setting globally? or is that a dumb idea?
mort___ has quit [Quit: Leaving.]
noddy has quit [Ping timeout: 240 seconds]
mort___ has joined #mirage
balduin has joined #mirage
<def`>
mort___: still there?
<def`>
what do you mean by setting globally?
gjaldon has quit []
djs55 has joined #mirage
mort___ has quit [Quit: Leaving.]
brson has quit [Ping timeout: 248 seconds]
brson has joined #mirage
djs55 has quit [Quit: Leaving.]
mort___ has joined #mirage
<mort___>
def`: sorry, went home :) i meant: aiui, emacs sets up tool paths etc based on executing opam config var share or similar. i assumed that was how merlin was finding packages containing the cmi files. but i'd like merlin to pick up an OPAMROOT set for this particular repo. (or is there already an easy way to tell merlin this from within emacs?)
<def`>
mort___: if you have findlib in this OPAMROOT, it should be possible to use the same merlin with an environment variable
<def`>
OCAMLFIND_CONF=<path to findlib.conf in your OPAMROOT>
<def`>
if merlin is started with this env var, it should find the local packages
<def`>
(if ocaml was patched, you might also have to update OCAMLLIB env var so that merlin can find the local stdlib)
<mort___>
merlin is being started by emacs (afaik) which is a long running server process
<mort___>
what i'd like is for merlin to pick up the approrpaite OPAMROOT when i open a file in a project
<mort___>
(i never run merlin myself, i just let merlin-mode do it)
<def`>
maybe putting
<def`>
FINDLIB <relative path to findlib.conf>
<def`>
STDLIB <relative path to standard_library, as printed by ocamlc -config>