<Drup>
hum, eq should probably go back in functoria_key
<yomimono>
(your original statement was unambiguous, the others are match_'s
<yomimono>
)
<yomimono>
ack, could definitely be used other places
<Drup>
the code is indeed clearer, the downside is that the dot will not indicate exactly the choice structure depending on keys :(
<yomimono>
I think I'm missing something about how to make good use of the dot output
<Drup>
You will get a big "choice node" that depends on all the involved key and 4 outputs, not a decision tree
insitu has joined #mirage
<Drup>
yomimono: alternatively, the dot output is not the right presentation for your usage. ;) I wouldn't mind having feedback on that part
<yomimono>
Drup: yeah, I was just about to ask what kinds of questions you envision the dot output answering
<yomimono>
probably "what will I get if I set this key", right?
<Drup>
yes, mostly
mort___ has quit [Quit: Leaving.]
<yomimono>
which does seem like the sort of thing a user would want to know, but I'm definitely more used to invoking a --help when confused about that sort of thing
mort___ has joined #mirage
<hannes>
I'd guess the underlying question is: can we have nice code and nice dot output? what is needed to make this happen (maybe Drup can PR how it should be done?)
<Drup>
hannes: this is something I wondered too, and I don't have an answer
<Drup>
either you use a if, then functoria know about if, and you get a nice structure, or you use a match, and then you don't
<hannes>
certainly nested choices in the dot output aren't too nice, but maybe choice2/3/4/5/6 should then be provided by functoria?
<Drup>
I would like to find good encoding for sum types that would make match convenients, but didn't really got time to pursue that
<hannes>
!
<hannes>
+1
<Drup>
(so I settle for this list-based solution with a default case, which is kinda crap, but workish enough)
<Drup>
(and If you look at the implementation of match_impl, it's basically a chain of If ...)
<hannes>
Drup: do you get one node with n edges for match_impl (of n cases), or n nodes with 2 edges each?
copy` has quit [Quit: Connection closed for inactivity]
<Drup>
huum, I don't remember
<Drup>
I wanted the former, but did I implemented it ?
<Drup>
doh, nothing compiles anymore since mirage and www/skeleton are partially out of sync :(
<yomimono>
mirage-skeleton branch mirage-dev or master?
<yomimono>
drup: there's also a mirage-dev branch of mirage-www but since that doesn't get built automatically it might really be broken atm :(
<mato>
is there a way i can get opam to tell me all known packages that depend on X (reverse depends)?
<yomimono>
opam list --depends on X
<yomimono>
sorry, --depends-on
<yomimono>
ugh, unicorns when I try to look at mirage-www on github :(
<hannes>
yomimono: ah, that should build again now that fat has a conflict with wt-2.6 in opam-repo..
<yomimono>
hannes: thanks for taking care of that
<yomimono>
drup: say more things about your problem; you shouldn't be totally unable to build everything
<hannes>
still, mirage-www (on mirage-dev branch) is broken after my console changes... i tried briefly to fix it, but couldn't..
<Drup>
it's fine, I'm just extremly mirage-rusty
<hannes>
ended up that i thought the whole logging should rather use logs instead of console.log
<Drup>
hannes: it will show one node with n outputs
<hannes>
and then fell asleep, sorry
<hannes>
Drup: that is good!
<Drup>
I coaless If nodes
<hannes>
ic
<Drup>
(can be seen directly in mirage-skeleton/stackv4)
<yomimono>
hannes: yes, I think you're right that it should use logs
<yomimono>
hannes: then we could perhaps export them to syslog and look at them
<hannes>
syslog them to /dev/null
<yomimono>
or throw them down the memory hole where no one will ever see them
<yomimono>
jinx
<Drup>
which ... result in a weird behavior for the new console
<Drup>
huum
<hannes>
that's what i do with my logs
<yomimono>
emerging best practice in these trying times
<Drup>
huum, the dot graph for stackv4 has grown significantly bigger and more spagetti with the qubes stuff
<yomimono>
https://status.github.com/messages says major service outage, so now might not be the time to try to figure out whether our tests pass
<yomimono>
(I mean, if they do that's great, but they're probably going to have a lot of transient pull failures)
<hannes>
oh wait... there's this new distributed version control system out there which should be tolerant to failures of single entities *runs away*
<yomimono>
yes, and it would be lovely to use it that way instead of putting all of our code on one server that then can sometimes fail, and telling all of our testing infrastructure to look there, I agree
* mato
is still wanting the "please use local git mirrors of *everything* instead of whatever the remote is" mode for opam
<yomimono>
mato: I want this too and I think it may actually already sort of exist -- opam info mirror suggests such a thing
<mato>
that plus "here's a manifest of {repo+commit}...", please use these and these only
<mato>
yomimono: yeah, but unclear if it'll work with git:// URLs
<hannes>
isn't this sth best to-be-solved outside of opam, i.e. a transparent git proxy?
<mato>
possibly. except that with the world hell bent on https-is-everywhere, proxies (transparent or not) are becoming somewhat more useless over time
<hannes>
afaics fetch (wget) respect HTTP_PROXY env var, and use http instead of https to the proxy.. plus you can inject your own CA since it's after all your computer..
<hannes>
but I may be too idealistic here... and the git version pins certainly need some opam support (but I guess you can already pin to a version, similar to a branch)
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Drup>
yomimono: going back to the previous topic. What do you use describe --dot for (if you do)/what kind of visualisation would like to have ?
<yomimono>
Drup: I don't really use it at all unless I'm talking with you and you tell me to look at it :P
<yomimono>
Then I usually look at it and say "yes, it appears that I indeed made mirage do something nonsensical" and close it
<Drup>
x)
<yomimono>
could be useful in noticing that some component is being shared that shouldn't be
<yomimono>
hm, annotations when I run it with --eval would be nice, I think
<Drup>
annotations ?
<yomimono>
reasons for choosing a node
<yomimono>
but tbh I'm really bad with visual things and usually prefer to use words when possible
<yomimono>
I'm not a good person to ask about things like this
<Drup>
I see
<Drup>
(I'm the opposite, I do little graph drawing everywhere, hence why I made that dot thing ...)
<yomimono>
it would probably be very valuable for me if I were hacking around in the actual graph stuff in functoria
<Drup>
yomimono: so what kind of feedback would you like ? describe+config.ml is good enough for you ?
<yomimono>
Drup: I've done a lot of hacking in printf debugging, I'm sorry to say, and then running mirage with -v
<yomimono>
I don't use describe very often either
<Drup>
:(
<yomimono>
sorry :(
<Drup>
what do you use the printfs for ?
<yomimono>
you might get less depressing answers on the mailing list
<yomimono>
drup: most recently I was using them to try to figure out how I was getting such confusing results after changing generic_stackvv4
<yomimono>
but I think the problem is that I'm hacking on mirage, not using mirage to build some other application, most of the time
<yomimono>
so it's not really the use that you intended, I don't think
<Drup>
actually, it sort of is
<Drup>
maybe a choice log would be useful ?
<Drup>
"I reduced this If node because that keys had value plouf" ?
<yomimono>
yeah, that's the sort of thing I'd like, I think
<Drup>
(--eval was meant to provide that, but I guess it's not detailed enough)
<yomimono>
part of it isn't really a deficiency of the tool, but --dot doesn't do the right thing on my system; I have to save a file and then open it with xdot which is annoying
<yomimono>
(--dot opens xdot but the graph doesn't display)
<Drup>
ah
<Drup>
but that's an unreported bug :<
<yomimono>
yes, I have consistently forgotten about it two seconds after encountering it every time
<yomimono>
best reported in mirage/mirage or mirage/functoria?
<avsm>
a few people travelling and such today, so lets get started
<seangrove>
o/
<avsm>
First up is the release schedule - yomimono, take it away
<yomimono>
i'd hoped to tag a beta yesterday which clearly didn't happen
<yomimono>
but I'm still hoping to do that this week
<yomimono>
it's silly to do it before we're done making really huge API changes, and there's one big outstanding one: result errors
<yomimono>
so I'm trying to get that into close-enough shape to PR and merge first.
<mato>
what does "tagging a beta" mean exactly?
<amirmc>
Could we summarise the rough outline of the path to 3.0?
<amirmc>
and I also have the same question as mato :)
<yomimono>
mato: specifying a version (not dev~mirage) for mirage-types then expressing that version constraint for the universe of stuff that's currently in mirage-dev
<yomimono>
mato: also plan on renaming V1, V1_LWT before this change
<avsm>
So the good news is that once the API churn has stopped, this can happen in the existing mirage-dev; just convert the dev.mirage versions to concrete archivs
<avsm>
we do need to set upper bounds early on in opam-repository though
<mato>
yomimono: So, in practice, if someone wants to install the beta, what would they do?
Hannes__ has joined #mirage
<mato>
yomimono: and, conversely, what happens to fixes in between the beta and 3.0?
<yomimono>
mato: similar workflow to how you end up with the mirage3 stuff currently: custom repo, then opam install
talex5 has joined #mirage
<mato>
so there'll be a short-lived mirage/mirage-dev#beta or something like that?
<yomimono>
mato: depends on the magnitude. I'd imagined a lot of point "releases" for things within mirage-dev
<Hannes__>
I guess the ability to specify version constraints in config.ml should also be fixed asap, since otherwise we end up in the same situation as now: we can't express support for a given mirage-types in a unikernel
<yomimono>
mato: something like that, yeah.
* mort___
says hi
<avsm>
that version constraints issue does seem pressing :-/
* mato
is just trying to understand how easy it'll be to point users to trying out the beta
<amirmc>
^^ same
<avsm>
A separate remote is a fine way to distribute the beta
<yomimono>
hannes__: everyone agrees that it would be nice to have, but nobody has had time to do it
<Hannes__>
It seems to be easy if we remove the opam calls from mirage configure and use a make depend instead
gemma_ has joined #mirage
<mato>
also, is "tagging a beta" dependent on tagging actual versions of all the unreleased packages in mirage-dev?
<yomimono>
mato, amirmc: what's your dream workflow for getting the beta?
<avsm>
One uncomfortable point right now is that `mirage configure` can also invoke `opam pin`, if you activate tracing, so its quite side-effectful
<yomimono>
mirage configure doesn't do that by itself
<yomimono>
avsm: it gives you some help text telling you that you should do it
<mato>
yomimono: having a separate remote available for trying out the beta (with instructions) is probably good enough for me
fgimenez has quit [Ping timeout: 268 seconds]
<avsm>
yomimono: yeah good point; I just c&p it blindly ;-)
<djwillia>
avsm: where's the best place to learn about "tracing"?
<amirmc>
yomimono: I think something like `opam install mirage.beta1` would work (I'm totally making that up on the spot btw - no idea if it's sensible).
<mato>
amirmc: that would depend on getting all the beta dependencies into upstream opam proper
<Drup>
amirmc: better use the mirage-dev repo for that
<djwillia>
avsm: thanks
<yomimono>
amirmc: would `opam remote add mirage-beta url && opam install mirage.beta1` be significantly worse from your perspective?
<avsm>
So the real goal of the first beta is to discover any show stoppers in APIs, not to have a fully reproducible beta1. So to some extent, we could even release with just the mirage-dev instructions without tagging releases
<yomimono>
(which is what drup and mato are saying)
<avsm>
Although tagging some of the core libraries seems prudent
<amirmc>
Asking people to add a remote and remember to remove it later seems complicated. If that's the best way for now, then fine. :)
fgimenez has joined #mirage
fgimenez has joined #mirage
fgimenez has quit [Changing host]
<yomimono>
avsm: true, but it would be nice for people to know they have "the beta" rather than some old version, which right now they have no way of knowing
<mato>
+1
<yomimono>
if we're going to ask people to try things and report errors, I'd rather be able to know that they're not running into stuff we fixed weeks ago :)
djs55 has joined #mirage
<mato>
amirmc: we can probably add some magic conflicts to ensure that you're either on the beta remote or not (yomimono?)
<amirmc>
If we want people to use mirage-dev, we don't need to mention 'beta1' at all. Just be on mirage-dev for a while.
<avsm>
right, that's true, so we want to distinguish: mirage.2.9.1, mirage.3.0.0~beta1, mirage.dev~mirage
<yomimono>
we can express versions within mirage-dev
<Hannes__>
Calling it beta1 helps!
* yomimono
nods
<amirmc>
But current issue is that if people are trying to be productive a global remote affects other switches.
<avsm>
Bear in mind that we do not want beta1 to survive in the wild very long; there is only a month-long release window.
<avsm>
so confining it to the warm confines of mirage-dev would be prudent. It should not hit ocaml/opam-repository
<Drup>
amirmc: jump on the opam 2.0 bandwagon ? :D
<Hannes__>
after all, there is a schedule?
<mato>
Sure, but (what amir said) we don't want the beta to potentially break people's existing working mirage 2 setups, whatever those might be
<amirmc>
drup: heh! one thing at a time :P
<Hannes__>
amirmc: agreed. We can prove a shell script with pins as well
<Drup>
(it was a joke, even if per-switch repositories are really cool)
<avsm>
amirmc: are you keeping the issue body uptodate with the comments?
<Hannes__>
S/prove/provide/
<amirmc>
avsm: Is there something missing there?
<avsm>
mato: I think we just have to clearly document the limitations of remotes in OPAM 1.2. We can't solve every upstream tooling problem
<avsm>
amirmc: I dont know, I havent cross checked all the comments, hence my question :)
<amirmc>
avsm: I don't think there's anything to add to that issue. The only thing that isn't clear is what the rough timeline looks like.
<mato>
avsm: Ack.
<amirmc>
avsm: The checkboxes haven't changed and the announcement activity is the same. Just when things are expected to happen.
<avsm>
amirmc: ack, I (literally just now) added another one for the performance harness
<avsm>
Alright, so we can get a sensible schedule once we do the last of the API churning merges
<avsm>
and get the V1 renaming in
<avsm>
but broadly speaking, still aiming for a beta this month with a website update, and a final release in January
<yomimono>
unless everyone changes their minds and decides that the current error interface and names are just great and nothing needs to change :P
<avsm>
from experience, it takes a significant amount of time to tag and release, so I would account a few days for that
<avsm>
and adding upper bounds and so on
<mato>
indeed.
<Hannes__>
But now we've topkg nearly everywhere :D
<mato>
so IIUC the beta1 remote does not depend on tagging or releasing the component packages?
<avsm>
mato: it makes sense to tag as many as we can
<avsm>
since that's the only vehicle by which we can constraint other packages
<yomimono>
mato: in practice, the fewer of them we tag the harder it will be to diagnose problem reports
<yomimono>
but it's not a strict requirement
<mato>
yomimono: hm. i'm away from tomorrow until the end of the week. so won't have time to tag the solo5 packages until i get back.
<amirmc>
I'm happy to review and walkthrough any instructions relating to the beta process. I'd like to get the early adopters using it. Just ping whenever's there's something to look at.
<avsm>
amirmc: sounds good!
<yomimono>
mato: is there a reason not to just tag current HEAD in a working universe?
<avsm>
mato: i have solo5 access right? i can do the tags on HEAD if you are away
<avsm>
jinx :)
<Hannes__>
I guess an initial upgrade guide would be nice to have for beta testers as well
<mato>
avsm: yomimono: what i don't understand is is it just a tag or a full "release", i.e. new opam version number, changelog, etc.
<avsm>
i'd be surprised if we tag before Monday though
<avsm>
It's a full package release
<avsm>
just not uploaded to ocaml/opam-repository yet
<avsm>
but instead pushed to mirage/mirage-dev
<amirmc>
We'd need to point to the mirage-dev branch of skeleton too. That'll likely be helpful.
thomasga has joined #mirage
<mato>
avsm: yomimono: in that case i'd prefer to be around while that's being done.
<avsm>
ok, so anything burning on any individual issues yomimono (aside from the opam constraint)
<yomimono>
mato: ack.
<avsm>
mato: early next week should be fine
<mato>
sounds good
<yomimono>
avsm: would like to reiterate the opam constraint. I doubt that will involve API changes but it's pretty important and it seems no one has looked at it seriously yet
<avsm>
yeah, it does seem very important :-/
<avsm>
at least if we hold the beta to mirage-dev, we have December to do it in
<avsm>
since its only a real disaster once we have incompatible universes in opam stable
<avsm>
ok, onto the next topic...
<avsm>
compilers! OCaml 4.04.0 came out, and the package universe is slowly adapting
<avsm>
thanks mato for getting ocaml-freestanding working with it, so Solo5/4.04 should be good to test with
Hannes__ has quit [Ping timeout: 260 seconds]
<avsm>
if anyone sees any packaging issues, please do raise them so that they get attention
<avsm>
most of the ppx universe should work now (ppx_sexp_conv and so on)
<yomimono>
xen/4.04 should be working as well, just to be clear
<yomimono>
please report problems with that too :)
<avsm>
yes sorry -- both xen and solo5. I'm going to shift mirage-www over today hopefully
<yomimono>
awesome!
<avsm>
we are still doing deployment builds on 4.02, no reason not to move now