Re: [rust-dev] Need help implementing some complex parent-child task behavior.
So I managed to implement a solution without needing a child task, using Kevin's initial idea of a struct with private fields and public getters. The idea had occurred to me but I wasn't sure exactly how to implement it; needless to say, I think I was overcomplicating things. Thanks for the help, Kevin. On Fri, Feb 14, 2014 at 4:18 PM, Damien Radtke damienrad...@gmail.comwrote: Ah, I think the problem is that I'm trying to create a new task within a loop over an iterator, so each value is an -ptr and is therefore causing it to fail... On Fri, Feb 14, 2014 at 4:12 PM, Damien Radtke damienrad...@gmail.comwrote: The function pointer is indeed a function pointer and all of the strings and vectors are ~, but the vector type is 'static. They're meant to hold references to card definitions, which is more efficient than passing around the cards themselves. I tried modifying the vectors to hold ~-strings instead, but it still didn't work. Looks like I'll need to do more research on Send. On Fri, Feb 14, 2014 at 3:19 PM, Kevin Ballard ke...@sb.org wrote: Depends. If the string or the vectors are instead of ~, that would do it. Also, if the element type of the vector does not fulfill Send. Oh, and the function pointer is a function pointer, not a closure, right? -Kevin On Feb 14, 2014, at 12:59 PM, Damien Radtke damienrad...@gmail.com wrote: Unfortunately, the type that maintains the state apparently doesn't fulfill Send, which confuses me because it's a struct that consists of a string, function pointer, and a few dynamically-sized vectors. Which of these types makes the struct as a whole violate Send? On Fri, Feb 14, 2014 at 2:47 PM, Kevin Ballard ke...@sb.org wrote: What if the state's fields are private, and in a different module than the players, but exposes getters to query the state? Then the players can't modify it, but if the component that processes the actions has visibility into the state's fields, it can modify them just fine. -Kevin On Feb 14, 2014, at 12:22 PM, Damien Radtke damienrad...@gmail.com wrote: I'm trying to write what is essentially a card game simulator in Rust, but I'm running into a bit of a roadblock with Rust's memory management. The gist of what I want to accomplish is: 1. In the program's main loop, iterate over several players and call their play method in turn. 2. Each play method should be able to send requests back to the parent in order to take certain actions, who will validate that the action is possible and update the player's state accordingly. The problem I'm running into is that, in order to let a player play and have the game validate actions for them, I would need to run each player in their own task, (I considered implementing it as each function call indicating a request for action [e.g. by returning Some(action), or None when finished] and calling it repeatedly until none are taken, but this makes the implementation for each player needlessly complex) but this makes for some tricky situations. My current implementation uses a DuplexStream to communicate back and forth, the child sending requests to the parent and the parent sending responses, but then I run into the issue of how to inform the child of their current state, but don't let them modify it outside of sending action requests. Ideally I'd like to be able to create an (unsafe) immutable pointer to the state held by the parent as mutable, but that gives me a values differ in mutability error. Other approaches so far have failed as well; Arcs don't work because I need to have one-sided mutability; standard borrowed pointers don't work because the child and parent need to access it at the same time (though only the parent should be able to modify it, ensuring its safety); even copying the state doesn't work because the child then needs to update its local state with a new copy sent by the parent, which is also prone to mutability-related errors. Any tips on how to accomplish something like this? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Need help implementing some complex parent-child task behavior.
I'm trying to write what is essentially a card game simulator in Rust, but I'm running into a bit of a roadblock with Rust's memory management. The gist of what I want to accomplish is: 1. In the program's main loop, iterate over several players and call their play method in turn. 2. Each play method should be able to send requests back to the parent in order to take certain actions, who will validate that the action is possible and update the player's state accordingly. The problem I'm running into is that, in order to let a player play and have the game validate actions for them, I would need to run each player in their own task, (I considered implementing it as each function call indicating a request for action [e.g. by returning Some(action), or None when finished] and calling it repeatedly until none are taken, but this makes the implementation for each player needlessly complex) but this makes for some tricky situations. My current implementation uses a DuplexStream to communicate back and forth, the child sending requests to the parent and the parent sending responses, but then I run into the issue of how to inform the child of their current state, but don't let them modify it outside of sending action requests. Ideally I'd like to be able to create an (unsafe) immutable pointer to the state held by the parent as mutable, but that gives me a values differ in mutability error. Other approaches so far have failed as well; Arcs don't work because I need to have one-sided mutability; standard borrowed pointers don't work because the child and parent need to access it at the same time (though only the parent should be able to modify it, ensuring its safety); even copying the state doesn't work because the child then needs to update its local state with a new copy sent by the parent, which is also prone to mutability-related errors. Any tips on how to accomplish something like this? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Need help implementing some complex parent-child task behavior.
What if the state's fields are private, and in a different module than the players, but exposes getters to query the state? Then the players can't modify it, but if the component that processes the actions has visibility into the state's fields, it can modify them just fine. -Kevin On Feb 14, 2014, at 12:22 PM, Damien Radtke damienrad...@gmail.com wrote: I'm trying to write what is essentially a card game simulator in Rust, but I'm running into a bit of a roadblock with Rust's memory management. The gist of what I want to accomplish is: 1. In the program's main loop, iterate over several players and call their play method in turn. 2. Each play method should be able to send requests back to the parent in order to take certain actions, who will validate that the action is possible and update the player's state accordingly. The problem I'm running into is that, in order to let a player play and have the game validate actions for them, I would need to run each player in their own task, (I considered implementing it as each function call indicating a request for action [e.g. by returning Some(action), or None when finished] and calling it repeatedly until none are taken, but this makes the implementation for each player needlessly complex) but this makes for some tricky situations. My current implementation uses a DuplexStream to communicate back and forth, the child sending requests to the parent and the parent sending responses, but then I run into the issue of how to inform the child of their current state, but don't let them modify it outside of sending action requests. Ideally I'd like to be able to create an (unsafe) immutable pointer to the state held by the parent as mutable, but that gives me a values differ in mutability error. Other approaches so far have failed as well; Arcs don't work because I need to have one-sided mutability; standard borrowed pointers don't work because the child and parent need to access it at the same time (though only the parent should be able to modify it, ensuring its safety); even copying the state doesn't work because the child then needs to update its local state with a new copy sent by the parent, which is also prone to mutability-related errors. Any tips on how to accomplish something like this? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev smime.p7s Description: S/MIME cryptographic signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Need help implementing some complex parent-child task behavior.
Unfortunately, the type that maintains the state apparently doesn't fulfill Send, which confuses me because it's a struct that consists of a string, function pointer, and a few dynamically-sized vectors. Which of these types makes the struct as a whole violate Send? On Fri, Feb 14, 2014 at 2:47 PM, Kevin Ballard ke...@sb.org wrote: What if the state's fields are private, and in a different module than the players, but exposes getters to query the state? Then the players can't modify it, but if the component that processes the actions has visibility into the state's fields, it can modify them just fine. -Kevin On Feb 14, 2014, at 12:22 PM, Damien Radtke damienrad...@gmail.com wrote: I'm trying to write what is essentially a card game simulator in Rust, but I'm running into a bit of a roadblock with Rust's memory management. The gist of what I want to accomplish is: 1. In the program's main loop, iterate over several players and call their play method in turn. 2. Each play method should be able to send requests back to the parent in order to take certain actions, who will validate that the action is possible and update the player's state accordingly. The problem I'm running into is that, in order to let a player play and have the game validate actions for them, I would need to run each player in their own task, (I considered implementing it as each function call indicating a request for action [e.g. by returning Some(action), or None when finished] and calling it repeatedly until none are taken, but this makes the implementation for each player needlessly complex) but this makes for some tricky situations. My current implementation uses a DuplexStream to communicate back and forth, the child sending requests to the parent and the parent sending responses, but then I run into the issue of how to inform the child of their current state, but don't let them modify it outside of sending action requests. Ideally I'd like to be able to create an (unsafe) immutable pointer to the state held by the parent as mutable, but that gives me a values differ in mutability error. Other approaches so far have failed as well; Arcs don't work because I need to have one-sided mutability; standard borrowed pointers don't work because the child and parent need to access it at the same time (though only the parent should be able to modify it, ensuring its safety); even copying the state doesn't work because the child then needs to update its local state with a new copy sent by the parent, which is also prone to mutability-related errors. Any tips on how to accomplish something like this? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Need help implementing some complex parent-child task behavior.
Depends. If the string or the vectors are instead of ~, that would do it. Also, if the element type of the vector does not fulfill Send. Oh, and the function pointer is a function pointer, not a closure, right? -Kevin On Feb 14, 2014, at 12:59 PM, Damien Radtke damienrad...@gmail.com wrote: Unfortunately, the type that maintains the state apparently doesn't fulfill Send, which confuses me because it's a struct that consists of a string, function pointer, and a few dynamically-sized vectors. Which of these types makes the struct as a whole violate Send? On Fri, Feb 14, 2014 at 2:47 PM, Kevin Ballard ke...@sb.org wrote: What if the state's fields are private, and in a different module than the players, but exposes getters to query the state? Then the players can't modify it, but if the component that processes the actions has visibility into the state's fields, it can modify them just fine. -Kevin On Feb 14, 2014, at 12:22 PM, Damien Radtke damienrad...@gmail.com wrote: I'm trying to write what is essentially a card game simulator in Rust, but I'm running into a bit of a roadblock with Rust's memory management. The gist of what I want to accomplish is: 1. In the program's main loop, iterate over several players and call their play method in turn. 2. Each play method should be able to send requests back to the parent in order to take certain actions, who will validate that the action is possible and update the player's state accordingly. The problem I'm running into is that, in order to let a player play and have the game validate actions for them, I would need to run each player in their own task, (I considered implementing it as each function call indicating a request for action [e.g. by returning Some(action), or None when finished] and calling it repeatedly until none are taken, but this makes the implementation for each player needlessly complex) but this makes for some tricky situations. My current implementation uses a DuplexStream to communicate back and forth, the child sending requests to the parent and the parent sending responses, but then I run into the issue of how to inform the child of their current state, but don't let them modify it outside of sending action requests. Ideally I'd like to be able to create an (unsafe) immutable pointer to the state held by the parent as mutable, but that gives me a values differ in mutability error. Other approaches so far have failed as well; Arcs don't work because I need to have one-sided mutability; standard borrowed pointers don't work because the child and parent need to access it at the same time (though only the parent should be able to modify it, ensuring its safety); even copying the state doesn't work because the child then needs to update its local state with a new copy sent by the parent, which is also prone to mutability-related errors. Any tips on how to accomplish something like this? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev smime.p7s Description: S/MIME cryptographic signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Need help implementing some complex parent-child task behavior.
The function pointer is indeed a function pointer and all of the strings and vectors are ~, but the vector type is 'static. They're meant to hold references to card definitions, which is more efficient than passing around the cards themselves. I tried modifying the vectors to hold ~-strings instead, but it still didn't work. Looks like I'll need to do more research on Send. On Fri, Feb 14, 2014 at 3:19 PM, Kevin Ballard ke...@sb.org wrote: Depends. If the string or the vectors are instead of ~, that would do it. Also, if the element type of the vector does not fulfill Send. Oh, and the function pointer is a function pointer, not a closure, right? -Kevin On Feb 14, 2014, at 12:59 PM, Damien Radtke damienrad...@gmail.com wrote: Unfortunately, the type that maintains the state apparently doesn't fulfill Send, which confuses me because it's a struct that consists of a string, function pointer, and a few dynamically-sized vectors. Which of these types makes the struct as a whole violate Send? On Fri, Feb 14, 2014 at 2:47 PM, Kevin Ballard ke...@sb.org wrote: What if the state's fields are private, and in a different module than the players, but exposes getters to query the state? Then the players can't modify it, but if the component that processes the actions has visibility into the state's fields, it can modify them just fine. -Kevin On Feb 14, 2014, at 12:22 PM, Damien Radtke damienrad...@gmail.com wrote: I'm trying to write what is essentially a card game simulator in Rust, but I'm running into a bit of a roadblock with Rust's memory management. The gist of what I want to accomplish is: 1. In the program's main loop, iterate over several players and call their play method in turn. 2. Each play method should be able to send requests back to the parent in order to take certain actions, who will validate that the action is possible and update the player's state accordingly. The problem I'm running into is that, in order to let a player play and have the game validate actions for them, I would need to run each player in their own task, (I considered implementing it as each function call indicating a request for action [e.g. by returning Some(action), or None when finished] and calling it repeatedly until none are taken, but this makes the implementation for each player needlessly complex) but this makes for some tricky situations. My current implementation uses a DuplexStream to communicate back and forth, the child sending requests to the parent and the parent sending responses, but then I run into the issue of how to inform the child of their current state, but don't let them modify it outside of sending action requests. Ideally I'd like to be able to create an (unsafe) immutable pointer to the state held by the parent as mutable, but that gives me a values differ in mutability error. Other approaches so far have failed as well; Arcs don't work because I need to have one-sided mutability; standard borrowed pointers don't work because the child and parent need to access it at the same time (though only the parent should be able to modify it, ensuring its safety); even copying the state doesn't work because the child then needs to update its local state with a new copy sent by the parent, which is also prone to mutability-related errors. Any tips on how to accomplish something like this? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Need help implementing some complex parent-child task behavior.
Ah, I think the problem is that I'm trying to create a new task within a loop over an iterator, so each value is an -ptr and is therefore causing it to fail... On Fri, Feb 14, 2014 at 4:12 PM, Damien Radtke damienrad...@gmail.comwrote: The function pointer is indeed a function pointer and all of the strings and vectors are ~, but the vector type is 'static. They're meant to hold references to card definitions, which is more efficient than passing around the cards themselves. I tried modifying the vectors to hold ~-strings instead, but it still didn't work. Looks like I'll need to do more research on Send. On Fri, Feb 14, 2014 at 3:19 PM, Kevin Ballard ke...@sb.org wrote: Depends. If the string or the vectors are instead of ~, that would do it. Also, if the element type of the vector does not fulfill Send. Oh, and the function pointer is a function pointer, not a closure, right? -Kevin On Feb 14, 2014, at 12:59 PM, Damien Radtke damienrad...@gmail.com wrote: Unfortunately, the type that maintains the state apparently doesn't fulfill Send, which confuses me because it's a struct that consists of a string, function pointer, and a few dynamically-sized vectors. Which of these types makes the struct as a whole violate Send? On Fri, Feb 14, 2014 at 2:47 PM, Kevin Ballard ke...@sb.org wrote: What if the state's fields are private, and in a different module than the players, but exposes getters to query the state? Then the players can't modify it, but if the component that processes the actions has visibility into the state's fields, it can modify them just fine. -Kevin On Feb 14, 2014, at 12:22 PM, Damien Radtke damienrad...@gmail.com wrote: I'm trying to write what is essentially a card game simulator in Rust, but I'm running into a bit of a roadblock with Rust's memory management. The gist of what I want to accomplish is: 1. In the program's main loop, iterate over several players and call their play method in turn. 2. Each play method should be able to send requests back to the parent in order to take certain actions, who will validate that the action is possible and update the player's state accordingly. The problem I'm running into is that, in order to let a player play and have the game validate actions for them, I would need to run each player in their own task, (I considered implementing it as each function call indicating a request for action [e.g. by returning Some(action), or None when finished] and calling it repeatedly until none are taken, but this makes the implementation for each player needlessly complex) but this makes for some tricky situations. My current implementation uses a DuplexStream to communicate back and forth, the child sending requests to the parent and the parent sending responses, but then I run into the issue of how to inform the child of their current state, but don't let them modify it outside of sending action requests. Ideally I'd like to be able to create an (unsafe) immutable pointer to the state held by the parent as mutable, but that gives me a values differ in mutability error. Other approaches so far have failed as well; Arcs don't work because I need to have one-sided mutability; standard borrowed pointers don't work because the child and parent need to access it at the same time (though only the parent should be able to modify it, ensuring its safety); even copying the state doesn't work because the child then needs to update its local state with a new copy sent by the parent, which is also prone to mutability-related errors. Any tips on how to accomplish something like this? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
