Difference between revisions of "User:Vikram Atreya/GSoC21/Project Report"
From BRL-CAD
| Line 3: | Line 3: | ||
*'''GSoC Project:''' Implementing UNDO | *'''GSoC Project:''' Implementing UNDO | ||
| − | The project started with deciding which kind of undo to be implemented. Various implementations were thought about including a complete re-run approach, partial checkpoint, full checkpoint, etc as discussed in detail in my [https://docs.google.com/document/d/1cZLgqVvxOiy7PgkUzEzeyXXhmLx1sEgRB1xw3hDFUlA/edit?usp=sharing| | + | The project started with deciding which kind of undo to be implemented. Various implementations were thought about including a complete re-run approach, partial checkpoint, full checkpoint, etc as discussed in detail in my [https://docs.google.com/document/d/1cZLgqVvxOiy7PgkUzEzeyXXhmLx1sEgRB1xw3hDFUlA/edit?usp=sharing|Proposal]. Using a version control system like libgit2 was also explored, but was found to be sub-optimal since it was occupying a lot of extra space and was also not very time efficient. |
| − | It was decided that the undo would be implemented using a partial checkpoint-like approach, where a change in an object at any step would be the only thing stored at that step instead of storing a full checkpoint of the .g file at that point. | + | It was decided that the undo would be implemented using a partial checkpoint-like approach, where a change in an object at any step would be the only thing stored at that step instead of storing a full checkpoint of the .g file at that point. After each step, we would need to store the last action and some details like which action and object. this information is stored as a string-value-pair in the _GLOBAL object. Initially, this data was stored in 2 separate variables one for the last action and one for object being acted upon. |
| − | To be | + | Since storing different information divided over many variables is not suitable, a data structure was made to hold all the information within it. This proved to be tough and making a linked list of these data structures wasn't easy. So a method was chosen to have all the information in 1 string and store that in _GLOBAL. |
| + | To be contined... | ||
Revision as of 00:35, 23 August 2021
Project Report
- Student Name: Vikram Atreyapurapu
- GSoC Project: Implementing UNDO
The project started with deciding which kind of undo to be implemented. Various implementations were thought about including a complete re-run approach, partial checkpoint, full checkpoint, etc as discussed in detail in my [1]. Using a version control system like libgit2 was also explored, but was found to be sub-optimal since it was occupying a lot of extra space and was also not very time efficient. It was decided that the undo would be implemented using a partial checkpoint-like approach, where a change in an object at any step would be the only thing stored at that step instead of storing a full checkpoint of the .g file at that point. After each step, we would need to store the last action and some details like which action and object. this information is stored as a string-value-pair in the _GLOBAL object. Initially, this data was stored in 2 separate variables one for the last action and one for object being acted upon. Since storing different information divided over many variables is not suitable, a data structure was made to hold all the information within it. This proved to be tough and making a linked list of these data structures wasn't easy. So a method was chosen to have all the information in 1 string and store that in _GLOBAL.
To be contined...
