avsm changed the topic of #mirage to: mirage 2 released! party on!
rgrinberg has quit [Remote host closed the connection]
copy` has quit [Quit: Connection closed for inactivity]
julio__ has joined #mirage
ansiwen_ has joined #mirage
sigjuice_ has joined #mirage
aggelos__ has joined #mirage
haesbaer1 has joined #mirage
sigjuice has quit [Ping timeout: 255 seconds]
julio_ has quit [Ping timeout: 255 seconds]
aggelos_ has quit [Ping timeout: 255 seconds]
copumpkin has quit [Ping timeout: 255 seconds]
ansiwen has quit [Ping timeout: 255 seconds]
haesbaert has quit [Ping timeout: 255 seconds]
julio__ is now known as julio_
copumpkin has joined #mirage
poka has joined #mirage
brson has quit [Quit: leaving]
insitu has joined #mirage
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
insitu has joined #mirage
w10have has joined #mirage
fgimenez has joined #mirage
fgimenez has joined #mirage
fgimenez has quit [Changing host]
mort___ has joined #mirage
Meeh has left #mirage ["Screw u guys, I'm going home!"]
mort___ has quit [Ping timeout: 240 seconds]
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mort___ has joined #mirage
insitu has joined #mirage
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
seangrove has joined #mirage
philtor has quit [Ping timeout: 240 seconds]
philtor has joined #mirage
amirmc has joined #mirage
thomasga has joined #mirage
<thomasga> hello
noddy has joined #mirage
talex5 has joined #mirage
<reynir> hello
<amirmc> o/
fgimenez has quit [Ping timeout: 252 seconds]
TImada has joined #mirage
fgimenez has joined #mirage
fgimenez has joined #mirage
fgimenez has quit [Changing host]
<thomasga> meeting starting soon, please update the agenda if you want to discuss about stuff not in there yet
djs55 has joined #mirage
ricarkol has joined #mirage
<reynir> oh! I always forget the meetings! o/
<vbmithr_> Hi
* djs55 waves
<thomasga> we are still looking for someone to take "human-readable" notes of this meeting, if you are interested please do :-) (and send me a summary to put online)
<thomasga> Mindy is travelling and asked me to run the meeting
<mort___> .
<thomasga> so let's start!
<hannes> hello!
djwillia has joined #mirage
<thomasga> first item on the agenda (https://irclog.whitequark.org/mirage/2017-02-15) is: hack retreat!
<thomasga> @hannes?
<hannes> it will happen. we're 34ish people right now :)
<hannes> still room for spontaneous guests (up to a certain level) :)
<thomasga> I've read the introduction that people sent on the mailing list, that looks like a pretty nice bunch of people!
<hannes> are there any specific questions? ;)
<thomasga> apparently not :-)
<hannes> I try to prepare some small service doing dhcp and dns using mirageos (and dnsupdate) for running locally :)
<thomasga> do you plan to write blog posts?
<thomasga> using canopy or something else?
<hannes> I hope to also deploy a local git server, with canopy locally and mirrored off-site :)
<thomasga> so that people not at the hackaton can see what is going on?
<thomasga> (like me ? bouhouhou)
<hannes> yes, we will! for sure! :) stay tuned
<thomasga> great!
<mort___> +1 :)
<lobo> hi
<hannes> thomasga: you're really not coming? :(
<thomasga> very low probability. Still not 0, so there is (a little) hope.
<hannes> I'm optimistic! :D (should I just book you some plane tickets? ;)
<thomasga> If nobody has more questions about the hackaton in Marroco, let's pass to the next item: Mirage3!
<thomasga> Mindy is traveling, so she can't do an update. (I believe this meeting will be quick :p)
<thomasga> but the tracking issue for the release is https://github.com/mirage/mirage/issues/592
<thomasga> lots of boxes are ticked
<thomasga> https://github.com/mirage/mirageos-3-beta contains all the tagged packages
<hannes> thomasga: amirmc any news on the press release front? I guess the release is more or less tested now, and djs55 and thomasga busily add irmin+fs packages to the beta repo!?
<thomasga> (which will be released soon)
<mort___> looks like mostly docs, deployable services, performance harness, blog posts / press releases left.
<mort___> are we going to hold the release up on the performance harness?
<mort___> i guess the docs and blog posts are being worked on… ?
<thomasga> I have just added git.1.10.0, and I am planning to add Irmin.1.0.0 in there at one point (hopefully before the end of the week, but everything takes always more time than I expect...)
<mort___> i'll pick up getting mirage-perf working again (had forgotten about that)
<djs55> unfortunately the CI on mirageos-3-beta seems to be out of disk space
<hannes> I don't think performance was a priority item of Mirage3 (though, intuitively it will be faster) ;)
<mort___> intuitive speed— the best kind ;)
<thomasga> djs55: we need to wait for @avsm to come back to fix the CI :-/ we need a more automated solution
<thomasga> feedback welcome
<thomasga> (you can add the feedback on the tracking issue for release, on GitHub mirage#592)
<thomasga> @amirmc: anything to add related to the press release? everything is under control?
<thomasga> hannes: are you still planning to work on the blog post "how MirageOS 3 got smaller and less magical"?
<hannes> thomasga: yes. WIP
<hannes> draft be there at the end of this week
<thomasga> @talex5: any chance that you can pick up the ""error handling in MirageOS" draft RFC into currently-accurate document" task?
<seangrove> Sounds exciting!
<thomasga> otherwise I can try to do it :-)
<talex5> Hmm, well my proposal was for something different. I think we should close that PR.
<thomasga> also, I am planning to write some docs for Irmin 1.0
<thomasga> @talex5: it's probably useful to document a bit more how the error are now handled in Mirage. @djs55 had some related issues with qcow2
<thomasga> but I can try to do it
<thomasga> (I am still reviewing the list of things to do for the release) For the changelogs, I think Mindy has made some toolings, I'll check with her with is the status of that task.
<mort___> my impression from yesterday evening was that she won't directly include teh changelogs in the blog post but will have something that points to the github provided diffs-between-tags
<thomasga> ok
<mort___> (but yes, check with her, she knows :)
<thomasga> @seangrove is there anything that you would like to see for the release?
<seangrove> thomasga: No, we're neck-deep in non-mirage-related stuff right now, so just watching from the sidelines
<thomasga> something that you think will excite potential users?
<thomasga> ok no pb
<thomasga> if you think of anything, please tell us :-)
<amirmc> Sorry, I was afk. Press Release is delayed on getting a date, which means co-ordinating with multiple parties. It's taken a while as there hasn't been a date that works for everyone. I've been chasing it and will let folks know as soon as I have more info. The content of the press release also needs to be reviewed by a bunch of people (e.g. LinuxFoundation, et al). First draft is pretty much ready for that.
<thomasga> should we still decouple the actual opam release and blog post stream and the press release?
<thomasga> (it's probably best, right?)
<amirmc> To summarise, there are two blockers for the Press Release. 1. deciding a date and 2. getting the content approved. I'm working on both.
<amirmc> Blog post pre-empts the press-release.
<thomasga> great, thanks
<hannes> and we plan to have it done before the hack retreat, don't we?
<amirmc> i.e. if a 3.0 post goes out, then no-one will be interested in writing articles about the release. They're kind of coupled.
<djwillia> amirmc: would it be possible for you to share the press release draft at this point? I'd still like to get IBM to make its quote :)
<amirmc> Unless we want to have blog posts about specific features, rather than an overview post. That should be fine.
<mort___> amirmc: ok— so the press release has to come before the blog posts, but the opam releases could trickle out before?
<djwillia> and i feel like i've been neglecting that
<amirmc> djwillia: Yes, I'll share it once I've had various marketing depts sign off on it :)
<thomasga> I am a bit confused with the dependencies between all the releases. It's a bit weird to just release in opam without publishing a blog post.
<mort___> it sounds like we're arguing ourselves to a state where everything is gated on the press release then
<thomasga> so we keep everything in a separate remote until the press release is out?
<thomasga> and no blog post?
<mort___> itym: blog post after press release?
<amirmc> Yes, it would be weird to release that way. We can't release without explain to people what changed. But we can't tell people what changed without pre-empting our own announcement (shrug)
<thomasga> do we really care about the press release? :p
<amirmc> yes
<amirmc> we do
<thomasga> is there any chance that this will happen before the hackaton?
<amirmc> We can still do a chai of posts like we did for 2.0 though.
<mort___> we also care about developer sanity :) so minimising time between packages being ready and release going out would be very useful
<amirmc> It's only the _announcement_ post (i.e. "here's 3.0!") that we shouldn't do.
<mort___> given the many api changes, i'm not sure how many pacakges can be released (and thus blogged about) incrementally
<thomasga> not much
<hannes> amirmc: for me (at least) it would be helpful to have in some issue a proposed timeline (with as precise dates as possible) for the release
<amirmc> They can be blogged about in the context of the beta quite easily.
<amirmc> hannes: I agree. And we keep thinking we had this but dates shift and code wasn't ready.
<thomasga> code is ready now, so we can have a new timeline :-)
<hannes> amirmc: then as soon as you have dates
<mort___> ok. so we start publishing a sequence of blog posts about "Mirage v3 beta components". meanwhile amirmc pushes forwards with the press release and we finally flip the switch in opam and put a summary "we released!" post live when the press release goes out … ?
<hannes> thomasga: I couldn't find the right irmin release to run canopy on mirage3 yet ;P
<thomasga> hum. code is "almost" ready now.
<amirmc> mort___: that would work for me. And means we can link to those posts from the press release itself (which is a nice bonus)
<mort___> thomasga: yes, so we can start blogging it while the PR catches up (and we find remaining bugs, finish updating docs, etc)
<hannes> (as stated above, I'll have the post on less magic and less code ready by the end of this week)
<mort___> amirmc: yes, true
<thomasga> @mort___ @amirmc: as long as the beta doesn't long for 3 months, that looks good :p
<mort___> thomasga: amen to that :)
<mort___> that's what I meant about developer sanity — we don't want things queuing up against the "beta" repos for too long
<amirmc> In that case we'd explicitly planned a blog post series before the release.
<mort___> else people feel compelled to submit issues / PRs against v2 versions
<thomasga> @amirmc: can you sync with Mindy to check how she wants to run things? And try to come up with a timeline?
<amirmc> I want this announcement (and code) to go out as much as everyone else.
<amirmc> mindy's in the loop on all that stuff already :)
<mort___> yup understood :)
<mort___> cool
<djs55> I've been merging v3 things to components master branches for v3 now. This means that it's harder to get stuff to build than it was before (missing remote == odd errors). If it's going to be a while before the official release perhaps we should go round and edit all the READMe files
<thomasga> sure, but it seems that having a timeline and communicating to the team seems to something quite important now :-)
<amirmc> Blockers are as mentioned earlier 1. Dates and 2. Approvals from various parties. :)
<amirmc> Unless we decide not to do a Press Release at all.
<mort___> i think that for graduation from LF it would be nice
<amirmc> That's off the table for now
<mort___> (oh, hadn't realised)
<amirmc> Since no-one really knows what it means :)
<mort___> amirmc: ok, so i guess the question is: how long until you think you can get a date nailed down from the various parties involved?
<thomasga> @amirmc: do you have some estimates for the dates? Is that days/weeks/months? (curious about what to expect here)
<mort___> we can then take a view on whether we can feasibly wait that long given how ready things are
<thomasga> (we might have lost Amir :p)
<thomasga> any other topic to discuss for the release?
<amirmc> I'll work on it and get back to you but the lead time is about a week or two (since people have to co-ordinate with journalists etc).
<mort___> in the meantime, perhaps we start releasing blog posts referring to components for mirage v3 beta
<thomasga> ok great
<mort___> amirmc: that's a week or two until we have a date, which may be some weeks later?
<amirmc> mort__: It's a minimum amount of time required. i.e. if dates were not a blocker, we could do it in a week or so.
<mort___> ok cool
<thomasga> last item in our agenda: progress on Irmin 1.0.
<thomasga> I am planning to merge https://github.com/mirage/irmin/pull/397 very soon
<amirmc> Let me know if there are points I've not covered. I've been trying to read and type at the same time but I probably missed stuff.
<thomasga> I have made a new release of ocaml-git (where references can be updated using test-and-set) and with better windows support.
<amirmc> thomasga: The folks at Ericsson have been using Irmin a lot (v0.11 I believe). Any tips on how to move to the newer version (before release) would be helpful :)
<thomasga> I will try to address/close the issues labeled with 1.0 on irmin bug tracker: https://github.com/mirage/irmin/labels/1.0
<thomasga> @amirmc: yes, I am planning to write docs
<thomasga> but I am focusing first of rewriting everything :-)
<mort___> thomasga: everything is … everything ;) is there anything that would benefit from wider testing?
<thomasga> and I will try to update canopy too
<mort___> (ie., where you don't already need to know irmin :))
<thomasga> the test suite is pretty complete, so I think that should be ok. I know the Git push/fetch protocol has some issues, this is *not* addressed in that release
<mort___> ok cool
* hannes will finally release -- after ~10 rewrites -- conex -- this week! http://berlin.ccc.de/~hannes/conex.png :D
<thomasga> but I hope @dinosaure will fix all the issues related to push/fetch
<mort___> hannes: yay! thomasga: yes!
<thomasga> anything else to discuss?
amirmc has quit [Quit: Leaving.]
<thomasga> if not, I call the end of that meeting! Merci everyone
<mort___> au revoir!
<djwillia> thanks all!
ricarkol has quit [Quit: Page closed]
talex5 has quit [Quit: Leaving]
djs55 has quit [Quit: Leaving.]
TImada has left #mirage [#mirage]
insitu has joined #mirage
djwillia has quit [Quit: Page closed]
brson has joined #mirage
copy` has joined #mirage
fgimenez has quit [Ping timeout: 264 seconds]
fgimenez has joined #mirage
fgimenez has joined #mirage
fgimenez has quit [Changing host]
<gjaldon__> @thomasga I prepared a summary of the earlier meeting at https://gist.github.com/gjaldon/3e29791405390c72ee19eb91a9585554. Let me know if there’s anything you would like improved
<thomasga> @gjaldon__: thank you very much! I'll check with Mindy how we can put your notes on the website (if that's fine with you)
<gjaldon__> yes, that is fine with me :)
seangrove has quit [Ping timeout: 245 seconds]
w10have has quit [Ping timeout: 252 seconds]
fgimenez has quit []
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
amirmc has joined #mirage
amirmc has quit [Client Quit]
mort___ has quit [Ping timeout: 252 seconds]
yomimono has joined #mirage
yomimono has quit [Ping timeout: 276 seconds]
yomimono has joined #mirage
thomasga has left #mirage [#mirage]
yomimono has quit [Ping timeout: 256 seconds]
haesbaer1 has quit [Quit: leaving]
haesbaert has joined #mirage
mort___ has joined #mirage
insitu has joined #mirage
brson has quit [Quit: leaving]
brson has joined #mirage
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
<haesbaert> so I'm feeling dirty about using Cstruct.concat
<haesbaert> basically I do stuff like
<haesbaert> let a = encode_foo(asomething)
<haesbaert> let b = encode_bla(bsomething)
<haesbaert> let c = encode_moinomoin(csomething)
<haesbaert> a, b and c are Cstruct.t
<haesbaert> but then I Cstruct.concat [a, b, c]
<haesbaert> this is 4 mallocs + 1 memcpy
<haesbaert> so I'm thinking about something like
<haesbaert> let buf = Cstruct.create 4096 |> Cstruct.set_len 0
<haesbaert> then encode becomes: let encode_foo foo buf
<haesbaert> encode_foo a buf |> encode_bla b |> encode c
<haesbaert> then each encode does Cstruct.shift and Cstruct.add_len
<haesbaert> and it makes sure it "can" do it, by calling Cstruct.check_bounds, and making sure the buffer is big enough
<haesbaert> ideas ?
<haesbaert> am I nuts ?
<kensan> hannes: just fyi, https://hannes.nqsb.io/Posts/Jackline gives me an Internal Server Error.
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
brson has quit [Ping timeout: 260 seconds]
brson has joined #mirage
<hannes> kensan: thx, fixed!
<hannes> haesbaert: since cstruct-2.2.0 the set 0 is no longer needed, Cstruct.create will zero out the buffer
<haesbaert> ah no, I mean cstruct.set_len 0
<hannes> oh ic... and yes, it is not entirely clear to me where to allocate things... it sounds like allocation a page and filling it should be less pressure on the gc+os than allocating every 2 bytes individually
<haesbaert> I mean I can precalculate how much I need, and then do one allocation and set some offsets
<haesbaert> but that is incredibly error prome
<haesbaert> *prone
<hannes> and wasn't spiros working on that with faraday, the reverse angstrom.. !?
<haesbaert> I want to do something like add_byte 7 buf |> add_uint32_t Int32.zero |> add_string "foo"
<haesbaert> and then get a Cstruct.t in the end,
<haesbaert> buf could start with lets say 1024, and it grows by 1024 every time there is no space, or something like that
<haesbaert> hmm I'm not aware
<haesbaert> like, on decoding I have an awesome idiom:
<haesbaert> decode_nl buf >>= fun (kex_algorithms, buf) ->
<haesbaert> decode_nl buf >>= fun (server_host_key_algorithms, buf) ->
<haesbaert> decode_nl buf >>= fun (encryption_algorithms_ctos, buf) ->
<haesbaert> I want the inverse in a similar idiom
<haesbaert> basically it gets what it wants and shifts
<haesbaert> I want to put and shift now
<haesbaert> without having to worry about sizes and what not
<haesbaert> I'm cooking up somehting, lets see how it goes
<hannes> :)
<haesbaert> I can't sleep with 4 + mallocs + 1 memcpy to handle 9 bytes
seangrove has joined #mirage
<haesbaert> hmm there is no "unshift" :(
<haesbaert> came up with this:
<haesbaert> Buf.(add_uint32 code (create ()) |>
<haesbaert> add_string lang |>
<haesbaert> add_string desc |>
<haesbaert> to_cstruct)
noddy has quit [Ping timeout: 240 seconds]
mort___ has quit [Quit: Leaving.]
noddy has joined #mirage