00:15 <cmr> dwrensha: really excited about futures-rs capnp!

02:29 <dwrensha> cmr: I'm happy to hear that Cap'n Proto is still on Robigalia's radar

02:29 <cmr> dwrensha: very much so :)

02:30 <cmr> dwrensha: there are a lot of kinks to work out in the core system before we get to the point where we'll be using a userspace cap system, but we'll get there.

21:56 <_habnabit> dwrensha, sorry, i'm not sure if it's documented somewhere i missed, but it's not clear what the lifetime 'a on a struct's Reader is. i was trying to figure out how to take ownership of sub-structs by consuming a parent struct, if it's possible. like if as an rpc result i get a List(T) and i want to now own some, but not all, of these items without owning the rest of the rpc result

21:57 <_habnabit> dwrensha, oh, i just found the explanation on the Owned trait

23:28 <dwrensha> _habnabit: right now the easiest thing is to make a copy of the sub-object

23:28 <_habnabit> dwrensha, with .clone() ?

23:28 <dwrensha> I was thinking message::Builder::set_root()

23:29 <_habnabit> oh

23:29 <dwrensha> And you could write a wrapper around the message builder to remember the type information

23:29 <dwrensha> we should probably figure out a standard way to do this and put it in the library

23:30 <_habnabit> so i make a new Builder, use set_root to implicitly copy from a Reader, and then i own the thing

23:30 <dwrensha> "implicitly"?

23:31 <_habnabit> it feels implicit if it's not using the usual approach for this in rust

23:31 <dwrensha> let mut msg = ::capnp::message::Builder::new_default();

23:31 <dwrensha> msg.set_root(reader);

23:34 <_habnabit> and there's no standard type in ::capnp that does the wrapping so the type is encoded in a way that it's guaranteed to be the right thing passed to set_root/get_root_as_reader

23:34 <_habnabit> ?

23:34 <dwrensha> it's not an encoding question

23:35 <dwrensha> it's inconvenient that when you want to use this message again, you need to specify the type

23:35 <dwrensha> msg.get_root<T>()

23:36 <dwrensha> we could write a wrapper that remembers the type

23:36 <_habnabit> right, that's what i mean: if you had a Wrapper<T>(::capnp::message::Builder), it could have a get_root_as_reader with no type parameter

23:36 <dwrensha> none exists in ::capnp yet

23:36 <_habnabit> okay

23:36 <aeternity> hi guys

23:37 <dwrensha> why hello

23:37 <dwrensha> what's up aeternity?

23:37 <aeternity> is it possible to use the rocket.chat dev branch in sandstorm?

23:38 <aeternity> dwrensha: thanks... trying to make it work again! :)

23:38 <aeternity> is any of the core devs here btw? I had send an email to jade around christmas, but no reply.

23:39 <dwrensha> you can clone the rocket.chat git repo and then do `vagrant-spk vm up`

23:39 <dwrensha> then `vagrant-spk vm dev`

23:39 <dwrensha> er, `vagrant-spk dev`

23:39 <dwrensha> and that'll launch the latest version on a local VM

23:40 <dwrensha> aeternity: are you trying to fix the slackbridge problem?

23:40 <aeternity> yeah

23:41 <aeternity> I mean,the fix is on GH

23:41 <aeternity> I am just trying to get my users back now

23:41 <aeternity> and the data inside this grain

23:41 <aeternity> would have been so easy if it was not inside this strange DB... but isntead on filesystem

23:43 <aeternity> dwrensha: would this above suggested path work for production?

23:43 <aeternity> or is it unsecure?

23:43 <aeternity> the sandstorm server is running

23:43 <dwrensha> ideally the rocket.chat devs would publish a new spk

23:44 <dwrensha> you could build a dev spk, but without the rocket.chat signing key, sandstorm won't let you use it for your existing grain

23:45 <aeternity> thus there is no way around messing with that database?

23:47 <dwrensha> if you want a fix ASAP, modifying the database seems like the easiest way

23:47 <aeternity> maybe I should fork sandstorm to let me use whatever grain?

23:47 <aeternity> yes, ASAP. imagine all your team is offline.

23:47 <dwrensha> actually, I find myself without more pressing priorities at the moment, so maybe I can work through the database edit with you

23:48 <aeternity> oh, that would be wonderful

23:48 <dwrensha> is mongo installed on the Server?

23:48 <aeternity> yes, I did

23:48 <dwrensha> what verstion?

23:49 <aeternity> mongod --version

23:49 <aeternity> 2017-01-06T00:48:59.828+0100 OpenSSL version: OpenSSL 1.0.2g 1 Mar 2016

23:49 <aeternity> 2017-01-06T00:48:59.828+0100 git version: nogitversion

23:49 <aeternity> db version v2.6.10

23:49 <aeternity> should be standard ubuntu 16.04

23:50 <dwrensha> hm. I think that's going to be too old

23:50 <aeternity> ok, removing and installing from mongo website

23:50 <dwrensha> alternatively, maybe we can just use the mongod that is packaged up in the rocket.chat app

23:50 <aeternity> hmm yes, maybe?

23:53 <dwrensha> if it's easy for you to install mongo 3, that would probably streamline this

23:53 <aeternity> sure

23:57 <aeternity> mongod --version

23:57 <aeternity> db version v3.4.1

23:58 <dwrensha> nice

23:59 <dwrensha> what about `mongo --version` ?

23:59 <aeternity> mongo --version

23:59 <aeternity> MongoDB shell version v3.4.1