WIP: Basic Routine Functionality #40

modulatingforce · 2024-03-22T22:51:33-04:00

modulatingforce commented

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

To address #5

Plan of Action :

Review Routine functionality from py implementation
- Related : https://twitchio.dev/en/stable/exts/routines.html
Design working Routines functionality that using findings from #5
Code/Implement Routines Feature
BotCommands that allow you to manage Routines (at least Basic management) - ⏩ As Mentioned in #5 , will be handled in separate future PR
To Test functionality, create a fun countdown BotCommand that allows an Elevated Chatter to
- 1. -a add channels to target a routine message
- 1. start to start the routine with an input String, that sends a number of messages to the targeted channels with a countdown, until it reaches 0 when it sends a cute or funny message
Unit Tests

To address https://git.flake.sh/modulatingforce/forcebot_rs/issues/5 # Plan of Action : - [x] Review Routine functionality from py implementation - Related : https://twitchio.dev/en/stable/exts/routines.html - [x] Design working Routines functionality that using findings from https://git.flake.sh/modulatingforce/forcebot_rs/issues/5 - [x] Code/Implement Routines Feature - [x] BotCommands that allow you to manage Routines (at least Basic management) - ⏩ As Mentioned in https://git.flake.sh/modulatingforce/forcebot_rs/issues/5 , will be handled in separate future PR - [ ] To Test functionality, create a fun `countdown` `BotCommand` that allows an Elevated Chatter to - 1. `-a` add channels to target a routine message - 2. `start` to start the routine with an input `String`, that sends a number of messages to the targeted channels with a countdown, until it reaches 0 when it sends a cute or funny message - [ ] Unit Tests

modulatingforce added this to the Rust Learning project 2024-03-22 22:51:42 -04:00

modulatingforce self-assigned this 2024-03-22 22:51:49 -04:00

modulatingforce added the

Kind/Feature

Priority

High

labels 2024-03-22 22:52:03 -04:00

modulatingforce added this to the Prototype 1.0 milestone 2024-03-22 22:52:10 -04:00

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

#5 [ENH] Routine functionality

modulatingforce commented

2024-03-22 23:03:04 -04:00

Reviewing the py twitchio documentation on routines - https://twitchio.dev/en/stable/exts/routines.html

The API wasn't too complicated . Among the functionality and attributes it included the following

completed_iterations
remaining_iterations
start_time
cancel()
change_interval()
restart()
- you could specify stop_on_error (bool) whether to stop and cancel the routine on error . Defaults to True
- you could specify force (bool) to cancel the currently running routine immediately and restart or if False, allow the routine to finish it's current iteration
start()
- you could specify stop_on_error (bool) whether to stop and cancel the routine on error . Defaults to True
stop()

Reviewing the py `twitchio` documentation on routines - https://twitchio.dev/en/stable/exts/routines.html The API wasn't too complicated . Among the functionality and attributes it included the following - `completed_iterations` - `remaining_iterations` - `start_time` - `cancel()` - `change_interval()` - `restart()` - you could specify `stop_on_error` (`bool`) whether to stop and cancel the routine on error . Defaults to True - you could specify `force` (`bool`) to cancel the currently running routine immediately and restart or if False, allow the routine to finish it's current iteration - `start()` - you could specify `stop_on_error` (`bool`) whether to stop and cancel the routine on error . Defaults to True - `stop()`

modulatingforce commented

2024-03-22 23:19:20 -04:00

From Obsidian Vault note Brainstorm 0322

[x] Desired Functionality

The following might be a basic starter draft of what I want. Let's see what I come up with

Basic Functionality :
- Define a Routine , including it's characteristics
- Add it to the Modules statusdb with it's BotModule - ⏩ As Mentioned in #5 , will be handled in separate future PR
- Retrieve that Routine from statusdb - ⏩ As Mentioned in #5 , will be handled in separate future PR
- start() the Routine
- at any point, stop() the Routine
Enhanced Features :
- Clone a Routine
  - This also adds an entry if required in statusdb , depending on where clones are separated - - ⏩ As Mentioned in #5 , will be handled in separate future PR
  - Clones can be managed separately - ✅ can be managed with existing HashMap ontop of the new Routine objects
- Able to take any Routine and Adjust characteristics - ✅ Routine has RoutineAttr
BotAction Routine Management
- When the BotModule is Disabled , ensure that all related Routine are stop() ⏩ As Mentioned in #5 , will be handled in separate future PR

_From Obsidian Vault note Brainstorm 0322_ # [x] Desired Functionality The following might be a basic starter draft of what I want. Let's see what I come up with - [x] Basic Functionality : - [x] Define a Routine , including it's characteristics - [x] Add it to the Modules `statusdb` with it's `BotModule` - ⏩ As Mentioned in https://git.flake.sh/modulatingforce/forcebot_rs/issues/5 , will be handled in separate future PR - [x] Retrieve that Routine from `statusdb` - ⏩ As Mentioned in https://git.flake.sh/modulatingforce/forcebot_rs/issues/5 , will be handled in separate future PR - [x] `start()` the Routine - [x] at any point, `stop()` the Routine - [x] Enhanced Features : - Clone a Routine - [x] This also adds an entry if required in `statusdb` , depending on where clones are separated - - ⏩ As Mentioned in https://git.flake.sh/modulatingforce/forcebot_rs/issues/5 , will be handled in separate future PR - [x] Clones can be managed separately - ✅ can be managed with existing `HashMap` ontop of the new `Routine` objects - [x] Able to take any Routine and Adjust characteristics - ✅ `Routine` has `RoutineAttr` - [x] `BotAction` `Routine` Management - When the `BotModule` is `Disabled` , ensure that all related `Routine` are `stop()` ⏩ As Mentioned in https://git.flake.sh/modulatingforce/forcebot_rs/issues/5 , will be handled in separate future PR

modulatingforce added 1 commit 2024-03-25 23:26:47 -04:00

Merge branch 'main' into routines-functionality

ci/woodpecker/pr/cargo-checks Pipeline was successful

Details

34c3c8af7a

modulatingforce added 3 commits 2024-03-26 16:56:37 -04:00

(init) routine methods 6c7290883f

runonce implementation 2ba92388a2

(init) experiment test module

ci/woodpecker/pr/cargo-checks Pipeline was successful

Details

4e9316ad49

modulatingforce added a new dependency 2024-03-26 19:47:41 -04:00

#46 WIP: Child fn should be able to access BotAction Header

modulatingforce referenced this pull request

2024-03-26 19:49:18 -04:00

WIP: Child fn should be able to access BotAction Header #46

modulatingforce commented

2024-03-26 21:57:40 -04:00

This is in essence a small demo of the problem scenario I'm facing when developing the start() method

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=5c743e156cc110fc5a8c319991d44a21

This is in essence a small demo of the problem scenario I'm facing when developing the `start()` method https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=5c743e156cc110fc5a8c319991d44a21

modulatingforce commented

2024-03-26 22:42:16 -04:00

This is in essence a small demo of the problem scenario I'm facing when developing the start() method

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=5c743e156cc110fc5a8c319991d44a21

Following may be the workaround - something similar I did with existing runner and listener_main_prvmsg for BotInstance

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0fc9e09bc9d4d53ee492814a2914b4e8

> This is in essence a small demo of the problem scenario I'm facing when developing the `start()` method > > https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=5c743e156cc110fc5a8c319991d44a21 Following may be the workaround - something similar I did with existing `runner` and `listener_main_prvmsg` for `BotInstance` https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0fc9e09bc9d4d53ee492814a2914b4e8

modulatingforce added 2 commits 2024-03-27 02:35:36 -04:00

smol debug in identity 5249c3af25

(cont) routine start

ci/woodpecker/pr/cargo-checks Pipeline was successful

Details

3f8e798050

modulatingforce added 1 commit 2024-03-27 10:18:19 -04:00

(cont) start runonce

ci/woodpecker/pr/cargo-checks Pipeline was successful

Details

b08d91af5d

modulatingforce referenced this pull request

2024-03-27 11:40:25 -04:00

Routine.Start() to run it's execution body for given duration #47

modulatingforce reviewed 2024-03-27 11:45:17 -04:00

modulatingforce left a comment

Addressing the following separate issue in #47

src/core/botmodules.rs Outdated

					
				@ -573,0 +919,4 @@

				                    // while inroutine.read().await.remaining_iterations.unwrap_or(0) > 1 {

				                        // execution body

				                        inroutine.read().await.loopbody().await;

modulatingforce commented

2024-03-27 11:44:27 -04:00

During Live Tests , issuing BotCommand appears to setup & begin to start() the routine , but never makes it to this point when the routine is started .

Strangely, the traces in this same tokio::spawn are being logged? But nothing is being logged within the loopbody() or after this line

Created PR #47 to address this issue

During Live Tests , issuing `BotCommand` appears to setup & begin to `start()` the routine , but never makes it to this point when the routine is started . Strangely, the traces in this same `tokio::spawn` are being logged? But nothing is being logged within the `loopbody()` or after this line Created PR #47 to address this issue

modulatingforce commented

2024-03-28 00:52:27 -04:00

Fixed . Refer to Resolution Notes - #47 (comment)

Fixed . Refer to Resolution Notes - https://git.flake.sh/modulatingforce/forcebot_rs/pulls/47#issuecomment-792

modulatingforce marked this conversation as resolved

modulatingforce referenced this pull request

2024-03-27 11:46:10 -04:00

Routine.Start() to run it's execution body for given duration #47

modulatingforce reviewed 2024-03-27 13:32:40 -04:00

modulatingforce left a comment

Need to check if this area is impacting #47

- [x] Need to check if this area is impacting https://git.flake.sh/modulatingforce/forcebot_rs/pulls/47

src/custom/experimental/experiment003.rs Outdated

					
				@ -0,0 +190,4 @@

				            params.clone()

				        ).await;

				        newr.clone().write().await.join_handle.take().expect("Issue with join handle").await.unwrap();

modulatingforce commented

2024-03-27 13:31:53 -04:00

newr
.clone()   // <-- is this required?
.write()
.await
.join_handle
.take()  // <-- is this an issue? Is this related to https://git.flake.sh/modulatingforce/forcebot_rs/pulls/47 ? 
.expect("Issue with join handle")
.await.unwrap();

``` newr .clone() // <-- is this required? .write() .await .join_handle .take() // <-- is this an issue? Is this related to https://git.flake.sh/modulatingforce/forcebot_rs/pulls/47 ? .expect("Issue with join handle") .await.unwrap(); ```

modulatingforce commented

2024-03-27 14:18:42 -04:00

Removing this statement completely seems to help resolve #47

Removing this statement completely seems to help resolve https://git.flake.sh/modulatingforce/forcebot_rs/pulls/47

modulatingforce commented

2024-03-28 00:53:30 -04:00

Fixed . Refer to Resolution Notes - #47 (comment)

Fixed . Refer to Resolution Notes - https://git.flake.sh/modulatingforce/forcebot_rs/pulls/47#issuecomment-792

modulatingforce marked this conversation as resolved

modulatingforce reviewed 2024-03-27 13:49:08 -04:00

modulatingforce left a comment

Consider adjusting Routine.join_handle

Consider adjusting `Routine.join_handle`

src/core/botmodules.rs Outdated

					
				@ -573,0 +622,4 @@

				    exec_body: bot_actions::actions_util::ExecBody,

				    // parent_params : Option<ExecBodyParams> ,

				    parent_params : ExecBodyParams ,

				    pub join_handle : Option<JoinHandle<()>> ,

modulatingforce commented

2024-03-27 13:48:42 -04:00

Should we make this just JoinHandle<()> ? This will require Routines to always have this defined

Should we make this just `JoinHandle<()>` ? This will require `Routines` to always have this defined

modulatingforce commented

2024-03-27 14:11:03 -04:00

No Keep with Option<JoinHandle<()>> . While constructing in Routine::from() , there is no JoinHandle yet . A JoinHandle is created at Task Spawn (which should be when it is Start)

No Keep with `Option<JoinHandle<()>>` . While constructing in `Routine::from()` , there is no `JoinHandle` yet . A `JoinHandle` is created at Task Spawn (which should be when it is `Start`)

modulatingforce marked this conversation as resolved

modulatingforce added 1 commit 2024-03-27 14:52:22 -04:00

proper join handling at custom

ci/woodpecker/pr/cargo-checks Pipeline was successful

Details

8da8460e47

modulatingforce added the

Bot_Code

Core

label 2024-03-27 17:47:59 -04:00

modulatingforce added the

Complexity

Advanced

label 2024-03-27 18:22:51 -04:00

modulatingforce modified the project from Rust Learning to Forcebot Prototype 1.0 Push

2024-03-27 18:31:51 -04:00

modulatingforce added the

Phase 3.0

Coding > Implementation

label 2024-03-27 20:12:23 -04:00

modulatingforce commented

2024-03-28 01:03:40 -04:00

[x] Routine Methods

validate_self_attr(self)
from() - Constructor

    pub async fn from(
        name : String ,
        module : BotModule ,
        channel : Channel,
        routine_attr : Vec<RoutineAttr> ,
        exec_body : bot_actions::actions_util::ExecBody ,
        parent_params : ExecBodyParams
    ) -> Result<
            Arc<RwLock<Routine>>,
            String
        >

start()

    pub async fn start(
        trg_routine_ar : Arc<RwLock<Routine>>
    ) -> Result<Arc<RwLock<Routine>>,String>

stop(&self) -> Result<String,String>
cancel(&self) -> Result<String,String>
restart

    pub async fn restart(
        &self,
        _force : bool
    ) -> Result<String,String>

change_channel()

    pub fn change_channel(
        &self,
        _channel : Channel
    ) -> Result<String,String>

set_routine_attributes()

    pub async fn set_routine_attributes(
        &mut self,
        routine_attr : Vec<RoutineAttr>
    ) -> Result<String,String>

# [x] Routine Methods - [x] `validate_self_attr(self)` - [x] `from()` - Constructor ```rust pub async fn from( name : String , module : BotModule , channel : Channel, routine_attr : Vec<RoutineAttr> , exec_body : bot_actions::actions_util::ExecBody , parent_params : ExecBodyParams ) -> Result< Arc<RwLock<Routine>>, String > ``` - [x] `start()` ```rust pub async fn start( trg_routine_ar : Arc<RwLock<Routine>> ) -> Result<Arc<RwLock<Routine>>,String> ``` - [x] ` stop(&self) -> Result<String,String> ` - [x] `cancel(&self) -> Result<String,String> ` - [x] `restart` ```rust pub async fn restart( &self, _force : bool ) -> Result<String,String> ``` - [x] `change_channel()` ```rust pub fn change_channel( &self, _channel : Channel ) -> Result<String,String> ``` - [x] `set_routine_attributes()` ```rust pub async fn set_routine_attributes( &mut self, routine_attr : Vec<RoutineAttr> ) -> Result<String,String> ```

modulatingforce changed title from ~~WIP: Routines Functionality~~ to WIP: Core Routines Functionality

2024-03-28 09:23:03 -04:00

modulatingforce changed title from ~~WIP: Core Routines Functionality~~ to WIP: Basic Routines Functionality

2024-03-28 09:23:09 -04:00

modulatingforce changed title from ~~WIP: Basic Routines Functionality~~ to WIP: Basic Routine Functionality

2024-03-28 09:24:39 -04:00

modulatingforce referenced this pull request

2024-03-28 09:25:58 -04:00

[ENH] Routine functionality #5

modulatingforce added

Phase 4.0

QA > Unit Testing & Design

and removed

Phase 3.0

Coding > Implementation

labels 2024-03-28 09:32:50 -04:00

modulatingforce added 16 commits 2024-03-29 09:05:40 -04:00

comments cleanup 226da4362a

cleanup start impl 669b2da871

custom start test fn 537c3565a2

comments 60fae25419

(cont) routine methods e963ae250d

impl other routine attr 6c3a151668

impl stop 4637312da9

routine methods ca9361cc93

ExecBody & routine addl references 2a1a7f8503

routine assigns self reference at construct 6d3b5eee41

custom countdown c27dd3b86f

fixed routine attr validation logic 1b534ebeb7

addl debugging 26f67787d7

ISSUE - commented out problem code? 5c35ad114a

corrected error with validate_attr 66195138f8

ISSUE - potential lock issue

ci/woodpecker/pr/cargo-checks Pipeline was successful

Details

b5e95668a5

modulatingforce reviewed 2024-03-29 09:23:54 -04:00

modulatingforce left a comment

Addressing in PR - #51
This is considered a block of the current PR

- [ ] Addressing in PR - https://git.flake.sh/modulatingforce/forcebot_rs/pulls/51 This is considered a block of the current PR

src/custom/experimental/experiment003.rs

					
				@ -0,0 +412,4 @@

				            if let BotAction::R(c) = &*guard {

				                println!("{:?}",c.read().await.channel);

				            }

				            println!("Critical code area end"); // <= 03.29 - ISSUE This is NOT printed

modulatingforce commented

2024-03-29 09:19:36 -04:00

ISSUE . The defined Routine's Custom Execution Body is being reached (so the custom fn is being triggered as expected); However, I believe at L413 where c.read().await.channel , it never goes beyond that point within the same Custom fn body

Even if the bot continues to be responsive (i.e., the main bot continues to run), the rest of the routine is not. I believe this is suggesting there's a lock with one of the objects we're introducing with this feature . In the above line, I believe the lock involves ExecBodyParam's curr_act value

**_ISSUE ._** The defined Routine's Custom Execution Body is being reached (so the custom `fn` is being triggered as expected); However, I believe at L413 where `c.read().await.channel` , it never goes beyond that point within the same Custom `fn` body Even if the bot continues to be responsive (i.e., the `main` bot continues to run), the rest of the routine is not. I *believe* this is suggesting there's a lock with one of the objects we're introducing with this feature . In the above line, I believe the lock involves `ExecBodyParam`'s `curr_act` value