avsm changed the topic of #mirage to: mirage 2 released! party on!
yegods has quit [Ping timeout: 250 seconds]
noddy has joined #mirage
yegods has joined #mirage
unbalancedparen has quit [Quit: WeeChat 1.4]
dsheets has joined #mirage
dsheets has quit [Ping timeout: 250 seconds]
yegods has quit [Read error: Connection reset by peer]
yegods has joined #mirage
brson has quit [Quit: leaving]
Bluerise has quit [Ping timeout: 276 seconds]
Bluerise has joined #mirage
yegods has quit [Ping timeout: 268 seconds]
noddy has quit [Ping timeout: 250 seconds]
yegods has joined #mirage
dsheets has joined #mirage
dsheets has quit [Ping timeout: 250 seconds]
yegods has quit [Read error: Connection reset by peer]
yegods has joined #mirage
jermar_ has joined #mirage
dsheets has joined #mirage
dsheets has quit [Ping timeout: 250 seconds]
insitu has joined #mirage
<insitu>
thx for your help
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
yegods has quit [Read error: Connection reset by peer]
yegods has joined #mirage
jermar_ has quit [Ping timeout: 268 seconds]
insitu has joined #mirage
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
yegods has quit [Read error: Connection reset by peer]
insitu has joined #mirage
yegods has joined #mirage
smkz has quit [Read error: Connection reset by peer]
smkz has joined #mirage
sigjuice has quit [Ping timeout: 252 seconds]
sigjuice has joined #mirage
mort___ has joined #mirage
yegods has quit [Remote host closed the connection]
rudenoise has joined #mirage
jermar_ has joined #mirage
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
insitu has joined #mirage
mort___ has quit [Quit: Leaving.]
dsheets has joined #mirage
noddy has joined #mirage
<lobo>
insitu: np. glad i could help :D
<insitu>
really, it was frustrating: being so close and failing to *see* the web page
<insitu>
that's the problem when laying elephants on top of turtles...
<insitu>
I will write some post on that experience, seems like documentation to get started with mirage is a bit lagging
mort___ has joined #mirage
<lobo>
insitu: i had the same issue a couple of month back with unetlab's vm. i was totally puzzled that hosts had no connectivity even though i could see their arp requests/replies with tcpdump :D
<lobo>
insitu: but enabling promiscuous mode did fix it in the end
<avsm>
First port of call is information retrieval. There were a few threads about this on mirageos-devel
<avsm>
GemmaG Hannes, do you want to say anything about this?
<dbuenzli>
Note if you want to have good documentation, you have to *design* it at some point. These things do not happen magically.
<avsm>
While they're typing, I'm going to jump ahead to "SSL expiration" as I'm refreshing the mirage.io site: I don't think it's controversial to switch to letsencrypt certificates, so I will go ahead and do that as part of the website refresh
* mattg
waves
yallop has joined #mirage
<avsm>
Sorry, I realised Hannes is driving to Oxford at the moment. Information retrieval covers a few things: firstly where our individual libraries and contents are, secondly the API documentation, thirdly tool documentation
<avsm>
the mirage-dashboard project and the TROVE are taking shape, and so we'll start curating a list of projects and libraries soon on the main website.
<GemmaG>
Is the plan also to separate general mirage content from hackathon content on canopy?
<avsm>
API documentation is (as dbuenzli notes) a mess at the moment, but is due to get better due to the release of a cross-referenced documentation tool. As part of deploying it, we'll need to work through explaining some of the core concepts in the Mirage API better.
<dbuenzli>
I think people should avoid using the canopy but rather try to improve the mirage website.
<avsm>
I'm inclined to split this into two sections: the MirageOS website is where curated documentation sits, and the Canopy is the stream-of-consciousness for rapid pushes
<avsm>
It's a lot easier to edit stuff into the main website if it shows up on Canopy first
<dbuenzli>
It's not in an entirely bad shape.
<dbuenzli>
(the mirageos website)
<dbuenzli>
Remove cruft and make it more user-centered
<avsm>
Yeah, but it hasn't kept up with all the recent changes. Finding (e.g.) functoria information is an exercise in search.
insitu has quit [Read error: Connection reset by peer]
<avsm>
I'm curious what the newer contributors such as djwillia or mattg think about this
<avsm>
mattg: especially with your effort to fix CLOCK
blrjs has joined #mirage
<thomasga>
well we haven't updated the wiki/doc in mirage.io for a long time
<amirmc>
I think splitting things across two sites makes it harder for people to find.
<avsm>
It's not splitting across two sites: the Canopy is where notes get pushed, and then they get edited into the main website. New users go to mirage.io
<amirmc>
e.g. I'm not sure we have any reference or pointers to canopy fro the current site
<thomasga>
I'm fine to integrate canopy features in mirage.io (and new style maybe)
<thomasga>
can't we just replace the blog post stream by canopy?
<avsm>
that's right -- and there shouldn't be. But Canopy can reference mirage.io. A good example is talex5's error handling proposal, which was a PR to mirage-www (still is), but could have been edited live on Canopy instead
<avsm>
thomasga: yes, we can do that.
<GemmaG>
Perhaps some necessary changes to mirage.io + a canopy style stream
<mattg>
avsm: I think when I first came across Mirage, I followed the hello world example from mirage.io, and then pretty much went to working from examples in mirage-skeleton and using .mli files for reference
<GemmaG>
Yes as per above :)
<avsm>
the big flaw right now is that we don't edit the blog post content back into the docs, so users have to search blog posts for documentation (e.g. functoria)
<thomasga>
yes, we do terrible job with the wiki/doc
<avsm>
mattg: thanks, that's useful -- so a rough learning curve :)
<djwillia>
avsm: I still haven't wrapped my head around all of the packaging stuff (that I think is really important to understanding Mirage) but I'm not sure that's the website's fault
<dbuenzli>
I'm sure it is
<avsm>
djwillia: it's an integral part of a library OS, so I think an explanation of OPAM (or least a strong xref to the OPAM site) is appropriate on mirage.io
<djwillia>
avsm: yes, certainly, I think needing to understand packaging is the biggest block to understanding Mirage
insitu has joined #mirage
mort___ has joined #mirage
<mattg>
avsm : I should also mention I learnt a lot from Mindy's and talex5's blogs
<thomasga>
me too
<avsm>
Ok, so GemmaG and I will take this on as an action then with help from Eng and mort: work through the website/blog/canopy melange and figure out the workflow we want (blog posts should come out more quickly, and get edited into the main website)
<dbuenzli>
which is bad (not their prose of course)
<avsm>
Mindy and talex5's blogs are legendary :)
<mort___>
(yo)
<GemmaG>
avsm: sounds good :)
<dbuenzli>
this knowledge should be consolidated in the mirageos website
<avsm>
Yes, agree with dbuenzli -- they did great posts due to the lack of documentation but it should be consolidated by now in the central docs.
<avsm>
Ok, closing out Information Retrieval. Any last comments?
<djwillia>
avsm: I mostly learned (and am still learning) from doing terrible terrible hacks before understanding packaging :)
<mato>
Random comment, I think the process of creating the Solo5 port (and integrating it with Mirage) could be good material for writing a blog post.
<mato>
"How to port Mirage to a new platform"
<thomasga>
would be great if Engil can help to fix/improve mirage.io CSS
<avsm>
mata djwillia : yes definitely! It also covers the ukvm work which is an area we've not talked about much in the blog (aside from the MiniOS ARM port that talex5 did)
<djwillia>
mato: yes, that's a great idea because it's forcing us to really understand what a mirage "platform" is
<avsm>
mato: could you create an issue on github.com/mirage/mirage-www/issues as a reminder to do this blog post...
<avsm>
Alright, full agenda, so moving onto next topic: Quality and Test
<mato>
avsm: will do.
<thomasga>
we need more tests :p
<avsm>
Good news: OCaml 4.03 is due out this week with an incredible new inliner that speeds up some mirageos kernels by 20-30% with a simple recompiler
<djwillia>
avsm mato: we may want 2 blog posts one on ukvm, on on porting mirage to new platforms
<avsm>
bad news: yallop keeps finding showstopper bugs in 4.03 ;-)
<avsm>
djwillia: (agree on more small blog posts)
<mort___>
(that's good news really...)
<avsm>
however, 4.03 is converging, and we have done really good work collectively on moving to PPX from camlp4
<avsm>
so aside from a port of the runtime to mirage-platform, we're pretty much set to move to 4.03
<avsm>
Has anyone taken a look at a 4.03 runtime for mirage-platform/xen? If not I'll take a look soon
<thomasga>
NO MORE CAMLP4!
<thomasga>
I've fulfilled my life goal
* yomimono
cheers
<dbuenzli>
NO MORE PPX
<avsm>
Bulk builds via Docker are in good shape: we have a comprehensive set of containers hosted on the Docker Hub for every conceivable combination of Linux distros at https://hub.docker.com/r/ocaml/opam/ -- read it and weep :)
<thomasga>
dbuenzli: that's my next life goal
<dbuenzli>
you have a new life goal
<thomasga>
exactly :-)
<avsm>
Leave camlp4 alone! It has served us well. A moment of silence for our old friend
<thomasga>
HAAAAA
<mort___>
*belch*
<djs55>
is it really gone? I still feel its presence… somewhere
<thomasga>
ppx his little brother is now there
<avsm>
So overall, the last few months of work should pay off very soon -- 4.03 is around the corner, ppx extensions make life easier, and we have an increasing amount of automated build infrastructure.
<avsm>
But we need to finish the leap as there are still a few stragglers that don't work.
<avsm>
For example: OASIS
<avsm>
(with ocaml 4.03)
<avsm>
is a giant elephant in the room
<mort___>
what's the elephant?
<thomasga>
can we just remove oasis instead of porting it to 4.03?
<dbuenzli>
Let's be realistic what's the actual problem ?
<djs55>
in the defense of oasis, it does make windows porting easier
<avsm>
one of the dependencies fails; I'm primarily interested in knowing if someone wants to take fixing it in opam-repository as an action
<avsm>
I'm sure it wont be hard
<dbuenzli>
Why not ping the author ?
<avsm>
no response
<avsm>
Ok, I'll take on the action then, and either fix it or bug someone else to fix it :P
<avsm>
Closing out quality and test unless there are any other updates?
<dbuenzli>
A message to caml-list could do no ?
<dbuenzli>
It's a pretty important part of the current eco-system
<avsm>
Sure. I'd rather get it unblocked in the short term though. A patch would be just as good as an email
<avsm>
And yes, it's very widely used indeed in our libraries.
<avsm>
Ok, let's take the OASIS topic offline for now.
<avsm>
Moving onto "Improved Logging and Errors"
<companion_cube>
in the defense of oasis, it's awfully convenient
<avsm>
talex5 has been working on this...
<talex5>
I split out a logging-only patch to Functoria, which is now merged. The corresponding PR to Mirage isn't merged yet: https://github.com/mirage/mirage/pull/514
<talex5>
I split out a logging-only patch to Functoria, which is now merged. The corresponding PR to Mirage isn't merged yet: https://github.com/mirage/mirage/pull/514
<talex5>
I split out a logging-only patch to Functoria, which is now merged. The corresponding PR to Mirage isn't merged yet: https://github.com/mirage/mirage/pull/514
<talex5>
I split out a logging-only patch to Functoria, which is now merged. The corresponding PR to Mirage isn't merged yet: https://github.com/mirage/mirage/pull/514
<talex5>
I split out a logging-only patch to Functor, which is now merged.
<talex5>
It's slightly ugly; if someone can suggest a more elegant solution please do :-)
<avsm>
is someone cutting and pasting into this meeting??
<talex5>
:-(
<dbuenzli>
Stuttering client.
<talex5>
Sorry. Using OS X cut-and-paste.
<talex5>
I split out a logging-only patch to Functoria, which is now merged. The corresponding PR to Mirage isn't merged yet: https://github.com/mirage/mirage/pull/514u
<avsm>
Any blockers to the mirage/mirage merge?
<avsm>
Someone break talex5 out of his temporal loop
<yallop>
mirage/mirage merge is quite difficult to say fast
insitu has quit [Read error: Connection reset by peer]
<talex5>
Hoping @Drup can suggest an alternative.
<talex5>
Once that's merged, I'll make PRs to add logging to the various libraries.
<avsm>
Ok, getting a release out with this next week would be useful to unblock people
<thomasga>
+1
insitu has joined #mirage
<talex5>
Then I'll resubmit the original patches to improve the error reporting and we can discuss that next time.
<avsm>
Yeah, fixing up libraries is going to take a while so I'm keen to get the mirage/mirage tool sorted
<talex5>
I don't know if there's full agreement yet, but I'm happy to update it to say that result types should be used for expected runtime errors and exceptions for bugs.
<avsm>
we appear to have cut and paste issues this week
<GemmaG>
hahahahahaha
<yomimono>
I'm very pro-result types & rresult so I'm on board with that
<dbuenzli>
\o/
<avsm>
thanks talex5 -- establishing logging standards across libraries is right at the bottom of the stack, so it feels like a good one for the website refresh as well
<dbuenzli>
@talex which exceptions ?
<dbuenzli>
Nevermind we can discuss that there
<avsm>
yes yomimono -- and 4.03 has the Result.t defined in the standard library! This is more amazing than breaking away from camlp4
<avsm>
Ok, closing out logging -- rest can be discussed on the respective issues, and its making good progress.
<yomimono>
thanks talex5 for continuing to push on this :)
<avsm>
a number of libraries are hitting this due to use of floating point, and in particular Cohttp
<dbuenzli>
We already discussed this last time.
<yomimono>
Did anyone do anything as a result of that discussion?
<dbuenzli>
Just use the strod.c file that is boot-rpi-ocaml
<thomasga>
I remember that Daniel said he wanted to fix this
* yomimono
didn't
<avsm>
Yeah, no progress since 2 weeks ago I believe, except has anyone looked at how important locale dependence is?
<dbuenzli>
I didn't say I wanted to fix it
<dbuenzli>
I just told people what to use.
<thomasga>
tututut I have a perfect memory :p
<avsm>
It could be significantly easier if we grab a BSD library for this (e.g. OpenBSD's)
<dbuenzli>
The file there is what used to be used in JavaScript runtime until they switched to grisu
<thomasga>
(was just joking, you indeed pointed out to the right files)
<avsm>
dbuenzli: ah, that's most useful to know, thanks.
<avsm>
Ok, let's move discussion of this one to the issue as well. It would be good to bump this up to get fixed in the mirage-platform support for 4.03, so I'll take a look
<avsm>
it's at least easy to test by running a cohttp server
<avsm>
or yojson, or most things...
<yomimono>
or calling float_of_string
<avsm>
I think we've made progress -- used to crash if we touched the floating point registers in xen mode :)
<avsm>
Ok, onto the next topic...
<avsm>
Mirage 2.8.0 released along with new version of TCP/IP, and most important, this was yomimono's first Mirage release!!!
<avsm>
Three cheers for yomimono for doing a full release, and implicitly, by not messing it up!
<GemmaG>
woop :)
<thomasga>
\p\ /o/
* mort___
cheers
<engil>
\o\
<avsm>
What's happening there yomimono ?
<djwillia>
yay
<yomimono>
I accept plaudits in the form of kitty cuddles
<yomimono>
2.8.0 was pretty minor but involved a change to mirage-types -- we now have an icmp module type and corresponding separate module implementation in tcpip.
<yomimono>
you can now easily make unikernels with whatever icmp behavior you want, which will make it quite a bit easier to make routers &c with our tcpip stack.
<avsm>
Does this make NAT easier?
<dbuenzli>
superbe
<yomimono>
potentially, yes.
<talex5>
Yeah, would be really useful to do NAT of ICMP messages (e.g. ping) for mirage-firewall.
* yomimono
nods
<avsm>
awesome. Hannes informs he is working on the TCP/iP test suite against freebsd as well, so that (combined with the AFL fuzzing work that yomimono did at the hackathon) puts us in good shape for more effective tcp/ip testing too
<dbuenzli>
avsm is the tcp/ip problem under embargo ? I saw that you retracted the topic from the call agenda
<thomasga>
great!
<avsm>
dbuenzli: yes
<avsm>
One outstanding PR in tcpip is ipv6
<avsm>
we have the code merged now in the stack, but not exposed to configuration
<dbuenzli>
(I think this should be made more clear in the future)
<avsm>
Does anyone have a particular interest in ipv6 and would like to learn more / hack on it?
<yomimono>
I'm going to have to a bit as part of ongoing tcpip restructuring
<yomimono>
it's part of pulling all the parsers/printers out and exposing them
<avsm>
yomimono: ack. I have access to public IPv6 addresses on the Rackspace Cloud, so point me if you need a VM that is routable for you to test stuff (or deploy)
<yomimono>
although if anyone else wants to volunteer I encourage them :)
<avsm>
we can't deploy Xen unikernels on Rackspace yet, but some tuntap thing should work.
<yomimono>
it actually should be doable with ec2 as well
<avsm>
IPv6 on EC2?
<yomimono>
think so
<avsm>
I thought they didn't support it except via the load balancer service
<yomimono>
also I have my own xen machine, so nbd
<yomimono>
maybe I'm wrong about ec2; irrelevant to most people anyway, sorry
<avsm>
Ok, please ping yomimono or me if you are interested in IPv6!
<avsm>
Next, onto the hackathon: a roundup blog post is flying around. What's happening GemmaG?
<avsm>
deja vu -- I didn't click on the link before, and it's great to see pictures of sunshine and hacking there too :)
<avsm>
looks great, that'll be our next blog post on the main site hten
insitu has quit [Read error: Connection reset by peer]
<avsm>
If anyone else does have updates on their trip that aren't there, please do ping soon
<avsm>
Ok, moving onto libraries then, just to get a check on them
<avsm>
mirage-dashboard came first: is the author here?
<avsm>
there was some mailing list traffic, and it's making progress. I'm going to do a unix-socket deployment (as I can do that quickly) next week hopefully
<avsm>
Having something up describing our libraries is very useful, and the TROVE was a little too low-level and always out of sync
<avsm>
Moving onto Canopy: engil, what's happening with it?
<engil>
slowly progressing
<engil>
RSS, tags are here
yallop has quit [Quit: Leaving]
<engil>
we still need to handle client caching properly
<avsm>
I've got a local deployment -- is anyone else using it themselves?
<engil>
hannes has made very good progress on making it run on Xen
<avsm>
Great stuff -- mort___ I'm going to move anil.recoil.org over to it as soon as I sort out my build scripts; maybe a target for mort.io too since you also run a unikernel homepage
<avsm>
Next: ARM images for Alpine Linux to replace the blobs.openmirage.org builds
<mort___>
yes
<avsm>
Progress has been made here, but is waiting on a decent build box.
<mort___>
been slowly workign on dockerising all the random crap i have for mort.io … canopy next
rudenoise has left #mirage [#mirage]
<avsm>
Good news: we have a fast multicore arm64 machine in the computer Lab that can do the builds.
<avsm>
mort___: what is the bad news? :)
insitu has joined #mirage
<mort___>
re arm build box — have (I think) got the new firmware in place on the box and on its BMC
yegods has joined #mirage
<mort___>
in doing so, the rootfs got moulinexed
<mort___>
(thanks avantek "support"!)
<avsm>
(we have reason to believe that we are in fact the first people in the world to ever buy an ARM64 machine from this particular supplier)
<mort___>
i've now booted off usb successfully and mounted the old filesystems — the uefi fs and the boot partition
yegods has quit [Remote host closed the connection]
<mort___>
i've not got further yet in either fixing things up so it boots off its hdd again, or doing a complete reinstall
yegods has joined #mirage
<avsm>
thank you for working through all the tedious installation issues mort___! The good news is that one it is up, we have fast builds for both ARM32 and ARM64.
<mort___>
i will hopefully find time tomorrow morning to spend on that
seangrove has joined #mirage
yegods has quit [Remote host closed the connection]
<avsm>
Ok, moving onto... camlp4: any remaining libraries?
<avsm>
aside from the oasis issue, is anyone aware of other blockers for libraries they need that hold them back to <OCaml 4.03?
<thomasga>
last time I tried, Irmin was not compiling with flambda
<avsm>
We have fixed URI recently, but Cohttp actually still has a constraint issue for OCaml 4.03 I need to fix (somewhere in the PPX build chain). I'm compiling right now.
<thomasga>
hopefully it should be better now
yegods has joined #mirage
<avsm>
thomasga: woah, when was this? Many bugs have been fixed in the last 2 months by mshinwell, yallop, diml, chambart
<thomasga>
last compiler hacking meeting
<thomasga>
the compilation just didn't terminate
Magnus__ has quit [Ping timeout: 250 seconds]
brson has joined #mirage
<avsm>
if anyone wants to try out ocaml 4.03, now is an excellent time to do so: `opam switch 4.03.0+trunk` or `docker run -it ocaml/opam:debian-7_ocaml-4.03.0_trunk_flambda` will get you a working environment
<djs55>
camlp4-free cstruct hasn't been released yet. It looks like ocaml-pcap hasn't been merged and released. Perhaps it's time to merge and release those 2?
<thomasga>
would be useful to test it with 4.03's candidate if anyone has time
<avsm>
djs55: thanks, added to action items. ocaml-pcap should be straightforward to release.
<mort___>
i know i have an issue against ocaml-pcap that i need to fix
<talex5>
Are there any bulk builds for 4.03?
<avsm>
thomasga: I've kicked off a docker build of irmin head on my laptop just now too
<mort___>
(via djs55 / yomimono i believe)
<avsm>
mort___: do you want to take care of the ocaml-pcap release then?
<mort___>
sure
<yomimono>
ocaml-pcap 0.4.0 is a fairly large change from 0.3 FWIW, users will need to make code changes for sure
<mort___>
is there a document describing release process anywhere? (as a n00b :)
<avsm>
mort___: thanks! talex5: I've done partial bulk builds, but they took > 500GB and so I ran out of space
<mort___>
else i'll bug yomimono as the most recent releaser :)
<avsm>
mort___: yomimono: just bump up to ocaml-pcap 1.0 then. semantic versions are cheap :)
<avsm>
ok, if everyone who mentioned libraries could do a refresh that'd be useful. I'll be tracking down the Cohttp one which unblocks a number of libraries. 4.03 will be out real soon now
<avsm>
Onto mirage-rump, which I believe mato has been looking at.
<avsm>
pinging mato pinging mato
yegods has quit [Ping timeout: 250 seconds]
<avsm>
also, a semi hijack to congratulate djwillia on releasing ukvm as well, as mentioned in last call
<yomimono>
yaaaaaay! \o/
<djwillia>
mato has been fantastic with helping get solo5 as a proper backend
<avsm>
mato and djwillia have been fixing up issues (better CPU portability, better OPAM packaging) which is awesome!
<thomasga>
yay!
<djwillia>
yes, a big thank you to mato
<avsm>
full support from me for getting solo5 in-tree, the qemu support is something we've wanted for _years_!
<thomasga>
+100
<thomasga>
that's pretty cool work
<avsm>
mato has fallen asleep at his keyboard from his heroic coding efforts, so we'll move onto the next library
<djwillia>
thanks!
<avsm>
which is...
<seangrove>
Thanks you djwillia!
<avsm>
what for it...
<avsm>
TOPKG!
<avsm>
how's it going dbuenzli ?
<thomasga>
*drum roll*
<dbuenzli>
It's going.
<dbuenzli>
When it's done.
<avsm>
Background: this is an effort to provide a simple package description format that is "opam native" to avoid duplication of metadata
<dbuenzli>
But I'm doing only this.
<dbuenzli>
But I'm slow because of you.
<thomasga>
of me?
<djs55>
Would more coffee help?
<dbuenzli>
no avsm
<avsm>
alright, no more Cambridge formal halls for dbuenzli until topkg is released
<thomasga>
avsm: stop slowing down Daniel!
<dbuenzli>
He got me to join ocaml lab's slack
<avsm>
but seriously, I'm ready to port Cohttp to topkg whenever you give the signal :)
<avsm>
Any other libraries of note that anyone would like to highlight that have been released recently?
yallop has joined #mirage
<avsm>
dinosaure got really nice results from using flambda on Decompress/Zlib
<dbuenzli>
Yes seriously, I hope to be finished at least at the beginning of may. I'm tired of the build stuff and want to do a little bit of other things
<avsm>
dbuenzli: that sounds like an excellent timeframe to me!
<thomasga>
yay!
dinosaure has joined #mirage
<dbuenzli>
I also have many other things in the pipeline that are waiting for it (e.g. carcass)
<dinosaure>
hi all :}
<thomasga>
I'm really looking forward to change all of my build scrips
<avsm>
any updates on your libraries that you'd like everyone to know?
<thomasga>
avsm: i prefer the 2nd "most popular" package in that list
<avsm>
while dinosaure is typing, thomasga : any update on new ocaml-git and irmin releases?
<dinosaure>
yes, I will improve the performance of and after that I will try to compute a gzip content
<thomasga>
there are few breaking changes
<thomasga>
and perf improvment
<avsm>
dinosaure: this is a really good test case for the new flambda mode in 4.03, so looking forward to that
<thomasga>
they now both use logs and rresult
<thomasga>
and fmt
<engil>
thomasga: you had the time to investigate the stacktraces I gave you ? :}
<thomasga>
engil: no
<engil>
:}
<avsm>
We're now also using Irmin in this very meeting to log and push them to Canopy, so I'm glad that Irmin's performance has been improved so it can scale as we type more
<engil>
ok :)
<thomasga>
might maybe release them anyway as the API is nicer (even if they are still some issues in `git push/pull` with the smart HTTP protocol)
<engil>
avsm: well to be honest the bot is just keeping everything in memory and will push later
<avsm>
That concludes the agenda that everyone wanted to discuss. Any other business people want to discuss in the closing minutes that weren't on there? Things you want tested or otherwise highlighted?
<thomasga>
@talex5 did a lot of work, I haven't done anything