<hannes>
what is the purpose of that agenda item? collecting random comments + opinions about jbuilder here? or anything in particular?
<yomimono>
I was just looking at the page history wondering who should be talking now ;)
<yomimono>
so it looks like amirmc added this agenda item a while ago, is he here?
<yomimono>
oh, you've just said ., you definitely are
<reynir>
Yes, <5 minutes ago
<amirmc>
I added after avsm mentioned on the email list. I figured it might be worth talking about now., so it was meant as a reminder.
<amirmc>
If there are no comments, or things to chat about synchronously, then we can keep it on the issue.
<yomimono>
well, my question about this is whether anyone has taken the time to follow hannes and talex5's advice on how to proceed with evaluating jbuilder
<demonimin>
I use ppx.lwt currently, hopefully that will get ported
<yomimono>
namely "lease try some difficult packages first -- i.e. those which need C libraries to be compiled for multiple targets"
<mato>
I agree with hannes' assessment.
<hannes>
other issues include: how to execute (depopt) tests? how to build docs? how to release packages with jbuilder (is sth like topkg lint fulfilled by construction?)?
<thomasga>
I have been trying jbuilder a bit and it is *very* fast
<Drup>
Contributions to lwt are welcome.
<thomasga>
but I really don't want to regress on the publishing workflow that we have with topkg
<hannes>
and - keeping moving parts low - maybe someone should finish the topkg ports first? maybe someone can come up with a topkg which calls out to jbuilder instead of ocamlbuild (it seems avsm doesn't think this is a good idea)
<mato>
hannes: +1
<yomimono>
yes, I would really hate to lose the workflow automation of topkg
<thomasga>
for me that's the only blocker, until then I am pretty happy to continue experimenting
<yomimono>
I don't think it's sensible to take an approach that regresses there
<hannes>
don't get me wrong -- I'd really love to get rid of ocamlbuild, and jbuilder looks promising
<rgrinberg>
sounds like we should wait until topkg + jbuilder is ready then. Although I don't know how that would look like
<rgrinberg>
Did daniel say something about supporting jbuilder in topkg?
<Drup>
he will not do it himself
<thomasga>
yes, he said he was happy to relicense some bits of code if it helps
<rgrinberg>
hannes: the question about depopts is easy in your situation. You should get rid of them and have proper sub packages.
<thomasga>
and that someone should copy/paste the bits of code needed inside jbuilder
<demonimin>
as I understand it, daniel wanted jbuilder to present the same api as topkg for use in opam
<thomasga>
topkg works by calling the build system with a list of targets
<thomasga>
which are the one the package wants to install
<thomasga>
I guess `jbuilder build <the list of targets>` should work
<hannes>
rgrinberg: let me rephrase this, you mean the solution is to always have a 1:1 correspondence of opam and ocamlfind packages? and never have some foo.bar package?
<thomasga>
and yes, I tend to agree about removing depopts
<thomasga>
(when possible)
<rgrinberg>
never is a strong word. but a strong preference against depopts is what we'd wnt
<thomasga>
a "a 1:1 correspondence of opam and ocamlfind packages" seems like a good idea too
<thomasga>
(e.g. less names)
<hannes>
then I'd expect someone to clean up e.g. tcpip using jbuilder as a PoC... and maybe also enlighten people on how to relese multiple packages out of a single repository at once..
<hannes>
(I agree that a 1:1 opam to ocamlfind is a good idea)
<hannes>
thomasga: no jbuilder in there afaics
<thomasga>
ha ok. So let me rephrase my position: until we have the same workflow as we have today with topkg, I think it is very unwise to switch the mirage packages to jbuilder.
<thomasga>
I think we all agree here
<thomasga>
(e.g. Mirage3 without topkg would have been a nightmare to manage)
<rgrinberg>
that's b/c ya'll have 50 repos ;)
<thomasga>
:-)
<rgrinberg>
thomasga: are you convinced by daniel's assesment that jbuilder should reimplement the parts of topkg that it is missing?
<hannes>
thomasga: well... this raises two questions: what are the mirage packages? are these PRs on various repos about jbuilder getting merged?
<thomasga>
@hannes: as far as I know only the _oasis repos are getting relifted with jbuildee
<thomasga>
I'd say: oasis < jbuilder < topkg
<thomasga>
(today)
<rgrinberg>
hannes: some packages have never been topkg'd in the first place. Also for packages that strongly rely on depopts today, I believe that splitting them into proper opam sub packages is more important than a smooth release process.
<thomasga>
rgrinberg: I am not sure how to merge topkg and jbuilder features, but I would trust Daniel on this one
<thomasga>
I think he said someone should just "vendor" topkg inside jbuilder
<talex5>
I think the problem is that there is quite a lot of overlap between topkg (which creates an opam .install file) and jbuilder (which does too, as I understand it).
<rgrinberg>
hannes: those don't have depopts
<rgrinberg>
so the gain from jbuilder is marginal
<Drup>
I think packages such as lwt are a better targets
<thomasga>
agreed
<talex5>
So topkg+jbuilder would result in duplication of some metadata.
<hannes>
rgrinberg: yes, they're (against your statement earlier) moving some topkg'ed package to jbuilder...
<thomasga>
talex5: clearly need to sort that kind of overlap too
<Drup>
big, multiple sub packages, C bindings, ppx and camlp4, currently uses oasis
<rgrinberg>
talex5: the overlap is as follows AFAIK: generation of .merlin, pkg.install, and META files. All of those things should clearly be done by jbuilder though
<Drup>
If someone (aka rgrinberg) can converts that and make a guide, lot's of packages can be converted
<rgrinberg>
hannes: i might have misspoke, I think transitioning to jbuilder from topkg only makes sense if your package suffers from depopts
<thomasga>
btw, I have a repo with multiple packages, C bindings, tests and jbuilder work great
<Drup>
(and it'll polish about the initial rough edges to make everything fit)
<talex5>
Yes, so the ideal system would be jbuilder + something for handling releases (possibly based on topkg's release system).
<Drup>
-about
<thomasga>
but I will need to publish some packages at one point :p
<hannes>
thomasga: including multiple targets/crosscompilation for the C artifacts?
<yomimono>
good point about lwt, Drup, wihch I don't want to see get lost
<thomasga>
hannes: not yet
<thomasga>
also topkg has a nice watermarking system, doc generation, etc
<hannes>
(I'm really easy, please port to jbuilder -- I just won't do any of it (did sufficent oasis -> topkg work), and expect the same featureset as before)
<thomasga>
lots of coold stuff
<Drup>
(I'm personally a lot more favorable to jbuilder's project descriptions that to topkg's lack of it)
<Drup>
(so when edges get a bit rounder, I might port ocsigen stuff to it)
<thomasga>
if someone can just do a mix of both system (e.g. fast builds + nice release workflow) that would just be great
<rgrinberg>
Drup: yeah, that's pretty clear. This is where I see the friction between topkg and jbuilder though. topkg shouldn't need its project description DSL when used with jbuilder
<rgrinberg>
thinking out loud: a jbuilder flavor jbuilder will simply construct its project description data structure from the jbuild sexps. or use jbuilder's api.
<yomimono>
an attempt to summarize: most people would be fine with switching to jbuilder if it didn't regress on the publishing workflow provided by topkg
<yomimono>
it would be some work to do and that work would be helped by a nice complicated example port like lwt
<yomimono>
with a nice writeup
<yomimono>
I don't expect any movement on this without some work to provide jbuilder with the functionality we're missing and some work to provide the example mentioned above
<yomimono>
further comments or explanations of my misunderstanding welcome
<hannes>
another feature missing in jbuilder seems to be mli-only modules...
argent_smith has quit [Quit: Leaving.]
<rgrinberg>
porting lwt to jbuilder just to for an example is pretty cruel :P. it's likely a massive task. But I think a typcial project with cstubs/ppx is in order.
<thomasga>
need to run sorry, but I fully agree with the summary!
ricarkol has quit [Ping timeout: 260 seconds]
<hannes>
it's not all about release workflow, also actual missing features... the cross-compilation of C code, atm usin ocl-stubblr etc., would be another feature we need for some libraries
<Drup>
rgrinberg: well, most people who learned oasis learned it by looking at lwt's oasis (written by diml!), why not repeat history ? :D
<yomimono>
thanks hannes, that's a good point
<hannes>
but it is obviously not a all-or-nothing thing: different packages can use different build systems (and luckily those with c bindings are rather rare in the mirage ecosystem)
<rgrinberg>
hannes: is that essential? just rename your .mli to .ml :P Agreed on the other points though.
thomasga has quit [Quit: Leaving.]
<rgrinberg>
Yeah, if topkg was a decent wrapper around both systems, you could argue that the transition could be done gradually
<hannes>
rgrinberg: yes, tis is essential. no, renaming is not an option.
<rgrinberg>
is symlinking an option? :)
<yomimono>
No.
<hannes>
no. doesn't work on windows.
<hannes>
and mli files are distributed/installed, whereas ml are not. if you duplicate the files (copy), each change will have to be done twice
<rgrinberg>
ok then a manual rule that copies .mli -> .ml is probably doable. hannes if you think it's essential you should leave a comment here: https://github.com/janestreet/jbuilder/issues/9
<rgrinberg>
I couldn't come up with any arguments why I couldn't do without it
<hannes>
a copy rule at build time may be an ok solution.. i will not distract myself into another build system
<mato>
rgrinberg: Random question (since I literally *just* ran into this), is the jbuilder dependency on bash absolutely necessary?
<rgrinberg>
there's no hard dependency on bash. just make sure not to use bash in your jbuilder rules
<hannes>
(mato: I use an old opam-repo snapshot atm without any newish sexplib etc. to avoid any of the struggle)
<mato>
right, so it's the downstream's (in this case ppx_ast's) fault?
<yomimono>
unless there are further points that could be helped by synchronous discussion, I'd like to propose that we move on
avsm has joined #mirage
<yomimono>
hearing no objections: next item is meetbot, which I said last time I'd try to take a look at by this meeting
<yomimono>
do or do not, there is no try, and in this case I did not
<rgrinberg>
okay!
<yomimono>
if we have other volunteers to look into that, I would be happy to see someone else take the time and set it up
<yomimono>
otherwise I'll try to find time before our next meeting in April
<yomimono>
other items?
<mato>
um
<amirmc>
I can add an AOB item about blog posts for the website about the hackathon.
ricarkol has joined #mirage
<yomimono>
please do
<mato>
well, as of about an hour ago,I have all the standalone ukvm tests passing on FreeBSD/vmmapi
<djwillia>
nice mato@
<yomimono>
that's great!
<mato>
I *would* have had a mirage unikernel tested on FreeBSD by now, were it not for random breakage in the MirageOS dependencies on FreeBSD
<hannes>
mato: nice! what about clock?
<mato>
hannes: I've solved clock, but can't test it properly w/o Mirage, which I can't install because blah.
<djwillia>
the high level story for Solo5/ukvm is there are a bunch of in-progress ports that are hopefully going to merge together into a big happy family soon
<djwillia>
originally we had the virtio and ukvm backends for Solo5 (both x86)
<hannes>
amirmc: to address your topic: gemma mentioned she has collected posts, and there'll be sth likely this week... avsm likely knows more
<gemmag>
amirmc: I've collected the 10 trip reports we have received so far as well as some photos - I'm expecting a few more, then passing over to avsm
<djwillia>
ukvm only ran on Linux/KVM on an x86
<djwillia>
now some collaborators from ARM have got it running on Linux/KVM on ARM
<amirmc>
hannes gemmag: great!
<avsm>
i can do a consolidated edit of the blogpost and send a PR to mirage-www
<avsm>
djwillia: have they actually booted on arm64 now? thats awesome!
<djwillia>
and mato has got it running on FreeBSD/vmmapi.h, and I have got it working on MacOSX/Hyperisor.framework
<djwillia>
the thing that makes all this difficult is that there are multiple "platforms" as well as multiple "architectures"
<djwillia>
mato has a plan to make them all live happily together, which he is testing out with the FreeBSD port
<djwillia>
avsm: i'm not sure if it's arm64 or arm32, mato do you know?
<djwillia>
the cool thing about this is that on all of these platform/arch combos we should be able to run the tiny "unikernel monitor" (ukvm) instead of needing a more general-purpose VMM like QEMU
<mato>
djwillia: avsm: arm64
<djwillia>
awesome!
<yomimono>
thanks for the updates mato and djwillia :)
<mato>
yeah, i think things are coming together rather nicely, hopefully april will be the month where Solo5 (and thus Mirage) gains a bunch of new targets
<yomimono>
:D that's a great note on which to conclude I think!
<yomimono>
thanks, everyone!
<mato>
thanks yomimono for coordinating
<djwillia>
thanks!
amirmc has quit [Quit: Leaving.]
ricarkol has quit [Quit: Page closed]
talex5 has quit [Quit: Leaving]
<avsm>
thanks!
gemmag has quit [Quit: Page closed]
avsm has quit [Ping timeout: 260 seconds]
<mattg>
wave, sorry i wasn't able to attend the meeting, I did promise and do still intend to look at topkg-ing tcpip. from backscroll it seems like that's still wanted, and a further port to jbuilder would be done on top of that?
<yomimono>
mattg: a topkg port would still be very welcome
thomasga has joined #mirage
thomasga has quit [Client Quit]
djwillia has quit [Ping timeout: 268 seconds]
djwillia has joined #mirage
djwillia has quit [Ping timeout: 258 seconds]
balduin has joined #mirage
djwillia has joined #mirage
mort___ has quit [Quit: Leaving.]
djwillia has left #mirage [#mirage]
mort___ has joined #mirage
fgimenez has quit [Remote host closed the connection]
copy` has joined #mirage
philtor has quit [Remote host closed the connection]
<kensan>
mato: Regarding the placement of the new source files: I put them in the kernel/ukvm dir alongside the existing UKVM/Solo5 kernel sources.
<kensan>
mato: Selection of the necessary files is done in the kernel/Makefile. Would you prefer if the Muen-specific code would reside in a distinct location e.g. kernel/muen ?
strykerkkd has joined #mirage
stryker_kkd has joined #mirage
strykerkkd has quit [Remote host closed the connection]