New interface with time machine

[majabbour]

This PR implements the resize instruction, as well as the new update price logic, without implementing the TwapTracker (which is currently left as a byte array with no_op operations).

I would appreciate feedback on:
1- the interface between rust_oracle.rs and the time_machine
2- The way I compined all the into in price_t into one struct
3- The way I dealt with integer conversion
4- The resize instruction test. (Assuming it is combined with unit_tests for add_first_price)

[jayantk]

I left you a bunch of comments inline. The rust code is generally fine and the comments are minor. I am a little worried about the change to the build scripts / dockerfile though (see the inline comments). I think you're doing this in order to run the python tests, but it would be better to do this in a way that doesn't touch the production build pipeline.

[jayantk]

this name sounds like it updates the version field in the account, which it doesn't. It just resizes the account.

[majabbour]

The idea originally is that this is the generic upgrade account to the current version instruction. Happy to change the name though

[majabbour]

I think I will name it upgrade_account, so that you can pass accounts through it after any oracle upgrade

[jayantk]

why do you need trait Tracker? Will there be other objects that implement the same interface? If not, could this be impl TimeMachineWrapper instead?

[majabbour]

There will be!
The individual SMA and Tick trackers in the wrapper will all be Trackers

[jayantk]

I think this function and the one below should verify that the current status == TRADING

[majabbour]

Right, I do not need to check the previous status but it is always the last with trading status, but for the current one, there's no such gurantee, thanks

[majabbour]

I made so that add_price verifies that things have been initialized in addition to that

[jayantk]

typo price account

[guibescos]

typo

[jayantk]

still a typo here accountm

[guibescos]

You need to fix this, it's actually more like :

    let [funding_account, price_account, clock_account] = match accounts {
        [x, y,z ] => Ok([x, y, z]),
        [x, y,_ , z ] => Ok([x, y, z]),
        _ => Err(ProgramError::InvalidArgument),
    }?;

[jayantk]

Since this is a thin wrapper around c_entrypoint_wrapper, you want to avoid writing code that could accidentally change the behavior. The best way to have approached this problem, imo, would have been something like:

let c_ret_value = c_entrypoint_wrapper(input)?;

let price_account = accounts.get(2)?; 
let account_len = ...
match {
  ... => price_account.add_price_to_time_machine();
} 

If you structure your code that way, all of your additions happen after c_entrypoint_wrapper, which makes it hard for future edits to accidentally forget to call that function.

[guibescos]

typo

[guibescos]

Make this consistent with PythAccount for pc_price_t

[jayantk]

I pretty much had the same comments as @guibescos .

[jayantk]

Since this is a thin wrapper around c_entrypoint_wrapper, you want to avoid writing code that could accidentally change the behavior. The best way to have approached this problem, imo, would have been something like:

let c_ret_value = c_entrypoint_wrapper(input)?;

let price_account = accounts.get(2)?; 
let account_len = ...
match {
  ... => price_account.add_price_to_time_machine();
} 

If you structure your code that way, all of your additions happen after c_entrypoint_wrapper, which makes it hard for future edits to accidentally forget to call that function.

[jayantk]

typo: account

[jayantk]

still a typo here accountm

[guibescos]

Good to go