02:12 <dwrensha> kentonv: OK, I'll work on a better description

05:06 <neynah> how are things going kentonv ?

05:06 <kentonv> eh?

05:08 <neynah> do you need me to help you with anything before Monday?

05:09 <kentonv> I don't think so

11:17 <JWK> Hello all

12:45 <dwrensha> hello JWK

12:45 <JWK> hi :-)

12:47 <dwrensha> you have a capnproto-rust question for me?

12:47 <JWK> yup

12:47 <dwrensha> fire away

12:48 <JWK> I had a question regarding as_reader() method in capnp-rust Builder struct. I was wondering if changing it to accept reference to self instead of value would break anything.

12:50 <dwrensha> You would at least need to make sure to tie the lifetime of the input to the output, like this: `fn as_reader<'b>(&'b self) -> Builder<'b>`

12:51 <dwrensha> er, `fn as_reader<'b>(&'b self) -> Reader<'b>`

12:52 <dwrensha> otherwise you'll have potential aliasing issues

12:52 <JWK> of course

12:52 <dwrensha> and then the problem is exactly the same with taking a reference in a get() or an init() method: it's less flexible

12:53 <dwrensha> it prevents you from returning calling `as_reader()` on something you've constructed in the middle of a function, and then returning the resulting reader

12:53 <dwrensha> because it won't live long enough

12:54 <JWK> the current problem I have with Builder structs is that I can only use it to write data into it, but not use it as internal struct for my application, because any simple read-only access to its contents move it. So if I have a capnp struct containing an integer, any attempt to read the integer will invalidate the struct.

12:55 <dwrensha> that is what the borrow() method is for

12:56 <JWK> yep, but borrow uses mutable self reference on input. It would be useful to have a read-only borrow that returned a Reader

12:57 <JWK> for instance, if I wanted to implement fmt::Display for a Builder, right now I have no option.

12:58 <dwrensha> hm, yeah I suppose that is awkward

12:59 <dwrensha> could you impl Display for `&'a mut Builder<'a>`?

13:00 <JWK> nop, that’s not possible, as the only method allowed for Display is: fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result

13:00 <dwrensha> it's also true the the core capnproto-rust library ought to be providing stringification functions...

13:04 <JWK> Also, it would be nice to have as_reader(), borrow(), etc as traits, so they could be used in generics.

13:04 <dwrensha> I think it should be possible to do `impl <'a> Display for `&'a mut Builder<'a> { ... }`. Then the self argument to `fmt()` would have type `& &mut Builder`.

13:07 <dwrensha> Good point re generics. Yes, those should be provided via traits.

13:11 <dwrensha> The "mut" that we end up needing for capnproto Builder types is more about uniqueness than about mutability per se.

13:12 <JWK> I just tried your advice on Display, but it seems that, although the signature is respected, I cannot actually call borrow() or as_reader() on self:

13:13 <dwrensha> I wonder whether we should provide two `as_reader()` methods for Builders. One by-move, and one by-reference.

13:13 <JWK> error: cannot move out of borrowed content on as_reader(); cannot borrow data mutably in a `&` reference on borrow()

13:14 <JWK> if it doesn’t break guarantees, it would be certainly helpful to support immutable patterns

13:14 <dwrensha> ... maybe the as-reference once would be called `borrow_as_reader()`

13:36 <dwrensha> OK, I'm pretty convinced that we need borrow_as_reader()

13:36 <dwrensha> adding it now

13:49 <JWK> :-)

13:50 <dwrensha> hm... actually I'm first trying to convince myself that the impl Display that I suggested above doesn't work

13:59 <dwrensha> OK, done.

13:59 <dwrensha> JWK: do you need me to publish a new version on crates.io with this change?

14:01 <JWK> well, that would be great, but I can just pull from github if you prefer to publish the new release later on.

14:03 <dwrensha> OK, I'm going to hold off on publishing right this moment

14:49 <JWK> thanks for your patience :-)

21:25 <mnutt_> I’m trying to add HTTP methods to sandstorm’s WebSession and getting `remote exception: Method not implemented.; interfaceName = sandstorm/web-session.capnp:WebSession; typeId = 11891492725577853134; methodId = 10`. I’ve implemented the method in sandstorm-http-bridge.c++, is there something else I need to do to override properly?

21:25 <mnutt_> the diff is at https://github.com/sandstorm-io/sandstorm/compare/master...mnutt:webdav-bridge

21:26 <kentonv> mnutt_: what app are you testing against?

21:27 <kentonv> note that sandstorm-http-bridge is bundled into the app, so you'll have to rebuild the app

21:27 <mnutt_> I’m using `make && make update` from the readme to rebuild sandstorm

21:28 <kentonv> and the app?

21:28 <dwrensha> mnutt_: by the way, you may find `make continuous` to be more convenient

21:29 <kentonv> yeah, you can have `make continuous` running in one window and then do other `make` commands in another window and they'll avoid rebuilding from scratch every time

21:30 <mnutt_> unfortunately the app depends on the changes so I’m building both at the same time, the app is here: https://github.com/mnutt/davros

21:31 <mnutt_> I’m using spk while building the app

21:31 <kentonv> ok, so after every `make update`, you'll need to kill `spk dev` and re-run it so it gets the latest sandstorm-http-bridge

21:33 <mnutt_> ah, that would explain it. which is why sandstorm itself knows about the capnp changes but the app’s bridge doesn’t

21:33 <kentonv> yeah

21:33 <kentonv> TBH I'm surprised spk dev apps survive through sandstorm updates at all...

21:39 <kentonv> (shutting down for a bit to rewire my desk)