newmanrs / rpncalc Goto Github PK

Last refactor changed behaviour of the print statements showing the stored values. This kind of just makes a horrible mess of an output to things like: rpncalc 0 1 2 3 4 veca store_x 2 3 4 5 6 veca store_y _x 0 ^ _x 1 ^ hstack store_V _V T _V dot inv _V T dot _y dot

Command history in non-interactive mode always appends command history even if it's the same command. I.e. running rpncalc 1 1 + twice in a row will append twice.

Interactive mode would be better with a command history bound to up-arrow key.

Refactor utils classes to have better error handling.

Stored variables and other state are not stored in the command history, only the input command. Edit to store the full stack, stored variables, and flags given to the program. See #5. The lines might get long if I store json objects in addition to the commands, so printing may require textwrapping to terminal width like the help page did.

Having the stack in a module is not the only state that needs access and mutation from the calculator actions, as well as roll-back upon crash.

Create a "State" class that also contains verbose/not verbose modes, toggles for clearing the stack (or not) after commands, and move the stored values into this class as well.

This would also be a good time to store a history of the most recent few actions so that they can be repeated, something akin to rpncalc d4 10 repeat_n to roll 4-sided dice 10 times.

The state.py submodule contains singleton pattern that makes using this project as a submodule of another awkward. Consider refactoring and make the main command line loop (or wherever) thread instantiate a Calculator() object that encapsulates the state.

This probably a significant refactor, at the least:

• Move compute functions into new Calculator class
• Add instance of State to Calculator class
• ActionEnum class constructors needs to know what State object this calculator is using instead of module variables
  • Consider better control of access to the state object (most code uses take_1, take_2, take_n, and push operators) but others seem to read or mutate the state directly. Maybe should provide a read_all or read_n method, or add the print functions to the state class (#11?) and not custom to the ActionEnums.
• History module also is stateful/singleton and needs to be made into a class that is optionally instantiated by the Calculator class. This also should also improve the now hardcoded HIST_LENGTH and HIST_LOC constants as init parameters.

Fixing this should also allow me to use this project as a submodule for a streamlit app so I can have browser or phone based access to my own calculator demo using their free cloudservice.

Save/load functions have some quirky json serialization of data structures (casting deque to list) and probably ought to have tests.

Add interface to save and restore calculator state to files using the state classes' snapshot mechanisms to dictionary/json. This will allow users that store values as named variables to reload them later.

Main state "stack" for calculator possibly better as deque than list. Changing this probably requires some patches in most print statements involving the stack, which also probably should go via centralized functions instead of different parts of the code directly accessing the stack.

Catching generic errors especially in interactive mode is a bit dirty. Make custom errors to catch in all of the calculator operators.

• Compact pushing of values/constants to stack to have one print statement only.
• Print statements also ought not trigger double print in verbose mode.
• Check which other operators should not trigger print statements. Probably the entire set of idempotent operators.

The input parsing and behavior of the calculator with different arg flags in parse_expression and compute_rpn remains awkward. The function run_from_expr in the test suite, interactive and noninteractive modes call these functions slightly differently, but these should be unified. The clever hack of inserting print statements to implement verbose mode also causes kludges elsewhere when repeating last command (have to ignore prints). This could be removed just by making flags incl/ verbose part of the calculator state, and triggering on item.action() consumption.