These are chat archives for bjz/gfx-rs

12th
Jul 2014
Dzmitry Malyshau
@kvark
Jul 12 2014 00:54
come to think of it, I see games from ThatGameCompany matching your description very closely, as far as I understood your idea
Dzmitry Malyshau
@kvark
Jul 12 2014 01:37
I need help with lifetimes...
Corey Richardson
@cmr
Jul 12 2014 01:37
sure
Dzmitry Malyshau
@kvark
Jul 12 2014 01:38
    fn get_program<'a>(&'a mut self, handle: ProgramHandle) -> Result<&'a ProgramMeta, &'a ()>  {
        loop {
            match *self.resource.programs.get(handle) {
                Pending => (),
                Loaded(ref meta) => return Ok(meta),
                Failed(ref e) => return Err(e),
            }
            let reply = self.device_rx.recv();
            self.resource.process(reply);
        }
    }
Corey Richardson
@cmr
Jul 12 2014 01:38
is there a reason you are returning &'a ()?
Dzmitry Malyshau
@kvark
Jul 12 2014 01:39
match prevents self.resource borrow
src/render/lib.rs:196:13: 196:26 error: cannot borrow `self.resource` as mutable because `self.resource.programs` is also borrowed as immutable
src/render/lib.rs:196             self.resource.process(reply);
                                  ^~~~~~~~~~~~~
src/render/lib.rs:189:24: 189:46 note: previous borrow of `self.resource.programs` occurs here; the immutable borrow prevents subsequent moves or mutable borrows of `self.resource.programs` until the borrow ends
src/render/lib.rs:189                 match *self.resource.programs.get(handle) {
                                             ^~~~~~~~~~~~~~~~~~~~~~
src/render/lib.rs:198:6: 198:6 note: previous borrow ends here
src/render/lib.rs:186     fn get_program<'a>(&'a mut self, handle: ProgramHandle) -> Result<&'a ProgramMeta, &'a ()>  {
...
src/render/lib.rs:198     }
Corey Richardson
@cmr
Jul 12 2014 01:39
try putting it in a block
Hm :(
Dzmitry Malyshau
@kvark
Jul 12 2014 01:39
tried... doesn't work
I think it's because the return type is bound to "'a" lifetime
but not entirely sure...
Corey Richardson
@cmr
Jul 12 2014 01:40
I'm not entirely sure either
ask in #rust?
Dzmitry Malyshau
@kvark
Jul 12 2014 01:40
ok
@cmr returning () error because we don't have those typed yet (temporal, as may other things you could have noticed)
Corey Richardson
@cmr
Jul 12 2014 01:41
ah ok
I think I can see why it is erroring but not how to fix it
if putting the match in the block didn't help
Dzmitry Malyshau
@kvark
Jul 12 2014 01:44
@cmr optimally, I'd like this function to only hold self as mutable reference for the life time of the function block, and hold it as immutable for the life time "'a". It looks to be outside of current Rust capabilities though....
Marvin Löbel
@Kimundi
Jul 12 2014 01:45
@kvark Does destructuring self first work?
ah wait, both are methods on ressourcess...
Dzmitry Malyshau
@kvark
Jul 12 2014 01:46
I'm stuck with it since yesterday...
Marvin Löbel
@Kimundi
Jul 12 2014 01:50
@kvark: Do you have that code snippet in a form that is compilable? Does it just use types already defined somewhere in gfx?
Dzmitry Malyshau
@kvark
Jul 12 2014 01:55
@Kimundi I'll try to make it a standalone snippet in a moment
@Kimundi Snippet is generously provided by @P1start http://is.gd/aUHYXN
Dzmitry Malyshau
@kvark
Jul 12 2014 02:32
@cmr so that's it? could you have a try (with the snippet) to work around it?
Corey Richardson
@cmr
Jul 12 2014 02:34
@kvark I can't figure out how to work around it :(
Marvin Löbel
@Kimundi
Jul 12 2014 02:37
@kvark I could only imagine working around it with internal mutability... Making all involved methods take &self
Dzmitry Malyshau
@kvark
Jul 12 2014 02:39
@Kimundi but would there be an overhead?

I kinda had a workaround - split it into 2 functions:

  1. &mut self, prepares the resource, returns nothing
  2. &self, returns the resource reference

But then realized that's error-prone and not very rustic... :(

Corey Richardson
@cmr
Jul 12 2014 02:40
Did that work?
Dzmitry Malyshau
@kvark
Jul 12 2014 02:40
ya
Corey Richardson
@cmr
Jul 12 2014 02:41
I tried doing something like that and it didn't, I wonder what you did different
Dzmitry Malyshau
@kvark
Jul 12 2014 02:41
@cmr oh well, I'll follow this path then (since we don't have alternatives), and will keep an eye on that rust bug you mentioned on IRC
Dzmitry Malyshau
@kvark
Jul 12 2014 03:56
I was able to wrap my code up to a point where I compile (with no warnings!) and run the triangle example, so I decided to share #95 to get feedback. Sorry if that's too much of a read there :hamster:
Dzmitry Malyshau
@kvark
Jul 12 2014 04:01
off to sleep now...
Corey Richardson
@cmr
Jul 12 2014 18:09
@kvark reviewing #95 now
Dzmitry Malyshau
@kvark
Jul 12 2014 18:17
@cmr awesome, thanks!
Sven Nilsen
@bvssvni
Jul 12 2014 18:37
@bjz I am thinking about creating a simple vector math library
Corey Richardson
@cmr
Jul 12 2014 18:52
@kvark at first pass it looks fine, but I want to take a few more looks through it to make sure I 100% understand the design here.
(I imagine this is approximating much more closely what the final design is?)
Dzmitry Malyshau
@kvark
Jul 12 2014 22:48
@cmr the final design is not set, but I believe that deferred/async loading in general is a must have feature. Whether or not my implementation gets us closer to the goal is what we need to figure out.
The thing I'm most confident about is the new device - render protocol.
Corey Richardson
@cmr
Jul 12 2014 23:21
@kvark what is the purpose of ping/pong?
The protocol needs docs in general :P
Dzmitry Malyshau
@kvark
Jul 12 2014 23:58
@cmr I added it as a fence mechanism: if render needed to wait for a resource, it sends Ping and then stops are receiving either the resource (success) or the Pong with the same token (something went wrong). I ended up not using this scheme because it still relies on the Ping/Pong being executed flawlessly, so it's easier to just assume all other calls are also flawless. I just don't want the render to stop completely in case the device doesn't send the needed resource back.
That being said, I can remove Ping/Pong if you think we'll not have a use case for it.