modulatingforce/forcebot_rs

Fork 0

[ENH] Routine functionality #5

New issue

Open

opened 2023-11-29 19:48:49 -05:00 by modulatingforce · 3 comments

modulatingforce commented

2023-11-29 19:48:49 -05:00

Owner

Initial Description

Similar to py implementation of forcebot, I'd like some easy way to implement routines that can be easily defined so that a developer can just worry about what the routine does and how often the routine is triggered

This could be used, for example, to post periodic messages in chat after x number of minutes

Not a high priority at the moment

Plan of Action :

Basic Routine Functionality - #40
Advanced Routine Functionality -
- This will include Additional Management of Routines at Bot Module level ; these are not required though to create and start basic routines

# Initial Description Similar to py implementation of forcebot, I'd like some easy way to implement routines that can be easily defined so that a developer can just worry about what the routine does and how often the routine is triggered This could be used, for example, to post periodic messages in chat after x number of minutes Not a high priority at the moment --- # Plan of Action : - [ ] Basic Routine Functionality - https://git.flake.sh/modulatingforce/forcebot_rs/pulls/40 - [ ] Advanced Routine Functionality - - This will include Additional Management of Routines at Bot Module level ; these are not required though to create and start basic routines

modulatingforce added the

Priority

Low

Kind/Feature

labels 2023-11-29 19:48:49 -05:00

modulatingforce added this to the Rust Learning project 2023-11-29 19:48:49 -05:00

modulatingforce added this to the Prototype 1.0 milestone 2023-12-10 16:42:33 -05:00

modulatingforce self-assigned this 2023-12-22 15:28:27 -05:00

modulatingforce commented

2023-12-22 15:32:49 -05:00

Author

Owner

Thinking about this off and on, I thought of maybe having Routine s be similar to Listener BotAction , and simply call the execution body when a servermsg is received . But a Routine would then really depend on whether the bot receives a servermsg or not

However, I believe there might be better ways involving async related coding/functionality? Worst case, I can review py twitchio code or compare with how others use the same library to create routines

Thinking about this off and on, I thought of maybe having `Routine` s be similar to `Listener` `BotAction` , and simply call the *execution body* when a *servermsg* is received . But a `Routine` would then really depend on whether the bot receives a *servermsg* or not However, I believe there might be better ways involving *async* related coding/functionality? Worst case, I can review py twitchio code or compare with how others use the same library to create routines

modulatingforce commented

2024-03-20 13:38:36 -04:00

Author

Owner

I am 100% certain this can be implemented through async

Maybe something like the following

enum Routine {
   name : String ,
   module : BotModule ,
   channel : Option<Channel<String>>,
   exec_body : async fn , 
   duration : Duration , 
   skipFirstIteration : bool , 
   join_handle : Option<Join_Handle>
}

the async fn could be defined like the following

async fn routinebody() {
   loop {
       println!("world");
       sleep(Duration::from_millis(500)).await
       }
}

Generally, a Module Developer May be able to do the following define a module, then spawn that module without any extra functionality from the bot

let mut a = Routine {
   name : "Socials Reminder" , 
   module : BotModule("Experiments001") , 
   channel : Some(Channel("testchannel")),
   exec_body : routinebody,
   duration : Duration::from_millis(500) ,
  join_handle : None , 
}

a.join_handle = Some(tokio::spawn(async { 
   a.exec_body()
   }));

// then after , some logic to add to a collection of Bot Routines

That, or I could add in methods to Routine to Start()/Stop() for ease

I would think we can store this as Vector<Routine> . If required, we can create business logic to abort() these handles

https://docs.rs/tokio/latest/tokio/task/struct.JoinHandle.html#method.abort

Hmm. I'm pretty sure the above can be refined even more, but working atm

I am 100% certain this can be implemented through async Maybe something like the following ```rust enum Routine { name : String , module : BotModule , channel : Option<Channel<String>>, exec_body : async fn , duration : Duration , skipFirstIteration : bool , join_handle : Option<Join_Handle> } ``` the async fn could be defined like the following ```rust async fn routinebody() { loop { println!("world"); sleep(Duration::from_millis(500)).await } } ``` Generally, a Module Developer May be able to do the following define a module, then spawn that module without any extra functionality from the bot ```rust let mut a = Routine { name : "Socials Reminder" , module : BotModule("Experiments001") , channel : Some(Channel("testchannel")), exec_body : routinebody, duration : Duration::from_millis(500) , join_handle : None , } a.join_handle = Some(tokio::spawn(async { a.exec_body() })); // then after , some logic to add to a collection of Bot Routines ``` That, or I could add in methods to `Routine` to `Start()`/`Stop()` for ease --- I would think we can store this as `Vector<Routine>` . If required, we can create business logic to `abort()` these handles https://docs.rs/tokio/latest/tokio/task/struct.JoinHandle.html#method.abort --- Hmm. I'm pretty sure the above can be refined even more, but working atm

modulatingforce commented

2024-03-21 14:59:26 -04:00

Author

Owner

As mentioned in #37 , ideally the following is added whenever Routine functionality is added
- FUTURE For Routines, when a module is set to Disabled, it should also Abort all running routines for the Module >> At least ensure this requirement is in the Routines issue

- [ ] As mentioned in https://git.flake.sh/modulatingforce/forcebot_rs/pulls/37 , ideally the following is added whenever `Routine` functionality is added - [ ] **FUTURE** For `Routines`, when a module is set to Disabled, it should also Abort all running routines for the Module >> At least ensure this requirement is in the Routines issue

modulatingforce referenced this issue

2024-03-21 14:59:52 -04:00

ModulesManager #37

modulatingforce referenced this issue

2024-03-22 21:30:15 -04:00

[CORE] ModulesManager #26

modulatingforce referenced this issue

2024-03-22 22:51:33 -04:00

WIP: Basic Routine Functionality #40

modulatingforce added a new dependency 2024-03-22 22:54:04 -04:00

#40 WIP: Basic Routine Functionality

modulatingforce added the