<hannes>
the overall question is: adding new websites, such as canopy, distributes the information even further... should we try to reconcile and have an idea where which information is stored (in a way that newcomers can easily find available information)?
<hannes>
and if so, is there anybody who would like to work on a proposal (or is the current state good, using various github repositories, wikis, mirage.io, ...)?
talex5 has quit [Quit: Leaving]
<thomasga>
I think canopy greatly simplifies the "push to Git" -> get your website running which is what we already that for mirage.io. In my opinion that's the next logical step.
mort___ has quit [Quit: Leaving.]
talex5 has joined #mirage
<thomasga>
merging canopy and the current deployment workflow makes a lot of sense
<djwillia>
is canopy meant to replace mirage.io?
* hannes
personally would like to store less information on GitHub wikis in the end, and prefers places we host ourselves (and can easily move away from GitHub if it is down)
<thomasga>
e.g. you don't want to recompile a new unikernel if you just change some Git-tracked contents
<amirmc>
Logical step for what though? replacing mirage.io or something else?
<thomasga>
we don't store anything on Github wikis as far as I know
<hannes>
djwillia: this is an idea, I suspect canopy is not yet ready feature-wise (@engil knows more)
mort___ has joined #mirage
<mort___>
hello!
<hannes>
thomasga: PioneerProjects + CallAgenda
<thomasga>
ha yes true
<amirmc>
As I mentioned in my email. Canopy (or any other static site thing) isn't as easy to edit as GH wiki is right now.
seangrove has joined #mirage
<thomasga>
I think that would be great that mirage.io post and wikis entry are stored in something which looks very much like canopy
dbuenzli has joined #mirage
<thomasga>
amirmc: that's not true
<hannes>
(and I agree with amir that we should first have a plan what we want to achieve)
<dbuenzli>
Hello timezone challenged people.
<amirmc>
thomasga: how so?
<thomasga>
just click the "Edit" button on Github
wiredsister has joined #mirage
<noddy>
dbuenzli: i know, right?
<djs55>
I don't believe in timezones
<amirmc>
That's kind of my point. GH wikis are better at that than the edit-in-repo functionality
<dbuenzli>
I thought everybody was using ptime.
<amirmc>
Yeah, sorry for the timezone confusion :)
<dbuenzli>
Tbh canopy feels a little bit retarded at organising information.
<thomasga>
canopy just reflects the changes directly
<mort___>
re canopy and editing: aiui canopy simply serves up the contents of a git repo, such as a GH wiki (which is a repo behind the scenes), responding to pokes from teh GH webhook
<dbuenzli>
Which seems to be the main problem mirage docs have has at the moment.
<noddy>
amirmc: thomasga: github couldn't be any more of a weak link. it's usable, but the company is going through turmoil, we're in other people's hands, and imho we're sending the wrong signal by not dogfooding enough
<mort___>
editing can still happen in the GH edit panes
<mort___>
just doesn't have to
* noddy
thinks we should strategically start relying on github less and self-hosting more, even if there's a shadow github presence for people to find the project easily.
<thomasga>
noddy: I'm fine with that. I'm just saying that if people wants to use the Github interface to edit the contents, that's also fine with Canopy. In my mind, we didn't do that before because Irmin was not ready.
<amirmc>
thomasga: The preview pane only shows changes
<hannes>
dbuenzli: could you elaborate by saying what features you miss? or how you'd optimally organise information?
Algebr` has joined #mirage
<mort___>
hannes: dbuenzli has already put a couple of issues on mirage-www about that i think
<hannes>
mort___: this was about mirage-www itself, I'm curious what is missing in canopy
<dbuenzli>
Last time I saw canopy it was just some time of timestamped entries. That certainly not the way of organizing documentation. I feels more people are more like vomitting information on a website.
<thomasga>
amirmc: I don't understand what you said :-)
<hannes>
dbuenzli: it has support for tags now. a tag is a free-form string, you can show all entries for a given tag
<amirmc>
thomasga: I went to look at the link you sent. Then I clicked on preview changes. It didn't show me any (as I hadn't made any).
<dbuenzli>
Still I found the blog format ill-suited.
<hannes>
dbuenzli: I really appreciate you input, if you've more details to share, please do offline
<Algebr`>
I mentioned two things that I need out of canopy, at least for me to be able to leave haykll. 1. language specific syntax highlighting 2. generation of atom feeds by, filterable by tags.
<amirmc>
Overall, I think static-site generation, based on a repo is very cool and ultimately I'd like to move my personal site over to it. However, I don't it's going to be suitable for everything.
<hannes>
I'm keen on closing this topic for this call, we can discuss it in a future call.
<engil>
Algebr`: syntax hl is done (not pushed), rss is done (but not by tag yet)
<mort___>
hannes thomasga amirmc dbuenzli: agree blog format is ill-suited to general (non-time-ordered) content, but that's relatively simple to add. in general i like that it separates concerns of content from serving which have always been a bit mixed up
<amirmc>
hannes: :P
<hannes>
I suspect the next point, build automation, will be deferred since avsm is not here
<hannes>
or does anyone have news on bytecode-only builders, experiments with mirage on flambda (4.03)?
<hannes>
I take this as a no.
<dbuenzli>
Most of the stuff is not compilable because of the ppx cancer.
<hannes>
Drup, talex5, samoht : any plan on this side (I see talex5 proposed a solution in 55)
<thomasga>
I'm fine to merge something half-perfect is that solves user-facing problems (which this PR does)
<yomimono>
+1
<thomasga>
as long as we don't compromise a future solution which will be better
<thomasga>
(which seems to be the case)
<talex5>
I think so. Is Drup here?
<thomasga>
I propose that we get an ack for Drup offline and move on
<Drup>
Well, we will just have one breaking change now and another when I implement the correct thing (which for some reason that is not clear to me, can only be implemented by me)
<thomasga>
ha great, hi Drup :-)
<Drup>
I don't have time right now :/
<talex5>
Drup: why is it a breaking change?
<thomasga>
do we require users to change their config.ml?
<Drup>
talex5: rather, you'll need in mirage new things introduced in functoria, so you have very tighlty coupled versions
<talex5>
thomasga: no, although the current patch has logging off by default which we should probably change.
<talex5>
Currently, you have to change your config.ml if you want to turn on the new logging.
<thomasga>
breaking internal APIs is fine, it's our problem and doesn't require users to update.
<Drup>
but, I described the alternative proposal in as much detailed as I could, and nobody really asked me anything about it, everyone just assumed that It had to be done by me :/
<hannes>
a related item is the EC2 command line options - https://github.com/mirage/mirage/pull/497 (which we wanted to read through after last call and maybe merge, and later move code to functoria)
<seangrove>
That one is a bit important to me, yes
<thomasga>
everyone is very busy with things, not having time to implement the perfect solution is a perfectly valid concern.
<yomimono>
drup: the real time-consuming work is overhauling the connect functions to use result types?
<yomimono>
sorry, that should have had an "is" up front to make a better english question
<thomasga>
we can mitigate that by integrating less good solution if that doesn't break user facing code, so I propose that we merge these PRs soon.
<Drup>
yomimono: yes, but that's not functoria work, kind of
<Drup>
it's mirage-devices work
<Drup>
we should just add pp_error and result-returning connect everywhere
<yomimono>
drup: yes, agreed; I think that's within scope for the kind of API overhaul that might justify a 3.0.0 along with some other desired things
<hannes>
Drup: for the record, is your proposal in the same PR or elsewhere?
<talex5>
The current PR doesn't require devices to be updated to use result types (that can happen separately where it makes sense).
<hannes>
I agree with Drup that devices should have connect returning a result and pp_error
<Drup>
I disagree with you talex5.
<talex5>
hannes: then you have to change everything using mirage in one go.
<Drup>
your way is basically to fine-tune the device implementation instead of using something completely uniform
<hannes>
talex5: is the error stuff separate from the logging stuff? I'd assume logging is the code which bitrots fast since it touches large amounts of code?
<hannes>
talex5: yes!
<thomasga>
well the question is when do we get logging and error reporting …
<talex5>
hannes: the changes touch the same code, so I built one on top of the other. They could be separated.
<thomasga>
it's been in discussion for months without progress. We know have a incremental proposal which improve the current state
<hannes>
talex5: it'll then be a 2.9.0 and in the mirage-dev incubator for a while, but that's life... we're still small enough to push changes through
<Drup>
talex5: they should, they are completely orthogonal
<Drup>
I told you that already
<thomasga>
well it's annoying to not have error reporting and logging :-/
<hannes>
talex5: I'd be happy to have the logs stuff separate [and merged now, even with the functoria log stuff drup dislikes], and care about the device connect error handling at a later point, in one go!?
<talex5>
Sure. Splitting is easy if we have agreement to merge it once I've done it.
<mort___>
+1 to logging being merged asap
<Drup>
fair enough
<talex5>
I don't like forcing connect functions to return errors though, when many of them don't need to.
<Drup>
talex5: then they'll return Ok x
<hannes>
talex5: I don't see anyone is against the logging changes
<Drup>
that's not a problem
<Drup>
hannes: I dislike the current implemention, see the various tickets for explanations
<talex5>
Drup: but then I have to test for an error that can't happen, and call another function to report it...
<amirmc>
Heh, seems there's some confusion about who's actually doing that :P
<djwillia>
oh I guess i didn't give a timeline for release: this week hopefully or next otherwise
<amirmc>
Great!
<hannes>
any news from martin lucina about potential plans to port mirage-rump to 2.7.0^W2.8.0?
<djwillia>
amirmc: regarding IncludeOS, he asked if I was interested in a shared virtio implementation, but in my new monitor, I've thrown out virtio :)
<thomasga>
hannes: I think he is waiting for feedback on his previous work
<amirmc>
djwillia: Ah, I see.
<djs55>
are you using something simpler than virtio?
<djwillia>
djs55: yes, the concept behind the monitor is that it can be built out of components to be minimal
<djwillia>
minimal meaning that it's specialized to the unikernel
<thomasga>
hannes: but I think Martin hasn't started the port yet, I'll poke him and report for the next call
<hannes>
thomasga: feedback in which way? certainly cross-compilation is the red herring there (and solved differently than in xen-minios)..
<djs55>
interesting
<djwillia>
we only expose a network interface if the unikenrel needs one
<hannes>
thomasga: I know saite has used mirage-rump-2.6 on FreeBSD, and it worked nicely. would be great to have a forward-port :)
<djwillia>
this makes the interfaces specialized in some sense, so there is no need for a standardized, general purpose device abstraction like virtio
<hannes>
and now, 9 minutes before we close...
<hannes>
and in no particular order: canopy, dashboard, camlp4 (cstruct.syntax gone!?), cow (mort is missing cow.syntax), syslog reporter?
<djwillia>
djs55: i have a draft in submission to hotcloud that i'm happy to share if you are interested
<thomasga>
mort___: for cow.syntax: use tyxml.syntax and read and comment on Drup tutorial
<thomasga>
djwillia: yes please!
<djs55>
djwillia: I'm definitely interested :)
<mort___>
thomasga: cool, could you give me a pointer to tyxml please? (and was that documented anywhere…? :)
<hannes>
djs55: I just noticed that vchan still depends on camlp4, but you've a PR.. would be good to have that merged and released..
<djs55>
ooh, I forgot about that
<hannes>
(it breaks travis on mirage-skeleton, I pinged)
<djs55>
the double bank holiday weekend in the UK caused me to forget what I was doing ;)
<dbuenzli>
djs55: I also had a look at ocaml-tar and I suspect it also does.
<thomasga>
and yes, would be interested to have a list of the remaining librairies using camlp4, I'm happy to help eradicating it
<Drup>
mort___: would be very happy to have opinions on what to improve. :)
<hannes>
also, we should push with cstruct-2, removing p4
<djs55>
a list would be very helpful
<mort___>
drup: ok will try to have a go (unlikely before next week unforutnately ;(
dance-bot has joined #mirage
<djs55>
btw I also noticed when doing the ppx conversion that lots of libraries define similar cstruct layouts, like ethernet frames, pcap headers, tcp headers that kind of thing